* Girish. S. G. <girishsg@xxxxxx> [080822 15:42]: > Tony, > > > Hi, > > > > Some comments below. > > > > * Girish. S. G. <girishsg@xxxxxx> [080731 14:26]: > >> Serial driver for OMAP Uart controllers > >> > >> Signed-off-by: Girish S G <girishsg@xxxxxx> > >> --- > >> arch/arm/configs/omap_3430sdp_defconfig | 12 > >> arch/arm/mach-omap2/serial.c | 166 ++--- > >> drivers/serial/Kconfig | 23 > >> drivers/serial/Makefile | 1 > >> drivers/serial/omap-serial.c | 887 > >> ++++++++++++++++++++++++++++++++ > >> include/linux/serial_core.h | 3 > >> 6 files changed, 974 insertions(+), 118 deletions(-) > >> > >> Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig > > >> } > >> -} > >> - > >> -static struct platform_device serial_device = { > >> - .name = "serial8250", > >> - .id = PLAT8250_DEV_PLATFORM, > >> - .dev = { > >> - .platform_data = serial_platform_data, > >> - }, > >> -}; > > > > What about powering UART on/off? I suggest you provide set_power() > > function in platform_data. That way the UART power function can be > > generic on later omaps, or external like the FPGA on omap1510. > > There isn't any specific power on/off for UART as such(or any on omap1510?). > But yes we can have all the clk and pm related functions to be grouped under > uart_ops->pm(). Yeah I believe it's an external power for early omaps. So some board specific function pointer should be available for that. > > >> +static struct console serial_omap_console = { > >> + .name = "ttyS", > >> + .write = serial_omap_console_write, > >> + .device = uart_console_device, > >> + .setup = serial_omap_console_setup, > >> + .flags = CON_PRINTBUFFER, > >> + .index = -1, > >> + .data = &serial_omap_reg, > >> +}; > >> + > > > > AFAIK using ttyS name will break hot-plug 8250 ports, such as CF ports. > > How about using ttyO or something similar? I guess the minor number also > > needs to be different then. > > > > In general, will this driver also work on DaVinci? Maybe use name like > > serial_ti or similar? > > I don't think the name would conflict as only our uart instance would be up and > working. Right now this driver is supported and tested only on OMAP2/OMAP3. But > yes, once it's in it can be easily ported on other TI platforms. The thing is this driver won't be accepted upstream if it conflicts with hot-pluggable 8250 ports. AFAIK, you need to get a new id for it, and call it something like ttyO instead. > I will resend the patch with only OMAP2/OMAP3 support as of now. Yeah that's fine as long as the functions can be added for ther omaps later on as needed. Tony -- 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