Re: [PATCH v12 2/9] drm/ingenic: Add support for JZ4780 and HDMI output

2022-02-02 Thread Paul Boddie 
On Wednesday, 2 February 2022 13:41:21 CET Paul Cercueil wrote:
> Le mer., févr. 2 2022 at 13:33:15 +0100, H. Nikolaus Schaller> 
 a écrit :
> >>  Am 02.02.2022 um 13:28 schrieb Paul Cercueil :
> >>  
> >>  Note that there are other things not working with your current
> >> 
> >> implementation, for instance you cannot set the X/Y start position
> >> of the f1 plane, which means it's only really usable for fullscreen
> >> desktop/windows.
> > 
> > Is setting x/y possible for the other SoC?
> 
> Yes. They support different x/y positions, sizes, and pixel format for
> both f0, f1 and IPU planes.

One thing worth noting about the JZ4780 is that a lot of the registers that 
might otherwise be used for the above purposes appear to be read-only, at 
least for the different fields concerned.

For example, those affecting ingenic_drm_plane_config:

Control Register (LCDCTRL) - specifically the BPP0 field
OSD Control Register (LCDOSDCTRL)
Foreground 0 XY Position Register (LCDXYP0)
Foreground 1 XY Position Register (LCDXYP1)
Foreground 0 Size Register (LCDSIZE0)
Foreground 1 Size Register (LCDSIZE1)

These require changes to the extended descriptor members instead, and I am 
fairly sure I mentioned the implications for pixel depth configuration 
previously. So, as far as I can tell, we would need to update the descriptors, 
not the registers, to support the operations mentioned above.

As for the f0 plane "not working", I am not aware of any limitation around 
using only f0 (assuming it corresponds to what the manual calls fg0) or only 
f1 (again, assuming fg1 in the manual) or both. My assumption was that for 
this particular driver, f0 was reserved for some kind of overlay and that f1 
was to be used for the normal non-overlay display for products where the OSD 
peripheral is provided.

From the definition of struct ingenic_drm:

/*
 * f1 (aka. foreground1) is our primary plane, on top of which
 * f0 (aka. foreground0) can be overlayed. Z-order is fixed in
 * hardware and cannot be changed.
 */

So, as I understood it, the driver would configure f1 in the case of the 
JZ4780 for basic display support. Configuring f0 as an overlay should be 
entirely possible, but I imagine that it needs to change the descriptors, not 
the registers, to have a chance of actually working.

I hope this is somewhat useful information. I honestly don't know if, say, the 
JZ4770 has a similar arrangement with regard to configuration via descriptors, 
as opposed to registers, but I think it is an important distinction between 
devices in this particular family that needs to be accommodated in the driver, 
and we obviously want to determine how this might best be achieved.

Paul

Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output

2022-01-19 Thread Paul Boddie 
On Wednesday, 19 January 2022 07:40:22 CET H. Nikolaus Schaller wrote:
> Hi Paul,
> 
> > Am 18.01.2022 um 23:59 schrieb Paul Boddie :
> > 
> > On Tuesday, 18 January 2022 17:58:58 CET Paul Cercueil wrote:
> >>
> >> Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working
> >> fine last time I tried, and now I indeed get a black screen unless this
> >> bit is set. The PM doesn't make it obvious that the bit is required,
> >> but that wouldn't be surprising.
> > 
> > It isn't actually needed. If the DMA descriptors are set up appropriately,
> > the OSD alpha bit seems to be set as a consequence. In my non-Linux
> > testing environment I don't even set any OSD registers explicitly, but
> > the OSD alpha and enable flags become set when the display is active.
> 
> Is it set by DMA descriptors or by explicit code?

The descriptors will cause it to be set when the peripheral is enabled, as far 
as I can tell.

> We did have an explicit setting of JZ_LCD_OSDC_ALPHAEN
> 
> https://www.spinics.net/lists/devicetree/msg438447.html
> 
> but that was postponed for further discussion. And now if we
> add it (from basic functionality) back, it is fine again.

It may be set in various versions of the Linux driver, but my observation was 
that in a non-Linux environment where nothing else is setting anything in the 
register concerned, initialising the descriptors seems to enable OSD and the 
OSD alpha enable bit.

Yesterday, I did consider what might be done to avoid the alpha bit being set, 
but I didn't immediately see anything in the descriptor fields that would 
offer such an alternative. The bit in question seems to be a global alpha 
enable setting, and so choosing per-pixel alpha would probably also result in 
it being set, although I didn't fire up the CI20 to check.

Paul

Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output

2022-01-18 Thread Paul Boddie 
On Tuesday, 18 January 2022 17:58:58 CET Paul Cercueil wrote:
> 
> Not at all. If the clock is disabled, the LCD controller is disabled,
> so all the registers read zero, this makes sense. You can only read the
> registers when the clock is enabled. On some SoCs, reading disabled
> registers can even cause a complete lockup.

My concern was that something might be accessing the registers before the 
clock had been enabled. It seems unlikely, given that the clock is enabled in 
the bind function, and I would have thought that nothing would invoke the 
different driver operations ("funcs") until bind has been called, nor should 
anything called from within bind itself be accessing registers.

> Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working
> fine last time I tried, and now I indeed get a black screen unless this
> bit is set. The PM doesn't make it obvious that the bit is required,
> but that wouldn't be surprising.

It isn't actually needed. If the DMA descriptors are set up appropriately, the 
OSD alpha bit seems to be set as a consequence. In my non-Linux testing 
environment I don't even set any OSD registers explicitly, but the OSD alpha 
and enable flags become set when the display is active.

Paul

Re: [PATCH v5 5/7] MIPS: DTS: jz4780: Account for Synopsys HDMI driver and LCD controllers

2021-10-05 Thread Paul Boddie 
On Tuesday, 5 October 2021 22:50:12 CEST Paul Cercueil wrote:
> Hi Nikolaus & Paul,
> 
> Le mar., oct. 5 2021 at 14:29:17 +0200, H. Nikolaus Schaller 
 a écrit :
> > 
> > diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> > b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> > index 9e34f433b9b5..c3c18a59c377 100644
> > --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> > +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> > @@ -424,6 +424,51 @@ i2c4: i2c@10054000 {
> > 
> > status = "disabled";
> > 
> > };
> > 
> > +   hdmi: hdmi@1018 {
> > +   compatible = "ingenic,jz4780-dw-hdmi";
> > +   reg = <0x1018 0x8000>;
> > +   reg-io-width = <4>;
> > +
> > +   clocks = < JZ4780_CLK_AHB0>, < JZ4780_CLK_HDMI>;
> > +   clock-names = "iahb", "isfr";
> > +
> > +   assigned-clocks = < JZ4780_CLK_HDMI>;
> > +   assigned-clock-rates = <2700>;
> 
> Any reason why this is set to 27 MHz? Is it even required? Because with
> the current ci20.dts, it won't be clocked at anything but 48 MHz.

EXCLK will be 48MHz, but the aim is to set the HDMI peripheral clock to 27MHz, 
which is supposedly required. I vaguely recall a conversation about whether we 
were doing this right, but I don't recall any conclusion.

> > +
> > +   interrupt-parent = <>;
> > +   interrupts = <3>;
> > +
> > +   /* ddc-i2c-bus = <>; */
> > +
> > +   status = "disabled";
> > +   };
> > +
> > +   lcdc0: lcdc0@1305 {
> > +   compatible = "ingenic,jz4780-lcd";
> > +   reg = <0x1305 0x1800>;
> > +
> > +   clocks = < JZ4780_CLK_TVE>, < JZ4780_CLK_LCD0PIXCLK>;
> > +   clock-names = "lcd", "lcd_pclk";
> > +
> > +   interrupt-parent = <>;
> > +   interrupts = <31>;
> > +
> > +   status = "disabled";
> 
> I think you can keep lcdc0 enabled by default (not lcdc1 though), since
> it is highly likely that you'd want that.

As far as I know, the clock gating for the LCD controllers acts like a series 
circuit, meaning that they both need to be enabled. Some testing seemed to 
confirm this. Indeed, I seem to remember only enabling one clock and not 
getting any output until I figured this weird arrangement out.

Paul

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

2021-09-25 Thread Paul Boddie 
On Friday, 24 September 2021 10:29:02 CEST Paul Cercueil wrote:
> 
> Le ven., sept. 24 2021 at 00:51:39 +0200, Paul Boddie
> >
> > 2. My approach, which just involves changing the Synopsys driver to
> > set the bridge type in dw_hdmi_probe like this:
> >
> >   hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > 
> > Otherwise, I don't see how the bridge's (struct drm_bridge) type will
> > be set.
> 
> The bridge's type is set in hdmi-connector, from DTS. The 'type = "a"'
> will result in the bridge's .type to be set to DRM_MODE_CONNECTOR_HDMIA.

Actually, I found that hdmi-connector might not have been available because 
CONFIG_DRM_DISPLAY_CONNECTOR was not enabled. Rectifying this, the connector 
does get detected and enabled. However, the Synopsys driver remains unaware of 
it, and so the bridge type in the Synopsys driver remains unset.

I do see that the connector sets the type on a bridge in its own private 
structure, so there would be a need to propagate this type to the actual 
bridge. In other words, what the connector does is distinct from the Synopsys 
driver which acts as the bridge with regard to the Ingenic driver.

Perhaps the Synopsys driver should set the connector's bridge as the next 
bridge, or maybe something is supposed to discover that the connector may act 
as (or provide) a bridge after the Synopsys driver in the chain and then back-
propagate the bridge type along the chain.

[...]

> > And I removed any of the above hacks. What I observe, apart from an
> > inactive LCD controller (and ingenic-drm driver), is the following in
> > /sys/devices/platform/1018.hdmi/:
> > 
> > consumer:platform:1305.lcdc0
> > consumer:platform:hdmi_connector

Interestingly, with the connector driver present, these sysfs entries no 
longer appear.

[...]

> > For me, running modetest yields plenty of information about encoders,
> > connectors (and the supported modes via the EDID, thanks to my HDMI-A
> > hack), CRTCs, and planes. But no framebuffers are reported.
> 
> Could you paste the result of "modetest -a -c -p" somewhere maybe?

I had to specify -M ingenic-drm as well, but here you go...



Connectors:
id  encoder status  namesize (mm)   modes   encoders
35  34  connected   HDMI-A-1340x270 17  34
  modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  #0 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: 
phsync, pvsync; type: preferred, driver
  #1 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: 
phsync, pvsync; type: driver
  #2 1280x960 60.00 1280 1376 1488 1800 960 961 964 1000 108000 flags: phsync, 
pvsync; type: driver
  #3 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, 
pvsync; type: driver
  #4 1024x768 75.03 1024 1040 1136 1312 768 769 772 800 78750 flags: phsync, 
pvsync; type: driver
  #5 1024x768 70.07 1024 1048 1184 1328 768 771 777 806 75000 flags: nhsync, 
nvsync; type: driver
  #6 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, 
nvsync; type: driver
  #7 832x624 74.55 832 864 928 1152 624 625 628 667 57284 flags: nhsync, 
nvsync; type: driver
  #8 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync, 
pvsync; type: driver
  #9 800x600 72.19 800 856 976 1040 600 637 643 666 5 flags: phsync, 
pvsync; type: driver
  #10 800x600 60.32 800 840 968 1056 600 601 605 628 4 flags: phsync, 
pvsync; type: driver
  #11 800x600 56.25 800 824 896 1024 600 601 603 625 36000 flags: phsync, 
pvsync; type: driver
  #12 640x480 75.00 640 656 720 840 480 481 484 500 31500 flags: nhsync, 
nvsync; type: driver
  #13 640x480 72.81 640 664 704 832 480 489 492 520 31500 flags: nhsync, 
nvsync; type: driver
  #14 640x480 66.67 640 704 768 864 480 483 486 525 30240 flags: nhsync, 
nvsync; type: driver
  #15 640x480 59.94 640 656 752 800 480 490 492 525 25175 flags: nhsync, 
nvsync; type: driver
  #16 720x400 70.08 720 738 846 900 400 412 414 449 28320 flags: nhsync, 
pvsync; type: driver
  props:
1 EDID:
flags: immutable blob
blobs:

value:
0000047232ad01010101
2d0e010380221b782aaea5a6544c9926
145054bfef0081808140714f01010101
010101010101302a009851002a403070
1300520e111e00ff00343435
303035354330300a00fc0041
4c313731350a20202020202000fd
00384c1e520e000a2020202020200051
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
5 link-status:
flags: enum
enums: Good=0 Bad=1

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

2021-09-23 Thread Paul Boddie 
On Thursday, 23 September 2021 22:23:28 CEST H. Nikolaus Schaller wrote:
> 
> > Am 23.09.2021 um 21:39 schrieb Paul Cercueil :
> > 
> > Start by wiring things properly, like in my previously linked DTS, and
> > *test*. If it fails, tell us where it fails.
>
> Well, I tell where drm_bridge_attach fails with
> DRM_BRIDGE_ATTACH_NO_CONNECTOR...

I tried to piece together this entire discussion from the mailing list 
archives, but there appear to be two approaches that "work", in that they 
activate the LCD controller with the HDMI peripheral:

1. Nikolaus's approach, which involves getting the Synopsys driver to create a 
connector and then avoiding the call to drm_bridge_connector_init in the 
Ingenic DRM driver.

2. My approach, which just involves changing the Synopsys driver to set the 
bridge type in dw_hdmi_probe like this:

  hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;

Otherwise, I don't see how the bridge's (struct drm_bridge) type will be set. 
And this causes drm_bridge_connector_init to fail because it tests the bridge 
type.

Now, I just reintroduced the HDMI connector to the device tree as follows:

hdmi_connector {
compatible = "hdmi-connector";
label = "hdmi";

type = "a";

port {
hdmi_connector_in: endpoint {
remote-endpoint = <_hdmi_out>;
};
};
};

And then I added a second port to the HDMI peripheral node as follows:

port@1 {
reg = <1>;
dw_hdmi_out: endpoint {
remote-endpoint = <_connector_in>;
};
};

And I removed any of the above hacks. What I observe, apart from an inactive 
LCD controller (and ingenic-drm driver), is the following in /sys/devices/
platform/1018.hdmi/:

consumer:platform:1305.lcdc0
consumer:platform:hdmi_connector

Maybe I don't understand the significance of "consumer" here, but the LCD 
controller and the HDMI connector obviously have rather different roles. Then 
again, the device tree is defining bidirectional relationships, so maybe this 
is how they manifest themselves.

> > Because your "it doesn't work" arguments have zero weight otherwise.
> 
> I hope I still can find it. So I can't promise anything.
> We have had it complete in DTS and added code to parse it.
> It may have been wiped out by cleaning up patch series during rebase.

I suppose the question is whether this is actually handled already. I would 
have thought that either the DRM framework would be able to identify such 
relationships in a generic way or that the Synopsys driver would need to do 
so. This might actually be happening, given that the sysfs entries are there, 
but I might also imagine that something extra would be required to set the 
bridge type.

I did start writing some code to look up a remote endpoint for the second 
port, find the connector type, and then set it, but it was probably after 
midnight on that occasion as well. Short-circuiting this little dance and 
setting the bridge type indicated that this might ultimately be the right 
approach, but it would probably also mean introducing a point of 
specialisation to the Synopsys driver so that device-specific drivers can 
define a function to set the connector type.

Otherwise, I can't see the Synopsys driver working for devices like the 
JZ4780, but then again, it seems that all the other devices seem to 
incorporate the Synopsys functionality in a different way and do not need to 
deal with connectors at all.

> > If I can find some time this weekend I will test it myself.
> 
> You may be faster than me.

So, when I wrote about approaches that "work", I can seemingly get the LCD 
controller and HDMI peripheral registers set up to match a non-Linux 
environment where I can demonstrate a functioning display, and yet I don't get 
a valid signal in the Linux environment.

Nikolaus can actually get HDMI output, but there may be other factors 
introduced by the Linux environment that frustrate success for me, whereas my 
non-Linux environment is much simpler and can reliably reproduce a successful 
result.

For me, running modetest yields plenty of information about encoders, 
connectors (and the supported modes via the EDID, thanks to my HDMI-A hack), 
CRTCs, and planes. But no framebuffers are reported.

Paul

Re: [Letux-kernel] [PATCH 8/8] drm/ingenic: Attach bridge chain to encoders

2021-08-10 Thread Paul Boddie 
On Tuesday, 10 August 2021 09:52:36 CEST Paul Cercueil wrote:
> 
> Le mar., août 10 2021 at 01:17:20 +0200, Paul Boddie  a 
écrit :
> > 
> > But then the reported error occurs in the DRM driver:
> > 
> > ingenic-drm 1305.lcdc0: Unable to init connector
> > ingenic-drm: probe of 1305.lcdc0 failed with error -22
> > 
> > This originates in a call to drm_bridge_connector_init from
> > ingenic_drm_bind:
> > 
> > connector = drm_bridge_connector_init(drm, encoder);
> > 
> > The invoked function iterates over the registered bridges, one of
> > which seems to be the HDMI peripheral (it has bridge operations defined
> > identically to those specified in the Synopsys driver), but the type
> > member of the drm_bridge structure is set to 0
> > (DRM_MODE_CONNECTOR_Unknown).

Although I had fancy ideas about finding the connector node in the device tree 
and populating the necessary type details on the bridge, I decided to just add 
the following to the Synopsys driver's dw_hdmi_probe function:

hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;

This then lets the above invocation succeed and the Ingenic DRM driver 
initialises. However, I get "Input Not Supported" on my display.

Conveniently, when indicating the necessary boot arguments...

env set bootargs ... drm.debug=0x3f

...as suggested to me on a previous occasion, the /sys/kernel/debug/dri/0/
state file indicates the following:

plane[31]: plane-0
crtc=crtc-0
fb=36   
allocated by = Xorg
refcount=2
format=XR24 little-endian (0x34325258)
modifier=0x0
size=1280x1024
layers: 
size[0]=1280x1024
pitch[0]=5120
offset[0]=0
obj[0]: 
name=0
refcount=3
start=0001
size=5242880
imported=no
paddr=0x00c0
vaddr=3eb0c080
crtc-pos=1280x1024+0+0
src-pos=1280.00x1024.00+0.00+0.00
rotation=1
normalized-zpos=0
color-encoding=ITU-R BT.601 YCbCr
color-range=YCbCr limited range
plane[33]: plane-1
crtc=(null)
fb=0
crtc-pos=0x0+0+0
src-pos=0.00x0.00+0.00+0.00
rotation=1
normalized-zpos=0
color-encoding=ITU-R BT.601 YCbCr
color-range=YCbCr limited range
crtc[32]: crtc-0
enable=1
active=1
self_refresh_active=0
planes_changed=0
mode_changed=0
active_changed=0
connectors_changed=0
color_mgmt_changed=0
plane_mask=1
connector_mask=1
encoder_mask=1
mode: "": 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x0 0x5
connector[35]: HDMI-A-1
crtc=crtc-0
self_refresh_aware=0

I suspect that we may be dealing with an incompatible bus format again, but I 
may be quite wrong about that, too.

Here is the result of running modetest using...

sudo ./modetest -D /dev/dri/card0 -M ingenic-drm

Encoders:
id  crtctypepossible crtcs  possible clones
34  32  DPI 0x0001  0x0001

Connectors:
id  encoder status  namesize (mm)   modes   
encoders
35  34  connected   HDMI-A-1340x270 17  34
  modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  #0 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: 
phsync, pvsync; type: preferred, driver
  #1 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: 
phsync, pvsync; type: driver
  #2 1280x960 60.00 1280 1376 1488 1800 960 961 964 1000 108000 flags: phsync, 
pvsync; type: driver
  #3 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, 
pvsync; type: driver
  #4 1024x768 75.03 1024 1040 1136 1312 768 769 772 800 78750 flags: phsync, 
pvsync; type: driver
  #5 1024x768 70.07 1024 1048 1184 1328 768 771 777 806 75000 flags: nhsync, 
nvsync; type: driver
  #6 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, 
nvsync; type: driver
  #7 832x624 74.55 832 864 928 1152 624 625 628 667 57284 flags: nhsync, 
nvsync; type: driver
  #8 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync, 
pvsync; type: driver
  #9 800x600 72.19 800 856 976 1040 600 637 643 666 5 flags: phsync, 
pvsync; type: driver
  #10 800x600 60.32 800 840 968 1056 600 601 605 628 4 flags: phsync, 
pvsync; type: driver
  #11 800x600 56.25 800 824 896 1024 600 601 603 625 36000 flags: phsync, 
pvsync; type: driver
  #12 640x480 75.00 640 656 720 840 480 481 484 500 31500 flags:

Re: [Letux-kernel] [PATCH 8/8] drm/ingenic: Attach bridge chain to encoders

2021-08-10 Thread Paul Boddie 
On Monday, 9 August 2021 18:22:12 CEST Paul Cercueil wrote:
> 
> Le lun., août 9 2021 at 13:14:03 +0200, H. Nikolaus Schaller 
 a écrit :
> >
> > quick feedback: our HDMI on top compiles fine after fixing 2 merge
> > conflicts, but dos not yet work.
> > Will need some spare time with access to the CI20 board to research
> > the issue, i.e. can not give feedback immediately.
> 
> Alright, no problem. I'll be back home in about 2 weeks and then I can
> test on my CI20 as well.

Just for reference, I looked into this initialisation failure. The HDMI 
peripheral driver gets initialised satisfactorily...

dw-hdmi-ingenic 1018.hdmi: Detected HDMI TX controller v1.31a with HDCP 
(DWC HDMI 3D TX PHY)
dw-hdmi-ingenic 1018.hdmi: registered DesignWare HDMI I2C bus driver

But then the reported error occurs in the DRM driver:

ingenic-drm 1305.lcdc0: Unable to init connector
ingenic-drm: probe of 1305.lcdc0 failed with error -22

This originates in a call to drm_bridge_connector_init from ingenic_drm_bind:

connector = drm_bridge_connector_init(drm, encoder);

The invoked function iterates over the registered bridges, one of which seems 
to be the HDMI peripheral (it has bridge operations defined identically to 
those specified in the Synopsys driver), but the type member of the drm_bridge 
structure is set to 0 (DRM_MODE_CONNECTOR_Unknown).

I might expect the bridge to expose a type acquired from its connector, but I 
don't see this propagation occurring in the Synopsys driver: dw_hdmi_probe 
sets the bridge operations and other members of the drm_bridge structure, but 
it doesn't set the type.

Also, it might be possible that dw_hdmi_connector_detect (exposed as the 
detect operation) is not getting called, and this would explain why the 
bridge's connector member does not have the connector_type set, either (since 
it is also set to 0).

Paul

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-08-22 Thread Paul Boddie 
On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> On Thu, 20 Aug 2020 at 19:49, Paul Boddie  wrote:
> > 
> > It still doesn't work for me. I still get "Input not supported" from my
> > monitor. It is a DVI monitor connected via a HDMI adapter, but EDID
> > probing
> > works and, as I noted previously, the HDMI/LCDC can be made to work (and
> > obviously did work in the 3.18 kernel).
> 
> This means the dw_hdmi encoder driver is still not good enough
> to support your adapter. I haven't yet compared v3.18 vendor
> with our version, but I'm afraid that the dw_hdmi stack has
> probably changed quite a bit, so a comparison will be difficult.

I would have to look at this again to check, but although I may have referred 
to the 3.18 HDMI driver (drivers/gpu/drm/jz4780/dwc_hdmi.c), I'm fairly sure I 
used the more recent driver (drivers/gpu/drm/bridge/synopsys/dw_hdmi.c) as my 
primary reference when making the hardware work with the L4 Runtime 
Environment. But the actual functionality with regard to setting registers in 
the HDMI peripheral is mostly identical between both forms of the driver.

(This makes sense because few people are likely to have access to the 
proprietary documentation. In fact, few people are likely to have even tried 
to deduce what is doing on. One of the register value tables suggests that one 
of the values would really need to be different, if you consider the patterns 
involved, which means that either the documentation mentions this special case 
or that a mistake has been made that has not yet been exposed through real 
world use.)

> The natural debug path for me would be to checkout v3.18,
> connect your DVI monitor and make a dump of all the
> dw_hdmi registers, then make the same dump for our
> mainline kernel -- making sure we are comparing the same
> mode.

It is possible that something does not get initialised in the same way, and 
Nikolaus and I have been working with register dumps, although I haven't been 
generating them myself within Linux. So it is possible that I am missing some 
misconfiguration in the driver that causes an incompatibility with my monitor.

It should be noted that the initialisation is simpler with the DVI mode, 
thankfully. The "AVI infoframe" stuff (going from memory) is completely 
skipped, as are a range of other things, which made my reimplementation effort 
somewhat quicker. I also didn't bother with the audio functionality, but then 
I don't think DVI has any audio channels, either.

One reason for implementing drivers for L4Re was to determine what is actually 
needed to initialise the hardware correctly, doing so in an environment that 
has been quicker to test than Linux has been (given some very old development 
hardware I have been using until recently). Another reason is that I actually 
want to get the CI20 hardware working with L4Re, which it was originally 
supposed to do, but in fact that effort was never actually finished.

> > I downloaded it from here:
> > 
> > https://gitlab.collabora.com/linux/0day/-/tree/jz4780-drm-hdmi-v5.9-rc1
> > 
> > (I was going to clone the repository late last night, but it was taking a
> > long time and I also didn't want to clone everything yet again.)
> 
> If you want to avoid cloning the same things over and over
> you can use git-clone --reference. And if you want to checkout
> just a single branch, git now has --single-branch.
> 
> For instance, (assuming a torvalds/ local repo):
> 
> git clone -b letux/jz4780-hdmi-v4 --single-branch
> git://git.goldelico.com/letux-kernel.git --reference torvalds/ letux

Thanks for the tip! I guess I will spare everyone my thoughts about git's 
never-ending usability deficit.

[...]

> > It would be nice to reconcile the JZ4780 support with the evolving
> > upstream support, accommodating the extended descriptors and the extra
> > register usage.
> I think that's already done in the patches I've cleaned up.
> The only thing left to check is plane offset and overlay enablement.

There are some things that are done in different places, like various 
registers being set in particular "atomic" methods and not during probing. 
Also, the upstream driver has specific plane descriptors whereas my own 
modifications introduced dual descriptors in a slightly different way. Plus, 
the upstream driver doesn't support extended descriptors, as far as I am 
aware.

So, unless Paul Cercueil is fine with what you have done, I don't think we are 
close to integrating anything. Then again, I am not really a Linux kernel 
developer, so perhaps I won't comment in depth about what the requirements 
might be.

> > P.S. I noticed a few problems with the 5.9-rc1 branches such as powering
> > down not actually removing the power and, in my own branch, networking
> > not w

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-08-21 Thread Paul Boddie 
On Thursday, 20 August 2020 10:19:45 CEST H. Nikolaus Schaller wrote:
> 
> Yes, it works!!!

It still doesn't work for me. I still get "Input not supported" from my 
monitor. It is a DVI monitor connected via a HDMI adapter, but EDID probing 
works and, as I noted previously, the HDMI/LCDC can be made to work (and 
obviously did work in the 3.18 kernel).

I used my usual recipe for kernel compilation:

ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make ci20_defconfig
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make menuconfig
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 uImage
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 modules
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 dtbs
sudo sh -c 'INSTALL_MOD_PATH=nn ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \
make modules_install'
sudo sh -c 'INSTALL_PATH=nn/boot ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \
make dtbs_install'
sudo cp arch/mips/boot/uImage nn/boot/

This was with a snapshot archive made from the following changeset:

b911b4883bfe4f7fa753ac2ff42b25fa6b3055e2

I downloaded it from here:

https://gitlab.collabora.com/linux/0day/-/tree/jz4780-drm-hdmi-v5.9-rc1

(I was going to clone the repository late last night, but it was taking a long 
time and I also didn't want to clone everything yet again.)

> There are some unexpected things related to CONFIG settings on my setup
> (maybe missing modules) but for the first time I can see the boot log on the
> panel.
> > This needs some more investigation, but seems at least a good start.
> 
> Yes it is!
> 
> I can now git diff the code and the CONFIG.
> 
> So it seems we have indeed a breakthrough.
> 
> Thanks to all who did contribute (even behind the scenes in the DRM
> subsystem), Nikolaus

Before trying this new branch, I did try and tidy up the branch I had been 
working on. I didn't notice all the changes and the new ingenic-drm-drv.c 
file, having assumed that not much would have changed in the DRM driver.

Nevertheless, my attempts at integrating the different branches can be found 
in the paulb-jz4780-ci20-hdmi-5.9-rc1 branch, mentioned earlier.

It would be nice to reconcile the JZ4780 support with the evolving upstream 
support, accommodating the extended descriptors and the extra register usage.

Paul

P.S. I noticed a few problems with the 5.9-rc1 branches such as powering down 
not actually removing the power and, in my own branch, networking not working 
reliably (or maybe even at all), with the tedious progress indicator never 
terminating in the boot sequence. So, once again, it is another case of half a 
step forwards and about three steps back.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-08-20 Thread Paul Boddie 
On Wednesday, 19 August 2020 12:21:17 CEST Ezequiel Garcia wrote:
> Hello,
> 
> First of all, I'd like to thank everyone for the great work
> on ingenic-drm. The driver is in very good shape
> and a pleasure to work with.

Thanks must go to Paul Cercueil for keeping up with all the framework 
evolution that goes on and for keeping the driver working.

> Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5",
> from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1,
> and then run weston over HDMI (how often
> weston runs on mips, uh? :)

I'm amazed that it works. I tried repeatedly and never got a picture, even 
though (as I wrote previously), I have extracted the necessary logic and got 
the LCD controller and HDMI peripheral to work in a different environment.

> The edid of my monitor is properly read
> and modetest reports all modes.

This was already something we were very confident about. You cannot really 
rely on the Ingenic I2C support, but the Synopsys peripheral does I2C 
reliably.

> I've only tested the primary plane, for some reason
> the overlay is not working as expected, but it must
> be probably some minor thing.

If planes correspond to aspects of the OSD (on-screen display) support then 
there may be a need to review the configuration. On the JZ4780, the OSD 
support is involved in getting the LCD controller to produce output.

> As for the bus format, I have just added a skip
> for CONNECTOR_HDMIA types in the encoder
> atomic check. And then MEDIA_BUS_FMT_RGB888_1X24
> is hardcoded if there are no bus formats negotiated.

This is the part that baffles me. And I am currently looking at other Ingenic 
devices and trying to figure out how I define their panels and whether the 
driver will be able to deduce a bus format, so advice is also welcome on this 
topic.

> Paul et al, if you guys can rebase your work on v5.9-rc1
> and Cc I will be happy to review and test the patches.

Nikolaus did rebase on the latest release candidate, and I made a branch 
available as the expected paulb-jz4780-ci20-hdmi-5.9-rc1 which can be browsed 
here:

https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/paulb-jz4780-ci20-hdmi-5.9-rc1

I imagine that you made a similar fix to the one I did, but that is probably 
the only thing not already in the branch you reviewed.

> Cheers & thanks again,
> Eze

Thanks for looking at the code, and congratulations on being the first to get 
it working!

Paul

> On Tue, 7 Jul 2020 at 04:27, Paul Boddie  wrote:
> > On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote:
> > > On 06/07/2020 01:57, Paul Boddie wrote:
> > > > It also seems to be appropriate to set the input_bus_format on the
> > > > platform- specific HDMI driver; otherwise, I doubt that appropriate
> > > > bus
> > > > encodings will be chosen in the Synopsys driver.
> > > 
> > > It does but when not provided, it doesn't use it.
> > > 
> > > It's handled in drm_atomic_bridge_chain_select_bus_fmts() :
> > >   if (conn->display_info.num_bus_formats &&
> > >   
> > >   conn->display_info.bus_formats)
> > >   
> > >   out_bus_fmts[0] = conn->display_info.bus_formats[0];
> > >   
> > >   else
> > >   
> > >   out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
> > 
> > OK. I thought I'd seen this somewhere, but I had started to think that
> > input_bus_format would remain initialised (presumably to zero) and this
> > would then cause the Synopsys driver to not change the bus format to the
> > actual default.
> > 
> > [...]
> > 
> > > > Testing against 5.8-rc3 with the above changes seems to have moved the
> > > > needle slightly. Although I still get "Input not supported" from my
> > > > monitor, running modetest now gives a different error:
> > > > 
> > > > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
> > > > 
> > > > ...now yields this:
> > > > 
> > > > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
> > > > failed to set gamma: Invalid argument
> > > 
> > > This is because you don't provide the gamma setup ioctl, it's not a
> > > fatal
> > > error at all. It should be warning since it's optional.
> > > 
> > > Did you check all modes ?
> > 
> > I have checked a few more. Currently, testing them is awkward because it
> > involves switching my monitor to DVI input, getting "Input Not Supported",
> > unplugging the cable, and then the hotplug e

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-07-07 Thread Paul Boddie 
On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote:
> 
> On 06/07/2020 01:57, Paul Boddie wrote:
> > 
> > It also seems to be appropriate to set the input_bus_format on the
> > platform- specific HDMI driver; otherwise, I doubt that appropriate bus
> > encodings will be chosen in the Synopsys driver.
> 
> It does but when not provided, it doesn't use it.
> 
> It's handled in drm_atomic_bridge_chain_select_bus_fmts() :
>   if (conn->display_info.num_bus_formats &&
>   conn->display_info.bus_formats)
>   out_bus_fmts[0] = conn->display_info.bus_formats[0];
>   else
>   out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;

OK. I thought I'd seen this somewhere, but I had started to think that 
input_bus_format would remain initialised (presumably to zero) and this would 
then cause the Synopsys driver to not change the bus format to the actual 
default.

[...]

> > Testing against 5.8-rc3 with the above changes seems to have moved the
> > needle slightly. Although I still get "Input not supported" from my
> > monitor, running modetest now gives a different error:
> > 
> > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
> > 
> > ...now yields this:
> > 
> > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
> > failed to set gamma: Invalid argument
> 
> This is because you don't provide the gamma setup ioctl, it's not a fatal
> error at all. It should be warning since it's optional.
> 
> Did you check all modes ?

I have checked a few more. Currently, testing them is awkward because it 
involves switching my monitor to DVI input, getting "Input Not Supported", 
unplugging the cable, and then the hotplug event has most likely caused a bad 
pointer dereference in ingenic_drm_crtc_atomic_flush and thus a kernel panic.

So, I'll try and fix this panic, which appears to be due to the DRM driver 
accessing a null framebuffer pointer (presumably having been invalidated 
elsewhere upon unplugging), and see if I can't get some more information about 
the state of the peripherals.

Paul


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-07-06 Thread Paul Boddie 
Hello,

On Friday, 15 May 2020 09:43:54 CEST Neil Armstrong wrote:
> 
> On 15/05/2020 00:04, Paul Boddie wrote:
> > 
> > Well, I've done this but I probably need to know what to look for. One
> > thing that appears regardless of this debugging output being enabled is a
> > problem with the vertical blanking functionality:
> > 
> > WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457
> > drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c
> > [CRTC:32:crtc-0] vblank wait timed out
> 
> This means the CRTC didn't start, usually because the Pixel clock didn't go
> through the pipeline to the pixel generator, thus not generating
> vblank/vsync interrupts.
> 
> You may check if there is not muxes to select the clock source/pixel
> destination.

It has obviously been a while since I asked about the DW-HDMI functionality. 
Since then, I have verified the initialisation of the Ingenic JZ4780 LCD 
controller and the Synopsys HDMI peripheral in the L4 Runtime Environment 
(running on the Fiasco.OC microkernel), producing a picture and handling 
display interrupts.

Having brought the necessary changes back to the Ingenic DRM driver, I can 
make the driver activate the LCD controller and produce vertical blank 
interrupts, and these are handled and counted in /proc/interrupts. The 
previous errors about timeouts are now gone.

However, the DRM driver can only be made to start if I set the bus format in 
dw_hdmi_bridge_attach:

  u32 bus_format[] = { MEDIA_BUS_FMT_RGB888_1X24 };
  ...
  drm_display_info_set_bus_formats(>display_info,
   bus_format, ARRAY_SIZE(bus_format));

Without this, the DRM driver will test for a bus format on the connector's 
display_info structure in ingenic_drm_encoder_atomic_check and return EINVAL. 
There have previously been indications that this should not need to be done, 
but I see that other drivers do similar things (for example, ti-tfp410.c).

It also seems to be appropriate to set the input_bus_format on the platform-
specific HDMI driver; otherwise, I doubt that appropriate bus encodings will 
be chosen in the Synopsys driver.

[...]

> > Attempting to set a mode using...
> > 
> > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
> > 
> > ...yields the following:
> > 
> > failed to set mode: Permission denied
> > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
> 
> This is weird, the command line is ok, is it the same for all modes ?

Testing against 5.8-rc3 with the above changes seems to have moved the needle 
slightly. Although I still get "Input not supported" from my monitor, running 
modetest now gives a different error:

modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02

...now yields this:

setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
failed to set gamma: Invalid argument

There also seems to be a card1, but I get the same result with that, and they 
both seem to produce similar output with modetest without the -s option.

Anyway, progress is rather slow trying to figure out the obstruction here, so 
any advice would still be appreciated.

Thanks in advance,

Paul


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/12] gpu/drm: Ingenic: Add support for the IPU

2020-05-19 Thread Paul Boddie 
On Monday 18. May 2020 13.26.58 Paul Cercueil wrote:
> >>  
> >>  @@ -186,13 +186,16 @@ static void
> >> 
> >> ingenic_drm_crtc_update_timings(struct ingenic_drm *priv,
> >> 
> >>  regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
> >> JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16,
> >> JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
> >>  
> >>  +
> >>  +   regmap_write(priv->map, JZ_REG_LCD_IPUR, JZ_LCD_IPUR_IPUREN
> >>  +(ht * vpe / 3) << JZ_LCD_IPUR_IPUR_LSB);
> > 
> > This hunk also indicates that it may be better to merge the IPU within
> > the existing driver.
> 
> This writes the IPUR register of the CRTC, nothing wrong here.

Since I noticed it in the above patch details, I think the mask when updating 
the burst setting in the LCD_CTRL register should - in general - involve 
multiple bits, since the BST field is 3 bits wide on the JZ4780 and 2 bits 
wide on earlier products. Just setting BURST_16 (0b10) could potentially 
enable BURST_32 (0b11) or other field values that are not explicitly defined.

Hope this is useful!

Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-05-16 Thread Paul Boddie 
On Friday 15. May 2020 09.43.54 Neil Armstrong wrote:
> 
> On 15/05/2020 00:04, Paul Boddie wrote:
> > 
> > WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457
> > drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c
> > [CRTC:32:crtc-0] vblank wait timed out
> 
> This means the CRTC didn't start, usually because the Pixel clock didn't go
> through the pipeline to the pixel generator, thus not generating
> vblank/vsync interrupts.
> 
> You may check if there is not muxes to select the clock source/pixel
> destination.

I have taken a look at the clocks to see what they get initialised to. Here 
are the details of the LCD controller clocks from this experiment as reported 
by /sys/kernel/debug/clk/clk_summary:

lcd   1104800
   tve1104800
vpll  222   88800
   hdmi   11026909090
   lcd1pixclk 000   88800
   lcd0pixclk 1109866

>From the 3.18 vendor kernel:

lcd   114800
   tve114800
vpll  22   88800
   hdmi   1126909090
   lcd1pixclk 00   88800
   lcd0pixclk 11   11100

(The 3.18 output lacks the "protect count" value.)

Here, the only obvious difference is a slower pixel clock in the experimental 
system: 98.7MHz versus 111MHz.

[...]

> Perfect, EDID reading works fine.

We're fairly confident about this now, at least. ;-) For the record, the 
Synopsys peripheral's own I2C support seems far preferable to Ingenic's own 
I2C peripherals and was a nice discovery amongst the bridge driver's 
capabilities.

[...]

> > Attempting to set a mode using...
> > 
> > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
> > 
> > ...yields the following:
> > 
> > failed to set mode: Permission denied
> > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
> 
> This is weird, the command line is ok, is it the same for all modes ?

Yes. Permission denied for all that I have tried.

[...]

> >>> But if you have "Input not supported" on your monitor, this means you
> >>> have TMDS going out on your hardware, which is good, this means all the
> >>> power/reset/system clocks are ok.
> >>> This could mean you have a timing/clock issue, please check if something
> >>> is not done on the pixel clock before going to the dw-hdmi block.
> 
> Replying to your previous email concerning the bus formats, yeah should
> probably look at the bus format configured, because if you have a DDR bus
> format, the clock will be half and thus won't work.

I can easily imagine that I am missing something with regard to bus formats 
and flags. However, I reviewed differences between drivers and found a few 
more things that are not done in the ingenic-drm driver, mostly because they 
won't be needed by other SoCs or aren't even supported by them. Some of these 
things are not so easy to explain, but maybe they sound familiar to someone.

The 3.18 kernel driver sets up two DMA descriptors, rather than the usual one 
that would be sufficient, and it enables 8-word descriptors that seem to use 
on-screen display functionality in their additional 4 words. The programming 
manual doesn't say anything obvious about this, but it did make me wonder 
whether this extra functionality might need to be enabled in order to activate 
the HDMI output. All it seems to do is to make a foreground layer equivalent 
to the size of the framebuffer.

(With the above noted, the 3.18 kernel doesn't obviously activate the on-
screen display support using the "OSD configure" register, although the vendor 
3.0.8 kernel does, alongside much else.)

There are some registers used that are probably not available on other SoCs in 
the family. An RGB control register sets up RGB output and odd/even line 
formats. A "priority level threshold configure" register seems to be used for 
some kind of bus arbitration. Again, I can imagine that the pipeline to the 
HDMI peripheral may need a specific configuration, but I haven't found an 
explanation yet.

I have tried to introduce these extra measures in a fairly sensible way to the 
ingenic-drm driver, but no further progress has been made so far.

Thanks once again for comments and suggestions!

Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-05-14 Thread Paul Boddie 
Hello,

Following up on my last message...

> On Wednesday 13. May 2020 09.37.49 Neil Armstrong wrote:
> > 
> > Can you run the kernel with drm debug enabled ? drm.debug=0x3f for example
> > you'll have all the modes checks & so on
> 
> I'll try and do this.

Well, I've done this but I probably need to know what to look for. One thing 
that appears regardless of this debugging output being enabled is a problem 
with the vertical blanking functionality:

WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457 
drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c
[CRTC:32:crtc-0] vblank wait timed out

This is preceded by the following:

[drm:drm_atomic_commit] committing 1d53fa19
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:crtc-0] 
flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:HDMI-A-1] 
flip_done timed out
[drm:drm_calc_timestamping_constants] crtc 32: hwmode: htotal 1688, vtotal 
1066, vdisplay 1024
[drm:drm_calc_timestamping_constants] crtc 32: clock 108000 kHz framedur 
16661185 linedur 15629
[drm:drm_update_vblank_count] updating vblank count on crtc 0: current=1, 
diff=0, hw=0 hw_last=0

Although the interrupt initialisation should be straightforward, maybe 
something isn't getting done.

[...]

> > Please use the "modetest" utility from the libdrm source package, it will
> > list all the available mode and permit testing other modes.
> 
> I'll give this a try. The modetest program was suggested by someone else as
> well, so it seems to be the way to go.

Well, I obtained libdrm and built it (after getting a much later version of 
meson than my distribution provides), and running modetest with the options 
indicated to me by another correspondent...

modetest -D /dev/dri/card0 -M ingenic-drm

...I get the following report:

---

Encoders:
id  crtctypepossible crtcs  possible clones
33  32  DPI 0x0001  0x

Connectors:
id  encoder status  namesize (mm)   modes   
encoders
34  33  connected   HDMI-A-1340x270 17  33
  modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  #0 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: 
phsync, pvsync; type: preferred, driver
  #1 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: 
phsync, pvsync; type: driver
  #2 1280x960 60.00 1280 1376 1488 1800 960 961 964 1000 108000 flags: phsync, 
pvsync; type: driver
  #3 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, 
pvsync; type: driver
  #4 1024x768 75.03 1024 1040 1136 1312 768 769 772 800 78750 flags: phsync, 
pvsync; type: driver
  #5 1024x768 70.07 1024 1048 1184 1328 768 771 777 806 75000 flags: nhsync, 
nvsync; type: driver
  #6 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, 
nvsync; type: driver
  #7 832x624 74.55 832 864 928 1152 624 625 628 667 57284 flags: nhsync, 
nvsync; type: driver
  #8 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync, 
pvsync; type: driver
  #9 800x600 72.19 800 856 976 1040 600 637 643 666 5 flags: phsync, 
pvsync; type: driver
  #10 800x600 60.32 800 840 968 1056 600 601 605 628 4 flags: phsync, 
pvsync; type: driver
  #11 800x600 56.25 800 824 896 1024 600 601 603 625 36000 flags: phsync, 
pvsync; type: driver
  #12 640x480 75.00 640 656 720 840 480 481 484 500 31500 flags: nhsync, 
nvsync; type: driver
  #13 640x480 72.81 640 664 704 832 480 489 492 520 31500 flags: nhsync, 
nvsync; type: driver
  #14 640x480 66.67 640 704 768 864 480 483 486 525 30240 flags: nhsync, 
nvsync; type: driver
  #15 640x480 59.94 640 656 752 800 480 490 492 525 25175 flags: nhsync, 
nvsync; type: driver
  #16 720x400 70.08 720 738 846 900 400 412 414 449 28320 flags: nhsync, 
pvsync; type: driver
  props:
1 EDID: 
flags: immutable blob
blobs:

value:  
0000047232ad01010101
2d0e010380221b782aaea5a6544c9926
145054bfef0081808140714f01010101
010101010101302a009851002a403070
1300520e111e00ff00343435
303035354330300a00fc0041
4c313731350a20202020202000fd
00384c1e520e000a2020202020200051
2 DPMS: 
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 3
5 link-status:
flags: enum
enums: Good=0 Bad=1
value: 0
6 non-desktop:
flags: immutable range
values: 0 1
value: 0
4 TILE: 
flags: immutable blob
blobs:

value:
20 CRTC_ID:
flags: object

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

2020-05-13 Thread Paul Boddie 
On Wednesday 13. May 2020 09.37.49 Neil Armstrong wrote:
> Hi Paul,
> 
> I'm one of the drm/bridge maintainer and, with Jernel & Jonas, we did most
> of the changes on the dw-hdmi driver recently for the Amlogic, Rockchip &
> Allwinner platforms.

Thanks for following up to my message!

> On 12/05/2020 21:37, Paul Boddie wrote:
> > 
> > When powering up the system with the driver built into the kernel, the
> > driver is able to obtain mode information over DDC using the Synopsys
> > peripheral's own I2C support (which is more reliable than using the
> > JZ4780's I2C peripherals), and a viable list of modes is obtained.
> 
> Can you run the kernel with drm debug enabled ? drm.debug=0x3f for example
> you'll have all the modes checks & so on

I'll try and do this.

[...]

> Please use the "modetest" utility from the libdrm source package, it will
> list all the available mode and permit testing other modes.

I'll give this a try. The modetest program was suggested by someone else as 
well, so it seems to be the way to go.

> > At the moment, I and others who have tried to test this code have seen
> > that
> > the peripheral is not enabled (as confirmed by inspecting the appropriate
> > entry under /sys/devices/platform). It appears that one obstacle is that
> > the "bus format" is not set for the connector. Here, I noticed (and was
> > reminded again recently) that in the bridge driver, there is no call to
> > drm_display_info_set_bus_formats unlike in other bridge drivers.
> 
> This call is optional, if your video pipeline outputs RGB for the dw-hdmi,
> then you can leave the default for now and omit the bus format negotiation.
> When you'll push the driver, you'll have to implement it correctly like I
> did in the meson-dw-hdmi glue (and in RFC for rockchip driver).

I'll have a look at the meson code. Frustratingly, I am familiar with the LCD 
controller functionality on the SoC family concerned here, but how it 
interacts with the DRI/DRM functionality isn't particularly clear.

The Ingenic DRM driver seems to define support for a number of plane formats 
(XRGB1555, RGB565, XRGB) which correspond to output modes for the LCD 
controller set using its control register.

The driver also supports a number of bus formats (RGB565_1X16, RGB666_1X18, 
RGB888_1X24, RGB888_3X8) that correspond to panel configurations set using its 
configuration register.

However, nothing in the driver sets the bus format (or plane format), meaning 
that something else needs to do so. I see that the input bus format is set in 
the bind function in meson_dw_hdmi.c, and seems to be set in the attach 
function in other comparable drivers.

This is why I wondered whether the generic Synopsys driver might be missing 
such an operation, but it is also plausible that it could be performed in the 
specialised JZ4780 driver, although I currently provide few functions in that 
driver and maybe more customisation is needed.

[...]

> "Input not supported" means the timings/clk are incorrect.
> 
> Of you had an format issue, you'll have incorrect colors/garbled output.

Note that this is with a modification to set drm_display_info_set_bus_formats. 
Without it, initialisation fails to complete, as noted previously. With it, I 
imagine that the timings are indeed wrong.

[...]

> Please enable the dw-hdmi debug prints and enable the DRM debug prints to
> check if everything is negociated.

I will try and generate debugging information.

> But if you have "Input not supported" on your monitor, this means you have
> TMDS going out on your hardware, which is good, this means all the
> power/reset/system clocks are ok.
> This could mean you have a timing/clock issue, please check if something is
> not done on the pixel clock before going to the dw-hdmi block.

I think I may have overlooked timing details, so this will also be a focus of 
mine as I review what I have done so far.

Thanks once again for the advice!

Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780

2020-05-12 Thread Paul Boddie 
Hello,

On and off over the past few months, I have been looking at getting the 
Synopsys DesignWare HDMI peripheral used in the Ingenic JZ4780 SoC working 
with a recent kernel. Unfortunately, what probably should be a straightforward 
task is proving more difficult than it seems, and I have been advised to ask 
for advice on this list.

== Background ==

Previously, in the vendor kernels released by Imagination Technologies for the 
MIPS Creator CI20, there were specialised HDMI drivers for the JZ4780:

* One (based on Linux 3.0.8) which seems to use a Synopsys hardware
  abstraction layer.

* Another (based on Linux 3.18) where the driver incorporates code used to
  support Freescale products and cooperates with a "CRTC" driver that has
  since been replaced by the ingenic-drm.c driver.

Since the Freescale-related code now seems to reside as a kind of generic 
driver in drivers/gpu/drm/bridge/synopsys [1], with some other drivers 
specialising this generic support, I thought that it might be straightforward 
to specialise the code similarly for the JZ4780. Unfortunately, I have not 
managed to achieve this so far, and I imagine that I must have overlooked 
something.

== Summary of Work ==

What I have done so far is to add a new file to...

drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c

(See [2] for the full file.)

This specialises the generic dw-hdmi.c driver and is heavily based on the 
existing driver in...

drivers/gpu/drm/imx/dw_hdmi-imx.c

However, the probe and remove functions are defined in a similar way to...

drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c

It would appear, looking at the vendor kernel code, that the configuration of 
the peripheral in the JZ4780 is most similar to that done in the i.MX 
products, with various configuration operations that are done in their own 
particular way in the vendor kernel code now being done in a more generic way 
in the bridge driver code. So, I have a certain amount of confidence that the 
PLL and current control tables are reasonable.

== Observations ==

When powering up the system with the driver built into the kernel, the driver 
is able to obtain mode information over DDC using the Synopsys peripheral's 
own I2C support (which is more reliable than using the JZ4780's I2C 
peripherals), and a viable list of modes is obtained. However, the debugfs 
state information in /sys/kernel/debug/dri/0/state is largely unpopulated:

plane[31]: plane-0
crtc=(null)
fb=0
crtc-pos=0x0+0+0
src-pos=0.00x0.00+0.00+0.00
rotation=1
normalized-zpos=0
color-encoding=ITU-R BT.601 YCbCr
color-range=YCbCr limited range
crtc[32]: crtc-0
enable=0
active=0
self_refresh_active=0
planes_changed=0
mode_changed=0
active_changed=0
connectors_changed=0
color_mgmt_changed=0
plane_mask=0
connector_mask=0
encoder_mask=0
mode: "": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
connector[34]: HDMI-A-1
crtc=(null)
self_refresh_aware=0

At the moment, I and others who have tried to test this code have seen that 
the peripheral is not enabled (as confirmed by inspecting the appropriate 
entry under /sys/devices/platform). It appears that one obstacle is that the 
"bus format" is not set for the connector. Here, I noticed (and was reminded 
again recently) that in the bridge driver, there is no call to 
drm_display_info_set_bus_formats unlike in other bridge drivers.

If such a call is added with a plausible bus format, the peripheral will be 
enabled, but the signal is not correct (monitors report things like "Input not 
supported"). It also occurs to me that other aspects of the signal may need to 
be defined. However, the debugfs state information will be populated with 
plausible values and seems to indicate that initialisation has taken place.

== Conclusions ==

Without direct modifications to dw-hdmi.c, it seems like the initialisation of 
the appropriate data structures is not being completed. Without the call to 
drm_display_info_set_bus_formats in dw_hdmi_bridge_attach, the encoder does 
not get set on the connector, and the chain of components is not fully 
traversed for initialisation.

One part of this situation is the dw_hdmi_setup function in the bridge driver. 
Here, there is the following code:

/* TOFIX: Get input format from plat data or fallback to RGB888 */
if (hdmi->plat_data->input_bus_format)
hdmi->hdmi_data.enc_in_bus_format =
hdmi->plat_data->input_bus_format;
else
hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;

/* TOFIX: Get input encoding from plat data or fallback to none */
if (hdmi->plat_data->input_bus_encoding)
hdmi->hdmi_data.enc_in_encoding =
hdmi->plat_data->input_bus_encoding;
else
hdmi->hdmi_data.enc_in_encoding =