Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1690264 > unrolled thread

Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock Mark Brown <broonie@kernel.org> - 2017-07-18 15:30 +0200
    Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-20 16:50 +0200

#1690264 — Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 17, 2017 at 11:01:07AM +0200, Maxime Ripard wrote:
> On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote:

> > > This might be problematic if the clock to enable is stored in another node.
> > > Let's add a function that allows to attach a clock that has already been
> > > retrieved to a regmap in order to fix this.

> > What is the use case for this?

> This is useful when the clock you want to be handled by the regmap is
> not described in the device node that probed the driver, but one of
> its subnode, or an another node entirely.

> We're in the latter case, where we have two controllers in the DT, but
> are driven by the same driver. We'll create two regmaps, but one will
> not have the proper of_node used to retrieve the clock.

I'm sorry but I'm still not seeing why you're doing this.  Can you be
more concrete please?

[toc] | [next] | [standalone]

#1692999

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 18, 2017 at 02:21:47PM +0100, Mark Brown wrote:
> On Mon, Jul 17, 2017 at 11:01:07AM +0200, Maxime Ripard wrote:
> > On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote:
> 
> > > > This might be problematic if the clock to enable is stored in another node.
> > > > Let's add a function that allows to attach a clock that has already been
> > > > retrieved to a regmap in order to fix this.
> 
> > > What is the use case for this?
> 
> > This is useful when the clock you want to be handled by the regmap is
> > not described in the device node that probed the driver, but one of
> > its subnode, or an another node entirely.
> 
> > We're in the latter case, where we have two controllers in the DT, but
> > are driven by the same driver. We'll create two regmaps, but one will
> > not have the proper of_node used to retrieve the clock.
> 
> I'm sorry but I'm still not seeing why you're doing this.  Can you be
> more concrete please?

We have two devices needed to bring DSI: the DSI controller itself and
its associated PHY.

The PHY configuration cannot be done through a framework because it
requires more information than the various phy frameworks allow to
pass through to the driver.

Therefore, we have a single driver, attached to the DSI controller,
which handles both the PHY and the DSI controller.

Both the PHY and the DSI controller are separate device, with
different memory regions. Therefore, we need to create two regmaps,
with clocks attached to them.

However, the default clock retrieval mechanism doesn't work for the
phy regmap, since only the DSI controller device of_node is
considered, while its clock is stored in a separate node.

I hope it's clearer,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web