On 1 March 2016 at 11:18, Leif Lindholm <[email protected]> wrote: > 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. >
Good, I'll do that today. >> 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. > If there is going to be a bus implementation, which sounds like a good plan, I reckon it would be better for a PrimeCell library to be part of that series. I expect the requirements are likely to shift during implementation. So I'll hold fire till I/we know more. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
