[PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
Govindraj
govindraj.ti at gmail.com
Wed Mar 2 05:07:11 EST 2011
On Wed, Mar 2, 2011 at 1:49 PM, Sricharan R <r.sricharan at ti.com> wrote:
> Hi,
>>-----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;
>>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 <r.sricharan at ti.com> wrote:
>>> Hi,
>>>>diff --git a/arch/arm/mach-omap2/serial.c
> b/arch/arm/mach-omap2/serial.c
>>>>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[]
>>>>= {
>>>> },
>>>> };
>>>>
>>>>+#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,
>>>>+ .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,
>>>>+ .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,
>>>>+ .enable = OMAP_MUX_MODE0,
>>>>+ },
>>>>+};
>>>>+
>>>>+static struct omap_device_pad default_omap36xx_serial3_pads[]
> __initdata
>>> =
>>>>{
>>>>+ {
>>>>+ .name = "gpmc_wait3.uart4_rx",
>>>>+ .flags = OMAP_DEVICE_PAD_REMUX |
> OMAP_DEVICE_PAD_WAKEUP,
>>>>+ .enable = OMAP_MUX_MODE2,
>>>>+ },
>>>>+};
>>>>+
>>>>+static struct omap_device_pad default_omap4_serial3_pads[] __initdata
> =
>>> {
>>>>+ {
>>>>+ .name = "uart4_rx.uart4_rx",
>>>>+ .flags = OMAP_DEVICE_PAD_REMUX |
> OMAP_DEVICE_PAD_WAKEUP,
>>>>+ .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.
>
>>Prior to this change uart wakeup is based on rx_pad and we were
> populating
>>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
> 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
init_port func.
> 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.
> 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
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
assumes that uarts are muxed from u-boot level and needs to only enable wakeup
capability for rx-pin.
Hope this clarifies.
--
Thanks,
Govindraj.R
>>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.
>>
>>
>>> Is it consistent that across all socs that only UART3 would have
>>UART/IRDA
>>> functions capability so that serial2 pads can always be called
> "rx_irxx"
>>> ?.
>>
>>Yes from OMAP2420 to OMAP4430 uart3 can used as irda.
>>
> Ok.
>>--
>>Thanks,
>>Govindraj.R
>
More information about the linux-arm-kernel
mailing list