From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
Vishnu Patekar
<vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
Date: Wed, 17 Jun 2015 09:19:48 +0200 [thread overview]
Message-ID: <55811F94.3080608@redhat.com> (raw)
In-Reply-To: <D4216F2D-0556-4849-B1DF-8E4D250006B4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Hi,
On 16-06-15 21:33, Pantelis Antoniou wrote:
> Hi Maxime,
>
>> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard@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?
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
WARNING: multiple messages have this Message-ID (diff)
From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
Date: Wed, 17 Jun 2015 09:19:48 +0200 [thread overview]
Message-ID: <55811F94.3080608@redhat.com> (raw)
In-Reply-To: <D4216F2D-0556-4849-B1DF-8E4D250006B4@konsulko.com>
Hi,
On 16-06-15 21:33, Pantelis Antoniou wrote:
> Hi Maxime,
>
>> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard@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?
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
next prev parent reply other threads:[~2015-06-17 7:19 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-30 14:55 [PATCH v2 0/6] Introduce Allwinner A33 support Hans de Goede
2015-05-30 14:55 ` Hans de Goede
[not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-05-30 14:55 ` [PATCH v2 1/6] ARM: sunxi: Add Machine support for A33 Hans de Goede
2015-05-30 14:55 ` Hans de Goede
[not found] ` <1432997706-20172-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:28 ` Maxime Ripard
2015-06-02 7:28 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 2/6] pinctrl: sunxi: Add allwinner A33 PIO controller support Hans de Goede
2015-05-30 14:55 ` Hans de Goede
2015-05-30 14:55 ` [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi Hans de Goede
2015-05-30 14:55 ` Hans de Goede
[not found] ` <1432997706-20172-4-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:51 ` Maxime Ripard
2015-06-02 7:51 ` Maxime Ripard
2015-06-02 8:08 ` Hans de Goede
2015-06-02 8:08 ` Hans de Goede
[not found] ` <556D6487.4010207-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 8:21 ` Maxime Ripard
2015-06-02 8:21 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi Hans de Goede
2015-05-30 14:55 ` Hans de Goede
[not found] ` <1432997706-20172-5-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:55 ` Maxime Ripard
2015-06-02 7:55 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support Hans de Goede
2015-05-30 14:55 ` Hans de Goede
[not found] ` <1432997706-20172-6-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:56 ` Maxime Ripard
2015-06-02 7:56 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support Hans de Goede
2015-05-30 14:55 ` Hans de Goede
[not found] ` <1432997706-20172-7-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 8:14 ` Maxime Ripard
2015-06-02 8:14 ` Maxime Ripard
2015-06-02 8:29 ` Hans de Goede
2015-06-02 8:29 ` Hans de Goede
[not found] ` <556D6955.8030708-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-03 9:45 ` Maxime Ripard
2015-06-03 9:45 ` Maxime Ripard
2015-06-03 11:12 ` Hans de Goede
2015-06-03 11:12 ` Hans de Goede
[not found] ` <556EE104.3090803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-13 13:50 ` Maxime Ripard
2015-06-13 13:50 ` Maxime Ripard
2015-06-13 14:18 ` Hans de Goede
2015-06-13 14:18 ` Hans de Goede
[not found] ` <557C3BD3.6030105-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-16 17:41 ` Maxime Ripard
2015-06-16 17:41 ` Maxime Ripard
2015-06-17 7:16 ` Hans de Goede
2015-06-17 7:16 ` Hans de Goede
[not found] ` <55811EB2.4060302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-18 18:37 ` Maxime Ripard
2015-06-18 18:37 ` Maxime Ripard
2015-06-18 20:16 ` Hans de Goede
2015-06-18 20:16 ` Hans de Goede
2015-06-14 18:16 ` Pantelis Antoniou
2015-06-14 18:16 ` Pantelis Antoniou
[not found] ` <85E62D2D-5387-433B-A944-7F2145459F08-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2015-06-16 17:55 ` Maxime Ripard
2015-06-16 17:55 ` Maxime Ripard
2015-06-16 19:33 ` Pantelis Antoniou
2015-06-16 19:33 ` Pantelis Antoniou
[not found] ` <D4216F2D-0556-4849-B1DF-8E4D250006B4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2015-06-17 7:19 ` Hans de Goede [this message]
2015-06-17 7:19 ` Hans de Goede
[not found] ` <55811F94.3080608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-17 7:26 ` Pantelis Antoniou
2015-06-17 7:26 ` Pantelis Antoniou
2015-06-17 7:16 ` Hans de Goede
2015-06-17 7:16 ` Hans de Goede
[not found] ` <55811ED9.9090503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-18 17:52 ` Maxime Ripard
2015-06-18 17:52 ` Maxime Ripard
2015-05-30 20:43 ` [PATCH v2 0/6] Introduce Allwinner A33 support jonsmirl-Re5JQEeQqe8AvxtiuMwx3w
2015-05-30 20:43 ` [linux-sunxi] " jonsmirl at gmail.com
2015-06-02 7:43 ` Chen-Yu Tsai
2015-06-02 7:43 ` Chen-Yu Tsai
2016-06-13 19:10 ` ernestovm07
2016-06-13 19:10 ` ernestovm07 at gmail.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55811F94.3080608@redhat.com \
--to=hdegoede-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org \
--cc=vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=wens-jdAy2FN1RRM@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.