[Letux-kernel] jz4780 CI20 v5.8 (was jz4730)

Paul Boddie paul at boddie.org.uk
Sun Jul 5 19:11:07 CEST 2020

On Sunday, 5 July 2020 17:41:53 CEST H. Nikolaus Schaller wrote:
> > Am 05.07.2020 um 16:17 schrieb Paul Boddie <paul at boddie.org.uk>:
> > 
> > Replying to this again specifically, I found that the DRM/HDMI patches
> > based on letux-5.8-rc3 will not yield a bootable kernel, but by disabling
> > SMP in the configuration it would boot.
> I already had this idea, but haven't tried.
> So the SMP patches are no longer compatible. I have to check if the original
> author has submitted something new or if we can backport something from
> linux-next (if it is there).
> Otherwise we should ask the LKML about the status of merging JZ4780 SMP
> support.

I might have a look at the relevant code, but it would involve some study 

> > So that is probably a significant factor.
> > 
> > Unfortunately, I did not manage to get a usable signal via HDMI ("Input
> > not supported"), but the DRM driver is operational.
> So we are not worse than before :)

Not really, no. All I can say is that with the extra setting of the bus format 
in the HDMI driver, vblank interrupts are produced and serviced by the DRM 

> > One strange complication I now
> > get when I unplug the HDMI cable (to get my monitor to switch back to the
> > VGA input, since the menu won't respond) is this kernel panic:
> > 
> > CPU 0 Unable to handle kernel paging request at virtual address 00000030,
> > epc == c025ee10, ra == c022fc08
> > 
> > ingenic_drm_crtc_atomic_flush+0x8c/0x3ac [ingenic_drm]
> > drm_atomic_helper_commit_planes+0x254/0x25c [drm_kms_helper]
> > drm_atomic_helper_commit_tail+0x44/0xb0 [drm_kms_helper]
> > commit_tail+0x1f0/0x1f8 [drm_kms_helper]
> > drm_atomic_helper_commit+0x17c/0x184 [drm_kms_helper]
> > drm_client_modeset_commit_atomic+0xdc/0x2a8 [drm]
> > drm_client_modeset_commit_locked+0x6c/0x1b8 [drm]
> > drm_client_modeset_commit+0x44/0x74 [drm]
> > __drm_fb_helper_restore_fbdev_mode_unlocked+0x74/0xd8 [drm_kms_helper]
> > drm_fb_helper_set_par+0x74/0x84 [drm_kms_helper]
> > drm_fb_helper_hotplug_event+0x170/0x190 [drm_kms_helper]
> > drm_kms_helper_hotplug_event+0x34/0x50 [drm_kms_helper]
> > drm_helper_hpd_irq_event+0xcc/0x1a0 [drm_kms_helper]
> > dw_hdmi_irq+0x12c/0x178 [dw_hdmi]
> > irq_thread_fn+0x2c/0x6c
> > irq_thread+0xe4/0x204
> > kthread+0x148/0x150
> > ret_from_kernel_thread+0x14/0x1c
> > 
> > So, upon receiving the hotplug event (in dw_hdmi_irq), the attempt to
> > configure the LCD controller fails (in ingenic_drm_crtc_atomic_flush) due
> > to an inappropriate access.
> Ok, that should be possible to identify. Maybe an uninitialized or
> overwritten variable.

It happens only when unplugging, in fact. So, maybe some state is thrown away 
and then the DRM system tries to update the missing state.

> Do you have your code in some git repo?

I have a clone of the letux-kernel repository with my code on a branch from 
origin/letux-5.8-rc3. So if I might push that somewhere, you would get to see 

> > One positive observation is that shutdown appears to power the device off.
> Yes, we made this working a while ago. Only reboot failed if I remember
> correctly. Or was it vice versa?

We struggled with power off but it seems to be happy now. The RTC is not set, 
but maybe the driver for the PCF8563 isn't getting activated correctly.

> > One negative observation is that networking doesn't seem to work any more,
> > although this might be a user space incompatibility.
> Yes, I have seen that as well. In general the CI20 is quite broken by
> v5.8-rc...

Maybe there is a simple remedy, but again, I'd need to study the situation 

> And I am still hunting upstream induced display problems on several
> devices. The first I fixed was the Letux 3704. Next I fixed the PinePhone.
> And the Pyra omapdrm doesn't work since v5.7-rc1. I already found one
> issue coming from upstream.
> So the CI20 is still waiting in the to-be-serviced queue...

Well, I thought I'd keep you updated. If you enable pushing to the letux-
kernel repository or have another suggestion, I can share my patches without 
problems applying them.


More information about the Letux-kernel mailing list