Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Wed, Mar 01, 2017 at 08:17:39PM +0800, Icenowy Zheng wrote:
> > I'm a bit worried by that to be honest. You claim to support the A31, 
> > yet jugdging by the current state of that code you never actually 
> > tested it on that SoC. 
> 
> I only claim to reserve possibility to extend the driver to support
> A31, but I didn't claim it currently support A31.

Well, you did call it sun6i.

Please rename it, and we will consolidate in due time.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Thu, Mar 02, 2017 at 11:13:18PM +0800, Icenowy Zheng wrote:
> 
> 
> 02.03.2017, 22:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Wed, Mar 01, 2017 at 08:17:39PM +0800, Icenowy Zheng wrote:
> >>  > I'm a bit worried by that to be honest. You claim to support the A31,
> >>  > yet jugdging by the current state of that code you never actually
> >>  > tested it on that SoC.
> >>
> >>  I only claim to reserve possibility to extend the driver to support
> >>  A31, but I didn't claim it currently support A31.
> >
> > Well, you did call it sun6i.
> >
> > Please rename it, and we will consolidate in due time.
> 
> Then rename it back when it really gains support for A31?

Yes.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

[maxime.ripard]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Thu, Mar 02, 2017 at 11:13:53PM +0800, Icenowy Zheng wrote:
> 
> 
> 02.03.2017, 22:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote:
> >>  > I'm a bit worried by that to be honest. You claim to support the A31,
> >>  > yet jugdging by the current state of that code you never actually
> >>  > tested it on that SoC.
> >>  >
> >>  > What makes you say that the PRCM clocks are the same for the H3 and
> >>  > A64? We have to be sure, otherwise we might not be able to get the DT
> >>  > binding right from the very beginning, and we might not be able to fix
> >>  > it later.
> >>
> >>  In fact, if we worry about this, we shouldn't make r-ccu, as
> >>  dedicated clocks are more easy to fix.
> >>
> >>  For newer SoCs' PRCM, we never have enough documents, and Allwinner
> >>  have said that they cannot provide it. (I asked them for this.)
> >>
> >>  The best solution is to implement mature enough dedicated clocks
> >>  before we convert to ccu.
> >
> > What do you mean by dedicated clocks?
> 
> The legacy form of clocks.

Which itself creates another form of issues. What happens if we get
something wrong on those clocks (as it is likely to happen)?

We potentially can't fix it at all, that's what happens.

And that's leaving aside the DT and clocks maintainers regular
complaints that we should get away from those.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]