All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Tony Lindgren <tony@atomide.com>,
	Enric Balletbo i Serra <eballetbo@gmail.com>,
	bcousson@baylibre.com, tomi.valkeinen@ti.com,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found
Date: Sun, 17 Nov 2013 02:06:27 +0100	[thread overview]
Message-ID: <52881693.7090600@collabora.co.uk> (raw)
In-Reply-To: <20131117002600.GA14253@earth.universe>

Hi Sebastian,

On 11/17/2013 01:26 AM, Sebastian Reichel wrote:
> Hi Javier,
> 
> On Sat, Nov 16, 2013 at 06:28:00PM +0100, Javier Martinez Canillas wrote:
>> > The hack, as being sent by Javier, will result in the wrong
>> > regulator being used on the Nokia N900, which is using vaux1.
>> > It must depend on the machine.
>> 
>> I see, so this hack is not generic enough to be usable for all OMAP3 boards so I
>> think is better to just add the hack on the DTS.
>>
>> I was more found about adding a hack on dpi.c since the DTB is an stable ABI
>> while the dpi.c implementation is not.
> 
> I agree with this. My suggestion would be to get the vdds_dsi regulator name
> from platform data. This way each board can setup its own quirk until omapdss
> supports DT.
> 
>> But I guess is not that bad to change the DTS later once DSS DT
>> bindings are added to mainline.
> 
> As far as I know DT bindings are supposed to be as stable as
> possible.
> 

Indeed, although as far as I understood on the latest ARM kernel summit it was
decided that DT bindings (and DTS) can be changed in incompatible ways if it can
be reasonably argued that nobody will be affected by the change.

IMHO this is the case for IGEP boards since the vendor (ISEE) is still shipping
the boards using an old 2.6.37 forked kernel that uses board files.

So I think is reasonable to remove this DT hack later once we have omapdss + CDF
bindings in mainline since current users that choose to use the mainline kernel
instead of the vendor one have to be able to replace the stock kernel +
bootloader that comes with the boards anyways.

>> > At the same time the N900 device tree file uses V28 as
>> > regulator-name for vaux1 (which is the same one as legacy boot
>> > used). Nothing depends on this, but I don't think it's a
>> > good idea to use this property. Apparently it does not work
>> > if multiple drivers need the same regulator under different
>> > names.
>> > 
>> > -- Sebastian
>> > 
>> 
>> So, what do you think about the following patch instead?
>> 
>> [PATCH]
> 
> For Nokia N900 vaux1 is also used for si4713 radio chip, lis3lv02d
> accelerometer and battery cover sensor, so I don't like this hack.
>
> If vppl2 is only used for omapdss.dsi on IGEP boards it might be
> sensible to label it, though? So it might be ok there.
>

Yes, you can't use this hack for the N900 since other devices already use the
vaux1 regulator named as "V28" so you can't just rename it to "vdds_dsi".

But for IGEP boards vpll2 is only used for omapdss DPI so we don't have that issue.

Let's see what Tomi says that is the best way to handle this to have DVI working
with DT until the propers bindings land in mainline.

> -- Sebastian
> 

Thanks a lot for your feedback and best regards,
Javier


WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found
Date: Sun, 17 Nov 2013 02:06:27 +0100	[thread overview]
Message-ID: <52881693.7090600@collabora.co.uk> (raw)
In-Reply-To: <20131117002600.GA14253@earth.universe>

Hi Sebastian,

On 11/17/2013 01:26 AM, Sebastian Reichel wrote:
> Hi Javier,
> 
> On Sat, Nov 16, 2013 at 06:28:00PM +0100, Javier Martinez Canillas wrote:
>> > The hack, as being sent by Javier, will result in the wrong
>> > regulator being used on the Nokia N900, which is using vaux1.
>> > It must depend on the machine.
>> 
>> I see, so this hack is not generic enough to be usable for all OMAP3 boards so I
>> think is better to just add the hack on the DTS.
>>
>> I was more found about adding a hack on dpi.c since the DTB is an stable ABI
>> while the dpi.c implementation is not.
> 
> I agree with this. My suggestion would be to get the vdds_dsi regulator name
> from platform data. This way each board can setup its own quirk until omapdss
> supports DT.
> 
>> But I guess is not that bad to change the DTS later once DSS DT
>> bindings are added to mainline.
> 
> As far as I know DT bindings are supposed to be as stable as
> possible.
> 

Indeed, although as far as I understood on the latest ARM kernel summit it was
decided that DT bindings (and DTS) can be changed in incompatible ways if it can
be reasonably argued that nobody will be affected by the change.

IMHO this is the case for IGEP boards since the vendor (ISEE) is still shipping
the boards using an old 2.6.37 forked kernel that uses board files.

So I think is reasonable to remove this DT hack later once we have omapdss + CDF
bindings in mainline since current users that choose to use the mainline kernel
instead of the vendor one have to be able to replace the stock kernel +
bootloader that comes with the boards anyways.

>> > At the same time the N900 device tree file uses V28 as
>> > regulator-name for vaux1 (which is the same one as legacy boot
>> > used). Nothing depends on this, but I don't think it's a
>> > good idea to use this property. Apparently it does not work
>> > if multiple drivers need the same regulator under different
>> > names.
>> > 
>> > -- Sebastian
>> > 
>> 
>> So, what do you think about the following patch instead?
>> 
>> [PATCH]
> 
> For Nokia N900 vaux1 is also used for si4713 radio chip, lis3lv02d
> accelerometer and battery cover sensor, so I don't like this hack.
>
> If vppl2 is only used for omapdss.dsi on IGEP boards it might be
> sensible to label it, though? So it might be ok there.
>

Yes, you can't use this hack for the N900 since other devices already use the
vaux1 regulator named as "V28" so you can't just rename it to "vdds_dsi".

But for IGEP boards vpll2 is only used for omapdss DPI so we don't have that issue.

Let's see what Tomi says that is the best way to handle this to have DVI working
with DT until the propers bindings land in mainline.

> -- Sebastian
> 

Thanks a lot for your feedback and best regards,
Javier

  reply	other threads:[~2013-11-17  1:07 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-16 13:23 [PATCH 00/11]: add remaining support for IGEP boards Javier Martinez Canillas
2013-11-16 13:23 ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 01/11] ARM: dts: omap3-igep: Fix bus-width for mmc1 Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 02/11] ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 03/11] ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 14:44   ` Tony Lindgren
2013-11-16 14:44     ` Tony Lindgren
2013-11-16 15:19     ` Javier Martinez Canillas
2013-11-16 15:19       ` Javier Martinez Canillas
2013-11-16 15:22       ` Tony Lindgren
2013-11-16 15:22         ` Tony Lindgren
2013-11-16 13:23 ` [PATCH 04/11] ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 05/11] ARM: dts: omap3-igep0020: Add pinmuxing for DVI output Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 06/11] ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 07/11] ARM: dts: AM33XX BASE0033: add pinmux and user led support Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 08/11] ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 09/11] ARM: dts: AM33XX IGEP0033: add USB support Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 13:23 ` [PATCH 11/11] OMAPDSS: DPI: use VPLL2 regulator if VDDS_DSI is not found Javier Martinez Canillas
2013-11-16 13:23   ` Javier Martinez Canillas
2013-11-16 14:18   ` Tony Lindgren
2013-11-16 14:18     ` Tony Lindgren
2013-11-16 15:34     ` Javier Martinez Canillas
2013-11-16 15:34       ` Javier Martinez Canillas
2013-11-16 15:45       ` Tony Lindgren
2013-11-16 15:45         ` Tony Lindgren
2013-11-16 16:02         ` Sebastian Reichel
2013-11-16 16:02           ` Sebastian Reichel
2013-11-16 17:28           ` Javier Martinez Canillas
2013-11-16 17:28             ` Javier Martinez Canillas
2013-11-17  0:26             ` Sebastian Reichel
2013-11-17  0:26               ` Sebastian Reichel
2013-11-17  1:06               ` Javier Martinez Canillas [this message]
2013-11-17  1:06                 ` Javier Martinez Canillas
2013-11-16 14:16 ` [PATCH 00/11]: add remaining support for IGEP boards Tony Lindgren
2013-11-16 14:16   ` Tony Lindgren
2013-11-16 14:41   ` Javier Martinez Canillas
2013-11-16 14:41     ` Javier Martinez Canillas

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=52881693.7090600@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=bcousson@baylibre.com \
    --cc=eballetbo@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    /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.