Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751391AbaKFV0a (ORCPT ); Thu, 6 Nov 2014 16:26:30 -0500 Received: from mail-1.atlantis.sk ([80.94.52.57]:50694 "EHLO mail-1.atlantis.sk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751051AbaKFV02 (ORCPT ); Thu, 6 Nov 2014 16:26:28 -0500 From: Ondrej Zary To: Ulf Hansson Subject: Re: [PATCH v2] [RESEND] mmc: add Toshiba PCI SD controller driver Date: Thu, 6 Nov 2014 22:25:56 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) Cc: "linux-mmc" , Kernel development list References: <1414965074-4784-1-git-send-email-linux@rainbow-software.org> <201411042241.45125.linux@rainbow-software.org> <201411060002.25257.linux@rainbow-software.org> In-Reply-To: <201411060002.25257.linux@rainbow-software.org> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201411062225.56556.linux@rainbow-software.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 06 November 2014 00:02:24 Ondrej Zary wrote: > On Tuesday 04 November 2014 22:41:44 Ondrej Zary wrote: > > On Tuesday 04 November 2014 12:09:44 Ulf Hansson wrote: > > > On 2 November 2014 22:51, Ondrej Zary wrote: > > > > This patch resurrects an old never-finished driver for Toshiba PCI SD > > > > controllers found in some older Toshiba laptops (such as Portege R100): > > > > > > > > 02:0d.0 System peripheral [0880]: Toshiba America Info Systems SD TypA Controller [1179:0805] (rev 05) > > > > > > > > The code is fixed, cleaned up and successfully tested with SD, SDHC, SDXC and > > > > MMC cards on Portege R100. (MMC cards don't even work in Windows!) > > > > SDIO probably does not work (don't have any SDIO card). > > > > > > > > The hardware is slow (around 2 MB/s - same in Windows) because it does not > > > > support bus mastering (busmaster enable bit cannot be set in PCI control reg). > > > > Also the card clock is limited to 16MHz (33MHz PCI clock divided by 2). > > > > > > > > Signed-off-by: Ondrej Zary > > > > > > Hi Ondrej, > > > > > > Sorry for a very very late reply. > > > > > > > ... > > > > > > +static void toshsd_init(struct toshsd_host *host); > > > > +static void toshsd_set_ios_unlocked(struct mmc_host *mmc, struct mmc_ios *ios); > > > > > > I would implement these functions at the proper place instead of > > > having them defined here. > > > > > > Moreover I think toshsd_set_ios_unlocked() could be renamed to > > > "__toshsd_set_ios()". > > > > OK, will do. > > > > > > + > > > > +static inline u16 toshsd_readw(struct toshsd_host *host, u16 reg) > > > > +{ > > > > + return ioread16(host->ioaddr + reg); > > > > +} > > > > + > > > > +static inline u32 toshsd_readl(struct toshsd_host *host, u16 reg) > > > > +{ > > > > + return ioread32(host->ioaddr + reg); > > > > +} > > > > + > > > > +static inline void toshsd_writew(struct toshsd_host *host, u16 reg, u16 val) > > > > +{ > > > > + iowrite16(val, host->ioaddr + reg); > > > > +} > > > > + > > > > +static inline void toshsd_writel(struct toshsd_host *host, u16 reg, u32 val) > > > > +{ > > > > + iowrite32(val, host->ioaddr + reg); > > > > +} > > > > + > > > > +static inline void toshsd_readl_rep(struct toshsd_host *host, u16 reg, > > > > + void *dst, unsigned long count) > > > > +{ > > > > + ioread32_rep(host->ioaddr + reg, dst, count); > > > > +} > > > > + > > > > +static inline void toshsd_writel_rep(struct toshsd_host *host, u16 reg, > > > > + const void *src, unsigned long count) > > > > +{ > > > > + iowrite32_rep(host->ioaddr + reg, src, count); > > > > +} > > > > > > To me, all these wrapper functions seems a bit ugly. How about > > > invoking io* functions directly instead? > > > > It's a matter of preference, some drivers use wrappers, some don't. > > I can remove them if they're not recommended in mmc subsystem. > > > > ... > > > > > > + tasklet_schedule(&host->data_read_tasklet); > > > > > > Instead of using a tasklet, I would advise to use a threaded IRQ. > > > > Haven't used threaded IRQ yet, will try. > > > > ... > > > > > > +#ifdef CONFIG_PM > > > > > > This should be CONFIG_PM_SLEEP. > > > > > > > + > > > > +static int toshsd_suspend(struct pci_dev *pdev, pm_message_t state) > > > > > > This is the legacy version of system PM callbacks. You need to convert > > > to the modern ones instead. > > > > > > > +{ > > > > + struct toshsd_host *host = pci_get_drvdata(pdev); > > > > + > > > > + toshsd_powerdown(host); > > > > + > > > > + pci_save_state(pdev); > > > > + pci_enable_wake(pdev, pci_choose_state(pdev, state), 0); > > > > + pci_disable_device(pdev); > > > > + pci_set_power_state(pdev, pci_choose_state(pdev, state)); > > > > + > > > > + return 0; > > > > +} > > > > + > > > > +static int toshsd_resume(struct pci_dev *pdev) > > > > > > This is the legacy version of system PM callbacks. You need to convert > > > to the modern ones instead. > > > > I just converted them and found that suspend does not work on current kernels > > when a SD card is inserted (even with unmodified toshsd driver): > > [ 188.960862] dpm_run_callback(): mmc_bus_suspend+0x0/0x2c [mmc_core] returns -110 > > [ 188.960867] PM: Device mmc0:b368 failed to suspend: error -110 > > [ 188.960869] PM: Some devices failed to suspend, or early wake event detected > > > > Is it a kernel bug or the driver is missing something? > > > > The same kernel with sdhci-pci works fine (on another HW) so the problem is > limited only to toshsd... > Seems that the MMC core is trying to do something with the card and it fails > with timeout: > [ 885.750001] PM: Entering mem sleep > [ 885.750023] Suspending console(s) (use no_console_suspend to debug) > [ 885.750281] Command opcode: 7 > [ 885.750432] timeout!!!!! > [ 885.750453] Command opcode: 7 > [ 885.750597] timeout!!!!! > [ 885.750615] Command opcode: 7 > [ 885.750758] timeout!!!!! > [ 885.750776] Command opcode: 7 > [ 885.750920] timeout!!!!! > [ 885.750956] dpm_run_callback(): mmc_bus_suspend+0x0/0x2c [mmc_core] returns -110 > [ 885.750961] PM: Device mmc0:0007 failed to suspend: error -110 > Found a bug in the header file, probably causing all no-response commands to fail: #define SD_CMD_RESP_TYPE_NORMAL (0 << 8) Both the name and value were wrong, it should be: #define SD_CMD_RESP_TYPE_NONE (3 << 8) Older kernels were probably not sending MMC_SELECT_CARD on suspend. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/