Re: [BUG] Kernel error when first driver unbind with empty MMC slot

Dne 13.9.2015 v 11:56 Robert Jarzmik napsal(a): > Petr Cvek writes: > >> During testing of these patches >> >> [PATCH] mmc: pxamci: fix card detect threaded interrupt >> [PATCH 1/3] dmaengine: virt-dma: don't always free descriptor upon >> completion >> >> I have found unrelated error.

Re: [BUG] Kernel error when first driver unbind with empty MMC slot

Petr Cvek writes: > During testing of these patches > > [PATCH] mmc: pxamci: fix card detect threaded interrupt > [PATCH 1/3] dmaengine: virt-dma: don't always free descriptor upon > completion > > I have found unrelated error. > > How to reproduce: > > 1) Remove any SD card > 2) No

[BUG] Kernel error when first driver unbind with empty MMC slot

During testing of these patches [PATCH] mmc: pxamci: fix card detect threaded interrupt [PATCH 1/3] dmaengine: virt-dma: don't always free descriptor upon completion I have found unrelated error. How to reproduce: 1) Remove any SD card 2) No CPLD initial power for card (in m

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On 08/19/2014 02:43 PM, Ulf Hansson wrote: > > Well, currently this seems like the best approach. If we end up having > some new regulator helper function, future wise, we can convert to > such later on. > Great, thanks a lot for your help! > Kind regards > Uffe > Best regards, Javier -- To un

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On 14 August 2014 14:39, Javier Martinez Canillas wrote: > The operation conditions register (OCR) stores the voltage > profile of the card, however the list of possible voltages > is restricted by the voltage range supported by the supply > used as VCC/VDD. So in mmc_vddrange_to_ocrmask() a OCR m

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On 19 August 2014 13:29, Javier Martinez Canillas wrote: > Hello Ulf, > > On 08/15/2014 04:51 PM, Ulf Hansson wrote: >> >> Just wanted to add some input regarding the errors in the mmc case. >> These are of high importance. In principle if you get, "Failed getting >> OCR mask: -22", likely you wil

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

Hello Ulf, On 08/15/2014 04:51 PM, Ulf Hansson wrote: > > Just wanted to add some input regarding the errors in the mmc case. > These are of high importance. In principle if you get, "Failed getting > OCR mask: -22", likely you will be using a wrong OCR mask while > negotiating the voltage level

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Sun, Aug 17, 2014 at 10:11:30AM -0700, Tim Kryger wrote: > On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown wrote: > > Nobody has written suitable code, and please bear in mind that even if > > the code is written there will probably be cases where it's too > > expensive for whatever reason so Javi

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown wrote: > On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote: > >> That is a little different from my suggestion where the constraints >> check is skipped when the regulator output is fixed. It effectively >> does this now when the regulator itse

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 04:51:38PM +0200, Ulf Hansson wrote: > Just wanted to add some input regarding the errors in the mmc case. > These are of high importance. In principle if you get, "Failed getting > OCR mask: -22", likely you will be using a wrong OCR mask while > negotiating the voltage le

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote: > That is a little different from my suggestion where the constraints > check is skipped when the regulator output is fixed. It effectively > does this now when the regulator itself provides the fixed voltage. > However, the checks aren'

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On 15 August 2014 11:55, Mark Brown wrote: > On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote: > >> But now I wonder why regulator_list_voltage() even list the voltage for >> fixed regulators (desc->fixed_uV) since they don't have the ability to >> vary voltage. The regulat

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 12:48 AM, Javier Martinez Canillas wrote: > Hello Tim, > > On 08/15/2014 07:36 AM, Tim Kryger wrote: >> On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown wrote: >> >>> Right, there's two things going on here. One is that as you describe we >>> shouldn't be putting constraints i

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

Hello Mark, On 08/15/2014 11:55 AM, Mark Brown wrote: > On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote: > >> But now I wonder why regulator_list_voltage() even list the voltage for >> fixed regulators (desc->fixed_uV) since they don't have the ability to > > That's beca

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote: > But now I wonder why regulator_list_voltage() even list the voltage for > fixed regulators (desc->fixed_uV) since they don't have the ability to > vary voltage. The regulator_list_voltage() documentation says: That's beca

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Thu, Aug 14, 2014 at 10:36:18PM -0700, Tim Kryger wrote: > On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown wrote: > > > Right, there's two things going on here. One is that as you describe we > > shouldn't be putting constraints in .dtsi files if we don't know they're > > OK for a given board. T

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

Hello Tim, On 08/15/2014 07:36 AM, Tim Kryger wrote: > On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown wrote: > >> Right, there's two things going on here. One is that as you describe we >> shouldn't be putting constraints in .dtsi files if we don't know they're >> OK for a given board. The other

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown wrote: > Right, there's two things going on here. One is that as you describe we > shouldn't be putting constraints in .dtsi files if we don't know they're > OK for a given board. The other thing is that on this particular board > it turns out that th

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

Hello Tim, Thanks for your feedback. On 08/14/2014 04:13 PM, Tim Kryger wrote: > > https://lkml.org/lkml/2014/8/12/377 > > Perhaps I misunderstood the discussion in that thread but couldn't > this failure also be addressed by adding proper constraints for each > FET in individual DTS files to r

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Thu, Aug 14, 2014 at 07:13:00AM -0700, Tim Kryger wrote: > On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas > > Without this patch, the following warning is reported when > > a FET is used as a vmmc-supply: > > dwmmc_exynos 1222.mmc: Failed getting OCR mask: -22 > > Signed-off-by

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas wrote: > The operation conditions register (OCR) stores the voltage > profile of the card, however the list of possible voltages > is restricted by the voltage range supported by the supply > used as VCC/VDD. So in mmc_vddrange_to_ocrmask()

[PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

The operation conditions register (OCR) stores the voltage profile of the card, however the list of possible voltages is restricted by the voltage range supported by the supply used as VCC/VDD. So in mmc_vddrange_to_ocrmask() a OCR mask is obtained to filter the not supported voltages, from the val

Re: [PATCH] SDIO / PM: Add empty bus-level suspend/resume callbacks

Hi, On Sun, Dec 02 2012, NeilBrown wrote: >> What about applying the appended patch (hopefully, the build warnings should >> be fixed properly this time)? > > Looks good to me - thanks! Thanks, both of you, pushed to mmc-next for 3.8. - Chris. -- Chris Ball One Laptop

Re: [PATCH] SDIO / PM: Add empty bus-level suspend/resume callbacks

> > nothing is very different from not having any function at all? > > Well, I agree. I didn't remember that the callback had been added for > a purpose and hence my "ack" for that patch. > > What about applying the appended patch (hopefully, the build warnings

Re: [PATCH] SDIO / PM: Add empty bus-level suspend/resume callbacks

s > > nothing is very different from not having any function at all? > > Well, I agree. I didn't remember that the callback had been added for > a purpose and hence my "ack" for that patch. > > What about applying the appended patch (hopefully, the build warnings

[PATCH] SDIO / PM: Add empty bus-level suspend/resume callbacks

ich does > nothing is very different from not having any function at all? Well, I agree. I didn't remember that the callback had been added for a purpose and hence my "ack" for that patch. What about applying the appended patch (hopefully, the build warnings should be fixed prope

Re: [PATCH] PM / SDIO: Use empty system suspend/resume callbacks at the bus level (was: Re: Recent ...)

me comments in there pointing out that having a function which does nothing is very different from not having any function at all? Thanks, NeilBrown > > --- > From: Rafael J. Wysocki > Subject: PM / SDIO: Use empty system suspend/resume callbacks at the bus level > > Neil Brown

RE: dw_mmc: New sdio CMD53 starts with non-empty FIFO

Hi, Dmitry Shmidt wrote: > Hi, > > I am working with dw_mmc controller. Kernel 3.4-rc3. Sdio wlan device > in UHS_SDR50 mode. > What I see that sometimes next sdio CMD53 starts before FIFO is empty > and then controller goes insane and > sdio request will be blocked forev

dw_mmc: New sdio CMD53 starts with non-empty FIFO

Hi, I am working with dw_mmc controller. Kernel 3.4-rc3. Sdio wlan device in UHS_SDR50 mode. What I see that sometimes next sdio CMD53 starts before FIFO is empty and then controller goes insane and sdio request will be blocked forever. And it looks like DW_MCI_QUIRK_IDMAC_DTO quirk is helping

Re: [PATCH] PM / SDIO: Use empty system suspend/resume callbacks at the bus level

On Monday, March 26, 2012, Chris Ball wrote: > Hi Rafael, > > On Mon, Mar 26 2012, Rafael J. Wysocki wrote: > > OK, I don't see any objections. Does it mean I can push this patch as a fix > > for 3.4? Chris? > > Sounds good, I'll push it through the MMC tree. (With a stable@ tag for > 3.3 to f

Re: [PATCH] PM / SDIO: Use empty system suspend/resume callbacks at the bus level

Hi Rafael, On Mon, Mar 26 2012, Rafael J. Wysocki wrote: > OK, I don't see any objections. Does it mean I can push this patch as a fix > for 3.4? Chris? Sounds good, I'll push it through the MMC tree. (With a stable@ tag for 3.3 to fix the regression there.) Thanks, - Chris. -- Chris Ball

Re: [PATCH] PM / SDIO: Use empty system suspend/resume callbacks at the bus level (was: Re: Recent ...)

; > (I'm testing with 3.3) > > > > > > > > The only fix I can think of is to rework SDIO to stop abusing the PM > > > > callbacks. > > > > I'll have a look at that next week, although I can't promise anything > > > > any

[PATCH] PM / SDIO: Use empty system suspend/resume callbacks at the bus level (was: Re: Recent ...)

> > > > > The only fix I can think of is to rework SDIO to stop abusing the PM > > > callbacks. > > > I'll have a look at that next week, although I can't promise anything any > > > time > > > soon, because I'm heading to San Francisco

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On 8 May 2011 17:09, Arnd Bergmann wrote: > On Saturday 07 May 2011, Per Forlin wrote: >> > The mmc queue never runs empty until end of transfer.. The requests >> > are 128 blocks (64k limit set in mmc host driver) compared to 256 >> > blocks before. This will not

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On Saturday 07 May 2011, Per Forlin wrote: > > The mmc queue never runs empty until end of transfer.. The requests > > are 128 blocks (64k limit set in mmc host driver) compared to 256 > > blocks before. This will not improve performance much since the > > transfer now are

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

le-wait sec 0 nsec 7810652 >  [mmc_queue_thread] req d967c820 blocks 128 >  [mmc_queue_thread] req d967c748 blocks 128 >  [do_generic_file_read] lock_page_killable-wait sec 0 nsec 7810952 >  [mmc_queue_thread] req d967c670 blocks 128 >  [mmc_queue_thread] req d967c598 blocks 128 >

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

_thread] req d967c598 blocks 128 [mmc_queue_thread] req d967c4c0 blocks 128 [mmc_queue_thread] req d967c3e8 blocks 128 [mmc_queue_thread] req (null) blocks 0 [mmc_queue_thread] req (null) blocks 0 The mmc queue never runs empty until end of transfer.. The requests are 128 blocks (64k limit set

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On Tuesday 03 May 2011, Per Forlin wrote: > > submitting small 512 byte read requests is a real problem when the > > underlying page size is 16 KB. If your interpretation is right, > > we should probably find a way to make it read larger chunks > > on flash media. > Sorry a typo. I missed out a "k"

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On 3 May 2011 22:02, Arnd Bergmann wrote: > On Tuesday 03 May 2011 20:54:43 Per Forlin wrote: >> >> page_not_up_to_date: >> >> /* Get exclusive access to the page ... */ >> >> error = lock_page_killable(page); >> > I looked at the code in do_generic_file_read(). lock_page_killable >> > waits until

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On Tuesday 03 May 2011 20:54:43 Per Forlin wrote: > >> page_not_up_to_date: > >> /* Get exclusive access to the page ... */ > >> error = lock_page_killable(page); > > I looked at the code in do_generic_file_read(). lock_page_killable > > waits until the current read ahead is completed. > > Is it po

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On 3 May 2011 15:16, Arnd Bergmann wrote: > On Thursday 28 April 2011, Per Forlin wrote: > >> For reads on the other hand it look like this >> root@(none):/ dd if=/dev/mmcblk0 of=/dev/null bs=4k count=256 >> 256+0 records in >> 256+0 records out >> root@(none):/ dmesg >> [mmc_queue_thread] req d95

Re: mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

On Thursday 28 April 2011, Per Forlin wrote: > For reads on the other hand it look like this > root@(none):/ dd if=/dev/mmcblk0 of=/dev/null bs=4k count=256 > 256+0 records in > 256+0 records out > root@(none):/ dmesg > [mmc_queue_thread] req d954cec0 blocks 32 > [mmc_queue_thread] req (null) bl

mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

[mmc_queue_thread] req d954c140 blocks 1024 [mmc_queue_thread] req d954c068 blocks 1024 [mmc_queue_thread] req d954cde8 blocks 1024 [mmc_queue_thread] req d954cec0 blocks 1024 mmc block queue is never empty. All the mmc request preparations can run in parallel with an ongoing transfer. [mmc_queue_thread

mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

[mmc_queue_thread] req d954c140 blocks 1024 [mmc_queue_thread] req d954c068 blocks 1024 [mmc_queue_thread] req d954cde8 blocks 1024 [mmc_queue_thread] req d954cec0 blocks 1024 mmc block queue is never empty. All the mmc request preparations can run in parallel with an ongoing transfer. [mmc_queue_thread

[empty]

Please ignore this series. My patch sending script got confused too much with mbox 'From ' line. I've resent the series with fixed headers. Best Regards, Michał Mirosław -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org M

[merged] omap_hsmmc-ensure-workqueues-are-empty-before-suspend.patch removed from -mm tree

The patch titled omap_hsmmc: ensure workqueues are empty before suspend has been removed from the -mm tree. Its filename was omap_hsmmc-ensure-workqueues-are-empty-before-suspend.patch This patch was dropped because it was merged into mainline or a subsystem tree The current -mm tree

[patch 057/232] omap_hsmmc: ensure workqueues are empty before suspend

/omap_hsmmc.c | 50 +--- 1 file changed, 34 insertions(+), 16 deletions(-) diff -puN drivers/mmc/host/omap_hsmmc.c~omap_hsmmc-ensure-workqueues-are-empty-before-suspend drivers/mmc/host/omap_hsmmc.c --- a/drivers/mmc/host/omap_hsmmc.c~omap_hsmmc-ensure-workqueues-are-

[PATCH V3 14/30] omap_hsmmc: ensure workqueues are empty before suspend

>From f97476c2395ae2a5003957caaf4897f43327e1dd Mon Sep 17 00:00:00 2001 From: Adrian Hunter Date: Fri, 24 Apr 2009 13:13:20 +0300 Subject: [PATCH] omap_hsmmc: ensure workqueues are empty before suspend Signed-off-by: Adrian Hunter --- drivers/mmc/host/omap_hsmmc.c |