linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Timur Tabi <timur@freescale.com>
Cc: Poonam_Aggrwal-b10812 <b10812@freescale.com>,
	michael.barkowski@freescale.com, netdev@vger.kernel.org,
	kumar.gala@freescale.com, linux-kernel@vger.kernel.org,
	rubini@vision.unipv.it, linuxppc-dev@ozlabs.org,
	ashish.kalra@freescale.com, rich.cutler@freescale.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Date: Thu, 24 Jan 2008 19:23:45 +0300	[thread overview]
Message-ID: <20080124162345.GA27359@localhost.localdomain> (raw)
In-Reply-To: <4798B4F3.2010101@freescale.com>

On Thu, Jan 24, 2008 at 09:55:31AM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
> 
> >Can we not introduce new pio-maps in the device trees? There
> >were debates regarding this, and if I understood everything
> >correctly, pio-maps considered as a bad taste. Better
> >do bunch of par_io_config_pin() in the board file. Better
> >yet fixup the firmware (u-boot) to set up dedicated pins
> >correctly.
> 
> I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls.  
> The problem is that the configuration of these pins is board-specific, but 
> pins are used by devices.  A device driver can't call par_io_config_pin(), 
> because the calls are different depending on which SoC and which UCC you're 
> using.  The platform code can't call par_io_config_pin(), because that 
> configuration depends on which drivers are loaded.

Are you saying that TDM is sharing same pins with the other QE device,
and we can choose to use/not use some device depending on which driver
is loaded? I think this particular board and patch isn't that case.

Even if someday there will be the case when drivers are mutually
exclusive, i.e. presence of some driver should trigger pins
reconfiguration, then anyway this should be handled differently.

That is, we should not _register_ two mutually exclusive devices
in the first place, so drivers will not probe them. That's board
setup code authority, and pins configuration still should happen
there.

[ Irrelevant to UCCs and this particular case: lately I've
  encountered one interesting case of Par IO usage. FHCI USB needs
  switching between pin's dedicated functions and GPIO functions.
  So, firstly it is using pins as dedicated, and later (at the bus
  reset) driver turns them to act as GPIOs. This is still handled
  without pio-map though, via gpios = <> property for that driver. ]

> In other words, the pin configurations are dependent on the UCC 
> configurations, and the UCC configurations are stored in the device tree.  
> So it makes sense to put the pin configurations in the device tree, too.

In that particular case UCC configuration is static, for every UCC.
So, we can set up all pins in the firmware/board file.

Please correct me if I'm wrong.

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

  reply	other threads:[~2008-01-24 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-24 10:30 [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries Poonam_Aggrwal-b10812
2008-01-24 15:48 ` Anton Vorontsov
2008-01-24 15:55   ` Timur Tabi
2008-01-24 16:23     ` Anton Vorontsov [this message]
2008-01-24 16:33       ` Timur Tabi
2008-01-24 17:23         ` Anton Vorontsov
2008-01-25  4:09           ` Aggrwal Poonam
2008-01-24 20:24         ` Scott Wood

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=20080124162345.GA27359@localhost.localdomain \
    --to=avorontsov@ru.mvista.com \
    --cc=akpm@linux-foundation.org \
    --cc=ashish.kalra@freescale.com \
    --cc=b10812@freescale.com \
    --cc=kumar.gala@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael.barkowski@freescale.com \
    --cc=netdev@vger.kernel.org \
    --cc=rich.cutler@freescale.com \
    --cc=rubini@vision.unipv.it \
    --cc=timur@freescale.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;
as well as URLs for NNTP newsgroup(s).