On Wed, Mar 2, 2011 at 1:49 PM, Sricharan R <r.sricharan@xxxxxx> wrote: > Hi, >>-----Original Message----- >>From: Govindraj [mailto:govindraj.ti@xxxxxxxxx] >>Sent: Wednesday, March 02, 2011 1:11 PM >>To: Sricharan R >>Cc: Govindraj.R; linux-omap@xxxxxxxxxxxxxxx; > linux-serial@xxxxxxxxxxxxxxx; >>linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
