From: Tony Lindgren <tony@atomide.com> To: Stephen Warren <swarren@wwwdotorg.org> Cc: linus.walleij@linaro.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states Date: Thu, 18 Jul 2013 06:48:07 -0700 [thread overview] Message-ID: <20130718134806.GW7656@atomide.com> (raw) In-Reply-To: <20130718074508.GQ7656@atomide.com> * Tony Lindgren <tony@atomide.com> [130718 00:57]: > * Stephen Warren <swarren@wwwdotorg.org> [130717 14:28]: > > > > Oh, I see you're trying to check that the set of pins in the active, > > sleep, and idle states are identical. > > Right, that's to avoid any further checking during runtime for runtime PM. > > > But I think that pinctrl_check_dynamic() only checks that one state is a > > subset of the other, not that the two states are equal. Instead, I think > > you want to comparison coded in pinctrl_check_dynamic() to be: > > In pinctrl_check_dynamic() we check that the pins match between the > states, and the number of found pins matches the first set. I'll > take a look if we check the total pins between the two sets. That that is a bit painful right now to check properly as we don't have any sorting, and we could use that elsewhere too for checks probably.. > > gen_group_list_of_pinctrl_state(s1, array1); > > gen_group_list_of_pinctrl_state(s2, array2); > > mismatch = memcmp(array1, array2, length); > > Well we could allocate and sort the pins, but the number of pins > for runtime PM is typically very small for each pin consumer device. > Typically you just need to toggle RX pin to GPIO mode for idle. And > this check is only done during consumer driver probe time. So > optimizing it for larger sets could be done at any point later on > as needed. ..so for now, let's just check the total number of pins for the sets like Felipe suggested. I think we're better off improving the pinctrl data first to make various checks easier. What you're suggesting with the mepcmp() can be done easily if we add something like device_get_pins() and have the pins sorted for the various states for a device at the device probe time. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states Date: Thu, 18 Jul 2013 06:48:07 -0700 [thread overview] Message-ID: <20130718134806.GW7656@atomide.com> (raw) In-Reply-To: <20130718074508.GQ7656@atomide.com> * Tony Lindgren <tony@atomide.com> [130718 00:57]: > * Stephen Warren <swarren@wwwdotorg.org> [130717 14:28]: > > > > Oh, I see you're trying to check that the set of pins in the active, > > sleep, and idle states are identical. > > Right, that's to avoid any further checking during runtime for runtime PM. > > > But I think that pinctrl_check_dynamic() only checks that one state is a > > subset of the other, not that the two states are equal. Instead, I think > > you want to comparison coded in pinctrl_check_dynamic() to be: > > In pinctrl_check_dynamic() we check that the pins match between the > states, and the number of found pins matches the first set. I'll > take a look if we check the total pins between the two sets. That that is a bit painful right now to check properly as we don't have any sorting, and we could use that elsewhere too for checks probably.. > > gen_group_list_of_pinctrl_state(s1, array1); > > gen_group_list_of_pinctrl_state(s2, array2); > > mismatch = memcmp(array1, array2, length); > > Well we could allocate and sort the pins, but the number of pins > for runtime PM is typically very small for each pin consumer device. > Typically you just need to toggle RX pin to GPIO mode for idle. And > this check is only done during consumer driver probe time. So > optimizing it for larger sets could be done at any point later on > as needed. ..so for now, let's just check the total number of pins for the sets like Felipe suggested. I think we're better off improving the pinctrl data first to make various checks easier. What you're suggesting with the mepcmp() can be done easily if we add something like device_get_pins() and have the pins sorted for the various states for a device at the device probe time. Regards, Tony
next prev parent reply other threads:[~2013-07-18 13:48 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-16 9:05 [PATCH 0/4] improved support for runtime muxing for pinctrl Tony Lindgren 2013-07-16 9:05 ` Tony Lindgren 2013-07-16 9:05 ` [PATCH 1/4] pinctrl: Remove duplicate code in pinctrl_pm_select_state functions Tony Lindgren 2013-07-16 9:05 ` Tony Lindgren 2013-07-16 13:15 ` Grygorii Strashko 2013-07-16 13:15 ` Grygorii Strashko 2013-07-16 13:15 ` Grygorii Strashko 2013-07-16 13:41 ` Tony Lindgren 2013-07-16 13:41 ` Tony Lindgren 2013-07-16 14:25 ` Grygorii Strashko 2013-07-16 14:25 ` Grygorii Strashko 2013-07-16 14:25 ` Grygorii Strashko 2013-07-17 6:31 ` Tony Lindgren 2013-07-17 6:31 ` Tony Lindgren 2013-07-16 9:05 ` [PATCH 2/4] pinctrl: Allow pinctrl to have multiple active states Tony Lindgren 2013-07-16 9:05 ` Tony Lindgren 2013-07-17 20:55 ` Stephen Warren 2013-07-17 20:55 ` Stephen Warren 2013-07-16 9:05 ` [PATCH 3/4] pinctrl: Add support for additional dynamic states Tony Lindgren 2013-07-16 9:05 ` Tony Lindgren 2013-07-16 9:35 ` Felipe Balbi 2013-07-16 9:35 ` Felipe Balbi 2013-07-16 9:35 ` Felipe Balbi 2013-07-16 12:06 ` Tony Lindgren 2013-07-16 12:06 ` Tony Lindgren 2013-07-17 21:14 ` Stephen Warren 2013-07-17 21:14 ` Stephen Warren 2013-07-18 7:25 ` Tony Lindgren 2013-07-18 7:25 ` Tony Lindgren 2013-07-18 10:53 ` Tony Lindgren 2013-07-18 10:53 ` Tony Lindgren 2013-07-18 19:21 ` Stephen Warren 2013-07-18 19:21 ` Stephen Warren 2013-07-19 7:29 ` Tony Lindgren 2013-07-19 7:29 ` Tony Lindgren 2013-07-19 18:52 ` Stephen Warren 2013-07-19 18:52 ` Stephen Warren 2013-07-29 9:05 ` Tony Lindgren 2013-07-29 9:05 ` Tony Lindgren 2013-07-29 22:01 ` Stephen Warren 2013-07-29 22:01 ` Stephen Warren 2013-08-14 16:41 ` Linus Walleij 2013-08-14 16:41 ` Linus Walleij 2013-08-14 16:41 ` Linus Walleij 2013-07-17 21:23 ` Stephen Warren 2013-07-17 21:23 ` Stephen Warren 2013-07-18 7:36 ` Tony Lindgren 2013-07-18 7:36 ` Tony Lindgren 2013-07-18 19:26 ` Stephen Warren 2013-07-18 19:26 ` Stephen Warren 2013-07-19 7:39 ` Tony Lindgren 2013-07-19 7:39 ` Tony Lindgren 2013-07-19 10:29 ` Grygorii Strashko 2013-07-19 10:29 ` Grygorii Strashko 2013-07-19 10:29 ` Grygorii Strashko 2013-07-19 19:03 ` Stephen Warren 2013-07-19 19:03 ` Stephen Warren 2013-07-22 23:15 ` Linus Walleij 2013-07-22 23:15 ` Linus Walleij 2013-07-22 23:15 ` Linus Walleij 2013-07-29 9:08 ` Tony Lindgren 2013-07-29 9:08 ` Tony Lindgren 2013-07-19 18:58 ` Stephen Warren 2013-07-19 18:58 ` Stephen Warren 2013-07-29 9:21 ` Tony Lindgren 2013-07-29 9:21 ` Tony Lindgren 2013-07-29 22:08 ` Stephen Warren 2013-07-29 22:08 ` Stephen Warren 2013-07-22 23:07 ` Linus Walleij 2013-07-22 23:07 ` Linus Walleij 2013-07-22 23:07 ` Linus Walleij 2013-07-29 9:31 ` Tony Lindgren 2013-07-29 9:31 ` Tony Lindgren 2013-07-29 9:31 ` Tony Lindgren 2013-07-16 9:05 ` [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states Tony Lindgren 2013-07-16 9:05 ` Tony Lindgren 2013-07-17 21:21 ` Stephen Warren 2013-07-17 21:21 ` Stephen Warren 2013-07-18 7:50 ` Tony Lindgren 2013-07-18 7:50 ` Tony Lindgren 2013-07-18 13:48 ` Tony Lindgren [this message] 2013-07-18 13:48 ` Tony Lindgren 2013-07-16 9:14 ` [PATCH 0/4] improved support for runtime muxing for pinctrl Tony Lindgren 2013-07-16 9:14 ` Tony Lindgren 2013-07-17 11:49 ` Grygorii Strashko 2013-07-17 11:49 ` Grygorii Strashko 2013-07-17 11:49 ` Grygorii Strashko 2013-07-18 15:15 [PATCHv2 " Tony Lindgren 2013-07-18 15:15 ` [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states Tony Lindgren 2013-07-18 15:15 ` Tony Lindgren
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=20130718134806.GW7656@atomide.com \ --to=tony@atomide.com \ --cc=gregkh@linuxfoundation.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=swarren@wwwdotorg.org \ /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.