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. >> In fact the original patchset does contain a command line quirk for >> enabling and disabling the onboard emmc & hdmi of the beaglebone >> black for capes that need to use those signals. > > Ah. I somehow overlooked that when reading it. > >> Saying that, if you’re in a hurry I’d say go with a different DTSs >> for now, since that’s going to go in a near kernel cycle; DT quirks >> will be discussed at plumber’s in a couple of months, and then we’ll >> if it will go in and in what form. > > Ok. I won't be here this year, but if you could raise the topic of how > to handle "non-discoverable boards" then, it would be great. > > Hans, I guess we can go for your suggestion then: apply a "generic" DT > for the board right now, we're going to need it anyway. Then, when > will have real display support, depending on the current state of the > discussion for the quirks, we will either merge a different DT > including the generic one, or if the quirks have something that work > for both of us then, use the quirks. Sounds good? > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com 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
