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

-----Original Message-----
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Sent: Wednesday, July 14, 2021 7:51 PM
To: Rob Herring <robh@kernel.org>
Cc: Sanil, Shruthi <redacted>; Daniel Lezcano
[off-list ref]; Thomas Gleixner [off-list ref]; linux-
kernel@vger.kernel.org; devicetree@vger.kernel.org;
kris.pan@linux.intel.com; Mark Gross [off-list ref]; Thokala,
Srikanth [off-list ref]; Raja Subramanian, Lakshmi Bai
[off-list ref]; Sangannavar, Mallikarjunappa
[off-list ref]
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:

quoted

On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko
[off-list ref] wrote:

quoted

On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote:

quoted

On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@intel.com

wrote:

quoted

quoted

quoted

quoted

+  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.

quoted

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.

quoted

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.

Regards,
Shruthi

--
With Best Regards,
Andy Shevchenko