On Thu, Jan 6, 2011 at 2:14 PM, Kukjin Kim wrote:
> Jaehoon Chung wrote:
>>
>> I tried to use mobile storage with sdhci-controller, but bit controlling
> is
>> too many different
>> So need Mobile Storage controller.
>>
>> I tested only 8-bit buswidth. It's working well...i think performance
>> di
Dear Kukjin Kim
i resent mshci patch..not this version..
you want..i would remove this patch..
If i resend the other patch...maybe something should present same thing.
because based-on sdhci.c and DWC mobile storage spec..
i will resend the next week..
Thank you for your opinion and sorry Mr.K
Jaehoon Chung wrote:
>
> I tried to use mobile storage with sdhci-controller, but bit controlling
is
> too many different
> So need Mobile Storage controller.
>
> I tested only 8-bit buswidth. It's working well...i think performance
> didn't ensure yet.
> It should be add DDR feature.
>
> Signed-
Hi David,
On Tue, Dec 21, 2010 at 03:03:58PM +, Tony Olech wrote:
>>> Any interest in reviewing this USB-SD driver? I'm especially curious
>>> about whether you think there are worthwhile possibilities to share
>>> code with USHC.
>> A quick look suggests that there is unlikely to be any comm
Hi John,
On Wed, Jan 05, 2011 at 03:03:42PM -0800, John Gilmore wrote:
> I'm working on secure deletion of data on various media. I recalled
> that the MMC and SD card specs contain a low-level command for erasing
> blocks, which could be used to erase a whole card if desired. And later
> MMC sp
On Tue, Dec 28, 2010 at 11:22:34PM +0100, Arnd Hannemann wrote:
> This patch enables the interrupt generation for SDIO IRQs
> of the sdhi controllers of the SoC. To make sure interrupt
> are handled announce the MMC_CAP_SDIO_IRQ capability
> on ecovec, kfr2r09 and se7724.
>
> Tested with a b43-bas
On Tue, Dec 28, 2010 at 11:22:33PM +0100, Arnd Hannemann wrote:
> This patch enables the interrupt generation for SDIO IRQs
> of the sdhi controllers of the SoC. To make sure interrupts
> are handled announce the MMC_CAP_SDIO_IRQ capability
> on AP4EVB. Tested with a b43-based SDIO wireless card.
>
Hi Chris,
On Thu, Jan 6, 2011 at 3:57 AM, Chris Ball wrote:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
>> This is basically where the problem lies. Ian has some version of the
>> hardware that we don't, and he likewise doesn't have access to the
>> version that we do (of course
On Wed, Jan 05, 2011 at 06:57:17PM +, Chris Ball wrote:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
> > This is basically where the problem lies. Ian has some version of the
> > hardware that we don't, and he likewise doesn't have access to the
> > version that we do (of cours
I'm working on secure deletion of data on various media. I recalled
that the MMC and SD card specs contain a low-level command for erasing
blocks, which could be used to erase a whole card if desired. And later
MMC specs provide a secure block erase command that also erases ancillary
unaddressabl
On Wed, Jan 05, 2011 at 10:16:24PM +0100, Arnd Hannemann wrote:
> Am 05.01.2011 19:57, schrieb Chris Ball:
> > Arnd, can I take just patches 1/2 from your six-part series, and have
> > you send the rest through the arch/ maintainers later?
>
> Sure, should be no problem.
> Ah, just saw that you al
Hi Ian,
On Wed, Dec 29, 2010 at 12:32:13AM +0100, Guennadi Liakhovetski wrote:
> There are a number of outstanding tmio-mmc patches from Arnd Hannemann and
> myself, many of them posted weeks ago. We really would like to have them
> in 2.6.38. Would you have time to process them? Otherwise, coul
On Wed, Jan 05, 2011 at 10:24:08PM +, Chris Ball wrote:
> > There are also these two:
> >
> > [1/2] tmio_mmc: handle missing HW interrupts
> > https://patchwork.kernel.org/patch/201962/
> > [2/2] tmio_mmc: fix CMD irq handling
> > https://patchwork.kernel.org/patch/201982/
>
> I haven
Hi Arnd,
On Wed, Dec 29, 2010 at 02:21:14PM +0100, Arnd Hannemann wrote:
> With current code card insert/eject interrupts will acknowledge outstanding
> commands. Normally this seems to be no problem, however if the hardware gets
> stuck and no interrupts for CMD_TIMEOUT or CMD_RESPEND are generat
Hi Arnd,
On Wed, Jan 05, 2011 at 11:31:00PM +0100, Arnd Hannemann wrote:
> Hmm, I could not reproduce this.
> delayed_reset_work should not be in the #ifdef TMIO_MMC_DMA #endif scope.
> And it isn't according to the patch.
>
> I tried with mmc-next last commit "549bad416ef62f09711cb22e77adff029e2
Hi Chris,
Am 05.01.2011 22:22, schrieb Chris Ball:
> Hi Arnd,
>
> On Wed, Dec 29, 2010 at 02:21:13PM +0100, Arnd Hannemann wrote:
>> This patch addresses this problem by introducing timeouts for outstanding
>> interrupts. If a hardware interrupt is missing, a soft reset will be
>> performed
>> t
Hi,
Just to check we're agreed on the current status:
On Wed, Dec 29, 2010 at 02:35:51PM +0100, Arnd Hannemann wrote:
> > my patches:
> >
> > mmc: tmio_mmc: allow multi-element scatter-gather lists
> > https://patchwork.kernel.org/patch/317142/
> > should go in via linux-mmc
> >
> > mmc
Hi Guennadi,
On Wed, Jan 05, 2011 at 10:09:42PM +0100, Guennadi Liakhovetski wrote:
> > - pr_warning("tmio_mmc: Spurious SDIO IRQ, disabling!
> > 0x%04x 0x%04x 0x%04x\n",
> > - sdio_status, sdio_irq_mask, sdio_ireg);
> > + pr_warning("
Hi Linus,
On Wed, Jan 05, 2011 at 12:44:32AM +0100, Linus Walleij wrote:
> The card is not always clocked and the clock frequency zero
> is perfectly legal, thus this code in mmc_set_data_timeout()
> may cause a division by zero. It will be triggered more often
> if you're using software clock gat
Hi Arnd,
On Wed, Dec 29, 2010 at 02:21:13PM +0100, Arnd Hannemann wrote:
> This patch addresses this problem by introducing timeouts for outstanding
> interrupts. If a hardware interrupt is missing, a soft reset will be performed
> to bring the hardware back to a working state.
> Tested with the S
Hi Chris,
Am 05.01.2011 19:57, schrieb Chris Ball:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
>> Again, this isn't the first time this has happened. Any perceived
>> hostility in this matter is not directed at you directly since you did
>> come in to things rather late and were
Hi Chris
On Wed, 5 Jan 2011, Chris Ball wrote:
> Hi Arnd,
>
> On Tue, Dec 28, 2010 at 11:22:31PM +0100, Arnd Hannemann wrote:
> > This patch implements SDIO IRQ support for mfds which
> > announce the TMIO_MMC_SDIO_IRQ flag for tmio_mmc.
> > If MMC_CAP_SDIO_IRQ is also set SDIO IRQ signalling is
Hi Guennadi,
On Wed, Jan 05, 2011 at 09:56:01PM +0100, Guennadi Liakhovetski wrote:
> For example, with SDIO WLAN cards, some transfers happen with buffers at
> odd addresses, whereas the SH-Mobile DMA engine requires even addresses
> for SDHI. This patch extends the tmio driver with a bounce buff
Hi Arnd,
On Tue, Dec 28, 2010 at 11:22:32PM +0100, Arnd Hannemann wrote:
> The SDHI Controller on SH-Mobile SoCs supports SDIO IRQ signalling.
> This patch advertises this fact to the tmio_mmc driver.
>
> Signed-off-by: Arnd Hannemann
> Acked-by: Samuel Ortiz
> ---
> drivers/mfd/sh_mobile_sdhi
Hi Arnd,
On Tue, Dec 28, 2010 at 11:22:31PM +0100, Arnd Hannemann wrote:
> This patch implements SDIO IRQ support for mfds which
> announce the TMIO_MMC_SDIO_IRQ flag for tmio_mmc.
> If MMC_CAP_SDIO_IRQ is also set SDIO IRQ signalling is activated.
> Tested with a b43-based wireless SDIO card and
For example, with SDIO WLAN cards, some transfers happen with buffers at
odd addresses, whereas the SH-Mobile DMA engine requires even addresses
for SDHI. This patch extends the tmio driver with a bounce buffer, that
is used for single entry scatter-gather lists both for sending and
receiving. If w
On Tue, Nov 23, 2010 at 05:24:19PM +0100, Guennadi Liakhovetski wrote:
> The SDHI controller on SH-Mobile SoCs requires even buffer addresses, when
> used
> with DMA.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> drivers/mfd/sh_mobile_sdhi.c |1 +
> 1 files changed, 1 insertions(+), 0 de
On Sun, Dec 19, 2010 at 09:16:07PM +, Arnd Hannemann wrote:
> with "mmc: tmio: implement a bounce buffer for unaligned DMA"
> gcc generates the following warnings:
>
> drivers/mmc/host/tmio_mmc.c:654:6: warning: 'ret' may be used uninitialized
> in this function
> drivers/mmc/host/tmio_mmc.c:
Hi Guennadi, could you resend this one with some style changes:
On Tue, Nov 23, 2010 at 05:24:15PM +0100, Guennadi Liakhovetski wrote:
> For example, with SDIO WLAN cards, some transfers happen with buffers at odd
> addresses, whereas the SH-Mobile DMA engine requires even addresses for SDHI.
> Th
On Tue, Nov 23, 2010 at 05:24:11PM +0100, Guennadi Liakhovetski wrote:
> drivers/mmc/host/tmio_mmc.h is only used by drivers/mmc/host/tmio_mmc.c, this
> needlessly complicates source-code handling.
>
> Signed-off-by: Guennadi Liakhovetski
Ouch; but fixing it needlessly complicates patch handling
Hi Guennadi,
On Thu, Nov 11, 2010 at 12:19:47PM +0100, Guennadi Liakhovetski wrote:
> The easiest way to fall back to PIO, when a DMA descriptor allocation fails is
> to disable DMA on the controller but continue with the current request in PIO
> mode. This way tmio_mmc_start_dma() can become void
Hi Guennadi,
On Thu, Nov 11, 2010 at 12:15:06PM +0100, Guennadi Liakhovetski wrote:
> The driver is capable of handling multi-element sg lists in both PIO and DMA
> modes. In DMA mode this also allows to use the DMA sg capability more
> efficiently and almost doubles the throughput.
>
> Signed-of
On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
> Again, this isn't the first time this has happened. Any perceived
> hostility in this matter is not directed at you directly since you did
> come in to things rather late and were possibly unaware of the situation.
> It's more absentee m
On Wed, Jan 05, 2011 at 04:57:57PM +, Chris Ball wrote:
> Wow, how hostile -- insult first, ask questions later? I do review and
> merge MMC patches; all it takes is a ping to let me know that the tmio
> maintainer is absent and that you'd like me to start picking these up.
> I'd seen them bei
Hi,
On Wed, Jan 05, 2011 at 01:53:47PM +0900, Paul Mundt wrote:
> The MMC subsystem has been pretty much a disaster in terms of maintenance
> for as long as I can remember, so this is certainly not a new situation,
> but I had hoped that the situation had rather improved recently with at
> least s
On Jan 5, 2011, at 1:39 AM, zhangfei gao wrote:
> From 7554ead744bfdc7304a7ae9fb227212bf548161a Mon Sep 17 00:00:00 2001
> From: Zhangfei Gao
> Date: Wed, 5 Jan 2011 17:21:00 -0500
> Subject: [PATCH] mmc: sdhci stop SDCLK during asynchronous interrupt peroid
>
> V3 controller could stop S
On Wed, Jan 5, 2011 at 10:40 AM, Ohad Ben-Cohen wrote:
> On Wed, Jan 5, 2011 at 11:10 AM, Pierre Tardy wrote:
>> Well, we dont do it like this in intel_mid. Every platform quirk has
>> to come somehow from the firmware (SFI), and there is no such
>> descriptor to my knowledge. Lets see what John
On Wed, Jan 5, 2011 at 11:10 AM, Pierre Tardy wrote:
> Well, we dont do it like this in intel_mid. Every platform quirk has
> to come somehow from the firmware (SFI), and there is no such
> descriptor to my knowledge. Lets see what John is proposing...
I think that John shared it with you this mo
>From 7554ead744bfdc7304a7ae9fb227212bf548161a Mon Sep 17 00:00:00 2001
From: Zhangfei Gao
Date: Wed, 5 Jan 2011 17:21:00 -0500
Subject: [PATCH] mmc: sdhci stop SDCLK during asynchronous interrupt peroid
V3 controller could stop SDCLK during asynchronous interrupt peroid
to save power, vi
On Wed, Jan 5, 2011 at 12:34 AM, Ohad Ben-Cohen wrote:
> On Wed, Jan 5, 2011 at 1:25 AM, Pierre Tardy wrote:
>> There is no such platform data in intel_mid platforms.. Sound like
>> another platform hack will be needed for wl1271 to be integrated. :-(
>
> John (cc'ed) ported this to your platform
On Wed, Jan 05, 2011 at 10:45:49AM +0900, Magnus Damm wrote:
> On Wed, Dec 29, 2010 at 4:59 PM, Guennadi Liakhovetski
> wrote:
> > Simplify the driver by removing the possibility to build it without the DMA
> > support and remove the respective Kconfig parameter.
> >
> > Signed-off-by: Guennadi Li
41 matches
Mail list logo
