linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
Date: Thu, 5 Apr 2012 10:02:56 -0700	[thread overview]
Message-ID: <20120405170255.GC3785@atomide.com> (raw)
In-Reply-To: <20120405165811.GB3785@atomide.com>

* Tony Lindgren <tony@atomide.com> [120405 10:01]:
> * Raja, Govindraj <govindraj.raja@ti.com> [120403 23:18]:
> > On Tue, Apr 3, 2012 at 11:49 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Govindraj.R <govindraj.raja@ti.com> [120321 03:06]:
> > >> From: "Govindraj.R" <govindraj.raja@ti.com>
> > >>
> > >> The following commit:
> > >> (7496ba3 ?ARM: OMAP2+: UART: Add default mux for all uarts)
> > >> added default pads for all uarts. But not all boards tend to
> > >> use all uarts and most of unused uart pins are muxed for
> > >> other purpose. This commit breaks the modules which where trying
> > >> to use unused uart pins on their boards.
> > >>
> > >> So remove all default pads except uart1/3 as most boards
> > >> tend to use either uart1/3 as console port and use only tx/rx
> > >> lines, declare only those pads for uart1/3.
> > >> If any boards tend to use any other uart other uart1/3
> > >> the mux data should to passed from board file and init individual
> > >> uart port using omap_serial_init_port api.
> > >
> > > This is still wrong. We can't mux any serial pins unless specifically
> > > requested from the board-*.c files. So please do a fix to get back to
> > > v3.2 behaviour where you basically revert 7496ba3.
> > 
> > How to do we fix the rx pin wakeup capability?
> > The mux data has the info about the rx pin wakeup
> > 
> > Without rx pin wakeup PM will be broken.
> 
> Let's first make things work reliably before even getting started
> about PM being broken.
> 
> > Fix all board files with duplicated data for uart3 or
> > uart1 having rx pin marked as wakeup capable?
> 
> And how do you know which pins to mux? You don't, unless you look
> at the schematics for all the boards.
> 
> The only safe option without looking at the schematics is to
> make omap_serial_init not do any muxing. If you want muxing and
> PM wake-up events, then use omap_serial_init_port for those ports
> with board specific pins.

Something that might be doable is to read the pin settings for the
uart in question in omap_serial_init. And then bail out for that
port if the rx or tx pin is not already muxed to uart in question.
Only if the rx and tx pin is muxed for uart, then you can enable
the wake-up events.

So basically doing remuxing in serial.c is only safe when
omap_serial_init_port with mux data is being used.

Regards,

Tony

  reply	other threads:[~2012-04-05 17:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-21 10:02 [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads Govindraj.R
2012-04-03 18:19 ` Tony Lindgren
2012-04-04  6:14   ` Raja, Govindraj
2012-04-05 16:58     ` Tony Lindgren
2012-04-05 17:02       ` Tony Lindgren [this message]
2012-04-06  6:05       ` Raja, Govindraj
2012-04-06 18:15         ` Tony Lindgren
2012-04-09 11:08           ` Raja, Govindraj
2012-04-09 16:56             ` Russ Dill
2012-04-09 20:36               ` 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=20120405170255.GC3785@atomide.com \
    --to=tony@atomide.com \
    --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 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).