Re: [PATCH] i2c: piix4: Replace piix4_smbus driver's cd6h/cd7h port io accesses with mmio accesses
From: Terry Bowman
Date: Tue Jan 11 2022 - 19:41:05 EST
On 1/11/22 10:17, Andy Shevchenko wrote:
> On Tue, Jan 11, 2022 at 5:50 PM Terry Bowman <Terry.Bowman@xxxxxxx> wrote:
>> On 1/11/22 8:54 AM, Andy Shevchenko wrote:
>>> On Tue, Jan 11, 2022 at 4:53 PM Andy Shevchenko
>>> <andy.shevchenko@xxxxxxxxx> wrote:
>>>> On Tue, Jan 11, 2022 at 4:13 PM Terry Bowman <Terry.Bowman@xxxxxxx> wrote:
>>>>> The cd6h/cd7h port I/O can be disabled on recent AMD processors and these
>>>>> changes replace the cd6h/cd7h port I/O accesses with with MMIO accesses.
>>>>> I can provide more details or answer questions.
>>>>
>>>> AFAIU the issue the list of questions looks like this (correct me, if
>>>> I'm wrong):
>>>> - some chips switched from I/O to MMIO
>>>> - the bus driver has shared resources with another (TCO) driver
>>>>
>> Correct
>>
>>>> Now, technically what you are trying is to find a way to keep the
>>>> original functionality on old machines and support new ones without
>>>> much trouble.
>>>>
>>>> From what I see, the silver bullet may be the switch to regmap as we
>>>> have done in I2C DesignWare driver implementation.
>>>>
>>>> Yes, it's a much more invasive solution, but at the same time it's
>>>> much cleaner from my p.o.v. And you may easily split it to logical
>>>> parts (prepare drivers, switch to regmap, add a new functionality).
>>>>
>>>> I might be missing something and above not gonna work, please tell me
>>>> what I miss in that case.
>
>>> On top of that I'm wondering why slow I/O is used? Do we have anything
>>> that really needs that or is it simply a cargo-cult?
>>
>> The efch SMBUS & WDT previously only supported a port I/O interface
>> (until recently) and thus dictated the HW access method.
>
> I believe you didn't get my question. Sorry for that. Elaboration below.
>
> The code is using in*_p() and out*_p() accessors (pay attention to the _p part).
>
> My question is about that.
>
>> Wolfram pointed out some AMD laptops suffer from slow trackpad [1] and
>> this is part of the fix.
>>
>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2FCAPoEpV0ZSidL6aMXvB6LN1uS-3CUHS4ggT8RwFgmkzzCiYJ-XQ%40mail.gmail.com&data=04%7C01%7CTerry.Bowman%40amd.com%7Cded2c3a486854ef44c3408d9d51e0cad%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637775147318596002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lKNVA1xFkS5bIxDS4%2BdCXVPKlrIOY9PV%2BW9sLtnR630%3D&reserved=0
>
> I see, but still it never worked, correct?
>
I was not familiar with the trackpad issue until a few days ago. According
to Miroslav's post, one of the issues is resolved but their is an interrupt
flood still to be resolved.
>>>>> On 1/11/22 6:39 AM, Wolfram Sang wrote:
>>>>>>
>>>>>>> I have briefly read the discussion by the link you provided above in
>>>>>>> this thread. I'm not sure I understand the issue and if Intel hardware
>>>>>>> is affected. Is there any summary of the problem?
>>>>>>
>>>>>> I guess the original patch description should explain it. You can find
>>>>>> it here:
>>>>>>
>>>>>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Flinux-i2c%2Fpatch%2F20210715221828.244536-1-Terry.Bowman%40amd.com%2F&data=04%7C01%7CTerry.Bowman%40amd.com%7Cded2c3a486854ef44c3408d9d51e0cad%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637775147318596002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oNfdc6ozDE57vqwnEH4n2KQfXdxcF9rAiI9R592CKv4%3D&reserved=0
>>>>>>
>>>>>> If this is not sufficient, hopefully Terry can provide more information?
>>>
>
>
>