Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[George Cherian]

Hi Stephen,

Thanks for your review.

On 8/20/2013 1:01 AM, Stephen Warren wrote:


On 08/16/2013 04:13 AM, George Cherian wrote:

Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.
diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt 
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
+EXTCON FOR DRA7xx
+
+Required Properties:

Please at lest explain what a DRA7xxx is, and the purpose of the HW
module this binding describes.


DRA7xx is the SoC name and the USB VID  detection is implemented via gpio's
Basically it does only ID detection via GPIO and there is no VBUS 
detection in h/w.



+ - compatible : Should be ti,dra7xx-usb

If this is a USB VID detector rather than a full USB host controller,
then usb in the binding is a bit over-reaching. Perhaps -usb-vid or
-usb-vid-detector would be more accurate.


This will be renamed to dra7xx-extcon.



+ - gpios : phandle to ID pin and interrupt gpio.

This isn't just a phandle; it's phandle+args, or a GPIO specifier. Some
reference should be made to ../gpio/gpio.txt for the format.


okay

Why does the interrupt line need to be included in a list of GPIOs?


ID pins are connected to pcf8575, and the pcf8575's interrupt line is 
inturn connected to

gpio bank6 pin 11, we use this gpio interrupt to detect the ID pin change.

If the DRA7xxx is a VID detector, why does it even need/have any GPIOs
associated with it; surely it has a dedicated VID input pin. Can you
provide more details re: how the HW is structured.


+Optional Properties:
+  - interrupt-parent : interrupt controller phandle
+  - interrupts : interrupt number
+
+

It's typical insert the following between those two blank lines:

Example:

... or delete one of the blank lines.


+dra7x_extcon1 {
+   compatible = ti,dra7xx-usb;
+   gpios = pcf_usb 1 0,
+   gpio6 11 2;
+   interrupt-parent = gpio6;
+   interrupts = 11;
+   };
+

No need for that trailing blank line.


okay





--
-George

--
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/5] mfd: twl6030-irq: rework and add twl6032 support

[Graeme Gregory]

On 20/08/13 02:01, Samuel Ortiz wrote:

Hi Grygorii,

On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote:

This patch series intorduces twl6030-irq module rework to use Threaded IRQ and
linear irq_domain, and adds support for PMIC TWL6032 IRQs.

After this patch series TWL6030/6032 IRQs will be supported only for DT boot 
mode.

Changes since v1:
- Added new patch mfd: twl6030-irq: create struct twl6030_irq
   which introduces struct twl6030_irq to store all local variables inside it.
- Patch mfd: twl6030-irq: migrate to IRQ threaded handler:
   Minor comments applied; fixed twl6030_exit_irq();
   The Parent IRQ has been set for each nested IRQ.
- Patch mfd: twl6030-irq: convert to use linear irq_domain:
   The irq_find_mapping() is used in twl6030_mmc_card_detect_config()
   to get virtual IRQ number.

This looks good to me. Kevin, Graeme, any further comments/ACKs ?

Cheers,
Samuel.


Yes, it looked good to me as well.

Acked-by: Graeme Gregory g...@slimlogic.co.uk

G

--
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 3/3] ARM: OMAP2+: Let DT say what devices should not to idled or reset

[Rajendra Nayak]

Now that we have DT bindings to specify which devices on the SoC should not
be reset or idled, get rid of the same information existing as part of the
hwmod data files and pass this info from DT instead.

For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to
any errata around the GPMC IP, but rather because any timings
set by the bootloader are not being correctly programmed by the kernel.
This seems like something that needs to be fixed as part of GPMC driver
in the kernel, and hence the flag is left as is in hwmod, which can be
removed once the driver does what its expected to.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi  |2 ++
 arch/arm/boot/dts/omap4.dtsi   |3 +++
 arch/arm/boot/dts/omap5.dtsi   |2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |4 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |2 --
 6 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..402d373 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -492,6 +492,7 @@
reg = 0x44d0 0x4000/* M3 UMEM */
   0x44d8 0x2000;  /* M3 DMEM */
ti,hwmods = wkup_m3;
+   ti,no-reset;
};
 
elm: elm@4808 {
@@ -522,6 +523,7 @@
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
+   ti,no-idle;
reg = 0x5000 0x2000;
interrupts = 100;
gpmc,num-cs = 7;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..9e22399 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -214,6 +214,7 @@
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
ti,hwmods = gpmc;
+   ti,no-idle;
};
 
uart1: serial@4806a000 {
@@ -492,6 +493,7 @@
reg = 0x4c00 0x100;
interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = emif1;
+   ti,no-idle;
phy-type = 1;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
@@ -503,6 +505,7 @@
reg = 0x4d00 0x100;
interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = emif2;
+   ti,no-idle;
phy-type = 1;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..85d20af 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -607,6 +607,7 @@
emif1: emif@0x4c00 {
compatible  = ti,emif-4d5;
ti,hwmods   = emif1;
+   ti,no-idle;
phy-type= 2; /* DDR PHY type: Intelli PHY */
reg = 0x4c00 0x400;
interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
@@ -618,6 +619,7 @@
emif2: emif@0x4d00 {
compatible  = ti,emif-4d5;
ti,hwmods   = emif2;
+   ti,no-idle;
phy-type= 2; /* DDR PHY type: Intelli PHY */
reg = 0x4d00 0x400;
interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index d4f0531..f34612b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -198,7 +198,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.class  = am33xx_wkup_m3_hwmod_class,
.clkdm_name = l4_wkup_aon_clkdm,
/* Keep hardreset asserted */
-   .flags  = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
+   .flags  = HWMOD_NO_IDLEST,
.main_clk   = dpll_core_m4_div2_ck,
.prcm   = {
.omap4  = {
@@ -926,7 +926,7 @@ static struct omap_hwmod am33xx_gpmc_hwmod = {
.name   = gpmc,
.class  = am33xx_gpmc_hwmod_class,
.clkdm_name = l3s_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_RESET,
.main_clk   = l3s_gclk,
.prcm   = {
.omap4  = {
diff --git 

[PATCH 2/3] ARM: OMAP2+: Add new bindings for OMAP

[Rajendra Nayak]

On OMAP we have co-processor IPs, memory controllers,
GPIOs which control regulators and power switches to
PMIC, and SoC internal Bus IPs, some or most of which
should either not be reset or idled or both. Have a
way to pass this information from DT.
(In some cases there are erratas which prevent an IPs
from being reset)

Also update omap_hwmod to extract this from DT.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../devicetree/bindings/arm/omap/omap.txt  |3 ++-
 arch/arm/mach-omap2/omap_hwmod.c   |   22 +---
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 6d498c7..a08647e 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,7 +21,8 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
-
+- ti,no-reset: When present, the module should not be reset
+- ti,no-idle: When present, the module should not be idled
 
 Example:
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7f4db12..4c66a5e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2361,11 +2361,11 @@ static struct device_node *of_dev_hwmod_lookup(struct 
device_node *np,
  * are part of the device's address space can be ioremapped properly.
  * No return value.
  */
-static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
+static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data,
+struct device_node *np)
 {
struct omap_hwmod_addr_space *mem;
void __iomem *va_start = NULL;
-   struct device_node *np;
 
if (!oh)
return;
@@ -2381,12 +2381,10 @@ static void __init _init_mpu_rt_base(struct omap_hwmod 
*oh, void *data)
 oh-name);
 
/* Extract the IO space from device tree blob */
-   if (!of_have_populated_dt())
+   if (!np)
return;
 
-   np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, ocp), oh);
-   if (np)
-   va_start = of_iomap(np, oh-mpu_rt_idx);
+   va_start = of_iomap(np, oh-mpu_rt_idx);
} else {
va_start = ioremap(mem-pa_start, mem-pa_end - mem-pa_start);
}
@@ -2418,12 +2416,16 @@ static void __init _init_mpu_rt_base(struct omap_hwmod 
*oh, void *data)
 static int __init _init(struct omap_hwmod *oh, void *data)
 {
int r;
+   struct device_node *np = NULL;
 
if (oh-_state != _HWMOD_STATE_REGISTERED)
return 0;
 
+   if (of_have_populated_dt())
+   np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, ocp), oh);
+
if (oh-class-sysc)
-   _init_mpu_rt_base(oh, NULL);
+   _init_mpu_rt_base(oh, NULL, np);
 
r = _init_clocks(oh, NULL);
if (r  0) {
@@ -2431,6 +2433,12 @@ static int __init _init(struct omap_hwmod *oh, void 
*data)
return -EINVAL;
}
 
+   if (np)
+   if (of_find_property(np, ti,no-reset, NULL))
+   oh-flags |= HWMOD_INIT_NO_RESET;
+   if (of_find_property(np, ti,no-idle, NULL))
+   oh-flags |= HWMOD_INIT_NO_IDLE;
+
oh-_state = _HWMOD_STATE_INITIALIZED;
 
return 0;
-- 
1.7.9.5

--
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 1/3] ARM: OMAP2+: hwmod: cleanup HWMOD_INIT_NO_RESET usage

[Rajendra Nayak]

For modules/IPs/hwmods which do not have
-1- sys-class-reset()
and
-2- hardreset lines
and
-3- No way to do an ocp reset (no sysc control)
the flag 'HWMOD_INIT_NO_RESET' is not much useful.

Cleanup all such instances across various hwmod data files.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   18 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +++---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |6 +++---
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index eb2f3b9..d4f0531 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -52,7 +52,7 @@ static struct omap_hwmod am33xx_emif_hwmod = {
.name   = emif,
.class  = am33xx_emif_hwmod_class,
.clkdm_name = l3_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = dpll_ddr_m2_div2_ck,
.prcm   = {
.omap4  = {
@@ -74,7 +74,7 @@ static struct omap_hwmod am33xx_l3_main_hwmod = {
.name   = l3_main,
.class  = am33xx_l3_hwmod_class,
.clkdm_name = l3_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = l3_gclk,
.prcm   = {
.omap4  = {
@@ -96,7 +96,7 @@ static struct omap_hwmod am33xx_l3_instr_hwmod = {
.name   = l3_instr,
.class  = am33xx_l3_hwmod_class,
.clkdm_name = l3_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = l3_gclk,
.prcm   = {
.omap4  = {
@@ -119,7 +119,7 @@ static struct omap_hwmod am33xx_l4_ls_hwmod = {
.name   = l4_ls,
.class  = am33xx_l4_hwmod_class,
.clkdm_name = l4ls_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = l4ls_gclk,
.prcm   = {
.omap4  = {
@@ -134,7 +134,7 @@ static struct omap_hwmod am33xx_l4_hs_hwmod = {
.name   = l4_hs,
.class  = am33xx_l4_hwmod_class,
.clkdm_name = l4hs_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = l4hs_gclk,
.prcm   = {
.omap4  = {
@@ -150,7 +150,7 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod = {
.name   = l4_wkup,
.class  = am33xx_l4_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.prcm   = {
.omap4  = {
.clkctrl_offs   = AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
@@ -170,7 +170,7 @@ static struct omap_hwmod am33xx_mpu_hwmod = {
.name   = mpu,
.class  = am33xx_mpu_hwmod_class,
.clkdm_name = mpu_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = dpll_mpu_m2_ck,
.prcm   = {
.omap4  = {
@@ -472,7 +472,7 @@ static struct omap_hwmod am33xx_ocmcram_hwmod = {
.name   = ocmcram,
.class  = am33xx_ocmcram_hwmod_class,
.clkdm_name = l3_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = l3_gclk,
.prcm   = {
.omap4  = {
@@ -526,7 +526,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
.name   = control,
.class  = am33xx_control_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
-   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = dpll_core_m4_div2_ck,
.prcm   = {
.omap4  = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9c3b504..1e5b12c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -914,7 +914,7 @@ static struct omap_hwmod omap44xx_emif1_hwmod = {
.name   = emif1,
.class  = omap44xx_emif_hwmod_class,
.clkdm_name = l3_emif_clkdm,
-   .flags  = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+   .flags  = HWMOD_INIT_NO_IDLE,
.main_clk   = 

[PATCH 0/3] OMAP: Add DT bindings to specify when devices should not be idled or reset

[Rajendra Nayak]

We have devices like co-processors, SoC internal busses, memory controllers
etc which should not be idled or reset. In some cases erratas around IP blocks
prevent them from either being idled or reset. Have a way to pass this
information from Device tree, and get rid of similar information that
exists as part of the omap_hwmod data files for various DT only OMAP SoCs.

Patches are tested on am335x beagleboneblack and omap4 panda es boards.

Rajendra Nayak (3):
  ARM: OMAP2+: hwmod: cleanup HWMOD_INIT_NO_RESET usage
  ARM: OMAP2+: Add new bindings for OMAP
  ARM: OMAP2+: Let DT say what devices should not to idled or reset

 .../devicetree/bindings/arm/omap/omap.txt  |3 ++-
 arch/arm/boot/dts/am33xx.dtsi  |2 ++
 arch/arm/boot/dts/omap4.dtsi   |3 +++
 arch/arm/boot/dts/omap5.dtsi   |2 ++
 arch/arm/mach-omap2/omap_hwmod.c   |   22 +---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   22 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |4 +---
 8 files changed, 38 insertions(+), 26 deletions(-)

-- 
1.7.9.5

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

[RESEND PATCH] ARM: OMAP: TI81XX: add always-on powerdomain for TI81XX

[Aida Mynzhasova]

This patch adds alwon powerdomain support for TI81XX, which is required
for stable functioning of a big number of TI81XX subsystems.

Signed-off-by: Aida Mynzhasova aida.mynzhas...@skitlab.ru
---
 arch/arm/mach-omap2/powerdomains3xxx_data.c | 8 
 arch/arm/mach-omap2/prcm-common.h   | 1 +
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c 
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index e2d4bd8..328c103 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -336,6 +336,13 @@ static struct powerdomain dpll5_pwrdm = {
.voltdm   = { .name = core },
 };
 
+static struct powerdomain alwon_81xx_pwrdm = {
+   .name = alwon_pwrdm,
+   .prcm_offs= TI81XX_PRM_ALWON_MOD,
+   .pwrsts   = PWRSTS_OFF_ON,
+   .voltdm   = { .name = core },
+};
+
 static struct powerdomain device_81xx_pwrdm = {
.name = device_pwrdm,
.prcm_offs= TI81XX_PRM_DEVICE_MOD,
@@ -442,6 +449,7 @@ static struct powerdomain *powerdomains_am35x[] __initdata 
= {
 };
 
 static struct powerdomain *powerdomains_ti81xx[] __initdata = {
+   alwon_81xx_pwrdm,
device_81xx_pwrdm,
active_816x_pwrdm,
default_816x_pwrdm,
diff --git a/arch/arm/mach-omap2/prcm-common.h 
b/arch/arm/mach-omap2/prcm-common.h
index ff1ac4a..0e841fd 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -58,6 +58,7 @@
 #define TI816X_PRM_IVAHD1_MOD  0x0d00
 #define TI816X_PRM_IVAHD2_MOD  0x0e00
 #define TI816X_PRM_SGX_MOD 0x0f00
+#define TI81XX_PRM_ALWON_MOD   0x1800
 
 /* 24XX register bits shared between CM  PRM registers */
 
-- 
1.8.1.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 v2 0/5] mfd: twl6030-irq: rework and add twl6032 support

[Samuel Ortiz]

On Tue, Aug 20, 2013 at 08:13:54AM +0100, Graeme Gregory wrote:
 On 20/08/13 02:01, Samuel Ortiz wrote:
 Hi Grygorii,
 
 On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote:
 This patch series intorduces twl6030-irq module rework to use Threaded IRQ 
 and
 linear irq_domain, and adds support for PMIC TWL6032 IRQs.
 
 After this patch series TWL6030/6032 IRQs will be supported only for DT 
 boot mode.
 
 Changes since v1:
 - Added new patch mfd: twl6030-irq: create struct twl6030_irq
which introduces struct twl6030_irq to store all local variables 
  inside it.
 - Patch mfd: twl6030-irq: migrate to IRQ threaded handler:
Minor comments applied; fixed twl6030_exit_irq();
The Parent IRQ has been set for each nested IRQ.
 - Patch mfd: twl6030-irq: convert to use linear irq_domain:
The irq_find_mapping() is used in twl6030_mmc_card_detect_config()
to get virtual IRQ number.
 This looks good to me. Kevin, Graeme, any further comments/ACKs ?
 
 Cheers,
 Samuel.
 
 Yes, it looked good to me as well.
 
 Acked-by: Graeme Gregory g...@slimlogic.co.uk
Thanks. All 5 patches applied to mfd-next.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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 00/13] ARM: OMAP2+: AM43x PRCM support

[Benoit Cousson]

+ Rajendra and Tero,

Hi Afzal,

On 19/08/2013 08:36, Afzal Mohammed wrote:

Hi Tony,

On Tuesday 13 August 2013 01:31 PM, Tony Lindgren wrote:


Hi Paul  Benoit,

Does this series look OK to you guys to queue or ack?



Can you please consider queuing this series for the coming merge window
as we are getting closer to the merge window.

If Paul or Benoit has any comments on this, we can have patches to fix
it up on top of this as required or these patches be reverted in the
worst case.


That series is pretty big and I will not have the time to review it 
properly. Moreover, without any public documentation, it will be really 
hard to do a correct review anyway.


That series must be reviewed and acked by people inside TI who does have 
the knowledge and the skill to do that.


I strongly recommend you to ask Rajendra and Tero to review it and ack 
it ASAP.


Otherwise, I guess that most of these patches should be non-intrusive 
for other OMAPs beside that one (ARM: OMAP2+: CM: reintroduce SW_SLEEP 
for OMAP4). And for the moment, that's maybe the most important point.


Have you checked that it will not generate any regression for OMAP4 in 
term of PM features: suspend, cpuidle at least?


Regards,
Benoit



Regards
Afzal



* Afzal Mohammed af...@ti.com [130802 06:42]:

Hi,

AM43x PRCM support (excluding clock tree) is being added with this
series. AM43x reuses most of the IP's from AM335x, as that is the
case, much of the AM335x hwmod data is reused.

I am aware that this series adds around +1K lines to platform. We in
TI, here are making efforts to clean platform code gradually and keep
to minumum the code being added to support new SoC's. Please note that
this SoC support series has positive diffstat of just above 1K only.
This compared to last SoC that was supported in OMAP family during
last merge window is way less (this is only around 1/8th postive
diffstat of it). Clock data is not added in this series, instead
directly clock tree in DT with driver would be used, this is a work in
progress. And as seen from recent OMAP clock tree DT conversion
series, there are serious efforts ongoing to that end. Also we will
start working on moving hwmod away from platform folders. In addition,
recently there was a PRCM cleanup by Rajendra Nayak that removed near
to 11K lines.

Considering the above facts, I request the maintainers to consider
this series for the next merge window.

Currently there is no public TRM available for AM43x.

Hwmod database of AM335x is reused by moving common elements to a new
array (most of AM335x IP's are present in AM43x) and keeping separate
arrays for elements that are specific only to either one of AM335x or
AM43x. And in the cases where relevant IP is present in both that has
difference in details like CLKCTRL register offsets, it is being
updated at runtime based on the SoC detected.

Powerdomain  Clockdomain data has been added separately as it was not
giving much advantage reusing AM335x ones (runtime updates required
was getting too ugly). But as AM43x PRCM functionality is similar to
OMAP4, power domain, clock domain  hwmod operations are reused from
OMAP4.

A single header file has been added to provide all AM43x PRCM defines.

Here sequencewise, initially AM335x hwmod is modified to have it's
fields get updated at runtime (wherever element is shared and has
some difference with AM43x). Then power domain, clock domain for AM43x
is added and finally AM335x hwmod database is updated with AM43x
specifics.

This series is being developed with additional clock tree changes that
are being DT'fied.

Additional DTS changes (posted separate from this series) are also
required for hwmod to get register target address space as most of
AM335x hwmod address space details has been recently cleaned up and
moved to DTS.

Regards
Afzal

Afzal Mohammed (8):
   ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse
   ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling
   ARM: OMAP2+: hwmod: AMx3: remove common static fields
   ARM: OMAP2+: PRCM: AM43x definitions
   ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling
   ARM: OMAP2+: hwmod: AM43x operations
   ARM: OMAP2+: AM43x: PRCM kbuild
   ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x

Ambresh K (3):
   ARM: OMAP2+: PM: AM43x powerdomain data
   ARM: OMAP2+: CM: AM43x clockdomain data
   ARM: OMAP2+: AM43x PRCM init

Ankur Kishore (1):
   ARM: OMAP2+: CM: cm_inst offset s16-u16

Vaibhav Bedia (1):
   ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4

  arch/arm/mach-omap2/Makefile|5 +-
  arch/arm/mach-omap2/clockdomain.h   |4 +-
  arch/arm/mach-omap2/clockdomains43xx_data.c |  199 
  arch/arm/mach-omap2/cm33xx.c|   30 +-
  arch/arm/mach-omap2/cm33xx.h|   28 +-
  arch/arm/mach-omap2/cminst44xx.c|   58 ++-
  arch/arm/mach-omap2/cminst44xx.h|   25 +-
  arch/arm/mach-omap2/io.c|6 +
  arch/arm/mach-omap2/omap_hwmod.c| 

Re: AM335x, early printk

[Lokesh Vutla]

Hi Sebastian,

On Monday 19 August 2013 06:07 PM, Sebastian Andrzej Siewior wrote:
 On 08/19/2013 02:27 PM, Jean Pihet wrote:
 Hi!
 
 Hi Jean,
 
 You need to add 'earlyprintk' in the kernel command line, given (I
 suppose) by U-Boot.
 
 Ah, good hint.
 

 I hope this helps!
 
 Yes. I do not see the decompress messages but I have an early console
 later on. Unfortunately it stops now right at the serial core:
 
 |pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
 |Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
I guess you are missing the following series from Rajendra. 

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92515.html

Thanks and regards,
Lokesh
 

 Jean
 
 Sebastian
 --
 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 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[George Cherian]

Hi Chanwoo,

Thanks for your review.

On 8/20/2013 5:54 AM, Chanwoo Choi wrote:

Hi George,

On 08/16/2013 07:13 PM, George Cherian wrote:

Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.

Signed-off-by: George Cherian george.cher...@ti.com
---
  .../devicetree/bindings/extcon/extcon-dra7xx.txt   |  19 ++
  drivers/extcon/Kconfig |   7 +
  drivers/extcon/Makefile|   1 +
  drivers/extcon/extcon-dra7xx.c | 234 +
  4 files changed, 261 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
  create mode 100644 drivers/extcon/extcon-dra7xx.c

diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt 
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
new file mode 100644
index 000..37e4c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
@@ -0,0 +1,19 @@
+EXTCON FOR DRA7xx
+
+Required Properties:
+ - compatible : Should be ti,dra7xx-usb
+ - gpios : phandle to ID pin and interrupt gpio.
+
+Optional Properties:
+  - interrupt-parent : interrupt controller phandle
+  - interrupts : interrupt number
+
+
+dra7x_extcon1 {

You used 'dra7xx-usb' device name. Why did you use 'dra7x_extcon1' name?
What is meaning 'dra7x_extcon1'?


I will rename it to  dra7xx_extcon.

+   compatible = ti,dra7xx-usb;
+   gpios = pcf_usb 1 0,
+   gpio6 11 2;
+   interrupt-parent = gpio6;
+   interrupts = 11;
+   };

You have to keep indentation rule.


okay



+
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index f1d54a3..b9cf0b2 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -64,4 +64,11 @@ config EXTCON_PALMAS
  Say Y here to enable support for USB peripheral and USB host
  detection by palmas usb.
  
+config EXTCON_DRA7XX

+   tristate DRA7XX EXTCON support
+   help
+ Say Y here to enable support for USB peripheral and USB host
+ detection by pcf8575 using DRA7XX extcon.

You should explain detailed description about pcf8575 on patch description
and change description of EXTCON_DRA7xx as following:
using DRA7XX extcon - using DRA7XX device or using DRA7XX usb


okay



+
+

Remove unnecessary blank line.


okay



  endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index e4fa8ba..e4778f9 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
  obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
  obj-$(CONFIG_EXTCON_ARIZONA)  += extcon-arizona.o
  obj-$(CONFIG_EXTCON_PALMAS)   += extcon-palmas.o
+obj-$(CONFIG_EXTCON_DRA7XX)+= extcon-dra7xx.o
diff --git a/drivers/extcon/extcon-dra7xx.c b/drivers/extcon/extcon-dra7xx.c
new file mode 100644
index 000..268c25e
--- /dev/null
+++ b/drivers/extcon/extcon-dra7xx.c
@@ -0,0 +1,234 @@
+/*
+ * DRA7XX USB ID pin detection driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: George Cherian george.cher...@ti.com
+ *
+ * Based on extcon-palmas.c
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/kthread.h
+#include linux/freezer.h
+#include linux/platform_device.h
+#include linux/extcon.h
+#include linux/err.h
+#include linux/of.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/of_platform.h
+
+struct dra7xx_usb {
+   struct device *dev;
+
+   struct extcon_dev edev;
+   struct task_struct *thread_task;
+
+   /*GPIO pin */

Add space between /* and GPIO.


okay



+   int id_gpio;
+   int irq_gpio;
+
+   int id_prev;
+   int id_current;
+
+};
+
+static const char *dra7xx_extcon_cable[] = {
+   [0] = USB,
+   [1] = USB-HOST,
+   NULL,
+};
+
+static const int mutually_exclusive[] = {0x3, 0x0};
+
+static int id_poll_func(void *data)
+{
+   struct dra7xx_usb *dra7xx_usb = (struct dra7xx_usb *) data;
+
+   allow_signal(SIGINT);
+   allow_signal(SIGTERM);
+   allow_signal(SIGKILL);
+   allow_signal(SIGUSR1);
+
+   set_freezable();
+
+   while (!kthread_should_stop()) {
+   dra7xx_usb-id_current = gpio_get_value_cansleep
+   

[PATCH v4 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver

[Ivan T. Ivanov]

From: Ivan T. Ivanov iiva...@mm-sol.com

DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
 drivers/usb/dwc3/Kconfig|8 +++
 drivers/usb/dwc3/Makefile   |1 +
 drivers/usb/dwc3/dwc3-msm.c |  167 +++
 3 files changed, 176 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-msm.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..d845966 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -71,6 +71,14 @@ config USB_DWC3_PCI
  One such PCIe-based platform is Synopsys' PCIe HAPS model of
  this IP.
 
+config USB_DWC3_MSM
+   tristate Qualcomm MSM/APQ Platforms
+   default USB_DWC3
+   select USB_MSM_DWC3_PHYS
+   help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
 comment Debugging features
 
 config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
 obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
 obj-$(CONFIG_USB_DWC3_EXYNOS)  += dwc3-exynos.o
 obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..361076c
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,167 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/usb/phy.h
+
+struct dwc3_msm {
+   struct device   *dev;
+
+   struct clk  *core_clk;
+   struct clk  *iface_clk;
+   struct clk  *sleep_clk;
+   struct clk  *utmi_clk;
+
+   struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+   struct device_node *node = pdev-dev.of_node;
+   struct dwc3_msm *mdwc;
+   struct resource *res;
+   void __iomem *tcsr;
+   int ret = 0;
+
+   mdwc = devm_kzalloc(pdev-dev, sizeof(*mdwc), GFP_KERNEL);
+   if (!mdwc)
+   return -ENOMEM;
+
+   platform_set_drvdata(pdev, mdwc);
+   mdwc-dev = pdev-dev;
+
+   mdwc-gdsc = devm_regulator_get(mdwc-dev, gdsc);
+
+   mdwc-core_clk = devm_clk_get(pdev-dev, core);
+   if (IS_ERR(mdwc-core_clk)) {
+   dev_dbg(pdev-dev, failed to get core clock\n);
+   return PTR_ERR(mdwc-core_clk);
+   }
+
+   mdwc-iface_clk = devm_clk_get(pdev-dev, iface);
+   if (IS_ERR(mdwc-iface_clk)) {
+   dev_dbg(pdev-dev, failed to get iface clock\n);
+   return PTR_ERR(mdwc-iface_clk);
+   }
+
+   mdwc-sleep_clk = devm_clk_get(pdev-dev, sleep );
+   if (IS_ERR(mdwc-sleep_clk)) {
+   dev_dbg(pdev-dev, failed to get sleep clock\n);
+   return  PTR_ERR(mdwc-sleep_clk);
+   }
+
+   mdwc-utmi_clk = devm_clk_get(pdev-dev, utmi);
+   if (IS_ERR(mdwc-utmi_clk)) {
+   dev_dbg(pdev-dev, failed to get utmi clock\n);
+   return  PTR_ERR(mdwc-utmi_clk);
+   }
+
+   if (!IS_ERR(mdwc-gdsc)) {
+   ret = regulator_enable(mdwc-gdsc);
+   if (ret)
+   dev_err(mdwc-dev, cannot enable usb3 gdsc\n);
+   }
+
+   /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and 60MHZ for HSUSB mode.
+*/
+   clk_set_rate(mdwc-core_clk, 12500);
+   clk_prepare_enable(mdwc-core_clk);
+   clk_prepare_enable(mdwc-iface_clk);
+   clk_prepare_enable(mdwc-sleep_clk);
+   clk_prepare_enable(mdwc-utmi_clk);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   tcsr = devm_ioremap_resource(pdev-dev, res);
+   if (!tcsr) {
+   ret = PTR_ERR(tcsr);
+   goto dis_clks;
+   }
+
+   /*
+* Primary USB port is shared between USB2 and USB3 controllers.
+   

[PATCH v4 1/3] usb: dwc3: msm: Add device tree binding information

[Ivan T. Ivanov]

From: Ivan T. Ivanov iiva...@mm-sol.com

MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.

It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
 .../devicetree/bindings/usb/msm-ssusb.txt  |  104 
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt

diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt 
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..cacbd3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,104 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+
+DWC3 Highspeed USB PHY
+==
+Required properities :
+- compatible : sould be qcom,dwc3-hsphy;
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+   xo : External reference clock 19 MHz
+   sleep_a : Sleep clock, used when USB3 core goes into low
+   power mode (U3).
+supply-name-supply : phandle to the regulator device tree node
+Required supply-name are:
+   v1p8 : 1.8v supply for HSPHY
+   v3p3 : 3.3v supply for HSPHY
+   vbus : vbus supply for host mode
+   vddcx : vdd supply for HS-PHY digital circuit operation
+
+DWC3 Superspeed USB PHY
+===
+Required properities :
+- compatible : sould be qcom,dwc3-ssphy;
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+   xo : External reference clock 19 MHz
+   ref : Reference clock - used in host mode.
+supply-name-supply : phandle to the regulator device tree node
+Required supply-name are:
+   v1p8 : 1.8v supply for SS-PHY
+   vddcx : vdd supply for SS-PHY digital circuit operation
+
+DWC3 controller wrapper
+===
+Required properties :
+- compatible : should be qcom,dwc3
+- reg : offset and length of the register set in the memory map
+   offset and length of the TCSR register for routing USB
+   signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+   core : Master/Core clock, have to be = 125 MHz for SS
+   operation and = 60MHz for HS operation
+   iface : System bus AXI clock
+   sleep : Sleep clock, used when USB3 core goes into low
+   power mode (U3).
+   utmi : Generated by HS-PHY. Used to clock the low power
+   parts of thr HS Link layer.
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+  regulator node to the USB controller.
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Example device nodes:
+
+   dwc3_hsphy: phy@f92f8800 {
+   compatible = qcom,dwc3-hsphy;
+   reg = 0xf92f8800 0x30;
+
+   clocks = cxo, usb2a_phy_sleep_cxc;
+   clock-names = xo, sleep_a;
+
+   vbus-supply = supply;
+   vddcx-supply = supply;
+   v1p8-supply = supply;
+   v3p3-supply = supply;
+   };
+
+   dwc3_ssphy: phy@f92f8830 {
+   compatible = qcom,dwc3-ssphy;
+   reg = 0xf92f8830 0x30;
+
+   clocks = cxo, usb30_mock_utmi_cxc;
+   clock-names = xo, ref;
+
+   vddcx-supply = supply;
+   v1p8-supply = supply;
+   };
+
+   usb@fd4ab000 {
+   compatible = qcom,dwc3;
+   #address-cells = 1;
+   #size-cells = 1;
+   reg = 0xfd4ab000 0x4;
+
+   clocks = usb30_master_cxc, sys_noc_usb3_axi_cxc,
+   usb30_sleep_cxc, usb30_mock_utmi_cxc;
+   clock-names = core, iface, sleep, utmi;
+
+   gdsc-supply = supply;
+
+   ranges;
+   dwc3@f920 {
+   compatible = snps,dwc3;
+   reg = 0xf920 0xcd00;
+   interrupts = 0 131 0;
+   usb-phy = dwc3_hsphy, dwc3_ssphy;
+   tx-fifo-resize;
+   };
+   };
-- 
1.7.9.5

--
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/3] DWC3 USB support for Qualcomm platform

[Ivan T. Ivanov]

From: Ivan T. Ivanov iiva...@mm-sol.com

Hi,

Here is fourth version of MSM USB3 drivers patches.

Changes since v3:
* Remove _clk suffix from clock names
* Clarify required child node for qcom,dwc3
* Fix comments in functions headers
* Use dbg instead err in drivers probe functions.

Changes since v2:
* Several improvements in devicetree bindings description
* Disable regulators in glue layer if there is error during 
  ioremap.

Changes since first version:
* Split devicetree bindings description file to separate patch
* Address comments for device bindings description
* Fix typo in 'gdsc' requlator name.

These patches add basic support for USB3.0 controllers found
on MSM platforms. USB3.0 core is based on Synopsys DesignWare 
SuperSpeed IP. 

Generated on top of Felipe 'testing' branch.

Ivan T. Ivanov (3):
  usb: dwc3: msm: Add device tree binding information
  usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
  usb: dwc3: Add Qualcomm DWC3 glue layer driver

 .../devicetree/bindings/usb/msm-ssusb.txt  |  104 ++
 drivers/usb/dwc3/Kconfig   |8 +
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/dwc3-msm.c|  167 +
 drivers/usb/phy/Kconfig|   11 +
 drivers/usb/phy/Makefile   |2 +
 drivers/usb/phy/phy-msm-dwc3-hs.c  |  327 +
 drivers/usb/phy/phy-msm-dwc3-ss.c  |  374 
 8 files changed, 994 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
 create mode 100644 drivers/usb/dwc3/dwc3-msm.c
 create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
 create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c

-- 
1.7.9.5

--
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 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Ivan T. Ivanov]

From: Ivan T. Ivanov iiva...@mm-sol.com

These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
 drivers/usb/phy/Kconfig   |   11 ++
 drivers/usb/phy/Makefile  |2 +
 drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
 drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +
 4 files changed, 714 insertions(+)
 create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
 create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d5589f9..c525835 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -214,6 +214,17 @@ config USB_RCAR_PHY
  To compile this driver as a module, choose M here: the
  module will be called phy-rcar-usb.
 
+config USB_MSM_DWC3_PHYS
+   tristate Qualcomm DWC3 USB controller PHY's support
+   depends on (USB || USB_GADGET)  ARCH_MSM
+   select USB_PHY
+   help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
 config USB_ULPI
bool Generic ULPI Transceiver Driver
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 2135e85..8f2dd94 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA)  += phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
 obj-$(CONFIG_USB_ISP1301)  += phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)  += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-ss.o
 obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c 
b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 000..840e766
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,327 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/usb/phy.h
+
+/**
+ *  USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG  (0x04)
+#define QSCRATCH_GENERAL_CFG   (0x08)
+#define PHY_CTRL_REG   (0x10)
+#define PARAMETER_OVERRIDE_X_REG   (0x14)
+#define CHARGING_DET_CTRL_REG  (0x18)
+#define CHARGING_DET_OUTPUT_REG(0x1c)
+#define ALT_INTERRUPT_EN_REG   (0x20)
+#define PHY_IRQ_STAT_REG   (0x24)
+#define CGCTL_REG  (0x28)
+
+#define PHY_3P3_VOL_MIN305 /* uV */
+#define PHY_3P3_VOL_MAX330 /* uV */
+#define PHY_3P3_HPM_LOAD   16000   /* uA */
+
+#define PHY_1P8_VOL_MIN180 /* uV */
+#define PHY_1P8_VOL_MAX180 /* uV */
+#define PHY_1P8_HPM_LOAD   19000   /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO   1   /* uV */
+#define USB_VDDCX_MIN  5   /* uV */
+#define USB_VDDCX_MAX  7   /* uV */
+
+struct msm_dwc3_hs_phy {
+   struct usb_phy  phy;
+   void __iomem*base;
+   struct device   *dev;
+
+   struct clk  *xo_clk;
+   struct clk  *sleep_a_clk;
+
+   struct regulator*v3p3;
+   struct regulator*v1p8;
+   struct regulator*vddcx;
+   struct regulator*vbus;
+};
+
+#definephy_to_dwc3_phy(x)  container_of((x), struct 
msm_dwc3_hs_phy, phy)
+
+
+/**
+ * Write register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dwc3_hs_write(void __iomem *base, u32 offset, u32 val)

Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[Chanwoo Choi]

Hi George,

 diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt 
 b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
 new file mode 100644
 index 000..37e4c22
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
 @@ -0,0 +1,19 @@
 +EXTCON FOR DRA7xx
 +
 +Required Properties:
 + - compatible : Should be ti,dra7xx-usb
 + - gpios : phandle to ID pin and interrupt gpio.
 +
 +Optional Properties:
 +  - interrupt-parent : interrupt controller phandle
 +  - interrupts : interrupt number
 +
 +
 +dra7x_extcon1 {
 You used 'dra7xx-usb' device name. Why did you use 'dra7x_extcon1' name?
 What is meaning 'dra7x_extcon1'?
 
 I will rename it to  dra7xx_extcon.

extcon naming means various external connector device. e.g., usb, jack, etc...
So, I prefer 'dra7xx_usb' instead of 'dra7xx_extcon'. I have plan to divide
extcon device driver according to the kind of device.


 +static int id_poll_func(void *data)
 +{
 +struct dra7xx_usb *dra7xx_usb = (struct dra7xx_usb *) data;
 +
 +allow_signal(SIGINT);
 +allow_signal(SIGTERM);
 +allow_signal(SIGKILL);
 +allow_signal(SIGUSR1);
 +
 +set_freezable();
 +
 +while (!kthread_should_stop()) {
 +dra7xx_usb-id_current = gpio_get_value_cansleep
 +(dra7xx_usb-id_gpio);
 +if (dra7xx_usb-id_current == dra7xx_usb-id_prev) {
 +schedule_timeout_interruptible
 +(msecs_to_jiffies(2*1000));
 +continue;
 +} else if (dra7xx_usb-id_current == 0) {
 +extcon_set_cable_state(dra7xx_usb-edev, USB, false);
 +extcon_set_cable_state(dra7xx_usb-edev,
 +USB-HOST, true);
 +} else {
 +extcon_set_cable_state(dra7xx_usb-edev,
 +USB-HOST, false);
 +extcon_set_cable_state(dra7xx_usb-edev, USB, true);
 +}
 Should dra7xx_usb keep always connected state with either USB or USB-HOST 
 cable?
 I don't understand. So please explain detailed operation method of 
 dra7xx_usb device.
 
 In dra7xx only ID pin is connected to the SoC gpio. There is no way, 
 currently to detect the VBUS on/off.
 So I always default to either HOST/DEVICE mode solely depending on the ID pin 
 value.
OK.

But I don't want to use kthread with polling method.
I recommend that you use interrupt method for cable detection.
All of extcon device driver have only used interrupt method without polling.

 

 +dra7xx_usb-id_prev = dra7xx_usb-id_current;
 +}
 +
 +return 0;
 +}
 +
 +static irqreturn_t id_irq_handler(int irq, void *data)
 +{
 +struct dra7xx_usb *dra7xx_usb = (struct dra7xx_usb *) data;
 +
 +dra7xx_usb-id_current = gpio_get_value_cansleep(dra7xx_usb-id_gpio);
 +
 +if (dra7xx_usb-id_current == dra7xx_usb-id_prev) {
 +return IRQ_NONE;
 +} else if (dra7xx_usb-id_current == 0) {

You should define some constant variable to clarify '0' meaning instead of 
using '0' directly.


 +dra7xx_usb = devm_kzalloc(pdev-dev, sizeof(*dra7xx_usb), GFP_KERNEL);
 +if (!dra7xx_usb)
 +return -ENOMEM;
 You have to add error message with dev_err().
 
 devm_kzalloc itself should give some message.

ok.


 +status = extcon_dev_register(dra7xx_usb-edev, dra7xx_usb-dev);
 +if (status) {
 +dev_err(pdev-dev, failed to register extcon device\n);
 +return status;
 You should restore previous operation about dra7xx_usb-irq_gpio.
 
 okay

 +}
 +
 +dra7xx_usb-id_prev = gpio_get_value_cansleep(dra7xx_usb-id_gpio);
 +if (dra7xx_usb-id_prev) {

ditto.
You should define some constant variable to clarify 'dra7xx_usb-id_prev' 
meaning.

 +extcon_set_cable_state(dra7xx_usb-edev, USB-HOST, false);
 +extcon_set_cable_state(dra7xx_usb-edev, USB, true);
 +} else {
 +extcon_set_cable_state(dra7xx_usb-edev, USB, false);
 +extcon_set_cable_state(dra7xx_usb-edev, USB-HOST, true);
 +}
 why did you do keep always connected state?
 
 There is no way, currently to detect the VBUS on/off.
 So I always default to either HOST/DEVICE mode solely depending on the ID pin 
 value.
 
 +
 +if (dra7xx_usb-irq_gpio) {
 +status = devm_request_threaded_irq(dra7xx_usb-dev, irq_num,
 +NULL, id_irq_handler, IRQF_SHARED |
 +IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
 +dev_name(pdev-dev), (void *) dra7xx_usb);
 +if (status)
 +dev_err(dra7xx_usb-dev, failed to request irq #%d\n,
 +irq_num);
 If devm_request_threaded_irq() return fail state, why did not you do add 
 error exception?
 
 If interrupt fails I fallback to polling thread.
 +else
 +return 0;
 If devm_request_threaded_irq() return success state, why did you directly 
 call 'return'?
 kthread_create operation isn't necessary?
 
 Yes kthread is optional. Some boards doenot have the ID pin hooked onto the 
 GPIO.
 In 

Re: [PATCH 1/6] ASoC: omap: simplify platform_get_resource_byname/devm_ioremap_resource

[Mark Brown]

On Mon, Aug 19, 2013 at 10:51:51AM +0200, Julia Lawall wrote:
 From: Julia Lawall julia.law...@lip6.fr
 
 Remove unneeded error handling on the result of a call to
 platform_get_resource_byname when the value is passed to 
 devm_ioremap_resource.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH v2 0/6] v4l: VPE mem to mem driver

[Archit Taneja]

VPE(Video Processing Engine) is an IP found on DRA7xx, this series adds VPE as a
mem to mem v4l2 driver, and VPDMA as a helper library.

The previous revision of the series described VPE in detail, you can have a look
at it here:

http://www.spinics.net/lists/linux-media/msg66518.html

There were a lot of useful suggestions made by Hans, Tomi and Laurent. This
series incorporate these changes. There are few comments which I haven't been
able to address, I've pointed those below too.

Changes in v2:
- Constify the structs that can be constified.
- Remove the use of wmb() from vpdma_submit_descs().
- Remove an unnecessary layer of helper macros used for creating or reading
  VPDMA descriptors.
- Create a CONFIG which enables/disables VPE debug prints.
- Remove CAPTURE/OUTPUT_MPLANE from device_caps.
- Fix the pix-field setting in TRY_FMT ioctl.
- Fix a bug in the v4l2 control handler registration and release.
- Move video_register_device() at the end of driver probe.
- Improve some of the function names, remove unnecessary BUG_ONs etc, use
  ERR_PTR() to return error codes correctly.

Things still open in v2:
- Tomi had a comment about the usage msleep_interruptible in the first patch. I
  am not clear whether this is actually a problem and what's the right approach.
- Laurent suggested using DMA allocation API for the VPDMA library, we currently
  use kzalloc to allocate and dma_map/unmap_single api to map to VPDMA/CPU. DMA
  pool api won't be a good replacement here.
- There was a suggestion to use synchronous firmware interface. If I understand
  right, synchronous interfaces forces us to have the firmware appended to the
  kernel, that's not something we want.


Archit Taneja (6):
  v4l: ti-vpe: Create a vpdma helper library
  v4l: ti-vpe: Add helpers for creating VPDMA descriptors
  v4l: ti-vpe: Add VPE mem to mem driver
  v4l: ti-vpe: Add de-interlacer support in VPE
  arm: dra7xx: hwmod data: add VPE hwmod data and ocp_if info
  experimental: arm: dts: dra7xx: Add a DT node for VPE

 arch/arm/boot/dts/dra7.dtsi|   11 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |   42 +
 drivers/media/platform/Kconfig |   16 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/ti-vpe/Makefile |5 +
 drivers/media/platform/ti-vpe/vpdma.c  |  846 
 drivers/media/platform/ti-vpe/vpdma.h  |  202 +++
 drivers/media/platform/ti-vpe/vpdma_priv.h |  640 +
 drivers/media/platform/ti-vpe/vpe.c| 2042 
 drivers/media/platform/ti-vpe/vpe_regs.h   |  496 +++
 10 files changed, 4302 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/Makefile
 create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
 create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
 create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h
 create mode 100644 drivers/media/platform/ti-vpe/vpe.c
 create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h

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

[PATCH v2 1/6] v4l: ti-vpe: Create a vpdma helper library

[Archit Taneja]

The primary function of VPDMA is to move data between external memory and
internal processing modules(in our case, VPE) that source or sink data. VPDMA is
capable of buffering this data and then delivering the data as demanded to the
modules as programmed. The modules that source or sink data are referred to as
clients or ports. A channel is setup inside the VPDMA to connect a specific
memory buffer to a specific client. The VPDMA centralizes the DMA control
functions and buffering required to allow all the clients to minimize the
effect of long latency times.

Add the following to the VPDMA helper:

- A data struct which describe VPDMA channels. For now, these channels are the
  ones used only by VPE, the list of channels will increase when VIP(Video
  Input Port) also uses the VPDMA library. This channel information will be
  used to populate fields required by data descriptors.

- Data structs which describe the different data types supported by VPDMA. This
  data type information will be used to populate fields required by data
  descriptors and used by the VPE driver to map a V4L2 format to the
  corresponding VPDMA data type.

- Provide VPDMA register offset definitions, functions to read, write and modify
  VPDMA registers.

- Functions to create and submit a VPDMA list. A list is a group of descriptors
  that makes up a set of DMA transfers that need to be completed. Each
  descriptor will either perform a DMA transaction to fetch input buffers and
  write to output buffers(data descriptors), or configure the MMRs of sub blocks
  of VPE(configuration descriptors), or provide control information to VPDMA
  (control descriptors).

- Functions to allocate, map and unmap buffers needed for the descriptor list,
  payloads containing MMR values and motion vector buffers. These use the
  DMA mapping APIs to ensure exclusive access to VPDMA.

- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the
  VPE interrupt line when a descriptor list is parsed completely and the DMA
  transactions are completed. This requires masking the events in VPDMA
  registers and configuring some top level VPE interrupt registers.

- Enable some VPDMA specific parameters: frame start event(when to start DMA for
  a client) and line mode(whether each line fetched should be mirrored or not).

- Function to load firmware required by VPDMA. VPDMA requires a firmware for
  it's internal list manager. We add the required request_firmware apis to fetch
  this firmware from user space.

- Function to dump VPDMA registers.

- A function to initialize and create a VPDMA instance, this will be called by
  the VPE driver with it's platform device pointer, this function will take care
  of loading VPDMA firmware and returning a vpdma_data instance back to the VPE
  driver. The VIP driver will also call the same init function to initialize 
it's
  own VPDMA instance.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpdma.c  | 578 +
 drivers/media/platform/ti-vpe/vpdma.h  | 154 
 drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++
 3 files changed, 851 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
 create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
 create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h

diff --git a/drivers/media/platform/ti-vpe/vpdma.c 
b/drivers/media/platform/ti-vpe/vpdma.c
new file mode 100644
index 000..84b8ee52
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -0,0 +1,578 @@
+/*
+ * VPDMA helper library
+ *
+ * Copyright (c) 2013 Texas Instruments Inc.
+ *
+ * David Griego, dagri...@biglakesoftware.com
+ * Dale Farnsworth, d...@farnsworth.org
+ * Archit Taneja, arc...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/err.h
+#include linux/firmware.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include vpdma.h
+#include vpdma_priv.h
+
+#define VPDMA_FIRMWARE vpdma-1b8.bin
+
+const struct vpdma_data_format vpdma_yuv_fmts[] = {
+   [VPDMA_DATA_FMT_Y444] = {
+   .data_type  = DATA_TYPE_Y444,
+   .depth  = 8,
+   },
+   [VPDMA_DATA_FMT_Y422] = {
+   .data_type  = DATA_TYPE_Y422,
+   .depth  = 8,
+   },
+   [VPDMA_DATA_FMT_Y420] = {
+   .data_type  = DATA_TYPE_Y420,
+   .depth  = 8,
+   },
+   [VPDMA_DATA_FMT_C444] = {
+   .data_type  = DATA_TYPE_C444,
+   .depth  = 8,
+   },
+   [VPDMA_DATA_FMT_C422] = {
+   .data_type  = DATA_TYPE_C422,
+   .depth  = 

[PATCH v2 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE

[Archit Taneja]

Add a DT node for VPE in dra7.dtsi. This is experimental because we might need
to split the VPE address space a bit more, and also because the IRQ line
described is accessible the IRQ crossbar driver is added for DRA7XX.

Cc: Rajendra Nayak rna...@ti.com
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..7c1cbfe 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -484,6 +484,17 @@
dmas = sdma 70, sdma 71;
dma-names = tx0, rx0;
};
+
+   vpe {
+   compatible = ti,vpe;
+   ti,hwmods = vpe;
+   reg = 0x489d 0xd000, 0x489dd000 0x400;
+   reg-names = vpe, vpdma;
+   interrupts = 0 158 0x4;
+   #address-cells = 1;
+   #size-cells = 0;
+   };
+
};
 
clocks {
-- 
1.8.1.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

[PATCH v2 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors

[Archit Taneja]

Create functions which the VPE driver can use to create a VPDMA descriptor and
add it to a VPDMA descriptor list. These functions take a pointer to an existing
list, and append the configuration/data/control descriptor header to the list.

In the case of configuration descriptors, the creation of a payload block may be
required(the payloads can hold VPE MMR values, or scaler coefficients). The
allocation of the payload buffer and it's content is left to the VPE driver.
However, the VPDMA library provides helper macros to create payload in the
correct format.

Add debug functions to dump the descriptors in a way such that it's easy to see
the values of different fields in the descriptors.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpdma.c  | 268 +++
 drivers/media/platform/ti-vpe/vpdma.h  |  48 +++
 drivers/media/platform/ti-vpe/vpdma_priv.h | 521 +
 3 files changed, 837 insertions(+)

diff --git a/drivers/media/platform/ti-vpe/vpdma.c 
b/drivers/media/platform/ti-vpe/vpdma.c
index 84b8ee52..18b7c24 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -21,6 +21,7 @@
 #include linux/platform_device.h
 #include linux/sched.h
 #include linux/slab.h
+#include linux/videodev2.h
 
 #include vpdma.h
 #include vpdma_priv.h
@@ -416,6 +417,273 @@ int vpdma_submit_descs(struct vpdma_data *vpdma, struct 
vpdma_desc_list *list)
return 0;
 }
 
+static void dump_cfd(struct vpdma_cfd *cfd)
+{
+   int class;
+
+   class = cfd_get_class(cfd);
+
+   pr_debug(config descriptor of payload class: %s\n,
+   class == CFD_CLS_BLOCK ? simple block :
+   address data block);
+
+   if (class == CFD_CLS_BLOCK)
+   pr_debug(word0: dst_addr_offset = 0x%08x\n,
+   cfd-dest_addr_offset);
+
+   if (class == CFD_CLS_BLOCK)
+   pr_debug(word1: num_data_wrds = %d\n, cfd-block_len);
+
+   pr_debug(word2: payload_addr = 0x%08x\n, cfd-payload_addr);
+
+   pr_debug(word3: pkt_type = %d, direct = %d, class = %d, dest = %d, 
+   payload_len = %d\n, cfd_get_pkt_type(cfd),
+   cfd_get_direct(cfd), class, cfd_get_dest(cfd),
+   cfd_get_payload_len(cfd));
+}
+
+/*
+ * append a configuration descriptor to the given descriptor list, where the
+ * payload is in the form of a simple data block specified in the descriptor
+ * header, this is used to upload scaler coefficients to the scaler module
+ */
+void vpdma_add_cfd_block(struct vpdma_desc_list *list, int client,
+   struct vpdma_buf *blk, u32 dest_offset)
+{
+   struct vpdma_cfd *cfd;
+   int len = blk-size;
+
+   WARN_ON(blk-dma_addr  VPDMA_DESC_ALIGN);
+
+   cfd = list-next;
+   WARN_ON((void *)(cfd + 1)  (list-buf.addr + list-buf.size));
+
+   cfd-dest_addr_offset = dest_offset;
+   cfd-block_len = len;
+   cfd-payload_addr = (u32) blk-dma_addr;
+   cfd-ctl_payload_len = cfd_pkt_payload_len(CFD_INDIRECT, CFD_CLS_BLOCK,
+   client, len  4);
+
+   list-next = cfd + 1;
+
+   dump_cfd(cfd);
+}
+
+/*
+ * append a configuration descriptor to the given descriptor list, where the
+ * payload is in the address data block format, this is used to a configure a
+ * discontiguous set of MMRs
+ */
+void vpdma_add_cfd_adb(struct vpdma_desc_list *list, int client,
+   struct vpdma_buf *adb)
+{
+   struct vpdma_cfd *cfd;
+   unsigned int len = adb-size;
+
+   WARN_ON(len  VPDMA_ADB_SIZE_ALIGN);
+   WARN_ON(adb-dma_addr  VPDMA_DESC_ALIGN);
+
+   cfd = list-next;
+   BUG_ON((void *)(cfd + 1)  (list-buf.addr + list-buf.size));
+
+   cfd-w0 = 0;
+   cfd-w1 = 0;
+   cfd-payload_addr = (u32) adb-dma_addr;
+   cfd-ctl_payload_len = cfd_pkt_payload_len(CFD_INDIRECT, CFD_CLS_ADB,
+   client, len  4);
+
+   list-next = cfd + 1;
+
+   dump_cfd(cfd);
+};
+
+/*
+ * control descriptor format change based on what type of control descriptor it
+ * is, we only use 'sync on channel' control descriptors for now, so assume 
it's
+ * that
+ */
+static void dump_ctd(struct vpdma_ctd *ctd)
+{
+   pr_debug(control descriptor\n);
+
+   pr_debug(word3: pkt_type = %d, source = %d, ctl_type = %d\n,
+   ctd_get_pkt_type(ctd), ctd_get_source(ctd), ctd_get_ctl(ctd));
+}
+
+/*
+ * append a 'sync on channel' type control descriptor to the given descriptor
+ * list, this descriptor stalls the VPDMA list till the time DMA is completed
+ * on the specified channel
+ */
+void vpdma_add_sync_on_channel_ctd(struct vpdma_desc_list *list,
+   enum vpdma_channel chan)
+{
+   struct vpdma_ctd *ctd;
+
+   ctd = list-next;
+   WARN_ON((void *)(ctd + 1)  (list-buf.addr + list-buf.size));
+
+   ctd-w0 = 0;
+   ctd-w1 = 0;
+   ctd-w2 = 0;
+   ctd-type_source_ctl = 

[PATCH v2 4/6] v4l: ti-vpe: Add de-interlacer support in VPE

[Archit Taneja]

Add support for the de-interlacer block in VPE.

For de-interlacer to work, we need to enable 2 more sets of VPE input ports
which fetch data from the 'last' and 'last to last' fields of the interlaced
video. Apart from that, we need to enable the Motion vector output and input
ports, and also allocate DMA buffers for them.

We need to make sure that two most recent fields in the source queue are
available and in the 'READY' state. Once a mem2mem context gets access to the
VPE HW(in device_run), it extracts the addresses of the 3 buffers, and provides
it to the data descriptors for the 3 sets of input ports((LUMA1, CHROMA1),
(LUMA2, CHROMA2), and (LUMA3, CHROMA3)) respectively for the 3 consecutive
fields. The motion vector and output port descriptors are configured and the
list is submitted to VPDMA.

Once the transaction is done, the v4l2 buffer corresponding to the oldest
field(the 3rd one) is changed to the state 'DONE', and the buffers corresponding
to 1st and 2nd fields become the 2nd and 3rd field for the next de-interlace
operation. This way, for each deinterlace operation, we have the 3 most recent
fields. After each transaction, we also swap the motion vector buffers, the new
input motion vector buffer contains the resultant motion information of all the
previous frames, and the new output motion vector buffer will be used to hold
the updated motion vector to capture the motion changes in the next field.

The de-interlacer is removed from bypass mode, it requires some extra default
configurations which are now added. The chrominance upsampler coefficients are
added for interlaced frames. Some VPDMA parameters like frame start event and
line mode are configured for the 2 extra sets of input ports.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 370 
 1 file changed, 336 insertions(+), 34 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 5e1d80e..724ae65 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -69,6 +69,8 @@
 #define VPE_CHROMA 1
 
 /* per m2m context info */
+#define VPE_MAX_SRC_BUFS   3   /* need 3 src fields to de-interlace */
+
 #define VPE_DEF_BUFS_PER_JOB   1   /* default one buffer per batch job */
 
 /*
@@ -110,6 +112,38 @@ static const struct vpe_us_coeffs us_coeffs[] = {
0x00C8, 0x0348, 0x0018, 0x3FD8, 0x3FB8, 0x0378, 0x00E8, 0x3FE8,
0x00C8, 0x0348, 0x0018, 0x3FD8, 0x3FB8, 0x0378, 0x00E8, 0x3FE8,
},
+   {
+   /* Coefficients for Top Field Interlaced input */
+   0x0051, 0x03D5, 0x3FE3, 0x3FF7, 0x3FB5, 0x02E9, 0x018F, 0x3FD3,
+   /* Coefficients for Bottom Field Interlaced input */
+   0x016B, 0x0247, 0x00B1, 0x3F9D, 0x3FCF, 0x03DB, 0x005D, 0x3FF9,
+   },
+};
+
+/*
+ * the following registers are for configuring some of the parameters of the
+ * motion and edge detection blocks inside DEI, these generally remain the 
same,
+ * these could be passed later via userspace if some one needs to tweak these.
+ */
+struct vpe_dei_regs {
+   unsigned long mdt_spacial_freq_thr_reg; /* VPE_DEI_REG2 */
+   unsigned long edi_config_reg;   /* VPE_DEI_REG3 */
+   unsigned long edi_lut_reg0; /* VPE_DEI_REG4 */
+   unsigned long edi_lut_reg1; /* VPE_DEI_REG5 */
+   unsigned long edi_lut_reg2; /* VPE_DEI_REG6 */
+   unsigned long edi_lut_reg3; /* VPE_DEI_REG7 */
+};
+
+/*
+ * default expert DEI register values, unlikely to be modified.
+ */
+static const struct vpe_dei_regs dei_regs = {
+   0x020C0804u,
+   0x0118100Fu,
+   0x08040200u,
+   0x1010100Cu,
+   0x10101010u,
+   0x10101010u,
 };
 
 /*
@@ -117,6 +151,7 @@ static const struct vpe_us_coeffs us_coeffs[] = {
  */
 struct vpe_port_data {
enum vpdma_channel channel; /* VPDMA channel */
+   u8  vb_index;   /* input frame f, f-1, f-2 index */
u8  vb_part;/* plane index for co-panar formats */
 };
 
@@ -125,6 +160,12 @@ struct vpe_port_data {
  */
 #define VPE_PORT_LUMA1_IN  0
 #define VPE_PORT_CHROMA1_IN1
+#define VPE_PORT_LUMA2_IN  2
+#define VPE_PORT_CHROMA2_IN3
+#define VPE_PORT_LUMA3_IN  4
+#define VPE_PORT_CHROMA3_IN5
+#define VPE_PORT_MV_IN 6
+#define VPE_PORT_MV_OUT7
 #define VPE_PORT_LUMA_OUT  8
 #define VPE_PORT_CHROMA_OUT9
 #define VPE_PORT_RGB_OUT   10
@@ -132,12 +173,40 @@ struct vpe_port_data {
 static const struct vpe_port_data port_data[11] = {
[VPE_PORT_LUMA1_IN] = {
.channel= VPE_CHAN_LUMA1_IN,
+   .vb_index   = 0,
.vb_part= VPE_LUMA,
},
[VPE_PORT_CHROMA1_IN] = {
.channel

[PATCH v2 5/6] arm: dra7xx: hwmod data: add VPE hwmod data and ocp_if info

[Archit Taneja]

Add hwmod data for the VPE IP, this is needed for the IP to be reset during
boot, and control the functional clock when the driver needs it via
pm_runtime apis. Add the corresponding ocp_if struct and add it DRA7XX's
ocp interface list.

Cc: Rajendra Nayak rna...@ti.com
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index f647998b..181365d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1883,6 +1883,39 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
},
 };
 
+/*
+ * 'vpe' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_vpe_sysc = {
+   .sysc_offs  = 0x0010,
+   .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+   .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_vpe_hwmod_class = {
+   .name   = vpe,
+   .sysc   = dra7xx_vpe_sysc,
+};
+
+/* vpe */
+static struct omap_hwmod dra7xx_vpe_hwmod = {
+   .name   = vpe,
+   .class  = dra7xx_vpe_hwmod_class,
+   .clkdm_name = vpe_clkdm,
+   .main_clk   = dpll_core_h23x2_ck,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_VPE_VPE_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_VPE_VPE_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
 
 /*
  * Interfaces
@@ -2636,6 +2669,14 @@ static struct omap_hwmod_ocp_if 
dra7xx_l4_wkup__wd_timer2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per3 - vpe */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__vpe = {
+   .master = dra7xx_l4_per3_hwmod,
+   .slave  = dra7xx_vpe_hwmod,
+   .clk= l3_iclk_div,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
@@ -2714,6 +2755,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
dra7xx_l3_main_1__vcp2,
dra7xx_l4_per2__vcp2,
dra7xx_l4_wkup__wd_timer2,
+   dra7xx_l4_per3__vpe,
NULL,
 };
 
-- 
1.8.1.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: AM335x, early printk

[Afzal Mohammed]

Hi Sebastian,

On Tuesday 20 August 2013 03:02 PM, Lokesh Vutla wrote:

 Yes. I do not see the decompress messages but I have an early console
 later on. Unfortunately it stops now right at the serial core:

 |pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
 |Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled

 I guess you are missing the following series from Rajendra. 
 
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92515.html

I think Lokesh's suggestion is more likely to help your case than mine.

Regards
Afzal

--
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/6] v4l: ti-vpe: Create a vpdma helper library

[Laurent Pinchart]

Hi Archit,

On Wednesday 14 August 2013 16:27:57 Archit Taneja wrote:
 On Friday 09 August 2013 03:34 AM, Laurent Pinchart wrote:
  On Friday 02 August 2013 19:33:38 Archit Taneja wrote:
  The primary function of VPDMA is to move data between external memory and
  internal processing modules(in our case, VPE) that source or sink data.
  VPDMA is capable of buffering this data and then delivering the data as
  demanded to the modules as programmed. The modules that source or sink
  data are referred to as clients or ports. A channel is setup inside the
  VPDMA to connect a specific memory buffer to a specific client. The VPDMA
  centralizes the DMA control functions and buffering required to allow all
  the clients to minimize the effect of long latency times.
  
  Add the following to the VPDMA helper:
  
  - A data struct which describe VPDMA channels. For now, these channels
  are the ones used only by VPE, the list of channels will increase when
  VIP(Video Input Port) also uses the VPDMA library. This channel
  information will be used to populate fields required by data descriptors.
  
  - Data structs which describe the different data types supported by
  VPDMA. This data type information will be used to populate fields
  required by data descriptors and used by the VPE driver to map a V4L2
  format to the corresponding VPDMA data type.
  
  - Provide VPDMA register offset definitions, functions to read, write and
  modify VPDMA registers.
  
  - Functions to create and submit a VPDMA list. A list is a group of
  descriptors that makes up a set of DMA transfers that need to be
  completed. Each descriptor will either perform a DMA transaction to fetch
  input buffers and write to output buffers(data descriptors), or configure
  the MMRs of sub blocks of VPE(configuration descriptors), or provide
  control information to VPDMA (control descriptors).
  
  - Functions to allocate, map and unmap buffers needed for the descriptor
  list, payloads containing MMR values and motion vector buffers. These use
  the DMA mapping APIs to ensure exclusive access to VPDMA.
  
  - Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on
  the VPE interrupt line when a descriptor list is parsed completely and
  the DMA transactions are completed. This requires masking the events in
  VPDMA registers and configuring some top level VPE interrupt registers.
  
  - Enable some VPDMA specific parameters: frame start event(when to start
  DMA for a client) and line mode(whether each line fetched should be
  mirrored or not).
  
  - Function to load firmware required by VPDMA. VPDMA requires a firmware
  for it's internal list manager. We add the required request_firmware
  apis to fetch this firmware from user space.
  
  - Function to dump VPDMA registers.
  
  - A function to initialize VPDMA, this will be called by the VPE driver
  with it's platform device pointer, this function will take care of
  loading VPDMA firmware and returning a handle back to the VPE driver.
  The VIP driver will also call the same init function to initialize it's
  own VPDMA instance.
  
  Signed-off-by: Archit Taneja arc...@ti.com

[snip]

  +/*
  + * Allocate a DMA buffer
  + */
  +int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
  +{
  +  buf-size = size;
  +  buf-mapped = 0;
  +  buf-addr = kzalloc(size, GFP_KERNEL);
  
  You should use the dma allocation API (depending on your needs,
  dma_alloc_coherent for instance) to allocate DMA-able buffers.
 
 I'm not sure about this, dma_map_single() api works fine on kzalloc'd
 buffers. The above function is used to allocate small contiguous buffers
 (never more than 1024 bytes) needed for descriptors for the DMA IP. I
 thought of using DMA pool, but that creates small buffers of the same size.
 So I finally went with kzalloc.

OK, I mistakenly thought it would allocate larger buffers as well. If it's 
used to allocate descriptors only, would it be better to rename it to 
vpdma_desc_alloc() (or something similar) ?

  +  if (!buf-addr)
  +  return -ENOMEM;
  +
  +  WARN_ON((u32) buf-addr  VPDMA_DESC_ALIGN);
  +
  +  return 0;
  +}

[snip]

  +static int vpdma_load_firmware(struct vpdma_data *vpdma)
  +{
  +  int r;
  +  struct device *dev = vpdma-pdev-dev;
  +
  +  r = request_firmware_nowait(THIS_MODULE, 1,
  +  (const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
  +  vpdma_firmware_cb);
  
  Is there a reason not to use the synchronous interface ? That would
  simplify both this code and the callers, as they won't have to check
  whether the firmware has been correctly loaded.
 
 I'm not clear what you mean by that, the firmware would be stored in the
 filesystem. If the driver is built-in, then the synchronous interface
 wouldn't work unless the firmware is appended to the kernel image. Am I
 missing something here? I'm not very aware of the firmware api.

request_firmware() would just sleep (with a 30 seconds timeout if I'm not 
mistaken) 

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

[Felipe Balbi]

Hi,

On Mon, Aug 19, 2013 at 10:58:09AM +0530, Kishon Vijay Abraham I wrote:
  So maybe let's stop solving an already solved problem and just state that 
  you need to explicitly assign device ID to use this framework?
  
  Felipe,
  Can we have it the way I had in my v10 patch series till we find a better 
  way?
  I think this *non-dt* stuff shouldn't be blocking as most of the users are 
  dt only?

I don't have a lot of things against it, but preventing driver authors
to use PLATFORM_DEVID_AUTO just to use the framework is likely going to
piss some people off.

Perhaps we can start with this approach and fix things later ? At least
it ungates all the PHY drivers which are depending on this framework
(quite a few already). If everybody agrees with this approach, I'd be ok
with it too.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Felipe Balbi]

Hi,

On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
 From: Ivan T. Ivanov iiva...@mm-sol.com
 
 These drivers handles control and configuration of the HS
 and SS USB PHY transceivers. They are part of the driver
 which manage Synopsys DesignWare USB3 controller stack
 inside Qualcomm SoC's.
 
 Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
 ---
  drivers/usb/phy/Kconfig   |   11 ++
  drivers/usb/phy/Makefile  |2 +
  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
 +

please rename these PHY drivers, they have nothing to do with DWC3. PHYs
don't care about the USB controller.

-- 
balbi


signature.asc
Description: Digital signature

Re: [GIT PULL] omap fixes against v3.11-rc5

[Tony Lindgren]

* Olof Johansson o...@lixom.net [130816 15:05]:
 
 Our current fixes branch is based on -rc4, and I didn't see any of
 these commits in linux-next, so I took the liberty to rebase them back
 onto our current branch.
 
 I.e. pulled, but rebased.

Thanks no problem at my end. But to avoid future confusion, what's
the reasoning for rebasing? AFAIK, pulling this in would have just
automatically updated your branch to -rc5, no?

The only time where pulling in a branch based on a later mainline
commit would cause problems is if your branch is based on another
series of patches you want to send separately as then you'd get
all the commits between -rc4 and -rc5 when doing the pull request.

Probably nothing new in this for your, but FYI, you can use pulling
or merging branches as a way of updating your publick branches without
rebasing or adding extra merge commits while keeping the branch
pullable.

Let's assume you have arm-soc/fixes based on -rc4, and -rc5
comes out:

$ git checkout -b my-fixes-of-the-week v3.11-rc5
# apply pending patches
...
$ git checkout arm-soc/fixes
$ git merge my-fixes-of-the-week

And then you have essentially fast forwarded your arm-soc/fixes to
-rc5 and it stays pullable ;)

Regards,

Tony
--
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/6] v4l: ti-vpe: Create a vpdma helper library

[Archit Taneja]

On Tuesday 20 August 2013 05:09 PM, Laurent Pinchart wrote:

Hi Archit,

On Wednesday 14 August 2013 16:27:57 Archit Taneja wrote:

On Friday 09 August 2013 03:34 AM, Laurent Pinchart wrote:

On Friday 02 August 2013 19:33:38 Archit Taneja wrote:

The primary function of VPDMA is to move data between external memory and
internal processing modules(in our case, VPE) that source or sink data.
VPDMA is capable of buffering this data and then delivering the data as
demanded to the modules as programmed. The modules that source or sink
data are referred to as clients or ports. A channel is setup inside the
VPDMA to connect a specific memory buffer to a specific client. The VPDMA
centralizes the DMA control functions and buffering required to allow all
the clients to minimize the effect of long latency times.

Add the following to the VPDMA helper:

- A data struct which describe VPDMA channels. For now, these channels
are the ones used only by VPE, the list of channels will increase when
VIP(Video Input Port) also uses the VPDMA library. This channel
information will be used to populate fields required by data descriptors.

- Data structs which describe the different data types supported by
VPDMA. This data type information will be used to populate fields
required by data descriptors and used by the VPE driver to map a V4L2
format to the corresponding VPDMA data type.

- Provide VPDMA register offset definitions, functions to read, write and
modify VPDMA registers.

- Functions to create and submit a VPDMA list. A list is a group of
descriptors that makes up a set of DMA transfers that need to be
completed. Each descriptor will either perform a DMA transaction to fetch
input buffers and write to output buffers(data descriptors), or configure
the MMRs of sub blocks of VPE(configuration descriptors), or provide
control information to VPDMA (control descriptors).

- Functions to allocate, map and unmap buffers needed for the descriptor
list, payloads containing MMR values and motion vector buffers. These use
the DMA mapping APIs to ensure exclusive access to VPDMA.

- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on
the VPE interrupt line when a descriptor list is parsed completely and
the DMA transactions are completed. This requires masking the events in
VPDMA registers and configuring some top level VPE interrupt registers.

- Enable some VPDMA specific parameters: frame start event(when to start
DMA for a client) and line mode(whether each line fetched should be
mirrored or not).

- Function to load firmware required by VPDMA. VPDMA requires a firmware
for it's internal list manager. We add the required request_firmware
apis to fetch this firmware from user space.

- Function to dump VPDMA registers.

- A function to initialize VPDMA, this will be called by the VPE driver
with it's platform device pointer, this function will take care of
loading VPDMA firmware and returning a handle back to the VPE driver.
The VIP driver will also call the same init function to initialize it's
own VPDMA instance.

Signed-off-by: Archit Taneja arc...@ti.com


[snip]


+/*
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+   buf-size = size;
+   buf-mapped = 0;
+   buf-addr = kzalloc(size, GFP_KERNEL);


You should use the dma allocation API (depending on your needs,
dma_alloc_coherent for instance) to allocate DMA-able buffers.


I'm not sure about this, dma_map_single() api works fine on kzalloc'd
buffers. The above function is used to allocate small contiguous buffers
(never more than 1024 bytes) needed for descriptors for the DMA IP. I
thought of using DMA pool, but that creates small buffers of the same size.
So I finally went with kzalloc.


OK, I mistakenly thought it would allocate larger buffers as well. If it's
used to allocate descriptors only, would it be better to rename it to
vpdma_desc_alloc() (or something similar) ?


Actually, I just thought about this again. We use this api to allocate a 
motion vector buffer for the de-interlacer, that's a buffer which is 
proportional to the size of the frame, it takes up 4 bits per pixel. So 
for a 1080i frame(our limit), it would take around 51 kilobytes for it. 
I should probably use dma_alloc_coherent there.





+   if (!buf-addr)
+   return -ENOMEM;
+
+   WARN_ON((u32) buf-addr  VPDMA_DESC_ALIGN);
+
+   return 0;
+}


[snip]


+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+   int r;
+   struct device *dev = vpdma-pdev-dev;
+
+   r = request_firmware_nowait(THIS_MODULE, 1,
+   (const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+   vpdma_firmware_cb);


Is there a reason not to use the synchronous interface ? That would
simplify both this code and the callers, as they won't have to check
whether the firmware has been correctly loaded.


I'm not clear what you mean by that, the firmware would be stored in the

Re: [PATCH v2 04/14] crypto: omap-aes: Simplify DMA usage by using direct SGs

[Lokesh Vutla]

Hi Joel,

On Sunday 18 August 2013 08:12 AM, Joel Fernandes wrote:
 In early version of this driver, assumptions were made such as DMA layer
 requires contiguous buffers etc. Due to this, new buffers were allocated,
 mapped and used for DMA. These assumptions are no longer true and DMAEngine
 scatter-gather DMA doesn't have such requirements. We simply the DMA 
 operations
 by directly using the scatter-gather buffers provided by the crypto layer
 instead of creating our own.
 
 Lot of logic that handled DMA'ing only X number of bytes of the total, or as
 much as fitted into a 3rd party buffer is removed and is no longer required.
 
 Also, good performance improvement of atleast ~20% seen with encrypting a
 buffer size of 8K (1800 ops/sec vs 1400 ops/sec).  Improvement will be higher
 for much larger blocks though such benchmarking is left as an exercise for the
 reader.  Also DMA usage is much more simplified and coherent with rest of the
 code.
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  drivers/crypto/omap-aes.c |  147 
 -
  1 file changed, 25 insertions(+), 122 deletions(-)
 
 diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
 index e369e6e..64dd5c1 100644
 --- a/drivers/crypto/omap-aes.c
 +++ b/drivers/crypto/omap-aes.c
 @@ -480,22 +480,14 @@ static int sg_copy(struct scatterlist **sg, size_t 
 *offset, void *buf,
  }
  
  static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
 - struct scatterlist *in_sg, struct scatterlist *out_sg)
 + struct scatterlist *in_sg, struct scatterlist *out_sg,
 + int in_sg_len, int out_sg_len)
  {
   struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
   struct omap_aes_dev *dd = ctx-dd;
   struct dma_async_tx_descriptor *tx_in, *tx_out;
   struct dma_slave_config cfg;
 - dma_addr_t dma_addr_in = sg_dma_address(in_sg);
 - int ret, length = sg_dma_len(in_sg);
 -
 - pr_debug(len: %d\n, length);
 -
 - dd-dma_size = length;
 -
 - if (!(dd-flags  FLAGS_FAST))
 - dma_sync_single_for_device(dd-dev, dma_addr_in, length,
 -DMA_TO_DEVICE);
 + int ret;
By this change FLAGS_FAST is unsed, it can be cleaned right?
or Am I missing something?

Thanks and regards,
Lokesh
  
   memset(cfg, 0, sizeof(cfg));
  
 @@ -514,7 +506,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
   return ret;
   }
  
 - tx_in = dmaengine_prep_slave_sg(dd-dma_lch_in, in_sg, 1,
 + tx_in = dmaengine_prep_slave_sg(dd-dma_lch_in, in_sg, in_sg_len,
   DMA_MEM_TO_DEV,
   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
   if (!tx_in) {
 @@ -533,7 +525,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
   return ret;
   }
  
 - tx_out = dmaengine_prep_slave_sg(dd-dma_lch_out, out_sg, 1,
 + tx_out = dmaengine_prep_slave_sg(dd-dma_lch_out, out_sg, out_sg_len,
   DMA_DEV_TO_MEM,
   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
   if (!tx_out) {
 @@ -551,7 +543,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
   dma_async_issue_pending(dd-dma_lch_out);
  
   /* start DMA */
 - dd-pdata-trigger(dd, length);
 + dd-pdata-trigger(dd, dd-total);
  
   return 0;
  }
 @@ -560,93 +552,28 @@ static int omap_aes_crypt_dma_start(struct omap_aes_dev 
 *dd)
  {
   struct crypto_tfm *tfm = crypto_ablkcipher_tfm(
   crypto_ablkcipher_reqtfm(dd-req));
 - int err, fast = 0, in, out;
 - size_t count;
 - dma_addr_t addr_in, addr_out;
 - struct scatterlist *in_sg, *out_sg;
 - int len32;
 + int err;
  
   pr_debug(total: %d\n, dd-total);
  
 - if (sg_is_last(dd-in_sg)  sg_is_last(dd-out_sg)) {
 - /* check for alignment */
 - in = IS_ALIGNED((u32)dd-in_sg-offset, sizeof(u32));
 - out = IS_ALIGNED((u32)dd-out_sg-offset, sizeof(u32));
 -
 - fast = in  out;
 + err = dma_map_sg(dd-dev, dd-in_sg, dd-in_sg_len, DMA_TO_DEVICE);
 + if (!err) {
 + dev_err(dd-dev, dma_map_sg() error\n);
 + return -EINVAL;
   }
  
 - if (fast)  {
 - count = min(dd-total, sg_dma_len(dd-in_sg));
 - count = min(count, sg_dma_len(dd-out_sg));
 -
 - if (count != dd-total) {
 - pr_err(request length != buffer length\n);
 - return -EINVAL;
 - }
 -
 - pr_debug(fast\n);
 -
 - err = dma_map_sg(dd-dev, dd-in_sg, 1, DMA_TO_DEVICE);
 - if (!err) {
 - dev_err(dd-dev, dma_map_sg() error\n);
 - return -EINVAL;
 - }
 -
 - err = dma_map_sg(dd-dev, dd-out_sg, 1, DMA_FROM_DEVICE);
 - if (!err) {
 - 

[PATCHv10] drivers: spi: Add qspi flash controller

[Sourav Poddar]

The patch add basic support for the quad spi controller.

QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.

The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).

Test details:
-
Tested this on dra7 board.
Test1: Ran mtd_stesstest for 4 iterations.
   - All iterations went through without failure.
Test2: Use mtd utilities:
  - flash_erase to erase the flash device
  - mtd_debug read to read data back.
  - mtd_debug write to write to the data flash.
 diff between the write and read data shows zero.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v9-v10:
- Few miscellaneous cleanup
- Add switch instead of ifelse.

Left 3 warnings(80 characters) for better readibilty of code.
These was posted till now as a two patch series.
Dropping the 2nd patch as of now, will add once the support
for multiple data lines are added in SPI framework(the patch is
under review).
 Documentation/devicetree/bindings/spi/ti_qspi.txt |   22 +
 drivers/spi/Kconfig   |8 +
 drivers/spi/Makefile  |1 +
 drivers/spi/spi-ti-qspi.c |  561 +
 4 files changed, 592 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
 create mode 100644 drivers/spi/spi-ti-qspi.c

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
new file mode 100644
index 000..398ef59
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -0,0 +1,22 @@
+TI QSPI controller.
+
+Required properties:
+- compatible : should be ti,dra7xxx-qspi.
+- reg: Should contain QSPI registers location and length.
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ti,hwmods: Name of the hwmod associated to the QSPI
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+qspi: qspi@4b30 {
+   compatible = ti,dra7xxx-qspi;
+   reg = 0x4b30 0x100;
+   #address-cells = 1;
+   #size-cells = 0;
+   spi-max-frequency = 2500;
+   ti,hwmods = qspi;
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92a9345..1c4e758 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,14 @@ config SPI_OMAP24XX
  SPI master controller for OMAP24XX and later Multichannel SPI
  (McSPI) modules.
 
+config SPI_TI_QSPI
+   tristate DRA7xxx QSPI controller support
+   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   help
+ QSPI master controller for DRA7xxx used for flash devices.
+ This device supports single, dual and quad read support, while
+ it only supports single write mode.
+
 config SPI_OMAP_100K
tristate OMAP SPI 100K
depends on ARCH_OMAP850 || ARCH_OMAP730
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..a174030 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON)  += spi-octeon.o
 obj-$(CONFIG_SPI_OMAP_UWIRE)   += spi-omap-uwire.o
 obj-$(CONFIG_SPI_OMAP_100K)+= spi-omap-100k.o
 obj-$(CONFIG_SPI_OMAP24XX) += spi-omap2-mcspi.o
+obj-$(CONFIG_SPI_TI_QSPI)  += spi-ti-qspi.o
 obj-$(CONFIG_SPI_ORION)+= spi-orion.o
 obj-$(CONFIG_SPI_PL022)+= spi-pl022.o
 obj-$(CONFIG_SPI_PPC4xx)   += spi-ppc4xx.o
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..795cf02
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
@@ -0,0 +1,561 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Sourav Poddar sourav.pod...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GPLv2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include 

Re: [PATCHv10] drivers: spi: Add qspi flash controller

[Felipe Balbi]

Hi,

On Tue, Aug 20, 2013 at 06:35:25PM +0530, Sourav Poddar wrote:
 +static int qspi_transfer_msg(struct ti_qspi *qspi, struct spi_transfer *t)
 +{
 + int ret;
 +
 + if (t-tx_buf) {
 + ret = qspi_write_msg(qspi, t);
 + if (ret) {
 + dev_dbg(qspi-dev, Error while writing\n);
 + return ret;
 + }
 + }
 +
 + if (t-rx_buf) {
 + ret = qspi_read_msg(qspi, t);
 + if (ret) {
 + dev_dbg(qspi-dev, Error while writing\n);

*READING*

other than that:

Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library

[Archit Taneja]

Hi Laurent,

On Tuesday 20 August 2013 05:09 PM, Laurent Pinchart wrote:

snip


+static int vpdma_load_firmware(struct vpdma_data *vpdma)
+{
+   int r;
+   struct device *dev = vpdma-pdev-dev;
+
+   r = request_firmware_nowait(THIS_MODULE, 1,
+   (const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
+   vpdma_firmware_cb);


Is there a reason not to use the synchronous interface ? That would
simplify both this code and the callers, as they won't have to check
whether the firmware has been correctly loaded.


I'm not clear what you mean by that, the firmware would be stored in the
filesystem. If the driver is built-in, then the synchronous interface
wouldn't work unless the firmware is appended to the kernel image. Am I
missing something here? I'm not very aware of the firmware api.


request_firmware() would just sleep (with a 30 seconds timeout if I'm not
mistaken) until userspace provides the firmware. As devices are probed
asynchronously (in kernel threads) the system will just boot normally, and the
request_firmware() call will return when the firmware is available.


Sorry, I sent the previous mail bit too early.

With request_firmware() and the driver built-in, I see that the kernel 
stalls for 10 seconds at the driver's probe, and the firware loading 
fails since we didn't enter userspace where the file is.


The probing of devices asynchronously with kernel threads makes sense, 
so it's possible that I'm doing something wrong here. I'll give it a try 
again


Archit

--
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: [PATCHv10] drivers: spi: Add qspi flash controller

[Sourav Poddar]

On Tuesday 20 August 2013 06:44 PM, Felipe Balbi wrote:

Hi,

On Tue, Aug 20, 2013 at 06:35:25PM +0530, Sourav Poddar wrote:

+static int qspi_transfer_msg(struct ti_qspi *qspi, struct spi_transfer *t)
+{
+   int ret;
+
+   if (t-tx_buf) {
+   ret = qspi_write_msg(qspi, t);
+   if (ret) {
+   dev_dbg(qspi-dev, Error while writing\n);
+   return ret;
+   }
+   }
+
+   if (t-rx_buf) {
+   ret = qspi_read_msg(qspi, t);
+   if (ret) {
+   dev_dbg(qspi-dev, Error while writing\n);

*READING*


hmm..got missed while folding local changes:(.
Will submit an updated patch.

other than that:

Acked-by: Felipe Balbiba...@ti.com
Reviewed-by: Felipe Balbiba...@ti.com


Thanks!

--
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/4] mtd:nand:omap2: clean-up of supported ECC schemes

[Gupta, Pekon]

Hi Artem, Brian,

 
 Changes v4 - v5
 - Rebased to linux-next
 IMPORTANT: Need to revert commit fb1585b, [PATCH 2/4] part of previous
 version
   http://lists.infradead.org/pipermail/linux-mtd/2013-July/047441.html
 
 - Swapped PATCH-1  PATCH-2 to maintain bisectibility  compilation
 dependency
   http://lists.infradead.org/pipermail/linux-mtd/2013-July/047461.html
 
 - PATCH-2: re-ordered call to is_elm_present() for later updates ELM driver
   - dropped changes in include/linux/platform_data/elm.h (not
 needed)
 - PATCH-3: re-ordered call to is_elm_present() for later updates ELM driver
 - Re-formated patch description (replaced tabs with white-spaces)
 
 
 Changes v3 - v4
 (Resent with CC: devicetree-disc...@lists.ozlabs.org)
 - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 
 MTD_NAND_OMAP_BCH4 from nand/Kconfig
   ECC scheme selectable via nand DT (nand-ecc-opt).
 - [*] rebased for l2-mtd.git
 
 
 Changes v2 - v3
 (Resent with Author Name fixed)
 - PATCH-1: re-arranged code to remove redundancy, added
 NAND_BUSWIDTH_AUTO
 - PATCH-2: updated nand-ecc-opt DT mapping and Documentation
 - PATCH-3: code-cleaning + changes to match PATCH-1
 - PATCH-4 DROPPED update DT attribute for ti,nand-ecc-opt
   - received feedback to keep DT mapping independent of linuxism
 - PATCH-4:NEW : ARM: dts: AM33xx: updated default ECC scheme in nand-
 ecc-opt
   - independent patch for AM335x-evm.dts update based on PATCH-2
 
 
 Changes v1 - v2
   added   [PATCH 3/4] and [PATCH 4/4]
 
 
 Patches in this series:
 [PATCH 1/4]-[PATCH v5 2/4]: clean-up and optimization for supported ECC
 schemes.
 [PATCH 2/4]-[PATCH v5 1/4]: add separate DT options each supported ECC
 scheme.
 [PATCH 3/4]: update BCH4 ECC implementation (using ELM or using lib/bch.h)
 [PATCH 4/4]: ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-
 opt
 
 After this patch series, omap2-nand driver will supports following ECC
 schemes:
 +---+---+---+
 | ECC scheme|ECC calculation|Error detection|
 +---+---+---+
 |OMAP_ECC_HAMMING_CODE_DEFAULT  |S/W|S/W|
 |OMAP_ECC_HAMMING_CODE_HW   |H/W (GPMC) |S/W|
 |OMAP_ECC_HAMMING_CODE_HW_ROMCODE   |H/W (GPMC) |S/W
 |
 +---+---+---+
 |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W
 (lib/bch.h)|
 |OMAP_ECC_BCH4_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
 +---+---+---+
 |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W
 (lib/bch.h)|
 |OMAP_ECC_BCH8_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
 +---+---+---+
 - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
   Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH
 ECC algorithm.
 
 - Selection of OMAP_ECC_BCHx_CODE_HW requires,
   Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W
 module.
 

Request to please pick-up this patch series, as following two more
patch series queued up depending on this.

http://lists.infradead.org/pipermail/linux-mtd/2013-July/047538.html

http://lists.infradead.org/pipermail/linux-mtd/2013-July/047562.html


with regards, pekon

Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[George Cherian]

On 8/20/2013 3:59 PM, Chanwoo Choi wrote:

Hi George,


diff --git a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt 
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
new file mode 100644
index 000..37e4c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
@@ -0,0 +1,19 @@
+EXTCON FOR DRA7xx
+
+Required Properties:
+ - compatible : Should be ti,dra7xx-usb
+ - gpios : phandle to ID pin and interrupt gpio.
+
+Optional Properties:
+  - interrupt-parent : interrupt controller phandle
+  - interrupts : interrupt number
+
+
+dra7x_extcon1 {

You used 'dra7xx-usb' device name. Why did you use 'dra7x_extcon1' name?
What is meaning 'dra7x_extcon1'?

I will rename it to  dra7xx_extcon.

extcon naming means various external connector device. e.g., usb, jack, etc...
So, I prefer 'dra7xx_usb' instead of 'dra7xx_extcon'. I have plan to divide
extcon device driver according to the kind of device.


okay will do it in v2




+static int id_poll_func(void *data)
+{
+struct dra7xx_usb *dra7xx_usb = (struct dra7xx_usb *) data;
+
+allow_signal(SIGINT);
+allow_signal(SIGTERM);
+allow_signal(SIGKILL);
+allow_signal(SIGUSR1);
+
+set_freezable();
+
+while (!kthread_should_stop()) {
+dra7xx_usb-id_current = gpio_get_value_cansleep
+(dra7xx_usb-id_gpio);
+if (dra7xx_usb-id_current == dra7xx_usb-id_prev) {
+schedule_timeout_interruptible
+(msecs_to_jiffies(2*1000));
+continue;
+} else if (dra7xx_usb-id_current == 0) {
+extcon_set_cable_state(dra7xx_usb-edev, USB, false);
+extcon_set_cable_state(dra7xx_usb-edev,
+USB-HOST, true);
+} else {
+extcon_set_cable_state(dra7xx_usb-edev,
+USB-HOST, false);
+extcon_set_cable_state(dra7xx_usb-edev, USB, true);
+}

Should dra7xx_usb keep always connected state with either USB or USB-HOST cable?
I don't understand. So please explain detailed operation method of dra7xx_usb 
device.

In dra7xx only ID pin is connected to the SoC gpio. There is no way, currently 
to detect the VBUS on/off.
So I always default to either HOST/DEVICE mode solely depending on the ID pin 
value.

OK.

But I don't want to use kthread with polling method.
I recommend that you use interrupt method for cable detection.
All of extcon device driver have only used interrupt method without polling.


okay will remove the polling thread.



+dra7xx_usb-id_prev = dra7xx_usb-id_current;
+}
+
+return 0;
+}
+
+static irqreturn_t id_irq_handler(int irq, void *data)
+{
+struct dra7xx_usb *dra7xx_usb = (struct dra7xx_usb *) data;
+
+dra7xx_usb-id_current = gpio_get_value_cansleep(dra7xx_usb-id_gpio);
+
+if (dra7xx_usb-id_current == dra7xx_usb-id_prev) {
+return IRQ_NONE;
+} else if (dra7xx_usb-id_current == 0) {

You should define some constant variable to clarify '0' meaning instead of 
using '0' directly.


okay



+dra7xx_usb = devm_kzalloc(pdev-dev, sizeof(*dra7xx_usb), GFP_KERNEL);
+if (!dra7xx_usb)
+return -ENOMEM;

You have to add error message with dev_err().

devm_kzalloc itself should give some message.

ok.



+status = extcon_dev_register(dra7xx_usb-edev, dra7xx_usb-dev);
+if (status) {
+dev_err(pdev-dev, failed to register extcon device\n);
+return status;

You should restore previous operation about dra7xx_usb-irq_gpio.

okay

+}
+
+dra7xx_usb-id_prev = gpio_get_value_cansleep(dra7xx_usb-id_gpio);
+if (dra7xx_usb-id_prev) {

ditto.
You should define some constant variable to clarify 'dra7xx_usb-id_prev' 
meaning.


okay



+extcon_set_cable_state(dra7xx_usb-edev, USB-HOST, false);
+extcon_set_cable_state(dra7xx_usb-edev, USB, true);
+} else {
+extcon_set_cable_state(dra7xx_usb-edev, USB, false);
+extcon_set_cable_state(dra7xx_usb-edev, USB-HOST, true);
+}

why did you do keep always connected state?

There is no way, currently to detect the VBUS on/off.
So I always default to either HOST/DEVICE mode solely depending on the ID pin 
value.


+
+if (dra7xx_usb-irq_gpio) {
+status = devm_request_threaded_irq(dra7xx_usb-dev, irq_num,
+NULL, id_irq_handler, IRQF_SHARED |
+IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
+dev_name(pdev-dev), (void *) dra7xx_usb);
+if (status)
+dev_err(dra7xx_usb-dev, failed to request irq #%d\n,
+irq_num);

If devm_request_threaded_irq() return fail state, why did not you do add error 
exception?

If interrupt fails I fallback to polling thread.

+else
+return 0;

If devm_request_threaded_irq() return success state, why did you directly call 
'return'?
kthread_create operation isn't necessary?

Yes kthread is optional. Some boards doenot have the ID pin hooked onto 

Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Ivan T. Ivanov]

Hi,

On Tue, 2013-08-20 at 07:29 -0500, Felipe Balbi wrote: 
 Hi,
 
 On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
  From: Ivan T. Ivanov iiva...@mm-sol.com
  
  These drivers handles control and configuration of the HS
  and SS USB PHY transceivers. They are part of the driver
  which manage Synopsys DesignWare USB3 controller stack
  inside Qualcomm SoC's.
  
  Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
  ---
   drivers/usb/phy/Kconfig   |   11 ++
   drivers/usb/phy/Makefile  |2 +
   drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
   drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
  +
 
 please rename these PHY drivers, they have nothing to do with DWC3. PHYs
 don't care about the USB controller.

I think they are SNPS DesignWare PHY's, additionally
wrapped with Qualcomm logic. I could substitute dwc3
with just dw, which will be more correct.

Regards,
Ivan


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

[PATCHv11] drivers: spi: Add qspi flash controller

[Sourav Poddar]

The patch add basic support for the quad spi controller.

QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.

The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).

Test details:
-
Tested this on dra7 board.
Test1: Ran mtd_stesstest for 4 iterations.
   - All iterations went through without failure.
Test2: Use mtd utilities:
  - flash_erase to erase the flash device
  - mtd_debug read to read data back.
  - mtd_debug write to write to the data flash.
 diff between the write and read data shows zero.

Acked-by: Felipe Balbiba...@ti.com
Reviewed-by: Felipe Balbiba...@ti.com 
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v10-v11:
- Fix a typo
Left 3 warnings(80 characters) for better readibilty of code.
These was posted till now as a two patch series.
Dropping the 2nd patch as of now, will add once the support
for multiple data lines are added in SPI framework(the patch is
under review).

 Documentation/devicetree/bindings/spi/ti_qspi.txt |   22 +
 drivers/spi/Kconfig   |8 +
 drivers/spi/Makefile  |1 +
 drivers/spi/spi-ti-qspi.c |  561 +
 4 files changed, 592 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
 create mode 100644 drivers/spi/spi-ti-qspi.c

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
new file mode 100644
index 000..398ef59
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -0,0 +1,22 @@
+TI QSPI controller.
+
+Required properties:
+- compatible : should be ti,dra7xxx-qspi.
+- reg: Should contain QSPI registers location and length.
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ti,hwmods: Name of the hwmod associated to the QSPI
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+qspi: qspi@4b30 {
+   compatible = ti,dra7xxx-qspi;
+   reg = 0x4b30 0x100;
+   #address-cells = 1;
+   #size-cells = 0;
+   spi-max-frequency = 2500;
+   ti,hwmods = qspi;
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92a9345..1c4e758 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,14 @@ config SPI_OMAP24XX
  SPI master controller for OMAP24XX and later Multichannel SPI
  (McSPI) modules.
 
+config SPI_TI_QSPI
+   tristate DRA7xxx QSPI controller support
+   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   help
+ QSPI master controller for DRA7xxx used for flash devices.
+ This device supports single, dual and quad read support, while
+ it only supports single write mode.
+
 config SPI_OMAP_100K
tristate OMAP SPI 100K
depends on ARCH_OMAP850 || ARCH_OMAP730
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..a174030 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON)  += spi-octeon.o
 obj-$(CONFIG_SPI_OMAP_UWIRE)   += spi-omap-uwire.o
 obj-$(CONFIG_SPI_OMAP_100K)+= spi-omap-100k.o
 obj-$(CONFIG_SPI_OMAP24XX) += spi-omap2-mcspi.o
+obj-$(CONFIG_SPI_TI_QSPI)  += spi-ti-qspi.o
 obj-$(CONFIG_SPI_ORION)+= spi-orion.o
 obj-$(CONFIG_SPI_PL022)+= spi-pl022.o
 obj-$(CONFIG_SPI_PPC4xx)   += spi-ppc4xx.o
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..09e2415
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
@@ -0,0 +1,561 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Sourav Poddar sourav.pod...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GPLv2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include 

Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Felipe Balbi]

Hi,

On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
  On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
   From: Ivan T. Ivanov iiva...@mm-sol.com
   
   These drivers handles control and configuration of the HS
   and SS USB PHY transceivers. They are part of the driver
   which manage Synopsys DesignWare USB3 controller stack
   inside Qualcomm SoC's.
   
   Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
   ---
drivers/usb/phy/Kconfig   |   11 ++
drivers/usb/phy/Makefile  |2 +
drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
   +
  
  please rename these PHY drivers, they have nothing to do with DWC3. PHYs
  don't care about the USB controller.
 
 I think they are SNPS DesignWare PHY's, additionally
 wrapped with Qualcomm logic. I could substitute dwc3
 with just dw, which will be more correct.

alright, thank you. Let's add Paul to the loop since he might have very
good insight in the synopsys PHYs.

mental note: if any other platform shows up with Synopsys PHY, ask them
to use this driver instead :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library

[Laurent Pinchart]

Hi Archit,

On Tuesday 20 August 2013 18:46:38 Archit Taneja wrote:
 On Tuesday 20 August 2013 05:09 PM, Laurent Pinchart wrote:
 
 snip
 
  +static int vpdma_load_firmware(struct vpdma_data *vpdma)
  +{
  +int r;
  +struct device *dev = vpdma-pdev-dev;
  +
  +r = request_firmware_nowait(THIS_MODULE, 1,
  +(const char *) VPDMA_FIRMWARE, dev, GFP_KERNEL, vpdma,
  +vpdma_firmware_cb);
  
  Is there a reason not to use the synchronous interface ? That would
  simplify both this code and the callers, as they won't have to check
  whether the firmware has been correctly loaded.
  
  I'm not clear what you mean by that, the firmware would be stored in the
  filesystem. If the driver is built-in, then the synchronous interface
  wouldn't work unless the firmware is appended to the kernel image. Am I
  missing something here? I'm not very aware of the firmware api.
  
  request_firmware() would just sleep (with a 30 seconds timeout if I'm not
  mistaken) until userspace provides the firmware. As devices are probed
  asynchronously (in kernel threads) the system will just boot normally, and
  the request_firmware() call will return when the firmware is available.

 Sorry, I sent the previous mail bit too early.
 
 With request_firmware() and the driver built-in, I see that the kernel
 stalls for 10 seconds at the driver's probe, and the firware loading fails
 since we didn't enter userspace where the file is.
 
 The probing of devices asynchronously with kernel threads makes sense, so
 it's possible that I'm doing something wrong here. I'll give it a try again

I might have spoken too fast. It looks like module initcalls are not run in 
threads. I've most probably mistaken that with asynchronous probing of hot-
pluggable devices.

If your driver is built-in then it looks like the correct solution is to build 
the firmware in the kernel image as well, or use the asynchronous API as you 
did.

-- 
Regards,

Laurent Pinchart

--
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/4] mtd:nand:omap2: clean-up of supported ECC schemes

[Artem Bityutskiy]

On Tue, 2013-08-20 at 13:20 +, Gupta, Pekon wrote:
 Hi Artem, Brian,

I'll try to go through old e-mails now, and especially ubi/ubifs ones,
including yours, and I'll let Brian handle your patches, if I can? :-)

I checked them, and they looked good to me:

Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com

-- 
Best Regards,
Artem Bityutskiy

--
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/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Ivan T. Ivanov]

Hi,

On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
 Hi,
 
 On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
   On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com

These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
 drivers/usb/phy/Kconfig   |   11 ++
 drivers/usb/phy/Makefile  |2 +
 drivers/usb/phy/phy-msm-dwc3-hs.c |  327 

 drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
+
   
   please rename these PHY drivers, they have nothing to do with DWC3. PHYs
   don't care about the USB controller.
  
  I think they are SNPS DesignWare PHY's, additionally
  wrapped with Qualcomm logic. I could substitute dwc3
  with just dw, which will be more correct.
 
 alright, thank you. Let's add Paul to the loop since he might have very
 good insight in the synopsys PHYs.
 
 mental note: if any other platform shows up with Synopsys PHY, ask them
 to use this driver instead :-)

I really doubt that this will bi possible. Control of the PHY's is
not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
QSCRATCH registers, which of course is highly Qualcomm specific.

Regards,
Ivan


--
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/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Felipe Balbi]

On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
 Hi,
 
 On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
  Hi,
  
  On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
 From: Ivan T. Ivanov iiva...@mm-sol.com
 
 These drivers handles control and configuration of the HS
 and SS USB PHY transceivers. They are part of the driver
 which manage Synopsys DesignWare USB3 controller stack
 inside Qualcomm SoC's.
 
 Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
 ---
  drivers/usb/phy/Kconfig   |   11 ++
  drivers/usb/phy/Makefile  |2 +
  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
 
  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
 +

please rename these PHY drivers, they have nothing to do with DWC3. PHYs
don't care about the USB controller.
   
   I think they are SNPS DesignWare PHY's, additionally
   wrapped with Qualcomm logic. I could substitute dwc3
   with just dw, which will be more correct.
  
  alright, thank you. Let's add Paul to the loop since he might have very
  good insight in the synopsys PHYs.
  
  mental note: if any other platform shows up with Synopsys PHY, ask them
  to use this driver instead :-)
 
 I really doubt that this will bi possible. Control of the PHY's is
 not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
 QSCRATCH registers, which of course is highly Qualcomm specific.

isn't it a memory mapped IP ? doesn't synopsys provide their own set of
registers ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Ivan T. Ivanov]

Hi, 

On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
 On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
  Hi,
  
  On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
   Hi,
   
   On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
 On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
  From: Ivan T. Ivanov iiva...@mm-sol.com
  
  These drivers handles control and configuration of the HS
  and SS USB PHY transceivers. They are part of the driver
  which manage Synopsys DesignWare USB3 controller stack
  inside Qualcomm SoC's.
  
  Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
  ---
   drivers/usb/phy/Kconfig   |   11 ++
   drivers/usb/phy/Makefile  |2 +
   drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
  
   drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
  +
 
 please rename these PHY drivers, they have nothing to do with DWC3. 
 PHYs
 don't care about the USB controller.

I think they are SNPS DesignWare PHY's, additionally
wrapped with Qualcomm logic. I could substitute dwc3
with just dw, which will be more correct.
   
   alright, thank you. Let's add Paul to the loop since he might have very
   good insight in the synopsys PHYs.
   
   mental note: if any other platform shows up with Synopsys PHY, ask them
   to use this driver instead :-)
  
  I really doubt that this will bi possible. Control of the PHY's is
  not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
  QSCRATCH registers, which of course is highly Qualcomm specific.
 
 isn't it a memory mapped IP ? doesn't synopsys provide their own set of
 registers ?

From what I see it is not directly mapped. How QSCRATCH write and
reads transactions are translated to DW IP is unclear to me.

Ivan




--
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/8] usb: phy: omap-control: Get rid of platform data

[Roger Quadros]

omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/phy/phy-omap-control.c   |   18 +++---
 include/linux/usb/omap_control_usb.h |4 
 2 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-control.c 
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..7f446c4 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,13 @@ static int omap_control_usb_probe(struct platform_device 
*pdev)
 {
struct resource *res;
struct device_node *np = pdev-dev.of_node;
-   struct omap_control_usb_platform_data *pdata =
-   dev_get_platdata(pdev-dev);
+
+   if (np) {
+   of_property_read_u32(np, ti,type, control_usb-type);
+   } else {
+   /* We only support DT boot */
+   return -EINVAL;
+   }
 
control_usb = devm_kzalloc(pdev-dev, sizeof(*control_usb),
GFP_KERNEL);
@@ -207,15 +212,6 @@ static int omap_control_usb_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
-   if (np) {
-   of_property_read_u32(np, ti,type, control_usb-type);
-   } else if (pdata) {
-   control_usb-type = pdata-type;
-   } else {
-   dev_err(pdev-dev, no pdata present\n);
-   return -EINVAL;
-   }
-
control_usb-dev= pdev-dev;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
diff --git a/include/linux/usb/omap_control_usb.h 
b/include/linux/usb/omap_control_usb.h
index 27b5b8c..e2416b4 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -31,10 +31,6 @@ struct omap_control_usb {
u32 type;
 };
 
-struct omap_control_usb_platform_data {
-   u8 type;
-};
-
 enum omap_control_usb_mode {
USB_MODE_UNDEFINED = 0,
USB_MODE_HOST,
-- 
1.7.4.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/8] phy: omap-usb: Support multiple instances and new types

[Roger Quadros]

Hi,

This patchset does the following:

* Get rid of omap_control_usb platform data as we support DT only.

* Restructure and add support for new PHY types. We now support the follwing
four types

 TYPE_OMAP - if it has otghs_control mailbox register (e.g. on OMAP4)
 TYPE_USB2 - if it has Power down bit in control_dev_conf register. e.g. USB2 
PHY
 TYPE_USB3 - if it has DPLL and individual Rx  Tx power control. e.g. USB3 PHY 
or SATA PHY
 TYPE_DRA7 - if it has both power down and power aux registers. e.g. USB2 PHY 
on DRA7

* Get rid of ti,type DT property and introduce compatible strings for each 
type.

* Have only one power control API omap_control_usb_phy_power() instead of a
different one for each PHY type.

* Get rid of omap_get_control_dev() so that we can support multiple instances
of the control device. We take advantage of the fact that omap control USB 
device
is only present on OMAP4 onwards and hence only supports DT boot. The users
of control USB device can get a reference to it from the device node's phandle.

Patches are based on balbi/next.

Smoke tested on OMAP4 panda with MUSB in gadget mode (g_zero).

You can find the patches in branch
 usb-control-module
in git tree
 git://github.com/rogerq/linux.git

v5:
- fixed whitespace alignment issues.

v4:
- removed ti,has-mailbox from omap-usb binding document example.

v3:
- return -EINVAL instead of -ENODEV on probe failure.
- pass device type data through of_device_id table.
- get rid of ti,mailbox property and has_mailbox from musb platform data.

v2:
- get rid of ti,type property and introduce compatible strings for each 
device type.

cheers,
-roger

---
Roger Quadros (8):
  usb: phy: omap-control: Get rid of platform data
  usb: phy: omap: Add new device types and remove
omap_control_usb3_phy_power()
  usb: phy: omap-usb2: Don't use omap_get_control_dev()
  usb: phy: omap-usb3: Don't use omap_get_control_dev()
  usb: musb: omap2430: Don't use omap_get_control_dev()
  usb: phy: omap: get rid of omap_get_control_dev()
  ARM: dts: omap4: update omap-control-usb nodes
  ARM: dts: omap5: update omap-control-usb node

 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++--
 arch/arm/boot/dts/omap4.dtsi   |   20 ++-
 arch/arm/boot/dts/omap5.dtsi   |   20 ++-
 drivers/usb/musb/omap2430.c|   25 ++-
 drivers/usb/phy/phy-omap-control.c |  210 +++-
 drivers/usb/phy/phy-omap-usb2.c|   26 ++-
 drivers/usb/phy/phy-omap-usb3.c|   32 +++-
 include/linux/usb/musb.h   |2 -
 include/linux/usb/omap_control_usb.h   |   33 ++--
 9 files changed, 226 insertions(+), 175 deletions(-)

-- 
1.7.4.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/8] usb: phy: omap-usb2: Don't use omap_get_control_dev()

[Roger Quadros]

omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.

As we don't support non-DT boot, we just bail out on probe
if device node is not present.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/phy/phy-omap-usb2.c |   26 --
 1 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..e278a3d 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include linux/pm_runtime.h
 #include linux/delay.h
 #include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -121,8 +122,14 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
suspend)
 
 static int omap_usb2_probe(struct platform_device *pdev)
 {
-   struct omap_usb *phy;
-   struct usb_otg  *otg;
+   struct omap_usb *phy;
+   struct usb_otg *otg;
+   struct device_node *node = pdev-dev.of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
+   if (!node)
+   return -EINVAL;
 
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -144,11 +151,18 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.otg= otg;
phy-phy.type   = USB_PHY_TYPE_USB2;
 
-   phy-control_dev = omap_get_control_dev();
-   if (IS_ERR(phy-control_dev)) {
-   dev_dbg(pdev-dev, Failed to get control device\n);
-   return -ENODEV;
+   control_node = of_parse_phandle(node, ctrl-module, 0);
+   if (!control_node) {
+   dev_err(pdev-dev, Failed to get control device phandle\n);
+   return -EINVAL;
}
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(pdev-dev, Failed to get control device\n);
+   return -EINVAL;
+   }
+
+   phy-control_dev = control_pdev-dev;
 
phy-is_suspended   = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
-- 
1.7.4.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/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()

[Roger Quadros]

Add support for new device types and in the process rid of ti,type
device tree property. The correct type of device will be determined
from the compatible string instead.

Introduce a compatible string for each device type. At the moment
we support 4 types Mailbox, USB2, USB3 and DRA7.

Update DT binding information to reflect these changes.

Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.

Signed-off-by: Roger Quadros rog...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   29 ++--
 drivers/usb/phy/phy-omap-control.c |  173 
 drivers/usb/phy/phy-omap-usb3.c|6 +-
 include/linux/usb/omap_control_usb.h   |   24 ++--
 4 files changed, 137 insertions(+), 95 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..e24078f 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -73,22 +73,23 @@ omap_dwc3 {
 OMAP CONTROL USB
 
 Required properties:
- - compatible: Should be ti,omap-control-usb
+ - compatible: Should be one of
+ ti,omap4-control-usb - if it has otghs_control mailbox register as on OMAP4.
+ ti,usb2-control-usb - if it has Power down bit in control_dev_conf register
+   e.g. USB2_PHY on OMAP5.
+ ti,usb3-control-usb - if it has DPLL and individual Rx  Tx power control
+   e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,dra7-control-usb - if it has both power down and power aux registers
+   e.g. USB2 PHY on DRA7 platform.
  - reg : Address and length of the register set for the device. It contains
-   the address of control_dev_conf and otghs_control or phy_power_usb
-   depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the 
registers
-   filled in reg.
- - ti,type: This is used to differentiate whether the control module has
-   usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
-   notify events to the musb core and omap5 has usb3 phy power register to
-   power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
-   phy power.
+   the address of otghs_control for omap4-control-usb or power register
+   for other types. For dra7-control-usb, it must also contain power_aux
+   register.
+ - reg-names: should be otghs_control for omap4-control-usb and power for
+   other types. For dra7-control-usb type it must also contain power_aux.
 
 omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,omap-control-usb;
-   reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
-   reg-names = control_dev_conf, otghs_control;
-   ti,type = 1;
+   reg = 0x4a00233c 0x4;
+   reg-names = otghs_control;
 };
diff --git a/drivers/usb/phy/phy-omap-control.c 
b/drivers/usb/phy/phy-omap-control.c
index 7f446c4..4c4c85c 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -20,6 +20,7 @@
 #include linux/platform_device.h
 #include linux/slab.h
 #include linux/of.h
+#include linux/of_device.h
 #include linux/err.h
 #include linux/io.h
 #include linux/clk.h
@@ -46,61 +47,76 @@ struct device *omap_get_control_dev(void)
 EXPORT_SYMBOL_GPL(omap_get_control_dev);
 
 /**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
  * @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
  */
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
 {
-   u32 val;
+   u32 val, val_aux;
unsigned long rate;
-   struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+   struct omap_control_usb *control_usb;
 
-   if (control_usb-type != OMAP_CTRL_DEV_TYPE2)
+   if (IS_ERR(dev) || !dev) {
+   pr_err(%s: invalid device\n, __func__);
return;
+   }
 
-   rate = clk_get_rate(control_usb-sys_clk);
-   rate = rate/100;
+   control_usb = dev_get_drvdata(dev);
+   if (!control_usb) {
+   dev_err(dev, %s: invalid control usb device\n, __func__);
+   return;
+   }
 
-   val = readl(control_usb-phy_power);
+   if (control_usb-type == OMAP_CTRL_TYPE_OMAP4)
+   return;
 
-   if (on) {
-   val = ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
-   OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
-   val |= OMAP_CTRL_USB3_PHY_TX_RX_POWERON 
-   OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
-   

[PATCH v5 7/8] ARM: dts: omap4: update omap-control-usb nodes

[Roger Quadros]

Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Get rid of ti,type property.

Also get rid of ti,has-mailbox property from usb_otg_hs
node and provide the ctrl-module phandle.

CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a77dd0a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
-   ctrl-module = omap_control_usb;
+   ctrl-module = omap_control_usb2phy;
};
};
 
@@ -643,12 +643,16 @@
};
};
 
-   omap_control_usb: omap-control-usb@4a002300 {
-   compatible = ti,omap-control-usb;
-   reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
-   reg-names = control_dev_conf, otghs_control;
-   ti,type = 1;
+   omap_control_usb2phy: omap-control-usb@4a002300 {
+   compatible = ti,usb2-control-usb;
+   reg = 0x4a002300 0x4;
+   reg-names = power;
+   };
+
+   omap_control_usbotg: omap-control-usb@4a00233c {
+   compatible = ti,omap4-control-usb;
+   reg = 0x4a00233c 0x4;
+   reg-names = otghs_control;
};
 
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -661,7 +665,7 @@
multipoint = 1;
num-eps = 16;
ram-bits = 12;
-   ti,has-mailbox;
+   ctrl-module = omap_control_usbotg;
};
};
 };
-- 
1.7.4.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 5/8] usb: musb: omap2430: Don't use omap_get_control_dev()

[Roger Quadros]

omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.

Also get rid of ti,has-mailbox property as it is redundant and
we can determine that from whether ctrl-module property is present
or not. Get rid of has_mailbox from musb_hdrc_platform_data as well.

Signed-off-by: Roger Quadros rog...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |4 ---
 drivers/usb/musb/omap2430.c|   25 +++
 include/linux/usb/musb.h   |2 -
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index e24078f..4dc9100 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
 OMAP MUSB GLUE
  - compatible : Should be ti,omap4-musb or ti,omap3-musb
  - ti,hwmods : must be usb_otg_hs
- - ti,has-mailbox : to specify that omap uses an external mailbox
-   (in control module) to communicate with the musb core during device connect
-   and disconnect.
  - multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
  - num-eps : Specifies the number of endpoints. This is also a
@@ -28,7 +25,6 @@ SOC specific device node entry
 usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
ti,hwmods = usb_otg_hs;
-   ti,has-mailbox;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ebb46ec..516795b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
 #include linux/delay.h
 #include linux/usb/musb-omap.h
 #include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
 
 #include musb_core.h
 #include omap2430.h
@@ -509,8 +510,12 @@ static int omap2430_probe(struct platform_device *pdev)
glue-dev   = pdev-dev;
glue-musb  = musb;
glue-status= OMAP_MUSB_UNKNOWN;
+   glue-control_otghs = ERR_PTR(-ENODEV);
 
if (np) {
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
dev_err(pdev-dev,
@@ -539,22 +544,20 @@ static int omap2430_probe(struct platform_device *pdev)
of_property_read_u32(np, ram-bits, (u32 *)config-ram_bits);
of_property_read_u32(np, power, (u32 *)pdata-power);
config-multipoint = of_property_read_bool(np, multipoint);
-   pdata-has_mailbox = of_property_read_bool(np,
-   ti,has-mailbox);
 
pdata-board_data   = data;
pdata-config   = config;
-   }
 
-   if (pdata-has_mailbox) {
-   glue-control_otghs = omap_get_control_dev();
-   if (IS_ERR(glue-control_otghs)) {
-   dev_vdbg(pdev-dev, Failed to get control device\n);
-   ret = PTR_ERR(glue-control_otghs);
-   goto err2;
+   control_node = of_parse_phandle(np, ctrl-module, 0);
+   if (control_node) {
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(pdev-dev, Failed to get control 
device\n);
+   ret = -EINVAL;
+   goto err2;
+   }
+   glue-control_otghs = control_pdev-dev;
}
-   } else {
-   glue-control_otghs = ERR_PTR(-ENODEV);
}
pdata-platform_ops = omap2430_ops;
 
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..eb50525 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,8 +99,6 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
-   u8  has_mailbox:1;
-
/* for clk_get() */
const char  *clock;
 
-- 
1.7.4.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 8/8] ARM: dts: omap5: update omap-control-usb node

[Roger Quadros]

Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of ti,type property.

CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..7cda18b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -626,12 +626,16 @@
hw-caps-temp-alert;
};
 
-   omap_control_usb: omap-control-usb@4a002300 {
-   compatible = ti,omap-control-usb;
-   reg = 0x4a002300 0x4,
- 0x4a002370 0x4;
-   reg-names = control_dev_conf, phy_power_usb;
-   ti,type = 2;
+   omap_control_usb2phy: omap-control-usb@4a002300 {
+   compatible = ti,usb2-control-usb;
+   reg = 0x4a002300 0x4;
+   reg-names = power;
+   };
+
+   omap_control_usb3phy: omap-control-usb@0x4a002370 {
+   compatible = ti,usb3-control-usb;
+   reg = 0x4a002370 0x4;
+   reg-names = power;
};
 
omap_dwc3@4a02 {
@@ -661,7 +665,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
-   ctrl-module = omap_control_usb;
+   ctrl-module = omap_control_usb2phy;
};
 
usb3_phy: usb3phy@4a084400 {
@@ -670,7 +674,7 @@
  0x4a084800 0x64,
  0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
-   ctrl-module = omap_control_usb;
+   ctrl-module = omap_control_usb3phy;
};
};
 
-- 
1.7.4.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 6/8] usb: phy: omap: get rid of omap_get_control_dev()

[Roger Quadros]

This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/phy/phy-omap-control.c   |   31 ++-
 include/linux/usb/omap_control_usb.h |5 -
 2 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-control.c 
b/drivers/usb/phy/phy-omap-control.c
index 4c4c85c..1a7e19a 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -26,26 +26,6 @@
 #include linux/clk.h
 #include linux/usb/omap_control_usb.h
 
-static struct omap_control_usb *control_usb;
-
-/**
- * omap_get_control_dev - returns the device pointer for this control device
- *
- * This API should be called to get the device pointer for this control
- * module device. This device pointer should be used for called other
- * exported API's in this driver.
- *
- * To be used by PHY driver and glue driver.
- */
-struct device *omap_get_control_dev(void)
-{
-   if (!control_usb)
-   return ERR_PTR(-ENODEV);
-
-   return control_usb-dev;
-}
-EXPORT_SYMBOL_GPL(omap_get_control_dev);
-
 /**
  * omap_control_usb_phy_power - power on/off the phy using control module reg
  * @dev: the control module device
@@ -188,11 +168,19 @@ void omap_control_usb_set_mode(struct device *dev,
 {
struct omap_control_usb *ctrl_usb;
 
-   if (IS_ERR(dev) || control_usb-type != OMAP_CTRL_TYPE_OMAP4)
+   if (IS_ERR(dev) || !dev)
return;
 
ctrl_usb = dev_get_drvdata(dev);
 
+   if (!ctrl_usb) {
+   dev_err(dev, Invalid control usb device\n);
+   return;
+   }
+
+   if (ctrl_usb-type != OMAP_CTRL_TYPE_OMAP4)
+   return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -215,6 +203,7 @@ static int omap_control_usb_probe(struct platform_device 
*pdev)
 {
struct resource *res;
const struct of_device_id *of_id;
+   struct omap_control_usb *control_usb;
 
of_id = of_match_device(omap_control_usb_id_table, pdev-dev);
if (!of_id)
diff --git a/include/linux/usb/omap_control_usb.h 
b/include/linux/usb/omap_control_usb.h
index 450b5c1..8008e8d 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -65,15 +65,10 @@ enum omap_control_usb_mode {
 #define OMAP_CTRL_USB2_PHY_PD  BIT(28)
 
 #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-extern struct device *omap_get_control_dev(void);
 extern void omap_control_usb_phy_power(struct device *dev, int on);
 extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
 #else
-static inline struct device *omap_get_control_dev(void)
-{
-   return ERR_PTR(-ENODEV);
-}
 
 static inline void omap_control_usb_phy_power(struct device *dev, int on)
 {
-- 
1.7.4.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 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()

[Roger Quadros]

omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.

As we don't support non-DT boot, we just bail out on probe
if device node is not present.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/phy/phy-omap-usb3.c |   26 --
 1 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..4004f82 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
 #include linux/pm_runtime.h
 #include linux/delay.h
 #include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
 
 #definePLL_STATUS  0x0004
 #definePLL_GO  0x0008
@@ -196,8 +197,14 @@ static int omap_usb3_init(struct usb_phy *x)
 
 static int omap_usb3_probe(struct platform_device *pdev)
 {
-   struct omap_usb *phy;
-   struct resource *res;
+   struct omap_usb *phy;
+   struct resource *res;
+   struct device_node *node = pdev-dev.of_node;
+   struct device_node *control_node;
+   struct platform_device *control_pdev;
+
+   if (!node)
+   return -EINVAL;
 
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -239,11 +246,18 @@ static int omap_usb3_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   phy-control_dev = omap_get_control_dev();
-   if (IS_ERR(phy-control_dev)) {
-   dev_dbg(pdev-dev, Failed to get control device\n);
-   return -ENODEV;
+   control_node = of_parse_phandle(node, ctrl-module, 0);
+   if (!control_node) {
+   dev_err(pdev-dev, Failed to get control device phandle\n);
+   return -EINVAL;
}
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(pdev-dev, Failed to get control device\n);
+   return -EINVAL;
+   }
+
+   phy-control_dev = control_pdev-dev;
 
omap_control_usb_phy_power(phy-control_dev, 0);
usb_add_phy_dev(phy-phy);
-- 
1.7.4.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

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

[Benoit Cousson]

Hi Tony,

Please pull the following commits for OMAP Device Tree for v3.12.

Thanks,
Benoit


Add the minimal DTS support for DRA7xx based SoC core.
Add the initial support for N900 and gta04 phones.
Do a lot of various cleanups.


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 9f311a2325905043718da9bf649e2344b8df8473:

  ARM: dts: omap3-beagle: Make USB host pin naming consistent (2013-08-20 
14:30:07 +0200)


Afzal Mohammed (2):
  ARM: dts: AM4372: cpu(s) node per latest binding
  ARM: dts: AM4372: add few nodes

Alexandre Belloni (1):
  ARM: dts: AM33XX: Add PMU support

Javier Martinez Canillas (5):
  ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration
  ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs
  ARM: dts: omap3-igep0030: add mux conf for GPIO LED
  ARM: dts: AM33XX: use pinmux node defined in included file
  ARM: dts: AM33XX: don't redefine OCP bus and device nodes

Kishon Vijay Abraham I (1):
  ARM: dts: omap5-uevm: Split SMPS10 in two nodes

Lars Poeschel (1):
  ARM: dts: AM33xx: Correct gpio #interrupt-cells property

Lee Jones (7):
  ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
  ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
  ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
  ARM: dts: Remove '0x's from OMAP3 DTS file
  ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
  ARM: dts: Remove '0x's from OMAP4 DTS file
  ARM: dts: Remove '0x's from OMAP5 DTS file

Marek Belisko (1):
  ARM: dts: Add devicetree for gta04 board.

Pavel Machek (1):
  ARM: dts: N900: Add device tree

R Sricharan (1):
  ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board

Robert Nelson (1):
  ARM: dts: omap3-beagle-xm: fix string error in compatible property

Roger Quadros (1):
  ARM: dts: omap3-beagle: Make USB host pin naming consistent

Ruslan Bilovol (1):
  ARM: dts: twl6030: Move common configuration for OMAP4 boards in a 
separate dtsi file

 arch/arm/boot/dts/Makefile|   5 +-
 arch/arm/boot/dts/am335x-bone.dts | 217 ++-
 arch/arm/boot/dts/am335x-evm.dts  | 576 +++---
 arch/arm/boot/dts/am335x-evmsk.dts| 374 ++-
 arch/arm/boot/dts/am33xx.dtsi |  13 +-
 arch/arm/boot/dts/am4372.dtsi | 347 ++
 arch/arm/boot/dts/dra7-evm.dts| 140 
 arch/arm/boot/dts/dra7.dtsi   | 575 +
 arch/arm/boot/dts/omap2420-h4.dts |   6 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts |   2 +-
 arch/arm/boot/dts/omap3-beagle.dts|  24 +-
 arch/arm/boot/dts/omap3-gta04.dts | 168 +
 arch/arm/boot/dts/omap3-igep.dtsi |   2 +
 arch/arm/boot/dts/omap3-igep0020.dts  |  19 +-
 arch/arm/boot/dts/omap3-igep0030.dts  |  17 +-
 arch/arm/boot/dts/omap3-n900.dts  |  92 +
 arch/arm/boot/dts/omap3.dtsi  |   2 +-
 arch/arm/boot/dts/omap3430-sdp.dts|  22 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi |  21 +-
 arch/arm/boot/dts/omap4-sdp.dts   |  21 +-
 arch/arm/boot/dts/omap4.dtsi  |   2 +-
 arch/arm/boot/dts/omap5-uevm.dts  |  13 +-
 arch/arm/boot/dts/omap5.dtsi  |   4 +-
 arch/arm/boot/dts/twl6030_omap4.dtsi  |  38 ++
 include/dt-bindings/pinctrl/dra.h |  50 +++
 25 files changed, 2077 insertions(+), 673 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
 create mode 100644 arch/arm/boot/dts/omap3-n900.dts
 create mode 100644 arch/arm/boot/dts/twl6030_omap4.dtsi
 create mode 100644 include/dt-bindings/pinctrl/dra.h
--
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/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Kumar Gala]

On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:

 
 Hi, 
 
 On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
 On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
 Hi,
 
 On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
 Hi,
 
 On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
 On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
 From: Ivan T. Ivanov iiva...@mm-sol.com
 
 These drivers handles control and configuration of the HS
 and SS USB PHY transceivers. They are part of the driver
 which manage Synopsys DesignWare USB3 controller stack
 inside Qualcomm SoC's.
 
 Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
 ---
 drivers/usb/phy/Kconfig   |   11 ++
 drivers/usb/phy/Makefile  |2 +
 drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
 
 drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
 +
 
 please rename these PHY drivers, they have nothing to do with DWC3. PHYs
 don't care about the USB controller.
 
 I think they are SNPS DesignWare PHY's, additionally
 wrapped with Qualcomm logic. I could substitute dwc3
 with just dw, which will be more correct.
 
 alright, thank you. Let's add Paul to the loop since he might have very
 good insight in the synopsys PHYs.
 
 mental note: if any other platform shows up with Synopsys PHY, ask them
 to use this driver instead :-)
 
 I really doubt that this will bi possible. Control of the PHY's is
 not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
 QSCRATCH registers, which of course is highly Qualcomm specific.
 
 isn't it a memory mapped IP ? doesn't synopsys provide their own set of
 registers ?
 
 From what I see it is not directly mapped. How QSCRATCH write and
 reads transactions are translated to DW IP is unclear to me.


I think the question is how does SW access them?

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
The Linux Foundation

--
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 0/2] crypto: omap-sham: Misc updates for driver

[Lokesh Vutla]

This patch series updates the following for the driver:
- Enable polling mode if DMA fails.
- Correct the DMA burst size.

Lokesh Vutla (2):
  crypto: omap-sham: Enable Polling mode if DMA fails
  crypto: omap-sham: correct dma burst size

 drivers/crypto/omap-sham.c |   72 
 1 file changed, 46 insertions(+), 26 deletions(-)

-- 
1.7.9.5

--
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 2/2] crypto: omap-sham: correct dma burst size

[Lokesh Vutla]

Each cycle of SHA512 operates on 32 data words where as
SHA256 operates on 16 data words. This needs to be updated
while configuring DMA channels. Doing the same.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 drivers/crypto/omap-sham.c |   11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 0a2bd16..8bdde57 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -46,9 +46,6 @@
 
 #define MD5_DIGEST_SIZE16
 
-#define DST_MAXBURST   16
-#define DMA_MIN(DST_MAXBURST * sizeof(u32))
-
 #define SHA_REG_IDIGEST(dd, x) ((dd)-pdata-idigest_ofs + ((x)*0x04))
 #define SHA_REG_DIN(dd, x) ((dd)-pdata-din_ofs + ((x) * 0x04))
 #define SHA_REG_DIGCNT(dd) ((dd)-pdata-digcnt_ofs)
@@ -558,7 +555,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, 
dma_addr_t dma_addr,
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
struct dma_async_tx_descriptor *tx;
struct dma_slave_config cfg;
-   int len32, ret;
+   int len32, ret, dma_min = get_block_size(ctx);
 
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
@@ -567,7 +564,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, 
dma_addr_t dma_addr,
 
cfg.dst_addr = dd-phys_base + SHA_REG_DIN(dd, 0);
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   cfg.dst_maxburst = DST_MAXBURST;
+   cfg.dst_maxburst = dma_min / DMA_SLAVE_BUSWIDTH_4_BYTES;
 
ret = dmaengine_slave_config(dd-dma_lch, cfg);
if (ret) {
@@ -575,7 +572,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, 
dma_addr_t dma_addr,
return ret;
}
 
-   len32 = DIV_ROUND_UP(length, DMA_MIN) * DMA_MIN;
+   len32 = DIV_ROUND_UP(length, dma_min) * dma_min;
 
if (is_sg) {
/*
@@ -729,7 +726,7 @@ static int omap_sham_update_dma_start(struct omap_sham_dev 
*dd)
 * the dmaengine infrastructure will calculate that it needs
 * to transfer 0 frames which ultimately fails.
 */
-   if (ctx-total  (DST_MAXBURST * sizeof(u32)))
+   if (ctx-total  get_block_size(ctx))
return omap_sham_update_dma_slow(dd);
 
dev_dbg(dd-dev, fast: digcnt: %d, bufcnt: %u, total: %u\n,
-- 
1.7.9.5

--
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 1/2] crypto: omap-sham: Enable Polling mode if DMA fails

[Lokesh Vutla]

For writing input buffer into DATA_IN register current driver
has the following state machine:
- if input buffer  9 : use fallback driver
- else if input buffer  block size : Copy input buffer into data_in regs
- else use dma transfer.

In cases where requesting for DMA channels fails for some reason,
or channel numbers are not provided in DT or platform data, probe
also fails. Instead of returning from driver use cpu polling mode.
In this mode processor polls on INPUT_READY bit and writes data into
data_in regs when it equals 1. This operation is repeated until the
length of message.

Now the state machine looks like:
- if input buffer  9 : use fallback driver
- else if input buffer  block size : Copy input buffer into data_in regs
- else if dma enabled: use dma transfer
   else use cpu polling mode.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 drivers/crypto/omap-sham.c |   61 ++--
 1 file changed, 42 insertions(+), 19 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index ae1ca8b2..0a2bd16 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -225,6 +225,7 @@ struct omap_sham_dev {
unsigned intdma;
struct dma_chan *dma_lch;
struct tasklet_struct   done_task;
+   u8  polling_mode;
 
unsigned long   flags;
struct crypto_queue queue;
@@ -510,7 +511,7 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, 
const u8 *buf,
  size_t length, int final)
 {
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
-   int count, len32;
+   int count, len32, bs32, offset = 0;
const u32 *buffer = (const u32 *)buf;
 
dev_dbg(dd-dev, xmit_cpu: digcnt: %d, length: %d, final: %d\n,
@@ -522,18 +523,23 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, 
const u8 *buf,
/* should be non-zero before next lines to disable clocks later */
ctx-digcnt += length;
 
-   if (dd-pdata-poll_irq(dd))
-   return -ETIMEDOUT;
-
if (final)
set_bit(FLAGS_FINAL, dd-flags); /* catch last interrupt */
 
set_bit(FLAGS_CPU, dd-flags);
 
len32 = DIV_ROUND_UP(length, sizeof(u32));
+   bs32 = get_block_size(ctx) / sizeof(u32);
+
+   while (len32) {
+   if (dd-pdata-poll_irq(dd))
+   return -ETIMEDOUT;
 
-   for (count = 0; count  len32; count++)
-   omap_sham_write(dd, SHA_REG_DIN(dd, count), buffer[count]);
+   for (count = 0; count  min(len32, bs32); count++, offset++)
+   omap_sham_write(dd, SHA_REG_DIN(dd, count),
+   buffer[offset]);
+   len32 -= min(len32, bs32);
+   }
 
return -EINPROGRESS;
 }
@@ -774,13 +780,22 @@ static int omap_sham_update_dma_start(struct 
omap_sham_dev *dd)
 static int omap_sham_update_cpu(struct omap_sham_dev *dd)
 {
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
-   int bufcnt;
+   int bufcnt, final;
+
+   if (!ctx-total)
+   return 0;
 
omap_sham_append_sg(ctx);
+
+   final = (ctx-flags  BIT(FLAGS_FINUP))  !ctx-total;
+
+   dev_dbg(dd-dev, cpu: bufcnt: %u, digcnt: %d, final: %d\n,
+   ctx-bufcnt, ctx-digcnt, final);
+
bufcnt = ctx-bufcnt;
ctx-bufcnt = 0;
 
-   return omap_sham_xmit_cpu(dd, ctx-buffer, bufcnt, 1);
+   return omap_sham_xmit_cpu(dd, ctx-buffer, bufcnt, final);
 }
 
 static int omap_sham_update_dma_stop(struct omap_sham_dev *dd)
@@ -903,8 +918,11 @@ static int omap_sham_final_req(struct omap_sham_dev *dd)
struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
int err = 0, use_dma = 1;
 
-   if (ctx-bufcnt = DMA_MIN)
-   /* faster to handle last block with cpu */
+   if ((ctx-bufcnt = get_block_size(ctx)) || dd-polling_mode)
+   /*
+* faster to handle last block with cpu or
+* use cpu when dma is not present.
+*/
use_dma = 0;
 
if (use_dma)
@@ -1056,6 +1074,7 @@ static int omap_sham_enqueue(struct ahash_request *req, 
unsigned int op)
 static int omap_sham_update(struct ahash_request *req)
 {
struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
+   struct omap_sham_dev *dd = ctx-dd;
int bs = get_block_size(ctx);
 
if (!req-nbytes)
@@ -1074,10 +1093,12 @@ static int omap_sham_update(struct ahash_request *req)
*/
omap_sham_append_sg(ctx);
return 0;
-   } else if (ctx-bufcnt + ctx-total = bs) {
+   } else if ((ctx-bufcnt + ctx-total = bs) ||
+  dd-polling_mode) {
/*
-   * faster to use CPU for short transfers
-

Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Pawel Moll]

On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
 On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
 
  
  Hi, 
  
  On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
  On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
  Hi,
  
  On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
  Hi,
  
  On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
  On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
  From: Ivan T. Ivanov iiva...@mm-sol.com
  
  These drivers handles control and configuration of the HS
  and SS USB PHY transceivers. They are part of the driver
  which manage Synopsys DesignWare USB3 controller stack
  inside Qualcomm SoC's.
  
  Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
  ---
  drivers/usb/phy/Kconfig   |   11 ++
  drivers/usb/phy/Makefile  |2 +
  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
  
  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
  +
  
  please rename these PHY drivers, they have nothing to do with DWC3. 
  PHYs
  don't care about the USB controller.
  
  I think they are SNPS DesignWare PHY's, additionally
  wrapped with Qualcomm logic. I could substitute dwc3
  with just dw, which will be more correct.
  
  alright, thank you. Let's add Paul to the loop since he might have very
  good insight in the synopsys PHYs.
  
  mental note: if any other platform shows up with Synopsys PHY, ask them
  to use this driver instead :-)
  
  I really doubt that this will bi possible. Control of the PHY's is
  not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
  QSCRATCH registers, which of course is highly Qualcomm specific.
  
  isn't it a memory mapped IP ? doesn't synopsys provide their own set of
  registers ?
  
  From what I see it is not directly mapped. How QSCRATCH write and
  reads transactions are translated to DW IP is unclear to me.
 
 
 I think the question is how does SW access them?

I afraid the answer may be: it depends on the SOC. In my past I had to
initialize a (SATA) PHY by implementing a software JTAG state machine,
as the PHY's registers were not memory mapped *at all*. And the IP
itself came from Synopsys, Cadence or yet another EDA company...

Paweł


--
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 1/8] usb: phy: omap-control: Get rid of platform data

[thomas.langer]

Hello Roger,

this will not work!

Roger Quadros wrote on 2013-08-20:

 - struct omap_control_usb_platform_data *pdata =
 - dev_get_platdata(pdev-dev);
 +
 + if (np) {
 + of_property_read_u32(np, ti,type, control_usb-type);

here you are dereferencing control_usb

 + } else {
 + /* We only support DT boot */
 + return -EINVAL;
 + }
 
   control_usb = devm_kzalloc(pdev-dev, sizeof(*control_usb),
   GFP_KERNEL);

and here it is allocated!

Best Regards,
Thomas


--
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/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Ivan T. Ivanov]

On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote: 
 On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
 
  
  Hi, 
  
  On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
  On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
  Hi,
  
  On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
  Hi,
  
  On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
  On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
  From: Ivan T. Ivanov iiva...@mm-sol.com
  
  These drivers handles control and configuration of the HS
  and SS USB PHY transceivers. They are part of the driver
  which manage Synopsys DesignWare USB3 controller stack
  inside Qualcomm SoC's.
  
  Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
  ---
  drivers/usb/phy/Kconfig   |   11 ++
  drivers/usb/phy/Makefile  |2 +
  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
  
  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
  +
  
  please rename these PHY drivers, they have nothing to do with DWC3. 
  PHYs
  don't care about the USB controller.
  
  I think they are SNPS DesignWare PHY's, additionally
  wrapped with Qualcomm logic. I could substitute dwc3
  with just dw, which will be more correct.
  
  alright, thank you. Let's add Paul to the loop since he might have very
  good insight in the synopsys PHYs.
  
  mental note: if any other platform shows up with Synopsys PHY, ask them
  to use this driver instead :-)
  
  I really doubt that this will bi possible. Control of the PHY's is
  not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
  QSCRATCH registers, which of course is highly Qualcomm specific.
  
  isn't it a memory mapped IP ? doesn't synopsys provide their own set of
  registers ?
  
  From what I see it is not directly mapped. How QSCRATCH write and
  reads transactions are translated to DW IP is unclear to me.
 
 
 I think the question is how does SW access them?

USB QSCRATCH Hardware registers don't ask me what is this :-)
or like Pawel says: it depends on the SOC .

Ivan

 
 - k
 


--
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/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support

[Russ Dill]

On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar
gururaja.heb...@ti.com wrote:

 On 8/15/2013 4:04 AM, Russ Dill wrote:
  On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar gururaja.heb...@ti.com 
  wrote:
  On 8/14/2013 3:50 AM, Russ Dill wrote:
  Changes since v1:
  * Rebased onto new am335x PM branch
  * Changed to use 5th param register

 

 [snip]
 [snip]

  +
  + wkup_m3_reset_data_pos();
  + if (am33xx_i2c_sleep_sequence) {
  + pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence,
  + i2c_sleep_sequence_sz);
 
  Why do we need to copy this data (same constant data) on every iteration?
 
  Because the CM3 firmware is reset after each suspend/resume cycle. The
  firmware reset handler reinitializes the DMEM.

 Well in that why can't the i2c payload be copied to UMEM?

 Thanks  regards
 Gururaja


I've given this some thought, and gone back and forth a bit. UMEM is a
bit more complicated because the linker decides what should go where.
Also, it may be that in the future, either the PM for am335x or am43xx
will be writing different sequences depending on the suspend
mode/options.

Is there a specific aspect of copying the data each suspend cycle that
you are trying to fix? Is it just that the data could only be copied
once? Or is it the latency of the copy?

Thanks!
--
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/5] mfd: twl6030-irq: rework and add twl6032 support

[Grygorii Strashko]

On 08/20/2013 11:18 AM, Samuel Ortiz wrote:

On Tue, Aug 20, 2013 at 08:13:54AM +0100, Graeme Gregory wrote:

On 20/08/13 02:01, Samuel Ortiz wrote:

Hi Grygorii,

On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote:

This patch series intorduces twl6030-irq module rework to use Threaded IRQ and
linear irq_domain, and adds support for PMIC TWL6032 IRQs.

After this patch series TWL6030/6032 IRQs will be supported only for DT boot 
mode.

Changes since v1:
- Added new patch mfd: twl6030-irq: create struct twl6030_irq
   which introduces struct twl6030_irq to store all local variables inside it.
- Patch mfd: twl6030-irq: migrate to IRQ threaded handler:
   Minor comments applied; fixed twl6030_exit_irq();
   The Parent IRQ has been set for each nested IRQ.
- Patch mfd: twl6030-irq: convert to use linear irq_domain:
   The irq_find_mapping() is used in twl6030_mmc_card_detect_config()
   to get virtual IRQ number.

This looks good to me. Kevin, Graeme, any further comments/ACKs ?

Cheers,
Samuel.


Yes, it looked good to me as well.

Acked-by: Graeme Gregory g...@slimlogic.co.uk

Thanks. All 5 patches applied to mfd-next.

Cheers,
Samuel.



Thanks.

Regards,
-grygorii


--
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] i2c-omap: always send stop after nack

[Grygorii Strashko]

On 08/19/2013 03:11 PM, Wolfram Sang wrote:

Hi,


Which means your original patch starts to make a lot more sense. I
wonder is this is really what we should be doing though - breaking out
of the loop, I mean.


Yup, that is fine. I applied the old patch with Acks from Hein and
Felipe to -next. Thanks!


Thanks.




It looks like TI's i2c-davinci will have the same problem as i2c-omap,
and will need the same change.


Somebody up for this?



Regards,
-grygorii
--
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: omap2: Use a consistent AM33XX SoC option description

[Ezequiel Garcia]

On Fri, Aug 09, 2013 at 11:18:43AM +0200, Javier Martinez Canillas wrote:
 On Thu, Aug 8, 2013 at 11:32 PM, Ezequiel Garcia
 ezequiel.gar...@free-electrons.com wrote:
  Fix the option description to match the other TI SoCs.
  This is just a cosmetic change.
 
  Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
  ---
   arch/arm/mach-omap2/Kconfig | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
  index 76170dd..56021c6 100644
  --- a/arch/arm/mach-omap2/Kconfig
  +++ b/arch/arm/mach-omap2/Kconfig
  @@ -64,7 +64,7 @@ config SOC_OMAP5
  select ARM_ERRATA_798181 if SMP
 
   config SOC_AM33XX
  -   bool AM33XX support
  +   bool TI AM33XX
  depends on ARCH_MULTI_V7
  select ARCH_OMAP2PLUS
  select ARM_CPU_SUSPEND if PM
  --
  1.8.1.5
 
 
 
 Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org

ping?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
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/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[Stephen Warren]

On 08/20/2013 12:55 AM, George Cherian wrote:
 Hi Stephen,
 
 Thanks for your review.
 
 On 8/20/2013 1:01 AM, Stephen Warren wrote:
 
 On 08/16/2013 04:13 AM, George Cherian wrote:
 Adding extcon driver for USB ID detection to dynamically
 configure USB Host/Peripheral mode.
 diff --git
 a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
 b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
 +EXTCON FOR DRA7xx
 +
 +Required Properties:
 Please at lest explain what a DRA7xxx is, and the purpose of the HW
 module this binding describes.
 
 DRA7xx is the SoC name and the USB VID  detection is implemented via gpio's
 Basically it does only ID detection via GPIO and there is no VBUS
 detection in h/w.

If there's no SoC-specific HW, then the binding has nothing to do with
the SoC; it's entirely generic.

I think instead, you need to define a generic gpio-usb-vid binding
instead.

Otherwise, ever SoC that doesn't have explicit USB VID detection HW is
going to re-invent the exact same binding, with pointless differences,
rather than using a single generic binding.

 + - compatible : Should be ti,dra7xx-usb

 If this is a USB VID detector rather than a full USB host controller,
 then usb in the binding is a bit over-reaching. Perhaps -usb-vid or
 -usb-vid-detector would be more accurate.
 
 This will be renamed to dra7xx-extcon.

So no, that rename doesn't sound correct.

 + - gpios : phandle to ID pin and interrupt gpio.

 Why does the interrupt line need to be included in a list of GPIOs?
 
 ID pins are connected to pcf8575, and the pcf8575's interrupt line is
 inturn connected to
 gpio bank6 pin 11, we use this gpio interrupt to detect the ID pin change.

In that case, the PCF8575 node needs to be a GPIO controller and an IRQ
controller, as does the driver for the PCF8575. This binding should have
a single entry in the gpios property, and the driver can call
gpio_to_irq() on that so it knows which IRQ to request.
--
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/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Pawel Moll]

On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
 On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
  On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
  
   
   Hi, 
   
   On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
   On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
   Hi,
   
   On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
   Hi,
   
   On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
   On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
   From: Ivan T. Ivanov iiva...@mm-sol.com
   
   These drivers handles control and configuration of the HS
   and SS USB PHY transceivers. They are part of the driver
   which manage Synopsys DesignWare USB3 controller stack
   inside Qualcomm SoC's.
   
   Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
   ---
   drivers/usb/phy/Kconfig   |   11 ++
   drivers/usb/phy/Makefile  |2 +
   drivers/usb/phy/phy-msm-dwc3-hs.c |  327 
   
   drivers/usb/phy/phy-msm-dwc3-ss.c |  374 
   +
   
   please rename these PHY drivers, they have nothing to do with DWC3. 
   PHYs
   don't care about the USB controller.
   
   I think they are SNPS DesignWare PHY's, additionally
   wrapped with Qualcomm logic. I could substitute dwc3
   with just dw, which will be more correct.
   
   alright, thank you. Let's add Paul to the loop since he might have very
   good insight in the synopsys PHYs.
   
   mental note: if any other platform shows up with Synopsys PHY, ask them
   to use this driver instead :-)
   
   I really doubt that this will bi possible. Control of the PHY's is
   not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
   QSCRATCH registers, which of course is highly Qualcomm specific.
   
   isn't it a memory mapped IP ? doesn't synopsys provide their own set of
   registers ?
   
   From what I see it is not directly mapped. How QSCRATCH write and
   reads transactions are translated to DW IP is unclear to me.
  
  
  I think the question is how does SW access them?
 
 I afraid the answer may be: it depends on the SOC. In my past I had to
 initialize a (SATA) PHY by implementing a software JTAG state machine,
 as the PHY's registers were not memory mapped *at all*. And the IP
 itself came from Synopsys, Cadence or yet another EDA company...

Having said all that... If the PHY's spec at least defined layout of the
registers in question and driver was using regmap API to talk to the
device (initially regmap-mmio), it has some chances to become universal.
The SOCs designed like my one would have to provide a custom regmap
implementation.

Paweł


--
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 5/8] usb: musb: omap2430: Don't use omap_get_control_dev()

[Sergei Shtylyov]

Hello.

On 08/20/2013 06:56 PM, Roger Quadros wrote:


omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.



Also get rid of ti,has-mailbox property as it is redundant and
we can determine that from whether ctrl-module property is present
or not. Get rid of has_mailbox from musb_hdrc_platform_data as well.



Signed-off-by: Roger Quadros rog...@ti.com

[...]


diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ebb46ec..516795b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c

[...]

@@ -509,8 +510,12 @@ static int omap2430_probe(struct platform_device *pdev)
glue-dev= pdev-dev;
glue-musb   = musb;
glue-status = OMAP_MUSB_UNKNOWN;
+   glue-control_otghs = ERR_PTR(-ENODEV);


   Could you please align = with the others above?

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] hwrng: reorder OMAP TRNG driver code

[Olof Johansson]

The newly added omap4 support in the driver was added without
consideration for building older configs. When building omap1_defconfig,
it resulted in:

drivers/char/hw_random/omap-rng.c:190:12: warning: 'omap4_rng_init' defined but 
not used [-Wunused-function]
drivers/char/hw_random/omap-rng.c:215:13: warning: 'omap4_rng_cleanup' defined 
but not used [-Wunused-function]
drivers/char/hw_random/omap-rng.c:251:20: warning: 'omap4_rng_irq' defined but 
not used [-Wunused-function]

Move the code around so it is grouped with its operations struct, which
for the omap4 case means also under the #ifdef CONFIG_OF, where it needs
to be.

Signed-off-by: Olof Johansson o...@lixom.net
Cc: Lokesh Vutla lokeshvu...@ti.com
---
 drivers/char/hw_random/omap-rng.c |  108 ++---
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index f3f7142..9b89ff4 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -140,16 +140,6 @@ static inline void omap_rng_write(struct omap_rng_dev 
*priv, u16 reg,
__raw_writel(val, priv-base + priv-pdata-regs[reg]);
 }
 
-static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
-{
-   return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
-}
-
-static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
-{
-   return omap_rng_read(priv, RNG_STATUS_REG)  RNG_REG_STATUS_RDY;
-}
-
 static int omap_rng_data_present(struct hwrng *rng, int wait)
 {
struct omap_rng_dev *priv;
@@ -187,6 +177,60 @@ static int omap_rng_data_read(struct hwrng *rng, u32 *data)
return data_size;
 }
 
+static int omap_rng_init(struct hwrng *rng)
+{
+   struct omap_rng_dev *priv;
+
+   priv = (struct omap_rng_dev *)rng-priv;
+   return priv-pdata-init(priv);
+}
+
+static void omap_rng_cleanup(struct hwrng *rng)
+{
+   struct omap_rng_dev *priv;
+
+   priv = (struct omap_rng_dev *)rng-priv;
+   priv-pdata-cleanup(priv);
+}
+
+static struct hwrng omap_rng_ops = {
+   .name   = omap,
+   .data_present   = omap_rng_data_present,
+   .data_read  = omap_rng_data_read,
+   .init   = omap_rng_init,
+   .cleanup= omap_rng_cleanup,
+};
+
+static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
+{
+   return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
+}
+
+static int omap2_rng_init(struct omap_rng_dev *priv)
+{
+   omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
+   return 0;
+}
+
+static void omap2_rng_cleanup(struct omap_rng_dev *priv)
+{
+   omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
+}
+
+static struct omap_rng_pdata omap2_rng_pdata = {
+   .regs   = (u16 *)reg_map_omap2,
+   .data_size  = OMAP2_RNG_OUTPUT_SIZE,
+   .data_present   = omap2_rng_data_present,
+   .init   = omap2_rng_init,
+   .cleanup= omap2_rng_cleanup,
+};
+
+#if defined(CONFIG_OF)
+static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
+{
+   return omap_rng_read(priv, RNG_STATUS_REG)  RNG_REG_STATUS_RDY;
+}
+
 static int omap4_rng_init(struct omap_rng_dev *priv)
 {
u32 val;
@@ -221,33 +265,6 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv)
omap_rng_write(priv, RNG_CONFIG_REG, val);
 }
 
-static int omap2_rng_init(struct omap_rng_dev *priv)
-{
-   omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
-   return 0;
-}
-
-static void omap2_rng_cleanup(struct omap_rng_dev *priv)
-{
-   omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
-}
-
-static int omap_rng_init(struct hwrng *rng)
-{
-   struct omap_rng_dev *priv;
-
-   priv = (struct omap_rng_dev *)rng-priv;
-   return priv-pdata-init(priv);
-}
-
-static void omap_rng_cleanup(struct hwrng *rng)
-{
-   struct omap_rng_dev *priv;
-
-   priv = (struct omap_rng_dev *)rng-priv;
-   priv-pdata-cleanup(priv);
-}
-
 static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
 {
struct omap_rng_dev *priv = dev_id;
@@ -275,23 +292,6 @@ static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static struct hwrng omap_rng_ops = {
-   .name   = omap,
-   .data_present   = omap_rng_data_present,
-   .data_read  = omap_rng_data_read,
-   .init   = omap_rng_init,
-   .cleanup= omap_rng_cleanup,
-};
-
-static struct omap_rng_pdata omap2_rng_pdata = {
-   .regs   = (u16 *)reg_map_omap2,
-   .data_size  = OMAP2_RNG_OUTPUT_SIZE,
-   .data_present   = omap2_rng_data_present,
-   .init   = omap2_rng_init,
-   .cleanup= omap2_rng_cleanup,
-};
-
-#if defined(CONFIG_OF)
 static struct omap_rng_pdata omap4_rng_pdata = {
.regs   = (u16 *)reg_map_omap4,
.data_size  = OMAP4_RNG_OUTPUT_SIZE,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap 

Re: [PATCH v5 0/4] mtd:nand:omap2: clean-up of supported ECC schemes

[Brian Norris]

On Tue, Aug 20, 2013 at 7:02 AM, Artem Bityutskiy dedeki...@gmail.com wrote:
 On Tue, 2013-08-20 at 13:20 +, Gupta, Pekon wrote:
 Hi Artem, Brian,

 I'll try to go through old e-mails now, and especially ubi/ubifs ones,
 including yours, and I'll let Brian handle your patches, if I can? :-)

Yes, these are on my radar, but I haven't spent any time on them yet.
I will handle them soon.

 I checked them, and they looked good to me:

 Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com

Brian
--
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] mmc: omap_hsmmc: Fix sleep too long in ISR context.

[Hein Tibosch]

Hi,

[ added some people from TI ]

On 8/7/2013 6:05 PM, majianpeng wrote:
 V2: 
   clean up code.
 V1:
   www.mail-archive.com/linux-omap@vger.../msg93239.html‎


 We found a problem when we removed a working sd card that the irqaction
 of omap_hsmmc can sleep to 3.6s. This cause our watchdog to work.
 In func omap_hsmmc_reset_controller_fsm, it should watch a 0-1
 transition.But avoiding endless waiting, it used loops_per_jiffy as the timer.

Tried on a OMAP4460:
This can easily be replicated: just withdraw an SD-card and the kernel
will get blocked during more than 3 seconds.
Calling OMAP_HSMMC_READ() in this loop makes it last so long.

The function waits for a 0=1, followed by a 1=0 transition.
The value of 1 always comes, but in most cases the code is just too
slow to detect it. The first loop will only stop when (i == limit)

 The code is:
 while ((!(OMAP_HSMMC_READ(host-base, SYSCTL)  bit))
 (i++  limit))
cpu_relax();
 But generanly loops_per_jiffy as a timer,it should like:
  while(i++  limit)
 cpu_relax();
 I found for the long time case, the while-opeation stoped because 'i == 
 limit'.
 Because added some code, so the duration became too longer than
 MMC_TIMEOU_US(20ms).

 The software can't monitor the transition of hardware for thi case.

 Becasue those codes in ISR context, it can't use timer_before/after.
 I divived the time into 1ms and used udelay(1) to instead.
 It will cause do additional udelay(1).But from my test,it looks good.

 Reported-by: Yuzheng Ma mayuzh...@kedacom.com
 Tested-by: Yuzheng Ma mayuzh...@kedacom.com
 Reviewed-by: Hein Tibosch hein_tibo...@yahoo.es
 Signed-off-by: Jianpeng Ma majianp...@gmail.com
 ---
  drivers/mmc/host/omap_hsmmc.c | 25 +++--
  1 file changed, 11 insertions(+), 14 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 1865321..bbda5ed 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -973,9 +973,8 @@ static inline void omap_hsmmc_dbg_report_irq(struct 
 omap_hsmmc_host *host,
  static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host 
 *host,
  unsigned long bit)
  {
 - unsigned long i = 0;
 - unsigned long limit = (loops_per_jiffy *
 - msecs_to_jiffies(MMC_TIMEOUT_MS));
 + /*change to 1ms,so we can use udelay(1)*/
 + unsigned long limit = MMC_TIMEOUT_MS * 1000;
  
   OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);

Checked here: the SRC-bit indeed becomes high.
After the test 'features  HSMMC_HAS_UPDATED_RESET', the bit has
become low again already.
Changing to order of statements worked for me, but for Jianpeng Ma
this didn't work (timings are 'on the edge').

This reset function is also called while mounting a card and then 'SRC'
will be high long enough (more than 100 loops). It is after withdrawing
the card that the reset is performed extremely fast.

 @@ -984,17 +983,15 @@ static inline void 
 omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
* OMAP4 ES2 and greater has an updated reset logic.
* Monitor a 0-1 transition first
*/
 - if (mmc_slot(host).features  HSMMC_HAS_UPDATED_RESET) {
 - while ((!(OMAP_HSMMC_READ(host-base, SYSCTL)  bit))
 -  (i++  limit))
 - cpu_relax();
 - }
 - i = 0;
 -
 - while ((OMAP_HSMMC_READ(host-base, SYSCTL)  bit) 
 - (i++  limit))
 - cpu_relax();
 -
 + if (mmc_slot(host).features  HSMMC_HAS_UPDATED_RESET)
 + while (!(OMAP_HSMMC_READ(host-base, SYSCTL)  bit)
 +  limit--)
 + udelay(1);

In this way, the loop will only last about 'MMC_TIMEOUT_MS' ms
and my WDT doesn't get triggered :-)

 + limit = MMC_TIMEOUT_MS * 1000;
 + while ((OMAP_HSMMC_READ(host-base, SYSCTL)  bit)  limit--)
 + udelay(1);
 +
   if (OMAP_HSMMC_READ(host-base, SYSCTL)  bit)
   dev_err(mmc_dev(host-mmc),
   Timeout waiting on controller reset in %s\n,

Anybody an opinion on this?

Thanks, Hein
--
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

OMAP baseline test results for v3.11-rc6

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.11-rc6.
Logs and other details at:

http://www.pwsan.com/omap/testlogs/test_v3.11-rc6/20130818180958/


Test summary


Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
  omap1_defconfig_1510innovator_only,
  omap1_defconfig_5912osk_only, omap2plus_defconfig,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  rmk_omap3430_ldp_allnoconfig,
  rmk_omap3430_ldp_oldconfig,
  rmk_omap4430_sdp_allnoconfig

Build: uImage+dtb:
Pass ( 3/ 3): am33xx_only/am335x-bone,
  omap2plus_defconfig/omap4-panda,
  omap2plus_defconfig/omap4-panda-es

Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
skip ( 1/ 1): 5912osk
Pass (10/10): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm,
  37xxevm, 4430es2panda, 4460pandaes, am335xbone,
  am335xbonelt, cmt3517

PM: chip retention via suspend:
FAIL ( 2/ 6): 2430sdp, 4430es2panda
Pass ( 4/ 6): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes

PM: chip retention via dynamic idle:
FAIL ( 3/ 6): 2430sdp, 4430es2panda, 4460pandaes
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 37xxevm

PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
FAIL ( 2/ 4): 4430es2panda, 4460pandaes
Pass ( 2/ 4): 3530es3beagle, 37xxevm

PM: chip off via dynamic idle:
FAIL ( 2/ 4): 4430es2panda, 4460pandaes
Pass ( 2/ 4): 3530es3beagle, 37xxevm


vmlinux object size
(delta in bytes from test_v3.11-rc5 
(d4e4ab86bcba5a72779c43dc1459f71fea3d89c8)):
   text data  bsstotal  kernel
   +27200 +272  n800_multi_omap2xxx
   +27200 +272  n800_only_a
  +100000+1000  omap1_defconfig
  +198400+1984  omap1_defconfig_1510innovator_only
   +99200 +992  omap1_defconfig_5912osk_only
  +488000+4880  omap2plus_defconfig
   +71200 +712  omap2plus_defconfig_2430sdp_only
   +78400 +784  omap2plus_defconfig_cpupm
   +72000 +720  omap2plus_defconfig_no_pm
   +78400 +784  omap2plus_defconfig_omap2_4_only
   +78400 +784  omap2plus_defconfig_omap3_4_only
   +2960  -32 +264  rmk_omap3430_ldp_allnoconfig
   +44800 +448  rmk_omap3430_ldp_oldconfig
   +2800  -16 +264  rmk_omap4430_sdp_allnoconfig

Boot-time memory difference
(delta in bytes from test_v3.11-rc5 
(d4e4ab86bcba5a72779c43dc1459f71fea3d89c8))
  avail  rsrvd   high  freed  board  kconfig
-8k 8k  .  .  2430sdpomap2plus_defconfig
-8k 8k  .  .  3517evmomap2plus_defconfig
-8k 8k  .  .  3530es3beagle  omap2plus_defconfig
-8k 8k  .  .  3730beaglexm   omap2plus_defconfig
-8k 8k  .  .  37xxevmomap2plus_defconfig
-8k 8k  .  .  4430es2panda   omap2plus_defconfig
-8k 8k  .  .  4460pandaesomap2plus_defconfig
-8k 8k  .  .  am335xbonelt   am33xx_only

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

[Paul Walmsley]

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.


- 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

Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[Chanwoo Choi]

 +
 +if (dra7xx_usb-irq_gpio) {
 +status = devm_request_threaded_irq(dra7xx_usb-dev, irq_num,
 +NULL, id_irq_handler, IRQF_SHARED |
 +IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
 +dev_name(pdev-dev), (void *) dra7xx_usb);
 +if (status)
 +dev_err(dra7xx_usb-dev, failed to request irq #%d\n,
 +irq_num);
 If devm_request_threaded_irq() return fail state, why did not you do add 
 error exception?
 If interrupt fails I fallback to polling thread.
 +else
 +return 0;
 If devm_request_threaded_irq() return success state, why did you directly 
 call 'return'?
 kthread_create operation isn't necessary?
 Yes kthread is optional. Some boards doenot have the ID pin hooked onto the 
 GPIO.
 In such cases we will run the kthread and poll on the ID pin values.
 +}
 +
 +dra7xx_usb-thread_task = kthread_create(id_poll_func, dra7xx_usb,
 + dev_name(pdev-dev));
 Should you use polling method with kthread? I think it isn't proper method.
 You did get the irq number by using DT helper function and register irq 
 handler
 with devm_request_threaded_irq(). I prefer interrupt method for detection 
 of cable state.
 I also prefer interrupt method. If any implementation does not have ID pin 
 connected to GPIOs then still
 it could use the driver in polling mode.
 As I mentioned above, I don't prefer interrupt method for cable detection.
 
 I hope you meant, you prefer interrupt method for cable detection over 
 polling .

Right, my mistake. I prefer interrupt method.

Thanks,
Chanwoo CHoi


--
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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs

[Paul Walmsley]

Hi

a few comments

On Wed, 14 Aug 2013, Suman Anna wrote:

 The remoteproc infrastructure is currently tied closely with the
 virtio/rpmsg framework, and the boot requires that there are virtio
 devices present in the resource table from the firmware image.

Using static channels is something that can be added to the existing code, 
if you don't want to use dynamic channels.

 The rpmsg shared memory buffers are currently kinda fixed (512 buffers 
 of 512 bytes each) and requires 3 pages just for the vring structures 
 for this many buffers. So, if there are restrictions on DDR access, then 
 this pretty much rules out remoteproc/rpmsg infrastructure.

It should be possible to patch that code to vary the size and count of the 
memory buffers, based on the remote processor.  So no direct DDR access 
should be required - for that reason, anyway.

 If the DDR access is ok, then there are other challenges that needs to
 be met. The current firmware definitely requires the addition of the
 resource table and the lower level code for handling the virtio_ring
 transport for receiving messages. It would also need its own remoteproc
 driver for handling the firmware binary format 

Hmm, could you explain this further?  Are you just referring to the 
process of parsing out the dynamic channel data during initialization?

 and the signalling required to trigger the rpmsg buffer processing. The 
 firmware binary format needs to be adapted to something that this driver 
 would understand.  It definitely doesn't look like ELF currently, so 
 something on the lines of ste_modem_rproc needs to be done.

Or just use ELF or static channels.

 Also, the remoteproc/rpmsg infrastructure can support multiple vring 
 transport channels between the processor, and depending on how many are 
 supported, we either need to exchange the vq_id (like OMAP remoteproc), 
 or process the known virtqueues always (like DA8xx remoteproc). The 
 former requires that a message payload is used, and mandates the usage 
 of the IPC data registers in the control module given that WkupM3 on 
 AM335 cannot access any mailbox registers. Any usage of IPC data 
 registers depends on where we do it. If all the accesses were to be done 
 within mach-omap2/control.c, then there is no easy way for using this 
 API from drivers/remoteproc, until we have the control module driver.

Yep, real SCM drivers have been needed for some time now, for pretty much 
all of the OMAP SoCs.  It should be pretty easy to prototype for your 
purposes, though.

 The current communication uses the IPC data registers, and sometimes
 uses them as plain status registers. There's certain registers used for
 sharing status, version etc which are shared by both the processors.
 Using rpmsg would require communicating every single message, and if
 there were to be some shared variables to be used simultaneously, then
 this has to be exchanged through a new remoteproc resource type.

I don't quite understand this last part - shared variables to be used 
simultaneously.  How does the existing code synchronize them?

 One additional aspect is that the current remoteproc core does not have
 the necessary runtime pm support, but in general the approach would be
 to treat the remoteprocs as true slave devices. I would imagine the
 driver core to put the remoteprocs into reset state, after asking them
 to save their context during suspend.

Why is runtime PM support needed in the remoteproc core?  Wouldn't that 
only be needed in the remote processor's device driver?


- 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

Re: [PATCH 3/3] ARM: OMAP4: dts: Add main and optional clock data into DT

[Paul Walmsley]

Hi

On Tue, 23 Jul 2013, Rajendra Nayak wrote:

 With support to parse clock data from DT, move all main and optional
 clock information from hwmod to DT.
 
 We still retain clocks in hwmod for devices which do not have a DT node.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  arch/arm/boot/dts/omap4.dtsi   |  100 +
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  112 
 
  2 files changed, 100 insertions(+), 112 deletions(-)
 
 diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
 index 8e142f9..4dddf64 100644
 --- a/arch/arm/boot/dts/omap4.dtsi
 +++ b/arch/arm/boot/dts/omap4.dtsi
 @@ -106,6 +106,8 @@
   compatible = ti,omap-counter32k;
   reg = 0x4a304000 0x20;
   ti,hwmods = counter_32k;
 + clocks = sys_32k_ck;
 + clock-names = fck;

Shouldn't these patches be using the official DT clock binding format?  
Either the 'clocks' property should be something like:

clocks = prm 10;

or a change to the bindings needs to be discussed and implemented.


- 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

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

[Paul Walmsley]

Hi Benoît,

On Wed, 17 Jul 2013, Mark A. Greer wrote:

 From: Mark A. Greer mgr...@animalcreek.com
 
 Long overdue patches to add the device tree updates and
 documentation for the SHAM and AES modules on the am33xx.
 The supporting code is already in the mainline kernel.
 
 This series is based on the current mainline kernel,
 c0d15cc (linked-list: Remove __list_for_each).
 
 Changes from v1:
  - Added missing '};' as pointed out by Lokesh Vutla lokeshvu...@ti.com

I guess you should take these patches?


- Paul

Re: [PATCH v2 04/14] crypto: omap-aes: Simplify DMA usage by using direct SGs

[Joel Fernandes]

On 08/20/2013 07:57 AM, Lokesh Vutla wrote:
 Hi Joel,
 
 On Sunday 18 August 2013 08:12 AM, Joel Fernandes wrote:
 In early version of this driver, assumptions were made such as DMA layer
 requires contiguous buffers etc. Due to this, new buffers were allocated,
 mapped and used for DMA. These assumptions are no longer true and DMAEngine
 scatter-gather DMA doesn't have such requirements. We simply the DMA 
 operations
 by directly using the scatter-gather buffers provided by the crypto layer
 instead of creating our own.

 Lot of logic that handled DMA'ing only X number of bytes of the total, or as
 much as fitted into a 3rd party buffer is removed and is no longer required.

 Also, good performance improvement of atleast ~20% seen with encrypting a
 buffer size of 8K (1800 ops/sec vs 1400 ops/sec).  Improvement will be higher
 for much larger blocks though such benchmarking is left as an exercise for 
 the
 reader.  Also DMA usage is much more simplified and coherent with rest of the
 code.

 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  drivers/crypto/omap-aes.c |  147 
 -
  1 file changed, 25 insertions(+), 122 deletions(-)

 diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
 index e369e6e..64dd5c1 100644
 --- a/drivers/crypto/omap-aes.c
 +++ b/drivers/crypto/omap-aes.c
 @@ -480,22 +480,14 @@ static int sg_copy(struct scatterlist **sg, size_t 
 *offset, void *buf,
  }
  
  static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
 -struct scatterlist *in_sg, struct scatterlist *out_sg)
 +struct scatterlist *in_sg, struct scatterlist *out_sg,
 +int in_sg_len, int out_sg_len)
  {
  struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
  struct omap_aes_dev *dd = ctx-dd;
  struct dma_async_tx_descriptor *tx_in, *tx_out;
  struct dma_slave_config cfg;
 -dma_addr_t dma_addr_in = sg_dma_address(in_sg);
 -int ret, length = sg_dma_len(in_sg);
 -
 -pr_debug(len: %d\n, length);
 -
 -dd-dma_size = length;
 -
 -if (!(dd-flags  FLAGS_FAST))
 -dma_sync_single_for_device(dd-dev, dma_addr_in, length,
 -   DMA_TO_DEVICE);
 +int ret;
 By this change FLAGS_FAST is unsed, it can be cleaned right?
 or Am I missing something?

Yes, FLAGS_FAST would be unused now and can go away. Since it is very trivial
change, I will make this change in the not-immediate future and submit.

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 1/3] ARM: OMAP2+: hwmod-data: Add SSI information

[Paul Walmsley]

Hi Sebastian

On Sun, 11 Aug 2013, Sebastian Reichel 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

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

The rest looks OK to me, based on a brief look.

... 

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


- Paul

 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  104 
 
  1 file changed, 104 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 0c3a427..74006c4 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -3693,6 +3693,109 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__aes 
 = {
   .user   = OCP_USER_MPU | OCP_USER_SDMA,
  };
  
 +/*
 + * 'ssi' class
 + * synchronous serial interface (multichannel and full-duplex serial if)
 + */
 +
 +static struct omap_hwmod_class_sysconfig omap34xx_ssi_sysc = {
 + .rev_offs   = 0x,
 + .sysc_offs  = 0x0010,
 + .syss_offs  = 0x0014,
 + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_EMUFREE |
 +SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
 +SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
 + .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
 +SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
 +MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
 + .sysc_fields= omap_hwmod_sysc_type1,
 +};
 +
 +static struct omap_hwmod_class omap34xx_ssi_hwmod_class = {
 + .name   = ssi,
 + .sysc   = omap34xx_ssi_sysc,
 +};
 +
 +static struct omap_hwmod_irq_info omap34xx_ssi_irqs[] = {
 + { .name = ssi_p1_mpu_irq0, .irq = 67 },
 + { .name = ssi_p1_mpu_irq1, .irq = 68 },
 + { .name = ssi_p2_mpu_irq0, .irq = 69 },
 + { .name = ssi_p2_mpu_irq1, .irq = 70 },
 + { .name = ssi_gdd_mpu, .irq = 71 },
 + { .irq = -1 },
 +};
 +
 +static struct omap_hwmod_addr_space omap34xx_ssi_addrs[] = {
 + {
 + .name   = sys,
 + .pa_start   = 0x48058000,
 + .pa_end = 0x48058fff,
 + .flags  = ADDR_TYPE_RT,
 + },
 + {
 + /* generic distributed DMA */
 + .name   = gdd,
 + .pa_start   = 0x48059000,
 + .pa_end = 0x48059fff,
 + .flags  = ADDR_TYPE_RT,
 + },
 + {
 + /* port 1: synchronous serial transmitter */
 + .name   = p1_sst,
 + .pa_start   = 0x4805a000,
 + .pa_end = 0x4805a7ff,
 + .flags  = ADDR_TYPE_RT,
 + },
 + {
 + /* port 1: synchronous serial receiver */
 + .name   = p1_ssr,
 + .pa_start   = 0x4805a800,
 + .pa_end = 0x4805afff,
 + .flags  = ADDR_TYPE_RT,
 + },
 + {
 + /* port 2: synchronous serial transmitter */
 + .name   = p2_sst,
 + .pa_start   = 0x4805b000,
 + .pa_end = 0x4805b7ff,
 + .flags  = ADDR_TYPE_RT,
 + },
 + {
 + /* port 2: synchronous serial receiver */
 + .name   = p2_ssr,
 + .pa_start   = 0x4805b800,
 + .pa_end = 0x4805bfff,
 + .flags  = ADDR_TYPE_RT,
 + },
 + {}
 +};
 +
 +static struct omap_hwmod omap34xx_ssi_hwmod = {
 + .name   = ssi,
 + .class  = omap34xx_ssi_hwmod_class,
 + .clkdm_name = l3_init_clkdm,
 + .mpu_irqs   = omap34xx_ssi_irqs,
 + .main_clk   = ssi_ssr_fck,
 + .prcm   = {
 + .omap2 = {
 + .prcm_reg_id= 1,
 + .module_bit = OMAP3430_EN_SSI_SHIFT,
 + .module_offs= WKUP_MOD,
 + .idlest_reg_id  = 1,
 + .idlest_idle_bit= OMAP3430ES2_ST_SSI_IDLE_SHIFT,
 + },
 + },
 +};
 +
 +/* SSI - l3 */
 +static struct omap_hwmod_ocp_if omap34xx_l3__ssi = {
 + .master = omap3xxx_l3_main_hwmod,
 + .slave  = 

Re: [PATCH v5 2/4] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe

[Brian Norris]

On Sun, Jul 14, 2013 at 02:24:49AM +0530, Pekon Gupta wrote:
 ECC scheme on NAND devices can be implemented in multiple ways.Some using
 Software algorithm, while others using in-build Hardware engines.
 omap2-nand driver currently supports following flavours of ECC schemes.
 
 +---+---+---+
 | ECC scheme|ECC calculation|Error detection|
 +---+---+---+
 |OMAP_ECC_HAMMING_CODE_DEFAULT  |S/W|S/W|
 |OMAP_ECC_HAMMING_CODE_HW   |H/W (GPMC) |S/W|
 |OMAP_ECC_HAMMING_CODE_HW_ROMCODE   |H/W (GPMC) |S/W|
 +---+---+---+
 |(requires CONFIG_MTD_NAND_ECC_BCH) |   |   |
 |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
 +---+---+---+
 |(requires CONFIG_MTD_NAND_OMAP_BCH)|   |   |
 |OMAP_ECC_BCH8_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
 +---+---+---+
 
 This patch
 - separates the configurations for various ECC schemes.
 - fixes dependency issues based on Kconfig options.
 - cleans up redundant code
 
 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  drivers/mtd/nand/omap2.c | 505 
 +++
  1 file changed, 249 insertions(+), 256 deletions(-)
 
 diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
 index daa3dfc..ea857cc 100644
 --- a/drivers/mtd/nand/omap2.c
 +++ b/drivers/mtd/nand/omap2.c

[...]

 @@ -2075,11 +2066,13 @@ out_release_mem_region:
   free_irq(info-gpmc_irq_fifo, info);
   release_mem_region(info-phys_base, info-mem_size);
  out_free_info:
 + omap3_free_bch(info-mtd);
   kfree(info);
  
   return err;
  }
  
 +

Extra blank line?

  static int omap_nand_remove(struct platform_device *pdev)
  {
   struct mtd_info *mtd = platform_get_drvdata(pdev);

Brian
--
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/4] mtd:nand:omap2: clean-up of supported ECC schemes

[Brian Norris]

Hi Pekon,

I don't think I will take this series (at least not yet), because of the
device-tree ABI breakage.

On Sun, Jul 14, 2013 at 02:24:47AM +0530, Pekon Gupta wrote:
 
 Changes v4 - v5
 - Rebased to linux-next 
 IMPORTANT: Need to revert commit fb1585b, [PATCH 2/4] part of previous version
   http://lists.infradead.org/pipermail/linux-mtd/2013-July/047441.html
 
 - Swapped PATCH-1  PATCH-2 to maintain bisectibility  compilation dependency
   http://lists.infradead.org/pipermail/linux-mtd/2013-July/047461.html
 
 - PATCH-2: re-ordered call to is_elm_present() for later updates ELM driver
   - dropped changes in include/linux/platform_data/elm.h (not needed)
 - PATCH-3: re-ordered call to is_elm_present() for later updates ELM driver
 - Re-formated patch description (replaced tabs with white-spaces)
 
 
 Changes v3 - v4
 (Resent with CC: devicetree-disc...@lists.ozlabs.org)

Make sure to use devicet...@vger.kernel.org for future series.

 - [Patch 1/3] removed MTD_NAND_OMAP_BCH8  MTD_NAND_OMAP_BCH4 from 
 nand/Kconfig
   ECC scheme selectable via nand DT (nand-ecc-opt).
 - [*] rebased for l2-mtd.git
 
 
 Changes v2 - v3
 (Resent with Author Name fixed)
 - PATCH-1: re-arranged code to remove redundancy, added NAND_BUSWIDTH_AUTO
 - PATCH-2: updated nand-ecc-opt DT mapping and Documentation
 - PATCH-3: code-cleaning + changes to match PATCH-1
 - PATCH-4 DROPPED update DT attribute for ti,nand-ecc-opt 
   - received feedback to keep DT mapping independent of linuxism
 - PATCH-4:NEW : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
   - independent patch for AM335x-evm.dts update based on PATCH-2
 
 
 Changes v1 - v2
   added   [PATCH 3/4] and [PATCH 4/4]

[...]

You might also consider a future patch for utilizing devm_* functions
for the probe/remove routines in drivers/mtd/nand/omap2.c. That could
improve some of the stuff I looked at in this series.

Brian
--
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 00/12] DRA7xx PRCM, hwmod and DT data

[Paul Walmsley]

Hi

On Tue, 9 Jul 2013, Rajendra Nayak wrote:

 This series adds the data files for DRA7xx devices for
 PRCM, hwmod and DT. This is dependent on the core support [1]
 patches for DRA7xx and leaves out the clock data since its
 on its way to DT [2]
 
 The regbit headers for prm and cm are cleaned up post the
 autogeneration as 95% was seen to be currently unused
 (prm-regbits-7xx.h was 100% unused and hence removed)
 
 These patches along with the core support patches are available at:
 git://github.com/rrnayak/linux.git for-3.12/dra-core-data

Is a public TRM available for this chip?

Can development boards be made available to the OMAP maintainers so we can 
ensure that the code, once merged, continues to work?


- 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

Re: [PATCH v2 00/13] ARM: OMAP2+: AM43x PRCM support

[Paul Walmsley]

Hi

On Fri, 2 Aug 2013, Afzal Mohammed wrote:

 AM43x PRCM support (excluding clock tree) is being added with this
 series. AM43x reuses most of the IP's from AM335x, as that is the
 case, much of the AM335x hwmod data is reused.

...

 Currently there is no public TRM available for AM43x.

Can you think of any way that the data can be doublechecked against some 
reference or against the reality of the chip?

Can development boards be made available to the OMAP maintainers so we can 
ensure that the code, once merged, continues to work?

 Powerdomain  Clockdomain data has been added separately as it was not
 giving much advantage reusing AM335x ones (runtime updates required
 was getting too ugly). But as AM43x PRCM functionality is similar to
 OMAP4, power domain, clock domain  hwmod operations are reused from
 OMAP4.

Is the AM43xx PRCM design and IP derived from AM33xx, or from OMAP4, or 
from something else?



- 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

Re: [PATCH v2 06/13] ARM: OMAP2+: PRCM: AM43x definitions

[Paul Walmsley]

On Fri, 2 Aug 2013, Afzal Mohammed wrote:

 Add AM43x CMINST, CDOFFS, RM_RSTST  RM_RSTCTRL definitions - minimal
 ones that would be used.
 
 Signed-off-by: Afzal Mohammed af...@ti.com

...

 +/* PRM instances */
 +#define AM43XX_PRM_OCP_SOCKET_INST   0x
 +#define AM43XX_PRM_MPU_INST  0x0300
 +#define AM43XX_PRM_GFX_INST  0x0400
 +#define AM43XX_PRM_RTC_INST  0x0500
 +#define AM43XX_PRM_TAMPER_INST   0x0600
 +#define AM43XX_PRM_CEFUSE_INST   0x0700
 +#define AM43XX_PRM_PER_INST  0x0800
 +#define AM43XX_PRM_WKUP_INST 0x2000
 +#define AM43XX_PRM_DEVICE_INST   0x4000
 +

...

 +/* CM instances */
 +#define AM43XX_CM_WKUP_INST  0x2800
 +#define AM43XX_CM_DEVICE_INST0x4100
 +#define AM43XX_CM_DPLL_INST  0x4200
 +#define AM43XX_CM_MPU_INST   0x8300
 +#define AM43XX_CM_GFX_INST   0x8400
 +#define AM43XX_CM_RTC_INST   0x8500
 +#define AM43XX_CM_TAMPER_INST0x8600
 +#define AM43XX_CM_CEFUSE_INST0x8700
 +#define AM43XX_CM_PER_INST   0x8800

That's a pretty broad address range to span, in PRCM terms.  Seems pretty 
unlikely that the whole area is really decoded to a single PRCM IP block?  
Or is it actually decoded into smaller PRM and CM sub-blocks, similar to 
OMAP4?

Just by looking at the offsets, it looks to me like you've got:

1. one IP block at 0x-0x1fff? that covers system PRM

2. one IP block at 0x2000-0x3fff? that covers WKUP PRM  CM
  
3. one IP block at 0x4000-? that covers device  PLL PRM  CM

4. one IP block at 0x8000-? that covers system CM



- 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

Re: [PATCH] hwrng: reorder OMAP TRNG driver code

[Lokesh Vutla]

Hi Olof,
On Tuesday 20 August 2013 11:37 PM, Olof Johansson wrote:
 The newly added omap4 support in the driver was added without
 consideration for building older configs. When building omap1_defconfig,
 it resulted in:
 
 drivers/char/hw_random/omap-rng.c:190:12: warning: 'omap4_rng_init' defined 
 but not used [-Wunused-function]
 drivers/char/hw_random/omap-rng.c:215:13: warning: 'omap4_rng_cleanup' 
 defined but not used [-Wunused-function]
 drivers/char/hw_random/omap-rng.c:251:20: warning: 'omap4_rng_irq' defined 
 but not used [-Wunused-function]
 
 Move the code around so it is grouped with its operations struct, which
 for the omap4 case means also under the #ifdef CONFIG_OF, where it needs
 to be.
 
Missed testing this. Thanks for the patch.
Reviewed-by: Lokesh Vutla lokeshvu...@ti.com

Regards,
Lokesh

 Signed-off-by: Olof Johansson o...@lixom.net
 Cc: Lokesh Vutla lokeshvu...@ti.com
 ---
  drivers/char/hw_random/omap-rng.c |  108 
 ++---
  1 file changed, 54 insertions(+), 54 deletions(-)
 
 diff --git a/drivers/char/hw_random/omap-rng.c 
 b/drivers/char/hw_random/omap-rng.c
 index f3f7142..9b89ff4 100644
 --- a/drivers/char/hw_random/omap-rng.c
 +++ b/drivers/char/hw_random/omap-rng.c
 @@ -140,16 +140,6 @@ static inline void omap_rng_write(struct omap_rng_dev 
 *priv, u16 reg,
   __raw_writel(val, priv-base + priv-pdata-regs[reg]);
  }
  
 -static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
 -{
 - return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
 -}
 -
 -static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
 -{
 - return omap_rng_read(priv, RNG_STATUS_REG)  RNG_REG_STATUS_RDY;
 -}
 -
  static int omap_rng_data_present(struct hwrng *rng, int wait)
  {
   struct omap_rng_dev *priv;
 @@ -187,6 +177,60 @@ static int omap_rng_data_read(struct hwrng *rng, u32 
 *data)
   return data_size;
  }
  
 +static int omap_rng_init(struct hwrng *rng)
 +{
 + struct omap_rng_dev *priv;
 +
 + priv = (struct omap_rng_dev *)rng-priv;
 + return priv-pdata-init(priv);
 +}
 +
 +static void omap_rng_cleanup(struct hwrng *rng)
 +{
 + struct omap_rng_dev *priv;
 +
 + priv = (struct omap_rng_dev *)rng-priv;
 + priv-pdata-cleanup(priv);
 +}
 +
 +static struct hwrng omap_rng_ops = {
 + .name   = omap,
 + .data_present   = omap_rng_data_present,
 + .data_read  = omap_rng_data_read,
 + .init   = omap_rng_init,
 + .cleanup= omap_rng_cleanup,
 +};
 +
 +static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
 +{
 + return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
 +}
 +
 +static int omap2_rng_init(struct omap_rng_dev *priv)
 +{
 + omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
 + return 0;
 +}
 +
 +static void omap2_rng_cleanup(struct omap_rng_dev *priv)
 +{
 + omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
 +}
 +
 +static struct omap_rng_pdata omap2_rng_pdata = {
 + .regs   = (u16 *)reg_map_omap2,
 + .data_size  = OMAP2_RNG_OUTPUT_SIZE,
 + .data_present   = omap2_rng_data_present,
 + .init   = omap2_rng_init,
 + .cleanup= omap2_rng_cleanup,
 +};
 +
 +#if defined(CONFIG_OF)
 +static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
 +{
 + return omap_rng_read(priv, RNG_STATUS_REG)  RNG_REG_STATUS_RDY;
 +}
 +
  static int omap4_rng_init(struct omap_rng_dev *priv)
  {
   u32 val;
 @@ -221,33 +265,6 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv)
   omap_rng_write(priv, RNG_CONFIG_REG, val);
  }
  
 -static int omap2_rng_init(struct omap_rng_dev *priv)
 -{
 - omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
 - return 0;
 -}
 -
 -static void omap2_rng_cleanup(struct omap_rng_dev *priv)
 -{
 - omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
 -}
 -
 -static int omap_rng_init(struct hwrng *rng)
 -{
 - struct omap_rng_dev *priv;
 -
 - priv = (struct omap_rng_dev *)rng-priv;
 - return priv-pdata-init(priv);
 -}
 -
 -static void omap_rng_cleanup(struct hwrng *rng)
 -{
 - struct omap_rng_dev *priv;
 -
 - priv = (struct omap_rng_dev *)rng-priv;
 - priv-pdata-cleanup(priv);
 -}
 -
  static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
  {
   struct omap_rng_dev *priv = dev_id;
 @@ -275,23 +292,6 @@ static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
   return IRQ_HANDLED;
  }
  
 -static struct hwrng omap_rng_ops = {
 - .name   = omap,
 - .data_present   = omap_rng_data_present,
 - .data_read  = omap_rng_data_read,
 - .init   = omap_rng_init,
 - .cleanup= omap_rng_cleanup,
 -};
 -
 -static struct omap_rng_pdata omap2_rng_pdata = {
 - .regs   = (u16 *)reg_map_omap2,
 - .data_size  = OMAP2_RNG_OUTPUT_SIZE,
 - .data_present   = omap2_rng_data_present,
 - .init   = omap2_rng_init,
 - .cleanup= omap2_rng_cleanup,
 -};
 -
 -#if 

[PATCH v11 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

[Kishon Vijay Abraham I]

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 drivers/phy/phy-twl4030-usb.c |   57 ++---
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 494f107..c437211 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, 
int on)
}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
if (twl-asleep)
-   return;
+   return 0;
 
twl4030_phy_power(twl, 0);
twl-asleep = 1;
dev_dbg(twl-dev, %s\n, __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-   struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-   twl4030_phy_suspend(twl, 0);
return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
if (!twl-asleep)
-   return;
-   __twl4030_phy_resume(twl);
+   return 0;
+   __twl4030_phy_power_on(twl);
twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
cancel_delayed_work(twl-id_workaround_work);
schedule_delayed_work(twl-id_workaround_work, HZ);
}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-   struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-   twl4030_phy_resume(twl);
return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct 
*work)
}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-   struct twl4030_usb *twl = phy_to_twl(phy);
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
enum omap_musb_vbus_id_status status;
 
/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl-linkstat);
-   twl4030_phy_resume(twl);
+   twl4030_phy_power_on(phy);
}
 
sysfs_notify(twl-dev-kobj, NULL, vbus);
return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-   struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-   return twl4030_usb_phy_init(twl-phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-   struct twl4030_usb *twl = phy_to_twl(x);
-
-   if (suspend)
-   twl4030_phy_suspend(twl, 1);
-   else
-   twl4030_phy_resume(twl);
-
-   return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
 {
@@ -719,8 +690,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.label  = twl4030;
twl-phy.otg= otg;
twl-phy.type   = USB_PHY_TYPE_USB2;
-   twl-phy.set_suspend= twl4030_set_suspend;
-   twl-phy.init   = twl4030_usb_phy_init;
 
otg-phy= twl-phy;
otg-set_host   = twl4030_set_host;
-- 
1.7.10.4

--
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 v11 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 drivers/phy/phy-omap-usb2.c |   25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 25e0f3c..dec3fab 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-   u32 ret;
-   struct omap_usb *phy = phy_to_omapusb(x);
-
-   if (suspend  !phy-is_suspended) {
-   omap_control_usb_phy_power(phy-control_dev, 0);
-   pm_runtime_put_sync(phy-dev);
-   phy-is_suspended = 1;
-   } else if (!suspend  phy-is_suspended) {
-   ret = pm_runtime_get_sync(phy-dev);
-   if (ret  0) {
-   dev_err(phy-dev, get_sync failed with err %d\n,
-   ret);
-   return ret;
-   }
-   omap_control_usb_phy_power(phy-control_dev, 1);
-   phy-is_suspended = 0;
-   }
-
-   return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
phy-phy.dev= phy-dev;
phy-phy.label  = omap-usb2;
-   phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type   = USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   phy-is_suspended   = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
 
otg-set_host   = omap_usb_set_host;
-- 
1.7.10.4

--
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 v11 5/8] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |6 ++
 arch/arm/boot/dts/omap3-beagle-xm.dts  |2 ++
 arch/arm/boot/dts/omap3-evm.dts|2 ++
 arch/arm/boot/dts/omap3-overo.dtsi |2 ++
 arch/arm/boot/dts/omap4.dtsi   |3 +++
 arch/arm/boot/dts/twl4030.dtsi |1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be 50. This signifies the controller can supply up to
100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num-eps = 16;
ram-bits = 12;
ctrl-module = omap_control_usb;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be ti,omap-usb2
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+   #phy-cells = 0;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in reg.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
  0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb;
+   #phy-cells = 0;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
 usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
mode = 3;
power = 50;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
 usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
mode = 3;
power = 50;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
 usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
mode = 3;
power = 50;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+   #phy-cells = 0;
};
};
 
@@ -658,6 +659,8 @@
  

[PATCH v11 6/8] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb-xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/musb/Kconfig |1 +
 drivers/usb/musb/musb_core.h |2 ++
 drivers/usb/musb/omap2430.c  |   26 --
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 797e3fd..25e2e57 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,6 +76,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
tristate OMAP2430 and onwards
depends on ARCH_OMAP2PLUS
+   select GENERIC_PHY
 
 config USB_MUSB_AM35X
tristate AM35x
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..6e567bd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include linux/usb.h
 #include linux/usb/otg.h
 #include linux/usb/musb.h
+#include linux/phy/phy.h
 
 struct musb;
 struct musb_hw_ep;
@@ -346,6 +347,7 @@ struct musb {
u16 int_tx;
 
struct usb_phy  *xceiv;
+   struct phy  *phy;
 
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..063773a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   if (dev-parent-of_node)
+   if (dev-parent-of_node) {
+   musb-phy = devm_phy_get(dev-parent, usb2-phy);
+
+   /* We can't totally remove musb-xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
-   else
+   } else {
musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+   musb-phy = devm_phy_get(dev, usb);
+   }
 
if (IS_ERR(musb-xceiv)) {
status = PTR_ERR(musb-xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
return -EPROBE_DEFER;
}
 
+   if (IS_ERR(musb-phy)) {
+   pr_err(HS USB OTG: no PHY configured\n);
+   return PTR_ERR(musb-phy);
+   }
musb-isr = omap2430_musb_interrupt;
 
status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
if (glue-status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
 
-   usb_phy_init(musb-xceiv);
+   phy_init(musb-phy);
 
pm_runtime_put_noidle(musb-controller);
return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
del_timer_sync(musb_idle_timer);
 
omap2430_low_level_exit(musb);
+   phy_exit(musb-phy);
 
return 0;
 }
@@ -638,7 +653,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
 
omap2430_low_level_exit(musb);
-   usb_phy_set_suspend(musb-xceiv, 1);
+   phy_power_off(musb-phy);
}
 
return 0;
@@ -653,8 +668,7 @@ static int omap2430_runtime_resume(struct device *dev)
omap2430_low_level_init(musb);
musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
-
-   usb_phy_set_suspend(musb-xceiv, 0);
+   phy_power_on(musb-phy);
}
 
return 0;
-- 
1.7.10.4

--
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 v11 4/8] arm: omap3: twl: add phy consumer data in twl4030_usb_data

[Kishon Vijay Abraham I]

The PHY framework uses the phy consumer data populated in platform data in the
case of non-dt boot to return the reference to the PHY when the controller
(PHY consumer) requests for it. So populated the phy consumer data in the 
platform
data of twl usb.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/mach-omap2/twl-common.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..b0d54da 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -24,6 +24,7 @@
 #include linux/i2c/twl.h
 #include linux/gpio.h
 #include linux/string.h
+#include linux/phy/phy.h
 #include linux/regulator/machine.h
 #include linux/regulator/fixed.h
 
@@ -90,8 +91,18 @@ void __init omap_pmic_late_init(void)
 }
 
 #if defined(CONFIG_ARCH_OMAP3)
+struct phy_consumer consumers[] = {
+   PHY_CONSUMER(musb-hdrc.0, usb),
+};
+
+struct phy_init_data init_data = {
+   .consumers = consumers,
+   .num_consumers = ARRAY_SIZE(consumers),
+};
+
 static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode   = T2_USB_MODE_ULPI,
+   .init_data  = init_data,
 };
 
 static int omap3_batt_table[] = {
-- 
1.7.10.4

--
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 v11 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Cc: Tomasz Figa t.f...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 .../devicetree/bindings/phy/phy-bindings.txt   |   66 ++
 Documentation/phy.txt  |  166 +
 MAINTAINERS|8 +
 drivers/Kconfig|2 +
 drivers/Makefile   |2 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |5 +
 drivers/phy/phy-core.c |  698 
 include/linux/phy/phy.h|  270 
 9 files changed, 1235 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier;  The meaning of all those
+   cells is defined by the binding for the phy node. The PHY
+   provider can use the values in cells to find the appropriate
+   PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg = ...;
+.
+.
+#phy-cells = 1;
+.
+.
+};
+
+That node describes an IP block (PHY provider) that implements 2 different 
PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should 
be
+given while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = usb2_phy, usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = phys 1;
+phy-names = usbphy;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+1 to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..0103e4b
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,166 @@
+   PHY SUBSYSTEM
+ Kishon Vijay Abraham I kis...@ti.com
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the 

[PATCH v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/phy/Kconfig   |   12 +
 drivers/phy/Makefile  |1 +
 drivers/{usb = }/phy/phy-omap-usb2.c |   45 ++---
 drivers/usb/phy/Kconfig   |   10 
 drivers/usb/phy/Makefile  |1 -
 5 files changed, 54 insertions(+), 15 deletions(-)
 rename drivers/{usb = }/phy/phy-omap-usb2.c (88%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..38c3477 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,16 @@ config GENERIC_PHY
  phy users can obtain reference to the PHY. All the users of this
  framework should select this config.
 
+config OMAP_USB2
+   tristate OMAP USB2 PHY Driver
+   depends on ARCH_OMAP2PLUS
+   select GENERIC_PHY
+   select USB_PHY
+   select OMAP_CONTROL_USB
+   help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ed5b088 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
+obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
similarity index 88%
rename from drivers/usb/phy/phy-omap-usb2.c
rename to drivers/phy/phy-omap-usb2.c
index 844ab68..25e0f3c 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include linux/pm_runtime.h
 #include linux/delay.h
 #include linux/usb/omap_control_usb.h
+#include linux/phy/phy.h
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
suspend)
return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   omap_control_usb_phy_power(phy-control_dev, 0);
+
+   return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   omap_control_usb_phy_power(phy-control_dev, 1);
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .power_on   = omap_usb_power_on,
+   .power_off  = omap_usb_power_off,
+   .owner  = THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
struct omap_usb *phy;
+   struct phy  *generic_phy;
struct usb_otg  *otg;
+   struct phy_provider *phy_provider;
 
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.otg= otg;
phy-phy.type   = USB_PHY_TYPE_USB2;
 
+   phy_provider = devm_of_phy_provider_register(phy-dev,
+   of_phy_simple_xlate);
+   if (IS_ERR(phy_provider))
+   return PTR_ERR(phy_provider);
+
phy-control_dev = omap_get_control_dev();
if (IS_ERR(phy-control_dev)) {
dev_dbg(pdev-dev, Failed to get control device\n);
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg-start_srp  = omap_usb_start_srp;
otg-phy= phy-phy;
 
+   platform_set_drvdata(pdev, phy);
+   pm_runtime_enable(phy-dev);
+
+   generic_phy = devm_phy_create(phy-dev, ops, NULL);
+   if (IS_ERR(generic_phy))
+   return PTR_ERR(generic_phy);
+
+   phy_set_drvdata(generic_phy, phy);
+
phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
if (IS_ERR(phy-wkupclk)) {
dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
usb_add_phy_dev(phy-phy);
 
-   platform_set_drvdata(pdev, phy);
-
-   pm_runtime_enable(phy-dev);
-
return 0;
 }
 
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..7813238 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -72,16 +72,6 @@ config 

[PATCH v11 0/8] PHY framework

[Kishon Vijay Abraham I]

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem
to use extcon framwork will have to be analysed.

You can find this patch series @
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing

I'll create a new branch *next* once this patch series is finalized. All the
PHY driver development that depends on PHY framework can be based on this
branch.

Did USB enumeration testing in panda and beagle after applying [1]

[1] - https://lkml.org/lkml/2013/7/26/88

Changes from v10:
* fixed a mistake in devm_of_phy_provider_register macro which was carried over 
from earlier version.
* used ida_simple_get for obtaining the id.

Changes from v9:
* Fixed Greg's concern on having *find PHY by string* and changed it to Tomasz
  pseudo code.
* move omap-usb2 phy and twl4030-usb phy to drivers/phy
* made all the dependent drivers select GENERIC_PHY instead of having depends
  on
* Made PHY core to assign the id's (so changed the phy_create API).
* Adapted twl4030-usb to the new design.

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
  using phy_set_drvdata now.
Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
  phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
  disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
  be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
  by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy 
providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added 

[PATCH v11 3/8] usb: phy: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed. Also twl4030-usb driver is moved
to drivers/phy/.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 drivers/phy/Kconfig |   11 ++
 drivers/phy/Makefile|1 +
 drivers/{usb = }/phy/phy-twl4030-usb.c |   56 +--
 drivers/usb/phy/Kconfig |9 -
 drivers/usb/phy/Makefile|1 -
 include/linux/i2c/twl.h |2 ++
 6 files changed, 67 insertions(+), 13 deletions(-)
 rename drivers/{usb = }/phy/phy-twl4030-usb.c (95%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 38c3477..ac239ac 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,4 +27,15 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config TWL4030_USB
+   tristate TWL4030 USB Transceiver Driver
+   depends on TWL4030_CORE  REGULATOR_TWL4030  USB_MUSB_OMAP2PLUS
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this to support the USB OTG transceiver on TWL4030
+ family chips (including the TWL5030 and TPS659x0 devices).
+ This transceiver supports high and full speed devices plus,
+ in host mode, low speed.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ed5b088..0dd8a98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
similarity index 95%
rename from drivers/usb/phy/phy-twl4030-usb.c
rename to drivers/phy/phy-twl4030-usb.c
index 8f78d2d..494f107 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include linux/io.h
 #include linux/delay.h
 #include linux/usb/otg.h
+#include linux/phy/phy.h
 #include linux/usb/musb-omap.h
 #include linux/usb/ulpi.h
 #include linux/i2c/twl.h
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, 
int controller_off)
dev_dbg(twl-dev, %s\n, __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+   twl4030_phy_suspend(twl, 0);
+   return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+   twl4030_phy_resume(twl);
+   return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
status = twl4030_usb_linkstat(twl);
twl-linkstat = status;
 
-   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl-linkstat);
+   twl4030_phy_resume(twl);
+   }
 
sysfs_notify(twl-dev-kobj, NULL, vbus);
return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+   return twl4030_usb_phy_init(twl-phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,23 @@ static int twl4030_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
 }
 
+static const struct phy_ops ops = {
+   .init   = twl4030_phy_init,
+   .power_on   = twl4030_phy_power_on,
+   .power_off  = twl4030_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
struct twl4030_usb_data *pdata = pdev-dev.platform_data;
struct twl4030_usb  *twl;
+   struct phy  *phy;
int status, err;
struct usb_otg  *otg;
struct device_node  *np = pdev-dev.of_node;
+   struct phy_provider *phy_provider;
+   struct phy_init_data