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. > 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. > I'm starting to agree with Hans, and to be able to implement > everything he needs, would require a turing complete device-tree, > which can include and apply device-tree overlays. > This doesn't mean it can't be done, nor that it shouldn't be done, but > that's a lot of work. > > Hans' i2c-probe-stop-at-first-match does make sense for most usecases, > but I have two problems with it: > 1. It is I2C specific (as I've mentioned earlier, I have the same > needs with DSI panels) > 2. This looks like a temporary solution if a turing-complete solution > is to be implemented. A custom I2C method would not be optimal IMO. 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
