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.
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?
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 :)
Regards,
Hans
--
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
