Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

2015-09-10 Thread Sebastian Reichel
Hi,

On Tue, Sep 08, 2015 at 01:14:17PM -0700, Tony Lindgren wrote:
> * Kevin Hilman  [150908 11:36]:
> > On Wed, Sep 2, 2015 at 6:07 AM, Tony Lindgren  wrote:
> > > * Neil Brown  [150901 23:23]:
> > >> Kevin Hilman  writes:
> > >>
> > >> > ping... this boot failure has now landed in mainline
> > >>
> > >> sorry, I'm on leave at the moment and travelling so I'm unlikely to be
> > >> able to look at this properly.  I should be able to examine this issue
> > >> before the end of the month but cannot promise sooner than that (though
> > >> it is not impossible).
> > >>
> > >> Maybe it would be best to just revert it until a proper analysis can be
> > >> done.
> > >
> > > OK yeah let's revert this one for now until we know what goes wrong.
> > 
> > Looks like this is still in mainline.
> > 
> > Tony, can you revert?
> 
> Probably best that Sebastian does it as there's another fix needed
> too. It seems the following are needed:
> 
> - Revert $subject patch 3fc3895e4fe1 ("twl4030_charger: correctly
>   handle -EPROBE_DEFER from devm_usb_get_phy_by_node")
> 
> - Apply compile fix "[PATCH] twl4030_charger: fix another compile
>   error"
> 
> Just in case Sebastian is travelling or something..

Right, I was on vacation without internet access until now.

> Sebastian, can you please confirm?

Sounds fine to me. I will take care of it once I've slept a bit.

-- Sebastian


signature.asc
Description: Digital signature


Re: mysterious crashes on OMAP5 uevm

2015-09-10 Thread Russell King - ARM Linux
On Thu, Sep 10, 2015 at 08:42:57AM +0200, Dr. H. Nikolaus Schaller wrote:
> 
> Am 08.09.2015 um 23:07 schrieb Tony Lindgren :
> 
> > * Grazvydas Ignotas  [150908 13:44]:
> >> On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren  wrote:
> >>> * Grazvydas Ignotas  [150908 05:50]:
>  Hi,
>  
>  this is a longstanding problem I'm seeing since the very beginning,
>  which was around 3.12 or so (when I've first got the hardware) and it
>  seems 4.2 is affected by it still. Basically what happens is Xorg
>  randomly segfaults at some "impossible" location. I don't have the
>  details at the moment (could get them is needed), but from what I
>  examined with gdb some time ago the situation did not make any sense.
>  
>  There are 2 workarounds that I know which make the problem go away
>  (one is enough):
>  - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
>  default)
>  - disable ARCH_MULTI_V6 in the kernel config
>  
>  Because of the above workarounds I have forgotten about it several
>  times, but it regularly comes back and bites again. It would look like
>  some missing erratum workaround, but I have all of them enabled in the
>  kernel.
>  
>  Does anyone know about this? Perhaps some missing erratum workaround
>  in the bootloader? u-boot isn't too old here (2015.07).
> >>> 
> >>> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
> >>> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
> >>> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
> >>> places ignoring uncompress and davinci code.
> >> 
> >> ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
> >> disabled, it is enough to just do this:
> >> 
> >> --- a/arch/arm/kernel/signal.c
> >> +++ b/arch/arm/kernel/signal.c
> >> @@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal 
> >> *ksig,
> >>/*
> >> * The LSB of the handler determines if we're going to
> >> * be using THUMB or ARM mode for this signal handler.
> >> */
> >>thumb = handler & 1;
> >> 
> >> -#if __LINUX_ARM_ARCH__ >= 7
> >> +#if 0 //__LINUX_ARM_ARCH__ >= 7
> >>/*
> >> * Clear the If-Then Thumb-2 execution state
> >> * ARM spec requires this to be all 000s in ARM mode
> >> * Snapdragon S4/Krait misbehaves on a Thumb=>ARM
> >> * signal transition without this.
> >> */
> >> 
> >> ... and the problem appears, so I guess this needs some real
> >> multiplatform handling,.
> > 
> > OK nice to hear you found it. Yeah looks like some runtime
> > capability check is needed.
> > 
> >>> Do you have some easy way to reproduce this issue?
> >> 
> >> Just moving a browser window around with mouse usually triggers it
> >> within a minute.
> > 
> > OK good to know.
> 
> It looks as if this is the solution for the same symptom on our OMAP3 board 
> (gta04).
> There, it suffices to draw on the touch screen for ~10 seconds to make the 
> xserver segfault.
> 
> [we are using the binary xserver from debian wheezy
> ii  xserver-xorg-core2:1.12.4-6+deb7u5 
> armhfXorg X server - core server]
> 
> We know about this bug for a while, but so far did think that some touch 
> screen
> event bit has changed and we have to fix our touch screen driver.
> 
> Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and adding the
> >> #if 0 //__LINUX_ARM_ARCH__ >= 7
> makes it re-appear.
> 
> A while ago I tried to debug running the x-server under strace and could find 
> that it also has
> something to do with SIGALRM.
> 
> And that is very consistent with “enable/disable” by modifying 
> arch/arm/kernel/signal.c

It would be really nice if someone could diagnose what's going on here.
What exception is causing the X server to be killed (someone said a
segfault)?  What is the register state at the point that happens?  What
does the code look like  Is it happening inside the SIGALRM handler, or
when the SIGALRM handler has returned?

I'd suggest attaching gdb to the X server, but remember to set gdb to
ignore SIGPIPEs.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 08/21] ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers

2015-09-10 Thread Arnd Bergmann
On Thursday 10 September 2015 11:37:37 Peter Ujfalusi wrote:
> bla-bla and bla
> 
> Signed-off-by: Peter Ujfalusi 

You may want to expand on that a bit.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe 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 20/21] dmaengine: edma: Move the pending error check into helper function

2015-09-10 Thread Peter Ujfalusi
In the ccerr interrupt handler the code checks for pending errors in the
error status registers in two different places.
Move the check out to a helper function.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5436c811aa2d..f1e898525ae6 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1608,6 +1608,16 @@ static void edma_error_handler(struct edma_chan *echan)
spin_unlock(>vchan.lock);
 }
 
+static inline bool edma_error_pending(struct edma_cc *ecc)
+{
+   if (edma_read_array(ecc, EDMA_EMR, 0) ||
+   edma_read_array(ecc, EDMA_EMR, 1) ||
+   edma_read(ecc, EDMA_QEMR) || edma_read(ecc, EDMA_CCERR))
+   return true;
+
+   return false;
+}
+
 /* eDMA error interrupt handler */
 static irqreturn_t dma_ccerr_handler(int irq, void *data)
 {
@@ -1622,10 +1632,7 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
 
dev_dbg(ecc->dev, "dma_ccerr_handler\n");
 
-   if ((edma_read_array(ecc, EDMA_EMR, 0) == 0) &&
-   (edma_read_array(ecc, EDMA_EMR, 1) == 0) &&
-   (edma_read(ecc, EDMA_QEMR) == 0) &&
-   (edma_read(ecc, EDMA_CCERR) == 0))
+   if (!edma_error_pending(ecc))
return IRQ_NONE;
 
while (1) {
@@ -1678,10 +1685,7 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
}
}
}
-   if ((edma_read_array(ecc, EDMA_EMR, 0) == 0) &&
-   (edma_read_array(ecc, EDMA_EMR, 1) == 0) &&
-   (edma_read(ecc, EDMA_QEMR) == 0) &&
-   (edma_read(ecc, EDMA_CCERR) == 0))
+   if (!edma_error_pending(ecc))
break;
cnt++;
if (cnt > 10)
-- 
2.5.1

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


[PATCH 17/21] dmaengine: edma: Print warning when linking slots from different eDMA

2015-09-10 Thread Peter Ujfalusi
Warning message in case of linking between paRAM slots in different eDMA
controllers.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e735147ccece..2c6be4c62a73 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -598,6 +598,9 @@ static void edma_free_slot(struct edma_cc *ecc, unsigned 
slot)
  */
 static void edma_link(struct edma_cc *ecc, unsigned from, unsigned to)
 {
+   if (unlikely(EDMA_CTLR(from) != EDMA_CTLR(to)))
+   dev_warn(ecc->dev, "Ignoring eDMA instance for linking\n");
+
from = EDMA_CHAN_SLOT(from);
to = EDMA_CHAN_SLOT(to);
if (from >= ecc->num_slots || to >= ecc->num_slots)
-- 
2.5.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: mysterious crashes on OMAP5 uevm

2015-09-10 Thread Dr. H. Nikolaus Schaller

Am 10.09.2015 um 10:30 schrieb Russell King - ARM Linux 
:

> On Thu, Sep 10, 2015 at 08:42:57AM +0200, Dr. H. Nikolaus Schaller wrote:
>> 
>> Am 08.09.2015 um 23:07 schrieb Tony Lindgren :
>> 
>>> * Grazvydas Ignotas  [150908 13:44]:
 On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren  wrote:
> * Grazvydas Ignotas  [150908 05:50]:
>> Hi,
>> 
>> this is a longstanding problem I'm seeing since the very beginning,
>> which was around 3.12 or so (when I've first got the hardware) and it
>> seems 4.2 is affected by it still. Basically what happens is Xorg
>> randomly segfaults at some "impossible" location. I don't have the
>> details at the moment (could get them is needed), but from what I
>> examined with gdb some time ago the situation did not make any sense.
>> 
>> There are 2 workarounds that I know which make the problem go away
>> (one is enough):
>> - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
>> default)
>> - disable ARCH_MULTI_V6 in the kernel config
>> 
>> Because of the above workarounds I have forgotten about it several
>> times, but it regularly comes back and bites again. It would look like
>> some missing erratum workaround, but I have all of them enabled in the
>> kernel.
>> 
>> Does anyone know about this? Perhaps some missing erratum workaround
>> in the bootloader? u-boot isn't too old here (2015.07).
> 
> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
> places ignoring uncompress and davinci code.
 
 ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
 disabled, it is enough to just do this:
 
 --- a/arch/arm/kernel/signal.c
 +++ b/arch/arm/kernel/signal.c
 @@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal 
 *ksig,
   /*
* The LSB of the handler determines if we're going to
* be using THUMB or ARM mode for this signal handler.
*/
   thumb = handler & 1;
 
 -#if __LINUX_ARM_ARCH__ >= 7
 +#if 0 //__LINUX_ARM_ARCH__ >= 7
   /*
* Clear the If-Then Thumb-2 execution state
* ARM spec requires this to be all 000s in ARM mode
* Snapdragon S4/Krait misbehaves on a Thumb=>ARM
* signal transition without this.
*/
 
 ... and the problem appears, so I guess this needs some real
 multiplatform handling,.
>>> 
>>> OK nice to hear you found it. Yeah looks like some runtime
>>> capability check is needed.
>>> 
> Do you have some easy way to reproduce this issue?
 
 Just moving a browser window around with mouse usually triggers it
 within a minute.
>>> 
>>> OK good to know.
>> 
>> It looks as if this is the solution for the same symptom on our OMAP3 board 
>> (gta04).
>> There, it suffices to draw on the touch screen for ~10 seconds to make the 
>> xserver segfault.
>> 
>> [we are using the binary xserver from debian wheezy
>> ii  xserver-xorg-core2:1.12.4-6+deb7u5 
>> armhfXorg X server - core server]
>> 
>> We know about this bug for a while, but so far did think that some touch 
>> screen
>> event bit has changed and we have to fix our touch screen driver.
>> 
>> Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and adding the
 #if 0 //__LINUX_ARM_ARCH__ >= 7
>> makes it re-appear.
>> 
>> A while ago I tried to debug running the x-server under strace and could 
>> find that it also has
>> something to do with SIGALRM.
>> 
>> And that is very consistent with “enable/disable” by modifying 
>> arch/arm/kernel/signal.c
> 
> It would be really nice if someone could diagnose what's going on here.
> What exception is causing the X server to be killed (someone said a
> segfault)?  What is the register state at the point that happens?  What
> does the code look like  Is it happening inside the SIGALRM handler, or
> when the SIGALRM handler has returned?
> 
> I'd suggest attaching gdb to the X server, but remember to set gdb to
> ignore SIGPIPEs.

I don’t have a setup to run gdb (with source) on the device and really zero
experience with Xserver sources. But maybe Grazvydas can do that better
than me.

Attached is some strace I had recorded during my earlier experiments.
X-Server appears not only to heavily use SIGALRM but SIGIO.

And it looks as if it a SEGFAULT appears inside the SIGIO handler after
having done 3 syscalls (select, read, clock_gettime) but before the
sigreturn. At least in this example.

Xserver then does a graceful shutdown after 

Re: mysterious crashes on OMAP5 uevm

2015-09-10 Thread Dr. H. Nikolaus Schaller

Am 08.09.2015 um 23:07 schrieb Tony Lindgren :

> * Grazvydas Ignotas  [150908 13:44]:
>> On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren  wrote:
>>> * Grazvydas Ignotas  [150908 05:50]:
 Hi,
 
 this is a longstanding problem I'm seeing since the very beginning,
 which was around 3.12 or so (when I've first got the hardware) and it
 seems 4.2 is affected by it still. Basically what happens is Xorg
 randomly segfaults at some "impossible" location. I don't have the
 details at the moment (could get them is needed), but from what I
 examined with gdb some time ago the situation did not make any sense.
 
 There are 2 workarounds that I know which make the problem go away
 (one is enough):
 - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
 default)
 - disable ARCH_MULTI_V6 in the kernel config
 
 Because of the above workarounds I have forgotten about it several
 times, but it regularly comes back and bites again. It would look like
 some missing erratum workaround, but I have all of them enabled in the
 kernel.
 
 Does anyone know about this? Perhaps some missing erratum workaround
 in the bootloader? u-boot isn't too old here (2015.07).
>>> 
>>> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
>>> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
>>> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
>>> places ignoring uncompress and davinci code.
>> 
>> ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
>> disabled, it is enough to just do this:
>> 
>> --- a/arch/arm/kernel/signal.c
>> +++ b/arch/arm/kernel/signal.c
>> @@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal 
>> *ksig,
>>/*
>> * The LSB of the handler determines if we're going to
>> * be using THUMB or ARM mode for this signal handler.
>> */
>>thumb = handler & 1;
>> 
>> -#if __LINUX_ARM_ARCH__ >= 7
>> +#if 0 //__LINUX_ARM_ARCH__ >= 7
>>/*
>> * Clear the If-Then Thumb-2 execution state
>> * ARM spec requires this to be all 000s in ARM mode
>> * Snapdragon S4/Krait misbehaves on a Thumb=>ARM
>> * signal transition without this.
>> */
>> 
>> ... and the problem appears, so I guess this needs some real
>> multiplatform handling,.
> 
> OK nice to hear you found it. Yeah looks like some runtime
> capability check is needed.
> 
>>> Do you have some easy way to reproduce this issue?
>> 
>> Just moving a browser window around with mouse usually triggers it
>> within a minute.
> 
> OK good to know.

It looks as if this is the solution for the same symptom on our OMAP3 board 
(gta04).
There, it suffices to draw on the touch screen for ~10 seconds to make the 
xserver segfault.

[we are using the binary xserver from debian wheezy
ii  xserver-xorg-core2:1.12.4-6+deb7u5 
armhfXorg X server - core server]

We know about this bug for a while, but so far did think that some touch screen
event bit has changed and we have to fix our touch screen driver.

Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and adding the
>> #if 0 //__LINUX_ARM_ARCH__ >= 7
makes it re-appear.

A while ago I tried to debug running the x-server under strace and could find 
that it also has
something to do with SIGALRM.

And that is very consistent with “enable/disable” by modifying 
arch/arm/kernel/signal.c

BR,
Nikolaus


--
To unsubscribe from this list: send the line "unsubscribe 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 14/21] dmaengine: edma: Cleanup regarding the use of dev around the code

2015-09-10 Thread Peter Ujfalusi
Be consistent and do not mix the use of dev, >dev, etc in the
functions.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0b46d4263ec6..71de1c843bb4 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1177,7 +1177,7 @@ static void edma_execute(struct edma_chan *echan)
j = i + edesc->processed;
edma_write_slot(ecc, echan->slot[i], >pset[j].param);
edesc->sg_len += edesc->pset[j].len;
-   dev_vdbg(echan->vchan.chan.device->dev,
+   dev_vdbg(dev,
"\n pset[%d]:\n"
"  chnum\t%d\n"
"  slot\t%d\n"
@@ -1828,7 +1828,6 @@ err_no_chan:
 static void edma_free_chan_resources(struct dma_chan *chan)
 {
struct edma_chan *echan = to_edma_chan(chan);
-   struct device *dev = chan->device->dev;
int i;
 
/* Terminate transfers */
@@ -1850,7 +1849,7 @@ static void edma_free_chan_resources(struct dma_chan 
*chan)
echan->alloced = false;
}
 
-   dev_dbg(dev, "freeing channel for %u\n", echan->ch_num);
+   dev_dbg(chan->device->dev, "freeing channel for %u\n", echan->ch_num);
 }
 
 /* Send pending descriptor to hardware */
@@ -2174,13 +2173,13 @@ static int edma_probe(struct platform_device *pdev)
return ret;
}
 
-   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
 
-   ecc = devm_kzalloc(>dev, sizeof(*ecc), GFP_KERNEL);
+   ecc = devm_kzalloc(dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
-   dev_err(>dev, "Can't allocate controller\n");
+   dev_err(dev, "Can't allocate controller\n");
return -ENOMEM;
}
 
@@ -2325,7 +2324,7 @@ static int edma_probe(struct platform_device *pdev)
 
ecc->dummy_slot = edma_alloc_slot(ecc, EDMA_SLOT_ANY);
if (ecc->dummy_slot < 0) {
-   dev_err(>dev, "Can't allocate PaRAM dummy slot\n");
+   dev_err(dev, "Can't allocate PaRAM dummy slot\n");
return ecc->dummy_slot;
}
 
@@ -2334,7 +2333,7 @@ static int edma_probe(struct platform_device *pdev)
dma_cap_set(DMA_CYCLIC, ecc->dma_slave.cap_mask);
dma_cap_set(DMA_MEMCPY, ecc->dma_slave.cap_mask);
 
-   edma_dma_init(ecc, >dma_slave, >dev);
+   edma_dma_init(ecc, >dma_slave, dev);
 
edma_chan_init(ecc, >dma_slave, ecc->slave_chans);
 
@@ -2346,7 +2345,7 @@ static int edma_probe(struct platform_device *pdev)
of_dma_controller_register(node, of_dma_xlate_by_chan_id,
   >dma_slave);
 
-   dev_info(>dev, "TI EDMA DMA engine driver\n");
+   dev_info(dev, "TI EDMA DMA engine driver\n");
 
return 0;
 
@@ -2360,8 +2359,8 @@ static int edma_remove(struct platform_device *pdev)
struct device *dev = >dev;
struct edma_cc *ecc = dev_get_drvdata(dev);
 
-   if (pdev->dev.of_node)
-   of_dma_controller_free(pdev->dev.of_node);
+   if (dev->of_node)
+   of_dma_controller_free(dev->of_node);
dma_async_device_unregister(>dma_slave);
edma_free_slot(ecc, ecc->dummy_slot);
 
-- 
2.5.1

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


[PATCH 06/21] ARM: common: edma: Internal API to use pointer to 'struct edma'

2015-09-10 Thread Peter Ujfalusi
Merge the iomem into the 'struct edma' and change the internal (static)
functions to use pointer to the edma_cc instead of the ctlr number.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 400 -
 1 file changed, 197 insertions(+), 203 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index dc960de1a95f..5fd8293a48aa 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -114,108 +114,141 @@
 #define EDMA_MAX_PARAMENTRY 512
 
 /*/
+struct edma {
+   struct device   *dev;
+   void __iomem *base;
+
+   /* how many dma resources of each type */
+   unsignednum_channels;
+   unsignednum_region;
+   unsignednum_slots;
+   unsignednum_tc;
+   enum dma_event_qdefault_queue;
 
-static void __iomem *edmacc_regs_base[EDMA_MAX_CC];
+   /* list of channels with no even trigger; terminated by "-1" */
+   const s8*noevent;
+
+   struct edma_soc_info *info;
+   int id;
+
+   /* The edma_inuse bit for each PaRAM slot is clear unless the
+* channel is in use ... by ARM or DSP, for QDMA, or whatever.
+*/
+   DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY);
 
-static inline unsigned int edma_read(unsigned ctlr, int offset)
+   /* The edma_unused bit for each channel is clear unless
+* it is not being used on this platform. It uses a bit
+* of SOC-specific initialization code.
+*/
+   DECLARE_BITMAP(edma_unused, EDMA_MAX_DMACH);
+
+   struct dma_interrupt_data {
+   void (*callback)(unsigned channel, unsigned short ch_status,
+   void *data);
+   void *data;
+   } intr_data[EDMA_MAX_DMACH];
+};
+/*/
+
+static inline unsigned int edma_read(struct edma *cc, int offset)
 {
-   return (unsigned int)__raw_readl(edmacc_regs_base[ctlr] + offset);
+   return (unsigned int)__raw_readl(cc->base + offset);
 }
 
-static inline void edma_write(unsigned ctlr, int offset, int val)
+static inline void edma_write(struct edma *cc, int offset, int val)
 {
-   __raw_writel(val, edmacc_regs_base[ctlr] + offset);
+   __raw_writel(val, cc->base + offset);
 }
-static inline void edma_modify(unsigned ctlr, int offset, unsigned and,
-   unsigned or)
+static inline void edma_modify(struct edma *cc, int offset, unsigned and,
+  unsigned or)
 {
-   unsigned val = edma_read(ctlr, offset);
+   unsigned val = edma_read(cc, offset);
val &= and;
val |= or;
-   edma_write(ctlr, offset, val);
+   edma_write(cc, offset, val);
 }
-static inline void edma_and(unsigned ctlr, int offset, unsigned and)
+static inline void edma_and(struct edma *cc, int offset, unsigned and)
 {
-   unsigned val = edma_read(ctlr, offset);
+   unsigned val = edma_read(cc, offset);
val &= and;
-   edma_write(ctlr, offset, val);
+   edma_write(cc, offset, val);
 }
-static inline void edma_or(unsigned ctlr, int offset, unsigned or)
+static inline void edma_or(struct edma *cc, int offset, unsigned or)
 {
-   unsigned val = edma_read(ctlr, offset);
+   unsigned val = edma_read(cc, offset);
val |= or;
-   edma_write(ctlr, offset, val);
+   edma_write(cc, offset, val);
 }
-static inline unsigned int edma_read_array(unsigned ctlr, int offset, int i)
+static inline unsigned int edma_read_array(struct edma *cc, int offset, int i)
 {
-   return edma_read(ctlr, offset + (i << 2));
+   return edma_read(cc, offset + (i << 2));
 }
-static inline void edma_write_array(unsigned ctlr, int offset, int i,
+static inline void edma_write_array(struct edma *cc, int offset, int i,
unsigned val)
 {
-   edma_write(ctlr, offset + (i << 2), val);
+   edma_write(cc, offset + (i << 2), val);
 }
-static inline void edma_modify_array(unsigned ctlr, int offset, int i,
+static inline void edma_modify_array(struct edma *cc, int offset, int i,
unsigned and, unsigned or)
 {
-   edma_modify(ctlr, offset + (i << 2), and, or);
+   edma_modify(cc, offset + (i << 2), and, or);
 }
-static inline void edma_or_array(unsigned ctlr, int offset, int i, unsigned or)
+static inline void edma_or_array(struct edma *cc, int offset, int i, unsigned 
or)
 {
-   edma_or(ctlr, offset + (i << 2), or);
+   edma_or(cc, offset + (i << 2), or);
 }
-static inline void edma_or_array2(unsigned ctlr, int offset, int i, int j,
+static inline void edma_or_array2(struct edma *cc, int offset, int i, int j,
unsigned or)
 {
-   edma_or(ctlr, offset + ((i*2 + j) << 2), or);
+   edma_or(cc, offset + ((i*2 + j) << 2), or);
 }
-static inline void 

Re: [PATCH 08/21] ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers

2015-09-10 Thread Peter Ujfalusi
On 09/10/2015 11:40 AM, Arnd Bergmann wrote:
> On Thursday 10 September 2015 11:37:37 Peter Ujfalusi wrote:
>> bla-bla and bla
>>
>> Signed-off-by: Peter Ujfalusi 
> 
> You may want to expand on that a bit.

I'm sorry about this.. I believed I did checked all the commit message.
Will be updated in v2.

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


Re: [PATCH 09/21] ARM: davinci: Add set dma_mask to eDMA devices

2015-09-10 Thread Peter Ujfalusi
On 09/10/2015 11:45 AM, Arnd Bergmann wrote:
> On Thursday 10 September 2015 11:37:38 Peter Ujfalusi wrote:
>> +static u64 da8xx_edma0_dmamask = DMA_BIT_MASK(32);
>> +
>>  static struct platform_device da8xx_edma0_device = {
>> .name   = "edma",
>> .id = 0,
>> .dev = {
>> .platform_data = _edma0_pdata,
>> +   .dma_mask = _edma0_dmamask,
>> +   .coherent_dma_mask = DMA_BIT_MASK(32),
>> },
>> .num_resources  = ARRAY_SIZE(da8xx_edma0_resources),
>> .resource   = da8xx_edma0_resources,
>>  };
> 
> While this is technically correct for all I can tell, could you
> convert it to use __initconst platform_device_info and
> platform_device_register_full() instead?

Yes, I can do that for the eDMAs. I was also thought about this, but looking
around the mach-davinci, I thought to stick with this mode.

> statically declaring platform_devices has been frowned upon for a long
> time (even though a lot of arm platforms still do it), and statically
> declaring the dma mask seems worse to me (and yes, I realize we also
> do that elsewhere).

Will be part of v2.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe 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 19/21] dmaengine: edma: Simplify the interrupt handling

2015-09-10 Thread Peter Ujfalusi
With the merger of the arch/arm/common/edma.c code into the dmaengine
driver, there is no longer need to have per channel callback/data storage
for interrupt events.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 444 -
 1 file changed, 203 insertions(+), 241 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index f869d130819b..5436c811aa2d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -154,12 +154,6 @@ struct edmacc_param {
 #define TCCHEN BIT(22)
 #define ITCCHENBIT(23)
 
-/*ch_status paramater of callback function possible values*/
-#define EDMA_DMA_COMPLETE 1
-#define EDMA_DMA_CC_ERROR 2
-#define EDMA_DMA_TC1_ERROR 3
-#define EDMA_DMA_TC2_ERROR 4
-
 struct edma_pset {
u32 len;
dma_addr_t  addr;
@@ -243,12 +237,6 @@ struct edma_cc {
 */
unsigned long *edma_unused;
 
-   struct dma_interrupt_data {
-   void (*callback)(unsigned channel, unsigned short ch_status,
-   void *data);
-   void *data;
-   } *intr_data;
-
struct dma_device   dma_slave;
struct edma_chan*slave_chans;
int dummy_slot;
@@ -464,24 +452,18 @@ static int prepare_unused_channel_list(struct device 
*dev, void *data)
return 0;
 }
 
-static void edma_setup_interrupt(struct edma_cc *ecc, unsigned lch,
-   void (*callback)(unsigned channel, u16 ch_status, void *data),
-   void *data)
+static void edma_setup_interrupt(struct edma_cc *ecc, unsigned lch, bool 
enable)
 {
lch = EDMA_CHAN_SLOT(lch);
 
-   if (!callback)
-   edma_shadow0_write_array(ecc, SH_IECR, lch >> 5,
-BIT(lch & 0x1f));
-
-   ecc->intr_data[lch].callback = callback;
-   ecc->intr_data[lch].data = data;
-
-   if (callback) {
+   if (enable) {
edma_shadow0_write_array(ecc, SH_ICR, lch >> 5,
 BIT(lch & 0x1f));
edma_shadow0_write_array(ecc, SH_IESR, lch >> 5,
 BIT(lch & 0x1f));
+   } else {
+   edma_shadow0_write_array(ecc, SH_IECR, lch >> 5,
+BIT(lch & 0x1f));
}
 }
 
@@ -774,8 +756,6 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
  * edma_alloc_channel - allocate DMA channel and paired parameter RAM
  * @ecc: pointer to edma_cc struct
  * @channel: specific channel to allocate; negative for "any unmapped channel"
- * @callback: optional; to be issued on DMA completion or errors
- * @data: passed to callback
  * @eventq_no: an EVENTQ_* constant, used to choose which Transfer
  * Controller (TC) executes requests using this channel.  Use
  * EVENTQ_DEFAULT unless you really need a high priority queue.
@@ -802,9 +782,7 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
  * Returns the number of the channel, else negative errno.
  */
 static int edma_alloc_channel(struct edma_cc *ecc, int channel,
-   void (*callback)(unsigned channel, u16 ch_status, void *data),
-   void *data,
-   enum dma_event_q eventq_no)
+ enum dma_event_q eventq_no)
 {
unsigned done = 0;
int ret = 0;
@@ -860,9 +838,7 @@ static int edma_alloc_channel(struct edma_cc *ecc, int 
channel,
edma_stop(ecc, EDMA_CTLR_CHAN(ecc->id, channel));
edma_write_slot(ecc, channel, _paramset);
 
-   if (callback)
-   edma_setup_interrupt(ecc, EDMA_CTLR_CHAN(ecc->id, channel),
-callback, data);
+   edma_setup_interrupt(ecc, EDMA_CTLR_CHAN(ecc->id, channel), true);
 
edma_map_dmach_to_queue(ecc, channel, eventq_no);
 
@@ -895,7 +871,7 @@ static void edma_free_channel(struct edma_cc *ecc, unsigned 
channel)
if (channel >= ecc->num_channels)
return;
 
-   edma_setup_interrupt(ecc, channel, NULL, NULL);
+   edma_setup_interrupt(ecc, channel, false);
/* REVISIT should probably take out of shadow region 0 */
 
edma_write_slot(ecc, channel, _paramset);
@@ -925,146 +901,6 @@ static void edma_assign_channel_eventq(struct edma_cc 
*ecc, unsigned channel,
edma_map_dmach_to_queue(ecc, channel, eventq_no);
 }
 
-/* eDMA interrupt handler */
-static irqreturn_t dma_irq_handler(int irq, void *data)
-{
-   struct edma_cc *ecc = data;
-   int ctlr;
-   u32 sh_ier;
-   u32 sh_ipr;
-   u32 bank;
-
-   ctlr = ecc->id;
-   if (ctlr < 0)
-   return IRQ_NONE;
-
-   dev_dbg(ecc->dev, "dma_irq_handler\n");
-
-   sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 0);
-   if (!sh_ipr) {
-   sh_ipr = 

[PATCH 21/21] dmaengine: edma: Simplify and optimize ccerr interrupt handler

2015-09-10 Thread Peter Ujfalusi
No need to run through the bits in QEMR and CCERR events since they will
not trigger any action, so just clearing the errors there is fine.
In case of the missed event the loop can be optimized so we spend less time
to handle the event.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 64 --
 1 file changed, 23 insertions(+), 41 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index f1e898525ae6..81302daf687c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1625,6 +1625,7 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
int i;
int ctlr;
unsigned int cnt = 0;
+   unsigned int val;
 
ctlr = ecc->id;
if (ctlr < 0)
@@ -1637,54 +1638,35 @@ static irqreturn_t dma_ccerr_handler(int irq, void 
*data)
 
while (1) {
int j = -1;
-   if (edma_read_array(ecc, EDMA_EMR, 0))
+   if ((val = edma_read_array(ecc, EDMA_EMR, 0)))
j = 0;
-   else if (edma_read_array(ecc, EDMA_EMR, 1))
+   else if ((val = edma_read_array(ecc, EDMA_EMR, 1)))
j = 1;
if (j >= 0) {
-   dev_dbg(ecc->dev, "EMR%d %08x\n", j,
-   edma_read_array(ecc, EDMA_EMR, j));
-   for (i = 0; i < 32; i++) {
+   unsigned long emr = val;
+
+   dev_dbg(ecc->dev, "EMR%d 0x%08x\n", j, val);
+   for (i = find_next_bit(, 32, 0); i < 32;
+i = find_next_bit(, 32, i + 1)) {
int k = (j << 5) + i;
-   if (edma_read_array(ecc, EDMA_EMR, j) &
-   BIT(i)) {
-   /* Clear the corresponding EMR bits */
-   edma_write_array(ecc, EDMA_EMCR, j,
+   /* Clear the corresponding EMR bits */
+   edma_write_array(ecc, EDMA_EMCR, j, BIT(i));
+   /* Clear any SER */
+   edma_shadow0_write_array(ecc, SH_SECR, j,
 BIT(i));
-   /* Clear any SER */
-   edma_shadow0_write_array(ecc, SH_SECR,
-   j, BIT(i));
-   
edma_error_handler(>slave_chans[k]);
-   }
-   }
-   } else if (edma_read(ecc, EDMA_QEMR)) {
-   dev_dbg(ecc->dev, "QEMR %02x\n",
-   edma_read(ecc, EDMA_QEMR));
-   for (i = 0; i < 8; i++) {
-   if (edma_read(ecc, EDMA_QEMR) & BIT(i)) {
-   /* Clear the corresponding IPR bits */
-   edma_write(ecc, EDMA_QEMCR, BIT(i));
-   edma_shadow0_write(ecc, SH_QSECR,
-  BIT(i));
-
-   /* NOTE:  not reported!! */
-   }
-   }
-   } else if (edma_read(ecc, EDMA_CCERR)) {
-   dev_dbg(ecc->dev, "CCERR %08x\n",
-   edma_read(ecc, EDMA_CCERR));
-   /* FIXME:  CCERR.BIT(16) ignored!  much better
-* to just write CCERRCLR with CCERR value...
-*/
-   for (i = 0; i < 8; i++) {
-   if (edma_read(ecc, EDMA_CCERR) & BIT(i)) {
-   /* Clear the corresponding IPR bits */
-   edma_write(ecc, EDMA_CCERRCLR, BIT(i));
-
-   /* NOTE:  not reported!! */
-   }
+   edma_error_handler(>slave_chans[k]);
}
+   } else if ((val = edma_read(ecc, EDMA_QEMR))) {
+   dev_dbg(ecc->dev, "QEMR 0x%02x\n", val);
+   /* Not reported, just clear the interrupt reason. */
+   edma_write(ecc, EDMA_QEMCR, val);
+   edma_shadow0_write(ecc, SH_QSECR, val);
+   } else if ((val = edma_read(ecc, EDMA_CCERR))) {
+   dev_warn(ecc->dev, "CCERR 0x%08x\n", val);
+   /* Not reported, just clear the interrupt reason. */
+   edma_write(ecc, EDMA_CCERRCLR, val);
}
+
if (!edma_error_pending(ecc))
break;
cnt++;

[PATCH 18/21] dmaengine: edma: Consolidate the comments for functions

2015-09-10 Thread Peter Ujfalusi
Remove or rewrite the comments for the internal functions.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 86 +++---
 1 file changed, 11 insertions(+), 75 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2c6be4c62a73..f869d130819b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -486,19 +486,7 @@ static void edma_setup_interrupt(struct edma_cc *ecc, 
unsigned lch,
 }
 
 /*
- * paRAM management functions
- */
-
-/**
- * edma_write_slot - write parameter RAM data for slot
- * @ecc: pointer to edma_cc struct
- * @slot: number of parameter RAM slot being modified
- * @param: data to be written into parameter RAM slot
- *
- * Use this to assign all parameters of a transfer at once.  This
- * allows more efficient setup of transfers than issuing multiple
- * calls to set up those parameters in small pieces, and provides
- * complete control over all transfer options.
+ * paRAM slot management functions
  */
 static void edma_write_slot(struct edma_cc *ecc, unsigned slot,
const struct edmacc_param *param)
@@ -509,15 +497,6 @@ static void edma_write_slot(struct edma_cc *ecc, unsigned 
slot,
memcpy_toio(ecc->base + PARM_OFFSET(slot), param, PARM_SIZE);
 }
 
-/**
- * edma_read_slot - read parameter RAM data from slot
- * @ecc: pointer to edma_cc struct
- * @slot: number of parameter RAM slot being copied
- * @param: where to store copy of parameter RAM data
- *
- * Use this to read data from a parameter RAM slot, perhaps to
- * save them as a template for later reuse.
- */
 static void edma_read_slot(struct edma_cc *ecc, unsigned slot,
   struct edmacc_param *param)
 {
@@ -568,15 +547,6 @@ static int edma_alloc_slot(struct edma_cc *ecc, int slot)
return EDMA_CTLR_CHAN(ecc->id, slot);
 }
 
-/**
- * edma_free_slot - deallocate DMA parameter RAM
- * @ecc: pointer to edma_cc struct
- * @slot: parameter RAM slot returned from edma_alloc_slot()
- *
- * This deallocates the parameter RAM slot allocated by edma_alloc_slot().
- * Callers are responsible for ensuring the slot is inactive, and will
- * not be activated.
- */
 static void edma_free_slot(struct edma_cc *ecc, unsigned slot)
 {
 
@@ -686,10 +656,9 @@ static int edma_start(struct edma_cc *ecc, unsigned 
channel)
  * @ecc: pointer to edma_cc struct
  * @channel: channel being deactivated
  *
- * When @lch is a channel, any active transfer is paused and
- * all pending hardware events are cleared.  The current transfer
- * may not be resumed, and the channel's Parameter RAM should be
- * reinitialized before being reused.
+ * Any active transfer is paused and all pending hardware events are cleared.
+ * The current transfer may not be resumed, and the channel's Parameter RAM
+ * should be reinitialized before being reused.
  */
 static void edma_stop(struct edma_cc *ecc, unsigned channel)
 {
@@ -721,13 +690,9 @@ static void edma_stop(struct edma_cc *ecc, unsigned 
channel)
}
 }
 
-/**
- * edma_pause - pause dma on a channel
- * @ecc: pointer to edma_cc struct
- * @channel: on which edma_start() has been called
- *
- * This temporarily disables EDMA hardware events on the specified channel,
- * preventing them from triggering new transfers on its behalf
+/*
+ * Temporarily disable EDMA hardware events on the specified channel,
+ * preventing them from triggering new transfers
  */
 static void edma_pause(struct edma_cc *ecc, unsigned channel)
 {
@@ -745,13 +710,7 @@ static void edma_pause(struct edma_cc *ecc, unsigned 
channel)
}
 }
 
-/**
- * edma_resume - resumes dma on a paused channel
- * @ecc: pointer to edma_cc struct
- * @channel: on which edma_pause() has been called
- *
- * This re-enables EDMA hardware events on the specified channel.
- */
+/* Re-enable EDMA hardware events on the specified channel.  */
 static void edma_resume(struct edma_cc *ecc, unsigned channel)
 {
if (ecc->id != EDMA_CTLR(channel)) {
@@ -787,19 +746,6 @@ static int edma_trigger_channel(struct edma_cc *ecc, 
unsigned channel)
return 0;
 }
 
-/**
- *
- * It cleans ParamEntry qand bring back EDMA to initial state if media has
- * been removed before EDMA has finished.It is usedful for removable media.
- * Arguments:
- *  ch_no - channel no
- *
- * Return: zero on success, or corresponding error no on failure
- *
- * FIXME this should not be needed ... edma_stop() should suffice.
- *
- */
-
 static void edma_clean_channel(struct edma_cc *ecc, unsigned channel)
 {
if (ecc->id != EDMA_CTLR(channel)) {
@@ -956,14 +902,7 @@ static void edma_free_channel(struct edma_cc *ecc, 
unsigned channel)
clear_bit(channel, ecc->edma_inuse);
 }
 
-/*
- * edma_assign_channel_eventq - move given channel to desired eventq
- 

[PATCH 16/21] dmaengine: edma: Use the edma_write_slot instead open coded memcpy_toio

2015-09-10 Thread Peter Ujfalusi
edma_write_slot() is for writing an entire paRAM slot.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5b97c11a33af..e735147ccece 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -949,8 +949,7 @@ static void edma_free_channel(struct edma_cc *ecc, unsigned 
channel)
edma_setup_interrupt(ecc, channel, NULL, NULL);
/* REVISIT should probably take out of shadow region 0 */
 
-   memcpy_toio(ecc->base + PARM_OFFSET(channel), _paramset,
-   PARM_SIZE);
+   edma_write_slot(ecc, channel, _paramset);
clear_bit(channel, ecc->edma_inuse);
 }
 
-- 
2.5.1

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


[PATCH 10/21] ARM/dmaengine: edma: Merge the two drivers under drivers/dmaengine

2015-09-10 Thread Peter Ujfalusi
Move the code out from arch/arm/common and merge it inside of the dmaengine
driver.
This change is done with as minimal change to the code as possible to avoid
any possibilities to introducing regression.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/Kconfig   |1 -
 arch/arm/common/Kconfig|3 -
 arch/arm/common/Makefile   |1 -
 arch/arm/common/edma.c | 1432 
 arch/arm/mach-omap2/Kconfig|1 -
 drivers/dma/Kconfig|1 -
 drivers/dma/edma.c | 1409 +--
 include/linux/platform_data/edma.h |   74 --
 8 files changed, 1351 insertions(+), 1571 deletions(-)
 delete mode 100644 arch/arm/common/edma.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724c67ae..513e38701418 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -736,7 +736,6 @@ config ARCH_DAVINCI
select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select HAVE_IDE
-   select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index c3a4e9ceba34..9353184d730d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -17,6 +17,3 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
bool
-
-config TI_PRIV_EDMA
-   bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 6ee5959a813b..27f23b15b1ea 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -15,6 +15,5 @@ obj-$(CONFIG_MCPM)+= mcpm_head.o mcpm_entry.o 
mcpm_platsmp.o vlock.o
 CFLAGS_REMOVE_mcpm_entry.o = -pg
 AFLAGS_mcpm_head.o := -march=armv7-a
 AFLAGS_vlock.o := -march=armv7-a
-obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
 obj-$(CONFIG_BL_SWITCHER)  += bL_switcher.o
 obj-$(CONFIG_BL_SWITCHER_DUMMY_IF) += bL_switcher_dummy_if.o
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
deleted file mode 100644
index 0f29997c62df..
--- a/arch/arm/common/edma.c
+++ /dev/null
@@ -1,1432 +0,0 @@
-/*
- * EDMA3 support for DaVinci
- *
- * Copyright (C) 2006-2009 Texas Instruments.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-/* Offsets matching "struct edmacc_param" */
-#define PARM_OPT   0x00
-#define PARM_SRC   0x04
-#define PARM_A_B_CNT   0x08
-#define PARM_DST   0x0c
-#define PARM_SRC_DST_BIDX  0x10
-#define PARM_LINK_BCNTRLD  0x14
-#define PARM_SRC_DST_CIDX  0x18
-#define PARM_CCNT  0x1c
-
-#define PARM_SIZE  0x20
-
-/* Offsets for EDMA CC global channel registers and their shadows */
-#define SH_ER  0x00/* 64 bits */
-#define SH_ECR 0x08/* 64 bits */
-#define SH_ESR 0x10/* 64 bits */
-#define SH_CER 0x18/* 64 bits */
-#define SH_EER 0x20/* 64 bits */
-#define SH_EECR0x28/* 64 bits */
-#define SH_EESR0x30/* 64 bits */
-#define SH_SER 0x38/* 64 bits */
-#define SH_SECR0x40/* 64 bits */
-#define SH_IER 0x50/* 64 bits */
-#define SH_IECR0x58/* 64 bits */
-#define SH_IESR0x60/* 64 bits */
-#define SH_IPR 0x68/* 64 bits */
-#define SH_ICR 0x70/* 64 bits */
-#define SH_IEVAL   0x78
-#define SH_QER 0x80
-#define SH_QEER0x84
-#define SH_QEECR   0x88
-#define SH_QEESR   0x8c
-#define SH_QSER0x90
-#define SH_QSECR   0x94
-#define SH_SIZE0x200
-
-/* Offsets for EDMA CC global registers */
-#define EDMA_REV   0x
-#define EDMA_CCCFG 0x0004
-#define EDMA_QCHMAP0x0200  /* 8 registers */
-#define EDMA_DMAQNUM   0x0240  /* 8 registers (4 on OMAP-L1xx) */
-#define EDMA_QDMAQNUM  0x0260
-#define EDMA_QUETCMAP  0x0280
-#define EDMA_QUEPRI0x0284
-#define EDMA_EMR   0x0300  /* 64 bits */
-#define EDMA_EMCR  0x0308  /* 64 bits */
-#define EDMA_QEMR  0x0310
-#define EDMA_QEMCR 0x0314

[PATCH 15/21] dmaengine: edma: Use dev_dbg instead pr_debug

2015-09-10 Thread Peter Ujfalusi
We have access to dev, so it is better to use the dev_dbg for debug prints.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 71de1c843bb4..5b97c11a33af 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -655,14 +655,14 @@ static int edma_start(struct edma_cc *ecc, unsigned 
channel)
 
/* EDMA channels without event association */
if (test_bit(channel, ecc->edma_unused)) {
-   pr_debug("EDMA: ESR%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_ESR, j));
+   dev_dbg(ecc->dev, "ESR%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_ESR, j));
edma_shadow0_write_array(ecc, SH_ESR, j, mask);
return 0;
}
 
/* EDMA channel with event association */
-   pr_debug("EDMA: ER%d %08x\n", j,
+   dev_dbg(ecc->dev, "ER%d %08x\n", j,
edma_shadow0_read_array(ecc, SH_ER, j));
/* Clear any pending event or error */
edma_write_array(ecc, EDMA_ECR, j, mask);
@@ -670,8 +670,8 @@ static int edma_start(struct edma_cc *ecc, unsigned channel)
/* Clear any SER */
edma_shadow0_write_array(ecc, SH_SECR, j, mask);
edma_shadow0_write_array(ecc, SH_EESR, j, mask);
-   pr_debug("EDMA: EER%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_EER, j));
+   dev_dbg(ecc->dev, "EER%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_EER, j));
return 0;
}
 
@@ -709,8 +709,8 @@ static void edma_stop(struct edma_cc *ecc, unsigned channel)
/* clear possibly pending completion interrupt */
edma_shadow0_write_array(ecc, SH_ICR, j, mask);
 
-   pr_debug("EDMA: EER%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_EER, j));
+   dev_dbg(ecc->dev, "EER%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_EER, j));
 
/* REVISIT:  consider guarding against inappropriate event
 * chaining by overwriting with dummy_paramset.
@@ -779,8 +779,8 @@ static int edma_trigger_channel(struct edma_cc *ecc, 
unsigned channel)
 
edma_shadow0_write_array(ecc, SH_ESR, (channel >> 5), mask);
 
-   pr_debug("EDMA: ESR%d %08x\n", (channel >> 5),
-edma_shadow0_read_array(ecc, SH_ESR, (channel >> 5)));
+   dev_dbg(ecc->dev, "ESR%d %08x\n", (channel >> 5),
+   edma_shadow0_read_array(ecc, SH_ESR, (channel >> 5)));
return 0;
 }
 
@@ -810,8 +810,8 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
int j = (channel >> 5);
unsigned int mask = BIT(channel & 0x1f);
 
-   pr_debug("EDMA: EMR%d %08x\n", j,
-edma_read_array(ecc, EDMA_EMR, j));
+   dev_dbg(ecc->dev, "EMR%d %08x\n", j,
+   edma_read_array(ecc, EDMA_EMR, j));
edma_shadow0_write_array(ecc, SH_ECR, j, mask);
/* Clear the corresponding EMR bits */
edma_write_array(ecc, EDMA_EMCR, j, mask);
-- 
2.5.1

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


[PATCH 12/21] dmaengine: edma: Parameter alignment and long line fixes

2015-09-10 Thread Peter Ujfalusi
Makes the code a bit more readable.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 84 --
 1 file changed, 44 insertions(+), 40 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 153869c9e13c..bed09ce22ff2 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -294,31 +294,33 @@ static inline void edma_or(struct edma_cc *ecc, int 
offset, unsigned or)
val |= or;
edma_write(ecc, offset, val);
 }
-static inline unsigned int edma_read_array(struct edma_cc *ecc, int offset, 
int i)
+static inline unsigned int edma_read_array(struct edma_cc *ecc, int offset,
+  int i)
 {
return edma_read(ecc, offset + (i << 2));
 }
 static inline void edma_write_array(struct edma_cc *ecc, int offset, int i,
-   unsigned val)
+   unsigned val)
 {
edma_write(ecc, offset + (i << 2), val);
 }
 static inline void edma_modify_array(struct edma_cc *ecc, int offset, int i,
-   unsigned and, unsigned or)
+unsigned and, unsigned or)
 {
edma_modify(ecc, offset + (i << 2), and, or);
 }
-static inline void edma_or_array(struct edma_cc *ecc, int offset, int i, 
unsigned or)
+static inline void edma_or_array(struct edma_cc *ecc, int offset, int i,
+unsigned or)
 {
edma_or(ecc, offset + (i << 2), or);
 }
 static inline void edma_or_array2(struct edma_cc *ecc, int offset, int i, int 
j,
-   unsigned or)
+ unsigned or)
 {
edma_or(ecc, offset + ((i*2 + j) << 2), or);
 }
-static inline void edma_write_array2(struct edma_cc *ecc, int offset, int i, 
int j,
-   unsigned val)
+static inline void edma_write_array2(struct edma_cc *ecc, int offset, int i,
+int j, unsigned val)
 {
edma_write(ecc, offset + ((i*2 + j) << 2), val);
 }
@@ -326,42 +328,43 @@ static inline unsigned int edma_shadow0_read(struct 
edma_cc *ecc, int offset)
 {
return edma_read(ecc, EDMA_SHADOW0 + offset);
 }
-static inline unsigned int edma_shadow0_read_array(struct edma_cc *ecc, int 
offset,
-   int i)
+static inline unsigned int edma_shadow0_read_array(struct edma_cc *ecc,
+  int offset, int i)
 {
return edma_read(ecc, EDMA_SHADOW0 + offset + (i << 2));
 }
-static inline void edma_shadow0_write(struct edma_cc *ecc, int offset, 
unsigned val)
+static inline void edma_shadow0_write(struct edma_cc *ecc, int offset,
+ unsigned val)
 {
edma_write(ecc, EDMA_SHADOW0 + offset, val);
 }
-static inline void edma_shadow0_write_array(struct edma_cc *ecc, int offset, 
int i,
-   unsigned val)
+static inline void edma_shadow0_write_array(struct edma_cc *ecc, int offset,
+   int i, unsigned val)
 {
edma_write(ecc, EDMA_SHADOW0 + offset + (i << 2), val);
 }
 static inline unsigned int edma_parm_read(struct edma_cc *ecc, int offset,
-   int param_no)
+ int param_no)
 {
return edma_read(ecc, EDMA_PARM + offset + (param_no << 5));
 }
-static inline void edma_parm_write(struct edma_cc *ecc, int offset, int 
param_no,
-   unsigned val)
+static inline void edma_parm_write(struct edma_cc *ecc, int offset,
+  int param_no, unsigned val)
 {
edma_write(ecc, EDMA_PARM + offset + (param_no << 5), val);
 }
-static inline void edma_parm_modify(struct edma_cc *ecc, int offset, int 
param_no,
-   unsigned and, unsigned or)
+static inline void edma_parm_modify(struct edma_cc *ecc, int offset,
+   int param_no, unsigned and, unsigned or)
 {
edma_modify(ecc, EDMA_PARM + offset + (param_no << 5), and, or);
 }
 static inline void edma_parm_and(struct edma_cc *ecc, int offset, int param_no,
-   unsigned and)
+unsigned and)
 {
edma_and(ecc, EDMA_PARM + offset + (param_no << 5), and);
 }
 static inline void edma_parm_or(struct edma_cc *ecc, int offset, int param_no,
-   unsigned or)
+   unsigned or)
 {
edma_or(ecc, EDMA_PARM + offset + (param_no << 5), or);
 }
@@ -388,8 +391,8 @@ static void edma_map_dmach_to_queue(struct edma_cc *ecc, 
unsigned ch_no,
queue_no = ecc->default_queue;
 
queue_no &= 7;
-   edma_modify_array(ecc, EDMA_DMAQNUM, (ch_no >> 3),
- ~(0x7 << bit), queue_no << bit);
+   edma_modify_array(ecc, EDMA_DMAQNUM, (ch_no >> 3), ~(0x7 << bit),
+ queue_no << bit);
 }
 
 static void edma_assign_priority_to_queue(struct edma_cc *ecc, int queue_no,
@@ -1134,8 +1137,7 @@ 

[PATCH 09/21] ARM: davinci: Add set dma_mask to eDMA devices

2015-09-10 Thread Peter Ujfalusi
The upcoming change to merge the arch/arm/common/edma.c into
drivers/dma/edma.c will need this change when booting daVinci devices in
no DT mode.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices-da8xx.c | 8 
 arch/arm/mach-davinci/dm355.c | 8 +++-
 arch/arm/mach-davinci/dm644x.c| 8 +++-
 arch/arm/mach-davinci/dm646x.c| 8 +++-
 4 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 9ae049ae816a..495e9293ed2a 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -213,21 +213,29 @@ static struct resource da850_edma1_resources[] = {
},
 };
 
+static u64 da8xx_edma0_dmamask = DMA_BIT_MASK(32);
+
 static struct platform_device da8xx_edma0_device = {
.name   = "edma",
.id = 0,
.dev = {
.platform_data = _edma0_pdata,
+   .dma_mask = _edma0_dmamask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
},
.num_resources  = ARRAY_SIZE(da8xx_edma0_resources),
.resource   = da8xx_edma0_resources,
 };
 
+static u64 da850_edma1_dmamask = DMA_BIT_MASK(32);
+
 static struct platform_device da850_edma1_device = {
.name   = "edma",
.id = 1,
.dev = {
.platform_data = _edma1_pdata,
+   .dma_mask = _edma1_dmamask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
},
.num_resources  = ARRAY_SIZE(da850_edma1_resources),
.resource   = da850_edma1_resources,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a50bb9c66952..0f8c0ab48872 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -613,10 +613,16 @@ static struct resource edma_resources[] = {
/* not using (or muxing) TC*_ERR */
 };
 
+static u64 dm355_edma_dmamask = DMA_BIT_MASK(32);
+
 static struct platform_device dm355_edma_device = {
.name   = "edma",
.id = 0,
-   .dev.platform_data  = _edma_pdata,
+   .dev = {
+   .platform_data  = _edma_pdata,
+   .dma_mask   = _edma_dmamask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
.num_resources  = ARRAY_SIZE(edma_resources),
.resource   = edma_resources,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index d759ca8e58e8..fc8950e5a9a0 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -542,10 +542,16 @@ static struct resource edma_resources[] = {
/* not using TC*_ERR */
 };
 
+static u64 dm644x_edma_dmamask = DMA_BIT_MASK(32);
+
 static struct platform_device dm644x_edma_device = {
.name   = "edma",
.id = 0,
-   .dev.platform_data  = _edma_pdata,
+   .dev = {
+   .platform_data  = _edma_pdata,
+   .dma_mask   = _edma_dmamask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
.num_resources  = ARRAY_SIZE(edma_resources),
.resource   = edma_resources,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 219ebc8f674a..77df905949bc 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -589,10 +589,16 @@ static struct resource edma_resources[] = {
/* not using TC*_ERR */
 };
 
+static u64 dm646x_edma_dmamask = DMA_BIT_MASK(32);
+
 static struct platform_device dm646x_edma_device = {
.name   = "edma",
.id = 0,
-   .dev.platform_data  = _edma_pdata,
+   .dev = {
+   .platform_data  = _edma_pdata,
+   .dma_mask   = _edma_dmamask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
.num_resources  = ARRAY_SIZE(edma_resources),
.resource   = edma_resources,
 };
-- 
2.5.1

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


[PATCH 13/21] dmaengine: edma: Use devm_kcalloc when possible

2015-09-10 Thread Peter Ujfalusi
When allocating a memory for number of items it is better (looks better)
to use devm_kcalloc.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index bed09ce22ff2..0b46d4263ec6 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2034,7 +2034,7 @@ static int edma_setup_from_hw(struct device *dev, struct 
edma_soc_info *pdata,
 * priority. So Q0 is the highest priority queue and the last queue has
 * the lowest priority.
 */
-   queue_priority_map = devm_kzalloc(dev, (ecc->num_tc + 1) * sizeof(s8),
+   queue_priority_map = devm_kcalloc(dev, ecc->num_tc + 1, sizeof(s8),
  GFP_KERNEL);
if (!queue_priority_map)
return -ENOMEM;
@@ -2065,7 +2065,7 @@ static int edma_xbar_event_map(struct device *dev, struct 
edma_soc_info *pdata,
u32 shift, offset, mux;
int ret, i;
 
-   xbar_chans = devm_kzalloc(dev, (nelm + 2) * sizeof(s16), GFP_KERNEL);
+   xbar_chans = devm_kcalloc(dev, nelm + 2, sizeof(s16), GFP_KERNEL);
if (!xbar_chans)
return -ENOMEM;
 
-- 
2.5.1

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


[PATCH 11/21] dmaengine: edma: Allocate memory dynamically for bitmaps and structures

2015-09-10 Thread Peter Ujfalusi
Instead of using defines to specify the size of different arrays and
bitmaps, allocate the memory for them based on the information we get from
the HW itself.
Since these defines are set based on the worst case, there are devices
where they are not valid.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 62 ++
 1 file changed, 34 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index cdde9a69cc59..153869c9e13c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -113,23 +113,6 @@
 #define CHMAP_EXISTBIT(24)
 
 /*
- * This will go away when the private EDMA API is folded
- * into this driver and the platform device(s) are
- * instantiated in the arch code. We can only get away
- * with this simplification because DA8XX may not be built
- * in the same kernel image with other DaVinci parts. This
- * avoids having to sprinkle dmaengine driver platform devices
- * and data throughout all the existing board files.
- */
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
-#define EDMA_CTLRS 2
-#define EDMA_CHANS 32
-#else
-#define EDMA_CTLRS 1
-#define EDMA_CHANS 64
-#endif /* CONFIG_ARCH_DAVINCI_DA8XX */
-
-/*
  * Max of 20 segments per channel to conserve PaRAM slots
  * Also note that MAX_NR_SG should be atleast the no.of periods
  * that are required for ASoC, otherwise DMA prep calls will
@@ -140,16 +123,12 @@
 #define EDMA_MAX_SLOTS MAX_NR_SG
 #define EDMA_DESCRIPTORS   16
 
-#define EDMA_MAX_PARAMENTRY 512
-
 #define EDMA_CHANNEL_ANY   -1  /* for edma_alloc_channel() */
 #define EDMA_SLOT_ANY  -1  /* for edma_alloc_slot() */
 #define EDMA_CONT_PARAMS_ANY1001
 #define EDMA_CONT_PARAMS_FIXED_EXACT1002
 #define EDMA_CONT_PARAMS_FIXED_NOT_EXACT 1003
 
-#define EDMA_MAX_CC   2
-
 /* PaRAM slots are laid out like this */
 struct edmacc_param {
u32 opt;
@@ -256,22 +235,22 @@ struct edma_cc {
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
-   DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY);
+   unsigned long *edma_inuse;
 
/* The edma_unused bit for each channel is clear unless
 * it is not being used on this platform. It uses a bit
 * of SOC-specific initialization code.
 */
-   DECLARE_BITMAP(edma_unused, EDMA_CHANS);
+   unsigned long *edma_unused;
 
struct dma_interrupt_data {
void (*callback)(unsigned channel, unsigned short ch_status,
void *data);
void *data;
-   } intr_data[EDMA_CHANS];
+   } *intr_data;
 
struct dma_device   dma_slave;
-   struct edma_chanslave_chans[EDMA_CHANS];
+   struct edma_chan*slave_chans;
int dummy_slot;
 };
 
@@ -431,6 +410,8 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
struct edma_cc *ecc = data;
+   int dma_req_min = EDMA_CTLR_CHAN(ecc->id, 0);
+   int dma_req_max = dma_req_min + ecc->num_channels;
int i, count;
struct of_phandle_args  dma_spec;
 
@@ -466,11 +447,15 @@ static int prepare_unused_channel_list(struct device 
*dev, void *data)
/* For non-OF case */
for (i = 0; i < pdev->num_resources; i++) {
struct resource *res = >resource[i];
+   int dma_req;
 
-   if ((res->flags & IORESOURCE_DMA) && (int)res->start >= 0) {
+   if (!(res->flags & IORESOURCE_DMA))
+   continue;
+
+   dma_req = (int)res->start;
+   if (dma_req >= dma_req_min && dma_req < dma_req_max)
clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
  ecc->edma_unused);
-   }
}
 
return 0;
@@ -1953,7 +1938,7 @@ static void __init edma_chan_init(struct edma_cc *ecc,
 {
int i, j;
 
-   for (i = 0; i < EDMA_CHANS; i++) {
+   for (i = 0; i < ecc->num_channels; i++) {
struct edma_chan *echan = [i];
echan->ch_num = EDMA_CTLR_CHAN(ecc->id, i);
echan->ecc = ecc;
@@ -,6 +2207,27 @@ static int edma_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   /* Allocate memory based on the information we got from the IP */
+   ecc->slave_chans = devm_kcalloc(dev, ecc->num_channels,
+   sizeof(*ecc->slave_chans), GFP_KERNEL);
+   if (!ecc->slave_chans)
+   return -ENOMEM;
+
+   ecc->intr_data = devm_kcalloc(dev, ecc->num_channels,
+ sizeof(*ecc->intr_data), GFP_KERNEL);

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

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

[PATCH 02/21] ARM: common: edma: Remove unused functions

2015-09-10 Thread Peter Ujfalusi
We no longer have users for these functions so they can be removed.
Remove also unused enums from the header file.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 376 -
 include/linux/platform_data/edma.h |  33 
 2 files changed, 409 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 56fc339571f9..e9c4cb16a47e 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -510,62 +510,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static int reserve_contiguous_slots(int ctlr, unsigned int id,
-unsigned int num_slots,
-unsigned int start_slot)
-{
-   int i, j;
-   unsigned int count = num_slots;
-   int stop_slot = start_slot;
-   DECLARE_BITMAP(tmp_inuse, EDMA_MAX_PARAMENTRY);
-
-   for (i = start_slot; i < edma_cc[ctlr]->num_slots; ++i) {
-   j = EDMA_CHAN_SLOT(i);
-   if (!test_and_set_bit(j, edma_cc[ctlr]->edma_inuse)) {
-   /* Record our current beginning slot */
-   if (count == num_slots)
-   stop_slot = i;
-
-   count--;
-   set_bit(j, tmp_inuse);
-
-   if (count == 0)
-   break;
-   } else {
-   clear_bit(j, tmp_inuse);
-
-   if (id == EDMA_CONT_PARAMS_FIXED_EXACT) {
-   stop_slot = i;
-   break;
-   } else {
-   count = num_slots;
-   }
-   }
-   }
-
-   /*
-* We have to clear any bits that we set
-* if we run out parameter RAM slots, i.e we do find a set
-* of contiguous parameter RAM slots but do not find the exact number
-* requested as we may reach the total number of parameter RAM slots
-*/
-   if (i == edma_cc[ctlr]->num_slots)
-   stop_slot = i;
-
-   j = start_slot;
-   for_each_set_bit_from(j, tmp_inuse, stop_slot)
-   clear_bit(j, edma_cc[ctlr]->edma_inuse);
-
-   if (count)
-   return -EBUSY;
-
-   for (j = i - num_slots + 1; j <= i; ++j)
-   memcpy_toio(edmacc_regs_base[ctlr] + PARM_OFFSET(j),
-   _paramset, PARM_SIZE);
-
-   return EDMA_CTLR_CHAN(ctlr, i - num_slots + 1);
-}
-
 static int prepare_unused_channel_list(struct device *dev, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -818,186 +762,11 @@ void edma_free_slot(unsigned slot)
 }
 EXPORT_SYMBOL(edma_free_slot);
 
-
-/**
- * edma_alloc_cont_slots- alloc contiguous parameter RAM slots
- * The API will return the starting point of a set of
- * contiguous parameter RAM slots that have been requested
- *
- * @id: can only be EDMA_CONT_PARAMS_ANY or EDMA_CONT_PARAMS_FIXED_EXACT
- * or EDMA_CONT_PARAMS_FIXED_NOT_EXACT
- * @count: number of contiguous Paramter RAM slots
- * @slot  - the start value of Parameter RAM slot that should be passed if id
- * is EDMA_CONT_PARAMS_FIXED_EXACT or EDMA_CONT_PARAMS_FIXED_NOT_EXACT
- *
- * If id is EDMA_CONT_PARAMS_ANY then the API starts looking for a set of
- * contiguous Parameter RAM slots from parameter RAM 64 in the case of
- * DaVinci SOCs and 32 in the case of DA8xx SOCs.
- *
- * If id is EDMA_CONT_PARAMS_FIXED_EXACT then the API starts looking for a
- * set of contiguous parameter RAM slots from the "slot" that is passed as an
- * argument to the API.
- *
- * If id is EDMA_CONT_PARAMS_FIXED_NOT_EXACT then the API initially tries
- * starts looking for a set of contiguous parameter RAMs from the "slot"
- * that is passed as an argument to the API. On failure the API will try to
- * find a set of contiguous Parameter RAM slots from the remaining Parameter
- * RAM slots
- */
-int edma_alloc_cont_slots(unsigned ctlr, unsigned int id, int slot, int count)
-{
-   /*
-* The start slot requested should be greater than
-* the number of channels and lesser than the total number
-* of slots
-*/
-   if ((id != EDMA_CONT_PARAMS_ANY) &&
-   (slot < edma_cc[ctlr]->num_channels ||
-   slot >= edma_cc[ctlr]->num_slots))
-   return -EINVAL;
-
-   /*
-* The number of parameter RAM slots requested cannot be less than 1
-* and cannot be more than the number of slots minus the number of
-* channels
-*/
-   if (count < 1 || count >
-   (edma_cc[ctlr]->num_slots - edma_cc[ctlr]->num_channels))
-   return -EINVAL;
-
-   switch (id) {
-   case EDMA_CONT_PARAMS_ANY:
-   return reserve_contiguous_slots(ctlr, id, count,
-  

Re: [PATCH 00/21] dmaengine/ARM: Merge the edma drivers into one

2015-09-10 Thread Arnd Bergmann
On Thursday 10 September 2015 11:37:29 Peter Ujfalusi wrote:
> 
> with this series the edma two driver setup will be changed to have only one
> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
> can
> only be used via dmaengine API from this point on.
> In order to do the merge the following improvements has been done:
> - One driver instance per eDMA:
>  - Any number of eDMA instances are supported (both legacy and DT boot)
> - Not relying on global variables, arrays, etc
> - Code simplification and optimizations in several places
> 
> This change will also help us to do bigger changes in the eDMA driver since,
> since now we have only one driver to work with.
> 

Very nice series, thanks for addressing this long-standing issue!

I've briefly read over the series and did not see anything major
sticking out, but I did not attempt to do a thorough review.

I found two minor things that I commented on that could be improved.

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


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

2015-09-10 Thread Jyri Sarha

On 09/09/15 21:27, Jyri Sarha wrote:

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

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

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index de1e3a8..25ff1fc 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -87,7 +87,6 @@ struct davinci_mcasp {
u8  *serial_dir;
u8  version;
u8  bclk_div;
-   u16 bclk_lrclk_ratio;
int streams;
u32 irq_request[2];
int dma_request[2];
@@ -558,8 +557,21 @@ static int __davinci_mcasp_set_clkdiv(struct snd_soc_dai 
*dai, int div_id,
mcasp->bclk_div = div;
break;

-   case 2: /* BCLK/LRCLK ratio */
-   mcasp->bclk_lrclk_ratio = div;
+   case 2: /*
+* BCLK/LRCLK ratio descries how many bit-clock cycles
+* fit into one frame. The clock ratio is given for a
+* full period of data (for I2S format both left and
+* right channels), so it has to be divided by number
+* of tdm-slots (for I2S - divided by 2).
+* Instead of storing this ratio, we calculate a new
+* tdm_slot width by dividing the the ratio by the
+* number of configured tdm slots.
+*/
+   mcasp->slot_width = div / mcasp->tdm_slots;
+   if (div % mcasp->tdm_slots)
+   dev_warn(mcasp->dev,
+"%s(): BCLK/LRCLK %d is not divisible by %d tdm 
slots",
+div, mcasp->tdm_slots);


Oops, there is a __func__ missing here.


break;

default:
@@ -682,11 +694,13 @@ static int davinci_mcasp_set_tdm_slot(struct snd_soc_dai 
*dai,
  }

  static int davinci_config_channel_size(struct davinci_mcasp *mcasp,
-  int word_length)
+  int sample_width)
  {
u32 fmt;
-   u32 tx_rotate = (word_length / 4) & 0x7;
-   u32 mask = (1ULL << word_length) - 1;
+   u32 tx_rotate = (sample_width / 4) & 0x7;
+   u32 mask = (1ULL << sample_width) - 1;
+   u32 slot_width = sample_width;
+
/*
 * For captured data we should not rotate, inversion and masking is
 * enoguh to get the data to the right position:
@@ -699,31 +713,23 @@ static int davinci_config_channel_size(struct 
davinci_mcasp *mcasp,
u32 rx_rotate = 0;

/*
-* if s BCLK-to-LRCLK ratio has been configured via the set_clkdiv()
-* callback, take it into account here. That allows us to for example
-* send 32 bits per channel to the codec, while only 16 of them carry
-* audio payload.
-* The clock ratio is given for a full period of data (for I2S format
-* both left and right channels), so it has to be divided by number of
-* tdm-slots (for I2S - divided by 2).
+* Setting the tdm slot width either with set_clkdiv() or
+* set_tdm_slot() allows us to for example send 32 bits per
+* channel to the codec, while only 16 of them carry audio
+* payload.
 */
-   if (mcasp->bclk_lrclk_ratio) {
-   u32 slot_length = mcasp->bclk_lrclk_ratio / mcasp->tdm_slots;
-
+   if (mcasp->slot_width) {
/*
-* When we have more bclk then it is needed for the data, we
-* need to use the rotation to move the received samples to have
-* correct alignment.
+* When we have more bclk then it is needed for the
+* data, we need to use the rotation to move the
+* received samples to have correct alignment.
 */
-   rx_rotate = (slot_length - word_length) / 4;
-   word_length = slot_length;
-   } else if (mcasp->slot_width) {
-   rx_rotate = (mcasp->slot_width - word_length) / 4;
-   word_length = mcasp->slot_width;
+   slot_width = mcasp->slot_width;
+   rx_rotate = (slot_width - sample_width) / 4;
}

/* mapping of the XSSZ bit-field as described in the datasheet */
-   fmt = (word_length >> 1) - 1;
+   fmt = (slot_width >> 1) - 1;

if (mcasp->op_mode != DAVINCI_MCASP_DIT_MODE) {
mcasp_mod_bits(mcasp, DAVINCI_MCASP_RXFMT_REG, RXSSZ(fmt),



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

[PATCH 01/21] ARM: common: edma: Fix channel parameter for irq callbacks

2015-09-10 Thread Peter Ujfalusi
In case when the interrupt happened for the second eDMA the channel
number was incorrectly passed to the client driver.

Signed-off-by: Peter Ujfalusi 
CC: 
---
 arch/arm/common/edma.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 873dbfcc7dc9..56fc339571f9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -406,7 +406,8 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
BIT(slot));
if (edma_cc[ctlr]->intr_data[channel].callback)
edma_cc[ctlr]->intr_data[channel].callback(
-   channel, EDMA_DMA_COMPLETE,
+   EDMA_CTLR_CHAN(ctlr, channel),
+   EDMA_DMA_COMPLETE,
edma_cc[ctlr]->intr_data[channel].data);
}
} while (sh_ipr);
@@ -460,7 +461,8 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
if (edma_cc[ctlr]->intr_data[k].
callback) {
edma_cc[ctlr]->intr_data[k].
-   callback(k,
+   callback(
+   EDMA_CTLR_CHAN(ctlr, k),
EDMA_DMA_CC_ERROR,
edma_cc[ctlr]->intr_data
[k].data);
-- 
2.5.1

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


[PATCH 07/21] ARM/dmaengine: edma: Public API to use private struct pointer

2015-09-10 Thread Peter Ujfalusi
Instead of relying on indexes pointing to edma private date in the global
pointer array, pass the private data pointer via the public API.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 305 ++---
 drivers/dma/edma.c |  79 +-
 include/linux/platform_data/edma.h |  38 +++--
 3 files changed, 214 insertions(+), 208 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 5fd8293a48aa..15b68ce98ec7 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -130,7 +130,7 @@ struct edma {
 
struct edma_soc_info *info;
int id;
-
+   boolunused_chan_list_done;
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -264,7 +264,6 @@ static inline void clear_bits(int offset, int len, unsigned 
long *p)
 }
 
 /*/
-static struct edma *edma_cc[EDMA_MAX_CC];
 static int arch_num_cc;
 
 /* dummy param set used to (re)initialize parameter RAM slots */
@@ -490,14 +489,18 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
 static int prepare_unused_channel_list(struct device *dev, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
-   int i, count, ctlr;
+   struct edma *cc = data;
+   int i, count;
struct of_phandle_args  dma_spec;
 
if (dev->of_node) {
+   struct platform_device *dma_pdev;
+
count = of_property_count_strings(dev->of_node, "dma-names");
if (count < 0)
return 0;
for (i = 0; i < count; i++) {
+
if (of_parse_phandle_with_args(dev->of_node, "dmas",
   "#dma-cells", i,
   _spec))
@@ -508,8 +511,12 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
continue;
}
 
+   dma_pdev = of_find_device_by_node(dma_spec.np);
+   if (_pdev->dev != cc->dev)
+   continue;
+
clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
- edma_cc[0]->edma_unused);
+ cc->edma_unused);
of_node_put(dma_spec.np);
}
return 0;
@@ -517,11 +524,11 @@ static int prepare_unused_channel_list(struct device 
*dev, void *data)
 
/* For non-OF case */
for (i = 0; i < pdev->num_resources; i++) {
-   if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
-   (int)pdev->resource[i].start >= 0) {
-   ctlr = EDMA_CTLR(pdev->resource[i].start);
+   struct resource *res = >resource[i];
+
+   if ((res->flags & IORESOURCE_DMA) && (int)res->start >= 0) {
clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
- edma_cc[ctlr]->edma_unused);
+ cc->edma_unused);
}
}
 
@@ -530,8 +537,6 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
 
 /*---*/
 
-static bool unused_chan_list_done;
-
 /* Resource alloc/free:  dma channels, parameter RAM slots */
 
 /**
@@ -564,77 +569,73 @@ static bool unused_chan_list_done;
  *
  * Returns the number of the channel, else negative errno.
  */
-int edma_alloc_channel(int channel,
+int edma_alloc_channel(struct edma *cc, int channel,
void (*callback)(unsigned channel, u16 ch_status, void *data),
void *data,
enum dma_event_q eventq_no)
 {
-   unsigned i, done = 0, ctlr = 0;
+   unsigned done = 0;
int ret = 0;
 
-   if (!unused_chan_list_done) {
+   if (!cc->unused_chan_list_done) {
/*
 * Scan all the platform devices to find out the EDMA channels
 * used and clear them in the unused list, making the rest
 * available for ARM usage.
 */
-   ret = bus_for_each_dev(_bus_type, NULL, NULL,
-   prepare_unused_channel_list);
+   ret = bus_for_each_dev(_bus_type, NULL, cc,
+  prepare_unused_channel_list);
if (ret < 0)
return ret;
 
-   unused_chan_list_done = true;
+   cc->unused_chan_list_done = true;
}
 
if (channel >= 0) {
-   ctlr = EDMA_CTLR(channel);
+   if (cc->id != EDMA_CTLR(channel)) {
+ 

[PATCH 00/21] dmaengine/ARM: Merge the edma drivers into one

2015-09-10 Thread Peter Ujfalusi
Hi,

with this series the edma two driver setup will be changed to have only one
driver to support eDMA3. The legacy edma interface will be removed and eDMA can
only be used via dmaengine API from this point on.
In order to do the merge the following improvements has been done:
- One driver instance per eDMA:
 - Any number of eDMA instances are supported (both legacy and DT boot)
- Not relying on global variables, arrays, etc
- Code simplification and optimizations in several places

This change will also help us to do bigger changes in the eDMA driver since,
since now we have only one driver to work with.

The series has been tested on:
da850-evm (OMAP-L138)
- with legacy and DT boot (both eDMA0 and eDMA1 is enabled)
- In code swapping the eDMA instances in legacy mode to make sure the second
  instance is handled correctly.

am335x-evmsk
- DT boot

I think this series could go via the dmaengine tree. Changes are trivial under
arch/arm/

Regards,
Peter
---
Peter Ujfalusi (21):
  ARM: common: edma: Fix channel parameter for irq callbacks
  ARM: common: edma: Remove unused functions
  dmaengine: edma: Simplify and optimize the edma_execute path
  ARM: davinci/common: Convert edma driver to handle one eDMA instance
per driver
  ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine
driver
  ARM: common: edma: Internal API to use pointer to 'struct edma'
  ARM/dmaengine: edma: Public API to use private struct pointer
  ARM/dmaengine: edma: Remove limitation on the number of eDMA
controllers
  ARM: davinci: Add set dma_mask to eDMA devices
  ARM/dmaengine: edma: Merge the two drivers under drivers/dmaengine
  dmaengine: edma: Allocate memory dynamically for bitmaps and
structures
  dmaengine: edma: Parameter alignment and long line fixes
  dmaengine: edma: Use devm_kcalloc when possible
  dmaengine: edma: Cleanup regarding the use of dev around the code
  dmaengine: edma: Use dev_dbg instead pr_debug
  dmaengine: edma: Use the edma_write_slot instead open coded
memcpy_toio
  dmaengine: edma: Print warning when linking slots from different eDMA
  dmaengine: edma: Consolidate the comments for functions
  dmaengine: edma: Simplify the interrupt handling
  dmaengine: edma: Move the pending error check into helper function
  dmaengine: edma: Simplify and optimize ccerr interrupt handler

 arch/arm/Kconfig  |1 -
 arch/arm/common/Kconfig   |3 -
 arch/arm/common/Makefile  |1 -
 arch/arm/common/edma.c| 1876 -
 arch/arm/mach-davinci/devices-da8xx.c |  118 +--
 arch/arm/mach-davinci/dm355.c |   27 +-
 arch/arm/mach-davinci/dm365.c |   25 +-
 arch/arm/mach-davinci/dm644x.c|   27 +-
 arch/arm/mach-davinci/dm646x.c|   33 +-
 arch/arm/mach-omap2/Kconfig   |1 -
 drivers/dma/Kconfig   |1 -
 drivers/dma/edma.c| 1518 +++---
 include/linux/platform_data/edma.h|  101 --
 13 files changed, 1455 insertions(+), 2277 deletions(-)
 delete mode 100644 arch/arm/common/edma.c

-- 
2.5.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 09/21] ARM: davinci: Add set dma_mask to eDMA devices

2015-09-10 Thread Arnd Bergmann
On Thursday 10 September 2015 11:37:38 Peter Ujfalusi wrote:
> +static u64 da8xx_edma0_dmamask = DMA_BIT_MASK(32);
> +
>  static struct platform_device da8xx_edma0_device = {
> .name   = "edma",
> .id = 0,
> .dev = {
> .platform_data = _edma0_pdata,
> +   .dma_mask = _edma0_dmamask,
> +   .coherent_dma_mask = DMA_BIT_MASK(32),
> },
> .num_resources  = ARRAY_SIZE(da8xx_edma0_resources),
> .resource   = da8xx_edma0_resources,
>  };

While this is technically correct for all I can tell, could you
convert it to use __initconst platform_device_info and
platform_device_register_full() instead?

statically declaring platform_devices has been frowned upon for a long
time (even though a lot of arm platforms still do it), and statically
declaring the dma mask seems worse to me (and yes, I realize we also
do that elsewhere).

Arnd
--
To unsubscribe from this list: send the line "unsubscribe 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/21] ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine driver

2015-09-10 Thread Peter Ujfalusi
If the of_dma_controller is registered in the non dmaengine driver we could
have race condition:
the of_dma_controller has been registered, but the dmaengine driver is not
yet probed. Drivers requesting DMA channels during this window will fail
since we do not yet have dmaengine drivers registered.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 10 --
 drivers/dma/edma.c | 16 
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 72fce68a959f..dc960de1a95f 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -1191,10 +1190,6 @@ static int edma_of_parse_dt(struct device *dev,
return ret;
 }
 
-static struct of_dma_filter_info edma_filter_info = {
-   .filter_fn = edma_filter_fn,
-};
-
 static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
  struct device_node *node)
 {
@@ -1209,11 +1204,6 @@ static struct edma_soc_info 
*edma_setup_info_from_dt(struct device *dev,
if (ret)
return ERR_PTR(ret);
 
-   dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
-   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
-   of_dma_controller_register(dev->of_node, of_dma_simple_xlate,
-  _filter_info);
-
return info;
 }
 #else
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 19fa49d6f555..fcb4680efed7 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -987,9 +988,14 @@ static void edma_dma_init(struct edma_cc *ecc, struct 
dma_device *dma,
INIT_LIST_HEAD(>channels);
 }
 
+static struct of_dma_filter_info edma_filter_info = {
+   .filter_fn = edma_filter_fn,
+};
+
 static int edma_probe(struct platform_device *pdev)
 {
struct edma_cc *ecc;
+   struct device_node *parent_node = pdev->dev.parent->of_node;
int ret;
 
ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
@@ -1024,6 +1030,13 @@ static int edma_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, ecc);
 
+   if (parent_node) {
+   dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
+   of_dma_controller_register(parent_node, of_dma_simple_xlate,
+  _filter_info);
+   }
+
dev_info(>dev, "TI EDMA DMA engine driver\n");
 
return 0;
@@ -1037,7 +1050,10 @@ static int edma_remove(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct edma_cc *ecc = dev_get_drvdata(dev);
+   struct device_node *parent_node = pdev->dev.parent->of_node;
 
+   if (parent_node)
+   of_dma_controller_free(parent_node);
dma_async_device_unregister(>dma_slave);
edma_free_slot(ecc->dummy_slot);
 
-- 
2.5.1

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


[PATCH 08/21] ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers

2015-09-10 Thread Peter Ujfalusi
bla-bla and bla

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 22 +-
 drivers/dma/edma.c | 17 -
 2 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 15b68ce98ec7..0f29997c62df 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1227,24 +1227,7 @@ static int edma_probe(struct platform_device *pdev)
.parent = >dev,
};
 
-   /* When booting with DT the pdev->id is -1 */
-   if (dev_id < 0)
-   dev_id = arch_num_cc;
-
-   if (dev_id >= EDMA_MAX_CC) {
-   dev_err(dev,
-   "eDMA3 with device id 0 and 1 is supported (id: %d)\n",
-   dev_id);
-   return -EINVAL;
-   }
-
if (node) {
-   /* Check if this is a second instance registered */
-   if (arch_num_cc) {
-   dev_err(dev, "only one EDMA instance is supported via 
DT\n");
-   return -ENODEV;
-   }
-
info = edma_setup_info_from_dt(dev, node);
if (IS_ERR(info)) {
dev_err(dev, "failed to get DT data\n");
@@ -1278,6 +1261,11 @@ static int edma_probe(struct platform_device *pdev)
 
cc->dev = dev;
cc->id = dev_id;
+   /* When booting with DT the pdev->id is -1 */
+   if (dev_id < 0) {
+   cc->id = 0;
+   dev_id = arch_num_cc;
+   }
dev_set_drvdata(dev, cc);
 
cc->base = devm_ioremap_resource(dev, mem);
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 53d48b2a700d..fc91ab9dd1bb 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -991,14 +991,12 @@ static void edma_dma_init(struct edma_cc *ecc, struct 
dma_device *dma,
INIT_LIST_HEAD(>channels);
 }
 
-static struct of_dma_filter_info edma_filter_info = {
-   .filter_fn = edma_filter_fn,
-};
-
 static int edma_probe(struct platform_device *pdev)
 {
struct edma_cc *ecc;
struct device_node *parent_node = pdev->dev.parent->of_node;
+   struct platform_device *parent_pdev =
+   to_platform_device(pdev->dev.parent);
int ret;
 
ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
@@ -1015,7 +1013,10 @@ static int edma_probe(struct platform_device *pdev)
if (!ecc->cc)
return -ENODEV;
 
-   ecc->ctlr = pdev->id;
+   ecc->ctlr = parent_pdev->id;
+   if (ecc->ctlr < 0)
+   ecc->ctlr = 0;
+
ecc->dummy_slot = edma_alloc_slot(ecc->cc, EDMA_SLOT_ANY);
if (ecc->dummy_slot < 0) {
dev_err(>dev, "Can't allocate PaRAM dummy slot\n");
@@ -1038,10 +1039,8 @@ static int edma_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ecc);
 
if (parent_node) {
-   dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
-   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
-   of_dma_controller_register(parent_node, of_dma_simple_xlate,
-  _filter_info);
+   of_dma_controller_register(parent_node, of_dma_xlate_by_chan_id,
+  >dma_slave);
}
 
dev_info(>dev, "TI EDMA DMA engine driver\n");
-- 
2.5.1

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


[PATCH 03/21] dmaengine: edma: Simplify and optimize the edma_execute path

2015-09-10 Thread Peter Ujfalusi
The code path in edma_execute() and edma_callback() can be simplified
and make it more optimal.
There is not need to call in to edma_execute() when the transfer
has been finished for example.
Also the handling of missed/first or next batch of paRAMs can
be done in a more optimal way.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 76 +-
 1 file changed, 29 insertions(+), 47 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3e5d4f193005..19fa49d6f555 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -154,15 +154,11 @@ static void edma_execute(struct edma_chan *echan)
struct device *dev = echan->vchan.chan.device->dev;
int i, j, left, nslots;
 
-   /* If either we processed all psets or we're still not started */
-   if (!echan->edesc ||
-   echan->edesc->pset_nr == echan->edesc->processed) {
-   /* Get next vdesc */
+   if (!echan->edesc) {
+   /* Setup is needed for the first transfer */
vdesc = vchan_next_desc(>vchan);
-   if (!vdesc) {
-   echan->edesc = NULL;
+   if (!vdesc)
return;
-   }
list_del(>node);
echan->edesc = to_edma_desc(>tx);
}
@@ -220,28 +216,26 @@ static void edma_execute(struct edma_chan *echan)
  echan->ecc->dummy_slot);
}
 
-   if (edesc->processed <= MAX_NR_SG) {
-   dev_dbg(dev, "first transfer starting on channel %d\n",
-   echan->ch_num);
-   edma_start(echan->ch_num);
-   } else {
-   dev_dbg(dev, "chan: %d: completed %d elements, resuming\n",
-   echan->ch_num, edesc->processed);
-   edma_resume(echan->ch_num);
-   }
-
-   /*
-* This happens due to setup times between intermediate transfers
-* in long SG lists which have to be broken up into transfers of
-* MAX_NR_SG
-*/
if (echan->missed) {
+   /*
+* This happens due to setup times between intermediate
+* transfers in long SG lists which have to be broken up into
+* transfers of MAX_NR_SG
+*/
dev_dbg(dev, "missed event on channel %d\n", echan->ch_num);
edma_clean_channel(echan->ch_num);
edma_stop(echan->ch_num);
edma_start(echan->ch_num);
edma_trigger_channel(echan->ch_num);
echan->missed = 0;
+   } else if (edesc->processed <= MAX_NR_SG) {
+   dev_dbg(dev, "first transfer starting on channel %d\n",
+   echan->ch_num);
+   edma_start(echan->ch_num);
+   } else {
+   dev_dbg(dev, "chan: %d: completed %d elements, resuming\n",
+   echan->ch_num, edesc->processed);
+   edma_resume(echan->ch_num);
}
 }
 
@@ -259,20 +253,17 @@ static int edma_terminate_all(struct dma_chan *chan)
 * echan->edesc is NULL and exit.)
 */
if (echan->edesc) {
-   int cyclic = echan->edesc->cyclic;
-
+   edma_stop(echan->ch_num);
+   /* Move the cyclic channel back to default queue */
+   if (echan->edesc->cyclic)
+   edma_assign_channel_eventq(echan->ch_num,
+  EVENTQ_DEFAULT);
/*
 * free the running request descriptor
 * since it is not in any of the vdesc lists
 */
edma_desc_free(>edesc->vdesc);
-
echan->edesc = NULL;
-   edma_stop(echan->ch_num);
-   /* Move the cyclic channel back to default queue */
-   if (cyclic)
-   edma_assign_channel_eventq(echan->ch_num,
-  EVENTQ_DEFAULT);
}
 
vchan_get_all_descriptors(>vchan, );
@@ -725,41 +716,33 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
void *data)
 
edesc = echan->edesc;
 
-   /* Pause the channel for non-cyclic */
-   if (!edesc || (edesc && !edesc->cyclic))
-   edma_pause(echan->ch_num);
-
+   spin_lock(>vchan.lock);
switch (ch_status) {
case EDMA_DMA_COMPLETE:
-   spin_lock(>vchan.lock);
-
if (edesc) {
if (edesc->cyclic) {
vchan_cyclic_callback(>vdesc);
+   goto out;
} else if (edesc->processed == edesc->pset_nr) {
dev_dbg(dev, "Transfer complete, stopping 
channel %d\n", ch_num);
edesc->residue = 0;

[PATCH 04/21] ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver

2015-09-10 Thread Peter Ujfalusi
Currently we have one device created to handle all (maximum 2) eDMAs in the
system.
With this change all eDMA instance will have it's own device/driver.
This change is needed for further cleanups in the eDMA driver stack since
the one device/driver to handle all eDMAs in the system was not flexible
enough and prevents the upcoming work.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c| 357 +++---
 arch/arm/mach-davinci/devices-da8xx.c | 110 ---
 arch/arm/mach-davinci/dm355.c |  21 +-
 arch/arm/mach-davinci/dm365.c |  25 +--
 arch/arm/mach-davinci/dm644x.c|  21 +-
 arch/arm/mach-davinci/dm646x.c|  27 ++-
 6 files changed, 235 insertions(+), 326 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index e9c4cb16a47e..72fce68a959f 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -235,6 +235,7 @@ static inline void clear_bits(int offset, int len, unsigned 
long *p)
 
 /* actual number of DMA channels and slots on this silicon */
 struct edma {
+   struct device   *dev;
/* how many dma resources of each type */
unsignednum_channels;
unsignednum_region;
@@ -246,6 +247,7 @@ struct edma {
const s8*noevent;
 
struct edma_soc_info *info;
+   int id;
 
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
@@ -258,9 +260,6 @@ struct edma {
 */
DECLARE_BITMAP(edma_unused, EDMA_MAX_DMACH);
 
-   unsignedirq_res_start;
-   unsignedirq_res_end;
-
struct dma_interrupt_data {
void (*callback)(unsigned channel, unsigned short ch_status,
void *data);
@@ -349,17 +348,6 @@ setup_dma_interrupt(unsigned lch,
}
 }
 
-static int irq2ctlr(int irq)
-{
-   if (irq >= edma_cc[0]->irq_res_start && irq <= edma_cc[0]->irq_res_end)
-   return 0;
-   else if (irq >= edma_cc[1]->irq_res_start &&
-   irq <= edma_cc[1]->irq_res_end)
-   return 1;
-
-   return -1;
-}
-
 /**
  *
  * DMA interrupt handler
@@ -367,16 +355,17 @@ static int irq2ctlr(int irq)
  */
 static irqreturn_t dma_irq_handler(int irq, void *data)
 {
+   struct edma *cc = data;
int ctlr;
u32 sh_ier;
u32 sh_ipr;
u32 bank;
 
-   ctlr = irq2ctlr(irq);
+   ctlr = cc->id;
if (ctlr < 0)
return IRQ_NONE;
 
-   dev_dbg(data, "dma_irq_handler\n");
+   dev_dbg(cc->dev, "dma_irq_handler\n");
 
sh_ipr = edma_shadow0_read_array(ctlr, SH_IPR, 0);
if (!sh_ipr) {
@@ -394,7 +383,7 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
u32 slot;
u32 channel;
 
-   dev_dbg(data, "IPR%d %08x\n", bank, sh_ipr);
+   dev_dbg(cc->dev, "IPR%d %08x\n", bank, sh_ipr);
 
slot = __ffs(sh_ipr);
sh_ipr &= ~(BIT(slot));
@@ -404,11 +393,11 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
/* Clear the corresponding IPR bits */
edma_shadow0_write_array(ctlr, SH_ICR, bank,
BIT(slot));
-   if (edma_cc[ctlr]->intr_data[channel].callback)
-   edma_cc[ctlr]->intr_data[channel].callback(
+   if (cc->intr_data[channel].callback)
+   cc->intr_data[channel].callback(
EDMA_CTLR_CHAN(ctlr, channel),
EDMA_DMA_COMPLETE,
-   edma_cc[ctlr]->intr_data[channel].data);
+   cc->intr_data[channel].data);
}
} while (sh_ipr);
 
@@ -423,15 +412,16 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
  */
 static irqreturn_t dma_ccerr_handler(int irq, void *data)
 {
+   struct edma *cc = data;
int i;
int ctlr;
unsigned int cnt = 0;
 
-   ctlr = irq2ctlr(irq);
+   ctlr = cc->id;
if (ctlr < 0)
return IRQ_NONE;
 
-   dev_dbg(data, "dma_ccerr_handler\n");
+   dev_dbg(cc->dev, "dma_ccerr_handler\n");
 
if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
(edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
@@ -446,8 +436,8 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
else if (edma_read_array(ctlr, EDMA_EMR, 1))
j = 1;
if (j >= 0) {
- 

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

2015-09-10 Thread Li Jun
On Wed, Sep 09, 2015 at 01:01:14PM +0300, Roger Quadros wrote:
... ...

>  +return -EINVAL;
> >>>
> >>> Return non-zero, then if err, do we need call usb_otg_add_hcd() after
> >>> usb_otg_register_hcd() fails?
> >>
> >> You should not call usb_otg_register_hcd() but usb_add_hcd().
> >> If that fails then you fail as ususal.
> > 
> > My point is if we use usb_add_hcd(), but failed in usb_otg_register_hcd(),
> > then usb_otg_add_hcd() will be called in *all* error case, is this your
> > expectation?
> > if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
> > return usb_otg_add_hcd(hcd, irqnum, irqflags);
> > 
> 
> Yes, my intention was that if otg fails then it is a non otg HCD so register 
> normally.
> Let me correct my previous statement. If you are absolutely sure
> that the HCD is for otg/dual-role usage then you should call 
> usb_otg_register_hcd().
> 

I think this is not just about a statement, in your usb_otg_register_hcd()
implementation, there are several places will return error, I think only
the first two are for a non-otg HCD case, the following error cases seems
mean this is for otg usage, but it fails in middle of registration, if that
is the case, is it reasonable to call usb_otg_add_hcd()?

>  + * @fsm_running: state machine running/stopped indicator
>  + */
>   struct usb_otg {
>   u8  default_a;
>   
>   struct phy  *phy;
>   /* old usb_phy interface */
>   struct usb_phy  *usb_phy;
>  +
> >>>
> >>> add a blank line?
> >>>
> > 
> > You missed this.
> 
> Sorry. Did you suggest to remove that blank line
> or add a new one before usb_phy?
> 

Remove it.

> > 
>   struct usb_bus  *host;
>   struct usb_gadget   *gadget;
>   
>   enum usb_otg_state  state;
>   
>  +struct device *dev;
>  +struct usb_otg_caps *caps;
>  +struct otg_fsm fsm;
>  +struct otg_fsm_ops fsm_ops;
>  +
>  +/* internal use only */
>  +struct otg_hcd primary_hcd;
>  +struct otg_hcd shared_hcd;
>  +struct otg_gadget_ops *gadget_ops;
>  +struct otg_timer timers[NUM_OTG_FSM_TIMERS];
>  +struct list_head list;
>  +struct work_struct work;
>  -- 
>  2.1.4
> > 
> 
> --
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

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


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

 What if there is another architecture like so?

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

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

 How about adding struct usb_otg parameter to usb_otg_register_hcd()?

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

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

 For existing cases this is sufficient.
 The otg device is either the one supplied during usb_otg_register_hcd
 (cases B and C) or it is the parent device (case A).
>>>
>>> How we differentiate case A and case B at usb_otg_register_hcd?
>>> Would you 

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

2015-09-10 Thread Roger Quadros
On 10/09/15 12:28, Li Jun wrote:
> On Wed, Sep 09, 2015 at 01:01:14PM +0300, Roger Quadros wrote:
> ... ...
> 
>> +return -EINVAL;
>
> Return non-zero, then if err, do we need call usb_otg_add_hcd() after
> usb_otg_register_hcd() fails?

 You should not call usb_otg_register_hcd() but usb_add_hcd().
 If that fails then you fail as ususal.
>>>
>>> My point is if we use usb_add_hcd(), but failed in usb_otg_register_hcd(),
>>> then usb_otg_add_hcd() will be called in *all* error case, is this your
>>> expectation?
>>> if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
>>> return usb_otg_add_hcd(hcd, irqnum, irqflags);
>>>
>>
>> Yes, my intention was that if otg fails then it is a non otg HCD so register 
>> normally.
>> Let me correct my previous statement. If you are absolutely sure
>> that the HCD is for otg/dual-role usage then you should call 
>> usb_otg_register_hcd().
>>
> 
> I think this is not just about a statement, in your usb_otg_register_hcd()
> implementation, there are several places will return error, I think only
> the first two are for a non-otg HCD case, the following error cases seems
> mean this is for otg usage, but it fails in middle of registration, if that
> is the case, is it reasonable to call usb_otg_add_hcd()?

OK. We need to check the return value then and differentiate if it is non-otg
or otg with failure.
If it is non-otg then only we must call usb_otg_add_hcd().

I will fix usb_add_hcd().

> 
>> + * @fsm_running: state machine running/stopped indicator
>> + */
>>  struct usb_otg {
>>  u8  default_a;
>>  
>>  struct phy  *phy;
>>  /* old usb_phy interface */
>>  struct usb_phy  *usb_phy;
>> +
>
> add a blank line?
>
>>>
>>> You missed this.
>>
>> Sorry. Did you suggest to remove that blank line
>> or add a new one before usb_phy?
>>
> 
> Remove it.

OK.

> 
>>>
>>  struct usb_bus  *host;
>>  struct usb_gadget   *gadget;
>>  
>>  enum usb_otg_state  state;
>>  
>> +struct device *dev;
>> +struct usb_otg_caps *caps;
>> +struct otg_fsm fsm;
>> +struct otg_fsm_ops fsm_ops;
>> +
>> +/* internal use only */
>> +struct otg_hcd primary_hcd;
>> +struct otg_hcd shared_hcd;
>> +struct otg_gadget_ops *gadget_ops;
>> +struct otg_timer timers[NUM_OTG_FSM_TIMERS];
>> +struct list_head list;
>> +struct work_struct work;
>> -- 
>> 2.1.4
>>>
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

2015-09-10 Thread Kevin Hilman
On Tue, Sep 1, 2015 at 8:03 AM, Tony Lindgren  wrote:
> * Grygorii Strashko  [150901 07:57]:
>> On 09/01/2015 05:50 PM, Tony Lindgren wrote:
>> >>
>> >>On -next, Above crash signature could be related to race
>> >>"ARM: OMAP2+: omap-device: fix race deferred probe of omap_hsmmc vs 
>> >>omap_device_late_init"
>> >>http://www.spinics.net/lists/linux-omap/msg121622.html
>> >
>> >Good point thanks, yes that's the case. MMC probing fails and then we hit 
>> >this
>> >separate issue while MMC is trying to probe. Applying your fix makes the
>> >abort disappear, but naturally does not get MMC working again.
>>
>> you may need CONFIG_GPIO_PCF857X=y for dra7-evm
>
> This is a regression at least on omap4 as pointed out by Olof.

FWIW, this problem still exists in mainline[1], and note that it fails
for omap2plus_defconfig which already has CONFIG_REGULATOR_PBIAS=y, so
that is not the fix for this issue.

Kevin

[1] 
http://kernelci.org/boot/omap4-panda-es/?mainline_defconfig
--
To unsubscribe from this list: send the line "unsubscribe 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: mysterious crashes on OMAP5 uevm

2015-09-10 Thread Woodruff, Richard
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Russell King - ARM Linux
 
> >  There are 2 workarounds that I know which make the problem go
> >  away (one is enough):
> >  - recompile Xorg with -marm (I'm using Debian armhf so it's
> >  thumb2 by default)
> >  - disable ARCH_MULTI_V6 in the kernel config

This reminds me of a customer crash I saw quite a while ago relating to thumb2. 
 I thought it was fixed but maybe not.

In a couple spots the PSR_IT_MASK was not conditionally handled well in 
ARCH_MULTI_V6 flow.  Some stack sanity check failed and a BUG() was triggered.

Compiling the app for v6 or pulling MULTI from the kernel build solved the 
issue.

Additionally it was not handled correctly in GDB.   The old build of GDB didn't 
do MULTI and needed a hack to be useable on thumb2 code.

Regards,
Richard W.



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

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

Re: [PATCH 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

2015-09-10 Thread Tony Lindgren
* Sebastian Reichel  [150910 13:31]:
> Hi,
> 
> On Thu, Sep 10, 2015 at 10:08:50AM +0200, Sebastian Reichel wrote:
> > > Probably best that Sebastian does it as there's another fix needed
> > > too. It seems the following are needed:
> > > 
> > > - Revert $subject patch 3fc3895e4fe1 ("twl4030_charger: correctly
> > >   handle -EPROBE_DEFER from devm_usb_get_phy_by_node")
> > > 
> > > - Apply compile fix "[PATCH] twl4030_charger: fix another compile
> > >   error"
> 
> I just added these to my next branch:
> 
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/?h=next=aefc574e74bb891ba392d98f2d59a417c774
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/?h=next=e11fc21e756e662e465cac3da6547d438d0b1446

Thanks!

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 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

2015-09-10 Thread Tony Lindgren
* Kevin Hilman  [150910 10:03]:
> On Tue, Sep 1, 2015 at 8:03 AM, Tony Lindgren  wrote:
> > * Grygorii Strashko  [150901 07:57]:
> >> On 09/01/2015 05:50 PM, Tony Lindgren wrote:
> >> >>
> >> >>On -next, Above crash signature could be related to race
> >> >>"ARM: OMAP2+: omap-device: fix race deferred probe of omap_hsmmc vs 
> >> >>omap_device_late_init"
> >> >>http://www.spinics.net/lists/linux-omap/msg121622.html
> >> >
> >> >Good point thanks, yes that's the case. MMC probing fails and then we hit 
> >> >this
> >> >separate issue while MMC is trying to probe. Applying your fix makes the
> >> >abort disappear, but naturally does not get MMC working again.
> >>
> >> you may need CONFIG_GPIO_PCF857X=y for dra7-evm
> >
> > This is a regression at least on omap4 as pointed out by Olof.
> 
> FWIW, this problem still exists in mainline[1], and note that it fails
> for omap2plus_defconfig which already has CONFIG_REGULATOR_PBIAS=y, so
> that is not the fix for this issue.

There are also the pbias regulator fixes pending.. And the .dts
fixes pending.. So looks like it's going to be few more days.

AFAIK, also the multi_v7_defconfig change is needed..

Regards,

Tony
 
> [1] 
> http://kernelci.org/boot/omap4-panda-es/?mainline_defconfig
--
To unsubscribe from this list: send the line "unsubscribe 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/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

2015-09-10 Thread Sebastian Reichel
Hi,

On Thu, Sep 10, 2015 at 10:08:50AM +0200, Sebastian Reichel wrote:
> > Probably best that Sebastian does it as there's another fix needed
> > too. It seems the following are needed:
> > 
> > - Revert $subject patch 3fc3895e4fe1 ("twl4030_charger: correctly
> >   handle -EPROBE_DEFER from devm_usb_get_phy_by_node")
> > 
> > - Apply compile fix "[PATCH] twl4030_charger: fix another compile
> >   error"

I just added these to my next branch:

https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/?h=next=aefc574e74bb891ba392d98f2d59a417c774
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/?h=next=e11fc21e756e662e465cac3da6547d438d0b1446

-- Sebastian


signature.asc
Description: Digital signature