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
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
> > >
Hi Mark,
On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote:
> On Thu, Jul 13, 2017 at 04:12:56PM +0200, Maxime Ripard 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
> >
On Thu, Jul 13, 2017 at 04:12:56PM +0200, Maxime Ripard 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?
si
regmap_init_mmio_clk allows to specify a clock that needs to be enabled
while accessing the registers.
However, that clock is retrieved through its clock ID, which means it will
lookup that clock based on the current device that registers the regmap,
and, in the DT case, will only look in that dev
5 matches
Mail list logo