how to find name of GPIO pin mux/Soc pin modes/Output/Pullup in libgpiod

[xlla]

for example, to use built in LED in arduino pin13 we need set 214 0 set 243 0 set 40 mode0 set 109 mode0 set 261 1 set 229 0 set 214 1

but in /usr/bin/blink-led

set_line("TRI_STATE_ALL", 0) set_line("SPI_CLK_SEL", 0) set_line("MUX18_DIR", 1) set_line("TRI_STATE_ALL", 0) led = gpiod.Chip("gpiochip0").get_line(40) led.request(consumer=led.owner().name(), type=gpiod.LINE_REQ_DIR_OUT)

1, where is the map or table, we can lookup 214 to "TRI_STATE_ALL", ?? to "SPI_CLK_SEL", ?? to "MUX18_DIR"? 2, why set TRI_STATE_ALL to zero twice?

[htot]

There is a schematic. There you can see TRI_STATE_ALL is on U17 which has address 0 (A0 = A1 = A2 = 0). This corresponds to gpiochip0. TRI_STATE_ALL is on IO1.6. With gpioinfo gpiochip1 you can see it is on line 14 (which corresponds to IO1.6)

[xlla]

I can understand that a little, TRI_STATE_ALL is on U17 which has address 0, so corresponds to gpiochip1 (0+1) ? TRI_STATE_ALL is on IO1.6, so line offset is 14 (8+6) ?

how can we determine the line name, if I want use led in pin13, GP40 is on U43->U18->U34 which has address 3, IO1.5, so corresponds to gpiochip4 (3+1), line offset 13 (8+5), with line name MUX18_DIR, the regular is MUX+chip no+DIR? GP109 is on U43->U16 which has address 2, IO1.3, so corresponds to gpiochip3 (2+1), line offset 11 (8+3), with line name SPI_CLK_SEL?

[htot]

I can understand that a little, TRI_STATE_ALL is on U17 which has address 0, so corresponds to gpiochip1 (0+1) ? TRI_STATE_ALL is on IO1.6, so line offset is 14 (8+6) ?

Exactly.

how can we determine the line name, if I want use led in pin13, GP40 is on U43->U18->U34 which has address 3, IO1.5, so corresponds to gpiochip4 (3+1), line offset 13 (8+5), with line name MUX18_DIR, the regular is MUX+chip no+DIR? GP109 is on U43->U16 which has address 2, IO1.3, so corresponds to gpiochip3 (2+1), line offset 11 (8+3), with line name SPI_CLK_SEL?

LED is controlled by DIG13_PWR. Depending on SPI_CLK_SEL this coming from either GP40 or GP109. These are coming from the SoC directly (gpiochip0), line 40. Therefore:

led = gpiod.Chip("gpiochip0").get_line(40)

[xlla]

I got it! after replace RPI.GPIO with libgpiod, I am able to run luma.example in thud branch.

[xlla]

Depending on SPI_CLK_SEL this coming from either GP40 or GP109. These are coming from the SoC directly (gpiochip0), line 40. Therefore:

led = gpiod.Chip("gpiochip0").get_line(40)

My last confusion, how to control SoC internel muxes. In this document, section 2.3,

Additionally, some of the SoC GPIO pins also feature internal mux options. These are listed as “SoC Pin Modes”. Currently, these are configured by setting the required pin mode for the corresponding SoC GPIO pin N, via /sys/kernel/debug/gpio_debug/gpioN/current_pinmux, to “mode[0/1/2/...]”

I can't find /sys/kernel/debug/gpio_debug... in warrior kernel.

led = gpiod.Chip("gpiochip0").get_line(40)                                                        
led.request(consumer=led.owner().name(), type=gpiod.LINE_REQ_DIR_OUT) 

Does "led.request, gpiod.LINE_REQ_DIR_OUT " same as set Soc 40 Pin mode 0 ? and how to set Soc 40 Pin mode 1, if I want to use I2S.

root@edison:~# python3
Python 3.7.6 (default, Feb 15 2020, 18:07:20) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gpiod
>>> print (gpiod.LINE_REQ_DIR_OUT)
3
>>> print (gpiod.LINE_REQ_DIR_IN)
2

what is the connection between mode 0/1/2 and gpiod.LINE_REQ_DIR_xxx ?

[htot]

Correct /sys/kernel/debug interface is not available in vanilla kernel. These are done by acpi tables.

[xlla]

@htot could you amend mechanism of acpi tables to support build and package many aml files? because we would like to change pin function in user space instead of update kernel or u-boot.

while arduino sketch file got compile, this mux.c will introduce and change function of used pins in the sketch, I can modify it to use gpiod instead of sysfs, but I can't switch Soc mode in user space.

I have think up a method, split arduino.asl into many individual units, each unit defined a simple function related to one or more pins, then compile and package these aml files into acpi-tables.deb.

for example, d0.asl - just switch GP130 to GPIO mode.
pwm0.asl - just switch GP12 to PWM mode. uart02.asl - just switch GP130,GP131 to UART mode. i2c.asl -just switch GP14, GP165 to i2c mode. a4.asl - just switch GP14 to A4 GPIO. ...

then I may find out which pin or function the sketch depend on, manage to invoke a special script via clloader zmodem protocol before the sketch got upload to edison board.

in that script it can receive some parameters to know which pin or function should tuned on, then ask acpi-tables-reload to deploy related unit aml.

what about this idea.

[htot]

@htot could you amend mechanism of acpi tables to support build and package many aml files? because we would like to change pin function in user space instead of update kernel or u-boot.

You can modify the recipe to compile and package a large number of aml file.

I have think up a method, split arduino.asl into many individual units, each unit defined a simple function related to one or more pins, then compile and package these aml files into acpi-tables.deb.

for example, d0.asl - just switch GP130 to GPIO mode. pwm0.asl - just switch GP12 to PWM mode. uart02.asl - just switch GP130,GP131 to UART mode. i2c.asl -just switch GP14, GP165 to i2c mode. a4.asl - just switch GP14 to A4 GPIO. ...

then I may find out which pin or function the sketch depend on, manage to invoke a special script via clloader zmodem protocol before the sketch got upload to edison board.

in that script it can receive some parameters to know which pin or function should tuned on, then ask acpi-tables-reload to deploy related unit aml.

loading an aml by script is shown here, / unloading is just a matter of rmdir.

what about this idea.

I thought of it too. But haven't implemented due to lack of time. But I would take your patch!

[xlla]

@htot Because we can't change Soc pin mode via ligpiod, I think it better to get rid of those muxs manipulation from mraa lib/arduino lib/scripts files, or it just confuse end user else.

another idea is, fixed mraa lib first, then make arduino lib depend on it to save efforts. it seems mraa lib and arduino lib was developed independently.

[htot]

Yes. But we could use a doc page to help people write asl table that configures pin mux as needed.

[htot]

Try this:

root@edison:~# ls -l /sys/kernel/config/acpi/table
total 0
drwxr-xr-x 2 root root 0 Jan  1  2000 arduino
drwxr-xr-x 2 root root 0 Jan  1  2000 leds
drwxr-xr-x 2 root root 0 Jan  1  2000 spidev
root@edison:~# rmdir /sys/kernel/config/acpi/table/leds/
# heartbeat stops
root@edison:~# systemctl start blink-led
# blink-led runs

Removing the leds table releases the gpio and unloads the trigger. And then blink-led runs normally.

[xlla]

but I still don't know how to switch soc pin function, I only found 4 pinFunction usage in all acpi table examples, but i2c and spi function were work fine, so I think those soc pin function switch must happen in kernel or kernel modules.

@htot @andy-shev please correct me if I were wrong.

[htot]

I don't know exactly how it works. All I know is for the SoC stuff is in U-Boot in the southcluster.asl like FLIS and PWM0.

Then in arduino.asli the function is changed.

Which SoC pin function do you want to change?

[xlla]

All I know is for the SoC stuff is in U-Boot in the southcluster.asl like FLIS and PWM0.

Aha, this table looks like communicator in backroom. I am not understand it very well. there still no pinFunction invoke, so those soc pin mode switch must happened in somewhere. why not i2c appear in FLIS PinGroup. can I mimic it add new pingroup like this?

PinGroup("i2s2", ResourceProducer, ) { 75, 76, 77, 78 }

does section RBUF of Device (SPI5) in arduino.asli be used for turn on soc pin mode of spi5_ss 0 to 3? why other pin does not need be turn on like spi5_tx, spi5_rx and spi5_clk.

Which SoC pin function do you want to change?

IO0 to IO6, IO9 to IO13, IO18, IO19, plus GP40 to GP43, GPGP14, GP165. Actually, I want to implement a set of scripts, to manipulate all of those mux , pullups, soc modes. for example, init_uart1.sh off 2 will turn off uart1 2wire function, switch soc pin mode to 0 for GP130~GP131. set pullup to default.

inituart1.sh on 4 will turn on uart1 4wire function, switch soc pin mode to 1 for GP128~GP131. set pullup in. set pin direction correct for U34 IO0.0~U34_ IO0.4

init_DIG.sh 1 in pullup will call inituart1.sh off 4, set U34 IO0.1 in, set U39_IO0.1 input.

init_pwm.sh on 0 will turn on pwm0 function, switch soc pin mode to 1 for GP12. set dir to out, set pullup to high impedance input.

Ideally, the implement in each script just depend on acpi tables dynamic load/unload. for exampe, to turn off uart1 4 wire, rmdir /sys/kernel/config/acpi/table/uart_4w to turn on spi, cp /kernel/firmware/acpi/spi /sys/kernel/config/acpi/table/ to turn DIG 2, cp /kernel/firmware/acpi/d2 /sys/kernel/config/acpi/table/

Because I don't know who in where switch those soc pin mode to 1 for spi/i2c/uart, I wonder if I unload the special acpi table, the corresponding soc pins mode will be remain or be reset. to guaranty it, I will switch soc pin mode in each acpi unit file.

[andy-shev]

but I still don't know how to switch soc pin function, I only found 4 pinFunction usage in all acpi table examples, but i2c and spi function were work fine, so I think those soc pin function switch must happen in kernel or kernel modules.

It must but it does not for time being...

[andy-shev]

All I know is for the SoC stuff is in U-Boot in the southcluster.asl like FLIS and PWM0.

Aha, this table looks like communicator in backroom. I am not understand it very well. there still no pinFunction invoke, so those soc pin mode switch must happened in somewhere. why not i2c appear in FLIS PinGroup.

I'm sorry but I'm tired to repeat over and over that kernel missed a crucial layer to make this work, i.e. ACPI subsystem <--> pin control subsystem.

can I mimic it add new pingroup like this?

You can, but see above.

PinGroup("i2s2", ResourceProducer, ) { 75, 76, 77, 78 } does section RBUF of Device (SPI5) in arduino.asli be used for turn on soc pin mode of spi5_ss 0 to 3? why other pin does not need be turn on like spi5_tx, spi5_rx and spi5_clk.

It's other way around. We are using chip selects in GPIO mode, and not native.

Which SoC pin function do you want to change? IO0 to IO6, IO9 to IO13, IO18, IO19, plus GP40 to GP43, GPGP14, GP165.

See above.

Actually, I want to implement a set of scripts, to manipulate all of those mux , pullups, soc modes.

No, it won't work like this even if the above mentioned layer will be implemented. The idea is to transparently (to the user) to switch modes based on currently connected devices (via their respective ASL excerpts).

The working scheme like

1. Prepare ACPI tables
2. Boot machine, load tables
3. Power off, go to 1. (for some cases it would work via ACPI ConfigFS w/o reboot, but it's not universal solution and never was considered for productization)

Ideally, the implement in each script just depend on acpi tables dynamic load/unload.

Yes, this might work.

[xlla]

@andy-shev , alright, I am understand whole theory and reason now. I want to help fill the gap between ACPI subsystem <--> pin control but maybe I am lack skills.

As the kernel developer, universal solution is most important concern. As the special hardware (edison arduino breadboard) user, could I write out some rough out-of-tree module to fill this gap temporary, we can discard it when upstream is ready.

The idea is to transparently (to the user) to switch modes based on currently connected devices

I plan to use those script to migrate Arduino lib and MRAA lib, to avoid duplicated libgpiod implement in each lib. In another perspective, the final business code is the user, it just depend on Arduino lib/MRAA lib and don't care how to switch mux.

I think this hardware(edison arduino breadboard) is best be used to experiment some ideas, those complex muxs just born to support changes, they won't be present in other product, so don't spend too many brains to work out uniform/universal sulotion.

you are already bring latest u-boot/kernel/acpi tables/software to this older gadget, it is great enough!

[xlla]

No, it won't work like this even if the above mentioned layer will be implemented.

the detail implement is, I will replace lookup table {248,249,...} , {216, 217,...} to my scripts, when user invoke arduino api/mraa api to access the digital pin/analog pin/pwm pin/i2c/spi/uart, the corresponding script will called transparently to prepare mux/pullup/soc pin mode.

[andy-shev]

@andy-shev , alright, I am understand whole theory and reason now.

Good!

I want to help fill the gap between ACPI subsystem <--> pin control but maybe I am lack skills.

As the kernel developer, universal solution is most important concern. As the special hardware (edison arduino breadboard) user, could I write out some rough out-of-tree module to fill this gap temporary, we can discard it when upstream is ready.

I already told, that we can use the old Edison approach (via debugfs) as temporary solution. I simple won't spend time on it. Same as for PSH.

The idea is to transparently (to the user) to switch modes based on currently connected devices

I plan to use those script to migrate Arduino lib and MRAA lib, to avoid duplicated libgpiod implement in each lib. In another perspective, the final business code is the user, it just depend on Arduino lib/MRAA lib and don't care how to switch mux.

I think this hardware(edison arduino breadboard) is best be used to experiment some ideas, those complex muxs just born to support changes, they won't be present in other product, so don't spend too many brains to work out uniform/universal sulotion.

Yes. And for that we don't need run-time availability to mux the pins. Basically as I described few times tooling should simple prepare proper ACPI excerpts that will be loaded on the next boot. That's it.

[xlla]

@andy-shev Thanks again, I hope I could implement it.

[xlla]

Removing the leds table releases the gpio and unloads the trigger. And then blink-led runs normally.

@htot I have tried it, works fine.

[xlla]

I already told, that we can use the old Edison approach (via debugfs) as temporary solution.

I wonder how to use that approach in our new kernel. In mraa lib, it use sysfs that does not support in our kernel, and it will check kernel version and skip set pinmode.

    if (vanilla_kernel != 0) {
        syslog(LOG_NOTICE, "edison: Vanilla kernel does not support setting pinmux %d", sysfs);
        return MRAA_SUCCESS;
    }

or comment that check and force it do following debugFs operation? also I found it's debugFs path does not exist in our system.

#define DEBUGFS_PINMODE_PATH "/sys/kernel/debug/gpio_debug/gpio"

root@edison:~# ls /sys/kernel/debug/gpio_debug/gpio
ls: cannot access '/sys/kernel/debug/gpio_debug/gpio': No such file or directory

[andy-shev]

I already told, that we can use the old Edison approach (via debugfs) as temporary solution.

I wonder how to use that approach in our new kernel.

You need to patch the kernel. Basically take the source from stock sources (not pretty and quite twisted, unfortunately) and re-apply them to the existing drivers/pinctrl/intel/pinctrl-merrifield.c.

I can answer simple additional questions, but I don't have time nor wish to look into this by the reasons I have expressed earlier.

[xlla]

I am sorry to bother you for this. due to the lack of document about whole architecture and implement details, I have to read a lot of sources, commit logs, scripts and ancient edison documents to understand something and ask simple questions sometimes.

[andy-shev]

I am sorry to bother you for this.

No problem.

due to the lack of document about whole architecture and implement details, I have to read a lot of sources, commit logs, scripts and ancient edison documents to understand something and ask simple questions sometimes.

I can give you some pointers. Here is the file where it's implemented (hmm... it took me whole 5 minutes to recall how that bad designed code spread over the kernel sources): https://github.com/intel/edison-linux/blob/edison-3.10.98/drivers/gpio/gpio-langwell.c#L807. More precisely https://github.com/intel/edison-linux/blob/edison-3.10.98/drivers/gpio/gpio-langwell.c#L1194.

What you need is to take these functions and add them to drivers/pinctrl/intel/pinctrl-merrifield.c. It will require to update an API calls, of course.

P.S. The minimum you may start with is to enable only pinmux part (to switch modes), the rest I guess was never used anyway in Intel Edison case.

[xlla]

I really appreciate your great help!

and I hate bad design too :) As I learned more about ACPI, I realized my design is bad too.

1. I have changed some ACPI object's _HID to meaningful string instead of "PRP0001", then driver will failure to probe those devices. I have to restore those _HID.
2. I found I can't modify same _DSD's package data from multiple aml files, so I must keep all definition in one aml file.

• Prepare ACPI tables
• Boot machine, load tables
• Power off, go to 1. (for some cases it would work via ACPI ConfigFS w/o reboot, but it's not universal solution and never was considered for productization)

3. I am agree this procedure absolutely, but want to simplify acpi-tables preparation. when I want connect some gadget to do a test, I must prepare whole yocto poky environment, create image, flash, then start test. or prepare whole yocto poky environment, create acpi-tables.deb, deploy and install it, manual load acpi. all above methods is too complex. so I thought another idea, use a script/program combine an asl file and compile it in Edison directly! I have tested and it works.

   root@edison:~# iasl /mnt/study/acpi/oled-i2c.asl

Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20190215 Copyright (c) 2000 - 2019 Intel Corporation

ASL Input: /mnt/study/acpi/oled-i2c.asl - 41 lines, 1575 bytes, 100 keywords AML Output: /mnt/study/acpi/oled-i2c.aml - 5699 bytes, 89 named objects, 11 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 87 Optimizations root@edison:~# cp /mnt/study/acpi/oled-i2c.aml /kernel/firmware/acpi/ root@edison:~# acpi-tables-load oled-i2c install oled-i2c ... [35982.809443] ssd1307fb i2c-PRP0001:00: No device tree data found! done.

for above reason, I will study more before do actual modification.

[andy-shev]

As I learned more about ACPI, I realized my design is bad too.

1. I have changed some ACPI object's _HID to meaningful string instead of "PRP0001", then driver will failure to probe those devices. I have to restore those _HID.

ACPI _HID is something that hardware vendors may provide, it can't be taken from the thin air. PRP0001 is a virtual _HID (no hardware belongs to it) in order to support OF enumeration, i.o.w. enumeration via compatible strings.

2. I found I can't modify same _DSD's package data from multiple aml files, so I must keep all definition in one aml file.

Yes, this is a known limitation of ACPICA.

• Prepare ACPI tables
• Boot machine, load tables
• Power off, go to 1. (for some cases it would work via ACPI ConfigFS w/o reboot, but it's not universal solution and never was considered for productization)

so I thought another idea, use a script/program combine an asl file and compile it in Edison directly! I have tested and it works.

Yes, you may compile it wherever you want to :-) In any case you will need to follow steps I described above.

root@edison:~# cp /mnt/study/acpi/oled-i2c.aml /kernel/firmware/acpi/ root@edison:~# acpi-tables-load oled-i2c install oled-i2c ... [35982.809443] ssd1307fb i2c-PRP0001:00: No device tree data found! done.

for above reason, I will study more before do actual modification.

[xlla]

ACPI _HID is something that hardware vendors may provide, it can't be taken from the thin air. PRP0001 is a virtual _HID (no hardware belongs to it) in order to support OF enumeration, i.o.w. enumeration via compatible strings.

I found a trick to use a customized _HID by put PRP0001 in _CID. it works and I don't know the impacts.

ls -al   /sys/bus/acpi/devices
lrwxrwxrwx 1 root root 0 Mar 31 00:43 ADS7951:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/ADS7951:00
lrwxrwxrwx 1 root root 0 Mar 31 00:43 SSD1331:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/SSD1331:00
lrwxrwxrwx 1 root root 0 Mar 31 00:43 LED0001:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/LED0001:00

[andy-shev]

ACPI _HID is something that hardware vendors may provide, it can't be taken from the thin air. PRP0001 is a virtual _HID (no hardware belongs to it) in order to support OF enumeration, i.o.w. enumeration via compatible strings.

I found a trick to use a customized _HID by put PRP0001 in _CID. it works and I don't know the impacts.

You may do it for your personal use, but it won't be accepted in any (official) repository.

[xlla]

@andy-shev OK, I know the impact and I will restore those _HID. I am try to migrate debugfs pinmux function from gpio-langwell to pinctrl-merrifield, I want to understand some principle.

1. to access a pinmode, is this the normal path user space -> kernel module-> acpi table-> BIOS/u-boot -> acutal soc pinmode mux

2. in gpio-langwell, it send actual command to intel_scu_flis, should I migrate this module too? will it conflict with something?

3. I saw pinmux.c in u-boot send actual command via scu_ipc_raw_command in scu.c, is it a replacement of old intel_scu_flis? how to invoke these function live in u-boot?

4. to simplify, can I add more dummy pin_group to achieve my goal ie, to disable pwm0, add those, PIN_GROUP("pwm0_off_grp", mrfld_pwm0_pins, 0), static const char * const mrfld_pwm0_off_groups[] = { "pwm0_off_grp" }; FUNCTION("pwm0off", mrfld_pwm0_off_groups), and replace RBUF section of device FLIS in southcluster.asl, PinGroup("pwm0off", ResourceProducer, ) { 144 }

if above method 4 work, to avoid re-flash u-boot, can I move whole Device(FLIS) definition out to arduino.asli, let acpi-table-load to load it?

[andy-shev]

@andy-shev I am try to migrate debugfs pinmux function from gpio-langwell to pinctrl-merrifield, I want to understand some principle.

Okay!

1. to access a pinmode, is this the normal path user space -> kernel module-> acpi table-> BIOS/u-boot -> acutal soc pinmode mux

ACPI tables for time being is not involved in this (as I told dozen of times, we lack of the certain software layer in the kernel).

2. in gpio-langwell, it send actual command to intel_scu_flis, should I migrate this module too? will it conflict with something?

That function IIRC chooses how to access the FLIS families (because I2C is under protection and you may not write to it directly). So, as far as you don't want to switch I2C modes, you don't need that. Otherwise you rather need my few patches that add the I2C pin mode support: https://github.com/andy-shev/linux/commits/eds (see, for example, https://github.com/andy-shev/linux/commit/7bd4227147c19860a915de6b0c775babb85c41c4). Also read this: https://svenschwermer.de/2017/10/14/intel-edison-i2c6-with-vanilla-linux.html

3. I saw pinmux.c in u-boot send actual command via scu_ipc_raw_command in scu.c, is it a replacement of old intel_scu_flis? how to invoke these function live in u-boot?

That stub is used to override default mode for I2C, which is 2, means PSH connected, by firmware. It's not a real driver there.

4. to simplify, can I add more dummy pin_group to achieve my goal ie, to disable pwm0, add those, PIN_GROUP("pwm0_off_grp", mrfld_pwm0_pins, 0), static const char * const mrfld_pwm0_off_groups[] = { "pwm0_off_grp" }; FUNCTION("pwm0off", mrfld_pwm0_off_groups),

"Disable" or AFAICS switching to GPIO mode will work without above.

and replace RBUF section of device FLIS in southcluster.asl, PinGroup("pwm0off", ResourceProducer, ) { 144 }

I don't know what to say more. I told you many times that we lack of the layer to make use of these Pin*() ASL features.

I will really appreciate if somebody helps to make it done.

if above method 4 work, to avoid re-flash u-boot, can I move whole Device(FLIS) definition out to arduino.asli, let acpi-table-load to load it?

No. If and only if 4 (second part) is working you simple need to provide Pin*() features to each device node in ACPI table. The muxing will be done automatically and transparently depends to what driver you have in use right now.

It's a crucial feature to get all magic works nicely.

[xlla]

@andy-shev pardon me for my similar questions repeatedly. Because kernel module and u-boot driver is hardly to trace and debug, I am just try to guess and understand how does those special soc pinmux work base on current source code in multiply project repo.

1. right path is for IO except i2c user space -> kernel module-> acutal soc pinmode mux for i2c user space -> kernel module-> scu psh -> acutal soc pinmode mux

4. I saw a lot of FUNCTION defined in pinctrl-merrifield, the only refer/usage I can found is in RBUF section of device FLIS in southcluster.asl, so I thought that method to turn off pwm0 in same manner without touch any logic code.

At last, does those below guesses true:

1. once power on , all soc pinmode of sdio/spi5/uart0-2/pwm0-3 at default mode 1? so all related source code just prepare for future acpi Pin* feature and do nothing right now?

2. once power on, soc pinmode of i2c at default mode 2. u-boot driver tangier_pinctrl will switch it to mode 1 after boot. if I comment out that code, then I can remain it as i2c-8 used for mcu?

[andy-shev]

@andy-shev pardon me for my similar questions repeatedly. Because kernel module and u-boot driver is hardly to trace and debug, I am just try to guess and understand how does those special soc pinmux work base on current source code in multiply project repo.

1. right path is for IO except i2c user space -> kernel module-> acutal soc pinmode mux

Correct.

for i2c user space -> kernel module-> scu psh -> acutal soc pinmode mux

No. SCU PSH can't be in one sentence like this, either of them can. PSH has nothing to do with this. PSH is providing peripheral (I²C buses 8 and 9) that are multiplexed by firmware on the corresponding pins. It's simple SCU which works as a proxy for the I²C families of pins.

2. I saw a lot of FUNCTION defined in pinctrl-merrifield, the only refer/usage I can found is in RBUF section of device FLIS in southcluster.asl, so I thought that method to turn off pwm0 in same manner without touch any logic code.

The driver part (in the C code) is a legacy to allow people to do at least board files easily to mux the groups of pins as they wish. Pin*() is ACPI replacement for that.

At last, does those below guesses true:

1. once power on , all soc pinmode of sdio/spi5/uart0-2/pwm0-3 at default mode 1?

No idea. It's done by firmware. If you don't request any GPIO, you can see it by dumping pins file in DebugFS.

so all related source code just prepare for future acpi Pin* feature and do nothing right now?

Not fully correct. The hardcoded functions and groups helps with board files, if user wants to create them. The code in ASL is indeed just a preparation for the brightest future.

2. once power on, soc pinmode of i2c at default mode 2.

For sure for I²C bus 6.

u-boot driver tangier_pinctrl will switch it to mode 1 after boot.

Only for bus 6.

if I comment out that code, then I can remain it as i2c-8 used for mcu?

It's done via DTS, no need to comment any code, just amend U-Boot DTS (note, it works solely for I²C family of pins, if you need more, you need to expand the driver to be a real pin control driver in U-Boot).

[xlla]

@andy-shev It's clear for me, thanks a lot!

[xlla]

@andy-shev after many times kernel panic, I bridge the gap :)

root@edison:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pins | grep GP27
pin 111 (GP27_I2C_6_SCL) mode 1 0x00000511
root@edison:~# echo GP27 2 > /sys/kernel/debug/pinctrl_pinmux/pinmux
root@edison:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pins | grep GP27
pin 111 (GP27_I2C_6_SCL) mode 2 0x00000512
root@edison:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pins | grep GP129
pin 120 (GP129_UART_1_RTS) mode 1 0x00003001
root@edison:~# echo GP129 0 > /sys/kernel/debug/pinctrl_pinmux/pinmux
root@edison:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pins | grep GP129
pin 120 (GP129_UART_1_RTS) GPIO 0x00003000