public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: "Cousson, Benoit" <b-cousson@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "R, Sricharan" <r.sricharan@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
Date: Thu, 18 Nov 2010 22:06:59 +0100	[thread overview]
Message-ID: <4CE59573.80408@ti.com> (raw)
In-Reply-To: <20101118190650.GK9264@atomide.com>

On 11/18/2010 8:06 PM, Tony Lindgren wrote:
> * sricharan<r.sricharan@ti.com>  [101114 23:26]:
>> This series updates the core device drivers to use mux framework
>> for OMAP4 SDP and PANDA board. It's generated against the
>> linux-omap master branch. It has a dependency on the Benoit's
>> omap4 mux data series.
>
> <snip>
>
>> 2. Do PAD configuration independently for each module
>> Pros:
>> 	a. Avoids repetition of similar data for different boards.
>> 	b. Gives a knowledge of how pins are configured for a module
>> 	   to the respective owners.
>> 	c. Pads are not initialised unless they are really needed.
>> Cons:
>> 	a. Can become difficult to maintain if lot of data tend to be
>> 	   different across boards.
>
> For the common modules, we should have generic platform init code
> using hwmod. And that init code is the logical place to do the muxing.
>
> We also need to consider that the pin muxing is board specific.
> So in cases where the are alternative signal paths, we need to pass
> the signal names from board-*.c file to the platform driver init code.

What about the omap_board_mux array in board file? Do you want to get 
rid of it, or is the plan is to use that for pads that does not belong 
to any driver or pads that are purely board specific?

Regards,
Benoit

  reply	other threads:[~2010-11-18 21:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-15  7:38 [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins sricharan
2010-11-15  7:38 ` [PATCH 1/5] OMAP4: hsmmc: Initialise the mmc " sricharan
2010-11-18 19:03   ` Tony Lindgren
2010-11-15  7:38 ` [PATCH 2/5] OMAP4: usb-musb: Initialise the usb " sricharan
2010-11-15  7:38 ` [PATCH 3/5] OMAP4: mcbsp: Initialise the mcbsp " sricharan
2010-11-15  7:38 ` [PATCH 4/5] OMAP4: board-4430sdp: Initialise the mcspi " sricharan
2010-11-15  7:38 ` [PATCH 5/5] OMAP4: serial: Initialise the uart " sricharan
2010-11-15 22:33 ` [PATCH 0/5] OMAP4: mux: Initialise OMAP4 " Cousson, Benoit
2010-11-18 19:06 ` Tony Lindgren
2010-11-18 21:06   ` Cousson, Benoit [this message]
2010-11-18 21:26     ` Tony Lindgren
2010-11-19  8:48       ` R, Sricharan
2010-11-19 16:04         ` Tony Lindgren
     [not found] <1289886357-22821-1-git-send-email-r.sricharan@ti.com>
2010-11-16  6:15 ` R, Sricharan

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=4CE59573.80408@ti.com \
    --to=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=r.sricharan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox