On Mon, Sep 29, 2014 at 03:37:50PM +0200, Bart Tanghe wrote: > On 2014-09-29 07:33, Thierry Reding wrote: > > On Fri, Sep 26, 2014 at 08:45:57AM -0600, Stephen Warren wrote: > >> On 09/26/2014 01:11 AM, Thierry Reding wrote: > >>> On Thu, Sep 04, 2014 at 09:06:48AM -0600, Stephen Warren wrote: > > [...] > >>>> Oh dear. It sounds like we need at least some form of clock driver for > >>>> the > >>>> platform then. I still don't think there's complete documentation for the > >>>> HW, even though a lot of register docs were published which presumably > >>>> cover > >>>> the clock HW? Equally, given that the VC firmware assumes it owns most of > >>>> the HW, it seems best to manipulate the clocks through the firmware > >>>> interface rather than directly touching the HW. Unfortunately, I don't > >>>> believe there's any ABI guarantee on the firmware interface. Perhaps we > >>>> can > >>>> get one? > >>> > >>> Urgs... this VC firmware seems to be more of a headache that I thought > >>> it was. How is this handled in other drivers? Surely PWM isn't the first > >>> one that needs clocks? > >> > >> For the other clocks, I've set up dummy fixed-rate clocks in the DT and/or > >> "clock driver" code to satisfy references by phandle or clock name > >> respectively. Since the other drivers don't actually manipulate the clock > >> rates etc., this is enough for the drivers. > > > > Given that this driver only queries the clock frequency adding a fixed- > > rate clock to the device tree should work as well. Then the calls to > > clk_prepare_enable() and clk_disable_unprepare() can still be added as > > appropriate so that the driver doesn't need to change if a proper clock > > driver ever gets added. > > > > Or am I missing anything? Perhaps the issue is that the default clock > > rate for the PWM clock isn't usable? That would still not prevent the > > driver from being merged. > > > > Thierry > > > The pwm clock is default unusable. To let the pwm clock run, It's necessary > to change some > clock registers. I've added the clk_prepare_enable and the > clk_disable_unprepare functions. So the > driver is able to work with a proper clock driver in the future.
Okay. Sounds good to me. Thierry
pgpofSHl8_EAy.pgp
Description: PGP signature