Pierre,
I am preparing a patch to just diable to interrupt line to the SD controller so
global interrupts are not locked out. This
will allow mdelay to work correctly in the routines the set_ios() calls.
The pm_ calls remove the lock before being called and restore it afterwards.
Is this ju
On Sat, Feb 12, 2011 at 12:37 PM, Arnd Bergmann wrote:
> On Friday 11 February 2011 23:27:51 Andrei Warkentin wrote:
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index 7054fd5..3b32329 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -31
Hi Wolfram,
On Sat, Feb 12, 2011 at 09:43:50PM +0100, Wolfram Sang wrote:
> > If there still isn't a better alternative in mind, I'm thinking about
> > going ahead and taking this patch, and then reusing the quirk bit for
> > Chuanxiao's "mmc: set a suitable max_discard_sectors value for HC"
> > p
On Sat, Feb 12, 2011 at 08:22:12PM +, Chris Ball wrote:
> Hi Wolfram,
>
> On Mon, Feb 07, 2011 at 06:48:39PM +0100, Wolfram Sang wrote:
> > Hmm, for now I don't have a better alternative, but I somehow hink there
> > must
> > be a better solution than to add one hook per [...]
>
> If there s
Hi Wolfram,
On Mon, Feb 07, 2011 at 06:48:39PM +0100, Wolfram Sang wrote:
> Hmm, for now I don't have a better alternative, but I somehow hink there must
> be a better solution than to add one hook per [...]
If there still isn't a better alternative in mind, I'm thinking about
going ahead and tak
On Friday 11 February 2011 23:27:51 Andrei Warkentin wrote:
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 7054fd5..3b32329 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -312,6 +316,157 @@ out:
> return err ? 0 : 1;
> }
>
> +/
On Saturday 12 February 2011 18:33:10 Andrei Warkentin wrote:
> On Sat, Feb 12, 2011 at 11:05 AM, Arnd Bergmann wrote:
> > On Friday 11 February 2011 23:33:42 Andrei Warkentin wrote:
> >> On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
> >
> >> Yes, this is a Toshiba card. I've sent the patc
On Saturday 12 February 2011 11:42:51 Dong, Chuanxiao wrote:
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > On Saturday 12 February 2011 07:22:14 Chuanxiao Dong wrote:
> > > max_discard_sectors value is UINT_MAX which means kernel block layer can
> > > pass
> > > down unlimited sectors to MMC
On Sat, Feb 12, 2011 at 06:29:26PM +0100, Arnd Bergmann wrote:
> On Friday 11 February 2011 23:42:34 Chris Ball wrote:
> > >
> > > {
> > > + .vendor = PCI_VENDOR_ID_RICOH,
> > > + .device = 0xe823,
> > > + .subvendor = PCI_ANY_ID,
> >
On Sat, Feb 12, 2011 at 11:05 AM, Arnd Bergmann wrote:
> On Friday 11 February 2011 23:33:42 Andrei Warkentin wrote:
>> On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
>
>> Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
>>
>> cid - 02010053454d3332479070cc51451d
On Saturday 12 February 2011 19:37:27 Shawn Guo wrote:
> > If you use a flattened device tree, you can avoid the need for
> > platform data by adding the phandle of the dma engine device to
> > a property of the mmc driver, along with the channel number inside
> > of that device. I think that would
On Friday 11 February 2011 23:42:34 Chris Ball wrote:
> >
> > {
> > + .vendor = PCI_VENDOR_ID_RICOH,
> > + .device = 0xe823,
> > + .subvendor = PCI_ANY_ID,
> > + .subdevice = PCI_ANY_ID,
> > + .driver_data
Hi Dmitry,
On Sat, Feb 12, 2011 at 12:33:33AM +, Dmitry Shmidt wrote:
> Recently new check was added to core.c function mmc_rescan():
> if (host->bus_ops && host->bus_ops->detect && !host->bus_dead
> && mmc_card_is_removable(host)) This one
> host->bus_ops->detect(host
On Friday 11 February 2011 23:33:42 Andrei Warkentin wrote:
> On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
> Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
>
> cid - 02010053454d3332479070cc51451d00
> csd - d00f00320f5903ff92404000
> erase_size - 524
On Sat, Feb 12, 2011 at 05:28:32PM +0100, Arnd Bergmann wrote:
> On Saturday 12 February 2011 11:59:18 Russell King - ARM Linux wrote:
> > Unrelated, I have a USB based device which provides an emulated FAT
> > filesystem - all files except one on this filesystem are read-only.
> > The writable fil
On Saturday 12 February 2011 11:59:18 Russell King - ARM Linux wrote:
> On Sat, Feb 12, 2011 at 11:45:41AM +0100, Arnd Bergmann wrote:
> > * The FAT location is clearly visible in a number of tests
> > done inside of an allocation unit. It's normally slower for
> > linear access, but faster for
On Sat, Feb 12, 2011 at 11:45:41AM +0100, Arnd Bergmann wrote:
> * The FAT location is clearly visible in a number of tests
> done inside of an allocation unit. It's normally slower for
> linear access, but faster for random access. Sometimes
> reading the FAT is also slower than reading else
On Saturday 12 February 2011 00:23:37 Linus Walleij wrote:
> H'm! That's an interesting resource indeed. When you write
> "From measurements, it appears that the size in which data is
> managed is typically 64 kb on SD cards" and "the size of the
> medium is always a multiple of entire allocation g
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Saturday, February 12, 2011 4:38 PM
> To: Dong, Chuanxiao
> Cc: linux-mmc@vger.kernel.org; c...@laptop.org; linux-ker...@vger.kernel.org;
> a...@linux-foundation.org; adrian.hun...@nokia.com
> Subject: Re: [PATCH v4 1
On Sat, Feb 12, 2011 at 11:07:17AM +0100, Arnd Bergmann wrote:
> On Saturday 12 February 2011 18:23:58 Shawn Guo wrote:
> > Well, we are removing inclusion of mach/dma.h from mmc driver, but
> > adding it to every mxs based machine code. This makes mmc driver
> > clean but machine code becomes not
On Saturday 12 February 2011 18:23:58 Shawn Guo wrote:
> Well, we are removing inclusion of mach/dma.h from mmc driver, but
> adding it to every mxs based machine code. This makes mmc driver
> clean but machine code becomes not. For some dma client devices
> coming later, the platform data could
On Sat, Feb 12, 2011 at 09:59:22AM +0100, Arnd Bergmann wrote:
> On Saturday 12 February 2011 15:04:19 Shawn Guo wrote:
> > > and tmio_mmc.c more or less do what I'm suggesting you do instead.
> > >
> > > Looking at sh_mmcif:
> > >
> > > host->chan_tx = dma_request_channel(mask, sh_mmcif_fi
On Saturday 12 February 2011 15:04:19 Shawn Guo wrote:
> > and tmio_mmc.c more or less do what I'm suggesting you do instead.
> >
> > Looking at sh_mmcif:
> >
> > host->chan_tx = dma_request_channel(mask, sh_mmcif_filter,
> > &pdata->dma->chan_priv_
On Saturday 12 February 2011 07:22:14 Chuanxiao Dong wrote:
> max_discard_sectors value is UINT_MAX which means kernel block layer can pass
> down unlimited sectors to MMC driver to erase. But erasing so many sectors may
> delay some other important I/O requests. This is not preferred.
>
> So use
On Saturday 12 February 2011 07:22:20 Chuanxiao Dong wrote:
> SDHCI host controller has TRIM/ERASE capability, enable these caps for erasing
> purpose.
>
> ERASE command needs R1B response. So for such command with busy signal, before
> sending command, SDHCI host driver will simply set a maximum
25 matches
Mail list logo
