Searching for tester of Linux Kernel drivers

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

Previous topic - Next topic

swahren

Hi Jörg,

yes i've still plans to work on this.

Any problems if i rebase the repo to 4.5 instead of 4.4?

Stefan

joerg.krause

#31
Quoteyes i've still plans to work on this.

That's really good news!

QuoteAny problems if i rebase the repo to 4.5 instead of 4.4?

4.4 will be the next LTS kernel, so I would vote for 4.4. Furthermore, I use 4.4 for a custom i.MX28 board. Nevertheless, if you prefer 4.5, I will backport the patchset.

Btw, which is the exact git rebase command you use? I tried, but did succeeded.

Which branch should I use for testing (I suppose dcdc-clk, right)? And how do the patches you sent to the Linux mailing list relate to your repo?

Jörg

swahren

Hi Jörg,

first of all i didn't get your email to the old V2 patch series, but the mail to my company account. So please stop cross posting.

I didn't know the fact about the next LTS, but i still need to use the latest kernel in order to avoid surprises on preparing V3 of the patch series. There shouldn't be much interfaces changes so i hope backporting is trivial.

To be honest i didn't really rebase the linux-mxs-power repo. Yes the dcdc-clk was the latest branch, it contains the following features:
* mxs_power (incl. debugfs)
* mxs-regulator-ldo
* mxs-regulator-dcdc
* mxs_pswitch
* opps for mx23 and mx28

As you can see the posted patch series is only a minor subset. I need this messy repo because of the debug information and prepared test environment. But before sending a V3 of my patch series i will create a clean branch.

Here is the TODO list which comes to my mind:
- update to Linux 4.5
- fixup rest issues from V2
- replace SYSCON with regmap for power registers

What features do you need?

What is your test environment?

Stefan

joerg.krause

#33
Hi Stefan,

sorry for cross-posting!

I'm fine with testing with 4.5. If backporting is trivial, I'd like to use 4.4.

If you don't rebase, how do you update to upstream Linux? I'm just curious in case I want to update to a specific branch or tag. For now, I copied the files for power and regulator into my own (clean) repo of the 4.4 kernel. I had to fix some compiler issues about mxs_power.c. After a first test run, I saw mxs_power with dmesg:

[    2.158610] mxs_power 80044000.power: 5V = connected
[    2.172647] mxs_regulator_ldo 80044000.power:regulator@1: vddd: Current power source (3)
[    2.186618] mxs_regulator_ldo 80044000.power:regulator@2: vdda: Current power source (3)
[    2.200394] mxs_regulator_ldo 80044000.power:regulator@3: vddio: Current power source (3)



I'd like to use the low-power modes and CPU frequency scaling.

My test environment is a custom i.MX28 board powered via 5V USB.

Jörg Krause

EDIT: Add a gist https://gist.github.com/joerg-krause/11fc3fcf7a9cdc1ae661 to the patches I fetched from the linux-mxs-power repo https://github.com/lategoodbye/linux-mxs-power/tree/dcdc-clk from the dcdc-clk branch...

EDIT: Add the config fragment:

CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_CPUFREQ_DT=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
CONFIG_POWER_SUPPLY=y
CONFIG_MXS_POWER=y
CONFIG_MFD_SYSCON=y
CONFIG_REGULATOR_MXS=y
CONFIG_STAGING=y
CONFIG_MXS_LRADC=y
CONFIG_IIO=y

swahren

Hi Jörg,

you missed some changes like the board init code. Please give me some time for rebasing, so you don't need to do it for your own.

Stefan

joerg.krause

Okay, just tell me when you're ready and which branch I shall use.

I had a look at the standby mode implementation from the legacy Linux kernel. I would like to start to port this feature based on your power and regulator implementation.

Jörg

swahren

Hi Jörg,

please take a look at https://github.com/lategoodbye/linux-mxs-power/commits/rebase-4.5

I had no problems with apply the changes, so there shouldn't be any problems with 4.4.

Run the following command on my branch and you will have the necessary patches:

git format-patch -13

Btw the repository from Digi https://github.com/digidotcom/yocto-linux/tree/v3.10.y/master has a Kernel 3.10 (incl. devicetree support) which already has a ported standby mode. Porting this to 4.4 should be much easier.

joerg.krause

#37
Hi Stefan,

many thanks for the link to digidotcom repository. This looks promising!

I applied your latest patches form the rebase-4.5 branch without any problems to my 4.4 branch. There is at least one issue with the ondemand governor using a faulty frequency of 240000. Selecting the performance governor afterwards does not increase the frequency to its max value, whereas selecting powersave does decrease the frequency to its min value:


# cd /sys/devices/system/cpu/cpu0/cpufreq/
# cat scaling_available_frequencies
64000 261818 360000 392727 454736
# cat scaling_available_governors
conservative ondemand userspace powersave performance
# cat scaling_governor
performance
# echo ondemand > scaling_governor
# cat cpuinfo_cur_freq
240000
# echo performance > scaling_governor
# cat cpuinfo_cur_freq
240000
# echo powersave > scaling_governor
# cat cpuinfo_cur_freq
64000
# echo performance > scaling_governor
# cat cpuinfo_cur_freq
240000


EDIT: scaling_cur_freq does show a different frequency value for ondemand
# cat scaling_cur_freq
64000
# cat scaling_cur_freq
454736

swahren

Hi Jörg,

thanks for testing. I think i've fixed the issue in the rebase branch.

But at the end the ondemand governor isn't suitable for MXS platform because of it's fast dynamic transitions. The conservative governor should be the better choice.

Regards
Stefan

joerg.krause

Hi Stefan,

thanks for the update and the link! It looks very promising..

I tested frequency scaling using the conservative governor today. However, I am still getting:


# echo conservative > scaling_governor
# echo performance > scaling_governor
# cat cpuinfo_cur_freq
240000


Even if I apply the conservative governor and immediately afterwards the performance governor my audio streaming with shairport-sync is not able to output some audio frames anymore.

swahren

Hi Jörg,

thank you and sorry for this. I'm now able to reproduce. The clock tree get messed up by the governor :-(


    pll0                                  5            5   480000000          0 0
       ref_cpu                            1            1   480000000          0 0
          cpu_pll                         1            1   240000000          0 0
             cpu                          2            2   240000000          0 0
                hbus                      4            4    80000000          0 0
                   fec                    2            2    80000000          0 0


Until now i tested only the userspace governor and it seems to take care of the opps.

Looks like i really need to port the existing mxs cpufreq driver and can't take the cpufreq-dt.

joerg.krause

Don't be! I'm glad you're working on this!

For now, I will try to get the standby mode to work...

swahren

And Now for Something Completely Different ...

I implemented suspend / resume support for mxs-lradc. Would be nice if someone with a touchscreen could test it.

joerg.krause

I ported the code for the standby mode from the digidotcom github repository ontop of Stefans linux-mxs-power tree: https://github.com/joerg-krause/linux-mxs-power/tree/standby.

Some notes:

  • I am not a kernel developer.
  • I use a custom i.MX28 board.
  • I use Linux kernel version 4.4.

Make sure you have set the following kernel options:

CONFIG_PM
CONFIG_SUSPEND
CONFIG_SRAM=y
CONFIG_POWER_SUPPLY=y
CONFIG_MXS_POWER=y
CONFIG_REGULATOR_MXS=y
CONFIG_STAGING=y
CONFIG_MXS_LRADC=y
CONFIG_IIO=y


Happy testing!

swahren

Hi Jörg,

thanks, but before i test your changes i've some questions:

1. Do you have plans to improve your changes and maybe submit to linux-arm-kernel?
2. How do you want comments about your changes (github, email, here)?
3. Could you please make your changes work on i.MX23 too since i.MX28 users should be a minority here?

Best regards
Stefan