Hi Enrico, On Thu, 8 Aug 2019 11:17:53 +0200, Enrico Weigelt, metux IT consult wrote: > On 02.08.19 14:51, Jean Delvare wrote: > > These patches fix a couple of issues with the i2c-piix4 driver on > > AMD Family 16h Model 30h SoCs and add ACPI-based enumeration to the > > i2c-piix4 driver. > > Can you tell a little bit more about what devices are behind the smbus ? > I recall the G-412 SoCs (such as on apu2+ boards) have an Hudson inside > and fall into this category. (I'll have to check when back in office), > so (as the apu2 platform driver maintainer) I'm very interested in this. Unfortunately not. I only picked up from where Andrew Cooks left, due to me being way too slow to review his patches. I did not want his work to be lost. I was able to test the first 2 patches which fix bugs, but not the 3rd one which deals with ACPI devices. There does not seem to be any such device on the 2 test machines I have remotely access to. > Does the probing need some special BIOS support (or do the necessary > table entries already come from aegesa) ? I assume that ACPI devices are declared in one of the ACPI tables, so it comes from the "BIOS", yes, whatever form it takes these days. > I have to admit, I'm still confused by the AMD documentation - haven't > found a clear documentation on what peripherals exactly are in the > G-412 SoC, just puzzled together that the FCH seems to be an Hudson, > probably v2. There also seems to be some relation between smbus and > gpio, but the gpio's are directly memory-mapped - no idea whether they > just share the same base address register or the gpios are really behind > smbus and some hw logic directy maps them into mmio space ... > Do you happen to have some more information on that ? I remember noticing long ago that SMBus ports were using GPIO pins, so these pins could be used for SMBus or for any other purpose. I could not find any way to figure out from the registers if a given pin pair was used for SMBus or not, which is pretty bad because it means we are blindly instantiating ALL possible SMBus ports even if some of the pins are used for a completely different purpose. It was over 1 year ago though, so I don't remember the details, and my findings then may not apply to the most recent hardware. > By the way: I'm considering collecting some hw documentation in the > kernel tree (maybe Documentation/hardware/...) - do you folks think > that's a good idea ? No. Only documentation specifically related to the Linux kernel should live in the kernel tree. OS-neutral documentation must go somewhere else. -- Jean Delvare SUSE L3 Support
