* Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780
@ 2020-05-12 19:37 Paul Boddie
2020-05-13 7:37 ` drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780) Neil Armstrong
0 siblings, 1 reply; 26+ messages in thread
From: Paul Boddie @ 2020-05-12 19:37 UTC (permalink / raw)
To: dri-devel
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.000000x0.000000+0.000000+0.000000
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 = V4L2_YCBCR_ENC_DEFAULT;
What I seek guidance on is whether the unfixed nature of this code is having
an impact and what I should be doing to make this driver initialise correctly.
Given that there is no obvious documentation for the Synopsys peripheral, I
feel that it will be a long journey figuring this out by myself.
Thanks for any advice that anyone might have!
Paul
[1] https://lists.freedesktop.org/archives/dri-devel/2017-March/134666.html
[2] http://git.goldelico.com/?p=letux-kernel.git;a=blob_plain;f=drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c;hb=75c6904c2f198825f67172a0a5a98190fa54ae05
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-12 19:37 Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 Paul Boddie
@ 2020-05-13 7:37 ` Neil Armstrong
2020-05-13 21:18 ` Paul Boddie
2020-05-14 22:04 ` Paul Boddie
0 siblings, 2 replies; 26+ messages in thread
From: Neil Armstrong @ 2020-05-13 7:37 UTC (permalink / raw)
To: Paul Boddie, dri-devel; +Cc: Jernej Skrabec, Jonas Karlman
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.
On 12/05/2020 21:37, Paul Boddie wrote:
> 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.
Can you run the kernel with drm debug enabled ? drm.debug=0x3f for example
you'll have all the modes checks & so on
> 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.000000x0.000000+0.000000+0.000000
> 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
Please use the "modetest" utility from the libdrm source package, it will
list all the available mode and permit testing other modes.
>
> 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).
>
> 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.
"Input not supported" means the timings/clk are incorrect.
Of you had an format issue, you'll have incorrect colors/garbled output.
>
> == 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 = V4L2_YCBCR_ENC_DEFAULT;
>
> What I seek guidance on is whether the unfixed nature of this code is having
> an impact and what I should be doing to make this driver initialise correctly.
> Given that there is no obvious documentation for the Synopsys peripheral, I
> feel that it will be a long journey figuring this out by myself.
Please enable the dw-hdmi debug prints and enable the DRM debug prints to check
if everything is negociated.
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.
Neil
>
> Thanks for any advice that anyone might have!
>
> Paul
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2017-March/134666.html
>
> [2] http://git.goldelico.com/?p=letux-kernel.git;a=blob_plain;f=drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c;hb=75c6904c2f198825f67172a0a5a98190fa54ae05
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 7:37 ` drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780) Neil Armstrong
@ 2020-05-13 21:18 ` Paul Boddie
2020-05-14 22:04 ` Paul Boddie
1 sibling, 0 replies; 26+ messages in thread
From: Paul Boddie @ 2020-05-13 21:18 UTC (permalink / raw)
To: Neil Armstrong; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
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, XRGB8888) 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 7:37 ` drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780) Neil Armstrong
2020-05-13 21:18 ` Paul Boddie
@ 2020-05-14 22:04 ` Paul Boddie
2020-05-15 7:43 ` Neil Armstrong
1 sibling, 1 reply; 26+ messages in thread
From: Paul Boddie @ 2020-05-14 22:04 UTC (permalink / raw)
To: Neil Armstrong; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
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 crtc type possible crtcs possible clones
33 32 DPI 0x00000001 0x00000000
Connectors:
id encoder status name size (mm) modes
encoders
34 33 connected HDMI-A-1 340x270 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 50000 flags: phsync,
pvsync; type: driver
#10 800x600 60.32 800 840 968 1056 600 601 605 628 40000 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:
00ffffffffffff00047232ad01010101
2d0e010380221b782aaea5a6544c9926
145054bfef0081808140714f01010101
010101010101302a009851002a403070
1300520e1100001e000000ff00343435
3030353444454330300a000000fc0041
4c313731350a202020202020000000fd
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
value: 32
CRTCs:
id fb pos size
32 38 (0,0) (1280x1024)
#0 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync,
pvsync; type:
props:
22 ACTIVE:
flags: range
values: 0 1
value: 0
23 MODE_ID:
flags: blob
blobs:
value:
e0a5010000053005a005980600000004
010404042a0400000000000005000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000
19 OUT_FENCE_PTR:
flags: range
values: 0 18446744073709551615
value: 0
24 VRR_ENABLED:
flags: range
values: 0 1
value: 0
Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
31 32 38 0,0 0,0 0 0x00000001
formats: XR15 RG16 XR24
props:
8 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
17 FB_ID:
flags: object
value: 38
18 IN_FENCE_FD:
flags: signed range
values: -1 2147483647
value: -1
20 CRTC_ID:
flags: object
value: 32
13 CRTC_X:
flags: signed range
values: -2147483648 2147483647
value: 0
14 CRTC_Y:
flags: signed range
values: -2147483648 2147483647
value: 0
15 CRTC_W:
flags: range
values: 0 2147483647
value: 1280
16 CRTC_H:
flags: range
values: 0 2147483647
value: 1024
9 SRC_X:
flags: range
values: 0 4294967295
value: 0
10 SRC_Y:
flags: range
values: 0 4294967295
value: 0
11 SRC_W:
flags: range
values: 0 4294967295
value: 83886080
12 SRC_H:
flags: range
values: 0 4294967295
value: 67108864
Frame buffers:
id size pitch
-----------------------------------------------------------
For completeness, this is what /sys/kernel/debug/dri/0/state shows:
-----------------------------------------------------------
plane[31]: plane-0
crtc=crtc-0
fb=38
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=00010500
size=5242880
imported=no
crtc-pos=1280x1024+0+0
src-pos=1280.000000x1024.000000+0.000000+0.000000
rotation=1
normalized-zpos=0
color-encoding=ITU-R BT.601 YCbCr
color-range=YCbCr limited range
crtc[32]: crtc-0
enable=1
active=0
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: "": 0 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x0 0x5
connector[34]: HDMI-A-1
crtc=crtc-0
self_refresh_aware=0
-----------------------------------------------------------
Some other output:
-----------------------------------------------------------
# cat /sys/devices/platform/13050000.lcd/graphics/fb0/mode
# cat /sys/devices/platform/13050000.lcd/graphics/fb0/modes
U:1280x1024p-0
# cat /sys/devices/platform/13050000.lcd/graphics/fb0/state
0
# cat /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/enabled
enabled
# cat /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/modes
1280x1024
1280x1024
1280x960
1152x864
1024x768
1024x768
1024x768
832x624
800x600
800x600
800x600
800x600
640x480
640x480
640x480
640x480
720x400
# cat /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/status
connected
-----------------------------------------------------------
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
[...]
> > 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.
What I did look at today was the Ingenic DRM driver initialisation. There are
certain things that are not done in this driver that the vendor driver does
do.
For example, there is some kind of priority level register (PCFG) that is set
up with a "magic value" that can be largely explained by the programming
manual. Also, there is a RGB control register that older Ingenic SoCs do not
provide, and this is set up by the vendor driver. I have no idea whether they
play any role in this, but I introduced their initialisation anyway.
There was also a configuration register field related to the bus signalling
(JZ_LCD_CFG_PCLK_FALLING_EDGE) not being set because it is dependent on the
appropriate bus flag being set (DRM_BUS_FLAG_PIXDATA_NEGEDGE), which may not
have been occurring. Unfortunately, setting the bus flag in the bridge driver
didn't yield any progress.
So that is what I have discovered today.
Thanks once again for the advice!
Paul
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 22:04 ` Paul Boddie
@ 2020-05-15 7:43 ` Neil Armstrong
2020-05-16 17:01 ` Paul Boddie
2020-07-05 23:57 ` Paul Boddie
0 siblings, 2 replies; 26+ messages in thread
From: Neil Armstrong @ 2020-05-15 7:43 UTC (permalink / raw)
To: Paul Boddie; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
Hi,
On 15/05/2020 00:04, Paul Boddie wrote:
> 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 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.
>
> 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 crtc type possible crtcs possible clones
> 33 32 DPI 0x00000001 0x00000000
>
> Connectors:
> id encoder status name size (mm) modes
> encoders
> 34 33 connected HDMI-A-1 340x270 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 50000 flags: phsync,
> pvsync; type: driver
> #10 800x600 60.32 800 840 968 1056 600 601 605 628 40000 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
Perfect, EDID reading works fine.
> props:
> 1 EDID:
> flags: immutable blob
> blobs:
>
> value:
> 00ffffffffffff00047232ad01010101
> 2d0e010380221b782aaea5a6544c9926
> 145054bfef0081808140714f01010101
> 010101010101302a009851002a403070
> 1300520e1100001e000000ff00343435
> 3030353444454330300a000000fc0041
> 4c313731350a202020202020000000fd
> 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
> value: 32
>
> CRTCs:
> id fb pos size
> 32 38 (0,0) (1280x1024)
> #0 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync,
> pvsync; type:
> props:
> 22 ACTIVE:
> flags: range
> values: 0 1
> value: 0
> 23 MODE_ID:
> flags: blob
> blobs:
>
> value:
> e0a5010000053005a005980600000004
> 010404042a0400000000000005000000
> 00000000000000000000000000000000
> 00000000000000000000000000000000
> 00000000
> 19 OUT_FENCE_PTR:
> flags: range
> values: 0 18446744073709551615
> value: 0
> 24 VRR_ENABLED:
> flags: range
> values: 0 1
> value: 0
>
> Planes:
> id crtc fb CRTC x,y x,y gamma size possible crtcs
> 31 32 38 0,0 0,0 0 0x00000001
> formats: XR15 RG16 XR24
> props:
> 8 type:
> flags: immutable enum
> enums: Overlay=0 Primary=1 Cursor=2
> value: 1
> 17 FB_ID:
> flags: object
> value: 38
> 18 IN_FENCE_FD:
> flags: signed range
> values: -1 2147483647
> value: -1
> 20 CRTC_ID:
> flags: object
> value: 32
> 13 CRTC_X:
> flags: signed range
> values: -2147483648 2147483647
> value: 0
> 14 CRTC_Y:
> flags: signed range
> values: -2147483648 2147483647
> value: 0
> 15 CRTC_W:
> flags: range
> values: 0 2147483647
> value: 1280
> 16 CRTC_H:
> flags: range
> values: 0 2147483647
> value: 1024
> 9 SRC_X:
> flags: range
> values: 0 4294967295
> value: 0
> 10 SRC_Y:
> flags: range
> values: 0 4294967295
> value: 0
> 11 SRC_W:
> flags: range
> values: 0 4294967295
> value: 83886080
> 12 SRC_H:
> flags: range
> values: 0 4294967295
> value: 67108864
>
> Frame buffers:
> id size pitch
>
> -----------------------------------------------------------
>
> For completeness, this is what /sys/kernel/debug/dri/0/state shows:
>
> -----------------------------------------------------------
>
> plane[31]: plane-0
> crtc=crtc-0
> fb=38
> 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=00010500
> size=5242880
> imported=no
> crtc-pos=1280x1024+0+0
> src-pos=1280.000000x1024.000000+0.000000+0.000000
> rotation=1
> normalized-zpos=0
> color-encoding=ITU-R BT.601 YCbCr
> color-range=YCbCr limited range
> crtc[32]: crtc-0
> enable=1
> active=0
> 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: "": 0 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x0 0x5
> connector[34]: HDMI-A-1
> crtc=crtc-0
> self_refresh_aware=0
>
> -----------------------------------------------------------
>
> Some other output:
>
> -----------------------------------------------------------
>
> # cat /sys/devices/platform/13050000.lcd/graphics/fb0/mode
> # cat /sys/devices/platform/13050000.lcd/graphics/fb0/modes
> U:1280x1024p-0
> # cat /sys/devices/platform/13050000.lcd/graphics/fb0/state
> 0
> # cat /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/enabled
> enabled
> # cat /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/modes
> 1280x1024
> 1280x1024
> 1280x960
> 1152x864
> 1024x768
> 1024x768
> 1024x768
> 832x624
> 800x600
> 800x600
> 800x600
> 800x600
> 640x480
> 640x480
> 640x480
> 640x480
> 720x400
> # cat /sys/devices/platform/13050000.lcd/drm/card0/card0-HDMI-A-1/status
> connected
>
> -----------------------------------------------------------
>
> 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 ?
>
> [...]
>
>>> 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 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.
>
> What I did look at today was the Ingenic DRM driver initialisation. There are
> certain things that are not done in this driver that the vendor driver does
> do.
>
> For example, there is some kind of priority level register (PCFG) that is set
> up with a "magic value" that can be largely explained by the programming
> manual. Also, there is a RGB control register that older Ingenic SoCs do not
> provide, and this is set up by the vendor driver. I have no idea whether they
> play any role in this, but I introduced their initialisation anyway.
>
> There was also a configuration register field related to the bus signalling
> (JZ_LCD_CFG_PCLK_FALLING_EDGE) not being set because it is dependent on the
> appropriate bus flag being set (DRM_BUS_FLAG_PIXDATA_NEGEDGE), which may not
> have been occurring. Unfortunately, setting the bus flag in the bridge driver
> didn't yield any progress.
>
> So that is what I have discovered today.
>
> Thanks once again for the advice!
>
> Paul
>
Hope it helped...
Neil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-15 7:43 ` Neil Armstrong
@ 2020-05-16 17:01 ` Paul Boddie
2020-07-05 23:57 ` Paul Boddie
1 sibling, 0 replies; 26+ messages in thread
From: Paul Boddie @ 2020-05-16 17:01 UTC (permalink / raw)
To: Neil Armstrong; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
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 1 1 0 48000000
tve 1 1 0 48000000
vpll 2 2 2 888000000
hdmi 1 1 0 26909090
lcd1pixclk 0 0 0 888000000
lcd0pixclk 1 1 0 98666666
From the 3.18 vendor kernel:
lcd 1 1 48000000
tve 1 1 48000000
vpll 2 2 888000000
hdmi 1 1 26909090
lcd1pixclk 0 0 888000000
lcd0pixclk 1 1 111000000
(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
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-15 7:43 ` Neil Armstrong
2020-05-16 17:01 ` Paul Boddie
@ 2020-07-05 23:57 ` Paul Boddie
2020-07-06 12:12 ` Neil Armstrong
1 sibling, 1 reply; 26+ messages in thread
From: Paul Boddie @ 2020-07-05 23:57 UTC (permalink / raw)
To: Neil Armstrong; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
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(&connector->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
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-05 23:57 ` Paul Boddie
@ 2020-07-06 12:12 ` Neil Armstrong
2020-07-06 20:55 ` Paul Boddie
0 siblings, 1 reply; 26+ messages in thread
From: Neil Armstrong @ 2020-07-06 12:12 UTC (permalink / raw)
To: Paul Boddie; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
Hi,
On 06/07/2020 01:57, Paul Boddie wrote:
> 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 };
> ...
> (&connector->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).
I think this is specific to the ingenic DRM driver, so yeah it may be needed in your case.
>
> 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;
>
> [...]
>
>>> 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
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 ?
>
> 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
>
>
Neil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 12:12 ` Neil Armstrong
@ 2020-07-06 20:55 ` Paul Boddie
2020-08-19 10:21 ` Ezequiel Garcia
0 siblings, 1 reply; 26+ messages in thread
From: Paul Boddie @ 2020-07-06 20:55 UTC (permalink / raw)
To: Neil Armstrong; +Cc: Jernej Skrabec, dri-devel, Jonas Karlman
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 20:55 ` Paul Boddie
@ 2020-08-19 10:21 ` Ezequiel Garcia
2020-08-19 16:22 ` Paul Boddie
2020-08-19 18:49 ` H. Nikolaus Schaller
0 siblings, 2 replies; 26+ messages in thread
From: Ezequiel Garcia @ 2020-08-19 10:21 UTC (permalink / raw)
To: Paul Boddie, Paul Cercueil, hns
Cc: Jernej Skrabec, Jonas Karlman, dri-devel, Neil Armstrong
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.
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? :)
The edid of my monitor is properly read
and modetest reports all modes.
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.
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.
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.
Cheers & thanks again,
Eze
On Tue, 7 Jul 2020 at 04:27, Paul Boddie <paul@boddie.org.uk> 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 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-19 10:21 ` Ezequiel Garcia
@ 2020-08-19 16:22 ` Paul Boddie
2020-08-19 18:49 ` H. Nikolaus Schaller
1 sibling, 0 replies; 26+ messages in thread
From: Paul Boddie @ 2020-08-19 16:22 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Jonas Karlman, hns, Neil Armstrong, dri-devel,
Paul Cercueil
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 <paul@boddie.org.uk> 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 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-19 10:21 ` Ezequiel Garcia
2020-08-19 16:22 ` Paul Boddie
@ 2020-08-19 18:49 ` H. Nikolaus Schaller
2020-08-19 22:26 ` Ezequiel Garcia
1 sibling, 1 reply; 26+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-19 18:49 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
Hi Ezequiel,
> Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
>
> 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.
>
> 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? :)
Wow!
> The edid of my monitor is properly read
> and modetest reports all modes.
>
> 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.
>
> 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
Cool!
> 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.
I have tried our latest letux-5.9-rc1 tree (with Pauls fixes)
on my setup but screen remains black and the kernel was stuck
after showing "login:" and reported
[ 490.680469] rcu: INFO: rcu_preempt self-detected stall on CPU
Maybe, can you share your rebased tree to clearly identify the
subtle differences? Maybe I have broken something by the rebase.
> Cheers & thanks again,
> Eze
Thanks and best regards,
Nikolaus
>
>
>
>
> On Tue, 7 Jul 2020 at 04:27, Paul Boddie <paul@boddie.org.uk> 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 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-19 18:49 ` H. Nikolaus Schaller
@ 2020-08-19 22:26 ` Ezequiel Garcia
2020-08-20 8:19 ` H. Nikolaus Schaller
0 siblings, 1 reply; 26+ messages in thread
From: Ezequiel Garcia @ 2020-08-19 22:26 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Ezequiel,
>
> > Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
> >
> > 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.
> >
> > 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? :)
>
> Wow!
>
> > The edid of my monitor is properly read
> > and modetest reports all modes.
> >
> > 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.
> >
> > 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
>
> Cool!
>
> > 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.
>
> I have tried our latest letux-5.9-rc1 tree (with Pauls fixes)
> on my setup but screen remains black and the kernel was stuck
> after showing "login:" and reported
>
> [ 490.680469] rcu: INFO: rcu_preempt self-detected stall on CPU
>
> Maybe, can you share your rebased tree to clearly identify the
> subtle differences? Maybe I have broken something by the rebase.
>
Sure.
Please give this a try and let me know if it works for you.
I've cleaned and squashed your changes, hopefully
I've kept the correct authorship for all of them.
https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-v5.9-rc1
This should be enough to get an fbcon, launch weston, etc.
However, there are few things that still don't look right.
Seems planes X,Y offset is not working, and also enabling
a second plane results in both planes going black for good.
This needs some more investigation, but seems at least a good start.
Thanks again for all the good work,
Ezequiel
> > Cheers & thanks again,
> > Eze
>
> Thanks and best regards,
> Nikolaus
>
>
> >
> >
> >
> >
> > On Tue, 7 Jul 2020 at 04:27, Paul Boddie <paul@boddie.org.uk> 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 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
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-19 22:26 ` Ezequiel Garcia
@ 2020-08-20 8:19 ` H. Nikolaus Schaller
2020-08-20 22:49 ` Paul Boddie
0 siblings, 1 reply; 26+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-20 8:19 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
Hi Ezequiel,
> Am 20.08.2020 um 00:26 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
>
> On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>> Maybe, can you share your rebased tree to clearly identify the
>> subtle differences? Maybe I have broken something by the rebase.
>>
>
> Sure.
>
> Please give this a try and let me know if it works for you.
>
> I've cleaned and squashed your changes, hopefully
> I've kept the correct authorship for all of them.
>
> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-v5.9-rc1
>
> This should be enough to get an fbcon, launch weston, etc.
> However, there are few things that still don't look right.
> Seems planes X,Y offset is not working, and also enabling
> a second plane results in both planes going black for good.
Yes, it works!!!
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 8:19 ` H. Nikolaus Schaller
@ 2020-08-20 22:49 ` Paul Boddie
2020-08-21 13:32 ` Ezequiel Garcia
0 siblings, 1 reply; 26+ messages in thread
From: Paul Boddie @ 2020-08-20 22:49 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Jernej Skrabec, Jonas Karlman, Neil Armstrong, dri-devel,
Paul Cercueil, MIPS Creator CI20 Development, Ezequiel Garcia
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 22:49 ` Paul Boddie
@ 2020-08-21 13:32 ` Ezequiel Garcia
2020-08-21 22:11 ` Paul Boddie
0 siblings, 1 reply; 26+ messages in thread
From: Ezequiel Garcia @ 2020-08-21 13:32 UTC (permalink / raw)
To: Paul Boddie
Cc: Jernej Skrabec, Jonas Karlman, H. Nikolaus Schaller,
Neil Armstrong, dri-devel, Paul Cercueil,
MIPS Creator CI20 Development
On Thu, 20 Aug 2020 at 19:49, Paul Boddie <paul@boddie.org.uk> wrote:
>
> 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).
>
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.
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.
> 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.)
>
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
> > 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.
>
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.
> 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.
>
Life (and kernel) is like this: sometimes you need to take three steps
back to make a jump forward :-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 13:32 ` Ezequiel Garcia
@ 2020-08-21 22:11 ` Paul Boddie
2020-08-21 22:24 ` Paul Cercueil
0 siblings, 1 reply; 26+ messages in thread
From: Paul Boddie @ 2020-08-21 22:11 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Jonas Karlman, H. Nikolaus Schaller,
Neil Armstrong, dri-devel, Paul Cercueil,
MIPS Creator CI20 Development
On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> On Thu, 20 Aug 2020 at 19:49, Paul Boddie <paul@boddie.org.uk> 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 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.
>
> Life (and kernel) is like this: sometimes you need to take three steps
> back to make a jump forward :-)
Well, I wish I could be so optimistic. Objectively, the whole Linux kernel
development process is just so poor when we consider that we started out in
2014 or earlier with software that actually worked with the hardware, but
since it wasn't written quite to everybody's tastes and in line with the
fashions of the day, the whole exercise of reworking it was thrown straight
back at the developers. And since the developers were only being paid for as
long as their employers were interested, which turned out not to last
particularly long, we all ended up with yet another piece of equipment which
risks becoming obsolete unnecessarily.
Of course I would probably benefit from upstreamed support for the CI20,
although I was actually fairly happy using the 3.18 kernel with a relatively
recent Debian version, and we might not yet be at the point where new Debian
releases don't work with such an old kernel. But for the most part I don't
really care personally about fixing up Linux support for such hardware because
my own interests lie elsewhere. I suppose the most I get out of it is looking
at how the hardware works and being in a stronger position to reimplement the
driver support for L4Re. Indeed, I got the RTC support working in L4Re in
order to troubleshoot the Linux drivers, although they still seem to be
pathologically unable to handle the "lost clock" condition that is hardly
unlikely on the CI20.
Yet at the same time, I always manage to feel guilty asking for cooperation to
get improvements made to Linux, spending quite a bit of my own personal time
working with the underdocumented frameworks involved, building, deploying,
testing, and so on. And this is just my own way of offering help to others who
might not be in quite the same position, technically, to improve a situation
that might be far more important to them. Whatever little satisfaction I might
get from helping out tends to get completely overwhelmed by the amount of
effort, frustration and time involved.
Anyway, sorry for the rant. I'm sure other people find their own activities of
this nature to be sufficiently fulfilling and enjoyable. Life does present us
all with setbacks, but I generally don't appreciate getting served up with
more of them just so that some people in the Valley or wherever can "have fun"
or whatever the mantra is these days.
Paul
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 22:11 ` Paul Boddie
@ 2020-08-21 22:24 ` Paul Cercueil
2020-08-24 13:46 ` Ezequiel Garcia
0 siblings, 1 reply; 26+ messages in thread
From: Paul Cercueil @ 2020-08-21 22:24 UTC (permalink / raw)
To: Paul Boddie
Cc: Jernej Skrabec, Jonas Karlman, H. Nikolaus Schaller,
Neil Armstrong, dri-devel, MIPS Creator CI20 Development,
Ezequiel Garcia
Le sam. 22 août 2020 à 0:11, Paul Boddie <paul@boddie.org.uk> a
écrit :
> On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
>> On Thu, 20 Aug 2020 at 19:49, Paul Boddie <paul@boddie.org.uk>
>> 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.
If you send clean patches, there's no reason for me not to merge them.
>> > 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.
>>
>> Life (and kernel) is like this: sometimes you need to take three
>> steps
>> back to make a jump forward :-)
That's pretty much expected for a -rc1 release. Wait until -rc3 or -rc4
to have something more or less stable.
Cheers,
-Paul
> Well, I wish I could be so optimistic. Objectively, the whole Linux
> kernel
> development process is just so poor when we consider that we started
> out in
> 2014 or earlier with software that actually worked with the hardware,
> but
> since it wasn't written quite to everybody's tastes and in line with
> the
> fashions of the day, the whole exercise of reworking it was thrown
> straight
> back at the developers. And since the developers were only being paid
> for as
> long as their employers were interested, which turned out not to last
> particularly long, we all ended up with yet another piece of
> equipment which
> risks becoming obsolete unnecessarily.
>
> Of course I would probably benefit from upstreamed support for the
> CI20,
> although I was actually fairly happy using the 3.18 kernel with a
> relatively
> recent Debian version, and we might not yet be at the point where new
> Debian
> releases don't work with such an old kernel. But for the most part I
> don't
> really care personally about fixing up Linux support for such
> hardware because
> my own interests lie elsewhere. I suppose the most I get out of it is
> looking
> at how the hardware works and being in a stronger position to
> reimplement the
> driver support for L4Re. Indeed, I got the RTC support working in
> L4Re in
> order to troubleshoot the Linux drivers, although they still seem to
> be
> pathologically unable to handle the "lost clock" condition that is
> hardly
> unlikely on the CI20.
>
> Yet at the same time, I always manage to feel guilty asking for
> cooperation to
> get improvements made to Linux, spending quite a bit of my own
> personal time
> working with the underdocumented frameworks involved, building,
> deploying,
> testing, and so on. And this is just my own way of offering help to
> others who
> might not be in quite the same position, technically, to improve a
> situation
> that might be far more important to them. Whatever little
> satisfaction I might
> get from helping out tends to get completely overwhelmed by the
> amount of
> effort, frustration and time involved.
>
> Anyway, sorry for the rant. I'm sure other people find their own
> activities of
> this nature to be sufficiently fulfilling and enjoyable. Life does
> present us
> all with setbacks, but I generally don't appreciate getting served up
> with
> more of them just so that some people in the Valley or wherever can
> "have fun"
> or whatever the mantra is these days.
>
> Paul
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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 22:24 ` Paul Cercueil
@ 2020-08-24 13:46 ` Ezequiel Garcia
2020-08-24 16:04 ` H. Nikolaus Schaller
0 siblings, 1 reply; 26+ messages in thread
From: Ezequiel Garcia @ 2020-08-24 13:46 UTC (permalink / raw)
To: Paul Cercueil
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, H. Nikolaus Schaller,
Neil Armstrong, dri-devel, MIPS Creator CI20 Development
On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <paul@crapouillou.net> wrote:
>
>
>
> Le sam. 22 août 2020 à 0:11, Paul Boddie <paul@boddie.org.uk> a
> écrit :
> > On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> >> On Thu, 20 Aug 2020 at 19:49, Paul Boddie <paul@boddie.org.uk>
> >> 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.
>
> If you send clean patches, there's no reason for me not to merge them.
>
I'd really like to see HDMI support on my CI20 being merged. Thank to
recent ingenic-drm work and thanks for Paul Boddie and Nikolaus work,
the patches are IMO quite clean.
Nikolaus, Paul: Do you have plans to submit these? If not, I'll be
happy to get them out the door for review.
Cheers,
Ezequiel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-24 13:46 ` Ezequiel Garcia
@ 2020-08-24 16:04 ` H. Nikolaus Schaller
2020-08-24 17:38 ` Ezequiel Garcia
0 siblings, 1 reply; 26+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-24 16:04 UTC (permalink / raw)
To: Ezequiel Garcia, Paul Boddie
Cc: Jernej Skrabec, Jonas Karlman, Neil Armstrong, dri-devel,
Paul Cercueil, MIPS Creator CI20 Development
Hi Ezequiel,
> Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
>
> On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <paul@crapouillou.net> wrote:
>>
>>
>>
>> Le sam. 22 août 2020 à 0:11, Paul Boddie <paul@boddie.org.uk> a
>> écrit :
>>
>> If you send clean patches, there's no reason for me not to merge them.
>>
>
> I'd really like to see HDMI support on my CI20 being merged. Thank to
> recent ingenic-drm work and thanks for Paul Boddie and Nikolaus work,
> the patches are IMO quite clean.
I have done some testing and it appears that it only works if DRM is
compiled into the kernel. At least in my setup. If DRM and/or HDMI are made
modules there is no video or code doesn't compile completely.
We have to analyse that further.
And it seems to differ significantly from what Paul has developed recently
to make it work. It seems to be quite lucky that we have a working setup now :)
> Nikolaus, Paul: Do you have plans to submit these?
Yes, as soon as we are sure that it works (and when it doesn't).
But thanks to your work it is now much easier to improve things, since we
are no longer looking for a break-through but just have to avoid regressions.
> If not, I'll be happy to get them out the door for review.
Let it mature a little first and have it tested on more setups and rebased
to mainline v5.9-rc2 :)
BR and thanks,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-24 16:04 ` H. Nikolaus Schaller
@ 2020-08-24 17:38 ` Ezequiel Garcia
2020-08-24 21:11 ` Paul Cercueil
2020-08-27 7:21 ` H. Nikolaus Schaller
0 siblings, 2 replies; 26+ messages in thread
From: Ezequiel Garcia @ 2020-08-24 17:38 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Ezequiel,
>
> > Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
> >
> > On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <paul@crapouillou.net> wrote:
> >>
> >>
> >>
> >> Le sam. 22 août 2020 à 0:11, Paul Boddie <paul@boddie.org.uk> a
> >> écrit :
> >>
> >> If you send clean patches, there's no reason for me not to merge them.
> >>
> >
> > I'd really like to see HDMI support on my CI20 being merged. Thank to
> > recent ingenic-drm work and thanks for Paul Boddie and Nikolaus work,
> > the patches are IMO quite clean.
>
> I have done some testing and it appears that it only works if DRM is
> compiled into the kernel. At least in my setup. If DRM and/or HDMI are made
> modules there is no video or code doesn't compile completely.
>
> We have to analyse that further.
>
Ah! That's true.
The fix is just re-organizing the code a bit. Just pushed a possible
fix for that (following the IPU handling by Paul Cercueil),
please feel free to test this:
https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2
FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
(which means dm9000 works). I'm testing with weston and modetest.
Note that enabling DRM_INGENIC_IPU will make the driver
fail to load, as the IPU is not optional (and not present on ci20.dts).
A minor thing to fix.
Cheers,
Ezequiel
> And it seems to differ significantly from what Paul has developed recently
> to make it work. It seems to be quite lucky that we have a working setup now :)
>
> > Nikolaus, Paul: Do you have plans to submit these?
>
> Yes, as soon as we are sure that it works (and when it doesn't).
>
> But thanks to your work it is now much easier to improve things, since we
> are no longer looking for a break-through but just have to avoid regressions.
>
> > If not, I'll be happy to get them out the door for review.
>
> Let it mature a little first and have it tested on more setups and rebased
> to mainline v5.9-rc2 :)
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-24 17:38 ` Ezequiel Garcia
@ 2020-08-24 21:11 ` Paul Cercueil
2020-08-27 7:21 ` H. Nikolaus Schaller
1 sibling, 0 replies; 26+ messages in thread
From: Paul Cercueil @ 2020-08-24 21:11 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, H. Nikolaus Schaller,
Neil Armstrong, dri-devel, MIPS Creator CI20 Development
Le lun. 24 août 2020 à 14:38, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> a écrit :
> On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller
> <hns@goldelico.com> wrote:
>>
>> Hi Ezequiel,
>>
>> > Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia
>> <ezequiel@vanguardiasur.com.ar>:
>> >
>> > On Fri, 21 Aug 2020 at 19:24, Paul Cercueil
>> <paul@crapouillou.net> wrote:
>> >>
>> >>
>> >>
>> >> Le sam. 22 août 2020 à 0:11, Paul Boddie <paul@boddie.org.uk> a
>> >> écrit :
>> >>
>> >> If you send clean patches, there's no reason for me not to merge
>> them.
>> >>
>> >
>> > I'd really like to see HDMI support on my CI20 being merged.
>> Thank to
>> > recent ingenic-drm work and thanks for Paul Boddie and Nikolaus
>> work,
>> > the patches are IMO quite clean.
>>
>> I have done some testing and it appears that it only works if DRM is
>> compiled into the kernel. At least in my setup. If DRM and/or HDMI
>> are made
>> modules there is no video or code doesn't compile completely.
>>
>> We have to analyse that further.
>>
>
> Ah! That's true.
>
> The fix is just re-organizing the code a bit. Just pushed a possible
> fix for that (following the IPU handling by Paul Cercueil),
> please feel free to test this:
>
> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2
>
> FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
> The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
> (which means dm9000 works). I'm testing with weston and modetest.
>
> Note that enabling DRM_INGENIC_IPU will make the driver
> fail to load, as the IPU is not optional (and not present on
> ci20.dts).
> A minor thing to fix.
Actually that's a bug, the IPU should be optional. I'll come up with a
fix.
>> And it seems to differ significantly from what Paul has developed
>> recently
>> to make it work. It seems to be quite lucky that we have a working
>> setup now :)
>>
>> > Nikolaus, Paul: Do you have plans to submit these?
>>
>> Yes, as soon as we are sure that it works (and when it doesn't).
>>
>> But thanks to your work it is now much easier to improve things,
>> since we
>> are no longer looking for a break-through but just have to avoid
>> regressions.
>>
>> > If not, I'll be happy to get them out the door for review.
>>
>> Let it mature a little first and have it tested on more setups and
>> rebased
>> to mainline v5.9-rc2 :)
>>
DRM drivers follow their own schedule, you should rebase to
drm-misc-next instead.
Cheers,
-Paul
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-24 17:38 ` Ezequiel Garcia
2020-08-24 21:11 ` Paul Cercueil
@ 2020-08-27 7:21 ` H. Nikolaus Schaller
2020-09-10 7:53 ` H. Nikolaus Schaller
1 sibling, 1 reply; 26+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-27 7:21 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
Hi Ezequiel,
> Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
>
> On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>> Hi Ezequiel,
>
> The fix is just re-organizing the code a bit. Just pushed a possible
> fix for that (following the IPU handling by Paul Cercueil),
> please feel free to test this:
>
> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2
Works well (after doing a minor fix to the CI20 defconfig)!
>
> FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
> The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
> (which means dm9000 works). I'm testing with weston and modetest.
>
> Note that enabling DRM_INGENIC_IPU will make the driver
> fail to load, as the IPU is not optional (and not present on ci20.dts).
> A minor thing to fix.
>
> Cheers,
> Ezequiel
>
>> And it seems to differ significantly from what Paul has developed recently
>> to make it work. It seems to be quite lucky that we have a working setup now :)
>>
>>> Nikolaus, Paul: Do you have plans to submit these?
>>
>> Yes, as soon as we are sure that it works (and when it doesn't).
>>
>> But thanks to your work it is now much easier to improve things, since we
>> are no longer looking for a break-through but just have to avoid regressions.
>>
>>> If not, I'll be happy to get them out the door for review.
>>
>> Let it mature a little first and have it tested on more setups and rebased
>> to mainline v5.9-rc2 :)
> Am 24.08.2020 um 23:11 schrieb Paul Cercueil <paul@crapouillou.net>:
>
> DRM drivers follow their own schedule, you should rebase to drm-misc-next instead.
>
With the comment from Paul, I think it is best if you push them for review.
My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have
included only for making my Ethernet interface work for testing):
https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5
Please take it, do the required squashes and rebasing and post them for discussion to the
appropriate lists.
BR and thanks for this great break through,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-27 7:21 ` H. Nikolaus Schaller
@ 2020-09-10 7:53 ` H. Nikolaus Schaller
2020-09-10 12:14 ` Ezequiel Garcia
0 siblings, 1 reply; 26+ messages in thread
From: H. Nikolaus Schaller @ 2020-09-10 7:53 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
Hi Ezequiel,
> Am 27.08.2020 um 09:21 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi Ezequiel,
>
>> Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
>>
>> On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>
>>> Hi Ezequiel,
>>
>> The fix is just re-organizing the code a bit. Just pushed a possible
>> fix for that (following the IPU handling by Paul Cercueil),
>> please feel free to test this:
>>
>> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2
>
> Works well (after doing a minor fix to the CI20 defconfig)!
>
>>
>> FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
>> The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
>> (which means dm9000 works). I'm testing with weston and modetest.
>>
>> Note that enabling DRM_INGENIC_IPU will make the driver
>> fail to load, as the IPU is not optional (and not present on ci20.dts).
>> A minor thing to fix.
>>
>> Cheers,
>> Ezequiel
>>
>>> And it seems to differ significantly from what Paul has developed recently
>>> to make it work. It seems to be quite lucky that we have a working setup now :)
>>>
>>>> Nikolaus, Paul: Do you have plans to submit these?
>>>
>>> Yes, as soon as we are sure that it works (and when it doesn't).
>>>
>>> But thanks to your work it is now much easier to improve things, since we
>>> are no longer looking for a break-through but just have to avoid regressions.
>>>
>>>> If not, I'll be happy to get them out the door for review.
>>>
>>> Let it mature a little first and have it tested on more setups and rebased
>>> to mainline v5.9-rc2 :)
>
>
>> Am 24.08.2020 um 23:11 schrieb Paul Cercueil <paul@crapouillou.net>:
>>
>> DRM drivers follow their own schedule, you should rebase to drm-misc-next instead.
>>
>
> With the comment from Paul, I think it is best if you push them for review.
>
> My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have
> included only for making my Ethernet interface work for testing):
>
> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5
>
> Please take it, do the required squashes and rebasing and post them for discussion to the
> appropriate lists.
I hope you are well. Do you plan to do the squash and rebase and posts?
BR and thanks,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-09-10 7:53 ` H. Nikolaus Schaller
@ 2020-09-10 12:14 ` Ezequiel Garcia
2020-09-10 13:48 ` H. Nikolaus Schaller
0 siblings, 1 reply; 26+ messages in thread
From: Ezequiel Garcia @ 2020-09-10 12:14 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
On Thu, 10 Sep 2020 at 04:54, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Ezequiel,
>
> > Am 27.08.2020 um 09:21 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> > Hi Ezequiel,
> >
> >> Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
> >>
> >> On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >>>
> >>> Hi Ezequiel,
> >>
> >> The fix is just re-organizing the code a bit. Just pushed a possible
> >> fix for that (following the IPU handling by Paul Cercueil),
> >> please feel free to test this:
> >>
> >> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2
> >
> > Works well (after doing a minor fix to the CI20 defconfig)!
> >
> >>
> >> FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
> >> The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
> >> (which means dm9000 works). I'm testing with weston and modetest.
> >>
> >> Note that enabling DRM_INGENIC_IPU will make the driver
> >> fail to load, as the IPU is not optional (and not present on ci20.dts).
> >> A minor thing to fix.
> >>
> >> Cheers,
> >> Ezequiel
> >>
> >>> And it seems to differ significantly from what Paul has developed recently
> >>> to make it work. It seems to be quite lucky that we have a working setup now :)
> >>>
> >>>> Nikolaus, Paul: Do you have plans to submit these?
> >>>
> >>> Yes, as soon as we are sure that it works (and when it doesn't).
> >>>
> >>> But thanks to your work it is now much easier to improve things, since we
> >>> are no longer looking for a break-through but just have to avoid regressions.
> >>>
> >>>> If not, I'll be happy to get them out the door for review.
> >>>
> >>> Let it mature a little first and have it tested on more setups and rebased
> >>> to mainline v5.9-rc2 :)
> >
> >
> >> Am 24.08.2020 um 23:11 schrieb Paul Cercueil <paul@crapouillou.net>:
> >>
> >> DRM drivers follow their own schedule, you should rebase to drm-misc-next instead.
> >>
> >
> > With the comment from Paul, I think it is best if you push them for review.
> >
> > My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have
> > included only for making my Ethernet interface work for testing):
> >
> > https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5
> >
> > Please take it, do the required squashes and rebasing and post them for discussion to the
> > appropriate lists.
>
> I hope you are well. Do you plan to do the squash and rebase and posts?
>
Hi Nikolaus,
I wanted to use the component API for the the dw hdmi glue driver
but somehow it wasn't probing and I haven't had time to debug it. Using the
component API consistently would allow to do some cleanups IMHO.
Thanks,
Ezequiel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* 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-09-10 12:14 ` Ezequiel Garcia
@ 2020-09-10 13:48 ` H. Nikolaus Schaller
0 siblings, 0 replies; 26+ messages in thread
From: H. Nikolaus Schaller @ 2020-09-10 13:48 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Jernej Skrabec, Paul Boddie, Jonas Karlman, Neil Armstrong,
dri-devel, Paul Cercueil, MIPS Creator CI20 Development
Hi Ezequiel,
> Am 10.09.2020 um 14:14 schrieb Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>:
>>> With the comment from Paul, I think it is best if you push them for review.
>>>
>>> My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have
>>> included only for making my Ethernet interface work for testing):
>>>
>>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5
>>>
>>> Please take it, do the required squashes and rebasing and post them for discussion to the
>>> appropriate lists.
>>
>> I hope you are well. Do you plan to do the squash and rebase and posts?
>>
>
> Hi Nikolaus,
>
> I wanted to use the component API for the the dw hdmi glue driver
> but somehow it wasn't probing and I haven't had time to debug it. Using the
> component API consistently would allow to do some cleanups IMHO.
Yes, that would be a good move as long as it is not a dead-end-street :)
If you have something to test please let us know.
BR,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2020-09-11 9:50 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-12 19:37 Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 Paul Boddie
2020-05-13 7:37 ` drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780) Neil Armstrong
2020-05-13 21:18 ` Paul Boddie
2020-05-14 22:04 ` Paul Boddie
2020-05-15 7:43 ` Neil Armstrong
2020-05-16 17:01 ` Paul Boddie
2020-07-05 23:57 ` Paul Boddie
2020-07-06 12:12 ` Neil Armstrong
2020-07-06 20:55 ` Paul Boddie
2020-08-19 10:21 ` Ezequiel Garcia
2020-08-19 16:22 ` Paul Boddie
2020-08-19 18:49 ` H. Nikolaus Schaller
2020-08-19 22:26 ` Ezequiel Garcia
2020-08-20 8:19 ` H. Nikolaus Schaller
2020-08-20 22:49 ` Paul Boddie
2020-08-21 13:32 ` Ezequiel Garcia
2020-08-21 22:11 ` Paul Boddie
2020-08-21 22:24 ` Paul Cercueil
2020-08-24 13:46 ` Ezequiel Garcia
2020-08-24 16:04 ` H. Nikolaus Schaller
2020-08-24 17:38 ` Ezequiel Garcia
2020-08-24 21:11 ` Paul Cercueil
2020-08-27 7:21 ` H. Nikolaus Schaller
2020-09-10 7:53 ` H. Nikolaus Schaller
2020-09-10 12:14 ` Ezequiel Garcia
2020-09-10 13:48 ` H. Nikolaus Schaller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).