Kevin, > -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, September 01, 2010 9:00 PM > To: DebBarma, Tarun Kanti > Cc: linux-omap@xxxxxxxxxxxxxxx; Gopinath, Thara; Basak, Partha; Nayak, > Rajendra; Paul Walmsley; Tony Lindgren > Subject: Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration > > "DebBarma, Tarun Kanti" <tarun.kanti@xxxxxx> writes: > > [...] > > >> > +static void omap2_dm_timer_enable(struct platform_device *pdev) > >> > +{ > >> > + if (!pdev) { > >> > + dev_err(&pdev->dev, "%s: invalid pdev\n", __func__); > >> > + return; > >> > + } > >> > + pm_runtime_get_sync(&pdev->dev); > >> > +} > >> > + > >> > +static void omap2_dm_timer_disable(struct platform_device *pdev) > >> > +{ > >> > + if (!pdev) { > >> > + dev_err(&pdev->dev, "%s: invalid pdev\n", __func__); > >> > + return; > >> > + } > >> > + pm_runtime_put_sync(&pdev->dev); > >> > +} > >> > >> There is no need for these functions. Driver should be calling runtime > >> PM API directly. > >> > > > In that case, driver will have to make call by directly accessing > > acquired timer's internal variables as shown below. > > pm_runtime_put_sync(&timer->pdev->dev); > > > > However, I believe we would like other drivers' perform all operations > > on acquired timers through exported APIs and keep the > > pm_runtime_put_sync() call internal to exported APIs as is the case > > current implementation. > > > > Let me know if I am missing anything here!! > > These new functions are not part of the exported API. You have made > them static, and part of the device layer. > > These are created as wrappers to pm_runtime_* API which are then called > by the driver layer. What I suggest is not creating these functions > (and the pdata-> function pointers to wrap them) but instead calling the > runtime PM api directly instead of using the pdata-> function pointers. > OK. > 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