On Tue, Mar 01, 2016 at 11:03:18AM +0000, Ryan Harkin wrote:
Yes, and the public documentation found in the obvious place is not for the part actually used on the platform, or at least not for the same revision. More recent ARM documents tend to be less confusing on which fields may be revision-sensitive or not.
Is there a version available publicly for the revision found on Versatile Express? A link would be handy for future reference. I'm looking at this doc:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0172a/index.h...
... which is assume is for pre r1p0, which is the version that is claimed to be in the IOFPGA on the Versatile Express motherboard doc:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0172a/index.h...
I intend to go on a minor archeological expedition when I'm working in the office tomorrow.
The point is that the "configuration" bits have no bearing on which component it is, they merely indicate implementation-time decisions (things like configurable fifo depths, inclusion of randomly bolted onto the side GPIO block, ...). These are not even necessarily software-visible, and the lack of interest on behalf of the Linux driver suggests this is the case here.
I'm happy to fix it "properly", but perhaps properly should be via functions, not macros?
Although, actually, isn't the PrimeCell identification mechanism common across all Prime Cells and if so, perhaps a small library is in order?
Good call. I was thinking in Linux mode.
So I propose a series of patches to get things working:
- depex fix to get TC2 working properly
- add debug to indicate PL180 probe failure
- simple fix to the probe, ignoring MCI_PERIPH_ID_REG3
Agreed.
Then another series:
- create a small PrimeCell library for common functions and only add
in the identification code
Sounds lovely.
- a patch per PrimeCell (PL180, PL111, PL061, ...) to use the library
Taking Ard's point into consideration, we may or may not need this - but the first part would certainly be real handy regardless.
For the library, we could have two functions:
PrimeCellDesigner(baseaddr) PrimeCellPartNumber(baseaddr)
I think we'd want the Configuration and Revision field as well (not really any extra effort).
Do we want to return enums of known designers and part numbers or are #defines preferable?
Umm, *shrug*?
Or perhaps just one TRUE/FALSE function IsPrimeCell(baseaddr, enum id) is better?
That _would_ preclude the Configuration/Revision fields, or require always passing pointers even when the driver doesn't care - so my preference would be against.
Thanks!
/ Leif