| Message ID | 20231114124748.581850-2-mubin.sayyed@amd.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add initial support for TTC PWM driver | expand |
Hi, > -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Sent: Wednesday, November 15, 2023 2:41 AM > To: Sayyed, Mubin <mubin.sayyed@amd.com>; > krzysztof.kozlowski+dt@linaro.org; u.kleine-koenig@pengutronix.de; > thierry.reding@gmail.com; robh+dt@kernel.org; conor+dt@kernel.org; > tglx@linutronix.de; daniel.lezcano@linaro.org; Simek, Michal > <michal.simek@amd.com> > Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; linux-pwm@vger.kernel.org; git (AMD-Xilinx) > <git@amd.com>; mubin10@gmail.com > Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not > probe TTC device configured as PWM > > On 14/11/2023 13:47, Mubin Sayyed wrote: > > TTC device can act either as clocksource/clockevent or PWM generator, > > it would be decided by pwm-cells property. > > TTC PWM feature would be supported through separate driver based on > > PWM framework. > > > > If pwm-cells property is present in TTC node, it would be treated as > > PWM device, and clocksource driver should just skip it. > > > > Signed-off-by: Mubin Sayyed <mubin.sayyed@amd.com> > > --- > > Changes for v2: > > - Added comment regarding pwm-cells property > > --- > > drivers/clocksource/timer-cadence-ttc.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/clocksource/timer-cadence-ttc.c > > b/drivers/clocksource/timer-cadence-ttc.c > > index 32daaac9b132..f8fcb1a4bdd0 100644 > > --- a/drivers/clocksource/timer-cadence-ttc.c > > +++ b/drivers/clocksource/timer-cadence-ttc.c > > @@ -477,6 +477,13 @@ static int __init ttc_timer_probe(struct > platform_device *pdev) > > u32 timer_width = 16; > > struct device_node *timer = pdev->dev.of_node; > > > > + /* > > + * If pwm-cells property is present in TTC node, > > + * it would be treated as PWM device. > > + */ > > + if (of_property_read_bool(timer, "#pwm-cells")) > > + return -ENODEV; > > You will introduce dmesg errors, so regressions. > [Mubin]: I will change it to "return 0" to avoid dmesg errors. > This does not look right. What you want is to bind one device driver and > choose different functionality based on properties. [Mubin]: I am doing it based on earlier discussion related to AXI Timer PWM driver. It was suggested to use #pwm-cells property for identifying role of device(PWM/clocksource) https://lore.kernel.org/linux-devicetree/20210513021631.GA878860@robh.at.kernel.org/. Thanks, Mubin > > Best regards, > Krzysztof
On 24/11/2023 12:03, Sayyed, Mubin wrote: > Hi Krzysztof, > >> -----Original Message----- >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> Sent: Wednesday, November 15, 2023 5:41 PM >> To: Sayyed, Mubin <mubin.sayyed@amd.com> >> Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; >> devicetree@vger.kernel.org; linux-pwm@vger.kernel.org; git (AMD-Xilinx) >> <git@amd.com>; mubin10@gmail.com; krzysztof.kozlowski+dt@linaro.org; >> u.kleine-koenig@pengutronix.de; thierry.reding@gmail.com; >> robh+dt@kernel.org; conor+dt@kernel.org; tglx@linutronix.de; >> daniel.lezcano@linaro.org; Simek, Michal <michal.simek@amd.com> >> Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not probe >> TTC device configured as PWM >> >> On 15/11/2023 06:55, Sayyed, Mubin wrote: >>>>> + /* >>>>> + * If pwm-cells property is present in TTC node, >>>>> + * it would be treated as PWM device. >>>>> + */ >>>>> + if (of_property_read_bool(timer, "#pwm-cells")) >>>>> + return -ENODEV; >>>> >>>> You will introduce dmesg errors, so regressions. >>>> >>> [Mubin]: I will change it to "return 0" to avoid dmesg errors. >> >> No, because solution is wrong. >> >>> >>>> This does not look right. What you want is to bind one device driver >>>> and choose different functionality based on properties. >>> [Mubin]: I am doing it based on earlier discussion related to AXI Timer PWM >> driver. It was suggested to use #pwm-cells property for identifying role of >> device(PWM/clocksource) https://lore.kernel.org/linux- >> devicetree/20210513021631.GA878860@robh.at.kernel.org/. >> >> You are mixing bindings with driver. I said here about driver and yes - you must >> use pwm-cells to differentiate that. It's obvious. >> >> So again, one driver binding. > [Mubin]: I will explore whether mfd framework can be used to handle this. You do not need MFD for this, because you do not have a really MFD. This is just one device, so I expect here one driver. Why do you need multiple drivers (which also would solve that problem but why?)? Best regards, Krzysztof
On 11/24/23 12:35, Krzysztof Kozlowski wrote: > On 24/11/2023 12:03, Sayyed, Mubin wrote: >> Hi Krzysztof, >> >>> -----Original Message----- >>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>> Sent: Wednesday, November 15, 2023 5:41 PM >>> To: Sayyed, Mubin <mubin.sayyed@amd.com> >>> Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; >>> devicetree@vger.kernel.org; linux-pwm@vger.kernel.org; git (AMD-Xilinx) >>> <git@amd.com>; mubin10@gmail.com; krzysztof.kozlowski+dt@linaro.org; >>> u.kleine-koenig@pengutronix.de; thierry.reding@gmail.com; >>> robh+dt@kernel.org; conor+dt@kernel.org; tglx@linutronix.de; >>> daniel.lezcano@linaro.org; Simek, Michal <michal.simek@amd.com> >>> Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not probe >>> TTC device configured as PWM >>> >>> On 15/11/2023 06:55, Sayyed, Mubin wrote: >>>>>> + /* >>>>>> + * If pwm-cells property is present in TTC node, >>>>>> + * it would be treated as PWM device. >>>>>> + */ >>>>>> + if (of_property_read_bool(timer, "#pwm-cells")) >>>>>> + return -ENODEV; >>>>> >>>>> You will introduce dmesg errors, so regressions. >>>>> >>>> [Mubin]: I will change it to "return 0" to avoid dmesg errors. >>> >>> No, because solution is wrong. >>> >>>> >>>>> This does not look right. What you want is to bind one device driver >>>>> and choose different functionality based on properties. >>>> [Mubin]: I am doing it based on earlier discussion related to AXI Timer PWM >>> driver. It was suggested to use #pwm-cells property for identifying role of >>> device(PWM/clocksource) https://lore.kernel.org/linux- >>> devicetree/20210513021631.GA878860@robh.at.kernel.org/. >>> >>> You are mixing bindings with driver. I said here about driver and yes - you must >>> use pwm-cells to differentiate that. It's obvious. >>> >>> So again, one driver binding. >> [Mubin]: I will explore whether mfd framework can be used to handle this. > > You do not need MFD for this, because you do not have a really MFD. This > is just one device, so I expect here one driver. Why do you need > multiple drivers (which also would solve that problem but why?)? this driver is following pattern which is xps-timer (soff IP) Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml which has two drivers in the kernel. On for clocksource arch/microblaze/kernel/timer.c and pwm one drivers/pwm/pwm-xilinx.c clocksource driver will be at some point moved to drivers/clocksource because that's what will be used in connection to MicroBlaze V. I have looked at TTC and functionality wise it is related to Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml or Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml which are based on MFD. Timer there is only clockevent not clocksource but it shouldn't really matter. The biggest issue what I see is that ttc clocksource driver is used on arm32 Zynq family for a lot of years. It means moving to different binding based on mfd would require keeping support for old dt binding too. That would be from my point of view thing to start with. What do you think what would be the best way forward? But I need to do my homework first to see what functionality that IP has but I am quite sure there could be at least multiple PMWs. Thanks, Michal
Hi, > -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Sent: Friday, November 24, 2023 5:06 PM > To: Sayyed, Mubin <mubin.sayyed@amd.com> > Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; linux-pwm@vger.kernel.org; git (AMD-Xilinx) > <git@amd.com>; mubin10@gmail.com; krzysztof.kozlowski+dt@linaro.org; > u.kleine-koenig@pengutronix.de; thierry.reding@gmail.com; > robh+dt@kernel.org; conor+dt@kernel.org; tglx@linutronix.de; > daniel.lezcano@linaro.org; Simek, Michal <michal.simek@amd.com> > Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do not probe > TTC device configured as PWM > > On 24/11/2023 12:03, Sayyed, Mubin wrote: > > Hi Krzysztof, > > > >> -----Original Message----- > >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >> Sent: Wednesday, November 15, 2023 5:41 PM > >> To: Sayyed, Mubin <mubin.sayyed@amd.com> > >> Cc: linux-arm-kernel@lists.infradead.org; > >> linux-kernel@vger.kernel.org; devicetree@vger.kernel.org; > >> linux-pwm@vger.kernel.org; git (AMD-Xilinx) <git@amd.com>; > >> mubin10@gmail.com; krzysztof.kozlowski+dt@linaro.org; > >> u.kleine-koenig@pengutronix.de; thierry.reding@gmail.com; > >> robh+dt@kernel.org; conor+dt@kernel.org; tglx@linutronix.de; > >> daniel.lezcano@linaro.org; Simek, Michal <michal.simek@amd.com> > >> Subject: Re: [LINUX PATCH v2 1/3] clocksource: timer-cadence-ttc: Do > >> not probe TTC device configured as PWM > >> > >> On 15/11/2023 06:55, Sayyed, Mubin wrote: > >>>>> + /* > >>>>> + * If pwm-cells property is present in TTC node, > >>>>> + * it would be treated as PWM device. > >>>>> + */ > >>>>> + if (of_property_read_bool(timer, "#pwm-cells")) > >>>>> + return -ENODEV; > >>>> > >>>> You will introduce dmesg errors, so regressions. > >>>> > >>> [Mubin]: I will change it to "return 0" to avoid dmesg errors. > >> > >> No, because solution is wrong. > >> > >>> > >>>> This does not look right. What you want is to bind one device > >>>> driver and choose different functionality based on properties. > >>> [Mubin]: I am doing it based on earlier discussion related to AXI > >>> Timer PWM > >> driver. It was suggested to use #pwm-cells property for identifying > >> role of > >> device(PWM/clocksource) https://lore.kernel.org/linux- > >> devicetree/20210513021631.GA878860@robh.at.kernel.org/. > >> > >> You are mixing bindings with driver. I said here about driver and yes > >> - you must use pwm-cells to differentiate that. It's obvious. > >> > >> So again, one driver binding. > > [Mubin]: I will explore whether mfd framework can be used to handle this. > > You do not need MFD for this, because you do not have a really MFD. This is just > one device, so I expect here one driver. Why do you need multiple drivers (which > also would solve that problem but why?)? Cadence TTC IP can be used as timer(clocksource/clockevent) and PWM device. We have drivers/clocksource/timer-cadence-ttc.c for clocksource/clockevent functionality. New driver for PWM functionality will be added to drivers/pwm/pwm-cadence.c (3/3 of this Series). In given SoC, multiple instances of TTC IP are possible(ZynqMP Ultrscale SoC has 4 Instances), few of them could be configured as clocksource/clockevent devices and others as PWM ones. So, cloksource as well as PWM drivers for cadence TTC IP would be enabled in the kernel. Now in this scenario, each TTC device would be matching with 2 drivers, clocksource and PWM, since compatible string is same. If I don’t add #pwm-cells checking in clocksource driver and return -ENODEV based on that, each device would always bind with clocksource driver. PWM driver would never probe since clocksource driver probes ahead of PWM one in probing order. I am exploring mfd to deal with said scenario. Do you see any better way to handle this? Thanks, Mubin > > Best regards, > Krzysztof
On 24/11/2023 13:07, Sayyed, Mubin wrote: >>>>>> This does not look right. What you want is to bind one device >>>>>> driver and choose different functionality based on properties. >>>>> [Mubin]: I am doing it based on earlier discussion related to AXI >>>>> Timer PWM >>>> driver. It was suggested to use #pwm-cells property for identifying >>>> role of >>>> device(PWM/clocksource) https://lore.kernel.org/linux- >>>> devicetree/20210513021631.GA878860@robh.at.kernel.org/. >>>> >>>> You are mixing bindings with driver. I said here about driver and yes >>>> - you must use pwm-cells to differentiate that. It's obvious. >>>> >>>> So again, one driver binding. >>> [Mubin]: I will explore whether mfd framework can be used to handle this. >> >> You do not need MFD for this, because you do not have a really MFD. This is just >> one device, so I expect here one driver. Why do you need multiple drivers (which >> also would solve that problem but why?)? > Cadence TTC IP can be used as timer(clocksource/clockevent) and PWM device. > We have drivers/clocksource/timer-cadence-ttc.c for clocksource/clockevent functionality. > New driver for PWM functionality will be added to drivers/pwm/pwm-cadence.c (3/3 of this > Series). In given SoC, multiple instances of TTC IP are possible(ZynqMP Ultrscale SoC has 4 > Instances), few of them could be configured as clocksource/clockevent devices and others > as PWM ones. So, cloksource as well as PWM drivers for cadence TTC IP would be enabled in > the kernel. > > Now in this scenario, each TTC device would be matching with 2 drivers, clocksource and PWM, since > compatible string is same. If I don’t add #pwm-cells checking in clocksource driver and return > -ENODEV based on that, each device would always bind with clocksource driver. PWM driver > would never probe since clocksource driver probes ahead of PWM one in probing order. None of these above explain why you need two drivers. > > I am exploring mfd to deal with said scenario. Do you see any better way to handle this? You basically repeated previous sentence about MFD without answering. Yeah, better way could be to have one driver. Why you cannot have it that way? Best regards, Krzysztof
On 24/11/2023 17:24, Krzysztof Kozlowski wrote: >>>>> So again, one driver binding. >>>> [Mubin]: I will explore whether mfd framework can be used to handle this. >>> >>> You do not need MFD for this, because you do not have a really MFD. This is just >>> one device, so I expect here one driver. Why do you need multiple drivers (which >>> also would solve that problem but why?)? >> Cadence TTC IP can be used as timer(clocksource/clockevent) and PWM device. >> We have drivers/clocksource/timer-cadence-ttc.c for clocksource/clockevent functionality. >> New driver for PWM functionality will be added to drivers/pwm/pwm-cadence.c (3/3 of this >> Series). In given SoC, multiple instances of TTC IP are possible(ZynqMP Ultrscale SoC has 4 >> Instances), few of them could be configured as clocksource/clockevent devices and others >> as PWM ones. So, cloksource as well as PWM drivers for cadence TTC IP would be enabled in >> the kernel. >> >> Now in this scenario, each TTC device would be matching with 2 drivers, clocksource and PWM, since >> compatible string is same. If I don’t add #pwm-cells checking in clocksource driver and return >> -ENODEV based on that, each device would always bind with clocksource driver. PWM driver >> would never probe since clocksource driver probes ahead of PWM one in probing order. > > None of these above explain why you need two drivers. And please do not answer to this with again: "I have two drivers...". > >> >> I am exploring mfd to deal with said scenario. Do you see any better way to handle this? > > You basically repeated previous sentence about MFD without answering. > Yeah, better way could be to have one driver. Why you cannot have it > that way? > > > Best regards, > Krzysztof > Best regards, Krzysztof
diff --git a/drivers/clocksource/timer-cadence-ttc.c b/drivers/clocksource/timer-cadence-ttc.c index 32daaac9b132..f8fcb1a4bdd0 100644 --- a/drivers/clocksource/timer-cadence-ttc.c +++ b/drivers/clocksource/timer-cadence-ttc.c @@ -477,6 +477,13 @@ static int __init ttc_timer_probe(struct platform_device *pdev) u32 timer_width = 16; struct device_node *timer = pdev->dev.of_node; + /* + * If pwm-cells property is present in TTC node, + * it would be treated as PWM device. + */ + if (of_property_read_bool(timer, "#pwm-cells")) + return -ENODEV; + if (initialized) return 0;
TTC device can act either as clocksource/clockevent or PWM generator, it would be decided by pwm-cells property. TTC PWM feature would be supported through separate driver based on PWM framework. If pwm-cells property is present in TTC node, it would be treated as PWM device, and clocksource driver should just skip it. Signed-off-by: Mubin Sayyed <mubin.sayyed@amd.com> --- Changes for v2: - Added comment regarding pwm-cells property --- drivers/clocksource/timer-cadence-ttc.c | 7 +++++++ 1 file changed, 7 insertions(+)