On Tue, Jun 18, 2019 at 8:39 PM Fabio Estevam <festevam@gmail.com> wrote:

On Tue, Jun 18, 2019 at 11:46 AM Pintu Agarwal <pintu.ping@gmail.com> wrote:

...

Thank you so much for your reply. Yes, I already checked the latest mainline kernel changes until 5.2-**. I see that there are many cleanup related changes, but still I see that suspend/resume functions are missing in dw_hdmi-imx driver.

Please see this recently submitted patch: https://lore.kernel.org/patchwork/patch/1084057/

Okay. Thank you for this reference. This can be definitely helpful. But a quick look may be feel, this is slightly different. Anyways, I will have a deeper look.

...

So, I am trying to implement myself. Also, I see that suspend/resume is missing even in : drivers/gpu/drm/imx/ipuv3-crtc.c I am trying this also (not sure if we need this as well).

Can you point out some specific patches which can be helpful ?

Currently, what I observed is that hdmi bind() functions are not getting called. Not sure who is responsible for triggering this bind function. Or, irq remains disabled after resume, and we need to enable it back again (but how ?) Or, we may need to enable vblank events and thus irqs can be enabled.

So, I am exploring many possibilities. If you have any suggestions please let me know.

The suggestion I have is to try to use latest mainline kernel. If you see any issues with it, please report.

The combination you mentioned in a prior thread (kernel 3.10 + backported drm patches 4.9) is not really something the community can help you.

You can think that the version I am using right now is almost 4.9 itself. Upgrading again to higher kernel version is again difficult, also customer does not want it. BTW, I am not talking about runtime suspend/resume. I know it works normally. I just need some approach and pointers. Like someone said rightly, I may need to re-implement bind() function again in resume path. I already tried doing hdmi_power_on/off and with that I could invoke hdmi_setup() function, but the system hang after that. Another approach I tried is, installing hdmi {dw-hdmi.ko, dw_hdmi-imx.ko} as a module, just after the resume. With this also system hangs during installation of dw_hdmi-imx.ko at below location: imx_drm_driver_load(..) | |--> component_bind_all(...) | |-> component_bind(ipu) | | ipu_drm_bind(..) | |-> ipu_crtc_init(..) | |-> ipu_plane_irq(..) | | ----> << __HANGS HERE__ >> | |-> devm_request_irq(ipu_irq_handler) So, ipu_drm_bind() never returns, and hangs. ---------- So, my question is, which approach is better (as a first trial): 1) Installing hdmi as a module, after resume ? 2) Or, implementing the suspend/resume itself ?

On Wed, Jun 19, 2019 at 7:14 PM Fabio Estevam <festevam@gmail.com> wrote:

On Wed, Jun 19, 2019 at 10:33 AM Pintu Agarwal <pintu.ping@gmail.com> wrote:

...

You can think that the version I am using right now is almost 4.9 itself.

"almost 4.9" does not help, sorry.

...

Upgrading again to higher kernel version is again difficult, also customer does not want it.

dw-hdmi is well supported on i.MX6 with mainline, so you could simply try that.

Try booting 5.1.11 on your custom board with a very minimal dts with HDMI support.

Okay. I will surely try it on another IMX6 fresh board. With 5.1.11 you mean the kernel from mainline kernel.org Or, is there a separate kernel repo for imx6. If yes, please let me know.

Then you can test suspend/resume and see if HDMI hangs or not.

By this suspend/resume, you mean "suspend-to-ram" or "suspend-to-disk" ?

...

Another approach I tried is, installing hdmi {dw-hdmi.ko, dw_hdmi-imx.ko} as a module, just after the resume. With this also system hangs during installation of dw_hdmi-imx.ko at below location:

imx_drm_driver_load(..) | |--> component_bind_all(...) | |-> component_bind(ipu) | | ipu_drm_bind(..) | |-> ipu_crtc_init(..) | |-> ipu_plane_irq(..) | | ----> << __HANGS HERE__ >>

I am not able to reproduce this hang. As I mentioned yesterday suspend/resume is working just fine.

This scenario is not with suspend/resume. This hang is, when we make hdmi as a loadable module (.ko) and trying to install it after resume. In this case, suspend/resume will not come into picture. Not sure why it still hangs. Do you have any clue for this scenario?

On Wed, Jun 19, 2019 at 8:41 PM Fabio Estevam <festevam@gmail.com> wrote:

...

...

Then you can test suspend/resume and see if HDMI hangs or not.

By this suspend/resume, you mean "suspend-to-ram" or "suspend-to-disk" ?

I tested with "echo mem > /sys/power/state"

hmm. That's what I said. This is runtime suspend, and it works for me also. I am talking about hibernation: # echo disk > /sys/power/state (with some customization)

...

This scenario is not with suspend/resume. This hang is, when we make hdmi as a loadable module (.ko) and trying to install it after resume. In this case, suspend/resume will not come into picture. Not sure why it still hangs. Do you have any clue for this scenario?

I haven't tried this one.

Please test it with 5.1.11 and if it fails, please report.

Okay will check this on latest kernel. Thanks.

On Fri, Jun 21, 2019 at 12:13 PM Pintu Agarwal <pintu.ping@gmail.com> wrote:

Okay there is some update on the 2nd part. Now I am able to successfully install all imx modules after the resume (no hang). But, I got some errors after install finish: [drm] disabling vblank on crtc 1 [IMX]: imx_drm_disable_vblank - called [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out

Also I am able to start the weston successfully. But I see LCD/HDMI display is not working (only some backlight is visible).

And, I noticed, weston also reports the following errors: imx-ipuv3 2400000.ipu: DC stop timeout after 50 ms [IMX]: drm_crtc_vblank_off - called [IMX]: imx_drm_disable_vblank - called INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=6002 jiffies, g=289, c=288, q=8) Task dump for CPU 1: weston R running 0 306 1 0x00000000 [<c05282d8>] (__schedule) from [<00080193>] (0x80193)

Do you have any clue about these errors ?

Which kernel version is this?

On Sat, Jun 22, 2019 at 1:43 PM Pintu Agarwal <pintu.ping@gmail.com> wrote:

On Fri, Jun 21, 2019 at 9:09 PM Fabio Estevam <festevam@gmail.com> wrote:

...

On Fri, Jun 21, 2019 at 12:13 PM Pintu Agarwal <pintu.ping@gmail.com> wrote:

...

Okay there is some update on the 2nd part. Now I am able to successfully install all imx modules after the resume (no hang). But, I got some errors after install finish: [drm] disabling vblank on crtc 1 [IMX]: imx_drm_disable_vblank - called [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out

Also I am able to start the weston successfully. But I see LCD/HDMI display is not working (only some backlight is visible).

And, I noticed, weston also reports the following errors: imx-ipuv3 2400000.ipu: DC stop timeout after 50 ms [IMX]: drm_crtc_vblank_off - called [IMX]: imx_drm_disable_vblank - called INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=6002 jiffies, g=289, c=288, q=8) Task dump for CPU 1: weston R running 0 306 1 0x00000000 [<c05282d8>] (__schedule) from [<00080193>] (0x80193)

Do you have any clue about these errors ?

Which kernel version is this?

Now, I am using Kernel 4.9 (custom) with some internal changes. After the hibernate-resume, I am trying to install the modules in following order: insmod imxdrm.ko insmod parallel-display.ko insmod dw-hdmi.ko insmod dw_hdmi-imx.ko insmod imx-ipu-v3.ko insmod imx-ipuv3-crtc.ko insmod imx-ldb.ko I noticed that if I don't install the "crtc" or "ldb" module at last, then system will hang. Otherwise, the modules are installed successfully. But, I get following errors: [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out But, hdmi could be detected from the logs: dwhdmi-imx 120000.hdmi: Detected HDMI controller 0x13:0x1a:0xa0:0xc1 However, after I start weston, there is no display in LCD and HDMI. I can only see the backlight. One more thing, I observed that, there was a huge delay after component_bind_all(): [IMX]: imx_drm_driver_load - component_bind_all - DONE <-------------- delay ---------------> Then we get flip_done timeout. So, my question is: 1) If we have to test hibernation on iMX6/7 then which is the suitable way? 2) Is it possible to support this feature by performing module installation after resume? 3) If yes, then which modules should be chosen as loadable, and which can be in-built? (So, we don't have to implement suspend/resume for each module) 4) I also compared clock_summary in normal boot and after resume (with module installed). I found below difference in clock frequency (pll5, pll4) Example: - pll5 1 1 1188000007 + pll5 1 1 1040000015 what does this indicates? Is there any issue?

On Wed, Jun 19, 2019 at 07:03:39PM +0530, Pintu Agarwal wrote:

You can think that the version I am using right now is almost 4.9 itself. Upgrading again to higher kernel version is again difficult, also customer does not want it.

They don't want a secure and supported kernel over the lifetime of their device? That sounds really odd. Never create a new device using the 4.9.y kernel tree unless you have someone else doing the support for it (i.e. a SoC vendor that you are paying support from). good luck! greg k-h

On Wed, 19 Jun 2019 20:47:34 +0530, Pintu Agarwal said:

No I mean to say, there are lots of features and customization already done on this version and stabilized. Upgrading again may require months of effort.

This is what happens when you don't upstream your local changes. And no, saying "But we're a small company and nobody cares" isn't an excuse - Linux carried the entire Voyager architecture around for several years for 2 machines. Not two models, 2 physical machines, the last 2 operational systems of the product line. (Not the Xubuntu-based Voyage distribution either - the Voyager was a mid-80s SMP fault-tolerant system from NCR with up to 32 486/586 cores and 4G of memory, which was a honking big system for the day...) https://kernel.googlesource.com/pub/scm/linux/kernel/git/rzhang/linux/+/v2.6... The architecture was finally dropped in 2009 when enough hardware failures had happened that James Bottomley was unable to create a bootable system from the parts from both... So if your production run is several thousand systems, that's *plenty* big enough for patches and drivers (especially since drivers for hardware you included in your several-thousand system run are also likely applicable to a half dozen other vendors who made several thousand systems using the same chipset....