<vigneshr>
austriancoder: not sure what does registers are for... I will ask HW folks internally. Please raise e2e query as well
florian_kc has joined #linux-ti
bennie has joined #linux-ti
bennie has left #linux-ti [#linux-ti]
benediktniederma has joined #linux-ti
benediktniederma has quit [Quit: Client closed]
florian has quit [Ping timeout: 265 seconds]
florian has joined #linux-ti
rogerq has quit [Ping timeout: 265 seconds]
benediktniederma has joined #linux-ti
benediktniederma has quit [Client Quit]
benediktniederma has joined #linux-ti
<benediktniederma>
Hello. I would continue the discussion regarding the gpiochardev interface (maybe some of you participated this week).
<benediktniederma>
But for clarification I describe the issue here again...
<benediktniederma>
We encountered some issues when accessing the gpiochardev interface. The basic idea was to fully rely on all features the gpiochardev seems to offer. I got all relevant information from the Linux Kernel Documentation (Documentation/driver-api/pin-control.rst) and saw some presentations from Linus Walleij (Maintainer of linux-gpio).
<benediktniederma>
If I understand that correctly the gpiochardev interface should support the following features:
<benediktniederma>
* Requesting gpio pins from userspace
<benediktniederma>
* Set input/output directions
<benediktniederma>
* Set BIAS settings (pull-up, pull-down, etc.)
<benediktniederma>
* Gpio function of that pin automatically gets muxed in if requested
<benediktniederma>
Requesting pins worked as expected after I added the required DTB properties:
<benediktniederma>
* pinctrl-single: Add each required pin to "pinctrl-single,gpio-range" in the pincontroller node
<benediktniederma>
* gpio: Add each required pin to gpio-range property in the gpio node
<benediktniederma>
I also added the required childnodes in the pinctrl node:
<benediktniederma>
The pinctrl-single driver highly depends on that information, which is not available at all wenn muxing with options 2&3.
<benediktniederma>
I was able to fix that for option 2 but not for option 3. The problem here is that the pcs_request_gpio() function simply does not provide
<benediktniederma>
sufficient parameters for achieving that task.
<benediktniederma>
I'm currently not sure how to proceed further here. But I think that issue has to be addresse sooner or later in order to completely support
<benediktniederma>
all the gpiochardev capabilities.
florian has quit [Ping timeout: 248 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
rob_w has quit [Quit: Leaving]
benediktniederma has quit [Quit: Client closed]
benediktniederma has joined #linux-ti
<benediktniederma>
ok it seems that my last message has been screwed up somehow.
<benediktniederma>
I'll paste it again in smaller parts....
<benediktniederma>
Hello. I would continue the discussion regarding the gpiochardev interface (maybe some of you participated this week).
<benediktniederma>
But for clarification I describe the issue here again...
<benediktniederma>
We encountered some issues when accessing the gpiochardev interface. The basic idea was to fully rely on all features the gpiochardev seems to offer. I got all relevant information from the Linux Kernel Documentation (Documentation/driver-api/pin-control.rst) and saw some presentations from Linus Walleij (Maintainer of linux-gpio).
<benediktniederma>
If I understand that correctly the gpiochardev interface should support the following features:
<benediktniederma>
* Requesting gpio pins from userspace
<benediktniederma>
* Set input/output directions
<benediktniederma>
* Set BIAS settings (pull-up, pull-down, etc.)
<benediktniederma>
* Gpio function of that pin automatically gets muxed in if requested
<benediktniederma>
Requesting pins worked as expected after I added the required DTB properties:
<benediktniederma>
* pinctrl-single: Add each required pin to "pinctrl-single,gpio-range" in the pincontroller node
<benediktniederma>
* gpio: Add each required pin to gpio-range property in the gpio node
<benediktniederma>
I also added the required childnodes in the pinctrl node:
<benediktniederma>
When I tried to set any BIAS settings nothing happened or some error occured in the kernel logs (i'm not 100% sure anymore since almost 2 months have past).
<benediktniederma>
The first thing I had to do was to assign the gpiochip_generic_config callback to the gpiochiop for that. This callback in turn will finally call pcs_pinconf_set(), which
<benediktniederma>
is the pinctrl drivers related callback for setting the pinconf.
<benediktniederma>
But still no success...
<benediktniederma>
Then I went deeper into the rabbit whole and encountered that the error had to do with pcs_get_function() (pinctrl-single.c).
<benediktniederma>
I found out that this function requests the current function (or pinmux state) from the pinctrl subsystem core.
<benediktniederma>
The pinctrl driver needs this information for accessing the correct pinctrl childnode.
<benediktniederma>
So what is the Problem here?
<benediktniederma>
The pinctrl offers 3 different possibilities/interfaces for muxing:
<benediktniederma>
1. Using the generic kernel APIs:
<benediktniederma>
Call pinctrl_select_state() function as stated in Documentation/driver-api/pin-control.rst (section "Pin control requests from drivers").
<benediktniederma>
This function will select a defined state which has been defined in DTB with "pinctrl-0", "pinctrl-1", "pinctrl-x"
<benediktniederma>
2. Mux pins with debugfs:
<benediktniederma>
Write the desired pingroup and pinfunction into the "pinmux-select" file of the related pin controller.
<benediktniederma>
3. Mux the GPIO function of a requested GPIO pin by calling the pinctrl drivers pcs_request_gpio() function.
<benediktniederma>
The problem now is that only option 1. will store the current mux information in the pinctrl subsystems core.
<benediktniederma>
The pinctrl-single driver highly depends on that information, which is not available at all wenn muxing with options 2&3.
<benediktniederma>
I was able to fix that for option 2 but not for option 3. The problem here is that the pcs_request_gpio() function simply does not provide
<benediktniederma>
sufficient parameters for achieving that task.
<benediktniederma>
I'm currently not sure how to proceed further here. But I think that issue has to be addresse sooner or later in order to completely support
<benediktniederma>
all the gpiochardev capabilities.
<benediktniederma>
I hope this messages have been submitted successfully now
benediktniederma has quit [Quit: Client closed]
ladis has quit [Quit: Leaving]
benediktniederma has joined #linux-ti
benediktniederma has quit [Quit: Client closed]
florian has joined #linux-ti
ikarso has joined #linux-ti
florian has quit [Ping timeout: 255 seconds]
florian has joined #linux-ti
florian has quit [Ping timeout: 276 seconds]
Kubu_work has quit [Quit: Leaving.]
ikarso has quit [Quit: Connection closed for inactivity]