All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Nishanth Menon <nm@ti.com>,
	linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com>
Cc: linux-arm-kernel@lists.infradead.org, Archit Taneja <archit@ti.com>
Subject: Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common
Date: Fri, 25 Oct 2013 14:33:26 +0300	[thread overview]
Message-ID: <526A5706.5010803@ti.com> (raw)
In-Reply-To: <526A542D.8060801@ti.com>

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

On 25/10/13 14:21, Nishanth Menon wrote:

>> The problem here is that the gpios don't really belong to anyone in the
>> kernel, as we don't have a driver for the switch.
>>
>> Or did you mean that we'd still have the code in dss-common.c, but just
>> get the gpio numbers from the .dts instead? That makes sense, although
>> I'd want to get rid of that code altogether.
>>
>> Should we have support in the gpio-controller to define default values
>> for gpios? I don't think we can rely on the boot loader to set things
>> correctly.
>>
> 
> I am unfortunately, not in a position to know how you plan to
> architect dss_common or the various panels associated with it. if you

The dss-common.c is just a hack, needed during the transition to DT.
It's supposed to go away as soon as we have proper DT support for DSS.

In this case it has just been a convenient place to set the gpios at
boot time. The gpios are not touched after that.

> model these as panels and a generic driver which controls the panel
> could request and control pins and gpios as needed I suppose.
> 
> gpio controller cannot drive default pull direction, that is the job
> of the driver using the gpio.

I agree. But what to do when there is no driver that uses the gpio, but
the gpio still affects the drivers? That's more or less the situation here.

The SDP board has an LCD and a PicoDLP projector, and the board
designers have shared resources between those, meaning only one can be
used at a time.

Having the GPIO pulled down means that LCD2 won't have backlight
(although the gpio doesn't actually enable the backlight, it just
handles the routing if I'm not mistaken) , but PicoDLP will have
something (parallel video datalines, if I recall right).

I can't add that GPIO to either the LCD driver or the PicoDLP driver, as
it's not a property of either of them.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common
Date: Fri, 25 Oct 2013 14:33:26 +0300	[thread overview]
Message-ID: <526A5706.5010803@ti.com> (raw)
In-Reply-To: <526A542D.8060801@ti.com>

On 25/10/13 14:21, Nishanth Menon wrote:

>> The problem here is that the gpios don't really belong to anyone in the
>> kernel, as we don't have a driver for the switch.
>>
>> Or did you mean that we'd still have the code in dss-common.c, but just
>> get the gpio numbers from the .dts instead? That makes sense, although
>> I'd want to get rid of that code altogether.
>>
>> Should we have support in the gpio-controller to define default values
>> for gpios? I don't think we can rely on the boot loader to set things
>> correctly.
>>
> 
> I am unfortunately, not in a position to know how you plan to
> architect dss_common or the various panels associated with it. if you

The dss-common.c is just a hack, needed during the transition to DT.
It's supposed to go away as soon as we have proper DT support for DSS.

In this case it has just been a convenient place to set the gpios at
boot time. The gpios are not touched after that.

> model these as panels and a generic driver which controls the panel
> could request and control pins and gpios as needed I suppose.
> 
> gpio controller cannot drive default pull direction, that is the job
> of the driver using the gpio.

I agree. But what to do when there is no driver that uses the gpio, but
the gpio still affects the drivers? That's more or less the situation here.

The SDP board has an LCD and a PicoDLP projector, and the board
designers have shared resources between those, meaning only one can be
used at a time.

Having the GPIO pulled down means that LCD2 won't have backlight
(although the gpio doesn't actually enable the backlight, it just
handles the routing if I'm not mistaken) , but PicoDLP will have
something (parallel video datalines, if I recall right).

I can't add that GPIO to either the LCD driver or the PicoDLP driver, as
it's not a property of either of them.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/319ae9e2/attachment.sig>

  reply	other threads:[~2013-10-25 11:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 10:07 [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing Tomi Valkeinen
2013-10-25 10:07 ` Tomi Valkeinen
2013-10-25 10:07 ` [PATCH 2/3] ARM: dts: omap4-sdp: add LCD pinmuxing Tomi Valkeinen
2013-10-25 10:07   ` Tomi Valkeinen
2013-10-25 10:07 ` [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common Tomi Valkeinen
2013-10-25 10:07   ` Tomi Valkeinen
2013-10-25 10:18   ` Nishanth Menon
2013-10-25 10:18     ` Nishanth Menon
2013-10-25 10:25     ` Tomi Valkeinen
2013-10-25 10:25       ` Tomi Valkeinen
2013-10-25 10:54       ` Nishanth Menon
2013-10-25 10:54         ` Nishanth Menon
2013-10-25 11:13         ` Tomi Valkeinen
2013-10-25 11:13           ` Tomi Valkeinen
2013-10-25 11:21           ` Nishanth Menon
2013-10-25 11:21             ` Nishanth Menon
2013-10-25 11:33             ` Tomi Valkeinen [this message]
2013-10-25 11:33               ` Tomi Valkeinen
2013-10-25 11:14         ` Nishanth Menon
2013-10-25 11:14           ` Nishanth Menon
2013-10-25 11:17           ` Tomi Valkeinen
2013-10-25 11:17             ` Tomi Valkeinen
2013-10-25 11:46           ` Tomi Valkeinen
2013-10-25 11:46             ` Tomi Valkeinen
2013-10-25 15:24             ` Nishanth Menon
2013-10-25 15:24               ` Nishanth Menon
2013-10-29 10:15 ` [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing Tomi Valkeinen
2013-10-29 10:15   ` Tomi Valkeinen
2013-10-29 21:25   ` Tony Lindgren
2013-10-29 21:25     ` Tony Lindgren

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=526A5706.5010803@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=archit@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@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.