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

[Laurent Pinchart]

On Thursday 01 Dec 2016 12:30:09 Jean-Francois Moine wrote:
> 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.

That's not correct. The connector type reported by DRM to userspace can be 
used as a hint to information the user about connectors. Displaying a "Please 
connect a monitor to the HDMI connector" is confusing when the system has a 
DVI connector.

> 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).

-- 
Regards,

Laurent Pinchart

-- 
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 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: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[Laurent Pinchart]

On Thursday 01 Dec 2016 09:55:20 Maxime Ripard wrote:
> On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote:
> >>>  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?
> > 
> > I suddenly thought about something...
> > 
> > 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).

> > How about solder a HDMI-to-VGA bridge on the board? (Maybe there
> > should be "dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge"
> > drivers?)
> 
> It probably wouldn't be dumb, but yeah, it would definitely be a
> bridge instead of the connector.

-- 
Regards,

Laurent Pinchart

-- 
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

[Maxime Ripard]

On Thu, Dec 01, 2016 at 11:19:56AM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> > On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> > >> More, it is not sure that the bridge/DW code would work with Allwinner's
> > >> SoCs.
> > > 
> > > If it doesn't work and can't be made to work in a non-invasive way they it
> > > should certainly not be used :-)
> > 
> > Even if the register layout is completely scrambled, as long as the
> > bits themselves aren't (and by comparing the two drivers it looks like
> > they haven't changed), you can easily deal with that using the
> > regmap_fields, with the two implementations (the original one and the
> > scrambled one) providing their register map that way, and the driver
> > code using whatever has been provided.
> 
> Looking at https://linux-sunxi.org/DWC_HDMI_Controller#DWC_HDMI_Controller it 
> seems that an address remapping function could be used.

Even better.

Maxime

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

-- 
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.


signature.asc
Description: PGP signature

[linux-sunxi] How should we group related devices in DT ? (was Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support)

[Laurent Pinchart]

Hello,

On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:

[snip]

> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However, those were sharing some encoders (HDMI,
> DSI) after that.
> 
> So we need to have a single DRM device taking care of the multiple
> display engines, which essentialy means that we have to decouple the
> DRM device from the display engine. This was done in the earlier
> designs using an additional node with a list of phandles to the
> display engines in the system, and obviously, I'd prefer to have some
> consistency and reuse the same thing.

I believe this problem isn't limited to sunxi and should be addressed in a 
more generic way. How should we describe in the device tree that multiple 
instances of a device unrelated from a control point of view are related at 
the hardware level ? There are multiple reasons why we need this, and here are 
a few.

- As described above, unrelated display controller instances that share 
encoders at their output need to be exposed to userspace as a single DRM 
device. This is also the case on Renesas platforms (where the display engines 
are independent except for the "small" detail that output routing is 
controlled through the first display engine).

- On Renesas platforms again a radio-related SPI receiver has multiple 
independent channels that each have their own registers, clocks and 
interrupts, but share the same physical clock and sync pins. They are used to 
receive multiple channels of the same data stream and must be exposed as a 
single V4L2 device to userspace. A generic DT binding RFC is available at 
http://www.spinics.net/lists/devicetree/msg152414.html.

> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.

-- 
Regards,

Laurent Pinchart

-- 
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

[Laurent Pinchart]

Hi Maxime,

On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> >> More, it is not sure that the bridge/DW code would work with Allwinner's
> >> SoCs.
> > 
> > If it doesn't work and can't be made to work in a non-invasive way they it
> > should certainly not be used :-)
> 
> Even if the register layout is completely scrambled, as long as the
> bits themselves aren't (and by comparing the two drivers it looks like
> they haven't changed), you can easily deal with that using the
> regmap_fields, with the two implementations (the original one and the
> scrambled one) providing their register map that way, and the driver
> code using whatever has been provided.

Looking at https://linux-sunxi.org/DWC_HDMI_Controller#DWC_HDMI_Controller it 
seems that an address remapping function could be used.

> >> Eventually, I went the same way as omap/hdmi5: different driver.
> > 
> > I might try to fix that for OMAP5 at some point, we'll see.
> 
> For complex drivers that have already a driver written and a lot of
> testing that already happened, I don't think duplication is a smart
> move.
> 
> >>>   - 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...
> > 
> > And you're certainly welcome to contribute drivers to the kernel, that's
> > always appreciated. Of course, to ensure a reasonable level of quality and
> > consistency between drivers, the review process often requires changes to
> > be made to the code being submitted. When it comes to drivers I mostly
> > pay attention to DT bindings, userspace APIs and modification to common
> > code. Driver code itself, as long as it's reasonably clean and doesn't
> > impede development of other drivers or impact system security in an
> > adverse way, is still important but maybe slightly less so. I'll defer to
> > Maxime to come to an agreement on the multiple display engines in
> > parallel problem as I'm not familiar with it for the Allwinner platforms.
> 
> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However, those were sharing some encoders (HDMI,
> DSI) after that.
> 
> So we need to have a single DRM device taking care of the multiple
> display engines, which essentialy means that we have to decouple the
> DRM device from the display engine. This was done in the earlier
> designs using an additional node with a list of phandles to the
> display engines in the system, and obviously, I'd prefer to have some
> consistency and reuse the same thing.
> 
> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.

-- 
Regards,

Laurent Pinchart

-- 
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

[Maxime Ripard]

Hi Laurent,

On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> > More, it is not sure that the bridge/DW code would work with Allwinner's
> > SoCs.
> 
> If it doesn't work and can't be made to work in a non-invasive way they it 
> should certainly not be used :-)

Even if the register layout is completely scrambled, as long as the
bits themselves aren't (and by comparing the two drivers it looks like
they haven't changed), you can easily deal with that using the
regmap_fields, with the two implementations (the original one and the
scrambled one) providing their register map that way, and the driver
code using whatever has been provided.

> > Eventually, I went the same way as omap/hdmi5: different driver.
> 
> I might try to fix that for OMAP5 at some point, we'll see.

For complex drivers that have already a driver written and a lot of
testing that already happened, I don't think duplication is a smart
move.

> > >   - 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...
> 
> And you're certainly welcome to contribute drivers to the kernel, that's 
> always appreciated. Of course, to ensure a reasonable level of quality and 
> consistency between drivers, the review process often requires changes to be 
> made to the code being submitted. When it comes to drivers I mostly pay 
> attention to DT bindings, userspace APIs and modification to common code. 
> Driver code itself, as long as it's reasonably clean and doesn't impede 
> development of other drivers or impact system security in an adverse way, is 
> still important but maybe slightly less so. I'll defer to Maxime to come to 
> an 
> agreement on the multiple display engines in parallel problem as I'm not 
> familiar with it for the Allwinner platforms.

The earlier Allwinner SoCs (with the old display engine), we had some
SoCs with multiple instances of the display engine and TCON (the
display engine roughly implementing the planes, the TCON the
CRTC. Roughly.). However, those were sharing some encoders (HDMI,
DSI) after that.

So we need to have a single DRM device taking care of the multiple
display engines, which essentialy means that we have to decouple the
DRM device from the display engine. This was done in the earlier
designs using an additional node with a list of phandles to the
display engines in the system, and obviously, I'd prefer to have some
consistency and reuse the same thing.

But the current approach doesn't work and will require some DT
modifications if that case happens again, which we can't do because of
the DT ABI.

Maxime

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

-- 
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.


signature.asc
Description: PGP signature

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

[Maxime Ripard]

On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote:
> >>  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?
> 
> I suddenly thought about something...
> 
> If a DVI connector instead of a HDMI connector is soldered, how
> should such a device tree be written?

Use a dvi-connector instead :)

> How about solder a HDMI-to-VGA bridge on the board? (Maybe there
> should be "dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge"
> drivers?)

It probably wouldn't be dumb, but yeah, it would definitely be a
bridge instead of the connector.

Maxime

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

-- 
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.


signature.asc
Description: PGP signature

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

[Maxime Ripard]

On Thu, Dec 01, 2016 at 10:02:59AM +0800, Icenowy Zheng wrote:
> 
> 
> 01.12.2016, 04:52, "Maxime Ripard" :
> > On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej Škrabec wrote:
> >>  > > > > 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.
> >>  >
> >>
> >>  True, H3 user manual can be misleading sometimes. But this doesn't change 
> >> the
> >>  fact that TCON0 has same register offsets with same meaning.
> >
> > Then yes, we should definitely share the drivers too. So, in the end,
> > the only thing that is actually new is the display-engine?
> 
> And HDMI PHY on H3 ;-)

Yes, and that one :)

> In my opinion, we should just put sun8i-de2-drm related code into
> drivers/gpu/drm/sun4i/ .  (Or rename the directory to sunxi)

We should definitely reuse the drivers that are already in there for
the TCON and HDMI parts.

I'd have to look at the exact amount of code that would be needed to
support the new display engine, but I guess if it's big, then a
separate folder makes sense, if it isn't, then putting it in sun4i
makes sense (but I'm reluctant to renaming it to sunxi).

Maxime

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

-- 
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.


signature.asc
Description: PGP signature