[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170718132147.uzexelksygjeasmw@sirena.org.uk>
Date: Tue, 18 Jul 2017 14:21:47 +0100
From: Mark Brown <broonie@...nel.org>
To: Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Chen-Yu Tsai <wens@...e.org>, dri-devel@...ts.freedesktop.org,
Daniel Vetter <daniel.vetter@...el.com>,
David Airlie <airlied@...ux.ie>,
Mark Rutland <mark.rutland@....com>,
Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Subject: Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock
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?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists