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

[Sergei Shtylyov]

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 at 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?

> Is the main issue that the clocks aren't accessible via DT at this time?

    In the eyes of Stephen, yes.

WBR, Sergei