[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Pantelis Antoniou]

Hi Hans,

> On Jun 17, 2015, at 10:19 , Hans de Goede <hdegoede at redhat.com> wrote:
> 
> Hi,
> 
> 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.
> 

I see.

> 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. :)

> Regards,
> 
> Hans

Regards

— Pantelis