All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
Cc: sean@mess.org, mchehab@kernel.org, robh+dt@kernel.org,
	khilman@baylibre.com, Neil Armstrong <narmstrong@baylibre.com>,
	jbrunet@baylibre.com, linux-media <linux-media@vger.kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, rockosov@gmail.com
Subject: Re: [PATCH v2 1/2] media: rc: meson-irblaster: document device tree bindings
Date: Thu, 8 Jul 2021 15:57:59 +0200	[thread overview]
Message-ID: <CAFBinCDOcR5t=6m5X6LnuA+XT4v9nMQnDdD_moOqzf5ffWt+4A@mail.gmail.com> (raw)
In-Reply-To: <20210708162051.13953369@192.168.1.3>

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

WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
Cc: sean@mess.org, mchehab@kernel.org, robh+dt@kernel.org,
	 khilman@baylibre.com, Neil Armstrong <narmstrong@baylibre.com>,
	jbrunet@baylibre.com,  linux-media <linux-media@vger.kernel.org>,
	devicetree@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-amlogic@lists.infradead.org, rockosov@gmail.com
Subject: Re: [PATCH v2 1/2] media: rc: meson-irblaster: document device tree bindings
Date: Thu, 8 Jul 2021 15:57:59 +0200	[thread overview]
Message-ID: <CAFBinCDOcR5t=6m5X6LnuA+XT4v9nMQnDdD_moOqzf5ffWt+4A@mail.gmail.com> (raw)
In-Reply-To: <20210708162051.13953369@192.168.1.3>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
Cc: sean@mess.org, mchehab@kernel.org, robh+dt@kernel.org,
	 khilman@baylibre.com, Neil Armstrong <narmstrong@baylibre.com>,
	jbrunet@baylibre.com,  linux-media <linux-media@vger.kernel.org>,
	devicetree@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-amlogic@lists.infradead.org, rockosov@gmail.com
Subject: Re: [PATCH v2 1/2] media: rc: meson-irblaster: document device tree bindings
Date: Thu, 8 Jul 2021 15:57:59 +0200	[thread overview]
Message-ID: <CAFBinCDOcR5t=6m5X6LnuA+XT4v9nMQnDdD_moOqzf5ffWt+4A@mail.gmail.com> (raw)
In-Reply-To: <20210708162051.13953369@192.168.1.3>

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

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2021-07-08 13:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 14:13 [PATCH v2 0/2] media: rc: add support for Amlogic Meson IR blaster Viktor Prutyanov
2021-07-07 14:13 ` Viktor Prutyanov
2021-07-07 14:13 ` Viktor Prutyanov
2021-07-07 14:13 ` [PATCH v2 1/2] media: rc: meson-irblaster: document device tree bindings Viktor Prutyanov
2021-07-07 14:13   ` Viktor Prutyanov
2021-07-07 14:13   ` Viktor Prutyanov
2021-07-08 13:09   ` Martin Blumenstingl
2021-07-08 13:09     ` Martin Blumenstingl
2021-07-08 13:09     ` Martin Blumenstingl
2021-07-08 13:20     ` Viktor Prutyanov
2021-07-08 13:20       ` Viktor Prutyanov
2021-07-08 13:20       ` Viktor Prutyanov
2021-07-08 13:57       ` Martin Blumenstingl [this message]
2021-07-08 13:57         ` Martin Blumenstingl
2021-07-08 13:57         ` Martin Blumenstingl
2021-07-07 14:13 ` [PATCH v2 2/2] media: rc: introduce Meson IR blaster driver Viktor Prutyanov
2021-07-07 14:13   ` Viktor Prutyanov
2021-07-07 14:13   ` Viktor Prutyanov
2021-07-07 14:29   ` Neil Armstrong
2021-07-07 14:29     ` Neil Armstrong
2021-07-07 14:29     ` Neil Armstrong
2021-07-07 15:11     ` Viktor Prutyanov
2021-07-07 15:11       ` Viktor Prutyanov
2021-07-07 15:11       ` Viktor Prutyanov
2021-07-07 17:18   ` [PATCH] fixup! " Viktor Prutyanov
2021-07-07 17:18     ` Viktor Prutyanov
2021-07-07 17:18     ` Viktor Prutyanov
2021-07-07 17:24   ` [PATCH v2 2/2] " kernel test robot
2021-07-07 17:24     ` kernel test robot
2021-07-08 10:16   ` Sean Young
2021-07-08 10:16     ` Sean Young
2021-07-08 10:16     ` Sean Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFBinCDOcR5t=6m5X6LnuA+XT4v9nMQnDdD_moOqzf5ffWt+4A@mail.gmail.com' \
    --to=martin.blumenstingl@googlemail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=rockosov@gmail.com \
    --cc=sean@mess.org \
    --cc=viktor.prutyanov@phystech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.