Message ID | 1568123236-767-1-git-send-email-claudiu.beznea@microchip.com (mailing list archive) |
---|---|
Headers | show |
Series | add support for clocksource/clockevent DT selection | expand |
Hi Claudiu, On 10/09/2019 15:47, Claudiu Beznea wrote: > Hi, > > This series adds support to permit the selection of clocksource/clockevent > via DT. Thanks for the proposal and taking care of making some progress on this. I just wanted to let you know I've been traveling but the series is in my pipe and I did not forget it. I'll comment it next week. -- Daniel
On 25.09.2019 20:19, Daniel Lezcano wrote: > External E-Mail > > > Hi Claudiu, > > On 10/09/2019 15:47, Claudiu Beznea wrote: >> Hi, >> >> This series adds support to permit the selection of clocksource/clockevent >> via DT. > > Thanks for the proposal and taking care of making some progress on this. > > I just wanted to let you know I've been traveling but the series is in > my pipe and I did not forget it. I'll comment it next week. Hi Daniel, No problem. Thank you for letting me know. Claudiu > > -- Daniel > >
Hi Daniel, Taking into account that Rob doesn't agree with the solution proposed in this series do you think there is a chance to merge this driver as is? If you have other suggestion I am open to try it. Thank you, Claudiu Beznea On 26.09.2019 11:42, Claudiu Beznea wrote: > > > On 25.09.2019 20:19, Daniel Lezcano wrote: >> External E-Mail >> >> >> Hi Claudiu, >> >> On 10/09/2019 15:47, Claudiu Beznea wrote: >>> Hi, >>> >>> This series adds support to permit the selection of clocksource/clockevent >>> via DT. >> >> Thanks for the proposal and taking care of making some progress on this. >> >> I just wanted to let you know I've been traveling but the series is in >> my pipe and I did not forget it. I'll comment it next week. > > Hi Daniel, > > No problem. Thank you for letting me know. > > Claudiu > >> >> -- Daniel >> >>
On 02.10.2019 16:35, Claudiu Beznea wrote: > Hi Daniel, > > Taking into account that Rob doesn't agree with the solution proposed in > this series do you think there is a chance to merge this driver as is? Sorry, I was talking here about the driver at [1]. [1] https://lore.kernel.org/lkml/1552580772-8499-1-git-send-email-claudiu.beznea@microchip.com/ > > If you have other suggestion I am open to try it. > > Thank you, > Claudiu Beznea > > On 26.09.2019 11:42, Claudiu Beznea wrote: >> >> >> On 25.09.2019 20:19, Daniel Lezcano wrote: >>> External E-Mail >>> >>> >>> Hi Claudiu, >>> >>> On 10/09/2019 15:47, Claudiu Beznea wrote: >>>> Hi, >>>> >>>> This series adds support to permit the selection of clocksource/clockevent >>>> via DT. >>> >>> Thanks for the proposal and taking care of making some progress on this. >>> >>> I just wanted to let you know I've been traveling but the series is in >>> my pipe and I did not forget it. I'll comment it next week. >> >> Hi Daniel, >> >> No problem. Thank you for letting me know. >> >> Claudiu >> >>> >>> -- Daniel >>> >>>
Hi Claudiu, sorry for the delay, I was OoO again. On 03/10/2019 12:43, Claudiu.Beznea@microchip.com wrote: > > > On 02.10.2019 16:35, Claudiu Beznea wrote: >> Hi Daniel, >> >> Taking into account that Rob doesn't agree with the solution proposed in >> this series do you think there is a chance to merge this driver as is? > > Sorry, I was talking here about the driver at [1]. > > [1] https://lore.kernel.org/lkml/1552580772-8499-1-git-send-email-claudiu.beznea@microchip.com/ Damn! 7 months old. I'm truly sorry we do not have progress on this. Let fix this once and for all. In the driver: ret = of_property_read_u32(node, "clock-frequency", &freq); It is unclear how is used this property. It should be the frequency driving the timer, but can we get from a clk_get_rate() and a fixed divider?
Hi Daniel, On 13.10.2019 21:16, Daniel Lezcano wrote: > Hi Claudiu, > > sorry for the delay, I was OoO again. No problem, thank you for your reply. > > On 03/10/2019 12:43, Claudiu.Beznea@microchip.com wrote: >> >> >> On 02.10.2019 16:35, Claudiu Beznea wrote: >>> Hi Daniel, >>> >>> Taking into account that Rob doesn't agree with the solution proposed in >>> this series do you think there is a chance to merge this driver as is? >> >> Sorry, I was talking here about the driver at [1]. >> >> [1] https://lore.kernel.org/lkml/1552580772-8499-1-git-send-email-claudiu.beznea@microchip.com/ > > Damn! 7 months old. I'm truly sorry we do not have progress on this. Let > fix this once and for all. > > In the driver: > > ret = of_property_read_u32(node, "clock-frequency", &freq); > > It is unclear how is used this property. It should be the frequency > driving the timer, but can we get from a clk_get_rate() and a fixed divider? > The timer could be driven by 2 clock sources, one is called peripheral clock and is the clock that is also driving the IP itself, and one is called generic clock (this could drive only the timer itself) and should be at least 3 times lower than the peripheral clock. We could choose the clock driving the timer by setting the PIT64B_MR.SGCLK bit (0 - means the timer itself is driven by peripheral clock, 1 - means the timer is driven by the generic clock). The timer clock source could be divided by MR.PRES + 1. So, I used the clock-frequency DT binding to let user choose the timer's frequency. Based on the value provided via this DT binding the best clock source and prescaler is chosen via mchp_pit64b_pres_prepare() function. As the datasheet for the product that is using this IP is open now, I'm inserting here a link to it [1]. Thank you, Claudiu Beznea [1] http://ww1.microchip.com/downloads/en/DeviceDoc/SAM9X60-Data-Sheet-DS60001579A.pdf >
Hi Claudiu, On 15/10/2019 11:23, Claudiu.Beznea@microchip.com wrote: [ ... ] > The timer clock source could be divided by MR.PRES + 1. > > So, I used the clock-frequency DT binding to let user choose the timer's > frequency. Based on the value provided via this DT binding the best clock > source and prescaler is chosen via mchp_pit64b_pres_prepare() function. I'm willing to take the driver but I doubt the purpose of the clock-frequency is to let the user choose the frequency. [ ... ]
Hi Daniel, On 18.10.2019 23:24, Daniel Lezcano wrote: > Hi Claudiu, > > On 15/10/2019 11:23, Claudiu.Beznea@microchip.com wrote: > > [ ... ] > >> The timer clock source could be divided by MR.PRES + 1. >> >> So, I used the clock-frequency DT binding to let user choose the timer's >> frequency. Based on the value provided via this DT binding the best clock >> source and prescaler is chosen via mchp_pit64b_pres_prepare() function. > > I'm willing to take the driver but I doubt the purpose of the > clock-frequency is to let the user choose the frequency. > I found this approach in the following already integrated drivers: drivers/clocksource/armv7m_systick.c drivers/clocksource/bcm2835_timer.c drivers/clocksource/bcm_kona_timer.c drivers/clocksource/mips-gic-timer.c drivers/clocksource/mps2-timer.c drivers/clocksource/timer-qcom.c drivers/clocksource/arm_arch_timer.c Looking through the documentation of these, most of them document this DT property as the frequency of the clock that drivers the timer, but none of them seems to have some IP internal dividers so that the timer to tick at different frequency than the clock that feeds the IP. From the documentation of the above drivers; drivers/clocksource/armv7m_systick.c - clock-frequency : The rate in HZ in input of the ARM SysTick drivers/clocksource/bcm2835_timer.c - clock-frequency : The frequency of the clock that drives the counter, in Hz. drivers/clocksource/bcm_kona_timer.c - clock-frequency: frequency that the clock operates drivers/clocksource/mips-gic-timer.c clock-frequency : Clock frequency at which the GIC timers operate. drivers/clocksource/mps2-timer.c - clock-frequency : The rate in HZ in input of the ARM MPS2 timer drivers/clocksource/timer-qcom.c - clock-frequency : The frequency of the debug timer and the general purpose timer(s) in Hz in that order. This is why I also chose this DT bindings. If you want I can stick to a fixed frequency hard coded in the driver. Please let me know if this would be OK for you. Thank you, Claudiu Beznea > > [ ... ] > >
On 21/10/2019 10:58, Claudiu.Beznea@microchip.com wrote: > Hi Daniel, > > On 18.10.2019 23:24, Daniel Lezcano wrote: >> Hi Claudiu, >> >> On 15/10/2019 11:23, Claudiu.Beznea@microchip.com wrote: >> >> [ ... ] >> >>> The timer clock source could be divided by MR.PRES + 1. >>> >>> So, I used the clock-frequency DT binding to let user choose the timer's >>> frequency. Based on the value provided via this DT binding the best clock >>> source and prescaler is chosen via mchp_pit64b_pres_prepare() function. >> >> I'm willing to take the driver but I doubt the purpose of the >> clock-frequency is to let the user choose the frequency. >> > > I found this approach in the following already integrated drivers: > drivers/clocksource/armv7m_systick.c > drivers/clocksource/bcm2835_timer.c > drivers/clocksource/bcm_kona_timer.c > drivers/clocksource/mips-gic-timer.c > drivers/clocksource/mps2-timer.c > drivers/clocksource/timer-qcom.c > drivers/clocksource/arm_arch_timer.c > > Looking through the documentation of these, most of them document this DT > property as the frequency of the clock that drivers the timer, but none of > them seems to have some IP internal dividers so that the timer to tick at > different frequency than the clock that feeds the IP. From the > documentation of the above drivers; > drivers/clocksource/armv7m_systick.c > - clock-frequency : The rate in HZ in input of the ARM SysTick > > drivers/clocksource/bcm2835_timer.c > - clock-frequency : The frequency of the clock that drives the counter, in > Hz. > drivers/clocksource/bcm_kona_timer.c > - clock-frequency: frequency that the clock operates > > drivers/clocksource/mips-gic-timer.c > clock-frequency : Clock frequency at which the GIC timers operate. > drivers/clocksource/mps2-timer.c > - clock-frequency : The rate in HZ in input of the ARM MPS2 timer > > drivers/clocksource/timer-qcom.c > - clock-frequency : The frequency of the debug timer and the general > purpose > timer(s) in Hz in that order. > > > This is why I also chose this DT bindings. > > If you want I can stick to a fixed frequency hard coded in the driver. > Please let me know if this would be OK for you. Yes, the clock-frequency is used to specify the frequency when the information can not be retrieved from the clock. The goal is not to specify a frequency and compute from there a prescalar value. Hardcoding the frequency is fine or hardcode the divider and compute the frequency from the clock rate.