Re: Nokia N900: Proper C-states

[Daniel Lezcano]

On 01/02/2016 03:26 PM, Pali Rohár wrote:

Hello,

due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51
cpuidle parameters table)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc

we need patch cpuidle34xx.c code to fix commit for Nokia N900. See:

https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc

As Nokia N900 code is converting from legacy board code to DST, I would
like to know how to patch correctly omap3_idle_driver in DTS with
correct values measured for Nokia N900. Thanks!


Hi Pali,

the conversion to the DT based arm cpuidle driver could be a bit complex 
with one issue (index 0 != cpu_do_idle()) and one performance regression 
(cpu_pm_enter/exit will be called in retention mode, even if this is not 
needed).


It will result in a PM code only on one side and on the other side, the 
generic cpuidle-arm.c driver will be used instead with the DT 
definition. It is worth to the conversion because the result will be 
nice IMO.


Added Lorenzo who is initially author of the arm generic driver. We 
already discussed in the past about those two issues above and I think 
this is something we should improve.




--
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

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

Re: [PATCH v2 0/3] drivers: net: cpsw: Fix bugs in fixed-link PHY DT parsing

[Daniel Trautmann]

On Thu, Dec 17, 2015 at 03:45:08PM -0500, David Miller wrote:
> From: "David Rivshin (Allworx)" 
> Date: Wed, 16 Dec 2015 23:02:08 -0500
> 
> > I have tested on the following hardware configurations:
> >  - (EVMSK) dual emac with two real MDIO-connected phys using RGMII-TXID
> >  - single emac with fixed-link using RGMII
> > Testing of other CPSW emac configurations that folks may have would
> > be appreciated.
> 
> I'm going to wait until some others give some feedback and testing
> results on this one, thanks.

I can confirm that this patch is working on the following hardware setup:
 - single emac using MII connected with fixed-link to Micrel KSZ8895 Switch
--
To unsubscribe from this list: send the line "unsubscribe 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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Hi Tony and Rogers, thanks for the reply.

I found this:

(clock3xxx_data.c)
static struct clk usbhost_48m_fck = {
.name   = "usbhost_48m_fck",
.ops= _omap3430es2_dss_usbhost_wait,
.parent = _48m_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430ES2_USBHOST_MOD,
CM_FCLKEN),
.enable_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
.clkdm_name = "usbhost_clkdm",
.recalc = _recalc,
};


Where  _omap3430es2_dss_usbhost_wait is
(clock34xx.c)
const struct clkops clkops_omap3430es2_dss_usbhost_wait = {
.enable = omap2_dflt_clk_enable,
.disable= omap2_dflt_clk_disable,
.find_idlest= omap3430es2_clk_dss_usbhost_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};

I tried to use this instead of clkops_omap3430es2_dss_usbhost_wait,
but without success
const struct clkops clkops_omap2_dflt = {
.enable = omap2_dflt_clk_enable,
.disable= omap2_dflt_clk_disable,
};


The crash happens while trying to read UHH registers, at this line:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=drivers/usb/host/ehci-omap.c;h=07db0d80d8f6a4b186d3de6638cb3affc2c4812f;hb=HEAD#l583

The clock *seems* enabled, since is an internal clock I think I can't
use an oscilloscope to see it clocking, right?

BR,

- dhs

2015-11-26 7:22 GMT-02:00 Roger Quadros <rog...@ti.com>:
> Daniel,
>
> On 24/11/15 15:36, Daniel. wrote:
>> Hi Michael
>>
>> About this:
>> "Two bugs are fixed by this patch.  First, OMAP hardware only supports
>> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
>> should not wait for these clocks to enable.  So, split the appropriate
>> clocks into ES1 and ES2+ variants, so that kernels running on ES1
>> devices won't try to wait."
>>
>> My chip is ES1. I think that ES2+ code is running since I see these waits
>> ocurring on code... I'll take a better look in this, thanks again!
>
> Did you figure out if this clock is really present in the ES1 TRM?
> If it is not then why is the kernel trying to enable this clock?
>
> If it is present in the ES1 TRM then why is the kernel trying to wait
> for it to be enabled? AFAIK there is no need to wait for the clock to be
> enabled as there is no such status bit on ES1.
>
> cheers,
> -roger
>
>>
>> Does anyone know how to check if a clock is enabled?
>>
>> Regards,
>>
>> 2015-11-23 18:24 GMT-02:00 Daniel. <danielhi...@gmail.com>:
>>> I've already tried, it fails to apply. My tree is based on last commit from
>>> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
>>> that this is already applied (since come from the same tree).
>>>
>>> I will try to apply it by hand
>>> Thanks!
>>> Regards,
>>>
>>> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>>> Hi
>>>>
>>>> Can you check if you have this patch in?
>>>>
>>>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>>>> Author: Paul Walmsley <p...@pwsan.com>
>>>> Date:   Fri Jul 24 19:44:06 2009 -0600
>>>>
>>>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>>>>
>>>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
>>>> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
>>>> initiators and targets.  Without this patch, clk_enable()s on clocks 
>>>> for
>>>> these modules can be very high latency (potentially up to ~200
>>>> milliseconds) and message such as the following are generated:
>>>>
>>>> Clock usbhost_48m_fck didn't enable in 10 tries
>>>>
>>>> Two bugs are fixed by this patch.  First, OMAP hardware only supports
>>>> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
>>>> should not wait for these clocks to enable.  So, split the appropriate
>>>> clocks into ES1 and ES2+ variants, so that kernels running on ES1
>>>> devices won't try to wait.
>>>>
>>>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
>>>> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
>>>> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
>>>> implementing custom clkops .find_idlest function pointers for the
>>>> appropriate clocks that return the correct slave IDLEST 

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Hi Michael,

Thanks for the help,

The clock_summary is not there but I found these files:
$ pwd
/sys/kernel/debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/dpll4_ck/dpll4_m2_ck/dpll4_m2x2_ck/omap_96m_alwon_fck/cm_96m_fck/omap_48m_fck/usbhost_48m_fck
$ cat flags
0x
$ cat
flags rate  usecount
$ cat rate
4800
$ cat usecount
1
$


Regards,

- dhs

2015-11-24 17:32 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
> Hi
>
> Do you have /sys/kernel/debug/clk/clock_summary?
>
> Michael
>
> On Tue, Nov 24, 2015 at 7:50 PM, Daniel. <danielhi...@gmail.com> wrote:
>> Doing some printk mess I found that the usbhost_48m_fck is enabled. So
>> my problem should be another thing:
>>
>> clock.c:omap2_dflt_clk_enable@193: usbhost_48m_fck enable_reg value 0x01
>>
>> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>> Hi
>>>
>>> Can you check if you have this patch in?
>>>
>>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>>> Author: Paul Walmsley <p...@pwsan.com>
>>> Date:   Fri Jul 24 19:44:06 2009 -0600
>>>
>>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>>>
>>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
>>> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
>>> initiators and targets.  Without this patch, clk_enable()s on clocks for
>>> these modules can be very high latency (potentially up to ~200
>>> milliseconds) and message such as the following are generated:
>>>
>>> Clock usbhost_48m_fck didn't enable in 10 tries
>>>
>>> Two bugs are fixed by this patch.  First, OMAP hardware only supports
>>> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
>>> should not wait for these clocks to enable.  So, split the appropriate
>>> clocks into ES1 and ES2+ variants, so that kernels running on ES1
>>> devices won't try to wait.
>>>
>>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
>>> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
>>> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
>>> implementing custom clkops .find_idlest function pointers for the
>>> appropriate clocks that return the correct slave IDLEST bit shift.
>>>
>>> This was originally fixed in the linux-omap kernel during 2.6.29 in a
>>> slightly different manner[2][3].
>>>
>>>
>>> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Building as built-in doesn't solve my problem. The difference is that
>>>> when compiled as module the dump shows up when I load it, and when is
>>>> built-in the dump shows up at boot time. Also when built-in the
>>>> problem seems to ocurr when device is reseted (on ehci_omap_stop) and
>>>> the first stack dump is followed by much more other dumps. At the end
>>>> I can see something like: "Fixing recursive fault but reboot is
>>>> needed!"
>>>>
>>>>
>>>> Here is the module info:
>>>> root@csi:~# modinfo ehci-hcd
>>>> filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
>>>> author: Felipe Balbi <felipe.ba...@nokia.com>
>>>> author: Texas Instruments, Inc.
>>>> alias:  platform:omap-ehci
>>>> license:GPL
>>>> author: David Brownell
>>>> description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>>> srcversion: B282C11CACFB9E75921367C
>>>> depends:
>>>> vermagic:   2.6.37+ mod_unload modversions ARMv7
>>>> parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
>>>> parm:   park:park setting; 1-3 back-to-back async packets (uint)
>>>> parm:   ignore_oc:ignore bogus hardware overcurrent indications 
>>>> (bool)
>>>> parm:   hird:host initiated resume duration, +1 for each 75us
>>>>  (int)
>>>> root@csi:~#
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> 2015-11-23 17:55 GMT-02:00 Michael Trimarchi 
>>>> <mich...@amarulasolutions.com>:
>>>>> Hi
>>>>>
>>>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
&g

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Doing some printk mess I found that the usbhost_48m_fck is enabled. So
my problem should be another thing:

clock.c:omap2_dflt_clk_enable@193: usbhost_48m_fck enable_reg value 0x01

2015-11-23 18:10 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
> Hi
>
> Can you check if you have this patch in?
>
> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
> Author: Paul Walmsley <p...@pwsan.com>
> Date:   Fri Jul 24 19:44:06 2009 -0600
>
> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>
> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
> initiators and targets.  Without this patch, clk_enable()s on clocks for
> these modules can be very high latency (potentially up to ~200
> milliseconds) and message such as the following are generated:
>
> Clock usbhost_48m_fck didn't enable in 10 tries
>
> Two bugs are fixed by this patch.  First, OMAP hardware only supports
> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
> should not wait for these clocks to enable.  So, split the appropriate
> clocks into ES1 and ES2+ variants, so that kernels running on ES1
> devices won't try to wait.
>
> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
> implementing custom clkops .find_idlest function pointers for the
> appropriate clocks that return the correct slave IDLEST bit shift.
>
> This was originally fixed in the linux-omap kernel during 2.6.29 in a
> slightly different manner[2][3].
>
>
> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. <danielhi...@gmail.com> wrote:
>> Hi,
>>
>> Building as built-in doesn't solve my problem. The difference is that
>> when compiled as module the dump shows up when I load it, and when is
>> built-in the dump shows up at boot time. Also when built-in the
>> problem seems to ocurr when device is reseted (on ehci_omap_stop) and
>> the first stack dump is followed by much more other dumps. At the end
>> I can see something like: "Fixing recursive fault but reboot is
>> needed!"
>>
>>
>> Here is the module info:
>> root@csi:~# modinfo ehci-hcd
>> filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
>> author: Felipe Balbi <felipe.ba...@nokia.com>
>> author: Texas Instruments, Inc.
>> alias:  platform:omap-ehci
>> license:GPL
>> author: David Brownell
>> description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> srcversion: B282C11CACFB9E75921367C
>> depends:
>> vermagic:   2.6.37+ mod_unload modversions ARMv7
>> parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
>> parm:   park:park setting; 1-3 back-to-back async packets (uint)
>> parm:   ignore_oc:ignore bogus hardware overcurrent indications 
>> (bool)
>> parm:   hird:host initiated resume duration, +1 for each 75us
>>  (int)
>> root@csi:~#
>>
>>
>> Best regards,
>>
>> 2015-11-23 17:55 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>> Hi
>>>
>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>> Hi Michael,
>>>>
>>>> It's a plain linux. I'm considering upgrading kernel as last option.
>>>> Variscite doesn't
>>>> support another kernel for this SoM so this would be a really hard
>>>> work. I'm looking
>>>> for a solution on this kernel and mainly trying to understand why
>>>> usbhost_48m_fck
>>>> is not getting enabled. I'm contacting Variscite in parallel.
>>>>
>>>
>>> Can you point me to te module description? I think that the module
>>> is working if it's compiled in. Correct?
>>>
>>> Michael
>>>
>>>
>>>> Thanks for your reply, best regards!
>>>>
>>>> 2015-11-23 16:57 GMT-02:00 Michael Trimarchi 
>>>> <mich...@amarulasolutions.com>:
>>>>> Hi Daniel
>>>>>
>>>>>
>>>>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>>>> Hi every body!
>>>>>>
>>>>>> I'm running a (2.6.37) kernel based on linux-omap tree
>>>>>> (http://arago-project.org/git/projects/?

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Hi Michael

About this:
"Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait."

My chip is ES1. I think that ES2+ code is running since I see these waits
ocurring on code... I'll take a better look in this, thanks again!

Does anyone know how to check if a clock is enabled?

Regards,

2015-11-23 18:24 GMT-02:00 Daniel. <danielhi...@gmail.com>:
> I've already tried, it fails to apply. My tree is based on last commit from
> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
> that this is already applied (since come from the same tree).
>
> I will try to apply it by hand
> Thanks!
> Regards,
>
> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>> Hi
>>
>> Can you check if you have this patch in?
>>
>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>> Author: Paul Walmsley <p...@pwsan.com>
>> Date:   Fri Jul 24 19:44:06 2009 -0600
>>
>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>>
>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
>> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
>> initiators and targets.  Without this patch, clk_enable()s on clocks for
>> these modules can be very high latency (potentially up to ~200
>> milliseconds) and message such as the following are generated:
>>
>> Clock usbhost_48m_fck didn't enable in 10 tries
>>
>> Two bugs are fixed by this patch.  First, OMAP hardware only supports
>> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
>> should not wait for these clocks to enable.  So, split the appropriate
>> clocks into ES1 and ES2+ variants, so that kernels running on ES1
>> devices won't try to wait.
>>
>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
>> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
>> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
>> implementing custom clkops .find_idlest function pointers for the
>> appropriate clocks that return the correct slave IDLEST bit shift.
>>
>> This was originally fixed in the linux-omap kernel during 2.6.29 in a
>> slightly different manner[2][3].
>>
>>
>> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. <danielhi...@gmail.com> wrote:
>>> Hi,
>>>
>>> Building as built-in doesn't solve my problem. The difference is that
>>> when compiled as module the dump shows up when I load it, and when is
>>> built-in the dump shows up at boot time. Also when built-in the
>>> problem seems to ocurr when device is reseted (on ehci_omap_stop) and
>>> the first stack dump is followed by much more other dumps. At the end
>>> I can see something like: "Fixing recursive fault but reboot is
>>> needed!"
>>>
>>>
>>> Here is the module info:
>>> root@csi:~# modinfo ehci-hcd
>>> filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
>>> author: Felipe Balbi <felipe.ba...@nokia.com>
>>> author: Texas Instruments, Inc.
>>> alias:  platform:omap-ehci
>>> license:GPL
>>> author: David Brownell
>>> description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> srcversion: B282C11CACFB9E75921367C
>>> depends:
>>> vermagic:   2.6.37+ mod_unload modversions ARMv7
>>> parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
>>> parm:   park:park setting; 1-3 back-to-back async packets (uint)
>>> parm:   ignore_oc:ignore bogus hardware overcurrent indications 
>>> (bool)
>>> parm:   hird:host initiated resume duration, +1 for each 75us
>>>  (int)
>>> root@csi:~#
>>>
>>>
>>> Best regards,
>>>
>>> 2015-11-23 17:55 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>>> Hi
>>>>
>>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>>> Hi Michael,
>>>>>
>>>>> It's a plain linux. I'm considering upgrading kernel as last option.
>>>>> Variscite doesn't
>>>>> support another kernel for 

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Hi,

Building as built-in doesn't solve my problem. The difference is that
when compiled as module the dump shows up when I load it, and when is
built-in the dump shows up at boot time. Also when built-in the
problem seems to ocurr when device is reseted (on ehci_omap_stop) and
the first stack dump is followed by much more other dumps. At the end
I can see something like: "Fixing recursive fault but reboot is
needed!"


Here is the module info:
root@csi:~# modinfo ehci-hcd
filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
author: Felipe Balbi <felipe.ba...@nokia.com>
author: Texas Instruments, Inc.
alias:  platform:omap-ehci
license:GPL
author: David Brownell
description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
srcversion: B282C11CACFB9E75921367C
depends:
vermagic:   2.6.37+ mod_unload modversions ARMv7
parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
parm:   park:park setting; 1-3 back-to-back async packets (uint)
parm:   ignore_oc:ignore bogus hardware overcurrent indications (bool)
parm:   hird:host initiated resume duration, +1 for each 75us
 (int)
root@csi:~#


Best regards,

2015-11-23 17:55 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
> Hi
>
> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>> Hi Michael,
>>
>> It's a plain linux. I'm considering upgrading kernel as last option.
>> Variscite doesn't
>> support another kernel for this SoM so this would be a really hard
>> work. I'm looking
>> for a solution on this kernel and mainly trying to understand why
>> usbhost_48m_fck
>> is not getting enabled. I'm contacting Variscite in parallel.
>>
>
> Can you point me to te module description? I think that the module
> is working if it's compiled in. Correct?
>
> Michael
>
>
>> Thanks for your reply, best regards!
>>
>> 2015-11-23 16:57 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>> Hi Daniel
>>>
>>>
>>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>> Hi every body!
>>>>
>>>> I'm running a (2.6.37) kernel based on linux-omap tree
>>>> (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary).
>>>> The board is a SoM from Variscite (var-som-am3517).
>>>>
>>>> I've compiled the ehci-hcd as a module. When I enable it I got this dump:
>>>> http://pastebin.com/5idXXBBi
>>>>
>>>
>>> Do you have an android device? or it's just plain linux.
>>> For option 2 I suggest to move on newest kernel
>>>
>>> Michael
>>>
>>>> Googling arroud I found that this can be triggered while trying to
>>>> access uhh registers when usbhost_48m_fck is not enabled. This is what
>>>> I think is happening since the message
>>>> "Clock usbhost_48m_fck didn't enable in 10 tries" is aways present
>>>> before the crash, and since the crash happens at first read o uhh
>>>> registers. I just can't figure out why usbhost_48m_fck is not getting
>>>> enabled and how to check if is trully disabled.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks in advance!
>>>> Regards,
>>>>
>>>> --
>>>> "Do or do not. There is no try"
>>>>   Yoda Master
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majord...@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> | Michael Nazzareno Trimarchi Amarula Solutions BV |
>>> | COO  -  Founder  Cruquiuskade 47 |
>>> | +31(0)851119172 Amsterdam 1018 AM NL |
>>> |  [`as] http://www.amarulasolutions.com   |
>>
>>
>>
>> --
>> "Do or do not. There is no try"
>>   Yoda Master
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> |  [`as] http://www.amarulasolutions.com   |



-- 
"Do or do not. There is no try"
  Yoda Master
--
To unsubscribe from this list: send the line "unsubscribe 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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

I've already tried, it fails to apply. My tree is based on last commit from
TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
that this is already applied (since come from the same tree).

I will try to apply it by hand
Thanks!
Regards,

2015-11-23 18:10 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
> Hi
>
> Can you check if you have this patch in?
>
> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
> Author: Paul Walmsley <p...@pwsan.com>
> Date:   Fri Jul 24 19:44:06 2009 -0600
>
> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>
> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
> initiators and targets.  Without this patch, clk_enable()s on clocks for
> these modules can be very high latency (potentially up to ~200
> milliseconds) and message such as the following are generated:
>
> Clock usbhost_48m_fck didn't enable in 10 tries
>
> Two bugs are fixed by this patch.  First, OMAP hardware only supports
> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
> should not wait for these clocks to enable.  So, split the appropriate
> clocks into ES1 and ES2+ variants, so that kernels running on ES1
> devices won't try to wait.
>
> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
> implementing custom clkops .find_idlest function pointers for the
> appropriate clocks that return the correct slave IDLEST bit shift.
>
> This was originally fixed in the linux-omap kernel during 2.6.29 in a
> slightly different manner[2][3].
>
>
> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. <danielhi...@gmail.com> wrote:
>> Hi,
>>
>> Building as built-in doesn't solve my problem. The difference is that
>> when compiled as module the dump shows up when I load it, and when is
>> built-in the dump shows up at boot time. Also when built-in the
>> problem seems to ocurr when device is reseted (on ehci_omap_stop) and
>> the first stack dump is followed by much more other dumps. At the end
>> I can see something like: "Fixing recursive fault but reboot is
>> needed!"
>>
>>
>> Here is the module info:
>> root@csi:~# modinfo ehci-hcd
>> filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
>> author: Felipe Balbi <felipe.ba...@nokia.com>
>> author: Texas Instruments, Inc.
>> alias:  platform:omap-ehci
>> license:GPL
>> author: David Brownell
>> description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> srcversion: B282C11CACFB9E75921367C
>> depends:
>> vermagic:   2.6.37+ mod_unload modversions ARMv7
>> parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
>> parm:   park:park setting; 1-3 back-to-back async packets (uint)
>> parm:   ignore_oc:ignore bogus hardware overcurrent indications 
>> (bool)
>> parm:   hird:host initiated resume duration, +1 for each 75us
>>  (int)
>> root@csi:~#
>>
>>
>> Best regards,
>>
>> 2015-11-23 17:55 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>> Hi
>>>
>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>> Hi Michael,
>>>>
>>>> It's a plain linux. I'm considering upgrading kernel as last option.
>>>> Variscite doesn't
>>>> support another kernel for this SoM so this would be a really hard
>>>> work. I'm looking
>>>> for a solution on this kernel and mainly trying to understand why
>>>> usbhost_48m_fck
>>>> is not getting enabled. I'm contacting Variscite in parallel.
>>>>
>>>
>>> Can you point me to te module description? I think that the module
>>> is working if it's compiled in. Correct?
>>>
>>> Michael
>>>
>>>
>>>> Thanks for your reply, best regards!
>>>>
>>>> 2015-11-23 16:57 GMT-02:00 Michael Trimarchi 
>>>> <mich...@amarulasolutions.com>:
>>>>> Hi Daniel
>>>>>
>>>>>
>>>>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>>>> Hi every body!
>>>>>>
>>>>>> I'm running a (2.6.37) kernel based 

Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Hi every body!

I'm running a (2.6.37) kernel based on linux-omap tree
(http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary).
The board is a SoM from Variscite (var-som-am3517).

I've compiled the ehci-hcd as a module. When I enable it I got this dump:
http://pastebin.com/5idXXBBi

Googling arroud I found that this can be triggered while trying to
access uhh registers when usbhost_48m_fck is not enabled. This is what
I think is happening since the message
"Clock usbhost_48m_fck didn't enable in 10 tries" is aways present
before the crash, and since the crash happens at first read o uhh
registers. I just can't figure out why usbhost_48m_fck is not getting
enabled and how to check if is trully disabled.

Any ideas?

Thanks in advance!
Regards,

-- 
"Do or do not. There is no try"
  Yoda Master
--
To unsubscribe from this list: send the line "unsubscribe 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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

Hi Michael,

It's a plain linux. I'm considering upgrading kernel as last option.
Variscite doesn't
support another kernel for this SoM so this would be a really hard
work. I'm looking
for a solution on this kernel and mainly trying to understand why
usbhost_48m_fck
is not getting enabled. I'm contacting Variscite in parallel.

Thanks for your reply, best regards!

2015-11-23 16:57 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
> Hi Daniel
>
>
> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> wrote:
>> Hi every body!
>>
>> I'm running a (2.6.37) kernel based on linux-omap tree
>> (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary).
>> The board is a SoM from Variscite (var-som-am3517).
>>
>> I've compiled the ehci-hcd as a module. When I enable it I got this dump:
>> http://pastebin.com/5idXXBBi
>>
>
> Do you have an android device? or it's just plain linux.
> For option 2 I suggest to move on newest kernel
>
> Michael
>
>> Googling arroud I found that this can be triggered while trying to
>> access uhh registers when usbhost_48m_fck is not enabled. This is what
>> I think is happening since the message
>> "Clock usbhost_48m_fck didn't enable in 10 tries" is aways present
>> before the crash, and since the crash happens at first read o uhh
>> registers. I just can't figure out why usbhost_48m_fck is not getting
>> enabled and how to check if is trully disabled.
>>
>> Any ideas?
>>
>> Thanks in advance!
>> Regards,
>>
>> --
>> "Do or do not. There is no try"
>>   Yoda Master
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> |  [`as] http://www.amarulasolutions.com   |



-- 
"Do or do not. There is no try"
  Yoda Master
--
To unsubscribe from this list: send the line "unsubscribe 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 RFC v2 0/2] Disable planes on blanked CRTC and enable on unblank

[Daniel Vetter]

On Fri, Nov 13, 2015 at 05:53:13PM +0200, Jyri Sarha wrote:
> Since first RFC version:
> - Added "drm/atomic: Track drm_plane's active state"-patch
> 
> We would need something like this to get rid off OMAPDSS somewhat
> messy runtime_resume code. How does this look, could this generic
> solution be refined to be acceptable for mainline, or should we start
> looking a local solution to omapdrm?

One more comment besides what I've written in the older thread: You're not
on latest drm-next, which has gained an active_only paramter to the plane
commit helper.

It might be best to discuss this topic on #dri-devel on freenode irc a
bit.

Cheers, Daniel

> 
> Jyri Sarha (2):
>   drm/atomic: Track drm_plane's active state
>   drm/atomic: Disable planes on blanked CRTC and enable on unblank
> 
>  drivers/gpu/drm/drm_atomic_helper.c | 82 
> +
>  drivers/gpu/drm/drm_plane_helper.c  | 10 +
>  include/drm/drm_atomic_helper.h | 39 +-
>  include/drm/drm_crtc.h  |  2 +
>  4 files changed, 70 insertions(+), 63 deletions(-)
> 
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe 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 v11 2/4] PM / Domains: add setter for dev.pm_domain

[Daniel Kurtz]

Hi Tomeu,

On Tue, Oct 27, 2015 at 10:38 PM, Tomeu Vizoso
 wrote:
> Adds a function that sets the pointer to dev_pm_domain in struct device
> and that warns if the device has already finished probing. The reason
> why we want to enforce that is because in the general case that can
> cause problems and also that we can simplify code quite a bit if we can
> always assume that.
>
> This patch also changes all current code that directly sets the
> dev.pm_domain pointer.
>
> Signed-off-by: Tomeu Vizoso 
> Reviewed-by: Ulf Hansson 
> ---

[snip...]

> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
> index f32b802b98f4..a70f8a5cdfd7 100644
> --- a/drivers/base/power/common.c
> +++ b/drivers/base/power/common.c
> @@ -128,3 +128,24 @@ void dev_pm_domain_detach(struct device *dev, bool 
> power_off)
> dev->pm_domain->detach(dev, power_off);
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_domain_detach);
> +
> +/**
> + * dev_pm_domain_set - Set PM domain of a device.
> + * @dev: Device whose PM domain is to be set.
> + * @pd: PM domain to be set, or NULL.
> + *
> + * Sets the PM domain the device belongs to. The PM domain of a device needs
> + * to be set before its probe finishes (it's bound to a driver).
> + *
> + * This function must be called with the device lock held.
> + */
> +void dev_pm_domain_set(struct device *dev, struct dev_pm_domain *pd)
> +{
> +   if (dev->pm_domain == pd)
> +   return;
> +
> +   WARN(device_is_bound(dev),
> +"PM domains can only be changed for unbound devices\n");
> +   dev->pm_domain = pd;
> +}

When testing this patch, I have a platform driver with a device in a
genpd that hits this WARN() during shutdown with a backtrace like:

[  930.476714] [ cut here ]
[  930.481323] WARNING: CPU: 3 PID: 10110 at
drivers/base/power/common.c:154 dev_pm_domain_set+0x50/0x60()
[  930.494605] PM domains can only be changed for unbound devices
[  930.541047] Call trace:
[  930.543470] [] dump_backtrace+0x0/0x140
[  930.548820] [] show_stack+0x1c/0x28
[  930.553826] [] dump_stack+0x74/0x94
[  930.558831] [] warn_slowpath_common+0x90/0xb8
[  930.564698] [] warn_slowpath_fmt+0x84/0xac
[  930.570305] [] dev_pm_domain_set+0x4c/0x60
[  930.575913] [] pm_genpd_remove_device+0xc4/0x174
[  930.582038] [] genpd_dev_pm_detach+0x7c/0xd4
[  930.587818] [] dev_pm_domain_detach+0x34/0x44
[  930.593685] [] platform_drv_shutdown+0x30/0x40
[  930.599639] [] device_shutdown+0x12c/0x184
[  930.605247] [] kernel_restart_prepare+0x38/0x44
[  930.611285] [] kernel_restart+0x1c/0x68
[  930.616634] [] SyS_reboot+0x1b4/0x210
[  930.621810] ---[ end trace 0551d0a7afcd5f6f ]---

The problem appears to be that:
  * On boot, platform_drv_probe() calls dev_pm_domain_attach() before
drv->probe(); thus, it calls dev_pm_domain_attach() while the device
is unbound.

 * However, for a platform_device, the reboot path calls
device_shutdown(), but not __device_release_driver():
device_shutdown()
  dev->driver->shutdown => platform_drv_shutdown()
dev_pm_domain_detach()
   dev->pm_domain->detach() => genpd_dev_pm_detach()
 pm_genpd_remove_device()
dev_pm_domain_set(dev, NULL);

So, for a platform_device in a genpd power domain with .shutdown
installed, platform_drv_shutdown() calls dev_pm_domain_detach() while
the device is still bound, which triggers the WARN().

Thanks,
-Dan
--
To unsubscribe from this list: send the line "unsubscribe 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 09/11] clocksource: add TI 32.768 Hz counter driver

[Daniel Lezcano]

On 10/06/2015 07:02 PM, Felipe Balbi wrote:

Introduce a new clocksource driver for Texas
Instruments 32.768 Hz device which is available
on most OMAP-like devices.

Signed-off-by: Felipe Balbi <ba...@ti.com>


Hi Felipe,

With the couple of nits below fixed, you can my:

Acked-by: Daniel Lezcano <daniel.lezc...@linaro.org>

[ ... ]


+#define OMAP2_32KSYNCNT_REV_OFF0x0
+#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30)
+#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
+#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30
+
+struct ti_32k {
+   void __iomem*base;
+   void __iomem*counter;
+   struct clocksource  cs;
+};
+#define to_ti_32k(cs)  (container_of((cs), struct ti_32k, cs))


Usually a static inline is used instead of a macro for that.


+static cycle_t ti_32k_read_cycles(struct clocksource *cs)
+{
+   struct ti_32k   *ti = to_ti_32k(cs);


format


--
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe 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 09/11] clocksource: add TI 32.768 Hz counter driver

[Daniel Lezcano]

(struct device_node *np)
+{
+   void __iomem *vbase;
+   int ret;
+
+   vbase = of_iomap(np, 0);
+   if (!vbase) {
+   pr_err("Can't ioremap 32k timer base\n");
+   return;
+   }
+
+   /*
+* 32k sync Counter IP register offsets vary between the
+* highlander version and the legacy ones.
+* The 'SCHEME' bits(30-31) of the revision register is used
+* to identify the version.
+*/


Please fix comment length.


+   if (readl_relaxed(vbase + OMAP2_32KSYNCNT_REV_OFF) &
+   OMAP2_32KSYNCNT_REV_SCHEME)
+   sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH;
+   else
+   sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW;
+
+   /*
+* 12 rough estimate from the calculations in
+* __clocksource_update_freq_scale.
+*/


Fix comment length also.


+   clocks_calc_mult_shift(_mult, _shift,
+   32768, NSEC_PER_SEC, 12);
+
+   ret = clocksource_mmio_init(sync32k_cnt_reg, "32k_counter", 32768,
+   250, 32, clocksource_mmio_readl_up);
+   if (ret) {
+   pr_err("32k_counter: can't register clocksource\n");
+   return;
+   }
+
+   sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
+   register_persistent_clock(NULL, omap_read_persistent_clock64);


I will let John Stultz to have a look at this part because I have doubt 
regarding the usage of the persistent clock.



  -- Daniel


--
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe 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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Daniel Vetter]

On Mon, Sep 28, 2015 at 12:26:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> > few questions/remarks
> > BR,
> > Arnaud
> > 
> > >+static void hdmi_codec_abort(struct device *dev)
> > >+{
> > >+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> > >+
> > >+dev_dbg(dev, "%s()\n", __func__);
> > >+
> > >+mutex_lock(>current_stream_lock);
> > >+if (hcp->current_stream && hcp->current_stream->runtime &&
> > >+snd_pcm_running(hcp->current_stream)) {
> > >+dev_info(dev, "HDMI audio playback aborted\n");
> > >+snd_pcm_stream_lock_irq(hcp->current_stream);
> > >+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> > >+snd_pcm_stream_unlock_irq(hcp->current_stream);
> > >+}
> > >+mutex_unlock(>current_stream_lock);
> > >+}
> > Does driver should stop the stream in case of unplug?
> > This could generate unexpected behavior at application level.
> > Perhaps should be better if this part is managed in DRM driver. if HDMI
> > master, I2S bus should be maintained ON to consume the audio stream until
> > application action.
> 
> If it does, that's really horrid.

Atm the rule for display outputs is that nothing gets yanked until
userspace approves, since otherwise compositors get stuck (or fall over
with an unexpected -EINVAL from the kernel). The exception is DP MST
because the current implementation is a complete hack for DP MST sink
lifetimes and that's why we need to synchronously nuke them (which means
shutting down everything). I'm surprised not a hole lot more people
complain about this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe 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 09/21] drm/omap: handle mismatching color format and buffer width

[Daniel Stone]

Hi,

On 2 March 2015 at 09:50, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 27/02/15 16:40, Daniel Stone wrote:
 On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
 omapdrm doesn't check if the width of the framebuffer and the color

 s/width/pitch/

 format's bits-per-pixel match.

 s/match/are compatible/

 For example, using a display with a width of 1280, and a buffer
 allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with

 Might be clearer to say 'i.e. byte stride of ...', and also s/with 
 using/for/.

 Above you said pitch, here you say stride. They are the same thing, right?

Yeah, they're interchangeable. In theory, I think it's supposed to be
that pitch is in pixels and stride in bpp, but they're so often
interchanged that they've lost that distinction. Still, using one
consistently is always good - and since KMS uses pitch exclusively,
that might be a good one to settle on.

 stride_bpp is very misnamed: it is the bits per pixel for that plane,
 and not stride at all. I think the check should in fact be be (pitch %

 I don't know why Rob named it like that. The bpp of the stride? Shrug.

It's just the bpp of the pixel format; it's not at all associated with
the stride?

 This isn't that check. At some stages, OMAP IIRC requires pitch to be
 specified in pixels rather than bytes, so this makes sure that's
 possible to express.

 Right, that's what this patch was trying to achieve.

 However... After thinking about this and going through some of the DISPC
 code, I think that's not a strict requirement. We do calculate all the
 configs using pixels as units, so at the moment the stride has to be an
 integer number of pixels. But the hardware actually takes the row-inc
 and pix-inc as bytes.

 That said, the HW supports features like rotation and whatnot, and it
 was not clear with a quick study if there are corner cases where the
 hardware also requires the stride to be an integer number of pixels.
 Also, the HW documentation only talks about pixels in this context, even
 if the final value written to the registers is in bytes. I don't know if
 that's just to make the documentation simpler, or if there's some
 reasoning to only use pixel units.

Indeed that was my impression from a quick look, but my OMAP is
extremely rusty these days, so wasn't quite sure ... :) Specifying
pixel units isn't totally unheard of, but bytes is definitely more
common.

Cheers,
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 09/21] drm/omap: handle mismatching color format and buffer width

[Daniel Vetter]

On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
 omapdrm doesn't check if the width of the framebuffer and the color
 format's bits-per-pixel match.
 
 For example, using a display with a width of 1280, and a buffer
 allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
 a 24 bits per pixel color format, leads to the following mismatch:
 5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
 screen.
 
 Add a check into omapdrm to return an error if the user tries to use
 such a combination.
 
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 ---
  drivers/gpu/drm/omapdrm/omap_fb.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
 b/drivers/gpu/drm/omapdrm/omap_fb.c
 index 2975096abdf5..bf98580223d0 100644
 --- a/drivers/gpu/drm/omapdrm/omap_fb.c
 +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
 @@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
 drm_device *dev,
   goto fail;
   }
  
 + if (mode_cmd-width % format-planes[i].stride_bpp != 0) {

width is in pixels. No idea what you're trying to check here, but this
probably isn't it.

Also drm checks that things fit into the specified pitch (which is in
bytes), see the pichtes[i]  width * cpp check in framebuffer_check.

Cheers, Daniel
 + dev_err(dev-dev,
 + buffer width (%d) is not a multiple of pixel 
 width (%d)\n,
 + mode_cmd-width, format-planes[i].stride_bpp);
 + ret = -EINVAL;
 + goto fail;
 + }
 +
   size = pitch * mode_cmd-height / format-planes[i].sub_y;
  
   if (size  (omap_gem_mmap_size(bos[i]) - mode_cmd-offsets[i])) 
 {
 -- 
 2.3.0
 
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe 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 09/21] drm/omap: handle mismatching color format and buffer width

[Daniel Stone]

Hi,

On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
 omapdrm doesn't check if the width of the framebuffer and the color

s/width/pitch/

 format's bits-per-pixel match.

s/match/are compatible/

 For example, using a display with a width of 1280, and a buffer
 allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with

Might be clearer to say 'i.e. byte stride of ...', and also s/with using/for/.

 a 24 bits per pixel color format, leads to the following mismatch:
 5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the

s/bytes/pixels/

 screen.

 Add a check into omapdrm to return an error if the user tries to use
 such a combination.

 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 ---
  drivers/gpu/drm/omapdrm/omap_fb.c | 8 
  1 file changed, 8 insertions(+)

 diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
 b/drivers/gpu/drm/omapdrm/omap_fb.c
 index 2975096abdf5..bf98580223d0 100644
 --- a/drivers/gpu/drm/omapdrm/omap_fb.c
 +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
 @@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
 drm_device *dev,
   goto fail;
   }

 + if (mode_cmd-width % format-planes[i].stride_bpp != 0) {

 width is in pixels. No idea what you're trying to check here, but this
 probably isn't it.

stride_bpp is very misnamed: it is the bits per pixel for that plane,
and not stride at all. I think the check should in fact be be (pitch %
format-planes[i].stride_bpp), which would achieve the desired result,
i.e. that the stride can be expressed as an integer number of pixels.

 Also drm checks that things fit into the specified pitch (which is in
 bytes), see the pichtes[i]  width * cpp check in framebuffer_check.

This isn't that check. At some stages, OMAP IIRC requires pitch to be
specified in pixels rather than bytes, so this makes sure that's
possible to express.

Cheers,
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 09/21] drm/omap: handle mismatching color format and buffer width

[Daniel Vetter]

On Fri, Feb 27, 2015 at 02:40:20PM +, Daniel Stone wrote:
 On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
  omapdrm doesn't check if the width of the framebuffer and the color
  diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
  b/drivers/gpu/drm/omapdrm/omap_fb.c
  index 2975096abdf5..bf98580223d0 100644
  --- a/drivers/gpu/drm/omapdrm/omap_fb.c
  +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
  @@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
  drm_device *dev,
goto fail;
}
 
  + if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
 
  width is in pixels. No idea what you're trying to check here, but this
  probably isn't it.
 
 stride_bpp is very misnamed: it is the bits per pixel for that plane,
 and not stride at all. I think the check should in fact be be (pitch %
 format-planes[i].stride_bpp), which would achieve the desired result,
 i.e. that the stride can be expressed as an integer number of pixels.

I meant that mode_cmd-width is in pixels and so totally not what you want
to check here. It probably should be mode_cmd-pitches[i].
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe 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 06/21] drm/omap: check CRTC color format earlier

[Daniel Vetter]

On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
 When setting a color format to a DRM plane, the DRM core checks whether
 the format is supported by the HW. However, it seems that when setting
 the color format of a CRTC (i.e. a root plane), there's no checking
 done. This causes omapdrm to configure omapdss with the bad color
 format, which omapdss then rejects.
 
 While the above is ok, the error message is a bit confusing, and the
 configuring of omapdss happens asynchronously from the ioctl that does
 the color format change.
 
 This patch adds a color format check to omap_plane_mode_set() which
 causes the ioctl to return an error for invalid color format. This means
 that the userspace will get to know of the wrong setting, instead of the
 current behavior where the error is not seen by the userspace.
 
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 ---
  drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
  1 file changed, 18 insertions(+)
 
 diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
 b/drivers/gpu/drm/omapdrm/omap_plane.c
 index 1f4f2b866379..bedd6f7af0f1 100644
 --- a/drivers/gpu/drm/omapdrm/omap_plane.c
 +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
 @@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
  {
   struct omap_plane *omap_plane = to_omap_plane(plane);
   struct omap_drm_window *win = omap_plane-win;
 + int i;
 +
 + /*
 +  * Check whether this plane supports the fb pixel format.
 +  * I don't think this should really be needed, but it looks like the
 +  * drm core only checks the format for planes, not for the crtc. So
 +  * when setting the format for crtc, without this check we would
 +  * get an error later when trying to program the color format into the
 +  * HW.
 +  */

I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.

Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
-Daniel

 + for (i = 0; i  plane-format_count; i++)
 + if (fb-pixel_format == plane-format_types[i])
 + break;
 + if (i == plane-format_count) {
 + DBG(Invalid pixel format %s,
 +   drm_get_format_name(fb-pixel_format));
 + return -EINVAL;
 + }
  
   win-crtc_x = crtc_x;
   win-crtc_y = crtc_y;
 -- 
 2.3.0
 
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.19-rc2 v15 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

On 19/01/15 21:38, Tony Lindgren wrote:
 * Daniel Thompson daniel.thomp...@linaro.org [150105 04:49]:
 The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
 the 8520 code the omap1 macro automatically determines what UART to use
 based on breadcrumbs left by the bootloader and automatically copes with
 the eccentric register layout on OMAP7XX.

 This patch drops both these features and relies instead on the generic
 8250 macros:

 1. Dropping support for the bootloader breadcrumbs is identical to the
way the migration was handled for OMAP2 (see 808b7e07464d...).

 2. Support for OMAP7XX still exists but it must be configured by hand
(DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

 Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Arnd Bergmann arnd.bergm...@linaro.org
 Cc: linux-omap@vger.kernel.org
 Tested-by: Aaro Koskinen aaro.koski...@iki.fi
 Acked-by: Tony Lindgren t...@atomide.com
 
 Daniel, I suggest you upload this patch into Russell's patch tracking
 system to get it merged. That at least shrinks down your patch series
 if the other patches need more work.

This has been in the patch tracker for a week or so:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8271/1

I'm very aware that this patch (and indeed the whole patch set) has been
knocking round for longer than it should have. The changelog for this
patchset is certainly not one to be especially proud off ;-) .


Daniel.

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

[PATCH 3.19-rc2 v15 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index eba36e35bad2..ec25d746b4dd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -527,6 +527,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -569,6 +593,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1308,6 +1356,9 @@ config DEBUG_UART_PHYS
default 0xffe4 if DEBUG_RCAR_GEN1_SCIF0
default 0xffe42000 if DEBUG_RCAR_GEN1_SCIF2
default 0xfff36000 if DEBUG_HIGHBANK_UART
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfffe8600 if DEBUG_UART_BCM63XX
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1390,6 +1441,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default 0xff003000

[PATCH 3.19-rc1 v14 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index eba36e35bad2..ec25d746b4dd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -527,6 +527,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -569,6 +593,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1308,6 +1356,9 @@ config DEBUG_UART_PHYS
default 0xffe4 if DEBUG_RCAR_GEN1_SCIF0
default 0xffe42000 if DEBUG_RCAR_GEN1_SCIF2
default 0xfff36000 if DEBUG_HIGHBANK_UART
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfffe8600 if DEBUG_UART_BCM63XX
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1390,6 +1441,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default 0xff003000

Re: [PATCH v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

On 16/11/14 00:29, Aaro Koskinen wrote:
 Hi,
 
 On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote:
 +config DEBUG_OMAP1UART1
 +bool Kernel low-level debugging via OMAP1 UART1
 +depends on ARCH_OMAP1
 +select DEBUG_UART_8250
 +help
 +  Say Y here if you want kernel low-level debugging support
 +  on OMAP1 based platforms (expect OMAP730) on the UART1.
 [...]
 +  on OMAP1 based platforms (expect OMAP730) on the UART2.
 [...]
 +  on OMAP1 based platforms (expect OMAP730) on the UART3.
 ^^
 
 Spelling again wrong. I think it was already corrected in v11?

Sorry and, yes, you're right this was corrected in v11.

I was travelling when I posted v11 so I guess I must have forgot to pull
the right branches to my main machine. I will dig it and diff shortly to
make sure I didn't miss anything else.


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 v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

On 17/11/14 09:07, Daniel Thompson wrote:
 On 16/11/14 00:29, Aaro Koskinen wrote:
 Hi,

 On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote:
 +   config DEBUG_OMAP1UART1
 +   bool Kernel low-level debugging via OMAP1 UART1
 +   depends on ARCH_OMAP1
 +   select DEBUG_UART_8250
 +   help
 + Say Y here if you want kernel low-level debugging support
 + on OMAP1 based platforms (expect OMAP730) on the UART1.
 [...]
 + on OMAP1 based platforms (expect OMAP730) on the UART2.
 [...]
 + on OMAP1 based platforms (expect OMAP730) on the UART3.
 ^^

 Spelling again wrong. I think it was already corrected in v11?
 
 Sorry and, yes, you're right this was corrected in v11.
 
 I was travelling when I posted v11 so I guess I must have forgot to pull
 the right branches to my main machine. I will dig it and diff shortly to
 make sure I didn't miss anything else.

Just as well I did the diff. v12 was derived from v9 rather than v11 as
it should have been, so apologies to Aaro and Paul Bolle for dropping
changes they asked for.

I will try to change how I keep track of things when I go travelling in
future...


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

[PATCH v13 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6dc39e69fe12..80e8ac50551e 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -495,6 +495,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -537,6 +561,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1163,6 +1211,9 @@ config DEBUG_UART_PHYS
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
default 0xfff36000 if DEBUG_HIGHBANK_UART
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfffe8600 if DEBUG_UART_BCM63XX
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1236,6 +1287,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X

Re: [PATCH v9] ARM: omap: edma: add suspend resume hook

[Daniel Mack]

Hi Sekhar,

On 11/14/2014 06:03 PM, Sekhar Nori wrote:
 I think I have asked this before, and I am still not sure why this call 
 to pm_runtime_get_sync() is needed here. From my testing today, this 
 does seem to be a a no-op and this call returns from rpm_resume() 
 because of this check:
 
   else if (dev-power.disable_depth == 1  dev-power.is_suspended
dev-power.runtime_status == RPM_ACTIVE)
   retval = 1;

Yes. IIRC, it was in fact not needed.

 So, AFAICS, the net effect is an increment of dev-power.usage_count
 (which is already greater than 0) and its subsequent decrement at the
 end of the function.
 
 After removing this call I did not see any EDMA malfunction as well 
 (can access MMC/SD just fine after suspend/resume cycle).
 
 So, any objections to merging this patch with the attached hunk 
 applied?

Looks good to me, we can still add it back later if it turns out to be
needed.


Thanks,
Daniel


 Thanks,
 Sekhar
 
 ---8---
 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 1f492d5be9c0..79de6a23047b 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -1803,13 +1803,7 @@ static int edma_probe(struct platform_device *pdev)
  
  static int edma_pm_resume(struct device *dev)
  {
 -   int i, j, r;
 -
 -   r = pm_runtime_get_sync(dev);
 -   if (r  0) {
 -   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
 -   return r;
 -   }
 +   int i, j;
  
 for (j = 0; j  arch_num_cc; j++) {
 struct edma *cc = edma_cc[j];
 @@ -1844,8 +1838,6 @@ static int edma_pm_resume(struct device *dev)
 }
 }
  
 -   pm_runtime_put_sync(dev);
 -
 return 0;
  }
 
 

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

[PATCH v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c8f623c..889ba7a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -495,6 +495,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -537,6 +561,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1163,6 +1211,9 @@ config DEBUG_UART_PHYS
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
default 0xfff36000 if DEBUG_HIGHBANK_UART
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfffe8600 if DEBUG_UART_BCM63XX
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1236,6 +1287,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 08/22/2014 07:02 AM, Nishanth Menon wrote:

From: Santosh Shilimkar santosh.shilim...@ti.com

Add OMAP5/DRA74/72 CPUIDLE support.

This patch adds MPUSS low power states in cpuidle.

 C1 - CPU0 WFI + CPU1 WFI + MPU ON
 C2 - CPU0 RET + CPU1 RET + MPU CSWR

Tested on DRA74/72-EVM for C1 and C2 states.

NOTE: DRA7 does not do voltage scaling as part of retention transition
and has Mercury which speeds up transition paths - Latency numbers are
based on measurements done by toggling GPIOs.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[ j-keer...@ti.com rework on 3.14]
Signed-off-by: Keerthy j-keer...@ti.com
[n...@ti.com: updates based on profiling, OMAP5 squashed]
Signed-off-by: Nishanth Menon n...@ti.com
---
  arch/arm/mach-omap2/cpuidle44xx.c |   82 -
  arch/arm/mach-omap2/pm44xx.c  |2 +-
  2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 2498ab0..8ad4f44 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,6 +22,7 @@
  #include common.h
  #include pm.h
  #include prm.h
+#include soc.h
  #include clockdomain.h

  #define MAX_CPUS  2
@@ -31,6 +32,7 @@ struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+   u32 mpu_state_vote;
  };

  static struct idle_statedata omap4_idle_data[] = {
@@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
},
  };

+static struct idle_statedata dra7_idle_data[] = {
+   {
+   .cpu_state = PWRDM_POWER_ON,
+   .mpu_state = PWRDM_POWER_ON,
+   .mpu_logic_state = PWRDM_POWER_ON,
+   },
+   {
+   .cpu_state = PWRDM_POWER_RET,
+   .mpu_state = PWRDM_POWER_RET,
+   .mpu_logic_state = PWRDM_POWER_RET,
+   },
+};
+
  static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
  static struct clockdomain *cpu_clkdm[MAX_CPUS];

  static atomic_t abort_barrier;
  static bool cpu_done[MAX_CPUS];
  static struct idle_statedata *state_ptr = omap4_idle_data[0];
+static DEFINE_RAW_SPINLOCK(mpu_lock);

  /* Private functions */

@@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
return index;
  }

+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+  struct cpuidle_driver *drv,
+  int index)
+{
+   struct idle_statedata *cx = state_ptr + index;
+   unsigned long flag;
+
+   raw_spin_lock_irqsave(mpu_lock, flag);


Why do you need this spin_lock_irqsave ? Aren't the local irqs already 
disabled ?



+   cx-mpu_state_vote++;
+   if (cx-mpu_state_vote == num_online_cpus()) {
+   pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+   omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+   }
+   raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+   omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+   raw_spin_lock_irqsave(mpu_lock, flag);
+   if (cx-mpu_state_vote == num_online_cpus())
+   omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+   cx-mpu_state_vote--;
+   raw_spin_unlock_irqrestore(mpu_lock, flag);


I am not sure that will work. What happens if a cpu exits idle and then 
re-enter idle immediately ?


Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c


+   return index;
+}
+
  static int omap_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
.safe_state_index = 0,
  };

+static struct cpuidle_driver dra7_idle_driver = {
+   .name   = dra7_idle,
+   .owner  = THIS_MODULE,
+   .states = {
+   {
+   /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+   .exit_latency = 2 + 2,
+   .target_residency = 5,
+   .flags = CPUIDLE_FLAG_TIME_VALID,
+   .enter = omap_enter_idle_simple,
+   .name = C1,
+   .desc = CPUx WFI, MPUSS ON
+   },
+   {
+   /* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
+   .exit_latency = 48 + 60,
+   .target_residency = 100,
+   .flags = CPUIDLE_FLAG_TIME_VALID
+   | CPUIDLE_FLAG_TIMER_STOP,
+   .enter = omap_enter_idle_smp,
+   .name = C2,
+   .desc = CPUx CSWR, MPUSS CSWR,
+   },
+   },
+   .state_count = ARRAY_SIZE(dra7_idle_data),
+   .safe_state_index = 0,
+};
+
  /* Public functions */

  

Re: [PATCH] arm: arm: fiq: fix build breakage with CONFIG_FIQ

[Daniel Thompson]

On 17/09/14 13:01, Felipe Balbi wrote:
 commit e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
 has a typo which causes build breakage whenever CONFIG_FIQ is
 set.
 
 The bug is very clear as can be noted that a new struct pt_regs
 def_fiq_regs was defined but code uses dfl_fiq_regs.

Quite so. My fault.

This error was picked up by Olof's autobuilder and I have offered
a fix as 8150/3 (posted to mailing list in this thread
http://thread.gmane.org/gmane.linux.kernel/1789554 ).

Your fix and mine are slightly different (I standardised on
dfl_fiq_regs) but both approaches should be functionally identical.


Daniel.


 Cc: Daniel Thompson daniel.thomp...@linaro.org
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Nicolas Pitre n...@linaro.org
 Fixes: e1add97 (ARM: 8150/2: fiq: Replace default FIQ handler)
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 KernelVersion: next-20140917
 
 Russell, let me know if this is the correct KernelVersion tag you want/need
 
  arch/arm/kernel/fiq.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
 index 1743049..b6ab4c7 100644
 --- a/arch/arm/kernel/fiq.c
 +++ b/arch/arm/kernel/fiq.c
 @@ -64,7 +64,7 @@ static int fiq_def_op(void *ref, int relinquish)
   if (!relinquish) {
   /* Restore default handler and registers */
   local_fiq_disable();
 - set_fiq_regs(dfl_fiq_regs);
 + set_fiq_regs(def_fiq_regs);
   set_fiq_handler(no_fiq_insn, sizeof(no_fiq_insn));
   local_fiq_enable();
  
 @@ -159,6 +159,6 @@ void __init init_FIQ(int start)
  {
   unsigned offset = FIQ_OFFSET;
   no_fiq_insn = *(unsigned long *)(0x + offset);
 - get_fiq_regs(dfl_fiq_regs);
 + get_fiq_regs(def_fiq_regs);
   fiq_start = start;
  }
 

--
To unsubscribe from this list: send the line unsubscribe 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 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:

Sorry for the format. Emailing from webmail.



[ ... ]


+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);


Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?

[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.


ok.


+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);


I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?

[Santosh] It works and that case is already taken care. CPU exist the idle and 
then votes
out for cluster state and if it reenters with the right targeted state, the 
cluster state would
be picked.


It isn't possible to have one cpu disabling the coherency, while the 
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the 
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the 
wfi check the state vote and set the power domain on. In the meantime 
cpu1 disables the coherency and cpu0 decrease the vote and release the 
lock. Could be possible there is a very small racy window here ?



Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

[Santosh] I am sure there will not be any issue with the long run test case 
here.
Lets see if Nishant sees anything otherwise


Ok. Make sure the cpu is effectively entering your C2 state with the 
sleep duration in the test program.



--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

--
To unsubscribe from this list: send the line unsubscribe 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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 97c3058..01f4ee2 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -471,6 +471,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -513,6 +537,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS
default 0xff69 if DEBUG_RK32_UART2
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfff36000 if DEBUG_HIGHBANK_UART
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default

Re: [PATCH v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

On 16/09/14 15:58, Aaro Koskinen wrote:
 Hi,
 
 On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote:
 +config DEBUG_OMAP1UART1
 +bool Kernel low-level debugging via OMAP1 UART1
 +depends on ARCH_OMAP1
 +select DEBUG_UART_8250
 +help
 +  Say Y here if you want kernel low-level debugging support
 +  on OMAP1 based platforms (expect OMAP730) on the UART1.
 ^^
 
 +select DEBUG_UART_8250
 +help
 +  Say Y here if you want kernel low-level debugging support
 +  on OMAP1 based platforms (expect OMAP730) on the UART2.
 ^^
 
 +select DEBUG_UART_8250
 +help
 +  Say Y here if you want kernel low-level debugging support
 +  on OMAP1 based platforms (expect OMAP730) on the UART3.
 ^^
 
 I already commented earlier, that expect here is probably a typo?

I'm extremely sorry to have overlooked your previous comment. There's
certainly no question I read your previous e-mail because because I
copied your Tested-by: from it.

I will fix this (and also grep all other patches in the set to make sure
I haven't copied the typo anywhere else).


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

[PATCH v11 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 97c3058..6540036 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -471,6 +471,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (except OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -513,6 +537,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS
default 0xff69 if DEBUG_RK32_UART2
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfff36000 if DEBUG_HIGHBANK_UART
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default

Re: [PATCH v7 RESEND] ARM: omap: edma: add suspend suspend/resume hooks

[Daniel Mack]

Hi,

On 08/26/2014 08:36 AM, Sekhar Nori wrote:
 On Friday 22 August 2014 01:16 PM, Dave Gerlach wrote:

Thanks for pushing that forward!

 +static int edma_pm_suspend(struct device *dev)
 +{
 +int j, r;
 +
 +r = pm_runtime_get_sync(dev);
 +if (r  0) {
 +dev_err(dev, %s: get_sync returned %d\n, __func__, r);
 +return r;
 +}
 
 The driver currently does a pm_runtime_get_sync() once during probe. And
 does not do a put(). So this should actually be not required. In fact
 looks like this additional get() call will prevent the clock from
 getting disabled which is probably not what you intend.

Well, the pm runtime is put again ...

 +
 +for (j = 0; j  arch_num_cc; j++) {
 +struct edma *ecc = edma_cc[j];
 +
 +disable_irq(ecc-irq_res_start);
 +disable_irq(ecc-irq_res_end);
 
 Do we really need to disable these irqs?
 
 +}
 +
 +pm_runtime_put_sync(dev);

... here, so it's in sync and should be fine.

I was also sure than when I wrote the code, disabling the interrupts
during suspend was necessary, and even the only thing that has to be
done at suspend time. Now that I address this again, my tests show that
in can in fact be omitted.

So I'll send a v9 now that has no edma_pm_suspend() at all anymore.

 +static const struct dev_pm_ops edma_pm_ops = {
 +.suspend_late   = edma_pm_suspend,
 +.resume_early   = edma_pm_resume,
 +};
 
 You can use SET_LATE_SYSTEM_SLEEP_PM_OPS() as some other DMA drivers are
 doing too.

Sure, why not.


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

[PATCH v9] ARM: omap: edma: add suspend resume hook

[Daniel Mack]

This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

[n...@ti.com: added error handling for runtime + suspend_late/early_resume]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Daniel Mack zon...@gmail.com
Tested-by: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
Changes from v8:

* Drop the edma_suspend hook altogether. Even though back then
  when I wrote the code I was sure disabling the interrupts
  during suspend is necessary, tests now show it in fact isn't.
  My test setup still works if that code is omitted.
* Use SET_LATE_SYSTEM_SLEEP_PM_OPS in the dev_pm_ops
  declaration.

Thanks to Sekhar for pointing out the above.

 arch/arm/common/edma.c | 60 --
 1 file changed, 58 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 485be42..c623dd0 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -244,6 +244,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -295,7 +297,7 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -314,7 +316,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1762,15 +1764,69 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (r  0) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+queue_priority_mapping[i][0],
+queue_priority_mapping[i][1]);
+
+   /*
+* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++) {
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+  BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i].data);
+   }
+   }
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static const struct dev_pm_ops edma_pm_ops = {
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, edma_pm_resume)
+};
+
 static struct platform_driver edma_driver = {
.driver = {
.name   = edma,
+   .pm = edma_pm_ops,
.of_match_table = edma_of_ids,
},
.probe = edma_probe,
-- 
2.1.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 v8 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 97c3058..01f4ee2 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -471,6 +471,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -513,6 +537,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS
default 0xff69 if DEBUG_RK32_UART2
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfff36000 if DEBUG_HIGHBANK_UART
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default

[PATCH v9 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 97c3058..01f4ee2 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -471,6 +471,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -513,6 +537,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS
default 0xff69 if DEBUG_RK32_UART2
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfff36000 if DEBUG_HIGHBANK_UART
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default

Re: [PATCH] ARM: OMAP: generic: add call to of_clk_init()

[Daniel Mack]

Hi Tony,

On 07/23/2014 10:54 AM, Tony Lindgren wrote:
 * Daniel Mack zon...@gmail.com [140712 03:57]:
 This is needed to instanciate fixed clocks in the DT.
 
 Makes sense to me. Does this fix some regression or hang
 that's needed for the -rc series?

No, it's a feature addition. No need to hurry :)

 Also would like to get an ack from Tero on this as the other
 clocks are initialized elsewhere.

Ok, thanks. I'm open to alternative ways of course.


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

[PATCH CFT v2] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but it must be configured by hand
   (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
---

Notes:
Changes since v1:

* Removed !ARCH_OMAP7XX from the DEBUG_OMAP1UART1/2/3 options
  (thanks to Aaro Koskinen)

 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6f9664a..762b3ed 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -463,6 +463,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -505,6 +529,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1106,6 +1154,9 @@ config DEBUG_UART_PHYS
default 0xfe80 if ARCH_IOP32X
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfff36000 if DEBUG_HIGHBANK_UART
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1173,6 +1224,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default

[PATCH CFT] arm: omap1: Migrate debug_ll macros to use 8250.S

[Daniel Thompson]

The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.

This patch drops both these features and relies instead on the generic
8250 macros:

1. Dropping support for the bootloader breadcrumbs is identical to the
   way the migration was handled for OMAP2 (see 808b7e07464d...).

2. Support for OMAP7XX still exists but is configured at compile time
   rather than runtime.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann arnd.bergm...@linaro.org
Cc: linux-omap@vger.kernel.org
---
 arch/arm/Kconfig.debug |  57 +-
 arch/arm/mach-omap1/include/mach/debug-macro.S | 101 -
 2 files changed, 56 insertions(+), 102 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6f9664a..0881853 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -463,6 +463,30 @@ choice
  Say Y here if you want kernel low-level debugging support
  on TI-NSPIRE CX models.
 
+   config DEBUG_OMAP1UART1
+   bool Kernel low-level debugging via OMAP1 UART1
+   depends on ARCH_OMAP1  !ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART1.
+
+   config DEBUG_OMAP1UART2
+   bool Kernel low-level debugging via OMAP1 UART2
+   depends on ARCH_OMAP1  !ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART2.
+
+   config DEBUG_OMAP1UART3
+   bool Kernel low-level debugging via OMAP1 UART3
+   depends on ARCH_OMAP1  !ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP1 based platforms (expect OMAP730) on the UART3.
+
config DEBUG_OMAP2UART1
bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 
boards)
depends on ARCH_OMAP2PLUS
@@ -505,6 +529,30 @@ choice
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
 
+   config DEBUG_OMAP7XXUART1
+   bool Kernel low-level debugging via OMAP730 UART1
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART1.
+
+   config DEBUG_OMAP7XXUART2
+   bool Kernel low-level debugging via OMAP730 UART2
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART2.
+
+   config DEBUG_OMAP7XXUART3
+   bool Kernel low-level debugging via OMAP730 UART3
+   depends on ARCH_OMAP730
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on OMAP730 based platforms on the UART3.
+
config DEBUG_TI81XXUART1
bool Kernel low-level debugging messages via TI81XX UART1 
(ti8148evm)
depends on ARCH_OMAP2PLUS
@@ -1106,6 +1154,9 @@ config DEBUG_UART_PHYS
default 0xfe80 if ARCH_IOP32X
default 0xffc02000 if DEBUG_SOCFPGA_UART
default 0xffd82340 if ARCH_IOP13XX
+   default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfff36000 if DEBUG_HIGHBANK_UART
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
@@ -1173,6 +1224,9 @@ config DEBUG_UART_VIRT
default 0xfef0 if ARCH_IXP4XX  !CPU_BIG_ENDIAN
default 0xfef3 if ARCH_IXP4XX  CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
+   default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
+   default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
+   default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
default 0xfefff700 if ARCH_IOP33X
default 0xff003000 if DEBUG_U300_UART
default DEBUG_UART_PHYS if !MMU
@@ -1183,7 +1237,8

[PATCH] ARM: OMAP: generic: add call to of_clk_init()

[Daniel Mack]

This is needed to instanciate fixed clocks in the DT.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/mach-omap2/board-generic.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 5606fa2..39f154a 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
 #include linux/of_irq.h
 #include linux/of_platform.h
 #include linux/irqdomain.h
+#include linux/clk-provider.h
 
 #include asm/mach/arch.h
 
@@ -33,6 +34,11 @@ static struct of_device_id omap_dt_match_table[] __initdata 
= {
{ }
 };
 
+static struct of_device_id clk_match[] __initdata = {
+   { .compatible = fixed-clock, .data = of_fixed_clk_setup, },
+   { }
+};
+
 static void __init omap_generic_init(void)
 {
omapdss_early_init_of();
@@ -40,6 +46,8 @@ static void __init omap_generic_init(void)
pdata_quirks_init(omap_dt_match_table);
 
omapdss_init_of();
+
+   of_clk_init(clk_match);
 }
 
 #ifdef CONFIG_SOC_OMAP2420
-- 
1.9.3

--
To unsubscribe from this list: send the line unsubscribe 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 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support

[Daniel Mack]

On 07/11/2014 04:55 AM, Dave Gerlach wrote:
 This series adds suspend/resume support for am335x. Version 3 of this
 series can be found at [1]. I apologize for the large delay between this
 and the previous revision. This code has been heavily refined
 since the last version based on the various comments received for v3. The
 major change from previous version is moving all wkup_m3 code into a
 remoteproc based driver. The new driver handles all IPC and fw loading
 and exposes a small API to be used by PM code to achieve low power states.

Thanks a lot for this new series, Dave!

I've given it a quick test on a custom AM335x board and can confirm
success. Tested with both DDR2 and DDR3 versions, both work fine, and
power consumption drops to a reasonable level.

I'd be very happy if these patches made it in for 3.17, but I haven't
followed the discussion on the patches this set depends on.


Best regards,
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/RESEND 0/9] drm: tilcdc driver fixes

[Daniel Vetter]

On Sat, Jun 28, 2014 at 06:51:15AM -0400, Rob Clark wrote:
 On Fri, Jun 27, 2014 at 6:08 PM, Darren Etheridge detheri...@ti.com wrote:
  Guido,
 
 
  On 06/17/2014 09:17 AM, Guido Martínez wrote:
 
  The tilcdc driver could be compiled as a module, but was severely broken
  and could not be used as such. This patchset attempts to fix the issues
  preventing a proper load/unload of the module.
 
  Issues included dangling sysfs nodes, dangling devices, memory leaks and
  a double kfree.
 
  It now seems to be working ok. We have tested this by loading and
  unloading the driver repeteadly, with both panel and slave connectors
  and found no flaws.
 
  There is still one warning left on tilcdc_crtc_destroy, caused by
  destroying the connector while still in an ON status. We don't know why
  this happens or why it's an issue, so we did not fix it.
 
 
  Yes I see what you mean, it triggers the WARN_ON in tilcdc_crtc_destroy
  because DRM_MODE_DPMS_ON is still set.  This WARN_ON does make some sense
  because DPMS_OFF would have the effect of turning off clocks and putting the
  monitor to sleep which seems logical considering we have torn down the
  display.  Adding a tilcdc_crtc_dpms(DPMS_OFF) right before the WARN_ON
  confirms this, but it seems strange that this hasn't happened automatically
  (+ Russell doesn't need to do it in his Armada driver) - so I suspect there
  is a better way.
 
 tbh, I'm not entirely sure offhand why drm_mode_config_cleanup()
 doesn't remove the fb's first (which should have the effect of
 shutting down any lit crtc/encoder/connector)..  that would seem like
 the sensible way to shut down..

All userspace fbs should be cleared already before going into the driver
unload. Which only leaves you with driver internal fbs (usually just one
for fbdev emulation). It's the driver's job to clean that up explicitly.
Then you can call mode_config_cleanup and the WARN_ON in there is a really
nice space leak check.

If we'd unconditionally clean up all fbs we'd have trouble with
driver-private embedded fbs and their refcounting and would loose the
space leak check.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe 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/9] [arch/arm/omap2] replace strict_strto* with kstrto*

[Daniel Walter]

Replace obsolete strict_strto call with kstrto calls.
Simplify copy_from_user/strict_strto by using kstrto_from_user

Signed-off-by: Daniel Walter dwal...@google.com
---
 arch/arm/mach-omap2/board-omap3touchbook.c |  2 +-
 arch/arm/mach-omap2/mux.c  | 22 ++
 2 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c 
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 7da48bc..70b904c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -336,7 +336,7 @@ static int __init early_touchbook_revision(char *p)
if (!p)
return 0;
 
-   return strict_strtoul(p, 10, touchbook_revision);
+   return kstrtoul(p, 10, touchbook_revision);
 }
 early_param(tbr, early_touchbook_revision);
 
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index fd88ede..9e1b610 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -679,29 +679,19 @@ static ssize_t omap_mux_dbg_signal_write(struct file 
*file,
 const char __user *user_buf,
 size_t count, loff_t *ppos)
 {
-   char buf[OMAP_MUX_MAX_ARG_CHAR];
struct seq_file *seqf;
struct omap_mux *m;
-   unsigned long val;
-   int buf_size, ret;
+   u16 val;
+   int ret;
struct omap_mux_partition *partition;
 
if (count  OMAP_MUX_MAX_ARG_CHAR)
return -EINVAL;
 
-   memset(buf, 0, sizeof(buf));
-   buf_size = min(count, sizeof(buf) - 1);
-
-   if (copy_from_user(buf, user_buf, buf_size))
-   return -EFAULT;
-
-   ret = strict_strtoul(buf, 0x10, val);
+   ret = kstrtou16_from_user(user_buf, count, 0x10, val);
if (ret  0)
return ret;
 
-   if (val  0x)
-   return -EINVAL;
-
seqf = file-private_data;
m = seqf-private;
 
@@ -709,7 +699,7 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
if (!partition)
return -ENODEV;
 
-   omap_mux_write(partition, (u16)val, m-reg_offset);
+   omap_mux_write(partition, val, m-reg_offset);
*ppos += count;
 
return count;
@@ -915,14 +905,14 @@ static void __init omap_mux_set_cmdline_signals(void)
 
while ((token = strsep(next_opt, ,)) != NULL) {
char *keyval, *name;
-   unsigned long val;
+   u16 val;
 
keyval = token;
name = strsep(keyval, =);
if (name) {
int res;
 
-   res = strict_strtoul(keyval, 0x10, val);
+   res = kstrtou16(keyval, 0x10, val);
if (res  0)
continue;
 
-- 
2.0.0.526.g5318336

--
To unsubscribe from this list: send the line unsubscribe 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: Gadget regression with enabling of MUSB babble interrupt handling

[Daniel Mack]

(+ George)

On 06/19/2014 11:56 AM, Tony Lindgren wrote:
 Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
 to recover from babble errors) causes MUSB gadgets to stop
 enumerating at least on omap3. Reverting the the commit fixes
 the issue.

Hmm, so do you see babble errors occuring?

Also, there are some more patches for musb and babble error recovery on
the usb list, namely the ones starting here in v6:

  http://marc.info/?l=linux-usbm=140109627505065w=4

Care to give them a try?


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: Gadget regression with enabling of MUSB babble interrupt handling

[Daniel Mack]

Hi Tony,

On 06/19/2014 12:31 PM, Tony Lindgren wrote:
 * Daniel Mack dan...@zonque.org [140619 03:10]:
 On 06/19/2014 11:56 AM, Tony Lindgren wrote:
 Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
 to recover from babble errors) causes MUSB gadgets to stop
 enumerating at least on omap3. Reverting the the commit fixes
 the issue.

 Hmm, so do you see babble errors occuring?
 
 Not that I noticed of.
  
 Also, there are some more patches for musb and babble error recovery on
 the usb list, namely the ones starting here in v6:

   http://marc.info/?l=linux-usbm=140109627505065w=4

 Care to give them a try?
 
 I can confirm that [PATCH v6 1/5] usb: musb: core: Handle Babble
 condition only in HOST mode fixes the issue for me. Also the
 explanation in the patch description explains why it breaks, and
 probably for all gadgets too because BABBLE and RESET share the
 same interrupt so it's RESET in peripheral mode.

Ok, thanks for testing. I was told Felipe was out for some weeks, so I
don't know when these patches will be reviewed and merged.

 But that also raises a question: Were these patches merged for
 v3.16 ever even tested in peripheral mode?

At the time, I had no such hardware to test this on, so I was hoping for
more testers to give them a try in different environments, which
apparently didn't happen. It fixed a dead USB port condition on
host-mode enabled hardware, though.

We should make sure at least patch 1/5 from the series mentioned above
makes it to 3.16.


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: Gadget regression with enabling of MUSB babble interrupt handling

[Daniel Mack]

On 06/19/2014 12:43 PM, Tony Lindgren wrote:
 * Daniel Mack dan...@zonque.org [140619 03:38]:
 On 06/19/2014 12:31 PM, Tony Lindgren wrote:
 * Daniel Mack dan...@zonque.org [140619 03:10]:
 On 06/19/2014 11:56 AM, Tony Lindgren wrote:

 But that also raises a question: Were these patches merged for
 v3.16 ever even tested in peripheral mode?

 At the time, I had no such hardware to test this on, so I was hoping for
 more testers to give them a try in different environments, which
 apparently didn't happen. It fixed a dead USB port condition on
 host-mode enabled hardware, though.
 
 Well we probably should not merge patches without proper acks and
 tested-by:s in general as things just seem to keep breaking
 constantly otherwise. And things not working will keep people from
 using linux next which will lead into even less testing..

I'm fairly sure the patch causing your trouble has been in linux-next
for a while before they hit the merge window, so people with gadget
enabled musb could have noticed the breakage early enough. The feedback
rate for patches to this driver posted to linux-usb is also usually low,
unfortunately.

Anyway, breaking things is certainly not good, and I'm sorry for that.
I'm just uncertain what detail in the procedure should be tweaked in
order to prevent that from happening in the future.


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 0/5] Handle non-secure L2C initialization on Exynos4

[Daniel Drake]

Hi,

On Fri, Jun 13, 2014 at 3:59 PM, Tomasz Figa t.f...@samsung.com wrote:
 I have attached, three patches which make the kernel boot fine with L2
 cache enabled on ODROID-U3. Could you test them on your setup to verify
 that they indeed fix the issue?

Nice work, now my ODROID-U2 boots fine.

L2C: platform modifies aux control register: 0x0207 - 0x3e470001
L2C: platform provided aux values permit register corruption.
L2C: DT/platform modifies aux control register: 0x0207 - 0x3e470001
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 8 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 1024 kB
L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001

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 0/5] Handle non-secure L2C initialization on Exynos4

[Daniel Drake]

Hi Tomasz,

Thanks for working on this!

I have just tried this, against Linus master
64b2d1fbbfda07765dae3f601862796a61b2c451.
Added patch ARM: dts: Initial ODROID U2 support and booted on
ODROID-U2. I believe this board has the security enabled.

Unfortunately, it hangs during early boot. With earlyprintk the last
messages seen are:

L2C: platform modifies aux control register: 0x0207 - 0x3e470001
L2C: platform provided aux values permit register corruption.
L2C: DT/platform modifies aux control register: 0x0207 - 0x3e470001
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 1024 kB
L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001

I then tried to go back to the earlier patch ARM: EXYNOS: Add secure
firmware support for l2x0 init (attached, needed a rebase) but that
one also now hangs at:

L2C: platform modifies aux control register: 0x0207 - 0x3e470001

It did work on 3.14 though. Looking at the changelogs, many changes
have been made to l2x0 recently. Can you confirm that you have tested
your patches against a kernel with all of Russell King's recent
changes?

Thanks
Daniel
From 2e67231f10ed0b05c2bacfdd05774fe21315d6da Mon Sep 17 00:00:00 2001
From: Gu1 g...@aeroxteam.fr
Date: Mon, 21 Jan 2013 04:13:56 +0100
Subject: [PATCH] ARM: EXYNOS: Add secure firmware support for l2x0 init

Conflicts:
arch/arm/mm/cache-l2x0.c
---
 arch/arm/mach-exynos/firmware.c | 19 +++
 arch/arm/mm/cache-l2x0.c|  3 +++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index eb91d23..c200f77 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -16,6 +16,7 @@
 
 #include asm/firmware.h
 
+#include asm/hardware/cache-l2x0.h
 #include mach/map.h
 
 #include common.h
@@ -64,10 +65,28 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
return 0;
 }
 
+extern struct l2x0_regs l2x0_saved_regs;
+#define L2_AUX_VAL 0x7C470001
+#define L2_AUX_MASK 0xC200
+
+static int exynos_l2x0_init(void)
+{
+   exynos_smc(SMC_CMD_L2X0SETUP1, l2x0_saved_regs.tag_latency,
+   l2x0_saved_regs.data_latency,
+   l2x0_saved_regs.prefetch_ctrl);
+   exynos_smc(SMC_CMD_L2X0SETUP2, l2x0_saved_regs.pwr_ctrl,
+   L2_AUX_VAL, L2_AUX_MASK);
+   exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+   exynos_smc(SMC_CMD_L2X0CTRL, 1, 0, 0);
+   return 0;
+}
+
+
 static const struct firmware_ops exynos_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr  = exynos_set_cpu_boot_addr,
.cpu_boot   = exynos_cpu_boot,
+   .l2x0_init  = exynos_l2x0_init,
 };
 
 void __init exynos_firmware_init(void)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index efc5cab..7367bef 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -29,6 +29,7 @@
 #include asm/cp15.h
 #include asm/cputype.h
 #include asm/hardware/cache-l2x0.h
+#include asm/firmware.h
 #include cache-tauros3.h
 #include cache-aurora-l2.h
 
@@ -1504,6 +1505,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
if (data-of_parse)
data-of_parse(np, aux_val, aux_mask);
 
+   call_firmware_op(l2x0_init);
+
if (cache_id_part_number_from_dt)
cache_id = cache_id_part_number_from_dt;
else
-- 
1.9.1

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/27/2014 11:03 PM, Santosh Shilimkar wrote:

On Tuesday 27 May 2014 04:34 PM, Tony Lindgren wrote:

* Daniel Lezcano daniel.lezc...@linaro.org [140523 13:53]:

On 23 May 2014 20:32, Tony Lindgren t...@atomide.com wrote:


* Tony Lindgren t...@atomide.com [140523 07:45]:

* Tobias Jakobi tjak...@math.uni-bielefeld.de [140519 14:19]:


But even if I don't connect via WiFi at all, just boot and let me

system

run with serial console connected, after some time I get a kernel

'WARNING':

http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log


BTW, care to update the bugzilla page with the second warning
in this log?

That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
at 238 seconds.


Also, with Santosh's fix applied, can you also try disabling one
or more of the idle states for cpuidle and see if that helps?

Something like this patch below. If that helps with the WARNING
above you're getting it narrows down the problem down quite a bit.

Regards,

Tony

--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
 .mpu_state = PWRDM_POWER_RET,
 .mpu_logic_state = PWRDM_POWER_RET,
 },
+#if 0
 {
 .cpu_state = PWRDM_POWER_OFF,
 .mpu_state = PWRDM_POWER_RET,
 .mpu_logic_state = PWRDM_POWER_OFF,
 },
+#endif



Hmm, I am afraid that will lead to a fault. Safer to set the state_count =
2 instead.


Hmm don't we have state_count = ARRAY_SIZE(omap4_idle_data) or am I
missing something?


I don't think you are missing anything. The change should work.


Oh, yes. Sorry, over-sighted that. I am too used with the other drivers 
assigning the state_count with a number.



--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/16/2014 11:29 PM, Tony Lindgren wrote:

* Santosh Shilimkar santosh.shilim...@ti.com [140516 06:43]:

Tony,

On Thursday 15 May 2014 02:29 PM, Santosh Shilimkar wrote:

On Thursday 15 May 2014 01:54 PM, Santosh Shilimkar wrote:

On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:

On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:


[..]


With above mentioned change, it should work. Other alternatives is OMAP4 driver 
does
its won registration where it can start the timer. The way it was before the
consolidation.

Ofcourse if you have better fix, then great.


What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.

Do let me know.


Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda ES 
to hang.


The hang is definitely due to the bctimer not started. As I said, I assumed it 
was and
then you corrected saying it is under the flag.


I am not convinced the culprit is this code you are trying to revert.


fair enough. Thats why I said if you have an alternative fix thats great.


For record, below is updated patch with bctimer started which
was missed in earlier version. I haven't tested it though.

Alex,
Please give a try with your test-case and see if you still see the hang.
Am just curious about your issue and hence the request..


Alex tested below patch and he don't see the hang so the patch is
addressing the issue.

If Daniel works out an alternate fix to avoid reverts, that will be great
but if not, we should merge the below patch. I let you take call on it.


Daniel any news on this?

And just to recap, this problem can be reproduced with current
Linux next with omap2plus_defconfig with CONFIG_CPU_IDLE enabled. The
system should hang during the boot at some point.


I can take the time to investigate a bit more but not right now. What is 
your deadline before committing the reverts ?



And for the record, the omap3 hang fix is now posted to the lists as
[PATCH] ARM: OMAP2+: Fix DMA hang after off-idle. This should not
have anything to do with the omap4 cpu_idle hang as omap4 does not
currently lose context during idle.



--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/19/2014 07:51 PM, Tony Lindgren wrote:

* Santosh Shilimkar santosh.shilim...@ti.com [140519 10:35]:

On Monday 19 May 2014 01:23 PM, Tony Lindgren wrote:

* Daniel Lezcano daniel.lezc...@linaro.org [140519 09:46]:

On 05/16/2014 11:29 PM, Tony Lindgren wrote:


And just to recap, this problem can be reproduced with current
Linux next with omap2plus_defconfig with CONFIG_CPU_IDLE enabled. The
system should hang during the boot at some point.


I can take the time to investigate a bit more but not right now. What is
your deadline before committing the reverts ?


Well we do have several automated build and boot systems failing
because of this with multi_v7_defconfig. And users are complaining,
see this report from Tobias Jakobi:

https://bugzilla.kernel.org/show_bug.cgi?id=75421

It seems that doing the revert is not enough based on the
page above.


Thats not true. The above link used the half patch and not the
updated patch. Updated patch worked for Alex also. As you can
see they saw RCU stalls and they go away after the updated patch.

Can you please point them to try out the updated patch ?


OK good point. I added a link to the updated patch in
bugzilla.


I'd prefer we'd fix this issue properly for sure, it seems that
we're not quite understanding what's going on. And this might
hit other platforms too when they start implementing deeper
PM idle states in the mainline kernel.


I am certain that the updated patch fixed the regression
for sure. The issue is really not generic enough since its related
an OMAP ROM errata which needs that special handling of
interrupt re-trigger etc. You don't need that for other platforms
so they are not likely get affected.


OK makes sense to me considering the ROM code. Daniel, are you OK
with that or do you still want to investigate further?


For the moment I am a bit short in time for some other tasks. So feel 
free to apply the revert and I will look for a proper fix when I will 
have time.


Thanks
  -- Daniel


--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/19/2014 09:36 PM, Tony Lindgren wrote:

* Daniel Lezcano daniel.lezc...@linaro.org [140519 11:07]:

On 05/19/2014 07:51 PM, Tony Lindgren wrote:

* Santosh Shilimkar santosh.shilim...@ti.com [140519 10:35]:

On Monday 19 May 2014 01:23 PM, Tony Lindgren wrote:

* Daniel Lezcano daniel.lezc...@linaro.org [140519 09:46]:

On 05/16/2014 11:29 PM, Tony Lindgren wrote:


And just to recap, this problem can be reproduced with current
Linux next with omap2plus_defconfig with CONFIG_CPU_IDLE enabled. The
system should hang during the boot at some point.


I can take the time to investigate a bit more but not right now. What is
your deadline before committing the reverts ?


Well we do have several automated build and boot systems failing
because of this with multi_v7_defconfig. And users are complaining,
see this report from Tobias Jakobi:

https://bugzilla.kernel.org/show_bug.cgi?id=75421

It seems that doing the revert is not enough based on the
page above.


Thats not true. The above link used the half patch and not the
updated patch. Updated patch worked for Alex also. As you can
see they saw RCU stalls and they go away after the updated patch.

Can you please point them to try out the updated patch ?


OK good point. I added a link to the updated patch in
bugzilla.


I'd prefer we'd fix this issue properly for sure, it seems that
we're not quite understanding what's going on. And this might
hit other platforms too when they start implementing deeper
PM idle states in the mainline kernel.


I am certain that the updated patch fixed the regression
for sure. The issue is really not generic enough since its related
an OMAP ROM errata which needs that special handling of
interrupt re-trigger etc. You don't need that for other platforms
so they are not likely get affected.


OK makes sense to me considering the ROM code. Daniel, are you OK
with that or do you still want to investigate further?


For the moment I am a bit short in time for some other tasks. So feel free
to apply the revert and I will look for a proper fix when I will have time.


Added Tobias to Cc. At the bugzilla link Tobias is saying
he used the right patch from Santosh to test and it still
fails.


So apparently Santosh, Kevin and Alex say they are not facing the issue 
anymore with the revert. But Tobias is still facing this issue.


There is this simple program [1] which usually makes cpuidle to hang the 
system more quickly when there is a problem somewhere. May be worth to 
check with it.


Hope that helps.

  -- Daniel

[1] 
https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c


--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

--
To unsubscribe from this list: send the line unsubscribe 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: RCU stall on panda

[Daniel Lezcano]

On 05/15/2014 10:44 AM, Alex Shi wrote:

On 05/13/2014 11:32 PM, Tony Lindgren wrote:

* Alex Shi alex@linaro.org [140512 23:37]:

On 05/13/2014 05:21 AM, Tony Lindgren wrote:

* Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]:

On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote:

I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest 
upstream kernel
and google find some one report it before: https://lkml.org/lkml/2012/9/20/519

Is it the hardware issue or a real software problem?


I cannot distinguish between hardware and software from the trace below,
but given that you are also seeing a soft lockup, either way you do
appear to have a real problem as opposed to an RCU CPU stall warning
false positive.


Looks like you have CPU_IDLE enabled on panda. Hangs with current linux
next with CPU_IDLE are currently being discussed on the linux-omap list
in thread omap4-panda-es boot issues with v3.15-rc4

I've seen occasional system hangs, and I've also noticed that doing
ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system
producing similar errors to the below.



Thanks a lot for the info.
In fact, the oops keeps in upstream kernel from 3.10 to latest.


Care to test if the revert of commit cb7094 Santosh posted as
[PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
solves the problem for you?



After enable this patch, system maybe hang in idle. :(


Hi Alex,

do you mean even with this revert applied, the board hangs in idle ?




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:

Daniel,

On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:

On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:

On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:

On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:

On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---


[ ... ]



+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();

+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);


[ ... ]



Shouldn't the broadcast timer to be setup with CLOCK_EVT_NOTIFY_BROADCAST_ON 
also ?


Which is already taken care by __cpuidle_register_driver(). Note that setup code
is still used from generic code...


Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle framework 
won't setup the timer.


I see. I assumed it was taken care. So we might have setup the timer too.


static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{

 ...

 for (i = drv-state_count - 1; i = 0 ; i--) {
 if (drv-states[i].flags  CPUIDLE_FLAG_TIMER_STOP) {

May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
or 'CPUIDLE_FLAG_COUPLED'

 drv-bctimer = 1;
 break;
 }
 }

 ...

}

static int __cpuidle_register_driver(struct cpuidle_driver *drv)
{
 ...

 if (drv-bctimer)
 on_each_cpu_mask(drv-cpumask,
 cpuidle_setup_broadcast_timer,
  (void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);

 ...
}

So the broadcast timer does not operate with this revert. Moreover, I am not 
sure reverting this patch is the right solution.


With above mentioned change, it should work. Other alternatives is OMAP4 driver 
does
its won registration where it can start the timer. The way it was before the
consolidation.

Ofcourse if you have better fix, then great.


What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.

Do let me know.


Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the 
panda ES to hang.


I am not convinced the culprit is this code you are trying to revert.

I will try to reproduce the bug on my board.

--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
  arch/arm/mach-omap2/cpuidle44xx.c |   12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..3e169d9 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
  #include linux/cpuidle.h
  #include linux/cpu_pm.h
  #include linux/export.h
+#include linux/clockchips.h

  #include asm/cpuidle.h
  #include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
  {
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+   int cpu_id = smp_processor_id();

/*
 * CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
 (cx-mpu_logic_state == PWRDM_POWER_OFF);

+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();

+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
  fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -189,8 +195,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +204,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
.exit_latency = 460 + 518,
.target_residency = 1100,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C3,
.desc = CPUx OFF, MPUSS OSWR,


Shouldn't the broadcast timer to be setup with 
CLOCK_EVT_NOTIFY_BROADCAST_ON also ?




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Daniel Lezcano]

On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:

On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:

On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---


[ ... ]



+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
   /*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
   if (dev-cpu == 0  mpuss_can_lose_context)
   cpu_cluster_pm_exit();

+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);


[ ... ]



Shouldn't the broadcast timer to be setup with CLOCK_EVT_NOTIFY_BROADCAST_ON 
also ?


Which is already taken care by __cpuidle_register_driver(). Note that setup code
is still used from generic code...


Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle 
framework won't setup the timer.


static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{

...

for (i = drv-state_count - 1; i = 0 ; i--) {
if (drv-states[i].flags  CPUIDLE_FLAG_TIMER_STOP) {
drv-bctimer = 1;
break;
}
}

...

}

static int __cpuidle_register_driver(struct cpuidle_driver *drv)
{
...

if (drv-bctimer)
on_each_cpu_mask(drv-cpumask,
cpuidle_setup_broadcast_timer,
 (void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);

...
}

So the broadcast timer does not operate with this revert. Moreover, I am 
not sure reverting this patch is the right solution.


--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

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

Re: [PATCH v3 0/5] Add support for SW babble Control

[Daniel Mack]

Hi George,

On 05/13/2014 10:31 AM, George Cherian wrote:
 Series add support for SW babble control logic found in 
 new silicon versions of AM335x. Runtime differentiation of
 silicon version is done by checking the BABBLE_CTL register.
 For newer silicon the register default value read is 0x4 and
 for older versions its 0x0.

I tested this on a AM33xx platform and don't see any regression at
least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
Anything particular you want me to test as well?


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 v3 0/5] Add support for SW babble Control

[Daniel Mack]

On 05/13/2014 01:57 PM, George Cherian wrote:
 On 5/13/2014 3:16 PM, Daniel Mack wrote:
 On 05/13/2014 10:31 AM, George Cherian wrote:
 Series add support for SW babble control logic found in
 new silicon versions of AM335x. Runtime differentiation of
 silicon version is done by checking the BABBLE_CTL register.
 For newer silicon the register default value read is 0x4 and
 for older versions its 0x0.
 I tested this on a AM33xx platform and don't see any regression at
 least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
 Anything particular you want me to test as well?
 Are you seeing a wrapper restart done always or does it continue with a 
 restart
 after the babble condition?

MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
(babble_ctl  MUSB_BABBLE_STUCK_J) is false, and hence
sw_babble_control() returns 1. Consequently, the glue is fully reset in
this case. Does this help?

FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:

[   54.066124] CAUTION: musb: Babble Interrupt Occurred
[   54.071856] usb 1-1: USB disconnect, device number 8
[   54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
[   54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


I only have one exact USB device to reproduce the babble condition, so I
guess this is all I can do for now.


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 v3 0/5] Add support for SW babble Control

[Daniel Mack]

Hi George,

On 05/13/2014 02:57 PM, George Cherian wrote:
 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
 can you try with the following patch.
 
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
   val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 - if (val == MUSB_BABBLE_RCV_DISABLE)
 + if (val == MUSB_BABBLE_RCV_DISABLE) {
   glue-sw_babble_enabled = true;
 + val |= MUSB_BABBLE_SW_SESSION_CTRL;
 + dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 + }
   
   ret = dsps_musb_dbg_init(musb, glue);
   if (ret)

MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?


[   19.672373] CAUTION: musb: Babble Interrupt Occurred
[   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[   19.685815] usb 1-1: USB disconnect, device number 3
[   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?

Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?


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 v3 0/5] Add support for SW babble Control

[Daniel Mack]

On 05/13/2014 03:24 PM, George Cherian wrote:
 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without an 
 IP reset .
 2) Babble condition - which could be recovered from only by doing an IP 
 reset.

Ok, thanks for the explanation.

 Looks like you are always hitting case 2 (Most times am also hitting the 
 same).

Seems like, yes.

 There is no 100% reliable method to force it to happen. Following is
 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble interrupt
 on both connects and disconnects ( Not always though).

I also get them at disconnects, but only with one specific USB device.

But as I don't ever see case 1) above, I can't say if your approach
works. What I can say, though, is that your patches don't break the
recovery from babble conditions that I experienced :)


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

Re: [PATCH v2 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.

[Daniel Mack]

Hi Geroge,

On 05/08/2014 11:35 AM, George Cherian wrote:
 -static inline void musb_platform_reset(struct musb *musb)
 +static inline int  musb_platform_reset(struct musb *musb)
  {
 - if (musb-ops-reset)
 - musb-ops-reset(musb);
 + if (!musb-ops-reset)
 + return -EINVAL;
 +
 + return musb-ops-reset(musb);
  }
  
  static inline int musb_platform_get_vbus_status(struct musb *musb)
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 74c4193..8438200 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
   return 0;
  }
  
 -static void dsps_musb_reset(struct musb *musb)
 +static int dsps_musb_reset(struct musb *musb)
  {
   struct device *dev = musb-controller;
   struct dsps_glue *glue = dev_get_drvdata(dev-parent);
 @@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
   usleep_range(100, 200);
   usb_phy_init(musb-xceiv);
  
 + return 1;

Could we follow the general kernel rule here and return 0 for success,
and  0 on failure?



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

[PATCH RESEND] mmc: omap_hsmmc: support more DT properties

[Daniel Mack]

This should probably be done implicitly through mmc_of_parse(), but that
doesn't play well along with the multi-slot model the hsmmc driver
features. Hence, for now, do it manually. The properties are already
documented in Documentation/devicetree/bindings/mmc/mmc.txt.

Signed-off-by: Daniel Mack zon...@gmail.com
Acked-by: Balaji T K balaj...@ti.com
---
This is a resend of a patch that was already acked by Balaji T K:

  http://www.spinics.net/lists/linux-mmc/msg25029.html


 drivers/mmc/host/omap_hsmmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2815de6..a5a38cc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-hs-handling, NULL))
pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
+   if (of_find_property(np, keep-power-in-suspend, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER;
+
+   if (of_find_property(np, enable-sdio-wakeup, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
return pdata;
 }
 #else
-- 
1.8.5.3

--
To unsubscribe from this list: send the line unsubscribe 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] mmc: omap_hsmmc: support more DT properties

[Daniel Mack]

On 02/18/2014 03:36 PM, Balaji T K wrote:
 On Monday 17 February 2014 05:06 PM, Daniel Mack wrote:
 This should probably be done implicitly through mmc_of_parse(), but that
 doesn't play well along with the multi-slot model the hsmmc driver
 features. Hence, for now, do it manually. The properties are already
 documented in Documentation/devicetree/bindings/mmc/mmc.txt.

 Signed-off-by: Daniel Mack zon...@gmail.com
 
 looks good to me
 Acked-by: Balaji T K balaj...@ti.com

Thanks for the review! Did it land in any tree yet?


Best regards,
Daniel

 ---
   drivers/mmc/host/omap_hsmmc.c | 6 ++
   1 file changed, 6 insertions(+)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 2815de6..a5a38cc 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
 *of_get_hsmmc_pdata(struct device *dev)
  if (of_find_property(np, ti,needs-special-hs-handling, NULL))
  pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;

 +if (of_find_property(np, keep-power-in-suspend, NULL))
 +pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER;
 +
 +if (of_find_property(np, enable-sdio-wakeup, NULL))
 +pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
 +
  return pdata;
   }
   #else

 

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

[PATCH] mmc: omap_hsmmc: support more DT properties

[Daniel Mack]

This should probably be done implicitly through mmc_of_parse(), but that
doesn't play well along with the multi-slot model the hsmmc driver
features. Hence, for now, do it manually. The properties are already
documented in Documentation/devicetree/bindings/mmc/mmc.txt.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/mmc/host/omap_hsmmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2815de6..a5a38cc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-hs-handling, NULL))
pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
+   if (of_find_property(np, keep-power-in-suspend, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER;
+
+   if (of_find_property(np, enable-sdio-wakeup, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
return pdata;
 }
 #else
-- 
1.8.5.3

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

Re: AM335x USB DMA seems broken on ISOC URBs

[Daniel Mack]

On 01/18/2014 04:12 PM, Daniel Mack wrote:
 On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
 On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:

 While doing some experiments with the stk1160 driver (for Easycap TV video
 capture devices), ran into problems using v3.13-rc4. The problem is that the
 stk1160 IRQ handler receives no URBs at all.

[...]

 Let me know if you find anything - I hope to find some time to do
 similar tests on AM33xx based hardware.

I tried using an USB headset connected to a AM33xx based board, using
kernel v3.13.

The good news is that aplay gives me sound, so there's nothing generally
wrong with isochronous streams on musb_dsps/cppi41.

I can also do some simple 'arecord | aplay' loopback, and I can hear the
microphone signal, but the stream breaks down after a couple of seconds,
showing the following error:

[  433.671757] ALSA sound/core/pcm_lib.c:1945 capture write error (DMA
or IRQ trouble?)

Also, when tearing down the aplay stream, the cppi41 driver spits a
number of the warnings below.

Sebastian, do you have any pending patches that might be worth testing?



Thanks,
Daniel



[  340.255651] [ cut here ]
[  340.262828] WARNING: CPU: 0 PID: 112 at drivers/dma/cppi41.c:605
cppi41_dma_control+0x2a8/0x2d4()
[  340.272086] Modules linked in:
[  340.287140] CPU: 0 PID: 112 Comm: aplay Tainted: GW
3.13.0-00051-gff62d1c #1661
[  340.295798] [c00137b8] (unwind_backtrace+0x0/0xf4) from
[c001158c] (show_stack+0x10/0x14)
[  340.304712] [c001158c] (show_stack+0x10/0x14) from [c0037154]
(warn_slowpath_common+0x6c/0x84)
[  340.314070] [c0037154] (warn_slowpath_common+0x6c/0x84) from
[c0037208] (warn_slowpath_null+0x1c/0x24)
[  340.324153] [c0037208] (warn_slowpath_null+0x1c/0x24) from
[c02b50d8] (cppi41_dma_control+0x2a8/0x2d4)
[  340.334255] [c02b50d8] (cppi41_dma_control+0x2a8/0x2d4) from
[c0375f0c] (cppi41_dma_channel_abort+0xcc/0)
[  340.344976] [c0375f0c] (cppi41_dma_channel_abort+0xcc/0x140) from
[c037187c] (musb_cleanup_urb.isra.16+0)
[  340.356147] [c037187c] (musb_cleanup_urb.isra.16+0x58/0x11c) from
[c0371b80] (musb_urb_dequeue+0xe8/0x12)
[  340.366595] [c0371b80] (musb_urb_dequeue+0xe8/0x128) from
[c035aa74] (unlink1+0x2c/0x110)
[  340.375497] [c035aa74] (unlink1+0x2c/0x110) from [c035b2e0]
(usb_hcd_unlink_urb+0x50/0xc4)
[  340.384496] [c035b2e0] (usb_hcd_unlink_urb+0x50/0xc4) from
[c03db53c] (deactivate_urbs+0xd8/0xf4)
[  340.394126] [c03db53c] (deactivate_urbs+0xd8/0xf4) from
[c03dc614] (snd_usb_endpoint_stop+0x30/0x70)
[  340.404032] [c03dc614] (snd_usb_endpoint_stop+0x30/0x70) from
[c03e3d40] (stop_endpoints+0x70/0x88)
[  340.413843] [c03e3d40] (stop_endpoints+0x70/0x88) from [c03e3ea0]
(snd_usb_substream_playback_trigger+0x)
[  340.424836] [c03e3ea0]
(snd_usb_substream_playback_trigger+0x9c/0xb8) from [c03cdb40]
(snd_pcm_do_stop+0)
[  340.435917] [c03cdb40] (snd_pcm_do_stop+0x54/0x58) from
[c03cd768] (snd_pcm_action_single+0x38/0x78)
[  340.445816] [c03cd768] (snd_pcm_action_single+0x38/0x78) from
[c03cd970] (snd_pcm_drop+0x6c/0xc4)
[  340.455443] [c03cd970] (snd_pcm_drop+0x6c/0xc4) from [c03cf22c]
(snd_pcm_common_ioctl1+0xc90/0x109c)
[  340.465344] [c03cf22c] (snd_pcm_common_ioctl1+0xc90/0x109c) from
[c03cf7f0] (snd_pcm_playback_ioctl1+0x1)
[  340.476434] [c03cf7f0] (snd_pcm_playback_ioctl1+0x1b8/0x4b0) from
[c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0)
[  340.486607] [c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0) from [c00e7cc4]
(SyS_ioctl+0x70/0x80)
[  340.495331] [c00e7cc4] (SyS_ioctl+0x70/0x80) from [c000e340]
(ret_fast_syscall+0x0/0x48)
[  340.504136] ---[ end trace 521a83c0d2567bbb ]---


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

Re: AM335x USB DMA seems broken on ISOC URBs

[Daniel Mack]

Hi Ezequiel,

On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
 On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:
 Hello,

 While doing some experiments with the stk1160 driver (for Easycap TV video
 capture devices), ran into problems using v3.13-rc4. The problem is that the
 stk1160 IRQ handler receives no URBs at all.

 When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the
 bandwidth requirements are too large for PIO (it's a raw video device) and 
 the
 video can't get captured.

 Interesting enough, using an old backported for v3.2 stk1160 driver, this 
 same
 setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in
 either the cppi41 dmaengine or the musb.

 I tried to compare the PSP to the mainline drivers but they seems *very*
 different and really beyond my understanding.

 Any ideas on how can I help debugging this?

 
 Ping? It would be good to hunt thig bug down. The TI PSP provided USB driver
 works fine so at least that's a starting point...
 

Did you try this with a different type of peripheral hardware, a USB
audio device for example? You could also check whether the packets are
actually received by the DMA driver but dropped before the USB subsys
gets to see them for whatever reason.

Let me know if you find anything - I hope to find some time to do
similar tests on AM33xx based hardware.


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

[SOLVED] Re: Cannot obtain needed commit when trying to clone?

[Daniel Santos]

oops, I'm very sorry. I had the wrong URL. Problem solved!

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

Cannot obtain needed commit when trying to clone?

[Daniel Santos]

Hey guys. I'm trying to grab v2.6.32.60 from 
http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git and 
I'm getting this sad little error:


# git clone --reference /mnt/gentoo32/usr/src/linux-2.6.32.y --branch 
v2.6.32.60 
http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git 
linux-omap-2.6.32.y

Cloning into 'linux-omap-2.6.32.y'...
error: Unable to find 811e7c87340b75dce5c488d9496075b00853942b under 
http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git

Cannot obtain needed commit 811e7c87340b75dce5c488d9496075b00853942b
while processing commit e942cc06e2d183975dd47d8da9e569316cb870ea.
error: Fetch failed.

Tried w/o a --reference and also tried to grab master, similar error:

# git clone 
http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git linux-omap

Cloning into 'linux-omap'...
error: Unable to find 8bb9660418e05bb1845ac1a2428444d78e322cc7 under 
http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git

Cannot obtain needed object 8bb9660418e05bb1845ac1a2428444d78e322cc7
while processing commit 9556974843c5a75c98a5e070c80b5bf7c304c85d.
error: Fetch failed.

Is there some type of server maintenance going on or is something 
broken? Any other clones out there where I can grab this from in the 
mean time?


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 v7] ARM: omap: edma: add suspend suspend/resume hooks

[Daniel Mack]

On 11/29/2013 09:08 AM, Brian Murphy wrote:
 On 11/27/2013 02:56 PM, Daniel Mack wrote:
 This patch makes the edma driver resume correctly after suspend. Tested
 on an AM33xx platform with cyclic audio streams and omap_hsmmc.
 
 Can I ask which git this patch is relative to? There is no
 suspend/resume support for AM33xx in Linus Torvalds kernel as far as I 
 can see.

I am based on 3.13-rc1 with some patches from Suman Anna, Vaibhav Bedia
and Dave Gerlach that have been posted on arm-linux some month ago.

This patch can be merged independently as it has no dependency on those.

We already did the same for cppi41, musb, mcasp and some other drivers,
which gradually learn support for suspend in mainline now. Only the core
bits are missing, but I'm sure someone from TI is pushing them forward :)


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] ARM: omap: edma: add suspend suspend/resume hooks

[Daniel Mack]

On 11/27/2013 02:22 PM, Sekhar Nori wrote:
 + Kevin
 
 On Monday 25 November 2013 11:04 PM, Joel Fernandes wrote:
 On 11/17/2013 04:19 PM, Daniel Mack wrote:
 This patch makes the edma driver resume correctly after suspend. Tested
 on an AM33xx platform with cyclic audio streams and omap_hsmmc.

 All information can be reconstructed by already known runtime
 information.

 As we now use some functions that were previously only used from __init
 context, annotations had to be dropped.

 [n...@ti.com: added error handling for runtime + suspend_late/early_resume]
 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Daniel Mack zon...@gmail.com
 Tested-by: Joel Fernandes jo...@ti.com
 Acked-by: Joel Fernandes jo...@ti.com

 Hi Sekhar,

 Can you consider pulling this patch? It has been tested and Acked. Thanks.
 
 Kevin had some inputs on previous version of this patch. Were you able
 to make sure he is okay with this version being merged?

I had concerns about the feedback I got, and haven't got answers yet.

In particular, I'm not convinced that using runtime PM to suspend
channels would actually save any power during runtime, or have any other
benefit. But I might be wrong - maybe someone at TI could comment on that?


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] ARM: omap: edma: add suspend suspend/resume hooks

[Daniel Mack]

Hi Sekhar,

On 11/27/2013 02:35 PM, Sekhar Nori wrote:
 On Monday 18 November 2013 03:49 AM, Daniel Mack wrote:

 +static int edma_pm_suspend(struct device *dev)
 +{
 +int j, r;
 +
 +r = pm_runtime_get_sync(dev);
 +if (IS_ERR_VALUE(r)) {
 
 So IS_ERR_VALUE() is only for functions which may return a negative
 number outside of MAX_ERRNO as a success indication.
 pm_runtime_get_sync() does not appear to be one of them so just use

 if (r  0) { .. }

That's true. Thanks for catching this, I'll fix it. However, grepping
through the tree, there are quite a lot places where the same mistake is
made.

 +/* Map the channel to param entry if channel mapping logic
 + * exist
 + */
 
 Please follow the multi-line commenting style.

Can do. However, these lines in fact follow the style that is used
throughout the entire file ;)

 There are some checkpatch checks that result from lines like this.
 Please fix these as well.
 
 CHECK: Alignment should match open parenthesis
 #179: FILE: arch/arm/common/edma.c:1841:
 + map_queue_tc(j, queue_tc_mapping[i][0],
 + queue_tc_mapping[i][1]);

If you say so, even though I disagree with checkpatch.pl here. The above
is actually more readable, right? :)


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

[PATCH v7] ARM: omap: edma: add suspend suspend/resume hooks

[Daniel Mack]

This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

[n...@ti.com: added error handling for runtime + suspend_late/early_resume]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Daniel Mack zon...@gmail.com
Tested-by: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
v6 - v7:

 * Addressed comments from Sekhar Nori:

   * pm_runtime_get_sync() returns negative errors, so do not use
 IS_ERR_VALUE()
   * Several style fixes


 arch/arm/common/edma.c | 95 --
 1 file changed, 92 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 41bca32..dece66d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -239,6 +239,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -290,13 +292,13 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
+static void map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
 {
int bit = queue_no * 4;
edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7  bit), ((tc_no  0x7)  bit));
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -315,7 +317,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1785,15 +1787,102 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (r  0) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *ecc = edma_cc[j];
+
+   disable_irq(ecc-irq_res_start);
+   disable_irq(ecc-irq_res_end);
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (r  0) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+   s8 (*queue_tc_mapping)[2];
+
+   queue_tc_mapping = cc-info-queue_tc_mapping;
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue to TC mapping */
+   for (i = 0; queue_tc_mapping[i][0] != -1; i++)
+   map_queue_tc(j, queue_tc_mapping[i][0],
+queue_tc_mapping[i][1]);
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+queue_priority_mapping[i][0],
+queue_priority_mapping[i][1]);
+
+   /*
+* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++) {
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+  BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i

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

[Daniel Mack]

On 11/26/2013 11:50 AM, Sergei Shtylyov wrote:
 On 25-11-2013 23:39, Daniel Mack wrote:
 
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.
 
 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 [...]
 
 diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
 index eb50525..e5a581c 100644
 --- a/include/linux/usb/musb.h
 +++ b/include/linux/usb/musb.h
 @@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
  /* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
  u8  mode;

 +/* should the musb core restore registers after suspend? */
 +u8  restore_after_suspend:1;
 +
 
 Better placement seems to be with 'extvbus' field which is also 1-bit -- 
 that would save space in the structure.

That patch is deprecated, as things are now done unconditionally,
without consulting this flag.


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

Re: [PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 10:32 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 10:30:37PM +0100, Daniel Mack wrote:
 On 11/25/2013 10:29 PM, Felipe Balbi wrote:
 Hi,

 On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
 +static int dsps_resume(struct device *dev)
 +{
 +  struct dsps_glue *glue = dev_get_drvdata(dev);
 +  const struct dsps_musb_wrapper *wrp = glue-wrp;
 +  struct musb *musb = platform_get_drvdata(glue-musb);
 +  void __iomem *mbase = musb-ctrl_base;
 +
 +  dsps_writel(mbase, wrp-control, glue-context.control);
 +  dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +  dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +  dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +  dsps_writel(mbase, wrp-mode, glue-context.mode);
 +  dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +  dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +  //musb_port_reset(musb, false);

 


 Urgs. Development left-over. Sorry. You want me to resend the whole
 series or just this last patch?
 
 just the last patch is fine :-)

Sorry, there was one more hunk that shouldn't be there. I'll resend a v4
with all the patches included again, for reference.

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

[PATCH v4 0/4] musb/dsps: suspend related patches for 3.14 (rebased)

[Daniel Mack]

v2 - v3:
 * removed a development left-over

v3 - v4:
 * one hunk removed that sneaked in during rebasing


Daniel Mack (4):
  usb: musb: unconditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume

 drivers/usb/musb/musb_core.c| 14 +-
 drivers/usb/musb/musb_dsps.c| 61 +
 drivers/usb/musb/musb_host.c|  9 +-
 drivers/usb/musb/musb_host.h|  4 +++
 drivers/usb/musb/musb_virthub.c |  4 +--
 include/linux/usb/musb.h|  3 ++
 6 files changed, 91 insertions(+), 4 deletions(-)

-- 
1.8.4.2

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

[PATCH v4 4/4] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to explicitly de-assert the port reset upon resume on this
platform, but musb_port_reset() should not be called from glue layers.

Hence, introduce a flag in struct musb_hdrc_config for this.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c| 57 +
 drivers/usb/musb/musb_host.c|  7 -
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 include/linux/usb/musb.h|  3 +++
 5 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..3600af0 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -509,6 +524,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
+   config-host_port_deassert_reset_at_resume = 1;
pdata.mode = get_musb_port_mode(dev);
/* DT keeps this entry in mA, musb expects it as per USB spec */
pdata.power = get_int_prop(dn, mentor,power) / 2;
@@ -632,11 +648,52 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 81caf9f..8224138 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2464,7 +2464,12 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
 
 static int musb_bus_resume(struct usb_hcd *hcd)
 {
-   /* resuming child port does the work */
+   struct musb *musb = hcd_to_musb(hcd);
+
+   if (musb-config 
+   musb-config-host_port_deassert_reset_at_resume)
+   musb_port_reset(musb, false);
+
return 0;
 }
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void

[PATCH v4 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.2

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

[PATCH v4 1/4] usb: musb: unconditionally save and restore the context on suspend

[Daniel Mack]

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

The dsps platform does, however, and because it should cause any trouble
on other platforms, do it unconditionally.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..797709d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2215,16 +2215,28 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* For the DSPS glue layer though, a full register restore has to
+* be done. As it shouldn't harm other platforms, we do it
+* unconditionally.
 */
+
+   musb_restore_context(musb);
+
return 0;
 }
 
-- 
1.8.4.2

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

[PATCH v4 3/4] usb: musb: dsps: add {tx,rx}_mode to wrapper

[Daniel Mack]

rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.2

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

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

[Daniel Mack]

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

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

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 17 -
 include/linux/usb/musb.h |  3 +++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..a8ded57 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
 {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
spin_lock_irqsave(musb-lock, flags);
 
@@ -2215,16 +2216,30 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   if (plat-restore_after_suspend)
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
 */
+
+   if (plat-restore_after_suspend)
+   musb_restore_context(musb);
+
return 0;
 }
 
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..e5a581c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
+   /* should the musb core restore registers after suspend? */
+   u8  restore_after_suspend:1;
+
/* for clk_get() */
const char  *clock;
 
-- 
1.8.4.2

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

[PATCH 0/5] musb/dsps: suspend related patches for 3.14 (rebased)

[Daniel Mack]

Hi Felipe,

These five patches for musb/dsps didn't make it into 3.13, which is no
big deal, at least as far as I'm concerned :)

I rebased the missing bits on top of 3.13-rc1. There are no functional
changes in comparison to what was posted earlier on this list.

Successfully tested on a AM33xx board.


Thanks,
Daniel


Daniel Mack (5):
  usb: musb: conditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume
  usb: musb: dsps: indentation and whitespace fixes

 drivers/usb/musb/musb_core.c| 17 +++-
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 86 +++--
 drivers/usb/musb/musb_host.c|  2 +
 drivers/usb/musb/musb_host.h|  4 ++
 drivers/usb/musb/musb_virthub.c |  4 +-
 include/linux/usb/musb.h|  3 ++
 7 files changed, 102 insertions(+), 15 deletions(-)

-- 
1.8.4.2

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

[PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to call musb_port_reset() for this platform upon resume, so
this function has to be made non-static.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 59 +
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 29f7cd7..a423037 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -295,6 +295,7 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
+
u16 hwvers;
 
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..361ddf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   musb_port_reset(musb, false);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
 extern void musb_port_suspend(struct musb *musb, bool do_suspend);
+extern void musb_port_reset(struct musb *musb, bool do_reset);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb 
*musb) {}
 static inline void musb_host_poll_rh_status(struct

[PATCH 3/5] usb: musb: dsps: add {tx,rx}_mode to wrapper

[Daniel Mack]

rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.2

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

[PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.2

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

[PATCH 5/5] usb: musb: dsps: indentation and whitespace fixes

[Daniel Mack]

Just a cosmetic thing, no functional change.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 361ddf8..b27c072 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -131,9 +131,9 @@ struct dsps_context {
 struct dsps_glue {
struct device *dev;
struct platform_device *musb;   /* child musb pdev */
-   const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
+   const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
-   unsigned long last_timer;/* last timer data for each instance */
+   unsigned long last_timer;   /* last timer data for each instance */
 
struct dsps_context context;
 };
@@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
 
dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
dsps_writel(reg_base, wrp-epintr_clear,
-wrp-txep_bitmap | wrp-rxep_bitmap);
+   wrp-txep_bitmap | wrp-rxep_bitmap);
dsps_writeb(musb-mregs, MUSB_DEVCTL, 0);
 }
 
@@ -234,7 +234,7 @@ static void otg_timer(unsigned long _musb)
 */
devctl = dsps_readb(mregs, MUSB_DEVCTL);
dev_dbg(musb-controller, Poll devctl %02x (%s)\n, devctl,
-   usb_otg_state_string(musb-xceiv-state));
+   usb_otg_state_string(musb-xceiv-state));
 
spin_lock_irqsave(musb-lock, flags);
switch (musb-xceiv-state) {
@@ -298,7 +298,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
dsps_writel(reg_base, wrp-coreintr_status, usbintr);
 
dev_dbg(musb-controller, usbintr (%x) epintr(%x)\n,
-   usbintr, epintr);
+   usbintr, epintr);
/*
 * DRVVBUS IRQs are the only proxy we have (a very poor one!) for
 * DSPS IP's missing ID change IRQ.  We need an ID change IRQ to
@@ -348,10 +348,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 
/* NOTE: this must complete power-on within 100 ms. */
dev_dbg(musb-controller, VBUS %s (%s)%s, devctl %02x\n,
-   drvvbus ? on : off,
-   usb_otg_state_string(musb-xceiv-state),
-   err ?  ERROR : ,
-   devctl);
+   drvvbus ? on : off,
+   usb_otg_state_string(musb-xceiv-state),
+   err ?  ERROR : , devctl);
ret = IRQ_HANDLED;
}
 
@@ -692,9 +691,9 @@ static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, 
dsps_resume);
 
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
-   .remove = dsps_remove,
-   .driver = {
-   .name   = musb-dsps,
+   .remove = dsps_remove,
+   .driver = {
+   .name   = musb-dsps,
.pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
-- 
1.8.4.2

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

Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 08:46 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
  struct musb *musb = hcd_to_musb(hcd);
  u8  devctl;
  
 +musb_port_suspend(musb, true);
 
 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?

 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

Well, I would have expected that, but in fact, the opposite is true.
With 3.12, mounting a filesystem on a USB media and accessing it after
resume was exactly my test case, and it worked just fine with that patch.

In 3.13, something about the parition table reading seems to be broken
currently, I'll have a closer look.


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 5/5] usb: musb: dsps: indentation and whitespace fixes

[Daniel Mack]

On 11/25/2013 08:49 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:53PM +0100, Daniel Mack wrote:
 Just a cosmetic thing, no functional change.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_dsps.c | 23 +++
  1 file changed, 11 insertions(+), 12 deletions(-)

 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 361ddf8..b27c072 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -131,9 +131,9 @@ struct dsps_context {
  struct dsps_glue {
  struct device *dev;
  struct platform_device *musb;   /* child musb pdev */
 -const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
 +const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
  struct timer_list timer;/* otg_workaround timer */
 -unsigned long last_timer;/* last timer data for each instance */
 +unsigned long last_timer;   /* last timer data for each instance */
  
  struct dsps_context context;
  };
 @@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
  
  dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
  dsps_writel(reg_base, wrp-epintr_clear,
 - wrp-txep_bitmap | wrp-rxep_bitmap);
 +wrp-txep_bitmap | wrp-rxep_bitmap);
 
 quite frankly, I don't what checkpatch.pl is trying to force here. I
 much prefer a tab-only indentation, matching with ( characters forces us
 to add some spaces. I would rather not take this patch.
 

Alright, I really don't care much. I'll drop the patch when resending.

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

Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 08:48 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:52PM +0100, Daniel Mack wrote:
 The dsps platform needs to save save some registers at suspend time and
 restore them after resume. This patch adds a struct for these registers,
 and also lets the musb core know that the core registers need to be
 saved as well.

 We also have to call musb_port_reset() for this platform upon resume, so
 this function has to be made non-static.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.h|  1 +
  drivers/usb/musb/musb_dsps.c| 59 
 +
  drivers/usb/musb/musb_host.h|  2 ++
  drivers/usb/musb/musb_virthub.c |  2 +-
  4 files changed, 63 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
 index 29f7cd7..a423037 100644
 --- a/drivers/usb/musb/musb_core.h
 +++ b/drivers/usb/musb/musb_core.h
 @@ -295,6 +295,7 @@ struct musb {
  
  irqreturn_t (*isr)(int, void *);
  struct work_struct  irq_work;
 +
  u16 hwvers;
  
  u16 intrrxe;
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index e57d712..361ddf8 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
  u8  poll_seconds;
  };
  
 +/*
 + * register shadow for suspend
 + */
 +struct dsps_context {
 +u32 control;
 +u32 epintr;
 +u32 coreintr;
 +u32 phy_utmi;
 +u32 mode;
 +u32 tx_mode;
 +u32 rx_mode;
 +};
 +
  /**
   * DSPS glue structure.
   */
 @@ -121,6 +134,8 @@ struct dsps_glue {
  const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
  struct timer_list timer;/* otg_workaround timer */
  unsigned long last_timer;/* last timer data for each instance */
 +
 +struct dsps_context context;
  };
  
  static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
 @@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
  }
  pdata.config = config;
  pdata.platform_ops = dsps_ops;
 +pdata.restore_after_suspend = 1;
  
  config-num_eps = get_int_prop(dn, mentor,num-eps);
  config-ram_bits = get_int_prop(dn, mentor,ram-bits);
 @@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] 
 = {
  };
  MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
  
 +#ifdef CONFIG_PM
 +static int dsps_suspend(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +glue-context.control = dsps_readl(mbase, wrp-control);
 +glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
 +glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
 +glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
 +glue-context.mode = dsps_readl(mbase, wrp-mode);
 +glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
 +glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
 +
 +return 0;
 +}
 +
 +static int dsps_resume(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +dsps_writel(mbase, wrp-control, glue-context.control);
 +dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +dsps_writel(mbase, wrp-mode, glue-context.mode);
 +dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +musb_port_reset(musb, false);
 +
 +return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
 +
  static struct platform_driver dsps_usbss_driver = {
  .probe  = dsps_probe,
  .remove = dsps_remove,
  .driver = {
  .name   = musb-dsps,
 +.pm = dsps_pm_ops,
  .of_match_table = musb_dsps_of_match,
  },
  };
 diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
 index e660af9..7436c24 100644
 --- a/drivers/usb/musb/musb_host.h
 +++ b/drivers/usb/musb/musb_host.h
 @@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
  extern void musb_host_resume_root_hub(struct musb *musb);
  extern void musb_host_poke_root_hub(struct musb *musb);
  extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 +extern void musb_port_reset(struct musb *musb, bool do_reset);
  #else
  static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
  {
 @@ -123,6 +124,7 @@ static inline void

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

[Daniel Mack]

On 11/25/2013 08:44 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.

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

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
  struct musb *musb = dev_to_musb(dev);
  unsigned long   flags;
 +struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
 we don't want to have platform_data on DT-based boot. It's best to just
 save those registers unconditionally as it doesn't hurt.
 

My concern about doing it unconditionally from the core is simply that I
fear regressions for other platforms. I can of course drop it if you're
certain that that's correct.

I can only test this on a dsps glue layer, and I have no documentation
for the musb core. All I'm left with here is fishing in muddy waters :/


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 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 09:01 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:46 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
  
 +  musb_port_suspend(musb, true);

 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?

 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.
 
 so you had a mounted file system, suspend, resume, it was still mounted?

Yes, exactly.

 or did it reenumerate and you remounted it ?

No, it did not reenumerate, but the core did a reset on it. See the
following log.

# mount /dev/sda /mnt
# md5sum /mnt/sine_left.wav
bcd90548c1ebf293289072f1a6161f0f  /mnt/sine_left.wav
#
#
# echo mem  /sys/power/state
[   31.553425] PM: Syncing filesystems ... done.
[   31.575462] Freezing user space processes ... (elapsed 0.002 seconds)
done.
[   31.585275] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[   31.595953] PM: Sending message for entering DeepSleep mode
[   31.628887] PM: suspend of devices complete after 21.097 msecs
[   31.641082] PM: late suspend of devices complete after 5.906 msecs
[   31.653834] PM: noirq suspend of devices complete after 6.135 msecs
[   31.660558] PM: GFX domain entered low power state
[   31.660558] PM: Successfully put all powerdomains to target state
[   31.660558] PM: Wakeup source GPIO0
[   31.679130] PM: noirq resume of devices complete after 17.941 msecs
[   31.693371] PM: early resume of devices complete after 4.388 msecs
[   31.702750] net eth0: initializing cpsw version 1.12 (0)
[   31.712084] net eth0: phy found : id is : 0x4dd076
[   31.717317] libphy: PHY  not found
[   31.722448] net eth0: phy  not found on slave 1
[   32.030792] usb 1-1: reset high-speed USB device number 2 using
musb-hdrc  !
[   32.395192] PM: resume of devices complete after 695.279 msecs
[   32.407816] PM: Sending message for resetting M3 state machine
[   32.414683] Restarting tasks ... done.
[   36.701568] libphy: 4a101000.mdio:04 - Link is Up - 100/Full
#
#
# md5sum /mnt/sine_left.wav
bcd90548c1ebf293289072f1a6161f0f  /mnt/sine_left.wav

 Try to do the same with transfers in flight, it's likely to corrupt your
 file system.

I did that as well, and it appeared stable to me. After all, the USB
device was properly put into suspend before VBUS went away, and the usb
storage driver caught up after the core's reset.

In my tests, this was the only approach that would work after resume.



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 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 09:08 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
 diff --git a/drivers/usb/musb/musb_virthub.c 
 b/drivers/usb/musb/musb_virthub.c
 index e977441..24e46c0 100644
 --- a/drivers/usb/musb/musb_virthub.c
 +++ b/drivers/usb/musb/musb_virthub.c
 @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
 do_suspend)
}
  }
  
 -static void musb_port_reset(struct musb *musb, bool do_reset)
 +void musb_port_reset(struct musb *musb, bool do_reset)

 NAK, this should not be called from the glue layers at all. If anything
 call from musb_core's resume callback. That will only be called after
 parent's resume has been called anyway.

 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.

 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?
 
 your original commit log only says we need to issue port reset but it
 never explains why. It could very well be you just found a device which
 needs to be reset when coming out of suspend and it misses a quirk flag ?

I think I can really rule that out, as I tested with multiple USB sticks
and also tested the same sticks on other embedded platforms.

 In any case, those functions should never be called by the glue, if
 reset needs to be called, it must be called by musb-hdrc.ko, if you need
 a flag, pass a flag but I need a really good explanation in your commit
 log of why that's necessary.

Well, if I'd only knew exactly why. All these patches are really the
result of many days of trial and error, with multiple drivers (musb,
cppi41, ...) involved. And as I said - I have no documentation of the
musb core itself.

So yes, I can do it the other way around and pass a flag, but what I
can't provide is a good explanantion why the dsps glue behaves
differently here than others. I'm curious myself, and all I know is that
with this reset in place, things work as expected on AM33xx.


Thanks for your feedback,
Daniel

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

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

[Daniel Mack]

On 11/25/2013 09:13 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 09:08:51PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:44 PM, Felipe Balbi wrote:
 Hi,

 On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.

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

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
 +  struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);

 we don't want to have platform_data on DT-based boot. It's best to just
 save those registers unconditionally as it doesn't hurt.


 My concern about doing it unconditionally from the core is simply that I
 fear regressions for other platforms. I can of course drop it if you're
 certain that that's correct.

 I can only test this on a dsps glue layer, and I have no documentation
 for the musb core. All I'm left with here is fishing in muddy waters :/
 
 I really don't think it should cause any issues with any other platform.
 
 We can make to leave this soaking in linux-next for a long time and hope
 people test it.
 

Ok, sounds good. I'll do it and repost, along with the other changes.


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 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 09:41 PM, Alan Stern wrote:
 On Mon, 25 Nov 2013, Daniel Mack wrote:
 
 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.

 so you had a mounted file system, suspend, resume, it was still mounted?

 Yes, exactly.

 or did it reenumerate and you remounted it ?

 No, it did not reenumerate, but the core did a reset on it. See the
 following log.
 
 ...
 [   32.030792] usb 1-1: reset high-speed USB device number 2 using
 musb-hdrc  !
 
 Like I said, you get a reset-resume.

Yup. We can't avoid losing VBUS on this platform, and even if we could,
we wouldn't want that, in order to save as much power as possible.

 Try to do the same with transfers in flight, it's likely to corrupt your
 file system.
 
 It's not so easy to suspend a system with USB mass-storage transfers in 
 flight.  For one thing, userspace gets frozen before the suspend 
 starts, so there's nothing to initiate new I/O requests (except perhaps 
 for dirty-block writebacks).
 
 Also, the child SCSI device gets suspended before the USB device, so
 its I/O queue stops running.  In addition, the usb-storage suspend
 routine and the main I/O thread are mutually exclusive (they both grab
 the private mutex), so a suspend can't occur while a SCSI command is
 underway.

Thanks Alan for the explanation. That was my understanding as well.


Best regards,
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 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

On 11/25/2013 09:01 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:

 In 3.13, something about the parition table reading seems to be broken
 currently, I'll have a closer look.
 
 cool

Ah, and forget about this one. I didn't look close enough. There's no
such issue in 3.13. Sorry for the noise.




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

Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

[Daniel Mack]

On 11/25/2013 09:46 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 09:26:55PM +0100, Daniel Mack wrote:
 On 11/25/2013 09:08 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
 diff --git a/drivers/usb/musb/musb_virthub.c 
 b/drivers/usb/musb/musb_virthub.c
 index e977441..24e46c0 100644
 --- a/drivers/usb/musb/musb_virthub.c
 +++ b/drivers/usb/musb/musb_virthub.c
 @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
 do_suspend)
  }
  }
  
 -static void musb_port_reset(struct musb *musb, bool do_reset)
 +void musb_port_reset(struct musb *musb, bool do_reset)

 NAK, this should not be called from the glue layers at all. If anything
 call from musb_core's resume callback. That will only be called after
 parent's resume has been called anyway.

 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.

 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?

 your original commit log only says we need to issue port reset but it
 never explains why. It could very well be you just found a device which
 needs to be reset when coming out of suspend and it misses a quirk flag ?

 I think I can really rule that out, as I tested with multiple USB sticks
 and also tested the same sticks on other embedded platforms.

 In any case, those functions should never be called by the glue, if
 reset needs to be called, it must be called by musb-hdrc.ko, if you need
 a flag, pass a flag but I need a really good explanation in your commit
 log of why that's necessary.

 Well, if I'd only knew exactly why. All these patches are really the
 result of many days of trial and error, with multiple drivers (musb,
 cppi41, ...) involved. And as I said - I have no documentation of the
 musb core itself.

 So yes, I can do it the other way around and pass a flag, but what I
 can't provide is a good explanantion why the dsps glue behaves
 differently here than others. I'm curious myself, and all I know is that
 with this reset in place, things work as expected on AM33xx.
 
 ok, then let's pass a flag. Meanwhile I'll try to figure out internally
 why we need that reset.

Well, we don't need a reset, I wasn't quite precise here. What we need
is to manually *de*assert the reset when we resume. Note the 'false'
flag that is passed to musb_port_reset().

 As Alan said, usb-persist should already for a
 bus-reset when resuming, right ?

The explicit un-reset is really needed, otherwise the port will
reenumerate the device, and a previously mounted filesystem will become
invalid of course. The log looks like this in that case:

[   17.045641] PM: resume of devices complete after 166.084 msecs
[   17.056461] PM: Sending message for resetting M3 state machine
[   17.063451] Restarting tasks ... [   17.071767] usb 1-1: USB
disconnect, device number 2
done.
[   17.403402] usb 1-1: new high-speed USB device number 3 using musb-hdrc
[   17.766959] usb 1-1: New USB device found, idVendor=058f, idProduct=6387
[   17.774849] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3



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

[PATCH v2 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack]

Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.2

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

[PATCH v2 1/4] usb: musb: unconditionally save and restore the context on suspend

[Daniel Mack]

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

The dsps platform does, however, and because it shouldn't cause any
trouble on other platforms, do it unconditionally for all of them.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..797709d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2215,16 +2215,28 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* For the DSPS glue layer though, a full register restore has to
+* be done. As it shouldn't harm other platforms, we do it
+* unconditionally.
 */
+
+   musb_restore_context(musb);
+
return 0;
 }
 
-- 
1.8.4.2

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

[PATCH v2 3/4] usb: musb: dsps: add {tx,rx}_mode to wrapper

[Daniel Mack]

rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.2

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