From: Michal Simek <email@example.com>
To: "Sean Anderson" <firstname.lastname@example.org>,
"Michal Simek" <email@example.com>,
"Uwe Kleine-König" <firstname.lastname@example.org>
Cc: <email@example.com>, <firstname.lastname@example.org>,
Rob Herring <email@example.com>,
Thierry Reding <firstname.lastname@example.org>,
Alvaro Gamez <email@example.com>,
Daniel Lezcano <firstname.lastname@example.org>,
Lee Jones <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>, <email@example.com>
Subject: Re: [PATCH v3 2/2] clocksource: Add support for Xilinx AXI Timer
Date: Thu, 24 Jun 2021 18:25:50 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 6/18/21 11:24 PM, Sean Anderson wrote:
> On 6/16/21 8:12 AM, Michal Simek wrote:
>> Hi Uwe,
>> On 5/25/21 8:11 AM, Uwe Kleine-König wrote:
>>> Hello Sean, hello Michal,
>>> On Mon, May 24, 2021 at 09:00:51AM +0200, Michal Simek wrote:
>>>> On 5/20/21 10:13 PM, Sean Anderson wrote:
>>>>> On 5/19/21 3:24 AM, Michal Simek wrote:
>>>>>> On 5/18/21 12:15 AM, Sean Anderson wrote:
>>>>>>> This could be deprecated, but cannot be removed since existing
>>>>>>> trees (e.g. qemu) have neither clocks nor clock-frequency
>>>>>> Rob: Do we have any obligation to keep properties for other projects?
>>> If a binding is in the wild and used to be documented, it has to stay.
>>>>>>>> 4. Make driver as module
>>>>>>>> 5. Do whatever changes you want before adding pwm support
>>>>>>>> 6. Extend DT binding doc for PWM support
>>>>>>>> 7. Add PWM support
>>>>>>> Frankly, I am inclined to just leave the microblaze timer as-is.
> The PWM
>>>>>>> driver is completely independent. I have already put too much
> effort into
>>>>>>> this driver, and I don't have the energy to continue working on the
>>>>>>> microblaze timer.
>>>>>> I understand. I am actually using axi timer as pwm driver in one
> of my
>>>>>> project but never had time to upstream it because of couple of
> steps above.
>>>>>> We need to do it right based on steps listed above. If this is too
>>>>>> work it will have to wait. I will NACK all attempts to add separate
>>>>>> driver for IP which we already support in the tree.
>>>>> 1. Many timers have separate clocksource and PWM drivers. E.g.
>>>>> renesas TPU, etc. It is completely reasonable to keep separate
>>>>> drivers for these purposes. There is no Linux requirement that
>>>>> device have only one driver, especially if it has multiple
>>>>> or ways to be configured.
>>>> It doesn't mean that it was done properly and correctly. Code
>>>> duplication is bad all the time.
>>> IMHO it's not so much about code duplication. Yes, code duplication is
>>> bad and should be prevented if possible. But it's more important to not
>>> introduce surprises. So I think it should be obvious from reading the
>>> device tree source which timer is used to provide the PWM. I don't care
>>> much if this is from an extra property (like xilinx,provide-pwm),
>>> overriding the compatible or some other explicit mechanism. IIUC in this
>>> suggested patch the selection is implicit and so this isn't so nice.
>>>>> 2. If you want to do work on a driver, I'm all for it. However, if you
>>>>> have not yet submitted that work to the list, you should not gate
>>>>> other work behind it. Saying that X feature must be gated behind Y
>>>>> *even if X works completely independently of Y* is just stifling
>>>> I gave you guidance how I think this should be done. I am not gating
>>>> from this work. Your patch is not working on Microblaze arch which is
>>>> what I maintain. And I don't want to go the route that we will have two
>>>> drivers for the same IP without integration. We were there in past and
>>>> it is just pain.
>>>> I am expecting that PWM guys will guide how this should be done
>>>> properly. I haven't heard any guidance on this yet.
>>>> Thierry/Uwe: Any comment?
>>> Not sure I can and want to provide guidance here. This is not Perl, but
>>> still TIMTOWTDI. If it was me who cared here, I'd look into the
>>> auxiliary bus (Documentation/driver-api/auxiliary_bus.rst) to check if
>>> it can help to solve this problem.
>> I recently got patches for cadence TTC driver
>> (drivers/clocksource/timer-cadence-ttc.c) for PWM support too. It is the
>> second and very similar case. This driver is used on Zynq as clock
>> source and can be also use as PWM. I can't believe that there are no
>> other examples how to deal with these timers which are used for PWM
> The approach I took in v4 is that probe functions and driver callbacks
> live in drivers/timer and drivers/pwm, and common functions live in
> drivers/mfd (although I may move them to drivers/timer since Lee Jones
> doesn't like them there).
> I would greatly appreciate if you could review v4. It has been on the
> list for three weeks now with no comments from either you or Uwe.
I will take a look at it next week.
next prev parent reply other threads:[~2021-06-24 16:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 19:12 [PATCH v3 1/2] dt-bindings: pwm: Add Xilinx AXI Timer Sean Anderson
2021-05-11 19:12 ` [PATCH v3 2/2] clocksource: Add support for " Sean Anderson
2021-05-11 19:19 ` Sean Anderson
2021-05-12 8:31 ` kernel test robot
2021-05-14 8:59 ` Michal Simek
2021-05-14 14:40 ` Sean Anderson
2021-05-17 7:54 ` Michal Simek
2021-05-17 22:15 ` Sean Anderson
2021-05-19 7:24 ` Michal Simek
2021-05-20 20:13 ` Sean Anderson
2021-05-24 7:00 ` Michal Simek
2021-05-24 18:34 ` Sean Anderson
2021-05-25 6:11 ` Uwe Kleine-König
2021-05-25 14:30 ` Sean Anderson
2021-06-16 12:12 ` Michal Simek
2021-06-18 21:24 ` Sean Anderson
2021-06-24 16:25 ` Michal Simek [this message]
2021-05-12 18:35 ` [PATCH v3 1/2] dt-bindings: pwm: Add " Rob Herring
2021-05-13 2:16 ` Rob Herring
2021-05-13 14:33 ` Sean Anderson
2021-05-13 15:28 ` Sean Anderson
2021-05-13 20:43 ` Rob Herring
2021-05-13 21:01 ` Sean Anderson
2021-05-14 8:50 ` Michal Simek
2021-05-14 17:13 ` Sean Anderson
2021-05-17 8:28 ` Michal Simek
2021-05-17 14:40 ` Sean Anderson
2021-05-17 14:49 ` Michal Simek
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).