this convention is suggested:
PLT_CLK[2:0] - Camera
PLT_CLK[3] - Audio Codec
PLT_CLK[4] -
PLT_CLK[5] - COMMs
By the way, would I suggest to use same prefix as provider, i.e.
pmc_atom_plt_clk_%d ?
I tried this suggestion and it doesn't work unfortunately. It looks like
the struct cl
On Thu, Dec 22, 2016 at 3:07 AM, Pierre-Louis Bossart
wrote:
> On 12/21/16 5:05 PM, Stephen Boyd wrote:
>>> The name pmc_plt_clk_ follows the data sheet specification, where
>>> this convention is suggested:
>>> PLT_CLK[2:0] - Camera
>>> PLT_CLK[3] - Audio Codec
>>> PLT_CLK[4] -
>>> PLT_C
On 12/21/2016 05:07 PM, Pierre-Louis Bossart wrote:
> On 12/21/16 5:05 PM, Stephen Boyd wrote:
>>
>> Ok, by clkdev design if a device is passed but there isn't a
>> match in the lookup table it allows it to match based solely on
>> the connection id. Given that the connection id is globally
>> uniq
On 12/21/16 5:05 PM, Stephen Boyd wrote:
On 12/19, Pierre-Louis Bossart wrote:
On 12/17/16 7:57 AM, Andy Shevchenko wrote:
On Sat, Dec 17, 2016 at 3:33 AM, Stephen Boyd wrote:
On 12/15, Pierre-Louis Bossart wrote:
Clients use devm_clk_get() with a "pmc_plt_clk_"
argument.
This is the pro
On 12/19, Pierre-Louis Bossart wrote:
> On 12/17/16 7:57 AM, Andy Shevchenko wrote:
> >On Sat, Dec 17, 2016 at 3:33 AM, Stephen Boyd wrote:
> >>On 12/15, Pierre-Louis Bossart wrote:
> >
> >>>Clients use devm_clk_get() with a "pmc_plt_clk_"
> >>>argument.
> >>
> >>This is the problem. Clients shoul
On 12/17/16 7:57 AM, Andy Shevchenko wrote:
On Sat, Dec 17, 2016 at 3:33 AM, Stephen Boyd wrote:
On 12/15, Pierre-Louis Bossart wrote:
Clients use devm_clk_get() with a "pmc_plt_clk_"
argument.
This is the problem. Clients should be calling clk_get() like:
clk_get(dev, "signal nam
On Fri, Dec 16, 2016 at 10:36:07AM -0800, Darren Hart wrote:
> My understanding is include/linux should be more generic, rather than platform
> specific headers. So while platform_data may refer specifically to the
> platform
> bus drivers, it's the closest thing we have to include/platform, whic
On Sat, Dec 17, 2016 at 3:33 AM, Stephen Boyd wrote:
> On 12/15, Pierre-Louis Bossart wrote:
>>Clients use devm_clk_get() with a "pmc_plt_clk_"
>> argument.
>
> This is the problem. Clients should be calling clk_get() like:
>
> clk_get(dev, "signal name in datasheet")
>
> where the first
On 12/15, Pierre-Louis Bossart wrote:
> I am not sure I understand this last comment.
> init.name is not a constant, it's made of the "pmc_plt_clk_" string
> concatenated with an id which directly maps to which hardware clock
> is registered.
That's all fine. We need globally unique strings for cl
On Sat, Dec 17, 2016 at 12:29:41AM +0200, Andy Shevchenko wrote:
> On Fri, Dec 16, 2016 at 9:19 PM, Darren Hart wrote:
> > On Fri, Dec 16, 2016 at 08:49:13PM +0200, Andy Shevchenko wrote:
> >> On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart wrote:
> >> > On Tue, Dec 13, 2016 at 02:26:21AM +0200, And
On Fri, Dec 16, 2016 at 9:19 PM, Darren Hart wrote:
> On Fri, Dec 16, 2016 at 08:49:13PM +0200, Andy Shevchenko wrote:
>> On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart wrote:
>> > On Tue, Dec 13, 2016 at 02:26:21AM +0200, Andy Shevchenko wrote:
>> >> On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis B
On Fri, Dec 16, 2016 at 08:49:13PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart wrote:
> > On Tue, Dec 13, 2016 at 02:26:21AM +0200, Andy Shevchenko wrote:
> >> On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
> >> wrote:
>
> >> For clock I would suggest incl
On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart wrote:
> On Tue, Dec 13, 2016 at 02:26:21AM +0200, Andy Shevchenko wrote:
>> On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
>> wrote:
>> For clock I would suggest include/linux/clk/ with x86_ prefix.
>> For the rest I have no strong opinion exc
On Tue, Dec 13, 2016 at 02:26:21AM +0200, Andy Shevchenko wrote:
> On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
> wrote:
> >
> >> Thanks for an update I will comment all the patches.
> >> Here we start.
> >
> >
> > Thanks Andy for the review. Two quick comments before going further in the
On 12/16/16 2:46 AM, Andy Shevchenko wrote:
On Fri, Dec 16, 2016 at 7:15 AM, Pierre-Louis Bossart
wrote:
Hi Stephen,
can you elaborate on the last comment?
Please don't do top posting.
devm_kasprintf()
Please no.
That's why I used modal verb "might" instead of "would".
It's all local
On Fri, Dec 16, 2016 at 7:15 AM, Pierre-Louis Bossart
wrote:
> Hi Stephen,
>
> can you elaborate on the last comment?
Please don't do top posting.
>>> devm_kasprintf()
>>
>> Please no.
That's why I used modal verb "might" instead of "would".
>> It's all local to this function, devm isn't helpi
Hi Stephen,
can you elaborate on the last comment?
thanks,
-Pierre
On 12/13/2016 05:25 PM, Stephen Boyd wrote:
+ void __iomem *base,
+ const char **parent_names,
+ int num_pare
On 12/13, Andy Shevchenko wrote:
> On Fri, Dec 9, 2016 at 8:01 PM, Irina Tirdea wrote:
>
> > --- a/drivers/clk/x86/Makefile
> > +++ b/drivers/clk/x86/Makefile
> > @@ -1,2 +1,5 @@
> > clk-x86-lpss-objs := clk-lpt.o
> > obj-$(CONFIG_X86_INTEL_LPSS) += clk-x86-lpss.o
>
> > +ifeq ($
On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
wrote:
>
>>> +#include
>
>
> This was a suggestion of Darren Hart in agreement with Thomas Gleixner.
> see
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-October/113936.html
>
> Darren, did we get your proposal right?
>
>> Is it i
On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
wrote:
>
>> Thanks for an update I will comment all the patches.
>> Here we start.
>
>
> Thanks Andy for the review. Two quick comments before going further in the
> details later.
>
>>
>>> The BayTrail and CherryTrail platforms provide platfor
Thanks for an update I will comment all the patches.
Here we start.
Thanks Andy for the review. Two quick comments before going further in
the details later.
The BayTrail and CherryTrail platforms provide platform clocks
through their Power Management Controller (PMC).
The SoC supports
On Fri, Dec 9, 2016 at 8:01 PM, Irina Tirdea wrote:
Thanks for an update I will comment all the patches.
Here we start.
> The BayTrail and CherryTrail platforms provide platform clocks
> through their Power Management Controller (PMC).
>
> The SoC supports up to 6 clocks (PMC_PLT_CLK[5:0]) with
The BayTrail and CherryTrail platforms provide platform clocks
through their Power Management Controller (PMC).
The SoC supports up to 6 clocks (PMC_PLT_CLK[5:0]) with a
frequency of either 19.2 MHz (PLL) or 25 MHz (XTAL) for BayTrail
and a frequency of 19.2 MHz (XTAL) for CherryTrail. These clock
23 matches
Mail list logo
