lkml.org 
[lkml]   [2021]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 1/2] media: rc: meson-irblaster: document device tree bindings
Hi Viktor,

On Thu, Jul 8, 2021 at 3:20 PM Viktor Prutyanov
<viktor.prutyanov@phystech.edu> wrote:
[...]
> > > + mod-clock:
> > > + maxItems: 1
> > in the change-log for this patch you mentioned that mod-clock is
> > updated as well I think that mod-clock (as a whole property) should
> > only be added if it's an external input to the IR blaster IP block
>
> There are 2 clocks connected to blaster module, and mod-clock is just a
> selector between them. Meson IR blaster driver should choose one of the
> modulation clocks. If not through a property, then how to do it?
It depends on what the requirement for this clock is
I'll give you some examples as I am not sure about the inner workings
of the IR blaster - in hope that you'll be able to make a conclusion
for yourself.

drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c:
If Ethernet is configured into RGMII mode we need to configure a clock
tree (which consists of a mux to select between two different input
clocks, a fixed divider, a configurable divider and a gate).
The output clock rate must be 125MHz (or on SoCs which don't support
this directly then "as close as possible").
In this driver the clocks (and their hierarchy) are modelled using the
common clock framework so in the end we can conveniently use
clk_set_rate(dwmac->rgmii_tx_clk, 125 * 1000 * 1000)

drivers/mmc/host/meson-mx-sdio.c:
During initialization we need to inform the MMC subsystem of the
minimum and maximum supported clocks - this is done in
meson_mx_mmc_add_host().
The actual clock rate in the end depends on the SD/MMC card and it's
passed down to use from the MMC subsystem.
We then use clk_set_rate() in meson_mx_mmc_set_ios() to set the clock
rate closest to what has been requested by the MMC subsystem.
The IP block for this controller does not contain a mux but a
fixed-divider as well as a configurable divider - both are modelled
using the common clock framework.

Based on my understanding of the IR blaster description in the
datasheet that IP uses:
- fixed divider clock: xtal / 3
- fixed divider clock or a fixed rate clock (it's hard to tell as all
Amlogic boards I have use a 24MHz crystal): 1MHz (1uS)
- fixed divider clock or a fixed rate clock (it's hard to tell as all
Amlogic boards I have use a 24MHz crystal): 100kHz (10uS)
- clk81
- a mux to choose between the four above clocks
- a configurable divider (SLOW_CLOCK_DIV)
- possibly a gate clock (bit 0 of IR_BLASTER_CNTL0 called ENABLE)

If you only care about one specific clock setting (let's say the 1MHz/1uS).
Then you can either hard-code the values and register initialization
in the driver.
The mod-clock property is not needed in this case.

If the desired clock rate however changes (for example with the IR
protocol) you can model the fixed dividers, fixed rate/divider clocks
and mux using the common clock framework (similar to how it's done in
dwmac-meson8b.c).
Then you need to calculate the desired clock rate and finally use
clk_set_rate(irb->clock, desired_clk_rate_hz);
The mod-clock property is not needed in this case.


Best regards,
Martin

\
 
 \ /
  Last update: 2021-07-08 15:58    [W:0.076 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site