On 2/5/2013 12:35 PM, Jaehoon Chung wrote:
> Hi Subhash,
>
> As Mr. Seungwon mentioned, your patch didn't solve the dead-lock issue.
> I'm prefered to the seungwon's patch.
Yes, i got the problem with the patch. I guess it's better to g ahead
with Seungwon's patch.
Looks good to me. Reviewed-by: S
Hi Subhash,
As Mr. Seungwon mentioned, your patch didn't solve the dead-lock issue.
I'm prefered to the seungwon's patch.
Best Regards,
Jaehoon Chung
On 02/05/2013 02:57 PM, Seungwon Jeon wrote:
> On Monday, February 04, 2013, Subhash Jadavani wrote:
>> On 1/30/2013 12:00 PM, Seungwon Jeon wrote
On Monday, February 04, 2013, Subhash Jadavani wrote:
> On 1/30/2013 12:00 PM, Seungwon Jeon wrote:
> > Hi Konstantin.
> >
> > Could you check this patch with [2/2]?
> > [PATCH 2/2] mmc: block: don't start new request when the card is removed
> >
> > mmcqd is often sleeping with acquiring the claim
Hi Dan,
Correct. I will prevent this kind of breaking in the future.
However, after our analysis the breaking of patch 1/3 and 2/3 should not
fail old devices. And since Samuel has applied 2/3 and 3/3, it might be
better for Chris to apply patch 1/3 and let all this things appear in
kernel v3
On 02/04/2013 03:29 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the network drive
On 02/04/2013 04:11 PM, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
wrote:
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote:
Based on our experience with fitting multiple subsystems on top of this
DMA
On Monday 04 February 2013, Linus Walleij wrote:
> So I think the above concerns are moot. The callback we can
> set on cookies is entirely optional, and it's even implemented by
> each DMA engine, and some may not even support it but require
> polling, and then it won't even be implemented by the
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
wrote:
> On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
>> On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote:
>
>> > Based on our experience with fitting multiple subsystems on top of this
>> > DMA-Engine driver, I must say that the
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
> On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote:
> > Based on our experience with fitting multiple subsystems on top of this
> > DMA-Engine driver, I must say that the DMA-Engine interface has proven
> > to be a less than id
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote:
> Based on our experience with fitting multiple subsystems on top of this
> DMA-Engine driver, I must say that the DMA-Engine interface has proven
> to be a less than ideal fit for the network driver use case.
>
> The first problem is that
Implement device_slave_sg_caps().
EDMA has a finite set of PaRAM slots available for linking a
multi-segment SG transfer. In order to prevent any one channel
from consuming all PaRAM slots to fulfill a large SG transfer,
the driver reports a static per-channel max number of SG segments
it will han
Add a dmaengine API to retrieve slave SG transfer capabilities.
The API is optionally implemented by dmaengine drivers and when
unimplemented will return a NULL pointer. A client driver using
this API provides the required dma channel, address width, and
burst size of the transfer. dma_get_slave_s
Replace the hardcoded values used to set max_segs/max_seg_size with
a dma_get_slave_sg_caps() query to the dmaengine driver.
Signed-off-by: Matt Porter
---
drivers/mmc/host/davinci_mmc.c| 37 -
include/linux/platform_data/mmc-davinci.h |3 ---
2 file
Changes since v2:
- Change to a separate slave sg specific api. Drop the
generic per-channel capabilities api that is not used.
Changes since v1:
- Use the existing dma_transaction_type enums instead of
adding the mostly duplicated dmaengine_apis enums
This ser
Hello Jeon,
I'm working on this and will post results.
Thanks,
On 01/30/2013 08:30 AM, Seungwon Jeon wrote:
> Hi Konstantin.
>
> Could you check this patch with [2/2]?
> [PATCH 2/2] mmc: block: don't start new request when the card is removed
>
> mmcqd is often sleeping with acquiring the clai
On 02/04/2013 12:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines s
Hello.
On 02/04/2013 08:02 PM, Felipe Balbi wrote:
>>> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
> Granted, CPPI 4.1
On Mon, Feb 04, 2013 at 06:47:12PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
> >In my eyes, getting rid of the mess doesn't justify breaking the rules
> > that
> > Russell formulated above.
>
> MUSB is no PCI, there is no single, st
Hi,
On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:
> > On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
> >>> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
> >>> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
>
> >>>
Hello.
On 02/04/2013 07:47 PM, Felipe Balbi wrote:
> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
>>> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
>>> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
>>> Granted, CPPI 4.1 makes so
Hi,
On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
> > opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
> > Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
>
> > Granted, CPPI 4.1 makes some assumptions about the fact that it's
> > hand
Hello.
On 02/04/2013 06:41 PM, Felipe Balbi wrote:
> I guess to make the MUSB side simpler we would need musb-dma-engine glue
> to map dmaengine to the private MUSB API. Then we would have some
> starting point to also move inventra (and anybody else) to dmaengine
> API.
On Mon, Feb 04, 2013 at 05:41:53PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
> > > > > I guess to make the MUSB side simpler we would need musb-dma-engine
> > > > > glue
> > > > > to map dmaengine to the private MUSB API. Then w
Hi,
On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
> > > > I guess to make the MUSB side simpler we would need musb-dma-engine glue
> > > > to map dmaengine to the private MUSB API. Then we would have some
> > > > starting point to also move inventra (and anybody else) t
On Thursday 31 January 2013 02:52 PM, Venkatraman S wrote:
On Thu, Jan 31, 2013 at 2:22 PM, Balaji T K wrote:
Update Maintainer email for omap_hsmmc,
as Venkatraman will no longer be able to maintain omap_hsmmc driver.
Signed-off-by: Venkatraman S
Signed-off-by: Balaji T K
Balaji,
My si
On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote:
> On 02-02-2013 1:30, Russell King - ARM Linux wrote:
> >> because it doesn't make sense to support multiple DMA APIs. We can check
> >> from MUSB's registers if it was configured with Inventra DMA support and
> >> based on that we can r
Hi,
On Mon, Feb 04, 2013 at 01:28:14PM +, Manjunathappa, Prakash wrote:
> Hi Mark,
>
> On Thu, Jan 31, 2013 at 16:53:03, Mark Rutland wrote:
> > Hello,
> >
> > I have a few comments on the devicetree binding and the way it's parsed.
> >
>
> Thanks for review.
>
> > On Thu, Jan 31, 2013 at 1
Hi Mark,
On Thu, Jan 31, 2013 at 16:53:03, Mark Rutland wrote:
> Hello,
>
> I have a few comments on the devicetree binding and the way it's parsed.
>
Thanks for review.
> On Thu, Jan 31, 2013 at 10:33:06AM +, Manjunathappa, Prakash wrote:
> > Adds device tree support for davinci_mmc. Also
Hi Sekhar,
On Fri, Feb 01, 2013 at 12:27:04, Nori, Sekhar wrote:
> On 1/31/2013 1:50 PM, Manjunathappa, Prakash wrote:
> > Do not return probe failure with missing DMA resources,
> > allow driver to work in PIO mode.
> > Tested on da850-evm.
>
> It will be nice to mention what exactly was tested.
Hi,
I'm working on a SDHCI driver for linux kernel 3.4.
The IP that I have to control does not control the Driver Strength.
Driver Type B is always selected. On the other hand, I can control the
drive strength of the pads in software.
I would like to use the interface select_drive_strength
Hi Roger,
On Mon, Feb 04, 2013 at 03:45:58PM +0800, Roger Tseng wrote:
> Implement different ways of selecting driving capability(a necessary
> adjustment
> along with voltage change). It was origionally in device-independent
> mmc/host/rtsx_pci_sdmmc.c. Moving it here to support devices which ma
Hi Roger,
On Mon, Feb 04, 2013 at 03:45:59PM +0800, Roger Tseng wrote:
> Support new model RTS5227.
>
> Signed-off-by: Roger Tseng
> Reviewed-by: Wei WANG
> ---
> drivers/mfd/Makefile | 2 +-
> drivers/mfd/rts5227.c| 234
> +++
> drive
On 1/30/2013 12:00 PM, Seungwon Jeon wrote:
> Hi Konstantin.
>
> Could you check this patch with [2/2]?
> [PATCH 2/2] mmc: block: don't start new request when the card is removed
>
> mmcqd is often sleeping with acquiring the claim(mmc_claim_host) when a card
> is removed.
> As a result, mmc_resca
On Mon, Feb 04, 2013 at 03:45:57PM +0800, Roger Tseng wrote:
> Several new models of readers use different way to select driving
> capability(a necessary adjustment along with voltage change). Removing this
> from device-independent rtsx_pci_sdmmc module. It will be implemented in
> device-depend c
34 matches
Mail list logo
