* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Shimoda, Yoshihiro @ 2012-01-27 8:37 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-kernel, linux-sh, Vinod Koul, Magnus Damm, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <1327589784-4287-2-git-send-email-g.liakhovetski@gmx.de>
Hello Guennadi-san,
2012/01/26 23:56, Guennadi Liakhovetski wrote:
> This patch adds a library of functions, helping to implement dmaengine
> drivers for hardware, unable to handle scatter-gather lists natively.
> The first version of this driver only supports memcpy and slave DMA
> operation.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> v2:
>
> 1. switch from using a tasklet to threaded IRQ, which allowed to
I tested this driver on 2 environment, but it could not work correctly.
- renesas_usbhs driver with shdma driver on the mackerel board
- renesas_usbhs driver with experimental SUDMAC driver
In this case, should we modify the renesas_usbhs driver?
For reference, if I changed the threaded IRQ to tasklet,
the 2 environment worked correctly:
==============
diff --git a/drivers/dma/dma-simple.c b/drivers/dma/dma-simple.c
index 49d8f7d..65a5170 100644
--- a/drivers/dma/dma-simple.c
+++ b/drivers/dma/dma-simple.c
@@ -715,16 +715,18 @@ static irqreturn_t chan_irq(int irq, void *dev)
spin_lock(&schan->chan_lock);
- ret = ops->chan_irq(schan, irq) ? IRQ_WAKE_THREAD : IRQ_NONE;
+ ret = ops->chan_irq(schan, irq) ? IRQ_HANDLED : IRQ_NONE;
+ if (ret == IRQ_HANDLED)
+ tasklet_schedule(&schan->tasklet);
spin_unlock(&schan->chan_lock);
return ret;
}
-static irqreturn_t chan_irqt(int irq, void *dev)
+static void chan_irqt(unsigned long dev)
{
- struct dma_simple_chan *schan = dev;
+ struct dma_simple_chan *schan = (struct dma_simple_chan *)dev;
const struct dma_simple_ops *ops =
to_simple_dev(schan->dma_chan.device)->ops;
struct dma_simple_desc *sdesc;
@@ -744,15 +746,13 @@ static irqreturn_t chan_irqt(int irq, void *dev)
spin_unlock_irq(&schan->chan_lock);
simple_chan_ld_cleanup(schan, false);
-
- return IRQ_HANDLED;
}
int dma_simple_request_irq(struct dma_simple_chan *schan, int irq,
unsigned long flags, const char *name)
{
- int ret = request_threaded_irq(irq, chan_irq, chan_irqt,
- flags, name, schan);
+ int ret = request_irq(irq, chan_irq, flags, name, schan);
+ tasklet_init(&schan->tasklet, chan_irqt, (unsigned long)schan);
schan->irq = ret < 0 ? ret : irq;
diff --git a/include/linux/dma-simple.h b/include/linux/dma-simple.h
index 5336674..beb1489 100644
--- a/include/linux/dma-simple.h
+++ b/include/linux/dma-simple.h
@@ -68,6 +68,7 @@ struct dma_simple_chan {
int id; /* Raw id of this channel */
int irq; /* Channel IRQ */
enum dma_simple_pm_state pm_state;
+ struct tasklet_struct tasklet;
};
/**
==============
Best regards,
Yoshihiro Shimoda
^ permalink raw reply related
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Guennadi Liakhovetski @ 2012-01-27 8:48 UTC (permalink / raw)
To: Shimoda, Yoshihiro
Cc: linux-kernel, linux-sh, Vinod Koul, Magnus Damm, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <4F22624E.2090201@renesas.com>
Hi Shimoda-san
On Fri, 27 Jan 2012, Shimoda, Yoshihiro wrote:
> Hello Guennadi-san,
>
> 2012/01/26 23:56, Guennadi Liakhovetski wrote:
> > This patch adds a library of functions, helping to implement dmaengine
> > drivers for hardware, unable to handle scatter-gather lists natively.
> > The first version of this driver only supports memcpy and slave DMA
> > operation.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> >
> > v2:
> >
> > 1. switch from using a tasklet to threaded IRQ, which allowed to
>
> I tested this driver on 2 environment, but it could not work correctly.
> - renesas_usbhs driver with shdma driver on the mackerel board
> - renesas_usbhs driver with experimental SUDMAC driver
>
> In this case, should we modify the renesas_usbhs driver?
Yes, you do. Please, see the respective version of the shdma patch. It
doesn't request channel IRQs any more directly, instead, it uses a
dma-simple wrapper function. Also operations change a bit.
Thanks
Guennadi
> For reference, if I changed the threaded IRQ to tasklet,
> the 2 environment worked correctly:
> ==============
> diff --git a/drivers/dma/dma-simple.c b/drivers/dma/dma-simple.c
> index 49d8f7d..65a5170 100644
> --- a/drivers/dma/dma-simple.c
> +++ b/drivers/dma/dma-simple.c
> @@ -715,16 +715,18 @@ static irqreturn_t chan_irq(int irq, void *dev)
>
> spin_lock(&schan->chan_lock);
>
> - ret = ops->chan_irq(schan, irq) ? IRQ_WAKE_THREAD : IRQ_NONE;
> + ret = ops->chan_irq(schan, irq) ? IRQ_HANDLED : IRQ_NONE;
> + if (ret == IRQ_HANDLED)
> + tasklet_schedule(&schan->tasklet);
>
> spin_unlock(&schan->chan_lock);
>
> return ret;
> }
>
> -static irqreturn_t chan_irqt(int irq, void *dev)
> +static void chan_irqt(unsigned long dev)
> {
> - struct dma_simple_chan *schan = dev;
> + struct dma_simple_chan *schan = (struct dma_simple_chan *)dev;
> const struct dma_simple_ops *ops =
> to_simple_dev(schan->dma_chan.device)->ops;
> struct dma_simple_desc *sdesc;
> @@ -744,15 +746,13 @@ static irqreturn_t chan_irqt(int irq, void *dev)
> spin_unlock_irq(&schan->chan_lock);
>
> simple_chan_ld_cleanup(schan, false);
> -
> - return IRQ_HANDLED;
> }
>
> int dma_simple_request_irq(struct dma_simple_chan *schan, int irq,
> unsigned long flags, const char *name)
> {
> - int ret = request_threaded_irq(irq, chan_irq, chan_irqt,
> - flags, name, schan);
> + int ret = request_irq(irq, chan_irq, flags, name, schan);
> + tasklet_init(&schan->tasklet, chan_irqt, (unsigned long)schan);
>
> schan->irq = ret < 0 ? ret : irq;
>
> diff --git a/include/linux/dma-simple.h b/include/linux/dma-simple.h
> index 5336674..beb1489 100644
> --- a/include/linux/dma-simple.h
> +++ b/include/linux/dma-simple.h
> @@ -68,6 +68,7 @@ struct dma_simple_chan {
> int id; /* Raw id of this channel */
> int irq; /* Channel IRQ */
> enum dma_simple_pm_state pm_state;
> + struct tasklet_struct tasklet;
> };
>
> /**
> ==============
>
> Best regards,
> Yoshihiro Shimoda
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* 8250 regression: infinite interrupts
From: Jiri Slaby @ 2012-01-27 14:22 UTC (permalink / raw)
To: philippe.langlais, Alan Cox, Greg KH, Linux kernel mailing list,
linux-serial
Hi,
the commit below causes infinite interrupts to be generated on some
chips. Namely on IBM x3850 M2.
commit 235dae5d094c415fcf0fc79fa637f1901bc8afe2
Author: Philippe Langlais <philippe.langlais@stericsson.com>
Date: Thu Jul 29 17:13:57 2010 +0200
U6715 16550A serial driver support
The culprit is the added size_fifo call proper in autoconfig_16550a. It
returns 16, but the chip is confused by what the function does at that
point. It is yet to be investigated why. Any ideas at this stage why
this could be a problem?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: 8250 regression: infinite interrupts
From: Linus Walleij @ 2012-01-28 10:50 UTC (permalink / raw)
To: Jiri Slaby
Cc: philippe.langlais, Alan Cox, Greg KH, Linux kernel mailing list,
linux-serial
In-Reply-To: <4F22B326.4060605@suse.cz>
2012/1/27 Jiri Slaby <jslaby@suse.cz>:
> The culprit is the added size_fifo call proper in autoconfig_16550a. It
> returns 16, but the chip is confused by what the function does at that
> point. It is yet to be investigated why. Any ideas at this stage why
> this could be a problem?
The header says the function sometimes fail :-/
What it does is set the UART in loopback mode and saturate it with
256 bytes to overflow the FIFO, then check how many chars
were in the FIFO to determine FIFO size.
Could it be that your variant does not clear the FIFO overflow
correctly and get stuck in some error state? Maybe try clearing
some error flags at the end of this function?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Vinod Koul @ 2012-01-30 8:32 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-kernel, linux-sh, Magnus Damm, Yoshihiro Shimoda, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <1327589784-4287-2-git-send-email-g.liakhovetski@gmx.de>
On Thu, 2012-01-26 at 15:56 +0100, Guennadi Liakhovetski wrote:
> This patch adds a library of functions, helping to implement dmaengine
> drivers for hardware, unable to handle scatter-gather lists natively.
> The first version of this driver only supports memcpy and slave DMA
> operation.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> v2:
>
> 1. switch from using a tasklet to threaded IRQ, which allowed to
> 2. remove lock / unlock inline functions
> 3. remove __devinit, __devexit annotations
Sorry to join the discussion late, was on vacation, travel, long
weekend...
I don't still comprehend the need for a library on top of dmaengine
which gain is just a library between clients and dmacs. Surely we don't
want to write another abstraction on top of one provided?
If the question is to handle scatter-gather even if the hardware doesn't
have the capability, then why don't add that in dmaengine itself rather
than one more layer?
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Guennadi Liakhovetski @ 2012-01-30 9:34 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-kernel, linux-sh, Magnus Damm, Yoshihiro Shimoda, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <1327912346.1527.13.camel@vkoul-udesk3>
Hi Vinod
Thanks for your email.
On Mon, 30 Jan 2012, Vinod Koul wrote:
> On Thu, 2012-01-26 at 15:56 +0100, Guennadi Liakhovetski wrote:
> > This patch adds a library of functions, helping to implement dmaengine
> > drivers for hardware, unable to handle scatter-gather lists natively.
> > The first version of this driver only supports memcpy and slave DMA
> > operation.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> >
> > v2:
> >
> > 1. switch from using a tasklet to threaded IRQ, which allowed to
> > 2. remove lock / unlock inline functions
> > 3. remove __devinit, __devexit annotations
> Sorry to join the discussion late, was on vacation, travel, long
> weekend...
>
> I don't still comprehend the need for a library on top of dmaengine
> which gain is just a library between clients and dmacs. Surely we don't
> want to write another abstraction on top of one provided?
>
> If the question is to handle scatter-gather even if the hardware doesn't
> have the capability, then why don't add that in dmaengine itself rather
> than one more layer?
Well, yes, adding new abstraction layers is always a decision, that has to
be well justified. In this case it does at least make the life easier for
two sh-mobile drivers: shdma and the new SUDMAC driver.
However, I did name the library in a generic way without reference to sh,
assuming, that it might with time become useful for other architectures
too. The reasons why I prefered to keep it as an optional addition to
dmaengine core, instead of tightly integrating it with it are, that (1) I
did not want to add useless code to drivers, that do not need it, (2) I am
not sure if and when this library will become useful for other drivers:
apart from sh I am only familiar with one more dmaengine driver:
ipu/ipu_idmac.c, and that one supports scatter-gather lists in a limited
way and has some further peculiarities, that would likely make it a bad
match for the simple DMA library, (3) keeping it separate makes its
further development easier.
OTOH, I'm certainly fine with a tighter library integration with the
dmaengine core. I think, it still would be better to keep it in a separate
file and only build it if needed, right? This woult also simplify code
debugging and further development. I can remove the "simple" notation,
which does make it look like an additional abstraction layer, and replace
it with, say, sgsoft (scatter-gather software implementation)? A more
interesting question is what to do with struct dma_simple_dev, struct
dma_simple_chan, struct dma_simple_desc, that embed struct dma_device,
struct dma_chan and struct dma_async_tx_descriptor respectively. I don't
think we want to merge all the additions from those wrapping structs back
into their dmaengine counterparts?
How would you like to do this? Don't you think, it would be good to allow
both: either implement a dmaengine driver directly, exactly as all drivers
are doing now, or use the additional helper library for suitable (simple)
hardware types? I see it similar to I2C, where you either implement an I2C
driver directly, or you use the bitbanging abstraction for simpler
hardware.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v2 0/3] tty: serial: OMAP: work around broken IP block, driver
From: Kevin Hilman @ 2012-01-30 19:13 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-omap, linux-serial, linux-arm-kernel, Govindraj.R,
Tomi Valkeinen, Greg Kroah-Hartman, Alan Cox
In-Reply-To: <20120126024903.31613.24730.stgit@dusk>
Paul Walmsley <paul@pwsan.com> writes:
> [ This series is targeted for merging during v3.3-rc ]
>
> Hi
>
> Here's an updated version of OMAP serial bugfix series against v3.3-rc1.
> This revision has:
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Tested on 3430/n900, 3530/Overo and 4430/Panda
Kevin
^ permalink raw reply
* [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Greg KH @ 2012-01-30 21:12 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-serial
Here are some tty/serial patches for 3.3-rc1
Big thing here is the movement of the 8250 serial drivers to their own
directory, now that the patch churn has calmed down.
Other than that, only minor stuff (omap patches were reverted as they
were found to be wrong), and another broken driver removed from the
system.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-3.1-rc1
All of these patches have been in the -mm and -next trees for a while.
Patches will be sent to the linux-serial mailing list, if anyone wants
to see them.
thanks,
greg k-h
------------
Documentation/DocBook/device-drivers.tmpl | 1 -
MAINTAINERS | 2 +-
drivers/tty/serial/{ => 8250}/8250.c | 0
drivers/tty/serial/{ => 8250}/8250.h | 0
drivers/tty/serial/{ => 8250}/8250_accent.c | 0
drivers/tty/serial/{ => 8250}/8250_acorn.c | 0
drivers/tty/serial/{ => 8250}/8250_boca.c | 0
drivers/tty/serial/{ => 8250}/8250_dw.c | 0
drivers/tty/serial/{ => 8250}/8250_early.c | 0
drivers/tty/serial/{ => 8250}/8250_exar_st16c554.c | 0
drivers/tty/serial/{ => 8250}/8250_fourport.c | 0
drivers/tty/serial/{ => 8250}/8250_fsl.c | 0
drivers/tty/serial/{ => 8250}/8250_gsc.c | 0
drivers/tty/serial/{ => 8250}/8250_hp300.c | 0
drivers/tty/serial/{ => 8250}/8250_hub6.c | 0
drivers/tty/serial/{ => 8250}/8250_mca.c | 0
drivers/tty/serial/{ => 8250}/8250_pci.c | 0
drivers/tty/serial/{ => 8250}/8250_pnp.c | 0
drivers/tty/serial/8250/Kconfig | 280 ++++++++++++++++
drivers/tty/serial/8250/Makefile | 20 ++
drivers/tty/serial/{ => 8250}/m32r_sio.c | 0
drivers/tty/serial/{ => 8250}/m32r_sio.h | 0
drivers/tty/serial/{ => 8250}/m32r_sio_reg.h | 0
drivers/tty/serial/{ => 8250}/serial_cs.c | 0
drivers/tty/serial/Kconfig | 283 +----------------
drivers/tty/serial/Makefile | 20 +-
drivers/tty/serial/amba-pl011.c | 30 ++-
drivers/tty/serial/jsm/jsm_driver.c | 1 +
drivers/tty/serial/max3107-aava.c | 344 --------------------
drivers/tty/serial/omap-serial.c | 4 +-
drivers/tty/serial/serial_core.c | 6 +-
drivers/tty/tty_port.c | 12 +-
32 files changed, 346 insertions(+), 657 deletions(-)
rename drivers/tty/serial/{ => 8250}/8250.c (100%)
rename drivers/tty/serial/{ => 8250}/8250.h (100%)
rename drivers/tty/serial/{ => 8250}/8250_accent.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_acorn.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_boca.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_dw.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_early.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_exar_st16c554.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_fourport.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_fsl.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_gsc.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_hp300.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_hub6.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_mca.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_pci.c (100%)
rename drivers/tty/serial/{ => 8250}/8250_pnp.c (100%)
create mode 100644 drivers/tty/serial/8250/Kconfig
create mode 100644 drivers/tty/serial/8250/Makefile
rename drivers/tty/serial/{ => 8250}/m32r_sio.c (100%)
rename drivers/tty/serial/{ => 8250}/m32r_sio.h (100%)
rename drivers/tty/serial/{ => 8250}/m32r_sio_reg.h (100%)
rename drivers/tty/serial/{ => 8250}/serial_cs.c (100%)
delete mode 100644 drivers/tty/serial/max3107-aava.c
---------------
Alan Cox (1):
serial: Kill off Moorestown code
Greg Kroah-Hartman (2):
Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip"
Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode"
Jiri Slaby (1):
TTY: fix UV serial console regression
Lucas Kannebley Tavares (2):
Updated TTY MAINTAINERS info
jsm: Fixed EEH recovery error
Paul Gortmaker (1):
serial: group all the 8250 related code together
Paul Walmsley (2):
tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode
tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip
Rabin Vincent (1):
serial: amba-pl011: lock console writes against interrupts
Randy Dunlap (1):
docbook: don't use serial_core.h in device-drivers book
Shreshtha Kumar Sahu (1):
amba-pl011: do not disable RTS during shutdown
Shubhrajyoti D (2):
omap-serial :Make the suspend/resume functions depend on CONFIG_PM_SLEEP.
omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME
Simon Glass (1):
serial: Fix wakeup init logic to speed up startup
^ permalink raw reply
* Re: [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Linus Torvalds @ 2012-01-30 23:19 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <20120130211241.GA12941@kroah.com>
On Mon, Jan 30, 2012 at 1:12 PM, Greg KH <gregkh@suse.de> wrote:
> Here are some tty/serial patches for 3.3-rc1
>
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-3.1-rc1
Tssk. Your script is broken, or your manual fixup is broken. Look at
the tag-name again.
I pulled the correct one, but please be more careful.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Linus Torvalds @ 2012-01-30 23:20 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <CA+55aFxFtsOj+9RYQGj+WEk3ovg4+d_syn8TooKjvBq2_B463Q@mail.gmail.com>
On Mon, Jan 30, 2012 at 3:19 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Tssk. Your script is broken, or your manual fixup is broken. Look at
> the tag-name again.
>
> I pulled the correct one, but please be more careful.
Oh, and if it's because your old script can't verify the tag-names, so
you fix things up by hand instead of scripting it, try using
"tags/<tagname>" instead of just "<tagname>". That makes old git
versions at least see the reference, even if they don't then react to
the signing itself (ie they just treat it as the commit it points to,
rather than as a tag with interesting contents in itself)
Linus
^ permalink raw reply
* Re: [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Greg KH @ 2012-01-31 0:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <CA+55aFxGf8-Bv8Jrhm1dbTg6AkTi37Vfuw5OOC7hDokKRa4hjw@mail.gmail.com>
On Mon, Jan 30, 2012 at 03:20:52PM -0800, Linus Torvalds wrote:
> On Mon, Jan 30, 2012 at 3:19 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Tssk. Your script is broken, or your manual fixup is broken. Look at
> > the tag-name again.
> >
> > I pulled the correct one, but please be more careful.
>
> Oh, and if it's because your old script can't verify the tag-names, so
> you fix things up by hand instead of scripting it, try using
> "tags/<tagname>" instead of just "<tagname>". That makes old git
> versions at least see the reference, even if they don't then react to
> the signing itself (ie they just treat it as the commit it points to,
> rather than as a tag with interesting contents in itself)
Ah, ok, I'll try that out.
Or I can spend the time to get the new version of git installed.
Wrestling with my scripts or rpm, I don't know which is worse...
greg k-h
^ permalink raw reply
* Re: [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Greg KH @ 2012-01-31 0:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <CA+55aFxFtsOj+9RYQGj+WEk3ovg4+d_syn8TooKjvBq2_B463Q@mail.gmail.com>
On Mon, Jan 30, 2012 at 03:19:07PM -0800, Linus Torvalds wrote:
> On Mon, Jan 30, 2012 at 1:12 PM, Greg KH <gregkh@suse.de> wrote:
> > Here are some tty/serial patches for 3.3-rc1
> >
> > Please pull from:
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-3.1-rc1
>
> Tssk. Your script is broken, or your manual fixup is broken. Look at
> the tag-name again.
>
> I pulled the correct one, but please be more careful.
Crap, that was my fault, I typed that by hand. I'll verify it next time
before I send it out.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Linus Torvalds @ 2012-01-31 0:27 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <20120131001308.GB20588@suse.de>
On Mon, Jan 30, 2012 at 4:13 PM, Greg KH <gregkh@suse.de> wrote:
>
> Or I can spend the time to get the new version of git installed.
> Wrestling with my scripts or rpm, I don't know which is worse...
Why do either?
The sane way to do things is to just
cd
mkdir src
cd src
git clone git://github.com/gitster/git
cd git
make
make install
all as a regular user. It will install in your $(HOME)/bin, so just
put that first in the path. No need to fight rpm, no need to fight
your scripts, you should be pretty much all done.
Linus
^ permalink raw reply
* Re: [GIT PATCH] TTY/serial patches for 3.3-rc1
From: Greg KH @ 2012-01-31 1:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <CA+55aFxXwZmhC4USJSOk_itatwkg1m8gkQRTqKHNRGDWD8MCOw@mail.gmail.com>
On Mon, Jan 30, 2012 at 04:27:22PM -0800, Linus Torvalds wrote:
> On Mon, Jan 30, 2012 at 4:13 PM, Greg KH <gregkh@suse.de> wrote:
> >
> > Or I can spend the time to get the new version of git installed.
> > Wrestling with my scripts or rpm, I don't know which is worse...
>
> Why do either?
>
> The sane way to do things is to just
>
> cd
> mkdir src
> cd src
> git clone git://github.com/gitster/git
> cd git
> make
> make install
>
> all as a regular user. It will install in your $(HOME)/bin, so just
> put that first in the path. No need to fight rpm, no need to fight
> your scripts, you should be pretty much all done.
Nice, for some reason I thought it would do the horrible /usr/local/
thing, and get all messed up with the installed version.
Ok, now done, so much for fighting with rpm, thanks, that made my day.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Vinod Koul @ 2012-01-31 6:41 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-kernel, linux-sh, Magnus Damm, Yoshihiro Shimoda, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1201300944360.7932@axis700.grange>
On Mon, 2012-01-30 at 10:34 +0100, Guennadi Liakhovetski wrote:
> > I don't still comprehend the need for a library on top of dmaengine
> > which gain is just a library between clients and dmacs. Surely we don't
> > want to write another abstraction on top of one provided?
> >
> > If the question is to handle scatter-gather even if the hardware doesn't
> > have the capability, then why don't add that in dmaengine itself rather
> > than one more layer?
>
> Well, yes, adding new abstraction layers is always a decision, that has to
> be well justified. In this case it does at least make the life easier for
> two sh-mobile drivers: shdma and the new SUDMAC driver.
>
> However, I did name the library in a generic way without reference to sh,
> assuming, that it might with time become useful for other architectures
> too. The reasons why I prefered to keep it as an optional addition to
> dmaengine core, instead of tightly integrating it with it are, that (1) I
> did not want to add useless code to drivers, that do not need it,
So are we sure that only sh-mobile drivers need this capablity?
Btw does you hardware only support single transfers and no sg support,
would this remain the same in future?
> (2) I am
> not sure if and when this library will become useful for other drivers:
> apart from sh I am only familiar with one more dmaengine driver:
> ipu/ipu_idmac.c, and that one supports scatter-gather lists in a limited
> way and has some further peculiarities, that would likely make it a bad
> match for the simple DMA library,
typically the dmacs will support this in some form or other, so your
point is valid :)
> (3) keeping it separate makes its
> further development easier.
>
> OTOH, I'm certainly fine with a tighter library integration with the
> dmaengine core. I think, it still would be better to keep it in a separate
> file and only build it if needed, right? This woult also simplify code
> debugging and further development. I can remove the "simple" notation,
> which does make it look like an additional abstraction layer, and replace
> it with, say, sgsoft (scatter-gather software implementation)?
that would be more apt :)
> A more
> interesting question is what to do with struct dma_simple_dev, struct
> dma_simple_chan, struct dma_simple_desc, that embed struct dma_device,
> struct dma_chan and struct dma_async_tx_descriptor respectively. I don't
> think we want to merge all the additions from those wrapping structs back
> into their dmaengine counterparts?
Sure they should be kept separate. I like the wrapping, this keeps it
simple.
>
> How would you like to do this? Don't you think, it would be good to allow
> both: either implement a dmaengine driver directly, exactly as all drivers
> are doing now, or use the additional helper library for suitable (simple)
> hardware types? I see it similar to I2C, where you either implement an I2C
> driver directly, or you use the bitbanging abstraction for simpler
> hardware.
I think it would be good to have both, this can be used by folks who
don't have sg support available.
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Guennadi Liakhovetski @ 2012-01-31 8:59 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-kernel, linux-sh, Magnus Damm, Yoshihiro Shimoda, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <1327992090.1527.116.camel@vkoul-udesk3>
Hi Vinod
Thanks for your reply.
On Tue, 31 Jan 2012, Vinod Koul wrote:
> On Mon, 2012-01-30 at 10:34 +0100, Guennadi Liakhovetski wrote:
> > > I don't still comprehend the need for a library on top of dmaengine
> > > which gain is just a library between clients and dmacs. Surely we don't
> > > want to write another abstraction on top of one provided?
> > >
> > > If the question is to handle scatter-gather even if the hardware doesn't
> > > have the capability, then why don't add that in dmaengine itself rather
> > > than one more layer?
> >
> > Well, yes, adding new abstraction layers is always a decision, that has to
> > be well justified. In this case it does at least make the life easier for
> > two sh-mobile drivers: shdma and the new SUDMAC driver.
> >
> > However, I did name the library in a generic way without reference to sh,
> > assuming, that it might with time become useful for other architectures
> > too. The reasons why I prefered to keep it as an optional addition to
> > dmaengine core, instead of tightly integrating it with it are, that (1) I
> > did not want to add useless code to drivers, that do not need it,
> So are we sure that only sh-mobile drivers need this capablity?
If I was sure about that, I'd call the library shmobile-dma or something
similar:-)
> Btw does you hardware only support single transfers and no sg support,
Well, the controller does have some repeat- and reload-modes, but they are
currently not supported by the driver and from the documentation I cannot
easily understand, how useful those modes could be to implement SG.
> would this remain the same in future?
Who knows?...
> > (2) I am
> > not sure if and when this library will become useful for other drivers:
> > apart from sh I am only familiar with one more dmaengine driver:
> > ipu/ipu_idmac.c, and that one supports scatter-gather lists in a limited
> > way and has some further peculiarities, that would likely make it a bad
> > match for the simple DMA library,
> typically the dmacs will support this in some form or other, so your
> point is valid :)
> > (3) keeping it separate makes its
> > further development easier.
> >
> > OTOH, I'm certainly fine with a tighter library integration with the
> > dmaengine core. I think, it still would be better to keep it in a separate
> > file and only build it if needed, right? This woult also simplify code
> > debugging and further development. I can remove the "simple" notation,
> > which does make it look like an additional abstraction layer, and replace
> > it with, say, sgsoft (scatter-gather software implementation)?
> that would be more apt :)
> > A more
> > interesting question is what to do with struct dma_simple_dev, struct
> > dma_simple_chan, struct dma_simple_desc, that embed struct dma_device,
> > struct dma_chan and struct dma_async_tx_descriptor respectively. I don't
> > think we want to merge all the additions from those wrapping structs back
> > into their dmaengine counterparts?
> Sure they should be kept separate. I like the wrapping, this keeps it
> simple.
> >
> > How would you like to do this? Don't you think, it would be good to allow
> > both: either implement a dmaengine driver directly, exactly as all drivers
> > are doing now, or use the additional helper library for suitable (simple)
> > hardware types? I see it similar to I2C, where you either implement an I2C
> > driver directly, or you use the bitbanging abstraction for simpler
> > hardware.
> I think it would be good to have both, this can be used by folks who
> don't have sg support available.
Ok, so, should I just rename the driver to sgsoft? Is this the only
change, that you'd like to see?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Shimoda, Yoshihiro @ 2012-01-31 11:03 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-kernel, linux-sh, Vinod Koul, Magnus Damm, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1201270946150.32661@axis700.grange>
Hi Guennadi-san,
2012/01/27 17:48, Guennadi Liakhovetski wrote:
> Hi Shimoda-san
>
> On Fri, 27 Jan 2012, Shimoda, Yoshihiro wrote:
[ snip ]
>>>
>>> 1. switch from using a tasklet to threaded IRQ, which allowed to
>>
>> I tested this driver on 2 environment, but it could not work correctly.
>> - renesas_usbhs driver with shdma driver on the mackerel board
>> - renesas_usbhs driver with experimental SUDMAC driver
>>
>> In this case, should we modify the renesas_usbhs driver?
>
> Yes, you do. Please, see the respective version of the shdma patch. It
> doesn't request channel IRQs any more directly, instead, it uses a
> dma-simple wrapper function. Also operations change a bit.
Thank you for your comment.
I investigaed the issue. I found out the renesas_usbhs driver may
call tx_submit() in the callback() of the dma-simple finally.
In this case, the value of power_up in the simple_tx_submit is 0,
the start_xfer() is not called. And then, even if the ld_queue is
not empty, the DMA doesn't start.
So, if I add codes like the following in the dma-simple.c,
the renesas_usbhs driver can work correctly without the driver changes.
If you think the code is good, would you merge it to your code?
======= chan_irqt() =======
simple_chan_ld_cleanup(schan, false);
+ spin_lock_irq(&schan->chan_lock);
+ /* Next desc */
+ simple_chan_xfer_ld_queue(schan);
+ spin_unlock_irq(&schan->chan_lock);
return IRQ_HANDLED;
==============
Best regards,
Yoshihiro Shimoda
> Thanks
> Guennadi
>
>> For reference, if I changed the threaded IRQ to tasklet,
>> the 2 environment worked correctly:
>> ==============
>> diff --git a/drivers/dma/dma-simple.c b/drivers/dma/dma-simple.c
>> index 49d8f7d..65a5170 100644
>> --- a/drivers/dma/dma-simple.c
>> +++ b/drivers/dma/dma-simple.c
>> @@ -715,16 +715,18 @@ static irqreturn_t chan_irq(int irq, void *dev)
>>
>> spin_lock(&schan->chan_lock);
>>
>> - ret = ops->chan_irq(schan, irq) ? IRQ_WAKE_THREAD : IRQ_NONE;
>> + ret = ops->chan_irq(schan, irq) ? IRQ_HANDLED : IRQ_NONE;
>> + if (ret == IRQ_HANDLED)
>> + tasklet_schedule(&schan->tasklet);
>>
>> spin_unlock(&schan->chan_lock);
>>
>> return ret;
>> }
>>
>> -static irqreturn_t chan_irqt(int irq, void *dev)
>> +static void chan_irqt(unsigned long dev)
>> {
>> - struct dma_simple_chan *schan = dev;
>> + struct dma_simple_chan *schan = (struct dma_simple_chan *)dev;
>> const struct dma_simple_ops *ops =
>> to_simple_dev(schan->dma_chan.device)->ops;
>> struct dma_simple_desc *sdesc;
>> @@ -744,15 +746,13 @@ static irqreturn_t chan_irqt(int irq, void *dev)
>> spin_unlock_irq(&schan->chan_lock);
>>
>> simple_chan_ld_cleanup(schan, false);
>> -
>> - return IRQ_HANDLED;
>> }
>>
>> int dma_simple_request_irq(struct dma_simple_chan *schan, int irq,
>> unsigned long flags, const char *name)
>> {
>> - int ret = request_threaded_irq(irq, chan_irq, chan_irqt,
>> - flags, name, schan);
>> + int ret = request_irq(irq, chan_irq, flags, name, schan);
>> + tasklet_init(&schan->tasklet, chan_irqt, (unsigned long)schan);
>>
>> schan->irq = ret < 0 ? ret : irq;
>>
>> diff --git a/include/linux/dma-simple.h b/include/linux/dma-simple.h
>> index 5336674..beb1489 100644
>> --- a/include/linux/dma-simple.h
>> +++ b/include/linux/dma-simple.h
>> @@ -68,6 +68,7 @@ struct dma_simple_chan {
>> int id; /* Raw id of this channel */
>> int irq; /* Channel IRQ */
>> enum dma_simple_pm_state pm_state;
>> + struct tasklet_struct tasklet;
>> };
>>
>> /**
>> ==============
>>
>> Best regards,
>> Yoshihiro Shimoda
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
--
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
EC No.
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Guennadi Liakhovetski @ 2012-02-01 0:52 UTC (permalink / raw)
To: Shimoda, Yoshihiro
Cc: linux-kernel, linux-sh, Vinod Koul, Magnus Damm, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <4F27CA7D.601@renesas.com>
Hi Shimoda-san
On Tue, 31 Jan 2012, Shimoda, Yoshihiro wrote:
> Hi Guennadi-san,
>
> 2012/01/27 17:48, Guennadi Liakhovetski wrote:
> > Hi Shimoda-san
> >
> > On Fri, 27 Jan 2012, Shimoda, Yoshihiro wrote:
> [ snip ]
> >>>
> >>> 1. switch from using a tasklet to threaded IRQ, which allowed to
> >>
> >> I tested this driver on 2 environment, but it could not work correctly.
> >> - renesas_usbhs driver with shdma driver on the mackerel board
> >> - renesas_usbhs driver with experimental SUDMAC driver
> >>
> >> In this case, should we modify the renesas_usbhs driver?
> >
> > Yes, you do. Please, see the respective version of the shdma patch. It
> > doesn't request channel IRQs any more directly, instead, it uses a
> > dma-simple wrapper function. Also operations change a bit.
>
> Thank you for your comment.
>
> I investigaed the issue. I found out the renesas_usbhs driver may
> call tx_submit() in the callback()
Well, actually, this is not something, that shdma officially supports ATM.
Originally it was prohibited by the API, but later a correction has been
added to Documentation/dmaengine.txt, explicitly allowing this. So, good,
if this works for you, but watch out for possible issues.
> of the dma-simple finally.
> In this case, the value of power_up in the simple_tx_submit is 0,
> the start_xfer() is not called. And then, even if the ld_queue is
> not empty, the DMA doesn't start.
This is correct. As soon as all the transfers, currently queued in the
shdma driver, has been processed and completed, to restart DMA you need to
call dma_async_issue_pending().
> So, if I add codes like the following in the dma-simple.c,
> the renesas_usbhs driver can work correctly without the driver changes.
> If you think the code is good, would you merge it to your code?
> ======= chan_irqt() =======
> simple_chan_ld_cleanup(schan, false);
>
> + spin_lock_irq(&schan->chan_lock);
> + /* Next desc */
> + simple_chan_xfer_ld_queue(schan);
> + spin_unlock_irq(&schan->chan_lock);
>
> return IRQ_HANDLED;
> ==============
Therefore, no, this shouldn't be needed.
Thanks
Guennadi
>
> Best regards,
> Yoshihiro Shimoda
>
> > Thanks
> > Guennadi
> >
> >> For reference, if I changed the threaded IRQ to tasklet,
> >> the 2 environment worked correctly:
> >> ==============
> >> diff --git a/drivers/dma/dma-simple.c b/drivers/dma/dma-simple.c
> >> index 49d8f7d..65a5170 100644
> >> --- a/drivers/dma/dma-simple.c
> >> +++ b/drivers/dma/dma-simple.c
> >> @@ -715,16 +715,18 @@ static irqreturn_t chan_irq(int irq, void *dev)
> >>
> >> spin_lock(&schan->chan_lock);
> >>
> >> - ret = ops->chan_irq(schan, irq) ? IRQ_WAKE_THREAD : IRQ_NONE;
> >> + ret = ops->chan_irq(schan, irq) ? IRQ_HANDLED : IRQ_NONE;
> >> + if (ret == IRQ_HANDLED)
> >> + tasklet_schedule(&schan->tasklet);
> >>
> >> spin_unlock(&schan->chan_lock);
> >>
> >> return ret;
> >> }
> >>
> >> -static irqreturn_t chan_irqt(int irq, void *dev)
> >> +static void chan_irqt(unsigned long dev)
> >> {
> >> - struct dma_simple_chan *schan = dev;
> >> + struct dma_simple_chan *schan = (struct dma_simple_chan *)dev;
> >> const struct dma_simple_ops *ops =
> >> to_simple_dev(schan->dma_chan.device)->ops;
> >> struct dma_simple_desc *sdesc;
> >> @@ -744,15 +746,13 @@ static irqreturn_t chan_irqt(int irq, void *dev)
> >> spin_unlock_irq(&schan->chan_lock);
> >>
> >> simple_chan_ld_cleanup(schan, false);
> >> -
> >> - return IRQ_HANDLED;
> >> }
> >>
> >> int dma_simple_request_irq(struct dma_simple_chan *schan, int irq,
> >> unsigned long flags, const char *name)
> >> {
> >> - int ret = request_threaded_irq(irq, chan_irq, chan_irqt,
> >> - flags, name, schan);
> >> + int ret = request_irq(irq, chan_irq, flags, name, schan);
> >> + tasklet_init(&schan->tasklet, chan_irqt, (unsigned long)schan);
> >>
> >> schan->irq = ret < 0 ? ret : irq;
> >>
> >> diff --git a/include/linux/dma-simple.h b/include/linux/dma-simple.h
> >> index 5336674..beb1489 100644
> >> --- a/include/linux/dma-simple.h
> >> +++ b/include/linux/dma-simple.h
> >> @@ -68,6 +68,7 @@ struct dma_simple_chan {
> >> int id; /* Raw id of this channel */
> >> int irq; /* Channel IRQ */
> >> enum dma_simple_pm_state pm_state;
> >> + struct tasklet_struct tasklet;
> >> };
> >>
> >> /**
> >> ==============
> >>
> >> Best regards,
> >> Yoshihiro Shimoda
> >>
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> >
>
>
> --
> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> EC No.
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Shimoda, Yoshihiro @ 2012-02-01 2:47 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-kernel, linux-sh, Vinod Koul, Magnus Damm, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1202010145510.31226@axis700.grange>
Hi Guennadi-san,
2012/02/01 9:52, Guennadi Liakhovetski wrote:
> Hi Shimoda-san
>
> On Tue, 31 Jan 2012, Shimoda, Yoshihiro wrote:
[ snip ]
>> I investigaed the issue. I found out the renesas_usbhs driver may
>> call tx_submit() in the callback()
>
> Well, actually, this is not something, that shdma officially supports ATM.
> Originally it was prohibited by the API, but later a correction has been
> added to Documentation/dmaengine.txt, explicitly allowing this. So, good,
> if this works for you, but watch out for possible issues.
>
>> of the dma-simple finally.
>> In this case, the value of power_up in the simple_tx_submit is 0,
>> the start_xfer() is not called. And then, even if the ld_queue is
>> not empty, the DMA doesn't start.
>
> This is correct. As soon as all the transfers, currently queued in the
> shdma driver, has been processed and completed, to restart DMA you need to
> call dma_async_issue_pending().
>
>> So, if I add codes like the following in the dma-simple.c,
>> the renesas_usbhs driver can work correctly without the driver changes.
>> If you think the code is good, would you merge it to your code?
>> ======= chan_irqt() =======
>> simple_chan_ld_cleanup(schan, false);
>>
>> + spin_lock_irq(&schan->chan_lock);
>> + /* Next desc */
>> + simple_chan_xfer_ld_queue(schan);
>> + spin_unlock_irq(&schan->chan_lock);
>>
>> return IRQ_HANDLED;
>> ==============
>
> Therefore, no, this shouldn't be needed.
Thank you very much for your comment.
I understood it. I will investigate the renesas_usbhs driver more.
Best regards,
Yoshihiro Shimoda
> Thanks
> Guennadi
>
>>
>> Best regards,
>> Yoshihiro Shimoda
>>
>>> Thanks
>>> Guennadi
>>>
>>>> For reference, if I changed the threaded IRQ to tasklet,
>>>> the 2 environment worked correctly:
>>>> ==============
>>>> diff --git a/drivers/dma/dma-simple.c b/drivers/dma/dma-simple.c
>>>> index 49d8f7d..65a5170 100644
>>>> --- a/drivers/dma/dma-simple.c
>>>> +++ b/drivers/dma/dma-simple.c
>>>> @@ -715,16 +715,18 @@ static irqreturn_t chan_irq(int irq, void *dev)
>>>>
>>>> spin_lock(&schan->chan_lock);
>>>>
>>>> - ret = ops->chan_irq(schan, irq) ? IRQ_WAKE_THREAD : IRQ_NONE;
>>>> + ret = ops->chan_irq(schan, irq) ? IRQ_HANDLED : IRQ_NONE;
>>>> + if (ret == IRQ_HANDLED)
>>>> + tasklet_schedule(&schan->tasklet);
>>>>
>>>> spin_unlock(&schan->chan_lock);
>>>>
>>>> return ret;
>>>> }
>>>>
>>>> -static irqreturn_t chan_irqt(int irq, void *dev)
>>>> +static void chan_irqt(unsigned long dev)
>>>> {
>>>> - struct dma_simple_chan *schan = dev;
>>>> + struct dma_simple_chan *schan = (struct dma_simple_chan *)dev;
>>>> const struct dma_simple_ops *ops =
>>>> to_simple_dev(schan->dma_chan.device)->ops;
>>>> struct dma_simple_desc *sdesc;
>>>> @@ -744,15 +746,13 @@ static irqreturn_t chan_irqt(int irq, void *dev)
>>>> spin_unlock_irq(&schan->chan_lock);
>>>>
>>>> simple_chan_ld_cleanup(schan, false);
>>>> -
>>>> - return IRQ_HANDLED;
>>>> }
>>>>
>>>> int dma_simple_request_irq(struct dma_simple_chan *schan, int irq,
>>>> unsigned long flags, const char *name)
>>>> {
>>>> - int ret = request_threaded_irq(irq, chan_irq, chan_irqt,
>>>> - flags, name, schan);
>>>> + int ret = request_irq(irq, chan_irq, flags, name, schan);
>>>> + tasklet_init(&schan->tasklet, chan_irqt, (unsigned long)schan);
>>>>
>>>> schan->irq = ret < 0 ? ret : irq;
>>>>
>>>> diff --git a/include/linux/dma-simple.h b/include/linux/dma-simple.h
>>>> index 5336674..beb1489 100644
>>>> --- a/include/linux/dma-simple.h
>>>> +++ b/include/linux/dma-simple.h
>>>> @@ -68,6 +68,7 @@ struct dma_simple_chan {
>>>> int id; /* Raw id of this channel */
>>>> int irq; /* Channel IRQ */
>>>> enum dma_simple_pm_state pm_state;
>>>> + struct tasklet_struct tasklet;
>>>> };
>>>>
>>>> /**
>>>> ==============
>>>>
>>>> Best regards,
>>>> Yoshihiro Shimoda
>>>>
>>>
>>> ---
>>> Guennadi Liakhovetski, Ph.D.
>>> Freelance Open-Source Software Developer
>>> http://www.open-technology.de/
>>>
>>
>>
>> --
>> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> EC No.
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
--
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
EC No.
^ permalink raw reply
* Re: [PATCH 1/7 v2] dmaengine: add a simple dma library
From: Vinod Koul @ 2012-02-01 5:38 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-kernel, linux-sh, Magnus Damm, Yoshihiro Shimoda, linux-mmc,
alsa-devel, linux-serial, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1201310746470.31226@axis700.grange>
On Tue, 2012-01-31 at 09:59 +0100, Guennadi Liakhovetski wrote:
> Hi Vinod
>
> Thanks for your reply.
>
> On Tue, 31 Jan 2012, Vinod Koul wrote:
>
> > On Mon, 2012-01-30 at 10:34 +0100, Guennadi Liakhovetski wrote:
> > > > I don't still comprehend the need for a library on top of dmaengine
> > > > which gain is just a library between clients and dmacs. Surely we don't
> > > > want to write another abstraction on top of one provided?
> > > >
> > > > If the question is to handle scatter-gather even if the hardware doesn't
> > > > have the capability, then why don't add that in dmaengine itself rather
> > > > than one more layer?
> > >
> > > Well, yes, adding new abstraction layers is always a decision, that has to
> > > be well justified. In this case it does at least make the life easier for
> > > two sh-mobile drivers: shdma and the new SUDMAC driver.
> > >
> > > However, I did name the library in a generic way without reference to sh,
> > > assuming, that it might with time become useful for other architectures
> > > too. The reasons why I prefered to keep it as an optional addition to
> > > dmaengine core, instead of tightly integrating it with it are, that (1) I
> > > did not want to add useless code to drivers, that do not need it,
> > So are we sure that only sh-mobile drivers need this capablity?
>
> If I was sure about that, I'd call the library shmobile-dma or something
> similar:-)
>
> > Btw does you hardware only support single transfers and no sg support,
>
> Well, the controller does have some repeat- and reload-modes, but they are
> currently not supported by the driver and from the documentation I cannot
> easily understand, how useful those modes could be to implement SG.
>
> > would this remain the same in future?
>
> Who knows?...
>
> > > (2) I am
> > > not sure if and when this library will become useful for other drivers:
> > > apart from sh I am only familiar with one more dmaengine driver:
> > > ipu/ipu_idmac.c, and that one supports scatter-gather lists in a limited
> > > way and has some further peculiarities, that would likely make it a bad
> > > match for the simple DMA library,
> > typically the dmacs will support this in some form or other, so your
> > point is valid :)
> > > (3) keeping it separate makes its
> > > further development easier.
> > >
> > > OTOH, I'm certainly fine with a tighter library integration with the
> > > dmaengine core. I think, it still would be better to keep it in a separate
> > > file and only build it if needed, right? This woult also simplify code
> > > debugging and further development. I can remove the "simple" notation,
> > > which does make it look like an additional abstraction layer, and replace
> > > it with, say, sgsoft (scatter-gather software implementation)?
> > that would be more apt :)
> > > A more
> > > interesting question is what to do with struct dma_simple_dev, struct
> > > dma_simple_chan, struct dma_simple_desc, that embed struct dma_device,
> > > struct dma_chan and struct dma_async_tx_descriptor respectively. I don't
> > > think we want to merge all the additions from those wrapping structs back
> > > into their dmaengine counterparts?
> > Sure they should be kept separate. I like the wrapping, this keeps it
> > simple.
> > >
> > > How would you like to do this? Don't you think, it would be good to allow
> > > both: either implement a dmaengine driver directly, exactly as all drivers
> > > are doing now, or use the additional helper library for suitable (simple)
> > > hardware types? I see it similar to I2C, where you either implement an I2C
> > > driver directly, or you use the bitbanging abstraction for simpler
> > > hardware.
> > I think it would be good to have both, this can be used by folks who
> > don't have sg support available.
>
> Ok, so, should I just rename the driver to sgsoft? Is this the only
> change, that you'd like to see?
That would be one :)
Also, I would review the other patch patches by today/tomorrow, you can
add any changes in next version as well
--
~Vinod
^ permalink raw reply
* [PATCH] qcserial: several fixes
From: ttuttle @ 2012-02-01 20:39 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial, linux-usb
1. Remove the unused "debug" parameter.
2. Add several new serial devices.
3. Disable autosuspend, as it has been flaky.
4. Log if we find too many altsettings.
Signed-off-by: ttuttle <ttuttle@chromium.org>
---
drivers/usb/serial/qcserial.c | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 1d5deee..be9050f 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -22,8 +22,6 @@
#define DRIVER_AUTHOR "Qualcomm Inc"
#define DRIVER_DESC "Qualcomm USB Serial driver"
-static bool debug;
-
static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x05c6, 0x9211)}, /* Acer Gobi QDL device */
{USB_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
@@ -36,6 +34,11 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x413c, 0x8171)}, /* Dell Gobi QDL device */
{USB_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
{USB_DEVICE(0x1410, 0xa008)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa010)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa011)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa012)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa013)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa014)}, /* Novatel Gobi QDL device */
{USB_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
{USB_DEVICE(0x0b05, 0x1774)}, /* Asus Gobi QDL device */
{USB_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
@@ -86,7 +89,16 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x16d8, 0x8002)}, /* CMDTech Gobi 2000 Modem device (VU922) */
{USB_DEVICE(0x05c6, 0x9204)}, /* Gobi 2000 QDL device */
{USB_DEVICE(0x05c6, 0x9205)}, /* Gobi 2000 Modem device */
+
+ {USB_DEVICE(0x05c6, 0x920c)}, /* Gobi 3000 QDL */
+ {USB_DEVICE(0x05c6, 0x920d)}, /* Gobi 3000 Composite */
+ {USB_DEVICE(0x1410, 0xa020)}, /* Novatel Gobi 3000 QDL */
+ {USB_DEVICE(0x1410, 0xa021)}, /* Novatel Gobi 3000 Composite */
+ {USB_DEVICE(0x413c, 0x8193)}, /* Dell Gobi 3000 QDL */
+ {USB_DEVICE(0x413c, 0x8194)}, /* Dell Gobi 3000 Composite */
{USB_DEVICE(0x1199, 0x9013)}, /* Sierra Wireless Gobi 3000 Modem device (MC8355) */
+ {USB_DEVICE(0x12D1, 0x14F0)}, /* Sony Gobi 3000 QDL */
+ {USB_DEVICE(0x12D1, 0x14F1)}, /* Sony Gobi 3000 Composite */
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, id_table);
@@ -123,16 +135,18 @@ static int qcprobe(struct usb_serial *serial, const struct usb_device_id *id)
spin_lock_init(&data->susp_lock);
- usb_enable_autosuspend(serial->dev);
-
switch (nintf) {
case 1:
/* QDL mode */
/* Gobi 2000 has a single altsetting, older ones have two */
if (serial->interface->num_altsetting == 2)
intf = &serial->interface->altsetting[1];
- else if (serial->interface->num_altsetting > 2)
+ else if (serial->interface->num_altsetting > 2) {
+ dev_err(&serial->dev->dev,
+ "too many altsettings: %u",
+ serial->interface->num_altsetting);
break;
+ }
if (intf->desc.bNumEndpoints == 2 &&
usb_endpoint_is_bulk_in(&intf->endpoint[0].desc) &&
@@ -280,6 +294,3 @@ module_exit(qcexit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL v2");
-
-module_param(debug, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(debug, "Debug enabled or not");
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] qcserial: several fixes
From: Greg Kroah-Hartman @ 2012-02-01 20:43 UTC (permalink / raw)
To: ttuttle; +Cc: linux-serial, linux-usb
In-Reply-To: <20120201203950.GA14586@google.com>
On Wed, Feb 01, 2012 at 03:39:50PM -0500, ttuttle wrote:
> 1. Remove the unused "debug" parameter.
> 2. Add several new serial devices.
> 3. Disable autosuspend, as it has been flaky.
> 4. Log if we find too many altsettings.
>
> Signed-off-by: ttuttle <ttuttle@chromium.org>
Can you split this up into 4 different patches, as you are doing 4
different things?
Remember, one patch per "thing you do".
Also, I need a "real" name in the signed-off-by area, odds are "ttuttle"
is not your "full" name, right?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/4] qcserial: add several new serial devices
From: Thomas Tuttle @ 2012-02-01 21:07 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Thomas Tuttle <ttuttle-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
drivers/usb/serial/qcserial.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 1d5deee..26e3e30 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -36,6 +36,11 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x413c, 0x8171)}, /* Dell Gobi QDL device */
{USB_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
{USB_DEVICE(0x1410, 0xa008)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa010)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa011)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa012)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa013)}, /* Novatel Gobi QDL device */
+ {USB_DEVICE(0x1410, 0xa014)}, /* Novatel Gobi QDL device */
{USB_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
{USB_DEVICE(0x0b05, 0x1774)}, /* Asus Gobi QDL device */
{USB_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
@@ -86,7 +91,16 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x16d8, 0x8002)}, /* CMDTech Gobi 2000 Modem device (VU922) */
{USB_DEVICE(0x05c6, 0x9204)}, /* Gobi 2000 QDL device */
{USB_DEVICE(0x05c6, 0x9205)}, /* Gobi 2000 Modem device */
+
+ {USB_DEVICE(0x05c6, 0x920c)}, /* Gobi 3000 QDL */
+ {USB_DEVICE(0x05c6, 0x920d)}, /* Gobi 3000 Composite */
+ {USB_DEVICE(0x1410, 0xa020)}, /* Novatel Gobi 3000 QDL */
+ {USB_DEVICE(0x1410, 0xa021)}, /* Novatel Gobi 3000 Composite */
+ {USB_DEVICE(0x413c, 0x8193)}, /* Dell Gobi 3000 QDL */
+ {USB_DEVICE(0x413c, 0x8194)}, /* Dell Gobi 3000 Composite */
{USB_DEVICE(0x1199, 0x9013)}, /* Sierra Wireless Gobi 3000 Modem device (MC8355) */
+ {USB_DEVICE(0x12D1, 0x14F0)}, /* Sony Gobi 3000 QDL */
+ {USB_DEVICE(0x12D1, 0x14F1)}, /* Sony Gobi 3000 Composite */
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, id_table);
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/4] qcserial: log when an interface has too many altsettings
From: Thomas Tuttle @ 2012-02-01 21:07 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Thomas Tuttle <ttuttle-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
drivers/usb/serial/qcserial.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 26e3e30..5a817d6 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -145,8 +145,12 @@ static int qcprobe(struct usb_serial *serial, const struct usb_device_id *id)
/* Gobi 2000 has a single altsetting, older ones have two */
if (serial->interface->num_altsetting == 2)
intf = &serial->interface->altsetting[1];
- else if (serial->interface->num_altsetting > 2)
+ else if (serial->interface->num_altsetting > 2) {
+ dev_err(&serial->dev->dev,
+ "too many altsettings: %u",
+ serial->interface->num_altsetting);
break;
+ }
if (intf->desc.bNumEndpoints == 2 &&
usb_endpoint_is_bulk_in(&intf->endpoint[0].desc) &&
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/4] qcserial: remove unused "debug" parameter
From: Thomas Tuttle @ 2012-02-01 21:07 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Thomas Tuttle <ttuttle-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
drivers/usb/serial/qcserial.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 5a817d6..0f549c6 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -22,8 +22,6 @@
#define DRIVER_AUTHOR "Qualcomm Inc"
#define DRIVER_DESC "Qualcomm USB Serial driver"
-static bool debug;
-
static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x05c6, 0x9211)}, /* Acer Gobi QDL device */
{USB_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
@@ -298,6 +296,3 @@ module_exit(qcexit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL v2");
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox