On Thu, Mar 3, 2011 at 10:38 AM, Sricharan R [off-list ref] wrote:

Hi,

quoted

-----Original Message-----
From: Govindraj [mailto:govindraj.ti at gmail.com]
Sent: Wednesday, March 02, 2011 3:37 PM
To: Sricharan R
Cc: Govindraj.R; linux-omap at vger.kernel.org;

linux-serial at vger.kernel.org;

quoted

linux-arm-kernel at lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
configured from board file

On Wed, Mar 2, 2011 at 1:49 PM, Sricharan R [off-list ref] wrote:

quoted

Hi,

quoted

-----Original Message-----
From: Govindraj [mailto:govindraj.ti at gmail.com]
Sent: Wednesday, March 02, 2011 1:11 PM
To: Sricharan R
Cc: Govindraj.R; linux-omap at vger.kernel.org;

linux-serial at vger.kernel.org;

quoted

linux-arm-kernel at lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
configured from board file

On Wed, Mar 2, 2011 at 12:46 AM, Sricharan R [off-list ref]

wrote:

quoted

quoted

quoted

quoted

Hi,

quoted

diff --git a/arch/arm/mach-omap2/serial.c

b/arch/arm/mach-omap2/serial.c

quoted

quoted

quoted

index 755f4aa..530e9e3 100644

--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c

@@ -44,6 +44,15 @@

static int omap_uart_con_id __initdata = -1;

+static struct omap_uart_port_info omap_serial_default_info[] = {
+ ? ? ?{
+ ? ? ? ? ? ? ?.dma_enabled ? ?= 0,
+ ? ? ? ? ? ? ?.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ ? ? ? ? ? ? ?.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
+ ? ? ? ? ? ? ?.idle_timeout ? = DEFAULT_IDLE_TIMEOUT,
+ ? ? ?},
+};
+
static int uart_idle_hwmod(struct omap_device *od)
{
? ? ? omap_hwmod_idle(od->hwmods[0]);

@@ -66,6 +75,54 @@ static struct omap_device_pm_latency

omap_uart_latency[]

quoted

= {
? ? ? },
};

+#ifdef CONFIG_OMAP_MUX
+static struct omap_device_pad default_serial0_pads[] __initdata = {
+ ? ? ?{
+ ? ? ? ? ? ? ?.name ? = "uart1_rx.uart1_rx",
+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |

OMAP_DEVICE_PAD_WAKEUP,

quoted

quoted

quoted

+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
+ ? ? ?},
+};
+
+static struct omap_device_pad default_serial1_pads[] __initdata = {
+ ? ? ?{
+ ? ? ? ? ? ? ?.name ? = "uart2_rx.uart2_rx",
+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |

OMAP_DEVICE_PAD_WAKEUP,

quoted

quoted

quoted

+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
+ ? ? ?},
+};
+
+static struct omap_device_pad default_serial2_pads[] __initdata = {
+ ? ? ?{
+ ? ? ? ? ? ? ?.name ? = "uart3_rx_irrx.uart3_rx_irrx",
+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |

OMAP_DEVICE_PAD_WAKEUP,

quoted

quoted

quoted

+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
+ ? ? ?},
+};
+
+static struct omap_device_pad default_omap36xx_serial3_pads[]

__initdata

quoted

quoted

=

quoted

{
+ ? ? ?{
+ ? ? ? ? ? ? ?.name ? = "gpmc_wait3.uart4_rx",
+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |

OMAP_DEVICE_PAD_WAKEUP,

quoted

quoted

quoted

+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE2,
+ ? ? ?},
+};
+
+static struct omap_device_pad default_omap4_serial3_pads[]

__initdata

quoted

quoted

=

quoted

quoted

{

quoted

+ ? ? ?{
+ ? ? ? ? ? ? ?.name ? = "uart4_rx.uart4_rx",
+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |

OMAP_DEVICE_PAD_WAKEUP,

quoted

quoted

quoted

+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
+ ? ? ?},
+};

Here only the UART RX pins are muxed, so what about the cts, rts, tx

pins?

The intention here is to enable wakeup capabilities for uart rx pad.

AFAIK most of the boards are currently dependent on bootloader for
uart-muxing if any board is not dependent on bootloader then we
can use omap_serial_init_port along with board_mux_info from board.

Yes. The idea is to be independent of the bootloaders for mux settings.

quoted

Prior to this change uart wakeup is based on rx_pad and we were

populating

quoted

offset and using omap_ctrl api's to read/write which is cleaned up now.
Most of boards are dependent on uart-rx wakeup to avoid breaking any
board support we
are using omap_serial_init by filling default values, which provides
us with same
environment but with right approach towards handling mux data with a
handshake with
hwmod framework.

Now, in this change only the RX pin is configured. So if some board

uses

quoted

quoted

omap_serial_init then only the RX is going to be configured.
How will they configure the rest of the pins?

They should call omap_serial_init_port to configure each individual uart
with
mux_info filled and not use omap_serial_init.

If any board is not dependent for mux from u-boot then they use above

said

quoted

init_port func.

quoted

They cannot call omap_serial_init_port after this just to configure the
rest of the mux pins( cts, rts, tx).

No. You need to use either omap_serial_init_port or omap_serial_init
you cannot call both apis from board file please refer to both func
documentation.

Also please note i am not configuring all uart pins for pullups and pull
downs
with this patch series and its not related to this patch series.
I am only enabling wakeup-enable pin for rx as it was done before.

quoted

So data which is passed from omap_serial_init should have the
configuration
for all the pins, and this default data should be consistent across
atleast
some boards, so that they can use this. This will reduce the data
duplication across board files.

If this is not true, then all the pads can be configured from the board
files itself using omap_serial_init_port and you can set the required
RX wakeup capability there as well.

Yes that be done but currently but that is not in my intention here
with my patch
I just want to retain rx wakeup by default to avoid breaking support
for any board.

Adding pin mux for each individual pin is a separate activity where I

also

quoted

need access to various boards So I am leaving that to developers who
want to configure
for the corresponding boards using init_port api.

Removing mux from u-boot level and adding it to board file is beyond
the scope of this
patch series and is a separate topic of discussion, as current patch

series

quoted

assumes that uarts are muxed from u-boot level and needs to only enable
wakeup
capability for rx-pin.

Hope this clarifies.

It is true that this patch is not intending to configure the pads.

But my question is, after this patch say
? 1) some board file calls omap_serial_port.
? 2) As a result , all the uarts devices are build and only the Rx pad is
configured for each device.
? 3) After this there will be no way of configuring the rest of the pads
??
? ? ?That should not happen. Also relying that the bootloaders are going
? ? ?to do the configuration is not correct.

? ? ?So if some board calls omap_serial_port then there should be default
values for all pads which a board can use, otherwise the board calls
omap_serial_init_port for each of the device.

ok I will add default values for all pads and enable rx wakeup for rx pad.

Will incorporate in next version.

--
Thanks,
Govindraj.R

quoted

--
Thanks,
Govindraj.R

quoted

quoted

So if any board needs specific mux they can go ahead and add required
mux data in
board file and use map_serial_init_port instead of current
omap_serial_init.

quoted

Is it consistent that across all socs that only UART3 would have

UART/IRDA

quoted

functions capability so that serial2 pads can always be called

"rx_irxx"

quoted

quoted

?.

Yes from OMAP2420 to OMAP4430 uart3 can used as irda.

Ok.

quoted

--
Thanks,
Govindraj.R