From: Tony Lindgren <tony@atomide.com> To: Pavel Machek <pavel@ucw.cz> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>, pali.rohar@gmail.com, kernel list <linux-kernel@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, linux-omap@vger.kernel.org Subject: Re: N900 device tree conversion: how to do first step Date: Thu, 13 Jun 2013 22:56:29 -0700 [thread overview] Message-ID: <20130614055629.GM8164@atomide.com> (raw) In-Reply-To: <20130613230808.GA14876@amd.pavel.ucw.cz> * Pavel Machek <pavel@ucw.cz> [130613 16:14]: > Hi! > > > > Now, by chance, any idea what is DT equivalent of > > > > > > omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); > > > > You can try the attached hack after calling the above to grep for > > pins in /sys/kernel/debug/omap_mux/board/core and you get the pins > > in DT suitable format. There's a bug where the the pins are not > > correctly split between core and wkup domains in the legacy mux fwk, > > but you probably won't need to mux many wkup domain pins. > > > > Then you just need to add the pinctr-single entries for each device, > > but AFAIK most of the pins are muxed correctly in the bootloader > > for the Nokia boards. > > Thanks a lot for the help. So far, I'm not playing with > suspend/resume, so wkup/core split should not be issue (right?). Well if you have any wkup mux registers mapped for core mux, pinctrl-single will complain about offset being out of range and not set the values. You can see that in dmesg, or at least with CONFIG_DEBUG_PINCTRL set. > How does it work with the devices? AFAICT omap4 groups it logically, > but that's just for easy reading, no? No, there really are two instances of mux registers even on omap3, but I missed that earlier while reading the docs, and with the legacy mux framework it does not matter which mux domain it is. But it matters for pinctrl-single as it ioremaps the ranges separately. > I tried this, but no luck, mux is not initialized correctly, so code > in board-rx51-video fails, and later fbcon crashes. > > Any ideas? You may have some wkup mux domain offsets in your .dts file, so pinctrl-single will abort the muxing. > --- a/arch/arm/boot/dts/omap3-n900.dts > +++ b/arch/arm/boot/dts/omap3-n900.dts > @@ -81,3 +81,218 @@ > power = <50>; > }; > */ > + > + > + > +&omap3_pmx_core { > + pinctrl-names = "default"; > + pinctrl-0 = < > + &all_pins > + >; > + > + all_pins: pinmux_all_pins { > + pinctrl-single,pins = < > + 0xe6 0x4104 /* cam_d0.gpio_99 gpio99 INPUT | OFF_WAKEUPENABLE | MODE4 */ > + 0xe8 0x11c /* cam_d1.gpio_100 gpio100 INPUT_PULLUP | MODE4 */ > + 0xfa 0x7 /* cam_d10.safe_mode gpio109 OUTPUT | MODE7 */ ... This is not a good way of doing muxing, hogging all the pins under omap3_pmx_core will make it impossible to unload pinctrl-single as a module, which is not nice for distros and developers. Further, if some pins need dynamic remuxing, we can't do it in the device driver for the device. For n900, dynamic remuxing needs to be done for eMMC at least, see rx51_mmc2_remux(). Also, see the recent patches that Benoit has queued to use the preprocessor for the .dts files, we should modify the legacy mux dump hack to output the mux mode defines instead. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: N900 device tree conversion: how to do first step Date: Thu, 13 Jun 2013 22:56:29 -0700 [thread overview] Message-ID: <20130614055629.GM8164@atomide.com> (raw) In-Reply-To: <20130613230808.GA14876@amd.pavel.ucw.cz> * Pavel Machek <pavel@ucw.cz> [130613 16:14]: > Hi! > > > > Now, by chance, any idea what is DT equivalent of > > > > > > omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); > > > > You can try the attached hack after calling the above to grep for > > pins in /sys/kernel/debug/omap_mux/board/core and you get the pins > > in DT suitable format. There's a bug where the the pins are not > > correctly split between core and wkup domains in the legacy mux fwk, > > but you probably won't need to mux many wkup domain pins. > > > > Then you just need to add the pinctr-single entries for each device, > > but AFAIK most of the pins are muxed correctly in the bootloader > > for the Nokia boards. > > Thanks a lot for the help. So far, I'm not playing with > suspend/resume, so wkup/core split should not be issue (right?). Well if you have any wkup mux registers mapped for core mux, pinctrl-single will complain about offset being out of range and not set the values. You can see that in dmesg, or at least with CONFIG_DEBUG_PINCTRL set. > How does it work with the devices? AFAICT omap4 groups it logically, > but that's just for easy reading, no? No, there really are two instances of mux registers even on omap3, but I missed that earlier while reading the docs, and with the legacy mux framework it does not matter which mux domain it is. But it matters for pinctrl-single as it ioremaps the ranges separately. > I tried this, but no luck, mux is not initialized correctly, so code > in board-rx51-video fails, and later fbcon crashes. > > Any ideas? You may have some wkup mux domain offsets in your .dts file, so pinctrl-single will abort the muxing. > --- a/arch/arm/boot/dts/omap3-n900.dts > +++ b/arch/arm/boot/dts/omap3-n900.dts > @@ -81,3 +81,218 @@ > power = <50>; > }; > */ > + > + > + > +&omap3_pmx_core { > + pinctrl-names = "default"; > + pinctrl-0 = < > + &all_pins > + >; > + > + all_pins: pinmux_all_pins { > + pinctrl-single,pins = < > + 0xe6 0x4104 /* cam_d0.gpio_99 gpio99 INPUT | OFF_WAKEUPENABLE | MODE4 */ > + 0xe8 0x11c /* cam_d1.gpio_100 gpio100 INPUT_PULLUP | MODE4 */ > + 0xfa 0x7 /* cam_d10.safe_mode gpio109 OUTPUT | MODE7 */ ... This is not a good way of doing muxing, hogging all the pins under omap3_pmx_core will make it impossible to unload pinctrl-single as a module, which is not nice for distros and developers. Further, if some pins need dynamic remuxing, we can't do it in the device driver for the device. For n900, dynamic remuxing needs to be done for eMMC at least, see rx51_mmc2_remux(). Also, see the recent patches that Benoit has queued to use the preprocessor for the .dts files, we should modify the legacy mux dump hack to output the mux mode defines instead. Regards, Tony
next prev parent reply other threads:[~2013-06-14 5:56 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-06-09 1:59 N900 device tree conversion: how to do first step Pavel Machek 2013-06-09 1:59 ` Pavel Machek 2013-06-09 9:24 ` Pali Rohár 2013-06-09 9:24 ` Pali Rohár 2013-06-09 16:47 ` Pavel Machek 2013-06-09 16:47 ` Pavel Machek 2013-06-09 17:03 ` Pali Rohár 2013-06-09 17:03 ` Pali Rohár 2013-06-09 17:03 ` Pali Rohár 2013-06-09 17:30 ` Pavel Machek 2013-06-09 17:30 ` Pavel Machek 2013-06-09 20:11 ` Aaro Koskinen 2013-06-09 20:11 ` Aaro Koskinen 2013-06-13 13:26 ` Pavel Machek 2013-06-13 13:26 ` Pavel Machek 2013-06-13 14:10 ` Tony Lindgren 2013-06-13 14:10 ` Tony Lindgren 2013-06-13 14:28 ` Pavel Machek 2013-06-13 14:28 ` Pavel Machek 2013-06-13 14:57 ` Tony Lindgren 2013-06-13 14:57 ` Tony Lindgren 2013-06-13 15:52 ` Pavel Machek 2013-06-13 15:52 ` Pavel Machek 2013-06-13 16:14 ` Tony Lindgren 2013-06-13 16:14 ` Tony Lindgren 2013-06-13 23:08 ` Pavel Machek 2013-06-13 23:08 ` Pavel Machek 2013-06-14 5:56 ` Tony Lindgren [this message] 2013-06-14 5:56 ` Tony Lindgren 2013-06-14 21:28 ` Pavel Machek 2013-06-14 21:28 ` Pavel Machek 2013-06-17 11:10 ` Tony Lindgren 2013-06-17 11:10 ` Tony Lindgren 2013-06-27 12:12 ` N900 device tree conversion: next steps Pavel Machek 2013-07-01 14:03 ` [PATCH] N900: fix operation on emulator Pavel Machek 2013-07-01 14:03 ` Pavel Machek 2013-07-01 18:22 ` Sergei Shtylyov 2013-07-01 18:22 ` Sergei Shtylyov 2013-07-01 18:22 ` Sergei Shtylyov 2013-07-01 19:51 ` Pavel Machek 2013-07-01 19:51 ` Pavel Machek 2013-07-01 20:00 ` Sergei Shtylyov 2013-07-01 20:00 ` Sergei Shtylyov 2013-07-01 20:53 ` Pavel Machek 2013-07-01 20:53 ` Pavel Machek 2013-07-01 21:15 ` [PATCH] N900: enable N900-specific drivers even if device tree is enabled Pavel Machek 2013-07-01 21:15 ` Pavel Machek 2013-07-04 11:47 ` Tony Lindgren 2013-07-04 11:47 ` Tony Lindgren 2013-07-01 21:17 ` [PATCH] N900: add device tree Pavel Machek 2013-07-01 21:17 ` Pavel Machek 2013-07-04 17:19 ` Aaro Koskinen 2013-07-04 17:19 ` Aaro Koskinen 2013-07-04 20:21 ` Pavel Machek 2013-07-04 20:21 ` Pavel Machek 2013-07-04 20:32 ` Aaro Koskinen 2013-07-04 20:32 ` Aaro Koskinen 2013-07-13 12:17 ` [PATCH v2] " Pavel Machek 2013-07-13 12:17 ` Pavel Machek 2013-07-14 22:28 ` Aaro Koskinen 2013-07-14 22:28 ` Aaro Koskinen 2013-07-28 13:44 ` Pavel Machek 2013-07-28 13:44 ` Pavel Machek 2013-08-01 23:43 ` Pavel Machek 2013-08-01 23:43 ` Pavel Machek 2013-08-10 11:09 ` Pavel Machek 2013-08-10 11:09 ` Pavel Machek 2013-08-10 11:09 ` Pavel Machek 2013-08-10 11:27 ` [PATCH] ARM: dts: omap3 / n900 support, Benoit please take me (was Re: [PATCH v2] N900: add device tree) Pavel Machek 2013-08-10 11:27 ` Pavel Machek 2013-08-10 11:46 ` [PATCH v2] N900: add device tree Belisko Marek 2013-08-10 11:46 ` Belisko Marek 2013-08-10 20:29 ` Jiri Kosina 2013-08-10 20:29 ` Jiri Kosina 2013-08-11 0:55 ` OMAP device tree maintainance (was Re: [PATCH v2] N900: add device tree) Pavel Machek 2013-08-11 0:55 ` Pavel Machek 2013-08-11 11:50 ` [PATCH v2] N900: add device tree Javier Martinez Canillas 2013-08-11 11:50 ` Javier Martinez Canillas 2013-08-11 13:47 ` Pavel Machek 2013-08-11 13:47 ` Pavel Machek 2013-08-11 13:47 ` Pavel Machek 2013-08-12 7:37 ` Tony Lindgren 2013-08-12 7:37 ` Tony Lindgren 2013-08-12 7:36 ` Tony Lindgren 2013-08-12 7:36 ` Tony Lindgren 2013-08-11 15:02 ` Javier Martinez Canillas 2013-08-11 15:02 ` Javier Martinez Canillas 2013-08-13 10:50 ` Benoit Cousson 2013-08-13 10:50 ` Benoit Cousson 2013-08-13 13:36 ` [PATCH v3] " Pavel Machek 2013-08-13 13:36 ` Pavel Machek 2013-08-13 14:06 ` Benoit Cousson 2013-08-13 14:06 ` Benoit Cousson 2013-06-26 15:14 ` N900 device tree conversion: first step Pavel Machek 2013-07-19 18:14 ` N900 device tree conversion: how to do " Sebastian Reichel 2013-07-19 18:14 ` Sebastian Reichel 2013-07-19 18:14 ` Sebastian Reichel 2013-07-28 13:37 ` Pavel Machek 2013-07-28 13:37 ` Pavel Machek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130614055629.GM8164@atomide.com \ --to=tony@atomide.com \ --cc=aaro.koskinen@iki.fi \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=pali.rohar@gmail.com \ --cc=pavel@ucw.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.