Device tree - mux not working for wakeup domain GPIO?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Device tree - mux not working for wakeup domain GPIO?

Akram Hameed
Hi guys,

Strange one for you:

&omap3_pmx_wkup {
pushbutton2_pins: pinmux_pushbutton2_pins {
pinctrl-single,pins = <
OMAP3_WKUP_IOPAD(0x2a26, PIN_INPUT_PULLUP | MUX_MODE4)  /* jtag_emu1.gpio_31 */
>;
};
};

Basically I wanted the jtag_emu1 pad to give me a gpio, as an input, pulled up.  Exporting the GPIO gives me an input that is stuck low - and the problem is definitely not hardware (read on for why).

Dumping memory at that address shows me that I can in fact see that most of the set up worked. The pin pull select is up, pull UD enable is set, and the input enabled pin is set also...but the register shows that the pin is in fact just set to MODE0.

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

If I prepare this line using u-boot, everything works just fine...but I was hoping to avoid having to do that given device-tree works for darned near everything else. 

So: Has anyone else had any issues like this? There are no references to that register anywhere else in my device-tree hierarchy, so I can only conclude that the macro is failing for reasons unknown to me (which is confusing, because the code is very simple).

Cheers,

Akram

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Device tree - mux not working for wakeup domain GPIO?

nswieder

Sorry, I just saw you were doing the equivalent… still it might be worth trying it at run time…

 

Nicholas Wieder

Senior Electrical Engineer

 

From: Akram Hameed [mailto:[hidden email]]
Sent: Tuesday, May 03, 2016 01:06
To: General mailing list for gumstix users.
Subject: [Gumstix-users] Device tree - mux not working for wakeup domain GPIO?

 

Hi guys,

 

Strange one for you:

 

&omap3_pmx_wkup {

     pushbutton2_pins: pinmux_pushbutton2_pins {

          pinctrl-single,pins = <

          OMAP3_WKUP_IOPAD(0x2a26, PIN_INPUT_PULLUP | MUX_MODE4)  /* jtag_emu1.gpio_31 */

          >;

     };

};

 

Basically I wanted the jtag_emu1 pad to give me a gpio, as an input, pulled up.  Exporting the GPIO gives me an input that is stuck low - and the problem is definitely not hardware (read on for why).

 

Dumping memory at that address shows me that I can in fact see that most of the set up worked. The pin pull select is up, pull UD enable is set, and the input enabled pin is set also...but the register shows that the pin is in fact just set to MODE0.

 

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

 

If I prepare this line using u-boot, everything works just fine...but I was hoping to avoid having to do that given device-tree works for darned near everything else. 

 

So: Has anyone else had any issues like this? There are no references to that register anywhere else in my device-tree hierarchy, so I can only conclude that the macro is failing for reasons unknown to me (which is confusing, because the code is very simple).

 

Cheers,

 

Akram


NOTICE: This electronic communication, (including any attachments) is intended exclusively for the individuals or entities to which it is addressed. It may contain sensitive, restricted, or proprietary information. Any unauthorized disclosure, use, dissemination, or copying is strictly prohibited and may be unlawful. Furthermore, this communication may contain technical information that is subject to U.S. Export Control Laws, including the International Traffic in Arms Regulations (ITAR) or the Dept. of Commerce Export Administration Regulations (EAR). If so, transfer to a foreign national or representative of a foreign government or interest, even in the U.S., without prior Government authorization is prohibited and violation of such Export Control Laws is subject to significant penalties. If you have received this communication in error, please notify its sender immediately by replying and then permanently delete this communication from your IT system.  ­­  
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Device tree - mux not working for wakeup domain GPIO?

nswieder
In reply to this post by Akram Hameed

Have you tried ensuring that the pin is set as gpio?

 

for the address, see page 783 in the processer reference manual.  It shows it as the upper bits of 0x48002A24, so add 2.

 

devmem2 0x48002A26 h 0x11C

 

Nicholas Wieder

Senior Electrical Engineer

 

From: Akram Hameed [mailto:[hidden email]]
Sent: Tuesday, May 03, 2016 01:06
To: General mailing list for gumstix users.
Subject: [Gumstix-users] Device tree - mux not working for wakeup domain GPIO?

 

Hi guys,

 

Strange one for you:

 

&omap3_pmx_wkup {

     pushbutton2_pins: pinmux_pushbutton2_pins {

          pinctrl-single,pins = <

          OMAP3_WKUP_IOPAD(0x2a26, PIN_INPUT_PULLUP | MUX_MODE4)  /* jtag_emu1.gpio_31 */

          >;

     };

};

 

Basically I wanted the jtag_emu1 pad to give me a gpio, as an input, pulled up.  Exporting the GPIO gives me an input that is stuck low - and the problem is definitely not hardware (read on for why).

 

Dumping memory at that address shows me that I can in fact see that most of the set up worked. The pin pull select is up, pull UD enable is set, and the input enabled pin is set also...but the register shows that the pin is in fact just set to MODE0.

 

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

 

If I prepare this line using u-boot, everything works just fine...but I was hoping to avoid having to do that given device-tree works for darned near everything else. 

 

So: Has anyone else had any issues like this? There are no references to that register anywhere else in my device-tree hierarchy, so I can only conclude that the macro is failing for reasons unknown to me (which is confusing, because the code is very simple).

 

Cheers,

 

Akram


NOTICE: This electronic communication, (including any attachments) is intended exclusively for the individuals or entities to which it is addressed. It may contain sensitive, restricted, or proprietary information. Any unauthorized disclosure, use, dissemination, or copying is strictly prohibited and may be unlawful. Furthermore, this communication may contain technical information that is subject to U.S. Export Control Laws, including the International Traffic in Arms Regulations (ITAR) or the Dept. of Commerce Export Administration Regulations (EAR). If so, transfer to a foreign national or representative of a foreign government or interest, even in the U.S., without prior Government authorization is prohibited and violation of such Export Control Laws is subject to significant penalties. If you have received this communication in error, please notify its sender immediately by replying and then permanently delete this communication from your IT system.  ­­  
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Device tree - mux not working for wakeup domain GPIO?

Akram Hameed
Hi Nicholas,

I probably wasn't clear enough in my email:

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

By that, I meant, at runtime, I changed the mux mode bits and it worked just fine: for whatever reason, the macro I invoked that sets mux mode correctly on other pins did not for this one...

So I am at a loss. I can 'fix' the problem by muxing in u-boot, but I was sort of hoping to not have to do that.

Cheers,

Akram 

On Tue, May 3, 2016 at 10:59 PM, Nicholas S. Wieder <[hidden email]> wrote:

Have you tried ensuring that the pin is set as gpio?

 

for the address, see page 783 in the processer reference manual.  It shows it as the upper bits of 0x48002A24, so add 2.

 

devmem2 0x48002A26 h 0x11C

 

Nicholas Wieder

Senior Electrical Engineer

 

From: Akram Hameed [mailto:[hidden email]]
Sent: Tuesday, May 03, 2016 01:06
To: General mailing list for gumstix users.
Subject: [Gumstix-users] Device tree - mux not working for wakeup domain GPIO?

 

Hi guys,

 

Strange one for you:

 

&omap3_pmx_wkup {

     pushbutton2_pins: pinmux_pushbutton2_pins {

          pinctrl-single,pins = <

          OMAP3_WKUP_IOPAD(0x2a26, PIN_INPUT_PULLUP | MUX_MODE4)  /* jtag_emu1.gpio_31 */

          >;

     };

};

 

Basically I wanted the jtag_emu1 pad to give me a gpio, as an input, pulled up.  Exporting the GPIO gives me an input that is stuck low - and the problem is definitely not hardware (read on for why).

 

Dumping memory at that address shows me that I can in fact see that most of the set up worked. The pin pull select is up, pull UD enable is set, and the input enabled pin is set also...but the register shows that the pin is in fact just set to MODE0.

 

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

 

If I prepare this line using u-boot, everything works just fine...but I was hoping to avoid having to do that given device-tree works for darned near everything else. 

 

So: Has anyone else had any issues like this? There are no references to that register anywhere else in my device-tree hierarchy, so I can only conclude that the macro is failing for reasons unknown to me (which is confusing, because the code is very simple).

 

Cheers,

 

Akram


NOTICE: This electronic communication, (including any attachments) is intended exclusively for the individuals or entities to which it is addressed. It may contain sensitive, restricted, or proprietary information. Any unauthorized disclosure, use, dissemination, or copying is strictly prohibited and may be unlawful. Furthermore, this communication may contain technical information that is subject to U.S. Export Control Laws, including the International Traffic in Arms Regulations (ITAR) or the Dept. of Commerce Export Administration Regulations (EAR). If so, transfer to a foreign national or representative of a foreign government or interest, even in the U.S., without prior Government authorization is prohibited and violation of such Export Control Laws is subject to significant penalties. If you have received this communication in error, please notify its sender immediately by replying and then permanently delete this communication from your IT system.  ­­  

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|

Re: Device tree - mux not working for wakeup domain GPIO?

nswieder

Akram, sorry I can’t help… It’s been a while since I’ve even tried to update things in u-boot/kernel. 

 

Nicholas Wieder

Senior Electrical Engineer

 

From: Akram Hameed [mailto:[hidden email]]
Sent: Tuesday, May 03, 2016 18:50
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] Device tree - mux not working for wakeup domain GPIO?

 

Hi Nicholas,

 

I probably wasn't clear enough in my email:

 

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

 

By that, I meant, at runtime, I changed the mux mode bits and it worked just fine: for whatever reason, the macro I invoked that sets mux mode correctly on other pins did not for this one...

 

So I am at a loss. I can 'fix' the problem by muxing in u-boot, but I was sort of hoping to not have to do that.

 

Cheers,

 

Akram 

 

On Tue, May 3, 2016 at 10:59 PM, Nicholas S. Wieder <[hidden email]> wrote:

Have you tried ensuring that the pin is set as gpio?

 

for the address, see page 783 in the processer reference manual.  It shows it as the upper bits of 0x48002A24, so add 2.

 

devmem2 0x48002A26 h 0x11C

 

Nicholas Wieder

Senior Electrical Engineer

 

From: Akram Hameed [mailto:[hidden email]]
Sent: Tuesday, May 03, 2016 01:06
To: General mailing list for gumstix users.
Subject: [Gumstix-users] Device tree - mux not working for wakeup domain GPIO?

 

Hi guys,

 

Strange one for you:

 

&omap3_pmx_wkup {

     pushbutton2_pins: pinmux_pushbutton2_pins {

          pinctrl-single,pins = <

          OMAP3_WKUP_IOPAD(0x2a26, PIN_INPUT_PULLUP | MUX_MODE4)  /* jtag_emu1.gpio_31 */

          >;

     };

};

 

Basically I wanted the jtag_emu1 pad to give me a gpio, as an input, pulled up.  Exporting the GPIO gives me an input that is stuck low - and the problem is definitely not hardware (read on for why).

 

Dumping memory at that address shows me that I can in fact see that most of the set up worked. The pin pull select is up, pull UD enable is set, and the input enabled pin is set also...but the register shows that the pin is in fact just set to MODE0.

 

If I then twiddle a bit so that the register is set to MODE4, everything works as expected.

 

If I prepare this line using u-boot, everything works just fine...but I was hoping to avoid having to do that given device-tree works for darned near everything else. 

 

So: Has anyone else had any issues like this? There are no references to that register anywhere else in my device-tree hierarchy, so I can only conclude that the macro is failing for reasons unknown to me (which is confusing, because the code is very simple).

 

Cheers,

 

Akram


NOTICE: This electronic communication, (including any attachments) is intended exclusively for the individuals or entities to which it is addressed. It may contain sensitive, restricted, or proprietary information. Any unauthorized disclosure, use, dissemination, or copying is strictly prohibited and may be unlawful. Furthermore, this communication may contain technical information that is subject to U.S. Export Control Laws, including the International Traffic in Arms Regulations (ITAR) or the Dept. of Commerce Export Administration Regulations (EAR). If so, transfer to a foreign national or representative of a foreign government or interest, even in the U.S., without prior Government authorization is prohibited and violation of such Export Control Laws is subject to significant penalties. If you have received this communication in error, please notify its sender immediately by replying and then permanently delete this communication from your IT system.  ­­  


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

 


NOTICE: This electronic communication, (including any attachments) is intended exclusively for the individuals or entities to which it is addressed. It may contain sensitive, restricted, or proprietary information. Any unauthorized disclosure, use, dissemination, or copying is strictly prohibited and may be unlawful. Furthermore, this communication may contain technical information that is subject to U.S. Export Control Laws, including the International Traffic in Arms Regulations (ITAR) or the Dept. of Commerce Export Administration Regulations (EAR). If so, transfer to a foreign national or representative of a foreign government or interest, even in the U.S., without prior Government authorization is prohibited and violation of such Export Control Laws is subject to significant penalties. If you have received this communication in error, please notify its sender immediately by replying and then permanently delete this communication from your IT system.  ­­  
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users