Hi Mike,
On Fri, 31 Jul 2015, Michael Turquette wrote:
> Quoting Paul Osmialowski (2015-07-30 14:40:48)
> > Hi Mike,
> >
> > I encountered some trouble while I tried to implement code fitting to DTS
> > that you proposed. SIM_CLKDIVx are SIM device registers, not MCG.
> > Therefore, in MCG de
Hi Mike,
I encountered some trouble while I tried to implement code fitting to DTS
that you proposed. SIM_CLKDIVx are SIM device registers, not MCG.
Therefore, in MCG device code I won't be able to figure out clock rate
for outputed clocks unles I try to access SIM registers from MCG driver -
Hi Mike,
My trouble is that now I'm dealing with two conradictory opinions on how
this driver should be written. The one you presented in your previous post
assumes that there will be a header file with defines shared between the
clock driver and DTS, also with clock gating details hidden behin
Hi Mike,
Thank you for spending time on this and pointing me into the right
direction. I'm wondering about going even further with it. Assuming that I
know everything about my board, I can skip run-time discovery phase (note
that the original driver was designed for other Kinetis-based boards t
Quoting Paul Osmialowski (2015-07-04 14:50:03)
> Hi Arnd,
>
> I'm attaching excerpt from Kinetis reference manual that may make
> situation clearer.
Hi Paul,
Can you please post the patch in the body of the email instead of an
attachment? It makes it easier to review. Another small nitpick is t
Hi Linus,
I had some discussion with an expert here and now I see drawbacks of using
struct for regs, I'll turn it into defines as you suggested.
On Wed, 15 Jul 2015, Paul Osmialowski wrote:
> Hi Linus,
>
> Thanks for all of your comments, I'll consider them during my works on the
> next iter
Hi Linus,
Thanks for all of your comments, I'll consider them during my works on the
next iteration. However, I have doubts about this one:
On Tue, 14 Jul 2015, Linus Walleij wrote:
> On Tue, Jun 30, 2015 at 2:27 PM, Paul Osmialowski wrote:
>
> > Based on K70P256M150SF3RM.pdf K70 Sub-Family R
On Tue, Jun 30, 2015 at 2:27 PM, Paul Osmialowski wrote:
> Based on K70P256M150SF3RM.pdf K70 Sub-Family Reference Manual, Rev. 3.
>
> Signed-off-by: Paul Osmialowski
(...)
> +struct kinetis_sim_regs {
> + u32 sopt1; /* System Options Register 1 */
> + u32 rsv0[1024];
> + u
Hi Guys,
Let me share with you one more approach. I moved clocks back to
sub-devices, so sharing the same resources (registers) is more obvious
again. I like it better than previous approach. Can you look at this,
please?
On Sat, 4 Jul 2015, Paul Osmialowski wrote:
Hi Arnd,
I'm attaching
On Friday 03 July 2015 00:08:27 Thomas Gleixner wrote:
> On Thu, 2 Jul 2015, Paul Osmialowski wrote:
> > On Thu, 2 Jul 2015, Arnd Bergmann wrote:
> >
> > > I wonder if you could move out the fixed rate clocks into their own
> > > nodes. Are they actually controlled by the same block? If they are
>
Arnd, Thomas,
Thanks for your valuable input and for your patience.
I'm attaching yet another proposal for this clock driver. I've
flattened the .dts and ensured register access protection. I've also added
one more clock source (osc0er) and clock gate to it.
Can you comment this one too?
On
On Thu, 2 Jul 2015, Paul Osmialowski wrote:
> On Thu, 2 Jul 2015, Arnd Bergmann wrote:
>
> > I wonder if you could move out the fixed rate clocks into their own
> > nodes. Are they actually controlled by the same block? If they are
> > just fixed, you can use the normal binding for fixed rate cloc
Hi Arnd,
On Thu, 2 Jul 2015, Arnd Bergmann wrote:
I wonder if you could move out the fixed rate clocks into their own
nodes. Are they actually controlled by the same block? If they are
just fixed, you can use the normal binding for fixed rate clocks
and only describe the clocks that are related
On Thursday 02 July 2015 12:08:39 Paul Osmialowski wrote:
> Nah, I've found this code hard to maintain. I'm attaching simplified
> version.
>
Looks better to me, but of course needs full review from the clock
maintainers.
I wonder if you could move out the fixed rate clocks into their own
nodes
Nah, I've found this code hard to maintain. I'm attaching simplified
version.
Thanks,
Paul
On Wed, 1 Jul 2015, Paul Osmialowski wrote:
Hi Arnd,
Can you look at attached candidate for the third iteration? Is it any better
now?
Thanks,
Paul
On Tue, 30 Jun 2015, Arnd Bergmann wrote:
On T
Hi Arnd,
Can you look at attached candidate for the third iteration? Is it any
better now?
Thanks,
Paul
On Tue, 30 Jun 2015, Arnd Bergmann wrote:
On Tuesday 30 June 2015 14:27:24 Paul Osmialowski wrote:
Based on K70P256M150SF3RM.pdf K70 Sub-Family Reference Manual, Rev. 3.
Signed-off-by:
On Tuesday 30 June 2015 14:27:24 Paul Osmialowski wrote:
> Based on K70P256M150SF3RM.pdf K70 Sub-Family Reference Manual, Rev. 3.
>
> Signed-off-by: Paul Osmialowski
> ---
> .../devicetree/bindings/clock/kinetis-clock.txt| 63 +++
> arch/arm/boot/dts/kinetis.dtsi | 36 +
17 matches
Mail list logo
