On Friday 28 March 2008 19:07, Scott Wood wrote: > Laurent Pinchart wrote: > > On Friday 28 March 2008 18:11, Scott Wood wrote: > >> Laurent Pinchart wrote: > >>> Locating the end of the muram isn't as straightforward as it > >>> could be. As the current code already uses the beginning of the > >>> muram to store the BDs and data buffers, should I really bother > >>> locating the end or can I store the SMC parameter ram at the > >>> beginning as well ? > >> Maybe, but the end would be safer. What's the problem with finding > >> the end? > > > > That requires manual parsing of all the cells in the reg property. > > The device-tree API doesn't provide a way to get the length of a > > property, > > Sure it does. Do a getprop with an insufficiently large buffer, and it > tells you how much you really need. :-)
Ok thanks. > > so I'll have to use a big enough pre-allocated buffer. I'm also not > > sure if resources are guaranteed to be sorted in increasing order. > > Ah, good point. > > > This doesn't make finding the end of the muram really difficult. I > > was just wondering if the increased code complexity was worth it, > > especially seeing how the cpm_serial code in the boot wrapper seem > > quite unstable. > > Unstable in what way? I was refering to the virtual-reg (non-)issue I mentionned below. > > I'm not familiar with the boot wrapper code so I'm sometimes not very > > confident in my assumptions, but isn't the handling of the > > virtual-reg property in cpm_console_init broken ? > > Not as far as I can see. > > > If I'm not mistaken, getprop will return the address and size of the > > first resource and not the addresses of the first two resources. > > No, it'll get as much of the virtual-reg property as will fit in the > buffer. There's no size in virtual-reg. Ah right. Sorry about the misunderstanding. > > What is virtual-reg used for ? To report the virtual address without > > requiring a device tree walk ? Does it provide any information that > > dt_xlate_reg can't find ? > > Yes, it tells you the virtual address when it's not an identity mapping. > It's not currently used on CPM platforms, but might be used down the > road with a QE device on 85xx. Will the virtual-reg property on the muram node list the addresses of all muram chunks or the address of the first chunk only ? > >> Even the end of the first reg resource would be OK. > > > > If I use the end of the first resource, can I assume it spans 0x0000 > > - 0x8000 to set the default tx BD address in Kconfig ? > > No, especially seeing as it doesn't on any existing boards. :-) I still need a default value :-) It obviously won't work for all boards. > You could set the default to just before 0x2000 with board-specific > exceptions, though. We're getting a bit lost. I'll try to summarize the discussion. - The muram node has a reg property that lists the offsets and sizes of all muram chunks, and an optional virtual-reg property that lists the virtual address of all chunks/the first chunk only. - From the above information I can locate a section of muram at the end of the first chunk (easy) or at the end of the muram (not really difficult, just a bit more complex, especially if chunks are not sorted by their start address). - Kconfig needs a default address for the tx BD. This depends on the allocation strategy (end of first chunk vs. end of last chunk). Is there some consistent default across QE devices ? -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75
pgpl4GQ0cQTU2.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
