Govindraj <govindraj.ti@xxxxxxxxx> writes: > Hi, > >> >> FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I >> agree with Tao. >> >> The only reason for the PM hackery in mach-omap2/serial.c is because >> of the limitations of the 8250 driver. >> > > I have an query, > > We have following functionality in serial.c: > 1.) Enabling and disabling uart clocks. > 2.) Adding rx wakeup capabilities. > 3.) Preparing UARTs for idle mode. > 4.) Context save and restore. > > What functionality should be retained in serial.c file? > > AFAIK currently no serial driver has incorporated their platform > specific PM functionality like context_save and restore into their > serial driver, shouldn't these things be retained into > */mach-omap2/serial.c ? Only SoC and/or board-specific settings should be done in serial.c (setup of base addresses, IRQs, DMA channels, etc.) The driver is an OMAP specific driver, but should be general enough to independent of any board/SoC specifics. IMO, all of 1-4 above above belong in the driver. Evenutally the enabling/disabling of clocks will be handled by the runtime PM layer, but the driver will have a similar enable/disable API. Kevin -- 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
