Hi Pierre,
> On Oct 27, 2016, at 22:04 , Pierre-Hugues Husson <phh@xxxxxx> wrote:
>
> 2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>:
>>
>> Hi Pierre,
>>
>>> On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh@xxxxxx> wrote:
>>>
>>> 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>:
>>>> 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.
>
It does require a new driver, but the driver is simple a probing method
driver; it does not require to modify the actual drivers that are going
to be instantiated.
In DT terms for a board specific probe driver:
bpm: board_probe_method {
compatible = “foocorp,bar-board-probe”;
};
genm: generic_model_manager {
compatible = “generic-model-manager”;
probe-method = <&bpm>;
/* list of models and overlays to apply in sequence */
models {
foo-model-0 = “foo,bar,screen-A”, “foo,bar,accel-A”;
foo-model-1 = “foo,bar,screen-A”, “foo,bar,accel-B”;
foo-model-2 = “foo,bar,screen-B”, “foo,bar,accel-A”;
foo-model-3 = “foo,bar,screen-B”, “foo,bar,accel-B”;
};
};
The manager can call the single exported method which could be as simple
as:
const char *probe_identify();
In fact for things like i2c probe a generic probe method might suffice.
i2c_generic_bpm: generic_i2c_probe_method {
compatible = “i2c-generic-probe-method”;
models {
model@0 {
result = “foo-model-0”;
/* match when read at address 12 returns 5 */
/* and read at address 14 returns 0 */
/* format is command, bus, address, argument */
match = <MATCH_READ &i2c0 12 5>, <MATCH_READ &i2c0 0 14 0>;
… etc ...
};
};
};
>>> 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.
>
Yeah, model number in this case means both model and revision.
If components change you change the internal model number.
> Regards,
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
