Re: [PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-09 Thread Kishon Vijay Abraham I 
hi,

On Wednesday 09 September 2015 09:33 AM, Guenter Roeck wrote:
> On Sun, Sep 06, 2015 at 04:41:10PM -0700, Guenter Roeck wrote:
>> On Thu, Sep 03, 2015 at 03:25:11PM +0530, Kishon Vijay Abraham I wrote:
>>> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
>>> OMAP5 and DRA7 SoCs. Enable it here.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I 
>>
>> Tested-by: Guenter Roeck 
>>
> This problem is now causing various runtime failures in mainline.
> I see the following qemu test failures:
> 
> arm:beagle:multi_v7_defconfig:omap3-beagle
> arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> arm:overo:multi_v7_defconfig:omap3-overo-tobi
> 
> I would expect all omap2/3/4/5 runtime tests with multi_v7_defconfig to fail.
> 
> Also, FWIW,
> 
> Fixes: 6a9b2ff07d04 ("mmc: host: omap_hsmmc: return on fatal errors from 
> omap_hsmmc_reg_get")

I've resend the patch to a...@kernel.org and it bounced back from Nicolas
Pitre. However others like Arnd, Thomas, Olof would have received and I
think they'll be applying this soonish.

Thanks
Kishon

> 
> Guenter
> 
>>> ---
>>>  arch/arm/configs/multi_v7_defconfig |1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>>> b/arch/arm/configs/multi_v7_defconfig
>>> index 5fd8df6..f497c96 100644
>>> --- a/arch/arm/configs/multi_v7_defconfig
>>> +++ b/arch/arm/configs/multi_v7_defconfig
>>> @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
>>>  CONFIG_REGULATOR_MAX77686=y
>>>  CONFIG_REGULATOR_MAX77693=m
>>>  CONFIG_REGULATOR_PALMAS=y
>>> +CONFIG_REGULATOR_PBIAS=y
>>>  CONFIG_REGULATOR_S2MPS11=y
>>>  CONFIG_REGULATOR_S5M8767=y
>>>  CONFIG_REGULATOR_TPS51632=y
>>> -- 
>>> 1.7.9.5
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>>
--
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 07/13] usb: otg: add OTG core

2015-09-09 Thread Li Jun 
On Mon, Sep 07, 2015 at 01:53:19PM +0300, Roger Quadros wrote:
> On 07/09/15 10:40, Li Jun wrote:
> > On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> >> The OTG core instantiates the OTG Finite State Machine
> >> per OTG controller and manages starting/stopping the
> >> host and gadget controllers based on the bus state.
> >>
> >> It provides APIs for the following tasks
> >>
> >> - Registering an OTG capable controller
> >> - Registering Host and Gadget controllers to OTG core
> >> - Providing inputs to and kicking the OTG state machine
> >>
> >> Signed-off-by: Roger Quadros 
> >> ---
> >>  MAINTAINERS  |4 +-
> >>  drivers/usb/Kconfig  |2 +-
> >>  drivers/usb/Makefile |1 +
> >>  drivers/usb/common/Makefile  |3 +-
> >>  drivers/usb/common/usb-otg.c | 1061 
> >> ++
> >>  drivers/usb/common/usb-otg.h |   71 +++
> >>  drivers/usb/core/Kconfig |   11 +-
> >>  include/linux/usb/otg.h  |  189 +++-
> >>  8 files changed, 1321 insertions(+), 21 deletions(-)
> >>  create mode 100644 drivers/usb/common/usb-otg.c
> >>  create mode 100644 drivers/usb/common/usb-otg.h
> >>
> > 
> > ... ...
> > 
> >> +
> >> +/**
> >> + * Get OTG device from host or gadget device.
> >> + *
> >> + * For non device tree boot, the OTG controller is assumed to be
> >> + * the parent of the host/gadget device.
> > 
> > This assumption/restriction maybe a problem, as I pointed in your previous
> > version, usb_create_hcd() use the passed dev as its dev, but,
> > usb_add_gadget_udc() use the passed dev as its parent dev, so often the
> > host and gadget don't share the same parent device, at least it doesn't
> > apply to chipidea case.
> 
> Let's provide a way for OTG driver to provide the OTG core exactly which is
> the related host/gadget device.
> 
> > 
> >> + * For device tree boot, the OTG controller is derived from the
> >> + * "otg-controller" property.
> >> + */
> >> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
> >> +{
> >> +  struct device *otg_dev;
> >> +
> >> +  if (!hcd_gcd_dev)
> >> +  return NULL;
> >> +
> >> +  if (hcd_gcd_dev->of_node) {
> >> +  struct device_node *np;
> >> +  struct platform_device *pdev;
> >> +
> >> +  np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
> >> +0);
> >> +  if (!np)
> >> +  goto legacy;/* continue legacy way */
> >> +
> >> +  pdev = of_find_device_by_node(np);
> >> +  of_node_put(np);
> >> +  if (!pdev) {
> >> +  dev_err(>dev, "couldn't get otg-controller 
> >> device\n");
> >> +  return NULL;
> >> +  }
> >> +
> >> +  otg_dev = >dev;
> >> +  return otg_dev;
> >> +  }
> >> +
> >> +legacy:
> >> +  /* otg device is parent and must be registered */
> >> +  otg_dev = hcd_gcd_dev->parent;
> >> +  if (!usb_otg_get_data(otg_dev))
> >> +  return NULL;
> >> +
> >> +  return otg_dev;
> >> +}
> >> +
> > 
> > ... ...
> > 
> >> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
> >> +{
> >> +  struct otg_fsm *fsm = >fsm;
> >> +  unsigned long tmouts[NUM_OTG_FSM_TIMERS];
> >> +  int i;
> >> +
> >> +  /* set default timeouts */
> >> +  tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
> >> +  tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
> >> +  tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
> >> +  tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
> >> +  tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
> >> +  tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
> >> +  tmouts[B_SE0_SRP] = TB_SE0_SRP;
> >> +  tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
> >> +
> >> +  /* set controller provided timeouts */
> >> +  if (timeouts) {
> >> +  for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
> >> +  if (timeouts[i])
> >> +  tmouts[i] = timeouts[i];
> >> +  }
> >> +  }
> >> +
> >> +  otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
> >> + >a_wait_vrise_tmout);
> >> +  otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
> >> + >a_wait_vfall_tmout);
> >> +  otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
> >> + >a_wait_bcon_tmout);
> >> +  otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
> >> + >a_aidl_bdis_tmout);
> >> +  otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
> >> + >a_bidl_adis_tmout);
> >> +  otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
> >> + >b_ase0_brst_tmout);
> >> +
> >> +  otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
> >> + >b_se0_srp);
> >> +  otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
> >> + >b_srp_done);
> >> +
> >> +  /* FIXME: what about A_WAIT_ENUM? */
> > 
> > Either you init it as other timers, or you remove all of it, otherwise
> > there will be

freeze on OMAP4460, timestamps jumping

2015-09-09 Thread Kunal Singh 
Hi,

We have a OMAP4460 based platform running Android Jellybean. We have
observed that OMAP can totally freeze at times, leading to watchdog
reboot.

There are two test cases which consistently reproduce the problem
- Running Camera Preview
- copying large files to eMMC.

Both of the above test cases involve heavy DMA. So, we are suspecting
that crash may be related to some DMA processing/logic.

After the watchdog reboot, last_kmsg consistently show two things
- A sudden jump in timestamps prior to crash
- Unhandled Fault in the kernel logs. The fault type can vary, but
it's mostly one of the following
   - Unhandled fault: imprecise external abort (0x1406)
   - Unhandled fault: external abort on non-linefetch (0x1008)

>From last_kmsg, the PC/LR is mostly at omap4_prm_inst_read_inst_reg
and omap4_pwrdm_read_pwrst respectively. Sometimes at other places
(e.g. sched_clock )

Can someone suggest what might be causing this?

Regards,
Kunal
--
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 07/13] usb: otg: add OTG core

2015-09-09 Thread Roger Quadros 
On 09/09/15 05:21, Peter Chen wrote:
> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>
>>
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
 On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops 
>> *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
>
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg 
> device
> in your patch), like chipidea and dwc2.
>
> Then, otg_dev will be glue layer device for chipidea after that.

 OK. Let's add a way for the otg controller driver to provide the host and 
 gadget
 information to the otg core for such devices like chipidea and dwc2.

>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
 This API must be called before the hcd/gadget-driver is added so that the 
 otg
 core knows it's linked to an OTG controller.

 Any better idea?

>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
> 
> How usb_otg_register_hcd get struct usb_otg, from where?

This only works when the parent driver creating the hcd has registered the
otg controller too.

> 
>>
>>>
>>> Peter
>>>
>>> P.S: I still read your code, I find not all APIs in this file are used
>>> in your dwc3 example. 
>>
>> Which ones? The ones for registering/unregistered host/gadget are used
>> by hcd/udc core as part of usb_add/remove_hcd() and
>> udc_bind_to_driver()/usb_gadget_remove_driver()
>>
> 
> Ok, now I understand your design, usb_create_hcd must be called before
> the fsm kicks off. The call flow like below:
> 
> usb_otg_register->usb_create_hcd->usb_add_hcd->usb_otg_register_hcd->
> usb_otg_start_host->usb_otg_add_hcd

Actually these are the discrete steps
- usb_otg_register
- usb_create_hcd
- usb_add_hcd->usb_otg_register_hcd  (HCD is not really added till FSM in host 
role)

Above 3 are prerequisite for FSM to start in addition to gadget controller and
driver being ready.

When FSM enters in host role
- usb_otg_start_host(true)->usb_otg_add_hcd (Now HCD is added)

When FSM exits host role
- usb_otg_start_host(false)->usb_otg_remove_hcd (Now HCD is removed, but not 
unregistered)

If HCD hardware really goes away
- usb_remove_hcd->usb_otg_unregister_hcd (Now FSM stops as host resource not 
available)

> 
> We need to make some changes to let chipidea work since usb_create_hcd
> is included at host->start.
> 

Yes, you just need to do the usb_add_hcd() in probe
and

Re: freeze on OMAP4460, timestamps jumping

2015-09-09 Thread Kunal Singh 
Hi,

In continuation to my earlier email, here are the kernel logs
[last_kmsg on watchdog reboot]
http://paste.ubuntu.com/12319445/
http://paste.ubuntu.com/12319449/
http://paste.ubuntu.com/12319453/
http://paste.ubuntu.com/12319460/

One thought we had was that may be sudden time-stamp jump is causing
the crash. So, we built kernel with CONFIG_NO_HZ. But that didn't
help.
We have also tried kernel image built with CONFIG_PRINTK_TIME &
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK and options. Still we run in to
identical problems.

We have total three product variants using similar platform. The
problem occurs only on one of the three products.
Also, on the failing product, some devices are stable [have never
failed the tests]. Out of failing boards, some boards have higher
failure frequency. Could the problem be related to Power/Clock
management? Is there any particular item we can check w.r.t. hardware.

Regards,
Kunal

On 9 September 2015 at 13:50, Kunal Singh  wrote:
> Hi,
>
> We have a OMAP4460 based platform running Android Jellybean. We have
> observed that OMAP can totally freeze at times, leading to watchdog
> reboot.
>
> There are two test cases which consistently reproduce the problem
> - Running Camera Preview
> - copying large files to eMMC.
>
> Both of the above test cases involve heavy DMA. So, we are suspecting
> that crash may be related to some DMA processing/logic.
>
> After the watchdog reboot, last_kmsg consistently show two things
> - A sudden jump in timestamps prior to crash
> - Unhandled Fault in the kernel logs. The fault type can vary, but
> it's mostly one of the following
>- Unhandled fault: imprecise external abort (0x1406)
>- Unhandled fault: external abort on non-linefetch (0x1008)
>
> From last_kmsg, the PC/LR is mostly at omap4_prm_inst_read_inst_reg
> and omap4_pwrdm_read_pwrst respectively. Sometimes at other places
> (e.g. sched_clock )
>
> Can someone suggest what might be causing this?
>
> Regards,
> Kunal



-- 

Kunal Singh
Embedded Systems Developer, BARTEC PIXAVI

Email:kunal.si...@bartec-pixavi.com
Mobile:+91 9818408590
Skype:kunalbangalore
Website:www.bartec-pixavi.com

Confidentiality:
The contents of this email including all text and
attachments are hereby marked as confidential
and proprietary information of BARTEC PIXAVI
--
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 07/13] usb: otg: add OTG core

2015-09-09 Thread Roger Quadros 
On 09/09/15 11:13, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
>> On 09/09/15 05:21, Peter Chen wrote:
>>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:


 On 08/09/15 11:31, Peter Chen wrote:
> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>> On 07/09/15 04:23, Peter Chen wrote:
>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
 + * This is used by the USB Host stack to register the Host controller
 + * to the OTG core. Host controller must not be started by the
 + * caller as it is left upto the OTG state machine to do so.
 + *
 + * Returns: 0 on success, error value otherwise.
 + */
 +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
 +   unsigned long irqflags, struct otg_hcd_ops 
 *ops)
 +{
 +  struct usb_otg *otgd;
 +  struct device *hcd_dev = hcd->self.controller;
 +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
 +
>>>
>>> One big problem here is: there are two designs for current (IP) driver
>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>> Another one doesn't do this, roothub's parent is core device (or otg 
>>> device
>>> in your patch), like chipidea and dwc2.
>>>
>>> Then, otg_dev will be glue layer device for chipidea after that.
>>
>> OK. Let's add a way for the otg controller driver to provide the host 
>> and gadget
>> information to the otg core for such devices like chipidea and dwc2.
>>
>
> Roger, not only chipidea and dwc2, I think the musb uses the same
> hierarchy. If the host, device, and otg share the same register
> region, host part can't be a platform driver since we don't want
> to remap the same register region again.
>
> So, in the design, we may need to consider both situations, one
> is otg/host/device has its own register region, and host is a
> separate platform device (A), the other is three parts share the
> same register region, there is only one platform driver (B).
>
> A:
>
>   IP core device 
>   |
>   |
> |-|-|
> gadget   host platform device 
>   |
>   roothub
>
> B:
>
>   IP core device
>   |
>   |
> |-|-|
> gadget roothub
>   
>
>> This API must be called before the hcd/gadget-driver is added so that 
>> the otg
>> core knows it's linked to an OTG controller.
>>
>> Any better idea?
>>
>
> A flag stands for this hcd controller is the same with otg controller
> can be used, this flag can be stored at struct usb_otg_config.

 What if there is another architecture like so?

 C:
[Parent]
   |
   |
|--|--|
[OTG core]  [gadget][host]

 We need a more flexible mechanism to link the gadget and
 host device to the otg core for non DT case.

 How about adding struct usb_otg parameter to usb_otg_register_hcd()?

 e.g.
 int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)

 If otg is NULL it will try DT otg-controller property or parent to
 get the otg controller.
>>>
>>> How usb_otg_register_hcd get struct usb_otg, from where?
>>
>> This only works when the parent driver creating the hcd has registered the
>> otg controller too.
>>
> 
> Sorry? So we need to find another way to solve this issue, right?

For existing cases this is sufficient.
The otg device is either the one supplied during usb_otg_register_hcd
(cases B and C) or it is the parent device (case A).

It does not work when the 3 devices are totally independent and get registered
at different times.
I don't think there is such a case for non-DT yet, but let's not have this
limitation. So yes, we need to look for better solution :).

--
cheers,
-roger
--
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 07/13] usb: otg: add OTG core

2015-09-09 Thread Roger Quadros 
(adding back folks in cc)

On 08/09/15 20:35, Alan Stern wrote:
> On Tue, 8 Sep 2015, Roger Quadros wrote:
> 
 What if there is another architecture like so?

 C:
[Parent]
   |
   |
|--|--|
[OTG core]  [gadget][host]

 We need a more flexible mechanism to link the gadget and
 host device to the otg core for non DT case.

 How about adding struct usb_otg parameter to usb_otg_register_hcd()?

 e.g.
 int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)

 If otg is NULL it will try DT otg-controller property or parent to
 get the otg controller.
>>>
>>> This seems a lot like something Peter and I discussed recently.  See
>>>
>>> http://marc.info/?l=linux-usb=143977568021328=2
>>>
>>> and the following messages in that thread.
>>>
>>
>> If I understood right, your proposal was to add a usb_pointers data
>> struct to the device's drvdata?
> 
> Right.
> 
>> This is fine only if the otg/gadget/host share the same device.
>> It does not solve the problem where each have different platform devices.
> 
> Why not?  Each of the platform devices can store a pointer to the same 
> usb_pointers structure.  Wouldn't that be suitable?
> 

I didn't understand how all of them get the reference to the
same usb_pointer structure (or contents) when their respective platform devices
get created so that they can store it in their respective drvdata.

Worst case, the 3 devices could be totally independent of each other without a
common parent, and get registered at different times.

The common resource here is the physical USB port for which the 3 drivers
otg/host/gadget are being registered.
There should be a mechanism for each device to tell that it is part of
this particular USB port. (or usb_pointers struct)

cheers,
-roger
--
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 07/13] usb: otg: add OTG core

2015-09-09 Thread Peter Chen 
On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
> On 09/09/15 11:13, Peter Chen wrote:
> > On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
> >> On 09/09/15 05:21, Peter Chen wrote:
> >>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> 
> 
>  On 08/09/15 11:31, Peter Chen wrote:
> > On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> >> On 07/09/15 04:23, Peter Chen wrote:
> >>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>  + * This is used by the USB Host stack to register the Host 
>  controller
>  + * to the OTG core. Host controller must not be started by the
>  + * caller as it is left upto the OTG state machine to do so.
>  + *
>  + * Returns: 0 on success, error value otherwise.
>  + */
>  +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  + unsigned long irqflags, struct otg_hcd_ops 
>  *ops)
>  +{
>  +struct usb_otg *otgd;
>  +struct device *hcd_dev = hcd->self.controller;
>  +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>  +
> >>>
> >>> One big problem here is: there are two designs for current (IP) driver
> >>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> >>> Another one doesn't do this, roothub's parent is core device (or otg 
> >>> device
> >>> in your patch), like chipidea and dwc2.
> >>>
> >>> Then, otg_dev will be glue layer device for chipidea after that.
> >>
> >> OK. Let's add a way for the otg controller driver to provide the host 
> >> and gadget
> >> information to the otg core for such devices like chipidea and dwc2.
> >>
> >
> > Roger, not only chipidea and dwc2, I think the musb uses the same
> > hierarchy. If the host, device, and otg share the same register
> > region, host part can't be a platform driver since we don't want
> > to remap the same register region again.
> >
> > So, in the design, we may need to consider both situations, one
> > is otg/host/device has its own register region, and host is a
> > separate platform device (A), the other is three parts share the
> > same register region, there is only one platform driver (B).
> >
> > A:
> >
> > IP core device 
> > |
> > |
> >   |-|-|
> >   gadget   host platform device 
> > |
> > roothub
> >
> > B:
> >
> > IP core device
> > |
> > |
> >   |-|-|
> >   gadget roothub
> > 
> >
> >> This API must be called before the hcd/gadget-driver is added so that 
> >> the otg
> >> core knows it's linked to an OTG controller.
> >>
> >> Any better idea?
> >>
> >
> > A flag stands for this hcd controller is the same with otg controller
> > can be used, this flag can be stored at struct usb_otg_config.
> 
>  What if there is another architecture like so?
> 
>  C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
>  We need a more flexible mechanism to link the gadget and
>  host device to the otg core for non DT case.
> 
>  How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
>  e.g.
>  int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
>  If otg is NULL it will try DT otg-controller property or parent to
>  get the otg controller.
> >>>
> >>> How usb_otg_register_hcd get struct usb_otg, from where?
> >>
> >> This only works when the parent driver creating the hcd has registered the
> >> otg controller too.
> >>
> > 
> > Sorry? So we need to find another way to solve this issue, right?
> 
> For existing cases this is sufficient.
> The otg device is either the one supplied during usb_otg_register_hcd
> (cases B and C) or it is the parent device (case A).

How we differentiate case A and case B at usb_otg_register_hcd?
Would you show me the sample code?

> 
> It does not work when the 3 devices are totally independent and get registered
> at different times.
> I don't think there is such a case for non-DT yet, but let's not have this
> limitation. So yes, we need to look for better solution :).
> 

Yes, we need to find some places to store gadget/host/otg information,
Alan's suggestion to save them at device drvdata may be a

Re: [PATCH v4 07/13] usb: otg: add OTG core

2015-09-09 Thread Roger Quadros 
On 09/09/15 11:45, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
>> On 09/09/15 11:13, Peter Chen wrote:
>>> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
 On 09/09/15 05:21, Peter Chen wrote:
> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>
>>
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
 On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host 
>> controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops 
>> *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
>
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg 
> device
> in your patch), like chipidea and dwc2.
>
> Then, otg_dev will be glue layer device for chipidea after that.

 OK. Let's add a way for the otg controller driver to provide the host 
 and gadget
 information to the otg core for such devices like chipidea and dwc2.

>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
 This API must be called before the hcd/gadget-driver is added so that 
 the otg
 core knows it's linked to an OTG controller.

 Any better idea?

>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
>
> How usb_otg_register_hcd get struct usb_otg, from where?

 This only works when the parent driver creating the hcd has registered the
 otg controller too.

>>>
>>> Sorry? So we need to find another way to solve this issue, right?
>>
>> For existing cases this is sufficient.
>> The otg device is either the one supplied during usb_otg_register_hcd
>> (cases B and C) or it is the parent device (case A).
> 
> How we differentiate case A and case B at usb_otg_register_hcd?
> Would you show me the sample code?

Case A:

hcd platform driver doesn't know about otg device so it calls

usb_add_hcd(hcd,..)->usb_otg_register_hcd(NULL, hcd,..);

Case B:

core driver knows about both otg and hcd so it calls
usb_otg_register_hcd(otg, hcd,...);

code:

usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ...)
{
if

Re: [PATCH v4 07/13] usb: otg: add OTG core

2015-09-09 Thread Peter Chen 
On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
> On 09/09/15 05:21, Peter Chen wrote:
> > On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> >>
> >>
> >> On 08/09/15 11:31, Peter Chen wrote:
> >>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>  On 07/09/15 04:23, Peter Chen wrote:
> > On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> >> + * This is used by the USB Host stack to register the Host controller
> >> + * to the OTG core. Host controller must not be started by the
> >> + * caller as it is left upto the OTG state machine to do so.
> >> + *
> >> + * Returns: 0 on success, error value otherwise.
> >> + */
> >> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
> >> +   unsigned long irqflags, struct otg_hcd_ops 
> >> *ops)
> >> +{
> >> +  struct usb_otg *otgd;
> >> +  struct device *hcd_dev = hcd->self.controller;
> >> +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
> >> +
> >
> > One big problem here is: there are two designs for current (IP) driver
> > code, one creates dedicated hcd device as roothub's parent, like dwc3.
> > Another one doesn't do this, roothub's parent is core device (or otg 
> > device
> > in your patch), like chipidea and dwc2.
> >
> > Then, otg_dev will be glue layer device for chipidea after that.
> 
>  OK. Let's add a way for the otg controller driver to provide the host 
>  and gadget
>  information to the otg core for such devices like chipidea and dwc2.
> 
> >>>
> >>> Roger, not only chipidea and dwc2, I think the musb uses the same
> >>> hierarchy. If the host, device, and otg share the same register
> >>> region, host part can't be a platform driver since we don't want
> >>> to remap the same register region again.
> >>>
> >>> So, in the design, we may need to consider both situations, one
> >>> is otg/host/device has its own register region, and host is a
> >>> separate platform device (A), the other is three parts share the
> >>> same register region, there is only one platform driver (B).
> >>>
> >>> A:
> >>>
> >>>   IP core device 
> >>>   |
> >>>   |
> >>> |-|-|
> >>> gadget   host platform device 
> >>>   |
> >>>   roothub
> >>>
> >>> B:
> >>>
> >>>   IP core device
> >>>   |
> >>>   |
> >>> |-|-|
> >>> gadget roothub
> >>>   
> >>>
>  This API must be called before the hcd/gadget-driver is added so that 
>  the otg
>  core knows it's linked to an OTG controller.
> 
>  Any better idea?
> 
> >>>
> >>> A flag stands for this hcd controller is the same with otg controller
> >>> can be used, this flag can be stored at struct usb_otg_config.
> >>
> >> What if there is another architecture like so?
> >>
> >> C:
> >>[Parent]
> >>   |
> >>   |
> >>|--|--|
> >>[OTG core]  [gadget][host]
> >>
> >> We need a more flexible mechanism to link the gadget and
> >> host device to the otg core for non DT case.
> >>
> >> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> >>
> >> e.g.
> >> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> >>
> >> If otg is NULL it will try DT otg-controller property or parent to
> >> get the otg controller.
> > 
> > How usb_otg_register_hcd get struct usb_otg, from where?
> 
> This only works when the parent driver creating the hcd has registered the
> otg controller too.
> 

Sorry? So we need to find another way to solve this issue, right?

> > 
> >>
> >>>
> >>> Peter
> >>>
> >>> P.S: I still read your code, I find not all APIs in this file are used
> >>> in your dwc3 example. 
> >>
> >> Which ones? The ones for registering/unregistered host/gadget are used
> >> by hcd/udc core as part of usb_add/remove_hcd() and
> >> udc_bind_to_driver()/usb_gadget_remove_driver()
> >>
> > 
> > Ok, now I understand your design, usb_create_hcd must be called before
> > the fsm kicks off. The call flow like below:
> > 
> > usb_otg_register->usb_create_hcd->usb_add_hcd->usb_otg_register_hcd->
> > usb_otg_start_host->usb_otg_add_hcd
> 
> Actually these are the discrete steps
> - usb_otg_register
> - usb_create_hcd
> - usb_add_hcd->usb_otg_register_hcd  (HCD is not really added till FSM in 
> host role)
> 
> Above 3 are prerequisite for FSM to start in addition to gadget controller and
> driver being ready.
> 
> When FSM enters in host role
> - usb_otg_start_host(true)->usb_otg_add_hcd (Now HCD is added)
> 
> When FSM exits host role
> -

Re: [PATCH v4 07/13] usb: otg: add OTG core

2015-09-09 Thread Roger Quadros 
On 09/09/15 09:20, Li Jun wrote:
> On Mon, Sep 07, 2015 at 01:53:19PM +0300, Roger Quadros wrote:
>> On 07/09/15 10:40, Li Jun wrote:
>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
 The OTG core instantiates the OTG Finite State Machine
 per OTG controller and manages starting/stopping the
 host and gadget controllers based on the bus state.

 It provides APIs for the following tasks

 - Registering an OTG capable controller
 - Registering Host and Gadget controllers to OTG core
 - Providing inputs to and kicking the OTG state machine

 Signed-off-by: Roger Quadros 
 ---
  MAINTAINERS  |4 +-
  drivers/usb/Kconfig  |2 +-
  drivers/usb/Makefile |1 +
  drivers/usb/common/Makefile  |3 +-
  drivers/usb/common/usb-otg.c | 1061 
 ++
  drivers/usb/common/usb-otg.h |   71 +++
  drivers/usb/core/Kconfig |   11 +-
  include/linux/usb/otg.h  |  189 +++-
  8 files changed, 1321 insertions(+), 21 deletions(-)
  create mode 100644 drivers/usb/common/usb-otg.c
  create mode 100644 drivers/usb/common/usb-otg.h

>>>
>>> ... ...
>>>
 +
 +/**
 + * Get OTG device from host or gadget device.
 + *
 + * For non device tree boot, the OTG controller is assumed to be
 + * the parent of the host/gadget device.
>>>
>>> This assumption/restriction maybe a problem, as I pointed in your previous
>>> version, usb_create_hcd() use the passed dev as its dev, but,
>>> usb_add_gadget_udc() use the passed dev as its parent dev, so often the
>>> host and gadget don't share the same parent device, at least it doesn't
>>> apply to chipidea case.
>>
>> Let's provide a way for OTG driver to provide the OTG core exactly which is
>> the related host/gadget device.
>>
>>>
 + * For device tree boot, the OTG controller is derived from the
 + * "otg-controller" property.
 + */
 +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
 +{
 +  struct device *otg_dev;
 +
 +  if (!hcd_gcd_dev)
 +  return NULL;
 +
 +  if (hcd_gcd_dev->of_node) {
 +  struct device_node *np;
 +  struct platform_device *pdev;
 +
 +  np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
 +0);
 +  if (!np)
 +  goto legacy;/* continue legacy way */
 +
 +  pdev = of_find_device_by_node(np);
 +  of_node_put(np);
 +  if (!pdev) {
 +  dev_err(>dev, "couldn't get otg-controller 
 device\n");
 +  return NULL;
 +  }
 +
 +  otg_dev = >dev;
 +  return otg_dev;
 +  }
 +
 +legacy:
 +  /* otg device is parent and must be registered */
 +  otg_dev = hcd_gcd_dev->parent;
 +  if (!usb_otg_get_data(otg_dev))
 +  return NULL;
 +
 +  return otg_dev;
 +}
 +
>>>
>>> ... ...
>>>
 +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
 +{
 +  struct otg_fsm *fsm = >fsm;
 +  unsigned long tmouts[NUM_OTG_FSM_TIMERS];
 +  int i;
 +
 +  /* set default timeouts */
 +  tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
 +  tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
 +  tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
 +  tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
 +  tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
 +  tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
 +  tmouts[B_SE0_SRP] = TB_SE0_SRP;
 +  tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
 +
 +  /* set controller provided timeouts */
 +  if (timeouts) {
 +  for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
 +  if (timeouts[i])
 +  tmouts[i] = timeouts[i];
 +  }
 +  }
 +
 +  otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
 + >a_wait_vrise_tmout);
 +  otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
 + >a_wait_vfall_tmout);
 +  otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
 + >a_wait_bcon_tmout);
 +  otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
 + >a_aidl_bdis_tmout);
 +  otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
 + >a_bidl_adis_tmout);
 +  otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
 + >b_ase0_brst_tmout);
 +
 +  otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
 + >b_se0_srp);
 +  otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
 + >b_srp_done);
 +
 +  /* FIXME: what about A_WAIT_ENUM? */
>>>
>>> Either you init it as other timers, or you remove all of

Re: [PATCH v4 10/13] usb: hcd: Adapt to OTG core

2015-09-09 Thread Roger Quadros 
On 09/09/15 05:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:21PM +0300, Roger Quadros wrote:
>> The existing usb_add/remove_hcd() functionality
>> remains unchanged for non-OTG devices. For OTG
>> devices they only register the HCD with the OTG core.
>>
>> Introduce usb_otg_add/remove_hcd() for use by OTG core.
>> These functions actually add/remove the HCD.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/core/hcd.c | 55 
>> +-
>>  1 file changed, 50 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index c0fd1f6..4851682 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -46,6 +46,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "usb.h"
>>  
>> @@ -2625,8 +2626,8 @@ static void usb_put_invalidate_rhdev(struct usb_hcd 
>> *hcd)
>>   * buffers of consistent memory, register the bus, request the IRQ line,
>>   * and call the driver's reset() and start() routines.
>>   */
>> -int usb_add_hcd(struct usb_hcd *hcd,
>> -unsigned int irqnum, unsigned long irqflags)
>> +static int usb_otg_add_hcd(struct usb_hcd *hcd,
>> +   unsigned int irqnum, unsigned long irqflags)
> 
> You may change the kernel doc to this name too.

Yes.

> 
>>  {
>>  int retval;
>>  struct usb_device *rhdev;
>> @@ -2839,17 +2840,16 @@ err_phy:
>>  }
>>  return retval;
>>  }
>> -EXPORT_SYMBOL_GPL(usb_add_hcd);
>>  
>>  /**
>> - * usb_remove_hcd - shutdown processing for generic HCDs
>> + * usb_otg_remove_hcd - shutdown processing for generic HCDs
>>   * @hcd: the usb_hcd structure to remove
>>   * Context: !in_interrupt()
>>   *
>>   * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>>   * invoking the HCD's stop() method.
>>   */
>> -void usb_remove_hcd(struct usb_hcd *hcd)
>> +static void usb_otg_remove_hcd(struct usb_hcd *hcd)
>>  {
>>  struct usb_device *rhdev = hcd->self.root_hub;
>>  
>> @@ -2923,6 +2923,51 @@ void usb_remove_hcd(struct usb_hcd *hcd)
>>  
>>  usb_put_invalidate_rhdev(hcd);
>>  }
>> +
>> +static struct otg_hcd_ops otg_hcd_intf = {
>> +.add = usb_otg_add_hcd,
>> +.remove = usb_otg_remove_hcd,
>> +};
>> +
>> +/**
>> + * usb_add_hcd - finish generic HCD structure initialization and register
>> + * @hcd: the usb_hcd structure to initialize
>> + * @irqnum: Interrupt line to allocate
>> + * @irqflags: Interrupt type flags
>> + *
>> + * Finish the remaining parts of generic HCD initialization: allocate the
>> + * buffers of consistent memory, register the bus, request the IRQ line,
>> + * and call the driver's reset() and start() routines.
>> + * If it is an OTG device then it only registers the HCD with OTG core.
>> + *
>> + */
>> +int usb_add_hcd(struct usb_hcd *hcd,
>> +unsigned int irqnum, unsigned long irqflags)
>> +{
>> +/* If OTG device, OTG core takes care of adding HCD */
>> +if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
>> +return usb_otg_add_hcd(hcd, irqnum, irqflags);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_add_hcd);
>> +
>> +/**
>> + * usb_remove_hcd - shutdown processing for generic HCDs
>> + * @hcd: the usb_hcd structure to remove
>> + * Context: !in_interrupt()
>> + *
>> + * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>> + * invoking the HCD's stop() method.
>> + * If it is an OTG device then it unregisters the HCD from OTG core
>> + * as well.
>> + */
>> +void usb_remove_hcd(struct usb_hcd *hcd)
>> +{
>> +/* If OTG device, OTG core takes care of stopping HCD */
>> +if (usb_otg_unregister_hcd(hcd))
>> +usb_otg_remove_hcd(hcd);
>> +}
>>  EXPORT_SYMBOL_GPL(usb_remove_hcd);
>>  
>>  void
>> -- 
>> 2.1.4
>>
> 
--
cheers,
-roger
--
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 07/13] usb: otg: add OTG core

2015-09-09 Thread Alan Stern 
On Wed, 9 Sep 2015, Roger Quadros wrote:

> (adding back folks in cc)
> 
> On 08/09/15 20:35, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Roger Quadros wrote:
> > 
>  What if there is another architecture like so?
> 
>  C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
>  We need a more flexible mechanism to link the gadget and
>  host device to the otg core for non DT case.
> 
>  How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
>  e.g.
>  int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
>  If otg is NULL it will try DT otg-controller property or parent to
>  get the otg controller.
> >>>
> >>> This seems a lot like something Peter and I discussed recently.  See
> >>>
> >>>   http://marc.info/?l=linux-usb=143977568021328=2
> >>>
> >>> and the following messages in that thread.
> >>>
> >>
> >> If I understood right, your proposal was to add a usb_pointers data
> >> struct to the device's drvdata?
> > 
> > Right.
> > 
> >> This is fine only if the otg/gadget/host share the same device.
> >> It does not solve the problem where each have different platform devices.
> > 
> > Why not?  Each of the platform devices can store a pointer to the same 
> > usb_pointers structure.  Wouldn't that be suitable?
> > 
> 
> I didn't understand how all of them get the reference to the
> same usb_pointer structure (or contents) when their respective platform 
> devices
> get created so that they can store it in their respective drvdata.
> 
> Worst case, the 3 devices could be totally independent of each other without a
> common parent, and get registered at different times.
> 
> The common resource here is the physical USB port for which the 3 drivers
> otg/host/gadget are being registered.
> There should be a mechanism for each device to tell that it is part of
> this particular USB port. (or usb_pointers struct)

True, it's not clear how to set up the common relationship among the 
three drivers.  But there must be some way to do it if they all are 
talking to the same port or PHY.

The details are an issue for the platform-specific code to handle.  
I'm not sure what would be involved; maybe you can invent something.

Alan Stern

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

Re: [GIT PULL] omap fixes for v4.3 merge window

2015-09-09 Thread Kevin Hilman 
Tony Lindgren  writes:

> The following changes since commit 2faf962d90ca4c5ee7ba026b7351b1f74500bcdf:
>
>   Merge tag 'armsoc-defconfig' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2015-09-01 
> 13:17:43 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v4.3/fixes-merge-window
>
> for you to fetch changes up to 21b430d23d233c67e6589ea5054d18392e15a28e:
>
>   ARM: omap2plus_defconfig: Enable MUSB DMA support (2015-09-01 13:59:25 
> -0700)
>
> 
> Few omap bug fixes that have come up recently:
>
> - Fix deferred probe with omap_device idling unused devices
>
> - Fix booting if no timer parent can be set
>
> - Fix always true warning for vc register check
>
> And also two minor changes not strictly fixes:
>
> - Add SoC detection for dra752
>
> - Enable omap related MUSB DMA engines as we can now
>   build them all in finally
>
> 

Queuing this into fixes branch for v4.3-rc2.

Thanks,

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

Re: [RESEND PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-09 Thread Kevin Hilman 
Kishon Vijay Abraham I  writes:

> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
> OMAP5 and DRA7 SoCs. Enable it here.
>
> Signed-off-by: Kishon Vijay Abraham I 

Thanks, added to our next/late branch.

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

Contact Us For Unsecured Guaranteed Loans Today!!!?

2015-09-09 Thread Guaranteed 
Do you need a genuine Loan to settle your bills and start up a good
business? Kindly contact us now with your details to get a good
Loan at a low rate of 3% per Annu, Quick send your details via:
guarloa...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] thermal: ti-soc: Kconfig fix to avoid menu showing wrongly

2015-09-09 Thread Eduardo Valentin 
Move the dependencies to menu, so we avoid showing it wrongly.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/Kconfig| 1 +
 drivers/thermal/ti-soc-thermal/Kconfig | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)
---

This depends on the compile test series.

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a752bef..c5eb142 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -341,6 +341,7 @@ config ACPI_THERMAL_REL
depends on ACPI
 
 menu "Texas Instruments thermal drivers"
+depends on ARCH_HAS_BANDGAP || COMPILE_TEST
 source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
b/drivers/thermal/ti-soc-thermal/Kconfig
index 7a24018..cb6686f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -1,7 +1,5 @@
 config TI_SOC_THERMAL
tristate "Texas Instruments SoCs temperature sensor driver"
-   depends on THERMAL
-   depends on ARCH_HAS_BANDGAP || COMPILE_TEST
help
  If you say yes here you get support for the Texas Instruments
  OMAP4460+ on die bandgap temperature sensor support. The register
-- 
2.5.0

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

[PATCHv3 1/1] ti-soc-thermal: implement omap3 support

2015-09-09 Thread Eduardo Valentin 
From: Pavel Machek 

This adds support for OMAP3 chips to ti-soc-thermal. As requested by
TI people, it is marked unreliable and warning is printed.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Pavel Machek 
Signed-off-by: Eduardo Valentin 
---
 .../devicetree/bindings/thermal/ti_soc_thermal.txt |   7 ++
 drivers/thermal/ti-soc-thermal/Kconfig |  15 +++
 drivers/thermal/ti-soc-thermal/Makefile|   1 +
 .../thermal/ti-soc-thermal/omap3-thermal-data.c| 103 +
 drivers/thermal/ti-soc-thermal/ti-bandgap.c|  10 ++
 drivers/thermal/ti-soc-thermal/ti-bandgap.h|   9 ++
 6 files changed, 145 insertions(+)
 create mode 100644 drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
---

Just not leave Pavels work behind, I took his patch and amended a couple
of things:
(1) added the omap3 DT example
(2) improved the dev_warn message
(3) improved the code documentation

diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt 
b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
index 0c9222d..d9a1b54 100644
--- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
@@ -10,6 +10,7 @@ to the silicon temperature.
 
 Required properties:
 - compatible : Should be:
+  - "ti,omap34xx-bandgap" : for OMAP34xx bandgap
   - "ti,omap4430-bandgap" : for OMAP4430 bandgap
   - "ti,omap4460-bandgap" : for OMAP4460 bandgap
   - "ti,omap4470-bandgap" : for OMAP4470 bandgap
@@ -25,6 +26,12 @@ to each bandgap version, because the mapping may change from
 soc to soc, apart of depending on available features.
 
 Example:
+OMAP34xx:
+bandgap {
+   reg = <0x48002524 0x4>;
+   compatible = "ti,omap34xx-bandgap";
+};
+
 OMAP4430:
 bandgap {
reg = <0x4a002260 0x4 0x4a00232C 0x4>;
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
b/drivers/thermal/ti-soc-thermal/Kconfig
index cb6686f..ea8283f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -19,6 +19,21 @@ config TI_THERMAL
  This includes trip points definitions, extrapolation rules and
  CPU cooling device bindings.
 
+config OMAP3_THERMAL
+   bool "Texas Instruments OMAP3 thermal support"
+   depends on TI_SOC_THERMAL
+   depends on ARCH_OMAP3 || COMPILE_TEST
+   help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP3 SoC family. The current chips supported are:
+  - OMAP3430
+
+ OMAP3 chips normally don't need thermal management, and sensors in
+ this generation are not accurate, nor they are very close to
+ the important hotspots.
+
+ Say 'N' here.
+
 config OMAP4_THERMAL
bool "Texas Instruments OMAP4 thermal support"
depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile 
b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..0f89bdf 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal.o
 ti-soc-thermal-y   := ti-bandgap.o
 ti-soc-thermal-$(CONFIG_TI_THERMAL)+= ti-thermal-common.o
 ti-soc-thermal-$(CONFIG_DRA752_THERMAL)+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL) += omap3-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal-data.o
 ti-soc-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c 
b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 000..8470225
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,103 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Note
+ * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
+ * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used"
+ *
+ * Also TI says:
+ * Just be careful when you try to make thermal policy like decisions
+ * based on this sensor. Placement of the sensor w.r.t the actual logic
+ * generating heat has to be a factor as well. If you are just looking
+ * for an approximation temperature (thermometerish kind), you

[PATCH 17/17] thermal: ti-soc: allow compile test

2015-09-09 Thread Eduardo Valentin 
Adding COMPILE_TEST flag to ti-soc driver to facilitate
maintenance.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/ti-soc-thermal/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..7a24018 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -1,7 +1,7 @@
 config TI_SOC_THERMAL
tristate "Texas Instruments SoCs temperature sensor driver"
depends on THERMAL
-   depends on ARCH_HAS_BANDGAP
+   depends on ARCH_HAS_BANDGAP || COMPILE_TEST
help
  If you say yes here you get support for the Texas Instruments
  OMAP4460+ on die bandgap temperature sensor support. The register
@@ -24,7 +24,7 @@ config TI_THERMAL
 config OMAP4_THERMAL
bool "Texas Instruments OMAP4 thermal support"
depends on TI_SOC_THERMAL
-   depends on ARCH_OMAP4
+   depends on ARCH_OMAP4 || COMPILE_TEST
help
  If you say yes here you get thermal support for the Texas Instruments
  OMAP4 SoC family. The current chip supported are:
@@ -38,7 +38,7 @@ config OMAP4_THERMAL
 config OMAP5_THERMAL
bool "Texas Instruments OMAP5 thermal support"
depends on TI_SOC_THERMAL
-   depends on SOC_OMAP5
+   depends on SOC_OMAP5 || COMPILE_TEST
help
  If you say yes here you get thermal support for the Texas Instruments
  OMAP5 SoC family. The current chip supported are:
@@ -50,7 +50,7 @@ config OMAP5_THERMAL
 config DRA752_THERMAL
bool "Texas Instruments DRA752 thermal support"
depends on TI_SOC_THERMAL
-   depends on SOC_DRA7XX
+   depends on SOC_DRA7XX || COMPILE_TEST
help
  If you say yes here you get thermal support for the Texas Instruments
  DRA752 SoC family. The current chip supported are:
-- 
2.5.0

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

[PATCH RFC 3/5] ASoC: davinci-mcasp: Add set_tdm_slots() support

2015-09-09 Thread Jyri Sarha 
Implements set_tdm_slot() callback for mcasp. Channel constraints are
updated according to the configured tdm mask and slots each time
set_tdm_slot() is called. The special case when slot width is set to
zero is allowed and it means that slot width is the same as the sample
width.

Signed-off-by: Jyri Sarha 
---
 sound/soc/davinci/davinci-mcasp.c | 255 ++
 1 file changed, 174 insertions(+), 81 deletions(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index bbd1987..de1e3a8 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -80,6 +80,8 @@ struct davinci_mcasp {
 
/* McASP specific data */
int tdm_slots;
+   u32 tdm_mask[2];
+   int slot_width;
u8  op_mode;
u8  num_serializer;
u8  *serial_dir;
@@ -601,6 +603,84 @@ static int davinci_mcasp_set_sysclk(struct snd_soc_dai 
*dai, int clk_id,
return 0;
 }
 
+/* All serializers must have equal number of channels */
+static int davinci_mcasp_ch_constraint(struct davinci_mcasp *mcasp, int stream,
+  int serializers)
+{
+   struct snd_pcm_hw_constraint_list *cl = >chconstr[stream];
+   unsigned int *list = (unsigned int *) cl->list;
+   int slots = mcasp->tdm_slots;
+   int i, count = 0;
+
+   if (mcasp->tdm_mask[stream])
+   slots = hweight32(mcasp->tdm_mask[stream]);
+
+   for (i = 2; i <= slots; i++)
+   list[count++] = i;
+
+   for (i = 2; i <= serializers; i++)
+   list[count++] = i*slots;
+
+   cl->count = count;
+
+   return 0;
+}
+
+static int davinci_mcasp_set_ch_constraints(struct davinci_mcasp *mcasp)
+{
+   int rx_serializers = 0, tx_serializers = 0, ret, i;
+
+   for (i = 0; i < mcasp->num_serializer; i++)
+   if (mcasp->serial_dir[i] == TX_MODE)
+   tx_serializers++;
+   else if (mcasp->serial_dir[i] == RX_MODE)
+   rx_serializers++;
+
+   ret = davinci_mcasp_ch_constraint(mcasp, SNDRV_PCM_STREAM_PLAYBACK,
+ tx_serializers);
+   if (ret)
+   return ret;
+
+   ret = davinci_mcasp_ch_constraint(mcasp, SNDRV_PCM_STREAM_CAPTURE,
+ rx_serializers);
+
+   return ret;
+}
+
+
+static int davinci_mcasp_set_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask,
+ unsigned int rx_mask,
+ int slots, int slot_width)
+{
+   struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
+
+   dev_dbg(mcasp->dev,
+"%s() tx_mask 0x%08x rx_mask 0x%08x slots %d width %d\n",
+__func__, tx_mask, rx_mask, slots, slot_width);
+
+   if (tx_mask >= (1<= (1<dev,
+   "Bad tdm mask tx: 0x%08x rx: 0x%08x slots %d\n",
+   tx_mask, rx_mask, slots);
+   return -EINVAL;
+   }
+
+   if (slot_width &&
+   (slot_width < 8 || slot_width > 32 || slot_width % 4 != 0)) {
+   dev_err(mcasp->dev, "%s: Unsupported slot_width %d\n",
+   __func__, slot_width);
+   return -EINVAL;
+   }
+
+   mcasp->tdm_slots = slots;
+   mcasp->tdm_mask[SNDRV_PCM_STREAM_PLAYBACK] = rx_mask;
+   mcasp->tdm_mask[SNDRV_PCM_STREAM_CAPTURE] = tx_mask;
+   mcasp->slot_width = slot_width;
+
+   return davinci_mcasp_set_ch_constraints(mcasp);
+}
+
 static int davinci_config_channel_size(struct davinci_mcasp *mcasp,
   int word_length)
 {
@@ -637,6 +717,9 @@ static int davinci_config_channel_size(struct davinci_mcasp 
*mcasp,
 */
rx_rotate = (slot_length - word_length) / 4;
word_length = slot_length;
+   } else if (mcasp->slot_width) {
+   rx_rotate = (mcasp->slot_width - word_length) / 4;
+   word_length = mcasp->slot_width;
}
 
/* mapping of the XSSZ bit-field as described in the datasheet */
@@ -782,33 +865,50 @@ static int mcasp_i2s_hw_param(struct davinci_mcasp 
*mcasp, int stream,
 
/*
 * If more than one serializer is needed, then use them with
-* their specified tdm_slots count. Otherwise, one serializer
-* can cope with the transaction using as many slots as channels
-* in the stream, requires channels symmetry
+* all the specified tdm_slots. Otherwise, one serializer can
+* cope with the transaction using just as many slots as there
+* are channels in the stream.
 */
-   active_serializers = (channels + total_slots - 1) / total_slots;
-   if (active_serializers == 1)
-

[PATCH RFC 2/5] ASoC: simple-card: Add tdm slot mask support to simple-card

2015-09-09 Thread Jyri Sarha 
Adds DT binding for explicitly choosing a tdm mask for DAI and uses it
in simple-card. The API for snd_soc_of_parse_tdm_slot() has also been
changed.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/sound/tdm-slot.txt | 11 +-
 include/sound/simple_card.h|  2 ++
 include/sound/soc.h|  2 ++
 sound/soc/generic/simple-card.c|  8 +--
 sound/soc/soc-core.c   | 25 ++
 5 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt 
b/Documentation/devicetree/bindings/sound/tdm-slot.txt
index 6a2c842..34cf70e 100644
--- a/Documentation/devicetree/bindings/sound/tdm-slot.txt
+++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt
@@ -4,11 +4,15 @@ This specifies audio DAI's TDM slot.
 
 TDM slot properties:
 dai-tdm-slot-num : Number of slots in use.
-dai-tdm-slot-width :  Width in bits for each slot.
+dai-tdm-slot-width : Width in bits for each slot.
+dai-tdm-slot-tx-mask : Transmit direction slot mask, optional
+dai-tdm-slot-rx-mask : Receive direction slot mask, optional
 
 For instance:
dai-tdm-slot-num = <2>;
dai-tdm-slot-width = <8>;
+   dai-tdm-slot-tx-mask = <0 1>;
+   dai-tdm-slot-rx-mask = <1 0>;
 
 And for each spcified driver, there could be one .of_xlate_tdm_slot_mask()
 to specify a explicit mapping of the channels and the slots. If it's absent
@@ -18,3 +22,8 @@ tx and rx masks.
 For snd_soc_of_xlate_tdm_slot_mask(), the tx and rx masks will use a 1 bit
 for an active slot as default, and the default active bits are at the LSB of
 the masks.
+
+The explicit masks are given as array of integers, where the first
+number presents bit-0 (LSB), second presents bit-1, etc. Any non zero
+number is considered 1 and 0 is 0. snd_soc_of_xlate_tdm_slot_mask()
+does not do anything, if either mask is set non zero value.
diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index b9b4f28..0399352 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -19,6 +19,8 @@ struct asoc_simple_dai {
unsigned int sysclk;
int slots;
int slot_width;
+   unsigned int tx_slot_mask;
+   unsigned int rx_slot_mask;
struct clk *clk;
 };
 
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 4cef20e..ca009bf 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1598,6 +1598,8 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
 int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
  const char *propname);
 int snd_soc_of_parse_tdm_slot(struct device_node *np,
+ unsigned int *tx_mask,
+ unsigned int *rx_mask,
  unsigned int *slots,
  unsigned int *slot_width);
 void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 3ff76d4..54c3320 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -151,7 +151,9 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
}
 
if (set->slots) {
-   ret = snd_soc_dai_set_tdm_slot(dai, 0, 0,
+   ret = snd_soc_dai_set_tdm_slot(dai,
+  set->tx_slot_mask,
+  set->rx_slot_mask,
set->slots,
set->slot_width);
if (ret && ret != -ENOTSUPP) {
@@ -243,7 +245,9 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return ret;
 
/* Parse TDM slot */
-   ret = snd_soc_of_parse_tdm_slot(np, >slots, >slot_width);
+   ret = snd_soc_of_parse_tdm_slot(np, >tx_slot_mask,
+   >rx_slot_mask,
+   >slots, >slot_width);
if (ret)
return ret;
 
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index c81aec9..1929f0e 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3289,13 +3289,38 @@ int snd_soc_of_parse_audio_simple_widgets(struct 
snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_simple_widgets);
 
+static int snd_soc_of_get_slot_mask(struct device_node *np,
+   const char *prop_name,
+   unsigned int *mask)
+{
+   u32 val;
+   const u32 *of_slot_mask = of_get_property(np, prop_name, );
+   int i;
+
+   if (!of_slot_mask)
+   return 0;
+   val /= sizeof(u32);
+   for (i = 0; i < val; i++)
+   if (be32_to_cpup(_slot_mask[i]))
+   *mask |= (1 << i);
+
+

[PATCH RFC 1/5] ASoC: davinci-mcasp: Set .symmetric_rates = 1 in snd_soc_dai_driver

2015-09-09 Thread Jyri Sarha 
The TX and RX direction share the same bit clock and frame sync, so
the samplerate must be the same to both directions.

Signed-off-by: Jyri Sarha 
---
 sound/soc/davinci/davinci-mcasp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index fa0511b..bbd1987 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1304,6 +1304,7 @@ static struct snd_soc_dai_driver davinci_mcasp_dai[] = {
.ops= _mcasp_dai_ops,
 
.symmetric_samplebits   = 1,
+   .symmetric_rates= 1,
},
{
.name   = "davinci-mcasp.1",
-- 
1.9.1

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

[PATCH RFC 4/5] ASoC: davinci-mcasp: Get rid of bclk_lrclk_ratio in private data

2015-09-09 Thread Jyri Sarha 
The slot_width is for essentially same thing. Instead of storing
bclk_lrclk_ratio, just store the slot_width. Comments has been updated
accordingly and some variable names changed to more descriptive.

Signed-off-by: Jyri Sarha 
---
 sound/soc/davinci/davinci-mcasp.c | 56 ++-
 1 file changed, 31 insertions(+), 25 deletions(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index de1e3a8..25ff1fc 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -87,7 +87,6 @@ struct davinci_mcasp {
u8  *serial_dir;
u8  version;
u8  bclk_div;
-   u16 bclk_lrclk_ratio;
int streams;
u32 irq_request[2];
int dma_request[2];
@@ -558,8 +557,21 @@ static int __davinci_mcasp_set_clkdiv(struct snd_soc_dai 
*dai, int div_id,
mcasp->bclk_div = div;
break;
 
-   case 2: /* BCLK/LRCLK ratio */
-   mcasp->bclk_lrclk_ratio = div;
+   case 2: /*
+* BCLK/LRCLK ratio descries how many bit-clock cycles
+* fit into one frame. The clock ratio is given for a
+* full period of data (for I2S format both left and
+* right channels), so it has to be divided by number
+* of tdm-slots (for I2S - divided by 2).
+* Instead of storing this ratio, we calculate a new
+* tdm_slot width by dividing the the ratio by the
+* number of configured tdm slots.
+*/
+   mcasp->slot_width = div / mcasp->tdm_slots;
+   if (div % mcasp->tdm_slots)
+   dev_warn(mcasp->dev,
+"%s(): BCLK/LRCLK %d is not divisible by %d 
tdm slots",
+div, mcasp->tdm_slots);
break;
 
default:
@@ -682,11 +694,13 @@ static int davinci_mcasp_set_tdm_slot(struct snd_soc_dai 
*dai,
 }
 
 static int davinci_config_channel_size(struct davinci_mcasp *mcasp,
-  int word_length)
+  int sample_width)
 {
u32 fmt;
-   u32 tx_rotate = (word_length / 4) & 0x7;
-   u32 mask = (1ULL << word_length) - 1;
+   u32 tx_rotate = (sample_width / 4) & 0x7;
+   u32 mask = (1ULL << sample_width) - 1;
+   u32 slot_width = sample_width;
+
/*
 * For captured data we should not rotate, inversion and masking is
 * enoguh to get the data to the right position:
@@ -699,31 +713,23 @@ static int davinci_config_channel_size(struct 
davinci_mcasp *mcasp,
u32 rx_rotate = 0;
 
/*
-* if s BCLK-to-LRCLK ratio has been configured via the set_clkdiv()
-* callback, take it into account here. That allows us to for example
-* send 32 bits per channel to the codec, while only 16 of them carry
-* audio payload.
-* The clock ratio is given for a full period of data (for I2S format
-* both left and right channels), so it has to be divided by number of
-* tdm-slots (for I2S - divided by 2).
+* Setting the tdm slot width either with set_clkdiv() or
+* set_tdm_slot() allows us to for example send 32 bits per
+* channel to the codec, while only 16 of them carry audio
+* payload.
 */
-   if (mcasp->bclk_lrclk_ratio) {
-   u32 slot_length = mcasp->bclk_lrclk_ratio / mcasp->tdm_slots;
-
+   if (mcasp->slot_width) {
/*
-* When we have more bclk then it is needed for the data, we
-* need to use the rotation to move the received samples to have
-* correct alignment.
+* When we have more bclk then it is needed for the
+* data, we need to use the rotation to move the
+* received samples to have correct alignment.
 */
-   rx_rotate = (slot_length - word_length) / 4;
-   word_length = slot_length;
-   } else if (mcasp->slot_width) {
-   rx_rotate = (mcasp->slot_width - word_length) / 4;
-   word_length = mcasp->slot_width;
+   slot_width = mcasp->slot_width;
+   rx_rotate = (slot_width - sample_width) / 4;
}
 
/* mapping of the XSSZ bit-field as described in the datasheet */
-   fmt = (word_length >> 1) - 1;
+   fmt = (slot_width >> 1) - 1;
 
if (mcasp->op_mode != DAVINCI_MCASP_DIT_MODE) {
mcasp_mod_bits(mcasp, DAVINCI_MCASP_RXFMT_REG, RXSSZ(fmt),
-- 
1.9.1

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

[PATCH RFC 5/5] ASoC: tlv320aic3x: Improve tdm support

2015-09-09 Thread Jyri Sarha 
Before this patch the set_tdm_slots() callback did not store the value
of slot width anywhere. The tdm support only worked if selected slot
width was equal to the sample width. With this patch all sample widths
that fit into the slot width are supported. There unused bits are
filled unnecessarily in the capture direction, but the other end of
the i2s bus should be able to ignore them.

Signed-off-by: Jyri Sarha 
---
 sound/soc/codecs/tlv320aic3x.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 1a82b19..f1c9fff 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -80,6 +80,7 @@ struct aic3x_priv {
unsigned int sysclk;
unsigned int dai_fmt;
unsigned int tdm_delay;
+   unsigned int slot_width;
struct list_head list;
int master;
int gpio_reset;
@@ -1025,10 +1026,14 @@ static int aic3x_hw_params(struct snd_pcm_substream 
*substream,
u8 data, j, r, p, pll_q, pll_p = 1, pll_r = 1, pll_j = 1;
u16 d, pll_d = 1;
int clk;
+   int width = aic3x->slot_width;
+
+   if (!width)
+   width = params_width(params);
 
/* select data word length */
data = snd_soc_read(codec, AIC3X_ASD_INTF_CTRLB) & (~(0x3 << 4));
-   switch (params_width(params)) {
+   switch (width) {
case 16:
break;
case 20:
@@ -1170,12 +1175,16 @@ static int aic3x_prepare(struct snd_pcm_substream 
*substream,
struct snd_soc_codec *codec = dai->codec;
struct aic3x_priv *aic3x = snd_soc_codec_get_drvdata(codec);
int delay = 0;
+   int width = aic3x->slot_width;
+
+   if (!width)
+   width = substream->runtime->sample_bits;
 
/* TDM slot selection only valid in DSP_A/_B mode */
if (aic3x->dai_fmt == SND_SOC_DAIFMT_DSP_A)
-   delay += (aic3x->tdm_delay + 1);
+   delay += (aic3x->tdm_delay*width + 1);
else if (aic3x->dai_fmt == SND_SOC_DAIFMT_DSP_B)
-   delay += aic3x->tdm_delay;
+   delay += aic3x->tdm_delay*width;
 
/* Configure data delay */
snd_soc_write(codec, AIC3X_ASD_INTF_CTRLC, delay);
@@ -1296,7 +1305,20 @@ static int aic3x_set_dai_tdm_slot(struct snd_soc_dai 
*codec_dai,
return -EINVAL;
}
 
-   aic3x->tdm_delay = lsb * slot_width;
+   switch (slot_width) {
+   case 16:
+   case 20:
+   case 24:
+   case 32:
+   break;
+   default:
+   dev_err(codec->dev, "Unsupported slot width %d\n", slot_width);
+   return -EINVAL;
+   }
+
+
+   aic3x->tdm_delay = lsb;
+   aic3x->slot_width = slot_width;
 
/* DOUT in high-impedance on inactive bit clocks */
snd_soc_update_bits(codec, AIC3X_ASD_INTF_CTRLA,
-- 
1.9.1

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

[PATCH RFC 0/5] ASoC: TDM stuff for simple-card, mcasp, and tlv320aic3x

2015-09-09 Thread Jyri Sarha 
The first patch is an independent fix.

The symmetric_samplebits constraint could probably be removed too
(with some changes to mcasp code too), but as tlv320aic3x family
codecs won't support it, I could not test it.

Jyri Sarha (5):
  ASoC: davinci-mcasp: Set .symmetric_rates = 1 in snd_soc_dai_driver
  ASoC: simple-card: Add tdm slot mask support to simple-card
  ASoC: davinci-mcasp: Add set_tdm_slots() support
  ASoC: davinci-mcasp: Get rid of bclk_lrclk_ratio in private data
  ASoC: tlv320aic3x: Improve tdm support

 .../devicetree/bindings/sound/tdm-slot.txt |  11 +-
 include/sound/simple_card.h|   2 +
 include/sound/soc.h|   2 +
 sound/soc/codecs/tlv320aic3x.c |  30 +-
 sound/soc/davinci/davinci-mcasp.c  | 306 ++---
 sound/soc/generic/simple-card.c|   8 +-
 sound/soc/soc-core.c   |  25 ++
 7 files changed, 274 insertions(+), 110 deletions(-)

-- 
1.9.1

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

[PATCH 2/4] ARM: omap2+: board-generic: Remove stale of_irq macros

2015-09-09 Thread Nishanth Menon 
When commit c4082d499fa2 ("ARM: omap2+: board-generic: clean up the
irq data from board file") cleaned up the direct usage of gic_of_init
and omap_intc_of_init, it failed to clean up the macros properly.

Since these macros are no longer used, lets just remove them.

Fixes: c4082d499fa2 ("ARM: omap2+: board-generic: clean up the irq data from 
board file")
Reported-by: Carlos Hernandez 
Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-omap2/board-generic.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 24c9afc9e8a7..6133eaac685d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -20,13 +20,6 @@
 
 #include "common.h"
 
-#if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
-#define intc_of_init   NULL
-#endif
-#ifndef CONFIG_ARCH_OMAP4
-#define gic_of_initNULL
-#endif
-
 static const struct of_device_id omap_dt_match_table[] __initconst = {
{ .compatible = "simple-bus", },
{ .compatible = "ti,omap-infra", },
-- 
1.7.9.5

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

[PATCH 4/4] ARM: OMAP5: Cleanup options for SoC only build

2015-09-09 Thread Nishanth Menon 
OMAP5 SoC has Cortex-A15 which does not use TWD timer. It uses
ARCH_TIMER instead, clean up unwanted configuration and enable
OMAP_INTERCONNECT and OPP which is necessary for expected functionality
on the SoC.

Reported-by: Carlos Hernandez 
Reported-by: Felipe Balbi 
Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-omap2/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 403022a38607..b3a0dff67e3f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -44,10 +44,11 @@ config SOC_OMAP5
select ARM_CPU_SUSPEND if PM
select ARM_GIC
select HAVE_ARM_SCU if SMP
-   select HAVE_ARM_TWD if SMP
select HAVE_ARM_ARCH_TIMER
select ARM_ERRATA_798181 if SMP
+   select OMAP_INTERCONNECT
select OMAP_INTERCONNECT_BARRIER
+   select PM_OPP if PM
 
 config SOC_AM33XX
bool "TI AM33XX"
-- 
1.7.9.5

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

[PATCH 0/4] ARM: OMAP5/DRA7: minor fixes

2015-09-09 Thread Nishanth Menon 
Hi,

While doing a SoC only build for DRA7, a few bugs did pop up. The
following series provides necessary fixups for the same.

Nishanth Menon (4):
  ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well
  ARM: omap2+: board-generic: Remove stale of_irq macros
  ARM: DRA7: Select missing options for SoC only build
  ARM: OMAP5: Cleanup options for SoC only build

 arch/arm/mach-omap2/Kconfig |6 +-
 arch/arm/mach-omap2/board-generic.c |7 ---
 arch/arm/mach-omap2/pm.h|3 ++-
 3 files changed, 7 insertions(+), 9 deletions(-)

-- 
1.7.9.5

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

[PATCH 3/4] ARM: DRA7: Select missing options for SoC only build

2015-09-09 Thread Nishanth Menon 
DRA7 does use OPP, uses OMAP interconnect and also does require SCU.
These are missing in the SoC only build of DRA7 breaking various PM
features in DRA7 only build.

Reported-by: Carlos Hernandez 
Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-omap2/Kconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 07d2e100caab..403022a38607 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -70,10 +70,13 @@ config SOC_DRA7XX
select ARCH_OMAP2PLUS
select ARM_CPU_SUSPEND if PM
select ARM_GIC
+   select HAVE_ARM_SCU if SMP
select HAVE_ARM_ARCH_TIMER
select IRQ_CROSSBAR
select ARM_ERRATA_798181 if SMP
+   select OMAP_INTERCONNECT
select OMAP_INTERCONNECT_BARRIER
+   select PM_OPP if PM
 
 config ARCH_OMAP2PLUS
bool
-- 
1.7.9.5

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

[PATCH 1/4] ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well

2015-09-09 Thread Nishanth Menon 
OMAP5 and DRA7 reuse the same pm44xx_erratum variable so, enable the
same, else PM features such as Suspend to ram is broken in a SoC only
build configuration.

Reported-by: Carlos Hernandez 
Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-omap2/pm.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 425bfcd67db6..f5bae699baac 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -103,7 +103,8 @@ static inline void 
enable_omap3630_toggle_l2_on_restore(void) { }
 #define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 << 0)
 #define PM_OMAP4_CPU_OSWR_DISABLE  (1 << 1)
 
-#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) ||\
+  defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX))
 extern u16 pm44xx_errata;
 #define IS_PM44XX_ERRATUM(id)  (pm44xx_errata & (id))
 #else
-- 
1.7.9.5

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