Re: [PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Sergei Shtylyov]

Hello.

On 12/18/2015 1:21 PM, Kishon Vijay Abraham I wrote:


Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I 
---
   arch/arm/boot/dts/dra7.dtsi |5 +
   1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
   compatible = "syscon";
   reg = <0x1c04 0x0020>;
   };
+
+scm_conf_pcie: tisyscon@1c24 {


Please use the generic node names as the ePAPR standard says.


something like  scm_conf_pcie: syscon@1c24??


   Yes, though "system-controller" would be probably more in line with what 
ePAPR has standardized.



Thanks
Kishon


MBR, Sergei

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

Re: [PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Sergei Shtylyov]

Hello.

On 12/15/2015 12:39 PM, Kishon Vijay Abraham I wrote:


Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I 
---
  arch/arm/boot/dts/dra7.dtsi |5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {


   Please use the generic node names as the ePAPR standard says.

[...]

MBR, Sergei

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

Re: [PATCH 3/5] Add device tree support for M-USB on AM35xx SOCs

[Sergei Shtylyov]

Hello.

On 10/23/2015 6:51 PM, Rolf Peukert wrote:


Add a function that sets up necessary data structures. In older kernels
this was done in a board_ file. To support initialization via a DT, this
now needs to be included in the probe() function.
Also declare a new device 'compatible' name (am35x-musb) to
differentiate it from omap3-musb.

Signed-off-by: Rolf Peukert 
---
  drivers/usb/musb/am35x.c | 73

  1 file changed, 73 insertions(+)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index c41fe58..3c1477a 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -462,6 +462,59 @@ static const struct platform_device_info
am35x_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
  };

+static struct musb_hdrc_platform_data *am35x_get_config(
+   struct platform_device *pdev)
+{

[...]

+   /* Read settings from device tree */
+   np = pdev->dev.of_node;
+   if (np) {
+   of_property_read_u32(np, "mode", (u32 *)>mode);
+   of_property_read_u32(np, "interface-type",
+   (u32 *)>interface_type);
+   of_property_read_u32(np, "num-eps", (u32 *)>num_eps);
+   of_property_read_u32(np, "ram-bits", (u32 *)>ram_bits);
+   of_property_read_u32(np, "power", (u32 *)>power);
+
+   ret = of_property_read_u32(np, "multipoint", );
+   if (!ret && val)
+   config->multipoint = true;


   These are common MUSB traits, so I think should be parsed by a generic 
function. If at all -- they might be determined from the "compatible" prop.


MBR, Sergei

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

Re: [PATCH 5/5] Add information about the new DT device name

[Sergei Shtylyov]

Hello.

On 10/23/2015 06:57 PM, Rolf Peukert wrote:


Add some information about the new device name to the DT documentation.

Signed-off-by: Rolf Peukert 
---
  Documentation/devicetree/bindings/usb/omap-usb.txt | 35
++
  1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8..cf98f61 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -78,3 +78,38 @@ omap_dwc3 {
ranges;
  };

+AM35x MUSB GLUE
+ - compatible : Should be "ti,am35x-musb"


   Wildcards in  "compatible" are not allowed; you should select a "least 
common denominator" model and use it.



+ - ti,hwmods : must be "am35x_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.


   Hm, I would think this should be boolean prop...


+ - num-eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - interface-type : Should be set to "1". (The AM35xx SOCs feature an
+   integrated phy, connected via UTMI+)


   Again, maybe boolean?


+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"


   There's already standardized "dr_mode" prop for that.


+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply up to
+   100mA when operating in host mode.


   Why not just exparess it in mA?

MBR, 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 5/8] dwc3-pci: use PCI_VDEVICE() instead of PCI_DEVICE()

[Sergei Shtylyov]

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
 drivers/usb/dwc3/dwc3-pci.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

Index: usb/drivers/usb/dwc3/dwc3-pci.c
===
--- usb.orig/drivers/usb/dwc3/dwc3-pci.c
+++ usb/drivers/usb/dwc3/dwc3-pci.c
@@ -174,16 +174,13 @@ static void dwc3_pci_remove(struct pci_d
 }
 
 static const struct pci_device_id dwc3_pci_id_table[] = {
-   {
-   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
-   PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
-   },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
-   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL_USB), },
+   { PCI_VDEVICE(SYNOPSYS, PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BSW), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BYT), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
+   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_NL_USB), },
{  }/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);

--
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 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Sergei Shtylyov]

Hello.

On 09/03/2015 05:01 PM, Roger Quadros wrote:


We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.

Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.

Signed-off-by: Roger Quadros 
---
   drivers/usb/dwc3/core.c | 27 +--
   1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 654aebf..25891e3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
   dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
   dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
   dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
+dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
+disable_irq(dwc->otg_irq);
   }

-switch (dwc->dr_mode) {
-case USB_DR_MODE_PERIPHERAL:
-case USB_DR_MODE_OTG:
+if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
+((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


Hm, you're not very consistent about your parens. :-)


You're right. Should be

if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) ||
 ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


   Parens around == are useless, I'd prefer if you deleted them. But if you'd 
like to keep them, let it be so. :-)



--
cheers,
-roger


MBR, Sergei

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

Re: [PATCH v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Sergei Shtylyov]

On 09/03/2015 05:10 PM, Roger Quadros wrote:


We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.

Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.

Signed-off-by: Roger Quadros 
---
drivers/usb/dwc3/core.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 654aebf..25891e3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
+dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
+disable_irq(dwc->otg_irq);
}

-switch (dwc->dr_mode) {
-case USB_DR_MODE_PERIPHERAL:
-case USB_DR_MODE_OTG:
+if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
+((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


 Hm, you're not very consistent about your parens. :-)


You're right. Should be

if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) ||
  ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


Parens around == are useless, I'd prefer if you deleted them. But if you'd 
like to keep them, let it be so. :-)



OK, how about this then?



if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
 (dwc->dr_mode == USB_DR_MODE_OTG && dwc->fsm->protocol == PROTO_GADGET))


   Strictly speaking, parens around && are also not needed but gcc may 
probably issue a warning without them. Not sure, your call.



cheers,
-roger


MBR, Sergei

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

Re: [PATCH v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Sergei Shtylyov]

Hello.

On 09/02/2015 05:24 PM, Roger Quadros wrote:


We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.

Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.

Signed-off-by: Roger Quadros 
---
  drivers/usb/dwc3/core.c | 27 +--
  1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 654aebf..25891e3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
+   dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
+   disable_irq(dwc->otg_irq);
}

-   switch (dwc->dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
+   ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


   Hm, you're not very consistent about your parens. :-)

[...]

@@ -1506,18 +1503,12 @@ static int dwc3_resume(struct device *dev)
dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl);
dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt);
dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten);
+   enable_irq(dwc->otg_irq);
}

-   switch (dwc->dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
+   ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


   Same here...

[...]

WBR, Sergei

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

Re: [PATCH] net/smsc911x: Fix deferred probe for interrupt

[Sergei Shtylyov]

Hello.

On 08/31/2015 05:03 PM, Grygorii Strashko wrote:


The interrupt handler may not be available when smsc911x probes if the
interrupt handler is a GPIO controller for example. Let's fix that
by adding handling for -EPROBE_DEFER.



Cc: Steve Glendinning 
Signed-off-by: Tony Lindgren 
---
   drivers/net/ethernet/smsc/smsc911x.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 959aeea..cb9f166f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2435,7 +2435,10 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
   res_size = resource_size(res);

   irq = platform_get_irq(pdev, 0);
-if (irq <= 0) {
+if (irq == -EPROBE_DEFER) {
+retval = -EPROBE_DEFER;
+goto out_0;
+} else if (irq <= 0) {
   pr_warn("Could not allocate irq resource\n");
   retval = -ENODEV;


 I'd propagate the error code from platfrom_get_irq() instead (in
fact, I've submitted a couple of such patches yesterday and they have
been already merged).



Have you paid some attention on current platform_get_irq_() implementation?



The platform_get_irq() can return 0 in case of DT-boot.


   This is what's indeed worth filtering out and converting to -ENODEV. ;-)
But my patches just ignored this possibility. I'm not at all fond of Linus' 
idea about IRQ0 being invalid, BTW...


WBR, Sergei

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

Re: [PATCH] net/smsc911x: Fix deferred probe for interrupt

[Sergei Shtylyov]

Hello.

On 8/28/2015 9:50 PM, Tony Lindgren wrote:


The interrupt handler may not be available when smsc911x probes if the
interrupt handler is a GPIO controller for example. Let's fix that
by adding handling for -EPROBE_DEFER.



Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/net/ethernet/smsc/smsc911x.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c 
b/drivers/net/ethernet/smsc/smsc911x.c
index 959aeea..cb9f166f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2435,7 +2435,10 @@ static int smsc911x_drv_probe(struct platform_device 
*pdev)
res_size = resource_size(res);

irq = platform_get_irq(pdev, 0);
-   if (irq = 0) {
+   if (irq == -EPROBE_DEFER) {
+   retval = -EPROBE_DEFER;
+   goto out_0;
+   } else if (irq = 0) {
pr_warn(Could not allocate irq resource\n);
retval = -ENODEV;


   I'd propagate the error code from platfrom_get_irq() instead (in fact, 
I've submitted a couple of such patches yesterday and they have been already 
merged).


[...]

NBR, Sergei

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

Re: [PATCH v2 4/6] usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter

[Sergei Shtylyov]

Hello.

On 7/24/2015 9:47 AM, Kishon Vijay Abraham I wrote:


No functional change. Added a new parameter in _dwc3_ep0_start_trans_ to
indicate whether the TRB is a chained TRB or last TRB. This is in
preparation for adding chained TRB support for ep0.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
  drivers/usb/dwc3/ep0.c |   15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)



diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 4998074..d1a2be1 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state 
state)
  }

  static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t 
buf_dma,
-   u32 len, u32 type)
+   u32 len, u32 type, unsigned chain)


   I'm seeing you always pass *false*, so why not just *bool* here?

[...]

WBR, Sergei

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

Re: [PATCH v2 47/48] usb: musb: gadget: add musb_match_ep() function

[Sergei Shtylyov]

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.



Signed-off-by: Robert Baldyga r.bald...@samsung.com


[...]

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 043248a..5f1eb35 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1684,6 +1684,49 @@ static int musb_gadget_pullup(struct usb_gadget *gadget, 
int is_on)
return 0;
  }

+#ifdef CONFIG_BLACKFIN
+static struct usb_ep *musb_find_ep(struct usb_gadget *g,
+   const char *name)
+{
+   struct usb_ep *ep;
+
+   list_for_each_entry(ep, g-ep_list, ep_list) {
+   if (0 == strcmp(ep-name, name))


   Please make the immediate value the 2nd operand of ==.


+   return ep;
+   }
+
+   return NULL;
+}
+
+static struct usb_ep *match_match_ep(struct usb_gadget *g,
+   struct usb_endpoint_descriptor *desc,
+   struct usb_ss_ep_comp_descriptor *ep_comp)
+{
+   struct usb_ep *ep = NULL;
+   u8 type = usb_endpoint_type(desc);
+
+   if ((USB_ENDPOINT_XFER_BULK == type) ||
+   (USB_ENDPOINT_XFER_ISOC == type)) {


   Likewise.


+   if (USB_DIR_IN  desc-bEndpointAddress)


   The same about .


+   ep = musb_find_ep(g, ep5in);
+   else
+   ep = musb_find_ep(g, ep6out);
+   } else if (USB_ENDPOINT_XFER_INT == type) {


   Likewise.


+   if (USB_DIR_IN  desc-bEndpointAddress)
+   ep = musb_find_ep(g, ep1in);
+   else
+   ep = musb_find_ep(g, ep2out);
+   }


   This string of *if* statements is asking to be *switch* instead.

[...]

WBR, Sergei

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

Re: [PATCH v2 45/48] usb: gadget: net2280: add net2280_match_ep() function

[Sergei Shtylyov]

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


Add 'match_ep' callback to utilize chip-specific knowledge in endpoint matching
process. Functions does the same that was done by chip-specific code inside
of epautoconf. Now this code can be removed from there to separate generic code
from platform specific logic.



Signed-off-by: Robert Baldyga r.bald...@samsung.com


[...]

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 0295cf7..4933321 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1533,6 +1533,49 @@ static int net2280_pullup(struct usb_gadget *_gadget, 
int is_on)
return 0;
  }

+static struct usb_ep *net2280_find_ep(struct usb_gadget *_gadget,
+   const char *name)


   Shouldn't this be a generic function as before?


+{
+   struct usb_ep *ep;
+
+   list_for_each_entry(ep, _gadget-ep_list, ep_list) {
+   if (0 == strcmp(ep-name, name))


   Please make 0 the 2nd operand to ==.


+   return ep;
+   }
+
+   return NULL;
+}

[...]

WBR, Sergei

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

Re: [PATCH v2 42/48] usb: gadget: epautoconf: use 'ep_match' gadget callback

[Sergei Shtylyov]

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


If gadget has set 'ep_match' callback we prefer to call it first to allow
UDC driver to find the best matching endpoint basing on chip-specific best
usage knowledge.



Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
  drivers/usb/gadget/epautoconf.c | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index ee0d4e6..92a1a4c 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -165,6 +165,12 @@ struct usb_ep *usb_ep_autoconfig_ss(

type = desc-bmAttributes  USB_ENDPOINT_XFERTYPE_MASK;

+   if (gadget-ops-match_ep) {
+   ep = gadget-ops-match_ep(gadget, desc, ep_comp);
+   if (ep)
+   goto found_ep;
+   }
+


   I think this patch should be merged with the previous one.

[...]

WBR, Sergei

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

Re: [PATCH v2 48/48] usb: gadget: epautoconf: cleanup dead code

[Sergei Shtylyov]

Hello.

On 7/14/2015 12:39 PM, Robert Baldyga wrote:


Function find_ep() is no longer needed here, so we can remove it.
We also don't use anything from gadget_chips.h header any longer.



Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
  drivers/usb/gadget/epautoconf.c | 14 --
  1 file changed, 14 deletions(-)



diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index e9a8682..9a80925 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -20,20 +20,6 @@
  #include linux/usb/ch9.h
  #include linux/usb/gadget.h

-#include gadget_chips.h
-
-static struct usb_ep *
-find_ep (struct usb_gadget *gadget, const char *name)
-{
-   struct usb_ep   *ep;
-
-   list_for_each_entry (ep, gadget-ep_list, ep_list) {
-   if (0 == strcmp (ep-name, name))
-   return ep;
-   }
-   return NULL;
-}
-


   I don't think duplicating the function in each driver that needs it is 
better than turniong this function into public.


WBR, Sergei

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

Re: [PATCH v3 4/9] usb: dwc3: core: Adapt to named interrupts

[Sergei Shtylyov]

Hello.

On 7/8/2015 1:36 PM, Roger Quadros wrote:


From: Felipe Balbi ba...@ti.com



Add support to use interrupt names,



Following are the interrupt names



Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interrupt - otg



[Roger Q]
- If any of these are missing we use the
first available IRQ resource so that we don't
break with older DTBs.



- Use gadget_irq in gadget driver.



Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
  drivers/usb/dwc3/core.c   | 12 
  drivers/usb/dwc3/core.h   |  7 +++
  drivers/usb/dwc3/gadget.c |  2 +-
  3 files changed, 20 insertions(+), 1 deletion(-)



diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a7498e0..7b33d7b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -941,6 +941,18 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-xhci_resources[1].flags = res-flags;
dwc-xhci_resources[1].name = res-name;

+   dwc-otg_irq = platform_get_irq_byname(pdev, otg);
+   if (!dwc-otg_irq)


   The usual mistake repeated again: that function reutrns error # on 
failure, not 0.



+   dwc-otg_irq = res-start;
+
+   dwc-gadget_irq = platform_get_irq_byname(pdev, peripheral);
+   if (!dwc-gadget_irq)
+   dwc-gadget_irq = res-start;


   Likewise.


+
+   dwc-xhci_irq = platform_get_irq_byname(pdev, host);
+   if (!dwc-xhci_irq)


   Likewise.

[...]

WBR, Sergei

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

Re: [PATCH v3 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Sergei Shtylyov]

Hello.

On 7/8/2015 1:37 PM, Roger Quadros wrote:


We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.



Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.



Signed-off-by: Roger Quadros rog...@ti.com
---
  drivers/usb/dwc3/core.c | 27 +--
  1 file changed, 9 insertions(+), 18 deletions(-)



diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e3c094d..3784287 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1444,18 +1444,15 @@ static int dwc3_suspend(struct device *dev)
dwc-octl = dwc3_readl(dwc-regs, DWC3_OCTL);
dwc-oevt = dwc3_readl(dwc-regs, DWC3_OEVT);
dwc-oevten = dwc3_readl(dwc-regs, DWC3_OEVTEN);
+   dwc3_writel(dwc-regs, DWC3_OEVTEN, 0);
+   disable_irq(dwc-otg_irq);
}

-   switch (dwc-dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   if (dwc-dr_mode == USB_DR_MODE_PERIPHERAL ||
+   ((dwc-dr_mode == USB_DR_MODE_OTG)  dwc-fsm-protocol == 
PROTO_GADGET))


   Hum, enclosing the first == op into parens and not doing it to the second 
== op doesn't look very consistent... :-)


[...]

@@ -1495,18 +1492,12 @@ static int dwc3_resume(struct device *dev)
dwc3_writel(dwc-regs, DWC3_OCTL, dwc-octl);
dwc3_writel(dwc-regs, DWC3_OEVT, dwc-oevt);
dwc3_writel(dwc-regs, DWC3_OEVTEN, dwc-oevten);
+   enable_irq(dwc-otg_irq);
}

-   switch (dwc-dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   if (dwc-dr_mode == USB_DR_MODE_PERIPHERAL ||
+   ((dwc-dr_mode == USB_DR_MODE_OTG)  dwc-fsm-protocol == 
PROTO_GADGET))


   Same here...

[...]

WBR, Sergei

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

Re: [PATCH 4/5] usb: dwc3: ep0: Add chained TRB support

[Sergei Shtylyov]

Hello.

On 06/10/2015 12:18 PM, Kishon Vijay Abraham I wrote:


Add chained TRB support to ep0. Now TRB's can be chained just by
invoking _dwc3_ep0_start_trans_ with 'chain' parameter set to true.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
  drivers/usb/dwc3/ep0.c|   16 +---
  drivers/usb/dwc3/gadget.c |2 +-
  2 files changed, 14 insertions(+), 4 deletions(-)



diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index d1a2be1..6847afe 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c

[...]

@@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, 
dma_addr_t buf_dma,
trb-ctrl = type;

trb-ctrl |= (DWC3_TRB_CTRL_HWO
-   | DWC3_TRB_CTRL_LST
-   | DWC3_TRB_CTRL_IOC
| DWC3_TRB_CTRL_ISP_IMI);

+   if (chain)
+   trb-ctrl |= DWC3_TRB_CTRL_CHN;
+   else
+   trb-ctrl |= (DWC3_TRB_CTRL_IOC
+   | DWC3_TRB_CTRL_LST);


   Parens not needed here (and above too).

[...]

WBR, Sergei

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

Re: [PATCH 2/5] usb: dwc3: ep0: preparation for handling non maxpacket aligned transfers 512

[Sergei Shtylyov]

On 06/10/2015 12:18 PM, Kishon Vijay Abraham I wrote:


No functional change. This is in preparation for handling non maxpacket
aligned transfers greater than bounce buffer size. This is basically to
avoid code duplication when using chained TRB transfers to handle
non maxpacket aligned transfers greater than bounce buffer size.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
  drivers/usb/dwc3/ep0.c |   25 +
  1 file changed, 17 insertions(+), 8 deletions(-)



diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 713e46a..4998074 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c

[...]

@@ -808,20 +812,24 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
}

ur = r-request;
+   buf = ur-buf;
+   remaining_ur_length = ur-length;

length = trb-size  DWC3_TRB_SIZE_MASK;

+   maxp = ep0-endpoint.maxpacket;
+
if (dwc-ep0_bounced) {
-   unsigned maxp = ep0-endpoint.maxpacket;
-   unsigned transfer_size = roundup(ur-length, maxp);
+   transfer_size = roundup((ur-length - transfer_size),
+   maxp);


   The innermost parens shouldn't be needed (if thay are, fix the macro 
instead).

[...]

@@ -941,7 +949,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}

maxpacket = dep-endpoint.maxpacket;
-   transfer_size = roundup(req-request.length, maxpacket);
+   transfer_size = roundup((req-request.length - transfer_size),
+   maxpacket);


   Likewise.

[...]

WBR, Sergei

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

Re: [PATCH 3/5] usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter

[Sergei Shtylyov]

Hello.

On 06/10/2015 12:18 PM, Kishon Vijay Abraham I wrote:


No functional change. Added a new parameter in _dwc3_ep0_start_trans_ to
indicate whether the TRB is a chained TRB or last TRB. This is in
preparation for adding chained TRB support for ep0.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
  drivers/usb/dwc3/ep0.c |   15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)



diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 4998074..d1a2be1 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state 
state)
  }

  static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t 
buf_dma,
-   u32 len, u32 type)
+   u32 len, u32 type, unsigned chain)


   Why not *bool*? You're passing boolean values anyway...

[...]

WBR, Sergei

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

Re: [PATCH 02/12] ARM: OMAP2+: Fix scrm compatible for dm814x

[Sergei Shtylyov]

Hello.

On 06/03/2015 07:23 PM, Tony Lindgren wrote:


Fix scrm compatible for dm814x.


   So, scrm...


Cc: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
  arch/arm/mach-omap2/control.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index af95a62..364925c 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -649,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] 
= {
{ .compatible = ti,am4-scm, .data = ctrl_data },
{ .compatible = ti,omap2-scm, .data = omap2_ctrl_data },
{ .compatible = ti,omap3-scm, .data = omap2_ctrl_data },
+   { .compatible = ti,dm814-scm, .data = ctrl_data },


   ... or scm? :-)


{ .compatible = ti,dm816-scrm, .data = ctrl_data },
{ .compatible = ti,omap4-scm-core, .data = ctrl_data },
{ .compatible = ti,omap5-scm-core, .data = ctrl_data },


WBR, Sergei

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

Re: [PATCH] usb: musb: Fix fifo reads for dm816x with musb_dsps

[Sergei Shtylyov]

Hello.

On 3/19/2015 1:48 AM, Tony Lindgren wrote:


Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.



Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:



asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4



While at it, let's also remove pointless cast of the driver data.



Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: George Cherian george.cher...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/usb/musb/musb_dsps.c | 37 -
  1 file changed, 36 insertions(+), 1 deletion(-)



--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
return !session_restart;
  }

+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+   void __iomem *fifo = hw_ep-fifo;
+   u32 val;
+   int i;
+
+   /* Read for 32bit-aligned destination address */
+   if (likely((0x03  (unsigned long)dst) == 0)  len = 4) {
+   readsl(fifo, dst, len  2);
+   dst += len  ~0x03;
+   len = 0x03;
+   }
+   /*
+* Now read the remaining 1 to 3 byte or complete length if
+* unaligned address.
+*/


  This comment seems misplaced, it belongs before the next *if*.


+   if (len  4) {
+   for (i = 0; i  (len  2); i++) {
+   *(u32 *)dst = musb_readl(fifo, 0);
+   dst += 4;
+   }


   Not sure how this is different to using readsl().


+   len = 0x03;
+   }
+   if (len  0) {
+   val = musb_readl(fifo, 0);
+   memcpy(dst, val, len);
+   }
+}
+
  static struct musb_platform_ops dsps_ops = {
.quirks = MUSB_INDEXED_EP,
.init   = dsps_musb_init,

[...]

WBR, Sergei

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

Re: [PATCH] usb: musb: Fix fifo reads for dm816x with musb_dsps

[Sergei Shtylyov]

On 03/19/2015 04:30 PM, Sergei Shtylyov wrote:


Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.



Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:



asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4



While at it, let's also remove pointless cast of the driver data.



Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: George Cherian george.cher...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/usb/musb/musb_dsps.c | 37 -
  1 file changed, 36 insertions(+), 1 deletion(-)



--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
  return !session_restart;
  }

+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+void __iomem *fifo = hw_ep-fifo;
+u32val;
+inti;
+
+/* Read for 32bit-aligned destination address */
+if (likely((0x03  (unsigned long)dst) == 0)  len = 4) {
+readsl(fifo, dst, len  2);
+dst += len  ~0x03;
+len = 0x03;
+}
+/*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */



   This comment seems misplaced, it belongs before the next *if*.



+if (len  4) {
+for (i = 0; i  (len  2); i++) {
+*(u32 *)dst = musb_readl(fifo, 0);
+dst += 4;
+}



Not sure how this is different to using readsl().


   Ah, the default implementation of musb_readl() uses __raw_readl().
So you'd probably want to keep this loop, not readsl() call.


+len = 0x03;
+}
+if (len  0) {
+val = musb_readl(fifo, 0);
+memcpy(dst, val, len);
+}
+}
+
  static struct musb_platform_ops dsps_ops = {
  .quirks= MUSB_INDEXED_EP,
  .init= dsps_musb_init,

[...]

WBR, Sergei

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

Re: [PATCH] usb: musb: Fix fifo reads for dm816x with musb_dsps

[Sergei Shtylyov]

On 03/19/2015 08:55 PM, Tony Lindgren wrote:


--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
  return !session_restart;
  }

+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+void __iomem *fifo = hw_ep-fifo;
+u32val;
+inti;
+
+/* Read for 32bit-aligned destination address */
+if (likely((0x03  (unsigned long)dst) == 0)  len = 4) {
+readsl(fifo, dst, len  2);
+dst += len  ~0x03;
+len = 0x03;
+}
+/*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */



   This comment seems misplaced, it belongs before the next *if*.



+if (len  4) {
+for (i = 0; i  (len  2); i++) {
+*(u32 *)dst = musb_readl(fifo, 0);
+dst += 4;
+}



Not sure how this is different to using readsl().



Ah, the default implementation of musb_readl() uses __raw_readl().
So you'd probably want to keep this loop, not readsl() call.



Not sure I follow you here..


   I just wrongly thought readsl() uses readl() internally. readl() is 
supposed to swap bytes when needed (BE case), while __raw_readl() is not.



Also include/asm-generic/io.h readsl()
uses __raw_readl()?


   Looking at the arch/arm/include/asm/io.h, readsl() is equivalent to 
__raw_readsl() too. Forgot about this asymmetry.



It seems things work with what I posted, so a readsl() loop, then
just read the remaining 1 to 3 bytes.


   In LE mode, there would have been no difference anyway.


Regards,



Tony


WBR, Sergei

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

Re: [PATCHv4 23/35] ARM: OMAP2+: id: cache omap_type value

[Sergei Shtylyov]

Hello.

On 03/18/2015 05:44 PM, Tero Kristo wrote:


There is no need to read the register with every invocation of the function,
as the value is constant. Thus, cache the value in a static variable.



Signed-off-by: Tero Kristo t-kri...@ti.com
---
  arch/arm/mach-omap2/id.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)



diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2a2f4d5..1f5949f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -52,7 +52,10 @@ EXPORT_SYMBOL(omap_rev);

  int omap_type(void)
  {
-   u32 val = 0;
+   static u32 val = OMAP2_DEVICETYPE_MASK + 1;
+
+   if (val  OMAP2_DEVICETYPE_MASK)


   =, perhaps?


+   return val;

[...]

WBR, Sergei

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

Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS

[Sergei Shtylyov]

Hello.

On 2/27/2015 5:17 PM, Robert Abel wrote:


Documentation/kernel-doc-nano-HOWTO.txt requires colons after the
parameter names, doesn't it?



Jesus Christ, you guys are killing me...
I've already spent way more time on this patch series than I intended
to anyway...


   That's what you get when pushing your stuff upstream. You're not alone 
here. :-)



+   mask = (1  nr_bits) - 1;



BIT(nr_bits) - 1, perhaps?



Not happening... BIT macro obscures what's actually going on.


   I did search for a macro that does ((1  n) - 1) but didn't found it, 
unfortunately...



Regards,
Robert


WBR, Sergei

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

Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS

[Sergei Shtylyov]

Hello.

On 02/26/2015 05:45 PM, Robert ABEL wrote:


DTS output was formatted to require additional work when copy-pasting into DTS.
Nano-second timings were replaced with interval of values that produce the same
number of clock ticks.



Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
  drivers/memory/omap-gpmc.c | 35 ++-
  1 file changed, 26 insertions(+), 9 deletions(-)



diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index dbb6753..9340e7a 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -337,32 +337,49 @@ static void gpmc_cs_bool_timings(int cs, const struct 
gpmc_bool_timings *p)
  }

  #ifdef DEBUG
+/**
+ * get_gpmc_timing_reg - read a timing parameter and print DTS settings for it.
+ * @cs  Chip Select Region


   Documentation/kernel-doc-nano-HOWTO.txt requires colons after the 
parameter names, doesn't it?



+ * @reg GPMC_CS_CONFIGn register offset.
+ * @st_bit  Start Bit
+ * @end_bit End Bit. Must be = @st_bit.
+ * @nameDTS node name, w/o gpmc,
+ * @raw Raw Format Option.
+ *  raw format:  gpmc,name = value
+ *  tick format: gpmc,name = value /zwj;*(x ns -- y ns]; x ticks 
*zwj;/
+ *  Where (x ns -- y ns] is the half-open interval from x ns to y ns 
that
+ *  result in the same tick value.
+ * @noval   Parameter values equal to 0 are not printed.
+ * @shift   Parameter value left shifts @shift, which is then printed instead 
of value.
+ *


   You should also describe the meaning of the function's result in a 
Return: section.



+ */
  static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
   bool raw, bool noval, int shift,
   const char *name)
  {
u32 l;
-   int nr_bits, max_value, mask;
+   int nr_bits;
+   int mask;

l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
-   max_value = (1  nr_bits) - 1;
-   mask = max_value  st_bit;
-   l = (l  mask)  st_bit;
+   mask = (1  nr_bits) - 1;


   BIT(nr_bits) - 1, perhaps?

WBR, Sergei

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

Re: -n900 (not mainline): fix compilation with 3.20-rc0

[Sergei Shtylyov]

Hello.

On 02/12/2015 01:23 AM, Pavel Machek wrote:

   This looked like a patch in its final form, so I decided to comment on it...


commit 02aa41563bd0f14268d2142ab69694880d3425a1
Author: Pavel pa...@ucw.cz
Date:   Wed Feb 11 23:22:51 2015 +0100


   No need for this header.


 Fix compilation of wl1251 specific parts with 3.20-rc0.



 Signed-off-by: Pavel Machek pa...@ucw.cz


   Please don't indent the change log.


diff --git a/drivers/net/wireless/ti/wl1251/netlink.c 
b/drivers/net/wireless/ti/wl1251/netlink.c
index e5f5a45..90a5486 100644
--- a/drivers/net/wireless/ti/wl1251/netlink.c
+++ b/drivers/net/wireless/ti/wl1251/netlink.c

[...]

@@ -406,14 +398,10 @@ static int wl1251_nl_phy_reg_read(struct sk_buff *skb, 
struct genl_info *info)
if (nla_put_u32(msg, WL1251_NL_ATTR_REG_VAL, *reg_value))
goto nla_put_failure;

-   ret = genlmsg_end(msg, hdr);
-   if (ret  0) {
-   wl1251_error(%s() failed, __func__);
-   goto nla_put_failure;
-   }
+   genlmsg_end(msg, hdr);

kfree(reg_value);
-
+   


   Remove this stray tab please.


return genlmsg_reply(msg, info);

  nla_put_failure:


WBR, Sergei

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

Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx

[Sergei Shtylyov]

Hello.

On 1/14/2015 2:37 AM, Tony Lindgren wrote:


This allows booting ti81xx boards with with when a .dts


   So, with, with or when? :-)


file is in place.



Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com


WBR, Sergei

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

Re: [PATCH] ARM: dts: DRA7: Add node for RTC

[Sergei Shtylyov]

Hello.

On 11/18/2014 8:01 AM, Lokesh Vutla wrote:


Add node for RTC.



Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};

+rtc: rtcss@48838000 {



 Please just name the node rtc@48838000, in accordance with ePAPR.



Okay. will update it.



+compatible = ti,am3352-rtc;
+reg = 0x48838000 0x100;
+interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;



 2 similar interrupts?



both rtc timer and rtc alarm uses same interrupt on DRA7 Soc.
Driver handles it accordingly.
So passing the same interrupt.



I think it would have been better if the driver just handled a single 
interrupt.



There are certain SoCs with RTC IP where timer and alarm uses different 
interrupts.


   I understood.


Driver has to take care of that scenario also. So it expects two interrupts 
from dt.


   You could also handle the missing second interrupt. I don't insist though...


Thanks and regards,
Lokesh


WBR, Sergei

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

Re: [PATCH] ARM: dts: DRA7: Add node for RTC

[Sergei Shtylyov]

Hello.

On 11/17/2014 7:45 AM, Lokesh Vutla wrote:


Add node for RTC.



Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
  arch/arm/boot/dts/dra7.dtsi | 9 +
  1 file changed, 9 insertions(+)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};

+   rtc: rtcss@48838000 {


   Please just name the node rtc@48838000, in accordance with ePAPR.


+   compatible = ti,am3352-rtc;
+   reg = 0x48838000 0x100;
+   interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;


   2 similar interrupts?

[...]

WBR, Sergei

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

Re: [PATCH] ARM: dts: DRA7: Add node for RTC

[Sergei Shtylyov]

On 11/17/2014 4:04 PM, Lokesh Vutla wrote:


On 11/17/2014 7:45 AM, Lokesh Vutla wrote:



Add node for RTC.



Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
   arch/arm/boot/dts/dra7.dtsi | 9 +
   1 file changed, 9 insertions(+)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
   status = disabled;
   };

+rtc: rtcss@48838000 {



Please just name the node rtc@48838000, in accordance with ePAPR.



Okay. will update it.



+compatible = ti,am3352-rtc;
+reg = 0x48838000 0x100;
+interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;



2 similar interrupts?



both rtc timer and rtc alarm uses same interrupt on DRA7 Soc.
Driver handles it accordingly.
So passing the same interrupt.


   I think it would have been better if the driver just handled a single 
interrupt.



Thanks and regards,
Lokesh



[...]


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] omap2430: use MUSB_DEVCTL_BDEVICE

[Sergei Shtylyov]

The OMAP2+ MUSB glue layer still uses a bare number for the DEVCTL.B-Device bit
in one place, while there's #define MUSB_DEVCTL_BDEVICE for that.

Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com

---
The patch is against the 'next' branch of Felipe Balbi's 'usb.git' repo.

 drivers/usb/musb/omap2430.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: usb/drivers/usb/musb/omap2430.c
===
--- usb.orig/drivers/usb/musb/omap2430.c
+++ usb/drivers/usb/musb/omap2430.c
@@ -162,7 +162,8 @@ static void omap2430_musb_set_vbus(struc
 * Wait for the musb to set as A device to enable the
 * VBUS
 */
-   while (musb_readb(musb-mregs, MUSB_DEVCTL)  0x80) {
+   while (musb_readb(musb-mregs, MUSB_DEVCTL) 
+  MUSB_DEVCTL_BDEVICE) {
 
mdelay(5);
cpu_relax();

--
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/2] usb: rename phy to usb_phy in HCD

[Sergei Shtylyov]

hello.

On 09/24/2014 09:11 AM, Greg KH wrote:


From: Antoine Tenart antoine.ten...@free-electrons.com



The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.



Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects
caused by patch reordering, updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Felipe Balbi ba...@ti.com



---
Changes in version 5:
- imported the patch from Antoine Tenart's series;
- added missing 'drivers/usb/misc/lvstest.c' file;
- resolved rejects caused by patch reordering;
- refreshed patch;
- updated changelog.



  drivers/usb/chipidea/host.c   |2 +-
  drivers/usb/core/hcd.c|   20 ++--
  drivers/usb/core/hub.c|8 
  drivers/usb/host/ehci-fsl.c   |   16 
  drivers/usb/host/ehci-hub.c   |2 +-
  drivers/usb/host/ehci-msm.c   |4 ++--
  drivers/usb/host/ehci-tegra.c |   16 
  drivers/usb/host/ohci-omap.c  |   20 ++--
  drivers/usb/misc/lvstest.c|8 
  include/linux/usb/hcd.h   |2 +-
  10 files changed, 49 insertions(+), 49 deletions(-)



This doesn't apply to my tree at all anymore,


   Well, I'm seeing only a minor reject in the first file, easily fixable.


can you refresh it and resend?


   OK, will re-post now.


thanks,



greg k-h


WBR, Sergei

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

[PATCH v6 0/2] Add generic PHY support to USB HCD

[Sergei Shtylyov]

Hello.

   This patchset is against the usb-next' branch of Greg KH's 'usb.git' repo.
Here I add support for the generic PHY to the 'struct usb_hcd' (having to
rename the existing 'phy' field to 'usb_phy' beforehand). This was mainly
intended to be used with the PCI OHCI/EHCI drivers and also xHCI driver;
however there are several more dependent patchsets now posted to 'linux-usb'.

[1/2] usb: rename phy to usb_phy in HCD
[2/2] usb: hcd: add generic PHY support

WBR, Sergei

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

[PATCH v6 1/2] usb: rename phy to usb_phy in HCD

[Sergei Shtylyov]

From: Antoine Tenart antoine.ten...@free-electrons.com

The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.

Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects,
updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu

---
Changes in version 6:
- resolved reject, refreshed the patch.

Changes in version 5:
- imported the patch from Antoine Tenart's series;
- added missing 'drivers/usb/misc/lvstest.c' file;
- resolved rejects caused by patch reordering;
- refreshed patch;
- updated changelog.

 drivers/usb/chipidea/host.c   |2 +-
 drivers/usb/core/hcd.c|   20 ++--
 drivers/usb/core/hub.c|8 
 drivers/usb/host/ehci-fsl.c   |   16 
 drivers/usb/host/ehci-hub.c   |2 +-
 drivers/usb/host/ehci-msm.c   |4 ++--
 drivers/usb/host/ehci-tegra.c |   16 
 drivers/usb/host/ohci-omap.c  |   20 ++--
 drivers/usb/misc/lvstest.c|8 
 include/linux/usb/hcd.h   |2 +-
 10 files changed, 49 insertions(+), 49 deletions(-)

Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd-has_tt = 1;
 
hcd-power_budget = ci-platdata-power_budget;
-   hcd-phy = ci-transceiver;
+   hcd-usb_phy = ci-transceiver;
hcd-tpl_support = ci-platdata-tpl_support;
 
ehci = hcd_to_ehci(hcd);
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2627,7 +2627,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
 
-   if (IS_ENABLED(CONFIG_USB_PHY)  !hcd-phy) {
+   if (IS_ENABLED(CONFIG_USB_PHY)  !hcd-usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
 
if (IS_ERR(phy)) {
@@ -2640,7 +2640,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
-   hcd-phy = phy;
+   hcd-usb_phy = phy;
hcd-remove_phy = 1;
}
}
@@ -2788,10 +2788,10 @@ err_allocate_root_hub:
 err_register_bus:
hcd_buffer_destroy(hcd);
 err_remove_phy:
-   if (hcd-remove_phy  hcd-phy) {
-   usb_phy_shutdown(hcd-phy);
-   usb_put_phy(hcd-phy);
-   hcd-phy = NULL;
+   if (hcd-remove_phy  hcd-usb_phy) {
+   usb_phy_shutdown(hcd-usb_phy);
+   usb_put_phy(hcd-usb_phy);
+   hcd-usb_phy = NULL;
}
return retval;
 }
@@ -2864,10 +2864,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
 
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
-   if (hcd-remove_phy  hcd-phy) {
-   usb_phy_shutdown(hcd-phy);
-   usb_put_phy(hcd-phy);
-   hcd-phy = NULL;
+   if (hcd-remove_phy  hcd-usb_phy) {
+   usb_phy_shutdown(hcd-usb_phy);
+   usb_put_phy(hcd-usb_phy);
+   hcd-usb_phy = NULL;
}
 
usb_put_invalidate_rhdev(hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4467,8 +4467,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
 
-   if (hcd-phy  !hdev-parent)
-   usb_phy_notify_connect(hcd-phy, udev-speed);
+   if (hcd-usb_phy  !hdev-parent)
+   usb_phy_notify_connect(hcd-usb_phy, udev-speed);
 
/*
 * Some superspeed devices have finished the link training process
@@ -4626,9 +4626,9 @@ static void hub_port_connect(struct usb_
 
/* Disconnect any existing devices under this port */
if (udev) {
-   if (hcd-phy  !hdev-parent 
+   if (hcd-usb_phy  !hdev-parent 
!(portstatus  USB_PORT_STAT_CONNECTION))
-   usb_phy_notify_disconnect(hcd-phy, udev-speed);
+   usb_phy_notify_disconnect(hcd-usb_phy, udev-speed);
usb_disconnect(port_dev-child);
}
 
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata

Re: [PATCH v6 1/2] usb: rename phy to usb_phy in HCD

[Sergei Shtylyov]

Hello.

On 09/24/2014 11:28 PM, Felipe Balbi wrote:


From: Antoine Tenart antoine.ten...@free-electrons.com



The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.



Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects,
updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu



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


   Sorry, forgot to collect your ACK from the previous posting. :-/

WBR, Sergei

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

Re: [PATCH 05/13] ARM: dts: DRA7: Add DCAN nodes

[Sergei Shtylyov]

Hello.

On 9/8/2014 6:10 PM, Roger Quadros wrote:


The SoC supports 2 DCAN nodes. Add them.



Signed-off-by: Roger Quadros rog...@ti.com
---
  arch/arm/boot/dts/dra7.dtsi | 30 ++
  1 file changed, 30 insertions(+)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..4ce1a4f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi

[...]

@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+   dcan1: d_can@481cc000 {


   The ePAPR standard has something to say here:


The name of a node should be somewhat generic, reflecting the function of the 
device and not its precise programming model. If appropriate, the name should 
be one of the following choices:


• can



+   compatible = bosch,d_can;
+   ti,hwmods = dcan1;
+   reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within 
syscon */
+   raminit-syscon = dra7_ctrl_core;
+   raminit-start-bit = 3;
+   raminit-done-bit = 1;
+   raminit-pulse;


   Hm, aren't the above 4 properties vendor specific? If so, they should 
start with a vendor prefix and comma.



+   interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+   clocks = dcan1_sys_clk_mux;
+   status = disabled;
+   };


WBR, Sergei

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

[PATCH v5 0/2] Add generic PHY support to USB HCD

[Sergei Shtylyov]

Hello.

   This patchset is against the usb-next' branch of Greg KH's 'usb.git' repo.
Here I add support for the generic PHY to the 'struct usb_hcd' (having to
rename the existing 'phy' field to 'usb_phy' beforehand). This was mainly
intended to be used with the PCI OHCI/EHCI drivers and also xHCI driver;
however there are several more dependent patchsets now posted to 'linux-usb'.
   Greg, if you want links to these patchsets and the device tree patches using
this patchset in order to link the PCI OHCI/EHCI devices to the PHY, just ask
(I have already posted the previously but will probably have to repost them
again)...

[1/2] usb: rename phy to usb_phy in HCD
[2/2] usb: hcd: add generic PHY support

WBR, Sergei

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

[PATCH v5 1/2] usb: rename phy to usb_phy in HCD

[Sergei Shtylyov]

From: Antoine Tenart antoine.ten...@free-electrons.com

The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.

Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects
caused by patch reordering, updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu

---
Changes in version 5:
- imported the patch from Antoine Tenart's series;
- added missing 'drivers/usb/misc/lvstest.c' file;
- resolved rejects caused by patch reordering;
- refreshed patch;
- updated changelog.

 drivers/usb/chipidea/host.c   |2 +-
 drivers/usb/core/hcd.c|   20 ++--
 drivers/usb/core/hub.c|8 
 drivers/usb/host/ehci-fsl.c   |   16 
 drivers/usb/host/ehci-hub.c   |2 +-
 drivers/usb/host/ehci-msm.c   |4 ++--
 drivers/usb/host/ehci-tegra.c |   16 
 drivers/usb/host/ohci-omap.c  |   20 ++--
 drivers/usb/misc/lvstest.c|8 
 include/linux/usb/hcd.h   |2 +-
 10 files changed, 49 insertions(+), 49 deletions(-)

Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd-has_tt = 1;
 
hcd-power_budget = ci-platdata-power_budget;
-   hcd-phy = ci-transceiver;
+   hcd-usb_phy = ci-transceiver;
 
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2627,7 +2627,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
 
-   if (IS_ENABLED(CONFIG_USB_PHY)  !hcd-phy) {
+   if (IS_ENABLED(CONFIG_USB_PHY)  !hcd-usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
 
if (IS_ERR(phy)) {
@@ -2640,7 +2640,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
-   hcd-phy = phy;
+   hcd-usb_phy = phy;
hcd-remove_phy = 1;
}
}
@@ -2788,10 +2788,10 @@ err_allocate_root_hub:
 err_register_bus:
hcd_buffer_destroy(hcd);
 err_remove_phy:
-   if (hcd-remove_phy  hcd-phy) {
-   usb_phy_shutdown(hcd-phy);
-   usb_put_phy(hcd-phy);
-   hcd-phy = NULL;
+   if (hcd-remove_phy  hcd-usb_phy) {
+   usb_phy_shutdown(hcd-usb_phy);
+   usb_put_phy(hcd-usb_phy);
+   hcd-usb_phy = NULL;
}
return retval;
 }
@@ -2864,10 +2864,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
 
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
-   if (hcd-remove_phy  hcd-phy) {
-   usb_phy_shutdown(hcd-phy);
-   usb_put_phy(hcd-phy);
-   hcd-phy = NULL;
+   if (hcd-remove_phy  hcd-usb_phy) {
+   usb_phy_shutdown(hcd-usb_phy);
+   usb_put_phy(hcd-usb_phy);
+   hcd-usb_phy = NULL;
}
 
usb_put_invalidate_rhdev(hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4461,8 +4461,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
 
-   if (hcd-phy  !hdev-parent)
-   usb_phy_notify_connect(hcd-phy, udev-speed);
+   if (hcd-usb_phy  !hdev-parent)
+   usb_phy_notify_connect(hcd-usb_phy, udev-speed);
 
/*
 * Some superspeed devices have finished the link training process
@@ -4617,9 +4617,9 @@ static void hub_port_connect(struct usb_
 
/* Disconnect any existing devices under this port */
if (udev) {
-   if (hcd-phy  !hdev-parent 
+   if (hcd-usb_phy  !hdev-parent 
!(portstatus  USB_PORT_STAT_CONNECTION))
-   usb_phy_notify_disconnect(hcd-phy, udev-speed);
+   usb_phy_notify_disconnect(hcd-usb_phy, udev-speed);
usb_disconnect(port_dev-child);
}
 
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct

Re: [PATCH] Removes FIXME message in usb.c

[Sergei Shtylyov]

Hello.

On 07/09/2014 05:58 AM, Nicholas Krause wrote:


This patch removes a fixme message in this file:wq for setting the usb 2


   The vim's commands interspersed with text? :-)


speed on the board to the correct level. We need to depend on the
bootloader for doing this as the wires may be shared for the other
things on the board with the usb chipset.



Signed-off-by: Nicholas Krause xerofo...@gmail.com

[...]

WBR, Sergei

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

Re: [PATCH 3/6] phy: core: Support regulator supply for PHY power

[Sergei Shtylyov]

Hello.

On 07/02/2014 04:03 PM, Roger Quadros wrote:


Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.



Signed-off-by: Roger Quadros rog...@ti.com
---
  drivers/phy/phy-core.c  | 32 
  include/linux/phy/phy.h |  2 ++
  2 files changed, 34 insertions(+)



diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..d817107 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c

[...]

@@ -664,6 +689,10 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
  void phy_destroy(struct phy *phy)
  {
pm_runtime_disable(phy-dev);
+
+   if (phy-pwr)
+   regulator_put(phy-pwr);


   regulator_put() already handles NULL pointer.


+
device_unregister(phy-dev);
  }
  EXPORT_SYMBOL_GPL(phy_destroy);
@@ -800,6 +829,9 @@ static void phy_release(struct device *dev)

phy = to_phy(dev);
dev_vdbg(dev, releasing '%s'\n, dev_name(dev));
+   if (phy-pwr)
+   regulator_put(phy-pwr);


   Same comment here.


+
ida_simple_remove(phy_ida, phy-id);
kfree(phy);
  }


WBR, Sergei

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

Re: [PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()

[Sergei Shtylyov]

Hello.

On 22-05-2014 10:29, George Cherian wrote:


Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.



Babble control register logic is implemented in the latest
revision of AM335x.



Signed-off-by: George Cherian george.cher...@ti.com


   Sorry for the late comments, I probably didn't pay enough attention to 
this series before...



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
  }

+static int sw_babble_control(struct musb *musb)


   Perhaps the result type should be *bool* instead of *int*?


+{
+   int timeout = 10;
+   u8 babble_ctl, session_restart = 0;
+
+   babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+   dev_dbg(musb-controller, babble: MUSB_BABBLE_CTL value %x\n,
+   babble_ctl);
+   /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+   dev_dbg(musb-controller, STUCK_J is %s\n,
+   babble_ctl  MUSB_BABBLE_STUCK_J ? set : reset);
+
+   if (babble_ctl  MUSB_BABBLE_STUCK_J) {


   'timeout' could be declared here, local to the block using it.


+   /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+   babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+   babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+   /* wait till line monitor flag cleared */
+   dev_dbg(musb-controller, Set TXIDLE, wait J to clear\n);
+   do {
+   babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+   udelay(1);
+   } while ((babble_ctl  MUSB_BABBLE_STUCK_J)  timeout--);
+
+   /* check whether stuck_at_j bit cleared */
+   if (babble_ctl  MUSB_BABBLE_STUCK_J) {
+   /*
+* real babble condition is occured


   s/is occured/has occurred/.


+* restart the controller to start the
+* session again
+*/
+   dev_dbg(musb-controller, J not cleared, misc (%x)\n,
+   babble_ctl);
+   session_restart = 1;
+   }
+


   Empty line not needed here.


+   } else {
+   session_restart = 1;
+   }
+
+   return session_restart;
+}


WBR, Sergei

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

Re: [PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()

[Sergei Shtylyov]

On 22-05-2014 10:29, George Cherian wrote:


Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.



Babble control register logic is implemented in the latest
revision of AM335x.



Signed-off-by: George Cherian george.cher...@ti.com
---
  drivers/usb/musb/musb_dsps.c | 50 
  drivers/usb/musb/musb_regs.h |  7 +++
  2 files changed, 57 insertions(+)



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
  }

+static int sw_babble_control(struct musb *musb)
+{


   Doesn't gcc complain on this function being unused? I think you should 
have added this function along with the caller, not separately.


WBR, Sergei

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

Re: [PATCH v5 6/6] usb: musb: dsps: Enable sw babble control for newer silicon

[Sergei Shtylyov]

Hello.

On 22-05-2014 10:29, George Cherian wrote:


Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.



Signed-off-by: George Cherian george.cher...@ti.com
---
  drivers/usb/musb/musb_dsps.c | 38 --
  1 file changed, 32 insertions(+), 6 deletions(-)



diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 868caf8..2ced061 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c

[...]

@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val = ~(1  wrp-otg_disable);
dsps_writel(musb-ctrl_base, wrp-phy_utmi, val);

+   /*
+*  Check whether the dsps version has babble control enabled.


   One space too many before this sentence.


+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+   val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+   if (val == MUSB_BABBLE_RCV_DISABLE) {
+   glue-sw_babble_enabled = true;
+   val |= MUSB_BABBLE_SW_SESSION_CTRL;
+   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+   }
+


   Hm, from the register offset that you declared in the previous patch, I 
got an impression that this is a new standard MUSB register? Shouldn't this 
check be done in the generic MUSB code then?


WBR, Sergei

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

Re: [PATCH v2 1/6] usb: dwc3: dwc3-omap: Remove x_major calculation from revision register

[Sergei Shtylyov]

Hello.

On 19-05-2014 12:32, George Cherian wrote:


Remove the x_major calculation logic from the wrapper revision register
to differentiate between OMAP5 and AM437x. This was done to find the
register offsets of wrapper register. Now that We do it using dt
compatible, remove the whole logic.



Signed-off-by: George Cherian george.cher...@ti.com
---
  drivers/usb/dwc3/dwc3-omap.c | 35 +++
  1 file changed, 3 insertions(+), 32 deletions(-)



diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 1160ff4..53f6490 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c

[...]

@@ -448,32 +442,9 @@ static int dwc3_omap_probe(struct platform_device *pdev)

[...]

-   /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
-* changes in wrapper registers, Using dt compatible for aegis
+   /* Differentiate between OMAP5 and AM437x
+* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for AM437x


   This sentence doesn't look complete...


 */

if (of_device_is_compatible(node, ti,am437x-dwc3)) {


WBR, Sergei

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

Re: [PATCH v2 5/7] phy: omap-usb2: Add clock names to Documentation binding

[Sergei Shtylyov]

Hello.

On 04/28/2014 06:01 PM, Roger Quadros wrote:


Add wkupclk and refclk information to DT binding information.



Signed-off-by: Roger Quadros rog...@ti.com
---
  Documentation/devicetree/bindings/phy/ti-phy.txt | 7 +++
  1 file changed, 7 insertions(+)



diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 788fb0f..9ce458f 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -32,6 +32,11 @@ Required properties:
   - 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.
+ - clocks: a list of phandles and clock-specifier pairs, one for each entry in
+   clock-names.


   I thought clock specifier includes phandle. Anyway, this description 
doesn't seem to match your example...



+ - clock-names: should include:
+   * wkupclk - wakeup clock.
+   * refclk - reference clock (optional).

  Optional properties:
   - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -44,6 +49,8 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
#phy-cells = 0;
+   clocks = usb_phy_cm_clk32k, usb_otg_ss_refclk960m;
+   clock-names = wkupclk, refclk;
  };


WBR, Sergei

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

Re: [PATCH 07/10] ARM: dts: DRA7: Add DT node for DES IP

[Sergei Shtylyov]

Hello.

On 26-04-2014 3:02, Joel Fernandes wrote:


DRA7xx SoCs have a DES3DES IP. Add DT data for the same.



Signed-off-by: Joel Fernandes jo...@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 1c0f8e1..0533b89 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,17 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+   des: des@480a5000 {


   Shouldn't the node name be crypto@480a5000, according to the ePAPR 
standard?

WBR, Sergei

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

Re: [PATCH 1/6] PM / clock_ops: Add helpers combining generic runtime and generic clock PM

[Sergei Shtylyov]

Hello.

On 24-04-2014 14:26, Geert Uytterhoeven wrote:


Add helpers pm_generic_runtime_clk_suspend() and
pm_generic_clk_runtime_resume(), combining generic runtime PM and generic
clock PM.



Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be


[...]


diff --git a/include/linux/pm_clock.h b/include/linux/pm_clock.h
index 6981aa288c45..bf1e4d09a0ca 100644
--- a/include/linux/pm_clock.h
+++ b/include/linux/pm_clock.h
@@ -35,6 +35,8 @@ extern int pm_clk_add_clk(struct device *dev, struct clk 
*clk);
  extern void pm_clk_remove(struct device *dev, const char *con_id);
  extern int pm_clk_suspend(struct device *dev);
  extern int pm_clk_resume(struct device *dev);
+extern int pm_generic_runtime_clk_suspend(struct device *dev);
+extern int pm_generic_clk_runtime_resume(struct device *dev);


   Shouldn't these function names be symmetric? I think '_clk' and '_runtime' 
need swapping in one case.


WBR, Sergei

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

Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a

[Sergei Shtylyov]

Hello.

On 24-04-2014 14:17, Tomi Valkeinen wrote:


omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.



Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
  arch/arm/boot/dts/omap5-uevm.dts | 7 +++
  1 file changed, 7 insertions(+)



diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b99ec25b748..9e7581eaeb23 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -434,6 +434,13 @@
pinctrl-0 = i2c5_pins;

clock-frequency = 40;
+
+   tca6424a: tca6424a@22 {


   The ePAPR standard [1] says: The name of a node should be somewhat generic,
reflecting the function of the device and not its precise programming model.
If appropriate, the name should be one of the following choices:
[...]
   - gpio;


+   compatible = ti,tca6424;
+   reg = 0x22;
+   gpio-controller;
+   #gpio-cells = 2;
+   };
  };


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

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

Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a

[Sergei Shtylyov]

Hello.

On 04/24/2014 06:33 PM, Tomi Valkeinen wrote:


omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.



Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
   arch/arm/boot/dts/omap5-uevm.dts | 7 +++
   1 file changed, 7 insertions(+)



diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 3b99ec25b748..9e7581eaeb23 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -434,6 +434,13 @@
   pinctrl-0 = i2c5_pins;

   clock-frequency = 40;
+
+tca6424a: tca6424a@22 {



The ePAPR standard [1] says: The name of a node should be somewhat
generic,
reflecting the function of the device and not its precise programming
model.
If appropriate, the name should be one of the following choices:
[...]
- gpio;



Right. I wonder what the name should be... gpio is out, as the name
should be more specific.


   No, it's not out. The name should be gpio@22, I think it would be unique.


We already have gpio1-8, which are the gpio
banks from the SoC.


   I don't understand why you are indexing the names while you probably have 
the address part after @ that makes them unique already.



  Tomi


WBR, Sergei

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

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

On 10-04-2014 13:20, David Laight wrote:


 It doesn't do any pin muxing. It switches SoC internal USB signals between
USB controllers. The pins remain the same.



Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?


   Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?


That also doesn't sound like you are changing the PHY.


   I am changing one of the PHY registers that controls USB port (Renesas 
calls it channel) multiplexing.



I'd have thought that would happen if you had a single controller
that select between multiply PHY.


   No, it's not the case.


David


WBR, Sergei

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

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

On 10-04-2014 15:14, David Laight wrote:


  It doesn't do any pin muxing. It switches SoC internal USB
signals between
USB controllers. The pins remain the same.



Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?



 Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?



Yes.



Why do you care which USB controller is driving the pins?


   Because the controllers the driver switches between are not companions.
The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device 
controller in this case) controllers on port 0 and between PCI EHCI/OHCI and 
non-PCI xHCI controller on port 2.



That also doesn't sound like you are changing the PHY.



 I am changing one of the PHY registers that controls USB port
(Renesas calls it channel) multiplexing.



I'd have thought that would happen if you had a single controller
that select between multiply PHY.



 No, it's not the case.



I realised that wasn't what you were doing, but at first it did seem
to be what you were doing.


   The PHY really does belong to the USBHS controller but that multiplexing 
register inside it controls routing of the ports 0 and 2; USBHS itself is on 
port 0.



There is an interesting case, the USB3 shares a PHY with a SATA
and the PCIE and SATA also share a PHY on the R8A7790.



Some of those look like pcb design decisions - so there is no dynamic
changing, just config time plumbing.


   No, there are also host/device mode DIP switches on the boards which 
control port 0 signals (and the port 0 connector is micro-AB, so both a host 
and device can be connected). The second board also has OTG chip on port 0 
thru which USB ID pin can be read from the micro-AB connector.



David


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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. 
This is in preparation to adding the generic PHY support.

Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com

---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.

 drivers/usb/chipidea/host.c   |2 +-
 drivers/usb/core/hcd.c|   20 ++--
 drivers/usb/core/hub.c|9 +
 drivers/usb/host/ehci-fsl.c   |   16 
 drivers/usb/host/ehci-hub.c   |2 +-
 drivers/usb/host/ehci-msm.c   |4 ++--
 drivers/usb/host/ehci-tegra.c |   16 
 drivers/usb/host/ohci-omap.c  |   20 ++--
 include/linux/usb/hcd.h   |6 +++---
 9 files changed, 48 insertions(+), 47 deletions(-)

Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd-has_tt = 1;
 
hcd-power_budget = ci-platdata-power_budget;
-   hcd-phy = ci-transceiver;
+   hcd-transceiver = ci-transceiver;
 
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2605,7 +2605,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
 
-   if (IS_ENABLED(CONFIG_USB_PHY)  !hcd-phy) {
+   if (IS_ENABLED(CONFIG_USB_PHY)  !hcd-transceiver) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
 
if (IS_ERR(phy)) {
@@ -2618,7 +2618,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
-   hcd-phy = phy;
+   hcd-transceiver = phy;
hcd-remove_phy = 1;
}
}
@@ -2764,10 +2764,10 @@ err_allocate_root_hub:
 err_register_bus:
hcd_buffer_destroy(hcd);
 err_remove_phy:
-   if (hcd-remove_phy  hcd-phy) {
-   usb_phy_shutdown(hcd-phy);
-   usb_put_phy(hcd-phy);
-   hcd-phy = NULL;
+   if (hcd-remove_phy  hcd-transceiver) {
+   usb_phy_shutdown(hcd-transceiver);
+   usb_put_phy(hcd-transceiver);
+   hcd-transceiver = NULL;
}
return retval;
 }
@@ -2841,10 +2841,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_dev(hcd-self.root_hub);
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
-   if (hcd-remove_phy  hcd-phy) {
-   usb_phy_shutdown(hcd-phy);
-   usb_put_phy(hcd-phy);
-   hcd-phy = NULL;
+   if (hcd-remove_phy  hcd-transceiver) {
+   usb_phy_shutdown(hcd-transceiver);
+   usb_put_phy(hcd-transceiver);
+   hcd-transceiver = NULL;
}
 }
 EXPORT_SYMBOL_GPL(usb_remove_hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4250,8 +4250,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
 
-   if (hcd-phy  !hdev-parent)
-   usb_phy_notify_connect(hcd-phy, udev-speed);
+   if (hcd-transceiver  !hdev-parent)
+   usb_phy_notify_connect(hcd-transceiver, udev-speed);
 
/*
 * Some superspeed devices have finished the link training process
@@ -4459,9 +4459,10 @@ static void hub_port_connect_change(stru
 
/* Disconnect any existing devices under this port */
if (udev) {
-   if (hcd-phy  !hdev-parent 
+   if (hcd-transceiver  !hdev-parent 
!(portstatus  USB_PORT_STAT_CONNECTION))
-   usb_phy_notify_disconnect(hcd-phy, udev-speed);
+   usb_phy_notify_disconnect(hcd-transceiver,
+ udev-speed);
usb_disconnect(hub-ports[port1 - 1]-child);
}
clear_bit(port1, hub-change_bits);
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
 
-   hcd-phy = usb_get_phy(USB_PHY_TYPE_USB2);
+   hcd-transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
dev_dbg(pdev-dev, hcd=0x%p  ehci=0x%p, phy=0x%p\n,
-   hcd, ehci, hcd-phy);
+   hcd, ehci, hcd

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

Hello.

On 04/09/2014 07:31 PM, Stephen Warren wrote:


Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
This is in preparation to adding the generic PHY support.



Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY support? To be honest, this rename
feels like churn, especially since the APIs and DT bindings all still
include the work phy so now everything will be inconsistent.


   How about 'usb_phy'?

WBR, Sergei

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

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

On 04/09/2014 08:48 PM, Stephen Warren wrote:


Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.



Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY support? To be honest, this rename
feels like churn, especially since the APIs and DT bindings all still
include the work phy so now everything will be inconsistent.



How about 'usb_phy'?



That certainly would make things more consistent, but I wonder why
usb_phy is better than phy when the code/struct in question is
something USB-specific; the usb_ prefix seems implicit to me due to
context.


   I tend to agree. However, I need to name the new field of stype 'struct 
phy *' somehow... perhaps something like 'gen_phy' for it would do?


WBR, Sergei

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

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

On 04/09/2014 09:37 PM, Stephen Warren wrote:


Return to the 'phy' field of 'struct usb_hcd' its historic name
'transceiver'.
This is in preparation to adding the generic PHY support.



Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY support? To be honest, this rename
feels like churn, especially since the APIs and DT bindings all still
include the work phy so now everything will be inconsistent.



 How about 'usb_phy'?



That certainly would make things more consistent, but I wonder why
usb_phy is better than phy when the code/struct in question is
something USB-specific; the usb_ prefix seems implicit to me due to
context.



I tend to agree. However, I need to name the new field of stype
'struct phy *' somehow... perhaps something like 'gen_phy' for it would do?



Ok, the existing field is being replaced by something? I didn't get that


   No, not replaced. I'm adding the support for generic PHY to the existing 
USB PHY support. I thought that was clear from the changelog.



from the patch description; I thought the new name in this patch was
going to be it. In that case, a temporary name of usb_phy for the
existing field, or adding the new field as gen_phy sound reasonable.


   OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.

WBR, Sergei

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

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

Hello.

On 04/09/2014 09:56 PM, Alan Stern wrote:


Ok, the existing field is being replaced by something? I didn't get that



 No, not replaced. I'm adding the support for generic PHY to the existing
USB PHY support. I thought that was clear from the changelog.



from the patch description; I thought the new name in this patch was
going to be it. In that case, a temporary name of usb_phy for the
existing field, or adding the new field as gen_phy sound reasonable.



 OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.



What is the reason for all of this?  That is, can you explain the
difference between USB PHY support and general PHY support, and why we
need both?


   The generic PHY framework (drivers/phy/phy-core.c) supports multifunction 
complex PHYs (some functions of which may be related to USB). My case is a 
Renesas R-Car generation 2 PHY that can switch two USB ports between different 
USB controllers (one PCI and one non-PCI on each port); I just haven't CCed 
linux-usb on my driver submission. Though there's already drivers/phy/usb/ 
driver for that hardware, it failed to meet the expectations (dynamic setting 
of the port multiplexing depending on what USB host/gadget drivers are 
loaded), so I had to write a new driver. I guess I don't need to describe 
drivers/phy/usb/ framework in detail, do I? It only provides for 
single-function simple USB PHYs...



Alan Stern


WBR, Sergei

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

Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Sergei Shtylyov]

On 04/09/2014 11:01 PM, Stephen Warren wrote:


Ok, the existing field is being replaced by something? I didn't get
that



  No, not replaced. I'm adding the support for generic PHY to the
existing
USB PHY support. I thought that was clear from the changelog.



from the patch description; I thought the new name in this patch was
going to be it. In that case, a temporary name of usb_phy for the
existing field, or adding the new field as gen_phy sound reasonable.



  OK, I'll respin the patch #2 with 'gen_phy' and remove the patch
#1.



What is the reason for all of this?  That is, can you explain the
difference between USB PHY support and general PHY support, and why we
need both?



The generic PHY framework (drivers/phy/phy-core.c) supports
multifunction complex PHYs (some functions of which may be related to
USB). My case is a Renesas R-Car generation 2 PHY that can switch two
USB ports between different USB controllers (one PCI and one non-PCI on
each port); I just haven't CCed linux-usb on my driver submission.
Though there's already drivers/phy/usb/ driver for that hardware, it
failed to meet the expectations (dynamic setting of the port
multiplexing depending on what USB host/gadget drivers are loaded), so I
had to write a new driver. I guess I don't need to describe
drivers/phy/usb/ framework in detail, do I? It only provides for
single-function simple USB PHYs...



Naively, it sounds like the complex PHY driver should also be a pinctrl
driver, since it sounds like the main feature it has beyond a simple PHY
is the ability to do pin muxing.


   It doesn't do any pin muxing. It switches SoC internal USB signals between 
USB controllers. The pins remain the same.


WBR, Sergei

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

Re: [PATCH 1/3] arm: dts: am33xx.dtsi: Add node name to rtc device node

[Sergei Shtylyov]

Hello.

On 02/05/2014 03:12 PM, Stefan Roese wrote:


Making it possible to reference and therefor change (disable) this
device node from other dts file which import this dtsi file.



Signed-off-by: Stefan Roese s...@denx.de
Cc: Lukas Stockmann lukas.stockm...@siemens.com
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
---
  arch/arm/boot/dts/am33xx.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..b8daf8c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -399,7 +399,7 @@
ti,timer-pwm;
};

-   rtc@44e3e000 {
+   rtc: rtc@44e3e000 {


   Node name is rtc@44e3e000 -- what you are adding is a label.

WBR, Sergei

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

Re: [PATCH v3 0/6] IIO pulse capture support for TI ECAP

[Sergei Shtylyov]

Hello.

On 02/05/2014 10:01 PM, Matt Porter wrote:

[...]


This series adds support for PWM capture devices within IIO and
adds a TI ECAP IIO driver.



PWM capture devices are supported using a new IIO pulse channel type.



The IIO ECAP driver implements interrupt driven triggered buffer capture
only as raw sample reads are not applicable to this hardware.
Initially, the driver supports a single pulse width measurement with
configurable polarity. The ECAP hardware can support measurement of a
complete period and duty cycle but this is not yet implemented.


   How about pulse counting? I have the hardware that can also count pulses 
in addition to measuring the periods, so I'm interested in this work 
(initially I supported it in driver/misc/ but it got turned down for iio).


WBR, Sergei

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

Re: [PATCH 2/2] usb: musb: Rework USB and USB_GADGET dependency

[Sergei Shtylyov]

Hello.

On 26-12-2013 16:24, Ezequiel Garcia wrote:


This USB controller can work in as host-only, gadget-only or dual-role
modes. Rework the dependency on the USB and USB_GADGET configs in order
to allow building the driver when !USB or !USG_GADGET.



Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com

[...]


diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 57dfc0c..a1d805f 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -6,7 +6,7 @@
  # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
  config USB_MUSB_HDRC
tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
-   depends on USB_GADGET
+   depends on (USB || USB_GADGET)


   Parens are not needed here. Be consistent with other entries MUSB please.


help
  Say Y here if your system has a dual role high speed USB
  controller based on the Mentor Graphics silicon IP.  Then
@@ -35,21 +35,21 @@ choice

  config USB_MUSB_HOST
bool Host only mode
-   depends on USB
+   depends on USB=y || USB=USB_MUSB_HDRC
help
  Select this when you want to use MUSB in host mode only,
  thereby the gadget feature will be regressed.

  config USB_MUSB_GADGET
bool Gadget only mode
-   depends on USB_GADGET
+   depends on USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC
help
  Select this when you want to use MUSB in gadget mode only,
  thereby the host feature will be regressed.

  config USB_MUSB_DUAL_ROLE
bool Dual Role mode
-   depends on (USB  USB_GADGET)
+   depends on ((USB=y || USB=USB_MUSB_HDRC)  (USB_GADGET=y || 
USB_GADGET=USB_MUSB_HDRC))


   Outer parens are not needed either...

WBR, Sergei

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

Re: OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5)

[Sergei Shtylyov]

Hello.

On 12/09/2013 10:14 PM, Tony Lindgren wrote:


Boot to userspace:
 FAIL ( 1/11): 37xxevm



So looks like this is due to the switchover to DT-based booting for 37xx
EVM.  Will plug that in here and re-test.



Here's the updated test report.  Looks like dynamic idle PM tests are
failing on the 37xxevm now.



Off-idle and wake-up events work but need these two pending patches:



1. [PATCH] of/platform: Fix no irq domain found errors when populating 
interrupts
http://lkml.org/lkml/2013/11/22/520



Oops, this is the wrong patch, it should be:



1. [PATCH] of/platform: Fix no irq domain found errors when populating 
interrupts
http://lkml.org/lkml/2013/11/22/520


   Isn't it the same patch and link? :-)

WBR, Sergei

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

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

[Sergei Shtylyov]

Hello.

On 25-11-2013 23:39, Daniel Mack wrote:


It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.



The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.



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

[...]


diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..e5a581c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;

+   /* should the musb core restore registers after suspend? */
+   u8  restore_after_suspend:1;
+


   Better placement seems to be with 'extvbus' field which is also 1-bit -- 
that would save space in the structure.


WBR, Sergei

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

Re: [PATCH] ARM: dts: am4372: Add McASP nodes

[Sergei Shtylyov]

Hello.

On 10/21/2013 01:45 PM, Peter Ujfalusi wrote:


Add nodes for McASP0 and McASP1 for AM43xx.



Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
  arch/arm/boot/dts/am4372.dtsi | 27 +++
  1 file changed, 27 insertions(+)



diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c328d5c..defaad1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -633,5 +633,32 @@
dma-names = tx, rx;
};

+   mcasp0: mcasp@48038000 {


   According to ePAPR spec [1], the name of a node should be somewhat 
generic, reflecting the function of the device and not its

precise programming model. In this case probably sound?

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

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

Re: [RFC PATCH 08/15] ata: ahci_platform: Manage SATA PHY

[Sergei Shtylyov]

Hello.

On 23-09-2013 1:51, Tejun Heo wrote:


Not sure why you asked -- I'm not using this driver, neither I'm



Well, you have better grip of what's going on in the embedded world
than me.  I'm mostly curious whether adding dependency on PHY is okay.


   This driver already supports optional clock, the optional PHY support
seems analogous.


Thanks.


WBR, Sergei

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

Re: [RFC PATCH 08/15] ata: ahci_platform: Manage SATA PHY

[Sergei Shtylyov]

Hello.

On 23-09-2013 11:37, Roger Quadros wrote:


Not sure why you asked -- I'm not using this driver, neither I'm



Well, you have better grip of what's going on in the embedded world
than me.  I'm mostly curious whether adding dependency on PHY is okay.



There is no hard dependency on presence of PHY. The driver will continue
as usual if devm_phy_get() fails.
I hope selecting GENERIC_PHY in Kconfig is not an issue.


   Selecting in the AHCI_PLATFORM section? It seems I have overlooked it. No, 
I don't think it's a good idea. The generic PHY functions seem to be stubbed 
when GENERIC_PHY=n.



cheers,
-roger


WBR, Sergei

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

Re: [RFC PATCH 08/15] ata: ahci_platform: Manage SATA PHY

[Sergei Shtylyov]

Hello.

On 09/23/2013 01:48 AM, Tejun Heo wrote:


@@ -37,6 +37,7 @@



  #include linux/clk.h
  #include linux/libata.h
+#include linux/phy/phy.h



struct phy;



should suffice.



Unless it's actually likely to cause inclusion loop, I think it's
better to include the header than adding explicit declarations.


   Apparently, tastes differ here. E.g. Greg KH would have also told Roger to 
use forward declaration in such case. :-)



Thanks.


WBR, Sergei

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

Re: [PATCH v2 5/5] dma: cppi41: add support for suspend and resume

[Sergei Shtylyov]

Hello.

On 22-09-2013 15:57, Daniel Mack wrote:


This patch adds support for suspend/resume functionality to the cppi41
DMA driver. The steps neccessary to make the system resume properly were


   Necessary.


figured out by hefty trial-and-error. The code as it stands now is the
minimum that has to be done to put the musb host system on an AM33xx
system into an operable state after resume.



Signed-off-by: Daniel Mack zon...@gmail.com
---
  drivers/dma/cppi41.c | 33 +
  1 file changed, 33 insertions(+)



diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 3347321..59dfa8e 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -1040,12 +1040,45 @@ static int cppi41_dma_remove(struct platform_device 
*pdev)
return 0;
  }

+#ifdef CONFIG_PM_SLEEP

[...]

+static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
+
+#define DEV_PM_OPS (cppi41_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif


   You don't need that with SIMPLE_DEV_PM_OPS(), just get it out of #ifdef.

WBR, Sergei

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

Re: [PATCH v2 3/4] usb: musb: omap2430: use SIMPLE_DEV_PM_OPS

[Sergei Shtylyov]

Hello.

On 22-09-2013 18:43, Daniel Mack wrote:


This makes omap2430_pm_ops const and will stub the struct out in case
CONFIG_PM_SLEEP is not set.



Signed-off-by: Daniel Mack zon...@gmail.com
---
  drivers/usb/musb/omap2430.c | 15 +--
  1 file changed, 5 insertions(+), 10 deletions(-)



diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 59d2245..be42460 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -659,17 +659,12 @@ static int omap2430_runtime_resume(struct device *dev)

return 0;
  }
-
-static struct dev_pm_ops omap2430_pm_ops = {
-   .runtime_suspend = omap2430_runtime_suspend,
-   .runtime_resume = omap2430_runtime_resume,
-};
-
-#define DEV_PM_OPS (omap2430_pm_ops)
-#else
-#define DEV_PM_OPS NULL
  #endif

+static SIMPLE_DEV_PM_OPS(omap2430_pm_ops,
+omap2430_runtime_suspend,
+omap2430_runtime_resume);


   No, SIMPLE_DEV_PM_OPS() won't do here, it's runtime PM, didn't you see?

WBR, Sergei

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

Re: [RFC PATCH 08/15] ata: ahci_platform: Manage SATA PHY

[Sergei Shtylyov]

Hello.

On 09/19/2013 05:05 PM, Roger Quadros wrote:


From: Balaji T K balaj...@ti.com



Some platforms have a PHY hooked up to the
SATA controller. The PHY needs to be initialized
and powered up for SATA to work. We do that
using the PHY framework.



[Roger Q] Cleaned up.



CC: Tejun Heo t...@kernel.org
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com

[...]


diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 1145637..94484cb 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -37,6 +37,7 @@

  #include linux/clk.h
  #include linux/libata.h
+#include linux/phy/phy.h


struct phy;

should suffice.


@@ -322,6 +323,7 @@ struct ahci_host_priv {
u32 em_buf_sz;  /* EM buffer size in byte */
u32 em_msg_type;/* EM message type */
struct clk  *clk;   /* Only for platforms 
supporting clk */
+   struct phy  *phy;   /* If platforms use phy */
void*plat_data; /* Other platform data */
  };

diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 2daaee0..f812ffa 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -23,6 +23,7 @@
  #include linux/platform_device.h
  #include linux/libata.h
  #include linux/ahci_platform.h
+#include linux/phy/phy.h


   Why include it from both ahci.h and here?


  #include ahci.h

  static void ahci_host_stop(struct ata_host *host);
@@ -141,16 +142,32 @@ static int ahci_probe(struct platform_device *pdev)
}
}

+   hpriv-phy = devm_phy_get(dev, sata-phy);
+   if (IS_ERR(hpriv-phy)) {
+   dev_err(dev, can't get phy\n);


   Don't think it's a good idea to complain about missing PHY when the driver 
doesn't even use it.



+   /* return only if -EPROBE_DEFER */
+   if (PTR_ERR(hpriv-phy) == -EPROBE_DEFER) {
+   rc = -EPROBE_DEFER;
+   goto disable_unprepare_clk;
+   }
+   }
+
/*
 * Some platforms might need to prepare for mmio region access,
 * which could be done in the following init call. So, the mmio
 * region shouldn't be accessed before init (if provided) has
 * returned successfully.
 */
+
+   if (!(IS_ERR(hpriv-phy))) {


   () not needed around IS_ERR() invocation.


+   phy_init(hpriv-phy);
+   phy_power_on(hpriv-phy);
+   }
+


   I think this is misplaced, i.e. it should precede the comment.


if (pdata  pdata-init) {
rc = pdata-init(dev, hpriv-mmio);
if (rc)
-   goto disable_unprepare_clk;
+   goto disable_phy;
}

ahci_save_initial_config(dev, hpriv,

[...]

@@ -328,6 +356,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend, 
ahci_resume);
  static const struct of_device_id ahci_of_match[] = {
{ .compatible = snps,spear-ahci, },
{ .compatible = snps,exynos5440-ahci, },
+   { .compatible = snps,dwc-ahci, },


   Looks like the binding documentation is incomplete -- it doesn't list 
snps,exynos5440-ahci...


WBR, Sergei

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

Re: [RFC PATCH 08/15] ata: ahci_platform: Manage SATA PHY

[Sergei Shtylyov]

Hello.

On 09/22/2013 08:58 PM, Tejun Heo wrote:


From: Balaji T K balaj...@ti.com



Some platforms have a PHY hooked up to the
SATA controller. The PHY needs to be initialized
and powered up for SATA to work. We do that
using the PHY framework.



[Roger Q] Cleaned up.



CC: Tejun Heo t...@kernel.org
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com



Looks okay to me although I don't know whether everyone using
ahci_platform would be happy with requiring phy.  Sergei, does this
look good to you?


   Not sure why you asked -- I'm not using this driver, neither I'm the 
author of it (former MV's Anton Vorontsov is IIRC). I've commented on the 
patch anyway though...



Thanks.


WBR, Sergei

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

Re: [RFC PATCH 15/15] arm: dts: dra7: add sata node

[Sergei Shtylyov]

On 09/20/2013 02:19 PM, Roger Quadros wrote:


From: Balaji T K balaj...@ti.com



Add support for sata controller.



[Roger Q] Clean up.



CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
   arch/arm/boot/dts/dra7.dtsi |   49 
+++
   1 files changed, 49 insertions(+), 0 deletions(-)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..545545d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -426,6 +426,55 @@

[...]


+sata: sata@4a141100 {
+compatible = ti,sata;
+ti,hwmods = sata;
+reg = 0x4a141100 0x7;


   Not 0x8 BTW?


+#address-cells = 1;
+#size-cells = 1;
+ranges;
+dwc-ahci@4a14 {



Hm, ePAPR spec. [1] says that the name of a node should be somewhat generic, reflecting 
the function of the device and not its precise programming model, so it looks like the name 
should be sata as well. I'm a bit at a loss here, not sure why you had to use the 
nested device nodes.



ok. will fix it to sata.
I've nested it because the wrapper registers are not part of the AHCI sata 
controller.
They are TI specific registers for power management.
Similar setup is on the USB controller. Please see omap_dwc3 node.



But if you have better idea, please let me know.


Don't know, it seems to me that you're over-complicating it by using the 
nested nodes. You could just have AHCI regs as a first tuple of the regs 
prop, and PM regs as a second tuple.



+  compatible = snps,dwc-ahci;
+  reg = 0x4a14 0x1100;
+  interrupts = 0 54 0x4;
+  phys = sata_phy;



Hm, it's the third PHY related generic property I'm encountering. First, there was 
phy-handle, then phy, now phys... Seems like a bit too much. :-)



I'm afraid but this is how the designers have made it.



1) control-phy-pipe3 is that part of the PHY which sits in control module space 
and is different
from the sata-phy space and hence needs a different node. If it were to me, I 
would just put this
resource in sata-phy node, but there was a discussion about this earlier to do 
it otherwise [1].



2) sata-phy (sataphy) is the actual SATA PHY device.



3) phys is just a reference to the sata_phy and is used via the generic PHY 
framework.
It is upto the sata driver to power up/down the phy.


   I understand that it's a reference but why have 3 variants of such phandle 
containing prop? Is it really possible for a device to have multiple PHYs? 
Well, remembering our customer's USB, it's indeed possible, however, there 2 
PHYs out of 3 are not software controllable...



+  phy-names = sata-phy;
+  clocks = sata_ref_clk;
+  clock-names = optclk;
+};
+};



[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf



cheers,
-roger



[1] - https://lkml.org/lkml/2012/9/10/399


WBR, Sergei

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

Re: [RFC PATCH 15/15] arm: dts: dra7: add sata node

[Sergei Shtylyov]

Hello.

On 09/19/2013 05:24 PM, Roger Quadros wrote:


From: Balaji T K balaj...@ti.com



Add support for sata controller.



[Roger Q] Clean up.



CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
  arch/arm/boot/dts/dra7.dtsi |   49 +++
  1 files changed, 49 insertions(+), 0 deletions(-)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..545545d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -426,6 +426,55 @@
dma-names = tx, rx;
};

+   omap_control_sata: control-phy@4a002374 {
+   compatible = ti,control-phy-pipe3;
+   reg = 0x4a002374 0x4;
+   reg-names = power;
+   clocks = sys_clkin1;
+   clock-names = sysclk;
+   };
+
+   ocp2scp3: ocp2scp3@4a09 {
+   compatible = ti,omap-ocp2scp;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   ti,hwmods = ocp2scp3;
+   reg = 0x4a09 0x1f; /* ocp2scp3 */
+   reg-names = ocp2scp3;
+   sata_phy: sataphy@4A096000 {


   It's better to name the PHY nodes uniformly after already standard 
ethernet-phy and your control-phy.



+   compatible = ti,phy-pipe3-sata;
+   reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+   reg-names = phy_rx, phy_tx, pll_ctrl;
+   ctrl-module = omap_control_sata;
+   clocks = sata_ref_clk,
+sys_clkin1;
+   clock-names = optclk, sysclk;
+   #phy-cells = 0;
+   };
+   };
+
+   sata: sata@4a141100 {
+   compatible = ti,sata;
+   ti,hwmods = sata;
+   reg = 0x4a141100 0x7;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   dwc-ahci@4a14 {


   Hm, ePAPR spec. [1] says that the name of a node should be somewhat 
generic, reflecting the function of the device and not its precise programming 
model, so it looks like the name should be sata as well. I'm a bit at a 
loss here, not sure why you had to use the nested device nodes.



+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100;
+ interrupts = 0 54 0x4;
+ phys = sata_phy;


   Hm, it's the third PHY related generic property I'm encountering. First, 
there was phy-handle, then phy, now phys... Seems like a bit too much. :-)



+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ clock-names = optclk;
+   };
+   };


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

--
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: [RFC PATCH 12/15] ARM: dts: omap5: add ocp2scp1 address resource

[Sergei Shtylyov]

On 09/19/2013 05:23 PM, Roger Quadros wrote:


Add OCP2SCP1 module address space.



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



diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 06aa665..8a88a94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -663,6 +663,7 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp1;
+   reg = 0x4a08 0x1f;


   Are you sure length is not 0x20?

WBR, Sergei

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

Re: [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode

[Sergei Shtylyov]

Hello.

On 09-09-2013 10:42, Mugunthan V N wrote:


Add DT entries for the phy mode selection in AM33xx SoC using
cpsw-phy-sel
driver.



Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
   arch/arm/boot/dts/am33xx.dtsi | 6 ++
   1 file changed, 6 insertions(+)



diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..4359672 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -594,6 +594,12 @@
   /* Filled in by U-Boot */
   mac-address = [ 00 00 00 00 00 00 ];
   };
+
+phy_sel: cpsw_phy_sel@44e10650 {



Dashes are preferred to uderscores in the device tree names.



I tried with dashes but i get the below error.



$ make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm dtbs
   DTC arch/arm/boot/dts/am335x-evm.dtb
Error: arch/arm/boot/dts/am33xx.dtsi:598.11-12 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/arm/boot/dts/am335x-evm.dtb] Error 1
make: *** [dtbs] Error 2


   Hm, perhaps the dashes can't be used in the labels but I was talking of 
the names. Dashes in the node names should be definitely valid.



Regards
Mugunthan V N


WBR, Sergei


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

Re: [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode

[Sergei Shtylyov]

Hello.

On 09/08/2013 03:23 PM, Mugunthan V N wrote:


Add DT entries for the phy mode selection in AM33xx SoC using cpsw-phy-sel
driver.



Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
  arch/arm/boot/dts/am33xx.dtsi | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..4359672 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -594,6 +594,12 @@
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
+
+   phy_sel: cpsw_phy_sel@44e10650 {


   Dashes are preferred to uderscores in the device tree names.


+   compatible = ti,am3352-cpsw-phy-sel;
+   reg= 0x44e10650 0x4;
+   reg-names = gmii-sel;
+   };


WBR, Sergei

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

Re: [PATCH 1/1] arm: dts: am33xx: correcting dt node unit address for usb

[Sergei Shtylyov]

Hello.

On 08/30/2013 09:52 PM, Mugunthan V N wrote:


DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.



Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
  arch/arm/boot/dts/am33xx.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..e9b6775 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi

[...]

@@ -449,7 +449,7 @@
tx14, tx15;
};

-   cppi41dma: dma-controller@07402000 {
+   cppi41dma: dma-controller@47402000 {


   Not @4740? Look at the first entry in the reg prop.


compatible = ti,am3359-cppi41;
reg =  0x4740 0x1000
0x47402000 0x1000


WBR, Sergei

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

Re: [PATCH v2 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[Sergei Shtylyov]

Hello.

On 08/28/2013 05:59 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian george.cher...@ti.com
---
  arch/arm/boot/dts/dra7-evm.dts | 52 +-
  1 file changed, 51 insertions(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..9ee97c0 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,17 @@
device_type = memory;
reg = 0x8000 0x6000; /* 1536 MB */
};
+
+   extcon1: gpio_usbvid_extcon1 {
+   compatible = ti,gpio-usb-id;
+   gpios = pcf_21 1 0;
+   };
+
+   extcon2: gpio_usbvid_extcon2 {
+   compatible = ti,gpio-usb-id;
+   gpios = pcf_21 2 0;
+   };
+
  };

  dra7_pmx_core {
@@ -33,10 +44,49 @@
  };
  };

+i2c1 {
+   clock-frequency = 40;
+
+   pcf_20: pcf8575@20 {


   Acorrding to the ePAPR spec [1], the name of a node should be somewhat 
generic, reflecting the function of the device and not its precise 
programming model. If appropriate, the name should be one of the following 
choices:


[...]
- gpio
[...]


+   compatible = ti,pcf8575;
+   reg = 0x20;
+   n_latch = 0x4000;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-parent = gpio6;
+   interrupts = 11 2;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   pcf_21: pcf8575@21 {


   Same comment here.


+   compatible = ti,pcf8575;
+   reg = 0x21;
+   n_latch = 0x1408;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-parent = pcf_20;
+   interrupts = 14 2;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+};
+


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

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

Re: [PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[Sergei Shtylyov]

On 08/28/2013 09:33 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian george.cher...@ti.com
---
  arch/arm/boot/dts/dra7-evm.dts | 50 +-
  1 file changed, 49 insertions(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..8b0738a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts

[...]

@@ -33,10 +44,47 @@
  };
  };

+i2c1 {
+   clock-frequency = 40;
+
+   gpio20: pcf8575@20 {


ePAPR was talking about the node naming, not about labelling. Back to the 
drawing board. ;-)



+   compatible = ti,pcf8575;
+   reg = 0x20;
+   n_latch = 0x4000;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-parent = gpio6;
+   interrupts = 11 2;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpio21: pcf8575@21 {
+   compatible = ti,pcf8575;
+   reg = 0x21;
+   n_latch = 0x1408;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-parent = pcf_20;
+   interrupts = 14 2;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+};
+


WBR, Sergei

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

Re: [PATCH] ARM: dts: add AM33XX EDMA support

[Sergei Shtylyov]

Hello.

On 08/23/2013 11:06 PM, Sebastian Andrzej Siewior wrote:


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



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



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



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



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



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



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = 0x4820 0x1000;
};

+   edma: edma@4900 {


   The node should be named dma-controller, not edma,according to ePAPR 
section 2.2.2:


http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

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

Re: [PATCH] ARM: dts: add AM33XX EDMA support

[Sergei Shtylyov]

Hello.

On 08/24/2013 10:33 PM, Joel Fernandes wrote:


Updating CC with Matt's current email address.



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



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



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



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



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



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



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
   reg = 0x4820 0x1000;
   };

+edma: edma@4900 {



The node should be named dma-controller, not edma,according to ePAPR
section 2.2.2:



http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf



So you mean something like the following?



edma: dma-controller@4900 {
   ...
}


   Yes, exactly.


Thanks,



-Joel


WBR, Sergei

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

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

[Sergei Shtylyov]

Hello.

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


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



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



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

[...]


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

[...]

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

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


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


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


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



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


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



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


WBR, Sergei

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

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

[Sergei Shtylyov]

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


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



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



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

[...]


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

[...]

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

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


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


res = PTR_ERR(priv-gmii_sel_reg);


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


WBR, Sergei


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

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

[Sergei Shtylyov]

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


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



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



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


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



And don't  you want to do:



res = PTR_ERR(priv-gmii_sel_reg);


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



Erm, of course. Sorry for that.



Daniel


WBR, Sergei

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

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

[Sergei Shtylyov]

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


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



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



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

[...]

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

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

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


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



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


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


ret = PTR_ERR(ss_regs);


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

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


   Same comment about resource check here...


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


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



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

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

[...]

WBR, Sergei

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

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

[Sergei Shtylyov]

Hello.

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


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



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



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



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

[...]

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

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


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

WBR, Sergei

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

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

[Sergei Shtylyov]

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


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



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



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



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



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



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

[...]


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

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


   Parens around decimal literals are hardly needed even in macros.

WBR, Sergei

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

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

[Sergei Shtylyov]

Hello.

On 08/22/2013 03:37 PM, Daniel Mack wrote:


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



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



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



diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 05d660e..4e5ca54 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt

[...]

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 63feaae..4855d8e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c

[...]

@@ -2012,6 +2013,27 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}

+   /* If the control memory region is unspecified, continue without it.
+* If it is specified, but we're unable to reserve it, bail. */


   According to Documentation/CodingStyle, the networking code's preferred 
style of multi-line comments is this:


/* Bla
 * bla
 */


+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_err(priv-dev, error getting control i/o resource\n);
+   goto no_gmii_sel;
+   }
+   if (!devm_request_mem_region(pdev-dev, res-start, resource_size(res),
+ndev-name)) {


   Not dev_name(pdev-dev)?


+   dev_err(priv-dev, failed request control i/o region\n);
+   ret = -ENXIO;


   Rather -EBUSY.


+   goto clean_runtime_disable_ret;
+   }
+   priv-gmii_sel_reg = devm_ioremap(pdev-dev, res-start,
+ resource_size(res));
+   if (!priv-gmii_sel_reg) {
+   dev_err(priv-dev, unable to map control i/o region\n);
+   goto clean_runtime_disable_ret;
+   }


   Why not use devm_ioremap_resource() instead of the above sequence?


+
+no_gmii_sel:


WBR, Sergei

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

Re: [PATCH v5 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

Re: [PATCH v4 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()

[Sergei Shtylyov]

Hello.

On 08/19/2013 02:37 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.



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 |   22 ++
  1 files changed, 18 insertions(+), 4 deletions(-)



diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..981313e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c

[...]

@@ -198,6 +199,12 @@ static int omap_usb3_probe(struct platform_device *pdev)
  {
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;


   Could you align the variable names with the above 2 variables?
Either that, or remove the alignment of those two.

WBR, Sergei

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

Re: [PATCH] usb: dwc3: core: modify IO memory resource after deferred probe completes

[Sergei Shtylyov]

On 07/25/2013 08:26 PM, Ivan T. Ivanov wrote:


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



When deferred probe happens driver will try to ioremap multiple times
and will fail. Memory resource.start variable is a global variable,
modifications in this field will be accumulated on every probe.
Fix this by moving the above operations after driver hold all
required PHY's.



Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
  drivers/usb/dwc3/core.c |   31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)



diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 607bef8..50c833f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c

[...]

@@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}

+   dwc-xhci_resources[0].start = res-start;
+   dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
+   DWC3_XHCI_REGS_END;
+   dwc-xhci_resources[0].flags = res-flags;
+   dwc-xhci_resources[0].name = res-name;
+
+   res-start += DWC3_GLOBALS_REGS_START;
+
+/*
+ * Request memory region but exclude xHCI regs,
+ * since it will be requested by the xhci-plat driver.
+ */


Please remove an extra space after a tab on each comment line.
It seems like a good time to do it, while you're moving this code.


+   regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
+


WBR, Sergei

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

Re: [PATCH] ARM: OMAP3EVM: Marking omap3_evm_display_init() with CONFIG_BROKEN

[Sergei Shtylyov]

Hello.

On 22-07-2013 9:29, Paul Walmsley wrote:


From: Lokesh Vutla lokeshvu...@ti.com



On 37xx EVM non-dt boot fails with current mainline,
because of broken GPIO numbering in the board file
that uses hardcoded GPIOs.



So marking omap3_evm_display_init() with CONFIG_BROKEN
for now as suggested by Tony as per the below link:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90399.html



Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Tested-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com



---



Hi -stablers,



OMAP37xx EVM does not boot on v3.10 without this patch, so please consider
it for the v3.10 stable releases.  It is upstream already as commit ID
8fb61e8d84e673eebf31e564a83bb71a50b1ed48.  Perhaps if I had managed to
test it sooner, we could have gotten it up during v3.10-rc, but, alas,
stable it is...



  arch/arm/mach-omap2/board-omap3evm.c |4 
  1 file changed, 4 insertions(+)



diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..278bf25 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -174,6 +174,7 @@ static struct panel_sharp_ls037v7dw01_data 
omap3_evm_lcd_data = {
.ud_gpio = OMAP3EVM_LCD_PANEL_UD,
  };

+#ifdef CONFIG_BROKEN
  static void __init omap3_evm_display_init(void)
  {
int r;
@@ -193,6 +194,7 @@ static void __init omap3_evm_display_init(void)
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
  }


   Perhaps it's better to follow what Documentation/SubmittingPatches suggests:

#else
static inline __init void omap3_evm_display_init(void) {}


+#endif

  static struct omap_dss_device omap3_evm_lcd_device = {
.name   = lcd,
@@ -715,7 +717,9 @@ static void __init omap3_evm_init(void)

omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
+#ifdef CONFIG_BROKEN
omap3_evm_display_init();
+#endif


   ... and eliminate #ifdef here?

WBR, Sergei

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

Re: [PATCH v2 3/4] arm: dts: Add USB phy nodes for AM33XX

[Sergei Shtylyov]

Hello.

On 19-07-2013 16:34, George Cherian wrote:


Add phy nodes for AM33XX platform and split the musb nodes
per instance.



Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: George Cherian george.cher...@ti.com
---
  arch/arm/boot/dts/am33xx.dtsi | 68 +--
  1 file changed, 53 insertions(+), 15 deletions(-)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..e3890c4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -326,21 +326,59 @@
status = disabled;
};

-   usb@4740 {
-   compatible = ti,musb-am33xx;
-   reg = 0x4740 0x1000 /* usbss */
-  0x47401000 0x800 /* musb instance 0 */
-  0x47401800 0x800;/* musb instance 1 */
-   interrupts = 17 /* usbss */
- 18/* musb instance 0 */
- 19;   /* musb instance 1 */
-   multipoint = 1;
-   num-eps = 16;
-   ram-bits = 12;
-   port0-mode = 3;
-   port1-mode = 3;
-   power = 250;
-   ti,hwmods = usb_otg_hs;
+   phy1: am335x-usb0@44e10620 {


   Shouldn't the PHYs be *under* the usb0/1 device nodes in the hierarchy?
They're not on the same bus as the MUSB controllers for sure.


+   compatible = ti,am335x-usb2;
+   #phy-cells = 0;
+   id= 0;


   Forgot space before =.


+   };
+
+   phy2: am335x-usb1@44e10628 {
+   compatible = ti,am335x-usb2;
+   #phy-cells = 0;
+   id= 1;


   Same here.


+   };
+
+   omap_control_usb: omap-control-usb@44e10620 {
+   compatible = ti,omap-control-usb;
+   reg = 0x44e10620 0x10;
+   reg-names = control_dev_conf;
+   ti,type = 3;
+   };
+
+musb: usb@4740 {
+compatible = ti,musb-am33xx;
+reg = 0x4740 0x1000;
+ranges;
+#address-cells = 1;
+#size-cells = 1;
+interrupts = 17;
+ti,hwmods = usb_otg_hs;
+
+usb0@47401000 {


   I don't think you need index in the name since you have the address as a 
part of the name anyway. That way it's closer to the ePAPR spec.



+reg = 0x47401000 0x800;
+interrupts = 18;
+interrupt-names = mc;
+multipoint = 1;
+num-eps = 16;
+ram-bits = 12;
+port-mode = 3;
+power = 250;
+phys = phy1;


   The above lines are indented with spaces, the below one with tabs. Use 
tabs please.



+   phy-names = am335x-usb0;
+};
+
+usb1@47401800 {
+reg = 0x47401800 0x800;
+interrupts = 19;
+interrupt-names = mc;
+multipoint = 1;
+num-eps = 16;
+ram-bits = 12;
+port-mode = 3;
+power = 250;
+phys = phy2;


   The above lines are indented with spaces, the below one with tabs. Use 
tabs please.



+   phy-names = am335x-usb1;
+   };
};


WBR, Sergei

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

Re: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree

[Sergei Shtylyov]

Hello.

On 19-07-2013 13:27, Oleksandr Kozaruk wrote:


GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.



Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
  arch/arm/boot/dts/twl6030.dtsi | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..d7d4c28 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+   adc: gpadc {


   Read my lips: the node should be called just adc, not gpadc.

WBR, Sergei

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

Re: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree

[Sergei Shtylyov]

Hello.

On 07/19/2013 07:40 PM, Grygorii Strashko wrote:


GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.



Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
  arch/arm/boot/dts/twl6030.dtsi | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/arch/arm/boot/dts/twl6030.dtsi
b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..d7d4c28 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
  compatible = ti,twl6030-pwmled;
  #pwm-cells = 2;
  };
+
+adc: gpadc {



Read my lips: the node should be called just adc, not gpadc.

    Are you sure?


   I didn't know how to express my disappointment from Oleksandr's inability 
to understand what I wanted to convey to him from 2 attempts... first, he 
changed the label instead of the node name, then he only dropped twl6030_ 
prefix from the name. I should probably have been even more specific before.



Why? The name was selected according to the documentation on device General
purpose analog-to-digital converter (GPADC).


   Sigh, we simply don't care whether this ADC is general-purpose or not.
The main thing it is ADC.


PS. Following your logic - GPIO need to renamed to IO everywhere ;P


   GPIO is well known and established abbreviation, contrasted to GPADC.
Moreover, ePAPR spec lists gpio as a generic node name.

WBR, Sergei

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

Re: [PATCH v2 3/4] arm: dts: Add USB phy nodes for AM33XX

[Sergei Shtylyov]

Hello.

On 07/19/2013 06:20 PM, Sebastian Andrzej Siewior wrote:


diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..e3890c4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -326,21 +326,59 @@
   status = disabled;
   };

-usb@4740 {
-compatible = ti,musb-am33xx;
-reg = 0x4740 0x1000/* usbss */
-   0x47401000 0x800/* musb instance 0 */
-   0x47401800 0x800;/* musb instance 1 */
-interrupts = 17/* usbss */
-  18/* musb instance 0 */
-  19;/* musb instance 1 */
-multipoint = 1;
-num-eps = 16;
-ram-bits = 12;
-port0-mode = 3;
-port1-mode = 3;
-power = 250;
-ti,hwmods = usb_otg_hs;
+phy1: am335x-usb0@44e10620 {



Shouldn't the PHYs be *under* the usb0/1 device nodes in the hierarchy?
They're not on the same bus as the MUSB controllers for sure.



I redo the complete thing. I have now:



usb: usb@4740 {
compatible = ti,am33xx-usb;

usb0_phy: phy@47401300 {
compatible = ti,am335x-usb-phy;
}
usb0: usb@47401000 {
musb0: usb@47401400 {
compatible = mg,musbmhdrc;
}
}
usb1_phy: phy@47402300 {
compatible = ti,am335x-usb-phy;
}
usb1: usb@47402000 {
musb1: usb@47402400 {
compatible = mg,musbmhdrc;
}
}
}



And you want usb0_phy to be child of usb0? In the TRM they are all in
the same block.


   Ah, the fact that PHYs didn't have the reg property got me muddled, I 
didn't pay attention to the address part of the node names... BTW, where is 
the reg prop? I see PHYs share the address space with 
omap-control-usb@44e10620 device -- what's the point with this?



Sebastian


WBR, Sergei

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

Re: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree

[Sergei Shtylyov]

Hello.

On 17-07-2013 15:12, Oleksandr Kozaruk wrote:


GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.



Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
  arch/arm/boot/dts/twl6030.dtsi | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..322aa8e 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+   adc: twl6030_gpadc {


   I was talking about the device name, not label. The twl6030_gpadc part.

WBR, Sergei

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

Re: [PATCH v4 1/2] ARM: dts: twl: Add GPADC data to device tree

[Sergei Shtylyov]

Hello.

On 07/16/2013 03:34 PM, Oleksandr Kozaruk wrote:


GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.



Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
  arch/arm/boot/dts/twl6030.dtsi | 6 ++
  1 file changed, 6 insertions(+)



diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+   gpadc: twl6030_gpadc {
+   compatible = ti,twl6030_gpadc;
+   interrupts = 3;
+   #io-channel-cells = 1;
+   };


   ePAPR [1] says: The name of a node should be somewhat generic, 
reflecting the function of the device and not its precise programming 
model.


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

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

Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node

[Sergei Shtylyov]

Hello.

On 09-07-2013 13:17, George Cherian wrote:


Adds device node for HS USB Host module for AM437x



changes from v1



renamed synopsis to snps
removed flag tx-fifo-resize



Signed-off-by: George Cherian george.cher...@ti.com
---
  arch/arm/boot/dts/am4372.dtsi | 18 ++
  1 file changed, 18 insertions(+)



diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible = 
ti,am4372-counter32k,ti,omap-counter32k;
reg = 0x44e86000 0x40;
};
+
+   usb_otg_hs1: am4372_dwc3@4838 {


   See http://www.devicetree.org/Device_Tree_Usage, Node Names section.


+   compatible = ti,am437x-dwc3;
+   reg = 0x4838 0x1ff;
+   interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+   #address-cells = 1;
+   #size-cells = 1;
+   utmi-mode = 1;
+   ranges;
+
+   dwc3@4839 {


   The same comment.


+   compatible = snps,dwc3;
+   reg = 0x4839 0xcfff;
+   interrupts = GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH;
+   };
+
+   };
+   


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