Re: [PATCH 00/42] SH pin control and GPIO rework
On Wed, Nov 21, 2012 at 3:27 AM, Laurent Pinchart wrote: > The idea behind these patches is to move SoC-specific pin control code from > arch/ to drivers/pinctrl/ and use the Linux device model to instantiate the > pin control device. This is required to add device tree support for the pin > control device. Ah, this looks nice :-) > The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't > be compiled for them. As the currently implemented arch-level pinmux support > also depends on generic GPIO, we're moving from a situation where the code > isn't used to a different situation where the code isn't used. I don't > consider that as a regression. That's OK, would be nice to get rid of this one day though. I will try to go through and review patches individually. I'll focus on pinctrl/GPIO mechanisms and trust you and Paul M to know that the SH side of things are correct. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/42] SH pin control and GPIO rework
On Wed, Nov 21, 2012 at 3:27 AM, Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com wrote: The idea behind these patches is to move SoC-specific pin control code from arch/ to drivers/pinctrl/ and use the Linux device model to instantiate the pin control device. This is required to add device tree support for the pin control device. Ah, this looks nice :-) The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't be compiled for them. As the currently implemented arch-level pinmux support also depends on generic GPIO, we're moving from a situation where the code isn't used to a different situation where the code isn't used. I don't consider that as a regression. That's OK, would be nice to get rid of this one day though. I will try to go through and review patches individually. I'll focus on pinctrl/GPIO mechanisms and trust you and Paul M to know that the SH side of things are correct. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/42] SH pin control and GPIO rework
On Wed, Nov 21, 2012 at 03:27:01AM +0100, Laurent Pinchart wrote: > Hi everybody, > > Here's a pretty large patch series that rework pin control and GPIO support > for SH and ARM SH/Renesas Mobile/Car platforms. The patches are based on top > of v3.7-rc6. You can get them from my git tree at > > git://linuxtv.org/pinchartl/fbdev.git pinmux > > The idea behind these patches is to move SoC-specific pin control code from > arch/ to drivers/pinctrl/ and use the Linux device model to instantiate the > pin control device. This is required to add device tree support for the pin > control device. > > The code has been compile-tested on all modified platforms except SH7264 and > SH7269, and runtime tested on SH7372 (Mackerel), SH73A0 (KZM-A9-GT) and > R8A7740 (Armadillo) so far. I will runtime test it on R8A7779 (Marzen). > > The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't > be compiled for them. As the currently implemented arch-level pinmux support > also depends on generic GPIO, we're moving from a situation where the code > isn't used to a different situation where the code isn't used. I don't > consider that as a regression. > > Sorry for the numerous checkpatch warnings, patches that move code around or > rename files don't modify the content to make review easier, and thus carry > warnings from the existing code. > > Currently missing from this series are DT bindings. I will send patches for > those a bit later. As they will build on top of this series I would appreciate > reviews (and hopefilly ack's). > I've only given it a quick look, but in general it looks good! For the series: Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/42] SH pin control and GPIO rework
On Wed, Nov 21, 2012 at 03:27:01AM +0100, Laurent Pinchart wrote: Hi everybody, Here's a pretty large patch series that rework pin control and GPIO support for SH and ARM SH/Renesas Mobile/Car platforms. The patches are based on top of v3.7-rc6. You can get them from my git tree at git://linuxtv.org/pinchartl/fbdev.git pinmux The idea behind these patches is to move SoC-specific pin control code from arch/ to drivers/pinctrl/ and use the Linux device model to instantiate the pin control device. This is required to add device tree support for the pin control device. The code has been compile-tested on all modified platforms except SH7264 and SH7269, and runtime tested on SH7372 (Mackerel), SH73A0 (KZM-A9-GT) and R8A7740 (Armadillo) so far. I will runtime test it on R8A7779 (Marzen). The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't be compiled for them. As the currently implemented arch-level pinmux support also depends on generic GPIO, we're moving from a situation where the code isn't used to a different situation where the code isn't used. I don't consider that as a regression. Sorry for the numerous checkpatch warnings, patches that move code around or rename files don't modify the content to make review easier, and thus carry warnings from the existing code. Currently missing from this series are DT bindings. I will send patches for those a bit later. As they will build on top of this series I would appreciate reviews (and hopefilly ack's). I've only given it a quick look, but in general it looks good! For the series: Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
