Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Paul Cercueil]

Le 2018-03-31 10:10, Daniel Lezcano a ÃcritÂ:
> On 29/03/2018 16:52, Paul Cercueil wrote:
> > Le mer. 28 mars 2018 Ã 18:25, Daniel Lezcano 
> > <daniel.lezcano@xxxxxxxxxx>
> > a Ãcrit :
> > > On 28/03/2018 17:15, Paul Cercueil wrote:
> > > > ÂLe 2018-03-24 07:26, Daniel Lezcano a Ãcrit :
> > > > > ÂOn 18/03/2018 00:29, Paul Cercueil wrote:
> > > > > > ÂThis driver will use the TCU (Timer Counter Unit) present on the
> > > > > > Ingenic
> > > > > > ÂJZ47xx SoCs to provide the kernel with a clocksource and timers.
> > > > >
> > > > > ÂPlease provide a more detailed description about the timer.
> > > >
> > > > ÂThere's a doc file for that :)
> > >
> > > Usually, when there is a new driver I ask for a description in the
> > > changelog for reference.
> > >
> > > > > ÂWhere is the clocksource ?
> > > >
> > > > ÂRight, there is no clocksource, just timers.
> > > >
> > > > > ÂI don't see the point of using channel idx and pwm checking here.
> > > > >
> > > > > ÂThere is one clockevent, why create multiple channels ? Can't you
> > > > > stick
> > > > > Âto the usual init routine for a timer.
> > > >
> > > > ÂSo the idea is that we use all the TCU channels that won't be used
> > > > for PWM
> > > > Âas timers. Hence the PWM checking. Why is this bad?
> > >
> > > It is not bad but arguable. By checking the channels used by the pwm 
> > > in
> > > the code, you introduce an adherence between two subsystems even if 
> > > it
> > > is just related to the DT parsing part.
> > >
> > > As it is not needed to have more than one timer in the time framework
> > > (at least with the same characteristics), the pwm channels check is
> > > pointless. We can assume the author of the DT file is smart enough to
> > > prevent conflicts and define a pwm and a timer properly instead of
> > > adding more code complexity.
> > >
> > > In addition, simplifying the code will allow you to use the timer-of
> > > code and reduce very significantly the init function.
> >
> > That's what I had in my V1 and V2, my DT node for the timer-ingenic 
> > driver
> > had a "timers" property (e.g. "timers = <4 5>;") to select the 
> > channels
> > that
> > should be used as timers. Then Rob told me I shouldn't do that, and 
> > instead
> > detect the channels that will be used for PWM.
>
> [ ... ]
>
> How do you specify the channels used for PWM ?

To detect the channels that will be used as PWM I parse the whole 
devicetree
searching for "pwms" properties; check that the PWM handle is for our 
TCU PWM
driver; then read the PWM number from there.

Of course it's hackish, and it only works for devicetree. I preferred 
the
method with the "timers" property.

> > > > > > Â+config INGENIC_TIMER
> > > > > > Â+ÂÂÂ bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
> > > > > > Â+ÂÂÂ depends on MACH_INGENIC || COMPILE_TEST
> > > > >
> > > > > Âbool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if
> > > > > COMPILE_TEST
> > > > >
> > > > > ÂRemove the depends MACH_INGENIC.
> > > >
> > > > ÂThis driver is not useful on anything else than Ingenic SoCs, why
> > > > should I
> > > > Âremove MACH_INGENIC then?
> > >
> > > For COMPILE_TEST on x86.
> >
> > Well that's a logical OR right here, so it will work...
>
> Right, I missed the second part of the condition. For consistency
> reason, we don't add a dependency on the platform. The platform will
> select it. Look the other timer options and you will see there is no
> MACH deps. I'm trying consolidating all these options to have same
> format and hopefully factor them out.

I'm all for factorisation, but what I dislike with not depending on
MACH_INGENIC, is that the driver now appears in the menuconfig for
every arch, even if it only applies to one MIPS SoC.

Regards,
-Paul