Hi, Rob > On Tue, Jul 9, 2019 at 7:30 PM Anson Huang <anson.huang@xxxxxxx> wrote: > > > > Hi, Rob > > > > > On Mon, Jul 1, 2019 at 3:47 AM <Anson.Huang@xxxxxxx> wrote: > > > > > > > > From: Anson Huang <Anson.Huang@xxxxxxx> > > > > > > 'dt-bindings: timer: ...' for the subject. > > > > OK, I made a mistake. > > > > > > > > > > > > > Systems which use platform driver model for clock driver require > > > > the clock frequency to be supplied via device tree when system > > > > counter driver is enabled. > > > > > > This is a DT binding. What's a platform driver? > > > > It is just trying to explain why we need to introduce this "clock-frequency" > > property, nothing about the binding and platform driver. > > > > > > > > > > > > > This is necessary as in the platform driver model the of_clk > > > > operations do not work correctly because system counter driver is > > > > initialized in early phase of system boot up, and clock driver > > > > using platform driver model is NOT ready at that time, it will > > > > cause system counter driver initialization failed. > > > > > > > > Add clock-frequency property to the device tree bindings of the > > > > NXP system counter, so the driver can tell timer-of driver to get > > > > clock frequency from DT directly instead of doing of_clk > > > > operations via clk APIs. > > > > > > While you've now given a good explanation why you need this, it all > > > sounds like linux specific issues and a DT change should not be necessary. > > > > > > Presumably, 'clocks' points to a fixed-clock node, right? Just parse the > 'clocks' > > > phandle and fetch the frequency from that node if you need to get > > > the frequency 'early'. > > > > Sound like a better solution, I will try that, since the system > > counter's clock is from osc_24m and divided by 3, since different > > platforms may have different divider, so maybe I can create a > > fixed-clock node in DT, then system counter driver can parse the clock and > fetch the frequency from that node, will redo a V5 patch. > > The divide by 3 can be implied by the compatible. If you need a different > divider, add another compatible. Yes, we can consider it later, till now, all the platforms used are with an internal divider of 3 in system counter block, so I make it fixed divided by 3 in system counter driver. > > > > > > > > Signed-off-by: Anson Huang <Anson.Huang@xxxxxxx> > > > > --- > > > > No change. > > > > --- > > > > .../devicetree/bindings/timer/nxp,sysctr-timer.txt | 15 +++++++++-- > ---- > > > > 1 file changed, 9 insertions(+), 6 deletions(-) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt > > > > b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt > > > > index d576599..7088a0e 100644 > > > > --- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt > > > > +++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt > > > > @@ -11,15 +11,18 @@ Required properties: > > > > - reg : Specifies the base physical address and size of the > comapre > > > > frame and the counter control, read & compare. > > > > - interrupts : should be the first compare frames' interrupt > > > > -- clocks : Specifies the counter clock. > > > > -- clock-names: Specifies the clock's name of this module > > > > +- clocks : Specifies the counter clock, mutually exclusive with > clock- > > > frequency. > > > > +- clock-names : Specifies the clock's name of this module, mutually > > > exclusive with > > > > + clock-frequency. > > > > +- clock-frequency : Specifies system counter clock frequency, > > > > +mutually > > > exclusive with > > > > + clocks/clock-names. > > > > > > It doesn't really work to say one or the other is needed unless you > > > make the OS support both cases. > > > > The OS already support both cases now with this patch series. > > What about FreeBSD or any other OS? Now that in V5, I use the fixed clock of OSC as clock input of system counter, no need to have all these changes now. And also no changes needed in DT binding, thanks for your review. Anson.
