Re: [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

On Thu, 01 Dec 2016 12:41:20 +0200
Laurent Pinchart  wrote:

> > > If a DVI connector instead of a HDMI connector is soldered, how
> > > should such a device tree be written?
> > 
> > Use a dvi-connector instead :)
> 
> The HDMI encoder DT node doesn't (and certainly shouldn't) report what type 
> of 
> connector is mounted on the board. Having a connector node in DT makes the 
> connector type available to the system, allowing the DRM driver to expose the 
> right connector type to userspace (it would be confusing for the user to 
> report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).

The connector type, HDMI or DVI, is known by the EDID.
The user is not interested by the software indication of the connector
type: (s)he knows it because (s)he connected him/herself the display
device.
And the DRM driver does not do anything from the knowledge of the
connector type in the DT. Only the EDID may tell if the display device
may do audio streaming (direct HDMI with audio capability) or not
(direct HDMI without audio, HDMI to DVI cable, DVI physical connector).

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

On Wed, 30 Nov 2016 11:52:25 +0200
Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote:

> Hi Jean-François,
> 
> On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
> > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
> > >> Well, I don't see what this connector can be.
> > >> May you give me a DT example?
> > > 
> > > Sure.
> > > 
> > > arch/arm/boot/dts/r8a7791-koelsch.dts
> > > 
> > > /* HDMI encoder */
[snip]
> > > /* HDMI connector */
> > > 
> > > hdmi-out {
> > > compatible = "hdmi-connector";
> > > type = "a";
> > > 
> > > port {
> > > hdmi_con: endpoint {
> > > remote-endpoint = <_out>;
> > > };
> > > };
> > > };
[snip]
> > - what does the software do with the connector type?
> 
> That's up to the software to decide, the DT bindings should describe the 
> hardware in the most accurate and usable way for the OS as possible. One of 
> my 
> longer term goals is to add connector drivers to handle DDC and HPD when 
> they're not handled by the encoder (they are in the above example).
> 
> If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD 
> to a GPIO, we would have
> 
>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";
>   /* I2C bus and GPIO references are made up for the example */
>   ddc-i2c-bus = <>;
>   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>
> 
>   port {
>   hdmi_con: endpoint {
>   remote-endpoint = <_out>;
>   };
>   };
>   };
> 
> and both HPD and EDID reading should be handled by the connector driver.
[snip]

Hi Laurent,

OK. I understand. This connector complexity should be added in all DTs,
and the same code would be used.

Actually, for component binding, I use drm_of_component_probe():

- from the DRM master, loop on the "ports" phandle array and bind the
  CRTCs,

- for each CRTC, loop on the first remote port level and bind the
  encoders/connectors

Now, this should be:

- from the DRM master, loop on the first remote ports level and bind
  the CRTCs,

- for each CRTC, loop on the second remote port level and bind the
  encoders (and bridges?),

- for each encoder, loop on the third remote port level and bind the
  connectors.

Then, it would be nice to have a generic function for doing this job.

Otherwise, from your description:

>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";
>   /* I2C bus and GPIO references are made up for the example */
>   ddc-i2c-bus = <>;
>   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>

the "hdmi-connector" is a big piece of software. It must handle a lot
of more and more exotic connectors.
So, I hope that you have written a "simple-hdmi-connector" which does
nothing but setting the connector type.
Where is it?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

On Wed, 30 Nov 2016 10:20:21 +0200
Laurent Pinchart  wrote:

> > Well, I don't see what this connector can be.
> > May you give me a DT example?
> 
> Sure.
> 
> arch/arm/boot/dts/r8a7791-koelsch.dts
> 
> /* HDMI encoder */
> 
> hdmi@39 {
> compatible = "adi,adv7511w";
> reg = <0x39>;
> interrupt-parent = <>;
> interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
> 
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> adi,input-style = <1>;
> adi,input-justification = "evenly";
> 
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> 
> port@0 {
> reg = <0>;
> adv7511_in: endpoint {
> remote-endpoint = <_out_rgb>;
> };
> };
> 
> port@1 {
> reg = <1>;
> adv7511_out: endpoint {
> remote-endpoint = <_con>;
> };
> };
> };
> };
> 
> /* HDMI connector */
> 
> hdmi-out {
> compatible = "hdmi-connector";
> type = "a";
> 
> port {
> hdmi_con: endpoint {
> remote-endpoint = <_out>;
> };
> };
> };

Hi Laurent,

Sorry for I don't see the interest:
- it is obvious that the HDMI connector is a 'hdmi-connector'!
- the physical connector type may be changed on any board by a soldering
  iron or a connector to connector cable.
- what does the software do with the connector type?
- why not to put the connector information in the HDMI device?

And, if I follow you, the graph of ports could also be used to describe
the way the various parts of the SoCs are powered, to describe the pin
connections, to describe the USB connectors, to describe the board
internal hubs and bridges...

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

[Jean-Francois Moine]

On Tue, 29 Nov 2016 22:36:50 +0100
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3 SoCs, and
> > some H3 boards, but it could be used/extended for other SoCs
> > (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> 
> Honestly, I'm getting a bit worried by the fact that you ignore
> reviews.
> 
> On the important reviews that you got that are to be seen as major
> issues that block the inclusion, we have:
>   - The fact that the HDMI driver is actually just a designware IP,
> and while you should use the driver that already exists, you just
> duplicated all that code.

The DW registers in the A83T and H3 are obfuscated, so, the code in
bridge/DW cannot be used as it is. There should be either a translation
table or a function to compute the register addresses.

More, it is not sure that the bridge/DW code would work with
Allwinner's SoCs. It seems that they got some schematics from
DesignWare, but, is it really the same hardware? Also, if some changes
had to be done in the bridge code, I could not check if this would
break or not the other SoCs.

Eventually, I went the same way as omap/hdmi5: different driver.

>   - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> graph to model the connection between the display engine and the
> TCON. Something that Laurent also pointed out in this version.

I simply use the drm function drm_of_component_probe().
If this one is in the DRM core, why should I not use it?
If it must not be used, it would be nice to mark it as deprecated and
to update the code of the drivers which are using it.

>   - The fact that you ignored that you needed an HDMI connector node
> as a child of the HDMI controller. This has been reported by Rob
> (v6) and yet again in this version by Laurent.

As I don't know what is a DT 'connector', I cannot go further.
I hope Laurent will give me clearer explanations and a real example.

>   - And finally the fact that we can't have several display engine in
> parallel, if needs be. This has happened in the past already on
> Allwinner SoCs, so it's definitely something we should consider in
> the DT bindings, since we can't break them.

IIRC, I proposed my driver before yours, and the DE2 is completely
different from the other display engines.
What you are telling is "add more code to already complex code and have
a big driver for all SoCs in each kernels".
I think it should be better to have small modules, each one treating
specific hardware, and to let only the needed code in the kernel memory
at startup time.

> Until those are fixed, I cannot see how this driver can be merged,
> unfortunately.

No problem. I just wanted to help people by giving the job I did on the
boards I have. My boards are working for almost one year, fine enough
for I use them as daily desktop computers. I don't want to spend one
more year for having my code in the Linux kernel: there are so much
other exciting things to do...

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

On Tue, 29 Nov 2016 22:10:01 +0200
Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote:

> Hi Jean-François,
> 
> On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> > On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> > >>> You need a third port for the HDMI encoder output, connected to an
> > >>> HDMI connector DT node.
> > >> 
> > >> I don't see what you mean. The HDMI device is both the encoder
> > >> and connector (as the TDA998x):
> > >
> > > The driver might create both an encoder and a connector, but I very much
> > > doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector,
> > > unless the SoC package has an HDMI connector coming out of it :-)
> > > 
> > >> plane -> DE2 mixer ---> TCON -> HDMI -> display device
> > >> - plane --- CRTC -   - encoder  \
> > >>connector -- (HDMI cable)
> > >>  audio-controller -   - audio-codec /
> > 
> > The schema is the same as the Dove Cubox: the TDA998x is just a chip
> > with some wires going out and the physical connector is supposed to be
> > at the end of the wires.
> 
> I've missed the Dove Cubox DT bindings when they were submitted. Fortunately 
> (or unfortunately for you, depending on how you look at it ;-)) I've paid 
> more 
> attention this time.
> 
> > Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> > the physical connector. Which software entity do you want to add?
> 
> I don't want to add a software entity, I just want to model the connector in 
> DT as it's present in the system. Even though that's more common for other 
> bus 
> types than HDMI (LVDS for instance) it wouldn't be inconceivable to connect 
> the HDMI signals to an on-board chim instead of an HDMI connector, so the 
> HDMI 
> encoder output should be modelled by a port and connected to a connector DT 
> node in this case.

Well, I don't see what this connector can be.
May you give me a DT example?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

On Tue, 29 Nov 2016 21:33 +0200
Laurent Pinchart  wrote:

> > > You need a third port for the HDMI encoder output, connected to an HDMI
> > > connector DT node.
> > 
> > I don't see what you mean. The HDMI device is both the encoder
> > and connector (as the TDA998x):
> 
> The driver might create both an encoder and a connector, but I very much 
> doubt 
> that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector, unless 
> the 
> SoC package has an HDMI connector coming out of it :-)
> 
> > plane -> DE2 mixer ---> TCON -> HDMI -> display device
> > - plane --- CRTC -   - encoder  \
> >connector -- (HDMI cable)
> >  audio-controller -   - audio-codec /

The schema is the same as the Dove Cubox: the TDA998x is just a chip
with some wires going out and the physical connector is supposed to be
at the end of the wires.

Here, the HDMI pins of the SoC go to a pure hardware chip and then to
the physical connector. Which software entity do you want to add?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

On Tue, 29 Nov 2016 20:46:22 +0200
Laurent Pinchart  wrote:
[snip]
> > +Example:
> > +
> > +   hdmi: hdmi@01ee {
> > +   compatible = "allwinner,sun8i-a83t-hdmi";
> > +   reg = <0x01ee 0x2>;
> > +   clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
> > +< CLK_HDMI_DDC>;
> > +   clock-names = "bus", "clock", "ddc-clock";
> > +   resets = < RST_HDMI0>, < RST_HDMI1>;
> > +   reset-names = "hdmi0", "hdmi1";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins_a>;
> > +   status = "disabled";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   port@0 {/* video */
> > +   reg = <0>;
> > +   hdmi_tcon1: endpoint {
> > +   remote-endpoint = <_hdmi>;
> > +   };
> > +   };
> > +   port@1 {/* audio */
> > +   reg = <1>;
> > +   hdmi_i2s2: endpoint {
> > +   remote-endpoint = <_hdmi>;
> > +   };
> > +   };
> 
> You need a third port for the HDMI encoder output, connected to an HDMI 
> connector DT node.

I don't see what you mean. The HDMI device is both the encoder
and connector (as the TDA998x):

plane -> DE2 mixer ---> TCON -> HDMI -> display device
- plane --- CRTC -   - encoder  \
   connector -- (HDMI cable)
 audio-controller -   - audio-codec /

> > +   };

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v7 3/8] drm: sun8i: add HDMI video support to A83T and H3

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/gpu/drm/sun8i/Kconfig   |   7 +
 drivers/gpu/drm/sun8i/Makefile  |   2 +
 drivers/gpu/drm/sun8i/de2_hdmi.c| 440 +++
 drivers/gpu/drm/sun8i/de2_hdmi.h|  51 +++
 drivers/gpu/drm/sun8i/de2_hdmi_io.c | 843 
 5 files changed, 1343 insertions(+)
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c

diff --git a/drivers/gpu/drm/sun8i/Kconfig b/drivers/gpu/drm/sun8i/Kconfig
index 6940895..5c4607b 100644
--- a/drivers/gpu/drm/sun8i/Kconfig
+++ b/drivers/gpu/drm/sun8i/Kconfig
@@ -17,3 +17,10 @@ config DRM_SUN8I_DE2
  Choose this option if your Allwinner chipset has the DE2 interface
  as the A64, A83T and H3. If M is selected the module will be called
  sun8i-de2-drm.
+
+config DRM_SUN8I_DE2_HDMI
+   tristate "Support for DE2 HDMI"
+   depends on DRM_SUN8I_DE2
+   help
+ Choose this option if you use want HDMI on DE2.
+ If M is selected the module will be called sun8i-de2-hdmi.
diff --git a/drivers/gpu/drm/sun8i/Makefile b/drivers/gpu/drm/sun8i/Makefile
index f107919..6ba97c2 100644
--- a/drivers/gpu/drm/sun8i/Makefile
+++ b/drivers/gpu/drm/sun8i/Makefile
@@ -3,5 +3,7 @@
 #
 
 sun8i-de2-drm-objs := de2_drv.o de2_crtc.o de2_plane.o
+sun8i-de2-hdmi-objs := de2_hdmi.o de2_hdmi_io.o
 
 obj-$(CONFIG_DRM_SUN8I_DE2) += sun8i-de2-drm.o
+obj-$(CONFIG_DRM_SUN8I_DE2_HDMI) += sun8i-de2-hdmi.o
diff --git a/drivers/gpu/drm/sun8i/de2_hdmi.c b/drivers/gpu/drm/sun8i/de2_hdmi.c
new file mode 100644
index 000..9ff6132
--- /dev/null
+++ b/drivers/gpu/drm/sun8i/de2_hdmi.c
@@ -0,0 +1,440 @@
+/*
+ * Allwinner DRM driver - HDMI
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ *
+ * 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 
+
+#include "de2_hdmi.h"
+
+static const struct of_device_id de2_hdmi_dt_ids[] = {
+   { .compatible = "allwinner,sun8i-a83t-hdmi",
+   .data = (void *) SOC_A83T },
+   { .compatible = "allwinner,sun8i-h3-hdmi",
+   .data = (void *) SOC_H3 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, de2_hdmi_dt_ids);
+
+#define conn_to_priv(x) \
+   container_of(x, struct de2_hdmi_priv, connector)
+
+#define enc_to_priv(x) \
+   container_of(x, struct de2_hdmi_priv, encoder)
+
+/* --- encoder functions --- */
+
+static int de2_hdmi_set_clock(struct de2_hdmi_priv *priv,
+   int rate)
+{
+   struct clk *parent_clk;
+   u32 parent_rate;
+   int ret;
+
+   /* determine and set the best rate for the parent clock (pll-video) */
+   if ((27 * 2) % rate == 0)
+   parent_rate = 27000;
+   else if (297000 % rate == 0)
+   parent_rate = 29700;
+   else
+   return -EINVAL; /* unsupported clock */
+
+   parent_clk = clk_get_parent(priv->clk);
+
+   ret = clk_set_rate(parent_clk, parent_rate);
+   if (ret) {
+   dev_err(priv->dev, "set parent rate failed %d\n", ret);
+   return ret;
+   }
+   ret = clk_set_rate(priv->clk, rate * 1000);
+   if (ret)
+   dev_err(priv->dev, "set rate failed %d\n", ret);
+
+   return ret;
+}
+
+static void de2_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+   struct de2_hdmi_priv *priv = enc_to_priv(encoder);
+
+   priv->cea_mode = drm_match_cea_mode(mode);
+
+   DRM_DEBUG_DRIVER("cea_mode %d\n", priv->cea_mode);
+
+   if (de2_hdmi_set_clock(priv, mode->clock) < 0)
+   return;
+
+   mutex_lock(>mutex);
+   hdmi_io_mode_set(priv, mode);
+   mutex_unlock(>mutex);
+}
+
+static void de2_hdmi_encoder_enable(struct drm_encoder *encoder)
+{
+   struct de2_hdmi_priv *priv = enc_to_priv(encoder);
+
+   mutex_lock(>mutex);
+   hdmi_io_video_on(priv);
+   mutex_unlock(>mutex);
+}
+
+static void de2_hdmi_encoder_disable(struct drm_encoder *encoder)
+{
+   struct de2_hdmi_priv *priv = enc_to_priv(encoder);
+
+   mutex_lock(>mutex);
+   hdmi_io_video_off(priv);
+   mutex_unlock(>mutex);
+}
+
+static const struct drm_encoder_helper_funcs de2_hdmi_encoder_helper_funcs = {
+   .

[linux-sunxi] [PATCH v7 2/8] drm/sun8i: Add DT bindings documentation of Allwinner DE2

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 .../bindings/display/sunxi/sun8i-de2.txt   | 121 +
 1 file changed, 121 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
new file mode 100644
index 000..edf38b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
@@ -0,0 +1,121 @@
+Allwinner sun8i Display Engine 2 subsystem
+==
+
+The Allwinner DE2 subsystem contains a display controller (DE2),
+one or two LCD controllers (Timing CONtrollers) and their external
+interfaces (encoders/connectors).
+
+  +---+
+  | DE2   |
+  |   |
+  | +---+ |
+  plane --->|   | |   +--+
+  | | mixer |>| TCON |---> encoder  ---> display
+  plane --->|   | |   +--+ connector device
+  | +---+ |
+  |   |
+  | +---+ |
+  plane --->|   | |   +--+
+  | | mixer |>| TCON |---> encoder  ---> display
+  plane --->|   | |   +--+ connector device
+  | +---+ |
+  +---+
+
+The DE2 contains a processor which mixes the input planes and creates
+the images which are sent to the TCONs.
+From the software point of vue, there are 2 independent real-time
+mixers, each one being statically associated to one TCON.
+
+The TCONs adjust the image format to the one of the display device.
+
+Display controller (DE2)
+
+
+Required properties:
+
+- compatible: value should be one of the following
+   "allwinner,sun8i-a83t-display-engine"
+   "allwinner,sun8i-h3-display-engine"
+
+- reg: base address and size of the I/O memory
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: must contain
+   "bus": bus gate
+   "clock": clock
+
+- resets: phandle to the reset of the device
+
+- ports: must contain a list of 2 phandles, indexed by mixer number,
+   and pointing to display interface ports of TCONs
+
+LCD controller (TCON)
+=
+
+Required properties:
+
+- compatible: should be
+   "allwinner,sun8i-a83t-tcon"
+
+- reg: base address and size of the I/O memory
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: must contain
+   "bus": bus gate
+   "clock": pixel clock
+
+- resets: phandle to the reset of the device
+
+- interrupts: interrupt number for the TCON
+
+- port: port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   de: de-controller@0100 {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   reg = <0x0100 0x40>;
+   clocks = < CLK_BUS_DE>, < CLK_DE>;
+   clock-names = "bus", "clock";
+   resets = < RST_BUS_DE>;
+   ports = <_p>, <_p>;
+   };
+
+   tcon0: lcd-controller@01c0c000 {
+   compatible = "allwinner,sun8i-a83t-tcon";
+   reg = <0x01c0c000 0x400>;
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "bus", "clock";
+   resets = < RST_BUS_TCON0>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   tcon0_p: port {
+   tcon0_hdmi: endpoint {
+   remote-endpoint = <_tcon0>;
+   };
+   };
+   };
+
+   /* not used */
+   tcon1: lcd-controller@01c0d000 {
+   compatible = "allwinner,sun8i-h3-tcon";
+   reg = <0x01c0d000 0x400>;
+   clocks = < CLK_BUS_TCON1>,
+< CLK_TCON0>;  /* no clock */
+   clock-names = "bus", "clock";
+   interrupts = ;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   tcon1_p: port {
+   endpoint {
+   /* empty */
+   };
+   };
+   };
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 .../devicetree/bindings/display/sunxi/hdmi.txt | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt

diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt 
b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
new file mode 100644
index 000..1e107cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
@@ -0,0 +1,56 @@
+Allwinner HDMI Transmitter
+==
+
+The Allwinner HDMI transmitters are included in the SoCs.
+They support audio and video.
+
+Required properties:
+ - compatible : should be one of
+   "allwinner,sun8i-a83t-hdmi"
+   "allwinner,sun8i-h3-hdmi"
+ - reg: base address and size of the I/O memory
+ - clocks : phandles to the HDMI clocks as described in
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+ - clock-names : must be
+   "bus" : bus gate
+   "clock" : streaming clock
+   "ddc-clock" : DDC clock
+ - resets : One or two phandles to the HDMI resets
+ - reset-names : when 2 phandles, must be
+   "hdmi0" and "hdmi1"
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+
+Required nodes:
+ - port: Audio and video input port nodes with endpoint definitions
+   as defined in Documentation/devicetree/bindings/graph.txt.
+   port@0 is video and port@1 is audio.
+
+Example:
+
+   hdmi: hdmi@01ee {
+   compatible = "allwinner,sun8i-a83t-hdmi";
+   reg = <0x01ee 0x2>;
+   clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
+< CLK_HDMI_DDC>;
+   clock-names = "bus", "clock", "ddc-clock";
+   resets = < RST_HDMI0>, < RST_HDMI1>;
+   reset-names = "hdmi0", "hdmi1";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {/* video */
+   reg = <0>;
+   hdmi_tcon1: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   port@1 {/* audio */
+   reg = <1>;
+   hdmi_i2s2: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   };
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v7 6/8] ARM: dts: sun8i-h3: add HDMI video nodes

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
Note 1:
 The DE clock is not set in the driver. Instead, it is set at system
 startup time by 'assigned-clocks', but there is a problem in sunxi-ng
 which uses readl_relaxed_poll_timeout(), and, as noticed by
 Ondřej Jirman, this function is not available at startup time.
 The fix of this problem is not part of this patchset series.
Note 2:
 The DE clock is set to a high enough rate (432MHz). It seems that
 this is needed to handle 4K video.
 But, as the proposed DE driver does not treat yet 4K video, the clock
 could be set to a lower rate. For example, the default rate for the A83T
 is 250MHz (no 4K video).
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 65 +
 1 file changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index fca66bf..1aa087d 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -140,6 +140,16 @@
#size-cells = <1>;
ranges;
 
+   de: de-controller@0100 {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   reg = <0x0100 0x40>;
+   clocks = < CLK_BUS_DE>, < CLK_DE>;
+   clock-names = "bus", "clock";
+   resets = < RST_BUS_DE>;
+   ports = <_p>, <_p>;
+   status = "disabled";
+   };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
@@ -149,6 +159,37 @@
#dma-cells = <1>;
};
 
+   tcon0: lcd-controller@01c0c000 {
+   compatible = "allwinner,sun8i-a83t-tcon";
+   reg = <0x01c0c000 0x400>;
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "bus", "clock";
+   resets = < RST_BUS_TCON0>;
+   interrupts = ;
+   status = "disabled";
+   tcon0_p: port {
+   tcon0_hdmi: endpoint {
+   remote-endpoint = <_tcon0>;
+   };
+   };
+   };
+
+   /* not used */
+   tcon1: lcd-controller@01c0d000 {
+   compatible = "allwinner,sun8i-h3-tcon";
+   reg = <0x01c0d000 0x400>;
+   clocks = < CLK_BUS_TCON1>,
+< CLK_TCON0>;  /* no clock */
+   clock-names = "bus", "clock";
+   interrupts = ;
+   status = "disabled";
+   tcon1_p: port {
+   endpoint {
+   /* empty */
+   };
+   };
+   };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -314,6 +355,11 @@
clock-names = "hosc", "losc";
#clock-cells = <1>;
#reset-cells = <1>;
+
+   assigned-clocks = < CLK_PLL_DE>,
+ < CLK_DE>;
+   assigned-clock-rates =  <86400>,
+   <43200>;
};
 
pio: pinctrl@01c20800 {
@@ -567,6 +613,25 @@
interrupts = ;
};
 
+   hdmi: hdmi@01ee {
+   compatible = "allwinner,sun8i-h3-hdmi";
+   reg = <0x01ee 0x2>;
+   clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
+< CLK_HDMI_DDC>;
+   clock-names = "bus", "clock", "ddc-clock";
+   resets = < RST_BUS_HDMI0>, < RST_BUS_HDMI1>;
+   reset-names = "hdmi0", "hdmi1";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {/* video */
+   reg = <0>;
+   hdmi_tcon0: endpoint {
+

[linux-sunxi] [PATCH v7 7/8] ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index c0c49dd..9f3e2f8 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -93,6 +93,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -101,12 +105,20 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v7 8/8] ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 047e9e1..7712972 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -105,16 +105,28 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

[Jean-Francois Moine]

This patchset series adds HDMI video support to the Allwinner
sun8i SoCs which include the display engine 2 (DE2).
The driver contains the code for the A83T and H3 SoCs, and
some H3 boards, but it could be used/extended for other SoCs
(A64, H2, H5) and boards (Banana PIs, Orange PIs).

v7:
- more explanations about the DE2 in the DT documentation
- separate patches for DT documentation (Rob Herring)
- show all properties in DT examples (Rob Herring)
- use drm_of_component_probe()
- use the index of the DE 'ports' in the DT as
  the DE mixer number (no alias needed anymore)
- change some 'lcd' to 'tcon' in the DT
- add HDMI module parameter for DVI mode when screen overscan
  problems
- fall back to some CEA modes in case of EDID read failure
- fix some settings (interlace) and simplify code
- fix bug in start of A83T HDMI
- fix lack of CLK_PLL_DE definition in the DT include
  (Icenowy Zheng)
v6:
- remove audio support (other patchset to come)
- use DRM modeset data for HDMI configuration
(thanks to Jernej Škrabec)
- more meaningfull register names
- use a mutex for DE I/O protection
- merge DE and plane into one file
- don't activate the video hardware when video not started
(Maxime Ripard)
- remove 'type = "video" in DT graph ports
(Rob Herring)
- change the I/O accesses by #define instead of struct
(Maxime Ripard, André Przywara)
- remove pm functions (Maxime Ripard)
- set the pll-de/de clocks in the DT (Maxime Ripard)
- use platform_get_irq instead of irq_of_parse_and_map
(Maxime Ripard)
- rename sunxi to sun8i (Maxime Ripard)
- fix coding style errors (Maxime Ripard)
- subclass the drm structure in private data (Daniel Vetter)
- move drm_dev_register at end of init (Daniel Vetter)
v5:
- add overlay plane
- add audio support
- add support for the A83T
- add back the HDMI driver
- many bug fixes
v4: 
- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
v3:
- add the hardware cursor
- simplify and fix the DE2 init sequences
- generation for all SUNXI SoCs (Andre Przywara)
v2:
- remove the HDMI driver
- remarks from Chen-Yu Tsai and Russell King
- DT documentation added

Jean-Francois Moine (8):
  drm: sun8i: Add a basic DRM driver for Allwinner DE2
  drm/sun8i: Add DT bindings documentation of Allwinner DE2
  drm: sun8i: add HDMI video support to A83T and H3
  drm/sunxi: Add DT bindings documentation of Allwinner HDMI
  clk: sunxi-ng: define the PLL DE clock
  ARM: dts: sun8i-h3: add HDMI video nodes
  ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+
  ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2

 .../devicetree/bindings/display/sunxi/hdmi.txt |  56 ++
 .../bindings/display/sunxi/sun8i-de2.txt   | 121 +++
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  12 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  12 +
 arch/arm/boot/dts/sun8i-h3.dtsi|  65 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/sun8i/Kconfig  |  26 +
 drivers/gpu/drm/sun8i/Makefile |   9 +
 drivers/gpu/drm/sun8i/de2_crtc.c   | 449 +++
 drivers/gpu/drm/sun8i/de2_crtc.h   |  52 ++
 drivers/gpu/drm/sun8i/de2_drv.c| 317 
 drivers/gpu/drm/sun8i/de2_drv.h|  48 ++
 drivers/gpu/drm/sun8i/de2_hdmi.c   | 440 +++
 drivers/gpu/drm/sun8i/de2_hdmi.h   |  51 ++
 drivers/gpu/drm/sun8i/de2_hdmi_io.c| 842 +
 drivers/gpu/drm/sun8i/de2_plane.c  | 734 ++
 include/dt-bindings/clock/sun8i-h3-ccu.h   |   1 +
 18 files changed, 3238 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
 create mode 100644 drivers/gpu/drm/sun8i/Kconfig
 create mode 100644 drivers/gpu/drm/sun8i/Makefile
 create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_drv.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c

-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubsc

[linux-sunxi] [PATCH v7 1/8] drm: sun8i: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
engine, DE2.
This patch adds a DRM video driver for this device.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/sun8i/Kconfig |  19 +
 drivers/gpu/drm/sun8i/Makefile|   7 +
 drivers/gpu/drm/sun8i/de2_crtc.c  | 449 +++
 drivers/gpu/drm/sun8i/de2_crtc.h  |  50 +++
 drivers/gpu/drm/sun8i/de2_drv.c   | 317 
 drivers/gpu/drm/sun8i/de2_drv.h   |  48 +++
 drivers/gpu/drm/sun8i/de2_plane.c | 734 ++
 9 files changed, 1627 insertions(+)
 create mode 100644 drivers/gpu/drm/sun8i/Kconfig
 create mode 100644 drivers/gpu/drm/sun8i/Makefile
 create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_drv.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95fc041..bb1bfbc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -202,6 +202,8 @@ source "drivers/gpu/drm/shmobile/Kconfig"
 
 source "drivers/gpu/drm/sun4i/Kconfig"
 
+source "drivers/gpu/drm/sun8i/Kconfig"
+
 source "drivers/gpu/drm/omapdrm/Kconfig"
 
 source "drivers/gpu/drm/tilcdc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 883f3e7..3e1eaa0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-y  += omapdrm/
 obj-$(CONFIG_DRM_SUN4I) += sun4i/
+obj-$(CONFIG_DRM_SUN8I) += sun8i/
 obj-y  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
diff --git a/drivers/gpu/drm/sun8i/Kconfig b/drivers/gpu/drm/sun8i/Kconfig
new file mode 100644
index 000..6940895
--- /dev/null
+++ b/drivers/gpu/drm/sun8i/Kconfig
@@ -0,0 +1,19 @@
+#
+# Allwinner DE2 Video configuration
+#
+
+config DRM_SUN8I
+   bool
+
+config DRM_SUN8I_DE2
+   tristate "Support for Allwinner Video with DE2 interface"
+   depends on DRM && OF
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_KMS_HELPER
+   select DRM_SUN8I
+   help
+ Choose this option if your Allwinner chipset has the DE2 interface
+ as the A64, A83T and H3. If M is selected the module will be called
+ sun8i-de2-drm.
diff --git a/drivers/gpu/drm/sun8i/Makefile b/drivers/gpu/drm/sun8i/Makefile
new file mode 100644
index 000..f107919
--- /dev/null
+++ b/drivers/gpu/drm/sun8i/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for Allwinner's sun8i DRM device driver
+#
+
+sun8i-de2-drm-objs := de2_drv.o de2_crtc.o de2_plane.o
+
+obj-$(CONFIG_DRM_SUN8I_DE2) += sun8i-de2-drm.o
diff --git a/drivers/gpu/drm/sun8i/de2_crtc.c b/drivers/gpu/drm/sun8i/de2_crtc.c
new file mode 100644
index 000..4e94ccc
--- /dev/null
+++ b/drivers/gpu/drm/sun8i/de2_crtc.c
@@ -0,0 +1,449 @@
+/*
+ * Allwinner DRM driver - DE2 CRTC
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ *
+ * 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 "de2_drv.h"
+#include "de2_crtc.h"
+
+/* I/O map */
+
+#define TCON_GCTL_REG  0x00
+#defineTCON_GCTL_TCON_ENABLE BIT(31)
+#define TCON_GINT0_REG 0x04
+#defineTCON_GINT0_TCON1_Vb_Int_En BIT(30)
+#defineTCON_GINT0_TCON1_Vb_Int_Flag BIT(14)
+#defineTCON_GINT0_TCON1_Vb_Line_Int_Flag BIT(12)
+#define TCON0_CTL_REG  0x40
+#defineTCON0_CTL_TCON_ENABLE BIT(31)
+#define TCON1_CTL_REG  0x90
+#defineTCON1_CTL_TCON_ENABLE BIT(31)
+#defineTCON1_CTL_INTERLACE_ENABLE BIT(20)
+#defineTCON1_CTL_Start_Delay_SHIFT 4
+#defineTCON1_CTL_Start_Delay_MASK GENMASK(8, 4)
+#define TCON1_BASIC0_REG   0x94/* XI/YI */
+#define TCON1_BASIC1_REG   0x98/* LS_XO/LS_YO */
+#define TCON1_BASIC2_REG   0x9c/* XO/YO */
+#define TCON1_BASIC3_REG   0xa0/* HT/HBP */
+#define TCON1_BASIC4_REG   0xa4/* VT/VBP */
+#define TCON1_BASIC5_REG   0xa8/* HSPW/VSPW */
+#define TCON1_PS_SYNC_REG  0xb0
+#define TCON1_IO_POL_REG   0xf0
+#defineTCON1_IO_POL_IO0_inv BIT(24)
+#defineTCON1_IO_POL_IO1_inv BIT(25)
+#define   

[linux-sunxi] [PATCH v7 5/8] clk: sunxi-ng: define the PLL DE clock

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 include/dt-bindings/clock/sun8i-h3-ccu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/sun8i-h3-ccu.h 
b/include/dt-bindings/clock/sun8i-h3-ccu.h
index efb7ba2..7af57b7 100644
--- a/include/dt-bindings/clock/sun8i-h3-ccu.h
+++ b/include/dt-bindings/clock/sun8i-h3-ccu.h
@@ -44,6 +44,7 @@
 #define _DT_BINDINGS_CLK_SUN8I_H3_H_
 
 #define CLK_CPUX   14
+#define CLK_PLL_DE 13
 
 #define CLK_BUS_CE 20
 #define CLK_BUS_DMA21
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

[Jean-Francois Moine]

(I reduced the Cc to linux-sunxi)

On Fri, 25 Nov 2016 18:32:07 +0800
Icenowy Zheng <icen...@aosc.xyz> wrote:
> 
> 25.11.2016, 18:22, "Jean-Francois Moine" <moin...@free.fr>:
> > 
> > The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
> > use the legacy u-boot, I don't know which can be the rate of the DE.
> 
> Can't CCU deal with this?
> 
> I still kept the CLK_DE's assigned-clock...

AFAIR, SET_RATE_PARENT did not work fine with this couple pll-de/de.

> >>  However, it cannot recognize any HDMI screen...
> >>
> >>  (My board is Orange Pi One, and I manually added status="okay"; to , 
> >> , )
> >>
> >>  [ 16.507802] sun8i-de2 100.de-controller: bound 
> >> 1c0c000.lcd-controller (ops de2_lcd_ops [sun8i_de2_drm])
> >>  [ 16.675948] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops 
> >> de2_hdmi_fini [sun8i_de2_hdmi])
> >>  [ 16.685120] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >>  [ 16.695876] [drm] No driver support for vblank timestamp query.
> >>  [ 16.701862] sun8i-de2 100.de-controller: No connectors reported 
> >> connected with modes
> >>  [ 16.713061] [drm] Cannot find any crtc or sizes - going 1024x768
> >>  [ 16.734214] Console: switching to colour frame buffer device 128x48
> >>  [ 16.751022] sun8i-de2 100.de-controller: fb0: frame buffer device
> >
> > I put a 'pr_warn' message is case the EDID cannot be read.
> > Have you this message?
> 
> Seems no...

You may check if there is a  EDID in
/sys/devices/platform/soc/100.de-controller/drm/card0/card0-HDMI-A-1/edid

> > Anyway, there is a problem with the EDID:
> > - my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
> >   rebooting once or twice.
> > - my Banana Pi M2+ (H3) reads it correctly each time.
> > - my Banana Pi M3 (A83T) can never read it.
> >
> > BTW, on first tries, I was forcing a CEA mode thru the kernel command
> > line. This was working with the OPi2 and BPiM3, but there was no sound.
> > In the last version, I use a EDID in edid_firmware for having sound
> > with the BPiM3. This works fine.
> > But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
> > read the EDID, the system switches to a VGA mode (default 1024x768)
> > which is not supported. It seems that this is your case.
> >
> > So, in brief, if your board cannot read the EDID, put a EDID somewhere
> > and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
> > There will be no console, but X11 will work correctly.
> 
> The problem seems to be that the CRTC is not properly initialized...

Yes. Looking back at your system messages, your screen is not seen as
connected. This means that the HPD is not asserted. This may be a HDMI
cable problem...

There may also be a clock problem. Recently, I tried to stop the HDMI
clock (not the DDC one). In this case, the HDP is not detected.
So, may you check the 3 clocks (bus, main and DDC).

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

[Jean-Francois Moine]

On Fri, 25 Nov 2016 17:41:51 +0800
Icenowy Zheng  wrote:

> After removing CLK_PLL_DE's assigned-clock, the kernel passes compilation.

The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
use the legacy u-boot, I don't know which can be the rate of the DE.

> However, it cannot recognize any HDMI screen...
> 
> (My board is Orange Pi One, and I manually added status="okay"; to , 
> , )
> 
> [   16.507802] sun8i-de2 100.de-controller: bound 1c0c000.lcd-controller 
> (ops de2_lcd_ops [sun8i_de2_drm])
> [   16.675948] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops 
> de2_hdmi_fini [sun8i_de2_hdmi])
> [   16.685120] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   16.695876] [drm] No driver support for vblank timestamp query.
> [   16.701862] sun8i-de2 100.de-controller: No connectors reported 
> connected with modes
> [   16.713061] [drm] Cannot find any crtc or sizes - going 1024x768
> [   16.734214] Console: switching to colour frame buffer device 128x48
> [   16.751022] sun8i-de2 100.de-controller: fb0:  frame buffer device

I put a 'pr_warn' message is case the EDID cannot be read.
Have you this message?

Anyway, there is a problem with the EDID:
- my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
  rebooting once or twice.
- my Banana Pi M2+ (H3) reads it correctly each time.
- my Banana Pi M3 (A83T) can never read it.

BTW, on first tries, I was forcing a CEA mode thru the kernel command
line. This was working with the OPi2 and BPiM3, but there was no sound.
In the last version, I use a EDID in edid_firmware for having sound
with the BPiM3. This works fine.
But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
read the EDID, the system switches to a VGA mode (default 1024x768)
which is not supported. It seems that this is your case.

So, in brief, if your board cannot read the EDID, put a EDID somewhere
and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
There will be no console, but X11 will work correctly.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support

[Jean-Francois Moine]

On Mon, 21 Nov 2016 01:54:53 +0100
Ondřej Jirman <meg...@megous.com> wrote:

> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3, but it could be
> > used/extended for other SoCs as the A64, H2 and H5.
> 
> Hi,
> 
> I'm trying to test your patches on Orange Pi PC, and I've run into a few
> issues: (I'm using sunxi-ng with the same patches as last time, to make
> it work with your driver)
> 
> 1] I just get pink output on the monitor - there's some signal, but it's
> pink (or more like magenta).
> 
> dmesg ouput indicates no error:
> 
> [1.887823] [drm] Initialized
> [1.888503] sun8i-de2 100.de-controller: bound
> 1c0c000.lcd-controller (ops 0xc0a63894)
> [2.057298] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops
> 0xc0a63b54)
> [2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [2.057307] [drm] No driver support for vblank timestamp query.
> [2.690862] Console: switching to colour frame buffer device 240x67
> [2.723059] sun8i-de2 100.de-controller: fb0:  frame buffer device
[snip]

My H3 boards work correctly, except the Orange PI 2 when it cannot read
the EDID (but it is OK after reboot).

Did you check if the EDID was correctly read?
Which resolution do you expect?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 5/5] ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 047e9e1..9ecc6f1 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -56,6 +56,7 @@
serial0 = 
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
ethernet1 = 
+   lcd0 = 
};
 
chosen {
@@ -105,16 +106,28 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 51 +
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 416b825..7c6b1d5 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -140,6 +140,16 @@
#size-cells = <1>;
ranges;
 
+   de: de-controller@0100 {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   reg = <0x0100 0x40>;
+   clocks = < CLK_BUS_DE>, < CLK_DE>;
+   clock-names = "bus", "clock";
+   resets = < RST_BUS_DE>;
+   ports = <_p>;
+   status = "disabled";
+   };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
@@ -149,6 +159,23 @@
#dma-cells = <1>;
};
 
+   lcd0: lcd-controller@01c0c000 {
+   compatible = "allwinner,sun8i-a83t-tcon";
+   reg = <0x01c0c000 0x400>;
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "bus", "clock";
+   resets = < RST_BUS_TCON0>;
+   interrupts = ;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   lcd0_p: port {
+   lcd0_hdmi: endpoint {
+   remote-endpoint = <_lcd0>;
+   };
+   };
+   };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -314,6 +341,11 @@
clock-names = "hosc", "losc";
#clock-cells = <1>;
#reset-cells = <1>;
+
+   assigned-clocks = < CLK_PLL_DE>,
+ < CLK_DE>;
+   assigned-clock-rates =  <86400>,
+   <43200>;
};
 
pio: pinctrl@01c20800 {
@@ -564,6 +596,25 @@
interrupts = ;
};
 
+   hdmi: hdmi@01ee {
+   compatible = "allwinner,sun8i-h3-hdmi";
+   reg = <0x01ee 0x2>;
+   clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
+< CLK_HDMI_DDC>;
+   clock-names = "bus", "clock", "ddc-clock";
+   resets = < RST_BUS_HDMI0>, < RST_BUS_HDMI1>;
+   reset-names = "hdmi0", "hdmi1";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {/* video */
+   reg = <0>;
+   hdmi_lcd0: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   };
+
rtc: rtc@01f0 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f0 0x54>;
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 4/5] ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index c0c49dd..4b5baae 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -55,6 +55,7 @@
aliases {
serial0 = 
serial1 = 
+   lcd0 = 
};
 
chosen {
@@ -93,6 +94,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -101,12 +106,20 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 2/5] drm: sun8i: add HDMI video support to A83T and H3

[Jean-Francois Moine]

This patch adds a HDMI video driver to the Allwinner's SoCs A83T and H3.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 .../devicetree/bindings/display/sunxi/hdmi.txt |  53 ++
 drivers/gpu/drm/sun8i/Kconfig  |   7 +
 drivers/gpu/drm/sun8i/Makefile |   2 +
 drivers/gpu/drm/sun8i/de2_hdmi.c   | 394 ++
 drivers/gpu/drm/sun8i/de2_hdmi.h   |  51 ++
 drivers/gpu/drm/sun8i/de2_hdmi_io.c| 839 +
 6 files changed, 1346 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c

diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt 
b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
new file mode 100644
index 000..85709ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
@@ -0,0 +1,53 @@
+Allwinner HDMI Transmitter
+==
+
+The Allwinner HDMI transmitters are included in the SoCs.
+They support audio and video.
+
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be one of
+   "allwinner,sun8i-a83t-hdmi"
+   "allwinner,sun8i-h3-hdmi"
+ - clocks : phandles to the HDMI clocks as described in
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+ - clock-names : must be
+   "gate" : bus gate
+   "clock" : streaming clock
+   "ddc-clock" : DDC clock
+ - resets : One or two phandles to the HDMI resets
+ - reset-names : when 2 phandles, must be
+   "hdmi0" and "hdmi1"
+
+Required nodes:
+ - port: Audio and video input port nodes with endpoint definitions
+   as defined in Documentation/devicetree/bindings/graph.txt.
+   port@0 is video and port@1 is audio.
+
+Example:
+
+   hdmi: hdmi@01ee {
+   compatible = "allwinner,sun8i-a83t-hdmi";
+   reg = <0x01ee 0x2>;
+   clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
+< CLK_HDMI_DDC>;
+   clock-names = "gate", "clock", "ddc-clock";
+   resets = < RST_HDMI0>, < RST_HDMI1>;
+   reset-names = "hdmi0", "hdmi1";
+   ...
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {/* video */
+   reg = <0>;
+   hdmi_lcd1: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   port@1 {/* audio */
+   reg = <1>;
+   hdmi_i2s2: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/sun8i/Kconfig b/drivers/gpu/drm/sun8i/Kconfig
index 6940895..5c4607b 100644
--- a/drivers/gpu/drm/sun8i/Kconfig
+++ b/drivers/gpu/drm/sun8i/Kconfig
@@ -17,3 +17,10 @@ config DRM_SUN8I_DE2
  Choose this option if your Allwinner chipset has the DE2 interface
  as the A64, A83T and H3. If M is selected the module will be called
  sun8i-de2-drm.
+
+config DRM_SUN8I_DE2_HDMI
+   tristate "Support for DE2 HDMI"
+   depends on DRM_SUN8I_DE2
+   help
+ Choose this option if you use want HDMI on DE2.
+ If M is selected the module will be called sun8i-de2-hdmi.
diff --git a/drivers/gpu/drm/sun8i/Makefile b/drivers/gpu/drm/sun8i/Makefile
index f107919..6ba97c2 100644
--- a/drivers/gpu/drm/sun8i/Makefile
+++ b/drivers/gpu/drm/sun8i/Makefile
@@ -3,5 +3,7 @@
 #
 
 sun8i-de2-drm-objs := de2_drv.o de2_crtc.o de2_plane.o
+sun8i-de2-hdmi-objs := de2_hdmi.o de2_hdmi_io.o
 
 obj-$(CONFIG_DRM_SUN8I_DE2) += sun8i-de2-drm.o
+obj-$(CONFIG_DRM_SUN8I_DE2_HDMI) += sun8i-de2-hdmi.o
diff --git a/drivers/gpu/drm/sun8i/de2_hdmi.c b/drivers/gpu/drm/sun8i/de2_hdmi.c
new file mode 100644
index 000..9898a12
--- /dev/null
+++ b/drivers/gpu/drm/sun8i/de2_hdmi.c
@@ -0,0 +1,394 @@
+/*
+ * Allwinner DRM driver - HDMI
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ *
+ * 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 
+
+#include 

[linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support

[Jean-Francois Moine]

This patchset series adds HDMI video support to the Allwinner
sun8i SoCs which include the display engine 2 (DE2).
The driver contains the code for the A83T and H3, but it could be
used/extended for other SoCs as the A64, H2 and H5.

v6:
- remove audio support (other patchset to come)
- use DRM modeset data for HDMI configuration
(thanks to Jernej Škrabec)
- more meaningfull register names
- use a mutex for DE I/O protection
- merge DE and plane into one file
- don't activate the video hardware when video not started
(Maxime Ripard)
- remove 'type = "video" in DT graph ports
(Rob Herring)
- change the I/O accesses by #define instead of struct
(Maxime Ripard, André Przywara)
- remove pm functions (Maxime Ripard)
- set the pll-de/de clocks in the DT (Maxime Ripard)
- use platform_get_irq instead of irq_of_parse_and_map
(Maxime Ripard)
- rename sunxi to sun8i (Maxime Ripard)
- fix coding style errors (Maxime Ripard)
- subclass the drm structure in private data (Daniel Vetter)
- move drm_dev_register at end of init (Daniel Vetter)
v5:
- add overlay plane
- add audio support
- add support for the A83T
- add back the HDMI driver
- many bug fixes
v4: 
- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
v3:
- add the hardware cursor
- simplify and fix the DE2 init sequences
- generation for all SUNXI SoCs (Andre Przywara)
v2:
- remove the HDMI driver
- remarks from Chen-Yu Tsai and Russell King
- DT documentation added

Jean-Francois Moine (5):
  drm: sun8i: Add a basic DRM driver for Allwinner DE2
  drm: sunxi: add HDMI video support to A83T and H3
  ARM: dts: sun8i-h3: add HDMI video nodes
  ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+
  ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2

 .../devicetree/bindings/display/sunxi/hdmi.txt |  53 ++
 .../bindings/display/sunxi/sun8i-de2.txt   |  83 ++
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  13 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  13 +
 arch/arm/boot/dts/sun8i-h3.dtsi|  51 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/sun8i/Kconfig  |  26 +
 drivers/gpu/drm/sun8i/Makefile |   9 +
 drivers/gpu/drm/sun8i/de2_crtc.c   | 440 +++
 drivers/gpu/drm/sun8i/de2_crtc.h   |  50 ++
 drivers/gpu/drm/sun8i/de2_drm.h|  48 ++
 drivers/gpu/drm/sun8i/de2_drv.c| 379 ++
 drivers/gpu/drm/sun8i/de2_hdmi.c   | 394 ++
 drivers/gpu/drm/sun8i/de2_hdmi.h   |  51 ++
 drivers/gpu/drm/sun8i/de2_hdmi_io.c| 839 +
 drivers/gpu/drm/sun8i/de2_plane.c  | 712 +
 17 files changed, 3164 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
 create mode 100644 drivers/gpu/drm/sun8i/Kconfig
 create mode 100644 drivers/gpu/drm/sun8i/Makefile
 create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_drm.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
 create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c

-- 
2.10.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Wed, 16 Nov 2016 22:33:06 +0100
Maxime Ripard  wrote:

> > > > The Device Engine just handles the planes of the LCDs, but, indeed,
> > > > the LCDs must know about the DE and the DE must know about the LCDs.
> > > > There are 2 ways to realize this knowledge in the DT:
> > > > 1) either the DE has one or two phandle's to the LCDs,
> > > > 2) or the LCDs have a phandle to the DE.
> > > > 
> > > > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > > > which is part of the video link (OF-graph LCD <-> connector).
> > > > It would be possible to have phandles to the LCDs themselves, but this
> > > > asks for more code.
> > > > 
> > > > The second way is also possible, but it also complexifies a bit the
> > > > exchanges DE <-> LCD.
> > > 
> > > I'm still not sure how it would complexify anything, and why you can't
> > > use the display graph to model the relation between the display engine
> > > and the TCON (and why you want to use a generic property that refers
> > > to the of-graph while it really isn't).
> > 
> > Complexification:
> > 1- my solution:
> >   At startup time, the DE device is the DRM device.
> 
> How do you deal with SoCs with multiple display engines then?

In the H3, A83T and A64, there is only one DE.
If many DEs in a SoC, there may be either one DRM device per DE or one
DRM device for the whole system. In this last case, the (global) DE
would have many resources (many I/O memory maps / IRQs..) and the
physical DE of each endpoint would be indicated by the position of its
phandle in the 'ports' array (DT documentation).

> > It has to know the devices entering in the video chains.
> >   The CRTCs (LCD/TCON) are found by
> > ports[i] -> parent
> >   The connectors are found by
> > ports[i] -> endpoint -> remote_endpoint -> parent
> > 2- with ports pointing to the LCDs:
> >   The CRTCs (LCD/TCON) are simply
> > ports[i]
> >   The connectors are found by
> > loop on all ports of ports[i]
> > ports[i][j] -> endpoint -> remote_endpoint -> parent
> > 3- with a phandle to the DE in the LCDs:
> 
> What do you mean with LCD? Panels? Why would panels have a phandle to
> the display engine?

LCD is the same as CRTC. I don't think people will connect old CRT's to
their new ARM boards. LCD's may be panels, modern TV sets, or any
digital display. The word LCD seems clearer to me in this context, even
if there may a DAC as an ancoder.

> >   The DE cannot be the DRM device because there is no information about
> >   the video devices in the DT. Then, the DRM devices are the LCDs.
> >   These LCDs must give their indices to the DE. So, the DE must implement
> >   some callback function to accept a LCD definition, and there must be
> >   a list of DEs in the driver to make the association DE <-> LCD[i]
> >   Some more problem may be raised if a user wants to have the same frame
> >   buffer on the 2 LCDs of a DE.
> 
> I have no idea what you're talking about, sorry.

Here is the DT (I am using back 'CRTC'):

de: display-controller@xxx {
...
};
crtc0: crt-controller@xxx{
...
display-controller = <>;
ports {
... /* to the crtc0 connectors */
}
};
crtc1: crt-controller@xxx{
...
display-controller = <>;
ports {
... /* to the crtc1 connectors */
};
};

There are 2 DRM devices: one on crtc0, the other one on crtc1.
The DE device is isolated. But, to treat the planes, it must receive
information about the CRTCs. How?

> > Anyway, my solution is already used in the IMX Soc.
> > See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.
> 
> Pointing out random example in the tree doesn't make a compelling
> argument.

This is not a random example. There was a thread about the 'ports'
phandle in the DT definition of the IMX video subsystem, and what kind
of OF function should be used (see one of my previous mails). In the DRI
list, nobody objected about the phandle by itself.

> > > > > > > Panel functions? In the CRTC driver?
> > > > > > 
> > > > > > Yes, dumb panel.
> > > > > 
> > > > > What do you mean by that? Using a Parallel/RGB interface?
> > > > 
> > > > Sorry, I though this was a well-known name. The 'dump panel' was used
> > > > in the documentation of my previous ARM machine as the video frame sent
> > > > to the HDMI controller. 'video_frame' is OK for you?
> > > 
> > > If it's the frame sent to the encoder, then it would be the CRTC by
> > > DRM's nomenclature.
> > 
> > The CRTC is a software entity. The frame buffer is a hardware entity.
> 
> Why are you about framebuffer now, this is nowhere in that
> discussion. Any way, the framebuffer is also what is put in a plane,
> so there's a name collision here, and you'll probably want to change
> 

[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Mon, 7 Nov 2016 23:37:41 +0100
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Hi,
> 
> On Fri, Oct 28, 2016 at 07:34:20PM +0200, Jean-Francois Moine wrote:
> > On Fri, 28 Oct 2016 00:03:16 +0200
> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote:
[snip]
> > > > > We've been calling them bus and mod.
> > > > 
> > > > I can understand "bus" (which is better than "apb"), but why "mod"?
> > > 
> > > Allwinner has been calling the clocks that are supposed to generate
> > > the external signals (depending on where you were looking) module or
> > > mod clocks (which is also why we have mod in the clock
> > > compatibles). The module 1 clocks being used for the audio and the
> > > module 0 for the rest (SPI, MMC, NAND, display, etc.)
> > 
> > I did not find any 'module' in the H3 documentation.
> > So, is it really a good name?
> 
> It's true that they use it less nowadays, but they still do,
> ie. 
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L513

There is a 'mod' suffix, but it is used for the bus gates only, not for
the main clocks.

> And we have to remain consistent anyway.

I don't see any consistency in the H3 DT:
- the bus gates are named "ahb" and apb"
- the (main) clocks are named "mmc", "usb0_phy" and "ir"
There is no "bus" nor "mod".

> > > > > > +
> > > > > > +- resets: phandle to the reset of the device
> > > > > > +
> > > > > > +- ports: phandle's to the LCD ports
> > > > > 
> > > > > Please use the OF graph.
> > > > 
> > > > These ports are references to the graph of nodes. See
> > > > http://www.kernelhub.org/?msg=911825=2
> > > 
> > > In an OF-graph, your phandle to the LCD controller would be replaced
> > > by an output endpoint.
> > 
> > This is the DE controller. There is no endpoint link at this level.
> 
> The display engine definitely has an endpoint: the TCON.

Not at all. The video chain is simply
CRTC (TCON) -> connector (HDMI/LCD/DAC/..)
The DE is an ancillary device which handles the planes.

> > The Device Engine just handles the planes of the LCDs, but, indeed,
> > the LCDs must know about the DE and the DE must know about the LCDs.
> > There are 2 ways to realize this knowledge in the DT:
> > 1) either the DE has one or two phandle's to the LCDs,
> > 2) or the LCDs have a phandle to the DE.
> > 
> > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > which is part of the video link (OF-graph LCD <-> connector).
> > It would be possible to have phandles to the LCDs themselves, but this
> > asks for more code.
> > 
> > The second way is also possible, but it also complexifies a bit the
> > exchanges DE <-> LCD.
> 
> I'm still not sure how it would complexify anything, and why you can't
> use the display graph to model the relation between the display engine
> and the TCON (and why you want to use a generic property that refers
> to the of-graph while it really isn't).

Complexification:
1- my solution:
  At startup time, the DE device is the DRM device. It has to know the
  devices entering in the video chains.
  The CRTCs (LCD/TCON) are found by
ports[i] -> parent
  The connectors are found by
ports[i] -> endpoint -> remote_endpoint -> parent
2- with ports pointing to the LCDs:
  The CRTCs (LCD/TCON) are simply
ports[i]
  The connectors are found by
loop on all ports of ports[i]
ports[i][j] -> endpoint -> remote_endpoint -> parent
3- with a phandle to the DE in the LCDs:
  The DE cannot be the DRM device because there is no information about
  the video devices in the DT. Then, the DRM devices are the LCDs.
  These LCDs must give their indices to the DE. So, the DE must implement
  some callback function to accept a LCD definition, and there must be
  a list of DEs in the driver to make the association DE <-> LCD[i]
  Some more problem may be raised if a user wants to have the same frame
  buffer on the 2 LCDs of a DE.

Anyway, my solution is already used in the IMX Soc.
See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.

> > > > > > +void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
> > > > > > +{
> > > > > > +   struct priv *priv = drm->dev_private;
> > > > > > +   struct lcd *lcd = priv->lcds[crtc];
> > > > > > +

Re: [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Jean-Francois Moine]

On Mon, 7 Nov 2016 21:05:05 +0100
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Hi,
> 
> On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai <w...@csie.org> wrote:
> > 
> > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moin...@free.fr> 
> > > wrote:
> > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > >
> > > > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > > > ---
> > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > - it handles the H3
> > > 
> > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > the newer SoCs.
> > 
> > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > regmap.
> > Many H3 registers are common with the A10, but some of them have more
> > or less fields, the fields may be at different offsets. And, finally,
> > some registers are completely different.
> > This would not raise any problem, except with regmap which is really
> > painful.
> 
> That's weird, because regmap's regmap_field should make that much
> easier.

#define field_relaxed(addr, mask, val) \
writel_relaxed((readl_relaxed(addr) & mask) | val, addr)

> > As I may understood, regmap is used to simplify suspend/resume, but, is
> > it useful to save the I2S register on suspend?
> > Practically, I am streaming some tune on my device. I suspend it for
> > any reason. The next morning, I resume it. Are you sure I want to
> > continue to hear the end of the tune?
> > 
> > I better think that streaming should be simply stopped on suspend.
> 
> You're mistaken. The code in there is for *runtime* suspend, ie when
> the device is no longer used, so that case shouldn't even happen at
> all.
> 
> (And real suspend isn't supported anyway)

Is it time to remove this useless code?

> > Then, there is no need to save the playing registers, and, here I am,
> > there is no need to use regmap.
> > 
> > May I go this way?
> 
> No, please don't. regmap is also providing very useful features, such
> as access to all the registers through debugfs, or tracing. What
> exactly feels painful to you?

When the I/O registers are in memory (that's the case), you may access
them (read and write) thru /dev/mem.
Also, is a register access trace really needed in this driver?

The pain is to define the regmap_config (which registers can be
read/write/volatile and which can be the values the u-boot let us in
the registers at startup time), and the lot of code which is run instead
of simple load/store machine instructions.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Jean-Francois Moine]

On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai <w...@csie.org> wrote:

> On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moin...@free.fr> wrote:
> > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> >
> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > ---
> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
> 
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.

I started to add the H3 into the sun4i-i2s, but I am blocked with
regmap.
Many H3 registers are common with the A10, but some of them have more
or less fields, the fields may be at different offsets. And, finally,
some registers are completely different.
This would not raise any problem, except with regmap which is really
painful.

As I may understood, regmap is used to simplify suspend/resume, but, is
it useful to save the I2S register on suspend?
Practically, I am streaming some tune on my device. I suspend it for
any reason. The next morning, I resume it. Are you sure I want to
continue to hear the end of the tune?

I better think that streaming should be simply stopped on suspend.
Then, there is no need to save the playing registers, and, here I am,
there is no need to use regmap.

May I go this way?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Fri, 28 Oct 2016 00:03:16 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Tue, Oct 25, 2016 at 04:14:41PM +0200, Jean-Francois Moine wrote:
> > > > +Display controller
> > > > +==
> > > > +
> > > > +Required properties:
> > > > +
> > > > +- compatible: value should be one of the following
> > > > +   "allwinner,sun8i-a83t-display-engine"
> > > > +   "allwinner,sun8i-h3-display-engine"
> > > > +
> > > > +- clocks: must include clock specifiers corresponding to entries in the
> > > > +   clock-names property.
> > > > +
> > > > +- clock-names: must contain
> > > > +   "gate": for DE activation
> > > > +   "clock": DE clock
> > > 
> > > We've been calling them bus and mod.
> > 
> > I can understand "bus" (which is better than "apb"), but why "mod"?
> 
> Allwinner has been calling the clocks that are supposed to generate
> the external signals (depending on where you were looking) module or
> mod clocks (which is also why we have mod in the clock
> compatibles). The module 1 clocks being used for the audio and the
> module 0 for the rest (SPI, MMC, NAND, display, etc.)

I did not find any 'module' in the H3 documentation.
So, is it really a good name?

> > > > +
> > > > +- resets: phandle to the reset of the device
> > > > +
> > > > +- ports: phandle's to the LCD ports
> > > 
> > > Please use the OF graph.
> > 
> > These ports are references to the graph of nodes. See
> > http://www.kernelhub.org/?msg=911825=2
> 
> In an OF-graph, your phandle to the LCD controller would be replaced
> by an output endpoint.

This is the DE controller. There is no endpoint link at this level.
The Device Engine just handles the planes of the LCDs, but, indeed,
the LCDs must know about the DE and the DE must know about the LCDs.
There are 2 ways to realize this knowledge in the DT:
1) either the DE has one or two phandle's to the LCDs,
2) or the LCDs have a phandle to the DE.

I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
which is part of the video link (OF-graph LCD <-> connector).
It would be possible to have phandles to the LCDs themselves, but this
asks for more code.

The second way is also possible, but it also complexifies a bit the
exchanges DE <-> LCD.

> > [snip]
> > > > +struct tcon {
> > > > +   u32 gctl;
> > > > +#defineTCON_GCTL_TCON_En BIT(31)
[snip]
> > > > +   u32 fill_ctl;   /* 0x300 */
> > > > +   u32 fill_start0;
> > > > +   u32 fill_end0;
> > > > +   u32 fill_data0;
> > > > +};
> > > 
> > > Please use defines instead of the structures.
> > 
> > I think that structures are more readable.
> 
> That's not really the point. No one in the kernel uses it (and even
> you use defines for registers offset in some places of that
> patch). And then you have André arguments.

I am not convinced, but I'll do as you said.

> > > > +void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
> > > > +{
> > > > +   struct priv *priv = drm->dev_private;
> > > > +   struct lcd *lcd = priv->lcds[crtc];
> > > > +
> > > > +   tcon_write(lcd->mmio, gint0,
> > > > +tcon_read(lcd->mmio, gint0) &
> > > > +   ~TCON_GINT0_TCON1_Vb_Int_En);
> > > > +}
> > > > +
> > > > +/* panel functions */
> > > 
> > > Panel functions? In the CRTC driver?
> > 
> > Yes, dumb panel.
> 
> What do you mean by that? Using a Parallel/RGB interface?

Sorry, I though this was a well-known name. The 'dump panel' was used
in the documentation of my previous ARM machine as the video frame sent
to the HDMI controller. 'video_frame' is OK for you?

[snip]
> > > > +   ret = clk_prepare_enable(lcd->clk);
> > > > +   if (ret)
> > > > +   goto err2;
> > > 
> > > Is there any reason not to do that in the enable / disable? Leaving
> > > clocks running while the device has no guarantee that it's going to be
> > > used seems like a waste of resources.
> > 
> > If the machine does not need video (network server, router..), it is simpler
> > to pr

Re: [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC

[Jean-Francois Moine]

On Fri, 28 Oct 2016 00:54:34 +0800
Chen-Yu Tsai  wrote:

> There's already a driver for basically the same thing:
> 
> sound/soc/codec/hdmi-codec.c
> 
> You use it by registering a sub-device from your hdmi driver, with the
> proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
> platforms already using it.

I know that for a long time, and I will not use it on any account: it is
a gasworks!

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [alsa-devel] [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Jean-Francois Moine]

On Mon, 24 Oct 2016 14:34:49 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Hi,
> 
> On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai <w...@csie.org> wrote:
> > 
> > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > - it handles the H3
> > > 
> > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > the newer SoCs.
> > > 
> > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > >   by the CODECs)
> > > 
> > > I think this is wrong. I2S is only the DAI. You typically have a separate
> > > platform driver for the whole card, or just use simple-card.
> > 
> > An other device is not needed. The layout is simple:
> > I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > so, it cannot be the card device.
> > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > natural to use it to handle the card.
> 
> Still, duplicating the driver is not the solution. I agree with
> Chen-Yu that we want to leverage the driver that is already there.

Hi Maxime and Chen-Yu,

After looking at the sun4i-i2s, I found 2 solutions for re-using its
code in the DE2 HDMI context:

1) either to split the sun4i-i2s driver into common I/O functions and
   slave CPU DAI,

2) or to move the sun4i-i2s into a master CPU DAI.

(
 some explanation about 'master' and 'slave': the master is the
 component the device of which is also the sound card.
 As the sound card uses the 'drvdata' of the device, this drvdata pointer
 cannot be used by the master.
 In the actual implementations:
  - sun4i-i2s
master: card dev = codec dev, drvdata -> card
slave:  i2s dev (CPU DAI), drvdata -> i2s data
  - sun8i-i2s
master: card dev = i2s dev (CPU DAI), drvdata -> card
slave:  codec dev (hdmi), drvdata -> codec data (audio/video)
)

In the case 1, there is no functional change, just a source split.
The sun8i-i2s will then use the common I/O functions.

In the case 2, the CODECs using the sun4i-i2s would have to move to
slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
In the 4.9, there is only one codec (sun4i-codec), so, the change
is just to move the card creation and the use of drvdata in both
codes.

In either cases, I could not check if this changes raise some
regression on the sun4i SoCs side. Then, I'd be glad to know:
- which solution suits you?
- are you ready to do and test the needed changes at the sun4i side?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Tue, 25 Oct 2016 08:44:22 +0200
Daniel Vetter  wrote:

> > +   /* start the subdevices */
> > +   ret = component_bind_all(dev, drm);
> > +   if (ret < 0)
> > +   goto out2;
> > +
> > +   ret = drm_dev_register(drm, 0);
> 
> This needs to be the very last step in your driver load sequence.
> Kerneldoc explains why. Similar, but inverted for unloading:
> drm_dev_unregister is the very first thing you must call.

Thanks, and also for embedding the drm device.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Mon, 24 Oct 2016 16:04:19 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> Hi,

Hi Maxime,

> On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> > Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> > engine, DE2.
> > This patch adds a DRM video driver for this device.
> > 
> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> 
> Output from checkpatch:
> total: 0 errors, 20 warnings, 83 checks, 1799 lines checked
> 
> > ---
> >  .../bindings/display/sunxi/sunxi-de2.txt   |  83 +++
> >  drivers/gpu/drm/Kconfig|   2 +
> >  drivers/gpu/drm/Makefile   |   1 +
> >  drivers/gpu/drm/sunxi/Kconfig  |  21 +
> >  drivers/gpu/drm/sunxi/Makefile |   7 +
> >  drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +
> >  drivers/gpu/drm/sunxi/de2_crtc.h   |  63 +++
> >  drivers/gpu/drm/sunxi/de2_de.c | 591 
> > +
> >  drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
> >  drivers/gpu/drm/sunxi/de2_drv.c| 378 +
> >  drivers/gpu/drm/sunxi/de2_plane.c  | 119 +
> >  11 files changed, 1787 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> >  create mode 100644 drivers/gpu/drm/sunxi/Kconfig
> >  create mode 100644 drivers/gpu/drm/sunxi/Makefile
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
> >  create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
> > 
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt 
> > b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> > new file mode 100644
> > index 000..f9cd67a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> > @@ -0,0 +1,83 @@
> > +Allwinner sunxi Display Engine 2 subsystem
> > +==
> > +
> > +The sunxi DE2 subsystem contains a display controller (DE2),
> 
> sunxi is a made up name, and doesn't really mean anything. You can
> call it either sun8i (because it was introduced in that family).

OK.

> > +one or two LCD controllers (TCON) and their external interfaces.
> > +
> > +Display controller
> > +==
> > +
> > +Required properties:
> > +
> > +- compatible: value should be one of the following
> > +   "allwinner,sun8i-a83t-display-engine"
> > +   "allwinner,sun8i-h3-display-engine"
> > +
> > +- clocks: must include clock specifiers corresponding to entries in the
> > +   clock-names property.
> > +
> > +- clock-names: must contain
> > +   "gate": for DE activation
> > +   "clock": DE clock
> 
> We've been calling them bus and mod.

I can understand "bus" (which is better than "apb"), but why "mod"?

> > +
> > +- resets: phandle to the reset of the device
> > +
> > +- ports: phandle's to the LCD ports
> 
> Please use the OF graph.

These ports are references to the graph of nodes. See
http://www.kernelhub.org/?msg=911825=2

[snip]
> > diff --git a/drivers/gpu/drm/sunxi/de2_crtc.c 
> > b/drivers/gpu/drm/sunxi/de2_crtc.c
> > new file mode 100644
> > index 000..dae0fab
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sunxi/de2_crtc.c
> > @@ -0,0 +1,475 @@
> > +/*
> > + * Allwinner DRM driver - DE2 CRTC
> > + *
> > + * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
> > + *
> > + * 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 "de2_drm.h"
> > +#include "de2_crtc.h"
> > +
> > +/* I/O map */
> > +
> > +struct tcon {
> > +   u32 gctl;
> > +#defineTCON_GCTL_TCON_En BIT(31)
>

[linux-sunxi] 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)
>  

Re: [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Jean-Francois Moine]

On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai  wrote:

> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
> 
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.
> 
> > - it creates the sound card (with sun4i-i2s, the sound card is created
> >   by the CODECs)
> 
> I think this is wrong. I2S is only the DAI. You typically have a separate
> platform driver for the whole card, or just use simple-card.

An other device is not needed. The layout is simple:
I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
The HDMI CODEC is supported by the HDMI video driver (only one device),
so, it cannot be the card device.
ASoC does not use the CPU DAI device (I2S_controller), so, it is
natural to use it to handle the card.
Otherwise, the simple-card asks for a node definition in the DT and
this node is a pure Linux software entity. On the other side, the
simple-graph-card from Kuninori is not useful for this simple case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video

[Jean-Francois Moine]

On Sun, 23 Oct 2016 09:38:04 +0800
Chen-Yu Tsai  wrote:

> > Recently, an announce about Tina OS for the R series
> > https://www.youtube.com/watch?v=h7KD-6HblAU
> > was followed by the upload of a new linux-3.4 source tree
> > https://github.com/tinalinux/linux-3.4
> > with files containing GPL headers.
> >
> > Well, I don't know if these sources are really from Allwinner, but
> > anyway, this is the opportunity to propose a new version of my DRM
> > HDMI driver.
> 
> Could you clarify about this bit? Did you just clean up Allwinner's
> existing drivers? Or just use them as reference? Either way I think
> this deserves some mention in all your copyright headers.
> 
> Otherwise what difference does the new release make?

- Allwinner's video driver is not DRM.
- their driver has no hardware cursor nor video overlay.
- I wrote the video DRM driver from the document
Allwinner_H3_Datasheet_V1.2.pdf
  and the structures defined in
linux-3.4/drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_rtmx.h
  Reading Allwinner's code helped me to understand how the DE2
  is working.
- my lowlevel HDMI is just a cleanup of theirs with explanations
  about the registers. Magic constants remain due to the lack of
  knowledge about the PHYs.
- the mention of Allwinner in the copyright headers is needed to
  indicate the source of the structures (DE2) and code (HDMI).

The main difference is the DRM interface and the use of the EDID,
permitting dynamic video resolution change with xrandr.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 6/7] ARM: dts: sun8i-h3: Add HDMI audio and video to the Banana Pi M2+

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
The patch for the Banana Pi M3 (A83T) is the same as this one.
---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index 06fddaa..2e81de8 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -55,6 +55,7 @@
aliases {
serial0 = 
serial1 = 
+   lcd0 = 
};
 
chosen {
@@ -93,6 +94,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -101,12 +106,24 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 5/7] ARM: dts: sun8i-h3: add HDMI audio and video nodes

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
The patch for the A83T DT is not included in this patchset because
the clock driver sunxi-ng does not support the A83T clocks.
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 67 +
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..869f3be 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -140,6 +140,16 @@
#size-cells = <1>;
ranges;
 
+   de: de-controller@0100 {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   reg = <0x0100 0x40>;
+   clocks = < CLK_BUS_DE>, < CLK_DE>;
+   clock-names = "gate", "clock";
+   resets = < RST_BUS_DE>;
+   ports = <_p>;
+   status = "disabled";
+   };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
@@ -149,6 +159,23 @@
#dma-cells = <1>;
};
 
+   lcd0: lcd-controller@01c0c000 {
+   compatible = "allwinner,sun8i-a83t-lcd";
+   reg = <0x01c0c000 0x400>;
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "gate", "clock";
+   resets = < RST_BUS_TCON0>;
+   interrupts = ;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   lcd0_p: port {
+   lcd0_hdmi: endpoint {
+   remote-endpoint = <_lcd0>;
+   };
+   };
+   };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -439,6 +466,22 @@
status = "disabled";
};
 
+   i2s2: i2s@1c22800 {
+   compatible = "allwinner,sun8i-h3-i2s";
+   reg = <0x01c22800 0x60>;
+   clocks = < CLK_I2S2>;
+   clock-names = "mod";
+   resets = < RST_BUS_I2S2>;
+   dmas = < 27>;
+   dma-names = "tx";
+   status = "disabled";
+   port {
+   i2s2_hdmi: endpoint {
+   remote-endpoint = <_i2s2>;
+   };
+   };
+   };
+
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -541,6 +584,30 @@
interrupts = ;
};
 
+   hdmi: hdmi@01ee {
+   compatible = "allwinner,sun8i-h3-hdmi";
+   reg = <0x01ee 0x2>;
+   clocks = < CLK_HDMI>, < CLK_HDMI_DDC>;
+   clock-names = "clock", "ddc-clock";
+   resets = < RST_BUS_HDMI0>, < RST_BUS_HDMI1>;
+   reset-names = "hdmi0", "hdmi1";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   hdmi_lcd0: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   hdmi_i2s2: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   };
+
rtc: rtc@01f0 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f0 0x54>;
-- 
2.10.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Jean-Francois Moine]

This patch adds I2S support to sun8i SoCs as the A83T and H3.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
Note: This driver is closed to the sun4i-i2s except that:
- it handles the H3
- it creates the sound card (with sun4i-i2s, the sound card is created
  by the CODECs)
---
 .../devicetree/bindings/sound/sun4i-i2s.txt|  38 +-
 sound/soc/sunxi/Kconfig|   8 +
 sound/soc/sunxi/Makefile   |   3 +
 sound/soc/sunxi/sun8i-i2s.c| 700 +
 4 files changed, 744 insertions(+), 5 deletions(-)
 create mode 100644 sound/soc/sunxi/sun8i-i2s.c

diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt 
b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7b526ec..2fb0a7a 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -1,4 +1,4 @@
-* Allwinner A10 I2S controller
+* Allwinner A10/A38T/H3 I2S controller
 
 The I2S bus (Inter-IC sound bus) is a serial link for digital
 audio data transfer between devices in the system.
@@ -6,20 +6,30 @@ audio data transfer between devices in the system.
 Required properties:
 
 - compatible: should be one of the followings
-   - "allwinner,sun4i-a10-i2s"
+  - "allwinner,sun4i-a10-i2s"
+   "allwinner,sun8i-a83t-i2s"
+   "allwinner,sun8i-h3-i2s"
 - reg: physical base address of the controller and length of memory mapped
   region.
-- interrupts: should contain the I2S interrupt.
 - dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: should include "tx" and "rx".
+- dma-names: must include "tx" and/or "rx".
 - clocks: a list of phandle + clock-specifer pairs, one for each entry in 
clock-names.
 - clock-names: should contain followings:
- "apb" : clock for the I2S bus interface
- "mod" : module clock for the I2S controller
 - #sound-dai-cells : Must be equal to 0
 
-Example:
+Optional properties:
+
+- interrupts: I2S interrupt
+- resets: phandle to the reset of the device
+
+Required nodes:
+
+ - port: link to the associated CODEC (DAC, HDMI...)
+
+Example 1:
 
 i2s0: i2s@01c22400 {
#sound-dai-cells = <0>;
@@ -32,3 +42,21 @@ i2s0: i2s@01c22400 {
   < SUN4I_DMA_NORMAL 3>;
dma-names = "rx", "tx";
 };
+
+Example 2:
+
+i2s2: i2s@1c22800 {
+   compatible = "allwinner,sun8i-a83t-i2s";
+   reg = <0x01c22800 0x60>;
+   clocks = < CLK_BUS_I2S2>, < CLK_I2S2>;
+   clock-names = "apb", "mod";
+   resets = < RST_I2S2>;
+   dmas = < 27>;
+   dma-names = "tx";
+   status = "disabled";
+   port {
+   i2s2_hdmi: endpoint {
+   remote-endpoint = <_i2s2>;
+   };
+   };
+};
diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index dd23682..d89b2da 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -26,4 +26,12 @@ config SND_SUN4I_SPDIF
help
  Say Y or M to add support for the S/PDIF audio block in the Allwinner
  A10 and affiliated SoCs.
+
+config SND_SUN8I_I2S
+   tristate "Allwinner sun8i I2S Support"
+   depends on OF
+   select SND_SOC_GENERIC_DMAENGINE_PCM
+   help
+ Say Y or M if you want to add support for SoC audio on
+ Allwinner sun8i boards.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index 604c7b84..bcb871b 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,3 +1,6 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o
 obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
+
+snd-soc-sun8i-i2s-objs := sun8i-i2s.o
+obj-$(CONFIG_SND_SUN8I_I2S) += snd-soc-sun8i-i2s.o
diff --git a/sound/soc/sunxi/sun8i-i2s.c b/sound/soc/sunxi/sun8i-i2s.c
new file mode 100644
index 000..ba15d62
--- /dev/null
+++ b/sound/soc/sunxi/sun8i-i2s.c
@@ -0,0 +1,700 @@
+/*
+ * Allwinner sun8i I2S sound card
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ *
+ * 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 
+
+/* --- hardware --- */
+
+#define I2S_CTL0x00
+   /* common */
+   #define I2S_CTL_SDO3EN  BIT(11)
+   #define I2S_CTL_SDO2EN  BIT(10)
+   #define I2S_CTL_SDO1EN  BIT(9)
+   #define I2S_CTL_SDO0E

[linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC

[Jean-Francois Moine]

Allwinner's SoCs include support for both audio and video on HDMI.
This patch defines a simple audio CODEC which may be used in sunxi
HDMI video drivers.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 include/sound/sunxi_hdmi.h|  23 +
 sound/soc/codecs/Kconfig  |   9 
 sound/soc/codecs/Makefile |   2 +
 sound/soc/codecs/sunxi-hdmi.c | 106 ++
 4 files changed, 140 insertions(+)
 create mode 100644 include/sound/sunxi_hdmi.h
 create mode 100644 sound/soc/codecs/sunxi-hdmi.c

diff --git a/include/sound/sunxi_hdmi.h b/include/sound/sunxi_hdmi.h
new file mode 100644
index 000..0986bb9
--- /dev/null
+++ b/include/sound/sunxi_hdmi.h
@@ -0,0 +1,23 @@
+#ifndef __SUNXI_HDMI_H__
+#define __SUNXI_HDMI_H__
+/*
+ * Copyright (C) 2016 Jean-François Moine
+ *
+ * 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.
+ */
+
+struct sunxi_hdmi_codec {
+   u8 *eld;
+   int (*set_audio_input)(struct device *dev,
+   int enable,
+   unsigned sample_rate,
+   unsigned sample_bit);
+};
+
+int sunxi_hdmi_codec_register(struct device *dev);
+void sunxi_hdmi_codec_unregister(struct device *dev);
+
+#endif /* __SUNXI_HDMI_H__ */
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index c67667b..53385b1 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -131,6 +131,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_STA529 if I2C
select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
select SND_SOC_STI_SAS
+   select SND_SOC_SUNXI_HDMI
select SND_SOC_TAS2552 if I2C
select SND_SOC_TAS5086 if I2C
select SND_SOC_TAS571X if I2C
@@ -793,6 +794,14 @@ config SND_SOC_STAC9766
 config SND_SOC_STI_SAS
tristate "codec Audio support for STI SAS codec"
 
+config SND_SOC_SUNXI_HDMI
+   tristate "Allwinner sunxi HDMI Support"
+   default m if DRM_SUNXI_DE2_HDMI=m
+   default y if DRM_SUNXI_DE2_HDMI=y
+   select SND_PCM_ELD
+   help
+ Enable HDMI audio output
+
 config SND_SOC_TAS2552
tristate "Texas Instruments TAS2552 Mono Audio amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 958cd49..35804eb 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -139,6 +139,7 @@ snd-soc-sta350-objs := sta350.o
 snd-soc-sta529-objs := sta529.o
 snd-soc-stac9766-objs := stac9766.o
 snd-soc-sti-sas-objs := sti-sas.o
+snd-soc-sunxi-hdmi-objs := sunxi-hdmi.o
 snd-soc-tas5086-objs := tas5086.o
 snd-soc-tas571x-objs := tas571x.o
 snd-soc-tas5720-objs := tas5720.o
@@ -359,6 +360,7 @@ obj-$(CONFIG_SND_SOC_STA350)   += snd-soc-sta350.o
 obj-$(CONFIG_SND_SOC_STA529)   += snd-soc-sta529.o
 obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o
 obj-$(CONFIG_SND_SOC_STI_SAS)  += snd-soc-sti-sas.o
+obj-$(CONFIG_SND_SOC_SUNXI_HDMI)   += snd-soc-sunxi-hdmi.o
 obj-$(CONFIG_SND_SOC_TAS2552)  += snd-soc-tas2552.o
 obj-$(CONFIG_SND_SOC_TAS5086)  += snd-soc-tas5086.o
 obj-$(CONFIG_SND_SOC_TAS571X)  += snd-soc-tas571x.o
diff --git a/sound/soc/codecs/sunxi-hdmi.c b/sound/soc/codecs/sunxi-hdmi.c
new file mode 100644
index 000..0d08676
--- /dev/null
+++ b/sound/soc/codecs/sunxi-hdmi.c
@@ -0,0 +1,106 @@
+/*
+ * Allwinner HDMI codec
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ *
+ * 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 "sound/sunxi_hdmi.h"
+
+#define SUNXI_HDMI_FORMATS (SNDRV_PCM_FMTBIT_S8 | \
+ SNDRV_PCM_FMTBIT_S16_LE | \
+ SNDRV_PCM_FMTBIT_S20_3LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE)
+
+static int sunxi_hdmi_codec_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct sunxi_hdmi_codec *priv = dev_get_drvdata(dai->dev);
+   u8 *eld;
+
+   eld = priv->eld;
+   if (!eld)
+   return -ENODEV;
+
+   return snd_pcm_hw_constraint_eld(runtime, eld);
+}
+
+static int sunxi_hdmi_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+   struct sunxi_hdmi_codec *

[linux-sunxi] [PATCH v5 7/7] ARM: dts: sun8i-h3: Add HDMI audio and video to the Orange PI 2

[Jean-Francois Moine]

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
The same patch may be applied to other H3 based boards (Orange PI xx).
---
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index e5bcaba..799ceb9 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -56,6 +56,7 @@
serial0 = 
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
ethernet1 = 
+   lcd0 = 
};
 
chosen {
@@ -105,16 +106,32 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 3/7] drm: sunxi: add DE2 HDMI support

[Jean-Francois Moine]

This patch adds a HDMI driver to the DE2 based Allwinner's SoCs
as A83T and H3.
Audio and video are supported.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 .../devicetree/bindings/display/sunxi/hdmi.txt |  52 ++
 drivers/gpu/drm/sunxi/Kconfig  |   8 +
 drivers/gpu/drm/sunxi/Makefile |   2 +
 drivers/gpu/drm/sunxi/de2_hdmi.c   | 396 +
 drivers/gpu/drm/sunxi/de2_hdmi.h   |  40 +
 drivers/gpu/drm/sunxi/de2_hdmi_io.c| 927 +
 drivers/gpu/drm/sunxi/de2_hdmi_io.h|  25 +
 7 files changed, 1450 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.h

diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt 
b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
new file mode 100644
index 000..0558c07
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
@@ -0,0 +1,52 @@
+Allwinner HDMI Transmitter
+==
+
+The Allwinner HDMI transmitters are included in the SoCs.
+They support audio and video.
+
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be
+   "allwinner,sun8i-a83t-hdmi" or
+   "allwinner,sun8i-h3-hdmi"
+ - clocks : phandles to the HDMI clocks as described in
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+ - clock-names : must be
+   "gate" : bus gate
+   "clock" : streaming clock
+   "ddc-clock" : DDC clock
+ - resets : One or two phandles to the HDMI resets
+ - reset-names : must be
+   "hdmi0" and "hdmi1"
+
+Required nodes:
+ - port: Audio and video input port nodes with endpoint definitions
+   as defined in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+   hdmi: hdmi@01ee {
+   compatible = "allwinner,sun8i-a83t-hdmi";
+   reg = <0x01ee 0x2>;
+   clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
+< CLK_HDMI_DDC>;
+   clock-names = "gate", "clock", "ddc-clock";
+   resets = < RST_HDMI0>, < RST_HDMI1>;
+   reset-names = "hdmi0", "hdmi1";
+   ...
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {/* video */
+   reg = <0>;
+   hdmi_lcd1: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   port@1 {/* audio */
+   reg = <1>;
+   hdmi_i2s2: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/sunxi/Kconfig b/drivers/gpu/drm/sunxi/Kconfig
index 56bde2e..4c82153 100644
--- a/drivers/gpu/drm/sunxi/Kconfig
+++ b/drivers/gpu/drm/sunxi/Kconfig
@@ -19,3 +19,11 @@ config DRM_SUNXI_DE2
  Choose this option if your Allwinner chipset has the DE2 interface
  as the A64, A83T and H3. If M is selected the module will be called
  sunxi-de2-drm.
+
+config DRM_SUNXI_DE2_HDMI
+   tristate "Support for DE2 HDMI"
+   depends on DRM_SUNXI_DE2
+   select SND_SOC_SUNXI_HDMI if SND_SOC
+   help
+ Choose this option if you use want HDMI on DE2.
+ If M is selected the module will be called sunxi-de2-hdmi.
diff --git a/drivers/gpu/drm/sunxi/Makefile b/drivers/gpu/drm/sunxi/Makefile
index 62220cb..a268069 100644
--- a/drivers/gpu/drm/sunxi/Makefile
+++ b/drivers/gpu/drm/sunxi/Makefile
@@ -3,5 +3,7 @@
 #
 
 sunxi-de2-drm-objs := de2_drv.o de2_de.o de2_crtc.o de2_plane.o
+sunxi-de2-hdmi-objs := de2_hdmi.o de2_hdmi_io.o
 
 obj-$(CONFIG_DRM_SUNXI_DE2) += sunxi-de2-drm.o
+obj-$(CONFIG_DRM_SUNXI_DE2_HDMI) += sunxi-de2-hdmi.o
diff --git a/drivers/gpu/drm/sunxi/de2_hdmi.c b/drivers/gpu/drm/sunxi/de2_hdmi.c
new file mode 100644
index 000..a2324cc
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_hdmi.c
@@ -0,0 +1,396 @@
+/*
+ * Allwinner DRM driver - HDMI
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moin...@free.fr>
+ *
+ * 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)

[linux-sunxi] [PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video

[Jean-Francois Moine]

This patchset series adds HDMI audio and video support to the Allwinner
sun8i SoCs which include the display engine 2 (DE2).

A first submission in January for video on the H3 could not enter into
the mainline kernel due to the lack of license headers in Allwinner's
sources.

Recently, an announce about Tina OS for the R series
https://www.youtube.com/watch?v=h7KD-6HblAU
was followed by the upload of a new linux-3.4 source tree
https://github.com/tinalinux/linux-3.4
with files containing GPL headers.

Well, I don't know if these sources are really from Allwinner, but
anyway, this is the opportunity to propose a new version of my DRM
HDMI driver.

v5:
- add overlay plane
- add audio support
- add support for the A83T
- add back the HDMI driver
- many bug fixes
v4: 
- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
v3:
- add the hardware cursor
- simplify and fix the DE2 init sequences
- generation for all SUNXI SoCs (Andre Przywara)
v2:
- remove the HDMI driver
- remarks from Chen-Yu Tsai and Russell King
- DT documentation added

Jean-Francois Moine (7):
  drm: sunxi: Add a basic DRM driver for Allwinner DE2
  ASoC: sunxi: Add a simple HDMI CODEC
  drm: sunxi: add DE2 HDMI support
  ASoC: sunxi: Add sun8i I2S driver
  ARM: dts: sun8i-h3: add HDMI audio and video nodes
  ARM: dts: sun8i-h3: Add HDMI audio and video to the Banana Pi M2+
  ARM: dts: sun8i-h3: Add HDMI audio and video to the Orange PI 2

 .../devicetree/bindings/display/sunxi/hdmi.txt |  52 ++
 .../bindings/display/sunxi/sunxi-de2.txt   |  83 ++
 .../devicetree/bindings/sound/sun4i-i2s.txt|  38 +-
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  17 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  17 +
 arch/arm/boot/dts/sun8i-h3.dtsi|  67 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/sunxi/Kconfig  |  29 +
 drivers/gpu/drm/sunxi/Makefile |   9 +
 drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +++
 drivers/gpu/drm/sunxi/de2_crtc.h   |  63 ++
 drivers/gpu/drm/sunxi/de2_de.c | 591 +
 drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
 drivers/gpu/drm/sunxi/de2_drv.c| 378 +
 drivers/gpu/drm/sunxi/de2_hdmi.c   | 396 +
 drivers/gpu/drm/sunxi/de2_hdmi.h   |  40 +
 drivers/gpu/drm/sunxi/de2_hdmi_io.c| 927 +
 drivers/gpu/drm/sunxi/de2_hdmi_io.h|  25 +
 drivers/gpu/drm/sunxi/de2_plane.c  | 119 +++
 include/sound/sunxi_hdmi.h |  23 +
 sound/soc/codecs/Kconfig   |   9 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/sunxi-hdmi.c  | 106 +++
 sound/soc/sunxi/Kconfig|   8 +
 sound/soc/sunxi/Makefile   |   3 +
 sound/soc/sunxi/sun8i-i2s.c| 700 
 27 files changed, 4222 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
 create mode 100644 include/sound/sunxi_hdmi.h
 create mode 100644 sound/soc/codecs/sunxi-hdmi.c
 create mode 100644 sound/soc/sunxi/sun8i-i2s.c

-- 
2.10.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
engine, DE2.
This patch adds a DRM video driver for this device.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 .../bindings/display/sunxi/sunxi-de2.txt   |  83 +++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/sunxi/Kconfig  |  21 +
 drivers/gpu/drm/sunxi/Makefile |   7 +
 drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +
 drivers/gpu/drm/sunxi/de2_crtc.h   |  63 +++
 drivers/gpu/drm/sunxi/de2_de.c | 591 +
 drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
 drivers/gpu/drm/sunxi/de2_drv.c| 378 +
 drivers/gpu/drm/sunxi/de2_plane.c  | 119 +
 11 files changed, 1787 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt 
b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
new file mode 100644
index 000..f9cd67a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
@@ -0,0 +1,83 @@
+Allwinner sunxi Display Engine 2 subsystem
+==
+
+The sunxi DE2 subsystem contains a display controller (DE2),
+one or two LCD controllers (TCON) and their external interfaces.
+
+Display controller
+==
+
+Required properties:
+
+- compatible: value should be one of the following
+   "allwinner,sun8i-a83t-display-engine"
+   "allwinner,sun8i-h3-display-engine"
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: must contain
+   "gate": for DE activation
+   "clock": DE clock
+
+- resets: phandle to the reset of the device
+
+- ports: phandle's to the LCD ports
+
+LCD controller
+==
+
+Required properties:
+
+- compatible: value should be one of the following
+   "allwinner,sun8i-a83t-lcd"
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: must contain
+   "gate": for LCD activation
+   "clock": pixel clock
+
+- resets: phandle to the reset of the device
+
+- port: port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   de: de-controller@0100 {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   ...
+   clocks = <& CLK_BUS_DE>, < CLK_DE>;
+   clock-names = "gate", "clock";
+   resets = < RST_BUS_DE>;
+   ports = <_p>;
+   };
+
+   lcd0: lcd-controller@01c0c000 {
+   compatible = "allwinner,sun8i-a83t-lcd";
+   ...
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "gate", "clock";
+   resets = < RST_BUS_TCON0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   lcd0_p: port {
+   lcd0_ep: endpoint {
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+
+   hdmi: hdmi@01ee {
+   ...
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port {
+   type = "video";
+   hdmi_ep: endpoint {
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 483059a..afd576f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -187,6 +187,8 @@ source "drivers/gpu/drm/shmobile/Kconfig"
 
 source "drivers/gpu/drm/sun4i/Kconfig"
 
+source "drivers/gpu/drm/sunxi/Kconfig"
+
 source "drivers/gpu/drm/omapdrm/Kconfig"
 
 source "drivers/gpu/drm/tilcdc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 25c7204..120d0bf

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [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

[linux-sunxi] [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_

[linux-sunxi] [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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [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>

[linux-sunxi] [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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [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

[linux-sunxi] [PATCH] dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant

[Jean-Francois Moine]

The A83T SoC has the same dma engine as the A31 (sun6i), with a reduced
amount of endpoints and physical channels.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
 drivers/dma/sun6i-dma.c | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt 
b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index d13c136..6b26704 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -7,6 +7,7 @@ Required properties:
 - compatible:  Must be one of
  "allwinner,sun6i-a31-dma"
  "allwinner,sun8i-a23-dma"
+ "allwinner,sun8i-a83t-dma"
  "allwinner,sun8i-h3-dma"
 - reg: Should contain the registers base address and length
 - interrupts:  Should contain a reference to the interrupt used by this device
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 3835fcd..8346199 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1011,6 +1011,12 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_vchans   = 37,
 };
 
+static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
+   .nr_max_channels = 8,
+   .nr_max_requests = 28,
+   .nr_max_vchans   = 39,
+};
+
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
@@ -1025,6 +1031,7 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
 static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun6i-a31-dma", .data = _a31_dma_cfg },
{ .compatible = "allwinner,sun8i-a23-dma", .data = _a23_dma_cfg },
+   { .compatible = "allwinner,sun8i-a83t-dma", .data = _a83t_dma_cfg 
},
{ .compatible = "allwinner,sun8i-h3-dma", .data = _h3_dma_cfg },
{ /* sentinel */ }
 };
-- 
2.10.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v3] mmc: sunxi: Handle the 'New Timing' mode

[Jean-Francois Moine]

On Tue, 30 Aug 2016 18:26:13 +0200
Maxime Ripard  wrote:

> > There are 2 flags saying that the new timing is used:
> > - the bit 'mode select' in the clock register, and
> > - the bit 'new timing' in the MMC register.
> > Both bits must be set/reset at the same time, otherwise the device
> > does not work (tested with wifi and eMMC in H3 and A83T boards).
> > So, some synchronization must exist.
> > 
> > The previous versions was using a DT property for the MMC and a flag
> > in the clock driver. This did work with a correct configuration
> > on both sides, but experiment showed that it was easy to do an error.
> 
> I still believe that we will need a property, at least to identify on
> which we can try the new mode, and on which clocks it's irrelevant (at
> least for the A33 and A83T).

As told above, setting the new mode on side (clock or MMC) and not on
the other one prevents the devices to work. Then, it is safer to have
the new mode capability flag only once for both sides.

Now, as the clocks are defined by memory tables and not by the DT, it
seems natural to have the flag on the clock side.

> However, I also believe we should make that mode switching explicit
> through a function call, instead of relying on some side effect (of
> some non-upstream code).

Do you mean a direct call from the MMC driver to the clock driver?

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH RESEND] mmc: sunxi: Check the value returned by clk_round_rate

[Jean-Francois Moine]

clk_round_rate() may return an error. Check it.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com>
---
Rebase on linux-next
---
 drivers/mmc/host/sunxi-mmc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 2ec91ce..142ab3f 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -692,7 +692,8 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host 
*host,
 static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
  struct mmc_ios *ios)
 {
-   u32 rate, rval, clock = ios->clock;
+   long rate;
+   u32 rval, clock = ios->clock;
int ret;
 
/* 8 bit DDR requires a higher module clock */
@@ -701,13 +702,18 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
clock <<= 1;
 
rate = clk_round_rate(host->clk_mmc, clock);
-   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %d\n",
+   if (rate < 0) {
+   dev_err(mmc_dev(host->mmc), "error rounding clk to %d: %ld\n",
+   clock, rate);
+   return rate;
+   }
+   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %ld\n",
clock, rate);
 
/* setting clock rate */
ret = clk_set_rate(host->clk_mmc, rate);
if (ret) {
-   dev_err(mmc_dev(host->mmc), "error setting clk to %d: %d\n",
+   dev_err(mmc_dev(host->mmc), "error setting clk to %ld: %d\n",
rate, ret);
return ret;
}
-- 
2.9.3

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v2 0/3] clk: sunxi-ng: Add the A83T clocks

[Jean-Francois Moine]

On Mon, 22 Aug 2016 02:23:51 +0800
Vishnu Patekar  wrote:

> Thanks for followup patches for a83t modern clock.
> 
> well, this patch series does not apply on sunxi/for-next.

Hi Vishnu,

This series is rather old!
Well, at this time, I was thinking that the 'modern' clock (aka
sunxi-ng) was a good thing, but, just after sending this series, I was
blocked, mainly because of the 'new timing' of the MMC clocks.
So, I rewrote and simplified the sunxi clock driver, and I submitted a
'ccu' patch which was refused by Maxime and Mike.

Actually, my 'ccu' driver is almost finished. The code is only 1200
lines in one file. It contains optimized computation of the clock
parameters, handles the H3 CPU frequency, the MMC 'new timing',
sigma-delta modulation for the audio PLL, the PRCM clocks and more.
The SoC specific tables (actually H3 and A83T) are about 10kB, but they
are defined as templates in .init.rodata, so that only the tables of the
current SoC remain in memory after system init.

This driver works fine for my Allwinner's boards and I will never go
back to the 'sunxi-ng' which is rather complex and lacks of flexibility.
If you are interested, the source is available in my site (see below).

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2] regulator: axp20x: support AXP803/AXP813 variants

[Jean-Francois Moine]

The X-Powers AXP803 and AXP813 PMICs are close to the AXP809 with some
more outputs.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
The AXP813 has been tested in a Banana PI M3 board (needed for WiFi/BT).
v2:
- fix lack of support of dcdc frequency
- notice that the AXP803 is also handled
- send the patch to the DT maintainers
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 32 -
 drivers/mfd/axp20x-rsb.c |  1 +
 drivers/mfd/axp20x.c |  3 +
 drivers/regulator/axp20x-regulator.c | 83 +++-
 include/linux/mfd/axp20x.h   | 38 +++
 5 files changed, 154 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 585a955..856a9ff 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -7,10 +7,12 @@ axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (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,axp809"
+ "x-powers,axp221", "x-powers,axp223", "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
@@ -110,6 +112,34 @@ LDO_IO1: LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 SW : On/Off Switch : swin-supply
 
+AXP803/AXP813 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
+DCDC7  : DC-DC buck: vin7-supply   : AXP813 only
+RTC_LDO: LDO   : ips-supply: always on
+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
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+
 Example:
 
 axp209: pmic@34 {
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a407527..e34643b 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -62,6 +62,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
+   { .compatible = "x-powers,axp813", .data = (void *)AXP813_ID },
{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index fd80b09..e62d56f 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -39,6 +39,7 @@ static const char * const axp20x_model_names[] = {
"AXP223",
"AXP288",
"AXP809",
+   "AXP813",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -494,6 +495,7 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip 
= {
 
 };
 
+/* common 803/809/813 */
 static const struct regmap_irq_chip axp809_regmap_irq_chip = {
.name   = "axp809",
.status_base= AXP20X_IRQ1_STATE,
@@ -733,6 +735,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
   

[linux-sunxi] [PATCH v3] mmc: sunxi: Handle the 'New Timing' mode

[Jean-Francois Moine]

Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have
a 'New Timing' mode.
When aware about this capability, and when this is possible (clock
rate great enough), the clock driver switches the MMC clock to the
'new mode', meaning that the phase delays are defined in the MMC
registers instead of in the clock registers.
To alert the MMC driver about this switch, the clock driver returns
the error code EPERM on calling clk_set_phase().

This patch makes the MMC driver to handle this returned code and to
activate or not the 'New Timing' mode on the MMC side.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
Some explanations:
In the old timing, the phase delays are set in the clock only
(that's why there is a function clk_set_phase() which is called from
the MMC side).
In the new timing, the delays are in the MMC register SDXC_REG_NTSR
only.
The new timing works only when the clock rate is greater or equal
to 50MHz.

There are 2 flags saying that the new timing is used:
- the bit 'mode select' in the clock register, and
- the bit 'new timing' in the MMC register.
Both bits must be set/reset at the same time, otherwise the device
does not work (tested with wifi and eMMC in H3 and A83T boards).
So, some synchronization must exist.

The previous versions was using a DT property for the MMC and a flag
in the clock driver. This did work with a correct configuration
on both sides, but experiment showed that it was easy to do an error.

The actual version asks for just a flag (and a rate) in the clock
driver and the synchronization is done by a specific error code.
It depends on my previous patch
 'clk: core: Force setting the phase delay when no change'.

The patch relative to the clock side is not included here.
It depends on 'which driver?'.
v3
- use an error code from the clock driver to enable/disable the
  'new timing'
v2
- use a DT property about the 'new timing' capability of
  the MMC device
---
 drivers/mmc/host/sunxi-mmc.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index ba647b7..d0ffe8b 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -64,6 +64,7 @@
 #define SDXC_REG_CBCR  (0x48) /* SMC CIU Byte Count Register */
 #define SDXC_REG_BBCR  (0x4C) /* SMC BIU Byte Count Register */
 #define SDXC_REG_DBGC  (0x50) /* SMC Debug Enable Register */
+#define SDXC_REG_NTSR  (0x5c) /* SMC NewTiming Set Register */
 #define SDXC_REG_HWRST (0x78) /* SMC Card Hardware Reset for Register */
 #define SDXC_REG_DMAC  (0x80) /* SMC IDMAC Control Register */
 #define SDXC_REG_DLBA  (0x84) /* SMC IDMAC Descriptor List Base Addre */
@@ -171,6 +172,9 @@
 #define SDXC_SEND_AUTO_STOPCCSDBIT(9)
 #define SDXC_CEATA_DEV_IRQ_ENABLE  BIT(10)
 
+/* NewTiming Set Register */
+#define SDXC_NEWMODE_ENABLEBIT(31)
+
 /* IDMA controller bus mod bit field */
 #define SDXC_IDMAC_SOFT_RESET  BIT(0)
 #define SDXC_IDMAC_FIX_BURST   BIT(1)
@@ -218,8 +222,8 @@
 #define SDXC_CLK_50M_DDR_8BIT  4
 
 struct sunxi_mmc_clk_delay {
-   u32 output;
-   u32 sample;
+   u16 output;
+   u16 sample;
 };
 
 struct sunxi_idma_des {
@@ -721,8 +725,22 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
return -EINVAL;
}
 
-   clk_set_phase(host->clk_sample, sclk_dly);
-   clk_set_phase(host->clk_output, oclk_dly);
+   ret = clk_set_phase(host->clk_sample, sclk_dly);
+
+   /*
+* EPERM is returned when the MMC clock is switched to the new mode.
+* In this mode, the phase delays are defined in the MMC register NTSR.
+* Actually, as the reset/boot values are fine enough, these delays are
+* not changed here.
+*/
+   if (ret == -EPERM) {
+   mmc_writel(host, REG_NTSR,
+  mmc_readl(host, REG_NTSR) | SDXC_NEWMODE_ENABLE);
+   } else {
+   mmc_writel(host, REG_NTSR,
+  mmc_readl(host, REG_NTSR) & ~SDXC_NEWMODE_ENABLE);
+   clk_set_phase(host->clk_output, oclk_dly);
+   }
 
return sunxi_mmc_oclk_onoff(host, 1);
 }
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH] clk: core: Force setting the phase delay when no change

[Jean-Francois Moine]

The hardware phase delay may depend on some other settings as clock
reparenting, so, it has to be set each time.
Also, when the delay was the same as previously, an error was returned.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 drivers/clk/clk.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2e6b91e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1908,10 +1908,6 @@ int clk_set_phase(struct clk *clk, int degrees)
 
clk_prepare_lock();
 
-   /* bail early if nothing to do */
-   if (degrees == clk->core->phase)
-   goto out;
-
trace_clk_set_phase(clk->core, degrees);
 
if (clk->core->ops->set_phase)
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH RESEND] mmc: sunxi: Check the value returned by clk_round_rate

[Jean-Francois Moine]

clk_round_rate() may return an error. Check it.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com>
---
This patch was initially sent in a patch series about the MMC new mode,
but it may be applied independently.
---
 drivers/mmc/host/sunxi-mmc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 2ee4c21..ba647b7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -656,7 +656,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host 
*host, u32 oclk_en)
 static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
  struct mmc_ios *ios)
 {
-   u32 rate, oclk_dly, rval, sclk_dly;
+   long rate;
+   u32 oclk_dly, rval, sclk_dly;
u32 clock = ios->clock;
int ret;
 
@@ -666,13 +667,18 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
clock <<= 1;
 
rate = clk_round_rate(host->clk_mmc, clock);
-   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %d\n",
+   if (rate < 0) {
+   dev_err(mmc_dev(host->mmc), "error rounding clk to %d: %ld\n",
+   clock, rate);
+   return rate;
+   }
+   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %ld\n",
clock, rate);
 
/* setting clock rate */
ret = clk_set_rate(host->clk_mmc, rate);
if (ret) {
-   dev_err(mmc_dev(host->mmc), "error setting clk to %d: %d\n",
+   dev_err(mmc_dev(host->mmc), "error setting clk to %ld: %d\n",
rate, ret);
return ret;
}
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Handle the 'New Timings'

[Jean-Francois Moine]

On Tue, 2 Aug 2016 12:20:48 +0100
Mark Rutland  wrote:

> > This mode is described at least in the Allwinner's documentation of the
> > A83T, A64 and H3.
> 
> Is this publicly available? If not, can the gist of it be described?

The links are in the kernel Documentation/arm/sunxi/README

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Handle the 'New Timings'

[Jean-Francois Moine]

Hi Chen-Yu,

On Mon, 1 Aug 2016 21:52:48 +0800
Chen-Yu Tsai <w...@csie.org> wrote:

> On Mon, Aug 1, 2016 at 9:10 PM, Jean-Francois Moine <moin...@free.fr> wrote:
> > Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have
> > a 'New Timings' mode.
> > Set this capacity in the DT and use it when possible.
> 
>^^ capability?
> 
> Also, in this patch you are adding support for a DT boolean flag
> property, not adding stuff to the DT.

Sorry, forgotten.

> >
> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > ---
> 
> I got 3 copies of the same patch...

Maybe because I sent it to you, and to the mmc and sunxi lists.

> > I don't know if this mode works or is needed at 25MHz.
> 
> Could you test it? You can change mmc->f_max in the probe function
> to limit it to 25 MHz.
> 
> I'm more interested in the throughput you get after applying this
> patch though.

I did a test on a BPI-M2+ (H3). The new timings don't work at 25MHz,
neither for mmc1 (wifi) - nor for mmc2 (eMMC).

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Handle the 'New Timings'

[Jean-Francois Moine]

On Mon, 1 Aug 2016 16:30:19 +0100
Mark Rutland <mark.rutl...@arm.com> wrote:

> On Mon, Aug 01, 2016 at 03:10:29PM +0200, Jean-Francois Moine wrote:
> > Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have
> > a 'New Timings' mode.
> > Set this capacity in the DT and use it when possible.
> 
> What exactly is this "New Timings" mode?
> 
> Why do we wnat to set it? Improved performance, power?
> 
> Is it *necessary* to use it?

This mode is described at least in the Allwinner's documentation of the
A83T, A64 and H3.
>From my tests, it is required to access the eMMC of the Banana Pi M3
(mmc2).

> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > ---
> > I don't know if this mode works or is needed at 25MHz.
> > ---
> >  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt |  1 +
> >  drivers/mmc/host/sunxi-mmc.c| 21 
> > +++--
> >  2 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt 
> > b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > index 4bf41d8..a541bf4 100644
> > --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > @@ -19,6 +19,7 @@ Optional properties:
> >   - reset-names : must contain "ahb"
> >   - for cd, bus-width and additional generic mmc parameters
> > please refer to mmc.txt within this directory
> > + - allwinner,new-timings: the controller may accept the "New Timings" mode
> 
> It's not at all clear to me what this means. This needs a better
> description.
> 
> Which devices have this? Can we determine this based on compatible
> string?

No, only some devices of the SoCs have this capability: the mmc2 of the
A83T, the smhc0 and smhc1 of the A64, and the mmc1 and mmc2 of the H3.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

On Sat, 30 Jul 2016 12:19:03 +0200
Hans de Goede  wrote:

> Jean-Francois, can you submit a v2 of your patch and make the writing of
> SDXC_REG_NTSR depend on a new sun8i-a83t-mmc compatible ?
> 
> Also you should probably drop the bits about the clock stuff from the
> commit message as that just seems to confuse people.

Hi Hans,

I submitted a new patch (sorry, I forgot the history), but it asks for
some explanation.

- in the old timings, the phase delays are set in the clock.
  That's why there is a function clk_set_phase() which is called from
  the MMC side.

- in the new timings, the delays are in the MMC register SDXC_REG_NTSR
  only.
  In this case, the function clk_set_phase() is of no use
  (also, by test, it seems that the phase delays set by hardware
   reset do work, so, there is no need to set them), but,

- there is a bit in the clock telling that the new timings are used,
  i.e. that the phase delays of the clock must be ignored.

  Not setting this bit prevents the device to work (at least in the
  A83T, the H3 seems more helpful).

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2] mmc: sunxi: Handle the 'New Timings'

[Jean-Francois Moine]

Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have
a 'New Timings' mode.
Set this capacity in the DT and use it when possible.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
I don't know if this mode works or is needed at 25MHz.
---
 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt |  1 +
 drivers/mmc/host/sunxi-mmc.c| 21 +++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt 
b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
index 4bf41d8..a541bf4 100644
--- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
@@ -19,6 +19,7 @@ Optional properties:
  - reset-names : must contain "ahb"
  - for cd, bus-width and additional generic mmc parameters
please refer to mmc.txt within this directory
+ - allwinner,new-timings: the controller may accept the "New Timings" mode
 
 Examples:
- Within .dtsi:
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 2ee4c21..98922b5 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -64,6 +64,7 @@
 #define SDXC_REG_CBCR  (0x48) /* SMC CIU Byte Count Register */
 #define SDXC_REG_BBCR  (0x4C) /* SMC BIU Byte Count Register */
 #define SDXC_REG_DBGC  (0x50) /* SMC Debug Enable Register */
+#define SDXC_REG_NTSR  (0x5c) /* SMC NewTiming Set Register */
 #define SDXC_REG_HWRST (0x78) /* SMC Card Hardware Reset for Register */
 #define SDXC_REG_DMAC  (0x80) /* SMC IDMAC Control Register */
 #define SDXC_REG_DLBA  (0x84) /* SMC IDMAC Descriptor List Base Addre */
@@ -171,6 +172,9 @@
 #define SDXC_SEND_AUTO_STOPCCSDBIT(9)
 #define SDXC_CEATA_DEV_IRQ_ENABLE  BIT(10)
 
+/* NewTiming Set Register */
+#define SDXC_NEWMODE_ENABLEBIT(31)
+
 /* IDMA controller bus mod bit field */
 #define SDXC_IDMAC_SOFT_RESET  BIT(0)
 #define SDXC_IDMAC_FIX_BURST   BIT(1)
@@ -261,6 +265,9 @@ struct sunxi_mmc_host {
 
/* vqmmc */
boolvqmmc_enabled;
+
+   /* misc */
+   boolnew_timings;/* new timings capable */
 };
 
 static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
@@ -715,8 +722,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
return -EINVAL;
}
 
-   clk_set_phase(host->clk_sample, sclk_dly);
-   clk_set_phase(host->clk_output, oclk_dly);
+   if (host->new_timings && rate >= 5000) {
+   mmc_writel(host, REG_NTSR,
+   mmc_readl(host, REG_NTSR) | SDXC_NEWMODE_ENABLE);
+   } else {
+   clk_set_phase(host->clk_sample, sclk_dly);
+   clk_set_phase(host->clk_output, oclk_dly);
+   }
 
return sunxi_mmc_oclk_onoff(host, 1);
 }
@@ -1133,12 +1145,17 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
if (ret)
goto error_free_dma;
 
+   if (pdev->dev.of_node &&
+   of_property_read_bool(pdev->dev.of_node, "allwinner,new-timings"))
+   host->new_timings = true;
+
ret = mmc_add_host(mmc);
if (ret)
goto error_free_dma;
 
dev_info(>dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
platform_set_drvdata(pdev, mmc);
+
return 0;
 
 error_free_dma:
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

On Fri, 29 Jul 2016 21:36:34 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Thu, Jul 21, 2016 at 11:26:55AM +0200, Jean-Francois Moine wrote:
> > On Thu, 21 Jul 2016 10:56:15 +0200
> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote:
> > 
> > > On Wed, Jul 20, 2016 at 08:16:28PM +0200, Jean-Francois Moine wrote:
> > > > The 'new timing mode' with 8 bits DDR works correctly when the NewTiming
> > > > register is set.
> > > 
> > > What does that mode brings to the table?
> > 
> > From my tests, the eMMC of the Banana Pi M3 (A83T) cannot work when the
> > new mode is not used.
> 
> That's odd. The one in the Pine64 seems to work just fine, and yet
> there's only the new mode on the A64.

I spent 2 weeks on this problem. You may try it by yourself.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

On Fri, 29 Jul 2016 21:17:30 +0200
Maxime Ripard  wrote:

> > > What happens if you actually want to set it to 100MHz?
> > 
> > There is no SDXC_CLK_100M in the mainline driver, and 100MHz is asked
> > only for 8 bits DDR at 50MHz.
> 
> You're missing the point.
> 
> clk_set_rate is supposed to apply a rate as close as possible as
> requested, there's no reason why you would request a rate twice as
> high as need.
> 
> You want to switch the clock from one mode to another, fine, create a
> new function for that. But don't hack an existing one.

I will not change the core clock stuff for this marginal case.
Flagging the clock as 'new mode capable' is enough.
Anyway, setting the 'new mode' bit to the clock divides the rate by
two, so, there is no reason to not use it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH] regulator: axp20x: support AXP813 variant

[Jean-Francois Moine]

The X-Powers AXP813 PMIC is close enough to the AXP809 with some
more outputs.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
 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(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 585a955..2a8ec61 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -7,10 +7,12 @@ axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (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,axp809"
+ "x-powers,axp221", "x-powers,axp223", "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
@@ -110,6 +112,34 @@ LDO_IO1: LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 SW : On/Off Switch : swin-supply
 
+AXP813 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
+DCDC7  : DC-DC buck: vin7-supply
+RTC_LDO: LDO   : ips-supply: always on
+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
+LDO_IO0: LDO   : ips-supply: GPIO 0
+LDO_IO1: LDO   : ips-supply: GPIO 1
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+
 Example:
 
 axp209: pmic@34 {
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a407527..e34643b 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -62,6 +62,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
+   { .compatible = "x-powers,axp813", .data = (void *)AXP813_ID },
{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index fd80b09..e62d56f 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -39,6 +39,7 @@ static const char * const axp20x_model_names[] = {
"AXP223",
"AXP288",
"AXP809",
+   "AXP813",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -494,6 +495,7 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip 
= {
 
 };
 
+/* common 803/809/813 */
 static const struct regmap_irq_chip axp809_regmap_irq_chip = {
.name   = "axp809",
.status_base= AXP20X_IRQ1_STATE,
@@ -733,6 +735,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP809_ID:
+   case AXP813_ID:
axp20x->nr_cells = ARRAY_SIZE(axp809_cells);
axp20x->cells = axp809_cells;

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 3/3] mmc: sunxi: Add support to the Allwinner A83T

[Jean-Francois Moine]

On Thu, 21 Jul 2016 11:18:51 +0200
Jean-Francois Moine <moin...@free.fr> wrote:

> > On Wed, Jul 20, 2016 at 08:28:47PM +0200, Jean-Francois Moine wrote:
> > > The rate of the PLL-PERIPH clock is usually set to 1.2GHz in the A83T.
> > 
> > Uh? The datasheet says to set it to 600MHz.
> 
> Right. But the driver of the SDK for the Banana Pi M3 (A83T) sets it
> to 1.2GHz.

I tested again, and, with the pll-periph at 600MHz, both the SDcard and
the eMMC are working fine.
So, you may forget about this patch, sorry for the noise.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

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

> On Wed, Jul 20, 2016 at 08:16:28PM +0200, Jean-Francois Moine wrote:
> > The 'new timing mode' with 8 bits DDR works correctly when the NewTiming
> > register is set.
> 
> What does that mode brings to the table?

>From my tests, the eMMC of the Banana Pi M3 (A83T) cannot work when the
new mode is not used.

> > 
> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > ---
> > Note about the 'new timing mode'.
> > 
> > This patch assumes that, when the new mode is used, the clock driver
> > sets the mode select in the MMC clock and multiplies the clock rate
> > by 2:
> > - MMC side:
> >   - with a timing 8 bits DDR at 50MHz, the MMC driver calls
> > clk_set_rate() with a rate 50*2 = 100MHz,
> > - clock side:
> >   - the clock driver sets the hardware MMC clock to 100*2 = 200MHz,
> >   - setting the 'mode select' of the hardware MMC clock divides the
> > rate by 2,
> > - MMC side:
> >   - setting the MMC clock divider register to 1 divides the rate by 2.
> > So, the final rate is 50MHz.
> 
> What happens if you actually want to set it to 100MHz?

There is no SDXC_CLK_100M in the mainline driver, and 100MHz is asked
only for 8 bits DDR at 50MHz.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 3/3] mmc: sunxi: Add support to the Allwinner A83T

[Jean-Francois Moine]

On Thu, 21 Jul 2016 10:58:38 +0200
Maxime Ripard <maxime.rip...@free-electrons.com> wrote:

> On Wed, Jul 20, 2016 at 08:28:47PM +0200, Jean-Francois Moine wrote:
> > The rate of the PLL-PERIPH clock is usually set to 1.2GHz in the A83T.
> 
> Uh? The datasheet says to set it to 600MHz.

Right. But the driver of the SDK for the Banana Pi M3 (A83T) sets it
to 1.2GHz.

> > This patch sets the phase delays of the output and sample clocks
> > accordingly.
> > 
> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > ---
> > Note: The impacted phase delays are only for 50MHz.
> > The phase delays are not used in 50MHz 8 bits DDR (new timing mode).
> 
> Actually, they seem to be, in the new timing mode register.

In the SDK driver, nothing is set in the new timing mode register.
Anyway, the eMMC works fine in both the Banana Pis M2+ and M3
with no delay.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

The 'new timing mode' with 8 bits DDR works correctly when the NewTiming
register is set.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
Note about the 'new timing mode'.

This patch assumes that, when the new mode is used, the clock driver
sets the mode select in the MMC clock and multiplies the clock rate
by 2:
- MMC side:
  - with a timing 8 bits DDR at 50MHz, the MMC driver calls
clk_set_rate() with a rate 50*2 = 100MHz,
- clock side:
  - the clock driver sets the hardware MMC clock to 100*2 = 200MHz,
  - setting the 'mode select' of the hardware MMC clock divides the
rate by 2,
- MMC side:
  - setting the MMC clock divider register to 1 divides the rate by 2.
So, the final rate is 50MHz.

For this to work, the clock driver must know when the 'mode select'
is used.
Instead of using a new special clock function, in my driver, the
'mode select' capable clocks are declared as such with an associated
rate (actually, mmc2 in A83T, and mmc{1,2} in H3).
When this rate is asked for (100MHz), the mode select is set.
This works without change in the MMC driver. If a 100MHz rate would be
used without 'mode select' for such clocks, an other mechanism should
be found (information in the low bits of the rate?).
---
 drivers/mmc/host/sunxi-mmc.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index ba647b7..7f9c31a 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -64,6 +64,7 @@
 #define SDXC_REG_CBCR  (0x48) /* SMC CIU Byte Count Register */
 #define SDXC_REG_BBCR  (0x4C) /* SMC BIU Byte Count Register */
 #define SDXC_REG_DBGC  (0x50) /* SMC Debug Enable Register */
+#define SDXC_REG_NTSR  (0x5c) /* SMC NewTiming Set Register */
 #define SDXC_REG_HWRST (0x78) /* SMC Card Hardware Reset for Register */
 #define SDXC_REG_DMAC  (0x80) /* SMC IDMAC Control Register */
 #define SDXC_REG_DLBA  (0x84) /* SMC IDMAC Descriptor List Base Addre */
@@ -171,6 +172,9 @@
 #define SDXC_SEND_AUTO_STOPCCSDBIT(9)
 #define SDXC_CEATA_DEV_IRQ_ENABLE  BIT(10)
 
+/* NewTiming Set Register */
+#define SDXC_NEWMODE_ENABLEBIT(31)
+
 /* IDMA controller bus mod bit field */
 #define SDXC_IDMAC_SOFT_RESET  BIT(0)
 #define SDXC_IDMAC_FIX_BURST   BIT(1)
@@ -661,10 +665,20 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
u32 clock = ios->clock;
int ret;
 
-   /* 8 bit DDR requires a higher module clock */
-   if (ios->timing == MMC_TIMING_MMC_DDR52 &&
-   ios->bus_width == MMC_BUS_WIDTH_8)
-   clock <<= 1;
+   /*
+* 8 bit DDR requires a higher module clock
+* and the 'new mode'
+*/
+   if (ios->bus_width == MMC_BUS_WIDTH_8) {/* eMMC */
+   rval = mmc_readl(host, REG_NTSR);
+   if (ios->timing == MMC_TIMING_MMC_DDR52) {
+   clock <<= 1;
+   rval |= SDXC_NEWMODE_ENABLE;
+   } else {
+   rval &= ~SDXC_NEWMODE_ENABLE;
+   }
+   mmc_writel(host, REG_NTSR, rval);
+   }
 
rate = clk_round_rate(host->clk_mmc, clock);
if (rate < 0) {
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 3/3] mmc: sunxi: Add support to the Allwinner A83T

[Jean-Francois Moine]

The rate of the PLL-PERIPH clock is usually set to 1.2GHz in the A83T.
This patch sets the phase delays of the output and sample clocks
accordingly.

Signed-off-by: Jean-Francois Moine <moin...@free.fr>
---
Note: The impacted phase delays are only for 50MHz.
The phase delays are not used in 50MHz 8 bits DDR (new timing mode).
---
 drivers/mmc/host/sunxi-mmc.c | 11 +++
 1 file changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 7f9c31a..e161a64 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -961,6 +961,7 @@ static int sunxi_mmc_card_busy(struct mmc_host *mmc)
 static const struct of_device_id sunxi_mmc_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-mmc", },
{ .compatible = "allwinner,sun5i-a13-mmc", },
+   { .compatible = "allwinner,sun8i-a83t-mmc", },
{ .compatible = "allwinner,sun9i-a80-mmc", },
{ /* sentinel */ }
 };
@@ -986,6 +987,14 @@ static const struct sunxi_mmc_clk_delay 
sunxi_mmc_clk_delays[] = {
[SDXC_CLK_50M_DDR_8BIT] = { .output =  90, .sample = 180 },
 };
 
+static const struct sunxi_mmc_clk_delay sun8i_a83t_mmc_clk_delays[] = {
+   [SDXC_CLK_400K] = { .output = 180, .sample = 180 },
+   [SDXC_CLK_25M]  = { .output = 180, .sample =  75 },
+   [SDXC_CLK_50M]  = { .output =  90, .sample = 105 },
+   [SDXC_CLK_50M_DDR]  = { .output =  60, .sample = 120 },
+   [SDXC_CLK_50M_DDR_8BIT] = { .output =  180, .sample = 180 },
+};
+
 static const struct sunxi_mmc_clk_delay sun9i_mmc_clk_delays[] = {
[SDXC_CLK_400K] = { .output = 180, .sample = 180 },
[SDXC_CLK_25M]  = { .output = 180, .sample =  75 },
@@ -1007,6 +1016,8 @@ static int sunxi_mmc_resource_request(struct 
sunxi_mmc_host *host,
 
if (of_device_is_compatible(np, "allwinner,sun9i-a80-mmc"))
host->clk_delays = sun9i_mmc_clk_delays;
+   else if (of_device_is_compatible(np, "allwinner,sun8i-a83t-mmc"))
+   host->clk_delays = sun8i_a83t_mmc_clk_delays;
else
host->clk_delays = sunxi_mmc_clk_delays;
 
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 1/3] clk: sunxi: Add a driver for the CCU

[Jean-Francois Moine]

On Thu, 30 Jun 2016 23:16:35 +0200
Maxime Ripard  wrote:

> > > I'm sorry, but the whole point of the initial serie was to rework and
> > > simplify things, precisely because dealing with the clk_factors code
> > > was just too difficult nowadays. And this doesn't solve anything on
> > > that aspect.
> > 
> > In my code, all the clock factors I know about are handled.
> > Basically, the requested and the parent rates give a multiplier and a
> > divider. These ones are dispatched into the specific clock factors
> > according to their constraints.
> 
> You missed the "simplify" part. The other reason for this serie to
> exist was to be consistent with what the other architectures are
> doing, which is not the case here either.

The other architectures have not a so complex mechanism as Allwinner's.
The 'divider'/'fractional-divider'/multiplier'/... "standard" functions
cannot be used in ou case. Your 'sunxi-ng' just add new structures to
replace them, and, in fact, you are building an other restricted
composite clock system. which will be unusable when new SoCs will
appear.

Yes, I should not have include the reset/bus gate/factor computation
stuff in my patch series. Because the only important part is to have a
flat definition of all the parameters giving this more simplification:
one structure and one source file.

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.