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? >>> > > >
