Re: [PATCH v2 4/4] ARM: shmobile: BOCK-W reference: add Ether PFC settings

[Simon Horman <horms@verge.net.au>]

On Thu, Oct 17, 2013 at 03:06:12PM +0900, Simon Horman wrote:
> On Thu, Oct 17, 2013 at 01:56:26AM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 09/27/2013 08:38 AM, Simon Horman wrote:
> > 
> >    Sorry for the very late reply: I was busy with other stuff and
> > then had ~2 weeks of vacations...
> > 
> > >>>>>>>>Add the Ether pin group to bockw_pinctrl_map[].
> > 
> > >>>>>>>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> > 
> > >>>>>>>>---
> > >>>>>>>>  arch/arm/mach-shmobile/board-bockw-reference.c |    3 +++
> > >>>>>>>>  1 file changed, 3 insertions(+)
> > 
> > >>>>>>>>Index: renesas/arch/arm/mach-shmobile/board-bockw-reference.c
> > >>>>>>>>=================================> > >>>>>>>>--- renesas.orig/arch/arm/mach-shmobile/board-bockw-reference.c
> > >>>>>>>>+++ renesas/arch/arm/mach-shmobile/board-bockw-reference.c
> > >>>>>>>>@@ -29,6 +29,9 @@
> > >>>>>>>>   */
> > >>>>>>>>
> > >>>>>>>>  static const struct pinctrl_map bockw_pinctrl_map[] = {
> > >>>>>>>>+       /* Ether */
> > >>>>>>>>+       PIN_MAP_MUX_GROUP_DEFAULT("fde00000.ethernet", "pfc-r8a7778",
> > >>>>>>>>+                                 "ether_rmii", "ether"),
> > >>>>>>>>         /* SCIF0 */
> > >>>>>>>>         PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
> > >>>>>>>>                                   "scif0_data_a", "scif0"),
> > 
> > >>>>>>>Hi Sergei,
> > 
> > >>>>>>>Thanks for your patches. In general I think your series looks fine. I
> > >>>>>>>have a single comment, and that's about the pinctrl-related hunk
> > >>>>>>>above. I can see that this patch is for DT reference for Bock-W, so I
> > >>>>>>>expect the code to be in DT. Do you have any plans to use DT to
> > >>>>>>>describe the pinmux bits? Perhaps you have some incremental patch
> > >>>>>>>planned?
> > 
> > >>>>>>    No, I just repeated what I saw mechanically. Now I'm seeing some
> > >>>>>>evidence that PFC driver supports the device tree, so I probably
> > >>>>>>need to redo the patchset... let me study this question better.
> > 
> > >>>>>Ping.
> > 
> > >>>>    Sorry, I got distracted by other work and didn't advance much here.
> > >>>>Will try to respin the patchset before my vacation (next Monday).
> > >>>>Although the driver DT support patch have seemingly stalemated due
> > >>>>to the most recent comments...
> > 
> > >>>Thanks for the update.
> > 
> > >>>I guess the key is to move forward on the driver side, somehow.
> > 
> > >>    Do you mean we should grant Stephen's requests concerning clock
> > >>DT support before we add the DT support to the driver?
> > 
> > >That seems like the most logical way forwards to me.
> > 
> >    Why? Why R-Car I2C driver device tree support was accepted
> > without this, although the driver uses clocks directly? Why such
> > discrimination is applied only to the Ethernet driver?
> 
> That is a good point. Have you made it to Stephen.

I see in the next email in my inbox that you now have.
Thanks.

> 
> My point was to point out where I feel the path of least resistance is
> and thus a possible avenue for you to pursue. The exact path you take
> to reach your goal isn't of particular interest to me. What is of interest
> to me is that you get there somehow :)
> 
> > >Is the main issue that the clocks aren't accessible via DT at this time?
> > 
> >    In the eyes of Stephen, yes.
> 
> Thanks, to be honest I was not entirely clear about this.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>