[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
pantelis.antoniou at konsulko.com
Wed Jun 17 00:26:41 PDT 2015
> On Jun 17, 2015, at 10:19 , Hans de Goede <hdegoede at redhat.com> wrote:
> On 16-06-15 21:33, Pantelis Antoniou wrote:
>> Hi Maxime,
>>> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard at free-electrons.com> 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?
You can already pass it. There’s a compatible property on root in each DT blob.
It’s a string property list that goes from most specific to least specific.
You can always tack a most specific compatible in front and that’s what the
quirks/variant can pick to apply changes.
I would try to ask Grant or Rob about what they think too however.
> 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 :)
FWIW if you pass a cmdline you already mangle the DT, since it is put in the
chosen node as such.
So there’s mangling already you just got to decide where and what to mangle. :)
More information about the linux-arm-kernel