CCing the people involved in this commit... On Thu, May 17, 2018 at 06:16:41PM +0100, Will Wagner wrote: > Hello, > > I have a Fujitsu DS3313-S6 mainboard with a GX-424CC apu on it (http://www.fujitsu.com/fts/products/computing/peripheral/mainboards/industrial-mainboards/d3313s.html). > It identifies as having PCI device 0x1022:780b which is > PCI_DEVICE_ID_AMD_HUDSON2_SMBUS > > The i2c-piix4.c driver was broken for me by commit 6befa3fde65f i2c: piix4: > Support alternative port selection register > > In that commit it added support for accessing the SMBus from either 0x2c or > alternatively 0x2e. The commit log comment says that the alternative > register is the only method supported for the Hudson2 chipset and so in the > code if the PCIe vendorId is AMD it is hard coded to use the alternative > register. > > Use of this alternative register on my board produces random locks and i2c > transaction errors. If I instead change the code so that it reads > Smbus0SelEn (0x2f.) to decide how to access it then it decides on Smbus0En > (0x2c) and everything works again great. > > There is no justification in the commit message for why only the alternative > is supported for Hudson2. I have tried looking in the AMD documentation, > unfortunately the BKDG for family 16h models 30h-3Fh doesn't seem to > document any of these registers (whereas it is covered in the SB800 > reference guide). > > I'd love to submit a patch that fixes this issue, but without better > documentation I'm not sure if it is invalid on some hardware to check > Smbus0SelEn to decide on the port. Does anyone have any idea of exactly what > the correct behaviour should be? > > Thanks > Will >
Attachment:
signature.asc
Description: PGP signature
