Hi Andrew, On 31/12/2013 23:21, Andrew Lunn wrote: >>> 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. > > I think this is something we need, not just for this i2c problem, but > for other issues, in particular, helping userspace get the right DT > file. > > We already have kirkwood-ts219-6281.dts and kirkwood-ts219-6282.dts, > different QNAP 21X variants which differ by SoC. I will soon be adding > kirkwood-ts419-6281.dts and kirkwood-ts419-6282.dts, once testing is > complete. > > It would be nice if the Debian installer can figure out which variant > is needed. I don't think we currently reliably export this information > to user space. We do print it at boot time, but there is no guarantee > it will still be there later. lspci does not seem to show it, and that I also think it could be useful to have a way to know the SoC ID and its revision. But I don't know where to export it, in /proc/cpuinfo there is a filed named Revision but I think it refers the board itself. There is also the /sys/bus/platform/devices/soc.0/ directory which would be a good candidate to export the SoC ID and revision. > assumes PCIe devices are actually enabled in the DT, which for > ts219-6181 they are not. > > At the moment, PCI_MVEBU is a bool in Kconfig. It is either built in, > or not available. That helps a little, but not too much. It could be > the i2c driver gets probed before PCI. Also, for Dove, PCI is > optional, since things like CuBox does not have any use of PCI. > > So maybe some mach code would be best, which directly peeks the PCIe > registers, and twiddles the clocks as needed. We can hard code the > addresses, and use dt_compat to determine which set of addresses to > use, and do it from init_machine, so we don't need to worry about what > the PCIe and clock drivers are doing. I have just written something like that: http://www.spinics.net/lists/arm-kernel/msg297642.html Gregory -- 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
