[Arm-netbook] MIPI DSI instead of RGB/TTL - the only way out of the blind alley
benson.mitchell+arm-netbook at gmail.com
Wed Dec 14 00:20:30 GMT 2016
On Tue, Dec 13, 2016 at 9:51 AM, dumblob <dumblob at gmail.com> wrote:
> Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while
> having a HW way to choose from these?
> Yes we can! EOMA already counts on several types of PC Cards (originally
> called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker (Type
> II - 5 mm). Let's declare the thicker cards to be high-end and offer only
> MIPI DSI while thinner cards low-end with just RGB/TTL. Problem solved!
To be specific, EOMA68 includes Type I, Type II and Type III already. There
are differences in permitted power, and RGB resolution. These differences
run in opposite directions, in order to make sure that any combination that
fits will work.
WRT resolution, Type I is the high-end, with card-minimum/housing-maximum
1920x1080, because a Type I housing will accept _only_ Type I cards. Thus
anything with a 1920x1080 screen has a Type I slot, and any card that
physically fits will drive that display.
Type II and Type III both have a card-minimum/housing-maximum 1366x768 --
but of course they'll accept a high-end Type I card, it'll just run
contentedly at less-than-max resolution.
(AIUI, a Type II housing can have a 1920x1080 display, as long as that
display will accept and upscale a 1366x768 signal. Then either a Type I card
or a Type II card exceeding the minimum specs can output full 1920x1080, but
it will work with even the minimum Type II card's 1366x768.)
The point is, any card _must_ work in any housing it physically fits in. So
if you want Type I to support MIPI, that's great -- but that Type I still
fits in a Type II, so it must also be able to output RGB/TTL on the same
pins, and there must be a mechanism to autonegotiate this depending on the
housing. (Or if, as in your proposal, Type II has MIPI, then a Type II
housing must accept both MIPI and the RGB/TTL signals from a Type I card --
again, with autonegotiation.)
I don't think adding autonegotiation here is particularly hard (basically
just defining a flag in the I2C EEPROM), but the need to support both
interfaces negates some of the benefits of MIPI, and adds complexity to all
cards supporting MIPI, and I'm not sure that complexity (multiplexer, and in
some cases, MIPI->RGB conversion IC) can actually fit on a crowded EOMA68
> The "high-end" specification shall then also be extended allowing higher
> thermal dissipation (5W is too low - maybe 15W would be OK as it's still
> easy to cool passively) etc. to accommodate "high-end" (actually mainstream,
> but in this context it's high-end) requirements.
Type I and Type II are currently limited to 5W, while Type III is limited to
10W. Again, these have to be in this order, because any card must work in
any housing it physically fits. So a 5W card can be powered by a 10W power
supply, but not the other way around.
I think 10W is a hardware limit of the connector (4 pins at 0.5A per pin);
but even if I'm wrong on that, keep in mind that _every_ Type III (and in
your proposal, Type II) housing _must_ provide the maximum allowed power. So
when you say 15W, you're saying that _every_ housing must have a 3A supply,
even if 90% of cards only need 2A.
(Some of this could be extended with autonegotiation -- e.g. all Type I/II
cards start in 5W maximum, but _if_ the housing permits it, can switch to an
optional high-performance 10W mode. It's tricky, because there's both
electrical and thermal considerations involved, but I think it may be
> Speaking about thermal dissipation, I'm not sure that in case of the
> high-end card type, this limit should be a fixed one.
Obviously, technically skilled people will overclock and overwatt specific
EOMA68 cards in housings that they know can supply more power. But the
minute you change this behavior from "hackers breaking the rules" to
"there are no rules", you've made it so that the whole promise of EOMA
("Just plug it in; it will work") can no longer be kept.
> I would probably
> prefer the 15W value as a strong recommendation instead of a firm
> requirement. While always (disregarding whether it's smaller than 15W or
> not) requiring to readably and fully visibly to the end user quote (at best
> on the outermost coating) the maximum dissipation of the whole particular
> card under heavy load.
I personally would be fine with that -- in fact, I would be fine with a lot
of things that are defined in the EOMA68 standard being just a matter of
labeling, and leave it on the user to choose compatible parts.
But Luke's not designing this standard for me; he's designing it for people
who would get confused and buy a 25W card and a 10W-max tablet housing, and
not understand why they don't work. If you're targeting those people (which
you have to, to get volume), you have to make it work for them.
More information about the arm-netbook