[Letux-kernel] jz4780 CI20 v5.8 (was jz4730)
H. Nikolaus Schaller
hns at goldelico.com
Sun Jul 5 19:39:52 CEST 2020
> Am 05.07.2020 um 19:35 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> Hi Paul,
>> Am 05.07.2020 um 19:11 schrieb Paul Boddie <paul at boddie.org.uk>:
>> 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
>> I might have a look at the relevant code, but it would involve some study
> I think I have it here:
> It looks as if I have applied some compile issue fix. But that may be wrong.
> Other ideas: the hight resolution timer may be broken.
> There may also be a general MIPS bug wich has been fixed/accepted for mips-fixes:
> "[PATCH] MIPS: Do not use smp_processor_id() in preemptible code"
Linus has just merged it some minutes ago:
So we will have it in letux-5.8-rc4 tomorrow.
> BTW: interesting is also a proposed "[PATCH] MIPS: CI20: DTS: Correcting IW8103 Wifi binding"
>>>> 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]
>>>> 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.
> Yes, could be a simple free before use issue.
>>> 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
> Great. I think it looks as if you are registered at https://projects.goldelico.com/p/gta04-kernel/
> as member of the "Happy Crew". So you should already be able to push (if you
> have ssh://email@example.com/letux-kernel.git as your remote).
> Please choose a unique branch name like "paulb-jz4780-hdmi" or similar.
>>>> 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
>> 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.
> Should already be possible - unless something is broken (e.g. ssh key lost).
> If not, please try to debug ssh with GIT_TRACE_true as described here:
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
More information about the Letux-kernel