[RFC/PATCH 8/8] LPDDR extended physmap driver to support LPDDR flash.

[Jared Hulbert]

> there is always platform data telling the driver
> _where_ the controller is to be found.  In that case the controller
> itself falls into category (3).  That's also the case for physmap.

Right, we need to tell the system where potential CFI Flash buses are
with some kind of data.  Physmap decouples that data from the platform
data.

> No, that's not true.  In fact we're actively working towards the
> possibility for a single defconfig, hence a single kernel binary, to
> support many different platforms at once.

Okay, that's good.

>> The platform data requires adding a .c file to arch/arm/mach-pxa/ and
>> tweaks to arch/arm/mach-pxa/Kconfig and arch/arm/mach-pxa/Makefile,
>> no?
>
> Of course.  That's the case for every different hardware platforms.

I think that is pushing it.  There would be tens of thousands of x86
"platforms" if you took that argument to it's extreme.

>> >  But in practice, the platform
>> > data approach has a bunch of advantages over the .config approach,
>> > such as that with the platform data approach it's still possible to
>> > build a single kernel image that supports booting on multiple different
>> > boards (which is important e.g. for distributors),'
>>
>> Yes there are places where platform data approach is very useful, I
>> totally agree.  Yet there are also places where it is annoying.
>
> Could you elaborate?

A lot of PXA270 hardware out there is pretty similar, there's only a
couple of registered platforms but there are thousands of different
boards.  Do we want thousands of platforms defined for the trivial
differences?

>> Also I'm not sure that totally accurate.  Here you can use the kernel
>> command line to alter the physmap.
>
> Why would you ever want to do that?

We have basically a respin of Mainstone with socket cards for Flash.
So we  alter the physmap to look at one chipselect or the other,
depending on what we are doing.  It's great for testing stuff.

That's why physmap is so important to me, I can test a stock kernel
for Mainstone with all kinds of unholy Flash configs without ever
touching the kernel.  This is very cool for us.

So you guys think of soldering irons when I talk about altering the
Flash layout, I think of swapping a card out.

> If you moved the flash then either you 1) modified the hardware in which
> case it strictly speaking can't be called under the existing name, or 2)
> platform data for that platform didn't acurately reflect the physical
> capabilities of the hardware.

So if I do a mild hack or revision of a board that should trigger a
new machine registration?  Really?  Even though today I can just tweak
the command line's physmap entry?

Okay.... 2) is a pretty interesting argument.  So how do we do
platform data for my board that has socketable Flash?

I don't know.  We have this cool ability to autodetect the Flash but
it seems like the direction we're going doesn't take advantage of
that.  I probably just don't see something.