Re: [PATCH v5 3/3] memstick: Add realtek USB memstick host driver
On Tue, 1 Apr 2014 11:20:32 +0800 Roger rogera...@realtek.com wrote: On 03/25/2014 06:44 PM, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Realtek USB memstick host driver provides memstick host support based on the Realtek USB card reader MFD driver. Signed-off-by: Roger Tseng rogera...@realtek.com --- drivers/memstick/host/Kconfig | 10 + drivers/memstick/host/Makefile | 1 + drivers/memstick/host/rtsx_usb_ms.c | 839 3 files changed, 850 insertions(+) create mode 100644 drivers/memstick/host/rtsx_usb_ms.c Hi Andrew, Since I'll have to send next revision(v6, to modify patch 1/3) and you've commented v4, would you also comment or Ack the 3/3 of this one? This should save one revision for me to make any necessary change. It looks OK to my inexpert eye. It would be better if Maxim and/or Alex could review the code. If that doesn't happen then I guess the best we can do is to go ahead and merge it. Have you worked out via which tree the patches will be merged? -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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 3/3] memstick: Add realtek USB memstick host driver
On Wed, 12 Feb 2014 18:00:38 +0800 rogera...@realtek.com wrote:
From: Roger Tseng rogera...@realtek.com
Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.
...
+#include linux/module.h
+#include linux/highmem.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/workqueue.h
+#include linux/memstick.h
+#include linux/kthread.h
+#include linux/mfd/rtsx_usb.h
+#include linux/pm_runtime.h
+#include asm/unaligned.h
+
+struct rtsx_usb_ms {
+ struct platform_device *pdev;
+ struct rtsx_ucr *ucr;
+ struct memstick_host*msh;
+ struct memstick_request *req;
+
+ struct mutexhost_mutex;
Should have included mutex.h.
+ struct work_struct handle_req;
+
+ struct task_struct *detect_ms;
sched.h.
+ struct completion detect_ms_exit;
completion.h.
+ u8 ssc_depth;
+ unsigned intclock;
+ int power_mode;
+ unsigned char ifmode;
+ booleject;
+};
+
...
+
+#else
+
+#define ms_print_debug_regs(host)
static void ms_print_debug_regs(struct rtsx_usb_ms *host)
{
}
It is good to have the same signature for either case. And doing it in
C provides typechecking and can avoid variable-unused warnings.
+#endif
...
+static int ms_power_on(struct rtsx_usb_ms *host)
+{
+ struct rtsx_ucr *ucr = host-ucr;
+ int err;
+
+ dev_dbg(ms_dev(host), %s\n, __func__);
+
+ rtsx_usb_init_cmd(ucr);
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, CARD_SELECT, 0x07, MS_MOD_SEL);
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, CARD_SHARE_MODE,
+ CARD_SHARE_MASK, CARD_SHARE_MS);
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, CARD_CLK_EN,
+ MS_CLK_EN, MS_CLK_EN);
+ err = rtsx_usb_send_cmd(ucr, MODE_C, 100);
+ if (err 0)
+ return err;
+
+ if (CHECK_PKG(ucr, LQFP48))
+ err = ms_pull_ctl_enable_lqfp48(ucr);
+ else
+ err = ms_pull_ctl_enable_qfn24(ucr);
+ if (err 0)
+ return err;
+
+ err = rtsx_usb_write_register(ucr, CARD_PWR_CTL,
+ POWER_MASK, PARTIAL_POWER_ON);
+ if (err)
+ return err;
+
+ /* Wait ms power stable */
Comment is strange.
+ usleep_range(800, 1000);
+
+ rtsx_usb_init_cmd(ucr);
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, CARD_PWR_CTL,
+ POWER_MASK, POWER_ON);
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, CARD_OE,
+ MS_OUTPUT_EN, MS_OUTPUT_EN);
+
+ return rtsx_usb_send_cmd(ucr, MODE_C, 100);
+}
+
...
+static int ms_transfer_data(struct rtsx_usb_ms *host, unsigned char data_dir,
+ u8 tpc, u8 cfg, struct scatterlist *sg)
+{
+ struct rtsx_ucr *ucr = host-ucr;
+ int err;
+ unsigned int length = sg-length;
+ u16 sec_cnt = (u16)(length / 512);
+ u8 trans_mode, dma_dir, flag;
+ unsigned int pipe;
+ struct memstick_dev *card = host-msh-card;
+
+ dev_dbg(ms_dev(host), %s: tpc = 0x%02x, data_dir = %s, length = %d\n,
length = %u
+ __func__, tpc, (data_dir == READ) ? READ : WRITE,
+ length);
+
+ if (data_dir == READ) {
+ flag = MODE_CDIR;
+ dma_dir = DMA_DIR_FROM_CARD;
+ if (card-id.type != MEMSTICK_TYPE_PRO)
+ trans_mode = MS_TM_NORMAL_READ;
+ else
+ trans_mode = MS_TM_AUTO_READ;
+ pipe = usb_rcvbulkpipe(ucr-pusb_dev, EP_BULK_IN);
+ } else {
+ flag = MODE_CDOR;
+ dma_dir = DMA_DIR_TO_CARD;
+ if (card-id.type != MEMSTICK_TYPE_PRO)
+ trans_mode = MS_TM_NORMAL_WRITE;
+ else
+ trans_mode = MS_TM_AUTO_WRITE;
+ pipe = usb_sndbulkpipe(ucr-pusb_dev, EP_BULK_OUT);
+ }
+
+ rtsx_usb_init_cmd(ucr);
+
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MS_TPC, 0xFF, tpc);
+ if (card-id.type == MEMSTICK_TYPE_PRO) {
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MS_SECTOR_CNT_H,
+ 0xFF, (u8)(sec_cnt 8));
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MS_SECTOR_CNT_L,
+ 0xFF, (u8)sec_cnt);
+ }
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MS_TRANS_CFG, 0xFF, cfg);
+
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MC_DMA_TC3,
+ 0xFF, (u8)(length 24));
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MC_DMA_TC2,
+ 0xFF, (u8)(length 16));
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MC_DMA_TC1,
+ 0xFF, (u8)(length 8));
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MC_DMA_TC0, 0xFF,
+ (u8)length);
+ rtsx_usb_add_cmd(ucr, WRITE_REG_CMD, MC_DMA_CTL,
+
Re: [PATCH v4 3/3] memstick: Add realtek USB memstick host driver
On Thu, 20 Mar 2014 16:38:03 +0800 Roger rogera...@realtek.com wrote: On 02/12/2014 06:00 PM, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Realtek USB memstick host driver provides memstick host support based on the Realtek USB card reader MFD driver. Signed-off-by: Roger Tseng rogera...@realtek.com Andrew, Would you please Ack or comment this patch(3/3) to let the 3 patches be merged together? I have been making the same request at the message thread of [PATCH v4 2/3] since several weeks ago but got no response. Thus I re-post here and hope I could get something. Looks OK to me - I had a few minor quibbles. Please proceed in that way. It would be nice if Alex and/or Maxim had time to look through the code. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] avr32-linux: at32ap700x: set DMA slave properties for MCI dw_dmac
On Mon, 27 Aug 2012 04:56:55 +0800 Hein Tibosch hein_tibo...@yahoo.es wrote: The MCI makes use of the dw_dmac driver when DMA is being used. Due to recent changes the driver was broken because: - the SMS field in the CTLL register received the wrong value 0 - a patch in dw_dmac allowed for 64-bit transfers on the memory side, giving an illegal value of 3 in the SRC/DST_TR_WIDTH register. Please try to avoid vague descriptions such as recent changes and a patch. We like to see specifics: commit IDs and titles. This way we can make more informed decisions about patch scheduling. We can ensure that the authors of the earlier commits get to review these changes. Maintainers of other trees can determine whether or not their tree needs the particular fix. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 32242] New: irq 18, nobody cared, nor did irqpoll
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 30 Mar 2011 13:06:17 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=32242 Summary: irq 18, nobody cared, nor did irqpoll Product: Drivers Version: 2.5 Kernel Version: 2.6.38.2 Is this a regression? Was 2.6.37 OK? Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: drivers_ot...@kernel-bugs.osdl.org ReportedBy: ha...@afaics.de Regression: No Created an attachment (id=52622) -- (https://bugzilla.kernel.org/attachment.cgi?id=52622) kernel config file I got this at boot time of my laptop: [ 11.837498] irq 18: nobody cared (try booting with the irqpoll option) [ 11.837503] Pid: 1618, comm: echo Not tainted 2.6.38.2 #1 [ 11.837504] Call Trace: [ 11.837506] IRQ [810723af] ? __report_bad_irq.clone.2+0x30/0x7c [ 11.837515] [81072502] ? note_interrupt+0x107/0x179 [ 11.837518] [81072f8e] ? handle_fasteoi_irq+0xa6/0xd4 [ 11.837522] [810036cc] ? call_softirq+0x1c/0x28 [ 11.837525] [8100514f] ? handle_irq+0x17/0x1d [ 11.837527] [81004e80] ? do_IRQ+0x45/0xad [ 11.837532] [812a2d13] ? ret_from_intr+0x0/0xe [ 11.837533] EOI [81175b76] ? cfb_imageblit+0x19e/0x434 [ 11.837539] [812a2d0e] ? common_interrupt+0xe/0x13 [ 11.837543] [81170fa7] ? bit_putcs+0x3c0/0x455 [ 11.837546] [81170bcb] ? bit_cursor+0x439/0x455 [ 11.837549] [8116b93b] ? fbcon_putcs+0xef/0xfe [ 11.837551] [81170be7] ? bit_putcs+0x0/0x455 [ 11.837554] [8116ef5b] ? fbcon_redraw.clone.15+0xcb/0x160 [ 11.837557] [8116f60e] ? fbcon_scroll+0x61e/0xb9d [ 11.837561] [811b2436] ? scrup+0x67/0xd4 [ 11.837563] [811b25c7] ? lf+0x25/0x58 [ 11.837566] [811b58fb] ? do_con_write+0x8aa/0x1e40 [ 11.837569] [81170792] ? bit_cursor+0x0/0x455 [ 11.837572] [811b6ed5] ? con_write+0xd/0x23 [ 11.837575] [811a5593] ? do_output_char+0x87/0x199 [ 11.837578] [811a56d4] ? process_output+0x2f/0x43 [ 11.837580] [811a6063] ? n_tty_write+0x26b/0x34d [ 11.837584] [8103018a] ? default_wake_function+0x0/0x11 [ 11.837587] [811a3374] ? tty_write+0x1ad/0x231 [ 11.837589] [811a5df8] ? n_tty_write+0x0/0x34d [ 11.837593] [810b7b60] ? vfs_write+0xaf/0x129 [ 11.837596] [810b7db3] ? sys_write+0x45/0x6e [ 11.837598] [8100287b] ? system_call_fastpath+0x16/0x1b [ 11.837600] handlers: [ 11.837601] [a01f80a7] (sdhci_irq+0x0/0x4d5 [sdhci]) [ 11.837621] [a05bb871] (r852_irq+0x0/0x201 [r852]) So both sdhci_irq and r852_irq were looking at the IRQ, but neither of them were interested in it. Could be that the bug lies in neither driver, at that something went wrong with the system setup. ACPI? [ 11.837625] Disabling IRQ #18 Booting with irqpoll as suggested did not help. With this option set I got [ 31.135445] irq 18: nobody cared (try booting with the irqpoll option) [ 31.136345] Pid: 0, comm: kworker/0:0 Not tainted 2.6.38.2 #1 [ 31.136345] Call Trace: [ 31.136345] IRQ [810723af] ? __report_bad_irq.clone.2+0x30/0x7c [ 31.136345] [81072502] ? note_interrupt+0x107/0x179 [ 31.136345] [81072f8e] ? handle_fasteoi_irq+0xa6/0xd4 [ 31.136345] [8100514f] ? handle_irq+0x17/0x1d [ 31.136345] [81004e80] ? do_IRQ+0x45/0xad [ 31.136345] [812a2d13] ? ret_from_intr+0x0/0xe [ 31.136345] EOI [a0416f7c] ? acpi_idle_enter_simple+0xd2/0x104 [processor] [ 31.136345] [a0416f77] ? acpi_idle_enter_simple+0xcd/0x104 [processor] [ 31.136345] [81208efc] ? cpuidle_idle_call+0x91/0xce [ 31.136345] [81001182] ? cpu_idle+0x4a/0x64 [ 31.136345] handlers: [ 31.136345] [a01d80a7] (sdhci_irq+0x0/0x4d5 [sdhci]) [ 31.136345] [a06c1871] (r852_irq+0x0/0x201 [r852]) [ 31.136345] Disabling IRQ #18 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/mmc/host/sdhci-of-core.c on sparc64
drivers/mmc/host/sdhci-of-core.c:24:25: asm/machdep.h: No such file or directory drivers/mmc/host/sdhci-of-core.c: In function `sdhci_of_wp_inverted': drivers/mmc/host/sdhci-of-core.c:115: error: implicit declaration of function `machine_is' That code's been there for a while. Did someone change Kconfig? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/mmc/host/sdhci-of-core.c on sparc64
On Thu, 13 Jan 2011 23:38:28 + Chris Ball c...@laptop.org wrote: On Thu, Jan 13, 2011 at 03:10:33PM -0800, Andrew Morton wrote: drivers/mmc/host/sdhci-of-core.c:24:25: asm/machdep.h: No such file or directory drivers/mmc/host/sdhci-of-core.c: In function `sdhci_of_wp_inverted': drivers/mmc/host/sdhci-of-core.c:115: error: implicit declaration of function `machine_is' That code's been there for a while. Did someone change Kconfig? Can you attach a .config? asm/machdep.h is arch-specific, so I'd suggest that you're building on an unsupported arch. sparc64 allmodconfig. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mmcoops with panic/oops
On Tue, 30 Nov 2010 17:42:13 +0900
Jaehoon Chung jh80.ch...@samsung.com wrote:
This patch is mmcoops.
When Kernel panic or oops, write panic log to circular buffer in eMMC.
then after reset, we can see the log in MMC.
So we need change mmc_wait_for_req().
because if we used schedule(), we can find atomic schedule warning.
That is not our needs log. so i used delay.
i want to know how about __mmc_wait_for_req()
If any question, let me know.
...
/**
- * mmc_wait_for_req - start a request and wait for completion
+ * __mmc_wait_for_req - start a request and wait for completion
* @host: MMC host to start command
* @mrq: MMC request to start
+ * @panic: kernel panic/oops or not
*
* Start a new MMC custom command request for a host, and wait
* for the command to complete. Does not attempt to parse the
* response.
*/
-void mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq)
+void __mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq,
+ int panic)
{
- DECLARE_COMPLETION_ONSTACK(complete);
+ if (panic) {
+ DECLARE_WAITQUEUE(wait, current);
+
+ mmc_start_request(host, mrq);
+
+ spin_lock_irq(host-wq.lock);
+ init_waitqueue_head(host-wq);
+
+ add_wait_queue_exclusive(host-wq, wait);
+ set_current_state(TASK_UNINTERRUPTIBLE);
- mrq-done_data = complete;
- mrq-done = mmc_wait_done;
+ mdelay(10);
+ spin_unlock_irq(host-wq.lock);
+ } else {
+ DECLARE_COMPLETION_ONSTACK(complete);
+
+ mrq-done_data = complete;
+ mrq-done = mmc_wait_done;
+
+ mmc_start_request(host, mrq);
+
+ wait_for_completion(complete);
+ }
+}
This approach seems somewhat OK - it will only do the busy-wait in the
panic=1 case, so existing callers shouldn't be affected. (`panic'
could have had type `bool', btw).
That being said, the code is odd/wrong.
void __mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq,
int panic)
{
if (panic) {
DECLARE_WAITQUEUE(wait, current);
mmc_start_request(host, mrq);
spin_lock_irq(host-wq.lock);
init_waitqueue_head(host-wq);
add_wait_queue_exclusive(host-wq, wait);
set_current_state(TASK_UNINTERRUPTIBLE);
mdelay(10);
spin_unlock_irq(host-wq.lock);
} else {
Surely the waitqueue is unneeded and the missing remove_wait_queue() is a
bug and the set_current_state() is a bug and the spin_lock_irq()
appears to be unneeded. afaict you want this:
void __mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq,
int panic)
{
if (panic) {
mmc_start_request(host, mrq);
mdelay(10);
} else {
However it is pretty bad to just delay 10 milliseconds and then assume
that the request has completed. Would it not be better to poll for the
IRQ completion, or to poll some hardware flag?
(We can't poll for IRQ completion if the caller has disabled IRQs, but
if the caller has disabled IRQs then the use of spin_lock_irq() instead
of spin_lock_irqsave() is yet another bug!)
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] sdhci-s3c: Add support no internal clock divider in host controller
On Tue, 12 Oct 2010 03:59:46 +0100 Chris Ball c...@laptop.org wrote: Hi Kyungmin, On Tue, Oct 12, 2010 at 11:53:35AM +0900, Kyungmin Park wrote: Hi Chris, we make a conclusion use this patch. Can you merge it for 2.6.37? Acked-by: Kyungmin Park kyungmin.p...@samsung.com I don't feel that I can, because Ben Dooks is listed as the maintainer for this driver and the patch does not have his ACK. I don't know what to do about this; I've already tried asking Ben whether he intends to continue maintaining sdhci-s3c, with no reply. People get busy and take vacations and change roles, etc. Sometimes, the best you can do is to make everyone aware of what's going on and then simply proceed on your own. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci-s3c: fix incorrect spinlock usage after merge
On Tue, 21 Sep 2010 02:17:11 +0100 Chris Ball c...@laptop.org wrote: On Mon, Sep 20, 2010 at 03:03:42PM +0200, Marek Szyprowski wrote: In the commit f522886e202a34a2191dd5d471b3c4d46410a9a0 a merge conflict in the sdhci-s3c driver been fixed. However the fix used incorrect spinlock operation - it cause a race with sdhci interrupt service. The correct way to solve it is to use spin_lock_irqsave/irqrestore() calls. Thanks, applied to mmc-next with: Signed-off-by: Chris Ball c...@laptop.org Andrew, not sure how best to get this upstream -- do you want to send this up to Linus (for -rc5) via your queue in -mm? Ordinarily I'd expect you to send it to Linus. I tend to merge important-looking bugfixes in my tree in case maintainers lose them (happens regularly). I'll then start spamming the maintainer with the patch. If the maintainer remains dead then I might merge it myself, or I might tag it for -stable backporting and try again in the next kernel. If the maintainer can't be bothered setting up a pull request then he can just send an acked-by and explicitly ask me to merge it up and I'll then add it to my next approximately-weekly Linus patchbombing. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 18602] New: mmc_block / tifm_sd not completely registering when a new sd card is inserted
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 15 Sep 2010 13:48:30 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=18602 Summary: mmc_block / tifm_sd not completely registering when a new sd card is inserted Product: Drivers Version: 2.5 Kernel Version: 2.6.35.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: MMC/SD AssignedTo: drivers_mmc...@kernel-bugs.osdl.org ReportedBy: pi...@pioto.org Regression: No After I insert an SD card once after booting, mount it, unmount it, then pop out the card, if I try to insert the card again, the /dev/mmcblk* devices do not show again. I have to unload the mmc_block and tifm_sd (and mmc_core) modules, then reload them, in order for the device node to apear again. I don't think this was always the case, but I can't remember the specific version that this problem first occurred. On the first insertion cycle, dmsg looks like this: [204702.558153] tifm_core: MMC/SD card detected in socket 0:1 [204702.834915] mmc0: new SD card at address 4f9a [204702.878743] mmcblk0: mmc0:4f9a SD02G 1.83 GiB [204702.878802] mmcblk0: p1 # ... do stuff with the card [204908.381864] tifm0 : demand removing card from socket 0:1 [204908.381936] mmc0: card 4f9a removed # now, insert the card again [204913.581176] tifm_core: MMC/SD card detected in socket 0:1 # and remove it again [204926.188570] tifm0 : demand removing card from socket 0:1 lspci identifies my SD card reader as: 0f:06.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller Any advice would be appreciated. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC maintainer
On Fri, 10 Sep 2010 21:14:19 +0100 Chris Ball c...@laptop.org wrote: On Thu, Sep 09, 2010 at 11:47:50AM -0700, Andrew Morton wrote: These things can happen in parallel - get the tree set up, get it into linux-next, start putting patches in it. If I see patches turn up in linux-next which I already have, I just drop them. If I find I'm holding patches which should be in the mmc tree but which aren't, I send them to you. Thanks -- have created the tree, added its mmc-next branch to -next, and started pushing to it (location below). Here's a MAINTAINERS update: Subject: mmc: add MAINTAINERS entry Add myself as maintainer. Kewl. Please work with Stephen on getting that into linux-next. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: move regulator handling closer to core v3
On Sun, 5 Sep 2010 11:05:38 +0200
Linus Walleij linus.wall...@stericsson.com wrote:
After discovering a problem in regulator reference counting I
took Mark Brown's advice to move the reference count into the
MMC core by making the regulator status a member of
struct mmc_host.
...
-static inline void pxamci_set_power(struct pxamci_host *host, unsigned int
vdd)
+static inline void pxamci_set_power(struct pxamci_host *host,
+ unsigned char power_mode,
+ unsigned int vdd)
{
int on;
-#ifdef CONFIG_REGULATOR
- if (host-vcc)
- mmc_regulator_set_ocr(host-vcc, vdd);
-#endif
+ if (host-vcc) {
+ int ret;
+
+ if (power_mode == MMC_POWER_UP)
+ ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
+ else if (power_mode == MMC_POWER_OFF)
+ ret = mmc_regulator_set_ocr(host-mmc, host-vcc, 0);
+ }
There's no point in copying the return value into a local then ignoring
it. mmc_regulator_set_ocr() can return a negative errno so we should
test for that, clean up and propagate the error.
If we really do deliberately ignore the error then there should be a
code comment which excuses this behaviour and perhaps a warning printk.
The same comments apply to mmci_set_ios().
omap_hsmmc_1_set_power() gets it right.
Why doesn't omap_hsmmc_23_set_sleep() run .before_set_reg() and
.after_set_reg()?
...
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
On Wed, 14 Jul 2010 17:07:28 +0400 Anton Vorontsov avoront...@mvista.com wrote: Hi all, Currently the sdhci driver does everything in the atomic context. And what is worse, PIO transfers are made from the IRQ handler. This causes huge latencies (up to 120 ms). On some P2020 SOCs, DMA and card detection is broken, which means that kernel polls for the card via PIO transfers every second. Needless to say that this is quite bad. So, this patch set reworks sdhci code to avoid atomic context, almost completely. We only do two device memory operations in the atomic context, and all the rest is threaded. I noticed no throughput drop neither with PIO transfers nor with DMA (tested on MPC8569E CPU), while latencies should be greatly improved. This patchset isn't causing any problems yet, but may do so in the future and will impact the validity of any testing. It seems to be kind of stuck. Should I drop it all? -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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] mmc: Make ID freq configurable
On Fri, 3 Sep 2010 02:47:57 +0100
Chris Ball c...@laptop.org wrote:
- mmc_send_if_cond(host, host-ocr_avail);
+ printk (mmc_rescan: trying %u Hz\n, host-f_init);
Need a loglevel here, and an mmc_hostname. Something like:
pr_info(%s: %s: trying to init card at %u Hz\n,
mmc_hostname(host), __func__, host-f_init);
+ mmc_power_up(host);
+ sdio_reset(host);
+ mmc_go_idle(host);
- /*
-* First we search for SDIO...
-*/
- err = mmc_send_io_op_cond(host, 0, ocr);
- if (!err) {
- if (mmc_attach_sdio(host, ocr)) {
- mmc_claim_host(host);
- /* try SDMEM (but not MMC) even if SDIO is broken */
- if (mmc_send_app_op_cond(host, 0, ocr))
- goto out_fail;
+ mmc_send_if_cond(host, host-ocr_avail);
+
+ /*
+* First we search for SDIO...
+*/
+ err = mmc_send_io_op_cond(host, 0, ocr);
+ if (!err) {
+ if (mmc_attach_sdio(host, ocr)) {
+ mmc_claim_host(host);
+ /* try SDMEM (but not MMC) even if SDIO is
broken */
This breaks 80-chars, so:
/*
* Try SDMEM (but not MMC) even if SDIO
* is broken.
*/
yup.
--- a/drivers/mmc/core/core.c~mmc-make-id-freq-configurable-checkpatch-fixes
+++ a/drivers/mmc/core/core.c
@@ -1450,7 +1450,9 @@ void mmc_rescan(struct work_struct *work
else
host-f_init = host-f_min;
- printk (mmc_rescan: trying %u Hz\n, host-f_init);
+ pr_info(%s: %s: trying to init card at %u Hz\n,
+ mmc_hostname(host), __func__, host-f_init);
+
mmc_power_up(host);
sdio_reset(host);
mmc_go_idle(host);
@@ -1464,7 +1466,10 @@ void mmc_rescan(struct work_struct *work
if (!err) {
if (mmc_attach_sdio(host, ocr)) {
mmc_claim_host(host);
- /* try SDMEM (but not MMC) even if SDIO is
broken */
+ /*
+* Try SDMEM (but not MMC) even if SDIO is
+* broken.
+*/
if (mmc_send_app_op_cond(host, 0, ocr))
goto out_fail;
diff -puN
include/linux/mmc/host.h~mmc-make-id-freq-configurable-checkpatch-fixes
include/linux/mmc/host.h
_
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] initialise DMA engine before MMC
On Fri, 27 Aug 2010 20:49:39 +0100 Chris Ball c...@laptop.org wrote: Hi, Andrew, mind taking this one? From: Guennadi Liakhovetski g.liakhovet...@gmx.de Date: Mon, 7 Jun 2010 13:16:36 +0200 (CEST) To use DMA engine based DMA with MMC in a non-modular build, the DMA engine has to initialise before MMC. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Acked-by: Dan Williams dan.j.willi...@intel.com --- diff --git a/drivers/Makefile b/drivers/Makefile index 91874e0..b713e75 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -92,6 +92,7 @@ obj-$(CONFIG_EISA) += eisa/ obj-y+= lguest/ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_CPU_IDLE) += cpuidle/ +obj-$(CONFIG_DMA_ENGINE) += dma/ obj-$(CONFIG_MMC)+= mmc/ obj-$(CONFIG_MEMSTICK) += memstick/ obj-$(CONFIG_NEW_LEDS) += leds/ @@ -102,7 +103,6 @@ obj-$(CONFIG_CRYPTO) += crypto/ obj-$(CONFIG_SUPERH) += sh/ obj-$(CONFIG_ARCH_SHMOBILE) += sh/ obj-$(CONFIG_GENERIC_TIME) += clocksource/ -obj-$(CONFIG_DMA_ENGINE) += dma/ obj-$(CONFIG_DCA)+= dca/ obj-$(CONFIG_HID)+= hid/ obj-$(CONFIG_PPC_PS3)+= ps3/ erk, doing this via link ordering isn't nice. It would be better to express this dependency via initcall levels - core_initcall() or something. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: Prevents unexpected status clear
On Thu, 26 Aug 2010 08:26:42 +0100 Matt Fleming m...@console-pimps.org wrote: On Thu, Aug 26, 2010 at 03:58:38PM +0900, Magnus Damm wrote: Hi Matt, Just FYI, the newer version of these patches also have a whole bunch of acked-by and tested-by tags, see this email: http://lkml.org/lkml/2010/8/20/429 Thanks for your help! Argh, right. Claws-mail searching has completely failed me. I didn't even see that thread when searching to tmio_mmc. Back to mutt.. Andrew, can you drop the patch with my changelog and pick up the one in that thread seeing as it's got all the tags and a new changelog? Thanks. I actually already had it, as tmio_mmc-dont-clear-unhandled-pending-interrupts.patch, scheduled for 2.6.36 and -stable. What's the score with tmio_mmc: allow 2 byte requests in 4-bit mode? I didn't merge it because Ian said This change needs to be modified to test what hardware is present. this wont work on my hardware TTBOMK.. Then I later _did_ merge it because it got sneakily renamed to tmio_mmc: revise a limit of the data size. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: Revise a limit of the data size
On Wed, 25 Aug 2010 22:52:08 +0100
Matt Fleming m...@console-pimps.org wrote:
On Tue, 13 Jul 2010 11:32:33 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Andrew
Andrew Morton wrote:
On Wed, 07 Jul 2010 11:01:20 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Signed-off-by: Yusuke Goda yusuke.goda...@renesas.com
---
drivers/mmc/host/tmio_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index ee7d0a5..cac1c97 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -661,7 +661,7 @@ static int tmio_mmc_start_data(struct tmio_mmc_host
*host,
data-blksz, data-blocks);
/* Hardware cannot perform 1 and 2 byte requests in 4 bit mode
*/
-if (data-blksz 4 host-mmc-ios.bus_width ==
MMC_BUS_WIDTH_4) {
+if (data-blksz 2 host-mmc-ios.bus_width ==
MMC_BUS_WIDTH_4) {
pr_err(%s: %d byte block unsupported in 4 bit mode\n,
mmc_hostname(host-mmc), data-blksz);
return -EINVAL;
Again, please provide a suitable description for this change.
I think the data size is not limited by MMC_BUS_WIDTH_x.
I confirmed that data transmission of 2Byte was performed without a problem.
This patch hasn't been picked up. I'm assuming that's because Andrew is
still unhappy with the changelog.
Actually I don't know what happened with this. I merged it on July 8
and appear to have dropped it on July 27, but I can't find its
removed-from-mm email so I don't know why I dropped it. Weird.
Oh well, I merged it again. Is 2.6.37 an appropriate merge schedule?
Also, I tend not to handle tmio_mmc patches - usually Paul patches that
driver.
Andrew, how about something like,
When running in 4-bit bus width mode, it is entirely possible to
transfer data in block sizes of 2 bytes and larger. Relax the
conditional check to allow 2-byte data block transfers which were
previously disallowed.
thanks.
Yusuke, have I interpreted your changelog correctly? Also note that
your patch should remove the comment above the conditional that says,
Hardware cannot perform 1 and 2 byte requests in 4 bit mode.
this?
--- a/drivers/mmc/host/tmio_mmc.c~tmio_mmc-revise-a-limit-of-the-data-size-fix
+++ a/drivers/mmc/host/tmio_mmc.c
@@ -660,7 +660,6 @@ static int tmio_mmc_start_data(struct tm
pr_debug(setup data transfer: blocksize %08x nr_blocks %d\n,
data-blksz, data-blocks);
- /* Hardware cannot perform 1 and 2 byte requests in 4 bit mode */
if (data-blksz 2 host-mmc-ios.bus_width == MMC_BUS_WIDTH_4) {
pr_err(%s: %d byte block unsupported in 4 bit mode\n,
mmc_hostname(host-mmc), data-blksz);
_
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: Prevents unexpected status clear
On Wed, 25 Aug 2010 23:11:07 +0100
Matt Fleming m...@console-pimps.org wrote:
On Thu, 15 Jul 2010 13:25:52 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Tue, 13 Jul 2010 10:16:39 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Andrew
Thank you for your comment.
#define ack_mmc_irqs(host, i) \
do { \
- u32 mask;\
- mask = sd_ctrl_read32((host), CTL_STATUS); \
- mask = ~((i) TMIO_MASK_IRQ); \
- sd_ctrl_write32((host), CTL_STATUS, mask); \
+ sd_ctrl_write32((host), CTL_STATUS, ~(i)); \
} while (0)
Can we have a better changelog please?
What was wrong with the old code?
How does the patch fix it?
What are the user-visible runtime effects of the bug?
(It looks like that was a pretty gross bug - how did it pass testing??)
Example
- CMD53(Single block read / Received data size : 64Byte)
1) Send CMD53
2) Receive CMD53 response
3) Call tmio_mmc_cmd_irq(host, status);
-- original code
#define ack_mmc_irqs(host, i) \
do { \
u32 mask;\
mask = sd_ctrl_read32((host), CTL_STATUS); \
case 1
mask = ~((i) TMIO_MASK_IRQ); \
case 2
sd_ctrl_write32((host), CTL_STATUS, mask); \
} while (0)
-
TMIO_STAT_RXRDY status will be cleared by sd_ctrl_write32((host),
CTL_STATUS, mask);
if TMIO_STAT_RXRDY becomes effective between case 1 and case 2
.
This causes the phenomenon that a TMIO_STAT_RXRDY interrupt does not
occur.
When received data are small, it rarely occurs.
OK..
But with both this patch and tmio_mmc-revise-limit-on-data-size.patch
the changelogs fail to describe the impact of the bug upon our users.
So when I sit here trying to work out whether the patches should be
applied to 2.6.35 and whether they should be backported into -stable, I
don't have enough information.
What are your thoughts on this?
Goda, do you have any more ideas on updating the changelog for this
patch? It looks to me like this patch is a candidate for stable
(whereas the tmio_mmc-revise-limit-on-data-size.patch is not, sorry
about replying to that one first, I'm reading my mail backwards)
because, without this patch, it's possible to miss interrupts because
the ack_mmc_irqs() macro clears bit in the CTL_STATUS register that it
should not do? Is that correct?
If that is the case then would this be a more appropriate changelog,
tmio_mmc: Don't clear unhandled pending interrupts
Previously, it was possible for ack_mmc_irqs() to clear pending
interrupt bits in the CTL_STATUS register, even though the interrupt
handler had not been called. This was because of a race that existed
when doing a read-modify-write sequence on CTL_STATUS. After the
read step in this sequence, if an interrupt occurred (causing one of the
bits in CTL_STATUS to be set) the write step would inadvertently clear
it.
This patch eliminates this race by only writing to CTL_STATUS and
clearing the interrupts that were passed as an argument to
ack_mmc_irqs().
hm, I seem to have secretly dropped this patch as well.
Oh well. I restored it as
tmio_mmc-dont-clear-unhandled-pending-interrupts.patch and tagged it
for a -stable backport. Unless I hear otherwise I'll send it in to
Linus when we return from Brazil a couple of weeks from now.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: add support for the Marvell platform SDHCI controller
On Wed, 25 Aug 2010 23:39:58 +0100 Matt Fleming m...@console-pimps.org wrote: On Tue, 22 Jun 2010 17:09:02 +0300 Saeed Bishara sa...@marvell.com wrote: This patch implements the driver for the platfrom SDHCI controllers that found on some of Marvell's SoC's. Signed-off-by: Saeed Bishara sa...@marvell.com --- drivers/mmc/host/Kconfig| 12 ++ drivers/mmc/host/Makefile |1 + drivers/mmc/host/sdhci-mv.c | 243 +++ 3 files changed, 256 insertions(+), 0 deletions(-) create mode 100644 drivers/mmc/host/sdhci-mv.c Andrew, any reason this hasn't been picked up? I must have been hungry, it was near lunchtime. :) (I noticed you weren't on the CC). That too. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + sdhci-support-mmc_cap_mmc_highspeed.patch added to -mm tree
On Mon, 23 Aug 2010 21:22:58 +0100 Matt Fleming m...@console-pimps.org wrote: On Mon, Aug 23, 2010 at 01:09:21PM -0700, Andrew Morton wrote: The patch titled sdhci: support MMC_CAP_MMC_HIGHSPEED has been added to the -mm tree. Its filename is sdhci-support-mmc_cap_mmc_highspeed.patch Before you just go and hit reply, please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ -- Subject: sdhci: support MMC_CAP_MMC_HIGHSPEED From: zhangfei gao zhangfei@gmail.com With MMC_CAP_MMC_HIGHSPEED, mmc emmc could negotiate up to 50M, otherwise only 25M could be reached. Signed-off-by: Zhangfei Gao zg...@marvell.com Acked-by: Matt Fleming m...@console-pimps.org Cc: linux-mmc@vger.kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org Andrew, Kyungmin Park also ACK'd this. Cool, thanks. I'd scheduled these patches for 2.6.37 but if you guys have reasons why you think they should go in earlier, please let me know. These: sdhci-support-mmc_cap_mmc_highspeed.patch sdhci-support-10-bit-divided-clock-mode-for-spec-30.patch sdhci-support-10-bit-divided-clock-mode-for-spec-30-checkpatch-fixes.patch sdhci-base-clock-freqency-change-in-spec-30.patch -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: MMC 4.4 DDR support
On Mon, 23 Aug 2010 21:48:29 +0100 Matt Fleming m...@console-pimps.org wrote: On Sat, Aug 21, 2010 at 06:37:45PM -0400, Chris Ball wrote: Hi, Hm is there some problem with this patch or has the processing of it simply stalled? When I read the thread I cannot see Hanumaths answers on the list but it looks mainly like the patch is OK and there is some chit-chat. Can it be picked up? Everyone is going to need DDR MMC for their eMMCs soon-ish. I'd like to dedicate more time to mmc/. Do you think it'd be useful for me to catch all the patches sent to linux-mmc@ into a public Git tree, and periodically report on what went upstream via akpm and what's still waiting? It's possible Andrew has a reason that hasn't been picked up yet. Kyungmin Park's questions didn't seem adequately answered and the discussion kind of died. I updated the patch and merged it, but I'd like the outstanding question(s) resolved. ie: why do we add MMC_DDR_MODE, set it in brq.data.flags and then never use it? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC workflow (was Re: [PATCH] mmc: MMC 4.4 DDR support)
On Mon, 23 Aug 2010 17:45:28 -0400 Chris Ball c...@laptop.org wrote: Hi, It's possible Andrew has a reason that hasn't been picked up yet. Maybe what we really need is to get patchwork setup for the linux-mmc list? Other subsystem maintainers swear by it. That way, it'd be much harder for patches to go unnoticed. Sounds good -- if no-one objects, I'll send e-mail to ftpad...@k.o tomorrow asking for linux-mmc@ to be added to patchwork.k.o. Andrew, how do you feel about MMC at the moment? It seems like we could mostly use more people reviewing patches, but do you think it'd also help to have submitted patches go into a -next tree for testing? Would you like to have someone else track down which patches got held up along the way and should be revisited, or is that something you're already doing? I'm basically acting as a stopgap patch monkey until a real maintainer comes along. I'll happily read the patches myself but do very much like to see that someone with mmc-specific experience has taken a look at them as well. So for me, review really really helps. The only other issue I have is that I don't read the list often enough, so please do add me to cc on replies if I was missed out on. I actually maintain well over 100 subsystems in this manner[*]. Really I should be in MAINTAINERS for a lot of these so I get cc'ed more reliably on those oddball once-off fixes. But usually they're cc'ed to lkml so I do see them. [*]: grep '^# ' series is below. I have headings for other maintainers trees and headings for trees I maintain and headings for random junk which probably shouldn't be there any more. That series file has been checked in 19194 times since Dec 2002. I should get out more. # 2.6.36 # me: # 2.6.33, early # acpi # platform drivers # x86 # alsa # kgdb # kmemcheck # agp # arm # audit # avr32 # btrfs # ceph # cifs # cpufreq # dm # dmar (dwmw2) # dma (Dan) # dma-debug (Joerg Roedel joerg.roe...@amd.com) # jfs # pcmcia # powerpc # driver core # dnotify # drm # dvb # ecryptfs # fscache # fsnotify # hpet # i2c # iommu # irqs # gfs # hid # hwpoison # time # ntp # ia64 # ieee1394 # infiniband # input # kbuild # kvm # kvm/ia64 # lblnet # leds # libata # pata # ide # m32r # mfd # microblaze # async-tx # mips # mqueue # mtd # nfsd # ntfs # score # spi # squashfs # ubi # ubifs # udf # uwb # connector (davem) # atm # wan # irda # i4l # net # netdev # netfilter # backlight # battery # blackfin # bluetooth # debugobjects # ext4 # nfs # ocfs2 # parisc # security # serial # udf # pci # md # perf # regulator # s390 # sched # tejun stuff # genirq # lockdep # fastboot # rcu # ftrace # sh # scsi # block # sparc # staging # uio # usb # v9fs # vfs # watchdog # wireless # xfs # crypto # xtensa # rusty # slab # tty # mm # mmend # security # frv # pagemap # gigaset # nommu # sh # h8/300 # alpha # CPU hotplug # power management # m32r # m68k # mn10300 # cpuidle # cris # floppy # uml # v850 # Misc # miscend # drivers/misc # *bmp085*: fold # core kernel # miscdev # printk # get_maintainer # MAINTAINERS # lib # bkl removal # sgi-xpc # compat # firmware # mmc # sdhci-*: perf regression (Albert Herranz albert_herr...@yahoo.es) # checkpatch # crc # poll select # epoll # hwmon # smm665: fold # oss # binfmt # warn # list # topology: # swiotlb # kallsyms # ramfs # rwsem # initramfs # ncpfs # dmi # oprofile # vt # kprobes # i2o # xen # autofs # smbfs # rtc # gpio # fbdev # auxdisplay # devmem # pnp # pnpbios # pipe # telephony # minix # ext2 # ext3 # befs # isofs # codafs # nilfs # hfs # hfsplus # ufs # reiserfs # hpfs # hppfs # fat # quota # documentation # cgroups # devcgroup # memcgroup # devscgroup # cpusets # ptrace # utrace # signals # pgrp # kmod # coredump # exit # proc # fork # exec # wait # workqueues # kthread # cpu hotplug # kdump # idr # ipc # ipmi # pty # elf # flat # char # hw_random # drivers/misc # partitions # rapidio # rbu # keys # sysctl # pid management # pidns # userns # edd # nbd # ioctl # atmel # aoe # markers # namespaces # accounting # taskstats # random # fuse # futex # edac # gcov # loop # dma-mapping # propagate these: # adfs # afs # affs # bfs # panic # parport # pps # memstick # w1 # c2 # ramdisk # kexec # mmtimer # ramzswap # sysvfs # cachefiles fs-cache # markup_oops # relayfs: # aio # dio # omfs # uv # gru # kfifo # radix-tree # resource # ssb # genclk # cpualloc # devpts # byteorder # unaligned # cramfs # ramoops # ramzswap # romfs # freeze feature # async # vlynq # qnx4 # static # decompress # ibft # inflate deflate # slow-work # lkdtm # lzo # end # debug stuff -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: make dev_to_mmc_card() macro public
On Fri, 20 Aug 2010 10:17:20 +0300 Andy Shevchenko andy.shevche...@gmail.com wrote: On Fri, Aug 20, 2010 at 12:49 AM, Andrew Morton a...@linux-foundation.org wrote: nit: generally, subsystem-specific identifiers should use their subsystem's identifier as a prefix. __So a better name for dev_to_mmc_card() would be mmc_dev_to_card(). Sounds reasonable. Would you like to get new version of patch or fix against patch? Either is OK for me. I'll turn a replacement patch into a delta so I can see what changed, but that takes just a few seconds. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 13/20] mmc: avoid getting CID on SDIO-only cards
On Thu, 19 Aug 2010 14:13:36 -0700 a...@linux-foundation.org wrote: From: David Vrabel david.vra...@csr.com The introduction of support for SD combo cards breaks the initialization of all CSR SDIO chips. The GO_IDLE (CMD0) in mmc_sd_get_cid() causes CSR chips to be reset (this is non-standard behavior). When initializing an SDIO card check for a combo card by using the memory present bit in the R4 response to IO_SEND_OP_COND (CMD5). This avoids the call to mmc_sd_get_cid() on an SDIO-only card. argh, crap, sorry, please drop this one - Michal found a bug in it. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'error: 'SDHCI_QUIRK_NO_HISPD_BIT' undeclared' and 'undefined reference to `sdhci_card_detect''
On Fri, 13 Aug 2010 10:13:04 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On Friday, August 13, 2010 9:32 AM Kukjin Kim wrote: This is just information about Samsung sdmmc stuff building error now. I found Marek's 'sdhci-s3c: enable SDHCI_QUIRK_NO_HISPD_BIT quirk' in the Linus' tree. (commit ID: a1d5646005af1247d6ae78434bb4db15b07a07b2) But not defined the quirk yet...so following build error happened with s3c6400_defconfig in Linus' latest. drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_probe': drivers/mmc/host/sdhci-s3c.c:400: error: 'SDHCI_QUIRK_NO_HISPD_BIT' undeclared (first use in this function) drivers/mmc/host/sdhci-s3c.c:400: error: (Each undeclared identifier is reported only once drivers/mmc/host/sdhci-s3c.c:400: error: for each function it appears in.) make[4]: *** [drivers/mmc/host/sdhci-s3c.o] Error 1 make[3]: *** [drivers/mmc/host] Error 2 make[2]: *** [drivers/mmc] Error 2 make[1]: *** [drivers] Error 2 Kyungmin Park's below patch can solve this and it is in mmotm now. (commit ID: 2935b9e7fcc4bea3751b8d039b383b2036a7d36d) But I think, to update quirk definition should being in Marek's patch for avoiding build error. Of course, I'm not sure whether the commit order changed. Anyway, in this case, will be solved after merging mm tree. And second case is same. Marek's 'sdhci-s3c: add support for new card detection methods' cause following build error. (commit ID:17866e14f3a4f219e94f1374ece7226479418ff8) drivers/built-in.o: In function `sdhci_s3c_notify_change': /home/kgene/linux/linux-2.6-mainline-dev/drivers/mmc/host/sdhci-s3c.c:255: undefined reference to `sdhci_card_detect' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 And Andrew's patch(b567e5dd5a34c184e5642100e752cb87e064bb97) can solve this. (of course this needs another patches...) Anyway... Marek, in future please make sure your patch has no building problem before submitting. (or it can help to add some kind of dependency note in your patch) My patches submited to Andrew Morton had the description and a note that they have been prepared especially for his tree, taking into account all patches that are already there (mainly a tasklets to threaded irq conversion). For me it was quite obvious that they will be merged after all other sdhci changes from that tree. I have no idea why the order of the patches has been reversed and my sdhci patches has been submitted to Linus before the other sdhci changes. We're talking about these: s5pc110-sdhci-s3c-can-override-host-capabilities.patch s5pc110-sdhci-s3c-support-on-s5pc110.patch sdhci-add-no-hi-speed-bit-quirk-support.patch I have a note that these await an ack from Ben Dooks so I held them back for a closer look after -rc1. I was unaware of this dependency. Ben, are you OK with those patches? http://userweb.kernel.org/~akpm/mmotm/broken-out/s5pc110-sdhci-s3c-can-override-host-capabilities.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/s5pc110-sdhci-s3c-support-on-s5pc110.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/sdhci-add-no-hi-speed-bit-quirk-support.patch Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC breakage
On Tue, 17 Aug 2010 16:21:32 +0100 Chris Ball c...@laptop.org wrote: Hi Russell, On Tue, Aug 17, 2010 at 02:54:56PM +0100, Russell King wrote: I get the following build error: drivers/built-in.o: In function `mmc_alloc_host': mmci.c:(.text+0x80c44): undefined reference to `mmc_pm_notify' Seems to be down to 4c2ef25fe. The commit claims to fix the CONFIG_PM=n build, but it seems not to as mmc_pm_notify() is within an #ifdef CONFIG_PM block but the initialization isn't. Patches have been sent to akpm to fix this already; see http://lkml.org/lkml/2010/8/12/207 http://article.gmane.org/gmane.linux.kernel/1022716 yup. I'm lying on a beach at present. I expect I'll get onto these later in the week. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + sdhci-add-no-hi-speed-bit-quirk-support.patch added to -mm tree
On Fri, 11 Jun 2010 12:25:32 +0900 Kyungmin Park kmp...@infradead.org wrote: On Fri, Jun 11, 2010 at 9:42 AM, Ben Dooks ben-li...@fluff.org wrote: On Thu, Jun 10, 2010 at 01:43:19PM -0700, a...@linux-foundation.org wrote: The patch titled __ __ __SDHCI: add no hi-speed bit quirk support has been added to the -mm tree. __Its filename is __ __ __sdhci-add-no-hi-speed-bit-quirk-support.patch Before you just go and hit reply, please: __ __a) Consider who else should be cc'ed __ __b) Prefer to cc a suitable mailing list as well __ __c) Ideally: find the original patch on the mailing list and do a __ __ __ reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ -- Subject: SDHCI: add no hi-speed bit quirk support From: Kyungmin Park kmp...@infradead.org Some SDHCI controllers like s5pc110 don't have an HISPD bit in the HOSTCTL register. It would be nice for someone at Samsung to (a) explain the differences from the base SDHCI spec for all their hardware (the databooks are often vague in this area) and (b) for the information for the extra registers this IP block has to be explained in more detail (and the platform code checked for this too). I hope also. Going back over this dicussion, I get the impression that nothing really got resolved or finished. So it is far from clear that I should send these: s5pc110-sdhci-s3c-can-override-host-capabilities.patch s5pc110-sdhci-s3c-support-on-s5pc110.patch sdhci-add-no-hi-speed-bit-quirk-support.patch upstream. Could we please revisit all of this ASAP? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC: [PATCH 0/2 v2] Two fixes for mmc system
On Fri, 06 Aug 2010 01:39:39 +0300 Maxim Levitsky maximlevit...@gmail.com wrote: On Thu, 2010-08-05 at 15:22 -0700, Andrew Morton wrote: On Thu, 05 Aug 2010 16:36:03 +0300 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-07-31 at 15:37 +0300, Maxim Levitsky wrote: Hi, This is resend of these patches. Tell me if I don't need to resent the first patch, it doesn't much matter to me. The second patch is slightly updated to plug last oportunety for a race. Also fixed accident move of EXPORT_SYMBOL. Any update? Comments? Will I see that upstream? I merged the update to [patch 2/2] two days ago - you should have received the commit email? I have seen message about merge to -mm, but I am asking about mainline. I merge in the second week of the -rc1 merge window. I'm not presently aware of any reason why these patches shouldn't be included. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -mm] mmc: add ricoh e822 pci id
On Wed, 4 Aug 2010 18:20:57 +0200 Stanislaw Gruszka sgrus...@redhat.com wrote: From: cybercas...@gmail.com Does this person have a name? We've had fusses in the past over anonymous contributors, although nobody's going to be making a fuss over a patch of this nature. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: add SDHCI driver for STM platforms.
On Mon, 2 Aug 2010 15:36:31 +0100 Matt Fleming m...@console-pimps.org wrote: What is devm_stm_pad_claim()? I can't find this function in linus' tree, or in -next, or in Andrew's -mm series. Where is this function from? This comes from our STMicroelectronics platform pad management infrastructure; code available from: http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=summary It's used to claim/manage various resources i.e. PIO and clock lines. That's interesting. So, this driver won't build with linus' tree? I didn't think that the kernel catered for external interfaces like this - it causes all sorts of issues, not least of which is the fact that the driver can't be built or tested with the mainline kernel. Andrew, what do you make of this? It definitely needs to be compileable. Otherwise it's dead code to everyone else and nobody can maintain it as they make tree-wide or subsystem-wide changes. Also I do think the code in mainline should be able to be excecutable (and testable!) without external code dependencies. This gets into the realm of licensing concerns: is the out-of-tree code GPL? If not then people will make a big fuss. If it _is_ GPL then get it merged up! -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
On Tue, 3 Aug 2010 11:11:10 +0800
Roy Zang tie-fei.z...@freescale.com wrote:
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -240,6 +240,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN(125)
/* Controller cannot support End Attribute in NOP ADMA descriptor */
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC(126)
+/* Controller uses Auto CMD12 command to stop the transfer */
+#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (127)
This becomes 129 in my tree.
We're about to run out. What happens then?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: add SDHCI driver for STM platforms.
On Wed, 4 Aug 2010 07:35:20 +0200 Peppe CAVALLARO peppe.cavall...@st.com wrote: Hi Andrew, -Original Message- From: Andrew Morton [mailto:a...@linux-foundation.org] Sent: Wednesday, August 04, 2010 12:21 AM To: Matt Fleming Cc: Peppe CAVALLARO; linux-mmc@vger.kernel.org Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms. On Mon, 2 Aug 2010 15:36:31 +0100 Matt Fleming m...@console-pimps.org wrote: What is devm_stm_pad_claim()? I can't find this function in linus' tree, or in -next, or in Andrew's -mm series. Where is this function from? This comes from our STMicroelectronics platform pad management infrastructure; code available from: http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=summary It's used to claim/manage various resources i.e. PIO and clock lines. That's interesting. So, this driver won't build with linus' tree? I didn't think that the kernel catered for external interfaces like this - it causes all sorts of issues, not least of which is the fact that the driver can't be built or tested with the mainline kernel. Andrew, what do you make of this? It definitely needs to be compileable. Otherwise it's dead code to everyone else and nobody can maintain it as they make tree-wide or subsystem-wide changes. Also I do think the code in mainline should be able to be excecutable (and testable!) without external code dependencies. This gets into the realm of licensing concerns: is the out-of-tree code GPL? If not then people will make a big fuss. If it _is_ GPL then get it merged up! It is under GPL license and available from git.stlinux.com at this time. Please also consider that I'm going to maintain and update the sdhci-stm driver, currently on high priority in our side. So why not merge the sdhci-stm driver into mainline at the same time as mmc: add SDHCI driver for STM platforms? Then all of this won't be an issue at all. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc_test: Add performance tests
On Fri, 23 Jul 2010 12:25:47 +0300
Adrian Hunter adrian.hun...@nokia.com wrote:
+/*
+ * Allocate a lot of memory, preferrably max_sz but at least min_sz. In case
+ * there isn't much memory do not exceed 1/16th total RAM.
+ */
+static struct mmc_test_mem *mmc_test_alloc_mem(unsigned int min_sz,
+unsigned int max_sz)
+{
+ unsigned int max_page_cnt = DIV_ROUND_UP(max_sz, PAGE_SIZE);
+ unsigned int min_page_cnt = DIV_ROUND_UP(min_sz, PAGE_SIZE);
+ unsigned int page_cnt = 0;
+ struct mmc_test_mem *mem;
+ struct sysinfo si;
+
+ si_meminfo(si);
+ if (max_page_cnt si.totalram 4)
+ max_page_cnt = si.totalram 4;
+ if (max_page_cnt min_page_cnt)
+ max_page_cnt = min_page_cnt;
+
+ mem = kzalloc(sizeof(struct mmc_test_mem), GFP_KERNEL);
...
+ gfp_t flags = GFP_KERNEL | GFP_DMA | __GFP_NOWARN |
+ __GFP_NORETRY;
+
+ order = get_order(page_cnt PAGE_SHIFT);
+ while (1) {
+ page = alloc_pages(flags, order);
...
struct sysinfo.totalram returns the total number of pages including
highmem. But a GFP_KERNEL allocation can only return lowmem pages.
The difference between the two can be 20x (on a 16G i386 box).
nr_free_buffer_pages() would be a more accurate thing to use.
Also, I worry about overflows here. For example, `page_cnt
PAGE_SHIFT' could overflow the unsigned int? Please check all of that.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
On Wed, 14 Jul 2010 17:07:28 +0400 Anton Vorontsov avoront...@mvista.com wrote: Hi all, Currently the sdhci driver does everything in the atomic context. And what is worse, PIO transfers are made from the IRQ handler. This causes huge latencies (up to 120 ms). On some P2020 SOCs, DMA and card detection is broken, which means that kernel polls for the card via PIO transfers every second. Needless to say that this is quite bad. So, this patch set reworks sdhci code to avoid atomic context, almost completely. We only do two device memory operations in the atomic context, and all the rest is threaded. I noticed no throughput drop neither with PIO transfers nor with DMA (tested on MPC8569E CPU), while latencies should be greatly improved. The patchset looks good to me, but it'd be nice to hear from the other people who work on this code, please? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: Prevents unexpected status clear
On Tue, 13 Jul 2010 10:16:39 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Andrew
Thank you for your comment.
#define ack_mmc_irqs(host, i) \
do { \
- u32 mask;\
- mask = sd_ctrl_read32((host), CTL_STATUS); \
- mask = ~((i) TMIO_MASK_IRQ); \
- sd_ctrl_write32((host), CTL_STATUS, mask); \
+ sd_ctrl_write32((host), CTL_STATUS, ~(i)); \
} while (0)
Can we have a better changelog please?
What was wrong with the old code?
How does the patch fix it?
What are the user-visible runtime effects of the bug?
(It looks like that was a pretty gross bug - how did it pass testing??)
Example
- CMD53(Single block read / Received data size : 64Byte)
1) Send CMD53
2) Receive CMD53 response
3) Call tmio_mmc_cmd_irq(host, status);
-- original code
#define ack_mmc_irqs(host, i) \
do { \
u32 mask;\
mask = sd_ctrl_read32((host), CTL_STATUS); \
case 1
mask = ~((i) TMIO_MASK_IRQ); \
case 2
sd_ctrl_write32((host), CTL_STATUS, mask); \
} while (0)
-
TMIO_STAT_RXRDY status will be cleared by sd_ctrl_write32((host),
CTL_STATUS, mask);
if TMIO_STAT_RXRDY becomes effective between case 1 and case 2 .
This causes the phenomenon that a TMIO_STAT_RXRDY interrupt does not occur.
When received data are small, it rarely occurs.
OK..
But with both this patch and tmio_mmc-revise-limit-on-data-size.patch
the changelogs fail to describe the impact of the bug upon our users.
So when I sit here trying to work out whether the patches should be
applied to 2.6.35 and whether they should be backported into -stable, I
don't have enough information.
What are your thoughts on this?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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] Samsung: sdhci-s3c: add support for new card detection methods
On Thu, 15 Jul 2010 10:15:21 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: On some Samsung SoCs not all SDHCI controllers have card detect (CD) line. For some embedded designs it is not even needed, because ususally the device (like SDIO flash memory or wifi controller) is permanently wired to the controller. There are also systems which have a card detect line connected to some of the external interrupt lines or the presence of the card depends on some other actions (like enabling a power regulator). This patch adds support for all these cases. The following card detection methods are possible: 1. internal sdhci host card detect line 2. external event 3. external gpio interrupt 4. no card detect line, controller will poll for the card 5. no card detect line, card is permanently wired to the controller (once detected host won't poll it any more) By default, all existing code would use method #1, what is compatible with the previous version of the driver. In case of external event, two callbacks must be provided in platdata: ext_cd_init and ext_cd_cleanup. Both of them get a callback to a function that notifies the s3c-sdhci host contoller as their argument. That callback function should be called from the even dispatcher to let host notice the card insertion/removal. In case of external gpio interrupt, a gpio pin number must be provided in platdata (ext_cd_gpio parameter), as well as the information about the polarity of that gpio pin (ext_cd_gpio_invert). By default (ext_cd_gpio_invert == 0) gpio value 0 means 'card has been removed', but this can be changed to 'card has been removed' when ext_cd_gpio_invert == 1. This patch adds all required changes to platform support code. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- This a resend of the previous patch. Relevant patches for sdhci-s3c driver has been posted in a separate patch series for easier merging, please refer to the [PATCH] SDHCI-S3C fixes and enhancements (driver specific code) thread. They have been already taken by Andrew Morton into his patch tracking tree. I hope these changes to platform specific code gets merged soon, so the changes to the driver can be merged as well. The patch has been prepared for the following git tree: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next Changes since V2: - added support for HSMMC3 device Changes since V1: - added support for gpio external interrupt card based detect method directly to sdhci-s3c driver - removed s3c64xx compilation fix patch from the series Best regards -- Marek Szyprowski Samsung Poland RD Center --- arch/arm/mach-s3c64xx/setup-sdhci-gpio.c | 14 +--- arch/arm/mach-s5pc100/setup-sdhci-gpio.c | 21 ++- arch/arm/mach-s5pv210/setup-sdhci-gpio.c | 22 +++- arch/arm/plat-samsung/dev-hsmmc.c |5 arch/arm/plat-samsung/dev-hsmmc1.c |5 arch/arm/plat-samsung/dev-hsmmc2.c |5 arch/arm/plat-samsung/dev-hsmmc3.c |5 arch/arm/plat-samsung/include/plat/sdhci.h | 29 8 files changed, 90 insertions(+), 16 deletions(-) This is quite confusing. You've already sent a patch called sdhci-s3c: add support for new card detection methods. It had the same changelog as this patch and the same title, but the two patches are utterly different! I suggest that you resend this patch under an appropriate title and with a more specific changelog, please. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 16390] New: Memory card reader does not function [Dell Latitude E6510, Ricoh device]
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 14 Jul 2010 19:13:33 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=16390 Summary: Memory card reader does not function [Dell Latitude E6510, Ricoh device] Product: Drivers Version: 2.5 Kernel Version: 2.6.35 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: MMC/SD AssignedTo: drivers_mmc...@kernel-bugs.osdl.org ReportedBy: oyvi...@ifi.uio.no Regression: No Memory card reader reports the following during boot: [3.018008] mmc0: Unknown controller version (2). You may experience problems. When inserting a Mini-SD card inside an SD-adapter, it is /not/ mounted, and the following appears in the kernel log: 724.044751] mmc0: ADMA error [ 724.046769] mmc0: Got data interrupt 0x0200 even though no data operation was in progress. [ 724.046774] sdhci: == REGISTER DUMP == [ 724.046782] sdhci: Sys addr: 0x | Version: 0x0402 [ 724.046789] sdhci: Blk size: 0x7008 | Blk cnt: 0x0001 [ 724.046796] sdhci: Argument: 0x | Trn mode: 0x0013 [ 724.046803] sdhci: Present: 0x01ff | Host ctl: 0x0011 [ 724.046810] sdhci: Power:0x000f | Blk gap: 0x [ 724.046817] sdhci: Wake-up: 0x | Clock:0x4007 [ 724.046824] sdhci: Timeout: 0x000a | Int stat: 0x [ 724.046831] sdhci: Int enab: 0x02ff00cb | Sig enab: 0x02ff00cb [ 724.046838] sdhci: AC12 err: 0x | Slot int: 0x [ 724.046845] sdhci: Caps: 0x21e832b2 | Max curr: 0x0040 [ 724.046852] sdhci: ADMA Err: 0x0001 | ADMA Ptr: 0x0224a050 [ 724.046854] sdhci: === [ 724.047879] mmc0: error -5 whilst initialising SD card PCI device info: 04:00.1 SD Host controller [0805]: Ricoh Co Ltd Device [1180:e822] (rev 03) (prog-if 01) Subsystem: Dell Device [1028:040b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 19 Region 0: Memory at d593 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME+ Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 4us, L1 64us ClockPM+ Suprise- LLActRep- BwNot- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: sdhci-pci Kernel modules: sdhci-pci Hardware: Dell Latitude E6510 laptop. Didn't work in default Ubuntu 10.04 2.6.32-based kernel, and still doesn't work in 2.6.35-rc it seems. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sdhci-s3c: add missing remove function
On Mon, 12 Jul 2010 13:04:09 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
static int __devexit sdhci_s3c_remove(struct platform_device *pdev)
{
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ struct sdhci_s3c *sc = sdhci_priv(host);
+ int ptr;
+
+ sdhci_remove_host(host, 1);
+
+ for (ptr = 0; ptr 3; ptr++) {
+ clk_disable(sc-clk_bus[ptr]);
+ clk_put(sc-clk_bus[ptr]);
+ }
+ clk_disable(sc-clk_io);
+ clk_put(sc-clk_io);
+
+ iounmap(host-ioaddr);
+ release_resource(sc-ioarea);
+ kfree(sc-ioarea);
+
+ sdhci_free_host(host);
+ platform_set_drvdata(pdev, NULL);
+
return 0;
}
This looks like it fixes a pretty serious omission. What happens if
the user rmmods this driver on a 2.6.34 kernel?
System will crash sooner or later once the memory with the code of the
s3c-sdhci.ko module is reused for something else. I really have no idea
how the lack of remove function went unnoticed into the mainline code.
Because I have a suspicion that this fix should be backported into
2.6.34.x?
Right, this is really a good idea. This patch applies cleanly onto
v2.6.34 too.
OK, thanks, I added the Cc: sta...@kernel.org to the changelog and
moved the patch into my for-2.6.35 queue.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] sdhci-s3c: add support for the non standard minimal clock value
On Wed, 16 Jun 2010 08:49:55 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: S3C SDHCI host controller can change the source for generating mmc clock. By default host bus clock is used, what causes some problems on machines with 133MHz bus, because the SDHCI divider cannot be as high get proper clock value for identification mode. This is not a problem for the controller, because it can generate lower frequencies from other clock sources. This patch adds a new quirk to SDHCI driver to calculate the minimal supported clock frequency. This fixes the flood of the following warnings on Samsung S5PV210 SoCs: mmc0: Minimum clock frequency too high for identification mode Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mmc/host/sdhci-of-esdhc.c |1 + drivers/mmc/host/sdhci-s3c.c | 29 + drivers/mmc/host/sdhci.c |2 +- drivers/mmc/host/sdhci.h |2 ++ 4 files changed, 33 insertions(+), 1 deletions(-) This patch doesn't know about Anton's sdhci-pltfm-add-support-for-cns3xxx-soc-devices.patch. Please check my fixup: --- a/drivers/mmc/host/sdhci-cns3xxx.c~sdhci-s3c-add-support-for-the-non-standard-minimal-clock-value-fix +++ a/drivers/mmc/host/sdhci-cns3xxx.c @@ -93,5 +93,6 @@ struct sdhci_pltfm_data sdhci_cns3xxx_pd SDHCI_QUIRK_INVERTED_WRITE_PROTECT | SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN | SDHCI_QUIRK_BROKEN_TIMEOUT_VAL | + SDHCI_QUIRK_NONSTANDARD_MINCLOCK | SDHCI_QUIRK_NONSTANDARD_CLOCK, }; -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sdhci-s3c: add support for new card detection methods
On Wed, 16 Jun 2010 08:49:56 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
On some Samsung SoCs not all SDHCI controllers have card detect (CD)
line. For some embedded designs it is not even needed, because ususally
the device (like SDIO flash memory or wifi controller) is permanently
wired to the controller. There are also systems which have a card detect
line connected to some of the external interrupt lines or the presence
of the card depends on some other actions (like enabling a power
regulator).
This patch adds support for all these cases. The following card
detection methods are possible:
1. internal sdhci host card detect line
2. external event
3. external gpio interrupt
4. no card detect line, controller will poll for the card
5. no card detect line, card is permanently wired to the controller
(once detected host won't poll it any more)
By default, all existing code would use method #1, what is compatible
with the previous version of the driver.
In case of external event, two callbacks must be provided in platdata:
ext_cd_init and ext_cd_cleanup. Both of them get a callback to a
function that notifies the s3c-sdhci host contoller as their argument.
That callback function should be called from the even dispatcher to let
host notice the card insertion/removal.
In case of external gpio interrupt, a gpio pin number must be provided
in platdata (ext_cd_gpio parameter), as well as the information about
the polarity of that gpio pin (ext_cd_gpio_invert). By default
(ext_cd_gpio_invert == 0) gpio value 0 means 'card has been removed',
but this can be changed to 'card has been removed' when
ext_cd_gpio_invert == 1.
This patch adds changes to sdhci-s3c driver.
...
+static void sdhci_s3c_notify_change(struct platform_device *dev, int state)
+{
+ struct sdhci_host *host;
+ unsigned long flags;
+
+ local_irq_save(flags);
+ host = platform_get_drvdata(dev);
+ if (host) {
+ if (state) {
+ dev_dbg(dev-dev, card inserted.\n);
+ host-flags = ~SDHCI_DEVICE_DEAD;
+ host-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+ tasklet_schedule(host-card_tasklet);
+ } else {
+ dev_dbg(dev-dev, card removed.\n);
+ host-flags |= SDHCI_DEVICE_DEAD;
+ host-quirks = ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+ tasklet_schedule(host-card_tasklet);
+ }
+ }
+ local_irq_restore(flags);
+}
What's the local_irq_save() there for?
Presumably it is for local-cpu-only protection of some data. But which
data is it there to protect?
It doesn't provide protection on SMP systems and if I'm guessing
correctly about why it was added, it would be much better to use
spin_lock_irq[save]() here. That sets a better example, it means the
code has a hope of working correctly on SMP systems and will devolve to
local_irq_save() on UP kernels anyway.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sdhci-s3c: add missing remove function
On Wed, 16 Jun 2010 08:49:54 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index af21792..ad30f07 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -365,6 +365,26 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
static int __devexit sdhci_s3c_remove(struct platform_device *pdev)
{
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ struct sdhci_s3c *sc = sdhci_priv(host);
+ int ptr;
+
+ sdhci_remove_host(host, 1);
+
+ for (ptr = 0; ptr 3; ptr++) {
+ clk_disable(sc-clk_bus[ptr]);
+ clk_put(sc-clk_bus[ptr]);
+ }
+ clk_disable(sc-clk_io);
+ clk_put(sc-clk_io);
+
+ iounmap(host-ioaddr);
+ release_resource(sc-ioarea);
+ kfree(sc-ioarea);
+
+ sdhci_free_host(host);
+ platform_set_drvdata(pdev, NULL);
+
return 0;
}
This looks like it fixes a pretty serious omission. What happens if
the user rmmods this driver on a 2.6.34 kernel?
Because I have a suspicion that this fix should be backported into
2.6.34.x?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: Prevents unexpected status clear
On Wed, 07 Jul 2010 10:59:52 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
This patch clears only necessary bit.
Signed-off-by: Yusuke Goda yusuke.goda...@renesas.com
---
drivers/mmc/host/tmio_mmc.h |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 64f7d5d..7944604 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -82,10 +82,7 @@
#define ack_mmc_irqs(host, i) \
do { \
- u32 mask;\
- mask = sd_ctrl_read32((host), CTL_STATUS); \
- mask = ~((i) TMIO_MASK_IRQ); \
- sd_ctrl_write32((host), CTL_STATUS, mask); \
+ sd_ctrl_write32((host), CTL_STATUS, ~(i)); \
} while (0)
Can we have a better changelog please?
What was wrong with the old code?
How does the patch fix it?
What are the user-visible runtime effects of the bug?
(It looks like that was a pretty gross bug - how did it pass testing??)
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: Revise a limit of the data size
On Wed, 07 Jul 2010 11:01:20 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Signed-off-by: Yusuke Goda yusuke.goda...@renesas.com
---
drivers/mmc/host/tmio_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index ee7d0a5..cac1c97 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -661,7 +661,7 @@ static int tmio_mmc_start_data(struct tmio_mmc_host *host,
data-blksz, data-blocks);
/* Hardware cannot perform 1 and 2 byte requests in 4 bit mode */
- if (data-blksz 4 host-mmc-ios.bus_width == MMC_BUS_WIDTH_4) {
+ if (data-blksz 2 host-mmc-ios.bus_width == MMC_BUS_WIDTH_4) {
pr_err(%s: %d byte block unsupported in 4 bit mode\n,
mmc_hostname(host-mmc), data-blksz);
return -EINVAL;
Again, please provide a suitable description for this change.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sdhci-pltfm: Add support for CNS3xxx SoC devices
On Fri, 25 Jun 2010 22:06:44 +0400
Anton Vorontsov avoront...@mvista.com wrote:
There's nothing special, just SoC-specific ops and quirks.
...
+static void sdhci_cns3xxx_set_clock(struct sdhci_host *host, unsigned int
clock)
+{
+ struct device *dev = mmc_dev(host-mmc);
+ int div = 1;
+ u16 clk;
+ unsigned long timeout;
+
+ if (clock == host-clock)
+ return;
I assume that mmc core prevents this function from being exectued twice
at the same time?
+ sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
+
+ if (clock == 0)
+ goto out;
+
+ while (host-max_clk / div clock) {
+ /*
+ * On CNS3xxx divider grows linearly up to 4, and then
+ * exponentially up to 256.
+ */
+ if (div 4)
+ div += 1;
+ else if (div 256)
+ div *= 2;
+ else
+ break;
+ }
+
+ dev_dbg(dev, desired SD clock: %d, actual: %d\n,
+ clock, host-max_clk / div);
+
+ /* Divide by 3 is special. */
+ if (div != 3)
+ div = 1;
+
+ clk = div SDHCI_DIVIDER_SHIFT;
+ clk |= SDHCI_CLOCK_INT_EN;
+ sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
+
+ timeout = 20;
+ while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
+ SDHCI_CLOCK_INT_STABLE)) {
+ if (timeout == 0) {
+ dev_warn(dev, clock is unstable);
+ break;
+ }
+ timeout--;
+ mdelay(1);
Could we have used the more polite msleep() here?
+ }
+
+ clk |= SDHCI_CLOCK_CARD_EN;
+ sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
+out:
+ host-clock = clock;
+}
+
...
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -158,6 +158,9 @@ static int __devexit sdhci_pltfm_remove(struct
platform_device *pdev)
static const struct platform_device_id sdhci_pltfm_ids[] = {
{ sdhci, },
+#ifdef CONFIG_MMC_SDHCI_CNS3XXX
+ { sdhci-cns3xxx, (kernel_ulong_t)sdhci_cns3xxx_pdata },
+#endif
What the heck is this kernel_ulong_t thing and why did `struct
platform_device_id' see a need to invent it??
{ },
};
MODULE_DEVICE_TABLE(platform, sdhci_pltfm_ids);
...
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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] MMC: Add JZ4740 mmc driver
On Mon, 28 Jun 2010 03:20:41 +0200
Lars-Peter Clausen l...@metafoo.de wrote:
This patch adds support for the mmc controller on JZ4740 SoCs.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Matt Fleming m...@console-pimps.org
Cc: linux-mmc@vger.kernel.org
...
+#define JZ4740_MMC_MAX_TIMEOUT 1000
That was a really big timeout. How long do 1e7 readw's take? Oh well.
...
+static void jz4740_mmc_clock_disable(struct jz4740_mmc_host *host)
+{
+ uint32_t status;
+
+ writew(JZ_MMC_STRPCL_CLOCK_STOP, host-base + JZ_REG_MMC_STRPCL);
+ do {
+ status = readl(host-base + JZ_REG_MMC_STATUS);
+ } while (status JZ_MMC_STATUS_CLK_EN);
+}
+
+static void jz4740_mmc_reset(struct jz4740_mmc_host *host)
+{
+ uint32_t status;
+
+ writew(JZ_MMC_STRPCL_RESET, host-base + JZ_REG_MMC_STRPCL);
+ udelay(10);
+ do {
+ status = readl(host-base + JZ_REG_MMC_STATUS);
+ } while (status JZ_MMC_STATUS_IS_RESETTING);
+}
Maybe these should have a timeout too?
...
+static inline unsigned int jz4740_mmc_wait_irq(struct jz4740_mmc_host *host,
+ unsigned int irq)
+{
+ unsigned int timeout = JZ4740_MMC_MAX_TIMEOUT;
+ uint16_t status;
+
+ do {
+ status = readw(host-base + JZ_REG_MMC_IREG);
+ } while (!(status irq) --timeout);
+
+ return timeout;
+}
This guy's too big to inline. Recent gcc's know that and they tend to
uninline such things behind your back anwyay.
...
+struct jz4740_mmc_platform_data {
+ int gpio_power;
+ int gpio_card_detect;
+ int gpio_read_only;
+ unsigned card_detect_active_low:1;
+ unsigned read_only_active_low:1;
+ unsigned power_active_low:1;
+
+ unsigned data_1bit:1;
+};
The bitfields will all share the same word, so modification of one
field can race against modification of another field. Hence some form
of locking which covers *all* the bitfields is needed.
Is that a problem in this driver?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 4/5] block: Add secure discard
On Thu, 24 Jun 2010 11:44:23 +0300 Adrian Hunter adrian.hun...@nokia.com wrote: From b25b9a499f255ee5999c219525d82ef40382318c Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Wed, 23 Jun 2010 15:41:38 +0300 Subject: [PATCH 4/5] block: Add secure discard Secure discard is the same as discard except that all copies of the discarded sectors (perhaps created by garbage collection) must also be erased. That's not an awfully informative changelog. From a quick peek at the code it seems that you took your earlier design sketch: On Mon, Jun 14, 2010 at 02:10:06PM +0300, Adrian Hunter wrote: Needs a bio flag, a request flag, setup the request flag based on the bio flag, prevent merging secure and non-secure discards, prevent drivers doing non-secure discards for secure discards. Seems like a lot of little changes for something that no one wants. Shouldn't it wait for someone to need it first? and changed your mind and implemented it. Is that a correct interpretation? -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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 1/5] mmc: Add erase, secure erase, trim and secure trim operations
On Thu, 24 Jun 2010 11:44:00 +0300 Adrian Hunter adrian.hun...@nokia.com wrote: SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4 cards can support secure erase, trim and secure trim operations that are all variants of the basic erase command. The patch proposes a new userspace interface via sysfs, yes? Please fully describe that interface and its operation in the changelog. It'd also be nice to add permanent documentation for it. From reading the code, it appears that erase_size and preferred_erase_size have units in bytes. But users shouldn't need to read the code to find that out. What are the alignemnt and size requirements on these? What is their position in /sys? What do they actually *do* and what is the difference between them? etetera. People want to review this code and other people actually want to use it. I'm not sure that I want to try to review this code when nobody's told me what interface it implements and how it's supposed to work. Seems that whoever implemented BLKDISCARD didn't want anyone to use it either. Sigh. All of mmc core appears to use 32-bit quantities to represent sectors, yes? Why didn't it use sector_t? What are the implications of this? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] SDHCI: 8-bit data transfer width support
On Mon, 28 Jun 2010 12:48:29 -0700 Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Jun 28, 2010 at 12:33 PM, Olof Johansson o...@lixom.net wrote: On Mon, Jun 28, 2010 at 11:56:26AM -0700, Colin Cross wrote: These patches are not coming from the tegra/for-next branch, they are coming from Grant's devicetree-next branch. __Grant, why are these patches in your tree, and why is tegra/for-next in your tree? __It's going to cause conflicts when we rebase our for-next branch. __Please remove tegra and this sdhci patch from your tree. Yeah, this seems to be a mixup by Grant. I gave him a few patches I had picked up locally to work with, and he seems to have published the work accidentally. Hi Colin, I've fixed it now. Profuse apologies, sorry for the noise, and I owe you a beer or 3. Thanks, guys - I resurrected sdhci-8-bit-data-transfer-width-support.patch and sdhci-dont-assign-mmc-caps-at-sdhci-directly.patch -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] SDHCI: Don't assign mmc-caps at SDHCI directly
On Sat, 12 Jun 2010 14:44:50 +0900 Kyungmin Park kyungmin.p...@samsung.com wrote: From: Kyungmin Park kyungmin.p...@samsung.com Some host controller can set mmc-caps before sdhci_add_host. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mmc/host/sdhci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 4321e0c..142419c 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1791,7 +1791,7 @@ int sdhci_add_host(struct sdhci_host *host) else mmc-f_min = host-max_clk / 256; mmc-f_max = host-max_clk; - mmc-caps = MMC_CAP_SDIO_IRQ; + mmc-caps |= MMC_CAP_SDIO_IRQ; if (!(host-quirks SDHCI_QUIRK_FORCE_1_BIT_DATA)) mmc-caps |= MMC_CAP_4_BIT_DATA; A great shower of MMC patches have magically turned up in linux-next, apparently via some tree of Grant's. Those patches changed the above code to look like: if (!(host-quirks SDHCI_QUIRK_NO_SDIO_IRQ)) mmc-caps |= MMC_CAP_SDIO_IRQ; So it appears that this bug is fixed in that code as well. So I'll drop your patch. If the above changes end up not getting merged into mainline then your fix will be lost. That fix was unchangelogged. In fact the patch was completely unchangelogged and I haven't looked at it at all and as far as I can tell none of it has been sent to the mmc list. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] SDHCI: 8-bit data transfer width support
On Sat, 12 Jun 2010 14:45:02 +0900
Kyungmin Park kyungmin.p...@samsung.com wrote:
From: Kyungmin Park kyungmin.p...@samsung.com
Some host constroller such as s5pc110 has WIDE8 support feature.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci.c |5 +
drivers/mmc/host/sdhci.h |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 142419c..6cf018a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1159,6 +1159,11 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
+ if (ios-bus_width == MMC_BUS_WIDTH_8)
+ ctrl |= SDHCI_CTRL_8BITBUS;
+ else
+ ctrl = ~SDHCI_CTRL_8BITBUS;
+
if (ios-bus_width == MMC_BUS_WIDTH_4)
ctrl |= SDHCI_CTRL_4BITBUS;
else
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c846813..eb5efe0 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -72,6 +72,7 @@
#define SDHCI_CTRL_ADMA1 0x08
#define SDHCI_CTRL_ADMA32 0x10
#define SDHCI_CTRL_ADMA64 0x18
+#define SDHCI_CTRL_8BITBUS 0x20
#define SDHCI_POWER_CONTROL 0x29
#define SDHCI_POWER_ON 0x01
This change (or something similar) also seems to have been lumped into
the unchangelogged, unreviewed mmc: sdhci: Initial Tegra sdhci driver
patch. So again, I'll drop your patch and if mmc: sdhci: Initial
Tegra sdhci driver doesn't get merged, your patch will be lost.
I wonder what else it does. Here it is:
commit feed6702dc4bb130869171cbd8167637ea13c33c
Author: Colin Cross ccr...@android.com
AuthorDate: Wed Mar 10 20:42:35 2010 -0800
Commit: Grant Likely grant.lik...@secretlab.ca
CommitDate: Fri Jun 25 09:47:58 2010 -0600
mmc: sdhci: Initial Tegra sdhci driver
Signed-off-by: Colin Cross ccr...@android.com
[Olof: Fixed up merge conflicts]
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
diff --git a/arch/arm/mach-tegra/include/mach/sdhci.h
b/arch/arm/mach-tegra/include/mach/sdhci.h
new file mode 100644
index 000..34e2686
--- /dev/null
+++ b/arch/arm/mach-tegra/include/mach/sdhci.h
@@ -0,0 +1,33 @@
+/*
+ * include/asm-arm/arch-tegra/sdhci.h
+ *
+ * Copyright (C) 2009 Palm, Inc.
+ * Author: Yvonne Yip y...@palm.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+#ifndef __ASM_ARM_ARCH_TEGRA_SDHCI_H
+#define __ASM_ARM_ARCH_TEGRA_SDHCI_H
+
+#include linux/mmc/host.h
+
+struct tegra_sdhci_platform_data {
+ const char *clk_id;
+ int force_hs;
+ int cd_gpio;
+ int wp_gpio;
+ int power_gpio;
+
+ void (*board_probe)(int id, struct mmc_host *);
+ void (*board_remove)(int id, struct mmc_host *);
+};
+
+#endif
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index b9dee28..85c473e 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -229,11 +229,13 @@ static int sdio_enable_hs(struct mmc_card *card)
int ret;
u8 speed;
- if (!(card-host-caps MMC_CAP_SD_HIGHSPEED))
- return 0;
+ if (!(card-host-caps MMC_CAP_FORCE_HS)) {
+ if (!(card-host-caps MMC_CAP_SD_HIGHSPEED))
+ return 0;
- if (!card-cccr.high_speed)
- return 0;
+ if (!card-cccr.high_speed)
+ return 0;
+ }
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, speed);
if (ret)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index f06d06e..357c294 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -382,6 +382,12 @@ config MMC_TMIO
This provides support for the SD/MMC cell found in TC6393XB,
T7L66XB and also HTC ASIC3
+config MMC_SDHCI_TEGRA
+ tristate Tegra SD/MMC Controller Support
+ depends on ARCH_TEGRA MMC_SDHCI
+ help
+ This selects the Tegra SD/MMC controller.
+
config MMC_CB710
tristate ENE CB710 MMC/SD Interface support
depends on PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e30c2ee..fb04448 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_MMC_SDHCI_PCI) += sdhci-pci.o
obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o
obj-$(CONFIG_MMC_SDHCI_S3C)+= sdhci-s3c.o
Re: MMC tree (Was: Re: [PATCH 1/2] MMC: fix all hangs related to mmc/sd card insert/removal during suspend/resume.)
On Wed, 23 Jun 2010 13:08:37 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew, On Tue, 22 Jun 2010 15:20:06 -0700 Andrew Morton a...@linux-foundation.org wrote: On Tue, 22 Jun 2010 23:53:21 +0200 Rafael J. Wysocki r...@sisk.pl wrote: Andrew, who's maintaining MMC now? Pierre stopped doing it, so I'm now pretending to. So I guess I should remove the mmc tree (currently empty) from linux-next, then? yup. I actually pretend to maintain a huge number of subsystems and should sprinkle akpms all over MAINTAINERS so stuff doesn't get lost. How about splitting these subsystems out of -mm and adding them to linux-next? Sigh. Need to get onto that. I suppose you'd prefer something that actually compiles a bit, too. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Two fixes for my mmc/sd cardreader
On Mon, 21 Jun 2010 22:21:44 +0300 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-06-18 at 00:21 +0300, Maxim Levitsky wrote: Hi, These are 2 fixes for my card reader. First patch fixes old issue with system hand on suspend to disk/ram with mmc card inserted. I updated description, and pm notification registration order. I think this patch can an should go to 2.6.35, because it fixes long standing and nasty regression. The second patch is a result of my work trying to understand why my card reader sometimes dies on resume. This reader has a special MMC function which steals MMC cards, and until now had no driver. A way to disable it was found, and while it works, it has (at least here) a side effect of killing the controller on resume from ram/disk (and it happens often, and doesn't depend of whether card was in slot or not during suspend). Fortunately it turned out that MMC part is _almost_ standard SDHCI controller. This patch adds support for this device to standard sdhci driver. Unfortunately, this support still contais small hack. It waits 1/2 of a second on resume before initializing the controller. Not doing so, and resuming with MMC card present results in confused controller. It is not dead though. A card reinsert makes it work again with all cards. Yet the 1st patch is must for this because otherwise mmc core seeing that controller doesn't respond, removes the card, therefore hangs the system. It doesn't happen when I wait these 1/2 of second though. I think that this patch is also ok for 2.6.35, because it only adds new functionality. You are free to disable MMC controller using the same CONFIG_MMC_RICOH_MMC. If you don't disable it though, instead of full lack of functionality you will get full featured MMC controller. Best regards, Maxim Levitsky ping hey, that was only three days. I commonly leave things to bake on the mailing list for a while, see what people have to say about it. Particularly with subsystems like MMC. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
On Thu, 17 Jun 2010 20:57:19 +0530 (IST) kishore kadiyala kishore.kadiy...@ti.com wrote: Adding card detect callback function which gives the status of the card .For MMC1 Controller, Card detect interrupt source is twl6030 and card present/absent status is provided by MMCCTRL register of twl6030. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com --- arch/arm/mach-omap2/board-4430sdp.c | 11 +-- arch/arm/mach-omap2/hsmmc.c |1 + arch/arm/plat-omap/include/plat/mmc.h |1 + drivers/mfd/twl6030-irq.c | 23 drivers/mmc/host/omap_hsmmc.c | 30 ++--- include/linux/i2c/twl.h | 46 + 6 files changed, 104 insertions(+), 8 deletions(-) I assume this depends on [PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card detect? It's all a bit too remote from my (ever-expanding) work area, so I'll assume that Tony or someone will look after these. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card detect
On Thu, 17 Jun 2010 20:56:58 +0530 (IST)
kishore kadiyala kishore.kadiy...@ti.com wrote:
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -43,6 +43,9 @@
#define OMAP_MMC_MAX_SLOTS 2
+#define NON_GPIO 0
+#define GPIO 1
I'm counting about seven different definitions of GPIO in the kernel
already.
drivers/hwmon/it87.c:
#define GPIO0x07
drivers/media/dvb/dvb-usb/ec168.h:
GPIO = 0x04,
drivers/net/hamachi.c:
GPIO=0x6E
drivers/staging/rtl8187se/r8180_hw.h:
#define GPIO 0x91
etcetera. It's a crazy identifier to use in a header file, and
the chances of a miscompile-causing collision are increasing.
enum cd_type {
CD_TYPE_NON_GPIO = 0,
CD_TYPE_GPIO = 1,
};
perhaps?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
On Thu, 17 Jun 2010 20:57:19 +0530 (IST)
kishore kadiyala kishore.kadiy...@ti.com wrote:
Adding card detect callback function which gives the status of
the card .For MMC1 Controller, Card detect interrupt source is
twl6030 and card present/absent status is provided by MMCCTRL
register of twl6030.
...
+ int ret = -ENOSYS;
+ int ret = -ENOSYS;
ENOSYS seems an inappropriate errno to use in a driver.
ENOSYS -- The system doesn't support that function. For example, if
you call setpgid() on a system without job control, you'll get an
ENOSYS error.
I think it means you the programmer tried to do something in a syscall
which didn't make sense in this context.
I'm not sure what _is_ appropraite here. There's always EIO I guess.
ENODEV?
This happens a lot. The userspace errnos just don't map well onto
kernel-internal operations. it was a mistake - we should have defined a
kernel-internal namespace and perhaps type for such things. Oh well.
+/* Configuring Card Detect for MMC1 */
+static inline int omap4_hsmmc1_card_detect_config(void)
+{
+ int res = -1;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ }
+
+
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ res = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (res 0)
+ return res;
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+
+ /* Configuring CFG_INPUT_PUPD3 */
+ res = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (res 0)
+ return res;
+ reg_val = ~(MMC_PU | MMC_PD);
+ twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_CFG_INPUT_PUPD3);
+ return res;
+}
This is way to large to be inlined. Why not put it in a .c file?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] MMC: fix all hangs related to mmc/sd card insert/removal during suspend/resume.
On Fri, 11 Jun 2010 22:19:55 +0300 Maxim Levitsky maximlevit...@gmail.com wrote: If you don't use CONFIG_MMC_UNSAFE_RESUME, card will now be removed in pm notified while userspace is still running. Thus it will be possible to sync it propely. That paragraph is a disaster and I'm not sure that I understand it well enough to repair it. I think you wanted s/now/not/ and s/in/if/ and s/it will be/it will not be/. Or perhaps you didn't. Please send a comprehensible replacement. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 16119] New: jmb38x recognized and works only if a card is plugged in during boot
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Fri, 4 Jun 2010 01:09:03 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=16119 Summary: jmb38x recognized and works only if a card is plugged in during boot Product: Drivers Version: 2.5 Kernel Version: 2.6.34 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: MMC/SD AssignedTo: drivers_mmc...@kernel-bugs.osdl.org ReportedBy: eugene.shaly...@gmail.com Regression: No Created an attachment (id=26643) -- (https://bugzilla.kernel.org/attachment.cgi?id=26643) lspci results with card plugged in Acer Aspire 8942G, card reader works only if a card was plugged in before boot. hm, I don't know who wold be the appropriate person to look into this. Let's try the mailing list. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts
On Sat, 29 May 2010 19:27:23 -0700 Cory Maccarrone darkstar6...@gmail.com wrote: This change removes a BUG_ON for when interrupts are disabled during an MMC request. During boot, interrupts can be disabled when a request is made, causing this bug to be triggered. In reality, there's no reason this should halt the kernel, as the driver has proved reliable in spite of disabled interrupts, and additionally, there's nothing in this code that would require interrupts to be enabled. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- drivers/mmc/host/omap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 2b28168..d98ddcf 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host, mmc_omap_start_command(host, req-cmd); if (host-dma_in_use) omap_start_dma(host-dma_ch); - BUG_ON(irqs_disabled()); } static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req) So we need to decide whether this should be backported into 2.6.34.x and perhaps earlier. For that decision we'll need to know the things you didn't tell us: Which drivers are affected? Under which setups is it triggering? Why aren't lots of people reporting hey my kernel went BUG? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] ARM: add DMA support to sh7372, enable DMA for SDHI
On Thu, 13 May 2010 08:57:06 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Wed, 12 May 2010, Andrew Morton wrote: On Tue, 4 May 2010 16:07:15 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch depends on patch series from Magnus for shmobile, adding INTC and clock support. This patch wasn't there in the first version of this series. Where is that patch series now? AFAIU, these are two patch series - for the interrupt controller and for the clock framework, and they are not upstream yet. So, I think, we can leave patch 9/9 for later to be merged via the respective platform tree. Again, because of your lack of specificity in identifying patches I am unable to determine whether arm-add-dma-support-to-sh7372-enable-dma-for-sdhi.patch is presently mergeable. So I won't merge it. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] tmio: let platforms decide upon write-protection availability
On Wed, 19 May 2010 20:35:57 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: No changes to patches themselves, just re-sending with an ack added. Applies on top of the [PATCH 0/10] add DMA support to tmio_mmc, using dmaengine API, use it on SH patch series. Paul, are you planning on merging the tem patches in the above-mentioned series for 2.6.35-rc1? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 15876] New: MMC initialisation: valid devices fail to init due to frequency check
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 29 Apr 2010 10:26:39 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=15876 Summary: MMC initialisation: valid devices fail to init due to frequency check Product: Drivers Version: 2.5 Kernel Version: 2.6.31 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Flash/Memory Technology Devices AssignedTo: dw...@infradead.org ReportedBy: n...@leverton.org Regression: Yes I have a commercially available development board with MMC card socket (Atmel ATSTK1006 with AP7000). Prior to 2.6.31 this board could successfully initialise and use MMC cards. Since the minimum frequency enforcement to 400 KHz was added in commit 8dfd0374be84793360db7fff2e635d2cd3bbcb21, this board can no longer detect MMC cards. Thanks to the following diagnostic patch: http://lkml.org/lkml/2010/1/4/291 I narrowed down the frequency range supported by this board. The host-f_min here is 136719 Hz. atmel_mci atmel_mci.0: Atmel MCI controller at 0xfff02400 irq 28, 1 slots mmc_rescan: trying 40 Hz Waiting for root device /dev/mmcblk0p1... mmc_rescan: trying 30 Hz mmc_rescan: trying 20 Hz mmc_rescan: trying 136719 Hz mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address 8fe4 mmcblk0: mmc0:8fe4 SD02G 1.84 GiB I understand that the MMC spec allows frequency ranges between about 400 KHZ and 138 KHz. It seems that enforcing the minimum frequency to be the highest from the specification is causing the problem and causes an otherwise within-spec device such as this to fail to initialise. Other AVR32/AP7000 boards such as NGW100 seem OK with the same cards (Sandisk 2Gb) by the way and do work at full speed. It seems it may be due to this particular board layout that, although just about within spec, it is limited to the lower end of the range. Could I please ask the MMC people to re-visit this frequency check issue ? I'm opening this bug as a marker, thank you :) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci-spear: ST SPEAr based SDHCI controller glue
On Wed, 5 May 2010 15:05:18 +0530
Viresh KUMAR viresh.ku...@st.com wrote:
This patch adds glue layer for support of sdhci driver on ST SPEAr platform.
Looks OK to my untrained eye. A few very minor things:
...
+static irqreturn_t sdhci_gpio_irq(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ struct spear_sdhci *sdhci =
+ (struct spear_sdhci *)(pdev-dev.platform_data);
Seems wrong to open-code all of this. There should be a
void *platform_device_get_platform_data(struct platform_device *);
but I can't find it. The code can use dev_get_platdata(), however.
Also, you don't _have_ to initialise things at the definition site. If
you were to do:
struct platform_device *pdev;
struct sdhci_host *host;
struct spear_sdhci *sdhci;
pdev = dev_id;
host = platform_get_drvdata(pdev);
sdhci = (struct spear_sdhci *)(pdev-dev.platform_data);
then you wouldn't need to do weird things to fit the code in 80-cols.
Also, platform_data has type void*, so the typecast here is unneeded
and, because it defeats typechecking it is undesirable.
+ unsigned long gpio_irq_type;
+ int val;
+
+ val = gpio_get_value(sdhci-data-card_int_gpio);
+
+ /* val == 1 - card removed, val == 0 - card inserted */
+ /* if card removed - set irq for low level, else vice versa */
+ gpio_irq_type = val ? IRQF_TRIGGER_LOW : IRQF_TRIGGER_HIGH;
+ set_irq_type(irq, gpio_irq_type);
+
+ if (sdhci-data-card_power_gpio = 0) {
+ if (!sdhci-data-power_always_enb) {
+ /* if card inserted, give power, otherwise remove it */
+ val = sdhci-data-power_active_high ? !val : val ;
+ gpio_set_value(sdhci-data-card_power_gpio, val);
+ }
+ }
+
+ /* inform sdhci driver about card insertion/removal */
+ tasklet_schedule(host-card_tasklet);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit sdhci_probe(struct platform_device *pdev)
+{
+ struct sdhci_host *host;
+ struct resource *iomem;
+ struct spear_sdhci *sdhci;
+ int ret;
+
+ BUG_ON(pdev == NULL);
+
+ iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!iomem) {
+ ret = -ENOMEM;
+ dev_dbg(pdev-dev, memory resource not defined\n);
+ goto err;
+ }
+
+ if (!request_mem_region(iomem-start, resource_size(iomem),
+ spear-sdhci)) {
+ ret = -EBUSY;
+ dev_dbg(pdev-dev, cannot request region\n);
+ goto err;
+ }
+
+ sdhci = kzalloc(sizeof(*sdhci), GFP_KERNEL);
+ if (!sdhci) {
+ ret = -ENOMEM;
+ dev_dbg(pdev-dev, cannot allocate memory for sdhci\n);
+ goto err_kzalloc;
+ }
+
+ /* clk enable */
+ sdhci-clk = clk_get(pdev-dev, NULL);
+ if (IS_ERR(sdhci-clk)) {
+ ret = PTR_ERR(sdhci-clk);
+ dev_dbg(pdev-dev, Error getting clock\n);
+ goto err_clk_get;
+ }
+
+ ret = clk_enable(sdhci-clk);
+ if (ret) {
+ dev_dbg(pdev-dev, Error enabling clock\n);
+ goto err_clk_enb;
+ }
+
+ /* overwrite platform_data */
+ sdhci-data = (struct sdhci_plat_data *)(pdev-dev.platform_data);
Similarly.
+ pdev-dev.platform_data = sdhci;
+
+ if (pdev-dev.parent)
+ host = sdhci_alloc_host(pdev-dev.parent, 0);
+ else
+ host = sdhci_alloc_host(pdev-dev, 0);
+
+ if (IS_ERR(host)) {
+ ret = PTR_ERR(host);
+ dev_dbg(pdev-dev, error allocating host\n);
+ goto err_alloc_host;
+ }
+
+ host-hw_name = sdhci;
+ host-ops = sdhci_pltfm_ops;
+ host-irq = platform_get_irq(pdev, 0);
+ host-quirks = SDHCI_QUIRK_BROKEN_ADMA;
+
+ host-ioaddr = ioremap(iomem-start, resource_size(iomem));
+ if (!host-ioaddr) {
+ ret = -ENOMEM;
+ dev_dbg(pdev-dev, failed to remap registers\n);
+ goto err_ioremap;
+ }
+
+ ret = sdhci_add_host(host);
+ if (ret) {
+ dev_dbg(pdev-dev, error adding host\n);
+ goto err_add_host;
+ }
+
+ platform_set_drvdata(pdev, host);
+
...
+static int __devexit sdhci_remove(struct platform_device *pdev)
+{
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ struct spear_sdhci *sdhci =
+ (struct spear_sdhci *)(pdev-dev.platform_data);
Again.
+ int dead;
+ u32 scratch;
+
+ if (sdhci-data) {
+ if (sdhci-data-card_int_gpio = 0) {
+ free_irq(gpio_to_irq(sdhci-data-card_int_gpio), pdev);
+
Re: [PATCH] sdio: add new function for RAW (Read after Write) operation
On Fri, 14 May 2010 14:04:17 +0300
Grazvydas Ignotas nota...@gmail.com wrote:
Hi Kalle,
On Wed, Apr 28, 2010 at 12:18 AM, Grazvydas Ignotas nota...@gmail.com wrote:
SDIO specification allows RAW (Read after Write) operation using
IO_RW_DIRECT command (CMD52) by setting the RAW bit. This operation is
similar to ordinary read/write commands, except that both write and read
are performed using single command/response pair. The Linux SDIO layer
already supports this internaly, only external function is missing for
drivers to make use, which is added by this patch.
This type of command is required to implement proper power save mode
support in wl1251 wifi driver.
As wl1251 maintainer, can you confirm this is needed for wl1251 driver
to function in SDIO mode? Perhaps this could help convince Andrew to
merge this patch.
I kinda ducked the patch because there are no callers of the function.
Without this the chip is having problems leaving ELP
mode. Android has similar patch for G1 in it's tree for the same
reason:
http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff;h=74a47786f6ecbe6c1cf9fb15efe6a968451deb52
Well let's cc Dmitry then. Dmitry's patch is somewhat different from
yours and that needs to be looked at.
Some comments:
: From: Grazvydas Ignotas nota...@gmail.com
:
: SDIO specification allows RAW (Read after Write) operation using
: IO_RW_DIRECT command (CMD52) by setting the RAW bit. This operation is
: similar to ordinary read/write commands, except that both write and read
: are performed using single command/response pair. The Linux SDIO layer
: already supports this internaly, only external function is missing for
: drivers to make use, which is added by this patch.
:
: This type of command is required to implement proper power save mode
: support in wl1251 wifi driver.
:
: Signed-off-by: Grazvydas Ignotas nota...@gmail.com
: Signed-off-by: Andrew Morton a...@linux-foundation.org
: ---
:
: drivers/mmc/core/sdio_io.c| 31 +++
: include/linux/mmc/sdio_func.h |3 +++
: 2 files changed, 34 insertions(+)
:
: diff -puN
drivers/mmc/core/sdio_io.c~sdio-add-new-function-for-raw-read-after-write-operation
drivers/mmc/core/sdio_io.c
: ---
a/drivers/mmc/core/sdio_io.c~sdio-add-new-function-for-raw-read-after-write-operation
: +++ a/drivers/mmc/core/sdio_io.c
: @@ -406,6 +406,37 @@ void sdio_writeb(struct sdio_func *func,
: EXPORT_SYMBOL_GPL(sdio_writeb);
:
: /**
: + * sdio_writeb_readb - write and read a byte from SDIO function
: + * @func: SDIO function to access
: + * @b: byte to write
: + * @addr: address to write to
: + * @err_ret: optional status value from transfer
: + *
: + * Performs a RAW (Read after Write) operation as defined by SDIO spec -
: + * single byte is written to address space of a given SDIO function and
: + * response is read back from the same address, both using single request.
: + * If there is a problem with the operation, 0xff is returned and
: + * @err_ret will contain the error code.
: + */
: +u8 sdio_writeb_readb(struct sdio_func *func, u8 b,
b is a poor name. Please choose something meaningful.
: + unsigned int addr, int *err_ret)
: +{
: + int ret;
: + u8 val;
: +
: + BUG_ON(!func);
This test doesn't gain us much. If `func' is NULL, we'll reliably oops
when dereferencing it, which gives the same info as the BUG_ON().
: + ret = mmc_io_rw_direct(func-card, 1, func-num, addr, b, val);
: + if (err_ret)
: + *err_ret = ret;
: + if (ret)
: + val = 0xff;
: +
: + return val;
: +}
: +EXPORT_SYMBOL_GPL(sdio_writeb_readb);
: +
: +/**
: * sdio_memcpy_fromio - read a chunk of memory from a SDIO function
: * @func: SDIO function to access
: * @dst: buffer to store the data
: diff -puN
include/linux/mmc/sdio_func.h~sdio-add-new-function-for-raw-read-after-write-operation
include/linux/mmc/sdio_func.h
: ---
a/include/linux/mmc/sdio_func.h~sdio-add-new-function-for-raw-read-after-write-operation
: +++ a/include/linux/mmc/sdio_func.h
: @@ -145,6 +145,9 @@ extern void sdio_writew(struct sdio_func
: extern void sdio_writel(struct sdio_func *func, u32 b,
: unsigned int addr, int *err_ret);
:
: +extern u8 sdio_writeb_readb(struct sdio_func *func, u8 b,
: + unsigned int addr, int *err_ret);
: +
: extern int sdio_memcpy_toio(struct sdio_func *func, unsigned int addr,
: void *src, int count);
: extern int sdio_writesb(struct sdio_func *func, unsigned int addr,
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9 v3] add DMA support to tmio_mmc, using dmaengine API, use it on SH
On Thu, 13 May 2010 15:44:21 +0900 Paul Mundt let...@linux-sh.org wrote: On Thu, May 13, 2010 at 08:42:42AM +0200, Guennadi Liakhovetski wrote: On Wed, 12 May 2010, Andrew Morton wrote: On Tue, 11 May 2010 12:07:07 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: 2.6.35 release is approaching and Ian hasn't found time yet to review this series, so I was wondering, maybe you could take it into mm at least for now? Well I did, but I don't know how useful that was. WHo is the most appropriate tree-maintainer to review and possibly merge these? Samuel has already acked the MFD patch: http://article.gmane.org/gmane.linux.ports.sh.devel/7985 (please, add this his ack to the patch too). Most of the patches in the series are SuperH- or SH-Mobile specific, which makes Paul (added to CC) the perfect candidate to review them. There is only one tmio-specific patch, and it is also the most complicated one. You or Paul can certainly just follow it to verify, that it doesn't introduce any regressions. I can also confirm it, because I also tested the patched driver without DMA loaded, and it worked just like before in PIO mode. It would, however, be great to test the patches on a non-sdhi hardware, of which none of us, probably, has any. I added Philipp Zabel to CC, who has contributed a few patches to tmio_mmc in the past, perhaps, he still has access to the hardware and could test these patches. I don't have any problems taking all of the SH and SDHI related bits, but since they all depend on the tmio_mmc change I haven't picked them up yet. They'll likely continue to sit in my patch queue until something happens with the tmio_mmc changes. Given the response times we've had with any tmio related changes in the past I'm not exactly betting on a speedy resolution.. argh. Patches have names, guys. What are the tmio_mmc changes and where are they? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc-omap: Add support for 16-bit and 32-bit registers
On Thu, 13 May 2010 12:29:35 -0700 Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100307 09:44]: From: Marek Belisko marek.beli...@open-nandra.com The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To resolve this, a bit shift is performed on base register addresses, either by 1 or 2 bits depending on the CPU in use. This yields the correct registers for each CPU. Signed-off-by: Marek Belisko marek.beli...@open-nandra.com Signed-off-by: Cory Maccarrone darkstar6...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Can you please queue this patch too? Ben's comments in this thread were for the i2c-omap, not for this MMC patch. We've had this patch in the omap tree for testing for quite a while now. The patch is also available in at: https://patchwork.kernel.org/patch/83971/ with the direct link to the mbox being: https://patchwork.kernel.org/patch/83971/mbox/ I already have that, as mmc-omap-add-support-for-16-bit-and-32-bit-registers.patch -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap_hsmmc: improve interrupt synchronisation
On Wed, 12 May 2010 10:50:45 +0300
Adrian Hunter adrian.hun...@nokia.com wrote:
From ad2e1cd024ccf9144b6620cfe808893719db738f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 14 Apr 2010 16:26:45 +0300
Subject: [PATCH] omap_hsmmc: improve interrupt synchronisation
The following changes were needed:
- do not use in_interrupt() because it will not work
with threaded interrupts
In addition, the following improvements were made:
- ensure DMA is unmapped only after the final DMA interrupt
- ensure a request is completed only after the final DMA interrupt
- disable controller interrupts when a request is not in progress
- remove the spin-lock protecting the start of a new request from
an unexpected interrupt because the locking was complicated and
a 'req_in_progress' flag suffices (since the spin-lock only defers
the unexpected interrupts anyway)
- instead use the spin-lock to protect the MMC interrupt handler
from the DMA interrupt handler
- remove the semaphore preventing DMA from being started while
the previous DMA is still in progress - the other changes make that
impossible, so it is now a BUG_ON condition
- ensure the controller interrupt status is clear before exiting
the interrrupt handler
In general, these changes make the code safer but do not fix any specific
bugs so backporting is not necessary.
...
+static void omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct
mmc_request *mrq)
+{
+ int dma_ch;
+
+ spin_lock(host-irq_lock);
+ host-req_in_progress = 0;
+ dma_ch = host-dma_ch;
+ spin_unlock(host-irq_lock);
+
+ omap_hsmmc_disable_irq(host);
+ /* Do not complete the request if DMA is still in progress */
+ if (mrq-data host-use_dma dma_ch != -1)
+ return;
+ host-mrq = NULL;
+ mmc_request_done(host-mmc, mrq);
+}
Are we sure that irq_lock doesn't need to be taken in an irq-safe fashion?
send_init_stream() doesn't report an error if its busywait times out.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: at91_mci: modify cache flush routines
On Tue, 11 May 2010 19:09:53 +0200 Nicolas Ferre nicolas.fe...@atmel.com wrote: As we were using an internal dma flushing routine, this patch changes to the DMA API flush_kernel_dcache_page(). Driver is able to compile now. Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- drivers/mmc/host/at91_mci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c index a6dd7da..813d208 100644 --- a/drivers/mmc/host/at91_mci.c +++ b/drivers/mmc/host/at91_mci.c @@ -315,7 +315,7 @@ static void at91_mci_post_dma_read(struct at91mci_host *host) } kunmap_atomic(sgbuffer, KM_BIO_SRC_IRQ); - dmac_flush_range((void *)sgbuffer, ((void *)sgbuffer) + amount); + flush_kernel_dcache_page(sg_page(sg)); data-bytes_xfered += amount; if (size == 0) break; The flush_kernel_dcache_page() documentation specifically says that thou shalt run flush_kernel_dcache_page() _prior_ to kunmapping the page. I don't know if that makes a difference in the real world, but heck why not: --- a/drivers/mmc/host/at91_mci.c~mmc-at91_mci-modify-cache-flush-routines-fix +++ a/drivers/mmc/host/at91_mci.c @@ -314,8 +314,8 @@ static void at91_mci_post_dma_read(struc dmabuf = (unsigned *)tmpv; } - kunmap_atomic(sgbuffer, KM_BIO_SRC_IRQ); flush_kernel_dcache_page(sg_page(sg)); + kunmap_atomic(sgbuffer, KM_BIO_SRC_IRQ); data-bytes_xfered += amount; if (size == 0) break; _ However, I'm wondering why you chose flush_kernel_dcache_page() instead of plain old flush_dcache_page(). Is this a pagecache or possibly direct-io page we're dealing with here? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] ARM: add DMA support to sh7372, enable DMA for SDHI
On Tue, 4 May 2010 16:07:15 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch depends on patch series from Magnus for shmobile, adding INTC and clock support. This patch wasn't there in the first version of this series. Where is that patch series now? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9 v3] add DMA support to tmio_mmc, using dmaengine API, use it on SH
On Tue, 11 May 2010 12:07:07 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: 2.6.35 release is approaching and Ian hasn't found time yet to review this series, so I was wondering, maybe you could take it into mm at least for now? Well I did, but I don't know how useful that was. WHo is the most appropriate tree-maintainer to review and possibly merge these? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmc: sdhci.h compile error
On Mon, 26 Apr 2010 14:17:04 +0400 Anton Vorontsov cbouatmai...@gmail.com wrote: On Sun, Apr 25, 2010 at 11:28:17PM +0100, Matt Fleming wrote: On Wed, 21 Apr 2010 19:43:32 +0800, zhangfei gao zhangfei@gmail.com wrote: There is compile error when we enable CONFIG_MMC_SDHCI_IO_ACCESSORS, and include header file #include sdhci.h error: macro writel passed 3 arguments, but takes just 2 Interesting... It was Anton Vorontsov that added this code; presumably the code has never been compiled for an ARM board (or any other architecture that #define's their I/O accessors in asm/io.h). Yep, there wasn't any need for these accessors on other platforms. It would be better if all architectures declared their I/O accessors as static inline, but I'm not volunteering to touch all those headers ;-) Renaming the SDHCI ops is definitely the easiest option. Anton, do you have a problem with the attached patch to rename the SDHCI accessor functions? Looks OK. Acked-by: Anton Vorontsov cbouatmai...@gmail.com (for -next, I presume) Why not for 2.6.34? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + sdhci-rename-sdhci-i-o-accessor-functions.patch added to -mm tree
On Fri, 30 Apr 2010 07:38:17 +0100
Matt Fleming m...@console-pimps.org wrote:
On Thu, 29 Apr 2010 15:29:26 -0700, a...@linux-foundation.org wrote:
Subject: sdhci: build fix: rename SDHCI I/O accessor functions
From: Matt Fleming m...@console-pimps.org
Unfortunately some architectures #define their read{b,w,l} and
write{b,w,l} I/O accessors which makes the SDHCI I/O accessor functions of
the same names subject to preprocessing. This leads to the following
compiler error,
In file included from drivers/mmc/host/sdhci.c:26:
drivers/mmc/host/sdhci.h:318:35: error: macro writel passed 3 arguments,
but takes just 2
Rename the SDHCI I/O functions so that CONFIG_MMC_SDHCI_IO_ACCESSORS can
be enabled for architectures that implement their read{b,w,l} and
write{b,w,l} functions with macros.
Signed-off-by: Matt Fleming m...@console-pimps.org
Cc: Zhangfei Gao zg...@marvell.com
Acked-by: Anton Vorontsov cbouatmai...@gmail.com
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Hi Andrew,
this patch got a couple more ACKs from Wolfram Sang and Ben Dooks. Would
like me to respin the patch?
I updated the changelog text, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MMC: atmel-mci: fix two parameters swapped
Patches 1-3 (at least) appear to be applicable to 2.6.33.x and perhaps earlier. But you didn't cc sta...@kernel.org and there was no Cc: sta...@kernel.org in the changelog and in this case I'd prefer not to make that decision myself? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MMC: Add support MMCIF for SuperH
On Tue, 27 Apr 2010 19:15:02 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
MMCIF is MMC Host Interface in SuperH.
...
+static void sh_mmcif_clock_control(struct sh_mmcif_host *host, unsigned int
clk)
+{
+ int i;
+ struct sh_mmcif_plat_data *p = host-pd-dev.platform_data;
+
+ sh_mmcif_bitclr(host, MMCIF_CE_CLK_CTRL, CLK_ENABLE);
+ sh_mmcif_bitclr(host, MMCIF_CE_CLK_CTRL, CLK_CLEAR);
+
+ if (!clk)
+ return;
+ if (p-sup_pclk clk == host-clk) {
+ sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_SUP_PCLK);
+ } else {
+ for (i = 1; (unsigned int)host-clk / (1 i) = clk; i++)
+ ;
I suspect this could be clarified. Perhaps
i = ilog2(__roundup_pow_of_two(host-clk));
If that's wrong then include/linux/log2.h has various tools which can
surely be used. If they're not appropriate then please feel free to
propose additions.
+ sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, (i - 1) 16);
+ }
+ sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_ENABLE);
+}
+
...
+static int sh_mmcif_error_manage(struct sh_mmcif_host *host)
+{
+ u32 state1, state2;
+ int ret, timeout = 1000;
+
+ host-sd_error = 0;
+ host-wait_int = 0;
+
+ state1 = sh_mmcif_readl(host, MMCIF_CE_HOST_STS1);
+ state2 = sh_mmcif_readl(host, MMCIF_CE_HOST_STS2);
+ pr_debug(%s: ERR HOST_STS1 = %08x\n, \
+ DRIVER_NAME, sh_mmcif_readl(host, MMCIF_CE_HOST_STS1));
+ pr_debug(%s: ERR HOST_STS2 = %08x\n, \
+ DRIVER_NAME, sh_mmcif_readl(host, MMCIF_CE_HOST_STS2));
+
+ if (state1 STS1_CMDSEQ) {
+ pr_debug(%s: Forced end of command sequence\n, DRIVER_NAME);
+ sh_mmcif_bitset(host, MMCIF_CE_CMD_CTRL, CMD_CTRL_BREAK);
+ sh_mmcif_bitset(host, MMCIF_CE_CMD_CTRL, ~CMD_CTRL_BREAK);
+ while (1) {
+ timeout--;
+ if (timeout 0) {
+ pr_err(DRIVER_NAME: Forceed end of \
+ command sequence timeout err\n);
+ return -EILSEQ;
+ }
+ if (!(sh_mmcif_readl(host, MMCIF_CE_HOST_STS1)
+ STS1_CMDSEQ))
+ break;
+ mdelay(1);
+ }
+ sh_mmcif_sync_reset(host);
+ return -EILSEQ;
Good heavens, what is EILSEQ?
googles a bit
An illegal multibyte sequence was found in the input. This
usually means that you have the wrong charactor encoding, for
instance the MicrosoftCorporation version of latin-1 (aka
iso_8859_1(7)) (which has it's own stuff like smart quotes in
the reserved bytes) instead of the real latin (or perhaps
utf8(7)).
Why on earth are driver writers using this in the kernel??? Imagine
the confusion which ensues when this error code propagates all the way
back to some poor user's console. They'll be scrabbling around with
language encodings not even suspecting that their hardware is busted.
People do this *a lot*. They go grubbing through errno.h and grab
something which looks vaguely appropriate. But it's wrong.
If your hardware is busted then return -EIO and emit a printk to tell
the operator what broke.
+ }
+
+ if (state2 STS2_CRC_ERR)
+ ret = -EILSEQ;
+ else if (state2 STS2_TIMEOUT_ERR)
+ ret = -ETIMEDOUT;
+ else
+ ret = -EILSEQ;
+ return ret;
+}
...
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] MMC:Add support MMCIF for SuperH
On Wed, 28 Apr 2010 14:06:08 +0900 Yusuke Goda yusuke.goda...@renesas.com wrote: + time = wait_event_interruptible_timeout(host-intr_wait, + host-wait_int == 1 || + host-sd_error == 1, host-timeout); + if (host-wait_int != 1 (time == 0 || host-sd_error != 0)) + return sh_mmcif_error_manage(host); wait_event_interruptible_timeout() will return early with -ERESTARTSYS if the calling process gets signalled (eg, ^C was hit). The driver uses wait_event_interruptible_timeout() rather a lot and the two sites I looked at seem to handle the signal_pending() case correctly. But incorrectly handling signals with interruptible waits is a frequently-occurring error in drivers. Did you deliberately cater for this case, and have you runtime tested it? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 15836] Commit 6ad696d2cf535772dff659298ec7e7260e344595 breaks my SD card reader [197b:2381]
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 26 Apr 2010 20:48:47 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=15836 OK, I give up. Can anyone suggest how 6ad696d2cf535772dff659298ec7e7260e344595 (mm: allow memory hotplug and hibernation in the same kernel) could have caused the mmc failures which Stephan is reporting in the above bugzilla record? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 15656] New: System sluggish when using ENE SD card reader
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 31 Mar 2010 11:09:28 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=15656 Summary: System sluggish when using ENE SD card reader Product: Drivers Version: 2.5 Kernel Version: 2.6.33 and earlier Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: MMC/SD AssignedTo: drivers_mmc...@kernel-bugs.osdl.org ReportedBy: theholyet...@googlemail.com Regression: No My system becomes incredibly sluggish (jerky X cursor, choppy audio) when accessing an SD card with my notebook's built-in ENE card reader. The kernel was compiled with full pre-emption enabled. From lspci -nn: 0c:07.0 FLASH memory [0501]: ENE Technology Inc ENE PCI Memory Stick Card Reader Controller [1524:0730] 0c:07.1 SD Host controller [0805]: ENE Technology Inc ENE PCI SmartMedia / xD Card Reader Controller [1524:0750] 0c:07.3 FLASH memory [0501]: ENE Technology Inc ENE PCI Secure Digital / MMC Card Reader Controller [1524:0751] From dmesg|grep sdhci, sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pci :0c:07.1: SDHCI controller found [1524:0750] (rev 0) sdhci-pci :0c:07.1: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: SDHCI controller found [1524:0751] (rev 0) sdhci-pci :0c:07.3: enabling device ( - 0002) sdhci-pci :0c:07.3: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: PCI INT A disabled sdhci-pci :0c:07.1: PCI INT A disabled sdhci-pci :0c:07.1: restoring config space at offset 0xf (was 0x482001ff, writing 0x48200105) sdhci-pci :0c:07.1: restoring config space at offset 0x4 (was 0x0, writing 0xf0f00400) sdhci-pci :0c:07.1: restoring config space at offset 0x3 (was 0x80, writing 0x802010) sdhci-pci :0c:07.1: restoring config space at offset 0x1 (was 0x210, writing 0x2100106) sdhci-pci :0c:07.3: restoring config space at offset 0x4 (was 0x0, writing 0xf0f00100) sdhci-pci :0c:07.3: restoring config space at offset 0x1 (was 0x210, writing 0x212) sdhci-pci :0c:07.1: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: PCI INT A disabled sdhci-pci :0c:07.1: PCI INT A disabled sdhci-pci :0c:07.1: restoring config space at offset 0xf (was 0x482001ff, writing 0x48200105) sdhci-pci :0c:07.1: restoring config space at offset 0x4 (was 0x0, writing 0xf0f00400) sdhci-pci :0c:07.1: restoring config space at offset 0x3 (was 0x80, writing 0x802010) sdhci-pci :0c:07.1: restoring config space at offset 0x1 (was 0x210, writing 0x2100106) sdhci-pci :0c:07.3: restoring config space at offset 0x4 (was 0x0, writing 0xf0f00100) sdhci-pci :0c:07.3: restoring config space at offset 0x1 (was 0x210, writing 0x212) sdhci-pci :0c:07.1: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: PCI INT A disabled sdhci-pci :0c:07.1: PCI INT A disabled sdhci-pci :0c:07.1: restoring config space at offset 0xf (was 0x482001ff, writing 0x48200105) sdhci-pci :0c:07.1: restoring config space at offset 0x4 (was 0x0, writing 0xf0f00400) sdhci-pci :0c:07.1: restoring config space at offset 0x3 (was 0x80, writing 0x802010) sdhci-pci :0c:07.1: restoring config space at offset 0x1 (was 0x210, writing 0x2100106) sdhci-pci :0c:07.3: restoring config space at offset 0x4 (was 0x0, writing 0xf0f00100) sdhci-pci :0c:07.3: restoring config space at offset 0x1 (was 0x210, writing 0x212) sdhci-pci :0c:07.1: PCI INT A - GSI 16 (level, low) - IRQ 16 sdhci-pci :0c:07.3: PCI INT A - GSI 16 (level, low) - IRQ 16 and finally dmesg|grep mmc: sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray Registered led device: mmc0:: mmc0: SDHCI controller on PCI [:0c:07.1] using PIO Registered led device: mmc1:: mmc1: SDHCI controller on PCI [:0c:07.3] using PIO mmc1: new high speed SDHC card at address 0007 mmcblk0: mmc1:0007 SD16G 15.0 GiB mmcblk0: p1 SELinux: initialized (dev mmcblk0p1, type vfat), uses genfs_contexts mmc1: card 0007 removed -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sdhci-pltfm: Do not print errors in case of an extended iomem size
On Wed, 17 Mar 2010 07:02:52 +0100 Richard R__jfors richard.rojf...@pelagicore.com wrote: On 3/16/10 7:34 PM, Anton Vorontsov wrote: Some hosts have an extended SDHCI iomem size, so the driver should only print errors if the iomem size is less than 0x100. With this change you allow a bigger resource than we really need. I think you should also change request_mem_region and ioremap to only request and map the actual needed size. (0x100) I merged these three with a note-to-self that some updates are expected (hint). -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] davinci: MMC: updates to suspend/resume implementation
On Tue, 16 Mar 2010 13:30:25 -0700
Kevin Hilman khil...@deeprootsystems.com wrote:
+static struct dev_pm_ops davinci_mmcsd_pm = {
+ .suspend= davinci_mmcsd_suspend,
+ .resume = davinci_mmcsd_resume,
+};
checkpatch said
WARNING: struct dev_pm_ops should normally be const
#83: FILE: drivers/mmc/host/davinci_mmc.c:1379:
+static struct dev_pm_ops davinci_mmcsd_pm = {
I'll make that change. Please check.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: fix incorrect interpretation of card type bits
On Fri, 19 Mar 2010 08:24:56 +0200 Adrian Hunter adrian.hun...@nokia.com wrote: From: Adrian Hunter adrian.hun...@nokia.com Date: Fri, 19 Mar 2010 08:06:54 +0200 Subject: [PATCH] mmc: fix incorrect interpretation of card type bits In the extended CSD register the CARD_TYPE is an 8-bit value of which the upper 6 bits were reserved in JEDEC specifications prior to version 4.4. In version 4.4 two of the reserved bits were designated for identifying support for the newly added High-Speed Dual Data Rate. Unfortunately the mmc_read_ext_csd() function required that the reserved bits be zero instead of ignoring them as it should. This patch makes mmc_read_ext_csd() ignore the CARD_TYPE bits that are reserved or not yet supported. It also stops the function jumping to the end as though an error occurred, when it is only warns that the CARD_TYPE bits (that it does interpret) are invalid. I need to whine about the changelog again. I'm guessing that the effect here is that if someone puts one of these new cards into an old kernel, this card will be incorrectly handled. Perhaps in ways which render the whole thing useless. If that was a good guess then this patch would be needed in earlier kernels too. But it was only a guess, and I'd prefer not to have to guess. So please do remember to explain things like this in the changelog? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] davinci: MMC: Pass number of SG segments as platform data
On Fri, 12 Mar 2010 18:04:09 +0530 Sudhakar Rajashekhara sudhakar@ti.com wrote: On some platforms like DM355, the number of EDMA parameter slots available for EDMA_SLOT_ANY usage are few. In such cases, if MMC/SD uses 16 slots for each instance of MMC controller, then the number of slots available for other modules will be very few. By passing the number of EDMA slots to be used in MMC driver from platform data, EDMA slots available for other purposes can be controlled. It's unclear what the runtime effects of this change are. I assumed (without justification) that they're minor and I scheduled the patch for 2.6.35. If that was the wrong decision then blame the changelog ;) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + sdio-recognize-io-card-without-powercycle.patch added to -mm tree
On Fri, 05 Mar 2010 23:25:54 +0100 Albert Herranz albert_herr...@yahoo.es wrote: a...@linux-foundation.org wrote: The patch titled sdio: recognize io card without powercycle has been added to the -mm tree. Its filename is sdio-recognize-io-card-without-powercycle.patch Sorry, disregard my previous message. I replied to the wrong mail. I meant _this_ patch: sdio-recognize-io-card-without-powercycle.patch So... Now yes :) Hi, Are there any objections to this patch? It's been in -mm now for nearly 6 months. AFAIK there's no report against it, and it fixes problems for at least 2 drivers: - the Nintendo Wii SDHCI controller (for which the patch was cooked) - the Silex's SX-SDWAG SDIO Wi-Fi card (http://marc.info/?l=linux-mmcm=126624571025203) I have a note here to check with Pierre, who said : I had problems with cards already in the idle state crashing when I : sent them a reset. I suggest a big round of testing before merging this. I guess there's no more testing we can do so I'll merge it? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] mmc: at91_mci: use DMA buffer for read
On Fri, 26 Feb 2010 19:39:32 +0100 Nicolas Ferre nicolas.fe...@atmel.com wrote: + kunmap_atomic(((void *)sgbuffer)-sg-offset, KM_BIO_SRC_IRQ); It's a feature of kunmap_atomic() that it will accept a pointer to any location in the page. So the subtraction isn't strictly needed. And if the subtraction is removed, the (void*) cast can also be removed. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mxcmmc: fixed max_seg_size value on initialization.
On Tue, 26 Jan 2010 14:40:04 +0300 Vladimir Zapolskiy vzapols...@gmail.com wrote: Signed-off-by: Vladimir Zapolskiy vzapols...@gmail.com Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Pierre Ossman pie...@ossman.eu --- drivers/mmc/host/mxcmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index 60a2b69..faa7b76 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -708,7 +708,7 @@ static int mxcmci_probe(struct platform_device *pdev) mmc-max_blk_size = 2048; mmc-max_blk_count = 65535; mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count; - mmc-max_seg_size = mmc-max_seg_size; + mmc-max_seg_size = mmc-max_req_size; host = mmc_priv(mmc); host-base = ioremap(r-start, resource_size(r)); Please don't send unchangelogged patches. I am not able to determine the user-visible impact of this bug hence I am not able to determine which kernel(s) we should merge this patch into. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tmio_mmc: keep card-detect interrupts enabled
On Tue, 16 Feb 2010 10:34:55 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On SuperH platforms the SDHI controller does not produce any command IRQs after a completed IO. This leads to card-detect interrupts staying disabled. Do not disable card-detect interrupts on DATA IRQs. Why is the current code disabling card-detect interrupts on DATA IRQs? Was that just a bug? What effect will this change have for current users of this driver? --- On Thu, 17 Dec 2009, Andrew Morton wrote: On Thu, 17 Dec 2009 21:25:52 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: I originally submitted this [1] patch on the 6th of November, then accidentally the MMC list got dropped from CC and the discussion moved to another irrelevant list, Ian's last reply is at [2]. Unfortunately, Ian hasn't replied to my reminders since then, and I don't see this patch anywhere upstream. Is there any way we could get it into 2.6.33? Please redo and retest it against curent mainline and do a full resend. Re-testing this patch has again become possible now, after Magnus has posted his INTC and the tmio_mmc: use 100ms mmc_detect_change() delay patches. Successfully tested on Migo-R (sh7722) and MS7724SE (sh7724). Andrew, please apply. drivers/mmc/host/tmio_mmc.h |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h index 692dc23..dafecfb 100644 --- a/drivers/mmc/host/tmio_mmc.h +++ b/drivers/mmc/host/tmio_mmc.h @@ -55,10 +55,8 @@ /* Define some IRQ masks */ /* This is the mask used at reset by the chip */ #define TMIO_MASK_ALL 0x837f031d -#define TMIO_MASK_READOP (TMIO_STAT_RXRDY | TMIO_STAT_DATAEND | \ - TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT) -#define TMIO_MASK_WRITEOP (TMIO_STAT_TXRQ | TMIO_STAT_DATAEND | \ - TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT) +#define TMIO_MASK_READOP (TMIO_STAT_RXRDY | TMIO_STAT_DATAEND) +#define TMIO_MASK_WRITEOP (TMIO_STAT_TXRQ | TMIO_STAT_DATAEND) #define TMIO_MASK_CMD (TMIO_STAT_CMDRESPEND | TMIO_STAT_CMDTIMEOUT | \ TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT) #define TMIO_MASK_IRQ (TMIO_MASK_READOP | TMIO_MASK_WRITEOP | TMIO_MASK_CMD) -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] SDIO: introduce API for special power management features
On Tue, 09 Feb 2010 15:29:22 -0500 Nicolas Pitre n...@fluxnic.net wrote: + BUG_ON(!func); + BUG_ON(!func-card); + + host = func-card-host; It's a bit redundant to check for null and then deref the pointer - the kernel will reliably oops on the NULL deref, which gives us the same info. I guess the BUG_ON is more useful in the case where a double-deref is being performed, as it can otherwise be a bit hard to work out which pointer was NULL. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: fix hang if card was removed during suspend and unsafe resume was enabled
On Fri, 05 Feb 2010 10:31:42 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Thu, 2010-02-04 at 16:09 -0800, Andrew Morton wrote: On Fri, 5 Feb 2010 01:18:15 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: Currently removal of the card leads to del_disk called indirectly by mmc core. This function expects userspace to be running, which isn't when .resume is called Fix that by removing the code that did that in mmc_resume_host. It is possible because card detection logic will kick it later and remove the card. I don't really understand. The above implies that to trigger this bug, one needs to physically remove the card during a resume operation. ie: a human-vs-computer race. Sounds unlikely? So... exactly what steps does the user need to take to trigger this Sorry for describing this poorly. The steps are: - Have a kernel with CONFIG_MMC_UNSAFE_RESUME - Insert MMC/SD card - Suspend/hibernate the system - While system is hibernated/suspended pull the card off - Resume the system - Hang if CONFIG_MMC_UNSAFE_RESUME is set, mmc core allows the user to suspend/resume the card normally assuming he won't change the card or modify it in another system. The former case is actually handled quite well. if CONFIG_MMC_UNSAFE_RESUME isn't set, it removes the card during suspend, and I now think (and will test) that this will still hang the system this time on suspend. Maybe we can make del_disk behave well if called with userspace frozen? After all if user calls it, very likely that hardware is absent thus there is no point in syncing (which I think triggers the hang) There is no del_disk in the kernel. Let's be more specific (and accurate!) about the hang. I assume it's mmc_remove_card-device_del-kobject_uevent? Yes, I'd have thought that it would be a good idea for the kobject_uevent code (or lower, in call_usermodehelper) to take avoiding action if userspace is frozen. However such action would probably involve doing a WARN_ON() too, so we'd still need MMC changes to avoid that. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: fix hang if card was removed during suspend and unsafe resume was enabled
On Fri, 05 Feb 2010 17:52:00 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: 4[15241.042047] [8106620a] ? prepare_to_wait+0x2a/0x90 4[15241.042159] [810790bd] ? trace_hardirqs_on+0xd/0x10 4[15241.042271] [8140db12] ? _raw_spin_unlock_irqrestore+0x42/0x80 4[15241.042386] [8112a390] ? bdi_sched_wait+0x0/0x20 4[15241.042496] [8112a39e] bdi_sched_wait+0xe/0x20 4[15241.042606] [8140af6f] __wait_on_bit+0x5f/0x90 4[15241.042714] [8112a390] ? bdi_sched_wait+0x0/0x20 4[15241.042824] [8140b018] out_of_line_wait_on_bit+0x78/0x90 4[15241.042935] [81065fd0] ? wake_bit_function+0x0/0x40 4[15241.043045] [8112a2d3] ? bdi_queue_work+0xa3/0xe0 4[15241.043155] [8112a37f] bdi_sync_writeback+0x6f/0x80 4[15241.043265] [8112a3d2] sync_inodes_sb+0x22/0x120 4[15241.043375] [8112f1d2] __sync_filesystem+0x82/0x90 4[15241.043485] [8112f3db] sync_filesystem+0x4b/0x70 4[15241.043594] [811391de] fsync_bdev+0x2e/0x60 4[15241.043704] [812226be] invalidate_partition+0x2e/0x50 4[15241.043816] [8116b92f] del_gendisk+0x3f/0x140 4[15241.043926] [a00c0233] mmc_blk_remove+0x33/0x60 [mmc_block] 4[15241.044043] [81338977] mmc_bus_remove+0x17/0x20 4[15241.044152] [812ce746] __device_release_driver+0x66/0xc0 4[15241.044264] [812ce89d] device_release_driver+0x2d/0x40 4[15241.044375] [812cd9b5] bus_remove_device+0xb5/0x120 4[15241.044486] [812cb46f] device_del+0x12f/0x1a0 4[15241.044593] [81338a5b] mmc_remove_card+0x5b/0x90 4[15241.044702] [8133ac27] mmc_sd_remove+0x27/0x50 4[15241.044811] [81337d8c] mmc_resume_host+0x10c/0x140 4[15241.044929] [a00850e9] sdhci_resume_host+0x69/0xa0 [sdhci] 4[15241.045044] [a0bdc39e] sdhci_pci_resume+0x8e/0xb0 [sdhci_pci] So what's the hang? del_gendisk is doing IO? I'd assumed that it was because it was calling kobject_uevent, but userspace is frozen. This is a backtrace of a hang. But why did it hang? Because the BDI worker threads are trying to perform IO through a suspended device? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: fix hang if card was removed during suspend and unsafe resume was enabled
On Fri, 5 Feb 2010 01:18:15 +0200 Maxim Levitsky maximlevit...@gmail.com
wrote:
Currently removal of the card leads to del_disk called indirectly by mmc core.
This function expects userspace to be running, which isn't when .resume is
called
Fix that by removing the code that did that in mmc_resume_host. It is possible
because card detection logic will kick it later and remove the card.
I don't really understand. The above implies that to trigger this bug,
one needs to physically remove the card during a resume operation. ie:
a human-vs-computer race. Sounds unlikely?
So... exactly what steps does the user need to take to trigger this
bug?
Also make mtd workqueue freezeable, so it won't attempt to add/remove the card
while userspace is frozen.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 30acd52..879d48d 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1257,7 +1257,6 @@ int mmc_suspend_host(struct mmc_host *host,
pm_message_t state)
if (host-caps MMC_CAP_DISABLE)
cancel_delayed_work(host-disable);
cancel_delayed_work(host-detect);
- mmc_flush_scheduled_work();
mmc_bus_get(host);
if (host-bus_ops !host-bus_dead) {
@@ -1300,15 +1299,11 @@ int mmc_resume_host(struct mmc_host *host)
mmc_select_voltage(host, host-ocr);
BUG_ON(!host-bus_ops-resume);
err = host-bus_ops-resume(host);
+
if (err) {
printk(KERN_WARNING %s: error %d during resume
(card was removed?)\n,
mmc_hostname(host), err);
- if (host-bus_ops-remove)
- host-bus_ops-remove(host);
- mmc_claim_host(host);
- mmc_detach_bus(host);
- mmc_release_host(host);
afacit that code's been there since March 2009. I'd have thought that
someone would have noticed kernel hangs on resume before now.
Do you think the patch should be backported into 2.6.32.x and eariler?
/* no need to bother upper layers */
err = 0;
}
@@ -1332,7 +1327,7 @@ static int __init mmc_init(void)
{
int ret;
- workqueue = create_singlethread_workqueue(kmmcd);
+ workqueue = create_freezeable_workqueue(kmmcd);
if (!workqueue)
return -ENOMEM;
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-Resend] mmc_test: block addressed cards
On Mon, 1 Feb 2010 13:04:55 +0100 Johan Kristell johan.krist...@axis.com wrote: The tests in mmc_test assumes that all cards are byte addressable. This patch updates the tests to also work with cards that use block addresses. When fixing a bug, please decribe the bug! Otherwise it's hard for others (ie: me) to work out the severity of the bug and hence the urgency of the fix. From the above info, I'm unable to decide whether this fix is needed in 2.6.33 or 2.6.32. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: bfin_sdh: set timeout based on actual card data
On Tue, 19 Jan 2010 03:02:11 -0500 Mike Frysinger vap...@gentoo.org wrote: From: Cliff Cai cliff@analog.com The hardcoded value doesn't really work for all cards. Signed-off-by: Cliff Cai cliff@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org Please don't write crappy changelogs. How am I to determine whether we want this fix in 2.6.33 and possibly earlier? How is anyone whose 2.6.32.x kernel doesn't really work to determine whether this patch might fix it? -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] port ricoh_mmc to be pci quirk
(cc linux-mmc) On Fri, 8 Jan 2010 07:40:01 -0800 Philip Langdale phil...@overt.org wrote: On Fri, 08 Jan 2010 17:24:44 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Thu, 2009-11-26 at 23:55 -0800, Philip Langdale wrote: On Fri, 27 Nov 2009 01:53:04 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: From 2d3002e29c329d76ca4e26d9f427814151a9648c Mon Sep 17 00:00:00 2001 From: Maxim Levitsky maximlevit...@gmail.com Date: Fri, 27 Nov 2009 00:53:28 +0200 Subject: [PATCH] port ricoh_mmc to be pci quirk This patch solves nasty problem original driver has. Original goal of the ricoh_mmc was to disable this device because then, mmc cards can be read using standard SDHCI controller, thus avoiding writing of yet another driver. However, the act of disablement, makes other pci functions that belong to this controller (xD and memstick) shift up one level, thus pci core has now wrong idea about these devices. To fix this issue, this patch moves the driver into pci quirk section, thus it is executes before the pci is enumerated, and therefore solving that issue, also same sequence of commands is performed on resume for same reasons. Also regardless of the above, this way is cleaner. You still need to set CONFIG_MMC_RICOH_MMC to enable this quirk I like it. Only comment is that I'd like the printks to identify which controller is involved. If Andrew is happy with the CONFIG mechanism, then you've got an ack from me. Thanks for doing this. Hi, do you plan to include this patch in the kernel? That's Andrew's call, but to the extent that my opinion matters, I support it being included. I have a note here that Pierre had issues with the patch. I'm uncertain whether those are now resolved? From: Maxim Levitsky maximlevit...@gmail.com This patch solves nasty problem original driver has. Original goal of the ricoh_mmc was to disable this device because then, mmc cards can be read using standard SDHCI controller, thus avoiding writing of yet another driver. However, the act of disablement, makes other pci functions that belong to this controller (xD and memstick) shift up one level, thus pci core has now wrong idea about these devices. To fix this issue, this patch moves the driver into the pci quirk section, thus it is executes before the pci is enumerated, and therefore solving that issue, also same sequence of commands is performed on resume for same reasons. Also regardless of the above, this way is cleaner. You still need to set CONFIG_MMC_RICOH_MMC to enable this quirk Signed-off-by: Maxim Levitsky maximlevit...@gmail.com Cc: Philip Langdale phil...@overt.org Cc: linux-mmc@vger.kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/mmc/host/Kconfig | 10 - drivers/mmc/host/Makefile|1 drivers/mmc/host/ricoh_mmc.c | 262 - drivers/pci/quirks.c | 92 +++ 4 files changed, 95 insertions(+), 270 deletions(-) diff -puN drivers/mmc/host/Kconfig~ricoh_mmc-port-from-driver-to-pci-quirk drivers/mmc/host/Kconfig --- a/drivers/mmc/host/Kconfig~ricoh_mmc-port-from-driver-to-pci-quirk +++ a/drivers/mmc/host/Kconfig @@ -69,20 +69,16 @@ config MMC_SDHCI_PCI If unsure, say N. config MMC_RICOH_MMC - tristate Ricoh MMC Controller Disabler (EXPERIMENTAL) + bool Ricoh MMC Controller Disabler (EXPERIMENTAL) depends on MMC_SDHCI_PCI help - This selects the disabler for the Ricoh MMC Controller. This + This adds a pci quirk to disable Ricoh MMC Controller. This proprietary controller is unnecessary because the SDHCI driver supports MMC cards on the SD controller, but if it is not disabled, it will steal the MMC cards away - rendering them - useless. It is safe to select this driver even if you don't + useless. It is safe to select this even if you don't have a Ricoh based card reader. - - To compile this driver as a module, choose M here: - the module will be called ricoh_mmc. - If unsure, say Y. config MMC_SDHCI_OF diff -puN drivers/mmc/host/Makefile~ricoh_mmc-port-from-driver-to-pci-quirk drivers/mmc/host/Makefile --- a/drivers/mmc/host/Makefile~ricoh_mmc-port-from-driver-to-pci-quirk +++ a/drivers/mmc/host/Makefile @@ -12,7 +12,6 @@ obj-$(CONFIG_MMC_IMX) += imxmmc.o obj-$(CONFIG_MMC_MXC) += mxcmmc.o obj-$(CONFIG_MMC_SDHCI)+= sdhci.o obj-$(CONFIG_MMC_SDHCI_PCI)+= sdhci-pci.o -obj-$(CONFIG_MMC_RICOH_MMC)+= ricoh_mmc.o obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o obj-$(CONFIG_MMC_SDHCI_S3C)+= sdhci-s3c.o obj-$(CONFIG_MMC_WBSD) += wbsd.o diff -puN drivers/mmc/host/ricoh_mmc.c~ricoh_mmc-port-from-driver-to-pci-quirk /dev/null --- a/drivers/mmc/host/ricoh_mmc.c +++ /dev/null @@ -1,262
Re: [Bugme-new] [Bug 14983] New: SD card reader stopped working completely
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 4 Jan 2010 10:22:53 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=14983 Summary: SD card reader stopped working completely Product: Drivers Version: 2.5 Kernel Version: 2.6.30 trough 2.6.32 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: MMC/SD AssignedTo: drivers_mmc...@kernel-bugs.osdl.org ReportedBy: peter.kr...@geeksonbikes.net CC: peter.kr...@geeksonbikes.net Regression: Yes Created an attachment (id=24428) -- (http://bugzilla.kernel.org/attachment.cgi?id=24428) working 2.6.29 kernel config Hello. My Ricoh card reader, which used to work absolutely fine, stopped working in newer kernels. - it works with kernel 2.6.29 This is a regression. There's additional info at the bugzilla link. Could someone please work with Peter on this? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc_block: fix queue cleanup
On Fri, 18 Dec 2009 14:15:48 +0200 Adrian Hunter adrian.hun...@nokia.com wrote: The main bug was that 'blk_cleanup_queue()' was called while the block device could still be in use, for example, because the card was removed while files were still open. In addition, to be sure that 'mmc_request()' will get called for all new requests (so it can error them out), the queue is emptied during cleanup. This is done after the worker thread is stopped to avoid racing with it. Finally, it is not a device error for this to be happening, so quiet the (sometimes very many) error messages. What nice changelogs. Thanks, I tagged all three patches for a 2.6.32.x backport. They do appear to be applicable to 2.6.31 and perhaps earlier, also. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: allow for MMC v4.4
On Fri, 18 Dec 2009 14:25:33 +0200 Adrian Hunter adrian.hun...@nokia.com wrote: JEDEC eMMC specification version 4.4 (MMCA 4.4) defines Extended CSD structure versions up to 5. Not such a nice changelog. It doesn't describe the effects of the current code's shortcoming so I was unable to decide whether to recommend that this patch be backported. -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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] tmio_mmc: keep card-detect interrupts enabled
On Thu, 17 Dec 2009 21:25:52 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: I originally submitted this [1] patch on the 6th of November, then accidentally the MMC list got dropped from CC and the discussion moved to another irrelevant list, Ian's last reply is at [2]. Unfortunately, Ian hasn't replied to my reminders since then, and I don't see this patch anywhere upstream. Is there any way we could get it into 2.6.33? Please redo and retest it against curent mainline and do a full resend. -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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][mmc/host]:Blackfin SD Host Controller Driver
On Wed, 25 Nov 2009 23:19:50 +0800
cliffcai...@gmail.com wrote:
From: Cliff Cai cliffcai...@gmail.com
Add SD host driver for Blackfin BF54x and BF51x.
Signed-off-by: Cliff Cai cliffcai...@gmail.com
Signed-off-by: Bryan Wu coolo...@kernel.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
...
+config SDH_BFIN
+tristate Blackfin Secure Digital Host support
+depends on MMC ((BF54x !BF544) || (BF51x !BF512))
+help
+ If you say yes here you will get support for the Blackfin on-chip
+ Secure Digital Host interface. This includes support for MMC and
+ SD cards.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bfin_sdh.
+
+ If unsure, say N.
+
+config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND
+bool Blackfin EZkit Missing SDH_CMD Pull Up Resistor Workaround
+depends on SDH_BFIN
+help
+ If you say yes here SD-Cards may work on the EZkit.
Indenting is all mangled.
...
+struct dma_desc_array {
+ unsigned long start_addr;
+ unsigned short cfg;
+ unsigned short x_count;
+ short x_modify;
+} __attribute__((packed));
__packed is preferred.
+struct sdh_host {
+ struct mmc_host *mmc;
+ spinlock_t lock;
+ struct resource *res;
+ void __iomem*base;
+ int irq;
+ int stat_irq;
+ int dma_ch;
+ int dma_dir;
+ struct dma_desc_array *sg_cpu;
+ dma_addr_t sg_dma;
+ int dma_len;
+
+ unsigned intimask;
+ unsigned intpower_mode;
+ unsigned intclk_div;
+
+ struct mmc_request *mrq;
+ struct mmc_command *cmd;
+ struct mmc_data *data;
+};
...
+static int sdh_setup_data(struct sdh_host *host, struct mmc_data *data)
+{
+ unsigned int length;
+ unsigned int data_ctl;
+ unsigned int dma_cfg;
+ struct scatterlist *sg;
+
+ dev_dbg(mmc_dev(host-mmc), %s enter flags: 0x%x\n, __func__,
data-flags);
+ host-data = data;
+ data_ctl = 0;
+ dma_cfg = 0;
+
+ length = data-blksz * data-blocks;
+ bfin_write_SDH_DATA_LGTH(length);
+
+ if (data-flags MMC_DATA_STREAM)
+ data_ctl |= DTX_MODE;
+
+ if (data-flags MMC_DATA_READ)
+ data_ctl |= DTX_DIR;
+ /* Only supports power-of-2 block size */
+ if (data-blksz (data-blksz - 1))
+ return -EINVAL;
+ data_ctl |= ((ffs(data-blksz) - 1) 4);
+
+ bfin_write_SDH_DATA_CTL(data_ctl);
+
+ bfin_write_SDH_DATA_TIMER(0x);
+ SSYNC();
+
+ if (data-flags MMC_DATA_READ) {
+ host-dma_dir = DMA_FROM_DEVICE;
+ dma_cfg |= WNR;
+ } else
+ host-dma_dir = DMA_TO_DEVICE;
+
+ sdh_enable_stat_irq(host, (DAT_CRC_FAIL | DAT_TIME_OUT | DAT_END));
+ host-dma_len = dma_map_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
host-dma_dir);
+#if defined(CONFIG_BF54x)
+ int i;
This is going to generate a compiler warning. We don't use the c99
declaration form in kernel code.
+ dma_cfg |= DMAFLOW_ARRAY | NDSIZE_5 | RESTART | WDSIZE_32 | DMAEN;
+ for_each_sg(data-sg, sg, host-dma_len, i) {
+ host-sg_cpu[i].start_addr = sg_dma_address(sg);
+ host-sg_cpu[i].cfg = dma_cfg;
+ host-sg_cpu[i].x_count = sg_dma_len(sg) / 4;
+ host-sg_cpu[i].x_modify = 4;
+ dev_dbg(mmc_dev(host-mmc), %d: start_addr:0x%lx, cfg:0x%x,
x_count:0x%x,\
+ x_modify:0x%x\n, i, host-sg_cpu[i].start_addr,
+ host-sg_cpu[i].cfg, host-sg_cpu[i].x_count,
+ host-sg_cpu[i].x_modify);
+ }
+ flush_dcache_range((unsigned int)host-sg_cpu,
+ (unsigned int)host-sg_cpu +
+ host-dma_len * sizeof(struct dma_desc_array));
+ /* Set the last descriptor to stop mode */
+ host-sg_cpu[host-dma_len - 1].cfg = ~(DMAFLOW | NDSIZE);
+ host-sg_cpu[host-dma_len - 1].cfg |= DI_EN;
+
+ set_dma_curr_desc_addr(host-dma_ch, (unsigned long *)host-sg_dma);
+ set_dma_x_count(host-dma_ch, 0);
+ set_dma_x_modify(host-dma_ch, 0);
+ set_dma_config(host-dma_ch, dma_cfg);
+#elif defined(CONFIG_BF51x)
+ /* RSI DMA doesn't work in array mode */
+ dma_cfg |= WDSIZE_32 | DMAEN;
+ set_dma_start_addr(host-dma_ch, sg_dma_address(data-sg[0]));
+ set_dma_x_count(host-dma_ch, length / 4);
+ set_dma_x_modify(host-dma_ch, 4);
+ set_dma_config(host-dma_ch, dma_cfg);
+#endif
+ bfin_write_SDH_DATA_CTL(bfin_read_SDH_DATA_CTL() | DTX_DMA_E | DTX_E);
+
+ SSYNC();
+
+ dev_dbg(mmc_dev(host-mmc), %s exit\n, __func__);
+ return 0;
+}
+
+static void sdh_start_cmd(struct sdh_host
Re: [PATCH] mmc: add module parameter to set whether cards are assumed removable
On Wed, 11 Nov 2009 04:44:36 + Ben Hutchings b...@decadent.org.uk wrote: Some people run general-purpose distribution kernels on netbooks with a card that is physically non-removable or logically non-removable (e.g. used for /home) and cannot be cleanly unmounted during suspend. Add a module parameter to set whether cards are assumed removable or non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME. The description really doesn't give me enough info to work out what's happening here and why this is being proposed. But it smells nasty. index ab37a6d..bb22ffd 100644 --- a/drivers/mmc/core/Kconfig +++ b/drivers/mmc/core/Kconfig @@ -3,7 +3,7 @@ # config MMC_UNSAFE_RESUME - bool Allow unsafe resume (DANGEROUS) + bool Assume MMC/SD cards are non-removable (DANGEROUS) help If you say Y here, the MMC layer will assume that all cards stayed in their respective slots during the suspend. The @@ -14,3 +14,5 @@ config MMC_UNSAFE_RESUME This option is usually just for embedded systems which use a MMC/SD card for rootfs. Most people should say N here. + This option sets a default which can be overridden by the + module parameter removable=0 or removable=1. diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index d98b0e2..010c964 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -48,6 +48,22 @@ int use_spi_crc = 1; module_param(use_spi_crc, bool, 0); /* + * We normally treat cards as removed during suspend if they are not + * known to be on a non-removable bus, to avoid the risk of writing + * back data to a different card after resume. Allow this to be + * overridden if necessary. + */ So we have a module parameter which nobody knows about. If they don't set this parameter which they don't know about, the kernel will trash their filesystem?? +#ifdef CONFIG_MMC_UNSAFE_RESUME +int mmc_assume_removable; +#else +int mmc_assume_removable = 1; +#endif +module_param_named(removable, mmc_assume_removable, bool, 0644); +MODULE_PARM_DESC( + removable, + MMC/SD cards are removable and may be removed during suspend); + -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TMIO MMC: full patchset.
On Thu, 1 Oct 2009 10:30:42 +0900 Magnus Damm magnus.d...@gmail.com wrote: Any chance we can get at least the ian-0001 patch and the kconfig bit merged in 2.6.32-rc? wakes up Please flag the proposed merge plans clearly in the description when you send out the patch series and lets take a look at it then. I don't need much reason to shove stuff into -rc2, but it's nice to have _some_ reason ;) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] atmel-mci: change use of dma slave interface
On Thu, 17 Sep 2009 18:29:26 +0200
Nicolas Ferre nicolas.fe...@atmel.com wrote:
Allow the use of another DMA controller driver in atmel-mci sd/mmc driver.
This
adds a generic dma_slave pointer to the mci platform structure where we can
store DMA controller information. In atmel-mci we use information provided by
this structure to initialize the driver (with new helper functions that are
architecture dependant).
This also adds at32/avr32 chip modifications to cope with this new access
method.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/avr32/mach-at32ap/at32ap700x.c |6 ++-
drivers/mmc/host/atmel-mci.c| 82
++-
include/linux/atmel-mci.h |3 +-
3 files changed, 68 insertions(+), 23 deletions(-)
diff --git a/arch/avr32/mach-at32ap/at32ap700x.c
b/arch/avr32/mach-at32ap/at32ap700x.c
index eb9d4dc..d1fe145 100644
--- a/arch/avr32/mach-at32ap/at32ap700x.c
+++ b/arch/avr32/mach-at32ap/at32ap700x.c
@@ -1320,7 +1320,7 @@ struct platform_device *__init
at32_add_device_mci(unsigned int id, struct mci_platform_data *data)
{
struct platform_device *pdev;
- struct dw_dma_slave *dws = data-dma_slave;
+ struct dw_dma_slave *dws;
u32 pioa_mask;
u32 piob_mask;
@@ -1339,6 +1339,8 @@ at32_add_device_mci(unsigned int id, struct
mci_platform_data *data)
ARRAY_SIZE(atmel_mci0_resource)))
goto fail;
+ dws = kzalloc(sizeof(struct dw_dma_slave), GFP_KERNEL);
I don't see anywhere where this gets freed again?
dws-dma_dev = dw_dmac0_device.dev;
dws-reg_width = DW_DMA_SLAVE_WIDTH_32BIT;
dws-cfg_hi = (DWC_CFGH_SRC_PER(0)
@@ -1346,6 +1348,8 @@ at32_add_device_mci(unsigned int id, struct
mci_platform_data *data)
dws-cfg_lo = ~(DWC_CFGL_HS_DST_POL
| DWC_CFGL_HS_SRC_POL);
+ data-dma_slave = dws;
+
if (platform_device_add_data(pdev, data,
sizeof(struct mci_platform_data)))
goto fail;
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 065fa81..1689396 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -1575,16 +1575,71 @@ static void __exit atmci_cleanup_slot(struct
atmel_mci_slot *slot,
}
#ifdef CONFIG_MMC_ATMELMCI_DMA
-static bool filter(struct dma_chan *chan, void *slave)
+static struct device *find_slave_dev(void *slave)
+{
+ if (!slave)
+ return NULL;
+
+ if (cpu_is_at32ap7000())
+ return ((struct dw_dma_slave *)slave)-dma_dev;
+ else
+ return ((struct at_dma_slave *)slave)-dma_dev;
+}
Quite a few unsafeish typecasts here.
struct mci_platform_data {
- struct dw_dma_slave dma_slave;
+ void*dma_slave;
struct mci_slot_pdata slot[ATMEL_MCI_MAX_NR_SLOTS];
};
I think the code would come out better if this has type dw_dma_slave*.
You'll still need typecasts to support the dma_request_channel()
callback, but the code will be safer and cleaner, I expect.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
