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

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:

quoted

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

quoted

Add the Ether pin group to bockw_pinctrl_map[].

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Signed-off-by: Sergei Shtylyov <redacted>

quoted

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

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

quoted

Hi Sergei,

quoted

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

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

quoted

Ping.

quoted

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

quoted

Thanks for the update.

quoted

quoted

quoted

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

quoted

quoted

   Do you mean we should grant Stephen's requests concerning clock
DT support before we add the DT support to the driver?

quoted

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 :)

quoted

quoted

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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html