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.html
>
> ... 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.html
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
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
