All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] video: ARM CLCD: Add DT support
Date: Thu, 12 Sep 2013 22:19:45 +0000	[thread overview]
Message-ID: <52323E01.2070902@wwwdotorg.org> (raw)
In-Reply-To: <1379009416.13571.68.camel@hornet>

On 09/12/2013 12:10 PM, Pawel Moll wrote:
> On Thu, 2013-09-12 at 16:23 +0100, Pawel Moll wrote:
>> Anyway, I think I've got an idea how to render the problem custom panel
>> properties invalid. If so, I'll send another version of the patch.
> 
> So, instead of describing the panel I thought I'd go lower level and try
> to describe the CLCD's signal functions. It gets down to something like
> this:
> 
> 8<----
> - arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
> 				a function of one of the CLD pads,
> 				starting from 0 up to 23; each pad can
> 				be described by one of the following values:
> 	- 0: reserved (not connected)
> 	- 0x100-0x107: color upper STN panel data 0 to 7
...
> Such approach would also solve problem with bizarre cases like the
> Versatile's (not Express ;-) muxer Russell mentioned (where there is a
> de-facto custom wiring used). And no, I had a look at pinmux bindings
> and I don't think they fit here at all...
> 
> Thoughts?

I think pinctrl would work just fine here. However, I suspect there's
little need for pinctrl. pinctrl is required when one module may impose
requirements on another module's muxable pins. I assume that the
configuration for pins on CLCD is only relevant for CLCD itself, so
there's no need to export an interface by which something else can
configure the pins. Now, if any of the pins could be e.g. "GPIO", then
this argument might not apply. Hence, I think pinctrl is only "possible"
here, not "required", and the approach above seems fine to me.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] video: ARM CLCD: Add DT support
Date: Thu, 12 Sep 2013 16:19:45 -0600	[thread overview]
Message-ID: <52323E01.2070902@wwwdotorg.org> (raw)
In-Reply-To: <1379009416.13571.68.camel@hornet>

On 09/12/2013 12:10 PM, Pawel Moll wrote:
> On Thu, 2013-09-12 at 16:23 +0100, Pawel Moll wrote:
>> Anyway, I think I've got an idea how to render the problem custom panel
>> properties invalid. If so, I'll send another version of the patch.
> 
> So, instead of describing the panel I thought I'd go lower level and try
> to describe the CLCD's signal functions. It gets down to something like
> this:
> 
> 8<----
> - arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
> 				a function of one of the CLD pads,
> 				starting from 0 up to 23; each pad can
> 				be described by one of the following values:
> 	- 0: reserved (not connected)
> 	- 0x100-0x107: color upper STN panel data 0 to 7
...
> Such approach would also solve problem with bizarre cases like the
> Versatile's (not Express ;-) muxer Russell mentioned (where there is a
> de-facto custom wiring used). And no, I had a look at pinmux bindings
> and I don't think they fit here at all...
> 
> Thoughts?

I think pinctrl would work just fine here. However, I suspect there's
little need for pinctrl. pinctrl is required when one module may impose
requirements on another module's muxable pins. I assume that the
configuration for pins on CLCD is only relevant for CLCD itself, so
there's no need to export an interface by which something else can
configure the pins. Now, if any of the pins could be e.g. "GPIO", then
this argument might not apply. Hence, I think pinctrl is only "possible"
here, not "required", and the approach above seems fine to me.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Sylwester Nawrocki
	<sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org"
	<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
	Arnd Bergmann
	<arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Jean-Christophe Plagniol-Villard
	<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
	Marek Szyprowski
	<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH 1/2] video: ARM CLCD: Add DT support
Date: Thu, 12 Sep 2013 16:19:45 -0600	[thread overview]
Message-ID: <52323E01.2070902@wwwdotorg.org> (raw)
In-Reply-To: <1379009416.13571.68.camel@hornet>

On 09/12/2013 12:10 PM, Pawel Moll wrote:
> On Thu, 2013-09-12 at 16:23 +0100, Pawel Moll wrote:
>> Anyway, I think I've got an idea how to render the problem custom panel
>> properties invalid. If so, I'll send another version of the patch.
> 
> So, instead of describing the panel I thought I'd go lower level and try
> to describe the CLCD's signal functions. It gets down to something like
> this:
> 
> 8<----
> - arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
> 				a function of one of the CLD pads,
> 				starting from 0 up to 23; each pad can
> 				be described by one of the following values:
> 	- 0: reserved (not connected)
> 	- 0x100-0x107: color upper STN panel data 0 to 7
...
> Such approach would also solve problem with bizarre cases like the
> Versatile's (not Express ;-) muxer Russell mentioned (where there is a
> de-facto custom wiring used). And no, I had a look at pinmux bindings
> and I don't think they fit here at all...
> 
> Thoughts?

I think pinctrl would work just fine here. However, I suspect there's
little need for pinctrl. pinctrl is required when one module may impose
requirements on another module's muxable pins. I assume that the
configuration for pins on CLCD is only relevant for CLCD itself, so
there's no need to export an interface by which something else can
configure the pins. Now, if any of the pins could be e.g. "GPIO", then
this argument might not apply. Hence, I think pinctrl is only "possible"
here, not "required", and the approach above seems fine to me.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-09-12 22:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06 17:23 [PATCH 1/2] video: ARM CLCD: Add DT support Pawel Moll
2013-09-06 17:23 ` Pawel Moll
2013-09-06 17:23 ` Pawel Moll
2013-09-06 17:23 ` [PATCH 2/2] ARM: vexpress: Add CLCD Device Tree properties Pawel Moll
2013-09-06 17:23   ` Pawel Moll
2013-09-06 17:23   ` Pawel Moll
2013-09-07 22:55 ` [PATCH 1/2] video: ARM CLCD: Add DT support Sylwester Nawrocki
2013-09-07 22:55   ` Sylwester Nawrocki
2013-09-07 22:55   ` Sylwester Nawrocki
2013-09-09 11:19   ` Pawel Moll
2013-09-09 11:19     ` Pawel Moll
2013-09-09 11:19     ` Pawel Moll
2013-09-10 21:41     ` Sylwester Nawrocki
2013-09-10 21:41       ` Sylwester Nawrocki
2013-09-10 21:41       ` Sylwester Nawrocki
2013-09-11 13:43       ` Pawel Moll
2013-09-11 13:43         ` Pawel Moll
2013-09-11 13:43         ` Pawel Moll
2013-09-11 21:14         ` Sylwester Nawrocki
2013-09-11 21:14           ` Sylwester Nawrocki
2013-09-11 21:14           ` Sylwester Nawrocki
2013-09-12 15:23           ` Pawel Moll
2013-09-12 15:23             ` Pawel Moll
2013-09-12 15:23             ` Pawel Moll
2013-09-12 18:10             ` Pawel Moll
2013-09-12 18:10               ` Pawel Moll
2013-09-12 18:10               ` Pawel Moll
2013-09-12 22:19               ` Stephen Warren [this message]
2013-09-12 22:19                 ` Stephen Warren
2013-09-12 22:19                 ` Stephen Warren
2013-09-12 22:38                 ` Russell King - ARM Linux
2013-09-12 22:38                   ` Russell King - ARM Linux
2013-09-12 22:38                   ` Russell King - ARM Linux

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=52323E01.2070902@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.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.