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

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...

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Add the Ether pin group to bockw_pinctrl_map[].

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Signed-off-by: Sergei Shtylyov <redacted>

quoted

quoted

quoted

quoted

quoted

quoted

quoted

---
  arch/arm/mach-shmobile/board-bockw-reference.c |    3 +++
  1 file changed, 3 insertions(+)

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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"),

quoted

quoted

quoted

quoted

quoted

quoted

Hi Sergei,

quoted

quoted

quoted

quoted

quoted

quoted

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?

quoted

quoted

quoted

quoted

quoted

    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.

quoted

quoted

quoted

quoted

Ping.

quoted

quoted

quoted

    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...

quoted

quoted

Thanks for the update.

quoted

quoted

I guess the key is to move forward on the driver side, somehow.

quoted

    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