[IMX] [DRM]: suspend/resume support

[IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

Hi All,

I am trying to implement suspend/resume functionality to to imx-hdmi driver:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/imx/dw_hdmi-imx.c?h=v4.9.181

So, I need some help about this.
I logged the request in imx community, but it seems they are not responding.
Firstly I expect nxp community members to support (if anybody here).
Otherwise, I guess, people who are experts here and have prior
experience in implementing suspend/resume for their drivers, should be
able to give me some guidance.

Currently, I am trying to understand what needs to be taken care
during suspend/resume.
With some reference, I figured out that hdmi power off/on needs to be
done during suspend/resume.
But after resume, system is hanging.
It seems like vblank events are not getting triggered after the resume.
May be irq remains disabled after resume, I need to figure out some
way to enable the all the irqs again.

Even if I try to install hdmi driver as a dynamic loadable module,
still I get the same issue.

So, I wonder, what is the right way to handle suspend/resume for any driver.
Some clue/reference should help me to keep going...


Regards,
Pintu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Oliver Neukum]

Am Montag, den 17.06.2019, 19:19 +0530 schrieb Pintu Agarwal:

> Currently, I am trying to understand what needs to be taken care
> during suspend/resume.

You need to take care of

* wakeup sources
* not requiring services of devices higher up in the tree.

> With some reference, I figured out that hdmi power off/on needs to be
> done during suspend/resume.

That would make sense.

First of all you need to understand that the generic model is, well,
generic. Now this may look like a tautology, so let me explain.
A generic model cannot tell you how to save power on a specific
hardware. It exists to model dependencies among subsystems and
to help you.

The suspend() call is a notification which tells you that the rest
of the system will not require your services until resume() is
called().
That means that after resume() your driver must be functional again.

And it means that between suspend() and resume() you cannot touch
your device because what is above you in the tree need not be
functional.

> But after resume, system is hanging.
> It seems like vblank events are not getting triggered after the resume.
> May be irq remains disabled after resume, I need to figure out some
> way to enable the all the irqs again.

In your case it looks like parts of dw_hdmi_imx_bind() need to be
redone in resume().

	HTH
		Oliver


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Fabio Estevam]

Hi Pintu,

On Mon, Jun 17, 2019 at 10:50 AM Pintu Agarwal <pintu.ping@gmail.com> wrote:
>
> Hi All,
>
> I am trying to implement suspend/resume functionality to to imx-hdmi driver:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/imx/dw_hdmi-imx.c?h=v4.9.181

Please test a recent kernel, such as 5.1.11. I recall that last time
you reported an issue with the dw hdmi you were running kernel 3.10
with backported patches from 4.9.

Just tried suspend/resume on a imx6q board and HDMI behaves correctly.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

On Tue, Jun 18, 2019 at 7:32 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Pintu,
>
> On Mon, Jun 17, 2019 at 10:50 AM Pintu Agarwal <pintu.ping@gmail.com> wrote:
> >
> > Hi All,
> >
> > I am trying to implement suspend/resume functionality to to imx-hdmi driver:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/imx/dw_hdmi-imx.c?h=v4.9.181
>
> Please test a recent kernel, such as 5.1.11. I recall that last time
> you reported an issue with the dw hdmi you were running kernel 3.10
> with backported patches from 4.9.
>
> Just tried suspend/resume on a imx6q board and HDMI behaves correctly.

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.
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.

Thanks,
Pintu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Fabio Estevam]

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/

> 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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

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 ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Fabio Estevam]

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.

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

> 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.

We would be glad to help fixing the hang if you could reproduce it
with a mainline kernel.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

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?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Fabio Estevam]

On Wed, Jun 19, 2019 at 12:05 PM Pintu Agarwal <pintu.ping@gmail.com> wrote:

> 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.

5.1.11 from kernel.org

> > 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"

> 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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

On Wed, Jun 19, 2019 at 8:59 PM Pintu Agarwal <pintu.ping@gmail.com> wrote:

> > > 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.
> >

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 ?

Thanks,
Pintu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Fabio Estevam]

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?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

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?

Please let me know in which version this issue is fixed.
I will try that.
I think I saw some commit that mentions about it, but I forgot.
Anyways, I am checking again.
Thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

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?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: help in analyzing clock_summary rate difference

[Pintu Agarwal]

Hi,

I need one general help in analyzing difference in clock_summary rate
before and after the system resume.

I am using custom IMX7 board with 4.9 Kernel.
With this I am trying to support some functionality during suspend/resume.
I am trying to analyze clk_summary from:
# cat /sys/kernel/debug/clk/clk_summary

I observed that there are difference in "clock rate" after system
resume and module install. However the enable/prepare count remains
the same.

Since I am not much familiar with clock framework, I am looking for
some help to analyze this issue. It's an internal issue.

May be someone which is familiar with clock analysis or fixed the
similar issue earlier can give me some guidance.
What does the difference in clock rate indicates?
What analysis can be done to narrow down the root cause?
Any example of reference could be helpful to understand.


Thank You!
Regards,
Pintu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Greg KH]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

On Wed, Jun 19, 2019 at 8:34 PM Greg KH <greg@kroah.com> wrote:
>
> 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.
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.
Of course upgrading is planned for later products.

> 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).
>
Actually, this is not a new device. Its an older device itself.
This is an experimental activity.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1346 bytes --]

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.20-rc1/Documentation/voyager.txt

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....

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [IMX] [DRM]: suspend/resume support

[Pintu Agarwal]

On Wed, Jun 19, 2019 at 9:56 PM Valdis Klētnieks
<valdis.kletnieks@vt.edu> wrote:
>
> 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.20-rc1/Documentation/voyager.txt
>
> 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....

Yes, I agree, but unfortunately I don't have any control.
I normally keep finding things, which seems interesting for me and
propose for upstream (even if it is very small).
And, I completely agree that system should be designed such a way that
it can be easily up-gradable.
But, as I said, its not fully in our hand :(

Also, I think this case is slightly different.
Here, even if I try with latest kernel, there is no use, since
hibernation feature is not fully support for IMX.
And I think that is already known.
I came here looking for some pointers and help and get some clue to
proceed further.
If I succeed in making it I will definitely like to contribute upstream :)

Thank You!

Regards,
Pintu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel