On 01/23/2017 09:06 PM, David Lechner wrote: > On 01/23/2017 04:49 PM, Franklin S Cooper Jr wrote: >> Hi, >> >> My team is currently working on up-streaming Texas Instrument's 66AK2Gx >> SOC which needs PM runtime at a minimum enable the SOC's uart clock. >> >> For other drivers I've been able to simply replace clk_xxx calls with >> equivalent pm_runtime calls. However, those drivers only impacted TI >> SOCs which I've been able to verify didn't break anything for other >> SOCs. However, with so many non TI SOCs using the 8250_of.c driver I'm >> worried that making similar changes could end up breaking things for >> other people. > > I should say so. The driver uses the clock rate, so you can't remove the > clock without breaking the driver for everyone. Or is there a way to get > a clock rate from pm_runtime that I don't know about? > > Is there a reason that clk_xxx and pm_runtime_xxx cannot coexist in the > same driver? Sorry I'm only talking about replacing clk_enable/clk_disable and its variants with calls to pm_runtime_enable/pm_runtime_disable and pm_runtime_get/pm_runtime_put. Calls such as clk_get and clk_get_rate will remain. > >> So I'm curious which route people think is best for me to take: >> >> 1. Replace the various clk_xxx calls with minimal pm_runtime functions >> to enable and disable the clocks at probe/remove and resume/suspend. I >> would depend on others to test to insure nothing broke on their SOC. >> >> 2. Make a duplicate of 8250_of driver and make it specific to 66AK2Gx >> and other Keystone 2 SOCs. For the most part this new driver will be a >> trimmed version of 8250_of since it doesn't have to worry about other >> SOCs. >> >> Any thoughts or comments would be appreciated. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
