Le 18/06/2015 17:25, Boris Brezillon a écrit :
> Hi Nicolas,
Thanks for your review Boris. I'll address your remarks by sending
another revision of this series in several days...
Bye,
> I haven't run checkpatch on your patch, but there seems to be a few
> things to fix ;-).
>
> On Wed, 17 Jun 2
Hi Nicolas,
I haven't run checkpatch on your patch, but there seems to be a few
things to fix ;-).
On Wed, 17 Jun 2015 15:23:29 +0200
Nicolas Ferre wrote:
> +
> +static long clk_generated_determine_rate(struct clk_hw *hw,
> + unsigned long rate,
> +
Hi Alexandre,
You know, I can't read Nicolas' mind, so I couldn't say from the patch
itself that it was not a silly mistake.
I also can't look into the future. I can however check lkml (at least
the few weeks of lkml I keep at hand) and see whether there's another
patch pending that would allow t
Hi Nicolas,
On Thu, 2015-06-18 at 14:40 +0200, Nicolas Ferre wrote:
> I have several options here:
>
> 1/ I send the clock patch early and benefit from early review and a
> comfortable landing strip
>
> 2/ I send the SoC early and have the very same remark concerning the
> "+ select HAVE_A
Le 18/06/2015 14:59, Alexandre Belloni a écrit :
> On 18/06/2015 at 09:54:50 +0200, Paul Bolle wrote :
>>> I'd like though that this matter of fact doesn't block this piece of
>>> code from being reviewed or even better merged in order to ease this new
>>> SoC landing...
>>
>> The other side of tha
On 18/06/2015 at 09:54:50 +0200, Paul Bolle wrote :
> > I'd like though that this matter of fact doesn't block this piece of
> > code from being reviewed or even better merged in order to ease this new
> > SoC landing...
>
> The other side of that is that the sama5d2 might never make it, or take
>
Le 18/06/2015 09:54, Paul Bolle a écrit :
> Hi Nicolas,
>
> On Thu, 2015-06-18 at 09:40 +0200, Nicolas Ferre wrote:
>> I am in the process, with my colleagues, of building bricks for our
>> upcoming SoC the sama5d2. So, the basic support for this chip will come
>> in the next weeks and will select
Hi Nicolas,
On Thu, 2015-06-18 at 09:40 +0200, Nicolas Ferre wrote:
> I am in the process, with my colleagues, of building bricks for our
> upcoming SoC the sama5d2. So, the basic support for this chip will come
> in the next weeks and will select this Kconfig option.
Perhaps that could be added,
On Thu, 2015-06-18 at 09:33 +0200, Boris Brezillon wrote:
> I guess it will be selected by platforms embedding such clks. We just
> have to wait for those platform to reach mainline ;-).
So what's the point of this patch at this moment?
Paul Bolle
--
To unsubscribe from this list: send the lin
Le 18/06/2015 09:33, Boris Brezillon a écrit :
> Hi Paul,
>
> On Thu, 18 Jun 2015 09:12:36 +0200
> Paul Bolle wrote:
>
>> On Wed, 2015-06-17 at 15:23 +0200, Nicolas Ferre wrote:
>>
>>> --- a/arch/arm/mach-at91/Kconfig
>>> +++ b/arch/arm/mach-at91/Kconfig
>>
>>> +config HAVE_AT91_GENERATED
>>>
Hi Paul,
On Thu, 18 Jun 2015 09:12:36 +0200
Paul Bolle wrote:
> On Wed, 2015-06-17 at 15:23 +0200, Nicolas Ferre wrote:
>
> > --- a/arch/arm/mach-at91/Kconfig
> > +++ b/arch/arm/mach-at91/Kconfig
>
> > +config HAVE_AT91_GENERATED
> > + bool
>
> This will always be 'n'.
>
> > --- a/drive
On Wed, 2015-06-17 at 15:23 +0200, Nicolas Ferre wrote:
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> +config HAVE_AT91_GENERATED
> + bool
This will always be 'n'.
> --- a/drivers/clk/at91/Makefile
> +++ b/drivers/clk/at91/Makefile
> +obj-$(CONFIG_HAVE_AT91_GEN
Add a new type of clocks that can be provided to a peripheral.
In addition to the peripheral clock, this new clock that can use several
input clocks as parents can generate divided rates.
This would allow a peripheral to have finer grained clocks for generating
a baud rate, clocking an asynchronous
13 matches
Mail list logo
