RE: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem Bay SoC Timer

From: Sanil, Shruthi
Date: Thu Jul 22 2021 - 05:57:47 EST


> -----Original Message-----
> From: Sanil, Shruthi
> Sent: Thursday, July 15, 2021 1:32 PM
> To: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>; Rob Herring
> <robh@xxxxxxxxxx>
> Cc: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>; Thomas Gleixner
> <tglx@xxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; kris.pan@xxxxxxxxxxxxxxx; Mark Gross
> <mgross@xxxxxxxxxxxxxxx>; Thokala, Srikanth <Srikanth.Thokala@xxxxxxxxx>;
> Raja Subramanian, Lakshmi Bai <lakshmi.bai.raja.subramanian@xxxxxxxxx>;
> Sangannavar, Mallikarjunappa <mallikarjunappa.sangannavar@xxxxxxxxx>
> Subject: RE: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem
> Bay SoC Timer
>
> > -----Original Message-----
> > From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > Sent: Wednesday, July 14, 2021 7:51 PM
> > To: Rob Herring <robh@xxxxxxxxxx>
> > Cc: Sanil, Shruthi <shruthi.sanil@xxxxxxxxx>; Daniel Lezcano
> > <daniel.lezcano@xxxxxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx>;
> > linux- kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> > kris.pan@xxxxxxxxxxxxxxx; Mark Gross <mgross@xxxxxxxxxxxxxxx>;
> > Thokala, Srikanth <srikanth.thokala@xxxxxxxxx>; Raja Subramanian,
> > Lakshmi Bai <lakshmi.bai.raja.subramanian@xxxxxxxxx>; Sangannavar,
> > Mallikarjunappa <mallikarjunappa.sangannavar@xxxxxxxxx>
> > Subject: Re: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel
> > Keem Bay SoC Timer
> >
> > On Wed, Jul 14, 2021 at 08:07:44AM -0600, Rob Herring wrote:
> > > On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko
> > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote:
> > > > > On Mon, Jun 28, 2021 at 11:44:09AM +0530,
> > > > > shruthi.sanil@xxxxxxxxx
> > wrote:
> > > >
> > > > > > + The parent node represents the common general configuration
> > > > > > + details and the child nodes represents the counter and timers.
> > > > >
> > > > > I don't think all the child nodes are necessary. Are the
> > > > > counters and timers configurable (say on another SoC)? If not,
> > > > > then a single node here would suffice.
> > > >
> > > > If you may notice the children may have different properties that
> > > > can't be known ahead, such as IRQ line. On some platforms it may
> > > > be this mapping, on another it maybe different.
> > >
> > > What I noticed is it's all the same clock and 1 interrupt for each
> > > timer can be just a single 'interrupts' property with 8 entries.
> >
> > This may work.
> >
> > > Is there a platform that's different or that's a hypothetical?
> > > Because hypothetically, every aspect of every IP could change. But
> > > we don't try to parameterize everything in DT. It's a judgement call
> > > between implying things from compatible and explicit DT properties.
> > >
> > > > With all respect for the simplification I think we can't do it here.
> > >
> > > You can. Any data in DT could be in the kernel. It's a question of
> > > balance, not can or can't.
> >
> > Not only, it's also matters of what exactly hardware is: 8 timers or
> > timer with
> > 8 channels. If it's the former one, I prefer to have DT exactly like
> > originally suggested, otherwise I will agree on your proposal.
>
> Yes Andy, its correct, we have 8 timers in the hardware which are
> independent.
> Also the timer framework provides option to parse all the device tree details.
> In this case we would pass the timer node to the framework and get the
> base, IRQ and clock. If we go for a single node approach then all these need
> to be handled in the driver, hence making it complicated.
>

Hi Rob,
Yes, the counter and timers are configurable on another SoC. Do you give a nod on the current design?
Shall I proceed with submitting the next version addressing the other 2 comments of yours regarding the description and the unit address update?

> Regards,
> Shruthi
>
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >