Re: [mmc:mmc-next 5/29] drivers/mmc/core/slot-gpio.c:123:2: error: implicit declaration of function 'devm_gpio_request_one'

On Tue, Jan 15, 2013 at 05:45:53AM +0800, kbuild test robot wrote: > tree: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git mmc-next > head: e35219140bbf0b6efcd8feb93fa6e9cb2df5bc08 > commit: 8733ba654cd9ad0396ac081b4858bfa0a29c5519 [5/29] mmc: slot-gpio: use > devm_* managed function

Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT

On Fri, Jan 11, 2013 at 09:03:54AM -0800, Doug Anderson wrote: > The original quirk was added in the change 'mmc: dw_mmc: add quirk to > indicate missing write protect line'. The original quirk was added at > a controller level even though each slot has its own write protect (so > the quirk should

Re: [PATCH v4 4/5] mmc: dw_mmc: Handle wp-gpios from device tree

On Fri, Jan 11, 2013 at 09:03:53AM -0800, Doug Anderson wrote: > On some SoCs (like exynos5250) you need to use an external GPIO for > write protect. Add support for wp-gpios to the core dw_mmc driver > since it could be useful across multiple SoCs. > > With this change I am able to make use of t

Re: [PATCH v4 2/5] ARM: dts: Add disable-wp for sd card slot on smdk5250

On Fri, Jan 11, 2013 at 09:03:51AM -0800, Doug Anderson wrote: > The next change will remove the code from the dw_mmc-exynos that added > the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of > having no write protect pin on smdk5250 by adding the disable-wp > property. > > Signed-off

Re: [PATCH v4 3/5] mmc: dw_mmc: exynos: Remove code for wp-gpios

On Fri, Jan 11, 2013 at 09:03:52AM -0800, Doug Anderson wrote: > The exynos code claimed the write protect with devm_gpio_request() but > never did anything with it. That meant that anyone using a write > protect GPIO would effectively be write protected all the time. > > The handling for wp-gpio

Re: [PATCH v4 1/5] mmc: dw_mmc: Add "disable-wp" device tree property

On Fri, Jan 11, 2013 at 09:03:50AM -0800, Doug Anderson wrote: > The "disable-wp" property is used to specify that a given SD card slot > doesn't have a concept of write protect. This eliminates the need for > special case code for SD slots that should never be write protected > (like a micro SD s

Re: [RFC PATCH] MAINTAINERS: Add an orphaned entry for the dw_mmc driver.

Hi All, I have interesting to maintain "dw_mmc" driver. Best Regards, Jaehoon Chung On 01/12/2013 02:31 AM, Chris Ball wrote: > Hi, > > On Fri, Jan 11 2013, Will Newton wrote: >> I submitted this driver but will shortly no longer have access >> to hardware that uses it. The driver is quite wide

RE: [mmc:mmc-next 45/63] of_iommu.c:(.text+0x114dbc): undefined reference to `__aeabi_uldivmod'

Hi, chris Could you please help review these patches again? Expect your comments. Thanks in advance. Regards Haijun. > -Original Message- > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > ow...@vger.kernel.org] On Behalf Of Zhang Haijun-B42677 > Sent: Friday, December 14, 2

[mmc:mmc-next 5/29] drivers/mmc/core/slot-gpio.c:123:2: error: implicit declaration of function 'devm_gpio_request_one'

tree: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git mmc-next head: e35219140bbf0b6efcd8feb93fa6e9cb2df5bc08 commit: 8733ba654cd9ad0396ac081b4858bfa0a29c5519 [5/29] mmc: slot-gpio: use devm_* managed functions to ease users config: make ARCH=blackfin TCM-BF537_defconfig All error/w

Re: [PATCH] mmc: sdhci: introduce sdhci_update_clock helper to re-enable clock

Hi, On Mon, Jan 07 2013, Andy Shevchenko wrote: > There are three places where same piece of code is used. Let's split it to a > separate function. > > Signed-off-by: Andy Shevchenko Thanks, pushed to mmc-next for 3.9. - Chris. -- Chris Ball One Laptop Per Child -- To

Re: [PATCH v2 2/2] mmc: sdhci-pxav3: add wake up support

Hi, On Sat, Jan 05 2013, Kevin Liu wrote: > Signed-off-by: Jialing Fu > Signed-off-by: Kevin Liu > --- > drivers/mmc/host/sdhci-pxav3.c |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c > index b4a

Re: [PATCH v2 1/2] mmc: sdhci: add wake up support

Hi, On Sat, Jan 05 2013, Kevin Liu wrote: > Not to disable SD Host IRQ during suspend if it is wake up source. > Enable wakeup event during suspend. > > Signed-off-by: Jialing Fu > Signed-off-by: Kevin Liu Thanks, pushed to mmc-next for 3.9. - Chris. -- Chris Ball On

Re: [PATCH] mmc: sdhci: disable interrupt before free_irq

Hi, On Sat, Jan 05 2013, Kevin Liu wrote: > Current code missed disabling interrupts before free irq which is shared. > > Notice below comments for function free_irq (kernel/irq/manage.c): > On a shared IRQ the caller must ensure the interrupt is disabled > on the card it drives before calling thi

Re: [PATCH] mmc: add BCM2835 driver

Hi Stephen, On Thu, Jan 03 2013, Stephen Warren wrote: > Add a very simple driver for the BCM2835 SoC, which is used in the > Raspberry Pi board. > > Signed-off-by: Stephen Warren Looks good, thanks -- pushed to mmc-next for 3.9. - Chris. -- Chris Ball One Laptop Per

Re: [PATCH v5] mmc: fix async request mechanism for sequential read scenarios

Hi Konstantin, On Fri, Dec 28 2012, Seungwon Jeon wrote: > I checked the changes. Thanks for your work. > > Reviewed-by: Seungwon Jeon > > On Wednesday, December 26, 2012, Konstantin Dorfman wrote: >> When current request is running on the bus and if next request fetched >> by mmcqd is NULL, mmc

Re: [PATCH v2] mmc: queue: exclude asynchronous transfer for special request

Hi, On Thu, Dec 27 2012, Konstantin Dorfman wrote: > Reviewed-by: Konstantin Dorfman > > On 12/26/2012 03:40 AM, Seungwon Jeon wrote: >> Unlike normal r/w request, special requests(discard, flush) >> is finished with a one-time issue_fn. Request change to >> mqrq_prev makes unnecessary call. >> >

Re: [PATCH/RFC] mmc: sh-mmcif: simplify IRQ processing

Hi Guennadi, On Wed, Dec 12 2012, Guennadi Liakhovetski wrote: > The classical way to process IRQs is read out the status, ack all triggered > IRQs, possibly mask them, then process them. Follow this simple procesure > instead of the current complex custom algorithm. > > Signed-off-by: Guennadi Li

Re: [PATCH 00/14] mmc: sh-mmcif: 3.8 fixes and improvements

Hi Guennadi, On Wed, Dec 12 2012, Guennadi Liakhovetski wrote: > This patch series fixes several bugs in the sh_mmcif.c driver, that showed > up on SMP with DMA (patches 10, 13), adds new features (3, 4) and adds > multiple further improvements and minor fixes. Even though these bugs > currentl

Re: [PATCH v2 0/3] Use devm_* managed functions to ease slot-gpio users

Hi Shawn, On Tue, Dec 11 2012, Shawn Guo wrote: > Changes since v1: > * Add kernel doc for mmc_gpio_request/free_ro/cd() to document the >use cases. > * Add a patch to remove unncessary mmc_gpio_free_cd() call from >existing slot-gpio users. > > Shawn Guo (3): > mmc: slot-gpio: use dev

Re: FW: [PATCH v1 0/3] SDIO fixes

Hi Subhash, On Tue, Dec 11 2012, Subhash Jadavani wrote: > This patch-series is having 1 fix for SDIO resume and 2 fixes related to > SDIO3.0 card detection > > Subhash Jadavani (2): > mmc: sdio: fix resume failure > mmc: sdio: print correct UHS mode during card detection > > Sujit Reddy

Re: [PATCH] mmc: sdhci: query card presence from cd-gpio before asking SDHCI

Hi Shawn, On Tue, Dec 11 2012, Shawn Guo wrote: > Call mmc_gpio_get_cd() to query card presence from cd-gpio before > asking SDHCI. The rationale behind this change is that flag > SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to > tell that SDHCI_PRESENT_STATE is broken, and

[Q] Vqmmc vs. Vmmc supply

Hi I'm trying to understand requirements for switching Vmmc and Vqmmc supply voltages of SD cards. IIUC, Vmmc is the card supply voltage, applied to the card's VDD pin, Vqmmc is the voltage, used to pull up signal lines. Traditionally it used to be the same voltage, respectively, OCR reflects

R5C822 SD-card reader not working under kernels 3.7.x

Hello. I hope, that this is the good plate to write to :-) This is my first post to this forum. I have a Dell D430 laptop, which has as SD(HC) card reader using Ricoh chip: 02:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18) (prog-if 01) Subsystem:

Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT

Will, On Mon, Jan 14, 2013 at 2:47 AM, Will Newton wrote: > These changes look ok to me. I don't know if patch 4 made it to the > list, I only got a copy via the cc and the only archive I can find of > linux-mmc (gmane) seems to be missing a lot of messages besides this > one. It seems to have m

Re: [PATCH v2 2/3] mmc: remove unncessary mmc_gpio_free_cd() call from slot-gpio users

On Tue, 11 Dec 2012, Shawn Guo wrote: > Since slot-gpio uses devm_* managed functions in mmc_gpio_request_cd() > now, we can remove those mmc_gpio_free_cd() call from host drivers' > .probe() error path and .remove(). > > Signed-off-by: Shawn Guo (for mmcif and tmio) Acked-by: Guennadi Liakhov

Re: [PATCH v2 1/3] mmc: slot-gpio: use devm_* managed functions to ease users

Hi Shawn Sorry for a late reply. On Tue, 11 Dec 2012, Shawn Guo wrote: > Use devm_* managed functions, so that slot-gpio users do not have to > call mmc_gpio_free_ro/cd to free up resources requested in > mmc_gpio_request_ro/cd. > > Signed-off-by: Shawn Guo Acked-by: Guennadi Liakhovetski T

Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT

On Fri, Jan 11, 2013 at 5:03 PM, Doug Anderson wrote: > The original quirk was added in the change 'mmc: dw_mmc: add quirk to > indicate missing write protect line'. The original quirk was added at > a controller level even though each slot has its own write protect (so > the quirk should be at t

[Q] MMC GPIO polarity flag usage

Hi all I'm confused by the ways to specify GPIO polarity in general and for MMC card-detect and write-protect pins specifically. IIUC, the flags variable as returned by a call to of_get_named_gpio_flags(..., &flags) should be platform-independent, if a specific gpio driver choses to define the

RE: [RFC PATCH] MAINTAINERS: Add an orphaned entry for the dw_mmc driver.

On Saturday, January 12, 2013, Chris Ball wrote: > Hi, > > On Fri, Jan 11 2013, Will Newton wrote: > > I submitted this driver but will shortly no longer have access > > to hardware that uses it. The driver is quite widely used so > > there may be someone out there that feels strongly enough to >