On 12/31/2013 01:28 PM, Gregory CLEMENT wrote:
First I wanted to be sure that there the issue was not introduce by a
commit so reverted one by one the commits on the file
drivers/i2c/busses/i2c-mv64xxx.c. I tested it on both version of the
OpenBlock AX-4 (with CPU A0 and B0). After each commit the kernel
continue to work on the B0 version as expected, but it was when I
reverted the commit "i2c: mv64xxx: Add I2C Transaction Generator
support" that it worked also on the A0 version.
Then I had a look on the errata datasheet and I found issues that I
missed when I worked on it. This issues were fixed in B0 version.
The fix should be pretty simple: disabling the offload_enabled flag when
an A0 version of the CPU is used. For this there are 2 solutions:
introducing a new compatible string or trying to detect the CPU
stepping at runtime. I would prefer the second solution and I am looking
for a way to get this information.
We can have this information in the same way that it is currently done
by the other mvebu SoC: accessing the PCIE_DEV_REV_OFF register. In
arch/arm/plat-orion/pcie.c there were functions named
orion_pcie_dev_id() and orion_pcie_dev_id() to retrieve information
about the CPU variant and its version.
Depending on running pcie when calling is tricky, as it can be clock
gated. Maybe we should have some mach code to get the SoC revision
early for all SoCs. That should look for a pcie controller node,
enable the clock, store the revision once, and disable the clock
again. The callback can then return the stored value.
We could the same in drivers/pci/host/pci-mvebu.c, however it would
add a dependency between PCIe and I2C for the mvebu SoCs. I can think
of several options:
1. Using only a new compatible strings: mv78230-A0-i2c. The benefits
of it are that it is very easy to implement and it don't touch anything
else than the driver itself. The drawback is that we need to add an
new dts file for the A0 variant of the AX3-4.
I know that DT should describe HW, but at this point I tend to not
fork off another dts. If it is probable, we should probe it. SoC
revisions are really hard to see even from looking at the pcb, there
is no way for users to determine the correct dts.
2. Using the CPU revision information from the pcie driver. The
benefits of it are that we don't need modify any device tree and a fix
in the kernel will be enough. The drawback is that we introduce a
dependency between PCIe and I2C.
3. Using the CPU revision information as primary solution and the
compatible string as fallback. The benefits of it are there won't be a
mandatory dependency between PCI and I2c and the change of the dts
won't be mandatory too. The drawback is that we could have a non
working kernel if on a Rev A0 CPU, PCIe is not enable _and_
mv78230-A0-i2c compatible string is not selected.
I am open to other ideas as I am not found of none of them.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
