Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Wed, 30 Nov 2016 20:14:11 +0100
Jernej Škrabec  wrote:

> Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> > 2016年12月1日 02:49于 Jernej Skrabec 写道：
> > 
> > > Hi Jean-François,
> > > 
> > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
> napisala:
> > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > >> 
> > >> Maxime Ripard  wrote:
> > >> > > > I'm still not sure which pipeline should I use.
> > >> > > > 
> > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > >> > > > 
> > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > >> > > 
> > >> > > So, I don't see how this may work.
> > >> > > How can the u-boot know the resolutions of the HDMI display device?
> > >> > > 
> > >> > > In other words: I have a new H3 board with the last u-boot and
> > >> > > kernel.
> > >> > > I plug my (rather old or brand new) HDMI display device.
> > >> > > After powering on the system, I hope to get something on the screen.
> > >> > > How?
> > >> > 
> > >> > If it works like the driver for the first display engine in U-Boot, it
> > >> > will use the preferred mode reported by the EDID, and will fallback to
> > >> > 1024x768 if it cannot access it.
> > >> 
> > >> Icenowy wrote: "simplefb won't use EDID"
> > >> 
> > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > >> not work with HDMI (different timings).
> > > 
> > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > was tested with at least following resolutions:
> > > - 1920x1080 @ 60 Hz
> > > - 1280x1024 @ 60 Hz
> > > - 1280x800 @ 60 Hz (slight clock difference)
> > > - 800x480 (not sure about frame rate)
> > > - 3840x2160 @ 30 Hz (4K)
> > 
> > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > 
> > > and nobody complained so far. I'm pretty sure 1024x768 would work.

Check the timings offered by the DRM core.

> > > 
> > >> > Maybe it would be worth exchanging on the EDID code that has been done
> > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > >> 
> > >> The u-boot got my code, and, up to now, I could not fix the random or
> > >> permanent failures of EDID reading in some boards.
> > > 
> > > I only have one OPi2, but as I said, EDID always worked for me.

Happy guy!

> > > The only
> > > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > > driver (including EDID reading), TCON code is now reverted to the same as
> > > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > > and compare it.
> > 
> > So is the TCON of DE 2.0 identical to the original TCON?
> > 
> > If so, we should reuse sun4i-tcon ...
> 
> Well, TCON is splitted in two parts (two base addresses), one for HDMI and 
> one 
> for TV. However, register offsets are same as before, so I guess driver 
> reusage make sense. I think that there are few additional registers, but they 
> can be ignored for simplefb.

The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
clock and I/O area.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Wed, 30 Nov 2016 20:14:11 +0100
Jernej Škrabec  wrote:

> Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> > 2016年12月1日 02:49于 Jernej Skrabec 写道：
> > 
> > > Hi Jean-François,
> > > 
> > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
> napisala:
> > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > >> 
> > >> Maxime Ripard  wrote:
> > >> > > > I'm still not sure which pipeline should I use.
> > >> > > > 
> > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > >> > > > 
> > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > >> > > 
> > >> > > So, I don't see how this may work.
> > >> > > How can the u-boot know the resolutions of the HDMI display device?
> > >> > > 
> > >> > > In other words: I have a new H3 board with the last u-boot and
> > >> > > kernel.
> > >> > > I plug my (rather old or brand new) HDMI display device.
> > >> > > After powering on the system, I hope to get something on the screen.
> > >> > > How?
> > >> > 
> > >> > If it works like the driver for the first display engine in U-Boot, it
> > >> > will use the preferred mode reported by the EDID, and will fallback to
> > >> > 1024x768 if it cannot access it.
> > >> 
> > >> Icenowy wrote: "simplefb won't use EDID"
> > >> 
> > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > >> not work with HDMI (different timings).
> > > 
> > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > was tested with at least following resolutions:
> > > - 1920x1080 @ 60 Hz
> > > - 1280x1024 @ 60 Hz
> > > - 1280x800 @ 60 Hz (slight clock difference)
> > > - 800x480 (not sure about frame rate)
> > > - 3840x2160 @ 30 Hz (4K)
> > 
> > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > 
> > > and nobody complained so far. I'm pretty sure 1024x768 would work.

Check the timings offered by the DRM core.

> > > 
> > >> > Maybe it would be worth exchanging on the EDID code that has been done
> > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > >> 
> > >> The u-boot got my code, and, up to now, I could not fix the random or
> > >> permanent failures of EDID reading in some boards.
> > > 
> > > I only have one OPi2, but as I said, EDID always worked for me.

Happy guy!

> > > The only
> > > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > > driver (including EDID reading), TCON code is now reverted to the same as
> > > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > > and compare it.
> > 
> > So is the TCON of DE 2.0 identical to the original TCON?
> > 
> > If so, we should reuse sun4i-tcon ...
> 
> Well, TCON is splitted in two parts (two base addresses), one for HDMI and 
> one 
> for TV. However, register offsets are same as before, so I guess driver 
> reusage make sense. I think that there are few additional registers, but they 
> can be ignored for simplefb.

The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
clock and I/O area.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Tue, 29 Nov 2016 22:59:32 +0100
Maxime Ripard  wrote:

> > > I'm still not sure which pipeline should I use.
> > > 
> > > And, it seems that HDMI Slow Clock is not needed?
> > > 
> > > (seems that it's only for EDID, but simplefb won't use EDID)
> > 
> > So, I don't see how this may work.
> > How can the u-boot know the resolutions of the HDMI display device?
> > 
> > In other words: I have a new H3 board with the last u-boot and kernel.
> > I plug my (rather old or brand new) HDMI display device.
> > After powering on the system, I hope to get something on the screen.
> > How?
> 
> If it works like the driver for the first display engine in U-Boot, it
> will use the preferred mode reported by the EDID, and will fallback to
> 1024x768 if it cannot access it.

Icenowy wrote: "simplefb won't use EDID"

Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
not work with HDMI (different timings).

> Maybe it would be worth exchanging on the EDID code that has been done
> for the u-boot driver too, so that it can be fixed in your driver.

The u-boot got my code, and, up to now, I could not fix the random or
permanent failures of EDID reading in some boards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Tue, 29 Nov 2016 22:59:32 +0100
Maxime Ripard  wrote:

> > > I'm still not sure which pipeline should I use.
> > > 
> > > And, it seems that HDMI Slow Clock is not needed?
> > > 
> > > (seems that it's only for EDID, but simplefb won't use EDID)
> > 
> > So, I don't see how this may work.
> > How can the u-boot know the resolutions of the HDMI display device?
> > 
> > In other words: I have a new H3 board with the last u-boot and kernel.
> > I plug my (rather old or brand new) HDMI display device.
> > After powering on the system, I hope to get something on the screen.
> > How?
> 
> If it works like the driver for the first display engine in U-Boot, it
> will use the preferred mode reported by the EDID, and will fallback to
> 1024x768 if it cannot access it.

Icenowy wrote: "simplefb won't use EDID"

Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
not work with HDMI (different timings).

> Maybe it would be worth exchanging on the EDID code that has been done
> for the u-boot driver too, so that it can be fixed in your driver.

The u-boot got my code, and, up to now, I could not fix the random or
permanent failures of EDID reading in some boards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Mon, 28 Nov 2016 17:59:00 +0800
Icenowy Zheng  wrote:

> As there's currently a fork of U-Boot which provides simplefb support
> for H3, a simplefb node can be added to the device tree.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> 
> I'm still not sure which pipeline should I use.
> 
> And, it seems that HDMI Slow Clock is not needed?
> 
> (seems that it's only for EDID, but simplefb won't use EDID)

So, I don't see how this may work.
How can the u-boot know the resolutions of the HDMI display device?

In other words: I have a new H3 board with the last u-boot and kernel.
I plug my (rather old or brand new) HDMI display device.
After powering on the system, I hope to get something on the screen.
How?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Mon, 28 Nov 2016 17:59:00 +0800
Icenowy Zheng  wrote:

> As there's currently a fork of U-Boot which provides simplefb support
> for H3, a simplefb node can be added to the device tree.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> 
> I'm still not sure which pipeline should I use.
> 
> And, it seems that HDMI Slow Clock is not needed?
> 
> (seems that it's only for EDID, but simplefb won't use EDID)

So, I don't see how this may work.
How can the u-boot know the resolutions of the HDMI display device?

In other words: I have a new H3 board with the last u-boot and kernel.
I plug my (rather old or brand new) HDMI display device.
After powering on the system, I hope to get something on the screen.
How?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Sun, 30 Oct 2016 10:06:20 +0800
Chen-Yu Tsai  wrote:

> >> Yes, I know that the burst size is always a power of 2.
> >> The best way to check it would be to change the {src,dts}_maxburst to a
> >> bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
> >> asks for a lot of changes...
> >
> > To be honest, I'm not really a big fan of those tree wide changes
> > without any way to maintain compatibility. It ends up in a single,
> > huge patch if we want to maintain bisectability that just isn't
> > reviewable.
> 
> Looking at the dmaengine API, I believe we got it wrong.
> 
> max_burst in dma_slave_config denotes the largest amount of data
> a single transfer should be, as described in dmaengine.h:
> 
>  * @src_maxburst: the maximum number of words (note: words, as in
>  * units of the src_addr_width member, not bytes) that can be sent
>  * in one burst to the device. Typically something like half the
>  * FIFO depth on I/O peripherals so you don't overflow it. This
>  * may or may not be applicable on memory sources.
>  * @dst_maxburst: same as src_maxburst but for destination target
>  * mutatis mutandis.
> 
> The DMA engine driver should be free to select whatever burst size
> that doesn't exceed this. So for max_burst = 4, the driver can select
> burst = 4 for controllers that do support it, or burst = 1 for those
> that don't, and do more bursts.
> 
> This also means we can increase max_burst for the audio codec, as
> the FIFO is 64 samples deep for stereo, or 128 samples for mono.
> 
> 
> If we agree on the above I can send some patches for this.

That's fine to me, but this does not solve the main problem which is
how/where are defined the possible bursts of a SoC.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Sun, 30 Oct 2016 10:06:20 +0800
Chen-Yu Tsai  wrote:

> >> Yes, I know that the burst size is always a power of 2.
> >> The best way to check it would be to change the {src,dts}_maxburst to a
> >> bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
> >> asks for a lot of changes...
> >
> > To be honest, I'm not really a big fan of those tree wide changes
> > without any way to maintain compatibility. It ends up in a single,
> > huge patch if we want to maintain bisectability that just isn't
> > reviewable.
> 
> Looking at the dmaengine API, I believe we got it wrong.
> 
> max_burst in dma_slave_config denotes the largest amount of data
> a single transfer should be, as described in dmaengine.h:
> 
>  * @src_maxburst: the maximum number of words (note: words, as in
>  * units of the src_addr_width member, not bytes) that can be sent
>  * in one burst to the device. Typically something like half the
>  * FIFO depth on I/O peripherals so you don't overflow it. This
>  * may or may not be applicable on memory sources.
>  * @dst_maxburst: same as src_maxburst but for destination target
>  * mutatis mutandis.
> 
> The DMA engine driver should be free to select whatever burst size
> that doesn't exceed this. So for max_burst = 4, the driver can select
> burst = 4 for controllers that do support it, or burst = 1 for those
> that don't, and do more bursts.
> 
> This also means we can increase max_burst for the audio codec, as
> the FIFO is 64 samples deep for stereo, or 128 samples for mono.
> 
> 
> If we agree on the above I can send some patches for this.

That's fine to me, but this does not solve the main problem which is
how/where are defined the possible bursts of a SoC.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness

[Jean-Francois Moine]

On Tue, 25 Oct 2016 07:38:55 +0200
LABBE Corentin  wrote:

> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> > 
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> > 
> 
> On my cubieboard2 (A20)
> hexdump -C 
> /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem 
>   16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C 
> /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem 
>   16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0200
> 
> So clearly for me its constant.

Even after power off/power on?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness

[Jean-Francois Moine]

On Tue, 25 Oct 2016 07:38:55 +0200
LABBE Corentin  wrote:

> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> > 
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> > 
> 
> On my cubieboard2 (A20)
> hexdump -C 
> /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem 
>   16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C 
> /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem 
>   16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0200
> 
> So clearly for me its constant.

Even after power off/power on?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Tue, 4 Oct 2016 18:55:54 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Tue, Oct 04, 2016 at 12:40:11PM +0200, Jean-Francois Moine wrote:
> > On Tue,  4 Oct 2016 11:46:14 +0200
> > Mylène Josserand <mylene.josser...@free-electrons.com> wrote:
> > 
> > > Add the case of a burst of 4 which is handled by the SoC.
> > > 
> > > Signed-off-by: Mylène Josserand <mylene.josser...@free-electrons.com>
> > > ---
> > >  drivers/dma/sun6i-dma.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > index 8346199..0485204 100644
> > > --- a/drivers/dma/sun6i-dma.c
> > > +++ b/drivers/dma/sun6i-dma.c
> > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > >   switch (maxburst) {
> > >   case 1:
> > >   return 0;
> > > + case 4:
> > > + return 1;
> > >   case 8:
> > >   return 2;
> > >   default:
> > > -- 
> > > 2.9.3
> > 
> > This patch has already been rejected by Maxime in the threads
> > http://www.spinics.net/lists/dmaengine/msg08610.html
> > and
> > http://www.spinics.net/lists/dmaengine/msg08719.html
> > 
> > I hope you will find the way he wants for this maxburst to be added.
> 
> I was talking about something along these lines (not tested):

I wonder why you don't submit this yourself.

> ---8<-
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 83461994e418..573ac4608293 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
>   switch (maxburst) {
>   case 1:
>   return 0;
> + case 4:
> + return 1;
>   case 8:
>   return 2;
>   default:
> @@ -1110,11 +1112,19 @@ static int sun6i_dma_probe(struct platform_device 
> *pdev)
>   sdc->slave.dst_addr_widths  = 
> BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> 
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> 
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> + sdc->slave.dst_bursts   = BIT(1) | BIT(8);
> + sdc->slave.src_bursts   = BIT(1) | BIT(8);
>   sdc->slave.directions   = BIT(DMA_DEV_TO_MEM) |
> BIT(DMA_MEM_TO_DEV);
>   sdc->slave.residue_granularity  = DMA_RESIDUE_GRANULARITY_BURST;
>   sdc->slave.dev = >dev;
>  
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun8i-h3-dma")) {
> + sdc->slave.dst_bursts |= BIT(4);
> + sdc->slave.src_bursts |= BIT(4);
> + }
> +
>   sdc->pchans = devm_kcalloc(>dev, sdc->cfg->nr_max_channels,
>  sizeof(struct sun6i_pchan), GFP_KERNEL);
>   if (!sdc->pchans)
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index cc535a478bae..f7bbec24bb58 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -673,6 +673,8 @@ struct dma_filter {
>   *   each type of direction, the dma controller should fill (1 <<
>   *   ) and same should be checked by controller as well
>   * @max_burst: max burst capability per-transfer
> + * @dst_bursts: bitfield of the available burst sizes for the destination
> + * @src_bursts: bitfield of the available burst sizes for the source

You did not define dst_bursts nor src_bursts.

>   * @residue_granularity: granularity of the transfer residue reported
>   *   by tx_status
>   * @device_alloc_chan_resources: allocate resources and return the
> @@ -800,6 +802,14 @@ struct dma_device {
>  static inline int dmaengine_slave_config(struct dma_chan *chan,
> struct dma_slave_config *config)
>  {
> + if (config->src_maxburst && config->device->src_bursts &&
> + !(BIT(config->src_maxburst) & config->device->src_bursts))

The maxburst may be as big as 4Kibytes, then, I am not sure that this
code will work!

> + return -EINVAL;
> +
> + if (config->dst_maxburst && config->device->dst_bursts &&
> + !(BIT(config->dst_maxburst) & config->device->dst_bursts))
> + return -EINVAL;
> +
>   if (chan->device->device_config)
>   return chan->device->device_config(chan, config);
> ---8< 

Yes, I know that the burst size is always a power of 2.
The best way to check it would be to change the {src,dts}_maxburst to a
bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
asks for a lot of changes...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Tue, 4 Oct 2016 18:55:54 +0200
Maxime Ripard  wrote:

> On Tue, Oct 04, 2016 at 12:40:11PM +0200, Jean-Francois Moine wrote:
> > On Tue,  4 Oct 2016 11:46:14 +0200
> > Mylène Josserand  wrote:
> > 
> > > Add the case of a burst of 4 which is handled by the SoC.
> > > 
> > > Signed-off-by: Mylène Josserand 
> > > ---
> > >  drivers/dma/sun6i-dma.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > index 8346199..0485204 100644
> > > --- a/drivers/dma/sun6i-dma.c
> > > +++ b/drivers/dma/sun6i-dma.c
> > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > >   switch (maxburst) {
> > >   case 1:
> > >   return 0;
> > > + case 4:
> > > + return 1;
> > >   case 8:
> > >   return 2;
> > >   default:
> > > -- 
> > > 2.9.3
> > 
> > This patch has already been rejected by Maxime in the threads
> > http://www.spinics.net/lists/dmaengine/msg08610.html
> > and
> > http://www.spinics.net/lists/dmaengine/msg08719.html
> > 
> > I hope you will find the way he wants for this maxburst to be added.
> 
> I was talking about something along these lines (not tested):

I wonder why you don't submit this yourself.

> ---8<-
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 83461994e418..573ac4608293 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
>   switch (maxburst) {
>   case 1:
>   return 0;
> + case 4:
> + return 1;
>   case 8:
>   return 2;
>   default:
> @@ -1110,11 +1112,19 @@ static int sun6i_dma_probe(struct platform_device 
> *pdev)
>   sdc->slave.dst_addr_widths  = 
> BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> 
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> 
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> + sdc->slave.dst_bursts   = BIT(1) | BIT(8);
> + sdc->slave.src_bursts   = BIT(1) | BIT(8);
>   sdc->slave.directions   = BIT(DMA_DEV_TO_MEM) |
> BIT(DMA_MEM_TO_DEV);
>   sdc->slave.residue_granularity  = DMA_RESIDUE_GRANULARITY_BURST;
>   sdc->slave.dev = >dev;
>  
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun8i-h3-dma")) {
> + sdc->slave.dst_bursts |= BIT(4);
> + sdc->slave.src_bursts |= BIT(4);
> + }
> +
>   sdc->pchans = devm_kcalloc(>dev, sdc->cfg->nr_max_channels,
>  sizeof(struct sun6i_pchan), GFP_KERNEL);
>   if (!sdc->pchans)
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index cc535a478bae..f7bbec24bb58 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -673,6 +673,8 @@ struct dma_filter {
>   *   each type of direction, the dma controller should fill (1 <<
>   *   ) and same should be checked by controller as well
>   * @max_burst: max burst capability per-transfer
> + * @dst_bursts: bitfield of the available burst sizes for the destination
> + * @src_bursts: bitfield of the available burst sizes for the source

You did not define dst_bursts nor src_bursts.

>   * @residue_granularity: granularity of the transfer residue reported
>   *   by tx_status
>   * @device_alloc_chan_resources: allocate resources and return the
> @@ -800,6 +802,14 @@ struct dma_device {
>  static inline int dmaengine_slave_config(struct dma_chan *chan,
> struct dma_slave_config *config)
>  {
> + if (config->src_maxburst && config->device->src_bursts &&
> + !(BIT(config->src_maxburst) & config->device->src_bursts))

The maxburst may be as big as 4Kibytes, then, I am not sure that this
code will work!

> + return -EINVAL;
> +
> + if (config->dst_maxburst && config->device->dst_bursts &&
> + !(BIT(config->dst_maxburst) & config->device->dst_bursts))
> + return -EINVAL;
> +
>   if (chan->device->device_config)
>   return chan->device->device_config(chan, config);
> ---8< 

Yes, I know that the burst size is always a power of 2.
The best way to check it would be to change the {src,dts}_maxburst to a
bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
asks for a lot of changes...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v3 5/6] ARM: sunxi: Remove useless allwinner,pull property

[Jean-Francois Moine]

On Thu, 20 Oct 2016 15:49:06 +0200
Maxime Ripard  wrote:

> The allwinner,pull property set to NO_PULL was really considered our
> default (and wasn't even changing the default value in the code).
> 
> Remove these properties to make it obvious that we do not set anything in
> such a case.
> 
> Signed-off-by: Maxime Ripard 
> Acked-by: Chen-Yu Tsai 
> Reviewed-by: Linus Walleij 
> ---
>  arch/arm/boot/dts/ntc-gr8-evb.dts |  4 +-
>  arch/arm/boot/dts/ntc-gr8.dtsi| 14 +-
>  arch/arm/boot/dts/sun4i-a10-a1000.dts |  2 +-
>  arch/arm/boot/dts/sun4i-a10-cubieboard.dts|  1 +-
>  arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts  |  4 +-
>  arch/arm/boot/dts/sun4i-a10-gemei-g9.dts  |  1 +-
>  arch/arm/boot/dts/sun4i-a10-hackberry.dts |  2 +-
>  arch/arm/boot/dts/sun4i-a10-inet1.dts |  2 +-
>  arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts|  2 +-
>  arch/arm/boot/dts/sun4i-a10-marsboard.dts |  1 +-
>  arch/arm/boot/dts/sun4i-a10-mk802.dts |  3 +-
>  arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts|  2 +-
>  arch/arm/boot/dts/sun4i-a10-pcduino.dts   |  2 +-
>  arch/arm/boot/dts/sun4i-a10-pcduino2.dts  |  1 +-
>  arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts  |  3 +-
>  arch/arm/boot/dts/sun4i-a10.dtsi  | 24 +
>  arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts  |  1 +-
>  arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts  |  2 +-
>  arch/arm/boot/dts/sun5i-a10s-mk802.dts|  2 +-
>  arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts  |  2 +-
>  arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts |  2 +-
>  arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts  |  2 +-
>  arch/arm/boot/dts/sun5i-a10s.dtsi |  7 +--
>  arch/arm/boot/dts/sun5i-a13-hsg-h702.dts  |  1 +-
>  arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts   |  3 +-
>  arch/arm/boot/dts/sun5i-a13-olinuxino.dts |  2 +-
>  arch/arm/boot/dts/sun5i-a13-utoo-p66.dts  |  1 +-
>  arch/arm/boot/dts/sun5i-a13.dtsi  |  3 +-
>  arch/arm/boot/dts/sun5i-r8-chip.dts   |  2 +-
>  arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi  |  2 +-
>  arch/arm/boot/dts/sun5i.dtsi  |  7 +--
>  arch/arm/boot/dts/sun6i-a31-app4-evb1.dts |  1 +-
>  arch/arm/boot/dts/sun6i-a31-colombus.dts  |  1 +-
>  arch/arm/boot/dts/sun6i-a31-hummingbird.dts   |  2 +-
>  arch/arm/boot/dts/sun6i-a31-i7.dts|  2 +-
>  arch/arm/boot/dts/sun6i-a31-m9.dts|  2 +-
>  arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts  |  2 +-
>  arch/arm/boot/dts/sun6i-a31.dtsi  | 13 +
>  arch/arm/boot/dts/sun6i-a31s-primo81.dts  |  1 +-
>  arch/arm/boot/dts/sun6i-a31s-sina31s.dts  |  1 +-
>  arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts  |  3 +-
>  arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts  |  3 +-
>  arch/arm/boot/dts/sun7i-a20-bananapi.dts  |  2 +-
>  arch/arm/boot/dts/sun7i-a20-bananapro.dts |  5 +--
>  arch/arm/boot/dts/sun7i-a20-cubieboard2.dts   |  1 +-
>  arch/arm/boot/dts/sun7i-a20-cubietruck.dts|  6 +--
>  arch/arm/boot/dts/sun7i-a20-hummingbird.dts   |  4 +-
>  arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts |  4 +-
>  arch/arm/boot/dts/sun7i-a20-itead-ibox.dts|  1 +-
>  arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts |  2 +-
>  arch/arm/boot/dts/sun7i-a20-m3.dts|  1 +-
>  arch/arm/boot/dts/sun7i-a20-mk808c.dts|  2 +-
>  arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts|  4 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts|  2 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts  |  1 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts   |  3 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts   |  1 +-
>  arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts |  4 +-
>  arch/arm/boot/dts/sun7i-a20-orangepi.dts  |  4 +-
>  arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts |  3 +-
>  arch/arm/boot/dts/sun7i-a20-pcduino3.dts  |  2 +-
>  arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts|  3 +-
>  arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts  |  1 +-
>  arch/arm/boot/dts/sun7i-a20.dtsi  | 37 +
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi  | 10 +---
>  arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts |  1 +-
>  arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts |  1 +-
>  arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts|  1 +-
>  arch/arm/boot/dts/sun8i-a33-olinuxino.dts   

Re: [PATCH v3 5/6] ARM: sunxi: Remove useless allwinner,pull property

[Jean-Francois Moine]

On Thu, 20 Oct 2016 15:49:06 +0200
Maxime Ripard  wrote:

> The allwinner,pull property set to NO_PULL was really considered our
> default (and wasn't even changing the default value in the code).
> 
> Remove these properties to make it obvious that we do not set anything in
> such a case.
> 
> Signed-off-by: Maxime Ripard 
> Acked-by: Chen-Yu Tsai 
> Reviewed-by: Linus Walleij 
> ---
>  arch/arm/boot/dts/ntc-gr8-evb.dts |  4 +-
>  arch/arm/boot/dts/ntc-gr8.dtsi| 14 +-
>  arch/arm/boot/dts/sun4i-a10-a1000.dts |  2 +-
>  arch/arm/boot/dts/sun4i-a10-cubieboard.dts|  1 +-
>  arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts  |  4 +-
>  arch/arm/boot/dts/sun4i-a10-gemei-g9.dts  |  1 +-
>  arch/arm/boot/dts/sun4i-a10-hackberry.dts |  2 +-
>  arch/arm/boot/dts/sun4i-a10-inet1.dts |  2 +-
>  arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts|  2 +-
>  arch/arm/boot/dts/sun4i-a10-marsboard.dts |  1 +-
>  arch/arm/boot/dts/sun4i-a10-mk802.dts |  3 +-
>  arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts|  2 +-
>  arch/arm/boot/dts/sun4i-a10-pcduino.dts   |  2 +-
>  arch/arm/boot/dts/sun4i-a10-pcduino2.dts  |  1 +-
>  arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts  |  3 +-
>  arch/arm/boot/dts/sun4i-a10.dtsi  | 24 +
>  arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts  |  1 +-
>  arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts  |  2 +-
>  arch/arm/boot/dts/sun5i-a10s-mk802.dts|  2 +-
>  arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts  |  2 +-
>  arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts |  2 +-
>  arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts  |  2 +-
>  arch/arm/boot/dts/sun5i-a10s.dtsi |  7 +--
>  arch/arm/boot/dts/sun5i-a13-hsg-h702.dts  |  1 +-
>  arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts   |  3 +-
>  arch/arm/boot/dts/sun5i-a13-olinuxino.dts |  2 +-
>  arch/arm/boot/dts/sun5i-a13-utoo-p66.dts  |  1 +-
>  arch/arm/boot/dts/sun5i-a13.dtsi  |  3 +-
>  arch/arm/boot/dts/sun5i-r8-chip.dts   |  2 +-
>  arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi  |  2 +-
>  arch/arm/boot/dts/sun5i.dtsi  |  7 +--
>  arch/arm/boot/dts/sun6i-a31-app4-evb1.dts |  1 +-
>  arch/arm/boot/dts/sun6i-a31-colombus.dts  |  1 +-
>  arch/arm/boot/dts/sun6i-a31-hummingbird.dts   |  2 +-
>  arch/arm/boot/dts/sun6i-a31-i7.dts|  2 +-
>  arch/arm/boot/dts/sun6i-a31-m9.dts|  2 +-
>  arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts  |  2 +-
>  arch/arm/boot/dts/sun6i-a31.dtsi  | 13 +
>  arch/arm/boot/dts/sun6i-a31s-primo81.dts  |  1 +-
>  arch/arm/boot/dts/sun6i-a31s-sina31s.dts  |  1 +-
>  arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts  |  3 +-
>  arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts  |  3 +-
>  arch/arm/boot/dts/sun7i-a20-bananapi.dts  |  2 +-
>  arch/arm/boot/dts/sun7i-a20-bananapro.dts |  5 +--
>  arch/arm/boot/dts/sun7i-a20-cubieboard2.dts   |  1 +-
>  arch/arm/boot/dts/sun7i-a20-cubietruck.dts|  6 +--
>  arch/arm/boot/dts/sun7i-a20-hummingbird.dts   |  4 +-
>  arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts |  4 +-
>  arch/arm/boot/dts/sun7i-a20-itead-ibox.dts|  1 +-
>  arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts |  2 +-
>  arch/arm/boot/dts/sun7i-a20-m3.dts|  1 +-
>  arch/arm/boot/dts/sun7i-a20-mk808c.dts|  2 +-
>  arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts|  4 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts|  2 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts  |  1 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts   |  3 +-
>  arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts   |  1 +-
>  arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts |  4 +-
>  arch/arm/boot/dts/sun7i-a20-orangepi.dts  |  4 +-
>  arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts |  3 +-
>  arch/arm/boot/dts/sun7i-a20-pcduino3.dts  |  2 +-
>  arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts|  3 +-
>  arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts  |  1 +-
>  arch/arm/boot/dts/sun7i-a20.dtsi  | 37 +
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi  | 10 +---
>  arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts |  1 +-
>  arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts |  1 +-
>  arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts|  1 +-
>  arch/arm/boot/dts/sun8i-a33-olinuxino.dts |  3 +-
>  arch/arm/boot/dts/sun8i-a33.dtsi  |  1 +-
>  

Re: [PATCH 0/5] drm/sun4i: Handle TV overscan

[Jean-Francois Moine]

On Tue, 18 Oct 2016 12:03:49 +0200
Maxime Ripard  wrote:

> The fourth one being the major one. Every time I raised the issue on
> IRC, the answer basically was "we don't care about analog", so I'm a
> bit pessimistic about whether dealing with this in the core would be
> accepted, hence why I chose to deal with this at the driver level.

The same problem exists with HDMI and old TVs (mine is an ASUS 22T1E):
these TVs overscan as soon as AVI frames are in the stream.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 0/5] drm/sun4i: Handle TV overscan

[Jean-Francois Moine]

On Tue, 18 Oct 2016 12:03:49 +0200
Maxime Ripard  wrote:

> The fourth one being the major one. Every time I raised the issue on
> IRC, the answer basically was "we don't care about analog", so I'm a
> bit pessimistic about whether dealing with this in the core would be
> accepted, hence why I chose to deal with this at the driver level.

The same problem exists with HDMI and old TVs (mine is an ASUS 22T1E):
these TVs overscan as soon as AVI frames are in the stream.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] clk: sunxi-ng: sun6i-a31: Force AHB1 clock to use PLL6 as parent

[Jean-Francois Moine]

On Tue, 18 Oct 2016 13:42:09 +0800
Chen-Yu Tsai  wrote:

> On the A31, the DMA engine only works if AHB1 is clocked from PLL6.
> In addition, the hstimer is clocked from AHB1, and if AHB1 is clocked
> from the CPU clock, and cpufreq is working, we get an unstable timer.
> 
> Force the AHB1 clock to use PLL6 as its parent. Previously this was done
> in the device tree with the assigned-clocks and assigned-clocks-parent
> bindings. However with this new monolithic driver, the system critical
> clocks aren't exported through the device tree. The alternative is to
> force this setting in the driver before the clocks are registered.

It should be simpler to export the constant (CLK_AHB1) instead of
adding code...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] clk: sunxi-ng: sun6i-a31: Force AHB1 clock to use PLL6 as parent

[Jean-Francois Moine]

On Tue, 18 Oct 2016 13:42:09 +0800
Chen-Yu Tsai  wrote:

> On the A31, the DMA engine only works if AHB1 is clocked from PLL6.
> In addition, the hstimer is clocked from AHB1, and if AHB1 is clocked
> from the CPU clock, and cpufreq is working, we get an unstable timer.
> 
> Force the AHB1 clock to use PLL6 as its parent. Previously this was done
> in the device tree with the assigned-clocks and assigned-clocks-parent
> bindings. However with this new monolithic driver, the system critical
> clocks aren't exported through the device tree. The alternative is to
> force this setting in the driver before the clocks are registered.

It should be simpler to export the constant (CLK_AHB1) instead of
adding code...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 08/23] ASoC: soc-core: snd_soc_get_dai_name() become non static

[Jean-Francois Moine]

On Mon, 17 Oct 2016 08:34:19 +
Kuninori Morimoto <kuninori.morimoto...@renesas.com> wrote:

> From: Kuninori Morimoto <kuninori.morimoto...@renesas.com>
> 
> snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
> and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
> But graph base DT is using "remote-endpoint". This patch makes
> snd_soc_get_dai_name() non static for graph support.
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto...@renesas.com>
> ---
>  include/sound/soc.h  | 2 ++
>  sound/soc/soc-core.c | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index fd63d23..77b01c4 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -1677,6 +1677,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node 
> *np,
>const char *prefix,
>struct device_node **bitclkmaster,
>struct device_node **framemaster);
> +int snd_soc_get_dai_name(struct of_phandle_args *args,
> +  const char **dai_name);
>  int snd_soc_of_get_dai_name(struct device_node *of_node,
>   const char **dai_name);
>  int snd_soc_of_get_dai_link_codecs(struct device *dev,
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 8371488..6f911f4 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -3794,7 +3794,7 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node 
> *np,
>  }
>  EXPORT_SYMBOL_GPL(snd_soc_of_parse_daifmt);
>  
> -static int snd_soc_get_dai_name(struct of_phandle_args *args,
> +int snd_soc_get_dai_name(struct of_phandle_args *args,
>   const char **dai_name)
>  {
>   struct snd_soc_component *pos;
> @@ -3846,6 +3846,7 @@ static int snd_soc_get_dai_name(struct of_phandle_args 
> *args,
>   mutex_unlock(_mutex);
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(snd_soc_get_dai_name);
>  
>  int snd_soc_of_get_dai_name(struct device_node *of_node,
>   const char **dai_name)
> -- 
> 1.9.1

I already proposed this patch
 http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086870.html
but it seems people were not interested.
I hope now is the right time.

Acked-by: Jean-Francois Moine <moin...@free.fr>

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 08/23] ASoC: soc-core: snd_soc_get_dai_name() become non static

[Jean-Francois Moine]

On Mon, 17 Oct 2016 08:34:19 +
Kuninori Morimoto  wrote:

> From: Kuninori Morimoto 
> 
> snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
> and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
> But graph base DT is using "remote-endpoint". This patch makes
> snd_soc_get_dai_name() non static for graph support.
> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  include/sound/soc.h  | 2 ++
>  sound/soc/soc-core.c | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index fd63d23..77b01c4 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -1677,6 +1677,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node 
> *np,
>const char *prefix,
>struct device_node **bitclkmaster,
>struct device_node **framemaster);
> +int snd_soc_get_dai_name(struct of_phandle_args *args,
> +  const char **dai_name);
>  int snd_soc_of_get_dai_name(struct device_node *of_node,
>   const char **dai_name);
>  int snd_soc_of_get_dai_link_codecs(struct device *dev,
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 8371488..6f911f4 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -3794,7 +3794,7 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node 
> *np,
>  }
>  EXPORT_SYMBOL_GPL(snd_soc_of_parse_daifmt);
>  
> -static int snd_soc_get_dai_name(struct of_phandle_args *args,
> +int snd_soc_get_dai_name(struct of_phandle_args *args,
>   const char **dai_name)
>  {
>   struct snd_soc_component *pos;
> @@ -3846,6 +3846,7 @@ static int snd_soc_get_dai_name(struct of_phandle_args 
> *args,
>   mutex_unlock(_mutex);
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(snd_soc_get_dai_name);
>  
>  int snd_soc_of_get_dai_name(struct device_node *of_node,
>   const char **dai_name)
> -- 
> 1.9.1

I already proposed this patch
 http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086870.html
but it seems people were not interested.
I hope now is the right time.

Acked-by: Jean-Francois Moine 

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 0/23] ASoC: add OF graph base simple-card

[Jean-Francois Moine]

On Mon, 17 Oct 2016 08:30:49 +
Kuninori Morimoto  wrote:

> These are OF graph base simple-card patch-set.
>  1) -  3) : simple-scu-card cleanup
>  4) - 10) : soc-core prepare for OF graph card
> 11) - 17) : OF graph new feature
> 18) - 23) : OF graph base simple-card
> 
> I posted 11) - 17) OF graph new feature patches before, and then Rob requested
> about usecase. 18) - 23) can be usecase for it.
>  1) - 10) are independent (= Mark)
> 11) - 17) are independent (= Rob)
> 18) - 23) are depends on 1) - 10) and 11) - 17) (= Mark)
>  
> Kuninori Morimoto (23):
>1) ASoC: simple-scu-card: code sync: follow to simple family style
>2) ASoC: simple-scu-card: code sync: rename asoc_simple_card_priv
>3) ASoC: simple-scu-card: code sync: tidyup props/link naming
>4) ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name
>5) ASoC: soc-core: adjust for graph on 
> snd_soc_of_parse_audio_simple_widgets
>6) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing
>7) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix
>8) ASoC: soc-core: snd_soc_get_dai_name() become non static
>9) ASoC: simple-card-utils: remove unnecessary cpu/codec pointer check
>   10) ASoC: simple-card-utils: adjust for graph on 
> asoc_simple_card_parse_card_name
>   11) Documentation: of: add type property
>   12) of_graph: add of_graph_get_remote_endpoint()
>   13) of_graph: add of_graph_port_type_is()
>   14) of_graph: add of_graph_get_port_parent()
>   15) of_graph: add of_graph_get_top_port()
>   16) of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()
>   17) of_graph: add of_graph_get_endpoint_count()
>   18) ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
>   19) ASoC: simple-card-utils: add 
> asoc_simple_card_try_to_probe_graph_card()
>   20) ASoC: add simple-graph-card document
>   21) ASoC: add simple-graph-card support
>   22) ASoC: add simple-graph-scu-card document
>   23) ASoC: add simple-graph-scu-card support
[snip]

Hi Kuninori,

The patches 11..17 put trivial functions in the OF core. As they are
used by only a few systems, it would be better to define them as
macros, or in a module or in the simple-card-utils.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 0/23] ASoC: add OF graph base simple-card

[Jean-Francois Moine]

On Mon, 17 Oct 2016 08:30:49 +
Kuninori Morimoto  wrote:

> These are OF graph base simple-card patch-set.
>  1) -  3) : simple-scu-card cleanup
>  4) - 10) : soc-core prepare for OF graph card
> 11) - 17) : OF graph new feature
> 18) - 23) : OF graph base simple-card
> 
> I posted 11) - 17) OF graph new feature patches before, and then Rob requested
> about usecase. 18) - 23) can be usecase for it.
>  1) - 10) are independent (= Mark)
> 11) - 17) are independent (= Rob)
> 18) - 23) are depends on 1) - 10) and 11) - 17) (= Mark)
>  
> Kuninori Morimoto (23):
>1) ASoC: simple-scu-card: code sync: follow to simple family style
>2) ASoC: simple-scu-card: code sync: rename asoc_simple_card_priv
>3) ASoC: simple-scu-card: code sync: tidyup props/link naming
>4) ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name
>5) ASoC: soc-core: adjust for graph on 
> snd_soc_of_parse_audio_simple_widgets
>6) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing
>7) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix
>8) ASoC: soc-core: snd_soc_get_dai_name() become non static
>9) ASoC: simple-card-utils: remove unnecessary cpu/codec pointer check
>   10) ASoC: simple-card-utils: adjust for graph on 
> asoc_simple_card_parse_card_name
>   11) Documentation: of: add type property
>   12) of_graph: add of_graph_get_remote_endpoint()
>   13) of_graph: add of_graph_port_type_is()
>   14) of_graph: add of_graph_get_port_parent()
>   15) of_graph: add of_graph_get_top_port()
>   16) of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()
>   17) of_graph: add of_graph_get_endpoint_count()
>   18) ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
>   19) ASoC: simple-card-utils: add 
> asoc_simple_card_try_to_probe_graph_card()
>   20) ASoC: add simple-graph-card document
>   21) ASoC: add simple-graph-card support
>   22) ASoC: add simple-graph-scu-card document
>   23) ASoC: add simple-graph-scu-card support
[snip]

Hi Kuninori,

The patches 11..17 put trivial functions in the OF core. As they are
used by only a few systems, it would be better to define them as
macros, or in a module or in the simple-card-utils.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2

[Jean-Francois Moine]

On Fri,  7 Oct 2016 10:25:55 +0200
Corentin Labbe  wrote:

> The sun8i-emac hardware is present on the Orange PI 2.
> It uses the internal PHY.
> 
> This patch create the needed emac node.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> index f93f5d1..5608eb4 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> @@ -54,6 +54,7 @@
>  
>   aliases {
>   serial0 = 
> + ethernet0 = 

As there is no 'of_alias_get_id' in the driver, this alias is useless.

>   };
>  
>   chosen {
> @@ -184,3 +185,10 @@
>   usb1_vbus-supply = <_usb1_vbus>;
>   status = "okay";
>  };
> +
> + {
> + phy-handle = <_mii_phy>;
> + phy-mode = "mii";
> + allwinner,leds-active-low;
> + status = "okay";
> +};
> -- 
> 2.7.3
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2

[Jean-Francois Moine]

On Fri,  7 Oct 2016 10:25:55 +0200
Corentin Labbe  wrote:

> The sun8i-emac hardware is present on the Orange PI 2.
> It uses the internal PHY.
> 
> This patch create the needed emac node.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> index f93f5d1..5608eb4 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> @@ -54,6 +54,7 @@
>  
>   aliases {
>   serial0 = 
> + ethernet0 = 

As there is no 'of_alias_get_id' in the driver, this alias is useless.

>   };
>  
>   chosen {
> @@ -184,3 +185,10 @@
>   usb1_vbus-supply = <_usb1_vbus>;
>   status = "okay";
>  };
> +
> + {
> + phy-handle = <_mii_phy>;
> + phy-mode = "mii";
> + allwinner,leds-active-low;
> + status = "okay";
> +};
> -- 
> 2.7.3
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig

[Jean-Francois Moine]

On Mon, 10 Oct 2016 14:35:11 +0200
LABBE Corentin  wrote:

> On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > > 
> > > Signed-off-by: Corentin Labbe 
> > > ---
> > >  arch/arm/configs/multi_v7_defconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > > b/arch/arm/configs/multi_v7_defconfig
> > > index 5845910..f44d633 100644
> > > --- a/arch/arm/configs/multi_v7_defconfig
> > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > >  CONFIG_VIRTIO_NET=y
> > >  CONFIG_HIX5HD2_GMAC=y
> > >  CONFIG_SUN4I_EMAC=y
> > > +CONFIG_SUN8I_EMAC=y
> > 
> > Any reason to build it statically?
> > 
> 
> No, just copied the same than CONFIG_SUN4I_EMAC that probably do not need it 
> also.

All arm configs are done the same way, and, some day, the generic ARM
V7 kernel will not be loadable in 1Gb RAM...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig

[Jean-Francois Moine]

On Mon, 10 Oct 2016 14:35:11 +0200
LABBE Corentin  wrote:

> On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > > 
> > > Signed-off-by: Corentin Labbe 
> > > ---
> > >  arch/arm/configs/multi_v7_defconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > > b/arch/arm/configs/multi_v7_defconfig
> > > index 5845910..f44d633 100644
> > > --- a/arch/arm/configs/multi_v7_defconfig
> > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > >  CONFIG_VIRTIO_NET=y
> > >  CONFIG_HIX5HD2_GMAC=y
> > >  CONFIG_SUN4I_EMAC=y
> > > +CONFIG_SUN8I_EMAC=y
> > 
> > Any reason to build it statically?
> > 
> 
> No, just copied the same than CONFIG_SUN4I_EMAC that probably do not need it 
> also.

All arm configs are done the same way, and, some day, the generic ARM
V7 kernel will not be loadable in 1Gb RAM...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 04/10] ARM: dts: sun8i-h3: Add dt node for the syscon control module

[Jean-Francois Moine]

On Mon, 10 Oct 2016 14:31:51 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Fri, Oct 07, 2016 at 10:25:51AM +0200, Corentin Labbe wrote:
> > This patch add the dt node for the syscon register present on the
> > Allwinner H3.
> > 
> > Only two register are present in this syscon and the only one useful is
> > the one dedicated to EMAC clock.
> > 
> > Signed-off-by: Corentin Labbe 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 8a95e36..1101d2f 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -140,6 +140,11 @@
> > #size-cells = <1>;
> > ranges;
> >  
> > +   syscon: syscon@01c0 {
> > +   compatible = "syscon";
> 
> It would be great to have a more specific compatible here in addition
> to the syscon, like "allwinner,sun8i-h3-system-controller".

The System Control area is just like the PRCM area: it would be simpler
to define the specific registers in the associated drivers.

Here, instead of the syscon node, plus

+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-h3-emac";
+   syscon = <>;
+   reg = <0x01c3 0x104>;
+   interrupts = ;
...

there would be no 'syscon' node and

+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-h3-emac";
+   syscon = <>;
+   reg =   <0x01c3 0x104>, /* EMAC */
+   <0x01c00030 4>; /* system control */
+   interrupts = ;
...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 04/10] ARM: dts: sun8i-h3: Add dt node for the syscon control module

[Jean-Francois Moine]

On Mon, 10 Oct 2016 14:31:51 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Fri, Oct 07, 2016 at 10:25:51AM +0200, Corentin Labbe wrote:
> > This patch add the dt node for the syscon register present on the
> > Allwinner H3.
> > 
> > Only two register are present in this syscon and the only one useful is
> > the one dedicated to EMAC clock.
> > 
> > Signed-off-by: Corentin Labbe 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 8a95e36..1101d2f 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -140,6 +140,11 @@
> > #size-cells = <1>;
> > ranges;
> >  
> > +   syscon: syscon@01c0 {
> > +   compatible = "syscon";
> 
> It would be great to have a more specific compatible here in addition
> to the syscon, like "allwinner,sun8i-h3-system-controller".

The System Control area is just like the PRCM area: it would be simpler
to define the specific registers in the associated drivers.

Here, instead of the syscon node, plus

+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-h3-emac";
+   syscon = <>;
+   reg = <0x01c3 0x104>;
+   interrupts = ;
...

there would be no 'syscon' node and

+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-h3-emac";
+   syscon = <>;
+   reg =   <0x01c3 0x104>, /* EMAC */
+   <0x01c00030 4>; /* system control */
+   interrupts = ;
...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3

[Jean-Francois Moine]

On Wed,  5 Oct 2016 11:48:24 +0200
Corentin Labbe  wrote:

> This patch add support for the sunxi-sid driver to the device tree for 
> sun8i-h3.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 9f58bb4..abfd29c 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -211,6 +211,11 @@
>   #size-cells = <0>;
>   };
>  
> + sid: eeprom@01c14200 {
> + compatible = "allwinner,sun7i-a20-sid";
> + reg = <0x01c14200 0x200>;

The datasheet says 1Kb starting at 0x01c14000.
Is there any reason to reduce the area and to shift the offset?

> + };
> +
>   usbphy: phy@01c19400 {
>   compatible = "allwinner,sun8i-h3-usb-phy";
>   reg = <0x01c19400 0x2c>,
> -- 
> 2.7.3

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3

[Jean-Francois Moine]

On Wed,  5 Oct 2016 11:48:24 +0200
Corentin Labbe  wrote:

> This patch add support for the sunxi-sid driver to the device tree for 
> sun8i-h3.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 9f58bb4..abfd29c 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -211,6 +211,11 @@
>   #size-cells = <0>;
>   };
>  
> + sid: eeprom@01c14200 {
> + compatible = "allwinner,sun7i-a20-sid";
> + reg = <0x01c14200 0x200>;

The datasheet says 1Kb starting at 0x01c14000.
Is there any reason to reduce the area and to shift the offset?

> + };
> +
>   usbphy: phy@01c19400 {
>   compatible = "allwinner,sun8i-h3-usb-phy";
>   reg = <0x01c19400 0x2c>,
> -- 
> 2.7.3

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 07/14] ASoC: Add sun8i audio card

[Jean-Francois Moine]

On Wed, 5 Oct 2016 08:04:26 +0200
Code Kipper  wrote:

> > +static int sun8i_probe(struct platform_device *pdev)
> > +{
> > +   struct snd_soc_dai_link *link = _dai_link;
> > +   struct device_node *np = pdev->dev.of_node;
> > +   int ret;
> > +
> > +   /* register the soc card */
> > +   sun8i_card.dev = >dev;
> > +
> > +   /* Retrieve the audio-codec from DT */
> > +   link->codec_of_node = of_parse_phandle(np, "allwinner,audio-codec", 
> > 0);
> > +   if (!link->codec_of_node) {
> > +   dev_err(>dev, "Missing audio codec\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Retrieve DAI from DT */
> > +   link->cpu_of_node = of_parse_phandle(np, 
> > "allwinner,i2s-controller", 0);
> Now that I've spent some time trying to add my changes for the H3
> ontop of your code,  I think this file should be more generic and rely
> on the dtsi more. It's pretty A33 specific but with little effort it
> can be worked to cover all of the sun8i type drivers. I would change
> "allwinner,i2s-controller" to "allwinner,audio-dai" for starters and
> then maybe pull in some info for the dai-link from the dtsi.
> CK
[snip]

In fact, there should be no audio card driver as proposed here:
with such a simple layout
CPU DAI (sun4i-a10-i2s) -> CODEC DAI (sun8i-a33-codec)
the 'simple-card' does the job.

BTW, I have a I2S/PCM/TDM driver for the H3 and A83T.
But, as it works with HDMI and contains echanges with the DRM driver,
it cannot go yet to the mainline...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 07/14] ASoC: Add sun8i audio card

[Jean-Francois Moine]

On Wed, 5 Oct 2016 08:04:26 +0200
Code Kipper  wrote:

> > +static int sun8i_probe(struct platform_device *pdev)
> > +{
> > +   struct snd_soc_dai_link *link = _dai_link;
> > +   struct device_node *np = pdev->dev.of_node;
> > +   int ret;
> > +
> > +   /* register the soc card */
> > +   sun8i_card.dev = >dev;
> > +
> > +   /* Retrieve the audio-codec from DT */
> > +   link->codec_of_node = of_parse_phandle(np, "allwinner,audio-codec", 
> > 0);
> > +   if (!link->codec_of_node) {
> > +   dev_err(>dev, "Missing audio codec\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Retrieve DAI from DT */
> > +   link->cpu_of_node = of_parse_phandle(np, 
> > "allwinner,i2s-controller", 0);
> Now that I've spent some time trying to add my changes for the H3
> ontop of your code,  I think this file should be more generic and rely
> on the dtsi more. It's pretty A33 specific but with little effort it
> can be worked to cover all of the sun8i type drivers. I would change
> "allwinner,i2s-controller" to "allwinner,audio-dai" for starters and
> then maybe pull in some info for the dai-link from the dtsi.
> CK
[snip]

In fact, there should be no audio card driver as proposed here:
with such a simple layout
CPU DAI (sun4i-a10-i2s) -> CODEC DAI (sun8i-a33-codec)
the 'simple-card' does the job.

BTW, I have a I2S/PCM/TDM driver for the H3 and A83T.
But, as it works with HDMI and contains echanges with the DRM driver,
it cannot go yet to the mainline...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Tue, 4 Oct 2016 14:12:21 +0200
Thomas Petazzoni  wrote:

> > > Add the case of a burst of 4 which is handled by the SoC.
> > > 
> > > Signed-off-by: Mylène Josserand 
> > > ---
> > >  drivers/dma/sun6i-dma.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > index 8346199..0485204 100644
> > > --- a/drivers/dma/sun6i-dma.c
> > > +++ b/drivers/dma/sun6i-dma.c
> > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > >   switch (maxburst) {
> > >   case 1:
> > >   return 0;
> > > + case 4:
> > > + return 1;
> > >   case 8:
> > >   return 2;
> > >   default:
> > > -- 
> > > 2.9.3  
> > 
> > This patch has already been rejected by Maxime in the threads
> > http://www.spinics.net/lists/dmaengine/msg08610.html
> > and
> > http://www.spinics.net/lists/dmaengine/msg08719.html
> > 
> > I hope you will find the way he wants for this maxburst to be added.
> 
> I was about to reply to Mylene's e-mail, suggesting that she should add
> a comment in the code (and maybe in the commit log) to explain why this
> addition is needed, and also that even though the schematics say that
> value "1" (max burst size of 4 bytes) is reserved, it is in fact
> incorrect. The Allwinner BSP code is really using this value, and it's
> the value that makes audio work, so we believe the datasheet is simply
> incorrect.
> 
> We already discussed it with Maxime, so I believe he should agree this
> time. But I would suggest to have such details explained in the commit
> log and in a comment in the code.

Strange. Looking at the datasheets of the A23, A31, A33, A83T and H3
(these are the SoCs using the DMA sun6i), only the H3 can have 4 as the
burst size (the doc is unclear for the A31).

Well, I was submitting for the H3, Mylène is submitting for the A33.
So, what about the A23, A31 and A83T?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Tue, 4 Oct 2016 14:12:21 +0200
Thomas Petazzoni  wrote:

> > > Add the case of a burst of 4 which is handled by the SoC.
> > > 
> > > Signed-off-by: Mylène Josserand 
> > > ---
> > >  drivers/dma/sun6i-dma.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > index 8346199..0485204 100644
> > > --- a/drivers/dma/sun6i-dma.c
> > > +++ b/drivers/dma/sun6i-dma.c
> > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > >   switch (maxburst) {
> > >   case 1:
> > >   return 0;
> > > + case 4:
> > > + return 1;
> > >   case 8:
> > >   return 2;
> > >   default:
> > > -- 
> > > 2.9.3  
> > 
> > This patch has already been rejected by Maxime in the threads
> > http://www.spinics.net/lists/dmaengine/msg08610.html
> > and
> > http://www.spinics.net/lists/dmaengine/msg08719.html
> > 
> > I hope you will find the way he wants for this maxburst to be added.
> 
> I was about to reply to Mylene's e-mail, suggesting that she should add
> a comment in the code (and maybe in the commit log) to explain why this
> addition is needed, and also that even though the schematics say that
> value "1" (max burst size of 4 bytes) is reserved, it is in fact
> incorrect. The Allwinner BSP code is really using this value, and it's
> the value that makes audio work, so we believe the datasheet is simply
> incorrect.
> 
> We already discussed it with Maxime, so I believe he should agree this
> time. But I would suggest to have such details explained in the commit
> log and in a comment in the code.

Strange. Looking at the datasheets of the A23, A31, A33, A83T and H3
(these are the SoCs using the DMA sun6i), only the H3 can have 4 as the
burst size (the doc is unclear for the A31).

Well, I was submitting for the H3, Mylène is submitting for the A33.
So, what about the A23, A31 and A83T?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 05/14] mfd: sun6i-prcm: Add sun8i analog codec as subnode

[Jean-Francois Moine]

On Tue,  4 Oct 2016 11:46:18 +0200
Mylène Josserand  wrote:

> The sun8i audio codec is using PRCM registers to configure all the
> analog part of the audio codec. It is added as a subnode of the PRCM
> with his resource (offset of 0x1c0).
> 
> Signed-off-by: Mylène Josserand 
> ---
>  drivers/mfd/sun6i-prcm.c | 16 
>  1 file changed, 16 insertions(+)
[snip]

I was heard that the PRCM as a MFD would disappear.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 05/14] mfd: sun6i-prcm: Add sun8i analog codec as subnode

[Jean-Francois Moine]

On Tue,  4 Oct 2016 11:46:18 +0200
Mylène Josserand  wrote:

> The sun8i audio codec is using PRCM registers to configure all the
> analog part of the audio codec. It is added as a subnode of the PRCM
> with his resource (offset of 0x1c0).
> 
> Signed-off-by: Mylène Josserand 
> ---
>  drivers/mfd/sun6i-prcm.c | 16 
>  1 file changed, 16 insertions(+)
[snip]

I was heard that the PRCM as a MFD would disappear.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Tue,  4 Oct 2016 11:46:14 +0200
Mylène Josserand  wrote:

> Add the case of a burst of 4 which is handled by the SoC.
> 
> Signed-off-by: Mylène Josserand 
> ---
>  drivers/dma/sun6i-dma.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 8346199..0485204 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
>   switch (maxburst) {
>   case 1:
>   return 0;
> + case 4:
> + return 1;
>   case 8:
>   return 2;
>   default:
> -- 
> 2.9.3

This patch has already been rejected by Maxime in the threads
http://www.spinics.net/lists/dmaengine/msg08610.html
and
http://www.spinics.net/lists/dmaengine/msg08719.html

I hope you will find the way he wants for this maxburst to be added.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Jean-Francois Moine]

On Tue,  4 Oct 2016 11:46:14 +0200
Mylène Josserand  wrote:

> Add the case of a burst of 4 which is handled by the SoC.
> 
> Signed-off-by: Mylène Josserand 
> ---
>  drivers/dma/sun6i-dma.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 8346199..0485204 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
>   switch (maxburst) {
>   case 1:
>   return 0;
> + case 4:
> + return 1;
>   case 8:
>   return 2;
>   default:
> -- 
> 2.9.3

This patch has already been rejected by Maxime in the threads
http://www.spinics.net/lists/dmaengine/msg08610.html
and
http://www.spinics.net/lists/dmaengine/msg08719.html

I hope you will find the way he wants for this maxburst to be added.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

On Sat, 24 Sep 2016 16:35:05 +0800
Chen-Yu Tsai <w...@csie.org> wrote:

> On Fri, Sep 23, 2016 at 4:58 PM, Jean-Francois Moine <moin...@free.fr> wrote:
> > This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
> > It is based on the previous patch series
> > regulator: axp20x: Simplify various code
> >
> > v3:
> > - put the code of the new devices in new files instead of in the common
> >   axp20x file.
> > - fix errors about the regulators and interrupts
> > v2:
> > - fix lack of support of dcdc frequency
> > - notice that the AXP803 is also handled
> > - send the patch to the DT maintainers
> >
> > Jean-Francois Moine (4):
> >   regulator: axp20x: move device independant parts to new files
> >   regulator: axp20x: duplicate the MFD axp20x-rsb code
> >   regulator: axp20x: add the AXP803
> >   regulator: axp20x: add the AXP813
> 
> NAK. Please follow the axp20x mfd and sub-device driver design we
> already have.

Sorry, I will not: installing a lot of useless code and tables in
permanent system memory for just one regulator is not the way I think
about a good kernel.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

On Sat, 24 Sep 2016 16:35:05 +0800
Chen-Yu Tsai  wrote:

> On Fri, Sep 23, 2016 at 4:58 PM, Jean-Francois Moine  wrote:
> > This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
> > It is based on the previous patch series
> > regulator: axp20x: Simplify various code
> >
> > v3:
> > - put the code of the new devices in new files instead of in the common
> >   axp20x file.
> > - fix errors about the regulators and interrupts
> > v2:
> > - fix lack of support of dcdc frequency
> > - notice that the AXP803 is also handled
> > - send the patch to the DT maintainers
> >
> > Jean-Francois Moine (4):
> >   regulator: axp20x: move device independant parts to new files
> >   regulator: axp20x: duplicate the MFD axp20x-rsb code
> >   regulator: axp20x: add the AXP803
> >   regulator: axp20x: add the AXP813
> 
> NAK. Please follow the axp20x mfd and sub-device driver design we
> already have.

Sorry, I will not: installing a lot of useless code and tables in
permanent system memory for just one regulator is not the way I think
about a good kernel.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 3/3] regulator: axp20x: simplify device access

[Jean-Francois Moine]

On Sat, 24 Sep 2016 16:29:11 +0800
Chen-Yu Tsai  wrote:

[snip]
> >  static int axp20x_regulator_probe(struct platform_device *pdev)
> >  {
> > +   struct device *dev = pdev->dev.parent;
> 
> There are 2 struct device's in play in this function, 1 from the parent,
> and 1 for the platform device for this regulator sub-device.
> 
> > struct regulator_dev *rdev;
> > -   struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> > +   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
> > const struct regulator_desc *regulators;
> > struct regulator_config config = {
> > -   .dev = pdev->dev.parent,
> > +   .dev = dev,
> > .regmap = axp20x->regmap,
> > .driver_data = axp20x,
> > };
> > @@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct 
> > platform_device *pdev)
> > dcdc5_ix = AXP22X_DCDC5;
> > dc1sw_ix = AXP22X_DC1SW;
> > dc5ldo_ix = AXP22X_DC5LDO;
> > -   drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
> > +   drivevbus = of_property_read_bool(dev->of_node,
> >   "x-powers,drive-vbus-en");
> > break;
> > case AXP806_ID:
> > @@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct 
> > platform_device *pdev)
> > dc5ldo_ix = AXP809_DC5LDO;
> > break;
> > default:
> > -   dev_err(>dev, "Unsupported AXP variant: %ld\n",
> > +   dev_err(dev, "Unsupported AXP variant: %ld\n",
> 
> So this one is incorrect. You should use this device's struct,
> not the parent. It's possible the mfd driver supports a PMIC,
> but the regulator driver is still missing.

Why do you need a regulator driver? The 'regulator' node in the DT is
not a real device. It is just a container and it could be removed
without any problem.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 3/3] regulator: axp20x: simplify device access

[Jean-Francois Moine]

On Sat, 24 Sep 2016 16:29:11 +0800
Chen-Yu Tsai  wrote:

[snip]
> >  static int axp20x_regulator_probe(struct platform_device *pdev)
> >  {
> > +   struct device *dev = pdev->dev.parent;
> 
> There are 2 struct device's in play in this function, 1 from the parent,
> and 1 for the platform device for this regulator sub-device.
> 
> > struct regulator_dev *rdev;
> > -   struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> > +   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
> > const struct regulator_desc *regulators;
> > struct regulator_config config = {
> > -   .dev = pdev->dev.parent,
> > +   .dev = dev,
> > .regmap = axp20x->regmap,
> > .driver_data = axp20x,
> > };
> > @@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct 
> > platform_device *pdev)
> > dcdc5_ix = AXP22X_DCDC5;
> > dc1sw_ix = AXP22X_DC1SW;
> > dc5ldo_ix = AXP22X_DC5LDO;
> > -   drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
> > +   drivevbus = of_property_read_bool(dev->of_node,
> >   "x-powers,drive-vbus-en");
> > break;
> > case AXP806_ID:
> > @@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct 
> > platform_device *pdev)
> > dc5ldo_ix = AXP809_DC5LDO;
> > break;
> > default:
> > -   dev_err(>dev, "Unsupported AXP variant: %ld\n",
> > +   dev_err(dev, "Unsupported AXP variant: %ld\n",
> 
> So this one is incorrect. You should use this device's struct,
> not the parent. It's possible the mfd driver supports a PMIC,
> but the regulator driver is still missing.

Why do you need a regulator driver? The 'regulator' node in the DT is
not a real device. It is just a container and it could be removed
without any problem.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH v3 1/4] regulator: axp20x: move device independant parts to new files

[Jean-Francois Moine]

The axp20x driver contains device specific and device independant parts.
This patch moves the independant parts to new .c/.h files.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/regulator/Makefile   |   2 +-
 drivers/regulator/axp-regulator.c| 308 ++
 drivers/regulator/axp-regulator.h| 127 +++
 drivers/regulator/axp20x-regulator.c | 415 +++
 4 files changed, 464 insertions(+), 388 deletions(-)
 create mode 100644 drivers/regulator/axp-regulator.c
 create mode 100644 drivers/regulator/axp-regulator.h

diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 2142a5d..225a026 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
 obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
 obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
 obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
-obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
+obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o axp-regulator.o
 obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
 obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
diff --git a/drivers/regulator/axp-regulator.c 
b/drivers/regulator/axp-regulator.c
new file mode 100644
index 000..0d7adb6
--- /dev/null
+++ b/drivers/regulator/axp-regulator.c
@@ -0,0 +1,308 @@
+/*
+ * AXP regulators driver
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ * Copyright (C) 2013 Carlo Caione <ca...@caione.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "axp-regulator.h"
+
+#define AXP20X_WORKMODE_DCDC2_MASK BIT(2)
+#define AXP20X_WORKMODE_DCDC3_MASK BIT(1)
+#define AXP22X_WORKMODE_DCDCX_MASK(x)  BIT(x)
+
+#define AXP20X_FREQ_DCDC_MASK  0x0f
+
+#define AXP22X_MISC_N_VBUSEN_FUNC  BIT(4)
+
+const struct regulator_ops axp_ops_fixed = {
+   .list_voltage   = regulator_list_voltage_linear,
+};
+EXPORT_SYMBOL_GPL(axp_ops_fixed);
+
+const struct regulator_ops axp_ops_range = {
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .list_voltage   = regulator_list_voltage_linear_range,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+EXPORT_SYMBOL_GPL(axp_ops_range);
+
+const struct regulator_ops axp_ops = {
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .list_voltage   = regulator_list_voltage_linear,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+EXPORT_SYMBOL_GPL(axp_ops);
+
+const struct regulator_ops axp_ops_sw = {
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+EXPORT_SYMBOL_GPL(axp_ops_sw);
+
+static const struct regulator_desc axp22x_drivevbus_regulator = {
+   .name   = "drivevbus",
+   .supply_name= "drivevbus",
+   .of_match   = of_match_ptr("drivevbus"),
+   .regulators_node = of_match_ptr("regulators"),
+   .type   = REGULATOR_VOLTAGE,
+   .owner  = THIS_MODULE,
+   .enable_reg = AXP20X_VBUS_IPSOUT_MGMT,
+   .enable_mask= BIT(2),
+   .ops= _ops_sw,
+};
+
+static int axp_set_dcdc_freq(struct device *dev,
+   u32 dcdcfreq)
+{
+   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
+   unsigned int reg = AXP20X_DCDC_FREQ;
+   u32 min, max, def, step;
+
+   switch (axp20x->variant) {
+   case AXP202_ID:
+   case AXP209_ID:
+   min = 750;
+   max = 1875;
+   def = 1500;
+   step = 75;
+   break;
+   case AXP806_ID:
+   /*
+* AXP806 DCDC work frequency setting has the same range and
+* step as AXP22X, but at a different register.
+* Fall through to the check below.
+* (See include/linux/mfd/axp20x.h)
+*/
+   reg = AXP806_DCDC_FREQ_CTRL;
+   case AXP221_

[PATCH v3 1/4] regulator: axp20x: move device independant parts to new files

[Jean-Francois Moine]

The axp20x driver contains device specific and device independant parts.
This patch moves the independant parts to new .c/.h files.

Signed-off-by: Jean-Francois Moine 
---
 drivers/regulator/Makefile   |   2 +-
 drivers/regulator/axp-regulator.c| 308 ++
 drivers/regulator/axp-regulator.h| 127 +++
 drivers/regulator/axp20x-regulator.c | 415 +++
 4 files changed, 464 insertions(+), 388 deletions(-)
 create mode 100644 drivers/regulator/axp-regulator.c
 create mode 100644 drivers/regulator/axp-regulator.h

diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 2142a5d..225a026 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
 obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
 obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
 obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
-obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
+obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o axp-regulator.o
 obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
 obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
diff --git a/drivers/regulator/axp-regulator.c 
b/drivers/regulator/axp-regulator.c
new file mode 100644
index 000..0d7adb6
--- /dev/null
+++ b/drivers/regulator/axp-regulator.c
@@ -0,0 +1,308 @@
+/*
+ * AXP regulators driver
+ *
+ * Copyright (C) 2016 Jean-Francois Moine 
+ * Copyright (C) 2013 Carlo Caione 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "axp-regulator.h"
+
+#define AXP20X_WORKMODE_DCDC2_MASK BIT(2)
+#define AXP20X_WORKMODE_DCDC3_MASK BIT(1)
+#define AXP22X_WORKMODE_DCDCX_MASK(x)  BIT(x)
+
+#define AXP20X_FREQ_DCDC_MASK  0x0f
+
+#define AXP22X_MISC_N_VBUSEN_FUNC  BIT(4)
+
+const struct regulator_ops axp_ops_fixed = {
+   .list_voltage   = regulator_list_voltage_linear,
+};
+EXPORT_SYMBOL_GPL(axp_ops_fixed);
+
+const struct regulator_ops axp_ops_range = {
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .list_voltage   = regulator_list_voltage_linear_range,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+EXPORT_SYMBOL_GPL(axp_ops_range);
+
+const struct regulator_ops axp_ops = {
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .list_voltage   = regulator_list_voltage_linear,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+EXPORT_SYMBOL_GPL(axp_ops);
+
+const struct regulator_ops axp_ops_sw = {
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+EXPORT_SYMBOL_GPL(axp_ops_sw);
+
+static const struct regulator_desc axp22x_drivevbus_regulator = {
+   .name   = "drivevbus",
+   .supply_name= "drivevbus",
+   .of_match   = of_match_ptr("drivevbus"),
+   .regulators_node = of_match_ptr("regulators"),
+   .type   = REGULATOR_VOLTAGE,
+   .owner  = THIS_MODULE,
+   .enable_reg = AXP20X_VBUS_IPSOUT_MGMT,
+   .enable_mask= BIT(2),
+   .ops= _ops_sw,
+};
+
+static int axp_set_dcdc_freq(struct device *dev,
+   u32 dcdcfreq)
+{
+   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
+   unsigned int reg = AXP20X_DCDC_FREQ;
+   u32 min, max, def, step;
+
+   switch (axp20x->variant) {
+   case AXP202_ID:
+   case AXP209_ID:
+   min = 750;
+   max = 1875;
+   def = 1500;
+   step = 75;
+   break;
+   case AXP806_ID:
+   /*
+* AXP806 DCDC work frequency setting has the same range and
+* step as AXP22X, but at a different register.
+* Fall through to the check below.
+* (See include/linux/mfd/axp20x.h)
+*/
+   reg = AXP806_DCDC_FREQ_CTRL;
+   case AXP221_ID:
+   case AXP223_ID:
+   case AXP809_ID:
+

[PATCH v3 4/4] regulator: axp20x: add the AXP813

[Jean-Francois Moine]

The X-Powers AXP813 PMIC is close to the AXP803.
It is used in some Allwinner boards as the Sinovoip BananaPi M3+.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 Documentation/devicetree/bindings/mfd/axp20x.txt |   9 +-
 drivers/mfd/axp20x.c |   2 +
 drivers/regulator/Makefile   |   2 +-
 drivers/regulator/axp813.c   | 229 +++
 include/linux/mfd/axp20x.h   |   1 +
 5 files changed, 239 insertions(+), 4 deletions(-)
 create mode 100644 drivers/regulator/axp813.c

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 3332d02..62019fb 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -8,11 +8,12 @@ axp221 (X-Powers)
 axp223 (X-Powers)
 axp803 (X-Powers)
 axp809 (X-Powers)
+axp813 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
  "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
- "x-powers,axp806", "x-powers,axp809"
+ "x-powers,axp806", "x-powers,axp809", "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -87,7 +88,7 @@ LDO_IO1   : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
-AXP803 regulators, type, and corresponding input supply names:
+AXP803/AXP813 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
 ---- -
@@ -97,6 +98,7 @@ DCDC3 : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
 DCDC6  : DC-DC buck: vin6-supply
+DCDC7  : DC-DC buck: vin7-supply   : (813 only)
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
@@ -109,10 +111,11 @@ ELDO2 : LDO   : eldoin-supply : 
shared supply
 ELDO3  : LDO   : eldoin-supply : shared supply
 FLDO1  : LDO   : fldoin-supply : shared supply
 FLDO2  : LDO   : fldoin-supply : shared supply
+FLDO3  : LDO   : fldoin-supply : shared supply (813 only)
 RTC_LDO: LDO   : ips-supply: always on
 LDO_IO0: LDO   : ips-supply: GPIO 0
 LDO_IO1: LDO   : ips-supply: GPIO 1
-DC1SW  : On/Off Switch :   : DCDC1 secondary output
+DC1SW  : On/Off Switch :   : DCDC1 secondary output (803 
only)
 
 AXP806 regulators, type, and corresponding input supply names:
 
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 7c90b12..4f2303d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
"AXP803",
"AXP806",
"AXP809",
+   "AXP813",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -811,6 +812,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP803_ID:
+   case AXP813_ID:
axp20x->cells = axp803_cells;
axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
break;
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 2cbb280..a678ba6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o 
arizona-ldo1.o
 obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
 obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
 obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o axp-regulator.o \
-   axp803.o
+   axp803.o axp813.o
 obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
 obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
diff --git a/drivers/regulator/axp813.c b/drivers/regulator/axp813.c
new file mode 100644
index 000..99bfaaa
--- /dev/null
+++ b/drivers/regulator/axp813.c
@@ -0,0 +1,229 @@
+/*
+ * AXP813 regulator driver
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>

[PATCH v3 4/4] regulator: axp20x: add the AXP813

[Jean-Francois Moine]

The X-Powers AXP813 PMIC is close to the AXP803.
It is used in some Allwinner boards as the Sinovoip BananaPi M3+.

Signed-off-by: Jean-Francois Moine 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt |   9 +-
 drivers/mfd/axp20x.c |   2 +
 drivers/regulator/Makefile   |   2 +-
 drivers/regulator/axp813.c   | 229 +++
 include/linux/mfd/axp20x.h   |   1 +
 5 files changed, 239 insertions(+), 4 deletions(-)
 create mode 100644 drivers/regulator/axp813.c

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 3332d02..62019fb 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -8,11 +8,12 @@ axp221 (X-Powers)
 axp223 (X-Powers)
 axp803 (X-Powers)
 axp809 (X-Powers)
+axp813 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
  "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
- "x-powers,axp806", "x-powers,axp809"
+ "x-powers,axp806", "x-powers,axp809", "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -87,7 +88,7 @@ LDO_IO1   : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
-AXP803 regulators, type, and corresponding input supply names:
+AXP803/AXP813 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
 ---- -
@@ -97,6 +98,7 @@ DCDC3 : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
 DCDC6  : DC-DC buck: vin6-supply
+DCDC7  : DC-DC buck: vin7-supply   : (813 only)
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
@@ -109,10 +111,11 @@ ELDO2 : LDO   : eldoin-supply : 
shared supply
 ELDO3  : LDO   : eldoin-supply : shared supply
 FLDO1  : LDO   : fldoin-supply : shared supply
 FLDO2  : LDO   : fldoin-supply : shared supply
+FLDO3  : LDO   : fldoin-supply : shared supply (813 only)
 RTC_LDO: LDO   : ips-supply: always on
 LDO_IO0: LDO   : ips-supply: GPIO 0
 LDO_IO1: LDO   : ips-supply: GPIO 1
-DC1SW  : On/Off Switch :   : DCDC1 secondary output
+DC1SW  : On/Off Switch :   : DCDC1 secondary output (803 
only)
 
 AXP806 regulators, type, and corresponding input supply names:
 
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 7c90b12..4f2303d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
"AXP803",
"AXP806",
"AXP809",
+   "AXP813",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -811,6 +812,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP803_ID:
+   case AXP813_ID:
axp20x->cells = axp803_cells;
axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
break;
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 2cbb280..a678ba6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o 
arizona-ldo1.o
 obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
 obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
 obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o axp-regulator.o \
-   axp803.o
+   axp803.o axp813.o
 obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
 obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
diff --git a/drivers/regulator/axp813.c b/drivers/regulator/axp813.c
new file mode 100644
index 000..99bfaaa
--- /dev/null
+++ b/drivers/regulator/axp813.c
@@ -0,0 +1,229 @@
+/*
+ * AXP813 regulator driver
+ *
+ * Copyright (C) 2016 Jean-Francois Moine 
+ *
+ * This program is free software; yo

[PATCH v3 3/4] regulator: axp20x: add the AXP803

[Jean-Francois Moine]

The X-Powers AXP803 PMIC is close to the AXP809 with more outputs.
It is used in some Allwinner boards as the Sinovoip BananaPi M64
and the Pine A64.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
not tested
---
 Documentation/devicetree/bindings/mfd/axp20x.txt |  32 +++-
 drivers/mfd/axp20x.c |  13 ++
 drivers/regulator/Makefile   |   3 +-
 drivers/regulator/axp803.c   | 225 +++
 include/linux/mfd/axp20x.h   |   1 +
 5 files changed, 271 insertions(+), 3 deletions(-)
 create mode 100644 drivers/regulator/axp803.c

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 8f3ad9a..3332d02 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,12 +6,13 @@ axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
+axp803 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
- "x-powers,axp809"
+ "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
+ "x-powers,axp806", "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -86,6 +87,33 @@ LDO_IO1  : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
+AXP803 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1  : DC-DC buck: vin1-supply
+DCDC2  : DC-DC buck: vin2-supply
+DCDC3  : DC-DC buck: vin3-supply
+DCDC4  : DC-DC buck: vin4-supply
+DCDC5  : DC-DC buck: vin5-supply
+DCDC6  : DC-DC buck: vin6-supply
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+DLDO1  : LDO   : dldoin-supply : shared supply
+DLDO2  : LDO   : dldoin-supply : shared supply
+DLDO3  : LDO   : dldoin-supply : shared supply
+DLDO4  : LDO   : dldoin-supply : shared supply
+ELDO1  : LDO   : eldoin-supply : shared supply
+ELDO2  : LDO   : eldoin-supply : shared supply
+ELDO3  : LDO   : eldoin-supply : shared supply
+FLDO1  : LDO   : fldoin-supply : shared supply
+FLDO2  : LDO   : fldoin-supply : shared supply
+RTC_LDO: LDO   : ips-supply: always on
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+
 AXP806 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be..7c90b12 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -38,6 +38,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+   "AXP803",
"AXP806",
"AXP809",
 };
@@ -739,6 +740,14 @@ static struct mfd_cell axp809_cells[] = {
},
 };
 
+static struct mfd_cell axp803_cells[] = {
+   {
+   .name   = "axp20x-pek",
+   .num_resources  = ARRAY_SIZE(axp809_pek_resources),
+   .resources  = axp809_pek_resources,
+   },
+};
+
 static struct axp20x_dev *axp20x_pm_power_off;
 static void axp20x_power_off(void)
 {
@@ -801,6 +810,10 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_cfg = _regmap_config;
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
+   case AXP803_ID:
+   axp20x->cells = axp803_cells;
+   axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
+   break;
case AXP806_ID:
axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
axp20x->cells = axp806_cells;
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 225a026..2cbb280 100

[PATCH v3 3/4] regulator: axp20x: add the AXP803

[Jean-Francois Moine]

The X-Powers AXP803 PMIC is close to the AXP809 with more outputs.
It is used in some Allwinner boards as the Sinovoip BananaPi M64
and the Pine A64.

Signed-off-by: Jean-Francois Moine 
---
not tested
---
 Documentation/devicetree/bindings/mfd/axp20x.txt |  32 +++-
 drivers/mfd/axp20x.c |  13 ++
 drivers/regulator/Makefile   |   3 +-
 drivers/regulator/axp803.c   | 225 +++
 include/linux/mfd/axp20x.h   |   1 +
 5 files changed, 271 insertions(+), 3 deletions(-)
 create mode 100644 drivers/regulator/axp803.c

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 8f3ad9a..3332d02 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,12 +6,13 @@ axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
+axp803 (X-Powers)
 axp809 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
- "x-powers,axp809"
+ "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
+ "x-powers,axp806", "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -86,6 +87,33 @@ LDO_IO1  : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
+AXP803 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1  : DC-DC buck: vin1-supply
+DCDC2  : DC-DC buck: vin2-supply
+DCDC3  : DC-DC buck: vin3-supply
+DCDC4  : DC-DC buck: vin4-supply
+DCDC5  : DC-DC buck: vin5-supply
+DCDC6  : DC-DC buck: vin6-supply
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+DLDO1  : LDO   : dldoin-supply : shared supply
+DLDO2  : LDO   : dldoin-supply : shared supply
+DLDO3  : LDO   : dldoin-supply : shared supply
+DLDO4  : LDO   : dldoin-supply : shared supply
+ELDO1  : LDO   : eldoin-supply : shared supply
+ELDO2  : LDO   : eldoin-supply : shared supply
+ELDO3  : LDO   : eldoin-supply : shared supply
+FLDO1  : LDO   : fldoin-supply : shared supply
+FLDO2  : LDO   : fldoin-supply : shared supply
+RTC_LDO: LDO   : ips-supply: always on
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+
 AXP806 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be..7c90b12 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -38,6 +38,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+   "AXP803",
"AXP806",
"AXP809",
 };
@@ -739,6 +740,14 @@ static struct mfd_cell axp809_cells[] = {
},
 };
 
+static struct mfd_cell axp803_cells[] = {
+   {
+   .name   = "axp20x-pek",
+   .num_resources  = ARRAY_SIZE(axp809_pek_resources),
+   .resources  = axp809_pek_resources,
+   },
+};
+
 static struct axp20x_dev *axp20x_pm_power_off;
 static void axp20x_power_off(void)
 {
@@ -801,6 +810,10 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_cfg = _regmap_config;
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
+   case AXP803_ID:
+   axp20x->cells = axp803_cells;
+   axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
+   break;
case AXP806_ID:
axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
axp20x->cells = axp806_cells;
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 225a026..2cbb280 100644
--- a/drivers/regulator/Make

[PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
It is based on the previous patch series
regulator: axp20x: Simplify various code

v3:
- put the code of the new devices in new files instead of in the common
  axp20x file.
- fix errors about the regulators and interrupts
v2:
- fix lack of support of dcdc frequency
- notice that the AXP803 is also handled
- send the patch to the DT maintainers

Jean-Francois Moine (4):
  regulator: axp20x: move device independant parts to new files
  regulator: axp20x: duplicate the MFD axp20x-rsb code
  regulator: axp20x: add the AXP803
  regulator: axp20x: add the AXP813

 Documentation/devicetree/bindings/mfd/axp20x.txt |  29 ++-
 drivers/mfd/axp20x.c |  15 +
 drivers/regulator/Makefile   |   3 +-
 drivers/regulator/axp-regulator.c| 347 +++
 drivers/regulator/axp-regulator.h| 133 
 drivers/regulator/axp20x-regulator.c | 415 ++-
 drivers/regulator/axp803.c   | 225 
 drivers/regulator/axp813.c   | 229 +
 include/linux/mfd/axp20x.h   |   2 +
 9 files changed, 1012 insertions(+), 388 deletions(-)
 create mode 100644 drivers/regulator/axp-regulator.c
 create mode 100644 drivers/regulator/axp-regulator.h
 create mode 100644 drivers/regulator/axp803.c
 create mode 100644 drivers/regulator/axp813.c

-- 
2.10.0

[PATCH v3 0/4] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

This patch series adds support for the X-Powers AXP803 and AXP813 PMICs.
It is based on the previous patch series
regulator: axp20x: Simplify various code

v3:
- put the code of the new devices in new files instead of in the common
  axp20x file.
- fix errors about the regulators and interrupts
v2:
- fix lack of support of dcdc frequency
- notice that the AXP803 is also handled
- send the patch to the DT maintainers

Jean-Francois Moine (4):
  regulator: axp20x: move device independant parts to new files
  regulator: axp20x: duplicate the MFD axp20x-rsb code
  regulator: axp20x: add the AXP803
  regulator: axp20x: add the AXP813

 Documentation/devicetree/bindings/mfd/axp20x.txt |  29 ++-
 drivers/mfd/axp20x.c |  15 +
 drivers/regulator/Makefile   |   3 +-
 drivers/regulator/axp-regulator.c| 347 +++
 drivers/regulator/axp-regulator.h| 133 
 drivers/regulator/axp20x-regulator.c | 415 ++-
 drivers/regulator/axp803.c   | 225 
 drivers/regulator/axp813.c   | 229 +
 include/linux/mfd/axp20x.h   |   2 +
 9 files changed, 1012 insertions(+), 388 deletions(-)
 create mode 100644 drivers/regulator/axp-regulator.c
 create mode 100644 drivers/regulator/axp-regulator.h
 create mode 100644 drivers/regulator/axp803.c
 create mode 100644 drivers/regulator/axp813.c

-- 
2.10.0

[PATCH v3 2/4] regulator: axp20x: duplicate the MFD axp20x-rsb code

[Jean-Francois Moine]

The axp20x rsb driver handles many different devices.
Duplicating its code in a generic regulator driver permits
to probe/remove individual devices.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/regulator/axp-regulator.c | 39 +++
 drivers/regulator/axp-regulator.h |  6 ++
 2 files changed, 45 insertions(+)

diff --git a/drivers/regulator/axp-regulator.c 
b/drivers/regulator/axp-regulator.c
index 0d7adb6..17943fb 100644
--- a/drivers/regulator/axp-regulator.c
+++ b/drivers/regulator/axp-regulator.c
@@ -303,6 +303,45 @@ int axp_regulator_create(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(axp_regulator_create);
 
+/* probe/remove RSB devices */
+int axp_rsb_probe(struct sunxi_rsb_device *rdev,
+ struct axp20x_dev *axp20x,
+ const struct axp_cfg *axp_cfg)
+{
+   int ret;
+
+   axp20x->dev = >dev;
+   axp20x->irq = rdev->irq;
+   dev_set_drvdata(>dev, axp20x);
+
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
+   axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev,
+   axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   dev_err(>dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   ret = axp20x_device_probe(axp20x);
+   if (ret < 0)
+   return ret;
+
+   return axp_regulator_create(>dev, axp_cfg);
+}
+EXPORT_SYMBOL_GPL(axp_rsb_probe);
+
+int axp_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+   return axp20x_device_remove(axp20x);
+}
+EXPORT_SYMBOL_GPL(axp_rsb_remove);
+
 MODULE_AUTHOR("Carlo Caione <ca...@caione.org>");
 MODULE_DESCRIPTION("Regulator Module for AXP PMIC");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/regulator/axp-regulator.h 
b/drivers/regulator/axp-regulator.h
index 0adf1b0..085eaa0 100644
--- a/drivers/regulator/axp-regulator.h
+++ b/drivers/regulator/axp-regulator.h
@@ -124,4 +124,10 @@ struct axp_cfg {
 int axp_regulator_create(struct device *dev,
 const struct axp_cfg *axp_cfg);
 
+struct sunxi_rsb_device;
+int axp_rsb_probe(struct sunxi_rsb_device *rdev,
+ struct axp20x_dev *axp20x,
+ const struct axp_cfg *axp_cfg);
+int axp_rsb_remove(struct sunxi_rsb_device *rdev);
+
 #endif /* __AXP_REGULATOR_H__ */
-- 
2.10.0

[PATCH v3 2/4] regulator: axp20x: duplicate the MFD axp20x-rsb code

[Jean-Francois Moine]

The axp20x rsb driver handles many different devices.
Duplicating its code in a generic regulator driver permits
to probe/remove individual devices.

Signed-off-by: Jean-Francois Moine 
---
 drivers/regulator/axp-regulator.c | 39 +++
 drivers/regulator/axp-regulator.h |  6 ++
 2 files changed, 45 insertions(+)

diff --git a/drivers/regulator/axp-regulator.c 
b/drivers/regulator/axp-regulator.c
index 0d7adb6..17943fb 100644
--- a/drivers/regulator/axp-regulator.c
+++ b/drivers/regulator/axp-regulator.c
@@ -303,6 +303,45 @@ int axp_regulator_create(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(axp_regulator_create);
 
+/* probe/remove RSB devices */
+int axp_rsb_probe(struct sunxi_rsb_device *rdev,
+ struct axp20x_dev *axp20x,
+ const struct axp_cfg *axp_cfg)
+{
+   int ret;
+
+   axp20x->dev = >dev;
+   axp20x->irq = rdev->irq;
+   dev_set_drvdata(>dev, axp20x);
+
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
+   axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev,
+   axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   dev_err(>dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   ret = axp20x_device_probe(axp20x);
+   if (ret < 0)
+   return ret;
+
+   return axp_regulator_create(>dev, axp_cfg);
+}
+EXPORT_SYMBOL_GPL(axp_rsb_probe);
+
+int axp_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+   return axp20x_device_remove(axp20x);
+}
+EXPORT_SYMBOL_GPL(axp_rsb_remove);
+
 MODULE_AUTHOR("Carlo Caione ");
 MODULE_DESCRIPTION("Regulator Module for AXP PMIC");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/regulator/axp-regulator.h 
b/drivers/regulator/axp-regulator.h
index 0adf1b0..085eaa0 100644
--- a/drivers/regulator/axp-regulator.h
+++ b/drivers/regulator/axp-regulator.h
@@ -124,4 +124,10 @@ struct axp_cfg {
 int axp_regulator_create(struct device *dev,
 const struct axp_cfg *axp_cfg);
 
+struct sunxi_rsb_device;
+int axp_rsb_probe(struct sunxi_rsb_device *rdev,
+ struct axp20x_dev *axp20x,
+ const struct axp_cfg *axp_cfg);
+int axp_rsb_remove(struct sunxi_rsb_device *rdev);
+
 #endif /* __AXP_REGULATOR_H__ */
-- 
2.10.0

[PATCH 0/3] regulator: axp20x: Simplify various code

[Jean-Francois Moine]

This patch series just simplifies a bit the code of the AXP20x driver.
It does not contain any fonctional changes.
It will be used as a base for adding new AXP devices (patches to come).
It applies on linux-next.

Jean-Francois Moine (3):
  regulator: axp20x: simplify poly-phase handling
  regulator: axp20x: simplify the treatment of linked regulators
  regulator: axp20x: simplify device access

 drivers/regulator/axp20x-regulator.c | 114 ++-
 1 file changed, 60 insertions(+), 54 deletions(-)

-- 
2.10.0

[PATCH 0/3] regulator: axp20x: Simplify various code

[Jean-Francois Moine]

This patch series just simplifies a bit the code of the AXP20x driver.
It does not contain any fonctional changes.
It will be used as a base for adding new AXP devices (patches to come).
It applies on linux-next.

Jean-Francois Moine (3):
  regulator: axp20x: simplify poly-phase handling
  regulator: axp20x: simplify the treatment of linked regulators
  regulator: axp20x: simplify device access

 drivers/regulator/axp20x-regulator.c | 114 ++-
 1 file changed, 60 insertions(+), 54 deletions(-)

-- 
2.10.0

[PATCH 2/3] regulator: axp20x: simplify the treatment of linked regulators

[Jean-Francois Moine]

Using ancillary variables for handling the linked regulators simplifies
the loop of regulator creation and makes easier the addition of new
regulator types.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/regulator/axp20x-regulator.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 4e5e7c8..7405f5b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -511,6 +511,10 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
u32 workmode;
const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
+   s8 dcdc1_ix = -1;
+   s8 dcdc5_ix = -1;
+   s8 dc1sw_ix = -1;
+   s8 dc5ldo_ix = -1;
bool drivevbus = false;
u32 skip_bitmap = 0;
 
@@ -524,6 +528,10 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
case AXP223_ID:
regulators = axp22x_regulators;
nregulators = AXP22X_REG_ID_MAX;
+   dcdc1_ix = AXP22X_DCDC1;
+   dcdc5_ix = AXP22X_DCDC5;
+   dc1sw_ix = AXP22X_DC1SW;
+   dc5ldo_ix = AXP22X_DC5LDO;
drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
  "x-powers,drive-vbus-en");
break;
@@ -541,6 +549,10 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
case AXP809_ID:
regulators = axp809_regulators;
nregulators = AXP809_REG_ID_MAX;
+   dcdc1_ix = AXP809_DCDC1;
+   dcdc5_ix = AXP809_DCDC5;
+   dc1sw_ix = AXP809_DC1SW;
+   dc5ldo_ix = AXP809_DC5LDO;
break;
default:
dev_err(>dev, "Unsupported AXP variant: %ld\n",
@@ -567,8 +579,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
 * part of this loop to see where we save the DT defined
 * name.
 */
-   if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
-   (regulators == axp809_regulators && i == AXP809_DC1SW)) {
+   if (i == dc1sw_ix && dcdc1_name) {
new_desc = devm_kzalloc(>dev, sizeof(*desc),
GFP_KERNEL);
*new_desc = regulators[i];
@@ -576,8 +587,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
desc = new_desc;
}
 
-   if ((regulators == axp22x_regulators && i == AXP22X_DC5LDO) ||
-   (regulators == axp809_regulators && i == AXP809_DC5LDO)) {
+   if (i == dc5ldo_ix && dcdc5_name) {
new_desc = devm_kzalloc(>dev, sizeof(*desc),
GFP_KERNEL);
*new_desc = regulators[i];
@@ -605,14 +615,12 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
/*
 * Save AXP22X DCDC1 / DCDC5 regulator names for later.
 */
-   if ((regulators == axp22x_regulators && i == AXP22X_DCDC1) ||
-   (regulators == axp809_regulators && i == AXP809_DCDC1))
+   if (i == dcdc1_ix)
of_property_read_string(rdev->dev.of_node,
"regulator-name",
_name);
 
-   if ((regulators == axp22x_regulators && i == AXP22X_DCDC5) ||
-   (regulators == axp809_regulators && i == AXP809_DCDC5))
+   if (i == dcdc5_ix)
of_property_read_string(rdev->dev.of_node,
"regulator-name",
_name);
-- 
2.10.0

[PATCH 2/3] regulator: axp20x: simplify the treatment of linked regulators

[Jean-Francois Moine]

Using ancillary variables for handling the linked regulators simplifies
the loop of regulator creation and makes easier the addition of new
regulator types.

Signed-off-by: Jean-Francois Moine 
---
 drivers/regulator/axp20x-regulator.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 4e5e7c8..7405f5b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -511,6 +511,10 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
u32 workmode;
const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
+   s8 dcdc1_ix = -1;
+   s8 dcdc5_ix = -1;
+   s8 dc1sw_ix = -1;
+   s8 dc5ldo_ix = -1;
bool drivevbus = false;
u32 skip_bitmap = 0;
 
@@ -524,6 +528,10 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
case AXP223_ID:
regulators = axp22x_regulators;
nregulators = AXP22X_REG_ID_MAX;
+   dcdc1_ix = AXP22X_DCDC1;
+   dcdc5_ix = AXP22X_DCDC5;
+   dc1sw_ix = AXP22X_DC1SW;
+   dc5ldo_ix = AXP22X_DC5LDO;
drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
  "x-powers,drive-vbus-en");
break;
@@ -541,6 +549,10 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
case AXP809_ID:
regulators = axp809_regulators;
nregulators = AXP809_REG_ID_MAX;
+   dcdc1_ix = AXP809_DCDC1;
+   dcdc5_ix = AXP809_DCDC5;
+   dc1sw_ix = AXP809_DC1SW;
+   dc5ldo_ix = AXP809_DC5LDO;
break;
default:
dev_err(>dev, "Unsupported AXP variant: %ld\n",
@@ -567,8 +579,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
 * part of this loop to see where we save the DT defined
 * name.
 */
-   if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
-   (regulators == axp809_regulators && i == AXP809_DC1SW)) {
+   if (i == dc1sw_ix && dcdc1_name) {
new_desc = devm_kzalloc(>dev, sizeof(*desc),
GFP_KERNEL);
*new_desc = regulators[i];
@@ -576,8 +587,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
desc = new_desc;
}
 
-   if ((regulators == axp22x_regulators && i == AXP22X_DC5LDO) ||
-   (regulators == axp809_regulators && i == AXP809_DC5LDO)) {
+   if (i == dc5ldo_ix && dcdc5_name) {
new_desc = devm_kzalloc(>dev, sizeof(*desc),
GFP_KERNEL);
*new_desc = regulators[i];
@@ -605,14 +615,12 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
/*
 * Save AXP22X DCDC1 / DCDC5 regulator names for later.
 */
-   if ((regulators == axp22x_regulators && i == AXP22X_DCDC1) ||
-   (regulators == axp809_regulators && i == AXP809_DCDC1))
+   if (i == dcdc1_ix)
of_property_read_string(rdev->dev.of_node,
"regulator-name",
_name);
 
-   if ((regulators == axp22x_regulators && i == AXP22X_DCDC5) ||
-   (regulators == axp809_regulators && i == AXP809_DCDC5))
+   if (i == dcdc5_ix)
of_property_read_string(rdev->dev.of_node,
"regulator-name",
_name);
-- 
2.10.0

[PATCH 3/3] regulator: axp20x: simplify device access

[Jean-Francois Moine]

Use the pointer to the main regulator device instead of the pointer
to the child platform device.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/regulator/axp20x-regulator.c | 45 ++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 7405f5b..244ddc3 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -347,9 +347,9 @@ static const struct regulator_desc axp809_regulators[] = {
AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
 };
 
-static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
+static int axp20x_set_dcdc_freq(struct device *dev, u32 dcdcfreq)
 {
-   struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
unsigned int reg = AXP20X_DCDC_FREQ;
u32 min, max, def, step;
 
@@ -378,7 +378,7 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
step = 150;
break;
default:
-   dev_err(>dev,
+   dev_err(dev,
"Setting DCDC frequency for unsupported AXP variant\n");
return -EINVAL;
}
@@ -388,13 +388,13 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
 
if (dcdcfreq < min) {
dcdcfreq = min;
-   dev_warn(>dev, "DCDC frequency too low. Set to %ukHz\n",
+   dev_warn(dev, "DCDC frequency too low. Set to %ukHz\n",
 min);
}
 
if (dcdcfreq > max) {
dcdcfreq = max;
-   dev_warn(>dev, "DCDC frequency too high. Set to %ukHz\n",
+   dev_warn(dev, "DCDC frequency too high. Set to %ukHz\n",
 max);
}
 
@@ -404,24 +404,24 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
  AXP20X_FREQ_DCDC_MASK, dcdcfreq);
 }
 
-static int axp20x_regulator_parse_dt(struct platform_device *pdev)
+static int axp20x_regulator_parse_dt(struct device *dev)
 {
struct device_node *np, *regulators;
int ret;
u32 dcdcfreq = 0;
 
-   np = of_node_get(pdev->dev.parent->of_node);
+   np = of_node_get(dev->of_node);
if (!np)
return 0;
 
regulators = of_get_child_by_name(np, "regulators");
if (!regulators) {
-   dev_warn(>dev, "regulators node not found\n");
+   dev_warn(dev, "regulators node not found\n");
} else {
of_property_read_u32(regulators, "x-powers,dcdc-freq", 
);
-   ret = axp20x_set_dcdc_freq(pdev, dcdcfreq);
+   ret = axp20x_set_dcdc_freq(dev, dcdcfreq);
if (ret < 0) {
-   dev_err(>dev, "Error setting dcdc frequency: 
%d\n", ret);
+   dev_err(dev, "Error setting dcdc frequency: %d\n", ret);
return ret;
}
 
@@ -499,11 +499,12 @@ static u32 axp20x_polyphase_slave(struct axp20x_dev 
*axp20x)
 
 static int axp20x_regulator_probe(struct platform_device *pdev)
 {
+   struct device *dev = pdev->dev.parent;
struct regulator_dev *rdev;
-   struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
const struct regulator_desc *regulators;
struct regulator_config config = {
-   .dev = pdev->dev.parent,
+   .dev = dev,
.regmap = axp20x->regmap,
.driver_data = axp20x,
};
@@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dcdc5_ix = AXP22X_DCDC5;
dc1sw_ix = AXP22X_DC1SW;
dc5ldo_ix = AXP22X_DC5LDO;
-   drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
+   drivevbus = of_property_read_bool(dev->of_node,
  "x-powers,drive-vbus-en");
break;
case AXP806_ID:
@@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dc5ldo_ix = AXP809_DC5LDO;
break;
default:
-   dev_err(>dev, "Unsupported AXP variant: %ld\n",
+   dev_err(dev, "Unsupported AXP variant: %ld\n",
axp20x->variant);
return -EINVAL;
}
 
/* This only sets the dcdc freq. Ignore any errors */
-   axp20x_regulator_parse_dt(pdev);
+   axp20x_regulat

[PATCH 1/3] regulator: axp20x: simplify poly-phase handling

[Jean-Francois Moine]

Building a list (bitmap) of the slaves included in poly-phase groups
at probe startup time simplifies the treatment in the regulator
creation loop.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/regulator/axp20x-regulator.c | 45 +---
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 54382ef..4e5e7c8 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -477,30 +477,24 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev 
*rdev, int id, u32 work
 }
 
 /*
- * This function checks whether a regulator is part of a poly-phase
- * output setup based on the registers settings. Returns true if it is.
+ * This function checks which regulators are part of poly-phase
+ * output setups based on the registers settings.
+ * Returns a bitmap of these regulators.
  */
-static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
+static u32 axp20x_polyphase_slave(struct axp20x_dev *axp20x)
 {
-   u32 reg = 0;
-
-   /* Only AXP806 has poly-phase outputs */
-   if (axp20x->variant != AXP806_ID)
-   return false;
+   u32 reg = 0, bitmap = 0;
 
regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, );
 
-   switch (id) {
-   case AXP806_DCDCB:
-   return (((reg & GENMASK(7, 6)) == BIT(6)) ||
-   ((reg & GENMASK(7, 6)) == BIT(7)));
-   case AXP806_DCDCC:
-   return ((reg & GENMASK(7, 6)) == BIT(7));
-   case AXP806_DCDCE:
-   return !!(reg & BIT(5));
-   }
+   if ((reg & GENMASK(7, 6)) == BIT(5))
+   bitmap |= 1 << AXP806_DCDCE;
+   if ((reg & GENMASK(7, 6)) == BIT(6))
+   bitmap |= 1 << AXP806_DCDCB;
+   if ((reg & GENMASK(7, 6)) == BIT(7))
+   bitmap |= (1 << AXP806_DCDCB) | (1 << AXP806_DCDCC);
 
-   return false;
+   return bitmap;
 }
 
 static int axp20x_regulator_probe(struct platform_device *pdev)
@@ -518,6 +512,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
bool drivevbus = false;
+   u32 skip_bitmap = 0;
 
switch (axp20x->variant) {
case AXP202_ID:
@@ -535,6 +530,13 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
case AXP806_ID:
regulators = axp806_regulators;
nregulators = AXP806_REG_ID_MAX;
+
+   /*
+* The regulators which are slave in a poly-phase setup
+* are skipped, as their controls are bound to the master
+* regulator and won't work.
+*/
+   skip_bitmap |= axp20x_polyphase_slave(axp20x);
break;
case AXP809_ID:
regulators = axp809_regulators;
@@ -553,12 +555,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
const struct regulator_desc *desc = [i];
struct regulator_desc *new_desc;
 
-   /*
-* If this regulator is a slave in a poly-phase setup,
-* skip it, as its controls are bound to the master
-* regulator and won't work.
-*/
-   if (axp20x_is_polyphase_slave(axp20x, i))
+   if (skip_bitmap & (1 << i))
continue;
 
/*
-- 
2.10.0

[PATCH 3/3] regulator: axp20x: simplify device access

[Jean-Francois Moine]

Use the pointer to the main regulator device instead of the pointer
to the child platform device.

Signed-off-by: Jean-Francois Moine 
---
 drivers/regulator/axp20x-regulator.c | 45 ++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 7405f5b..244ddc3 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -347,9 +347,9 @@ static const struct regulator_desc axp809_regulators[] = {
AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
 };
 
-static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
+static int axp20x_set_dcdc_freq(struct device *dev, u32 dcdcfreq)
 {
-   struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
unsigned int reg = AXP20X_DCDC_FREQ;
u32 min, max, def, step;
 
@@ -378,7 +378,7 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
step = 150;
break;
default:
-   dev_err(>dev,
+   dev_err(dev,
"Setting DCDC frequency for unsupported AXP variant\n");
return -EINVAL;
}
@@ -388,13 +388,13 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
 
if (dcdcfreq < min) {
dcdcfreq = min;
-   dev_warn(>dev, "DCDC frequency too low. Set to %ukHz\n",
+   dev_warn(dev, "DCDC frequency too low. Set to %ukHz\n",
 min);
}
 
if (dcdcfreq > max) {
dcdcfreq = max;
-   dev_warn(>dev, "DCDC frequency too high. Set to %ukHz\n",
+   dev_warn(dev, "DCDC frequency too high. Set to %ukHz\n",
 max);
}
 
@@ -404,24 +404,24 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
  AXP20X_FREQ_DCDC_MASK, dcdcfreq);
 }
 
-static int axp20x_regulator_parse_dt(struct platform_device *pdev)
+static int axp20x_regulator_parse_dt(struct device *dev)
 {
struct device_node *np, *regulators;
int ret;
u32 dcdcfreq = 0;
 
-   np = of_node_get(pdev->dev.parent->of_node);
+   np = of_node_get(dev->of_node);
if (!np)
return 0;
 
regulators = of_get_child_by_name(np, "regulators");
if (!regulators) {
-   dev_warn(>dev, "regulators node not found\n");
+   dev_warn(dev, "regulators node not found\n");
} else {
of_property_read_u32(regulators, "x-powers,dcdc-freq", 
);
-   ret = axp20x_set_dcdc_freq(pdev, dcdcfreq);
+   ret = axp20x_set_dcdc_freq(dev, dcdcfreq);
if (ret < 0) {
-   dev_err(>dev, "Error setting dcdc frequency: 
%d\n", ret);
+   dev_err(dev, "Error setting dcdc frequency: %d\n", ret);
return ret;
}
 
@@ -499,11 +499,12 @@ static u32 axp20x_polyphase_slave(struct axp20x_dev 
*axp20x)
 
 static int axp20x_regulator_probe(struct platform_device *pdev)
 {
+   struct device *dev = pdev->dev.parent;
struct regulator_dev *rdev;
-   struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+   struct axp20x_dev *axp20x = dev_get_drvdata(dev);
const struct regulator_desc *regulators;
struct regulator_config config = {
-   .dev = pdev->dev.parent,
+   .dev = dev,
.regmap = axp20x->regmap,
.driver_data = axp20x,
};
@@ -532,7 +533,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dcdc5_ix = AXP22X_DCDC5;
dc1sw_ix = AXP22X_DC1SW;
dc5ldo_ix = AXP22X_DC5LDO;
-   drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
+   drivevbus = of_property_read_bool(dev->of_node,
  "x-powers,drive-vbus-en");
break;
case AXP806_ID:
@@ -555,13 +556,13 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dc5ldo_ix = AXP809_DC5LDO;
break;
default:
-   dev_err(>dev, "Unsupported AXP variant: %ld\n",
+   dev_err(dev, "Unsupported AXP variant: %ld\n",
axp20x->variant);
return -EINVAL;
}
 
/* This only sets the dcdc freq. Ignore any errors */
-   axp20x_regulator_parse_dt(pdev);
+   axp20x_regulator_par

[PATCH 1/3] regulator: axp20x: simplify poly-phase handling

[Jean-Francois Moine]

Building a list (bitmap) of the slaves included in poly-phase groups
at probe startup time simplifies the treatment in the regulator
creation loop.

Signed-off-by: Jean-Francois Moine 
---
 drivers/regulator/axp20x-regulator.c | 45 +---
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 54382ef..4e5e7c8 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -477,30 +477,24 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev 
*rdev, int id, u32 work
 }
 
 /*
- * This function checks whether a regulator is part of a poly-phase
- * output setup based on the registers settings. Returns true if it is.
+ * This function checks which regulators are part of poly-phase
+ * output setups based on the registers settings.
+ * Returns a bitmap of these regulators.
  */
-static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
+static u32 axp20x_polyphase_slave(struct axp20x_dev *axp20x)
 {
-   u32 reg = 0;
-
-   /* Only AXP806 has poly-phase outputs */
-   if (axp20x->variant != AXP806_ID)
-   return false;
+   u32 reg = 0, bitmap = 0;
 
regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, );
 
-   switch (id) {
-   case AXP806_DCDCB:
-   return (((reg & GENMASK(7, 6)) == BIT(6)) ||
-   ((reg & GENMASK(7, 6)) == BIT(7)));
-   case AXP806_DCDCC:
-   return ((reg & GENMASK(7, 6)) == BIT(7));
-   case AXP806_DCDCE:
-   return !!(reg & BIT(5));
-   }
+   if ((reg & GENMASK(7, 6)) == BIT(5))
+   bitmap |= 1 << AXP806_DCDCE;
+   if ((reg & GENMASK(7, 6)) == BIT(6))
+   bitmap |= 1 << AXP806_DCDCB;
+   if ((reg & GENMASK(7, 6)) == BIT(7))
+   bitmap |= (1 << AXP806_DCDCB) | (1 << AXP806_DCDCC);
 
-   return false;
+   return bitmap;
 }
 
 static int axp20x_regulator_probe(struct platform_device *pdev)
@@ -518,6 +512,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
bool drivevbus = false;
+   u32 skip_bitmap = 0;
 
switch (axp20x->variant) {
case AXP202_ID:
@@ -535,6 +530,13 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
case AXP806_ID:
regulators = axp806_regulators;
nregulators = AXP806_REG_ID_MAX;
+
+   /*
+* The regulators which are slave in a poly-phase setup
+* are skipped, as their controls are bound to the master
+* regulator and won't work.
+*/
+   skip_bitmap |= axp20x_polyphase_slave(axp20x);
break;
case AXP809_ID:
regulators = axp809_regulators;
@@ -553,12 +555,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
const struct regulator_desc *desc = [i];
struct regulator_desc *new_desc;
 
-   /*
-* If this regulator is a slave in a poly-phase setup,
-* skip it, as its controls are bound to the master
-* regulator and won't work.
-*/
-   if (axp20x_is_polyphase_slave(axp20x, i))
+   if (skip_bitmap & (1 << i))
continue;
 
/*
-- 
2.10.0

Re: [PATCH v2] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

On Tue, 16 Aug 2016 23:04:47 +0800
Icenowy Zheng  wrote:

> > Also, please, may you give me a pointer to the AXP813 documentation?
> I got it on BaiduPan.
> https://pan.baidu.com/share/link?shareid=120641733=2121502978=169295081716431
> Here's a link, you can download it if you can read Chinese...
> Or at least you can read it online.

I got it. Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

On Tue, 16 Aug 2016 23:04:47 +0800
Icenowy Zheng  wrote:

> > Also, please, may you give me a pointer to the AXP813 documentation?
> I got it on BaiduPan.
> https://pan.baidu.com/share/link?shareid=120641733=2121502978=169295081716431
> Here's a link, you can download it if you can read Chinese...
> Or at least you can read it online.

I got it. Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

On Tue, 16 Aug 2016 19:30:17 +0800
Icenowy Zheng  wrote:

> > The X-Powers AXP803 and AXP813 PMICs are close to the AXP809 with some
> > more outputs.
> AXP803 and AXP813 is quite different.
> AXP803 have 6 DCDCs and 16 LDOs
> AXP813 have 7 DCDCs and 15 LDOs
> and AXP813 have an audio codec.
> 
> AXP803 cannot be handled without extra code.
> 
> (I'm trying to get RSB working in my semi-mainline A64 kernel)

Hi Icenowy,

Interesting.
I did not find the documentation about the AXP813, but looking at the
Banana PI M3 driver (which seems a bit buggy), I found it was very
close to the AXP803.

Which more code do you think is needed for the AXP803?

Also, please, may you give me a pointer to the AXP813 documentation?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

On Tue, 16 Aug 2016 19:30:17 +0800
Icenowy Zheng  wrote:

> > The X-Powers AXP803 and AXP813 PMICs are close to the AXP809 with some
> > more outputs.
> AXP803 and AXP813 is quite different.
> AXP803 have 6 DCDCs and 16 LDOs
> AXP813 have 7 DCDCs and 15 LDOs
> and AXP813 have an audio codec.
> 
> AXP803 cannot be handled without extra code.
> 
> (I'm trying to get RSB working in my semi-mainline A64 kernel)

Hi Icenowy,

Interesting.
I did not find the documentation about the AXP813, but looking at the
Banana PI M3 driver (which seems a bit buggy), I found it was very
close to the AXP803.

Which more code do you think is needed for the AXP803?

Also, please, may you give me a pointer to the AXP813 documentation?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 4/5] clk: sunxi-ng: Add A31/A31s clocks

[Jean-Francois Moine]

On Mon, 15 Aug 2016 16:13:14 +0800
Chen-Yu Tsai  wrote:

> +/*
> + * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from
> + * the base (2x, 4x and 8x), and one variable divider (the one true
> + * pll audio).
> + *
> + * We don't have any need for the variable divider for now, so we just
> + * hardcode it to match with the clock names
> + */
> +#define SUN6I_A31_PLL_AUDIO_REG  0x008
> +
> +static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
> +"osc24M", 0x008,
> +8, 7,/* N */
> +0, 5,/* M */
> +BIT(31), /* gate */
> +BIT(28), /* lock */
> +0);
> +

FYI, as in many other SoCs (A83T/H3/..), the multipliers/dividers from
the base clock (24MHz) do not give an exact rate for standard audio
(44.1kHz and 48kHz). Sigma-Delta Modulation must be used.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 4/5] clk: sunxi-ng: Add A31/A31s clocks

[Jean-Francois Moine]

On Mon, 15 Aug 2016 16:13:14 +0800
Chen-Yu Tsai  wrote:

> +/*
> + * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from
> + * the base (2x, 4x and 8x), and one variable divider (the one true
> + * pll audio).
> + *
> + * We don't have any need for the variable divider for now, so we just
> + * hardcode it to match with the clock names
> + */
> +#define SUN6I_A31_PLL_AUDIO_REG  0x008
> +
> +static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
> +"osc24M", 0x008,
> +8, 7,/* N */
> +0, 5,/* M */
> +BIT(31), /* gate */
> +BIT(28), /* lock */
> +0);
> +

FYI, as in many other SoCs (A83T/H3/..), the multipliers/dividers from
the base clock (24MHz) do not give an exact rate for standard audio
(44.1kHz and 48kHz). Sigma-Delta Modulation must be used.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [linux-sunxi] Re: [PATCH v4 3/7] clk: sunxi: add generic multi-parent bus clock gates driver

[Jean-Francois Moine]

On Tue, 9 Aug 2016 18:02:47 +0800
Chen-Yu Tsai  wrote:

> > The 'parent's of the bus gates are of no interest.
> > They are supposed to be (no clear documentation) apb1, apb2, ahb1 and
> > ahb2, but, as you well noticed in the patch 5/7, these clocks are fixed
> > and have no gate. Some of them are parents of real clocks, but they
> > don't bring anything to the bus gates of the other clocks.
> 
> Yes they are. Some devices, such as UARTs and I2C controllers, need
> to get the clock rate of the gate and calculate the proper internal
> divider.

You are right, the clocks of some subsystems have only a gate, but
these are exceptions.

Look at an ordinary clock, say the mmc0 of the H3.
There is a "bus" gate (see below) in the CCU register 0x60, bit 8, and
the "clock" gate in the CCU register 0x88, bit 31.

The 'simple-gates' says that the "bus gate" is child of ahb1 (in all
sunxi versions, the one prior to 'simple-gate', in the 'simple-gate',
in 'sunxi-ng', and now in André's patch).

But, where do you see a hardware relation between the mmc0 clock and
the ahb1 clock?

> > As I wrote previously, the simplest is to ungate/gate the clocks in
> > both the bus and clock registers on clk_prepare/unprepare.
> > Then, your 'multi-bus-gates' would be simply a generic 'multi-gates'.
> 
> This is somewhat misleading. What "clock" registers are you referring
> to? There are no "bus" registers. The reason we call them "bus clock
> gates" is because they are mashed together, instead of having clearly
> separated registers for each AHB/APB bus.
> 
> And if you want just a generic clock gates driver, we already have
> the "simple-gates" driver.

Maybe I used the wrong words.

The "clock" register is the one which defines the parameters of the
clock (parents, mul/div factors, gate). For the H3 mmc0, it is the
CCU register 0x60.

The "bus" register is one of the so-called "Bus Clock Gating Register"s.
For the H3 mmc0, it is the CCU register 0x88.   

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [linux-sunxi] Re: [PATCH v4 3/7] clk: sunxi: add generic multi-parent bus clock gates driver

[Jean-Francois Moine]

On Tue, 9 Aug 2016 18:02:47 +0800
Chen-Yu Tsai  wrote:

> > The 'parent's of the bus gates are of no interest.
> > They are supposed to be (no clear documentation) apb1, apb2, ahb1 and
> > ahb2, but, as you well noticed in the patch 5/7, these clocks are fixed
> > and have no gate. Some of them are parents of real clocks, but they
> > don't bring anything to the bus gates of the other clocks.
> 
> Yes they are. Some devices, such as UARTs and I2C controllers, need
> to get the clock rate of the gate and calculate the proper internal
> divider.

You are right, the clocks of some subsystems have only a gate, but
these are exceptions.

Look at an ordinary clock, say the mmc0 of the H3.
There is a "bus" gate (see below) in the CCU register 0x60, bit 8, and
the "clock" gate in the CCU register 0x88, bit 31.

The 'simple-gates' says that the "bus gate" is child of ahb1 (in all
sunxi versions, the one prior to 'simple-gate', in the 'simple-gate',
in 'sunxi-ng', and now in André's patch).

But, where do you see a hardware relation between the mmc0 clock and
the ahb1 clock?

> > As I wrote previously, the simplest is to ungate/gate the clocks in
> > both the bus and clock registers on clk_prepare/unprepare.
> > Then, your 'multi-bus-gates' would be simply a generic 'multi-gates'.
> 
> This is somewhat misleading. What "clock" registers are you referring
> to? There are no "bus" registers. The reason we call them "bus clock
> gates" is because they are mashed together, instead of having clearly
> separated registers for each AHB/APB bus.
> 
> And if you want just a generic clock gates driver, we already have
> the "simple-gates" driver.

Maybe I used the wrong words.

The "clock" register is the one which defines the parameters of the
clock (parents, mul/div factors, gate). For the H3 mmc0, it is the
CCU register 0x60.

The "bus" register is one of the so-called "Bus Clock Gating Register"s.
For the H3 mmc0, it is the CCU register 0x88.   

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 3/7] clk: sunxi: add generic multi-parent bus clock gates driver

[Jean-Francois Moine]

On Mon,  8 Aug 2016 18:21:45 +0100
Andre Przywara  wrote:

> The Allwinner H3 SoC introduced bus clock gates with potentially
> different parents per clock gate register. The H3 driver chose to
> hardcode the actual parent clock relation in the code.
> Add a new driver (which has the potential to drive the H3 and also
> the simple clock gates as well) which uses the power of DT to describe
> this relationship in an elegant and flexible way.
> Using one subnode for every parent clock we get away with a single
> DT compatible match, which can be used as a fallback value in the
> actual DTs without the need to add specific compatible strings to the
> code.  This avoids adding a new driver or function for every new SoC.

The 'parent's of the bus gates are of no interest.
They are supposed to be (no clear documentation) apb1, apb2, ahb1 and
ahb2, but, as you well noticed in the patch 5/7, these clocks are fixed
and have no gate. Some of them are parents of real clocks, but they
don't bring anything to the bus gates of the other clocks.

As I wrote previously, the simplest is to ungate/gate the clocks in
both the bus and clock registers on clk_prepare/unprepare.
Then, your 'multi-bus-gates' would be simply a generic 'multi-gates'.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v4 3/7] clk: sunxi: add generic multi-parent bus clock gates driver

[Jean-Francois Moine]

On Mon,  8 Aug 2016 18:21:45 +0100
Andre Przywara  wrote:

> The Allwinner H3 SoC introduced bus clock gates with potentially
> different parents per clock gate register. The H3 driver chose to
> hardcode the actual parent clock relation in the code.
> Add a new driver (which has the potential to drive the H3 and also
> the simple clock gates as well) which uses the power of DT to describe
> this relationship in an elegant and flexible way.
> Using one subnode for every parent clock we get away with a single
> DT compatible match, which can be used as a fallback value in the
> actual DTs without the need to add specific compatible strings to the
> code.  This avoids adding a new driver or function for every new SoC.

The 'parent's of the bus gates are of no interest.
They are supposed to be (no clear documentation) apb1, apb2, ahb1 and
ahb2, but, as you well noticed in the patch 5/7, these clocks are fixed
and have no gate. Some of them are parents of real clocks, but they
don't bring anything to the bus gates of the other clocks.

As I wrote previously, the simplest is to ungate/gate the clocks in
both the bus and clock registers on clk_prepare/unprepare.
Then, your 'multi-bus-gates' would be simply a generic 'multi-gates'.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Mon, 1 Aug 2016 20:01:49 +0800
Chen-Yu Tsai <w...@csie.org> wrote:

> On Mon, Aug 1, 2016 at 8:00 PM, Jean-Francois Moine <moin...@free.fr> wrote:
> > On Mon, 1 Aug 2016 17:13:34 +0800
> > Chen-Yu Tsai <w...@csie.org> wrote:
> >
> >> > But I don't see why you are keeping the simple-gates. The bus gate may
> >> > be ungated/gated when the clock is enabled/disabled, and that's what
> >> > Allwinner's software does.
> >>
> >> For peripherals that have a separate mod clock, having them separate
> >> is a good thing. One example might be the audio codecs. You could ungate
> >> the bus gate to access its registers to program it, but only enable
> >> the mod clock when you actually play something.
> >
> > The roles of the bus gate and the clock gate are the same. I don't see
> > any reason to set one gate without setting the other one. More, the
> > spec says what the bus gate must be enabled before the clock gate (and
> > reverse order while disabling). So, setting both gates in one function
> > call seems safer.
> 
> Wha? Aren't bus gates and clock gates the same thing in this context?

Yes. What is the problem?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Mon, 1 Aug 2016 20:01:49 +0800
Chen-Yu Tsai  wrote:

> On Mon, Aug 1, 2016 at 8:00 PM, Jean-Francois Moine  wrote:
> > On Mon, 1 Aug 2016 17:13:34 +0800
> > Chen-Yu Tsai  wrote:
> >
> >> > But I don't see why you are keeping the simple-gates. The bus gate may
> >> > be ungated/gated when the clock is enabled/disabled, and that's what
> >> > Allwinner's software does.
> >>
> >> For peripherals that have a separate mod clock, having them separate
> >> is a good thing. One example might be the audio codecs. You could ungate
> >> the bus gate to access its registers to program it, but only enable
> >> the mod clock when you actually play something.
> >
> > The roles of the bus gate and the clock gate are the same. I don't see
> > any reason to set one gate without setting the other one. More, the
> > spec says what the bus gate must be enabled before the clock gate (and
> > reverse order while disabling). So, setting both gates in one function
> > call seems safer.
> 
> Wha? Aren't bus gates and clock gates the same thing in this context?

Yes. What is the problem?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Mon, 1 Aug 2016 17:13:34 +0800
Chen-Yu Tsai  wrote:

> > But I don't see why you are keeping the simple-gates. The bus gate may
> > be ungated/gated when the clock is enabled/disabled, and that's what
> > Allwinner's software does.
> 
> For peripherals that have a separate mod clock, having them separate
> is a good thing. One example might be the audio codecs. You could ungate
> the bus gate to access its registers to program it, but only enable
> the mod clock when you actually play something.

The roles of the bus gate and the clock gate are the same. I don't see
any reason to set one gate without setting the other one. More, the
spec says what the bus gate must be enabled before the clock gate (and
reverse order while disabling). So, setting both gates in one function
call seems safer.

Then, if you want to save some power while not playing anything, just do
clk_disable() of the (main and only) i2s clock.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Mon, 1 Aug 2016 17:13:34 +0800
Chen-Yu Tsai  wrote:

> > But I don't see why you are keeping the simple-gates. The bus gate may
> > be ungated/gated when the clock is enabled/disabled, and that's what
> > Allwinner's software does.
> 
> For peripherals that have a separate mod clock, having them separate
> is a good thing. One example might be the audio codecs. You could ungate
> the bus gate to access its registers to program it, but only enable
> the mod clock when you actually play something.

The roles of the bus gate and the clock gate are the same. I don't see
any reason to set one gate without setting the other one. More, the
spec says what the bus gate must be enabled before the clock gate (and
reverse order while disabling). So, setting both gates in one function
call seems safer.

Then, if you want to save some power while not playing anything, just do
clk_disable() of the (main and only) i2s clock.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Mon, 1 Aug 2016 02:43:06 +0100
André Przywara  wrote:

> As this became quite a long read, here a TL;DR:
> - We consider using an SCPI based clock system for the A64, alongside
> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
> specific clocks (apart from the simple-gates).
> - ARM Trusted Firmware provides the SCPI implementation - for now, later
> we may move this into a possible arisc firmware.
> - We upstream some basic DT first, possibly omitting any controversial
> clock parts at all.
> 
> Let me know what you think!

Hi André,

This looks interesting.
As I understand, the clock enable/rate setting functions would be in
the arisc. The arisc firmware would be loaded only once in the Soc and
would contain the code for handling this specific SoC.
>From my calculations, this would save about 1Mb of clock descriptions
in the kernel for a universal Allwinner kernel.

But I don't see why you are keeping the simple-gates. The bus gate may
be ungated/gated when the clock is enabled/disabled, and that's what
Allwinner's software does.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Mon, 1 Aug 2016 02:43:06 +0100
André Przywara  wrote:

> As this became quite a long read, here a TL;DR:
> - We consider using an SCPI based clock system for the A64, alongside
> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
> specific clocks (apart from the simple-gates).
> - ARM Trusted Firmware provides the SCPI implementation - for now, later
> we may move this into a possible arisc firmware.
> - We upstream some basic DT first, possibly omitting any controversial
> clock parts at all.
> 
> Let me know what you think!

Hi André,

This looks interesting.
As I understand, the clock enable/rate setting functions would be in
the arisc. The arisc firmware would be loaded only once in the Soc and
would contain the code for handling this specific SoC.
>From my calculations, this would save about 1Mb of clock descriptions
in the kernel for a universal Allwinner kernel.

But I don't see why you are keeping the simple-gates. The bus gate may
be ungated/gated when the clock is enabled/disabled, and that's what
Allwinner's software does.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] regulator: axp20x: support AXP813 variant

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:19:44 +0200
Maxime Ripard  wrote:

> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 32 -
> >  drivers/mfd/axp20x-rsb.c |  1 +
> >  drivers/mfd/axp20x.c |  3 +
> >  drivers/regulator/axp20x-regulator.c | 82 
> > +++-
> >  include/linux/mfd/axp20x.h   | 38 +++
> >  5 files changed, 153 insertions(+), 3 deletions(-)
> 
> And this needs to be split per logical changes.

There is only one logical change: support the AXP813.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH] regulator: axp20x: support AXP813 variant

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:19:44 +0200
Maxime Ripard  wrote:

> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 32 -
> >  drivers/mfd/axp20x-rsb.c |  1 +
> >  drivers/mfd/axp20x.c |  3 +
> >  drivers/regulator/axp20x-regulator.c | 82 
> > +++-
> >  include/linux/mfd/axp20x.h   | 38 +++
> >  5 files changed, 153 insertions(+), 3 deletions(-)
> 
> And this needs to be split per logical changes.

There is only one logical change: support the AXP813.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:07:05 +0200
Maxime Ripard  wrote:

> > > Let me know what you think,
> > 
> > I don't see the interest to have common code for 32bits and 64bits.
> > The clock driver of a SoC will never evolve, so, it is simpler to
> > copy the source common with the H3 into a clean A64 clock driver.
> 
> I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> a significant number of drivers already between armv7 and armv8, like
> MMC, EMAC, I2C, and so on.
> 
> And I expect to share the data in other SoCs for the A10, A13 and A20
> for example, or A23/A33, which have a lot of clocks in common too.

The interest of your sunxi-ng approach is that the clocks of each SoC
is described in one file. Here you are mixing 2 SoCs in the same source
file. The advantage is lost.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Thu, 28 Jul 2016 22:07:05 +0200
Maxime Ripard  wrote:

> > > Let me know what you think,
> > 
> > I don't see the interest to have common code for 32bits and 64bits.
> > The clock driver of a SoC will never evolve, so, it is simpler to
> > copy the source common with the H3 into a clean A64 clock driver.
> 
> I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> a significant number of drivers already between armv7 and armv8, like
> MMC, EMAC, I2C, and so on.
> 
> And I expect to share the data in other SoCs for the A10, A13 and A20
> for example, or A23/A33, which have a lot of clocks in common too.

The interest of your sunxi-ng approach is that the clocks of each SoC
is described in one file. Here you are mixing 2 SoCs in the same source
file. The advantage is lost.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Thu, 28 Jul 2016 15:28:42 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Wed, Jul 27, 2016 at 10:36:49AM +0200, Jean-Francois Moine wrote:
> > On Wed, 27 Jul 2016 09:40:20 +0200
> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote:
> > 
> > > > > Parenting functions would also not work as expected,
> > > > > clk_hw_get_parent_by_index being the obvious example, in that case
> > > > > returning the empty string for an invalid parent, while it should
> > > > > really return NULL.
> > > > 
> > > > I don't see why the clock should be orphan.
> > > > Then, when a parent is "", clk_hw_get_parent_by_index() returns NULL.
> > > 
> > > Why? It should return NULL when there's no parent, while you
> > > explicitly registered a parent.
> > 
> > "" is not an existing parent. It could be "none" / "dum" / "toto" / ...
> > with the same result: 'this index cannot be used in mux'.
> 
> And the clock is marked as orphan, while it really isn't.

Sorry for I don't follow you.

A clock is orphan when it has no parent. In our case, there are many
possible parents and, at startup time, the hardware or the boot sets
the mux to point to a real parent, with an index out of the usused
values.
Yes, the clock may be orphan, as the other clocks, but just the time
this real parent becomes visible.

So, how could such a clock stay marked as orphan?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Thu, 28 Jul 2016 15:28:42 +0200
Maxime Ripard  wrote:

> On Wed, Jul 27, 2016 at 10:36:49AM +0200, Jean-Francois Moine wrote:
> > On Wed, 27 Jul 2016 09:40:20 +0200
> > Maxime Ripard  wrote:
> > 
> > > > > Parenting functions would also not work as expected,
> > > > > clk_hw_get_parent_by_index being the obvious example, in that case
> > > > > returning the empty string for an invalid parent, while it should
> > > > > really return NULL.
> > > > 
> > > > I don't see why the clock should be orphan.
> > > > Then, when a parent is "", clk_hw_get_parent_by_index() returns NULL.
> > > 
> > > Why? It should return NULL when there's no parent, while you
> > > explicitly registered a parent.
> > 
> > "" is not an existing parent. It could be "none" / "dum" / "toto" / ...
> > with the same result: 'this index cannot be used in mux'.
> 
> And the clock is marked as orphan, while it really isn't.

Sorry for I don't follow you.

A clock is orphan when it has no parent. In our case, there are many
possible parents and, at startup time, the hardware or the boot sets
the mux to point to a real parent, with an index out of the usused
values.
Yes, the clock may be orphan, as the other clocks, but just the time
this real parent becomes visible.

So, how could such a clock stay marked as orphan?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Tue, 26 Jul 2016 22:30:28 +0200
Maxime Ripard  wrote:

> ere is the previous A64 patches made by Andre [1], reworked to use
> the new sunxi-ng clock framework.
> 
> This uses the current H3 clock code, as both are really similar. The
> first patches are just meant to rework slightly the H3 code, before
> introducing the A64-related patches.
> 
> Some WiP stuff have been removed, such as the MMC part, but this serie
> already has a decent amount of devices supported: uart, i2c, rsb, etc.
> 
> Let me know what you think,

I don't see the interest to have common code for 32bits and 64bits.
The clock driver of a SoC will never evolve, so, it is simpler to
copy the source common with the H3 into a clean A64 clock driver.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

[Jean-Francois Moine]

On Tue, 26 Jul 2016 22:30:28 +0200
Maxime Ripard  wrote:

> ere is the previous A64 patches made by Andre [1], reworked to use
> the new sunxi-ng clock framework.
> 
> This uses the current H3 clock code, as both are really similar. The
> first patches are just meant to rework slightly the H3 code, before
> introducing the A64-related patches.
> 
> Some WiP stuff have been removed, such as the MMC part, but this serie
> already has a decent amount of devices supported: uart, i2c, rsb, etc.
> 
> Let me know what you think,

I don't see the interest to have common code for 32bits and 64bits.
The clock driver of a SoC will never evolve, so, it is simpler to
copy the source common with the H3 into a clean A64 clock driver.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 5/9] clk: sunxi-ng: mux: support fixed pre-dividers on multiple parents

[Jean-Francois Moine]

On Tue, 26 Jul 2016 15:04:27 +0800
Chen-Yu Tsai  wrote:

> Some clocks on the A31 have fixed pre-dividers on multiple parents.
> Add support for them.

This could be done by intermediate clocks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 5/9] clk: sunxi-ng: mux: support fixed pre-dividers on multiple parents

[Jean-Francois Moine]

On Tue, 26 Jul 2016 15:04:27 +0800
Chen-Yu Tsai  wrote:

> Some clocks on the A31 have fixed pre-dividers on multiple parents.
> Add support for them.

This could be done by intermediate clocks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Wed, 27 Jul 2016 09:40:20 +0200
Maxime Ripard  wrote:

> > > Parenting functions would also not work as expected,
> > > clk_hw_get_parent_by_index being the obvious example, in that case
> > > returning the empty string for an invalid parent, while it should
> > > really return NULL.
> > 
> > I don't see why the clock should be orphan.
> > Then, when a parent is "", clk_hw_get_parent_by_index() returns NULL.
> 
> Why? It should return NULL when there's no parent, while you
> explicitly registered a parent.

"" is not an existing parent. It could be "none" / "dum" / "toto" / ...
with the same result: 'this index cannot be used in mux'.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Wed, 27 Jul 2016 09:40:20 +0200
Maxime Ripard  wrote:

> > > Parenting functions would also not work as expected,
> > > clk_hw_get_parent_by_index being the obvious example, in that case
> > > returning the empty string for an invalid parent, while it should
> > > really return NULL.
> > 
> > I don't see why the clock should be orphan.
> > Then, when a parent is "", clk_hw_get_parent_by_index() returns NULL.
> 
> Why? It should return NULL when there's no parent, while you
> explicitly registered a parent.

"" is not an existing parent. It could be "none" / "dum" / "toto" / ...
with the same result: 'this index cannot be used in mux'.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Wed, 27 Jul 2016 08:59:34 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Tue, Jul 26, 2016 at 07:43:06PM +0200, Jean-Francois Moine wrote:
> > On Tue, 26 Jul 2016 15:04:26 +0800
> > Chen-Yu Tsai <w...@csie.org> wrote:
> > 
> > > Some clock muxes have holes, i.e. invalid or unconnected inputs,
> > > between parent mux values.
> > > 
> > > Add support for specifying a mux table to map clock parents to
> > > mux values.
> > 
> > Putting empty strings in the holes should work. No?
> > Ex:
> > 
> > static const char * const csi_mclk_parents[] =
> > { "pll-video0", "pll-video1", "", "", "", "osc24M" };
> 
> Not really. The clock would be declared as orphan, while it's really
> not.
> 
> Parenting functions would also not work as expected,
> clk_hw_get_parent_by_index being the obvious example, in that case
> returning the empty string for an invalid parent, while it should
> really return NULL.

I don't see why the clock should be orphan.
Then, when a parent is "", clk_hw_get_parent_by_index() returns NULL.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Wed, 27 Jul 2016 08:59:34 +0200
Maxime Ripard  wrote:

> On Tue, Jul 26, 2016 at 07:43:06PM +0200, Jean-Francois Moine wrote:
> > On Tue, 26 Jul 2016 15:04:26 +0800
> > Chen-Yu Tsai  wrote:
> > 
> > > Some clock muxes have holes, i.e. invalid or unconnected inputs,
> > > between parent mux values.
> > > 
> > > Add support for specifying a mux table to map clock parents to
> > > mux values.
> > 
> > Putting empty strings in the holes should work. No?
> > Ex:
> > 
> > static const char * const csi_mclk_parents[] =
> > { "pll-video0", "pll-video1", "", "", "", "osc24M" };
> 
> Not really. The clock would be declared as orphan, while it's really
> not.
> 
> Parenting functions would also not work as expected,
> clk_hw_get_parent_by_index being the obvious example, in that case
> returning the empty string for an invalid parent, while it should
> really return NULL.

I don't see why the clock should be orphan.
Then, when a parent is "", clk_hw_get_parent_by_index() returns NULL.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Tue, 26 Jul 2016 15:04:26 +0800
Chen-Yu Tsai  wrote:

> Some clock muxes have holes, i.e. invalid or unconnected inputs,
> between parent mux values.
> 
> Add support for specifying a mux table to map clock parents to
> mux values.

Putting empty strings in the holes should work. No?
Ex:

static const char * const csi_mclk_parents[] =
{ "pll-video0", "pll-video1", "", "", "", "osc24M" };

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Jean-Francois Moine]

On Tue, 26 Jul 2016 15:04:26 +0800
Chen-Yu Tsai  wrote:

> Some clock muxes have holes, i.e. invalid or unconnected inputs,
> between parent mux values.
> 
> Add support for specifying a mux table to map clock parents to
> mux values.

Putting empty strings in the holes should work. No?
Ex:

static const char * const csi_mclk_parents[] =
{ "pll-video0", "pll-video1", "", "", "", "osc24M" };

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 8/9] clk: sunxi-ng: Add A31/A31s clocks

[Jean-Francois Moine]

On Tue, 26 Jul 2016 15:04:30 +0800
Chen-Yu Tsai  wrote:

> +static const struct ccu_mux_fixed_prediv clk_out_predivs[] = {
> + { .index = 0, .div = 750, },
> + { .index = 3, .div = 4, },
> + { .index = 4, .div = 4, },
> +};

No end of table.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH 8/9] clk: sunxi-ng: Add A31/A31s clocks

[Jean-Francois Moine]

On Tue, 26 Jul 2016 15:04:30 +0800
Chen-Yu Tsai  wrote:

> +static const struct ccu_mux_fixed_prediv clk_out_predivs[] = {
> + { .index = 0, .div = 750, },
> + { .index = 3, .div = 4, },
> + { .index = 4, .div = 4, },
> +};

No end of table.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 15 Jul 2016 12:38:54 +0200
Ondřej Jirman  wrote:

> > If so, then yes, trying to switch to the 24MHz oscillator before
> > applying the factors, and then switching back when the PLL is stable
> > would be a nice solution.
> > 
> > I just checked, and all the SoCs we've had so far have that
> > possibility, so if it works, for now, I'd like to stick to that.
> 
> It would need to be tested. U-boot does the change only once, while the
> kernel would be doing it all the time and between various frequencies
> and PLL settings. So the issues may show up with this solution too.

I don't think this is a good idea: the CPU clock may be changed at any
time with the CPUFreq governor. I don't see the system moving from
1008MHz to 24MHz and then to 1200MHz when some computation is needed!

BTW, Ondřej, in my BPi M2+, I tried to change the CPU clock with your
code at kernel start time from 792MHz to 1008MHz, but the hardware
(arisc?) set an other value, and the system speed was lower than before
(the PLL-CPUx register is 0x90031521 on boot, I want to set it to
1410 and I read 0x91031f33 - sorry, I did not have a look at the
CPU SD pattern). Do you know why?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 15 Jul 2016 12:38:54 +0200
Ondřej Jirman  wrote:

> > If so, then yes, trying to switch to the 24MHz oscillator before
> > applying the factors, and then switching back when the PLL is stable
> > would be a nice solution.
> > 
> > I just checked, and all the SoCs we've had so far have that
> > possibility, so if it works, for now, I'd like to stick to that.
> 
> It would need to be tested. U-boot does the change only once, while the
> kernel would be doing it all the time and between various frequencies
> and PLL settings. So the issues may show up with this solution too.

I don't think this is a good idea: the CPU clock may be changed at any
time with the CPUFreq governor. I don't see the system moving from
1008MHz to 24MHz and then to 1200MHz when some computation is needed!

BTW, Ondřej, in my BPi M2+, I tried to change the CPU clock with your
code at kernel start time from 792MHz to 1008MHz, but the hardware
(arisc?) set an other value, and the system speed was lower than before
(the PLL-CPUx register is 0x90031521 on boot, I want to set it to
1410 and I read 0x91031f33 - sorry, I did not have a look at the
CPU SD pattern). Do you know why?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 1 Jul 2016 08:34:21 +0200
Ondřej Jirman  wrote:

> > The documentation says that only the CPU and DDR PLLs can be dynamically
> > changed after boot.
> 
> The question is what exactly is meant by after boot. :) Anyway, if the
> kernel has no business changing some other PLLs, if there's code for
> changing them, should it be dropped?

No, because all the other PLLs may not be initialized by the U-boot
(audio, video, gpu...), and also, their rate may be changed safely by
stopping them (gate).

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 1 Jul 2016 08:34:21 +0200
Ondřej Jirman  wrote:

> > The documentation says that only the CPU and DDR PLLs can be dynamically
> > changed after boot.
> 
> The question is what exactly is meant by after boot. :) Anyway, if the
> kernel has no business changing some other PLLs, if there's code for
> changing them, should it be dropped?

No, because all the other PLLs may not be initialized by the U-boot
(audio, video, gpu...), and also, their rate may be changed safely by
stopping them (gate).

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 1 Jul 2016 02:50:57 +0200
Ondřej Jirman  wrote:

> > Since this is really specific, I guess you could simply make the
> > clk_ops for the nkmp clocks public, and just re-implement set_rate
> > using that logic.
> 
> I would argue that this may be necessary for other PLL clocks too, if
> you can get out of bounds output frequency, by changing the dividers too
> early or too late. So perhaps this code should be generalized for other
> PLL clocks too, instead.

The documentation says that only the CPU and DDR PLLs can be dynamically
changed after boot.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 1 Jul 2016 02:50:57 +0200
Ondřej Jirman  wrote:

> > Since this is really specific, I guess you could simply make the
> > clk_ops for the nkmp clocks public, and just re-implement set_rate
> > using that logic.
> 
> I would argue that this may be necessary for other PLL clocks too, if
> you can get out of bounds output frequency, by changing the dividers too
> early or too late. So perhaps this code should be generalized for other
> PLL clocks too, instead.

The documentation says that only the CPU and DDR PLLs can be dynamically
changed after boot.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/