Searching for tester of Linux Kernel drivers

Started by swahren, November 21, 2014, 07:49:39 PM

Previous topic - Next topic

swahren

And i must confess that i didn't test with IRQCHIP_SKIP_SET_WAKE flag. Since you describe a test scenario i should be able to test it and add a patch.

joerg.krause

I noticed another issue with the SAIF of the i.MX28. When the CPU goes into supsend mode, the MCLK and BCLK pins are going sometimes into a HIGH state and sometimes into a LOW state. Not sure what the expected behavior should be, so I started a question on the NXP community platform: https://community.nxp.com/message/818211

swahren

Unfortunately it seems that i toasted my Olinuxino Maxi, so i wasn't able to test my last change IRQCHIP_SKIP_SET_WAKE with i.MX23 and GPIO wake up. Did it work for you (already commited the change to my repo)?

It don't have access to a board with SAIF. Sorry for the naive question but what's the problem behind the random pin level in suspend?
Higher power consumption?
Are you able to verify that mxs_saif_trigger is called with SNDRV_PCM_TRIGGER_SUSPEND in case of suspend? In this case i would expect that both clocks are going to be disabled.

I think in case we need a proper solution the alsa mailing list and Fabio Estevam from NXP should be contacted.

Btw: You should mention in your question to NXP community that your using Mainline Linux or does the Vendor Kernel show the same behavior?

joerg.krause

QuoteUnfortunately it seems that i toasted my Olinuxino Maxi, so i wasn't able to test my last change IRQCHIP_SKIP_SET_WAKE with i.MX23 and GPIO wake up.

Oops! That's bad!

QuoteDid it work for you (already commited the change to my repo)?

Sorry, I didn't noticed. I'll check tomorrow.

QuoteIt don't have access to a board with SAIF. Sorry for the naive question but what's the problem behind the random pin level in suspend?
Higher power consumption?

Yes, the DAC has an auto power-down feature which is activated if the MCLK stays LOW.

QuoteAre you able to verify that mxs_saif_trigger is called with SNDRV_PCM_TRIGGER_SUSPEND in case of suspend? In this case i would expect that both clocks are going to be disabled.

No, I haven't done yet. However, I guess what's happening. The I2S clocks are continuous clocks and each clock keeps its level it has when the CPU goes into standby mode. But, that's only guessing...

QuoteI think in case we need a proper solution the alsa mailing list and Fabio Estevam from NXP should be contacted.

Good idea! I'll ask for help on the alsa mailing list tomorrow.

QuoteBtw: You should mention in your question to NXP community that your using Mainline Linux or does the Vendor Kernel show the same behavior?

I have only tested with mainline. I'll update my post, thanks!

joerg.krause

Hi Stefan,

I've tested your patch which sets IRQCHIP_SKIP_SET_WAKE and it works! There is no warning printed anymore. Thanks!

Jörg

swahren


joerg.krause

Hi Stefan,

NXP replied that Mainline Linux is not supported and I should use the BSP :-(

I did not had the time to prepare a board with the ancient BSP and I'll be in vacation the next two weeks, so nothing new here.

swahren

#67
I only want to mention that i rebased all off-tree changes on top a recent linux-next tree:

https://github.com/lategoodbye/linux-mxs-power/tree/rebase-4.12

Unfortunately i didn't had the time to test it with a Olimex iM233 board.

lambda

Hi Stefan,

you have there some very nice pieces of code. Any plans to
get them merged into mainline?

Thanks for your work!

swahren

This branch is "only" a rebase of my last attempt to get it mainline. It doesn't address all the comments for the version. Furthermore the syscon part must be replaced with a MXS specific mfd driver layer which handles the concurrent register access and the power interrupts.

Since i'm the bcm2835 co-maintainer now i've little time for this series. I would be happy in case someone could continue and finally merge it.