RE: [PATCH 0/5] usb: musb: am335x support

2013-04-03 Thread B, Ravi
Felipe

 
 Hi,
 
 On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
  On 03.04.2013 14:04, Felipe Balbi wrote:
   On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
 
   Felipe, could you explain the background on how the dsps driver is
   supposed to work in host mode at boot time with the rework of the
 driver
   you did for 3.7? It might just be me not understanding the rationale
   behind all these changes, but appearantly, I'm not the only one who's
   affected by that.
  
   right, so the idea with that was to drop the huge amount of ifdeferry
   hack from the MUSB driver. It would be great if someone would send
   *CLEAN* patches adding Kconfig-based role choices again.
 
  Are Kconfig-based rules really what we want here after all? Wouldn't
  run-time configured settings make much more sense, considering that
 
 we need both. Say that you want to build a product with MUSB hardwired
 as host, why would you enable gadget framework ?
 
 I can think of at least am335x where this would be perfectly plausible
 (no EHCI available, only MUSB).
 
  people might want to run a single kernel image on multiple platforms? I
  believe it should be up to the DT to define the actual hardware wiring.
 
 Right, for runtime decision Ravi pointed me to a patch implementing that
 (Ravi, could you post it by any chance as RFC ?) which we could start a
 discussion and hopefully merge for v3.11

Ok. 

--
Ravi B
--
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 0/7] usb: musb: add driver for control module

2013-01-15 Thread B, Ravi
 Hi,
 
 On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
  Hi Arnd,
  
  On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
  On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
  Added a new driver for the usb part of control module. 
 This has an 
  API to power on the USB2 phy and an API to write to the mailbox 
  depending on whether MUSB has to act in host mode or in 
 device mode.
  
  Writing to control module registers for doing the above 
 task which 
  was previously done in omap glue and in omap-usb2 phy is removed.
  
  Also added the dt data to get MUSB working in OMAP platforms.
  This series has patches for both drivers and ARCH 
 folders, so If it 
  has to be split I'll do it.
  
  
  The series looks good to me, I just had a minor comment on 
 one patch.
  
  One a somewhat related topic, I wonder whether there are 
 any plans on 
  your side to change this driver to support multiple bus 
 glues to be 
  built for one kernel image. With a multiplatform kernel, 
 we may need 
  all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.
  
  We don't have plans as of now. I actually don't expect any 
 changes in 
  the driver other than the Kconfig changes. Anyways the 
 probe of glue's 
  other than the platform it's running won't get called. right Felipe?

If understand correctly the control module driver used to configure the 
respective usb phy of SoC to respective usb modes using the common set of 
control module APIs. What if, if control module interface (register defintions) 
varies b/w different revision or spin of same type of SoCs, if usbphy type is 
changed. In this case whether the single instance of control module driver is 
good enough to cater of all cpu types of same SoC series ? 
Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM 
driver?

 
 AFAICT there's nothing preventing those from being built 
 together as long as you don't use DMA (yeah, that's a touchy 
 subject still with MUSB).
 
 If there are any build breaks, please report them so bus glue 
 owners can fix. I see that at least the davinci folks need to 
 work a bit
 
 $ git grep -e mach\/ drivers/usb/musb/ 
 drivers/usb/musb/da8xx.c:#include mach/da8xx.h 
 drivers/usb/musb/davinci.c:#include mach/cputype.h 
 drivers/usb/musb/davinci.c:#include mach/hardware.h
 
 I'm adding Ravi B to the loop here for those.
 
 --
 balbi
 --
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 0/5] usb: musb: am335x support

2012-11-02 Thread B, Ravi
 
 On 02.11.2012 17:31, Afzal Mohammed wrote:
  This series adds usb support to am335x SoC's found on boards like 
  Beagle Bone. Here only first instance is supported, as currently 
  multiple phy's of same type is not supported (am335x has two USB2 
  phy's).
 
 I'm testing these patches with an AM33xx board that has the 
 first musb port wired to an USB type A plug, but it doesn't 
 yet work for me.
 
 The messages I'm getting are:
 
 [1.219339] ehci_hcd: USB 2.0 'Enhanced' Host Controller 
 (EHCI) Driver
 [1.226568] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver

Why ehci, ohci has selected for am335xx platform?

 [1.233444] usbcore: registered new interface driver uas
 [1.239066] Initializing USB Mass Storage driver...
 [1.244395] usbcore: registered new interface driver usb-storage
 [1.250732] USB Mass Storage support registered.
 [1.255573] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
 [1.262671] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
 combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
 [1.262889] musb-hdrc: MHDRC RTL version 2.0
 [1.262907] musb-hdrc: setup fifo_mode 4
 [1.262940] musb-hdrc: 28/31 max ep, 16384/16384 memory
 
 So there is no host interface registered. I'm unsure on how 

The host interface will be registered when you load the gadget driver, (like 
insmod g_zero.ko ,etc).

 to fix this, and I didn't get an answer yet to that question 
 when I asked Felipe about how interface drivers like dsps are 
 supposed to act in order to get host mode back after the 
 recent musb cleanups.
 
 What type of hardware do you test this with? Does host mode 
 work for you?
 

By default only otg build is supported, you must insert the gadget module for 
each usb port in order to enable the host/device functionality. Have you 
checked with loading any gadget module (g_ether.ko, or g_ether.ko etc)? 

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


RE: [PATCH v9 00/13] usb: musb: adding multi instance support

2012-09-11 Thread B, Ravi
 
 Hi,
 
 On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote:
  This series of patches adds,
  a) Multi instances support in musb driver
  b) DT support for musb_dsps glue layer
  c) DT support for NOP transceiver
  
  AM33xx and TI81xx has dual musb controller and has two usb 
 PHY of same type.
  This patch series uses 'phandle' based API 
  devm_usb_get_phy_by_phandle() to get the PHY of same type. This API 
  support is being added by Kishon's patch discussed at [1]
  
  The series applies to felipe/master [1] branch
  + Vaibhav baseport patches on his tree at [4]
  + Kishon's multi phy patches on Felipe's branch 'xceiv'
  + Kishon's patch on phandle at [2]
  + Damodar's recent patch at [3] 
  + Ajay's  Damodar's patches at [5] and [6] included in 
 this series
  
  1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary
  2. http://marc.info/?l=linux-usbm=134070369306112w=2
  3. http://marc.info/?l=linux-usbm=134200284230689w=2
  4. 
  
 https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-stagi
  ng 5. http://marc.info/?l=linux-usbm=134200285530701w=2
  6. http://marc.info/?l=linux-usbm=134208820028625w=2
  
  Changes from v8:
  - included Sergei's comment, removing underscore in 
 device tree file
  - removed duplicated signoff from patches Changes from v7:
  - patches rebased on felipe/master branch  verified
  - included additional two patches 0001  0002 as part 
 of this series
which are already submitted [5]  [6] Changes from v6:
  - Removed parent_pdev to get glue and used 
 dev_get_getdrv() as per
Felipe's comment
  - use pr_debug() instead of pr_info() as per Felipe's 
 comment Changes 
  from v5:
  - Removed musb-id as per Felipe's comment
  - used nop_ida as per Felipe's comment Changes from v4:
  - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL()
  - Fixed Felipe's comment on using dev_set_mask() 
 Changes from v3:
  - Fixed Kishon's comment on removing id from phy struct and
removing unneeded #else part.
  Changes from v2:
  - Fixed Sergei's comment on not using address prefix in 
 musb_dsps
glue and nop transceiver dt dats.
  - Also removed the ti string in compatible property 
 for nop data.
  Changes from v1:
  - Defined musb_ida to manage core ids based on Felipe's comment
in [PATCH 01/11]
 
 I tried appliying this, but this doesn't apply. Please rebase 
 on my musb branch. Unfortunately there's no time anymore to 
 wait otherwise the entire musb branch will miss this merge window.
 
 I'm sorry

Felipe, patch set is ready, I will re-send the patches shortly by today.

 
 --
 balbi
 --
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 v9 00/13] usb: musb: adding multi instance support

2012-09-11 Thread B, Ravi
   
   On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote:
This series of patches adds,
a) Multi instances support in musb driver
b) DT support for musb_dsps glue layer
c) DT support for NOP transceiver

AM33xx and TI81xx has dual musb controller and has two usb
   PHY of same type.
This patch series uses 'phandle' based API
devm_usb_get_phy_by_phandle() to get the PHY of same type. This 
API support is being added by Kishon's patch discussed at [1]

The series applies to felipe/master [1] branch
+ Vaibhav baseport patches on his tree at [4]
+ Kishon's multi phy patches on Felipe's branch 'xceiv'
+ Kishon's patch on phandle at [2]
+ Damodar's recent patch at [3] 
+ Ajay's  Damodar's patches at [5] and [6] included in
   this series

1. 

 http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary
2. http://marc.info/?l=linux-usbm=134070369306112w=2
3. http://marc.info/?l=linux-usbm=134200284230689w=2
4. 

   
 https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-sta
   gi
ng 5. http://marc.info/?l=linux-usbm=134200285530701w=2
6. http://marc.info/?l=linux-usbm=134208820028625w=2

Changes from v8:
- included Sergei's comment, removing underscore in
   device tree file
- removed duplicated signoff from patches 
 Changes from v7:
- patches rebased on felipe/master branch  verified
- included additional two patches 0001  0002 as part
   of this series
  which are already submitted [5]  [6] Changes from v6:
- Removed parent_pdev to get glue and used
   dev_get_getdrv() as per
  Felipe's comment
- use pr_debug() instead of pr_info() as per Felipe's
   comment Changes
from v5:
- Removed musb-id as per Felipe's comment
- used nop_ida as per Felipe's comment Changes from v4:
- Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL()
- Fixed Felipe's comment on using dev_set_mask()
   Changes from v3:
- Fixed Kishon's comment on removing id from 
 phy struct and
  removing unneeded #else part.
Changes from v2:
- Fixed Sergei's comment on not using address prefix in
   musb_dsps
  glue and nop transceiver dt dats.
- Also removed the ti string in compatible property
   for nop data.
Changes from v1:
- Defined musb_ida to manage core ids based on 
 Felipe's comment
  in [PATCH 01/11]
   
   I tried appliying this, but this doesn't apply. Please 
 rebase on my 
   musb branch. Unfortunately there's no time anymore to 
 wait otherwise 
   the entire musb branch will miss this merge window.
   
   I'm sorry
  
  Felipe, patch set is ready, I will re-send the patches 
 shortly by today.
 
 Thanks a lot. So I'll wait for a few more hours before 
 sending out my musb pull request ;-)
 

Thanks Felipe, these v9 patches are created on felipe/master branch. Now 
working on, to rebase on felipe/musb branch, will try to provide by end of 
today. 

 --
 balbi
 --
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 v9 01/13] usb: musb: dsps: add phy control logic to glue

2012-09-04 Thread B, Ravi
 On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote:
  Hi,
  
  On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi ba...@ti.com wrote:
   Hi,
  
   On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote:
   From: Santhapuri, Damodar damodar.santhap...@ti.com
  
   AM335x uses NOP transceiver driver and need to enable 
 builtin PHY 
   by writing into usb_ctrl register available in system control 
   module register space. This is being added at musb glue driver 
   layer untill a separate system control module driver is 
 available.
  
   Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
   Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
   Signed-off-by: Ravi Babu ravib...@ti.com
  
   Kishon, you were adding a real phy driver for OMAP's internal phy 
   logic on one of your patches and I believe this will 
 conflict with 
   your changes, right ?
  
  Indeed. My final patch of that series removes some of the functions 
  from omap_phy_internal.c (which was taken care in the phy driver).
  
   How does this look to you ? Is this at least correct ? I 
 suppose the 
   correct way would be to actually have the system control module 
   driver which we have been waiting, right ?
  
  Correct. I think once we have the system control module driver in 
  place, we'll have everything wrt control module register writes 
  implemented in correct way.
 
 So $SUBJECT will pretty much be thrown away once we have SCM 
 driver, in that case it's best to wait a bit longer and apply 
 this series once SCM driver is available and after your 
 series too... you agree ?
 

Felipe, I am sure there are patches in this series[0/13], which are not 
dependent on this patch or control module,
Can we pull in those patches (all dual instances support patches)? So that I 
can re-work and submit again? 

 --
 balbi
 --
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 v9 01/13] usb: musb: dsps: add phy control logic to glue

2012-09-04 Thread B, Ravi
Hi

 AM335x uses NOP transceiver driver and need to enable
   builtin PHY
 by writing into usb_ctrl register available in 
 system control 
 module register space. This is being added at musb 
 glue driver 
 layer untill a separate system control module driver is
   available.

 Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
 Signed-off-by: Santhapuri, Damodar 
 damodar.santhap...@ti.com
 Signed-off-by: Ravi Babu ravib...@ti.com

 Kishon, you were adding a real phy driver for OMAP's internal 
 phy logic on one of your patches and I believe this will
   conflict with
 your changes, right ?

Indeed. My final patch of that series removes some of the 
functions from omap_phy_internal.c (which was taken 
 care in the phy driver).

 How does this look to you ? Is this at least correct ? I
   suppose the
 correct way would be to actually have the system 
 control module 
 driver which we have been waiting, right ?

Correct. I think once we have the system control module 
 driver in 
place, we'll have everything wrt control module register writes 
implemented in correct way.
   
   So $SUBJECT will pretty much be thrown away once we have 
 SCM driver, 
   in that case it's best to wait a bit longer and apply this series 
   once SCM driver is available and after your series too... 
 you agree 
   ?
   
  
  Felipe, I am sure there are patches in this series[0/13], which are 
  not dependent on this patch or control module, Can we pull in those 
  patches (all dual instances support patches)? So that I can re-work 
  and submit again?
 
 sure, will do, don't worry :-)

Thanks.
Then shall I rework patches [3/13 to 13/13] and re-submit only musb dual 
instances patches which 
are independent of control module. 

 
 --
 balbi
 --
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 v8 08/13] arm/dts: am33xx: Add dt data for usbss

2012-08-31 Thread B, Ravi
 On Thu, Aug 30, 2012 at 03:39:40PM +0400, Sergei Shtylyov wrote:
  Hello.
  
  On 30-08-2012 14:50, Ravi Babu wrote:
  
  From: Ajay Kumar Gupta ajay.gu...@ti.com
  
  Added device tree data for usbss on am33xx. There are two musb 
  controllers on am33xx platform so have port0_mode and 
 port1_mode additional data.
  
  Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
  Signed-off-by: Ravi Babu ravib...@ti.com
  Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
  Signed-off-by: Ravi Babu ravib...@ti.com
  ---
arch/arm/boot/dts/am33xx.dtsi |   11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
  
  diff --git a/arch/arm/boot/dts/am33xx.dtsi 
  b/arch/arm/boot/dts/am33xx.dtsi index 59509c4..778b95e 100644
  --- a/arch/arm/boot/dts/am33xx.dtsi
  +++ b/arch/arm/boot/dts/am33xx.dtsi
  @@ -154,5 +154,16 @@
 #size-cells = 0;
 ti,hwmods = i2c3;
 };
  +
  +  usb_otg_hs: usb_otg_hs {
  +  compatible = ti,musb-am33xx;
  +  ti,hwmods = usb_otg_hs;
  +  multipoint = 1;
  +  num_eps = 16;
  +  ram_bits = 12;
  +  port0_mode = 3;
  +  port1_mode = 3;
  
 Hyphen is preferred traditionally to underscore in the 
 device tree files...
 
 Are we having a v2 of this patch ??

Felipe, I will send it shortly.

Regards
Ravi B
 
 --
 balbi
 --
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 v8 08/13] arm/dts: am33xx: Add dt data for usbss

2012-08-31 Thread B, Ravi
 
 On Thu, Aug 30, 2012 at 4:20 PM, Ravi Babu ravib...@ti.com wrote:
  From: Ajay Kumar Gupta ajay.gu...@ti.com
 
  Added device tree data for usbss on am33xx. There are two musb 
  controllers on am33xx platform so have port0_mode and 
 port1_mode additional data.
 
  Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
  Signed-off-by: Ravi Babu ravib...@ti.com
  Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
  Signed-off-by: Ravi Babu ravib...@ti.com
 
 One Signed-off-by: Ravi Babu would suffice :-)

Yes, by mistake, signoff got added two times. I will check and remove it from 
all patches if any.

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


RE: [PATCH v7 00/11] usb: musb: adding multi instance support

2012-08-03 Thread B, Ravi
Hi Daniel

   This series of patches adds,
   a) Multi instances support in musb driver
   b) DT support for musb_dsps glue layer
   c) DT support for NOP transceiver
  
   AM33xx and TI81xx has dual musb controller and has two usb
   PHY of same type.
   This patch series uses 'phandle' based API
   devm_usb_get_phy_by_phandle() to get the PHY of same type. This 
   API support is being added by Kishon's patch discussed at [1]
  
   The series applies to linux-omap (master branch)
   + Vaibhav baseport patches on his tree at [3]
   + Kishon's multi phy patches on Felipe's branch 'xceiv'
   + Kishon's patch on phandle at [1]
   + AM33xx musb glue compile and bugfix patches at [4],
   [5], [6] and [7]
   + Damodar's recent patch at [2]
  
   and have been tested on Beaglebone board.
  
   Have you applied the above patches before applying these patches.
  
  Somehow, I was missing some of Ajay's patches. I resolved that, and 
  now the series applied.
  
  However, I needed to add a phandle usb0-phy = usb0_phy to the 
  usb_otg_hs DTSI block, otherwise devm_usb_get_phy_by_phandle() in 
  drivers/usb/musb/musb_dsps.c would fail. Is that correct? I 
 can't seem 
  to find that in your patches.
 
 It's getting done in patch 11/11.

Refer patch 11/11 available at 
http://marc.info/?l=linux-usbm=134390988804627w=2 

Ravi Babu

 
  
  With this addition, I see the following:
  
  [1.782180] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
  [1.809966] musb-hdrc musb-hdrc.0: MUSB HDRC host driver
  [1.819068] musb-hdrc musb-hdrc.0: new USB bus 
 registered, assigned
  bus number 1
  [1.827970] usb usb1: New USB device found, idVendor=1d6b,
  idProduct=0002
  [1.835184] usb usb1: New USB device strings: Mfr=3, Product=2,
  SerialNumber=1
  [1.842818] usb usb1: Product: MUSB HDRC host driver
  [1.848031] usb usb1: Manufacturer: Linux
  3.6.0-rc1-00038-g8a1ec8f-dirty musb-hcd
  [1.855933] usb usb1: SerialNumber: musb-hdrc.0
  [1.866913] hub 1-0:1.0: USB hub found
  [1.871192] hub 1-0:1.0: 1 port detected
  [1.878106] musb-hdrc musb-hdrc.0: USB Host mode controller at
  d08c using PIO, IRQ 18  
  
  ... but no USB functions. Also, every two seconds, the following 
  message is
  printed:
  
  [   11.036608] musb_bus_suspend 2308: trying to suspend as 
 a_wait_vrise
  while active
  [   13.044811] musb_bus_suspend 2308: trying to suspend as 
 a_wait_vrise
  while active
  [   15.052196] musb_bus_suspend 2308: trying to suspend as 
 a_wait_vrise
  while active
 
 Do you see them even when you connect a device to port?
 
 Ajay
  
  
  Anything obvious that I'm missing?
  
  
  Thanks,
  Daniel
  --
  To unsubscribe from this list: send the line unsubscribe 
 linux-usb 
  in the body of a message to majord...@vger.kernel.org More 
 majordomo 
  info at http://vger.kernel.org/majordomo-info.html
 --
 -
 This email message is for the sole use of the intended 
 recipient(s) and may contain confidential information.  Any 
 unauthorized review, use, disclosure or distribution is 
 prohibited.  If you are not the intended recipient, please 
 contact the sender by reply email and destroy all copies of 
 the original message.
 --
 -
 --
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 v7 00/11] usb: musb: adding multi instance support

2012-08-03 Thread B, Ravi
 
 On 03.08.2012 11:07, Hiremath, Vaibhav wrote:
  I have just pushed the code (V7 which Ravi submitted), so can you 
  please try with below branch?
  
  
 https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-
  usb
 
 Thanks for doing this, but I'm unfortunately getting tons of 
 merge conflicts when I try to put this on top of 3.6-rc1. 
 Still pondering which way around is the easiest to get this solved.
 
 OTOH, I wonder whether your staging branches would need to 
 rebased sooner or later anyway?
 

Sorry, We don't have patches on latest v3.6-rc1 and will take couple of days.

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


RE: [PATCH v7 00/11] usb: musb: adding multi instance support

2012-08-02 Thread B, Ravi
Hi

 
 On 02.08.2012 14:12, Ravi Babu wrote:
  This series of patches adds,
  a) Multi instances support in musb driver
  b) DT support for musb_dsps glue layer
  c) DT support for NOP transceiver
  
  AM33xx and TI81xx has dual musb controller and has two usb 
 PHY of same type.
  This patch series uses 'phandle' based API 
  devm_usb_get_phy_by_phandle() to get the PHY of same type. This API 
  support is being added by Kishon's patch discussed at [1]
  
  The series applies to linux-omap (master branch)
  + Vaibhav baseport patches on his tree at [3]
  + Kishon's multi phy patches on Felipe's branch 'xceiv'
  + Kishon's patch on phandle at [1]
  + AM33xx musb glue compile and bugfix patches at [4], 
 [5], [6] and [7]
  + Damodar's recent patch at [2]
  
  and have been tested on Beaglebone board.

Have you applied the above patches before applying these patches.

Ravi Babu

 
 I would like to test these patches on a custom AM33xx board, 
 but I'm having trouble applying them. I am based on Linus' 
 master tree, and git am fails for 
 drivers/usb/musb/musb_dsps.c. The commits I got for that file are:
 
 ded017ee6 usb: phy: fix return value check of usb_get_phy 
 662dca54c usb: otg: support for multiple transceivers by a 
 single controller
 721002ec1 usb: otg: utils: rename function name in OTG utils
 9ecb88752 usb: musb: Add support for ti81xx platform
 
 I wonder which branch you are based on and which tree those 
 patches should go thru eventually.
 
 
 Thanks,
 Daniel
 
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v6 04/11] usb: otg: nop: add support for multiple tranceiver

2012-08-01 Thread B, Ravi
 
Hi

 Subject: Re: [PATCH v6 04/11] usb: otg: nop: add support for 
 multiple tranceiver
 
 On Fri, Jul 27, 2012 at 02:02:00PM +0530, Ravi B wrote:
  +static void nop_put_id(int id)
  +{
  +
  +   pr_info(removing id %d\n, id);
 
 not pr_info. I guess pr_vdebug() is better. We don't want to 
 know about every new nop ID requested.

Ok. Agreed. 

Thanks
Ravibabu
 
 --
 balbi
 --
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 03/11] usb: musb: am335x: add support for dual instance

2012-07-31 Thread B, Ravi
 Hi,
 
 On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
  From: Ajay Kumar Gupta ajay.gu...@ti.com
  
  AM335x and TI81xx platform has dual musb controller so updating the 
  musb_dspc.c to support the same.
  
  Changes:
  - Moved otg_workaround timer to glue structure
  - Moved static local variable last_timer to glue structure
  - PHY on/off related cleanups
  
  Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
  Signed-off-by: Ravi B ravib...@ti.com
  ---
   drivers/usb/musb/musb_dsps.c |  118 
  +
   1 files changed, 72 insertions(+), 46 deletions(-)
  
  diff --git a/drivers/usb/musb/musb_dsps.c 
  b/drivers/usb/musb/musb_dsps.c index 2174699..2fd5dc8 100644
  --- a/drivers/usb/musb/musb_dsps.c
  +++ b/drivers/usb/musb/musb_dsps.c
  @@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
  /* miscellaneous stuff */
  u32 musb_core_offset;
  u8  poll_seconds;
  +   /* number of musb instances */
  +   u8  instances;
   };
   
   /**
  @@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
   struct dsps_glue {
  struct device *dev;
  -   struct platform_device *musb;   /* child musb pdev */
  +   struct platform_device *musb[2];/* child musb pdev */
  const struct dsps_musb_wrapper *wrp; /* wrapper 
 register offsets */
  -   struct timer_list timer;/* otg_workaround timer */
  -   u32 __iomem *usb_ctrl;
  +   struct timer_list timer[2]; /* otg_workaround timer */
  +   unsigned long last_timer[2];/* last timer data for 
 each instance */
  +   u32 __iomem *usb_ctrl[2];
  u8  usbss_rev;
   };
   
   /**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
  + * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system 
  control @@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a 
 seperate driver for
* control module
*/
  -static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
  +static void musb_dsps_phy_control(struct dsps_glue *glue, 
 u8 id, u8 
  +on)
   {
  u32 usbphycfg;
   
  -   usbphycfg = __raw_readl(glue-usb_ctrl);
  +   usbphycfg = __raw_readl(glue-usb_ctrl[id]);
   
  if (on) {
  if (glue-usbss_rev == MUSB_USBSS_REV_816X) { 
 @@ -157,7 +161,7 @@ 
  static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
  glue-usbss_rev == MUSB_USBSS_REV_33XX)
  usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
  }
  -   __raw_writel(usbphycfg, glue-usb_ctrl);
  +   __raw_writel(usbphycfg, glue-usb_ctrl[id]);
   }
   /**
* dsps_musb_enable - enable interrupts @@ -207,8 +211,9 @@ static 
  void otg_timer(unsigned long _musb)
  struct musb *musb = (void *)_musb;
  void __iomem *mregs = musb-mregs;
  struct device *dev = musb-controller;
  -   struct platform_device *pdev = to_platform_device(dev-parent);
  -   struct dsps_glue *glue = platform_get_drvdata(pdev);
  +   struct platform_device *pdev = to_platform_device(dev);
  +   struct platform_device *parent_pdev = 
 to_platform_device(dev-parent);
  +   struct dsps_glue *glue = platform_get_drvdata(parent_pdev);
  const struct dsps_musb_wrapper *wrp = glue-wrp;
  u8 devctl;
  unsigned long flags;
  @@ -247,7 +252,7 @@ static void otg_timer(unsigned long _musb)
   
  devctl = dsps_readb(mregs, MUSB_DEVCTL);
  if (devctl  MUSB_DEVCTL_BDEVICE)
  -   mod_timer(glue-timer,
  +   mod_timer(glue-timer[pdev-id],
  jiffies + 
 wrp-poll_seconds * HZ);
  else
  musb-xceiv-state = OTG_STATE_A_IDLE; 
 @@ -261,9 +266,9 @@ static 
  void otg_timer(unsigned long _musb)  static void 
  dsps_musb_try_idle(struct musb *musb, unsigned long timeout)  {
  struct device *dev = musb-controller;
  -   struct platform_device *pdev = to_platform_device(dev-parent);
  -   struct dsps_glue *glue = platform_get_drvdata(pdev);
  -   static unsigned long last_timer;
  +   struct platform_device *pdev = to_platform_device(dev);
  +   struct platform_device *parent_pdev = 
 to_platform_device(dev-parent);
  +   struct dsps_glue *glue = platform_get_drvdata(parent_pdev);
 
 just one thing that could be cleaned on a later patch:
 
 if parent_pdev is only used to get to struct dsps_glue, you 
 could just:
 
 struct dsps_glue *glue = dev_get_drvdata(dev-parent);
 
 with no need to do a container_of() to the platform_device ;-)

Yes Felipe, parent_pdev is only to get dsps_glue. I will include this change in 
later patch.

RaviBabu
 
 --
 balbi
 --
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 TI81xx fix MUSB software mode setting

2012-06-19 Thread B, Ravi

 - Original Message -
 From: Andrea Scian [mailto:r...@dave-tech.it]
 Sent: Monday, June 18, 2012 08:25 PM
 To: linux-omap@vger.kernel.org linux-omap@vger.kernel.org
 Subject: RFC: PATCH TI81xx fix MUSB software mode setting
 
 
 Dear all,
 
 when configuring our platform (DM8148 based) to work with 
 USB0 as device and USB1 as host I've found some problems.

It seems that you created the patch against the ti-psp release, there
is another way to achieve this (one port as host and other port as device). 
Please refer to release/user's guide.
Moreover, you should create a patch against mainline, where the musb_dsps.c is
used instead of ti81xx.c, where there is no host-only or device-only mode, by 
default OTG mode is used.

 It was fine if I configure both as device or both as host or 
 enable only one port, but configure both in different modes 
 lead to a not working configuration.
 After a bit of debug I've found that probably the problem is inside
 ti81xx_musb_set_mode() because this configure the controller 
 but does not set musb-board_mode. IIUC, without setting this 
 structure the whole musb generic state machine does not work 
 correctly.
 Attached you can find the patch that fixed the problem on our 
 board. I hope -this can help others too and can be integrated 
 inside the main tree.
 Feel free to comment and tell me if I've done something wrong.
 
 I hope the the patch format is quite correct for you.
 
 Best Regards,
 
 
 -- 
 
 Andrea SCIAN
 --
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