Re: [PATCH 3/4] net: ethernet: cpsw: add support for hardware interface mode config

[Mugunthan V N]

On Thursday 22 August 2013 05:07 PM, Daniel Mack wrote:
 The cpsw currently lacks code to properly set up the hardware interface
 mode on AM33xx. Other platforms might be equally affected.

 Usually, the bootloader will configure the control module register, so
 probably that's why such support wasn't needed in the past. In suspend
 mode though, this register is modified, and so it needs reprogramming
 after resume.

 This patch adds code that makes use of the previously added and optional
 support for passing the control mode register, and configures the
 correct register bits from _cpsw_adjust_link().

 The AM33xx also has a bit for each slave to configure the RMII reference
 clock direction. Setting it is now supported by a per-slave DT property.

 This code path introducted by this patch is currently exclusive for
 am33xx.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  2 ++
  drivers/net/ethernet/ti/cpsw.c | 49 
 ++
  include/linux/platform_data/cpsw.h |  1 +
  3 files changed, 52 insertions(+)

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index 4e5ca54..0ccf01f 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -33,6 +33,8 @@ Required properties:
  - phy_id : Specifies slave phy id
  - phy-mode   : The interface between the SoC and the PHY (a string
 that of_get_phy_mode() can understand)
 +- ti,rmii-clock-ext  : If present, the driver will configure the RMII
 +   interface to external clock usage
  - mac-address: Specifies slave MAC address
  
  Optional properties:
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 4855d8e..d18ae43 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -138,6 +138,14 @@ do { 
 \
  #define CPSW_CMINTMAX_INTVL  (1000 / CPSW_CMINTMIN_CNT)
  #define CPSW_CMINTMIN_INTVL  ((1000 / CPSW_CMINTMAX_CNT) + 1)
  
 +#define AM33XX_GMII_SEL_MODE_MII (0)
 +#define AM33XX_GMII_SEL_MODE_RMII(1)
 +#define AM33XX_GMII_SEL_MODE_RGMII   (2)
 +#define AM33XX_GMII_SEL_MODE_UNUSED  (3)
 +
 +#define AM33XX_GMII_SEL_RMII2_IO_CLK_EN  BIT(7)
 +#define AM33XX_GMII_SEL_RMII1_IO_CLK_EN  BIT(6)
 +
  #define cpsw_enable_irq(priv)\
   do {\
   u32 i;  \
 @@ -728,6 +736,44 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
   u32 mac_control = 0;
   u32 slave_port;
  
 + if (priv-gmii_sel_reg  of_machine_is_compatible(ti,am33xx)) {
 + u32 reg = __raw_readl(priv-gmii_sel_reg);
 + u32 mode = AM33XX_GMII_SEL_MODE_UNUSED;

If phy interface is other than the below handled case then you will be
writing UNUSED bit to gmii sel bits which is wrong as it should not be
used as per hardware design guys. Please refer the following thread in
U-Boot which had a discussion about the UNUSED bit combination usage.
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/166689

 + u32 mask;
 +
 + if (phy) {
 + switch (phy-interface) {
 + case PHY_INTERFACE_MODE_MII:
 + mode = AM33XX_GMII_SEL_MODE_MII;
 + break;
 + case PHY_INTERFACE_MODE_RMII:
 + mode = AM33XX_GMII_SEL_MODE_RMII;
 + break;
 + case PHY_INTERFACE_MODE_RGMII:
 + mode = AM33XX_GMII_SEL_MODE_RGMII;
 + break;
 + default:
 + break;
 + };
 + }
 +
 + mask = 0x3  (slave-slave_num * 2) |
 +BIT(slave-slave_num + 6);
 + mode = slave-slave_num * 2;
 +
 + if (slave-data-rmii_clock_external) {
 + if (slave-slave_num == 0)
 + mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
 + else
 + mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
 + }
 +
 + reg = ~mask;
 + reg |= mode;
 +
 + __raw_writel(reg, priv-gmii_sel_reg);
 + }
 +

This is not the proper location to add phy interface enable and rmii
external clock enable. This should be moved to open as this api is
called from phy poll work queue at constant interval to detect phy link
changes. The above init has required only once and not to be done regularly.

   if (!phy)
   return;
  
 @@ -1798,6 +1844,9 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
 *data,

Re: [PATCH 1/3] misc: Add crossbar driver

[Sricharan R]

Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
Yes, when done based on what is available then there is a
problem when we run out of free ones because we do not
know which one to replace. I was thinking of something like
this,
1) DT would give a list of all free ones, and also if some are
mapped as default and not used, mark those also as free.

 2) While mapping see if it has a default mapping and use it.
  otherwise, pick from free list.   

  This should be ok right ?

Regards,
 Sricharan

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] net: ethernet: cpsw: add support for hardware interface mode config

[Mugunthan V N]

On Friday 23 August 2013 11:00 AM, Sekhar Nori wrote:
 @@ -728,6 +736,44 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
 u32 mac_control = 0;
 u32 slave_port;
   
  +  if (priv-gmii_sel_reg  of_machine_is_compatible(ti,am33xx)) {
 This sounds like the DT version of cpu_is_am335x()! Looks like you need
 to introduce a new compatible ti,am3352-cpsw to indicate the AM3352
 specific features of the CPSW IP (yeah, control module is not really
 part of the IP, but by introducing it in the driver, we are treating it
 such anyway. And you can see this register as extension of IP since its
 not shared for any other purpose).


I also agree but it should be ti,am3352-cpsw or ti.am33xx-cpsw?

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Rajendra Nayak]

On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
 Hi,
 On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
 Yes, when done based on what is available then there is a
 problem when we run out of free ones because we do not
 know which one to replace. I was thinking of something like
 this,
 1) DT would give a list of all free ones, and also if some are
 mapped as default and not used, mark those also as free.
 
  2) While mapping see if it has a default mapping and use it.
   otherwise, pick from free list.   
 
   This should be ok right ?

yeah, sounds ok.

 
 Regards,
  Sricharan
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: OMAP2: use 'int' instead of 'unsigned' for variable 'gpmc_irq_start'

[Chen Gang]

On 08/23/2013 01:48 PM, Tony Lindgren wrote:
 * Chen Gang F T chen.gang.flying.transfor...@gmail.com [130822 02:08]:
 Hmm... I guess: for our case, what your meaning is fixes-none-urgent,
 not fixes-none-critical, is it correct ?  :-)
 
 Right, that naming might be actually better :)
 
 Tony
 
 

Thanks !

-- 
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Sekhar Nori]

On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
 Hi,
 On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
 Yes, when done based on what is available then there is a
 problem when we run out of free ones because we do not
 know which one to replace. I was thinking of something like
 this,
 1) DT would give a list of all free ones, and also if some are
 mapped as default and not used, mark those also as free.
 
  2) While mapping see if it has a default mapping and use it.
   otherwise, pick from free list.   

Since the entire DT is available to you at boot time, you should be able
to find each node where interrupt-parent = crossbar and then allocate
one of 0-160 GIC interrupt numbers for that node, no? Where would there
be a need for default mapping and remapping? From one the mails in the
thread the crossbar is completely flexible - any of the 320 crossbar
interrupts can be mapped to any of the 160 GIC interrupts.

Any GIC interrupts left after this boot-time scan can be added to an
unused list for use with runtime DT fragments (when that support comes).

Sorry if I misunderstood, but above proposal sounds like maintaining a
separate free interrupt lines list in DT. That will quickly go out of sync.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Sricharan R]

On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
 On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
 Hi,
 On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
 Yes, when done based on what is available then there is a
 problem when we run out of free ones because we do not
 know which one to replace. I was thinking of something like
 this,
 1) DT would give a list of all free ones, and also if some are
 mapped as default and not used, mark those also as free.

  2) While mapping see if it has a default mapping and use it.
   otherwise, pick from free list.   
 Since the entire DT is available to you at boot time, you should be able
 to find each node where interrupt-parent = crossbar and then allocate
 one of 0-160 GIC interrupt numbers for that node, no? Where would there
 be a need for default mapping and remapping? From one the mails in the
 thread the crossbar is completely flexible - any of the 320 crossbar
 interrupts can be mapped to any of the 160 GIC interrupts.

 Any GIC interrupts left after this boot-time scan can be added to an
 unused list for use with runtime DT fragments (when that support comes).
  
 Sorry if I misunderstood, but above proposal sounds like maintaining a
 separate free interrupt lines list in DT. That will quickly go out of sync.
 Say, peripheral x uses crossbar 1 and specifies this in DT.
 During boot crossbar 1 gets mapped int 10. So if by default
some other crossbar has its interrupt mapped to 10,
then it should be removed.  Instead clear all crossbar registers
once and mark all as free, then  allocate only during request.
Correct ?. In this the free no need to maintain any list.

Regards,
 Sricharan
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: VExpress: Kconfig: avoid arm6 compatible for ARCH_VEXPRESS

[Chen Gang]

On 08/23/2013 01:51 PM, Tony Lindgren wrote:
 * Chen Gang gang.c...@asianux.com [130822 20:20]:
 The related error:

   /tmp/ccOMIprI.s: Assembler messages:
   /tmp/ccOMIprI.s:507: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:513: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:514: Error: selected processor does not support ARM mode 
 `dsb '
   /tmp/ccOMIprI.s:584: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:590: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:591: Error: selected processor does not support ARM mode 
 `dsb '
   make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1
   make: *** [arch/arm/mach-vexpress] Error 2


 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  arch/arm/mach-vexpress/Kconfig |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
 index 3657954..9b176ce 100644
 --- a/arch/arm/mach-vexpress/Kconfig
 +++ b/arch/arm/mach-vexpress/Kconfig
 @@ -1,5 +1,5 @@
  config ARCH_VEXPRESS
 -bool ARM Ltd. Versatile Express family if ARCH_MULTI_V7
 +bool ARM Ltd. Versatile Express family if ARCH_MULTI_V7  !CPU_V6  
 !CPU_V6K
  select ARCH_REQUIRE_GPIOLIB
  select ARM_AMBA
  select ARM_GIC
 
 We do support v6 and v7 in the same kernel. So instead of limiting
 what to select in Kconfig, just specify the v7 flags in the Makefile
 for the vexpress .c file with the inline assembly. Look for the
 find command I posted earlier in this thread for examples of specifying 
 flags for a single object in a makefile.


I guess what your meaning is like the diff below:

diff begin--

diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
index 36ea824..4ebfda4 100644
--- a/arch/arm/mach-vexpress/Makefile
+++ b/arch/arm/mach-vexpress/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
 ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
-   -I$(srctree)/arch/arm/plat-versatile/include
+   -I$(srctree)/arch/arm/plat-versatile/include -march=armv7-a
 
 obj-y  := v2m.o
 obj-$(CONFIG_ARCH_VEXPRESS_CA9X4)  += ct-ca9x4.o

diff end

If my above guess is correct, it can pass compiling without related
warnings, but it will be like below (CONFIG_CPU_32v6 is enabled in
allmodconfig):

  ... -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j ...  -march=armv7-a 
...

Is '-march=armv7-a' conflict with '-D__LINUX_ARM_ARCH__=6' ?


The related command is :

  arm-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-vexpress/.dcscb.o.d  -nostdinc 
-isystem /usr/lib/gcc/arm-linux-gnueabi/4.7/include 
-I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude 
-I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi 
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include 
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall 
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security 
-fno-delete-null-pointer-checks -Werror=implicit-int -Werror=strict-prototypes 
-Os -Wno-maybe-uninitialized -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs 
-mno-sched-prolog -fstack-protector -mabi=aapcs-linux -mno-thumb-interwork 
-funwind-tables -marm -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s 
-msoft-float -Uarm -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining 
-Wframe-larger-than=1024 -Wno-unused-but-se
 t-variabl
e -fno-omit-frame-pointer -fno-optimize-sibling-calls -g 
-femit-struct-debug-baseonly -fno-var-tracking -pg 
-fno-inline-functions-called-once -Wdeclaration-after-statement 
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO 
-I/root/linux-next/arch/arm/mach-vexpress/include 
-I/root/linux-next/arch/arm/plat-versatile/include -march=armv7-a -W 
-DKBUILD_STR(s)=#s -DKBUILD_BA

 

Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: VExpress: Kconfig: avoid arm6 compatible for ARCH_VEXPRESS

[Chen Gang]

On 08/23/2013 03:02 PM, Chen Gang wrote:
 On 08/23/2013 01:51 PM, Tony Lindgren wrote:
 * Chen Gang gang.c...@asianux.com [130822 20:20]:
 The related error:

   /tmp/ccOMIprI.s: Assembler messages:
   /tmp/ccOMIprI.s:507: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:513: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:514: Error: selected processor does not support ARM mode 
 `dsb '
   /tmp/ccOMIprI.s:584: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:590: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:591: Error: selected processor does not support ARM mode 
 `dsb '
   make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1
   make: *** [arch/arm/mach-vexpress] Error 2


 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  arch/arm/mach-vexpress/Kconfig |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
 index 3657954..9b176ce 100644
 --- a/arch/arm/mach-vexpress/Kconfig
 +++ b/arch/arm/mach-vexpress/Kconfig
 @@ -1,5 +1,5 @@
  config ARCH_VEXPRESS
 -   bool ARM Ltd. Versatile Express family if ARCH_MULTI_V7
 +   bool ARM Ltd. Versatile Express family if ARCH_MULTI_V7  !CPU_V6  
 !CPU_V6K
 select ARCH_REQUIRE_GPIOLIB
 select ARM_AMBA
 select ARM_GIC

 We do support v6 and v7 in the same kernel. So instead of limiting
 what to select in Kconfig, just specify the v7 flags in the Makefile
 for the vexpress .c file with the inline assembly. Look for the
 find command I posted earlier in this thread for examples of specifying 
 flags for a single object in a makefile.

 
 I guess what your meaning is like the diff below:
 
 diff begin--
 
 diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
 index 36ea824..4ebfda4 100644
 --- a/arch/arm/mach-vexpress/Makefile
 +++ b/arch/arm/mach-vexpress/Makefile
 @@ -2,7 +2,7 @@
  # Makefile for the linux kernel.
  #
  ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 - -I$(srctree)/arch/arm/plat-versatile/include
 + -I$(srctree)/arch/arm/plat-versatile/include -march=armv7-a
  
  obj-y  := v2m.o
  obj-$(CONFIG_ARCH_VEXPRESS_CA9X4)  += ct-ca9x4.o
 
 diff end
 
 If my above guess is correct, it can pass compiling without related
 warnings, but it will be like below (CONFIG_CPU_32v6 is enabled in
 allmodconfig):
 
   ... -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j ...  
 -march=armv7-a ...
 
 Is '-march=armv7-a' conflict with '-D__LINUX_ARM_ARCH__=6' ?
 

Oh, sorry.

'-D__LINUX_ARM_ARCH__' is for C file, '-march' is for assembly file.
for assembly file (or a C file has inline assemble code), need
'-march=armv7-a' (just like you have already mentioned).

I will send patch v2 for it.


Thanks.

 
 The related command is :
 
   arm-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-vexpress/.dcscb.o.d  -nostdinc 
 -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7/include 
 -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude 
 -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi 
 -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include 
 /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall 
 -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
 -Werror-implicit-function-declaration -Wno-format-security 
 -fno-delete-null-pointer-checks -Werror=implicit-int 
 -Werror=strict-prototypes -Os -Wno-maybe-uninitialized -fno-dwarf2-cfi-asm 
 -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fstack-protector 
 -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -marm 
 -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s -msoft-float -Uarm 
 -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining 
 -Wframe-larger-than=1024 -Wno-unused-but-
 set-varia
bl
 e -fno-omit-frame-pointer -fno-optimize-sibling-calls -g 
 -femit-struct-debug-baseonly -fno-var-tracking -pg 
 -fno-inline-functions-called-once -Wdeclaration-after-statement 
 -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO 
 -I/root/linux-next/arch/arm/mach-vexpress/include 
 -I/root/linux-next/arch/arm/plat-versatile/include -march=armv7-a -W 
 -DKBUILD_STR(s)=#s -DKBUILD_BA
 
  
 
 Thanks.
 


-- 
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: VExpress: Makefile: add armv7 flags for inline assmembly code compiling

[Chen Gang]

On 08/23/2013 04:02 PM, Chen Gang wrote:
 When vexpress kernel is compiled for v6, it still can support armv7
 instructions (hardware still support), so need let compiler know about
 it for related inline assembly code, or compiling will fail.
 

Hmm... need change compiled for v6, it still can to compiled for both
v6 and v7, it of cause can.

Thanks.

 The related failure command:
 
   arm-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-vexpress/.dcscb.o.d  -nostdinc 
 -isystem /usr/lib/gcc/arm-linux-gnueabi/4.7/include 
 -I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude 
 -I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi 
 -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include 
 /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall 
 -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
 -Werror-implicit-function-declaration -Wno-format-security 
 -fno-delete-null-pointer-checks -Werror=implicit-int 
 -Werror=strict-prototypes -Os -Wno-maybe-uninitialized -fno-dwarf2-cfi-asm 
 -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fstack-protector 
 -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -marm 
 -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s -msoft-float -Uarm 
 -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining 
 -Wframe-larger-than=1024 -Wno-unused-but-
 set-varia
bl
 e -fno-omit-frame-pointer -fno-optimize-sibling-calls -g 
 -femit-struct-debug-baseonly -fno-var-tracking -pg 
 -fno-inline-functions-called-once -Wdeclaration-after-statement 
 -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO 
 -I/root/linux-next/arch/arm/mach-vexpress/include 
 -I/root/linux-next/arch/arm/plat-versatile/include -W 
 -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(dcscb)  
 -DKBUILD_MODNAME=KBUILD_STR(dcscb) -c -o 
 arch/arm/mach-vexpress/.tmp_dcscb.o arch/arm/mach-vexpress/dcscb.c
 
 The related error:
 
   /tmp/ccOMIprI.s: Assembler messages:
   /tmp/ccOMIprI.s:507: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:513: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:514: Error: selected processor does not support ARM mode 
 `dsb '
   /tmp/ccOMIprI.s:584: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:590: Error: selected processor does not support ARM mode 
 `isb '
   /tmp/ccOMIprI.s:591: Error: selected processor does not support ARM mode 
 `dsb '
   make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1
   make: *** [arch/arm/mach-vexpress] Error 2
 
 
 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  arch/arm/mach-vexpress/Makefile |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
 index 36ea824..f224577 100644
 --- a/arch/arm/mach-vexpress/Makefile
 +++ b/arch/arm/mach-vexpress/Makefile
 @@ -10,3 +10,6 @@ obj-$(CONFIG_ARCH_VEXPRESS_DCSCB)   += dcscb.o  
 dcscb_setup.o
  obj-$(CONFIG_ARCH_VEXPRESS_TC2_PM)   += tc2_pm.o spc.o
  obj-$(CONFIG_SMP)+= platsmp.o
  obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o
 +
 +CFLAGS_dcscb.o   +=-march=armv7-a
 +CFLAGS_tc2_pm.o  +=-march=armv7-a
 


-- 
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] net: ethernet: cpsw: add support for hardware interface mode config

[Daniel Mack]

On 23.08.2013 08:14, Mugunthan V N wrote:
 On Friday 23 August 2013 11:00 AM, Sekhar Nori wrote:
 @@ -728,6 +736,44 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
u32 mac_control = 0;
u32 slave_port;
  
 +  if (priv-gmii_sel_reg  of_machine_is_compatible(ti,am33xx)) {
 This sounds like the DT version of cpu_is_am335x()! Looks like you need
 to introduce a new compatible ti,am3352-cpsw to indicate the AM3352
 specific features of the CPSW IP (yeah, control module is not really
 part of the IP, but by introducing it in the driver, we are treating it
 such anyway. And you can see this register as extension of IP since its
 not shared for any other purpose).

 
 I also agree but it should be ti,am3352-cpsw or ti.am33xx-cpsw?

I think the rule is to be as specific as possible, so I'll take
ti,am3352-cpsw.

Thank you very much for the review, everyone. I'll respin a new series
with all issues addressed.


Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Sekhar Nori]

On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
 On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
 On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
 Hi,
 On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
 Yes, when done based on what is available then there is a
 problem when we run out of free ones because we do not
 know which one to replace. I was thinking of something like
 this,
 1) DT would give a list of all free ones, and also if some are
 mapped as default and not used, mark those also as free.

  2) While mapping see if it has a default mapping and use it.
   otherwise, pick from free list.   
 Since the entire DT is available to you at boot time, you should be able
 to find each node where interrupt-parent = crossbar and then allocate
 one of 0-160 GIC interrupt numbers for that node, no? Where would there
 be a need for default mapping and remapping? From one the mails in the
 thread the crossbar is completely flexible - any of the 320 crossbar
 interrupts can be mapped to any of the 160 GIC interrupts.

 Any GIC interrupts left after this boot-time scan can be added to an
 unused list for use with runtime DT fragments (when that support comes).
  
 Sorry if I misunderstood, but above proposal sounds like maintaining a
 separate free interrupt lines list in DT. That will quickly go out of sync.
  Say, peripheral x uses crossbar 1 and specifies this in DT.
  During boot crossbar 1 gets mapped int 10. So if by default
 some other crossbar has its interrupt mapped to 10,
 then it should be removed.  Instead clear all crossbar registers
 once and mark all as free, then  allocate only during request.
 Correct ?. In this the free no need to maintain any list.

Right, so in my suggestion there is nothing like a default mapping and
entire 160 GIC interrupt number space is up for grabs. I think this will
be much simpler to write and maintain.

If you really want to maintain default mapping as far as possible, you
can do two passes on the crossbar interrupt numbers requested. Once to
assign the default map - for numbers less that 160 - and then look at
the free GIC interrupt slots and use those for numbers greater than 160.

Thanks,
Sekhar


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: VExpress: Makefile: add armv7 flags for inline assmembly code compiling

[Chen Gang]

When vexpress kernel is compiled for v6, it still can support armv7
instructions (hardware still support), so need let compiler know about
it for related inline assembly code, or compiling will fail.

The related failure command:

  arm-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-vexpress/.dcscb.o.d  -nostdinc 
-isystem /usr/lib/gcc/arm-linux-gnueabi/4.7/include 
-I/root/linux-next/arch/arm/include -Iarch/arm/include/generated  -Iinclude 
-I/root/linux-next/arch/arm/include/uapi -Iarch/arm/include/generated/uapi 
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include 
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall 
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security 
-fno-delete-null-pointer-checks -Werror=implicit-int -Werror=strict-prototypes 
-Os -Wno-maybe-uninitialized -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs 
-mno-sched-prolog -fstack-protector -mabi=aapcs-linux -mno-thumb-interwork 
-funwind-tables -marm -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s 
-msoft-float -Uarm -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining 
-Wframe-larger-than=1024 -Wno-unused-but-se
 t-variabl
e -fno-omit-frame-pointer -fno-optimize-sibling-calls -g 
-femit-struct-debug-baseonly -fno-var-tracking -pg 
-fno-inline-functions-called-once -Wdeclaration-after-statement 
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO 
-I/root/linux-next/arch/arm/mach-vexpress/include 
-I/root/linux-next/arch/arm/plat-versatile/include -W -DKBUILD_STR(s)=#s 
-DKBUILD_BASENAME=KBUILD_STR(dcscb)  -DKBUILD_MODNAME=KBUILD_STR(dcscb) -c 
-o arch/arm/mach-vexpress/.tmp_dcscb.o arch/arm/mach-vexpress/dcscb.c

The related error:

  /tmp/ccOMIprI.s: Assembler messages:
  /tmp/ccOMIprI.s:507: Error: selected processor does not support ARM mode `isb 
'
  /tmp/ccOMIprI.s:513: Error: selected processor does not support ARM mode `isb 
'
  /tmp/ccOMIprI.s:514: Error: selected processor does not support ARM mode `dsb 
'
  /tmp/ccOMIprI.s:584: Error: selected processor does not support ARM mode `isb 
'
  /tmp/ccOMIprI.s:590: Error: selected processor does not support ARM mode `isb 
'
  /tmp/ccOMIprI.s:591: Error: selected processor does not support ARM mode `dsb 
'
  make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1
  make: *** [arch/arm/mach-vexpress] Error 2


Signed-off-by: Chen Gang gang.c...@asianux.com
---
 arch/arm/mach-vexpress/Makefile |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
index 36ea824..f224577 100644
--- a/arch/arm/mach-vexpress/Makefile
+++ b/arch/arm/mach-vexpress/Makefile
@@ -10,3 +10,6 @@ obj-$(CONFIG_ARCH_VEXPRESS_DCSCB) += dcscb.o  
dcscb_setup.o
 obj-$(CONFIG_ARCH_VEXPRESS_TC2_PM) += tc2_pm.o spc.o
 obj-$(CONFIG_SMP)  += platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)  += hotplug.o
+
+CFLAGS_dcscb.o +=-march=armv7-a
+CFLAGS_tc2_pm.o+=-march=armv7-a
-- 
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] cpsw: support for control module register

[Daniel Mack]

v1 - v2:
* combine devm_request_mem_region() and devm_ioremap() and use
  devm_ioremap_resource() (reported by Sergei Shtylyov)
* fix multi-line comment style (reported by Sergei Shtylyov)
* fix ti,rmii-clock-ext property name (reported by Sekhar)
* rebased to net-next (reported by Mugunthan V N, David Miller)
* add a new compatible type, and handle AM33xx specific
  registers that way (reported by Sekhar)
* move gmii_sel_reg modifications to the open routine
  (reported by Mugunthan V N)


Daniel Mack (5):
  net: ethernet: cpsw: switch to devres allocations
  net: ethernet: cpsw: add optional third memory region for CONTROL
module
  net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
  net: ethernet: cpsw: add support for hardware interface mode config
  ARM: dts: am33xx: adopt to cpsw changes

 Documentation/devicetree/bindings/net/cpsw.txt |  10 +-
 arch/arm/boot/dts/am33xx.dtsi  |   5 +-
 drivers/net/ethernet/ti/cpsw.c | 254 ++---
 drivers/net/ethernet/ti/cpsw.h |   2 +
 4 files changed, 159 insertions(+), 112 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Daniel Mack]

This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.

Also update the compatible string to make use of the am335x specific
features of the cpsw driver.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/boot/dts/am33xx.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a785b95..1a1e9dd 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -446,7 +446,7 @@
};
 
mac: ethernet@4a10 {
-   compatible = ti,cpsw;
+   compatible = ti,am3352-cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
ale_entries = 1024;
@@ -459,7 +459,8 @@
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
reg = 0x4a10 0x800
-  0x4a101200 0x100;
+  0x4a101200 0x100
+  0x44e10650 0x4;
#address-cells = 1;
#size-cells = 1;
interrupt-parent = intc;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
 drivers/net/ethernet/ti/cpsw.c | 32 --
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 4e5ca54..b717458 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 --
 
 Required properties:
-- compatible   : Should be ti,cpsw
+- compatible   : Should be ti,cpsw for generic cpsw support, or
+ ti,am3352-cpsw for AM3352 SoCs
 - reg  : physical base address and size of the cpsw
  registers map.
  An optional third memory region can be supplied if
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index bd0b664..2e19de0 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -155,6 +155,11 @@ do {   
\
((priv-data.dual_emac) ? priv-emac_port : \
priv-data.active_slave)
 
+enum {
+   CPSW_TYPE_GENERIC,
+   CPSW_TYPE_AM33XX
+};
+
 static int debug_level;
 module_param(debug_level, int, 0);
 MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
@@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave *slave, 
struct cpsw_priv *priv,
slave-port_vlan = data-dual_emac_res_vlan;
 }
 
+static const struct of_device_id cpsw_of_mtable[] = {
+   {
+   .compatible = ti,cpsw,
+   .data   = (void *) CPSW_TYPE_GENERIC
+   }, {
+   .compatible = ti,am3352-cpsw,
+   .data   = (void *) CPSW_TYPE_AM33XX
+   },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
+
 static int cpsw_probe_dt(struct cpsw_platform_data *data,
 struct platform_device *pdev)
 {
struct device_node *node = pdev-dev.of_node;
+   const struct of_device_id *match;
struct device_node *slave_node;
+   unsigned long match_data;
int i = 0, ret;
u32 prop;
 
-   if (!node)
+   match = of_match_device(cpsw_of_mtable, pdev-dev);
+
+   if (!node || !match)
return -EINVAL;
 
+   match_data = (unsigned long) match-data;
+   data-hw_type = match_data;
+
if (of_property_read_u32(node, slaves, prop)) {
pr_err(Missing slaves property in the DT.\n);
return -EINVAL;
@@ -2228,12 +2252,6 @@ static const struct dev_pm_ops cpsw_pm_ops = {
.resume = cpsw_resume,
 };
 
-static const struct of_device_id cpsw_of_mtable[] = {
-   { .compatible = ti,cpsw, },
-   { /* sentinel */ },
-};
-MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
-
 static struct platform_driver cpsw_driver = {
.driver = {
.name= cpsw,
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index eb3e101..96c374a 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -37,6 +37,7 @@ struct cpsw_platform_data {
u32 mac_control;/* Mac control register */
u16 default_vlan;   /* Def VLAN for ALE lookup in VLAN aware mode*/
booldual_emac;  /* Enable Dual EMAC mode */
+   u32 hw_type;/* hardware type as specified in 'compatible' */
 };
 
 #endif /* __CPSW_H__ */
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] net: ethernet: cpsw: switch to devres allocations

[Daniel Mack]

This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/net/ethernet/ti/cpsw.c | 145 +
 1 file changed, 44 insertions(+), 101 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..1a91aac 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t  lock;
struct platform_device  *pdev;
struct net_device   *ndev;
-   struct resource *cpsw_res;
-   struct resource *cpsw_wr_res;
struct napi_struct  napi;
struct device   *dev;
struct cpsw_platform_data   data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
*data,
 
if (of_property_read_u32(node, active_slave, prop)) {
pr_err(Missing active_slave property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-active_slave = prop;
 
if (of_property_read_u32(node, cpts_clock_mult, prop)) {
pr_err(Missing cpts_clock_mult property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_mult = prop;
 
if (of_property_read_u32(node, cpts_clock_shift, prop)) {
pr_err(Missing cpts_clock_shift property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_shift = prop;
 
-   data-slave_data = kcalloc(data-slaves, sizeof(struct cpsw_slave_data),
-  GFP_KERNEL);
+   data-slave_data = devm_kzalloc(pdev-dev, data-slaves
+   * sizeof(struct cpsw_slave_data),
+   GFP_KERNEL);
if (!data-slave_data)
-   return -EINVAL;
+   return -ENOMEM;
 
if (of_property_read_u32(node, cpdma_channels, prop)) {
pr_err(Missing cpdma_channels property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-channels = prop;
 
if (of_property_read_u32(node, ale_entries, prop)) {
pr_err(Missing ale_entries property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-ale_entries = prop;
 
if (of_property_read_u32(node, bd_ram_size, prop)) {
pr_err(Missing bd_ram_size property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-bd_ram_size = prop;
 
if (of_property_read_u32(node, rx_descs, prop)) {
pr_err(Missing rx_descs property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-rx_descs = prop;
 
if (of_property_read_u32(node, mac_control, prop)) {
pr_err(Missing mac_control property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-mac_control = prop;
 
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, phy_id, lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err(Missing slave[%d] phy_id property\n, i);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
 
return 0;
-
-error_ret:
-   kfree(data-slave_data);
-   return ret;
 }
 
 static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
priv_sl2-coal_intvl = 0;
priv_sl2-bus_freq_mhz = priv-bus_freq_mhz;
 
-   priv_sl2-cpsw_res = priv-cpsw_res;
priv_sl2-regs = priv-regs;
priv_sl2-host_port = priv-host_port;
priv_sl2-host_port_regs = priv-host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv*priv;
struct cpdma_params dma_params;
struct cpsw_ale_params  ale_params;
- 

[PATCH v2 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Daniel Mack]

The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.

Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.

This patch adds code that makes use of the previously added and optional
support for passing the control mode register, and configures the
correct register bits when the slave is opened.

The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.

This code path introducted by this patch is currently exclusive for
am33xx.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  2 +
 drivers/net/ethernet/ti/cpsw.c | 61 ++
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index b717458..0895a51 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -34,6 +34,8 @@ Required properties:
 - phy_id   : Specifies slave phy id
 - phy-mode : The interface between the SoC and the PHY (a string
  that of_get_phy_mode() can understand)
+- ti,rmii-clock-ext: If present, the driver will configure the RMII
+ interface to external clock usage
 - mac-address  : Specifies slave MAC address
 
 Optional properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 2e19de0..6e36f49 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -138,6 +138,13 @@ do {   
\
 #define CPSW_CMINTMAX_INTVL(1000 / CPSW_CMINTMIN_CNT)
 #define CPSW_CMINTMIN_INTVL((1000 / CPSW_CMINTMAX_CNT) + 1)
 
+#define AM33XX_GMII_SEL_MODE_MII   (0)
+#define AM33XX_GMII_SEL_MODE_RMII  (1)
+#define AM33XX_GMII_SEL_MODE_RGMII (2)
+
+#define AM33XX_GMII_SEL_RMII2_IO_CLK_ENBIT(7)
+#define AM33XX_GMII_SEL_RMII1_IO_CLK_ENBIT(6)
+
 #define cpsw_enable_irq(priv)  \
do {\
u32 i;  \
@@ -980,6 +987,56 @@ static inline void cpsw_add_dual_emac_def_ale_entries(
priv-host_port, ALE_VLAN, slave-port_vlan);
 }
 
+static void cpsw_set_phy_interface_mode(struct cpsw_slave *slave,
+   struct cpsw_priv *priv)
+{
+   u32 reg, mask, mode = 0;
+
+   switch (priv-data.hw_type) {
+   case CPSW_TYPE_AM33XX:
+   if (!priv-gmii_sel_reg)
+   break;
+
+   reg = readl(priv-gmii_sel_reg);
+
+   if (slave-phy) {
+   switch (slave-phy-interface) {
+   case PHY_INTERFACE_MODE_MII:
+   default:
+   mode = AM33XX_GMII_SEL_MODE_MII;
+   break;
+   case PHY_INTERFACE_MODE_RMII:
+   mode = AM33XX_GMII_SEL_MODE_RMII;
+   break;
+   case PHY_INTERFACE_MODE_RGMII:
+   mode = AM33XX_GMII_SEL_MODE_RGMII;
+   break;
+   };
+   }
+
+   mask = 0x3  (slave-slave_num * 2) |
+  BIT(slave-slave_num + 6);
+   mode = slave-slave_num * 2;
+
+   if (slave-data-rmii_clock_external) {
+   if (slave-slave_num == 0)
+   mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
+   else
+   mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
+   }
+
+   reg = ~mask;
+   reg |= mode;
+
+   writel(reg, priv-gmii_sel_reg);
+   break;
+
+   default:
+   break;
+
+   }
+}
+
 static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
 {
char name[32];
@@ -1028,6 +1085,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, 
struct cpsw_priv *priv)
 slave-phy-phy_id);
phy_start(slave-phy);
}
+
+   cpsw_set_phy_interface_mode(slave, priv);
 }
 
 static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
@@ -1823,6 +1882,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
 
slave_data-phy_if = of_get_phy_mode(slave_node);
+   if (of_find_property(slave_node, ti,rmii-clock-ext, NULL))
+ 

[PATCH v2 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.

I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  5 -
 drivers/net/ethernet/ti/cpsw.c | 16 
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 05d660e..4e5ca54 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -4,7 +4,10 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 Required properties:
 - compatible   : Should be ti,cpsw
 - reg  : physical base address and size of the cpsw
- registers map
+ registers map.
+ An optional third memory region can be supplied if
+ the platform has a control module register to
+ configure phy interface details
 - interrupts   : property with a value describing the interrupt
  number
 - interrupt-parent : The parent interrupt controller
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 1a91aac..bd0b664 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -372,6 +372,7 @@ struct cpsw_priv {
struct cpsw_platform_data   data;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
+   u32 __iomem *gmii_sel_reg;
u8 __iomem  *hw_stats;
struct cpsw_host_regs __iomem   *host_port_regs;
u32 msg_enable;
@@ -1999,6 +2000,21 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}
 
+   /* If the control memory region is unspecified, continue without it.
+* If it is specified, but we're unable to reserve it, bail.
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_err(priv-dev, error getting control i/o resource\n);
+   goto no_gmii_sel;
+   }
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+   if (!priv-gmii_sel_reg) {
+   dev_err(priv-dev, unable to map control i/o region\n);
+   goto clean_runtime_disable_ret;
+   }
+
+no_gmii_sel:
memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] i2c: move of helpers into the core

[Wolfram Sang]

On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote:
 I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
 that it is much cleaner to have this in the core. This also removes a
 circular dependency between the helpers and the core, and so we can
 finally register child nodes in the core instead of doing this manually
 in each driver. So, fix the drivers and documentation, too.
 
 Acked-by: Rob Herring rob.herr...@calxeda.com
 Reviewed-by: Felipe Balbi ba...@ti.com
 Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Wolfram Sang w...@the-dreams.de

Applied to for-next!


signature.asc
Description: Digital signature

Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions

[Sekhar Nori]

Hi Benoit,

Did you get a chance to think about this, I have provided some replies
below.

On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote:
 Hi Sekhar,
 
 On 16/08/2013 17:41, Sekhar Nori wrote:

 On 8/16/2013 7:45 PM, Benoit Cousson wrote:
 Hi Gururaja,

 On 16/08/2013 13:36, Hebbar, Gururaja wrote:
 The syntax of compatible property in DT is to mention the Most specific
 match to most generic match.

 Since AM335x is the platform with latest IP revision, add it 1st in
 the device id table.

 I don't understand why? The order should not matter at all.

 Yes, it should not. We are trying to work around a bug in the kernel
 where the compatible order is not honored (instead the order in
 of_match[] array matters). There were patches being discussed to fix this.


 I've tried to follow the thread you had with Mark on the v2, but AFAIK,
 you've never answered to his latest question.

 Moreover, checking the differences between the Davinci and the am3352
 RTC IP, I would not claim that both are compatible.

 Sure you can use the am3352 with the Davinci driver, but you will lose
 the wakeup functionality without even being notify about that.

 When the kernel is fixed for the bug pointed out above, this should not
 happen with properly defined compatible property.


 For my point of view, compatible mean that the HW will still be fully
 functional with both versions of the driver, which is not the case here.

 I do not think that's the interpretation of compatible. Its goes from
 most specific to most generic per the ePAPR spec. That in itself says
 that 100% functionality is not expected if you don't find a match for
 the more specific property.
 
 Well, to be honest I checked as well the official documentation, and this is 
 far from being clear:
 
 page 21 of the ePAPR:
 
 
 Property: compatible
 Value type: stringlist
 
 Description:
  The compatible property value consists of one or more strings that define 
 the specific 
  programming model for the device. This list of strings should be used by a 
 client program for
  device driver selection. The property value consists of a concatenated list 
 of null terminated
  strings, from most specific to most general. They allow a device to express 
 its compatibility
  with a family of similar devices, potentially allowing a single device 
 driver to match against
  several devices.
  
  The recommended format is “manufacturer,model”, where manufacturer is a
  string describing the name of the manufacturer (such as a stock ticker 
 symbol), and model
  specifies the model number.
 
 Example:
  compatible = “fsl,mpc8641-uart”, “ns16550;
  In this example, an operating system would first try to locate a device 
 driver that supported
  fsl,mpc8641-uart. If a driver was not found, it would then try to locate a 
 driver that supported
  the more general ns16550 device type.
 
 
 In this example, the generic vs specific is just about the driver. You could 
 have one driver that manage 10 different UARTs or a specific one that manage 
 only your HW. 

Right, the assumption is that a specific driver is written because there
are parts of the hardware that cannot be serviced by generic driver. So
ultimately its all driven by changes in hardware.

 
 There is no assumption about the lost of functionality by using the generic 
 version of the driver. How the user is supposed to know the amount of 
 functionality he will lose, and if this is acceptable to him.

I suppose the generic driver would return some error code like -ENOTSUP
for the functionality it cannot provide.

 I'd rather have an error at boot saying that the driver is not compatible 
 with the HW and thus I will have to upgrade the kernel, than booting a kernel 
 that will not work as expected because some functionality are missing for 
 that specific HW.

If you have an update available, you can always upgrade to it. But what
if there is no update available? Would you rather not have the user use
the available functionality in the meanwhile while he waits for the
kernel support to be developed.

 
 Claiming that a piece of HW is compatible with an other one that is just a 
 subset in term of functionality is wrong. You can claim that the ti,da830-rtc 
 is compatible with the ti,am3352-rtc driver, but not the opposite.

If this is wrong, then what is the use of compatible property? Why would
someone write a driver supporting “fsl,mpc8641-uart” if 100% of its
hardware features are also supported by “ns16550 driver?

 am3352 DTS must use the ti,am3352-rtc to have the expected behavior.

 Yes, that's what patch 2/2 does.

 Using the ti,da830-rtc version will not make the board working as
 expected. So we cannot claim the compatibility.

 Ideally, the DT file was *always* written as

  compatible = ti,am3352-rtc, ti,da830-rtc;

 even when there was no kernel support for AM3352 RTC.
 
 You could do that only for the davinci DTS, because it is a subset of the 
 am3352 but you cannot do that for the 

Re: [PATCH v2 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Sekhar Nori]

On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
 This third memory region just denotes one single register in the CONTROL
 module block. The driver uses that in order to set the correct physical
 ethernet interface modes.
 
 Also update the compatible string to make use of the am335x specific
 features of the cpsw driver.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  arch/arm/boot/dts/am33xx.dtsi | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index a785b95..1a1e9dd 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -446,7 +446,7 @@
   };
  
   mac: ethernet@4a10 {
 - compatible = ti,cpsw;
 + compatible = ti,am3352-cpsw;

Please keep this as

compatible = ti,am3352-cpsw, ti,cpsw;

so users can upgrade the DTB or kernel independently. Apart from this
the series looks good to me.

Thanks,
Sekhar

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Daniel Mack]

On 23.08.2013 11:28, Sekhar Nori wrote:
 On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
 This third memory region just denotes one single register in the CONTROL
 module block. The driver uses that in order to set the correct physical
 ethernet interface modes.

 Also update the compatible string to make use of the am335x specific
 features of the cpsw driver.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  arch/arm/boot/dts/am33xx.dtsi | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index a785b95..1a1e9dd 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -446,7 +446,7 @@
  };
  
  mac: ethernet@4a10 {
 -compatible = ti,cpsw;
 +compatible = ti,am3352-cpsw;
 
 Please keep this as
 
   compatible = ti,am3352-cpsw, ti,cpsw;
 
 so users can upgrade the DTB or kernel independently. Apart from this
 the series looks good to me.

Ok, thanks. Given that this last patch will be merged through another
tree, can I just resend it separately, while David takes the rest as it is?

Thanks,
Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Sekhar Nori]

On Friday 23 August 2013 03:04 PM, Daniel Mack wrote:
 On 23.08.2013 11:28, Sekhar Nori wrote:
 On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
 This third memory region just denotes one single register in the CONTROL
 module block. The driver uses that in order to set the correct physical
 ethernet interface modes.

 Also update the compatible string to make use of the am335x specific
 features of the cpsw driver.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  arch/arm/boot/dts/am33xx.dtsi | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index a785b95..1a1e9dd 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -446,7 +446,7 @@
 };
  
 mac: ethernet@4a10 {
 -   compatible = ti,cpsw;
 +   compatible = ti,am3352-cpsw;

 Please keep this as

  compatible = ti,am3352-cpsw, ti,cpsw;

 so users can upgrade the DTB or kernel independently. Apart from this
 the series looks good to me.
 
 Ok, thanks. Given that this last patch will be merged through another
 tree, can I just resend it separately, while David takes the rest as it is?

Ideally you could, but there are some bugs in the way compatible string
in handled and due to this I suspect you need to reorder
cpsw_of_mtable[] to match correctly. Not sure if the bug has been fixed
in recent -rcs. Please check if modifying just this patch works and then
go ahead and post.

Please Cc Benoit Cousson bcous...@baylibre.com on your next submission
as he is the one who picks up DT patches for OMAP.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*

[Kishon Vijay Abraham I]

Hi,

On Friday 23 August 2013 02:20 AM, Stephen Warren wrote:
 On 08/22/2013 02:31 AM, Kishon Vijay Abraham I wrote:
 The Palmas device contains only a USB VBUS-ID detector, so added a
 compatible type *ti,palmas-usb-vid*. Didn't remove the existing compatible
 types for backward compatibility.
 
 diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt 
 b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
 
  PALMAS USB COMPARATOR
  Required Properties:
 - - compatible : Should be ti,palmas-usb or ti,twl6035-usb
 + - compatible : Should be ti,palmas-usb-vid. ti,twl6035-usb and
 +   ti,palmas-usb is deprecated and is kept for backward compatibility.
 
 So this defines one new value and deprecates the two old values.

yeah.
 
 Why isn't a new ti,twl6035-usb-vid entry useful? Don't you still need

yeah, it should be added too.
 SoC-specific compatible values so the driver can enable any SoC-specific
 bug-fixes/workarounds later if needed?

hmm.. Palmas is external to SoC. So not sure if adding SoC specific compatible
values is such a good idea.

Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Daniel Mack]

On 23.08.2013 11:40, Sekhar Nori wrote:
 On Friday 23 August 2013 03:04 PM, Daniel Mack wrote:
 On 23.08.2013 11:28, Sekhar Nori wrote:

 Ok, thanks. Given that this last patch will be merged through another
 tree, can I just resend it separately, while David takes the rest as it is?
 
 Ideally you could, but there are some bugs in the way compatible string
 in handled and due to this I suspect you need to reorder
 cpsw_of_mtable[] to match correctly. Not sure if the bug has been fixed
 in recent -rcs. Please check if modifying just this patch works and then
 go ahead and post.

No, you're right. I had to swap the two entries. Thanks for mentioning it.

 Please Cc Benoit Cousson bcous...@baylibre.com on your next submission
 as he is the one who picks up DT patches for OMAP.

Will do.



Daniel


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/5] cpsw: support for control module register

[Daniel Mack]

v2 - v3:
* swap ti,am3352-cpsw and ti,cpsw to work around a matching
  bug (reported by Sekhar)

v1 - v2:
* combine devm_request_mem_region() and devm_ioremap() and use
  devm_ioremap_resource() (reported by Sergei Shtylyov)
* fix multi-line comment style (reported by Sergei Shtylyov)
* fix ti,rmii-clock-ext property name (reported by Sekhar)
* rebased to net-next (reported by Mugunthan V N, David Miller)
* add a new compatible type, and handle AM33xx specific
  registers that way (reported by Sekhar)
* move gmii_sel_reg modifications to the open routine
  (reported by Mugunthan V N)


Daniel Mack (5):
  net: ethernet: cpsw: switch to devres allocations
  net: ethernet: cpsw: add optional third memory region for CONTROL
module
  net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
  net: ethernet: cpsw: add support for hardware interface mode config
  ARM: dts: am33xx: adopt to cpsw changes

 Documentation/devicetree/bindings/net/cpsw.txt |  10 +-
 arch/arm/boot/dts/am33xx.dtsi  |   5 +-
 drivers/net/ethernet/ti/cpsw.c | 254 ++---
 drivers/net/ethernet/ti/cpsw.h |   2 +
 4 files changed, 159 insertions(+), 112 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Daniel Mack]

This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.

Also update the compatible string to make use of the am335x specific
features of the cpsw driver.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/boot/dts/am33xx.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a785b95..c7b41ae 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -446,7 +446,7 @@
};
 
mac: ethernet@4a10 {
-   compatible = ti,cpsw;
+   compatible = ti,am3352-cpsw, ti,cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
ale_entries = 1024;
@@ -459,7 +459,8 @@
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
reg = 0x4a10 0x800
-  0x4a101200 0x100;
+  0x4a101200 0x100
+  0x44e10650 0x4;
#address-cells = 1;
#size-cells = 1;
interrupt-parent = intc;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
 drivers/net/ethernet/ti/cpsw.c | 32 --
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 4e5ca54..b717458 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 --
 
 Required properties:
-- compatible   : Should be ti,cpsw
+- compatible   : Should be ti,cpsw for generic cpsw support, or
+ ti,am3352-cpsw for AM3352 SoCs
 - reg  : physical base address and size of the cpsw
  registers map.
  An optional third memory region can be supplied if
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index bd0b664..b194529 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -155,6 +155,11 @@ do {   
\
((priv-data.dual_emac) ? priv-emac_port : \
priv-data.active_slave)
 
+enum {
+   CPSW_TYPE_GENERIC,
+   CPSW_TYPE_AM33XX
+};
+
 static int debug_level;
 module_param(debug_level, int, 0);
 MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
@@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave *slave, 
struct cpsw_priv *priv,
slave-port_vlan = data-dual_emac_res_vlan;
 }
 
+static const struct of_device_id cpsw_of_mtable[] = {
+   {
+   .compatible = ti,am3352-cpsw,
+   .data   = (void *) CPSW_TYPE_AM33XX
+   }, {
+   .compatible = ti,cpsw,
+   .data   = (void *) CPSW_TYPE_GENERIC
+   },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
+
 static int cpsw_probe_dt(struct cpsw_platform_data *data,
 struct platform_device *pdev)
 {
struct device_node *node = pdev-dev.of_node;
+   const struct of_device_id *match;
struct device_node *slave_node;
+   unsigned long match_data;
int i = 0, ret;
u32 prop;
 
-   if (!node)
+   match = of_match_device(cpsw_of_mtable, pdev-dev);
+
+   if (!node || !match)
return -EINVAL;
 
+   match_data = (unsigned long) match-data;
+   data-hw_type = match_data;
+
if (of_property_read_u32(node, slaves, prop)) {
pr_err(Missing slaves property in the DT.\n);
return -EINVAL;
@@ -2228,12 +2252,6 @@ static const struct dev_pm_ops cpsw_pm_ops = {
.resume = cpsw_resume,
 };
 
-static const struct of_device_id cpsw_of_mtable[] = {
-   { .compatible = ti,cpsw, },
-   { /* sentinel */ },
-};
-MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
-
 static struct platform_driver cpsw_driver = {
.driver = {
.name= cpsw,
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index eb3e101..96c374a 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -37,6 +37,7 @@ struct cpsw_platform_data {
u32 mac_control;/* Mac control register */
u16 default_vlan;   /* Def VLAN for ALE lookup in VLAN aware mode*/
booldual_emac;  /* Enable Dual EMAC mode */
+   u32 hw_type;/* hardware type as specified in 'compatible' */
 };
 
 #endif /* __CPSW_H__ */
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Daniel Mack]

The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.

Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.

This patch adds code that makes use of the previously added and optional
support for passing the control mode register, and configures the
correct register bits when the slave is opened.

The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.

This code path introducted by this patch is currently exclusive for
am33xx.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  2 +
 drivers/net/ethernet/ti/cpsw.c | 61 ++
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index b717458..0895a51 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -34,6 +34,8 @@ Required properties:
 - phy_id   : Specifies slave phy id
 - phy-mode : The interface between the SoC and the PHY (a string
  that of_get_phy_mode() can understand)
+- ti,rmii-clock-ext: If present, the driver will configure the RMII
+ interface to external clock usage
 - mac-address  : Specifies slave MAC address
 
 Optional properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b194529..b839501 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -138,6 +138,13 @@ do {   
\
 #define CPSW_CMINTMAX_INTVL(1000 / CPSW_CMINTMIN_CNT)
 #define CPSW_CMINTMIN_INTVL((1000 / CPSW_CMINTMAX_CNT) + 1)
 
+#define AM33XX_GMII_SEL_MODE_MII   (0)
+#define AM33XX_GMII_SEL_MODE_RMII  (1)
+#define AM33XX_GMII_SEL_MODE_RGMII (2)
+
+#define AM33XX_GMII_SEL_RMII2_IO_CLK_ENBIT(7)
+#define AM33XX_GMII_SEL_RMII1_IO_CLK_ENBIT(6)
+
 #define cpsw_enable_irq(priv)  \
do {\
u32 i;  \
@@ -980,6 +987,56 @@ static inline void cpsw_add_dual_emac_def_ale_entries(
priv-host_port, ALE_VLAN, slave-port_vlan);
 }
 
+static void cpsw_set_phy_interface_mode(struct cpsw_slave *slave,
+   struct cpsw_priv *priv)
+{
+   u32 reg, mask, mode = 0;
+
+   switch (priv-data.hw_type) {
+   case CPSW_TYPE_AM33XX:
+   if (!priv-gmii_sel_reg)
+   break;
+
+   reg = readl(priv-gmii_sel_reg);
+
+   if (slave-phy) {
+   switch (slave-phy-interface) {
+   case PHY_INTERFACE_MODE_MII:
+   default:
+   mode = AM33XX_GMII_SEL_MODE_MII;
+   break;
+   case PHY_INTERFACE_MODE_RMII:
+   mode = AM33XX_GMII_SEL_MODE_RMII;
+   break;
+   case PHY_INTERFACE_MODE_RGMII:
+   mode = AM33XX_GMII_SEL_MODE_RGMII;
+   break;
+   };
+   }
+
+   mask = 0x3  (slave-slave_num * 2) |
+  BIT(slave-slave_num + 6);
+   mode = slave-slave_num * 2;
+
+   if (slave-data-rmii_clock_external) {
+   if (slave-slave_num == 0)
+   mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
+   else
+   mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
+   }
+
+   reg = ~mask;
+   reg |= mode;
+
+   writel(reg, priv-gmii_sel_reg);
+   break;
+
+   default:
+   break;
+
+   }
+}
+
 static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
 {
char name[32];
@@ -1028,6 +1085,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, 
struct cpsw_priv *priv)
 slave-phy-phy_id);
phy_start(slave-phy);
}
+
+   cpsw_set_phy_interface_mode(slave, priv);
 }
 
 static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
@@ -1823,6 +1882,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
 
slave_data-phy_if = of_get_phy_mode(slave_node);
+   if (of_find_property(slave_node, ti,rmii-clock-ext, NULL))
+ 

[PATCH v3 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.

I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  5 -
 drivers/net/ethernet/ti/cpsw.c | 16 
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 05d660e..4e5ca54 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -4,7 +4,10 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 Required properties:
 - compatible   : Should be ti,cpsw
 - reg  : physical base address and size of the cpsw
- registers map
+ registers map.
+ An optional third memory region can be supplied if
+ the platform has a control module register to
+ configure phy interface details
 - interrupts   : property with a value describing the interrupt
  number
 - interrupt-parent : The parent interrupt controller
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 1a91aac..bd0b664 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -372,6 +372,7 @@ struct cpsw_priv {
struct cpsw_platform_data   data;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
+   u32 __iomem *gmii_sel_reg;
u8 __iomem  *hw_stats;
struct cpsw_host_regs __iomem   *host_port_regs;
u32 msg_enable;
@@ -1999,6 +2000,21 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}
 
+   /* If the control memory region is unspecified, continue without it.
+* If it is specified, but we're unable to reserve it, bail.
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_err(priv-dev, error getting control i/o resource\n);
+   goto no_gmii_sel;
+   }
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+   if (!priv-gmii_sel_reg) {
+   dev_err(priv-dev, unable to map control i/o region\n);
+   goto clean_runtime_disable_ret;
+   }
+
+no_gmii_sel:
memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/5] net: ethernet: cpsw: switch to devres allocations

[Daniel Mack]

This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/net/ethernet/ti/cpsw.c | 145 +
 1 file changed, 44 insertions(+), 101 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..1a91aac 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t  lock;
struct platform_device  *pdev;
struct net_device   *ndev;
-   struct resource *cpsw_res;
-   struct resource *cpsw_wr_res;
struct napi_struct  napi;
struct device   *dev;
struct cpsw_platform_data   data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
*data,
 
if (of_property_read_u32(node, active_slave, prop)) {
pr_err(Missing active_slave property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-active_slave = prop;
 
if (of_property_read_u32(node, cpts_clock_mult, prop)) {
pr_err(Missing cpts_clock_mult property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_mult = prop;
 
if (of_property_read_u32(node, cpts_clock_shift, prop)) {
pr_err(Missing cpts_clock_shift property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_shift = prop;
 
-   data-slave_data = kcalloc(data-slaves, sizeof(struct cpsw_slave_data),
-  GFP_KERNEL);
+   data-slave_data = devm_kzalloc(pdev-dev, data-slaves
+   * sizeof(struct cpsw_slave_data),
+   GFP_KERNEL);
if (!data-slave_data)
-   return -EINVAL;
+   return -ENOMEM;
 
if (of_property_read_u32(node, cpdma_channels, prop)) {
pr_err(Missing cpdma_channels property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-channels = prop;
 
if (of_property_read_u32(node, ale_entries, prop)) {
pr_err(Missing ale_entries property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-ale_entries = prop;
 
if (of_property_read_u32(node, bd_ram_size, prop)) {
pr_err(Missing bd_ram_size property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-bd_ram_size = prop;
 
if (of_property_read_u32(node, rx_descs, prop)) {
pr_err(Missing rx_descs property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-rx_descs = prop;
 
if (of_property_read_u32(node, mac_control, prop)) {
pr_err(Missing mac_control property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-mac_control = prop;
 
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, phy_id, lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err(Missing slave[%d] phy_id property\n, i);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
 
return 0;
-
-error_ret:
-   kfree(data-slave_data);
-   return ret;
 }
 
 static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
priv_sl2-coal_intvl = 0;
priv_sl2-bus_freq_mhz = priv-bus_freq_mhz;
 
-   priv_sl2-cpsw_res = priv-cpsw_res;
priv_sl2-regs = priv-regs;
priv_sl2-host_port = priv-host_port;
priv_sl2-host_port_regs = priv-host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv*priv;
struct cpdma_params dma_params;
struct cpsw_ale_params  ale_params;
- 

Re: [PATCH v2] Add support for Newflow NanoBone board

[Mark Jackson]

On 11/08/13 14:25, Mark Jackson wrote:
 NanoBone Specification:
 ---
 CPU:
   TI AM335x
 
 Memory:
   256MB DDR3
   128MB NOR flash
   128KB FRAM
 
 Ethernet:
   2 x 10/100 connected to SMSC LAN8710 PHY
 
 USB:
   1 x USB2.0 Type A
 
 I2C:
   2Kbit EEPROM (Microchip 24AA02)
   RTC (Maxim DS1338)
   GPIO Expander (Microchip MCP23017)
 
 Expansion connector:
   6 x UART
   1 x MMC/SD
   1 x USB2.0
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Any comments on this patch set ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Santosh Shilimkar]

On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote:
 On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
 On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
 On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
 Hi,
 On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
 Yes, when done based on what is available then there is a
 problem when we run out of free ones because we do not
 know which one to replace. I was thinking of something like
 this,
 1) DT would give a list of all free ones, and also if some are
 mapped as default and not used, mark those also as free.

  2) While mapping see if it has a default mapping and use it.
   otherwise, pick from free list.   
 Since the entire DT is available to you at boot time, you should be able
 to find each node where interrupt-parent = crossbar and then allocate
 one of 0-160 GIC interrupt numbers for that node, no? Where would there
 be a need for default mapping and remapping? From one the mails in the
 thread the crossbar is completely flexible - any of the 320 crossbar
 interrupts can be mapped to any of the 160 GIC interrupts.

 Any GIC interrupts left after this boot-time scan can be added to an
 unused list for use with runtime DT fragments (when that support comes).
  
 Sorry if I misunderstood, but above proposal sounds like maintaining a
 separate free interrupt lines list in DT. That will quickly go out of sync.
  Say, peripheral x uses crossbar 1 and specifies this in DT.
  During boot crossbar 1 gets mapped int 10. So if by default
 some other crossbar has its interrupt mapped to 10,
 then it should be removed.  Instead clear all crossbar registers
 once and mark all as free, then  allocate only during request.
 Correct ?. In this the free no need to maintain any list.
 
 Right, so in my suggestion there is nothing like a default mapping and
 entire 160 GIC interrupt number space is up for grabs. I think this will
 be much simpler to write and maintain.
 
 If you really want to maintain default mapping as far as possible, you
 can do two passes on the crossbar interrupt numbers requested. Once to
 assign the default map - for numbers less that 160 - and then look at
 the free GIC interrupt slots and use those for numbers greater than 160.
 
The whole point we are moving to domain is not have any default
mapping(connection done) at DT level. Rather DT only specifies the
peripherals and their cross-bar connection ID(i.e cross-bar IRQ line).
This will be the driver input as a IRQ line from DT. The cross-bar
driver needs to map any of the free list available on *request* only.

Of-course you have 320 inputs out of which only 160 can be mapped
and once you run out of it, you just return error on request IRQ. 

That way there is no contention.

Regards,
Santosh


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ARM: OMAP2+: HSI: Introduce OMAP SSI driver

[Linus Walleij]

On Sun, Aug 11, 2013 at 6:17 PM, Sebastian Reichel s...@debian.org wrote:

 From: Sebastian Reichel s...@ring0.de

 This patch adds an OMAP SSI driver to the HSI framework.

 The Synchronous Serial Interface (SSI) is a legacy version
 of HSI. As in the case of HSI, it is mainly used to connect
 Application engines (APE) with cellular modem engines (CMT)
 in cellular handsets.

 It provides a multichannel, full-duplex, multi-core communication
 with no reference clock. The OMAP SSI block is capable of reaching
 speeds of 110 Mbit/s.

First: good to see this.

The HSI subsystem is lacking an active maintainer, interested?
Given that you can apparently test the OMAP HSI driver you're
one of the few applicable candidates.

Overall there is one big problem with this patch in that it implements
a lot of stuff that should not be implemented in the driver at all,
but in the HSI core.

For example compare commit
ffbbdd21329f3e15eeca6df2d4bc11c04d9d91c0
spi: create a message queueing infrastructure

This patch basically seems to redo the mistake we did in
SPI and not create a central message queue from day one,
instead re-implementing the same code in each and every
driver.

Please attempt to draw the message queueuing into the
driver core atlease.

Further the allocation of hosts seem pretty generic as well
but I'm unsure about this. I'd prefer if you take a second
look at the generalizeable parts.

(...)
 +   spinlock_t  wk_lock;
 +   spinlock_t  lock;
 +   unsigned intchannels;
 +   struct list_headtxqueue[SSI_MAX_CHANNELS];
 +   struct list_headrxqueue[SSI_MAX_CHANNELS];
 +   struct list_headbrkqueue;
 +   unsigned intirq;
 +   int wake_irq;
 +   int wake_gpio;
 +   struct tasklet_struct   pio_tasklet;
 +   struct tasklet_struct   wake_tasklet;
 +   unsigned intwktest:1; /* FIXME: HACK to be removed */
 +   unsigned intwkin_cken:1; /* Workaround */

Atleast make them into the bool type.

 +   int wk_refcount;

A refcount does not seem like it coul be negative. Should
this be unsigned?

Since these seem to be associated with a piece of code
that only runs when this goes to 0, why not just use kref?

 +   /* OMAP SSI port context */
 +   u32 sys_mpu_enable; /* We use only one irq */
 +   struct omap_ssm_ctx sst;
 +   struct omap_ssm_ctx ssr;
 +};
 +
 +/**
 + * struct omap_ssi_controller - OMAP SSI controller data
 + * @dev: device associated to the controller (HSI controller)
 + * @sys: SSI I/O base address
 + * @gdd: GDD I/O base address
 + * @ick: SSI interconnect clock
 + * @fck: SSI functional clock
 + * @ck_refcount: References count for clocks
 + * @gdd_irq: IRQ line for GDD
 + * @gdd_tasklet: bottom half for DMA transfers
 + * @gdd_trn: Array of GDD transaction data for ongoing GDD transfers
 + * @lock: lock to serialize access to GDD
 + * @ck_lock: lock to serialize access to the clocks
 + * @loss_count: To follow if we need to restore context or not
 + * @max_speed: Maximum TX speed (Kb/s) set by the clients.
 + * @sysconfig: SSI controller saved context
 + * @gdd_gcr: SSI GDD saved context
 + * @get_loss: Pointer to omap_pm_get_dev_context_loss_count, if any
 + * @port: Array of pointers of the ports of the controller
 + * @dir: Debugfs SSI root directory
 + */
 +struct omap_ssi_controller {
 +   struct device   *dev;
 +   void __iomem*sys;
 +   void __iomem*gdd;
 +   struct clk  *ick;
 +   struct clk  *fck;
 +   int ck_refcount;

Unsigned?

Since these seem to be associated with a piece of code
that only runs when this goes to 0, why not just use kref?

(...)
 +static int ssi_set_port_mode(struct omap_ssi_port *omap_port, void *data)
 +{
 +   u32 *mode = data;
 +
 +   __raw_writel(*mode, omap_port-sst_base + SSI_SST_MODE_REG);
 +   __raw_writel(*mode, omap_port-ssr_base + SSI_SSR_MODE_REG);
 +   /* OCP barrier */
 +   *mode = __raw_readl(omap_port-ssr_base + SSI_SSR_MODE_REG);
 +
 +   return 0;
 +}

Why do you insist on using __raw_readl/writel()? I can understand
that you want to use readl/writel_relaxed() but __raw* is just
ugly and confusing.

The last in a series of writel should probably be a plain
writel() so as to flush buffers etc.

Comment applies to every instance of these.

 +static u32 ssi_calculate_div(struct hsi_controller *ssi)
 +{
 +   struct omap_ssi_controller *omap_ssi = hsi_controller_drvdata(ssi);
 +   u32 tx_fckrate = (u32) omap_ssi-fck_rate;
 +
 +   /* / 2 : SSI TX clock is always half of the SSI functional clock */
 +   tx_fckrate = 1;
 +   /* Round down when tx_fckrate % omap_ssi-max_speed == 0 */
 +   tx_fckrate--;
 +   dev_dbg(ssi-device, TX div %d for fck_rate %lu Khz speed 

Re: [PATCH 3/3] ARM: OMAP2+: Add SSI driver configuration

[Linus Walleij]

On Mon, Aug 12, 2013 at 10:30 AM, Tony Lindgren t...@atomide.com wrote:
 * Sebastian Reichel s...@debian.org [130811 09:25]:
 From: Sebastian Reichel s...@ring0.de

 This patch configures and activates the OMAP SSI driver on the RX-51.

 Hmm, I'd rather see this be DT only driver at this point.

+1 on this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Sergei Shtylyov]

Hello.

On 23-08-2013 12:43, Daniel Mack wrote:


At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.



I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.



Signed-off-by: Daniel Mack zon...@gmail.com

[...]


diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 1a91aac..bd0b664 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c

[...]

@@ -1999,6 +2000,21 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}

+   /* If the control memory region is unspecified, continue without it.
+* If it is specified, but we're unable to reserve it, bail.
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_err(priv-dev, error getting control i/o resource\n);


   If the resource is optional, why use dev_err()?


+   goto no_gmii_sel;
+   }
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+   if (!priv-gmii_sel_reg) {


   devm_ioremap_resource() doesn't return NULL, it returns error, so you 
should check with IS_ERR() and propagate the error to the caller with PTR_ERR().



+   dev_err(priv-dev, unable to map control i/o region\n);


   devm_ioremap_resource() prints out the error messages itself, so you don't 
have to.



+   goto clean_runtime_disable_ret;
+   }
+
+no_gmii_sel:
memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));


WBR, Sergei

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

On 23.08.2013 16:03, Sergei Shtylyov wrote:
 On 23-08-2013 12:43, Daniel Mack wrote:

 +dev_err(priv-dev, unable to map control i/o region\n);
 
 devm_ioremap_resource() prints out the error messages itself, so you 
 don't 
 have to.

Right. Thanks. Will send a v4.



Best,
Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
 drivers/net/ethernet/ti/cpsw.c | 32 --
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 4e5ca54..b717458 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 --
 
 Required properties:
-- compatible   : Should be ti,cpsw
+- compatible   : Should be ti,cpsw for generic cpsw support, or
+ ti,am3352-cpsw for AM3352 SoCs
 - reg  : physical base address and size of the cpsw
  registers map.
  An optional third memory region can be supplied if
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7a25ff4..73c44cb6 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -155,6 +155,11 @@ do {   
\
((priv-data.dual_emac) ? priv-emac_port : \
priv-data.active_slave)
 
+enum {
+   CPSW_TYPE_GENERIC,
+   CPSW_TYPE_AM33XX
+};
+
 static int debug_level;
 module_param(debug_level, int, 0);
 MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
@@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave *slave, 
struct cpsw_priv *priv,
slave-port_vlan = data-dual_emac_res_vlan;
 }
 
+static const struct of_device_id cpsw_of_mtable[] = {
+   {
+   .compatible = ti,am3352-cpsw,
+   .data   = (void *) CPSW_TYPE_AM33XX
+   }, {
+   .compatible = ti,cpsw,
+   .data   = (void *) CPSW_TYPE_GENERIC
+   },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
+
 static int cpsw_probe_dt(struct cpsw_platform_data *data,
 struct platform_device *pdev)
 {
struct device_node *node = pdev-dev.of_node;
+   const struct of_device_id *match;
struct device_node *slave_node;
+   unsigned long match_data;
int i = 0, ret;
u32 prop;
 
-   if (!node)
+   match = of_match_device(cpsw_of_mtable, pdev-dev);
+
+   if (!node || !match)
return -EINVAL;
 
+   match_data = (unsigned long) match-data;
+   data-hw_type = match_data;
+
if (of_property_read_u32(node, slaves, prop)) {
pr_err(Missing slaves property in the DT.\n);
return -EINVAL;
@@ -2228,12 +2252,6 @@ static const struct dev_pm_ops cpsw_pm_ops = {
.resume = cpsw_resume,
 };
 
-static const struct of_device_id cpsw_of_mtable[] = {
-   { .compatible = ti,cpsw, },
-   { /* sentinel */ },
-};
-MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
-
 static struct platform_driver cpsw_driver = {
.driver = {
.name= cpsw,
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index eb3e101..96c374a 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -37,6 +37,7 @@ struct cpsw_platform_data {
u32 mac_control;/* Mac control register */
u16 default_vlan;   /* Def VLAN for ALE lookup in VLAN aware mode*/
booldual_emac;  /* Enable Dual EMAC mode */
+   u32 hw_type;/* hardware type as specified in 'compatible' */
 };
 
 #endif /* __CPSW_H__ */
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/5] cpsw: support for control module register

[Daniel Mack]

v3 - v4:
* use IS_ERR() to check for failed devm_ioremap_resource()
  calls (reported by Sergei Shtylyov)

v2 - v3:
* swap ti,am3352-cpsw and ti,cpsw to work around a matching
  bug (reported by Sekhar)

v1 - v2:
* combine devm_request_mem_region() and devm_ioremap() and use
  devm_ioremap_resource() (reported by Sergei Shtylyov)
* fix multi-line comment style (reported by Sergei Shtylyov)
* fix ti,rmii-clock-ext property name (reported by Sekhar)
* rebased to net-next (reported by Mugunthan V N, David Miller)
* add a new compatible type, and handle AM33xx specific
  registers that way (reported by Sekhar)
* move gmii_sel_reg modifications to the open routine
  (reported by Mugunthan V N)


Daniel Mack (5):
  net: ethernet: cpsw: switch to devres allocations
  net: ethernet: cpsw: add optional third memory region for CONTROL
module
  net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
  net: ethernet: cpsw: add support for hardware interface mode config
  ARM: dts: am33xx: adopt to cpsw changes

 Documentation/devicetree/bindings/net/cpsw.txt |  10 +-
 arch/arm/boot/dts/am33xx.dtsi  |   5 +-
 drivers/net/ethernet/ti/cpsw.c | 254 ++---
 drivers/net/ethernet/ti/cpsw.h |   2 +
 4 files changed, 159 insertions(+), 112 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Daniel Mack]

The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.

Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.

This patch adds code that makes use of the previously added and optional
support for passing the control mode register, and configures the
correct register bits when the slave is opened.

The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.

This code path introducted by this patch is currently exclusive for
am33xx.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  2 +
 drivers/net/ethernet/ti/cpsw.c | 61 ++
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index b717458..0895a51 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -34,6 +34,8 @@ Required properties:
 - phy_id   : Specifies slave phy id
 - phy-mode : The interface between the SoC and the PHY (a string
  that of_get_phy_mode() can understand)
+- ti,rmii-clock-ext: If present, the driver will configure the RMII
+ interface to external clock usage
 - mac-address  : Specifies slave MAC address
 
 Optional properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 73c44cb6..86b8f7a 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -138,6 +138,13 @@ do {   
\
 #define CPSW_CMINTMAX_INTVL(1000 / CPSW_CMINTMIN_CNT)
 #define CPSW_CMINTMIN_INTVL((1000 / CPSW_CMINTMAX_CNT) + 1)
 
+#define AM33XX_GMII_SEL_MODE_MII   (0)
+#define AM33XX_GMII_SEL_MODE_RMII  (1)
+#define AM33XX_GMII_SEL_MODE_RGMII (2)
+
+#define AM33XX_GMII_SEL_RMII2_IO_CLK_ENBIT(7)
+#define AM33XX_GMII_SEL_RMII1_IO_CLK_ENBIT(6)
+
 #define cpsw_enable_irq(priv)  \
do {\
u32 i;  \
@@ -980,6 +987,56 @@ static inline void cpsw_add_dual_emac_def_ale_entries(
priv-host_port, ALE_VLAN, slave-port_vlan);
 }
 
+static void cpsw_set_phy_interface_mode(struct cpsw_slave *slave,
+   struct cpsw_priv *priv)
+{
+   u32 reg, mask, mode = 0;
+
+   switch (priv-data.hw_type) {
+   case CPSW_TYPE_AM33XX:
+   if (!priv-gmii_sel_reg)
+   break;
+
+   reg = readl(priv-gmii_sel_reg);
+
+   if (slave-phy) {
+   switch (slave-phy-interface) {
+   case PHY_INTERFACE_MODE_MII:
+   default:
+   mode = AM33XX_GMII_SEL_MODE_MII;
+   break;
+   case PHY_INTERFACE_MODE_RMII:
+   mode = AM33XX_GMII_SEL_MODE_RMII;
+   break;
+   case PHY_INTERFACE_MODE_RGMII:
+   mode = AM33XX_GMII_SEL_MODE_RGMII;
+   break;
+   };
+   }
+
+   mask = 0x3  (slave-slave_num * 2) |
+  BIT(slave-slave_num + 6);
+   mode = slave-slave_num * 2;
+
+   if (slave-data-rmii_clock_external) {
+   if (slave-slave_num == 0)
+   mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
+   else
+   mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
+   }
+
+   reg = ~mask;
+   reg |= mode;
+
+   writel(reg, priv-gmii_sel_reg);
+   break;
+
+   default:
+   break;
+
+   }
+}
+
 static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
 {
char name[32];
@@ -1028,6 +1085,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, 
struct cpsw_priv *priv)
 slave-phy-phy_id);
phy_start(slave-phy);
}
+
+   cpsw_set_phy_interface_mode(slave, priv);
 }
 
 static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
@@ -1823,6 +1882,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
 
slave_data-phy_if = of_get_phy_mode(slave_node);
+   if (of_find_property(slave_node, ti,rmii-clock-ext, NULL))
+

[PATCH v4 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.

I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  5 -
 drivers/net/ethernet/ti/cpsw.c | 16 
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 05d660e..4e5ca54 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -4,7 +4,10 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 Required properties:
 - compatible   : Should be ti,cpsw
 - reg  : physical base address and size of the cpsw
- registers map
+ registers map.
+ An optional third memory region can be supplied if
+ the platform has a control module register to
+ configure phy interface details
 - interrupts   : property with a value describing the interrupt
  number
 - interrupt-parent : The parent interrupt controller
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 849af52..7a25ff4 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -372,6 +372,7 @@ struct cpsw_priv {
struct cpsw_platform_data   data;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
+   u32 __iomem *gmii_sel_reg;
u8 __iomem  *hw_stats;
struct cpsw_host_regs __iomem   *host_port_regs;
u32 msg_enable;
@@ -1999,6 +2000,21 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}
 
+   /* If the control memory region is unspecified, continue without it.
+* If it is specified, but we're unable to reserve it, bail.
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_info(priv-dev, error getting control i/o resource\n);
+   goto no_gmii_sel;
+   }
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(priv-gmii_sel_reg)) {
+   dev_err(priv-dev, unable to map control i/o region\n);
+   goto clean_runtime_disable_ret;
+   }
+
+no_gmii_sel:
memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/5] net: ethernet: cpsw: switch to devres allocations

[Daniel Mack]

This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/net/ethernet/ti/cpsw.c | 147 +
 1 file changed, 45 insertions(+), 102 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..849af52 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t  lock;
struct platform_device  *pdev;
struct net_device   *ndev;
-   struct resource *cpsw_res;
-   struct resource *cpsw_wr_res;
struct napi_struct  napi;
struct device   *dev;
struct cpsw_platform_data   data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
*data,
 
if (of_property_read_u32(node, active_slave, prop)) {
pr_err(Missing active_slave property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-active_slave = prop;
 
if (of_property_read_u32(node, cpts_clock_mult, prop)) {
pr_err(Missing cpts_clock_mult property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_mult = prop;
 
if (of_property_read_u32(node, cpts_clock_shift, prop)) {
pr_err(Missing cpts_clock_shift property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_shift = prop;
 
-   data-slave_data = kcalloc(data-slaves, sizeof(struct cpsw_slave_data),
-  GFP_KERNEL);
+   data-slave_data = devm_kzalloc(pdev-dev, data-slaves
+   * sizeof(struct cpsw_slave_data),
+   GFP_KERNEL);
if (!data-slave_data)
-   return -EINVAL;
+   return -ENOMEM;
 
if (of_property_read_u32(node, cpdma_channels, prop)) {
pr_err(Missing cpdma_channels property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-channels = prop;
 
if (of_property_read_u32(node, ale_entries, prop)) {
pr_err(Missing ale_entries property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-ale_entries = prop;
 
if (of_property_read_u32(node, bd_ram_size, prop)) {
pr_err(Missing bd_ram_size property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-bd_ram_size = prop;
 
if (of_property_read_u32(node, rx_descs, prop)) {
pr_err(Missing rx_descs property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-rx_descs = prop;
 
if (of_property_read_u32(node, mac_control, prop)) {
pr_err(Missing mac_control property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-mac_control = prop;
 
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, phy_id, lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err(Missing slave[%d] phy_id property\n, i);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
 
return 0;
-
-error_ret:
-   kfree(data-slave_data);
-   return ret;
 }
 
 static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
priv_sl2-coal_intvl = 0;
priv_sl2-bus_freq_mhz = priv-bus_freq_mhz;
 
-   priv_sl2-cpsw_res = priv-cpsw_res;
priv_sl2-regs = priv-regs;
priv_sl2-host_port = priv-host_port;
priv_sl2-host_port_regs = priv-host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv*priv;
struct cpdma_params dma_params;
struct cpsw_ale_params  ale_params;
- 

[PATCH v4 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Daniel Mack]

This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.

Also update the compatible string to make use of the am335x specific
features of the cpsw driver.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/boot/dts/am33xx.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a785b95..c7b41ae 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -446,7 +446,7 @@
};
 
mac: ethernet@4a10 {
-   compatible = ti,cpsw;
+   compatible = ti,am3352-cpsw, ti,cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
ale_entries = 1024;
@@ -459,7 +459,8 @@
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
reg = 0x4a10 0x800
-  0x4a101200 0x100;
+  0x4a101200 0x100
+  0x44e10650 0x4;
#address-cells = 1;
#size-cells = 1;
interrupt-parent = intc;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
 In order to support features that are specific to the AM335x IP, we have
 to add hardware types and another compatible string.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
  drivers/net/ethernet/ti/cpsw.c | 32 
 --
  drivers/net/ethernet/ti/cpsw.h |  1 +
  3 files changed, 28 insertions(+), 8 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index 4e5ca54..b717458 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
  --
  
  Required properties:
 -- compatible : Should be ti,cpsw
 +- compatible : Should be ti,cpsw for generic cpsw support, or
 +   ti,am3352-cpsw for AM3352 SoCs
  - reg: physical base address and size of the cpsw
 registers map.
 An optional third memory region can be supplied if
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 7a25ff4..73c44cb6 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -155,6 +155,11 @@ do { 
 \
   ((priv-data.dual_emac) ? priv-emac_port : \
   priv-data.active_slave)
  
 +enum {
 + CPSW_TYPE_GENERIC,
 + CPSW_TYPE_AM33XX
 +};
 +
  static int debug_level;
  module_param(debug_level, int, 0);
  MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
 @@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave *slave, 
 struct cpsw_priv *priv,
   slave-port_vlan = data-dual_emac_res_vlan;
  }
  
 +static const struct of_device_id cpsw_of_mtable[] = {
 + {
 + .compatible = ti,am3352-cpsw,
I didn't notice this earlier, but can't you use the IP version
as a compatible instead of using a SOC name. Whats really SOC specific
on this IP ? Sorry i have missed any earlier discussion on this but
this approach doesn't seem good. Its like adding SOC checks in the
driver subsystem.

Regards,
Santosh


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Dave Gerlach]

On 08/20/2013 05:48 PM, Paul Walmsley wrote:


Hi folks,

catching up on this thread.

On 08/06/2013 12:49 PM, Dave Gerlach wrote:


+
+static int am33xx_pm_suspend(void)
+{
+ int i, j, ret = 0;
+
+ int status = 0;
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ /*
+  * By default the following IPs do not have MSTANDBY asserted
+  * which is necessary for PER domain transition. If the drivers
+  * are not compiled into the kernel HWMOD code will not change the
+  * state of the IPs if the IP was not never enabled. To ensure
+  * that there no issues with or without the drivers being compiled
+  * in the kernel, we forcefully put these IPs to idle.
+  */
+ for (i = 0; i  ARRAY_SIZE(am33xx_mod); i++) {
+ pdev = to_platform_device(am33xx_mod[i].dev);
+ od = to_omap_device(pdev);
+ if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER) {
+ omap_device_enable_hwmods(od);
+ omap_device_idle_hwmods(od);
+ }
+ }


Does this have to be done for every suspend entry, or can it just be done
once during kernel initialization?

If the latter, shouldn't this be done by hwmod during the initial reset
and idle of all of these devices, based on a flag?  For example, we had
this flag for OMAP3630:

  * HWMOD_FORCE_MSTANDBY: Always keep MIDLEMODE bits cleared so that device
  * is kept in force-standby mode. Failing to do so causes PM problems
  * with musb on OMAP3630 at least. Note that musb has a dedicated
register
  * to control MSTANDBY signal when MIDLEMODE is set to force-standby.



Hi,
Unfortunately this does have to be done at some point after every 
suspend/resume cycle because while the IPs are idled during initial 
reset, after a suspend cycle the context loss when no driver is bound 
causes MSTANDBY to be unasserted again which as mentioned breaks the PER 
power domain transition during the next suspend attempt.


The current plan for this is somewhat similar to what you mentioned, all 
of the troublesome modules will be flagged in hwmod and when the hwmods 
are loaded they are tracked if no driver gets bound and then idled post 
resume by a pm_notifier.


Regards,
Dave



- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Sergei Shtylyov]

On 23-08-2013 18:16, Daniel Mack wrote:


At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.



I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.



Signed-off-by: Daniel Mack zon...@gmail.com

[...]


diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 849af52..7a25ff4 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c

[...]

@@ -1999,6 +2000,21 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}

+   /* If the control memory region is unspecified, continue without it.
+* If it is specified, but we're unable to reserve it, bail.
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_info(priv-dev, error getting control i/o resource\n);
+   goto no_gmii_sel;
+   }
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(priv-gmii_sel_reg)) {
+   dev_err(priv-dev, unable to map control i/o region\n);


   You didn't actually seem to heed my words about error message. And don't 
you want to do:


res = PTR_ERR(priv-gmii_sel_reg);


+   goto clean_runtime_disable_ret;
+   }
+
+no_gmii_sel:
memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));


WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions

[Benoit Cousson]

Hi Sekhar,

On 23/08/2013 10:50, Sekhar Nori wrote:

Hi Benoit,

Did you get a chance to think about this, I have provided some
replies below.

On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote:

Hi Sekhar,

On 16/08/2013 17:41, Sekhar Nori wrote:


On 8/16/2013 7:45 PM, Benoit Cousson wrote:

Hi Gururaja,

On 16/08/2013 13:36, Hebbar, Gururaja wrote:

The syntax of compatible property in DT is to mention the
Most specific match to most generic match.

Since AM335x is the platform with latest IP revision, add it
1st in the device id table.


I don't understand why? The order should not matter at all.


Yes, it should not. We are trying to work around a bug in the
kernel where the compatible order is not honored (instead the
order in of_match[] array matters). There were patches being
discussed to fix this.



I've tried to follow the thread you had with Mark on the v2,
but AFAIK, you've never answered to his latest question.

Moreover, checking the differences between the Davinci and the
am3352 RTC IP, I would not claim that both are compatible.

Sure you can use the am3352 with the Davinci driver, but you
will lose the wakeup functionality without even being notify
about that.


When the kernel is fixed for the bug pointed out above, this
should not happen with properly defined compatible property.



For my point of view, compatible mean that the HW will still be
fully functional with both versions of the driver, which is not
the case here.


I do not think that's the interpretation of compatible. Its goes
from most specific to most generic per the ePAPR spec. That in
itself says that 100% functionality is not expected if you don't
find a match for the more specific property.


Well, to be honest I checked as well the official documentation,
and this is far from being clear:

page 21 of the ePAPR:

 Property: compatible Value type: stringlist

Description: The compatible property value consists of one or more
strings that define the specific programming model for the device.
This list of strings should be used by a client program for device
driver selection. The property value consists of a concatenated
list of null terminated strings, from most specific to most
general. They allow a device to express its compatibility with a
family of similar devices, potentially allowing a single device
driver to match against several devices.

The recommended format is “manufacturer,model”, where manufacturer
is a string describing the name of the manufacturer (such as a
stock ticker symbol), and model specifies the model number.

Example: compatible = “fsl,mpc8641-uart”, “ns16550; In this
example, an operating system would first try to locate a device
driver that supported fsl,mpc8641-uart. If a driver was not found,
it would then try to locate a driver that supported the more
general ns16550 device type. 

In this example, the generic vs specific is just about the driver.
You could have one driver that manage 10 different UARTs or a
specific one that manage only your HW.


Right, the assumption is that a specific driver is written because
there are parts of the hardware that cannot be serviced by generic
driver. So ultimately its all driven by changes in hardware.


Yeah, that example remind me the omap-serial driver we had done to 
handle the DMA mode that was not supported by the generic one.



There is no assumption about the lost of functionality by using the
generic version of the driver. How the user is supposed to know the
amount of functionality he will lose, and if this is acceptable to
him.


I suppose the generic driver would return some error code like
-ENOTSUP for the functionality it cannot provide.


Well, I guess it depends of the added functionality add how far the IP 
version is forward compatible with the old driver. If the new IP version 
is just improving the performance by adding a DMA mode instead of the 
PIO, then the driver API can remain the same.
But if you add a new functionality that will require an extended API, 
there is no way you can report such error. Except if the API itself is 
done with a good forward compatibility support.


And if the new functionality is mandatory to make the new system 
operational, returning an error might just make the system not working 
at all.



I'd rather have an error at boot saying that the driver is not
compatible with the HW and thus I will have to upgrade the kernel,
than booting a kernel that will not work as expected because some
functionality are missing for that specific HW.


If you have an update available, you can always upgrade to it. But
what if there is no update available? Would you rather not have the
user use the available functionality in the meanwhile while he waits
for the kernel support to be developed.


It depends... In the UART example, that's just a matter of performance 
improvement, so keeping the old version is fine.
As soon as the driver is usable, and the new feature is not mandatory to 
ensure the system will 

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Benoit Cousson]

Hi Santosh,

[...]


+static const struct of_device_id cpsw_of_mtable[] = {
+   {
+   .compatible = ti,am3352-cpsw,

I didn't notice this earlier, but can't you use the IP version
as a compatible instead of using a SOC name. Whats really SOC specific
on this IP ? Sorry i have missed any earlier discussion on this but
this approach doesn't seem good. Its like adding SOC checks in the
driver subsystem.


Hehe, welcome to the club!
I keep arguing about that as well :-)

I think we should create a Facebook group: 
against-the-soc-version-in-the-compatible-string.


Regards,
Benoit

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] DMA: add help function to check whether dma controller registered

[Stephen Warren]

On 08/22/2013 07:17 PM, Richard Zhao wrote:
 On Fri, Aug 23, 2013 at 04:36:53AM +0800, Stephen Warren wrote:
 On 08/22/2013 12:43 AM, Richard Zhao wrote:
 DMA client device driver usually needs to know at probe time whether
 dma controller has been registered to deffer probe. So add a help
 function of_dma_check_controller.

 DMA request channel functions can also used to check it, but they
 are usually called at open() time.

 This new function is almost identical to the existing
 of_dma_request_slave_channel(). Surely the code should be shared?

 ofdma-of_dma_xlate(dma_spec, ofdma);
 The above is called holding of_dma_lock. If I want to abstract the
 common lines, there' two options.

What is the problem with acquiring the lock? If request_slave_channel()
needs to take the lock, then there must be a reason which presumably
applies to the other path too.

...
 But that said, I don't see any need for a new function; why can't
 drivers simply call of_dma_request_slave_channel() at probe time;

 It'll mislead user. channel supposed to be request at open time.

I don't agree.

 from
 what I can see, that function doesn't actually request the channel, but
 rather simply looks it up, just like this one. The only difference is
 that of_dma_xlate() is also called, but that's just doing some data
 transformation, not actually recording channel ownership.

 xlate function request the channel if things go well.

Oh. xlate should not do that; that's a design flaw. xlate should do
nothing more than translate the DT content to an internal channel ID.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] DMA: let filter functions of of_dma_simple_xlate possible check of_node

[Stephen Warren]

On 08/22/2013 07:29 PM, Richard Zhao wrote:
 On Fri, Aug 23, 2013 at 04:18:27AM +0800, Stephen Warren wrote:
 On 08/21/2013 11:19 PM, Richard Zhao wrote:
 On Fri, Aug 02, 2013 at 10:00:00AM +0800, Richard Zhao wrote:
 pass of_phandle_args dma_spec to dma_request_channel in 
 of_dma_simple_xlate,
 so the filter function could access of_node in of_phandle_args.

 It also remove restriction of #dma-cells has to be one.

 Signed-off-by: Richard Zhao riz...@nvidia.com
 ---
  drivers/dma/edma.c |  7 +--
  drivers/dma/of-dma.c   | 10 --
  drivers/dma/omap-dma.c |  6 --
  3 files changed, 13 insertions(+), 10 deletions(-)


 Hi Vinod,

 Can you please pick up this change?

 Hi Stephen,

 Can you please give a ack or reviewed-by etc?

 Hmm. Looking at the patch, I'm not sure it's right.

 This patch simply passes all the specfier args to the filter function,
 and the code to check the equality of the of_node to the filter args is
 still duplicated in each DMA driver. Instead, the DMA core should be
 implementing the equality check, and only even calling the
 driver-specific filter function for devices where the client's phandle
 matches the DMA providing device's of_node handle.
 
 Filter function is called in dmaengine core code, independent of dt.

The core code can still check if a dmaengine's driver was instantiated
from DT and take additional actions in that case.

 And the reason why the driver has to write its own filter function is
 it has to store slave id there in its own way.

I'm not saying don't call the driver's filter function, but rather that
the dmaengine core should perform the common checks before doing so.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 11:22 AM, Benoit Cousson wrote:
 Hi Santosh,
 
 [...]
 
 +static const struct of_device_id cpsw_of_mtable[] = {
 +{
 +.compatible= ti,am3352-cpsw,
 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.
 
 Hehe, welcome to the club!
 I keep arguing about that as well :-)
 
 I think we should create a Facebook group: 
 against-the-soc-version-in-the-compatible-string.
 
Indeed !!

Regards,
Santosh

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions

[Sekhar Nori]

On 8/23/2013 8:40 PM, Benoit Cousson wrote:

 There is no assumption about the lost of functionality by using the
 generic version of the driver. How the user is supposed to know the
 amount of functionality he will lose, and if this is acceptable to
 him.

 I suppose the generic driver would return some error code like
 -ENOTSUP for the functionality it cannot provide.
 
 Well, I guess it depends of the added functionality add how far the IP
 version is forward compatible with the old driver. If the new IP version
 is just improving the performance by adding a DMA mode instead of the
 PIO, then the driver API can remain the same.
 But if you add a new functionality that will require an extended API,
 there is no way you can report such error. Except if the API itself is
 done with a good forward compatibility support.
 
 And if the new functionality is mandatory to make the new system
 operational, returning an error might just make the system not working
 at all.

If the driver cannot work at all, then yes, I would not claim
compatibility. At least a subset of functionality should work.

 
 Why
 would someone write a driver supporting “fsl,mpc8641-uart” if 100% of
 its hardware features are also supported by “ns16550 driver?
 
 That's still doable, if you want to reduce the size of a big generic
 driver into a smaller specific driver. The point is that the compatible

Thats plausible. Although I have to admit I have never seen a new driver
being written just because another existing driver is bloated.

 value does not have any assumption about the driver that will handle it.

Right. Its all driven by hardware changes.

 
 The other issue is that we are supposed to always use the latest SoC
 version even if the IP is 100% the same. Like
 
 omap5-timer {
 compatible = omap5-timer, omap4-timer;
 }
 
 So how are you suppose to differentiate the same IP, and a compatible IP???
 
 That's what I don't like in that compatible string definition. You do
 not necessarily know the amount of compatibility you are talking about.

That's correct. The strings themselves tell very little how much OMAP5
timer works when compatible = omap4-timer is passed. Some known
limitations can perhaps be documented in binding definition.

 that it is today. Thing is, you can never know if the IP needs any
 additional handling even after reading the spec. We keep discovering
 new features/quirks. So, when writing new-soc.dtsi its safer to
 always use

 compatible = ti,new-soc-rtc, ti,compatible-soc-rtc;

 even though _today_ you may not have code that specifically handles
 ti,new-soc-rtc.
 
 Well, we can do that, but honestly, I do not see the need. You can
 always update the dts later. Why would we add hundreds more compatible
 strings just in case few devices will need special handling. That's
 overkill.
 If was maybe easy and harmless in the good old PPC time when the DTS
 files were relatively small, but the ARM DTS files are much bigger.
 
 In the name of the Keep It Simple Principle, I would just avoid adding
 something just because it might be useful in 5 % of the cases.

It certainly seems overkill today. If and when the .dts[i] files are
maintained as a separate project it will become painful to keep kernel
and .dtb in sync. This will then become important, as bootloader
independence today is.

 Otherwise they get plain RTC functionality - but at least they
 get something instead of no RTC.

 Because you assume that this feature is not important and thus you
 can use the plain RTC, but what if someone is buying that HW
 because of this new feature. Without that feature his system will
 just not work properly.

 Right, but thats not a problem DT can solve. He/she needs to hassle
 TI for updated drivers. But there could be 10 other customers who are
 just okay with plain RTC. So till the time driver is updated to use
 ti,am3352-rtc, are you saying no one should be able to use the RTC
 on the SoC at all even though 90% features are available?
 
 Again, if it will not prevent the system to work properly, then it is
 fine. But let's assume that without the wakeup RTC functionality, you
 just cannot wakeup from suspend an am3352 board. Then you end up with a
 non functional system for the PM point of view.

Correct, but this is because of lack of kernel support for a feature.
Not because of the way compatible is written.

 Someone who is not aware that the compatible RTC is not supporting that
 feature might spend some time figuring out why he cannot wakeup from
 suspend on a RTC alarm.

Right. DT/compatible does not make this problem better or worse. Even
using platform device model, you would still end up with a partially
working system.

 Saying that this is compatible whereas you lost functionality is
 lying to the customer for my point of view.

 If 100% functionality is required for compatibility then I am afraid
 there is nothing like compatibility. There are just different
 isolated versions.
 
 I guess you are right.
 

Re: [PATCH v4 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

On 23.08.2013 16:59, Sergei Shtylyov wrote:
 On 23-08-2013 18:16, Daniel Mack wrote:

 +priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
 +if (IS_ERR(priv-gmii_sel_reg)) {
 +dev_err(priv-dev, unable to map control i/o region\n);
 
 You didn't actually seem to heed my words about error message.

Well yes I did, but only in the check for platform_get_resource(). As
the comment says - we pass on if that memory region is not given, but if
it is given, it also has to be valid.

 And don't  you want to do:
 
   res = PTR_ERR(priv-gmii_sel_reg);


Erm, of course. Sorry for that.


Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Sekhar Nori]

On 8/23/2013 7:08 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote:
 On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
 On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
 On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
 Hi,
 On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
 On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
  maps crossbar number-  to interrupt number and
  calls request_irq(int_no, crossbar_handler,..)
 So will this mapping happen based on some data passed from DT or
 just based on whats available when the device does a request_irq()?

 If its based on whats available then I see an issue when you need
 to remap something thats already mapped by default (and not used)
 since you run out of all free ones.
 Yes, when done based on what is available then there is a
 problem when we run out of free ones because we do not
 know which one to replace. I was thinking of something like
 this,
 1) DT would give a list of all free ones, and also if some are
 mapped as default and not used, mark those also as free.

  2) While mapping see if it has a default mapping and use it.
   otherwise, pick from free list.   
 Since the entire DT is available to you at boot time, you should be able
 to find each node where interrupt-parent = crossbar and then allocate
 one of 0-160 GIC interrupt numbers for that node, no? Where would there
 be a need for default mapping and remapping? From one the mails in the
 thread the crossbar is completely flexible - any of the 320 crossbar
 interrupts can be mapped to any of the 160 GIC interrupts.

 Any GIC interrupts left after this boot-time scan can be added to an
 unused list for use with runtime DT fragments (when that support comes).
  
 Sorry if I misunderstood, but above proposal sounds like maintaining a
 separate free interrupt lines list in DT. That will quickly go out of sync.
  Say, peripheral x uses crossbar 1 and specifies this in DT.
  During boot crossbar 1 gets mapped int 10. So if by default
 some other crossbar has its interrupt mapped to 10,
 then it should be removed.  Instead clear all crossbar registers
 once and mark all as free, then  allocate only during request.
 Correct ?. In this the free no need to maintain any list.

 Right, so in my suggestion there is nothing like a default mapping and
 entire 160 GIC interrupt number space is up for grabs. I think this will
 be much simpler to write and maintain.

 If you really want to maintain default mapping as far as possible, you
 can do two passes on the crossbar interrupt numbers requested. Once to
 assign the default map - for numbers less that 160 - and then look at
 the free GIC interrupt slots and use those for numbers greater than 160.

 The whole point we are moving to domain is not have any default
 mapping(connection done) at DT level. Rather DT only specifies the
 peripherals and their cross-bar connection ID(i.e cross-bar IRQ line).
 This will be the driver input as a IRQ line from DT. The cross-bar
 driver needs to map any of the free list available on *request* only.

Right, the mapping can be done on request. That will be cleaner.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

On 23.08.2013 16:23, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:

 +static const struct of_device_id cpsw_of_mtable[] = {
 +{
 +.compatible = ti,am3352-cpsw,

 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.

As I already mentioned in the cover letter and in the commit message, I
just don't know which criteria makes most sense here.

On a general note, I would say that chances that this exactly IP core
with the same version number will appear on some other silicon which
doesn't support the control mode register in an AM33xx fashion, is not
necessarily negligible.

So what that new compatible string denotes is the cpsw in a version as
found on am3352 SoCs, which is actually exactly what it does.

I don't have a strong opinion here, but see your point. I just don't
have a better idea on how to treat that.


Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Sekhar Nori]

On 8/23/2013 7:53 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
 In order to support features that are specific to the AM335x IP, we have
 to add hardware types and another compatible string.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
  drivers/net/ethernet/ti/cpsw.c | 32 
 --
  drivers/net/ethernet/ti/cpsw.h |  1 +
  3 files changed, 28 insertions(+), 8 deletions(-)

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index 4e5ca54..b717458 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
  --
  
  Required properties:
 -- compatible: Should be ti,cpsw
 +- compatible: Should be ti,cpsw for generic cpsw support, 
 or
 +  ti,am3352-cpsw for AM3352 SoCs
  - reg   : physical base address and size of the cpsw
registers map.
An optional third memory region can be supplied if
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 7a25ff4..73c44cb6 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -155,6 +155,11 @@ do {
 \
  ((priv-data.dual_emac) ? priv-emac_port : \
  priv-data.active_slave)
  
 +enum {
 +CPSW_TYPE_GENERIC,
 +CPSW_TYPE_AM33XX
 +};
 +
  static int debug_level;
  module_param(debug_level, int, 0);
  MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
 @@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave 
 *slave, struct cpsw_priv *priv,
  slave-port_vlan = data-dual_emac_res_vlan;
  }
  
 +static const struct of_device_id cpsw_of_mtable[] = {
 +{
 +.compatible = ti,am3352-cpsw,
 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.

The objection then should not just be to the name of compatible string,
but to handling AM335x control module register in CPSW driver. What
would be the alternate method of doing what Daniel is doing? I vaguely
remember there were attempts to develop an independent control module
driver that were abandoned.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Mugunthan V N]

On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
 The cpsw currently lacks code to properly set up the hardware interface
 mode on AM33xx. Other platforms might be equally affected.

 Usually, the bootloader will configure the control module register, so
 probably that's why such support wasn't needed in the past. In suspend
 mode though, this register is modified, and so it needs reprogramming
 after resume.

 This patch adds code that makes use of the previously added and optional
 support for passing the control mode register, and configures the
 correct register bits when the slave is opened.

 The AM33xx also has a bit for each slave to configure the RMII reference
 clock direction. Setting it is now supported by a per-slave DT property.

 This code path introducted by this patch is currently exclusive for
 am33xx.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  2 +
  drivers/net/ethernet/ti/cpsw.c | 61 
 ++
  drivers/net/ethernet/ti/cpsw.h |  1 +
  3 files changed, 64 insertions(+)

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index b717458..0895a51 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -34,6 +34,8 @@ Required properties:
  - phy_id : Specifies slave phy id
  - phy-mode   : The interface between the SoC and the PHY (a string
 that of_get_phy_mode() can understand)
 +- ti,rmii-clock-ext  : If present, the driver will configure the RMII
 +   interface to external clock usage
  - mac-address: Specifies slave MAC address
  
  Optional properties:
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 2e19de0..6e36f49 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -138,6 +138,13 @@ do { 
 \
  #define CPSW_CMINTMAX_INTVL  (1000 / CPSW_CMINTMIN_CNT)
  #define CPSW_CMINTMIN_INTVL  ((1000 / CPSW_CMINTMAX_CNT) + 1)
  
 +#define AM33XX_GMII_SEL_MODE_MII (0)
 +#define AM33XX_GMII_SEL_MODE_RMII(1)
 +#define AM33XX_GMII_SEL_MODE_RGMII   (2)
 +
 +#define AM33XX_GMII_SEL_RMII2_IO_CLK_EN  BIT(7)
 +#define AM33XX_GMII_SEL_RMII1_IO_CLK_EN  BIT(6)

These defined can go into cpsw.h so that we can maintain platform
defines in one file.

 +
  #define cpsw_enable_irq(priv)\
   do {\
   u32 i;  \
 @@ -980,6 +987,56 @@ static inline void cpsw_add_dual_emac_def_ale_entries(
   priv-host_port, ALE_VLAN, slave-port_vlan);
  }
  
 +static void cpsw_set_phy_interface_mode(struct cpsw_slave *slave,
 + struct cpsw_priv *priv)
 +{
 + u32 reg, mask, mode = 0;
 +

Please define each variable in separate line to make it clean.
Please check for IS_ERR(gmii_sel_reg) and return if gmii register is not
specified in DT then the below code will crash when trying to access
gmii_sel_reg.

 + switch (priv-data.hw_type) {
 + case CPSW_TYPE_AM33XX:
 + if (!priv-gmii_sel_reg)
 + break;
 +
 + reg = readl(priv-gmii_sel_reg);
 +
 + if (slave-phy) {
 + switch (slave-phy-interface) {
 + case PHY_INTERFACE_MODE_MII:
 + default:
 + mode = AM33XX_GMII_SEL_MODE_MII;
 + break;
 + case PHY_INTERFACE_MODE_RMII:
 + mode = AM33XX_GMII_SEL_MODE_RMII;
 + break;
 + case PHY_INTERFACE_MODE_RGMII:

You need to take care of other RGMII modes as well, for your info
AM335xevm phy mode is rgmii-txid

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mailbox: remove unnecessary platform_set_drvdata()

[Suman Anna]

+ OMAP mailing list

Tony,
Can you pick up this minor cleanup patch?

regards
Suman

On 08/21/2013 09:10 PM, Jingoo Han wrote:
 The driver core clears the driver data to NULL after device_release
 or on probe failure. Thus, it is not needed to manually clear the
 device driver data to NULL.
 
 Signed-off-by: Jingoo Han jg1@samsung.com

Acked-by: Suman Anna s-a...@ti.com

 ---
  drivers/mailbox/mailbox-omap2.c |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
 index eba380d..42d2b89 100644
 --- a/drivers/mailbox/mailbox-omap2.c
 +++ b/drivers/mailbox/mailbox-omap2.c
 @@ -325,7 +325,6 @@ static int omap2_mbox_remove(struct platform_device *pdev)
   kfree(privblk);
   kfree(mboxblk);
   kfree(list);
 - platform_set_drvdata(pdev, NULL);
  
   return 0;
  }
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Mugunthan V N]

On Friday 23 August 2013 07:53 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
 In order to support features that are specific to the AM335x IP, we have
 to add hardware types and another compatible string.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
  drivers/net/ethernet/ti/cpsw.c | 32 
 --
  drivers/net/ethernet/ti/cpsw.h |  1 +
  3 files changed, 28 insertions(+), 8 deletions(-)

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index 4e5ca54..b717458 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
  --
  
  Required properties:
 -- compatible: Should be ti,cpsw
 +- compatible: Should be ti,cpsw for generic cpsw support, 
 or
 +  ti,am3352-cpsw for AM3352 SoCs
  - reg   : physical base address and size of the cpsw
registers map.
An optional third memory region can be supplied if
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 7a25ff4..73c44cb6 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -155,6 +155,11 @@ do {
 \
  ((priv-data.dual_emac) ? priv-emac_port : \
  priv-data.active_slave)
  
 +enum {
 +CPSW_TYPE_GENERIC,
 +CPSW_TYPE_AM33XX
 +};
 +
  static int debug_level;
  module_param(debug_level, int, 0);
  MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
 @@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave 
 *slave, struct cpsw_priv *priv,
  slave-port_vlan = data-dual_emac_res_vlan;
  }
  
 +static const struct of_device_id cpsw_of_mtable[] = {
 +{
 +.compatible = ti,am3352-cpsw,
 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.


But the same IP can be used in different SoC as well where the control
register may be different as per the Silicon Integration team's decision?

Ideally there should be a separate control module driver so that it can
take care of different SoC related needs.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Mugunthan V N]

On Friday 23 August 2013 07:46 PM, Daniel Mack wrote:
 The cpsw currently lacks code to properly set up the hardware interface
 mode on AM33xx. Other platforms might be equally affected.

 Usually, the bootloader will configure the control module register, so
 probably that's why such support wasn't needed in the past. In suspend
 mode though, this register is modified, and so it needs reprogramming
 after resume.

 This patch adds code that makes use of the previously added and optional
 support for passing the control mode register, and configures the
 correct register bits when the slave is opened.

 The AM33xx also has a bit for each slave to configure the RMII reference
 clock direction. Setting it is now supported by a per-slave DT property.

 This code path introducted by this patch is currently exclusive for
 am33xx.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  2 +
  drivers/net/ethernet/ti/cpsw.c | 61 
 ++
  drivers/net/ethernet/ti/cpsw.h |  1 +
  3 files changed, 64 insertions(+)

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index b717458..0895a51 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -34,6 +34,8 @@ Required properties:
  - phy_id : Specifies slave phy id
  - phy-mode   : The interface between the SoC and the PHY (a string
 that of_get_phy_mode() can understand)
 +- ti,rmii-clock-ext  : If present, the driver will configure the RMII
 +   interface to external clock usage
  - mac-address: Specifies slave MAC address
  
  Optional properties:
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 73c44cb6..86b8f7a 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -138,6 +138,13 @@ do { 
 \
  #define CPSW_CMINTMAX_INTVL  (1000 / CPSW_CMINTMIN_CNT)
  #define CPSW_CMINTMIN_INTVL  ((1000 / CPSW_CMINTMAX_CNT) + 1)
  
 +#define AM33XX_GMII_SEL_MODE_MII (0)
 +#define AM33XX_GMII_SEL_MODE_RMII(1)
 +#define AM33XX_GMII_SEL_MODE_RGMII   (2)
 +
 +#define AM33XX_GMII_SEL_RMII2_IO_CLK_EN  BIT(7)
 +#define AM33XX_GMII_SEL_RMII1_IO_CLK_EN  BIT(6)

These defined can go into cpsw.h so that we can maintain platform
defines in one file.


 +
  #define cpsw_enable_irq(priv)\
   do {\
   u32 i;  \
 @@ -980,6 +987,56 @@ static inline void cpsw_add_dual_emac_def_ale_entries(
   priv-host_port, ALE_VLAN, slave-port_vlan);
  }
  
 +static void cpsw_set_phy_interface_mode(struct cpsw_slave *slave,
 + struct cpsw_priv *priv)
 +{
 + u32 reg, mask, mode = 0;

Please define each variable in separate line to make it clean.
Please check for IS_ERR(gmii_sel_reg) and return if gmii register is not
specified in DT then the below code will crash when trying to access
gmii_sel_reg.


 +
 + switch (priv-data.hw_type) {
 + case CPSW_TYPE_AM33XX:
 + if (!priv-gmii_sel_reg)
 + break;
 +
 + reg = readl(priv-gmii_sel_reg);
 +
 + if (slave-phy) {
 + switch (slave-phy-interface) {
 + case PHY_INTERFACE_MODE_MII:
 + default:
 + mode = AM33XX_GMII_SEL_MODE_MII;
 + break;
 + case PHY_INTERFACE_MODE_RMII:
 + mode = AM33XX_GMII_SEL_MODE_RMII;
 + break;
 + case PHY_INTERFACE_MODE_RGMII:

You need to take care of other RGMII modes as well, for your info
AM335xevm phy mode is rgmii-txid

Regards
Mugunthan V N

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] ARM: dts: Add SHAM and AES DT information

[Joel Fernandes]

On 08/22/2013 04:24 PM, Mark A. Greer wrote:
 On Thu, Aug 22, 2013 at 10:34:06AM +0200, Benoit Cousson wrote:
 Hi Lokesh,

 On 22/08/2013 05:50, Lokesh Vutla wrote:
 Hi Benoit,
 On Wednesday 21 August 2013 07:11 PM, Benoit Cousson wrote:
 Hi Mark,

 In fact I cannot even apply these patches since they are referring the the 
 edma controller node that does not seem to be there in 3.11-rc6.

 Is this EDMA series supposed to be merged for 3.12? If this is the case, 
 where can I find a reference GIT for it?
 The following EDMA support dt patch series from Joel is needed :
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92176.html
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92177.html

 Thanks, it works a little bit better with these patches :-)
 
 Yeah, sorry.
 
 Given Mark Rutland's comments in another email, let me respin and send v3.
 I'll put a comment about the dependencies this time.

Just sanity tested these patches on v3.11-rc6 too.

Drivers register successfully after passing the boot crypto testmgr tests.

bash-4.2# cat /proc/crypto | grep -i omap
driver   : ctr-aes-omap
driver   : cbc-aes-omap
driver   : ecb-aes-omap
driver   : omap-hmac-sha256
driver   : omap-hmac-sha224
driver   : omap-sha256
driver   : omap-sha224
driver   : omap-hmac-md5
driver   : omap-hmac-sha1
driver   : omap-md5
driver   : omap-sha1


Thanks,

-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
 On 23.08.2013 16:23, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
 
 +static const struct of_device_id cpsw_of_mtable[] = {
 +   {
 +   .compatible = ti,am3352-cpsw,

 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.
 
 As I already mentioned in the cover letter and in the commit message, I
 just don't know which criteria makes most sense here.
 
 On a general note, I would say that chances that this exactly IP core
 with the same version number will appear on some other silicon which
 doesn't support the control mode register in an AM33xx fashion, is not
 necessarily negligible.
 
 So what that new compatible string denotes is the cpsw in a version as
 found on am3352 SoCs, which is actually exactly what it does.
 
 I don't have a strong opinion here, but see your point. I just don't
 have a better idea on how to treat that.
 
So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
That way if in future if someone uses those features, they can use
this compatible if they don't they use the one which suites that
SOC.

Regards,
Santosh

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 0/8] omap mailbox dt

[Suman Anna]

Tony, Benoit,

 This is an updated series for adding the device tree support to
 the OMAP mailbox driver. The series is based on 3.11-rc4 and now
 includes the support for AM335 WkupM3 mailbox.
 
 The support for WkupM3 mailbox is essential for achieving the PM
 Suspend on AM335 devices, and this series is a dependency for
 the AM335 suspend/resume series [1]. The AM335 support patches
 required the mailbox DT patches posted previously, so I have
 refreshed all of them together.
 
 Tested this on Beagle-XM, Panda4 and OMAP5 uEVM (with
 out-of-tree clock patches).
 
 v3:
 - Includes 3 new patches on top of the unchanged patches in v2.
 - Patches 7 and 8 adds the driver support and DT node for AM335.
 - Patch6 is a minor cleanup patch removing omap_mbox_type_t from
   mbox ops.

Any additional feedback/comments on this series? The series contains
patches both for the driver code and DT/hwmod data. Let me know if you
need me to rearrange the patches. I currently have one review comment
to address regarding adding some additional notes [1] to the DT binding
information.

regards
Suman

[1] http://marc.info/?t=13758257546r=1w=2


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 12:45 PM, Mugunthan V N wrote:
 On Friday 23 August 2013 07:53 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
 In order to support features that are specific to the AM335x IP, we have
 to add hardware types and another compatible string.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
  drivers/net/ethernet/ti/cpsw.c | 32 
 --
  drivers/net/ethernet/ti/cpsw.h |  1 +
  3 files changed, 28 insertions(+), 8 deletions(-)

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index 4e5ca54..b717458 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
  --
  
  Required properties:
 -- compatible   : Should be ti,cpsw
 +- compatible   : Should be ti,cpsw for generic cpsw support, 
 or
 + ti,am3352-cpsw for AM3352 SoCs
  - reg  : physical base address and size of the cpsw
   registers map.
   An optional third memory region can be supplied if
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index 7a25ff4..73c44cb6 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 @@ -155,6 +155,11 @@ do {   
 \
 ((priv-data.dual_emac) ? priv-emac_port : \
 priv-data.active_slave)
  
 +enum {
 +   CPSW_TYPE_GENERIC,
 +   CPSW_TYPE_AM33XX
 +};
 +
  static int debug_level;
  module_param(debug_level, int, 0);
  MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
 @@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave 
 *slave, struct cpsw_priv *priv,
 slave-port_vlan = data-dual_emac_res_vlan;
  }
  
 +static const struct of_device_id cpsw_of_mtable[] = {
 +   {
 +   .compatible = ti,am3352-cpsw,
 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.


 But the same IP can be used in different SoC as well where the control
 register may be different as per the Silicon Integration team's decision?
 
 Ideally there should be a separate control module driver so that it can
 take care of different SoC related needs.
 
Instead of having one control module driver to address all the requirements
in various IP's, you could specifically address that in subsystem driver layer.
SOC guys invariably use control modules for certain functionality since it
is easy and quick fix. And their is uniformity in the way they are
implemented for different IP needs.

In this specific case, if the CPSW IP version has some part of the
functionality implemented using control module that is just harfaware
choice. Its not mandatory to partition that in two sub-system. Rather
consider it as a special IP version and treat it accordingly in the
driver.

Regards,
Santosh


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices

[Sekhar Nori]

On 8/13/2013 7:01 PM, Santosh Shilimkar wrote:
 On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
 On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
 On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
 I think this an A9-specific register, which reads as 0 on UP A9 and reads 
 as
 some form of PERIPH_BASE for SMP parts. The issue I have is when 
 PERIPH_BASE
 is zero.

 What do we do here ? Should we document this in the code and proceed ?
 Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but
 I am open for any other alternative.

 The only other alternative I can think of is forcing people to have
 CONFIG_SMP=n, but that blows away single zImage for your platform.

 Yep which surely we don't want considering after so much effort we
 have it working first place. How about going ahead with assumption
 that PERIPH_BASE = 0 case doesn't work.

I must be missing something but why cannot we use the SCU configuration
register CPU number field to determine that its a UP? I do not have an
OMAP4 board, but on AM437x, it certainly indicates only CPU0 present.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Sekhar Nori]

On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
 On 23.08.2013 16:23, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:

 +static const struct of_device_id cpsw_of_mtable[] = {
 +  {
 +  .compatible = ti,am3352-cpsw,

 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.

 As I already mentioned in the cover letter and in the commit message, I
 just don't know which criteria makes most sense here.

 On a general note, I would say that chances that this exactly IP core
 with the same version number will appear on some other silicon which
 doesn't support the control mode register in an AM33xx fashion, is not
 necessarily negligible.

 So what that new compatible string denotes is the cpsw in a version as
 found on am3352 SoCs, which is actually exactly what it does.

 I don't have a strong opinion here, but see your point. I just don't
 have a better idea on how to treat that.

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.

If this could be handled using IP version then the right way would be to
just read the IP version from hardware and use it. No need of DT property.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

On 23.08.2013 19:09, Sekhar Nori wrote:
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
 
 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT property.

Yes, exactly. The information we need to support the phy interface
setting is completely disconnected from the cpsw core itself.


Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices

[Santosh Shilimkar]

On Friday 23 August 2013 01:08 PM, Sekhar Nori wrote:
 On 8/13/2013 7:01 PM, Santosh Shilimkar wrote:
 On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
 On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
 On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
 I think this an A9-specific register, which reads as 0 on UP A9 and reads 
 as
 some form of PERIPH_BASE for SMP parts. The issue I have is when 
 PERIPH_BASE
 is zero.

 What do we do here ? Should we document this in the code and proceed ?
 Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but
 I am open for any other alternative.

 The only other alternative I can think of is forcing people to have
 CONFIG_SMP=n, but that blows away single zImage for your platform.

 Yep which surely we don't want considering after so much effort we
 have it working first place. How about going ahead with assumption
 that PERIPH_BASE = 0 case doesn't work.
 
 I must be missing something but why cannot we use the SCU configuration
 register CPU number field to determine that its a UP? I do not have an
 OMAP4 board, but on AM437x, it certainly indicates only CPU0 present.
 
Thats what patch does. Yes, you are missing the point of dicussion. 
On real UP Cortex-A9, the base address read will return '0' which is
treated as invalid address in the patch. Will D pointed out that one
can build a SOC where PERIPH_BASE can be 0 so thats not safe.
Thats the only contention left here.

Will, Russell,
Am just re-asking the question about whether we can ignore PERIPH_BASE = 0
and just document in the code about the limitation.

regards,
Santosh




--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Mugunthan V N]

On Friday 23 August 2013 10:26 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
 On 23.08.2013 16:23, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
 +static const struct of_device_id cpsw_of_mtable[] = {
 +  {
 +  .compatible = ti,am3352-cpsw,
 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.
 As I already mentioned in the cover letter and in the commit message, I
 just don't know which criteria makes most sense here.

 On a general note, I would say that chances that this exactly IP core
 with the same version number will appear on some other silicon which
 doesn't support the control mode register in an AM33xx fashion, is not
 necessarily negligible.

 So what that new compatible string denotes is the cpsw in a version as
 found on am3352 SoCs, which is actually exactly what it does.

 I don't have a strong opinion here, but see your point. I just don't
 have a better idea on how to treat that.

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
 That way if in future if someone uses those features, they can use
 this compatible if they don't they use the one which suites that
 SOC.

We cannot map control module register with CPSW IP version as both comes
from different design team and CPSW ip version can be same across SoC
and gmii sel register definition can be different. Control module
defines may vary in different SoC as per SoC requirements.

Adding Pekon Gupta who had worked in Silicon team before.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

On 23.08.2013 19:19, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.

 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT property.

 Thats fine as well but I thought the patch needed additional properties like
 CM reg-address come from DT and hence the separate compatible. If you can
 manage without that, thats even better.

We can't, that's the whole point :)

Well, theoretically, we could for now, but that's not a clean solution.
Again: the problem here is that the control port is separated from the
cpsw core, and so we have to implement something specific for the AM3352
SoC. I know that's a violation of clean and generic driver ideas, but
there's no way we can assume that every cpsw v2 ip block has a control
port that is compatible to the one found on am335x chips.


Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
 
 
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
 On 23.08.2013 16:23, Santosh Shilimkar wrote:
 On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:

 +static const struct of_device_id cpsw_of_mtable[] = {
 + {
 + .compatible = ti,am3352-cpsw,

 I didn't notice this earlier, but can't you use the IP version
 as a compatible instead of using a SOC name. Whats really SOC specific
 on this IP ? Sorry i have missed any earlier discussion on this but
 this approach doesn't seem good. Its like adding SOC checks in the
 driver subsystem.

 As I already mentioned in the cover letter and in the commit message, I
 just don't know which criteria makes most sense here.

 On a general note, I would say that chances that this exactly IP core
 with the same version number will appear on some other silicon which
 doesn't support the control mode register in an AM33xx fashion, is not
 necessarily negligible.

 So what that new compatible string denotes is the cpsw in a version as
 found on am3352 SoCs, which is actually exactly what it does.

 I don't have a strong opinion here, but see your point. I just don't
 have a better idea on how to treat that.

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
 
 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT property.
 
Thats fine as well but I thought the patch needed additional properties like
CM reg-address come from DT and hence the separate compatible. If you can
manage without that, thats even better.

Regards,
Santosh


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
 On 23.08.2013 19:19, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
 
 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.

 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT property.

 Thats fine as well but I thought the patch needed additional properties like
 CM reg-address come from DT and hence the separate compatible. If you can
 manage without that, thats even better.
 
 We can't, that's the whole point :)
 
I saw that from the patch :)

 Well, theoretically, we could for now, but that's not a clean solution.
 Again: the problem here is that the control port is separated from the
 cpsw core, and so we have to implement something specific for the AM3352
 SoC. I know that's a violation of clean and generic driver ideas, but
 there's no way we can assume that every cpsw v2 ip block has a control
 port that is compatible to the one found on am335x chips.
 
But there is a possibility that other SOC will just use the same
control module approach. So using a revision IP is just fine. BTW,
CPSW is not the only driver where control module is used. There are
many examples like USB, MMC etc

There is nothing wrong in using the version info and associating
the additional functionality with it.

Regards,
Santosh

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Sergei Shtylyov]

On 08/23/2013 08:21 PM, Daniel Mack wrote:


+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(priv-gmii_sel_reg)) {
+   dev_err(priv-dev, unable to map control i/o region\n);



 You didn't actually seem to heed my words about error message.



Well yes I did, but only in the check for platform_get_resource(). As
the comment says - we pass on if that memory region is not given, but if
it is given, it also has to be valid.


   Yes, but what I told you was devm_ioremap_resource() prints the error 
messages itself, so that you don't have to. And you even consented with that. :-)



And don't  you want to do:



res = PTR_ERR(priv-gmii_sel_reg);


Well, I've messed with the variable name: 'res' is struct resource *', 
what I meant was *int* variable.



Erm, of course. Sorry for that.



Daniel


WBR, Sergei

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Sekhar Nori]

On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
 On 23.08.2013 19:19, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.

 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT property.

 Thats fine as well but I thought the patch needed additional properties like
 CM reg-address come from DT and hence the separate compatible. If you can
 manage without that, thats even better.

 We can't, that's the whole point :)

 I saw that from the patch :)
 
 Well, theoretically, we could for now, but that's not a clean solution.
 Again: the problem here is that the control port is separated from the
 cpsw core, and so we have to implement something specific for the AM3352
 SoC. I know that's a violation of clean and generic driver ideas, but
 there's no way we can assume that every cpsw v2 ip block has a control
 port that is compatible to the one found on am335x chips.

 But there is a possibility that other SOC will just use the same
 control module approach. So using a revision IP is just fine. BTW,

But this is misleading because it makes appear like the same compatible
can be used on on another SoC like DRA7 which probably has the same
version of IP but a different control module implementation, when in
practice it cannot.

The fact is we are doing something SoC specific in the driver and we
cannot hide that behind IP versions. If really in practice there comes
another SoC with the same control module definition then it can always
use ti,am3352-cpsw compatible as well. The compatible name does not
preclude its usage.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices

[Sekhar Nori]

On 8/23/2013 10:47 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:08 PM, Sekhar Nori wrote:
 On 8/13/2013 7:01 PM, Santosh Shilimkar wrote:
 On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
 On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
 On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
 I think this an A9-specific register, which reads as 0 on UP A9 and 
 reads as
 some form of PERIPH_BASE for SMP parts. The issue I have is when 
 PERIPH_BASE
 is zero.

 What do we do here ? Should we document this in the code and proceed ?
 Mostly there is no platform with PERIPH_BASE = 0, so its should be fine 
 but
 I am open for any other alternative.

 The only other alternative I can think of is forcing people to have
 CONFIG_SMP=n, but that blows away single zImage for your platform.

 Yep which surely we don't want considering after so much effort we
 have it working first place. How about going ahead with assumption
 that PERIPH_BASE = 0 case doesn't work.

 I must be missing something but why cannot we use the SCU configuration
 register CPU number field to determine that its a UP? I do not have an
 OMAP4 board, but on AM437x, it certainly indicates only CPU0 present.

 Thats what patch does. Yes, you are missing the point of dicussion. 

Right, I see that now after actually reading the complete patch :)

 On real UP Cortex-A9, the base address read will return '0' which is
 treated as invalid address in the patch. Will D pointed out that one

Is this something defined by spec for all UP Cortex-A9 or just an
observation on AM437x implementation? It sounds like the later?

Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Santosh Shilimkar]

On Friday 23 August 2013 01:39 PM, Sekhar Nori wrote:
 On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
 On 23.08.2013 19:19, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:

 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.

 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT property.

 Thats fine as well but I thought the patch needed additional properties 
 like
 CM reg-address come from DT and hence the separate compatible. If you can
 manage without that, thats even better.

 We can't, that's the whole point :)

 I saw that from the patch :)

 Well, theoretically, we could for now, but that's not a clean solution.
 Again: the problem here is that the control port is separated from the
 cpsw core, and so we have to implement something specific for the AM3352
 SoC. I know that's a violation of clean and generic driver ideas, but
 there's no way we can assume that every cpsw v2 ip block has a control
 port that is compatible to the one found on am335x chips.

 But there is a possibility that other SOC will just use the same
 control module approach. So using a revision IP is just fine. BTW,
 
 But this is misleading because it makes appear like the same compatible
 can be used on on another SoC like DRA7 which probably has the same
 version of IP but a different control module implementation, when in
 practice it cannot.
 
 The fact is we are doing something SoC specific in the driver and we
 cannot hide that behind IP versions. If really in practice there comes
 another SoC with the same control module definition then it can always
 use ti,am3352-cpsw compatible as well. The compatible name does not
 preclude its usage.
 
My point was the CPSW needs a feature which is implemented using
control module rather than within the IP itself. Its an implementation
detail. As such the additional feature makes sense for that IP. O.w
there was no need to do any monkeying with control module.

E.g
MMC card detect is a basic functionality, implemented by various types
like control module, PMIC or MMC IP itself. As such the driver need
that support and all the implementation details needs to still handled
to make that part work.

Regards,
Santosh


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ARM: OMAP2+: HSI: Introduce OMAP SSI driver

[Sebastian Reichel]

Hi,

On Fri, Aug 23, 2013 at 03:57:05PM +0200, Linus Walleij wrote:
 The HSI subsystem is lacking an active maintainer, interested?
 Given that you can apparently test the OMAP HSI driver you're
 one of the few applicable candidates.

I don't think I'm a good candidate for that. At least not yet. This
is my first patch sent to the kernel and I merly took the code from
Carlos Chinea and ported it to some new kernel frameworks. Apart
from that I'm lacking any documentation for the interface (SSI is
not part of TI's public OMAP3 TRM).

 Overall there is one big problem with this patch in that it implements
 a lot of stuff that should not be implemented in the driver at all,
 but in the HSI core.

The actual implementation has not (yet?) been changed by me. It's
still the code as written by Carlos.

 For example compare commit
 ffbbdd21329f3e15eeca6df2d4bc11c04d9d91c0
 spi: create a message queueing infrastructure
 
 This patch basically seems to redo the mistake we did in
 SPI and not create a central message queue from day one,
 instead re-implementing the same code in each and every
 driver.
 
 Please attempt to draw the message queueuing into the
 driver core atlease.

I will have a look at it after conversion to DT. I will sent another
RFC before this change to speed up the DT review, though.

 Further the allocation of hosts seem pretty generic as well
 but I'm unsure about this. I'd prefer if you take a second
 look at the generalizeable parts.

OK.

 [...] (Code Comments)

Thanks for the review. The code has been written by Carlos, who
apparently had documentation for the SSI IP used in the OMAP3. I
cannot fix the magic numbers without either reverse engineering the
IP (which I do not have the time for) or access to the documentation.

I will fix the other comments in the next RFC patch.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 3/3] ARM: OMAP2+: Add SSI driver configuration

[Sebastian Reichel]

On Fri, Aug 23, 2013 at 03:58:30PM +0200, Linus Walleij wrote:
 On Mon, Aug 12, 2013 at 10:30 AM, Tony Lindgren t...@atomide.com wrote:
  * Sebastian Reichel s...@debian.org [130811 09:25]:
  From: Sebastian Reichel s...@ring0.de
 
  This patch configures and activates the OMAP SSI driver on the RX-51.
 
  Hmm, I'd rather see this be DT only driver at this point.
 
 +1 on this.

I'm already working on this.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 1/3] ARM: OMAP2+: hwmod-data: Add SSI information

[Sebastian Reichel]

Hi Paul,

On Wed, Aug 21, 2013 at 01:22:09AM +, Paul Walmsley wrote:
  From: Sebastian Reichel s...@ring0.de
  This patch adds Synchronous Serial Interface (SSI) hwmod support for
  OMAP34xx SoCs.
 
 a few comments:
 
 - please add your Signed-off-by: to the patch description, per 
 Documentation/SubmittingPatches

I assumed this was only important, when I actually want to submit
patches.  This was merely a first RFC. I will do this for the next
round of patches.

 - please drop omap34xx_ssi_irqs and omap34xx_ssi_addrs - that data 
 should go into DT now

I'm currently working on converting the driver to use DT.
I will send another patch when I'm done.

 [...]
 FYI, this is stretching my recollection, and is not directly related to 
 this patch, but I seem to recall that there was a problem with auto-idle 
 when SSI was active on the 3430.  Basically, if the SSI was active, but 
 other CORE_L3/CORE_L4 clockdomain devices weren't, I think that DPLL3 
 would be incorrectly shut down.  You'll probably need to check the Nokia 
 kernel source for details.  I thought we had a hwmod flag for this, but I 
 guess not.  Anyway, in case you notice odd behavior...

OK. Thanks for the hint.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Mugunthan V N]

On Friday 23 August 2013 11:40 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:39 PM, Sekhar Nori wrote:
 On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
 On 23.08.2013 19:19, Santosh Shilimkar wrote:
 On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
 On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
 So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
 If this could be handled using IP version then the right way would be to
 just read the IP version from hardware and use it. No need of DT 
 property.

 Thats fine as well but I thought the patch needed additional properties 
 like
 CM reg-address come from DT and hence the separate compatible. If you can
 manage without that, thats even better.
 We can't, that's the whole point :)

 I saw that from the patch :)

 Well, theoretically, we could for now, but that's not a clean solution.
 Again: the problem here is that the control port is separated from the
 cpsw core, and so we have to implement something specific for the AM3352
 SoC. I know that's a violation of clean and generic driver ideas, but
 there's no way we can assume that every cpsw v2 ip block has a control
 port that is compatible to the one found on am335x chips.

 But there is a possibility that other SOC will just use the same
 control module approach. So using a revision IP is just fine. BTW,
 But this is misleading because it makes appear like the same compatible
 can be used on on another SoC like DRA7 which probably has the same
 version of IP but a different control module implementation, when in
 practice it cannot.

 The fact is we are doing something SoC specific in the driver and we
 cannot hide that behind IP versions. If really in practice there comes
 another SoC with the same control module definition then it can always
 use ti,am3352-cpsw compatible as well. The compatible name does not
 preclude its usage.

 My point was the CPSW needs a feature which is implemented using
 control module rather than within the IP itself. Its an implementation
 detail. As such the additional feature makes sense for that IP. O.w
 there was no need to do any monkeying with control module.

 E.g
 MMC card detect is a basic functionality, implemented by various types
 like control module, PMIC or MMC IP itself. As such the driver need
 that support and all the implementation details needs to still handled
 to make that part work.



CPSW core as such understands only GMII/MII signals, there is an
additional module which converts GMII/MII signals to RGMII/RMII signals
respectively which is called as CPRGMII/CPRMII as specified in the
AM335x TRM in Figure 14-1. Ethernet Switch Integration.

So to control this sub-module, the control register is used and this has
to be configured according to the EVM design like what mode of phy is
connected. CPRGMII and CPRMII is no way related to CPSW core.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ARM: OMAP: Device Tree for 3.12

[Kevin Hilman]

Benoit Cousson bcous...@baylibre.com writes:

 Hi Kevin  Olof,

 I've just updated the branch with the few USB3 patches I missed from Felipe.

 So here is a new pull-request.

 Thanks,
 Benoit

 
 Add the minimal DTS support for DRA7xx based SoC core.
 Add the initial support for N900 and gta04 phones.
 Enable USB3 on OMAP5 evm board.
 Do a lot of various cleanups.
 

This is a nice description, but would be even better if it was the
description of the signed tag.  For future pulls, since we're pulling
from you directly into arm-soc, can you start using signed tags please?


 The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:

   Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
 for_3.12/dts

 for you to fetch changes up to 5903208d4e2c09a3872feba6b9e2e49c64fd07ad:

   ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies (2013-08-21 
 16:43:21 +0200)


Pulled into next/dt.

Benoit, since we're pulling directly from you into arm-soc, can you
start using signed tags please?  Thanks.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] net: ethernet: cpsw: switch to devres allocations

[Daniel Mack]

On 23.08.2013 20:10, Sergei Shtylyov wrote:
 On 08/23/2013 06:16 PM, Daniel Mack wrote:

  priv-coal_intvl = 0;
  priv-bus_freq_mhz = clk_get_rate(priv-clk) / 100;

 -priv-cpsw_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 -if (!priv-cpsw_res) {
 +ss_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +if (!ss_res) {
 
 You don't need to check the result of platform_get_resource() if you call
 devm_ioremap_resource() right afterwards -- it will check resource ptr for 
 NULL the first thing. :-)

Thanks! Will address that in v5.


Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] net: ethernet: cpsw: switch to devres allocations

[Sergei Shtylyov]

On 08/23/2013 06:16 PM, Daniel Mack wrote:


This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.



Signed-off-by: Daniel Mack zon...@gmail.com
---
  drivers/net/ethernet/ti/cpsw.c | 147 +
  1 file changed, 45 insertions(+), 102 deletions(-)



diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..849af52 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c

[...]

@@ -1977,55 +1963,41 @@ static int cpsw_probe(struct platform_device *pdev)
priv-slaves[0].ndev = ndev;
priv-emac_port = 0;

-   priv-clk = clk_get(pdev-dev, fck);
+   priv-clk = devm_clk_get(pdev-dev, fck);
if (IS_ERR(priv-clk)) {
-   dev_err(pdev-dev, fck is not found\n);
+   dev_err(priv-dev, fck is not found\n);
ret = -ENODEV;
-   goto clean_slave_ret;
+   goto clean_runtime_disable_ret;
}
priv-coal_intvl = 0;
priv-bus_freq_mhz = clk_get_rate(priv-clk) / 100;

-   priv-cpsw_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!priv-cpsw_res) {
+   ss_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!ss_res) {


   You don't need to check the result of platform_get_resource() if you call
devm_ioremap_resource() right afterwards -- it will check resource ptr for 
NULL the first thing. :-)



dev_err(priv-dev, error getting i/o resource\n);
ret = -ENOENT;
-   goto clean_clk_ret;
+   goto clean_runtime_disable_ret;
}
-   if (!request_mem_region(priv-cpsw_res-start,
-   resource_size(priv-cpsw_res), ndev-name)) {
-   dev_err(priv-dev, failed request i/o region\n);
-   ret = -ENXIO;
-   goto clean_clk_ret;
-   }
-   ss_regs = ioremap(priv-cpsw_res-start, resource_size(priv-cpsw_res));
-   if (!ss_regs) {
+   ss_regs = devm_ioremap_resource(pdev-dev, ss_res);
+   if (IS_ERR(ss_regs)) {
dev_err(priv-dev, unable to map i/o region\n);


   Don't need the error message anymore -- devm_ioremap_resource() will print 
it. And you missed:


ret = PTR_ERR(ss_regs);


-   goto clean_cpsw_iores_ret;
+   goto clean_runtime_disable_ret;
}
priv-regs = ss_regs;
priv-version = __raw_readl(priv-regs-id_ver);
priv-host_port = HOST_PORT_NUM;

-   priv-cpsw_wr_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (!priv-cpsw_wr_res) {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res) {


   Same comment about resource check here...


dev_err(priv-dev, error getting i/o resource\n);
ret = -ENOENT;
-   goto clean_iomap_ret;
-   }
-   if (!request_mem_region(priv-cpsw_wr_res-start,
-   resource_size(priv-cpsw_wr_res), ndev-name)) {
-   dev_err(priv-dev, failed request i/o region\n);
-   ret = -ENXIO;
-   goto clean_iomap_ret;
+   goto clean_runtime_disable_ret;
}
-   wr_regs = ioremap(priv-cpsw_wr_res-start,
-   resource_size(priv-cpsw_wr_res));
-   if (!wr_regs) {
+   priv-wr_regs = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(priv-wr_regs)) {
dev_err(priv-dev, unable to map i/o region\n);


   And same comments about the unneeded error message and missing 'ret' 
assignment here...



-   goto clean_cpsw_wr_iores_ret;
+   goto clean_runtime_disable_ret;
}
-   priv-wr_regs = wr_regs;

memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));

[...]

WBR, Sergei

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/5] net: ethernet: cpsw: switch to devres allocations

[Daniel Mack]

This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/net/ethernet/ti/cpsw.c | 153 -
 1 file changed, 43 insertions(+), 110 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..fc3263f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t  lock;
struct platform_device  *pdev;
struct net_device   *ndev;
-   struct resource *cpsw_res;
-   struct resource *cpsw_wr_res;
struct napi_struct  napi;
struct device   *dev;
struct cpsw_platform_data   data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
*data,
 
if (of_property_read_u32(node, active_slave, prop)) {
pr_err(Missing active_slave property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-active_slave = prop;
 
if (of_property_read_u32(node, cpts_clock_mult, prop)) {
pr_err(Missing cpts_clock_mult property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_mult = prop;
 
if (of_property_read_u32(node, cpts_clock_shift, prop)) {
pr_err(Missing cpts_clock_shift property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_shift = prop;
 
-   data-slave_data = kcalloc(data-slaves, sizeof(struct cpsw_slave_data),
-  GFP_KERNEL);
+   data-slave_data = devm_kzalloc(pdev-dev, data-slaves
+   * sizeof(struct cpsw_slave_data),
+   GFP_KERNEL);
if (!data-slave_data)
-   return -EINVAL;
+   return -ENOMEM;
 
if (of_property_read_u32(node, cpdma_channels, prop)) {
pr_err(Missing cpdma_channels property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-channels = prop;
 
if (of_property_read_u32(node, ale_entries, prop)) {
pr_err(Missing ale_entries property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-ale_entries = prop;
 
if (of_property_read_u32(node, bd_ram_size, prop)) {
pr_err(Missing bd_ram_size property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-bd_ram_size = prop;
 
if (of_property_read_u32(node, rx_descs, prop)) {
pr_err(Missing rx_descs property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-rx_descs = prop;
 
if (of_property_read_u32(node, mac_control, prop)) {
pr_err(Missing mac_control property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-mac_control = prop;
 
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, phy_id, lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err(Missing slave[%d] phy_id property\n, i);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
 
return 0;
-
-error_ret:
-   kfree(data-slave_data);
-   return ret;
 }
 
 static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
priv_sl2-coal_intvl = 0;
priv_sl2-bus_freq_mhz = priv-bus_freq_mhz;
 
-   priv_sl2-cpsw_res = priv-cpsw_res;
priv_sl2-regs = priv-regs;
priv_sl2-host_port = priv-host_port;
priv_sl2-host_port_regs = priv-host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv*priv;
struct cpdma_params dma_params;
struct cpsw_ale_params  ale_params;
- 

Re: [PATCH 1/3] ARM: OMAP2+: hwmod-data: Add SSI information

[Paul Walmsley]

Hi

On Fri, 23 Aug 2013, Sebastian Reichel wrote:

 On Wed, Aug 21, 2013 at 01:22:09AM +, Paul Walmsley wrote:
   From: Sebastian Reichel s...@ring0.de
   This patch adds Synchronous Serial Interface (SSI) hwmod support for
   OMAP34xx SoCs.
  
  a few comments:
  
  - please add your Signed-off-by: to the patch description, per 
  Documentation/SubmittingPatches
 
 I assumed this was only important, when I actually want to submit
 patches.  This was merely a first RFC. I will do this for the next
 round of patches.

OK makes sense.  Just FYI, usually when folks send out RFCs, they put 
RFC in the patch description for each patch.  So the subject line might 
read:

[RFC PATCH 1/3] ARM: OMAP2+: hwmod-data: Add SSI information

  - please drop omap34xx_ssi_irqs and omap34xx_ssi_addrs - that data 
  should go into DT now
 
 I'm currently working on converting the driver to use DT.
 I will send another patch when I'm done.

OK great.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Daniel Mack]

The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.

Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.

This patch adds code that makes use of the previously added and optional
support for passing the control mode register, and configures the
correct register bits when the slave is opened.

The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.

This code path introducted by this patch is currently exclusive for
am33xx.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  2 +
 drivers/net/ethernet/ti/cpsw.c | 58 ++
 drivers/net/ethernet/ti/cpsw.h |  8 
 3 files changed, 68 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index b717458..0895a51 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -34,6 +34,8 @@ Required properties:
 - phy_id   : Specifies slave phy id
 - phy-mode : The interface between the SoC and the PHY (a string
  that of_get_phy_mode() can understand)
+- ti,rmii-clock-ext: If present, the driver will configure the RMII
+ interface to external clock usage
 - mac-address  : Specifies slave MAC address
 
 Optional properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 87c2bab..64e2269 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -980,6 +980,60 @@ static inline void cpsw_add_dual_emac_def_ale_entries(
priv-host_port, ALE_VLAN, slave-port_vlan);
 }
 
+static void cpsw_set_phy_interface_mode(struct cpsw_slave *slave,
+   struct cpsw_priv *priv)
+{
+   u32 reg;
+   u32 mask;
+   u32 mode = 0;
+
+   switch (priv-data.hw_type) {
+   case CPSW_TYPE_AM33XX:
+   if (IS_ERR(priv-gmii_sel_reg))
+   break;
+
+   reg = readl(priv-gmii_sel_reg);
+
+   if (slave-phy) {
+   switch (slave-phy-interface) {
+   case PHY_INTERFACE_MODE_MII:
+   default:
+   mode = AM33XX_GMII_SEL_MODE_MII;
+   break;
+   case PHY_INTERFACE_MODE_RMII:
+   mode = AM33XX_GMII_SEL_MODE_RMII;
+   break;
+   case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_ID:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   case PHY_INTERFACE_MODE_RGMII_TXID:
+   mode = AM33XX_GMII_SEL_MODE_RGMII;
+   break;
+   };
+   }
+
+   mask = 0x3  (slave-slave_num * 2) |
+  BIT(slave-slave_num + 6);
+   mode = slave-slave_num * 2;
+
+   if (slave-data-rmii_clock_external) {
+   if (slave-slave_num == 0)
+   mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
+   else
+   mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
+   }
+
+   reg = ~mask;
+   reg |= mode;
+
+   writel(reg, priv-gmii_sel_reg);
+   break;
+
+   default:
+   break;
+   }
+}
+
 static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
 {
char name[32];
@@ -1028,6 +1082,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, 
struct cpsw_priv *priv)
 slave-phy-phy_id);
phy_start(slave-phy);
}
+
+   cpsw_set_phy_interface_mode(slave, priv);
 }
 
 static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
@@ -1823,6 +1879,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
 
slave_data-phy_if = of_get_phy_mode(slave_node);
+   if (of_find_property(slave_node, ti,rmii-clock-ext, NULL))
+   slave_data-rmii_clock_external = true;
 
if (data-dual_emac) {
if (of_property_read_u32(slave_node, 
dual_emac_res_vlan,
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index 96c374a..0ee0fbe 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -19,6 

[PATCH v5 5/5] ARM: dts: am33xx: adopt to cpsw changes

[Daniel Mack]

This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.

Also update the compatible string to make use of the am335x specific
features of the cpsw driver.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/boot/dts/am33xx.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a785b95..c7b41ae 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -446,7 +446,7 @@
};
 
mac: ethernet@4a10 {
-   compatible = ti,cpsw;
+   compatible = ti,am3352-cpsw, ti,cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
ale_entries = 1024;
@@ -459,7 +459,8 @@
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
reg = 0x4a10 0x800
-  0x4a101200 0x100;
+  0x4a101200 0x100
+  0x44e10650 0x4;
#address-cells = 1;
#size-cells = 1;
interrupt-parent = intc;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/5] cpsw: support for control module register

[Daniel Mack]

Hi,

this is the 5th version of my patch set, the version history is below.

Note that for personal reasons, I won't be able to work on that patch
set for two weeks, starting from a few hours from now. If there are any
more objections or comments, I'll catch up after that period. Or if
anyone wants to make minor changes to my patches and resubmit them,
I'd also be fine with that :)

The compatible discussion is still ongoing, but I'd rather submit what
I got until now, and I'm also still convinced that having
ti,am3352-cpsw is still the best we can do.


Thanks,
Daniel

v4 - v5:
* fix return value assignment in devm_ioremap_resource() error
  paths (reported by Sergei Shtylyov)
* add more RGMII modes (reported by Mugunthan V N)
* check for IS_ERR(priv-gmii_sel_reg) in
  cpsw_set_phy_interface_mode() (reported by Mugunthan V N)
* move SoC specific definitions to cpsw.h
* further simplify the probe logic, as devm_ioremap_resource()
  will check for NULL resources (Sergei Shtylyov)

v3 - v4:
* use IS_ERR() to check for failed devm_ioremap_resource()
  calls (reported by Sergei Shtylyov)

v2 - v3:
* swap ti,am3352-cpsw and ti,cpsw to work around a matching
  bug (reported by Sekhar)

v1 - v2:
* combine devm_request_mem_region() and devm_ioremap() and use
  devm_ioremap_resource() (reported by Sergei Shtylyov)
* fix multi-line comment style (reported by Sergei Shtylyov)
* fix ti,rmii-clock-ext property name (reported by Sekhar)
* rebased to net-next (reported by Mugunthan V N, David Miller)
* add a new compatible type, and handle AM33xx specific
  registers that way (reported by Sekhar)
* move gmii_sel_reg modifications to the open routine
  (reported by Mugunthan V N)

Daniel Mack (5):
  net: ethernet: cpsw: switch to devres allocations
  net: ethernet: cpsw: add optional third memory region for CONTROL
module
  net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
  net: ethernet: cpsw: add support for hardware interface mode config
  ARM: dts: am33xx: adopt to cpsw changes

 Documentation/devicetree/bindings/net/cpsw.txt |  10 +-
 arch/arm/boot/dts/am33xx.dtsi  |   5 +-
 drivers/net/ethernet/ti/cpsw.c | 248 +
 drivers/net/ethernet/ti/cpsw.h |   9 +
 4 files changed, 151 insertions(+), 121 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string

[Daniel Mack]

In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt |  3 ++-
 drivers/net/ethernet/ti/cpsw.c | 32 --
 drivers/net/ethernet/ti/cpsw.h |  1 +
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 4e5ca54..b717458 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 --
 
 Required properties:
-- compatible   : Should be ti,cpsw
+- compatible   : Should be ti,cpsw for generic cpsw support, or
+ ti,am3352-cpsw for AM3352 SoCs
 - reg  : physical base address and size of the cpsw
  registers map.
  An optional third memory region can be supplied if
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4feba2f..87c2bab 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -155,6 +155,11 @@ do {   
\
((priv-data.dual_emac) ? priv-emac_port : \
priv-data.active_slave)
 
+enum {
+   CPSW_TYPE_GENERIC,
+   CPSW_TYPE_AM33XX
+};
+
 static int debug_level;
 module_param(debug_level, int, 0);
 MODULE_PARM_DESC(debug_level, cpsw debug level (NETIF_MSG bits));
@@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave *slave, 
struct cpsw_priv *priv,
slave-port_vlan = data-dual_emac_res_vlan;
 }
 
+static const struct of_device_id cpsw_of_mtable[] = {
+   {
+   .compatible = ti,am3352-cpsw,
+   .data   = (void *) CPSW_TYPE_AM33XX
+   }, {
+   .compatible = ti,cpsw,
+   .data   = (void *) CPSW_TYPE_GENERIC
+   },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
+
 static int cpsw_probe_dt(struct cpsw_platform_data *data,
 struct platform_device *pdev)
 {
struct device_node *node = pdev-dev.of_node;
+   const struct of_device_id *match;
struct device_node *slave_node;
+   unsigned long match_data;
int i = 0, ret;
u32 prop;
 
-   if (!node)
+   match = of_match_device(cpsw_of_mtable, pdev-dev);
+
+   if (!node || !match)
return -EINVAL;
 
+   match_data = (unsigned long) match-data;
+   data-hw_type = match_data;
+
if (of_property_read_u32(node, slaves, prop)) {
pr_err(Missing slaves property in the DT.\n);
return -EINVAL;
@@ -2207,12 +2231,6 @@ static const struct dev_pm_ops cpsw_pm_ops = {
.resume = cpsw_resume,
 };
 
-static const struct of_device_id cpsw_of_mtable[] = {
-   { .compatible = ti,cpsw, },
-   { /* sentinel */ },
-};
-MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
-
 static struct platform_driver cpsw_driver = {
.driver = {
.name= cpsw,
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index eb3e101..96c374a 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -37,6 +37,7 @@ struct cpsw_platform_data {
u32 mac_control;/* Mac control register */
u16 default_vlan;   /* Def VLAN for ALE lookup in VLAN aware mode*/
booldual_emac;  /* Enable Dual EMAC mode */
+   u32 hw_type;/* hardware type as specified in 'compatible' */
 };
 
 #endif /* __CPSW_H__ */
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.

I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/net/cpsw.txt | 5 -
 drivers/net/ethernet/ti/cpsw.c | 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 05d660e..4e5ca54 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -4,7 +4,10 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 Required properties:
 - compatible   : Should be ti,cpsw
 - reg  : physical base address and size of the cpsw
- registers map
+ registers map.
+ An optional third memory region can be supplied if
+ the platform has a control module register to
+ configure phy interface details
 - interrupts   : property with a value describing the interrupt
  number
 - interrupt-parent : The parent interrupt controller
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index fc3263f..4feba2f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -372,6 +372,7 @@ struct cpsw_priv {
struct cpsw_platform_data   data;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
+   u32 __iomem *gmii_sel_reg;
u8 __iomem  *hw_stats;
struct cpsw_host_regs __iomem   *host_port_regs;
u32 msg_enable;
@@ -1989,6 +1990,10 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}
 
+   /* Don't fail hard if the optional control memory region is missing */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+
memset(dma_params, 0, sizeof(dma_params));
memset(ale_params, 0, sizeof(ale_params));
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] misc: Add crossbar driver

[Linus Walleij]

On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori nsek...@ti.com wrote:
 On 8/23/2013 7:08 PM, Santosh Shilimkar wrote:

 The whole point we are moving to domain is not have any default
 mapping(connection done) at DT level. Rather DT only specifies the
 peripherals and their cross-bar connection ID(i.e cross-bar IRQ line).
 This will be the driver input as a IRQ line from DT. The cross-bar
 driver needs to map any of the free list available on *request* only.

 Right, the mapping can be done on request. That will be cleaner.

I like where this design is going now :-)

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: add AM33XX EDMA support

[Sebastian Andrzej Siewior]

From: Matt Porter m...@ti.com

Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt

Joel: Drop DT entries that are non-hardware-description for now as discussed in 
[1]

[1] https://patchwork.kernel.org/patch/2226761/

Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
Could someone please pick this up?

 arch/arm/boot/dts/am33xx.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = 0x4820 0x1000;
};
 
+   edma: edma@4900 {
+   compatible = ti,edma3;
+   ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+   reg =   0x4900 0x1,
+   0x44e10f90 0x10;
+   interrupts = 12 13 14;
+   #dma-cells = 1;
+   dma-channels = 64;
+   ti,edma-regions = 4;
+   ti,edma-slots = 256;
+   };
+
gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] ARM: OMAP: DRA7xx PRCM/hwmod support

[Paul Walmsley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony

The following changes since commit cf470a1b1a741bca00080ebc70968b4f22d9b1ea:

  Merge tag 'dra7-core-support-minus-dt' of git://github.com/rrnayak/linux into 
omap-for-v3.12/soc (2013-08-14 01:01:41 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/for-v3.12/dra7xx

for you to fetch changes up to 7de516a63c634a0db1920757f501f98f68f92716:

  ARM: OMAP: DRA7: Enable PM framework initializations (2013-08-23 04:29:37 
-0600)

- 
This series adds basic TI DRA7xx PRCM and hwmod support.

Basic test logs are available here:

http://www.pwsan.com/omap/testlogs/dra7xx_prcm_devel_v3.12/20130823050445/

Note that DRA7xx could not be tested locally, since I don't have a board.

- 
vmlinux object size
(delta in bytes from tony_soc_for_v3.12 
(cf470a1b1a741bca00080ebc70968b4f22d9b1ea)):
   text data  bsstotal  kernel
  0000  n800_multi_omap2xxx
  0000  n800_only_a
  0000  omap1_defconfig
  0000  omap1_defconfig_1510innovator_only
  0000  omap1_defconfig_5912osk_only
+7200  +72  omap2plus_defconfig
  0000  omap2plus_defconfig_2430sdp_only
+7200  +72  omap2plus_defconfig_cpupm
 +800   +8  omap2plus_defconfig_no_pm
 +800   +8  omap2plus_defconfig_omap2_4_only
 +800   +8  omap2plus_defconfig_omap3_4_only
  0000  rmk_omap3430_ldp_allnoconfig
  0000  rmk_omap3430_ldp_oldconfig
+560  -16  +40  rmk_omap4430_sdp_allnoconfig

Boot-time memory difference
(delta in bytes from tony_soc_for_v3.12 
(cf470a1b1a741bca00080ebc70968b4f22d9b1ea))
  avail  rsrvd   high  freed  board  kconfig
  (no differences)

Ambresh K (7):
  ARM: OMAP: DRA7: PRM: Add DRA7XX register definitions
  ARM: OMAP: DRA7: CM: Add DRA7XX register defines
  ARM: OMAP: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
  ARM: OMAP: DRA7: clockdomain: Add DRA7XX data and update header
  ARM: OMAP: DRA7: powerdomain: Add DRA7XX data and update header
  ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data
  ARM: OMAP: DRA7: Enable PM framework initializations

Rajendra Nayak (3):
  ARM: OMAP: DRA7: CM: Add minimal regbit shifts
  ARM: OMAP: DRA7: powerdomain: Handle missing vc/vp
  ARM: OMAP: DRA7: Reuse the omap44xx_restart and fix the device instance

 arch/arm/mach-omap2/Makefile   |4 +
 arch/arm/mach-omap2/board-generic.c|1 +
 arch/arm/mach-omap2/clockdomain.h  |1 +
 arch/arm/mach-omap2/clockdomains7xx_data.c |  740 
 arch/arm/mach-omap2/cm-regbits-7xx.h   |   51 +
 arch/arm/mach-omap2/cm1_7xx.h  |  324 
 arch/arm/mach-omap2/cm2_7xx.h  |  513 ++
 arch/arm/mach-omap2/io.c   |5 +
 arch/arm/mach-omap2/omap_hwmod.h   |1 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 2724 
 arch/arm/mach-omap2/powerdomain.h  |1 +
 arch/arm/mach-omap2/powerdomains7xx_data.c |  454 +
 arch/arm/mach-omap2/prcm44xx.h |5 +
 arch/arm/mach-omap2/prcm_mpu7xx.h  |   78 +
 arch/arm/mach-omap2/prm44xx.c  |   12 +-
 arch/arm/mach-omap2/prm7xx.h   |  678 +++
 arch/arm/mach-omap2/prminst44xx.c  |   20 +-
 17 files changed, 5607 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c
 create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h
 create mode 100644 arch/arm/mach-omap2/cm1_7xx.h
 create mode 100644 arch/arm/mach-omap2/cm2_7xx.h
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c
 create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h
 create mode 100644 arch/arm/mach-omap2/prm7xx.h
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSF7MqAAoJEMePsQ0LvSpLVWcP/RLLMneCi2myW40UctJwHDIw
+c58TJnYt6aFmp5ht+MhKGS3BIrRRD6uWZx4/HfxytjxKyV/t7hbkrsHzUMfN32z
FL6d9IDN+IvIMUhbQyaW/se1j8dqAJlAM/ef5xavN2wgDb/4XiYkFT3BNybqe374
fpr7qQ4727kVrPp3h0olLDDUDUPY7LCseSGlFql+g8txHsOok+VnmXxPP1E/IMEa
OxCO8CTDibDQCvq+uw1OACUvHOG9yzbNfjcbXWttNNNgWuti2OL0xnAGEs+yqG+9
cI8pHurRHKYPDrv1nnq4uEOsse+iCbsQNaj1ws32u/3ye0wDCRSDOq2Whe69xBvs
7EdoT5nVjisF916Ij/xzX/zwOSAgIO3iu5DitHUOaCtrhOoJA8Rcpcl+S0xr8S4w
z8oi+7aC+OLByn1hXITV+FNhBs+uNMMOmIfiC4G7uHSK3fYu8vv2X6vdfrm5NYFI
vzjBPaoqDNg4S+4h3AGwe6ZuTI4KMRm1juYWlQJFjim+T23Fjlas9Xm5bQ7f1wwE
mZLQLKsosiwit+23bDtAOEVmtKv7SmDMJSjKRlqJJsEkdIhyI3xmzjXGJdpmCNV7

Re: [PATCH v5 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Sergei Shtylyov]

Hello.

On 08/23/2013 10:53 PM, Daniel Mack wrote:


At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.



I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.



Signed-off-by: Daniel Mack zon...@gmail.com
---
  Documentation/devicetree/bindings/net/cpsw.txt | 5 -
  drivers/net/ethernet/ti/cpsw.c | 5 +
  2 files changed, 9 insertions(+), 1 deletion(-)



diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index fc3263f..4feba2f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c

[...]

@@ -1989,6 +1990,10 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}

+   /* Don't fail hard if the optional control memory region is missing */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);


   Hm, but why now you don't fail if devm_ioremap_resource() fails?

WBR, Sergei

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module

[Daniel Mack]

On 23.08.2013 21:10, Sergei Shtylyov wrote:
 Hello.
 
 On 08/23/2013 10:53 PM, Daniel Mack wrote:
 
 At least the AM33xx SoC has a control module register to configure
 details such as the hardware ethernet interface mode.
 
 I'm not sure whether all SoCs which feature the cpsw block have such a
 register, so that third memory region is considered optional for now.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
   Documentation/devicetree/bindings/net/cpsw.txt | 5 -
   drivers/net/ethernet/ti/cpsw.c | 5 +
   2 files changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
 index fc3263f..4feba2f 100644
 --- a/drivers/net/ethernet/ti/cpsw.c
 +++ b/drivers/net/ethernet/ti/cpsw.c
 [...]
 @@ -1989,6 +1990,10 @@ static int cpsw_probe(struct platform_device *pdev)
  goto clean_runtime_disable_ret;
  }

 +/* Don't fail hard if the optional control memory region is missing */
 +res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
 +priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
 
 Hm, but why now you don't fail if devm_ioremap_resource() fails?

Well, because I thought maybe we should just ignore failures of that
kind altogether for this optional resource. There will still be a
warning in that case. Did you like the old approach better?


Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/5] cpsw: support for control module register

[Mugunthan V N]

On Saturday 24 August 2013 12:23 AM, Daniel Mack wrote:
 Note that for personal reasons, I won't be able to work on that patch
 set for two weeks, starting from a few hours from now. If there are any
 more objections or comments, I'll catch up after that period. Or if
 anyone wants to make minor changes to my patches and resubmit them,
 I'd also be fine with that :)

 The compatible discussion is still ongoing, but I'd rather submit what
 I got until now, and I'm also still convinced that having
 ti,am3352-cpsw is still the best we can do.
Apart from the DT compatibility discussion this patch series looks good
to me.

Acked-by: Mugunthan V N mugunthan...@ti.com

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*

[Stephen Warren]

On 08/23/2013 05:28 AM, Kishon Vijay Abraham I wrote:
 Hi,
 
 On Friday 23 August 2013 02:20 AM, Stephen Warren wrote:
 On 08/22/2013 02:31 AM, Kishon Vijay Abraham I wrote:
 The Palmas device contains only a USB VBUS-ID detector, so added a
 compatible type *ti,palmas-usb-vid*. Didn't remove the existing compatible
 types for backward compatibility.

 diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt 
 b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt

  PALMAS USB COMPARATOR
  Required Properties:
 - - compatible : Should be ti,palmas-usb or ti,twl6035-usb
 + - compatible : Should be ti,palmas-usb-vid. ti,twl6035-usb and
 +   ti,palmas-usb is deprecated and is kept for backward compatibility.

 So this defines one new value and deprecates the two old values.
 
 yeah.

 Why isn't a new ti,twl6035-usb-vid entry useful? Don't you still need
 
 yeah, it should be added too.
 SoC-specific compatible values so the driver can enable any SoC-specific
 bug-fixes/workarounds later if needed?
 
 hmm.. Palmas is external to SoC. So not sure if adding SoC specific compatible
 values is such a good idea.

In this case, but SoC, I meant the Palmas chip rather than the
application processor. Is twl6035 a name for Palmas or something else?

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/5] net: ethernet: cpsw: add support for hardware interface mode config

[Sergei Shtylyov]

On 08/23/2013 10:53 PM, Daniel Mack wrote:


The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.



Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.



This patch adds code that makes use of the previously added and optional
support for passing the control mode register, and configures the
correct register bits when the slave is opened.



The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.



This code path introducted by this patch is currently exclusive for
am33xx.



Signed-off-by: Daniel Mack zon...@gmail.com

[...]


@@ -40,4 +41,11 @@ struct cpsw_platform_data {
u32 hw_type;/* hardware type as specified in 'compatible' */
  };

+/* SoC specific definitions for the CONTROL port */
+#define AM33XX_GMII_SEL_MODE_MII   (0)
+#define AM33XX_GMII_SEL_MODE_RMII  (1)
+#define AM33XX_GMII_SEL_MODE_RGMII (2)


   Parens around decimal literals are hardly needed even in macros.

WBR, Sergei

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/5] net: ethernet: cpsw: switch to devres allocations

[Daniel Mack]

This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.

Signed-off-by: Daniel Mack zon...@gmail.com
Acked-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/cpsw.c | 153 -
 1 file changed, 43 insertions(+), 110 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..fc3263f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t  lock;
struct platform_device  *pdev;
struct net_device   *ndev;
-   struct resource *cpsw_res;
-   struct resource *cpsw_wr_res;
struct napi_struct  napi;
struct device   *dev;
struct cpsw_platform_data   data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
*data,
 
if (of_property_read_u32(node, active_slave, prop)) {
pr_err(Missing active_slave property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-active_slave = prop;
 
if (of_property_read_u32(node, cpts_clock_mult, prop)) {
pr_err(Missing cpts_clock_mult property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_mult = prop;
 
if (of_property_read_u32(node, cpts_clock_shift, prop)) {
pr_err(Missing cpts_clock_shift property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-cpts_clock_shift = prop;
 
-   data-slave_data = kcalloc(data-slaves, sizeof(struct cpsw_slave_data),
-  GFP_KERNEL);
+   data-slave_data = devm_kzalloc(pdev-dev, data-slaves
+   * sizeof(struct cpsw_slave_data),
+   GFP_KERNEL);
if (!data-slave_data)
-   return -EINVAL;
+   return -ENOMEM;
 
if (of_property_read_u32(node, cpdma_channels, prop)) {
pr_err(Missing cpdma_channels property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-channels = prop;
 
if (of_property_read_u32(node, ale_entries, prop)) {
pr_err(Missing ale_entries property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-ale_entries = prop;
 
if (of_property_read_u32(node, bd_ram_size, prop)) {
pr_err(Missing bd_ram_size property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-bd_ram_size = prop;
 
if (of_property_read_u32(node, rx_descs, prop)) {
pr_err(Missing rx_descs property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-rx_descs = prop;
 
if (of_property_read_u32(node, mac_control, prop)) {
pr_err(Missing mac_control property in the DT.\n);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
data-mac_control = prop;
 
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, phy_id, lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err(Missing slave[%d] phy_id property\n, i);
-   ret = -EINVAL;
-   goto error_ret;
+   return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
 
return 0;
-
-error_ret:
-   kfree(data-slave_data);
-   return ret;
 }
 
 static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
priv_sl2-coal_intvl = 0;
priv_sl2-bus_freq_mhz = priv-bus_freq_mhz;
 
-   priv_sl2-cpsw_res = priv-cpsw_res;
priv_sl2-regs = priv-regs;
priv_sl2-host_port = priv-host_port;
priv_sl2-host_port_regs = priv-host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv*priv;
struct cpdma_params dma_params;