[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPtuhThQRS1=CFQuMe2tYjy00hXVbyt7WCL=YYHEokAscHoeXQ@mail.gmail.com>
Date: Thu, 14 Aug 2014 08:54:52 -0700
From: Mike Turquette <mturquette@...aro.org>
To: Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc: Boris BREZILLON <boris.brezillon@...e-electrons.com>,
Stephen Warren <swarren@...dotorg.org>,
Tomasz Figa <t.figa@...sung.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
rabin@....in, Thierry Reding <thierry.reding@...il.com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 0/6] Per-user clock constraints
On Thu, Aug 14, 2014 at 5:07 AM, Tomeu Vizoso
<tomeu.vizoso@...labora.com> wrote:
> On 08/13/2014 11:46 AM, Boris BREZILLON wrote:
>>
>> Hi Tomeu,
>>
>> Sorry for the late reply.
>>
>> On Wed, 6 Aug 2014 15:56:03 +0200
>> Tomeu Vizoso <tomeu.vizoso@...labora.com> wrote:
>>
>>> Hi,
>>>
>>> in this v5 of the patchset I have just moved the storage of the clock
>>> constraints to the struct clk, as suggested by Stephen. Follows the original
>>> cover letter blurb:
>>>
>>> I'm retaking Rabin's patches [0] for splitting the clk API in two: one
>>> API for
>>> clk consumers and another for providers. The consumer API uses a clk
>>> structure
>>> that just keeps track of the consumer and has a reference to the actual
>>> clk_core struct, which is used internally.
>>>
>>> I have kept a patch from Rabin that aims to aid in debugging nested
>>> enable/disable calls, though my personal aim is to allow more than one
>>> consumer
>>> to influence the final, effective frequency rate. For now this is limited
>>> to
>>> setting floor and ceiling constraints, with the short-term aim of
>>> allowing
>>> devfreq and thermal drivers to set floor and ceiling frequencies on the
>>> memory
>>> clock, respectively.
>>>
>>> For those functions in the consumer clk API that were called from
>>> providers, I
>>> have added variants to clk-provider.h that are the same only that accept
>>> a
>>> clk_core instead. These functions are prefixed with clk_provider_.
>>>
>>> Patch 1/6 just adds a bunch of defines with the goal of having all the
>>> renames
>>> in their own commit while preserving git-bisectability, with patch 3/6
>>> containing the rename itself as generated by the Coccinelle script in
>>> [1].
>>> Patch 2/6 is needed because sound/soc/mxs/mxs-saif.c calls both the
>>> consumer
>>> and the provider API. The actual implementation of the API split comes in
>>> patch
>>> 4/6. I will be happy to organize the refactoring differently if anybody
>>> has a
>>> better idea.
>>>
>>> Patch 5/6 warns when there's an unbalanced usage of the enable and
>>> disable
>>> APIs, and patch 6/6 adds the API for setting floor and ceiling
>>> frequencies, per
>>> consumer.
>>
>>
>> I tested your patch series on an at91 platform (sama5d3), and it works
>> as expected, but I had to fix some conflicts when applying your patches
>> on clk-next, and then got a few errors at compile time.
>>
>> Anyway here is my branch with all those conflicts resolved: [1]. The
>> last commit [2] fixes the build errors (I'll let you squash/split the
>> changes as you wish).
>
>
> Thanks a lot, it has saved me quite some time.
Ok, that's great. I also applied v6 against Linus' master and
linux-next from today, August 14. Both of them have the same conflicts
in arch/arm code, namely i.MX, OMAP2+ and Kirkwood. Could this series
be refreshed against -rc1 after it comes out? That should be the last
rebase hurdle for a while.
Regards,
Mike
>
> I have just re-run my coccinelle script and added the new file to the input
> file list. Will be sending v6 now.
>
> Regards,
>
> Tomeu
>
>
>> Best Regards,
>>
>> Boris
>>
>> [1]https://github.com/bbrezillon/linux-at91/tree/per-clk-contraints
>>
>> [2]https://github.com/bbrezillon/linux-at91/commit/d366c37dcfa5f06de3e27fc3c2807017bece9a2f
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists