[PATCH V2] usb: musb: Fix unstable init of OTG_INTERFSEL.

[anaumann]

From: Andreas Naumann 

This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.

The fix is to initialize the value, BEFORE being written in the resume
function.


Signed-off-by: Andreas Naumann 
---
 drivers/usb/musb/omap2430.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..783547c 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -337,7 +337,6 @@ static irqreturn_t omap2430_musb_interrupt(int irq, void 
*__hci)
 
 static int omap2430_musb_init(struct musb *musb)
 {
-   u32 l;
int status = 0;
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -366,23 +365,24 @@ static int omap2430_musb_init(struct musb *musb)
 
musb->isr = omap2430_musb_interrupt;
 
+   musb->context.otg_interfsel = musb_readl(musb->mregs, OTG_INTERFSEL);
+
+   if (data->interface_type == MUSB_INTERFACE_UTMI) {
+   /* OMAP4 uses Internal PHY GS70 which uses UTMI interface */
+   musb->context.otg_interfsel &= ~ULPI_12PIN;  /* Disable ULPI */
+   musb->context.otg_interfsel |= UTMI_8BIT;/* Enable UTMI  */
+   } else {
+   musb->context.otg_interfsel |= ULPI_12PIN;
+   }
+
status = pm_runtime_get_sync(dev);
if (status < 0) {
dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
goto err1;
}
 
-   l = musb_readl(musb->mregs, OTG_INTERFSEL);
-
-   if (data->interface_type == MUSB_INTERFACE_UTMI) {
-   /* OMAP4 uses Internal PHY GS70 which uses UTMI interface */
-   l &= ~ULPI_12PIN;   /* Disable ULPI */
-   l |= UTMI_8BIT; /* Enable UTMI  */
-   } else {
-   l |= ULPI_12PIN;
-   }
 
-   musb_writel(musb->mregs, OTG_INTERFSEL, l);
+   musb_writel(musb->mregs, OTG_INTERFSEL, musb->context.otg_interfsel);
 
pr_debug("HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
"sysstatus 0x%x, intrfsel 0x%x, simenable  0x%x\n",
-- 
1.8.4.1

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

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Pali Rohár]

On Thursday 28 November 2013 01:25:50 Sebastian Reichel wrote:
> On Wed, Nov 27, 2013 at 10:16:47PM +0100, Pali Rohár wrote:
> > On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > > > 2 seems more generic to me, but as rx51-battery is
> > > > missing the functionality to send events on temperature
> > > > change, I guess 1 will be easier to implement.
> > > 
> > > The temperature must be polled anyway, if the ADC does not
> > > support interrupts.
> > 
> > Yes, ADC does not support interrupts, temperature must be
> > polled. Also bq27200 chip does not support interrupts, but
> > bq27x00_battery driver using delayed work which every 60s
> > poll all values (timeout can be configured via modprobe
> > param). So similar code can be added to rx51_battery.ko
> > too.
> 
> I think the safest implementation would be:
> 
> bq2415x polls the temperature from rx51-battery in the bq2415x
> watchdog handler. That way discontinuation of the charge
> process is guaranteed.
> 
> To avoid useless ADC conversion the rx51-battery driver caches
> the converted temperature value for a reasonable time (e.g.
> 10 seconds). This helps if multiple users want to read the
> battery temperature (e.g. userspace).
> 
> This also means, that the kernel stuff can handle charging
> autonomously and the userland daemon checks the battery
> temperature only for emergency shutdown (I guess the
> temperatures for stopping the charging and emergency shutdown
> are different).
> 
> IMHO it makes sense to move the emergency shutdown also into
> the kernel (but different driver!) in the future, but that's
> another topic :)
> 
> -- Sebastian

Just to note, here is original nokia table of temperature limits:

https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface/source/master:modules/thermalobject_surface.c#L40

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 12/17] spi/qspi: convert driver to enable/disable memory mapped.

[Sourav Poddar]

Hi Mark,
On Tuesday 26 November 2013 06:41 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 01:05:08PM +0530, Sourav Poddar wrote:

Idea is to enable memory mapped by default at the end of the probe,
if the control reaches the "transfer" api, then the operation is
not a memory mapped one. Hence, we switch to Normal mode and at the
end of the "transfer" function. switch back to memory mapped mode.

This doesn't see safe, what happens if something tries to use the map
while a transfer is in progress?

Transfer gets initiated with the following api "ti_qspi_start_transfer_one".

At the beginning of this api, I am doing a "disable memory mapped", as 
becuase of
the code implemntation, if the control has reaches this api, memory 
mapped is not

the desired operation. Then, at the end of this api after
"spi_finalize_current_message(master)", which indicated the current 
transfer complete, I
issue a end of transfer command. Only after which, I enable memory 
mapped mode again.


So, will the condition you mention above will hit.? Please help me 
understand if i am

missing something?

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

Re: [PATCH 02/17] spi/spi.h: Add configure from slave support.

[Sourav Poddar]

On Tuesday 26 November 2013 05:51 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 04:51:53PM +0530, Sourav Poddar wrote:

On Tuesday 26 November 2013 03:59 PM, Mark Brown wrote:

+   void(*configure_from_slave)(struct spi_device *spi, u8 *val);

Clearly this is far too unstructured to be useful, this is only ever
going to work with one specific combination of slave and master since
there's absolutely no semantics defined.

I thought "val" might be good enuf, and this can be filled with whatever
data that need to be used from slave into master(irrespective of
slave and master?).

The name isn't the issue, it's the fact that you're passing a completely
unspecified blob of data.
May be, what you are suggesting here is to we should define a flash 
information

structure and should pass that structure here ?

--
To unsubscribe from this list: send the line "unsubscribe 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 03/17] spi/qspi: parse register by name.

[Sourav Poddar]

On Tuesday 26 November 2013 05:54 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 04:47:49PM +0530, Sourav Poddar wrote:


I have added "reg-names" property in dt bindings. (17/17) patch of
this series has that info.

Do device tree binding changes early on in the series rather than at the
end, one of the things that gets reviewed for is binding updates.

Your code should also cope with the existing bindings, falling back on
the current behaviour if it can't get the names or the extra resources.

My current code only has a single resouce, hence "*_byname* variants
was not used. With extra resources, I am switching to "byname" variants,
So, if a particular resource name is not found, it should just bypass 
that, thinking

the resource is not required and should not resort to existing bindings..
--
To unsubscribe from this list: send the line "unsubscribe 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/17] spi/qspi: Add support to switc to memory mapped operation.

[Sourav Poddar]

On Tuesday 26 November 2013 06:27 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 01:05:02PM +0530, Sourav Poddar wrote:


+void enable_qspi_memory_mapped(struct ti_qspi *qspi)
+void disable_qspi_memory_mapped(struct ti_qspi *qspi)

These are driver internal functions so they should be static.  It'd also
be more normal to put the qspi_ at the start of the name though it's not
too big a deal.

Ok. will change.
--
To unsubscribe from this list: send the line "unsubscribe 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/17] spi/spi.h: Add "mem" variable in spi master.

[Sourav Poddar]

On Tuesday 26 November 2013 06:50 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 06:35:35PM +0530, Sourav Poddar wrote:

On Tuesday 26 November 2013 06:31 PM, Mark Brown wrote:

Is this really generic enough to put here rather than in the driver
data?

The thought behind this was that if a master controller supports
memory mapped operation and slave wants to use memcpy in his
driver(bypassing spi ), then we should have a mean to communicate
between the
master and the slave. So, 'spi_master' seems to be the place for me
for this data,
which could be parsed in the slave side also.

I would have expected that the address would be returned by the function
that maps the buffer in rather than stored permanently in the master.

Yes, it could be be done the above way. I will change.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] mfd: menelaus: a few cleanups

[Felipe Balbi]

Hi,

On Wed, Nov 27, 2013 at 10:46:21PM +0200, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Nov 27, 2013 at 02:11:49PM -0600, Felipe Balbi wrote:
> > On Wed, Nov 27, 2013 at 10:02:47PM +0200, Aaro Koskinen wrote:
> > > On Wed, Nov 27, 2013 at 01:06:44PM -0600, Felipe Balbi wrote:
> > > > few cleanups on the old menelaus driver. I don't have
> > > > HW to test these patches, maybe Aaro can help here ?
> > > 
> > > Hmm, I got:
> > > 
> > > [1.33] Unable to handle kernel NULL pointer dereference at 
> > > virtual address 
> > > [1.34] pgd = c0004000
> > > [1.34] [] *pgd=
> > > [1.35] Internal error: Oops: 17 [#1] ARM
> > > [1.35] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > > 3.13.0-rc1-n8x0_tiny-los.git-729021f-00018-g74a0f39 #2
> > > [1.35] task: c782c000 ti: c782e000 task.ti: c782e000
> > > [1.35] PC is at mutex_lock+0x0/0x20
> > > [1.35] LR is at __irq_get_desc_lock+0x6c/0x88
> [...]
> > > [1.35] [] (mutex_lock+0x0/0x20) from [] 
> > > (__irq_get_desc_lock+0x6c/0x88)
> > > [1.35] [] (__irq_get_desc_lock+0x6c/0x88) from 
> > > [] (__irq_set_handler+0x24/0x128)
> > > [1.35] [] (__irq_set_handler+0x24/0x128) from 
> > > [] (menelaus_probe+0xbc/0x280)
> > > [1.35] [] (menelaus_probe+0xbc/0x280) from [] 
> > > (i2c_device_probe+0x98/0xc0)
> 
> [...]
> 
> > hmm, irq_set_chip_and_handler() will call back into the irq_chip we just
> > registered, so my ->irq_bus_lock needs to have everything setup
> > (chip_data my mutex), this should solve it:
> 
> Yes, that fixes it. Seems to work fine now.

Awesome, should I add your tested-by ? I also added a few extra patches
on top which I'll send soon.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] ARM: OMAP2+: Powerdomain: Fix unchecked dereference of arch_pwrdm

[Nishanth Menon]

On 11/27/2013 05:57 AM, Rajendra Nayak wrote:
> Commit 'cd8abed' "ARM: OMAP2+: Powerdomain: Remove the need to
> always have a voltdm associated to a pwrdm" leads to the following
> Smatch complaint:
> 
> arch/arm/mach-omap2/powerdomain.c:131 _pwrdm_register()
>error: we previously assumed 'arch_pwrdm' could be null (see line 105)
> 
> So, fix the unchecked dereference of arch_pwrdm.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm/mach-omap2/powerdomain.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/powerdomain.c 
> b/arch/arm/mach-omap2/powerdomain.c
> index e233dfc..93a2a6e 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -128,7 +128,8 @@ skip_voltdm:
>   for (i = 0; i < pwrdm->banks; i++)
>   pwrdm->ret_mem_off_counter[i] = 0;
>  
> - arch_pwrdm->pwrdm_wait_transition(pwrdm);
> + if (arch_pwrdm && arch_pwrdm->pwrdm_wait_transition)
> + arch_pwrdm->pwrdm_wait_transition(pwrdm);
>   pwrdm->state = pwrdm_read_pwrst(pwrdm);
>   pwrdm->state_counter[pwrdm->state] = 1;
>  
> 
Acked-by: Nishanth Menon 

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

Re: [PATCHv10 00/41] ARM: TI SoC clock DT conversion

[Nishanth Menon]

On 11/26/2013 02:05 AM, Tero Kristo wrote:
> Hi,
> 
> Changes compared to v9:
> - rebased on top of 3.13-rc1
> - modified the low level clk register API to provide SoC specific clk_readl
>   and clk_writel support which can be registered during boot, TI SoC variant
>   uses regmap on low level
> - dropped regmap parameter from clock init calls, instead a helper is used
>   for getting regmap index along with the register offset from DT
> - dropped regmap parameter from clock structs, instead platform specific
>   clk_readl / clk_writel are used to parse reg parameter according to
>   platform, for TI SoC:s, this is encoded as:
>   struct clk_omap_reg {
> u16 offset; /* register offset */
> u16 index; /* regmap index */
>   }
> - Nishanth's comments to v9 mostly addressed, except for the CLK_OF_DECLARE
>   tweak which I would actually want some feedback upon, basically the problem
>   is I need to return status from the clk init functions so I can see if
>   -EAGAIN is passed, in which case init will be retried later, maybe some of
>   this can be made generic, like converting all the CLK_OF_DECLARE type
>   functions to return status
> 
> Testing done:
> - omap3-beagle : boot + suspend/resume
> - omap3-beagle-xm : boot (thanks to Nishanth)
> - omap4-panda-es : boot + suspend/resume
> - omap5-uevm : boot
> - dra7-evm : boot
> - am335x-bone : boot
> 
> Separate branches available at https://github.com/t-kristo/linux-pm.git
> 
> - full: 3.13-rc1-dt-clks-v10 (should be merged last, contains everything)

More testing (boot):
(uImage + dtb combined):
http://pastebin.mozilla.org/3681899 - AM37xx-evm
http://pastebin.mozilla.org/3681900 -> AM3517-evm (not sure yet how
long this has been broken).

zImage and dtbs: (boot tests):
http://pastebin.mozilla.org/3669889 -> omap5uevm
http://pastebin.mozilla.org/3669917 -> Panda-ES
http://pastebin.mozilla.org/3669928 -> Beagle-XM
http://pastebin.mozilla.org/3669939 -> BBBlack
http://pastebin.mozilla.org/3670104 ->AM335x-EVM

Other than these, ran a quick coccicheck
http://pastebin.mozilla.org/3682339
at least the kzalloc one seems to indicate a pending fix.

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

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Sebastian Reichel]

On Wed, Nov 27, 2013 at 10:16:47PM +0100, Pali Rohár wrote:
> On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > > 2 seems more generic to me, but as rx51-battery is missing
> > > the functionality to send events on temperature change, I
> > > guess 1 will be easier to implement.
> > 
> > The temperature must be polled anyway, if the ADC does not
> > support interrupts.
> > 
> 
> Yes, ADC does not support interrupts, temperature must be polled. 
> Also bq27200 chip does not support interrupts, but 
> bq27x00_battery driver using delayed work which every 60s poll 
> all values (timeout can be configured via modprobe param). So 
> similar code can be added to rx51_battery.ko too.

I think the safest implementation would be:

bq2415x polls the temperature from rx51-battery in the bq2415x
watchdog handler. That way discontinuation of the charge process
is guaranteed.

To avoid useless ADC conversion the rx51-battery driver caches the
converted temperature value for a reasonable time (e.g. 10 seconds).
This helps if multiple users want to read the battery temperature
(e.g. userspace).

This also means, that the kernel stuff can handle charging
autonomously and the userland daemon checks the battery temperature
only for emergency shutdown (I guess the temperatures for stopping
the charging and emergency shutdown are different).

IMHO it makes sense to move the emergency shutdown also into the
kernel (but different driver!) in the future, but that's another
topic :)

-- Sebastian


signature.asc
Description: Digital signature

Re: [pandaboard] wl12xx borked after one up/down cycle

[Tony Lindgren]

* Tobias Jakobi  [131026 14:58]:
> And another one:
> https://bugzilla.kernel.org/show_bug.cgi?id=63821

OK this one turned out to be a pin mux issue probably caused
by a mismerge while rebasing patches for v3.10.

See the thread "[PATCH 0/2] ARM: dts: omap4: Fix pin muxing for wl12xx"
for the fix. Care to test it and if it works, update the bugzilla?

Regards,

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

Re: [PATCH 1/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx

[Tony Lindgren]

* Tony Lindgren  [131127 08:49]:
> * Balaji T K  [131127 08:30]:
> > On Wednesday 27 November 2013 03:25 AM, Tony Lindgren wrote:
> > >* Dan Murphy  [131121 09:28]:
> > >>On 11/21/2013 10:58 AM, Tony Lindgren wrote:
> > >>>* Balaji T K  [131121 05:51]:
> > pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
> > and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.
> > 
> > Fix the following error message:
> > pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
> > pinctrl-single 4a31e040.pinmux: could not add functions for 
> > pinmux_wl12xx_pins 56x
> > >>
> > >>Why is the led pins moved then?
> > >
> > >Heh the patch just looks that way, looking at the curly brackets
> > >thing do get moved properly.
> > >
> > SDIO card is not detected after moving pin mux to omap4_pmx_core since
> > sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect 
> > SDIO card.
> > >>>Cool, does this fix the issue with the WLAN not coming up after a warm 
> > >>>reset
> > >>>on panda?
> > >
> > >Also commit f446043f1aa7 (regulator: fixed: fix regulator_list_voltage() 
> > >for
> > >regression) is needed that recently got merged. But with v3.13-rc1 +
> > >f446043f1aa7 + this patch no luck whatsoever bringing up the wl12xx so 
> > >there
> > >must be also some regression somewhere from v3.12 on that?
> > >
> > Hi Tony,
> > 
> > I tried loading wl12xx as modules on latest base as yours with
> > ti-connectivity/wl127x-fw-5-sr.bin firmware in place and I could connect
> > and run iperf.
> 
> Oh OK I must have missed something then.
> 
> Does it now work after a warm reboot too? And after bringing the interface
> down with "ifconfig wlan0 down" followed by "ifconfig wlan0 up"?

Yes great, I can confirm that v3.13-rc1 + f446043f1aa7 (regulator: fixed: fix
regulator_list_voltage() for regression) + this patch works even after a
warm reset :) Will apply both to omap-for-v3.13/fixes-take4 with Cc stable.

Regards,

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

Re: Status of 1GHz support on am37xx

[Mark A. Greer]

On Tue, Nov 26, 2013 at 09:49:27AM -0600, Nishanth Menon wrote:
> On 11/25/2013 05:35 PM, Tony Lindgren wrote:
> > * Mark A. Greer  [131122 15:02]:
> >> Hello.
> >>
> >> I was wondering what that the status of 1GHz support for the am37xx is.
> >>
> >> It looks like smartreflex/avs and ABB drivers are there.  Do they need
> >> more work (e.g., DT support)?  What DT nodes and related support need
> >> to be added?
> >>
> >> What pieces are being worked on and which ones aren't?
> >> Is there an ETA for the pieces being worked on?
> > 
> > There are still various parts of twl4030 that are only working with
> > platform data, so at least those should be fixed now that we're moving
> > to DT only based booting for mach-omap2 for v3.14.
> > 
> 
> For 3630/DM3730 1GHz support the following needs to be done:
> a) clock nodes[1] without which cpufreq-cpu0 will never scale frequencies
> The following includes conversion to device tree enabled support.
> b) VC-vp regulator
> c) ABB dt nodes
> d) AVS class 1.5 support
> e) voltage regulator notifier around clock node for mpu so that avs
> and abb can be sequenced around voltage and frequency changes.
> 
> So, to answer your question, we are a little farther away beyond the
> first step of DT only boot to being able to exercise 1GHz properly.
> 
> [1] http://marc.info/?l=linux-omap&m=138545331825036&w=2

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

pm_runtime functions and IS_ERR_VALUE (was Re: [PATCH v6] ARM: omap: edma: add suspend suspend/resume hooks)

[Nishanth Menon]

Change in subject line + wider forum

On 19:24-20131127, Sekhar Nori wrote:
> On Wednesday 27 November 2013 07:17 PM, Daniel Mack wrote:
> > 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.
> 
> Yes, this is a common fallacy. Russell cleaned up a bunch of these a
> while back.

Thinking a little more on this front, to prevent recurrence and fixing
the ones we already have, how about something like the following
patch?

For example, on 3.13-rc1, with omap2plus_defconfig, I see the following:
http://pastebin.mozilla.org/3681911

-->8--
>From b7946d214fab72b2e18cd67eec01c377f1cddee8 Mon Sep 17 00:00:00 2001
From: Nishanth Menon 
Date: Wed, 27 Nov 2013 17:01:20 -0600
Subject: [RFC PATCH] scripts: Coccinelle script for pm_runtime_* return checks
 with IS_ERR_VALUE

As indicated by Sekhar in [1], there seems to be a tendency to use
IS_ERR_VALUE to check the error result for pm_runtime_* functions which
make no sense considering commit c48cd65 (ARM: OMAP: use consistent
error checking) - the error values can either be < 0 for error OR
0, 1 in cases where we have success.

So, setup a coccinelle script to help identify the same.

[1] http://marc.info/?t=13847267813&r=1&w=2

Cc: Russell King 
Reported-by: Sekhar Nori 
Signed-off-by: Nishanth Menon 
---
 scripts/coccinelle/api/pm_runtime.cocci |  109 +++
 1 file changed, 109 insertions(+)
 create mode 100644 scripts/coccinelle/api/pm_runtime.cocci

diff --git a/scripts/coccinelle/api/pm_runtime.cocci 
b/scripts/coccinelle/api/pm_runtime.cocci
new file mode 100644
index 000..f01789e
--- /dev/null
+++ b/scripts/coccinelle/api/pm_runtime.cocci
@@ -0,0 +1,109 @@
+/// Make sure pm_runtime_* calls does not use unnecessary IS_ERR_VALUE
+//
+// Keywords: pm_runtime
+// Confidence: Medium
+// Copyright (C) 2013 Texas Instruments Incorporated - GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --include-headers
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+//--
+//  Detection
+//--
+
+@runtime_bad_err_handle exists@
+expression ret;
+@@
+(
+ret = \(pm_runtime_idle\|
+   pm_runtime_suspend\|
+   pm_runtime_autosuspend\|
+   pm_runtime_resume\|
+   pm_request_idle\|
+   pm_request_resume\|
+   pm_request_autosuspend\|
+   pm_runtime_get\|
+   pm_runtime_get_sync\|
+   pm_runtime_put\|
+   pm_runtime_put_autosuspend\|
+   pm_runtime_put_sync\|
+   pm_runtime_put_sync_suspend\|
+   pm_runtime_put_sync_autosuspend\|
+   pm_runtime_set_active\|
+   pm_schedule_suspend\|
+   pm_runtime_barrier\|
+   pm_generic_runtime_suspend\|
+   pm_generic_runtime_resume\)(...);
+...
+IS_ERR_VALUE(ret)
+...
+)
+
+//--
+//  For context mode
+//--
+
+@depends on runtime_bad_err_handle && context@
+identifier pm_runtime_api;
+expression ret;
+@@
+(
+ret = pm_runtime_api(...);
+...
+* IS_ERR_VALUE(ret)
+...
+)
+
+//--
+//  For patch mode
+//--
+
+@depends on runtime_bad_err_handle && patch@
+identifier pm_runtime_api;
+expression ret;
+@@
+(
+ret = pm_runtime_api(...);
+...
+- IS_ERR_VALUE(ret)
++ ret < 0
+...
+)
+
+//--
+//  For org and report mode
+//--
+
+@r depends on runtime_bad_err_handle exists@
+position p1, p2;
+identifier pm_runtime_api;
+expression ret;
+@@
+(
+ret = pm_runtime_api@p1(...);
+...
+IS_ERR_VALUE@p2(ret)
+...
+)
+
+@script:python depends on org@
+p1 << r.p1;
+p2 << r.p2;
+pm_runtime_api << r.pm_runtime_api;
+@@
+
+cocci.print_main(pm_runtime_api,p1)
+cocci.print_secs("IS_ERR_VALUE",p2)
+
+@script:python depends on report@
+p1 << r.p1;
+p2 << r.p2;
+pm_runtime_api << r.pm_runtime_api;
+@@
+
+msg = "%s returns < 0 as err

Re: [PATCH] ARM: dts: omap3-beagle: Add omap-twl4030 audio support

[Tony Lindgren]

* Jarkko Nikula  [131127 10:48]:
> This adds typical McBSP2-TWL4030 audio description to the legacy
> Beagle Board.

Nice to see that work almost out of the box :)

BTW, I just noticed that sound/soc/omap/Kconfig has depends on
OMAP_MUX. The OMAP_MUX option will be dropped for mach-omap2
for v3.14, so you may want to take a look at that too. If there
really is a dependency, that should be handled using
pinctrl-single for the .dts entries.

Regards,

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

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Chris Ball  [131127 13:48]:
> Hi,
> 
> On Wed, Nov 27 2013, Jarkko Nikula wrote:
> > Can you enlighten me what's the proper way to get patches to mmc since
> > I cannot figure out working methodology from MAINTAINERS file?
> 
> Sorry about this, Jarkko.
> 
> Since I don't have omap.c hardware, I'm generally going to wait for
> a Tested-by/Acked-by from someone else on patches like these.  We
> actually have a maintainer already listed for the driver, Jarkko
> Lavinen .
> 
> So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
> an update?  Feel free to send me patches to it.  Either way, I'll
> start treating Aaro and Jarkko (Nikula) as maintainers for this
> driver.

Hmm looks like here's a reasonably recent update that we've missed
from Jarkko Lavinen to update his email address:

http://lkml.org/lkml/2013/10/4/142

I've updated Jarkko Lavinen's address in this mail, we should
probably also patch the MAINTAINERS file for that, and then see if
Aaro and Jarkko Nikula are interested to be listed there as well.

Regards,

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

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Chris Ball]

Hi,

On Wed, Nov 27 2013, Jarkko Nikula wrote:
> Can you enlighten me what's the proper way to get patches to mmc since
> I cannot figure out working methodology from MAINTAINERS file?

Sorry about this, Jarkko.

Since I don't have omap.c hardware, I'm generally going to wait for
a Tested-by/Acked-by from someone else on patches like these.  We
actually have a maintainer already listed for the driver, Jarkko
Lavinen .

So, maybe the MAINTAINERS section for drivers/mmc/host/omap.c needs
an update?  Feel free to send me patches to it.  Either way, I'll
start treating Aaro and Jarkko (Nikula) as maintainers for this
driver.

Thanks!

- Chris.
-- 
Chris Ball  
--
To unsubscribe from this list: send the line "unsubscribe 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/8] mmc: omap: Fix DMA configuration to not rely on device id

[Tony Lindgren]

* Jarkko Nikula  [131127 12:55]:
> Hi Chris
> 
> On Tue, 26 Nov 2013 18:33:50 -0500
> Chris Ball  wrote:
> 
> > Hi Tony,
> > 
> > On Mon, Nov 18 2013, Tony Lindgren wrote:
> > > We are wrongly relying on device id for the DMA configuration
> > > which can lead to wrong DMA channel being selected.
> > >
> > > Fix the issue by using the standard resources like we should.
> > >
> > > Cc: Chris Ball 
> > > Cc: linux-...@vger.kernel.org
> > > Signed-off-by: Tony Lindgren 
> > 
> > Feel free to merge via your tree:
> > 
> > Acked-by: Chris Ball 
> > 
> Can you enlighten me what's the proper way to get patches to mmc since
> I cannot figure out working methodology from MAINTAINERS file?
> 
> I happened to notice that Tony had this similar patch in linux-omap
> list I sent first time already September to you and linux-mmc (sorry
> linux-omap folks, I didn't want to spam multiple lists):
> 
> http://www.spinics.net/lists/linux-mmc/msg22137.html
> 
> After that I've resend the set a few times including a fix to
> user triggable NULL pointer dereference:
> 
> http://www.spinics.net/lists/linux-mmc/msg22610.html
> 
> I'm fine if mmc patches should go through other subsystems but at least
> it should be documented in MAINTAINERS file.

Bummer, sounds like some duplicate work could have been avoided :(
I suggest resend to Chris and linux-mmc one more time as Chris should
pick up the MMC patches in general.

I've been just trying to get things working in general for v3.13-rc
series for omaps with device tree based booting and patching all over
the place. This is to make it easy for us to just drop the legacy
platform based booting for v3.14 while keeping things working.

Chris, as far as I'm concerned, Aaro and Jarkko are good people to
review and ack the drivers/mmc/omap.c patches, so adding Aaro to
Cc as well.

Regards,

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

[PATCH RESEND v2] ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance

[Aaro Koskinen]

When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig
(LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled,
the following BUG is seen during the boot:

[7.302154] =
[7.307128] [ BUG: bad unlock balance detected! ]
[7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7 #3 Not tainted
[7.318450] -
[7.323425] kworker/u2:1/12 is trying to release lock (&ddata->mutex) at:
[7.330657] [] acx565akm_enable+0x12c/0x18c
[7.335998] but there are no more locks to release!

Fix by removing double unlock and handling the locking completely inside
acx565akm_panel_power_on() when doing the power on.

Reported-by: Eduardo Valentin 
Signed-off-by: Aaro Koskinen 
Cc: sta...@vger.kernel.org
---
 drivers/video/omap2/displays-new/panel-sony-acx565akm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c 
b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index e6d56f7..d94f35d 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -526,6 +526,8 @@ static int acx565akm_panel_power_on(struct omap_dss_device 
*dssdev)
struct omap_dss_device *in = ddata->in;
int r;
 
+   mutex_lock(&ddata->mutex);
+
dev_dbg(&ddata->spi->dev, "%s\n", __func__);
 
in->ops.sdi->set_timings(in, &ddata->videomode);
@@ -614,10 +616,7 @@ static int acx565akm_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
 
-   mutex_lock(&ddata->mutex);
r = acx565akm_panel_power_on(dssdev);
-   mutex_unlock(&ddata->mutex);
-
if (r)
return r;
 
-- 
1.8.4.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 v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Pali Rohár]

On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > 2 seems more generic to me, but as rx51-battery is missing
> > the functionality to send events on temperature change, I
> > guess 1 will be easier to implement.
> 
> The temperature must be polled anyway, if the ADC does not
> support interrupts.
> 

Yes, ADC does not support interrupts, temperature must be polled. 
Also bq27200 chip does not support interrupts, but 
bq27x00_battery driver using delayed work which every 60s poll 
all values (timeout can be configured via modprobe param). So 
similar code can be added to rx51_battery.ko too.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/8] mmc: omap: Fix DMA configuration to not rely on device id

[Jarkko Nikula]

Hi Chris

On Tue, 26 Nov 2013 18:33:50 -0500
Chris Ball  wrote:

> Hi Tony,
> 
> On Mon, Nov 18 2013, Tony Lindgren wrote:
> > We are wrongly relying on device id for the DMA configuration
> > which can lead to wrong DMA channel being selected.
> >
> > Fix the issue by using the standard resources like we should.
> >
> > Cc: Chris Ball 
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Tony Lindgren 
> 
> Feel free to merge via your tree:
> 
> Acked-by: Chris Ball 
> 
Can you enlighten me what's the proper way to get patches to mmc since
I cannot figure out working methodology from MAINTAINERS file?

I happened to notice that Tony had this similar patch in linux-omap
list I sent first time already September to you and linux-mmc (sorry
linux-omap folks, I didn't want to spam multiple lists):

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

After that I've resend the set a few times including a fix to
user triggable NULL pointer dereference:

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

I'm fine if mmc patches should go through other subsystems but at least
it should be documented in MAINTAINERS file.

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

Re: [PATCH 00/13] mfd: menelaus: a few cleanups

[Aaro Koskinen]

Hi,

On Wed, Nov 27, 2013 at 02:11:49PM -0600, Felipe Balbi wrote:
> On Wed, Nov 27, 2013 at 10:02:47PM +0200, Aaro Koskinen wrote:
> > On Wed, Nov 27, 2013 at 01:06:44PM -0600, Felipe Balbi wrote:
> > > few cleanups on the old menelaus driver. I don't have
> > > HW to test these patches, maybe Aaro can help here ?
> > 
> > Hmm, I got:
> > 
> > [1.33] Unable to handle kernel NULL pointer dereference at virtual 
> > address 
> > [1.34] pgd = c0004000
> > [1.34] [] *pgd=
> > [1.35] Internal error: Oops: 17 [#1] ARM
> > [1.35] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > 3.13.0-rc1-n8x0_tiny-los.git-729021f-00018-g74a0f39 #2
> > [1.35] task: c782c000 ti: c782e000 task.ti: c782e000
> > [1.35] PC is at mutex_lock+0x0/0x20
> > [1.35] LR is at __irq_get_desc_lock+0x6c/0x88
[...]
> > [1.35] [] (mutex_lock+0x0/0x20) from [] 
> > (__irq_get_desc_lock+0x6c/0x88)
> > [1.35] [] (__irq_get_desc_lock+0x6c/0x88) from 
> > [] (__irq_set_handler+0x24/0x128)
> > [1.35] [] (__irq_set_handler+0x24/0x128) from 
> > [] (menelaus_probe+0xbc/0x280)
> > [1.35] [] (menelaus_probe+0xbc/0x280) from [] 
> > (i2c_device_probe+0x98/0xc0)

[...]

> hmm, irq_set_chip_and_handler() will call back into the irq_chip we just
> registered, so my ->irq_bus_lock needs to have everything setup
> (chip_data my mutex), this should solve it:

Yes, that fixes it. Seems to work fine now.

A.

> diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
> index 376f01d..c9bd2fb 100644
> --- a/drivers/mfd/menelaus.c
> +++ b/drivers/mfd/menelaus.c
> @@ -1232,6 +1232,7 @@ static int menelaus_probe(struct i2c_client *client,
>  
>   the_menelaus = m;
>   m->client = client;
> + mutex_init(&m->lock);
>  
>   irq_base = irq_alloc_descs(-1, 0, MENELAUS_NR_IRQS, 0);
>   if (irq_base < 0) {
> @@ -1245,10 +1246,10 @@ static int menelaus_probe(struct i2c_client *client,
>   m->irq_base = irq_base;
>  
>   for (i = irq_base; i < irq_base + MENELAUS_NR_IRQS; i++) {
> + irq_set_chip_data(i, m);
>   irq_set_chip_and_handler(i, &menelaus_irq_chip,
>   handle_simple_irq);
>   irq_set_nested_thread(i, 1);
> - irq_set_chip_data(i, m);
>   set_irq_flags(i, IRQF_VALID);
>   }
>  
> @@ -1280,8 +1281,6 @@ static int menelaus_probe(struct i2c_client *client,
>   }
>   }
>  
> - mutex_init(&m->lock);
> -
>   pr_info("Menelaus rev %d.%d\n", rev >> 4, rev & 0x0f);
>  
>   val = menelaus_read_reg(m, MENELAUS_VCORE_CTRL1);
> 
> 
> let me know when you can, and I'll meld these hunks to proper patch.
> 
> -- 
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] mfd: menelaus: a few cleanups

[Felipe Balbi]

Hi,

On Wed, Nov 27, 2013 at 10:02:47PM +0200, Aaro Koskinen wrote:
> On Wed, Nov 27, 2013 at 01:06:44PM -0600, Felipe Balbi wrote:
> > few cleanups on the old menelaus driver. I don't have
> > HW to test these patches, maybe Aaro can help here ?
> 
> Hmm, I got:
> 
> [1.33] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [1.34] pgd = c0004000
> [1.34] [] *pgd=
> [1.35] Internal error: Oops: 17 [#1] ARM
> [1.35] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 3.13.0-rc1-n8x0_tiny-los.git-729021f-00018-g74a0f39 #2
> [1.35] task: c782c000 ti: c782e000 task.ti: c782e000
> [1.35] PC is at mutex_lock+0x0/0x20
> [1.35] LR is at __irq_get_desc_lock+0x6c/0x88
> [1.35] pc : []lr : []psr: a013
> [1.35] sp : c782fe10  ip : fffa  fp : 
> [1.35] r10: c01e0268  r9 :   r8 : c7903e20
> [1.35] r7 : 0001  r6 : c782fe2c  r5 :   r4 : c7147080
> [1.35] r3 : c013eab0  r2 :   r1 : 00f2  r0 : 
> [1.35] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> kernel
> [1.35] Control: 00c5387d  Table: 8704c000  DAC: 0017
> [1.35] Process swapper (pid: 1, stack limit = 0xc782e1b8)
> [1.35] Stack: (0xc782fe10 to 0xc783)
> [1.35] fe00:  00f2 
> c0053034 
> [1.35] fe20:  c0053518 c016b798  00f2 c711ea10 
> 0102 c7903e00
> [1.35] fe20:  c0053518 c016b798  00f2 c711ea10 
> 0102 c7903e00
> [1.35] fe40: c7903e20 c013ec80 c016b798 c711ea10 c7903e20 c013ebc4 
> c7903e00 
> [1.35] fe60: c046ae74  0015 c0140ab8 c7903e20 c0498b10 
> c0498b18 c0131194
> [1.35] fe80: c7903e20 c046ae74 c7903e54  c01da8fc c0131338 
>  c046ae74
> [1.35] fea0: c01312ac c012fa00 c784e64c c78e7f90 c046ae74 c70b6420 
> c046b1e0 c01301a8
> [1.35] fec0: c01b1130 c00ce2fc c046ae74 c046ae74 c01dce14 c01e24d0 
> c01c6484 c01316cc
> [1.35] fee0: c046b1e0 c046ae50 c01dce14 c0141bc8 c782e000 0006 
> c01dce14 c01c6ad0
> [1.35] ff00: c04907e4 c784d3c0 c016b7a8 006f   
>  c00c488c
> [1.35] ff20: c05998c0 c0170258 0015 c003ff84 c0466030  
> c01b1204 c01b4358
> [1.35] ff40: 0006 0006  0006 0006 c01dce14 
> c01e24d0 c01c6484
> [1.35] ff60: c01dce20 c046c460 0015 c01c6c70 0006 0006 
> c01c6484 
> [1.35] ff80:    c01634e0   
>  
> [1.35] ffa0:  c01634e8  c000e0f8   
>  
> [1.35] ffc0:       
>  
> [1.35] ffe0:     0013  
>  
> [1.35] [] (mutex_lock+0x0/0x20) from [] 
> (__irq_get_desc_lock+0x6c/0x88)
> [1.35] [] (__irq_get_desc_lock+0x6c/0x88) from [] 
> (__irq_set_handler+0x24/0x128)
> [1.35] [] (__irq_set_handler+0x24/0x128) from [] 
> (menelaus_probe+0xbc/0x280)
> [1.35] [] (menelaus_probe+0xbc/0x280) from [] 
> (i2c_device_probe+0x98/0xc0)
> [1.35] [] (i2c_device_probe+0x98/0xc0) from [] 
> (driver_probe_device+0x110/0x228)
> [1.35] [] (driver_probe_device+0x110/0x228) from 
> [] (__driver_attach+0x8c/0x90)
> [1.35] [] (__driver_attach+0x8c/0x90) from [] 
> (bus_for_each_dev+0x54/0x88)
> [1.35] [] (bus_for_each_dev+0x54/0x88) from [] 
> (bus_add_driver+0xd4/0x1c8)
> [1.35] [] (bus_add_driver+0xd4/0x1c8) from [] 
> (driver_register+0x78/0xf4)
> [1.35] [] (driver_register+0x78/0xf4) from [] 
> (i2c_register_driver+0x2c/0xb8)
> [1.35] [] (i2c_register_driver+0x2c/0xb8) from [] 
> (do_one_initcall+0x94/0x150)
> [1.35] [] (do_one_initcall+0x94/0x150) from [] 
> (kernel_init_freeable+0xe4/0x1b0)
> [1.35] [] (kernel_init_freeable+0xe4/0x1b0) from 
> [] (kernel_init+0x8/0x110)
> [1.35] [] (kernel_init+0x8/0x110) from [] 
> (ret_from_fork+0x14/0x3c)
> [1.35] Code: 03a03000 05843000 e28dd010 e8bd81f0 (e1902f9f)
> [1.36] ---[ end trace 75cc9e337407e765 ]---
> [1.36] Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x000b

hmm, irq_set_chip_and_handler() will call back into the irq_chip we just
registered, so my ->irq_bus_lock needs to have everything setup
(chip_data my mutex), this should solve it:

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 376f01d..c9bd2fb 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1232,6 +1232,7 @@ static int menelaus_probe(struct i2c_client *client,
 
the_menelaus = m;
m->client = client;
+   mutex_init(&m->lock);

Re: [PATCH 00/13] mfd: menelaus: a few cleanups

[Aaro Koskinen]

On Wed, Nov 27, 2013 at 01:06:44PM -0600, Felipe Balbi wrote:
> few cleanups on the old menelaus driver. I don't have
> HW to test these patches, maybe Aaro can help here ?

Hmm, I got:

[1.33] Unable to handle kernel NULL pointer dereference at virtual 
address 
[1.34] pgd = c0004000
[1.34] [] *pgd=
[1.35] Internal error: Oops: 17 [#1] ARM
[1.35] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.13.0-rc1-n8x0_tiny-los.git-729021f-00018-g74a0f39 #2
[1.35] task: c782c000 ti: c782e000 task.ti: c782e000
[1.35] PC is at mutex_lock+0x0/0x20
[1.35] LR is at __irq_get_desc_lock+0x6c/0x88
[1.35] pc : []lr : []psr: a013
[1.35] sp : c782fe10  ip : fffa  fp : 
[1.35] r10: c01e0268  r9 :   r8 : c7903e20
[1.35] r7 : 0001  r6 : c782fe2c  r5 :   r4 : c7147080
[1.35] r3 : c013eab0  r2 :   r1 : 00f2  r0 : 
[1.35] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[1.35] Control: 00c5387d  Table: 8704c000  DAC: 0017
[1.35] Process swapper (pid: 1, stack limit = 0xc782e1b8)
[1.35] Stack: (0xc782fe10 to 0xc783)
[1.35] fe00:  00f2 
c0053034 
[1.35] fe20:  c0053518 c016b798  00f2 c711ea10 
0102 c7903e00
[1.35] fe20:  c0053518 c016b798  00f2 c711ea10 
0102 c7903e00
[1.35] fe40: c7903e20 c013ec80 c016b798 c711ea10 c7903e20 c013ebc4 
c7903e00 
[1.35] fe60: c046ae74  0015 c0140ab8 c7903e20 c0498b10 
c0498b18 c0131194
[1.35] fe80: c7903e20 c046ae74 c7903e54  c01da8fc c0131338 
 c046ae74
[1.35] fea0: c01312ac c012fa00 c784e64c c78e7f90 c046ae74 c70b6420 
c046b1e0 c01301a8
[1.35] fec0: c01b1130 c00ce2fc c046ae74 c046ae74 c01dce14 c01e24d0 
c01c6484 c01316cc
[1.35] fee0: c046b1e0 c046ae50 c01dce14 c0141bc8 c782e000 0006 
c01dce14 c01c6ad0
[1.35] ff00: c04907e4 c784d3c0 c016b7a8 006f   
 c00c488c
[1.35] ff20: c05998c0 c0170258 0015 c003ff84 c0466030  
c01b1204 c01b4358
[1.35] ff40: 0006 0006  0006 0006 c01dce14 
c01e24d0 c01c6484
[1.35] ff60: c01dce20 c046c460 0015 c01c6c70 0006 0006 
c01c6484 
[1.35] ff80:    c01634e0   
 
[1.35] ffa0:  c01634e8  c000e0f8   
 
[1.35] ffc0:       
 
[1.35] ffe0:     0013  
 
[1.35] [] (mutex_lock+0x0/0x20) from [] 
(__irq_get_desc_lock+0x6c/0x88)
[1.35] [] (__irq_get_desc_lock+0x6c/0x88) from [] 
(__irq_set_handler+0x24/0x128)
[1.35] [] (__irq_set_handler+0x24/0x128) from [] 
(menelaus_probe+0xbc/0x280)
[1.35] [] (menelaus_probe+0xbc/0x280) from [] 
(i2c_device_probe+0x98/0xc0)
[1.35] [] (i2c_device_probe+0x98/0xc0) from [] 
(driver_probe_device+0x110/0x228)
[1.35] [] (driver_probe_device+0x110/0x228) from [] 
(__driver_attach+0x8c/0x90)
[1.35] [] (__driver_attach+0x8c/0x90) from [] 
(bus_for_each_dev+0x54/0x88)
[1.35] [] (bus_for_each_dev+0x54/0x88) from [] 
(bus_add_driver+0xd4/0x1c8)
[1.35] [] (bus_add_driver+0xd4/0x1c8) from [] 
(driver_register+0x78/0xf4)
[1.35] [] (driver_register+0x78/0xf4) from [] 
(i2c_register_driver+0x2c/0xb8)
[1.35] [] (i2c_register_driver+0x2c/0xb8) from [] 
(do_one_initcall+0x94/0x150)
[1.35] [] (do_one_initcall+0x94/0x150) from [] 
(kernel_init_freeable+0xe4/0x1b0)
[1.35] [] (kernel_init_freeable+0xe4/0x1b0) from [] 
(kernel_init+0x8/0x110)
[1.35] [] (kernel_init+0x8/0x110) from [] 
(ret_from_fork+0x14/0x3c)
[1.35] Code: 03a03000 05843000 e28dd010 e8bd81f0 (e1902f9f)
[1.36] ---[ end trace 75cc9e337407e765 ]---
[1.36] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b

A.
--
To unsubscribe from this list: send the line "unsubscribe 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 00/13] mfd: menelaus: a few cleanups

[Felipe Balbi]

few cleanups on the old menelaus driver. I don't have
HW to test these patches, maybe Aaro can help here ?

cheers

Felipe Balbi (13):
  mfd: menelaus: drop __exit section annotation
  mfd: menelaus: switch over to module_i2c_driver
  mfd: menelaus: convert to threaded irq
  mfd: menelaus: remove unnecessary loop
  mfd: menelaus: use for_each_set_bit()
  mfd: menelaus: pass menelaus pointer as argument to enable/disable irq
  mfd: menelaus: limit the usage of the_menelaus
  mfd: menelaus: pass menelaus_chip pointer to add/remove irq functions
  mfd: menelaus: pass menelaus_chip pointer to get/set voltage
  mfd: menelaus: pass menelaus_chip argument to menelaus <-> time
helpers
  mfd: menelaus: start to use irqdomain
  mfd: menelaus: switch all children to threaded_irq
  mfd: menelaus: remove unnecessary definition

 drivers/mfd/menelaus.c | 616 +
 1 file changed, 319 insertions(+), 297 deletions(-)

-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 02/13] mfd: menelaus: switch over to module_i2c_driver

[Felipe Balbi]

just a macro to remove some boilerplate code,
no functional changes.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 975ff9e..8bd97ca 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1287,29 +1287,8 @@ static struct i2c_driver menelaus_i2c_driver = {
.id_table   = menelaus_id,
 };
 
-static int __init menelaus_init(void)
-{
-   int res;
-
-   res = i2c_add_driver(&menelaus_i2c_driver);
-   if (res < 0) {
-   pr_err(DRIVER_NAME ": driver registration failed\n");
-   return res;
-   }
-
-   return 0;
-}
-
-static void __exit menelaus_exit(void)
-{
-   i2c_del_driver(&menelaus_i2c_driver);
-
-   /* FIXME: Shutdown menelaus parts that can be shut down */
-}
+module_i2c_driver(menelaus_i2c_driver);
 
 MODULE_AUTHOR("Texas Instruments, Inc. (and others)");
 MODULE_DESCRIPTION("I2C interface for Menelaus.");
 MODULE_LICENSE("GPL");
-
-module_init(menelaus_init);
-module_exit(menelaus_exit);
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 07/13] mfd: menelaus: limit the usage of the_menelaus

[Felipe Balbi]

pass a menelaus_chip pointer as argument to most
functions so we can minimize the usage of the
global the_menelaus pointer.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 265 ++---
 1 file changed, 142 insertions(+), 123 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 4c51e4b..8796e5e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -177,9 +177,9 @@ struct menelaus_chip {
 
 static struct menelaus_chip *the_menelaus;
 
-static int menelaus_write_reg(int reg, u8 value)
+static int menelaus_write_reg(struct menelaus_chip *m, int reg, u8 value)
 {
-   int val = i2c_smbus_write_byte_data(the_menelaus->client, reg, value);
+   int val = i2c_smbus_write_byte_data(m->client, reg, value);
 
if (val < 0) {
pr_err(DRIVER_NAME ": write error");
@@ -189,9 +189,9 @@ static int menelaus_write_reg(int reg, u8 value)
return 0;
 }
 
-static int menelaus_read_reg(int reg)
+static int menelaus_read_reg(struct menelaus_chip *m, int reg)
 {
-   int val = i2c_smbus_read_byte_data(the_menelaus->client, reg);
+   int val = i2c_smbus_read_byte_data(m->client, reg);
 
if (val < 0)
pr_err(DRIVER_NAME ": read error");
@@ -204,11 +204,11 @@ static int menelaus_enable_irq(struct menelaus_chip *m, 
int irq)
if (irq > 7) {
irq -= 8;
m->mask2 &= ~(1 << irq);
-   return menelaus_write_reg(MENELAUS_INT_MASK2,
+   return menelaus_write_reg(m, MENELAUS_INT_MASK2,
m->mask2);
} else {
m->mask1 &= ~(1 << irq);
-   return menelaus_write_reg(MENELAUS_INT_MASK1,
+   return menelaus_write_reg(m, MENELAUS_INT_MASK1,
m->mask1);
}
 }
@@ -218,11 +218,11 @@ static int menelaus_disable_irq(struct menelaus_chip *m, 
int irq)
if (irq > 7) {
irq -= 8;
m->mask2 |= (1 << irq);
-   return menelaus_write_reg(MENELAUS_INT_MASK2,
+   return menelaus_write_reg(m, MENELAUS_INT_MASK2,
m->mask2);
} else {
m->mask1 |= (1 << irq);
-   return menelaus_write_reg(MENELAUS_INT_MASK1,
+   return menelaus_write_reg(m, MENELAUS_INT_MASK1,
m->mask1);
}
 }
@@ -230,9 +230,9 @@ static int menelaus_disable_irq(struct menelaus_chip *m, 
int irq)
 static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
 {
if (irq > 7)
-   return menelaus_write_reg(MENELAUS_INT_ACK2, 1 << (irq - 8));
+   return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 << (irq - 8));
else
-   return menelaus_write_reg(MENELAUS_INT_ACK1, 1 << irq);
+   return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 << irq);
 }
 
 /* Adds a handler for an interrupt. Does not run in interrupt context */
@@ -268,12 +268,12 @@ static int menelaus_remove_irq_work(int irq)
  * in each slot. In this case the cards are not seen by menelaus.
  * FIXME: Add handling for D1 too
  */
-static void menelaus_mmc_cd_work(struct menelaus_chip *menelaus_hw)
+static void menelaus_mmc_cd_work(struct menelaus_chip *m)
 {
int reg;
unsigned char card_mask = 0;
 
-   reg = menelaus_read_reg(MENELAUS_MCT_PIN_ST);
+   reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg < 0)
return;
 
@@ -283,8 +283,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip 
*menelaus_hw)
if (!(reg & 0x2))
card_mask |= MCT_PIN_ST_S2_CD_ST;
 
-   if (menelaus_hw->mmc_callback)
-   menelaus_hw->mmc_callback(menelaus_hw->mmc_callback_data,
+   if (m->mmc_callback)
+   m->mmc_callback(m->mmc_callback_data,
  card_mask);
 }
 
@@ -293,14 +293,16 @@ static void menelaus_mmc_cd_work(struct menelaus_chip 
*menelaus_hw)
  */
 int menelaus_set_mmc_opendrain(int slot, int enable)
 {
+   struct menelaus_chip *m = the_menelaus;
int ret, val;
 
if (slot != 1 && slot != 2)
return -EINVAL;
-   mutex_lock(&the_menelaus->lock);
-   ret = menelaus_read_reg(MENELAUS_MCT_CTRL1);
+
+   mutex_lock(&m->lock);
+   ret = menelaus_read_reg(m, MENELAUS_MCT_CTRL1);
if (ret < 0) {
-   mutex_unlock(&the_menelaus->lock);
+   mutex_unlock(&m->lock);
return ret;
}
val = ret;
@@ -315,8 +317,8 @@ int menelaus_set_mmc_opendrain(int slot, int enable)
else
val &= ~MCT_CTRL1_S2_CMD_OD;
}
-   ret = menelaus_write_reg(MENELAUS_MCT_CTRL1, val);
-   mutex_unlock(&the_menelaus->lock);
+   ret = menelaus_write_reg(m, MENELAUS_MCT_CTRL1, val);
+   mutex_unlock(&m->lock);
 
return ret;

[PATCH 06/13] mfd: menelaus: pass menelaus pointer as argument to enable/disable irq

[Felipe Balbi]

we want to, eventually, get rid of the global
the_menelaus pointer, so let's start passing
menelaus as argument to some function calls
and slowly phase out the_menelaus global pointer.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9ccbb79..4c51e4b 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -199,35 +199,35 @@ static int menelaus_read_reg(int reg)
return val;
 }
 
-static int menelaus_enable_irq(int irq)
+static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
 {
if (irq > 7) {
irq -= 8;
-   the_menelaus->mask2 &= ~(1 << irq);
+   m->mask2 &= ~(1 << irq);
return menelaus_write_reg(MENELAUS_INT_MASK2,
-   the_menelaus->mask2);
+   m->mask2);
} else {
-   the_menelaus->mask1 &= ~(1 << irq);
+   m->mask1 &= ~(1 << irq);
return menelaus_write_reg(MENELAUS_INT_MASK1,
-   the_menelaus->mask1);
+   m->mask1);
}
 }
 
-static int menelaus_disable_irq(int irq)
+static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
 {
if (irq > 7) {
irq -= 8;
-   the_menelaus->mask2 |= (1 << irq);
+   m->mask2 |= (1 << irq);
return menelaus_write_reg(MENELAUS_INT_MASK2,
-   the_menelaus->mask2);
+   m->mask2);
} else {
-   the_menelaus->mask1 |= (1 << irq);
+   m->mask1 |= (1 << irq);
return menelaus_write_reg(MENELAUS_INT_MASK1,
-   the_menelaus->mask1);
+   m->mask1);
}
 }
 
-static int menelaus_ack_irq(int irq)
+static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
 {
if (irq > 7)
return menelaus_write_reg(MENELAUS_INT_ACK2, 1 << (irq - 8));
@@ -243,7 +243,7 @@ static int menelaus_add_irq_work(int irq,
 
mutex_lock(&the_menelaus->lock);
the_menelaus->handlers[irq] = handler;
-   ret = menelaus_enable_irq(irq);
+   ret = menelaus_enable_irq(the_menelaus, irq);
mutex_unlock(&the_menelaus->lock);
 
return ret;
@@ -255,7 +255,7 @@ static int menelaus_remove_irq_work(int irq)
int ret = 0;
 
mutex_lock(&the_menelaus->lock);
-   ret = menelaus_disable_irq(irq);
+   ret = menelaus_disable_irq(the_menelaus, irq);
the_menelaus->handlers[irq] = NULL;
mutex_unlock(&the_menelaus->lock);
 
@@ -793,25 +793,25 @@ out:
 
 static irqreturn_t menelaus_irq(int irq, void *_menelaus)
 {
-   struct menelaus_chip *menelaus = _menelaus;
-   void (*handler)(struct menelaus_chip *menelaus);
+   struct menelaus_chip *m = _menelaus;
+   void (*handler)(struct menelaus_chip *m);
unsigned long isr;
unsigned long i;
 
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-   & ~menelaus->mask2) << 8;
+   & ~m->mask2) << 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-   & ~menelaus->mask1;
+   & ~m->mask1;
 
for_each_set_bit(i, &isr, 16) {
-   mutex_lock(&menelaus->lock);
-   menelaus_disable_irq(i);
-   menelaus_ack_irq(i);
-   handler = menelaus->handlers[i];
+   mutex_lock(&m->lock);
+   menelaus_disable_irq(m, i);
+   menelaus_ack_irq(m, i);
+   handler = m->handlers[i];
if (handler)
-   handler(menelaus);
-   menelaus_enable_irq(i);
-   mutex_unlock(&menelaus->lock);
+   handler(m);
+   menelaus_enable_irq(m, i);
+   mutex_unlock(&m->lock);
}
 
return IRQ_HANDLED;
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 05/13] mfd: menelaus: use for_each_set_bit()

[Felipe Balbi]

that macro just helps removing some extra
line of code and hides ffs() calls.

while at that, also fix a variable shadowing
bug where 'int irq' was being redeclared inside
inner loop while it was also argument to interrupt
handler.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 11dc4d3..9ccbb79 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,24 +795,22 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
 {
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
-   unsigned isr;
+   unsigned long isr;
+   unsigned long i;
 
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
& ~menelaus->mask2) << 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
& ~menelaus->mask1;
 
-   while (isr) {
-   int irq = fls(isr) - 1;
-   isr &= ~(1 << irq);
-
+   for_each_set_bit(i, &isr, 16) {
mutex_lock(&menelaus->lock);
-   menelaus_disable_irq(irq);
-   menelaus_ack_irq(irq);
-   handler = menelaus->handlers[irq];
+   menelaus_disable_irq(i);
+   menelaus_ack_irq(i);
+   handler = menelaus->handlers[i];
if (handler)
handler(menelaus);
-   menelaus_enable_irq(irq);
+   menelaus_enable_irq(i);
mutex_unlock(&menelaus->lock);
}
 
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 13/13] mfd: menelaus: remove unnecessary definition

[Felipe Balbi]

menelaus_i2c_driver isn't referenced on probe,
just remove that unnecessary line. No functional
changes.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index e7006e4..376f01d 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1206,8 +1206,6 @@ static inline void menelaus_rtc_init(struct menelaus_chip 
*m)
 
 /*---*/
 
-static struct i2c_driver menelaus_i2c_driver;
-
 static int menelaus_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
 {
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 10/13] mfd: menelaus: pass menelaus_chip argument to menelaus <-> time helpers

[Felipe Balbi]

time_to_menelaus() and menelaus_to_time() are
static and can easily receive a struct menelaus_chip
pointer argument.

After this patch, the_menelaus is only used on
exported functions which are currently being
used by board-n8x0.c.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 13d1cb0..aa3c579 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -857,10 +857,9 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
 
 #define RTC_HR_PM  (1 << 7)
 
-static void menelaus_to_time(char *regs, struct rtc_time *t)
+static void menelaus_to_time(struct menelaus_chip *m,
+   char *regs, struct rtc_time *t)
 {
-   struct menelaus_chip *m = the_menelaus;
-
t->tm_sec = bcd2bin(regs[0]);
t->tm_min = bcd2bin(regs[1]);
if (m->rtc_control & RTC_CTRL_MODE12) {
@@ -874,9 +873,9 @@ static void menelaus_to_time(char *regs, struct rtc_time *t)
t->tm_year = bcd2bin(regs[5]) + 100;
 }
 
-static int time_to_menelaus(struct rtc_time *t, int regnum)
+static int time_to_menelaus(struct menelaus_chip *m,
+   struct rtc_time *t, int regnum)
 {
-   struct menelaus_chip *m = the_menelaus;
int hour, status;
 
status = menelaus_write_reg(m, regnum++, bin2bcd(t->tm_sec));
@@ -944,7 +943,7 @@ static int menelaus_read_time(struct device *dev, struct 
rtc_time *t)
return -EIO;
}
 
-   menelaus_to_time(regs, t);
+   menelaus_to_time(m, regs, t);
t->tm_wday = bcd2bin(regs[6]);
 
return 0;
@@ -956,7 +955,7 @@ static int menelaus_set_time(struct device *dev, struct 
rtc_time *t)
int status;
 
/* write date and time registers */
-   status = time_to_menelaus(t, MENELAUS_RTC_SEC);
+   status = time_to_menelaus(m, t, MENELAUS_RTC_SEC);
if (status < 0)
return status;
status = menelaus_write_reg(m, MENELAUS_RTC_WKDAY, bin2bcd(t->tm_wday));
@@ -1001,7 +1000,7 @@ static int menelaus_read_alarm(struct device *dev, struct 
rtc_wkalrm *w)
return -EIO;
}
 
-   menelaus_to_time(regs, &w->time);
+   menelaus_to_time(m, regs, &w->time);
 
w->enabled = !!(m->rtc_control & RTC_CTRL_AL_EN);
 
@@ -1029,7 +1028,7 @@ static int menelaus_set_alarm(struct device *dev, struct 
rtc_wkalrm *w)
}
 
/* write alarm registers */
-   status = time_to_menelaus(&w->time, MENELAUS_RTC_AL_SEC);
+   status = time_to_menelaus(m, &w->time, MENELAUS_RTC_AL_SEC);
if (status < 0)
return status;
 
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 11/13] mfd: menelaus: start to use irqdomain

[Felipe Balbi]

introduce an irq_chip and irq_domain for
menelaus driver. Following patches will
convert uses to traditional request_threaded_irq().

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 109 +
 1 file changed, 109 insertions(+)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index aa3c579..295fe84 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -47,6 +48,7 @@
 #include 
 
 #define DRIVER_NAME"menelaus"
+#define MENELAUS_NR_IRQS   16
 
 #define MENELAUS_I2C_ADDRESS   0x72
 
@@ -168,11 +170,19 @@ struct menelaus_chip {
u8  rtc_control;
unsigneduie:1;
 #endif
+   int irq_base;
unsignedvcore_hw_mode:1;
u8  mask1, mask2;
+   u8  ack1, ack2;
+
void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
+
+   unsignedmask1_pending:1;
+   unsignedmask2_pending:1;
+   unsignedack1_pending:1;
+   unsignedack2_pending:1;
 };
 
 static struct menelaus_chip *the_menelaus;
@@ -235,6 +245,83 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int 
irq)
return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 << irq);
 }
 
+static void menelaus_irq_ack(struct irq_data *data)
+{
+   struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+   int irq = data->irq - m->irq_base;
+
+   if (irq > 7) {
+   m->ack2 |= BIT(irq);
+   m->ack2_pending = true;
+   } else {
+   m->ack1 |= BIT(irq);
+   m->ack1_pending = true;
+   }
+}
+
+static void menelaus_irq_mask(struct irq_data *data)
+{
+   struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+   int irq = data->irq - m->irq_base;
+
+   if (irq > 7) {
+   m->mask2 |= BIT(irq);
+   m->mask2_pending = true;
+   } else {
+   m->mask1 |= BIT(irq);
+   m->mask1_pending = true;
+   }
+}
+
+static void menelaus_irq_unmask(struct irq_data *data)
+{
+   struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+   int irq = data->irq - m->irq_base;
+
+   if (irq > 7) {
+   m->mask2 &= ~BIT(irq);
+   m->mask2_pending = true;
+   } else {
+   m->mask1 &= ~BIT(irq);
+   m->mask1_pending = true;
+   }
+}
+
+static void menelaus_irq_bus_lock(struct irq_data *data)
+{
+   struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+   mutex_lock(&m->lock);
+}
+
+static void menelaus_irq_bus_sync_unlock(struct irq_data *data)
+{
+   struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+   if (m->ack1_pending)
+   menelaus_write_reg(m, MENELAUS_INT_ACK1, m->ack1);
+
+   if (m->ack2_pending)
+   menelaus_write_reg(m, MENELAUS_INT_ACK2, m->ack2);
+
+   if (m->mask1_pending)
+   menelaus_write_reg(m, MENELAUS_INT_MASK1, m->mask1);
+
+   if (m->mask2_pending)
+   menelaus_write_reg(m, MENELAUS_INT_MASK2, m->mask2);
+
+   mutex_unlock(&m->lock);
+}
+
+static struct irq_chip menelaus_irq_chip = {
+   .name   = "menelaus",
+   .irq_ack= menelaus_irq_ack,
+   .irq_mask   = menelaus_irq_mask,
+   .irq_unmask = menelaus_irq_unmask,
+   .irq_bus_lock   = menelaus_irq_bus_lock,
+   .irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
+};
+
 /* Adds a handler for an interrupt. Does not run in interrupt context */
 static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
@@ -1186,8 +1273,11 @@ static int menelaus_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
 {
struct menelaus_chip*m;
+   struct device_node  *node = client->dev.of_node;
int rev = 0, val;
int err = 0;
+   int irq_base;
+   int i;
struct menelaus_platform_data *menelaus_pdata =
dev_get_platdata(&client->dev);
 
@@ -1206,6 +1296,25 @@ static int menelaus_probe(struct i2c_client *client,
the_menelaus = m;
m->client = client;
 
+   irq_base = irq_alloc_descs(-1, 0, MENELAUS_NR_IRQS, 0);
+   if (irq_base < 0) {
+   dev_err(&client->dev, "failed to allocate irq descs\n");
+   return irq_base;
+   }
+
+   irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0,
+ 

[PATCH 04/13] mfd: menelaus: remove unnecessary loop

[Felipe Balbi]

we can let irqs refire and give the scheduler
a chance to choose when we should be scheduled.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 43 +++
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 11d7d81..11dc4d3 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,30 +795,25 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
 {
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
-
-   while (1) {
-   unsigned isr;
-
-   isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-   & ~menelaus->mask2) << 8;
-   isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-   & ~menelaus->mask1;
-   if (!isr)
-   break;
-
-   while (isr) {
-   int irq = fls(isr) - 1;
-   isr &= ~(1 << irq);
-
-   mutex_lock(&menelaus->lock);
-   menelaus_disable_irq(irq);
-   menelaus_ack_irq(irq);
-   handler = menelaus->handlers[irq];
-   if (handler)
-   handler(menelaus);
-   menelaus_enable_irq(irq);
-   mutex_unlock(&menelaus->lock);
-   }
+   unsigned isr;
+
+   isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
+   & ~menelaus->mask2) << 8;
+   isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
+   & ~menelaus->mask1;
+
+   while (isr) {
+   int irq = fls(isr) - 1;
+   isr &= ~(1 << irq);
+
+   mutex_lock(&menelaus->lock);
+   menelaus_disable_irq(irq);
+   menelaus_ack_irq(irq);
+   handler = menelaus->handlers[irq];
+   if (handler)
+   handler(menelaus);
+   menelaus_enable_irq(irq);
+   mutex_unlock(&menelaus->lock);
}
 
return IRQ_HANDLED;
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 09/13] mfd: menelaus: pass menelaus_chip pointer to get/set voltage

[Felipe Balbi]

those functions are static and can easily receive
a menelaus_chip pointer argument.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 50 +++---
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8672d86..13d1cb0 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -463,10 +463,9 @@ struct menelaus_vtg_value {
u16 val;
 };
 
-static int menelaus_set_voltage(const struct menelaus_vtg *vtg, int mV,
-   int vtg_val, int mode)
+static int menelaus_set_voltage(struct menelaus_chip *m,
+   const struct menelaus_vtg *vtg, int mV, int vtg_val, int mode)
 {
-   struct menelaus_chip *m = the_menelaus;
struct i2c_client *c = m->client;
int val, ret;
 
@@ -498,8 +497,8 @@ out:
return ret;
 }
 
-static int menelaus_get_vtg_value(int vtg, const struct menelaus_vtg_value 
*tbl,
- int n)
+static int menelaus_get_vtg_value(struct menelaus_chip *m,
+   int vtg, const struct menelaus_vtg_value *tbl, int n)
 {
int i;
 
@@ -546,7 +545,7 @@ int menelaus_set_vcore_sw(unsigned int mV)
struct i2c_client *c = m->client;
int val, ret;
 
-   val = menelaus_get_vtg_value(mV, vcore_values,
+   val = menelaus_get_vtg_value(m, mV, vcore_values,
 ARRAY_SIZE(vcore_values));
if (val < 0)
return -EINVAL;
@@ -570,11 +569,11 @@ int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned 
int floor_mV)
struct i2c_client *c = m->client;
int fval, rval, val, ret;
 
-   rval = menelaus_get_vtg_value(roof_mV, vcore_values,
+   rval = menelaus_get_vtg_value(m, roof_mV, vcore_values,
  ARRAY_SIZE(vcore_values));
if (rval < 0)
return -EINVAL;
-   fval = menelaus_get_vtg_value(floor_mV, vcore_values,
+   fval = menelaus_get_vtg_value(m, floor_mV, vcore_values,
  ARRAY_SIZE(vcore_values));
if (fval < 0)
return -EINVAL;
@@ -619,15 +618,16 @@ static const struct menelaus_vtg_value vmem_values[] = {
 
 int menelaus_set_vmem(unsigned int mV)
 {
+   struct menelaus_chip *m = the_menelaus;
int val;
 
if (mV == 0)
-   return menelaus_set_voltage(&vmem_vtg, 0, 0, 0);
+   return menelaus_set_voltage(m, &vmem_vtg, 0, 0, 0);
 
-   val = menelaus_get_vtg_value(mV, vmem_values, ARRAY_SIZE(vmem_values));
+   val = menelaus_get_vtg_value(m, mV, vmem_values, 
ARRAY_SIZE(vmem_values));
if (val < 0)
return -EINVAL;
-   return menelaus_set_voltage(&vmem_vtg, mV, val, 0x02);
+   return menelaus_set_voltage(m, &vmem_vtg, mV, val, 0x02);
 }
 EXPORT_SYMBOL(menelaus_set_vmem);
 
@@ -648,15 +648,16 @@ static const struct menelaus_vtg_value vio_values[] = {
 
 int menelaus_set_vio(unsigned int mV)
 {
+   struct menelaus_chip *m = the_menelaus;
int val;
 
if (mV == 0)
-   return menelaus_set_voltage(&vio_vtg, 0, 0, 0);
+   return menelaus_set_voltage(m, &vio_vtg, 0, 0, 0);
 
-   val = menelaus_get_vtg_value(mV, vio_values, ARRAY_SIZE(vio_values));
+   val = menelaus_get_vtg_value(m, mV, vio_values, ARRAY_SIZE(vio_values));
if (val < 0)
return -EINVAL;
-   return menelaus_set_voltage(&vio_vtg, mV, val, 0x02);
+   return menelaus_set_voltage(m, &vio_vtg, mV, val, 0x02);
 }
 EXPORT_SYMBOL(menelaus_set_vio);
 
@@ -689,6 +690,7 @@ static const struct menelaus_vtg vdcdc3_vtg = {
 
 int menelaus_set_vdcdc(int dcdc, unsigned int mV)
 {
+   struct menelaus_chip *m = the_menelaus;
const struct menelaus_vtg *vtg;
int val;
 
@@ -700,13 +702,13 @@ int menelaus_set_vdcdc(int dcdc, unsigned int mV)
vtg = &vdcdc3_vtg;
 
if (mV == 0)
-   return menelaus_set_voltage(vtg, 0, 0, 0);
+   return menelaus_set_voltage(m, vtg, 0, 0, 0);
 
-   val = menelaus_get_vtg_value(mV, vdcdc_values,
+   val = menelaus_get_vtg_value(m, mV, vdcdc_values,
 ARRAY_SIZE(vdcdc_values));
if (val < 0)
return -EINVAL;
-   return menelaus_set_voltage(vtg, mV, val, 0x03);
+   return menelaus_set_voltage(m, vtg, mV, val, 0x03);
 }
 
 static const struct menelaus_vtg_value vmmc_values[] = {
@@ -726,15 +728,16 @@ static const struct menelaus_vtg vmmc_vtg = {
 
 int menelaus_set_vmmc(unsigned int mV)
 {
+   struct menelaus_chip *m = the_menelaus;
int val;
 
if (mV == 0)
-   return menelaus_set_voltage(&vmmc_vtg, 0, 0, 0);
+   return menelaus_set_voltage(m, &vmmc_vtg, 0, 0, 0);
 
-   val = menelaus_get_vtg_value(mV, vmmc_values, ARRAY_SIZE(vmmc_values));
+   val = menelaus_get_vtg_value(

[PATCH 08/13] mfd: menelaus: pass menelaus_chip pointer to add/remove irq functions

[Felipe Balbi]

those functions are static and can receive a
menelaus_chip pointer very easily.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 57 ++
 1 file changed, 30 insertions(+), 27 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8796e5e..8672d86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -236,28 +236,28 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int 
irq)
 }
 
 /* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(int irq,
+static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
 {
int ret = 0;
 
-   mutex_lock(&the_menelaus->lock);
-   the_menelaus->handlers[irq] = handler;
-   ret = menelaus_enable_irq(the_menelaus, irq);
-   mutex_unlock(&the_menelaus->lock);
+   mutex_lock(&m->lock);
+   m->handlers[irq] = handler;
+   ret = menelaus_enable_irq(m, irq);
+   mutex_unlock(&m->lock);
 
return ret;
 }
 
 /* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(int irq)
+static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
 {
int ret = 0;
 
-   mutex_lock(&the_menelaus->lock);
-   ret = menelaus_disable_irq(the_menelaus, irq);
-   the_menelaus->handlers[irq] = NULL;
-   mutex_unlock(&the_menelaus->lock);
+   mutex_lock(&m->lock);
+   ret = menelaus_disable_irq(m, irq);
+   m->handlers[irq] = NULL;
+   mutex_unlock(&m->lock);
 
return ret;
 }
@@ -412,23 +412,24 @@ EXPORT_SYMBOL(menelaus_set_mmc_slot);
 int menelaus_register_mmc_callback(void (*callback)(void *data, u8 card_mask),
   void *data)
 {
+   struct menelaus_chip *m = the_menelaus;
int ret = 0;
 
-   the_menelaus->mmc_callback_data = data;
-   the_menelaus->mmc_callback = callback;
-   ret = menelaus_add_irq_work(MENELAUS_MMC_S1CD_IRQ,
+   m->mmc_callback_data = data;
+   m->mmc_callback = callback;
+   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
menelaus_mmc_cd_work);
if (ret < 0)
return ret;
-   ret = menelaus_add_irq_work(MENELAUS_MMC_S2CD_IRQ,
+   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
menelaus_mmc_cd_work);
if (ret < 0)
return ret;
-   ret = menelaus_add_irq_work(MENELAUS_MMC_S1D1_IRQ,
+   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
menelaus_mmc_cd_work);
if (ret < 0)
return ret;
-   ret = menelaus_add_irq_work(MENELAUS_MMC_S2D1_IRQ,
+   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2D1_IRQ,
menelaus_mmc_cd_work);
 
return ret;
@@ -437,13 +438,15 @@ EXPORT_SYMBOL(menelaus_register_mmc_callback);
 
 void menelaus_unregister_mmc_callback(void)
 {
-   menelaus_remove_irq_work(MENELAUS_MMC_S1CD_IRQ);
-   menelaus_remove_irq_work(MENELAUS_MMC_S2CD_IRQ);
-   menelaus_remove_irq_work(MENELAUS_MMC_S1D1_IRQ);
-   menelaus_remove_irq_work(MENELAUS_MMC_S2D1_IRQ);
+   struct menelaus_chip *m = the_menelaus;
+
+   menelaus_remove_irq_work(m, MENELAUS_MMC_S1CD_IRQ);
+   menelaus_remove_irq_work(m, MENELAUS_MMC_S2CD_IRQ);
+   menelaus_remove_irq_work(m, MENELAUS_MMC_S1D1_IRQ);
+   menelaus_remove_irq_work(m, MENELAUS_MMC_S2D1_IRQ);
 
-   the_menelaus->mmc_callback = NULL;
-   the_menelaus->mmc_callback_data = NULL;
+   m->mmc_callback = NULL;
+   m->mmc_callback_data = NULL;
 }
 EXPORT_SYMBOL(menelaus_unregister_mmc_callback);
 
@@ -1070,8 +1073,8 @@ static int menelaus_ioctl(struct device *dev, unsigned 
cmd, unsigned long arg)
case RTC_UIE_ON:
if (m->uie)
return 0;
-   status = menelaus_remove_irq_work(MENELAUS_RTCTMR_IRQ);
-   status = menelaus_add_irq_work(MENELAUS_RTCTMR_IRQ,
+   status = menelaus_remove_irq_work(m, MENELAUS_RTCTMR_IRQ);
+   status = menelaus_add_irq_work(m, MENELAUS_RTCTMR_IRQ,
menelaus_rtc_update_work);
if (status == 0)
m->uie = 1;
@@ -1079,7 +1082,7 @@ static int menelaus_ioctl(struct device *dev, unsigned 
cmd, unsigned long arg)
case RTC_UIE_OFF:
if (!m->uie)
return 0;
-   status = menelaus_remove_irq_work(MENELAUS_RTCTMR_IRQ);
+   status = menelaus_remove_irq_work(m, MENELAUS_RTCTMR_IRQ);
if (status == 0)
m->uie = 0;
return status;
@@ -1127,7 +1130,7 @@ static inline void menelaus_rtc_init(struct menelaus_chip 
*m)
 
/* support RTC alarm; it can issue wakeups */
i

[PATCH 12/13] mfd: menelaus: switch all children to threaded_irq

[Felipe Balbi]

now that we have our own irq_chip, all children
can use traditional request_threaded_irq().

While at that, also remove so functions which
became unused.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 161 +++--
 1 file changed, 50 insertions(+), 111 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 295fe84..e7006e4 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -175,7 +175,6 @@ struct menelaus_chip {
u8  mask1, mask2;
u8  ack1, ack2;
 
-   void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
 
@@ -209,42 +208,6 @@ static int menelaus_read_reg(struct menelaus_chip *m, int 
reg)
return val;
 }
 
-static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
-{
-   if (irq > 7) {
-   irq -= 8;
-   m->mask2 &= ~(1 << irq);
-   return menelaus_write_reg(m, MENELAUS_INT_MASK2,
-   m->mask2);
-   } else {
-   m->mask1 &= ~(1 << irq);
-   return menelaus_write_reg(m, MENELAUS_INT_MASK1,
-   m->mask1);
-   }
-}
-
-static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
-{
-   if (irq > 7) {
-   irq -= 8;
-   m->mask2 |= (1 << irq);
-   return menelaus_write_reg(m, MENELAUS_INT_MASK2,
-   m->mask2);
-   } else {
-   m->mask1 |= (1 << irq);
-   return menelaus_write_reg(m, MENELAUS_INT_MASK1,
-   m->mask1);
-   }
-}
-
-static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
-{
-   if (irq > 7)
-   return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 << (irq - 8));
-   else
-   return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 << irq);
-}
-
 static void menelaus_irq_ack(struct irq_data *data)
 {
struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
@@ -322,47 +285,15 @@ static struct irq_chip menelaus_irq_chip = {
.irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
 };
 
-/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
-   void (*handler)(struct menelaus_chip *))
-{
-   int ret = 0;
-
-   mutex_lock(&m->lock);
-   m->handlers[irq] = handler;
-   ret = menelaus_enable_irq(m, irq);
-   mutex_unlock(&m->lock);
-
-   return ret;
-}
-
-/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
-{
-   int ret = 0;
-
-   mutex_lock(&m->lock);
-   ret = menelaus_disable_irq(m, irq);
-   m->handlers[irq] = NULL;
-   mutex_unlock(&m->lock);
-
-   return ret;
-}
-
-/*
- * Gets scheduled when a card detect interrupt happens. Note that in some cases
- * this line is wired to card cover switch rather than the card detect switch
- * in each slot. In this case the cards are not seen by menelaus.
- * FIXME: Add handling for D1 too
- */
-static void menelaus_mmc_cd_work(struct menelaus_chip *m)
+static irqreturn_t menelaus_mmc_cd_irq(int irq, void *_m)
 {
-   int reg;
+   struct menelaus_chip *m = _m;
unsigned char card_mask = 0;
+   int reg;
 
reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg < 0)
-   return;
+   return IRQ_NONE;
 
if (!(reg & 0x1))
card_mask |= MCT_PIN_ST_S1_CD_ST;
@@ -373,6 +304,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip *m)
if (m->mmc_callback)
m->mmc_callback(m->mmc_callback_data,
  card_mask);
+
+   return IRQ_HANDLED;
 }
 
 /*
@@ -504,20 +437,25 @@ int menelaus_register_mmc_callback(void (*callback)(void 
*data, u8 card_mask),
 
m->mmc_callback_data = data;
m->mmc_callback = callback;
-   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
-   menelaus_mmc_cd_work);
+
+   ret = request_threaded_irq(MENELAUS_MMC_S1CD_IRQ + m->irq_base,
+   NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+   "mmc_s1cd", m);
if (ret < 0)
return ret;
-   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
-   menelaus_mmc_cd_work);
+   ret = request_threaded_irq(MENELAUS_MMC_S2CD_IRQ + m->irq_base,
+   NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+   "mmc_s2cd", m);
if (ret < 0)
return ret;
-   ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
-   menelaus_mmc_cd_work);
+   ret =

[PATCH 01/13] mfd: menelaus: drop __exit section annotation

[Felipe Balbi]

we could build that as a driver.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index ad25bfa..975ff9e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1262,7 +1262,7 @@ fail:
return err;
 }
 
-static int __exit menelaus_remove(struct i2c_client *client)
+static int menelaus_remove(struct i2c_client *client)
 {
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
 
@@ -1283,7 +1283,7 @@ static struct i2c_driver menelaus_i2c_driver = {
.name   = DRIVER_NAME,
},
.probe  = menelaus_probe,
-   .remove = __exit_p(menelaus_remove),
+   .remove = menelaus_remove,
.id_table   = menelaus_id,
 };
 
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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 03/13] mfd: menelaus: convert to threaded irq

[Felipe Balbi]

we don't need that extra workqueue when we
have generic threaded irq handlers support.

Signed-off-by: Felipe Balbi 
---
 drivers/mfd/menelaus.c | 29 -
 1 file changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8bd97ca..11d7d81 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -161,12 +160,9 @@
 #define MCT_PIN_ST_S1_CD_ST(1 << 0)
 #define MCT_PIN_ST_S2_CD_ST(1 << 1)
 
-static void menelaus_work(struct work_struct *_menelaus);
-
 struct menelaus_chip {
struct mutexlock;
struct i2c_client   *client;
-   struct work_struct  work;
 #ifdef CONFIG_RTC_DRV_TWL92330
struct rtc_device   *rtc;
u8  rtc_control;
@@ -795,11 +791,9 @@ out:
 
 /*---*/
 
-/* Handles Menelaus interrupts. Does not run in interrupt context */
-static void menelaus_work(struct work_struct *_menelaus)
+static irqreturn_t menelaus_irq(int irq, void *_menelaus)
 {
-   struct menelaus_chip *menelaus =
-   container_of(_menelaus, struct menelaus_chip, work);
+   struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
 
while (1) {
@@ -826,18 +820,6 @@ static void menelaus_work(struct work_struct *_menelaus)
mutex_unlock(&menelaus->lock);
}
}
-   enable_irq(menelaus->client->irq);
-}
-
-/*
- * We cannot use I2C in interrupt context, so we just schedule work.
- */
-static irqreturn_t menelaus_irq(int irq, void *_menelaus)
-{
-   struct menelaus_chip *menelaus = _menelaus;
-
-   disable_irq_nosync(irq);
-   (void)schedule_work(&menelaus->work);
 
return IRQ_HANDLED;
 }
@@ -1225,8 +1207,8 @@ static int menelaus_probe(struct i2c_client *client,
menelaus_write_reg(MENELAUS_MCT_CTRL1, 0x73);
 
if (client->irq > 0) {
-   err = request_irq(client->irq, menelaus_irq, 0,
- DRIVER_NAME, menelaus);
+   err = request_threaded_irq(client->irq, NULL, menelaus_irq,
+   IRQF_ONESHOT, DRIVER_NAME, menelaus);
if (err) {
dev_dbg(&client->dev,  "can't get IRQ %d, err %d\n",
client->irq, err);
@@ -1235,7 +1217,6 @@ static int menelaus_probe(struct i2c_client *client,
}
 
mutex_init(&menelaus->lock);
-   INIT_WORK(&menelaus->work, menelaus_work);
 
pr_info("Menelaus rev %d.%d\n", rev >> 4, rev & 0x0f);
 
@@ -1258,7 +1239,6 @@ static int menelaus_probe(struct i2c_client *client,
return 0;
 fail:
free_irq(client->irq, menelaus);
-   flush_work(&menelaus->work);
return err;
 }
 
@@ -1267,7 +1247,6 @@ static int menelaus_remove(struct i2c_client *client)
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
 
free_irq(client->irq, menelaus);
-   flush_work(&menelaus->work);
the_menelaus = NULL;
return 0;
 }
-- 
1.8.4.GIT

--
To unsubscribe from this list: send the line "unsubscribe 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] ARM: dts: omap3-beagle: Add omap-twl4030 audio support

[Jarkko Nikula]

This adds typical McBSP2-TWL4030 audio description to the legacy
Beagle Board.

Signed-off-by: Jarkko Nikula 
---
 arch/arm/boot/dts/omap3-beagle.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aaacc68..1912c421e246 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -61,6 +61,14 @@
vcc-supply = <&hsusb2_power>;
};
 
+   sound {
+   compatible = "ti,omap-twl4030";
+   ti,model = "omap3beagle";
+
+   ti,mcbsp = <&mcbsp2>;
+   ti,codec = <&twl_audio>;
+   };
+
gpio_keys {
compatible = "gpio-keys";
 
@@ -120,6 +128,12 @@
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
+
+   twl_audio: audio {
+   compatible = "ti,twl4030-audio";
+   codec {
+   };
+   };
};
 };
 
-- 
1.8.4.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 1/8] net: smc91x: Fix device tree based configuration so it's usable

[Tony Lindgren]

* Tony Lindgren  [131116 07:17]:
>
> Here's what I was thinking with the reg-io-width-mask. Anybody
> have comments on using reg-io-width vs reg-io-width-mask?
...

> --- a/drivers/net/ethernet/smsc/smc91x.c
> +++ b/drivers/net/ethernet/smsc/smc91x.c
> @@ -,11 +2234,31 @@ static int smc_drv_probe(struct platform_device *pdev)
>*/
>  
>   lp = netdev_priv(ndev);
> + lp->cfg.flags = 0;
>  
>   if (pd) {
>   memcpy(&lp->cfg, pd, sizeof(lp->cfg));
>   lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
> - } else {
> + }
> +
> +#if IS_BUILTIN(CONFIG_OF)
> + match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
> + if (match) {
> + u32 val;
> +
> + of_property_read_u32(np, "reg-io-width", &val);
> + if (val == 0)
> + lp->cfg.flags |= SMC91X_USE_16BIT;
> + if (val & 1)
> + lp->cfg.flags |= SMC91X_USE_8BIT;
> + if (val & 2)
> + lp->cfg.flags |= SMC91X_USE_16BIT;
> + if (val & 4)
> + lp->cfg.flags |= SMC91X_USE_32BIT;
> + }
> +#endif
> +
> + if (!pd && !match) {
>   lp->cfg.flags |= (SMC_CAN_USE_8BIT)  ? SMC91X_USE_8BIT  : 0;
>   lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
>   lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;

Looks this patch is missing the check for the return value for
of_property_read_u32(), will repost this patch separately as the
others in this series are out of the way now.

Regards,

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

RE: [PATCH v2 1/3] power_supply: Add power_supply notifier

[Tc, Jenny]

> Subject: [PATCH v2 1/3] power_supply: Add power_supply notifier
> 
> This patch adds a notifier chain to the power_supply.
> This notifier helps drivers in other subsystem to listen to changes in power 
> supply
> subsystem. This would help to take some actions in those drivers on changing 
> the power
> supply properties.
> One such scenario is to increase/decrease system performance based on the 
> battery
> capacity/voltage. Another scenario is to adjust the h/w peak current detection
> voltage/current thresholds based on battery voltage/capacity. The notifier 
> helps drivers to
> listen to changes in power_suppy susbystem without polling the power_supply 
> properties
> 
> Signed-off-by: Jenny TC 
> Signed-off-by: Pali Rohár 
> ---

Acked-by: Jenny TC 

Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Tony Lindgren]

* Balaji T K  [131127 09:00]:
> On Tuesday 26 November 2013 04:16 AM, Tony Lindgren wrote:
> >
> >This patch we can now make a bit more generic with the recent addition
> >of interrupts-extended property that's now merged in mainline tree :)
> >
> >We can optionally pass two interrupts to omap_hsmmc.c where the second
> >interrupt is either the pinctrl-single wake-up interrupt, or the GPIO
> >interrupt.
> >
> >Both the iochain wake interrupt or the GPIO interrupt are available with
> >request_irq as long as configured in the .dts file. And can both use the
> >SDIO interrupt handler. The only difference is that the GPIO wake-up
> >still needs to do the dynamic remuxing of pins.
> >
> >So omap3 can use:
> >
> >mmc: mmc@4800abcd {
> > compatible = "ti,omap3-hsmmc";
> > ...
> > interrupts-extended = <&intc 83 &omap3_pmx_core 0x11a>;
> > ...
> >};
> >
> >And am33xx can use:
> >
> >mmc: mmc@4810abcd {
> > compatible = "ti,omap33xx-hsmmc";
> > ...
> > interrupts-extended = <&intc 64 &gpio3 28>;
> > ...
> >};
> >
> Hi Tony,
> 
> I made similar changes for omap4 panda-es as below, but get WARNING for no 
> irq domain [1]
> omap3 beagle seems to be OK.
> 
>   mmc1: mmc@4809c000 {
>   compatible = "ti,omap4-hsmmc";
>   reg = <0x4809c000 0x400>;
> + interrupts-extended = <&gic GIC_SPI 83 
> IRQ_TYPE_LEVEL_HIGH &omap4_pmx_core 0xa8>;
>   ti,hwmods = "mmc1";
> 
> [0.338745] OMAP GPIO hardware version 0.1
> [0.348266] omap-gpmc 5000.gpmc: GPMC revision 6.0
> [0.354339] irq: no irq domain found for /ocp/pinmux@4a100040 !
> [0.354339] [ cut here ]
> [0.354370] WARNING: CPU: 1 PID: 1 at 
> /home/a0393241/git/lo/drivers/of/platform.c:171 of_device_alloc+0x158/0x16c()
> [0.354370] Modules linked in:
> [0.354400] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
> 3.13.0-rc1-00141-g8ae516a-dirty #36
> [0.354431] [] (unwind_backtrace+0x0/0xf0) from [] 
> (show_stack+0x10/0x14)
> [0.354431] [] (show_stack+0x10/0x14) from [] 
> (dump_stack+0x78/0x94)
> [0.354461] [] (dump_stack+0x78/0x94) from [] 
> (warn_slowpath_common+0x6c/0x90)
> [0.354492] [] (warn_slowpath_common+0x6c/0x90) from 
> [] (warn_slowpath_null+0x1c/0x24)
> [0.354492] [] (warn_slowpath_null+0x1c/0x24) from [] 
> (of_device_alloc+0x158/0x16c)
> [0.354522] [] (of_device_alloc+0x158/0x16c) from [] 
> (of_platform_device_create_pdata+0x30/0x94)
> [0.354522] [] (of_platform_device_create_pdata+0x30/0x94) from 
> [] (of_platform_bus_create+0xe0/0x164)
> [0.354553] [] (of_platform_bus_create+0xe0/0x164) from 
> [] (of_platform_bus_create+0x13c/0x164)
> [0.354553] [] (of_platform_bus_create+0x13c/0x164) from 
> [] (of_platform_populate+0x5c/0x9c)
> [0.354583] [] (of_platform_populate+0x5c/0x9c) from 
> [] (pdata_quirks_init+0x28/0x70)
> [0.354614] [] (pdata_quirks_init+0x28/0x70) from [] 
> (customize_machine+0x1c/0x40)
> [0.354614] [] (customize_machine+0x1c/0x40) from [] 
> (do_one_initcall+0xec/0x150)
> [0.354644] [] (do_one_initcall+0xec/0x150) from [] 
> (kernel_init_freeable+0xfc/0x1cc)
> [0.354644] [] (kernel_init_freeable+0xfc/0x1cc) from 
> [] (kernel_init+0x8/0x118)
> [0.354675] [] (kernel_init+0x8/0x118) from [] 
> (ret_from_fork+0x14/0x2c)
> [0.354766] ---[ end trace 7067c7558a4cd015 ]---

Yeah that's nasty looking but harmless, so you can ignore that for now :)

See the thread "[PATCH] of/platform: Fix no irq domain found errors
when populating interrupts" on LAKML for attempted fix for that.

Regards,

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

Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Balaji T K]

On Tuesday 26 November 2013 04:16 AM, Tony Lindgren wrote:

* Andreas Fenkart  [131125 05:30]:

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -452,10 +475,23 @@ static int omap_hsmmc_gpio_init(struct 
omap_mmc_platform_data *pdata)
} else
pdata->slots[0].gpio_wp = -EINVAL;

+   if (gpio_is_valid(pdata->slots[0].gpio_cirq)) {
+   ret = gpio_request_one(pdata->slots[0].gpio_cirq, GPIOF_DIR_IN,
+  "sdio_cirq");
+   if (ret)
+   goto err_free_ro;
+
+   } else {
+   pdata->slots[0].gpio_cirq = -EINVAL;
+   }
+
+
return 0;

+err_free_ro:
+   if (gpio_is_valid(pdata->slots[0].gpio_wp))
  err_free_wp:
-   gpio_free(pdata->slots[0].gpio_wp);
+   gpio_free(pdata->slots[0].gpio_wp);
  err_free_cd:
if (gpio_is_valid(pdata->slots[0].switch_pin))
  err_free_sp:


This patch we can now make a bit more generic with the recent addition
of interrupts-extended property that's now merged in mainline tree :)

We can optionally pass two interrupts to omap_hsmmc.c where the second
interrupt is either the pinctrl-single wake-up interrupt, or the GPIO
interrupt.

Both the iochain wake interrupt or the GPIO interrupt are available with
request_irq as long as configured in the .dts file. And can both use the
SDIO interrupt handler. The only difference is that the GPIO wake-up
still needs to do the dynamic remuxing of pins.

So omap3 can use:

mmc: mmc@4800abcd {
compatible = "ti,omap3-hsmmc";
...
interrupts-extended = <&intc 83 &omap3_pmx_core 0x11a>;
...
};

And am33xx can use:

mmc: mmc@4810abcd {
compatible = "ti,omap33xx-hsmmc";
...
interrupts-extended = <&intc 64 &gpio3 28>;
...
};


Hi Tony,

I made similar changes for omap4 panda-es as below, but get WARNING for no irq 
domain [1]
omap3 beagle seems to be OK.

mmc1: mmc@4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
+   interrupts-extended = <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH 
&omap4_pmx_core 0xa8>;
ti,hwmods = "mmc1";

[0.338745] OMAP GPIO hardware version 0.1
[0.348266] omap-gpmc 5000.gpmc: GPMC revision 6.0
[0.354339] irq: no irq domain found for /ocp/pinmux@4a100040 !
[0.354339] [ cut here ]
[0.354370] WARNING: CPU: 1 PID: 1 at 
/home/a0393241/git/lo/drivers/of/platform.c:171 of_device_alloc+0x158/0x16c()
[0.354370] Modules linked in:
[0.354400] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
3.13.0-rc1-00141-g8ae516a-dirty #36
[0.354431] [] (unwind_backtrace+0x0/0xf0) from [] 
(show_stack+0x10/0x14)
[0.354431] [] (show_stack+0x10/0x14) from [] 
(dump_stack+0x78/0x94)
[0.354461] [] (dump_stack+0x78/0x94) from [] 
(warn_slowpath_common+0x6c/0x90)
[0.354492] [] (warn_slowpath_common+0x6c/0x90) from [] 
(warn_slowpath_null+0x1c/0x24)
[0.354492] [] (warn_slowpath_null+0x1c/0x24) from [] 
(of_device_alloc+0x158/0x16c)
[0.354522] [] (of_device_alloc+0x158/0x16c) from [] 
(of_platform_device_create_pdata+0x30/0x94)
[0.354522] [] (of_platform_device_create_pdata+0x30/0x94) from 
[] (of_platform_bus_create+0xe0/0x164)
[0.354553] [] (of_platform_bus_create+0xe0/0x164) from 
[] (of_platform_bus_create+0x13c/0x164)
[0.354553] [] (of_platform_bus_create+0x13c/0x164) from 
[] (of_platform_populate+0x5c/0x9c)
[0.354583] [] (of_platform_populate+0x5c/0x9c) from [] 
(pdata_quirks_init+0x28/0x70)
[0.354614] [] (pdata_quirks_init+0x28/0x70) from [] 
(customize_machine+0x1c/0x40)
[0.354614] [] (customize_machine+0x1c/0x40) from [] 
(do_one_initcall+0xec/0x150)
[0.354644] [] (do_one_initcall+0xec/0x150) from [] 
(kernel_init_freeable+0xfc/0x1cc)
[0.354644] [] (kernel_init_freeable+0xfc/0x1cc) from [] 
(kernel_init+0x8/0x118)
[0.354675] [] (kernel_init+0x8/0x118) from [] 
(ret_from_fork+0x14/0x2c)
[0.354766] ---[ end trace 7067c7558a4cd015 ]---
[0.366607] platform 4b501000.aes: Cannot lookup hwmod 'aes'
[0.367034] platform 480a5000.des: Cannot lookup hwmod 'des'
[0.374481] No ATAGs?
[0.374511] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint 
registers.
[0.374542] hw-breakpoint: maximum watchpoint size is 4 bytes.
[0.377502] OMAP DMA hardware revision 0.0
[0.415100] bio: create slab  at 0
[0.417388] edma-dma-engine edma-dma-engine.0: Can't allocate PaRAM dummy 
slot
[0.417419] edma-dma-engine: probe of edma-dma-engine.0 failed with error -5
[0.460754] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver
[0.462249] hsusb1_vbus: 3300 mV

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

Re: [PATCH 1/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx

[Tony Lindgren]

* Balaji T K  [131127 08:30]:
> On Wednesday 27 November 2013 03:25 AM, Tony Lindgren wrote:
> >* Dan Murphy  [131121 09:28]:
> >>On 11/21/2013 10:58 AM, Tony Lindgren wrote:
> >>>* Balaji T K  [131121 05:51]:
> pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
> and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.
> 
> Fix the following error message:
> pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
> pinctrl-single 4a31e040.pinmux: could not add functions for 
> pinmux_wl12xx_pins 56x
> >>
> >>Why is the led pins moved then?
> >
> >Heh the patch just looks that way, looking at the curly brackets
> >thing do get moved properly.
> >
> SDIO card is not detected after moving pin mux to omap4_pmx_core since
> sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO 
> card.
> >>>Cool, does this fix the issue with the WLAN not coming up after a warm 
> >>>reset
> >>>on panda?
> >
> >Also commit f446043f1aa7 (regulator: fixed: fix regulator_list_voltage() for
> >regression) is needed that recently got merged. But with v3.13-rc1 +
> >f446043f1aa7 + this patch no luck whatsoever bringing up the wl12xx so there
> >must be also some regression somewhere from v3.12 on that?
> >
> Hi Tony,
> 
> I tried loading wl12xx as modules on latest base as yours with
> ti-connectivity/wl127x-fw-5-sr.bin firmware in place and I could connect
> and run iperf.

Oh OK I must have missed something then.

Does it now work after a warm reboot too? And after bringing the interface
down with "ifconfig wlan0 down" followed by "ifconfig wlan0 up"?

Regards,

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

Re: [PATCH 1/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx

[Balaji T K]

On Wednesday 27 November 2013 03:25 AM, Tony Lindgren wrote:

* Dan Murphy  [131121 09:28]:

On 11/21/2013 10:58 AM, Tony Lindgren wrote:

* Balaji T K  [131121 05:51]:

pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.

Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 
56x


Why is the led pins moved then?


Heh the patch just looks that way, looking at the curly brackets
thing do get moved properly.


SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.

Cool, does this fix the issue with the WLAN not coming up after a warm reset
on panda?


Also commit f446043f1aa7 (regulator: fixed: fix regulator_list_voltage() for
regression) is needed that recently got merged. But with v3.13-rc1 +
f446043f1aa7 + this patch no luck whatsoever bringing up the wl12xx so there
must be also some regression somewhere from v3.12 on that?


Hi Tony,

I tried loading wl12xx as modules on latest base as yours with
ti-connectivity/wl127x-fw-5-sr.bin firmware in place and I could connect
and run iperf.


Regards,

Tony


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

Re: [PATCH 1/2] ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx

[Balaji T K]

On Thursday 21 November 2013 10:57 PM, Dan Murphy wrote:

On 11/21/2013 10:58 AM, Tony Lindgren wrote:

* Balaji T K  [131121 05:51]:

pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.

Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 
56x


Why is the led pins moved then?

Hi Dan,

I just moved 27 lines (wl12xx_pins, wl12xx_gpio) up, git diff generated smaller
diff stat by moving 10 line of code (led_wkgpio_pins) further down :-)




SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.

Cool, does this fix the issue with the WLAN not coming up after a warm reset
on panda?

Regards,

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





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

musb host mode suspend mode

[Michael Trimarchi]

Hi Felipe,

I'm trying to understand how dpll_usb and vbus should work in suspend mode.
What I have in my kernel 3.0.31 from ti is that if I suspend the device with id
pin ground and no device connected I have:

- vbus 5v
- dpll_usb locked problem so l3domain can not suspend

If I have the id pin floating (device mode) and no device connected I
can suspend
without problem. I'm not care about remote wakeup and I would like to understand
what is the reason of having no complete suspend in host mode. Can you give
some insight?

Michael
--
To unsubscribe from this list: send the line "unsubscribe 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] ARM: OMAP4/highbank: Flush L2 cache before disabling

[Taras Kondratiuk]

Kexec disables outer cache before jumping to reboot code, but it doesn't
flush it explicitly. Flush is done implicitly inside of l2x0_disable().
But some SoC's override default .disable handler and don't flush cache.
This may lead to a corrupted memory during Kexec reboot on these
platforms.

This patch adds cache flush inside of OMAP4 and Highbank outer_cache.disable()
handlers to make it consistent with default l2x0_disable().

Acked-by: Rob Herring 
Acked-by: Santosh Shilimkar 
Acked-by: Tony Lindgren 
Signed-off-by: Taras Kondratiuk 
---
I was not aware about Russell's patch tracker process, so this patch
was not hooked there. Highbank moved to PSCI since then, so patch
has to be slightly modified.

Rob, are you still ok with this patch?

v1..v2: Removed changes in highbank_suspend_finish since after
commit dd68eb0 "ARM: highbank: adapt to use ARM PSCI calls"
cache is not explicitly disabled there.

v1: http://www.spinics.net/lists/linux-omap/msg98318.html

RFC v2: https://patchwork.kernel.org/patch/2990231/
Make the fix specific to platforms that don't use
l2x0_disable().
RFC v1: https://patchwork.kernel.org/patch/2974431/

Based on v3.13-rc1
---
 arch/arm/mach-highbank/highbank.c  |1 +
 arch/arm/mach-omap2/omap4-common.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-highbank/highbank.c 
b/arch/arm/mach-highbank/highbank.c
index b3d7e56..ae17150 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -50,6 +50,7 @@ static void __init highbank_scu_map_io(void)
 
 static void highbank_l2x0_disable(void)
 {
+   outer_flush_all();
/* Disable PL310 L2 Cache controller */
highbank_smc1(0x102, 0x0);
 }
diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index b39efd4..c0ab9b2 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -162,6 +162,7 @@ void __iomem *omap4_get_l2cache_base(void)
 
 static void omap4_l2x0_disable(void)
 {
+   outer_flush_all();
/* Disable PL310 L2 Cache controller */
omap_smc1(0x102, 0x0);
 }
-- 
1.7.9.5

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

Re: HYP Kernel boot requirements

[Lorenzo Pieralisi]

On Tue, Nov 26, 2013 at 09:49:10PM +, Santosh Shilimkar wrote:
> On Tuesday 26 November 2013 12:37 PM, Dave Martin wrote:
> > On Tue, Nov 26, 2013 at 09:47:13AM -0500, Santosh Shilimkar wrote:
> >> On Tuesday 26 November 2013 09:13 AM, Catalin Marinas wrote:
> >>> On Mon, Nov 25, 2013 at 07:44:08PM +, Santosh Shilimkar wrote:
>  On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote:
> > On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote:
> >> What I am saying is the platforms like OMAP5 already support PM in
> >> mainline kernel and we can't break that for KVM. Boot-loaders
> >> would be thrashed after boot so you need something which runs
> >> in Kernel or along with Kernel to have equivalent of hyp
> >> switching.
> >>
> >> Am not challenging the agreed direction but we need to solve the
> >> PM problem as well before making "all CPU runs boot-loader for
> >> HYP kernels" as a must have. At least its is a change in boot
> >> strategy from existing kernels.
> >
> > Of course I recommend PSCI which covers both hotplug and suspend ;), but
> > I guess it's not the case for OMAP5. Since OMAP has its own secondary
> > booting protocol and CPU hotplug re-entry, can you not just use
> > different entry point when the primary CPU was initially started in Hyp
> > mode (e.g. omap5_hyp_secondary_startup)?
> >
>  How will that solve the guest secondary boot failure case when using
>  the same kernel binary for guest-boot ? Even for primary CPU which
>  will be suspended it needs to resume already in HYP mode and its not
>  going to go through boot-loader. So the low power code needs to have
>  HYP switch code so that CPU resumes in HYP mode.
> >>>
> >>> Is it late to rewrite the OMAP5 firmware?
> >>>
> >> Well its ROM'ed unfortunately so no choice. OMAP5 ROM did implement
> >> a secure API which lets you enter into HYP mode and thats the only
> >> thing can be used.
> > 
> > If the ROM is capable of loading some additional signed Secure World
> > firmware after the ROM itself has booted, PSCI could be implemented
> > in the second, resident firmware payload.
> > 
> > Some SoCs ship with boot ROMs that can do that -- is this not the case
> > for OMAP5?
> > 
> On OMAP, the secure devices there is a way to do this but not for 
> general purpose devices. General purpose devices once you
> exit the ROM code, we exit out of security and only way to
> re-enter secure word is via ROM implemented monitor/secure
> APIs.

As last resort, you can still write a bunch of instructions acting as
warm-bootloader, reserve a page and add them there. Code required is just
a shim layer and should not require more than few bytes, after all
it has just to check some variables and jump accordingly (+ calling
smc if required).

Not pretty, agreed, but still better than patching the kernel IMHO
(basically you will end up patching the bootloader - and possibly the
dtb - instead, to install the shim mentioned above).

Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe 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

[Sekhar Nori]

On Wednesday 27 November 2013 07:17 PM, Daniel Mack wrote:
> 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.

Yes, this is a common fallacy. Russell cleaned up a bunch of these a
while back.

> 
>>> +   /* 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 ;)

:) I did not compare the rest of the file, but hey the bar keep rising
all the time.

> 
>> 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? :)

In this particular case, I agree so I am okay if you keep it as is. The
rest of the two reports are valid though.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe 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 
Signed-off-by: Daniel Mack 
Tested-by: Joel Fernandes 
Acked-by: Joel Fernandes 
---
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].data);
+  

[PATCH] i2c: omap: raw read and write endian fix

[Taras Kondratiuk]

From: Victor Kamensky 

All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.

Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.

Signed-off-by: Victor Kamensky 
Signed-off-by: Taras Kondratiuk 
---
Posting this as a saparate patch out of RFC series.
RFC: http://patchwork.ozlabs.org/patch/291726/
Only minor comment change is done since RFC patch.

Based on v3.13-rc1

 drivers/i2c/busses/i2c-omap.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d76228d..90dcc2e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -266,13 +266,13 @@ static const u8 reg_map_ip_v2[] = {
 static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
  int reg, u16 val)
 {
-   __raw_writew(val, i2c_dev->base +
+   writew_relaxed(val, i2c_dev->base +
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
 }
 
 static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
 {
-   return __raw_readw(i2c_dev->base +
+   return readw_relaxed(i2c_dev->base +
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
 }
 
@@ -1162,9 +1162,9 @@ omap_i2c_probe(struct platform_device *pdev)
 * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
 * On omap1/3/2 Offset 4 is IE Reg the bit [15:14] is 0 at reset.
 * Also since the omap_i2c_read_reg uses reg_map_ip_* a
-* raw_readw is done.
+* readw_relaxed is done.
 */
-   rev = __raw_readw(dev->base + 0x04);
+   rev = readw_relaxed(dev->base + 0x04);
 
dev->scheme = OMAP_I2C_SCHEME(rev);
switch (dev->scheme) {
-- 
1.7.9.5

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

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

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

[Sekhar Nori]

+ Kevin

On Monday 18 November 2013 03:49 AM, 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 
> Signed-off-by: Daniel Mack 
> Tested-by: Joel Fernandes 
> Acked-by: Joel Fernandes 
> ---
> 
> v6:
>   amended version from Nishanth Menon, adding error handling for runtime,
>   and using suspend_late/early_resume.
> 
> 
>  arch/arm/common/edma.c | 94 
> --
>  1 file changed, 91 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 8e1a024..e2b9638 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,101 @@ 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 (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) { .. }

> + 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 (IS_ERR_VALUE(r)) {

Same here as above.

> + 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
> +  */

Please follow the multi-line commenting style.

> + if (edma_read(j, EDMA_CCCFG) & CHMAP_EXIST)
> + map_dmach_param(j);
> +
> + for (i = 0; i < cc->num_channels; i++) {
> + if (test_bit(

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 
>>> Signed-off-by: Daniel Mack 
>>> Tested-by: Joel Fernandes 
>>> Acked-by: Joel Fernandes 
>>
>> 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

[Sekhar Nori]

+ 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 
>> Signed-off-by: Daniel Mack 
>> Tested-by: Joel Fernandes 
>> Acked-by: Joel Fernandes 
> 
> 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 have some comments for which I will send another e-mail.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe 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] mfd: twl-core: Clean up module by removing twl603x pdata handling

[Lee Jones]

On Thu, 21 Nov 2013, Ruslan Ruslichenko wrote:

> Since currently nobody uses TWL603x platform data and all new

Hmm... when you say nobody, how did you come to this conclusion?

Without digging into it and probably not that relevant, it
appears there is some references to it in platform data still:

$ git grep twl603 -- arch/ | grep -v dts
arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct 
omap2_hsmmc_info *controllers);
arch/arm/mach-omap2/omap4-common.c:static int 
omap4_twl6030_hsmmc_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: irq = 
twl6030_mmc_card_detect_config();
arch/arm/mach-omap2/omap4-common.c: pdata->slots[0].card_detect = 
twl6030_mmc_card_detect;
arch/arm/mach-omap2/omap4-common.c:static __init void 
omap4_twl6030_hsmmc_set_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: pdata->init =   
omap4_twl6030_hsmmc_late_init;
arch/arm/mach-omap2/omap4-common.c:int __init omap4_twl6030_hsmmc_init(struct 
omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap4-common.c: 
omap4_twl6030_hsmmc_set_late_init(&c->pdev->dev);
arch/arm/mach-omap2/omap4-common.c:int __init omap4_twl6030_hsmmc_init(struct 
omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap_twl.c:static unsigned long twl6030_vsel_to_uv(const u8 
vsel)
arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned long uv)
arch/arm/mach-omap2/omap_twl.c: if (uv > twl6030_vsel_to_uv(0x39)) {
arch/arm/mach-omap2/omap_twl.c: __func__, uv, 
twl6030_vsel_to_uv(0x39));
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv = twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel = twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv = twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel = twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv = twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel = twl6030_uv_to_vsel,

> users will supply it through device tree, handling of these
> data within twl-core will never be used, so remove it.
> 
> Signed-off-by: Ruslan Ruslichenko 
> ---
> 
> Tested on TI SDP/Tablet OMAP4460 board
> Based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> commit 5e01dc7 Linux 3.12
> 
>  drivers/mfd/twl-core.c | 198 
> -
>  1 file changed, 198 deletions(-)
> 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 29473c2..c3c28b9 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -701,62 +701,6 @@ add_children(struct twl4030_platform_data *pdata, 
> unsigned irq_base,
>   usb3v1[0].dev_name = dev_name(child);
>   }
>   }
> - if (IS_ENABLED(CONFIG_TWL6030_USB) && pdata->usb &&
> - twl_class_is_6030()) {
> -
> - static struct regulator_consumer_supply usb3v3;
> - int regulator;
> -
> - if (IS_ENABLED(CONFIG_REGULATOR_TWL4030)) {
> - /* this is a template that gets copied */
> - struct regulator_init_data usb_fixed = {
> - .constraints.valid_modes_mask =
> - REGULATOR_MODE_NORMAL
> - | REGULATOR_MODE_STANDBY,
> - .constraints.valid_ops_mask =
> - REGULATOR_CHANGE_MODE
> - | REGULATOR_CHANGE_STATUS,
> - };
> -
> - if (features & TWL6032_SUBCLASS) {
> - usb3v3.supply = "ldousb";
> - regulator = TWL6032_REG_LDOUSB;
> - } else {
> - usb3v3.supply = "vusb";
> - regulator = TWL6030_REG_VUSB;
> - }
> - child = add_regulator_linked(regulator, &usb_fixed,
> - &usb3v3, 1,
> - features);
> - if (IS_ERR(child))
> - return PTR_ERR(child);
> - }
> -
> - pdata->usb->features = features;
> -
> - child = add_child(TWL_MODULE_USB, "twl6030_usb",
> - pdata->usb, sizeof(*pdata->usb), true,
> - /* irq1 = VBUS_PRES, irq0 = USB ID */
> - irq_base + USBOTG_INTR_OFFSET,
> - irq_base + USB_PRES_INTR_OFFSET);
> -
> - if (IS_ERR(child))
> - return PTR_ERR(child);
> - /* we need to connect regulators to this transceiver */
> - if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && child)
> - usb3v3.dev_name = dev_name(child);
> - } else if (IS_ENABLED(CONFI

[PATCH] ARM: OMAP2+: Powerdomain: Fix unchecked dereference of arch_pwrdm

[Rajendra Nayak]

Commit 'cd8abed' "ARM: OMAP2+: Powerdomain: Remove the need to
always have a voltdm associated to a pwrdm" leads to the following
Smatch complaint:

arch/arm/mach-omap2/powerdomain.c:131 _pwrdm_register()
 error: we previously assumed 'arch_pwrdm' could be null (see line 105)

So, fix the unchecked dereference of arch_pwrdm.

Reported-by: Dan Carpenter 
Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/powerdomain.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index e233dfc..93a2a6e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -128,7 +128,8 @@ skip_voltdm:
for (i = 0; i < pwrdm->banks; i++)
pwrdm->ret_mem_off_counter[i] = 0;
 
-   arch_pwrdm->pwrdm_wait_transition(pwrdm);
+   if (arch_pwrdm && arch_pwrdm->pwrdm_wait_transition)
+   arch_pwrdm->pwrdm_wait_transition(pwrdm);
pwrdm->state = pwrdm_read_pwrst(pwrdm);
pwrdm->state_counter[pwrdm->state] = 1;
 
-- 
1.7.9.5

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

Re: [PATCHv10 31/41] ARM: OMAP2+: clock: add support for regmap

[Tero Kristo]

On 11/26/2013 07:40 PM, Tony Lindgren wrote:

* Tero Kristo  [131126 00:10]:

Using regmap is required for isolating the actual memory access from
the clock code. Now, the driver providing the support for the clock IP
block can provide a regmap for this purpose.

Signed-off-by: Tero Kristo 
---
  arch/arm/mach-omap2/clock.c |   27 ++-
  arch/arm/mach-omap2/clock.h |3 +++
  2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 238be3f..1ef6df8 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -25,7 +25,7 @@
  #include 
  #include 
  #include 
-
+#include 

  #include 

@@ -56,6 +56,31 @@ u16 cpu_mask;
  static bool clkdm_control = true;

  static LIST_HEAD(clk_hw_omap_clocks);
+struct regmap *clk_regmaps[CLK_MAX_REGMAPS];
+
+void omap2_clk_writel(u32 val, struct clk_hw_omap *clk, void __iomem *reg)
+{
+   if (clk->flags & REGMAP_ADDRESSING) {
+   struct clk_omap_reg *r = (struct clk_omap_reg *)®
+   regmap_write(clk_regmaps[r->index], r->offset, val);
+   } else {
+   __raw_writel(val, reg);
+   }
+}
+
+u32 omap2_clk_readl(struct clk_hw_omap *clk, void __iomem *reg)
+{
+   u32 val;
+
+   if (clk->flags & REGMAP_ADDRESSING) {
+   struct clk_omap_reg *r = (struct clk_omap_reg *)®
+   regmap_read(clk_regmaps[r->index], r->offset, &val);
+   } else {
+   val = __raw_readl(reg);
+   }
+
+   return val;
+}

  /*
   * Used for clocks that have the same value as the parent clock,


Maybe use read[lw]_relaxed and write[lw]_relaxed here and elsewhere
instead of __raw_read/write to help cut down the changes needed for
the big endian patch set?


Well, this is the only place where we have a call to __raw_readl / 
__raw_writel in this patch set, the next patch actually removes all 
these calls from mach-omap2. But yes, I can change this.


-Tero

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

Re: [PATCHv10 41/41] ARM: OMAP3: use DT clock init if DT data is available

[Tero Kristo]

On 11/26/2013 07:44 PM, Tony Lindgren wrote:

* Tero Kristo  [131126 00:10]:

OMAP3 platforms support both DT and non-DT boot at the moment, make
the clock init work according to the used setup.


We're making omap3 to be DT only as well, so it might make sense to
drop the omap3 clock data as well while at it. Or do it later to
avoid adding dependencies, up to you.


Ok, I can remove it with next rev if you like.

-Tero
--
To unsubscribe from this list: send the line "unsubscribe 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] Add more device nodes for am43x-epos-evm

[Sourav Poddar]

On Wednesday 27 November 2013 01:38 PM, Sathya Prakash wrote:

On Wednesday 27 November 2013 01:00 PM, Sourav Poddar wrote:

The patch series adds support for enabling pwm backlight, i2c2, spi and
matrix gpio keys on am43x-gp-evm.

Seems a typo - series is for epos evm.

Yes, true. The series if for epos.




Done on top of 3.13-rc1 + tero clock series(1)

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

Tested on am43x-gp-evm.

There is a some bug while using regulators through backlight
driver on 3.13-rc1. So, tested pwm part with this temporary patch[2].

[2]: http://www.spinics.net/lists/arm-kernel/msg288215.html

Darren Etheridge (1):
   pinctrl: am43xx: dt-bindings: add MUX_MODE8

Sourav Poddar (4):
   arm: dts: am4372: Add pwm-cellsproperty for ecap device.
   arm: dts: am43x-epos-evm: Add I2C data.
   arm: dts: am43x-epos-evm: Add SPI data.
   ARM: dts: am43x-epos-evm: Add pwm backlight support.

  arch/arm/boot/dts/am4372.dtsi|9 +
  arch/arm/boot/dts/am43x-epos-evm.dts |   67 
++

  include/dt-bindings/pinctrl/am43xx.h |1 +
  3 files changed, 77 insertions(+), 0 deletions(-)

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

~Sathya


--
To unsubscribe from this list: send the line "unsubscribe 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] Add more device nodes for am43x-epos-evm

[Sathya Prakash]

On Wednesday 27 November 2013 01:00 PM, Sourav Poddar wrote:

The patch series adds support for enabling pwm backlight, i2c2, spi and
matrix gpio keys on am43x-gp-evm.

Seems a typo - series is for epos evm.


Done on top of 3.13-rc1 + tero clock series(1)

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

Tested on am43x-gp-evm.

There is a some bug while using regulators through backlight
driver on 3.13-rc1. So, tested pwm part with this temporary patch[2].

[2]: http://www.spinics.net/lists/arm-kernel/msg288215.html

Darren Etheridge (1):
   pinctrl: am43xx: dt-bindings: add MUX_MODE8

Sourav Poddar (4):
   arm: dts: am4372: Add pwm-cellsproperty for ecap device.
   arm: dts: am43x-epos-evm: Add I2C data.
   arm: dts: am43x-epos-evm: Add SPI data.
   ARM: dts: am43x-epos-evm: Add pwm backlight support.

  arch/arm/boot/dts/am4372.dtsi|9 +
  arch/arm/boot/dts/am43x-epos-evm.dts |   67 ++
  include/dt-bindings/pinctrl/am43xx.h |1 +
  3 files changed, 77 insertions(+), 0 deletions(-)

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

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