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

[hdegoede@redhat.com (Hans de Goede)]

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