Re: [resend rfc v3] pwm: add BCM2835 PWM driver

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]