Olimex Support Forum

Hi,

i'm currently i try to provide cpufreq support for Freescale i.MX23/i.MX28 into Linux Mainline. Unfortunately i don't have a i.MX23 board to test my code. So i want ask if someone here wants to help me with testing my drivers on a i.MX23 board.

The development process has 3 stages:
1. Implementing mxs power subsystem driver
2. Implementing mxs regulator driver
3. Modify i.MX23/i.MX28 devicetree for cpufreq-dt support

Currently i'm in the first stage and send my first patch series to linux-pm mailing list:

http://marc.info/?l=linux-pm&m=141651453315940&w=2

I imagine that i provide a git repository including my patches and the tester needs to compile the kernel and build the rootfs by himself.

Anyone interested?

Stefan

Hi Stefan,

I'm very interested! (Particularly into everything that brings us closer to mainline support for battery charging.)

I did already build custom kernels/rootfs using OpenWrt in the past, so that part shouldn't be a problem.

Unfortunately I can't commit to any schedule right now.

Which testing would be necessary? It seems you are developening on an i.MX28 board and your code doesn't have any i.MX23 specific parts AFAICS, so why is testing on i.MX23 important?

Harald

Hi Harald,

in the end the mxs power driver could do the battery charging, but there are many code lines to write. Unfortunately i don't any hardware for this use case.

Sounds good and no problem about the time. I will setup the repository and will be happy to receive some feedback. I don't believe that development is finished this year.

I think it would be the best to write here some test scenarios down.

The testing on i.MX23 is important, because i only have a i.MX28. Currently the code isn't specific to i.MX23, but the regulator code is. Btw i don't believe in documents, only in tests.

Stefan

Hi Stefan!

Quote from: swahren on November 22, 2014, 01:03:53 AM
in the end the mxs power driver could do the battery charging, but there are many code lines to write. Unfortunately i don't any hardware for this use case.

I know. If nobody is faster I will write a driver for battery charging myself. Your work would make this easier for me.

Quote
Sounds good and no problem about the time. I will setup the repository and will be happy to receive some feedback. I don't believe that development is finished this year.

I think it would be the best to write here some test scenarios down.

Sounds good. Feel free to CC me on any mxs related mails to kernel mailinglists, etc.

Quote
The testing on i.MX23 is important, because i only have a i.MX28. Currently the code isn't specific to i.MX23, but the regulator code is. Btw i don't believe in documents, only in tests.

I see your point about documents, but to have the code accepted into mainline there is no need to test the unspecific parts on i.MX23. Of course testing is always a good thing.

Harald

Quote from: lambda on November 22, 2014, 03:40:55 PM

Quote from: swahren on November 22, 2014, 01:03:53 AM
in the end the mxs power driver could do the battery charging, but there are many code lines to write. Unfortunately i don't any hardware for this use case.

I know. If nobody is faster I will write a driver for battery charging myself. Your work would make this easier for me.

A lot of mxs user are interested in battery charging. That would be great.

Quote from: lambda on November 22, 2014, 03:40:55 PM
Sounds good. Feel free to CC me on any mxs related mails to kernel mailinglists, etc.

Sure, if you send me your mail address.

Btw i made a RFC for a mxs ocotp driver, may be you want to test it on i.MX23:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html

It wasn't accepted, but it would be good to know how it works on i.MX23.

Here is the test scenario for fsl_ocotp driver:

• apply the patch series (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html) against the last 3.17 or 3.18 Linux kernel
• configure FSL_OCOTP as kernel module ( Device drivers -> Misc devices -> Freescale MXS on-Chip OTP Memory support )
• build a bootable image (bootloader, kernel, devicetree blob, rootfs) as usual
• boot your system with the image
• check if the module is autoloaded
• if it's not loaded modprobe it
• go to directory /sys/devices/soc0/80000000.apb/80000000.apbh/8002c000.ocotp/fuses
• read them out and store them in text file
• unload the module and load the module again
• boot your system into USB recovery mode (special USB A-A cable required)
• start your common OTP tool like bitburner.exe from Freescale
• compare the register and read out values with bitburner

Warning: Don't change any OTP bits with bitburner!

I can and will* setup 2 ( two ) iMX233-OLinuXino boards for You with LiPo batteries and SSH root** access through a public ip and sub-domains to my personal domain.

* - it can happen this weekend, but ONLY if you are serious and will use them ( 10 minutes a week is a use ;-) so no pressure ). Also I can help you with development and testing as I myself am an Embedded Developer and recently + currently working on Kernel Development for Embedded Devices :-) Also our work (me and my colleagues) is pushed to mainline at final stage so could provide some support there too, cause I personally don't have yet direct experience with pushing to mainline ;-) But people around me do and they are always open for talk :-)

** - non-root user login, then sudo or su, key authentication - NOT (ONLY) WITH PASSWORD

The two boards are: MAXI and NANO. Also if you ask, I'm sure Olimex will send you one or two, or even more. They support Developers who contribute to the Open Source Community and/or their Products, which is awesome of their side. Really great attitude.

ps: I'm From EU/BG/SF , if in the region we can meet for fast and more effective communication.

Will check the forum regularly this week

Hi scout_3pm,

thanks for the offer about the iMX233 boards, but i'm not familiar with the OLinuXino hardware including the LiPo batteries.

I'm searching for people, who wants to test with their own hardware. I develop in my spare time for i.MX28 and i don't have the time for another platform.

I will setup the repository and post the test scenario here.

Thanks

Stefan

1
I.e You don't look for Hardware, you look for testers ?

2
Testers with their own hardware OR only testers ?

3
Is this for a commercial project doing it open source ?

You are not very responsive to what i wrote so i will suppose you have a busy work week.

Quote from: scout_3pm on November 27, 2014, 10:28:44 PM
1
I.e You don't look for Hardware, you look for testers ?

Yes

Quote from: scout_3pm on November 27, 2014, 10:28:44 PM
2
Testers with their own hardware OR only testers ?

Testers with a i.MX233

Quote from: scout_3pm on November 27, 2014, 10:28:44 PM
3
Is this for a commercial project doing it open source ?

My intension is to push the driver into Linux Kernel mainline. It's not a commercial project.

Quote from: scout_3pm on November 27, 2014, 10:28:44 PM
You are not very responsive to what i wrote so i will suppose you have a busy work week.

Yes

OK. From your answer turns out my offer for support is not applicable so - Good Luck.
I'm not interested in only testing, but develop and design, which incl testing, but that's different.

Quote from: scout_3pm on November 28, 2014, 01:35:15 AM
OK. From your answer turns out my offer for support is not applicable so - Good Luck.
I'm not interested in only testing, but develop and design, which incl testing, but that's different.

I know testing isn't fun. But for developing the relevant mailing list is a better place.

Push it to staging, NOT mainline; and it will be tested ;-) Good Luck :-)

Quote from: scout_3pm on November 29, 2014, 12:06:59 AM
Push it to staging, NOT mainline; and it will be tested ;-) Good Luck :-)

Thanks for the wishes, but staging isn't a good solution. I think the driver is clear enough. If the code isn't good i need to fix it and not dumping it in staging.

btw: mxs-lradc is in staging since 2012 and we don't know when it's leave.

I don't want to make a discussion about it or take of your time. But this driver is there for more than one reason ;-) (Also) Clear doesn't mean it's tested, ready or safe/secure to be used.

Okay, the repository (https://github.com/lategoodbye/linux-mxs-power) is ready now. It contains the patches for all 3 stages (mxs_power, mxs-regulator and cpufreq support). I modified mxs_defconfig to simplify kernel build and testing.

I want to clarify that the mxs_power driver doesn't support battery charging. The focus for the test is cpufreq-dt (formally know as cpufreq-cpu0) and it's dependencies.

First of all, i don't want to narrow down the test path. So please see the following scenario as a hint:

• checkout the repository with git ( https://github.com/lategoodbye/linux-mxs-power.git )
• config the kernel for your platform including mxs_power, mxs-regulator and cpufreq-dt
• build a bootable image (bootloader, kernel, devicetree blob, rootfs) as usual
• boot your system with the image
• check if mxs_power and mxs-regulator are loaded successfully
• check if sysfs interface of cpufreq is available ( /sys/devices/system/cpu/cpu0/cpufreq/ )
• play a little bit with it

Here is the list of the kernel config parameter, if you want to use your "old" config:

CONFIG_POWER_SUPPLY
CONFIG_MXS_POWER
CONFIG_REGULATOR_DEBUG
CONFIG_REGULATOR_MXS
CONFIG_CPU_FREQ
CONFIG_CPUFREQ_DT
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE
CONFIG_CPU_FREQ_GOV_PERFORMANCE
CONFIG_CPU_FREQ_GOV_POWERSAVE
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_CPU_FREQ_GOV_CONSERVATIVE


Good luck

Edit: For those of you how aren't familiar to cpufreq:


$ cd /sys/devices/system/cpu/cpu0/cpufreq
$ cat scaling_available_frequencies
# Set to 261 MHz speed
$ echo 261819 > scaling_setspeed
# Set to 392 MHz speed
$ echo 392728 > scaling_setspeed
# Set to 360 MHz speed
$ echo 360000 > scaling_setspeed
# Set to 454 MHz speed
$ echo 454737 > scaling_setspeed


cpufreq seems to work fine.
I changed the frequency to 266MHhz and the CPU performance dropped as expected.
I'll try to look at power consumption tomorrow.

What are the other things you suggest to check, if any?

By the way, do you have any plans to support suspend/resume on i.mx23/28 ?

Quote from: Evgeny Boger on December 03, 2014, 03:55:52 AM
cpufreq seems to work fine.
I changed the frequency to 266MHhz and the CPU performance dropped as expected.
I'll try to look at power consumption tomorrow.

Nice to hear. Could you please post the dmesg output?

Quote from: Evgeny Boger on December 03, 2014, 03:55:52 AM
What are the other things you suggest to check, if any?

The driver for the power subsystem supports a module parameter to set the DCDC source frequency in kHz. This is a feature to avoid interferences, but usually not needed.

You change the frequency to one of these values:
19200, 20000, 24000

by setting the the parameter in the kernel cmdline:
mxs_power.dcdc_pll=19200

Quote from: Evgeny Boger on December 03, 2014, 03:55:52 AM
By the way, do you have any plans to support suspend/resume on i.mx23/28 ?

Actually not. Those features are more complex.

dmesg output with mxs_power.dcdc_pll=19200 :

root@wirenboard:~# dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.18.0-rc6-imxv5-x0.1 (boger@boger-ThinkPad-Edge-E440) (gcc version 4.7.4 20130913 (release) [ARM/embedded-4_7-branch revision
202601] (GNU Tools for ARM Embedded Processors) ) #10 Tue Dec 2 23:57:44 MSK 2014
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine model: i.MX23 Olinuxino Low Cost Board
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 16384
[    0.000000] free_area_init_node: node 0, pgdat c0737d3c, node_mem_map c3f7c000
[    0.000000]   Normal zone: 128 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 16384 pages, LIFO batch:3
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: console=ttyAMA0,115200 mxs_power.dcdc_pll=19200 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc video=
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Memory: 49260K/65536K available (5008K kernel code, 300K rwdata, 1784K rodata, 292K init, 8201K bss, 16276K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xc4800000 - 0xff000000   ( 936 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc06aa460   (6794 kB)
[    0.000000]       .init : 0xc06ab000 - 0xc06f4000   ( 292 kB)
[    0.000000]       .data : 0xc06f4000 - 0xc073f040   ( 301 kB)
[    0.000000]        .bss : 0xc073f040 - 0xc0f41740   (8202 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836480000000ns
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.000000] ... MAX_LOCKDEP_CHAINS:      65536
[    0.000000] ... CHAINHASH_SIZE:          32768
[    0.000000]  memory used by lock dependency info: 5167 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.070000] Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
[    0.070000] pid_max: default: 32768 minimum: 301
[    0.070000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.070000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.070000] CPU: Testing write buffer coherency: ok
[    0.080000] Setting up static identity map for 0x404c16d0 - 0x404c1728
[    0.100000] devtmpfs: initialized
[    0.110000] pinctrl core: initialized pinctrl subsystem
[    0.120000] regulator-dummy: no parameters
[    0.150000] NET: Registered protocol family 16
[    0.160000] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.190000] gpiochip_add: registered GPIOs 0 to 31 on device: 80018000.pinctrl:gpio@0
[    0.200000] gpiochip_add: registered GPIOs 32 to 63 on device: 80018000.pinctrl:gpio@1
[    0.200000] gpiochip_add: registered GPIOs 64 to 95 on device: 80018000.pinctrl:gpio@2
[    0.240000] Serial: AMBA PL011 UART driver
[    0.240000] uart-pl011 80070000.serial: ttyAMA0 at MMIO 0x80070000 (irq = 17, base_baud = 0) is a PL011 rev2
[    0.440000] console [ttyAMA0] enabled
[    0.510000] mxs-dma 80004000.dma-apbh: initialized
[    0.530000] mxs-dma 80024000.dma-apbx: initialized
[    0.540000] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulators/regulator@0[0]' - status (0)
[    0.540000] usb0_vbus: 5000 mV
[    0.550000] usbcore: registered new interface driver usbfs
[    0.550000] usbcore: registered new interface driver hub
[    0.560000] usbcore: registered new device driver usb
[    0.570000] Advanced Linux Sound Architecture Driver Initialized.
[    0.590000] Switched to clocksource mxs_timer
[    0.600000] cfg80211: Calling CRDA to update world regulatory domain
[    1.140000] NET: Registered protocol family 2
[    1.150000] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    1.160000] TCP bind hash table entries: 1024 (order: 3, 36864 bytes)
[    1.170000] TCP: Hash tables configured (established 1024 bind 1024)
[    1.180000] TCP: reno registered
[    1.180000] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    1.190000] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    1.200000] NET: Registered protocol family 1
[    1.200000] NetWinder Floating Point Emulator V0.97 (double precision)
[    1.220000] futex hash table entries: 256 (order: 1, 11264 bytes)
[    1.350000] msgmni has been set to 96
[    1.370000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.370000] io scheduler noop registered (default)
[    1.390000] of_dma_request_slave_channel: dma-names property of node '/apb@80000000/apbx@80040000/serial@80070000' missing or empty
[    1.400000] uart-pl011 80070000.serial: no DMA platform data
[    1.410000] mxs-auart 8006c000.serial: ttyAPP0 at MMIO 0x8006c000 (irq = 147, base_baud = 1500000) is a 8006c000.serial
[    1.420000] mxs-auart 8006c000.serial: Found APPUART 3.0.0
[    1.440000] PPP generic driver version 2.4.2
[    1.450000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.460000] usbcore: registered new interface driver usbserial
[    1.470000] usbcore: registered new interface driver usbserial_generic
[    1.470000] usbserial: USB Serial support registered for generic
[    1.490000] ci_hdrc ci_hdrc.0: doesn't support gadget
[    1.500000] ci_hdrc ci_hdrc.0: EHCI Host Controller
[    1.510000] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[    1.530000] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[    1.530000] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.540000] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.550000] usb usb1: Product: EHCI Host Controller
[    1.550000] usb usb1: Manufacturer: Linux 3.18.0-rc6-imxv5-x0.1 ehci_hcd
[    1.560000] usb usb1: SerialNumber: ci_hdrc.0
[    1.580000] hub 1-0:1.0: USB hub found
[    1.580000] hub 1-0:1.0: 1 port detected
[    1.600000] mousedev: PS/2 mouse device common for all mice
[    1.620000] stmp3xxx-rtc 8005c000.rtc: rtc core: registered 8005c000.rtc as rtc0
[    1.630000] i2c /dev entries driver
[    1.640000] mxs_power 80044000.power: DCDC clock freq: 19200 kHz
[    1.650000] vddd: 1350 <--> 1550 mV at 1500 mV
[    1.650000] regulator regulator.2: vddd: Set LinReg offset below DCDC target
[    1.660000] vdda: 1725 <--> 1950 mV at 1800 mV
[    1.670000] regulator regulator.3: vdda: Set LinReg offset below DCDC target
[    1.680000] vddio: 80mV offset
[    1.690000] regulator regulator.4: vddio: Invalid power source config
[    1.700000] stmp3xxx_rtc_wdt stmp3xxx_rtc_wdt: initialized watchdog with heartbeat 19s
[    1.720000] 80010000.ssp supply vmmc not found, using dummy regulator
[    1.730000] mxs-mmc 80010000.ssp: GPIO lookup for consumer cd
[    1.730000] mxs-mmc 80010000.ssp: using device tree for GPIO lookup
[    1.730000] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/apb@80000000/apbh@80000000/ssp@80010000[0]'
[    1.730000] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/apb@80000000/apbh@80000000/ssp@80010000[0]'
[    1.730000] mxs-mmc 80010000.ssp: using lookup tables for GPIO lookup
[    1.730000] mxs-mmc 80010000.ssp: lookup for GPIO cd failed
[    1.730000] mxs-mmc 80010000.ssp: GPIO lookup for consumer wp
[    1.730000] mxs-mmc 80010000.ssp: using device tree for GPIO lookup
[    1.730000] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/apb@80000000/apbh@80000000/ssp@80010000[0]'
[    1.730000] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/apb@80000000/apbh@80000000/ssp@80010000[0]'
[    1.730000] mxs-mmc 80010000.ssp: using lookup tables for GPIO lookup
[    1.730000] mxs-mmc 80010000.ssp: lookup for GPIO wp failed
[    1.770000] mxs-mmc 80010000.ssp: initialized
[    1.770000] of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/user[0]' - status (0)
[    1.800000] usbcore: registered new interface driver usbhid
[    1.810000] usbhid: USB HID core driver
[    1.820000] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.840000] mmc0: new high speed SDHC card at address b368
[    1.860000] TCP: cubic registered
[    1.870000] mmcblk0: mmc0:b368 USD   7.45 GiB
[    1.900000] NET: Registered protocol family 10
[    1.910000] sit: IPv6 over IPv4 tunneling driver
[    1.920000] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[    1.930000]  mmcblk0: p1 p2
[    1.940000] NET: Registered protocol family 17
[    1.950000] mmcblk0: p2 size 15603712 extends beyond EOD, truncated
[    1.960000] Key type dns_resolver registered
[    1.980000] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted freq: 454736 KHz
[    1.990000] cpufreq: __cpufreq_add_dev: CPU0: Unlisted initial frequency changed to: 454737 KHz
[    2.010000] registered taskstats version 1
[    2.020000] stmp3xxx-rtc 8005c000.rtc: setting system clock to 1970-01-01 00:00:07 UTC (7)
[    2.030000] device-tree: Duplicate name in testcase-data, renamed to "duplicate-name#1"
[    2.060000] ### dt-test ### start of selftest - you will see error messages
[    2.070000] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
[    2.080000] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
[    2.090000] /testcase-data/phandle-tests/consumer-a: could not find phandle
[    2.100000] /testcase-data/phandle-tests/consumer-a: could not find phandle
[    2.110000] /testcase-data/phandle-tests/consumer-a: arguments longer than property
[    2.110000] /testcase-data/phandle-tests/consumer-a: arguments longer than property
[    2.130000] irq: no irq domain found for /testcase-data/interrupts/intc0 !
[    2.150000] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    2.150000] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.160000] ### dt-test ### end of selftest - 115 passed, 0 failed
[    2.190000] hub 1-1:1.0: USB hub found
[    2.190000] hub 1-1:1.0: 5 ports detected
[    2.240000] vddio: disabling
[    2.240000] vdda: disabling
[    2.240000] vddd: disabling
[    2.250000] ALSA device list:
[    2.250000]   No soundcards found.
[    2.270000] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[    2.280000] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[    2.500000] usb 1-1.1: new high-speed USB device number 3 using ci_hdrc
[    2.630000] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    2.630000] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.740000] usb 1-1.5: new high-speed USB device number 4 using ci_hdrc
[    2.870000] usb 1-1.5: New USB device found, idVendor=0bda, idProduct=018a
[    2.880000] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.880000] usb 1-1.5: Product: 802.11n WLAN Adapter
[    2.890000] usb 1-1.5: Manufacturer: Realtek
[    2.890000] usb 1-1.5: SerialNumber: 00e04c000001
[    2.950000] EXT4-fs (mmcblk0p2): recovery complete
[    2.970000] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.980000] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    3.010000] devtmpfs: mounted
[    3.010000] Freeing unused kernel memory: 292K (c06ab000 - c06f4000)
[    6.480000] udevd[151]: starting version 175
[   13.410000] smsc95xx v1.0.4
[   13.670000] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-ci_hdrc.0-1.1, smsc95xx USB 2.0 Ethernet, d6:53:61:b9:e3:c6
[   13.730000] rtl8192cu: Chip version 0x10
[   13.730000] usbcore: registered new interface driver smsc95xx
[   14.970000] rtl8192cu: MAC address: 00:a1:10:f0:02:ee
[   14.980000] rtl8192cu: Board Type 0
[   15.000000] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[   15.000000] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[   15.000000] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[   15.000000] cfg80211: Disabling freq 2467 MHz as custom regd has no rule that fits it
[   15.000000] cfg80211: Disabling freq 2472 MHz as custom regd has no rule that fits it
[   15.000000] cfg80211: Disabling freq 2484 MHz as custom regd has no rule that fits it
[   15.010000] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[   15.020000] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain
[   15.050000] usb 1-1.5: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
[   15.070000] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
[   15.080000] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[   15.110000] usbcore: registered new interface driver rtl8192cu
[   21.850000] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   22.780000] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
[   46.350000] random: nonblocking pool is initialized
[   50.900000] rtl8192cu: MAC auto ON okay!
[   51.190000] rtl8192cu: Tx queue select: 0x05
[   52.230000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   52.360000] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   52.380000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   53.960000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   53.970000] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1


Thank you, Evgeny

Which bootloader does your board use?
Is it a 5V only configuration?

u-boot.
Yes, it's 5V-only, BAT pin is not connected. Eagle board and schematic can be found here: https://github.com/contactless/hardware/tree/master/WB-IMX233-CORE/C3 . The hardware is very similar to the Olinuxino Micro.

I have submitted a bugfix (https://github.com/lategoodbye/linux-mxs-power/commit/03f8189538f0fab367803bea18d1144f21b1c201) for clock handling. It would be nice if someone can test it.

Btw i've found out that ref_cpu is parent of the fec clock. So it's necessary to test Ethernet after changing cpu frequency.

Hi,

here are some updates from my Github repository:

- update repository to pm+acpi-3.19-rc4
- some bugfixes in the regulator driver
- implement is_enabled operation for regulator driver to get current state
- some limit fixes in the DT binding for the i.MX23/i.MX28

Stefan

I submitted the first version of cpufreq support patch, yesterday:

http://marc.info/?l=linux-pm&m=142698428606221&w=2

Thanks goes to all the testers.

Stefan

Hi,

since i'm already working on the power subsystem i also started the mainline port of the pswitch input driver:

https://github.com/lategoodbye/mxs_pswitch/tree/mainline (https://github.com/lategoodbye/mxs_pswitch/tree/mainline)

I think this feature would be interesting for the Olimex boards (MINI, MAXI) because AFAIK the PWR_BUT has no function in mainline.

Hi,

the last updates (https://github.com/lategoodbye/linux-mxs-power/tree/dcdc-clk) from Github repository:

- rebase on 4.0rc4
- add syscon support to mxs_power and mxs-regulator
- separate mxs-regulator in LDO and DC-DC part
- make DC-DC switching frequency a DT property
- implement proper 5V status handling for mxs_power
- several bugfixes ...

Stefan

Hi,

there are some updates about OTP driver support for MX23. The upcoming Kernel 4.3 will have a new framework (https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=eace75cfdcf7d9937d8c1fb226780123c64d72c4) for Non-Violatile-Memory (NVMEM) just like EEPROM or OTP. My OTP driver based now on that framework and has been acked (https://www.marc.info/?l=devicetree&m=143941814710784&w=2).

Stefan

Hi Stefan,

that's great news! Since you obviously already looked into nvmem in
detail: Do you think nvmem is the way to go to support the persistent
bits from the rtc/watchdog block?

I'm working on a few patches against the rtc and watchdog drivers
and the watchdog driver is an in-kernel consumer of persistent bits,
but there is no proper support so the driver just does the register
accesses itself.

TIA,
Harald

Hi Harald,

nvmem framework is pretty new and currently only supports userspace access. The in-kernel interface would come in the near future.

To your question: the persistent bits are some kind of special, but i think you could give it a try.

Stefan

Hi Stefan,

do you have plans to work on this any further? I would like to test your patches on a 4.4 kernel.

Jörg

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

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

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

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

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

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

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.

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

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

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.

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.

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

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

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.

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!

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

Hi Stefan,

1. Yes, I do!
2. I prefer comments on github, it's more public.
3. I can try. However, I do not have an i.MX23 board to test with.

Any help and feedback is welcome!

Best regards
Jörg

Sounds great. In case of i.MX23 i think you only need to add the SRAM node to the devicetree.

Based on Jörg's patches i tried to make the code work with i.MX23 and i.MX28:

https://github.com/lategoodbye/linux-mxs-power/commits/rebase-4.5

Unfortunately my Olinuxino Maxi freezes after switching cpu clock source from PLL to XTAL :-(

Strangly the code work's with my i.MX28 board.

Regards
Stefan

Edit:

Here some consumption values of my i.MX28 board:

State ON: 0.988 W
State Idle: 0.5 W (echo mem > /sys/power/state BEFORE standby support)
State standby: 0.141 W (echo mem > /sys/power/state AFTER standby support)

Hi Stefan,

I've tested your updated branch. Unfortunately, my i.MX28 board freezes, too. Measurements show that the device consumes more power compared to my branch (~20mA more) after issuing "standby". Furthermore, the device cannot be waken up.

I will try to compare the changes you made with my branch to investigate the issue.

I was able to fix my issue by reverting commit https://github.com/lategoodbye/linux-mxs-power/commit/321656a5a9b6476f2837d0c71848e78f504ff91e (https://github.com/lategoodbye/linux-mxs-power/commit/321656a5a9b6476f2837d0c71848e78f504ff91e).

Note that I do not use the PSWITCH pin on my board.

Hi Jörg,

thanks for testing, but i need more specific information:

Could you please describe the "freeze" exactly. Is really a freeze or doesn't it resume?

Do you use "no_console_suspend"?

How do you reproduce the issue (suspend and resume action) and your observation?

What issue does the revert fix ("freeze" or power consumption or both)?

Hi Stefan,

sorry for the delay - I was quite busy.

Actually, it does not resume.

Yes, I use "no_console_suspend".

I am using a GPIO as suspend- and wakeup-source. Pulling the GPIO to low emits "echo standby > /sys/power/state" and the CPU goes into standby mode. After releasing the GPIO to high the CPU wakes up and resumes operation. In this case I measure ~15 mA current consumption in standby mode.

Without the reverted patch the device goes into the suspend state (at least mxs_suspend_in_ocram_fn is called). In this case, current consumption is about ~26 mA in standby mode. Releasing the GPIO does not wake up the CPU.

Note that PSWITCH is connected to VDDXTAL, but without a switch.

Best regards
Jörg

Hi Jörg,

thanks for pointing out. I reverted the commit.

Regards
Stefan

Any idea why does it fails in my case?

I did a fresh clone of the Linux repository and cherry-picked most of the commits from lategoodbye/rebase-4.5 https://github.com/lategoodbye/linux-mxs-power/tree/rebase-4.5 (https://github.com/lategoodbye/linux-mxs-power/tree/rebase-4.5) on top of the latest version tag v4.7-rc7: https://github.com/joerg-krause/linux/commits/mxs-power-v4.7-rc7.

Note that I dropped some patches from lategoodbye/rebase-4.5, e.g. adding the variants for the Duckbill boards, as I did not need them.

Quote from: joerg.krause on July 18, 2016, 01:39:58 PM
Any idea why does it fails in my case?

I tested with a Duckbill (i.MX28 platform with PSWITCH connected to VDDA) and had the same results as yours.

So it seems the ENIRQ_PSWITCH must be handled by platform PM code instead of pswitch driver. I'm still working on it.

Edit: Commited 2 fixes ...

Hi Stefan,

I had some time to test the latest commits of your branch. I am using a sleep/wake-up gpio-key to suspend/resume the cpu. This is the corresponding dts snippet:


[..]
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpio_keys>;

sleep {
label = "Wakeup";
gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
linux,code = <KEY_SLEEP>;
wakeup-source;
};
};

[..]

pinctrl_gpio_keys: pinctrl-gpio-keys@0 {
reg = <0>;
fsl,pinmux-ids = <
MX28_PAD_LCD_VSYNC__GPIO_1_28 /* KEY_SLEEP */
>;
fsl,drive-strength = <MXS_DRIVE_4mA>;
fsl,voltage = <MXS_VOLTAGE_HIGH>;
fsl,pull-up = <MXS_PULL_DISABLE>;
};
[..]


A key event listener executes /usr/sbin/pm-suspend when KEY_SLEEP was emitted. The cpu wakes up if I release the gpio. However, a kernel warning is printed:

[   48.365030] PM: Syncing filesystems ... done.
[   48.392543] Freezing user space processes ... (elapsed 0.011 seconds) done.
[   48.412799] Freezing remaining freezable tasks ... (elapsed 0.004 seconds) done.
[   48.459679] PM: suspend of devices complete after 26.615 msecs
[   48.474752] PM: late suspend of devices complete after 9.115 msecs
[   48.490430] PM: noirq suspend of devices complete after 9.210 msecs
[   48.512271] PM: noirq resume of devices complete after 12.327 msecs
[   48.529728] PM: early resume of devices complete after 6.975 msecs
[   48.538648] ------------[ cut here ]------------
[   48.543395] WARNING: CPU: 0 PID: 392 at kernel/irq/manage.c:605 irq_set_irq_wake+0xac/0xf4()
[   48.551874] Unbalanced IRQ 60 wake disable
[   48.556000] Modules linked in: [last unloaded: brcmutil]
[   48.561405] CPU: 0 PID: 392 Comm: pm-suspend Not tainted 4.5.0-LINTECH #1
[   48.568224] Hardware name: Freescale MXS (Device Tree)
[   48.573462] [<c000f070>] (unwind_backtrace) from [<c000d2f0>] (show_stack+0x10/0x14)
[   48.581290] [<c000d2f0>] (show_stack) from [<c0017964>] (warn_slowpath_common+0x80/0xa8)
[   48.589449] [<c0017964>] (warn_slowpath_common) from [<c00179b8>] (warn_slowpath_fmt+0x2c/0x3c)
[   48.598216] [<c00179b8>] (warn_slowpath_fmt) from [<c004ef74>] (irq_set_irq_wake+0xac/0xf4)
[   48.606649] [<c004ef74>] (irq_set_irq_wake) from [<c01bca40>] (mxs_gpio_set_wake_irq+0x1c/0x24)
[   48.615429] [<c01bca40>] (mxs_gpio_set_wake_irq) from [<c004ef90>] (irq_set_irq_wake+0xc8/0xf4)
[   48.624205] [<c004ef90>] (irq_set_irq_wake) from [<c023a27c>] (gpio_keys_resume+0x88/0xb4)
[   48.632538] [<c023a27c>] (gpio_keys_resume) from [<c01f84e4>] (dpm_run_callback+0x28/0xa0)
[   48.640858] [<c01f84e4>] (dpm_run_callback) from [<c01f893c>] (device_resume+0xc0/0x198)
[   48.649004] [<c01f893c>] (device_resume) from [<c01f97ac>] (dpm_resume+0x104/0x1e4)
[   48.656717] [<c01f97ac>] (dpm_resume) from [<c01f9a28>] (dpm_resume_end+0xc/0x18)
[   48.664262] [<c01f9a28>] (dpm_resume_end) from [<c004ac14>] (suspend_devices_and_enter+0xd4/0x420)
[   48.673281] [<c004ac14>] (suspend_devices_and_enter) from [<c004b0a0>] (pm_suspend+0x140/0x210)
[   48.682039] [<c004b0a0>] (pm_suspend) from [<c0049e08>] (state_store+0x9c/0xb8)
[   48.689413] [<c0049e08>] (state_store) from [<c011eda4>] (kernfs_fop_write+0x130/0x184)
[   48.697494] [<c011eda4>] (kernfs_fop_write) from [<c00c2dc8>] (__vfs_write+0x1c/0xd0)
[   48.705395] [<c00c2dc8>] (__vfs_write) from [<c00c3a80>] (vfs_write+0xa8/0x178)
[   48.712767] [<c00c3a80>] (vfs_write) from [<c00c44d0>] (SyS_write+0x3c/0x74)
[   48.719869] [<c00c44d0>] (SyS_write) from [<c000a140>] (ret_fast_syscall+0x0/0x1c)
[   48.727479] ---[ end trace dbbbb797e7693392 ]---


Did I missed something?

Hi Stefan,

I applied the patches from your rebase-4.5 branch on top of a clean 4.7 linux branch: https://github.com/joerg-krause/linux/commits/mxs-power-v4.7 (https://github.com/joerg-krause/linux/commits/mxs-power-v4.7).

After this, I compared the patches with my previous branch https://github.com/joerg-krause/linux-mxs-power/tree/standby (https://github.com/joerg-krause/linux-mxs-power/tree/standby) and I figured out that your branch misses some commits from my standby branch (now applied to the 4.7 Kernel branch, too):

• https://github.com/joerg-krause/linux/commit/82540cbdea97512504120bfe0e472712920025b6 (https://github.com/joerg-krause/linux/commit/82540cbdea97512504120bfe0e472712920025b6)
• https://github.com/joerg-krause/linux/commit/dacdd8ed192da6b22e49ff90ef43035b921f86b5 (https://github.com/joerg-krause/linux/commit/dacdd8ed192da6b22e49ff90ef43035b921f86b5)

Using those commits makes the Kernel warning disappear.

Sorry for this inconvenience, but the two patches doesn't seem to be the right way. Since everything works before except this warning we should set IRQCHIP_SKIP_SET_WAKE instead of these two patches ( like here http://lxr.free-electrons.com/source/kernel/irq/dummychip.c )?

I must confess I didn't take much effort to understand the warning and the two patches. If you think setting IRQCHIP_SKIP_SET_WAKE is a better solution I am absolutely fine with it. Will you add a patch to your repo?

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.

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 (https://community.nxp.com/message/818211)

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?

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!

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

Okay, what's the state of the SAIF issue?

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.

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.

Hi Stefan,

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

Thanks for your work!

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.