Add Allwinner Q8 tablets hardware manager

[Pierre-Hugues Husson]

2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou at konsulko.com>:
>
> Hi Pierre,
>
> > On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh at phh.me> wrote:
> >
> > 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou at konsulko.com>:
> >> Yes there is no EEPROM but you might be able to map probing results to
> >> a fake ‘model’ number.
> >>
> >> Let me expand a bit:
> >>
> >> Assume that you have a number of probing steps, for example A, B, C each
> >> returning true or false, and C being executed only when B is ‘true’ you
> >> could do this to generate a bit field that identifies it.
> >>
> >> For example let’s assume that model FOO’s probing steps are
> >>
> >> A false, B true, C false -> 010
> >>
> >> Model’s BAR
> >>
> >> A true, B false, C don’t care -> 10x
> >>
> >> Mapping these to models could be
> >>
> >> Model FOO, (010 & 111) == 010 (all three probing steps must match)
> >>
> >> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
> >
> > This method looks too complex on multiple grounds.
> > Assuming your method, I'm not too sure how this would actually be
> > described in a DTS.
> > Such probing steps should include reading/matching IDs in an EEPROM/on
> > an ADC, but it should also include the result of a driver's probe.
> > Also, drivers should have a way to report an ID/OTP instead of just a
> > boolean.
> >
>
> Err, I don’t think you got the point.
>
> The probing steps are done by a board specific probe driver.
> This driver performs the probing steps (which is exactly what Hans’s
> method now does) but instead of applying changes to the device tree
> programmatically generates a model string.
>
> This model string can be used by a general purpose overlay manager to apply
> the overlay(s) for the specific board. The plural part is important - read
> below.

Ok, I agree I didn't get the point, and I'm not sure I do now.
If I understand correctly, the difference between your method and
Hans', is that instead of manipulating directly OF properties based on
heuristics, there will be a heuristic to determine model revision, and
THEN apply overlays based on determined model revision.

If this is the correct interpretation, this means that for boards with
two possible accelerometers, a new driver is required, while something
as simple as i2c-probe-stop-at-first-match wouldn't require a new
driver.

> > As you mentioned, it is a way to distinguish models, not just a set of
> > parameters.
> > Does this mean that this DT would lead to loading various DT based on
> > the matching model, which would look like a FIT?
> > Also there is a modularity problem there. If I have phones with either
> > screen A or screen B, and with either accelerometer A or accelerometer
> > B, I would have to implement all four combinations.
> >
>
> The model lookup need not result in a simple overlay to apply.
>
> So for your case it would be:
>
> model corp,0 -> overlay screen A + overlay accel A
> model corp,1 -> overlay screen A + overlay accel B
> model corp,2 -> overlay screen B + overlay accel A
> model corp,3 -> overlay screen B + overlay accel B
>
> You don’t need the combinatorial number of overlays.

My worry initially was that all 4 "model corp" are needed, while with
using a simple approach like i2c-probe-stop-at-first-match, this
wouldn't be needed.
But now that I'm thinking of it again, for such a case to happen, this
would require to have OEMs picking random components for tablets of
one production batch. This wouldn't make any sense.
So I agree a model-based method should cover sufficient cases to be worthwhile.
I think it covers every device I've met.

Regards,