[Arm-netbook] RGB/TTL interface selection, why in EOMA-68

[luke.leighton]

On 11/29/12, Henrik Nordström <henrik at henriknordstrom.net> wrote:
> tor 2012-11-29 klockan 09:06 +0000 skrev luke.leighton:
>> On 11/29/12, Tom Cubie <mr.hipboi at gmail.com> wrote:
>>
>> > The lcd is from BOE. The spec is here:
>> > http://tom.linux-sunxi.org/hardware/datasheet/HV070WSA-100%20product%20spec%20rev.0%20%5b%e6%9c%80%e6%96%b0%e7%89%88%5d.pdf
>>
>>  superb!
>
> I wonder... maybe EOMA68 should already be revised to use LVDS instead?
> Feels kind of stupid to have to do TTL->LVDS convertion when the CPU is
> perfectly capable of delivering LVDS with just the flip of some software
> bits.
>
> I kind of doubt there will be need for a CPU module based on a CPU that
> can not do LVDS.
>
> But you know these things better than me.

 not necessarily!   but i have been over this, and nobody came up with
an objection, the logic went as follows:

* EOMA_68 covers from as low as 320x240 all the way up to e.g. 2048x2048.
* therefore whatever interface is chosen, it must NOT cause products
which have 320x240 or even lower resolution LCDs to have to add 10%
onto the BOM just for an LCD converter IC (whatever it is)
* $1 for a converter IC when the BOM is $80 is however considered "acceptable"
* therefore 24-pin RGB/TTL is pretty much the only
lowest-common-denominator, lowest-cost option.

if you make dual-channel LVDS part of the standard as an "option", you
just screwed absolutely every module provider whose SoCs do not have
the capability to put both 24-pin RGB/TTL *and* dual-channel LVDS onto
the same pins.

so, ridiculous as it seems initially, 24-pin RGB/TTL is the best
option that i can see, when taking into account all the factors that
i've been able to consider *so far*.

if anyone can come up with better reasoning it'd best be done quick
because the A10 module is almost ready.

l.