Re: [PATCH] i2c: piix4: Replace piix4_smbus driver's cd6h/cd7h port io accesses with mmio accesses

[Terry Bowman]

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.  

Wolfram pointed out some AMD laptops suffer from slow trackpad [1] and 
this is part of the fix. 

[1] https://lore.kernel.org/r/CAPoEpV0ZSidL6aMXvB6LN1uS-3CUHS4ggT8RwFgmkzzCiYJ-XQ@xxxxxxxxxxxxxx

> 
>>> 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&amp;data=04%7C01%7CTerry.Bowman%40amd.com%7C89e551e0ebe94607beaf08d9d51288f9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637775097863907004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=gvJ0FC9MVacQunc8uMJ6oJEw0pGcisu9muQkE8u4rxY%3D&amp;reserved=0
>>>>
>>>> If this is not sufficient, hopefully Terry can provide more information?
>