Hi Hans, > On Jun 17, 2015, at 10:19 , Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > Hi, > > On 16-06-15 21:33, Pantelis Antoniou wrote: >> Hi Maxime, >> >>> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: >>> >>> Hi Pantelis, >>> >>> On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote: >>>>> I think we need to discuss this with Pantelis and what is his feeling >>>>> about this. >>>>> >>>>> Pantelis, to sum things up, we have a case of a tablet that comes with >>>>> the exact same board, but coming in two flavours with two differents >>>>> screen resolutions. It looks like a great case for your DT quirks >>>>> work, but we have no way of runtime detecting the difference between >>>>> the two variants. What do you think about this? Should we go with >>>>> using the DT quirks or is this simply out of scope? >>>>> >>>>> There's not so much example of similar cases in the kernel, and none >>>>> of them use quirks so far (obviously) but they all boil down to either >>>>> the solution you were suggesting in that patch or adding the alternate >>>>> configuration as a comment. >>>>> >>>>> I don't think the latter would work for you, and I agree with that, so >>>>> I guess that depending on what Pantelis says, either we go with a >>>>> better solution using the quirks, or we end up using what you >>>>> suggested (with a nitpick though, I'd prefer if you used the display >>>>> standard instead of the resolution, which would make it xga I guess?) >>>>> >>>> >>>> First of all, the quirks interface is at an RFC stage (new name >>>> suggested is ‘variants’); getting that out of the way this seems >>>> like what it is designed to do. >>>> >>>> The idea of the DT quirks is to drastically cut down on the number >>>> of different DTs required, each different for each board with minute >>>> differences from one another. >>> >>> We're on the same page then :) >>> >> >> Heh :) >> >>>> In your case you have boards that have no way to be probed about >>>> what they ‘are’, but that’s no big problem. You can easily pass the >>>> board variant in the kernel command line and use that to select the >>>> quirk to apply. >>> >>> Hans actually pointed out that this would just move the logic >>> somewhere else, but not remove it. In our case, that would mean U-Boot >>> (Hans being the U-Boot maintainer for the SoCs that are used in this >>> particular board). >>> >>> That would still require us to have a different configuration and to >>> add some logic to pass that extra parameter to the kernel. I'd be glad >>> to have less stuff in the kernel, but I can understand that he doesn't >>> want more stuff either. >>> >> >> Well, I don’t know the specifics of your board, but if you have a configuration >> subset that works for all the boards and makes it at least possible to load >> a kernel (i.e. ram, serial, storage) you can keep a single bootloader that’s not >> full featured, but at least can boot any kind of variant. >> >> Afterwards you can just update the bootargs variable to the correct one for >> a given board. > > We're talking about tablets here and uboot supports the lcd, as that is the only > way to show errors loading the kernel / show a boot menu, etc. > I see. > Show u-boot will know which lcd is present (by the user having flashed > the right u-boot binary for his model or so we hope). So I really think > that this is something which u-boot should pass along in our case. > > Talking about how this will all work in the future would it be possible > for u-boot to pass this info via devicetree rather then the kernel commandline? > You can already pass it. There’s a compatible property on root in each DT blob. It’s a string property list that goes from most specific to least specific. You can always tack a most specific compatible in front and that’s what the quirks/variant can pick to apply changes. I would try to ask Grant or Rob about what they think too however. > In general we try not to mangle the cmdline in u-boot, while otoh we already > patch plenty of stuff into the dtb like memory size and such :) > FWIW if you pass a cmdline you already mangle the DT, since it is put in the chosen node as such. So there’s mangling already you just got to decide where and what to mangle. :) > Regards, > > Hans 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
