[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFBinCDzNw6nV3oBJs6C0sssW61GERBXq39DCM22BT9zS8M31A@mail.gmail.com>
Date: Mon, 27 Apr 2020 18:23:49 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Jerome Brunet <jbrunet@...libre.com>
Cc: linux-amlogic@...ts.infradead.org, devicetree@...r.kernel.org,
linux-mmc@...r.kernel.org, ulf.hansson@...aro.org,
robh+dt@...nel.org, mark.rutland@....com, jianxin.pan@...ogic.com,
linux-kernel@...r.kernel.org, yinxin_1989@...yun.com,
linux-arm-kernel@...ts.infradead.org, lnykww@...il.com
Subject: Re: [PATCH v5 0/3] Amlogic 32-bit Meson SoC SDHC MMC controller driver
Hi Jerome,
On Mon, Apr 27, 2020 at 10:56 AM Jerome Brunet <jbrunet@...libre.com> wrote:
[...]
> > Changes since v3 at [3]:
> > - split the clock bits into a separate clock controller driver because
> > of two reasons: 1) it keeps the MMC controller driver mostly clean of
> > the clock bits
>
> If the register is in the MMC controller register space and the MMC
> driver is the driver using these clocks, it is where the clocks belong.
> I don't get why it could be an issue ?
>
> Is the clock block is shared with another device, like on the Gx family ?
no, it is not shared with another device (to my knowledge).
> > 2) the pure clock controller can use
> > devm_clk_hw_register() (instead of devm_clk_register(), which is
> > deprecated) and the MMC controller can act as a pure clock consumer.
>
> Why can't you use devm_clk_hw_register in an MMC driver ?
> Unless I missed something, it is provided by clk-provider.h, which can be
> included by any driver.
indeed, I could use devm_clk_hw_register in the MMC driver.
Ulfs concern was that a lot of code was needed for managing the clocks
and I agree with him. so this is my way of keeping those details away
from the MMC driver and have two separate drivers which are better to
understand overall.
Martin
Powered by blists - more mailing lists