Hi,
> -----Original Message-----
> From: Krzysztof Kozlowski <[email protected]>
> Sent: Wednesday, November 15, 2023 2:41 AM
> To: Sayyed, Mubin <[email protected]>;
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Simek, Michal
> <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-Xilinx)
> <[email protected]>; [email protected]
> 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 <[email protected]>
> > ---
> > 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/[email protected]/.
Thanks,
Mubin
>
> Best regards,
> Krzysztof
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/[email protected]/.
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.
Wrap your emails to mailing list discussion style.
Best regards,
Krzysztof
Hi Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <[email protected]>
> Sent: Wednesday, November 15, 2023 5:41 PM
> To: Sayyed, Mubin <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-Xilinx)
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>
> 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/[email protected]/.
>
> 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.
Thanks,
Mubin
>
> Wrap your emails to mailing list discussion style.
>
> Best regards,
> Krzysztof
On 24/11/2023 12:03, Sayyed, Mubin wrote:
> Hi Krzysztof,
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <[email protected]>
>> Sent: Wednesday, November 15, 2023 5:41 PM
>> To: Sayyed, Mubin <[email protected]>
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected]; git (AMD-Xilinx)
>> <[email protected]>; [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; Simek, Michal <[email protected]>
>> 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/[email protected]/.
>>
>> 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 <[email protected]>
>>> Sent: Wednesday, November 15, 2023 5:41 PM
>>> To: Sayyed, Mubin <[email protected]>
>>> Cc: [email protected]; [email protected];
>>> [email protected]; [email protected]; git (AMD-Xilinx)
>>> <[email protected]>; [email protected]; [email protected];
>>> [email protected]; [email protected];
>>> [email protected]; [email protected]; [email protected];
>>> [email protected]; Simek, Michal <[email protected]>
>>> 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/[email protected]/.
>>>
>>> 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 <[email protected]>
> Sent: Friday, November 24, 2023 5:06 PM
> To: Sayyed, Mubin <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-Xilinx)
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>
> 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 <[email protected]>
> >> Sent: Wednesday, November 15, 2023 5:41 PM
> >> To: Sayyed, Mubin <[email protected]>
> >> Cc: [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; git (AMD-Xilinx) <[email protected]>;
> >> [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; Simek, Michal <[email protected]>
> >> 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/[email protected]/.
> >>
> >> 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/[email protected]/.
>>>>
>>>> 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