On Fri, 29 Jul 2011, Rob Herring wrote: > On 07/29/2011 07:40 AM, Nicolas Pitre wrote: > > On Fri, 29 Jul 2011, Dave Martin wrote: > > > >> On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote: > >>> On Thu, 28 Jul 2011, Dave Martin wrote: > >> > >>>> I have a slightly biased interest in this, since ARM seems to like > >>>> funky memory maps for many of its newer boards, and it would be > >>>> unfortunate for these to get left out of the whole single effort. > >>>> > >>>> Of course we could include those platforms in non-sparsemem kernels, > >>>> but since that will often mean sacrificing half the RAM, this is > >>>> far from ideal. > >>> > >>> Maybe that half could simply be pushed to home. > >> > >> Eh? > > > > Euh... I meant "himem". No idea how my fingers turned that into > > "home". > > > >>>> We could even embed the printch() function body into the DT if we > >>>> wanted to make the kernel's job even simpler. Realistic implementations > >>>> of this function are tiny, so this shouldn't be too cumbersome. > >>>> That really seems an abuse of the DT though, since this goes beyond > >>>> just describing the hardware. > >>> > >>> Well... I'm not entirely against the idea. This could be seen as the > >>> most efficient way to describe how to output a character over some > >>> serial device for the given hardware. The danger is that some vendors > >>> might be tempted to abuse that idea by stuffing BIOS-like services in > >>> there that the kernel would have to cope with. > >> > >> See my reply to Arnd... > > > > What might be done is to describe the data FIFO register location, and > > the FIFO full bit mask, and the FIFO empty bit mask. That's all we need > > really. > > > Except for RPC which outputs to video memory. We don't care about that > one for single kernel, but that may limit a new common solution.
There will always be exceptions. Since RPC is so different and unique, it better be left alone and we should not try to find a solution that covers it as well. I doubt it will ever use DT either. > BTW, I did implement a conversion to use debug macro code for > uncompress, but it doesn't work for RPC, OMAP and Davinci. So while it > shrinks the the code by over 2K lines, we probably need a new approach > like you suggest. The patches are here if you want to take a look: > > git://git.jdl.com/software/linux-3.0.git > http://git.jdl.com/gitweb/?p=linux-3.0.git;a=shortlog;h=refs/heads/uncompress Will try to have a look. Nicolas _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
