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? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
