On Wed, Jun 17, 2015 at 09:16:41AM +0200, Hans de Goede wrote: > Hi, > > On 16-06-15 19:55, Maxime Ripard 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 :) > > > >>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. > > > >>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? > > Sounds good to me, will you make the changes while merging, or shall > I do a new version of the patch ? I'll apply and fix. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
