[Arm-netbook] motherboard negotiation

[lkcl luke]

On Fri, Jan 13, 2012 at 9:15 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Fri, Jan 13, 2012 at 3:53 PM, lkcl luke <luke.leighton at gmail.com> wrote:
>> On Fri, Jan 13, 2012 at 8:42 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>>
>>> There is no good solution to the LCD problem, they are simply way too
>>> many variations. I suspect that you'll end up with at most two or
>>> three different LCDs interfaced to the EOMA board.
>>
>>  nope - no can do: inflexibility is failure.  failure is not an
>> option.  this project has to cope with 320x240 all the way up to
>> 1900x1200.
>>
>>  we'll start _off_ small, just to make it manageable (2 or 3 different
>> LCDs), but not dealing with this isn't an option.
>>
>>
>>> You also have to deal with the fact that different CPU LCD controllers
>>> have different capabilities. You may make a baseboard for an LCD that
>>> a future CPU does not have the ability to control.
>>
>>  that would surprise me greatly.  *thinks*.... actually it wouldn't,
>> no you're right (forgot about a couple of cases)  i know for example
>> that the S5PV210 and S5PC110 can only cope with 1024x768 - if you try
>> to push them to 1388x768 (like hardkernel.com did) then not only do
>> you lose 2 pixels at either edge (because the internal memory buffer
>> is only 1mb) but the quality is pretty dreadful, too.
>
> There is much more to this than resolution. LCDs come with various
> interfaces: 6800, 8080, SPI, RGB, different types of signaling levels,
> etc. They have multiple ways of setting them up: SPI, I2C, in-band,
> registers, etc. Each one sets up differently. Even more basic: where
> is the framebuffer - in the LCD or in the host? Backlight
> control/power? There is no such thing as a generic LCD interface. That
> why there is a different driver for each one in the kernel. There is
> little to no standardization in LCDs.

 i'm aware of all of this, jon.

 we're entirely ruling out everything but RGB/TTL interfaces, and it's
the motherboard's problem to set them up [and to provide I2C or other
interfaces for control and setup].

 backlight and power is, again, the motherboard's problem - it's
outside of scope [with the exception of it possibly requiring some I2C
or other device integration, which is a software issue, which brings
us back to it being in device-tree, thus we are covered]

 if an SPI-based LCD is required, it would have to be connected to an
embedded controller... on the motherboard: again, that's outside of
scope.  under such circumstances, the framebuffer would be on the
embedded controller: again, outside of scope.

 thus, the framebuffer will be on-CPU (ok, on the side of the EOMA CPU card).

 a standard _has_ to have no alternatives: only _one_ option [*1].
that option is: 24-pin RGB/TTL.  you can use less of those 24 pins
(15, 18, 21).

 once you're on the other side of that RGB/TTL interface, you can do
what you like.  direct to an 800x600 or 320x240, or to a
single-channel LVDS for up to 1388x800, dual-channel for up to
1440x900, or triple-channel for 1920x1080.

 but all the other ones - SPI etc. - are definitely, definitely out of
scope of EOMA.

 l.

[*1] my lecturer at university brought the consequences of having
double options home by pointing out that the X25 standard specified
that you could either have control-signalling in hardware _or_ in
software.  what that meant was that at no time would you _ever_ know
if the thing you were connecting to would have either software _or_
hardware control-signalling.  thus... you had to have both.  thus, an
entire pin was completely wasted.  the consequences of that were that
there could only be one clock line, and it had to be an "input" (going
to both devices)  thus, now, you had to have an external device which
had to have power and a crystal and a boat-load of other circuitry, so
now you had a £20 cable instead of a £2 one.  if they'd bloody well
done a decent job of _thinking_ before making the standard, they would
have realised that the control-signalling line was redundant, turned
it into a TX-Clock and X-25 could have been used as a bi-directional
low-cost replacement for RS-232 which was desperately in need of an
upgraded replacement at the time.  lesson learned: NO OPTIONS in
standards.