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 ?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
