From: Jonas Jensen <jonas.jensen@gmail.com> To: Linus Walleij <linus.walleij@linaro.org> Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>, Grant Likely <grant.likely@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "arm@kernel.org" <arm@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Subject: Re: [PATCH v5] gpio: Add MOXA ART GPIO driver Date: Mon, 14 Oct 2013 13:15:28 +0200 [thread overview] Message-ID: <CACmBeS1NoyHWhS5ydONf3x_z8SQu5-vh_XzMazuY9-uYXdg_wQ@mail.gmail.com> (raw) In-Reply-To: <CACRpkda23nUF8i03RWePj+dGa9Wj6E1L8vfPMfxvnGkazfKS5w@mail.gmail.com> Thank you for the replies. On 11 October 2013 17:44, Linus Walleij <linus.walleij@linaro.org> wrote: >> The register responsible for doing enable/disable is located >> at <0x98100100 0x4>, the clock register is very close at >> <0x98100000 0x34>. > > If we don't know we have to guess. > > This layout makes me think that the IO-window at 0x98100000 is > a power-clock-and-reset controller. It contains some register > to latch the pins enable/disable them, or if this is even a clock > gate? Are you sure about this? Is it now a gated clock, simply, > so that this bit should be handled in the clock driver, i.e. > this bit gets set by clk_enable() from the GPIO driver? The IO-window at 0x98100000 contains registers that are read to determine PLL and APB clock frequencies. Sorry I don't know more than that. This is part of a pending patch adding the clock driver: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203494.html Arnd made a similar comment suggesting syscon back when MMC mapped the same register: https://groups.google.com/d/msg/linux.kernel/eeS7vhMWMAc/zNYhzyKilh8J I think I prefer to have this in the clock driver opposed to using syscon. The one downside I can see, individual control of the pins would be lost? Does it make sense to enable all pins once? this is acceptable for at least UC-7112-LX, it doesn't need to disable/enable pins beyond the initial clk_enable(). I say the above because I currently have nothing that requires individual pin control. However, I removed one line from MMC that turned out to be unnecessary. That line directly access the "PMU" register disabling pins 10-17 with the following comment: " /* change I/O multiplexing to SD, so the GPIO 17-10 will be fail */ moxart_gpio_mp_clear(0xff << 10); " http://code.google.com/p/linux-2-6-9-moxart/source/browse/drivers/mmc/host/moxasd.c#619 >> I don't think gpio_poweroff driver is right for this hardware >> because the pin is not connected to anything that can do reset. >> The old 2.6.9 kernel driver uses timer poll with eventual call >> to userspace. >> >> To test that it works, I added gpio_poweroff anyway, modified >> with gpio_export() the pin can then be seen switching between >> 0 and 1 (on "cat /sys/class/gpio/gpio25/value"). > > Hmmmm not quite following this... I'll try to elaborate. What happens in gpio_poweroff driver does not look like something that can reset the hardware. Reset on UC-7112-LX is implemented using the same register as the watchdog, in platform code hooked up to arm_pm_restart. The old sources "solved" this by polling the reset pin with eventual call_usermodehelper (/sbin/reboot): http://code.google.com/p/linux-2-6-9-moxart/source/browse/drivers/char/moxa_watchdog.c#174 What was previously in a kernel driver, would now be solved in userspace? gpio_export() allowed me to verify the pin number, pressing reset toggles the value. Adding the gpio-leds driver, that pin was automatically exported to sysfs, that got me thinking: How do I export the reset button to sysfs? Should gpio_export() be added to platform code? from drivers/power/reset/gpio-poweroff.c: static void gpio_poweroff_do_poweroff(void) { BUG_ON(!gpio_is_valid(gpio_num)); /* drive it active, also inactive->active edge */ gpio_direction_output(gpio_num, !gpio_active_low); mdelay(100); /* drive inactive, also active->inactive edge */ gpio_set_value(gpio_num, gpio_active_low); mdelay(100); /* drive it active, also inactive->active edge */ gpio_set_value(gpio_num, !gpio_active_low); /* give it some time */ mdelay(3000); WARN_ON(1); } Regards, Jonas
WARNING: multiple messages have this Message-ID (diff)
From: jonas.jensen@gmail.com (Jonas Jensen) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v5] gpio: Add MOXA ART GPIO driver Date: Mon, 14 Oct 2013 13:15:28 +0200 [thread overview] Message-ID: <CACmBeS1NoyHWhS5ydONf3x_z8SQu5-vh_XzMazuY9-uYXdg_wQ@mail.gmail.com> (raw) In-Reply-To: <CACRpkda23nUF8i03RWePj+dGa9Wj6E1L8vfPMfxvnGkazfKS5w@mail.gmail.com> Thank you for the replies. On 11 October 2013 17:44, Linus Walleij <linus.walleij@linaro.org> wrote: >> The register responsible for doing enable/disable is located >> at <0x98100100 0x4>, the clock register is very close at >> <0x98100000 0x34>. > > If we don't know we have to guess. > > This layout makes me think that the IO-window at 0x98100000 is > a power-clock-and-reset controller. It contains some register > to latch the pins enable/disable them, or if this is even a clock > gate? Are you sure about this? Is it now a gated clock, simply, > so that this bit should be handled in the clock driver, i.e. > this bit gets set by clk_enable() from the GPIO driver? The IO-window at 0x98100000 contains registers that are read to determine PLL and APB clock frequencies. Sorry I don't know more than that. This is part of a pending patch adding the clock driver: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203494.html Arnd made a similar comment suggesting syscon back when MMC mapped the same register: https://groups.google.com/d/msg/linux.kernel/eeS7vhMWMAc/zNYhzyKilh8J I think I prefer to have this in the clock driver opposed to using syscon. The one downside I can see, individual control of the pins would be lost? Does it make sense to enable all pins once? this is acceptable for at least UC-7112-LX, it doesn't need to disable/enable pins beyond the initial clk_enable(). I say the above because I currently have nothing that requires individual pin control. However, I removed one line from MMC that turned out to be unnecessary. That line directly access the "PMU" register disabling pins 10-17 with the following comment: " /* change I/O multiplexing to SD, so the GPIO 17-10 will be fail */ moxart_gpio_mp_clear(0xff << 10); " http://code.google.com/p/linux-2-6-9-moxart/source/browse/drivers/mmc/host/moxasd.c#619 >> I don't think gpio_poweroff driver is right for this hardware >> because the pin is not connected to anything that can do reset. >> The old 2.6.9 kernel driver uses timer poll with eventual call >> to userspace. >> >> To test that it works, I added gpio_poweroff anyway, modified >> with gpio_export() the pin can then be seen switching between >> 0 and 1 (on "cat /sys/class/gpio/gpio25/value"). > > Hmmmm not quite following this... I'll try to elaborate. What happens in gpio_poweroff driver does not look like something that can reset the hardware. Reset on UC-7112-LX is implemented using the same register as the watchdog, in platform code hooked up to arm_pm_restart. The old sources "solved" this by polling the reset pin with eventual call_usermodehelper (/sbin/reboot): http://code.google.com/p/linux-2-6-9-moxart/source/browse/drivers/char/moxa_watchdog.c#174 What was previously in a kernel driver, would now be solved in userspace? gpio_export() allowed me to verify the pin number, pressing reset toggles the value. Adding the gpio-leds driver, that pin was automatically exported to sysfs, that got me thinking: How do I export the reset button to sysfs? Should gpio_export() be added to platform code? from drivers/power/reset/gpio-poweroff.c: static void gpio_poweroff_do_poweroff(void) { BUG_ON(!gpio_is_valid(gpio_num)); /* drive it active, also inactive->active edge */ gpio_direction_output(gpio_num, !gpio_active_low); mdelay(100); /* drive inactive, also active->inactive edge */ gpio_set_value(gpio_num, gpio_active_low); mdelay(100); /* drive it active, also inactive->active edge */ gpio_set_value(gpio_num, !gpio_active_low); /* give it some time */ mdelay(3000); WARN_ON(1); } Regards, Jonas
next prev parent reply other threads:[~2013-10-14 11:15 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-10 13:49 [PATCH] gpio: Add MOXA ART GPIO driver Jonas Jensen 2013-07-10 13:49 ` Jonas Jensen 2013-07-16 12:00 ` [PATCH v2] " Jonas Jensen 2013-07-16 12:00 ` Jonas Jensen 2013-07-17 9:34 ` [PATCH v3] " Jonas Jensen 2013-07-17 9:34 ` Jonas Jensen 2013-07-29 13:06 ` [PATCH v4] " Jonas Jensen 2013-07-29 13:06 ` Jonas Jensen 2013-08-02 11:34 ` Mark Rutland 2013-08-02 11:34 ` Mark Rutland 2013-08-16 14:05 ` Linus Walleij 2013-08-16 14:05 ` Linus Walleij 2013-08-16 14:05 ` Linus Walleij 2013-10-11 14:53 ` [PATCH v5] " Jonas Jensen 2013-10-11 14:53 ` Jonas Jensen 2013-10-11 15:44 ` Linus Walleij 2013-10-11 15:44 ` Linus Walleij 2013-10-11 15:44 ` Linus Walleij 2013-10-14 11:15 ` Jonas Jensen [this message] 2013-10-14 11:15 ` Jonas Jensen 2013-10-14 11:15 ` Jonas Jensen 2013-10-17 9:24 ` Linus Walleij 2013-10-17 9:24 ` Linus Walleij 2013-10-17 9:24 ` Linus Walleij 2013-11-28 15:19 ` [PATCH v6] " Jonas Jensen 2013-11-28 15:19 ` Jonas Jensen 2013-11-28 16:37 ` Arnd Bergmann 2013-11-28 16:37 ` Arnd Bergmann 2013-11-29 20:21 ` Linus Walleij 2013-11-29 20:21 ` Linus Walleij 2013-11-29 20:21 ` Linus Walleij 2013-11-29 21:45 ` Arnd Bergmann 2013-11-29 21:45 ` Arnd Bergmann 2013-11-29 21:45 ` Arnd Bergmann 2013-11-29 11:11 ` [PATCH v7] " Jonas Jensen 2013-11-29 11:11 ` Jonas Jensen [not found] ` <1385723494-8033-1-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2013-11-29 19:06 ` Arnd Bergmann 2013-11-29 19:06 ` Arnd Bergmann 2013-11-29 19:06 ` Arnd Bergmann 2013-11-29 20:29 ` Linus Walleij 2013-11-29 20:29 ` Linus Walleij 2013-11-29 20:29 ` Linus Walleij 2013-12-02 10:27 ` [PATCH] gpio: MOXA ART: rename moxart_gpio_base to base Jonas Jensen 2013-12-02 10:27 ` Jonas Jensen [not found] ` <1385980079-20175-1-git-send-email-jonas.jensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2013-12-04 12:28 ` Linus Walleij 2013-12-04 12:28 ` Linus Walleij 2013-12-04 12:28 ` Linus Walleij
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=CACmBeS1NoyHWhS5ydONf3x_z8SQu5-vh_XzMazuY9-uYXdg_wQ@mail.gmail.com \ --to=jonas.jensen@gmail.com \ --cc=arm@kernel.org \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ /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.