NishanthMenon changed the topic of #linux-ti to: Linux development for TI SoCs | Logs: https://libera.irclog.whitequark.org/linux-ti/| paste logs in https://pastebin.ubuntu.com/ | Let it rock! Vendor SDK/kernel: Also see e2e.ti.com
florian has quit [Ping timeout: 250 seconds]
RaviG has joined #linux-ti
ikarso has joined #linux-ti
vigneshr has quit []
vigneshr has joined #linux-ti
rob_w has joined #linux-ti
ladis has joined #linux-ti
rogerq has joined #linux-ti
Kubu_work has joined #linux-ti
florian has joined #linux-ti
<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> &main_pmx0 {
<benediktniederma>   ...
<benediktniederma>    d6_gpio: d6-gpio {
<benediktniederma>   pinctrl-single,pins = <
<benediktniederma>    /* (AH16) GPIO0_38 */
<benediktniederma>    AM65X_IOPAD(0x0098, PIN_INPUT, 7)
<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> &main_pmx0 {
<benediktniederma>   ...
<benediktniederma>    d6_gpio: d6-gpio {
<benediktniederma>   pinctrl-single,pins = <
<benediktniederma>    /* (AH16) GPIO0_38 */
<benediktniederma>    AM65X_IOPAD(0x0098, PIN_INPUT, 7)
<benediktniederma>   >;
<benediktniederma>   pinctrl-single,bias-pullup = <0x20000 0x20000 0x10000 0x30000>;
<benediktniederma>   pinctrl-single,bias-pulldown = <0x00000 0x0 0x10000 0x30000>;
<benediktniederma>  };
<benediktniederma> ...
<benediktniederma> }
<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]