Re: [RFC PATCH v3 00/16] DMA Engine support for AM33XX

2012-10-26 Thread Russ Dill 
On Thu, Oct 18, 2012 at 6:26 AM, Matt Porter mpor...@ti.com wrote:
 Changes since v2:
 - Rebased on 3.7-rc1
 - Fixed bug in DT/pdata parsing first found by Gururaja
   that turned out to be masked by some toolchains
 - Dropped unused mach-omap2/devices.c hsmmc patch
 - Added AM33XX crossbar DMA event mux support
 - Added am335x-evm support

 Changes since v1:
 - Rebased on top of mainline from 12250d8
 - Dropped the feature removal schedule patch
 - Implemented dma_request_slave_channel_compat() and
   converted the mmc and spi drivers to use it
 - Dropped unneeded #address-cells and #size-cells from
   EDMA DT support
 - Moved private EDMA header to linux/platform_data/ and
   removed some unneeded definitions
 - Fixed parsing of optional properties

 TODO:
 - Add dmaengine support for per-channel caps so the
   hack to set the maximum segments can be replaced with
   a query to the dmaengine driver

 This series adds DMA Engine support for AM33xx, which uses
 an EDMA DMAC. The EDMA DMAC has been previously supported by only
 a private API implementation (much like the situation with OMAP
 DMA) found on the DaVinci family of SoCs.

This pretty far along and looks great.

Reviewed-by: russ.d...@ti.com

 The series applies on top of 3.7-rc1 and the following patches:

 - GPMC fails to reserve memory fix:
   http://www.spinics.net/lists/linux-omap/msg79675.html
 - TPS65910 regulator fix:
   https://patchwork.kernel.org/patch/1593651/
 - dmaengine DT support from Vinod's dmaengine_dt branch in
   git://git.infradead.org/users/vkoul/slave-dma.git since
   027478851791df751176398be02a3b1c5f6aa824

 The approach taken is similar to how OMAP DMA is being converted to
 DMA Engine support. With the functional EDMA private API already
 existing in mach-davinci/dma.c, we first move that to an ARM common
 area so it can be shared. Adding DT and runtime PM support to the
 private EDMA API implementation allows it to run on AM33xx. AM33xx
 *only* boots using DT so we leverage Jon's generic DT DMA helpers to
 register EDMA DMAC with the of_dma framework and then add support
 for calling the dma_request_slave_channel() API to both the mmc
 and spi drivers.

 With this series both BeagleBone and the AM335x EVM have working
 MMC and SPI support.

 This is tested on BeagleBone with a SPI framebuffer driver and MMC
 rootfs. A trivial gpio DMA event misc driver was used to test the
 crossbar DMA event support. It is also tested on the AM335x EVM
 with the onboard SPI flash and MMC rootfs. The branch at
 https://github.com/ohporter/linux/tree/edma-dmaengine-v3 has the
 complete series, dependencies, and some test drivers/defconfigs.

 Regression testing was done on AM180x-EVM (which also makes use
 of the EDMA dmaengine driver and the EDMA private API) using SD,
 SPI flash, and the onboard audio supported by the ASoC Davinci
 driver.

 After this series, the plan is to convert the last in-tree user
 of the private EDMA API (davinci-pcm/mcasp) and then eliminate
 the private EDMA API by folding its functionality into
 drivers/dma/edma.c.

 Matt Porter (16):
   dmaengine: edma: fix slave config dependency on direction
   ARM: davinci: move private EDMA API to arm/common
   ARM: edma: remove unused transfer controller handlers
   ARM: edma: add DT and runtime PM support for AM33XX
   ARM: edma: add AM33XX crossbar event support
   dmaengine: edma: enable build for AM33XX
   dmaengine: edma: Add TI EDMA device tree binding
   ARM: dts: add AM33XX EDMA support
   dmaengine: add dma_request_slave_channel_compat()
   mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
   mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
   mmc: omap_hsmmc: add generic DMA request support to the DT binding
   ARM: dts: add AM33XX MMC support
   spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
   spi: omap2-mcspi: add generic DMA request support to the DT binding
   ARM: dts: add AM33XX SPI support

  Documentation/devicetree/bindings/dma/ti-edma.txt  |   51 +
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   25 +-
  Documentation/devicetree/bindings/spi/omap-spi.txt |   27 +-
  arch/arm/Kconfig   |1 +
  arch/arm/boot/dts/am335x-bone.dts  |   23 +
  arch/arm/boot/dts/am335x-evm.dts   |   15 +
  arch/arm/boot/dts/am33xx.dtsi  |  101 ++
  arch/arm/common/Kconfig|3 +
  arch/arm/common/Makefile   |1 +
  arch/arm/common/edma.c | 1841 
 
  arch/arm/mach-davinci/Makefile |2 +-
  arch/arm/mach-davinci/board-da830-evm.c|4 +-
  arch/arm/mach-davinci/board-da850-evm.c|8 +-

Re: [PATCH] mmc: core: debugfs: Add signal_voltage to ios dump

2012-10-26 Thread Philip Rakity 

On Oct 26, 2012, at 11:31 AM, Johan Rudholm johan.rudh...@stericsson.com 
wrote:

 Signed-off-by: Johan Rudholm johan.rudh...@stericsson.com
 ---
 drivers/mmc/core/debugfs.c |   16 
 1 file changed, 16 insertions(+)
 
 diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
 index d96c643..35c2f85 100644
 --- a/drivers/mmc/core/debugfs.c
 +++ b/drivers/mmc/core/debugfs.c
 @@ -144,6 +144,22 @@ static int mmc_ios_show(struct seq_file *s, void *data)
   }
   seq_printf(s, timing spec:\t%u (%s)\n, ios-timing, str);
 
 + switch (ios-signal_voltage) {
 + case MMC_SIGNAL_VOLTAGE_330:
 + str = 3.30 V;
 + break;
 + case MMC_SIGNAL_VOLTAGE_180:
 + str = 1.80 V;
 + break;
 + case MMC_SIGNAL_VOLTAGE_120:
 + str = 1.20 V;
 + break;
 + default:
 + str = invalid;

would is unknown  be a better str ?
 + break;
 + }
 + seq_printf(s, signal voltage:\t%u (%s)\n, ios-chip_select, str);
 +
   return 0;
 }
 
Reviewed-by: Philip Rakity prak...@nvidia.com
 -- 
 1.7.10
 
 --
 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

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: dw-mmc: relocate the position called dw_mci_setup_bus()

2012-10-26 Thread Seungwon Jeon 
Friday, October 26, 2012, Jaehoon Chung jh80.ch...@samsung.com
 I think right that dw_mci_setup_bus() is called into set_ios().
 Actually clock is enabled at dw_mci_setup_bus() in now.
 Then didn't ensure to wait the 74clock.
This will be ensured when first command is sent
with 'send_initialization' flag of CMD register.
But I feel this change is reasonable.
Looks good to me if commit message is modified.

Acked-by: Seungwon Jeon tgih@samsung.com

Thanks.
Seungwon Jeon

 To stable clock is relocated the position into dw_mci_set_ios().
 
 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/mmc/host/dw_mmc.c |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 250aa18..9001844 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -682,9 +682,6 @@ static void __dw_mci_start_request(struct dw_mci *host,
   if (host-pdata-select_slot)
   host-pdata-select_slot(slot-id);
 
 - /* Slot specific timing and width adjustment */
 - dw_mci_setup_bus(slot);
 -
   host-cur_slot = slot;
   host-mrq = mrq;
 
 @@ -810,6 +807,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
 mmc_ios *ios)
   if (slot-host-drv_data-set_ios)
   slot-host-drv_data-set_ios(slot-host, ios);
 
 + /* Slot specific timing and width adjustment */
 + dw_mci_setup_bus(slot);
 +
   switch (ios-power_mode) {
   case MMC_POWER_UP:
   set_bit(DW_MMC_CARD_NEED_INIT, slot-flags);
 --
 1.7.4.1
 --
 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

--
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/1] mmc/card/queue.c: change action when the condition of if is true

2012-10-26 Thread Venkatraman S 

On Thursday 25 October 2012 06:29 PM, wang.jing.windsdae...@gmail.com wrote:

From: Jing Wang windsdae...@gmail.com

Some description of the actual effect of the change here would be nice.
For example, Trim the error handling path in mmc_alloc_sg.
But what's the point of this patch anyway ? There are 2 return statements
instead of one.


Signed-off-by: Jing Wang windsdae...@gmail.com
---
  drivers/mmc/card/queue.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index e360a97..98a22a1 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -118,13 +118,14 @@ static struct scatterlist *mmc_alloc_sg(int sg_len, int 
*err)
struct scatterlist *sg;
  
  	sg = kmalloc(sizeof(struct scatterlist)*sg_len, GFP_KERNEL);

-   if (!sg)
+   if (!sg) {
*err = -ENOMEM;
-   else {
-   *err = 0;
-   sg_init_table(sg, sg_len);
+   return sg;
}
  
+	*err = 0;

+   sg_init_table(sg, sg_len);
+
return sg;
  }
  


--
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/PATCH] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete

2012-10-26 Thread Venkatraman S 

On Thursday 25 October 2012 11:34 PM, Felipe Balbi wrote:

Hi,

On Mon, Oct 22, 2012 at 04:27:08PM +0300, Felipe Balbi wrote:

On Mon, Oct 22, 2012 at 03:59:28PM +0300, Felipe Balbi wrote:

prepare() is supposed to prevent new children from
being registered. On the MMC subsystem, children
(new cards) registration starts with the card
detect IRQ.

Move card detect IRQ disabling to prepare() so that
no new cards will be registered while we're trying
to suspend.

Likewise, move card detect IRQ enabling to complete()
so we only try to register new children after our MMC
IP is back up.

Signed-off-by: Felipe Balbi ba...@ti.com
---

Venkat, do you think the patch below makes sense ?

btw, just checked suspend to ram with beagle and panda. We still have
our filesystem after waking up.

ps: you will [1] to test it:

[1] http://marc.info/?l=linux-arm-kernelm=135090724817604w=2

ping

I've been off for the past 3 days. Will test this on Monday once I'm 
back in office.

--
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: core: debugfs: Add signal_voltage to ios dump

2012-10-26 Thread Johan Rudholm 
Hi,

2012/10/26 Philip Rakity prak...@nvidia.com:

 On Oct 26, 2012, at 11:31 AM, Johan Rudholm johan.rudh...@stericsson.com 
 wrote:

 + default:
 + str = invalid;

 would is unknown  be a better str ?

Maybe... Actually, I just followed the standard in the function, all
other strings default to invalid when the definition is missing. So
if I change this, then I should also change the rest of the strings in
the function. I will do this if we think it's worth the effort, but is
it?

Kind regards, Johan
--
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 v1] mmc: fix async request mechanism for sequential read scenarios

2012-10-26 Thread Venkatraman S 
On Thu, Oct 25, 2012 at 6:58 PM, Konstantin Dorfman
kdorf...@codeaurora.org wrote:
 On 10/24/2012 07:07 PM, Per Förlin wrote:
 On 10/24/2012 11:41 AM, Konstantin Dorfman wrote:
 Hello Per,

 On Mon, October 22, 2012 1:02 am, Per Forlin wrote:
 When mmcqt reports on completion of a request there should be
 a context switch to allow the insertion of the next read ahead BIOs
 to the block layer. Since the mmcqd tries to fetch another request
 immediately after the completion of the previous request it gets NULL
 and starts waiting for the completion of the previous request.
 This wait on completion gives the FS the opportunity to insert the next
 request but the MMC layer is already blocked on the previous request
 completion and is not aware of the new request waiting to be fetched.
 I thought that I could trigger a context switch in order to give
 execution time for FS to add the new request to the MMC queue.
 I made a simple hack to call yield() in case the request gets NULL. I
 thought it may give the FS layer enough time to add a new request to
 the MMC queue. This would not delay the MMC transfer since the yield()
 is done in parallel with an ongoing transfer. Anyway it was just meant
 to be a simple test.

 One yield was not enough. Just for sanity check I added a msleep as
 well and that was enough to let FS add a new request,
 Would it be possible to gain throughput by delaying the fetch of new
 request? Too avoid unnecessary NULL requests

 If (ongoing request is read AND size is max read ahead AND new request
 is NULL) yield();

 BR
 Per
 We did the same experiment and it will not give maximum possible
 performance. There is no guarantee that the context switch which was
 manually caused by the MMC layer comes just in time: when it was early
 then next fetch still results in NULL, when it was later, then we miss
 possibility to fetch/prepare new request.

 Any delay in fetch of the new request that comes after the new request has
 arrived hits throughput and latency.

 The solution we are talking about here will fix not only situation with FS
 read ahead mechanism, but also it will remove penalty of the MMC context
 waiting on completion while any new request arrives.

 Thanks,

 It seems strange that the block layer cannot keep up with relatively slow 
 flash media devices. There must be a limitation on number of outstanding 
 request towards MMC.
 I need to make up my mind if it's the best way to address this issue in the 
 MMC framework or block layer. I have started to look into the block layer 
 code but it will take some time to dig out the relevant parts.

 BR
 Per

 The root cause of the issue in incompletion of the current design with
 well known producer-consumer problem solution (producer is block layer,
 consumer is mmc layer).
 Classic definitions states that the buffer is fix size, in our case we
 have queue, so Producer always capable to put new request into the queue.
 Consumer context blocked when both buffers (curr and prev) are busy
 (first started its execution on the bus, second is fetched and waiting
 for the first).
 Producer context considered to be blocked when FS (or others bio
 sources) has no requests to put into queue.
 To maximize performance there are 2 notifications should be used:
 1. Producer notifies Consumer about new item to proceed.
 2. Consumer notifies Producer about free place.

 In our case 2nd notification not need since as I said before - it is
 always free space in the queue.
 There is no such notification as 1st, i.e. block layer has no way to
 notify mmc layer about new request arrived.

Being nitpicky, I think it contradicts with the commit log that you have
for the patch..
Quote
When the block layer notifies the MMC layer on a new request, we check
for the above case where MMC layer is waiting on a previous request
completion and the current request is NULL.
/Quote


 What you suggesting is to resolve specific case, when FS READ_AHEAD
 mechanism behavior causes delays in producing new requests.
 Probably you can resolve this specific case, but do you have guarantee
 that this is only case that causes delays between new requests events?
 Flash memory devices these days constantly improved on all levels: NAND,
 firmware, bus speed and host controller capabilities, this makes any
 yield/sleep/timeouts solution only temporary hacks.

--
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 v1] mmc: fix async request mechanism for sequential read scenarios

2012-10-26 Thread Venkatraman S 
On Thu, Oct 25, 2012 at 8:32 PM, Per Förlin per.for...@stericsson.com wrote:
 On 10/25/2012 03:28 PM, Konstantin Dorfman wrote:
 On 10/24/2012 07:07 PM, Per Förlin wrote:
 On 10/24/2012 11:41 AM, Konstantin Dorfman wrote:
 Hello Per,

 On Mon, October 22, 2012 1:02 am, Per Forlin wrote:
 When mmcqt reports on completion of a request there should be
 a context switch to allow the insertion of the next read ahead BIOs
 to the block layer. Since the mmcqd tries to fetch another request
 immediately after the completion of the previous request it gets NULL
 and starts waiting for the completion of the previous request.
 This wait on completion gives the FS the opportunity to insert the next
 request but the MMC layer is already blocked on the previous request
 completion and is not aware of the new request waiting to be fetched.
 I thought that I could trigger a context switch in order to give
 execution time for FS to add the new request to the MMC queue.
 I made a simple hack to call yield() in case the request gets NULL. I
 thought it may give the FS layer enough time to add a new request to
 the MMC queue. This would not delay the MMC transfer since the yield()
 is done in parallel with an ongoing transfer. Anyway it was just meant
 to be a simple test.

 One yield was not enough. Just for sanity check I added a msleep as
 well and that was enough to let FS add a new request,
 Would it be possible to gain throughput by delaying the fetch of new
 request? Too avoid unnecessary NULL requests

 If (ongoing request is read AND size is max read ahead AND new request
 is NULL) yield();

 BR
 Per
 We did the same experiment and it will not give maximum possible
 performance. There is no guarantee that the context switch which was
 manually caused by the MMC layer comes just in time: when it was early
 then next fetch still results in NULL, when it was later, then we miss
 possibility to fetch/prepare new request.

 Any delay in fetch of the new request that comes after the new request has
 arrived hits throughput and latency.

 The solution we are talking about here will fix not only situation with FS
 read ahead mechanism, but also it will remove penalty of the MMC context
 waiting on completion while any new request arrives.

 Thanks,

 It seems strange that the block layer cannot keep up with relatively slow 
 flash media devices. There must be a limitation on number of outstanding 
 request towards MMC.
 I need to make up my mind if it's the best way to address this issue in the 
 MMC framework or block layer. I have started to look into the block layer 
 code but it will take some time to dig out the relevant parts.

 BR
 Per

 The root cause of the issue in incompletion of the current design with
 well known producer-consumer problem solution (producer is block layer,
 consumer is mmc layer).
 Classic definitions states that the buffer is fix size, in our case we
 have queue, so Producer always capable to put new request into the queue.
 Consumer context blocked when both buffers (curr and prev) are busy
 (first started its execution on the bus, second is fetched and waiting
 for the first).
 This happens but I thought that the block layer would continue to add request 
 to the MMC queue while the consumer is busy.
 When consumer fetches request from the queue again there should be several 
 requests available in the queue, but there is only one.

 Producer context considered to be blocked when FS (or others bio
 sources) has no requests to put into queue.
 Does the block layer ever wait for outstanding request to finish? Could this 
 be another reason why the producer doesn't add new requests on the MMC queue?


Actually there could a lot of reasons why block layer or CFQ would not have
inserted the request into the queue. i.e. you can see a lot of exit paths
where blk_peek_request returns NULL, even though there could be any request
pending in one of the CFQ requests queues.

Essentially you need to check what makes blk_fetch_request
(cfq_dispatch_requests() ) return NULL when there is an element in
queue, if at all.

 To maximize performance there are 2 notifications should be used:
 1. Producer notifies Consumer about new item to proceed.
 2. Consumer notifies Producer about free place.

 In our case 2nd notification not need since as I said before - it is
 always free space in the queue.
 There is no such notification as 1st, i.e. block layer has no way to
 notify mmc layer about new request arrived.

 What you suggesting is to resolve specific case, when FS READ_AHEAD
 mechanism behavior causes delays in producing new requests.
 Probably you can resolve this specific case, but do you have guarantee
 that this is only case that causes delays between new requests events?
 Flash memory devices these days constantly improved on all levels: NAND,
 firmware, bus speed and host controller capabilities, this makes any
 yield/sleep/timeouts solution only temporary hacks.
 I never meant yield or sleep to be a

RE: [RFC PATCH v3 05/16] ARM: edma: add AM33XX crossbar event support

2012-10-26 Thread Hebbar, Gururaja 
On Thu, Oct 18, 2012 at 18:56:44, Porter, Matt wrote:
 Adds support for the per-EDMA channel event mux. This is required
 for any peripherals using DMA crossbar mapped events.
 
 Signed-off-by: Matt Porter mpor...@ti.com
 ---
  arch/arm/common/edma.c |   63 
 +++-
  include/linux/platform_data/edma.h |1 +
  2 files changed, 63 insertions(+), 1 deletion(-)
 

..snip..
..snip..

 +
 + for (i = 0; xbar_chans[i][0] != -1; i++) {
 + shift = (xbar_chans[i][1] % 4) * 8;
 + offset = xbar_chans[i][1]  2;
 + offset = 2;
 + mux = __raw_readl((void *)((u32)xbar + offset));
 + mux = (~(0xff  shift));
 + mux |= (xbar_chans[i][0]  shift);
 + __raw_writel(mux, (void *)((u32)xbar + offset));

This method of calculating Xbar Channel offset has a bug that
the code breaks with unaligned access trap error when requested 
channel to be mapped is odd.

This was fixed in Arago tree [1]. Kindly verify


 + }
 +
 + pdata-xbar_chans = xbar_chans;
 +
 + return 0;
 +}
 +

..snip..
..snip..

[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=c08d3cb557adf71c79aeefb3395455824e83

Regards, 
Gururaja
--
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: dw-mmc: relocate the position called dw_mci_setup_bus()

2012-10-26 Thread Will Newton 
On Fri, Oct 26, 2012 at 3:57 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 I think right that dw_mci_setup_bus() is called into set_ios().
 Actually clock is enabled at dw_mci_setup_bus() in now.
 Then didn't ensure to wait the 74clock.
 To stable clock is relocated the position into dw_mci_set_ios().

 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/mmc/host/dw_mmc.c |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

This patch looks ok in principle, but I have trouble understanding the
commit message. Would it be possible to try and reword it a bit to
make it clearer?

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 v6 0/3] Add modules to support realtek PCIE card reader

2012-10-26 Thread Greg KH 
On Fri, Oct 26, 2012 at 10:51:23AM +0800, wwang wrote:
 于 2012年10月26日 10:45, Greg KH 写道:
 On Fri, Oct 26, 2012 at 09:10:45AM +0800, wwang wrote:
 于 2012年10月26日 02:50, Greg KH 写道:
 On Sat, Oct 20, 2012 at 06:46:15AM +0300, Dan Carpenter wrote:
 On Sat, Oct 06, 2012 at 03:23:56PM +0800, wwang wrote:
 We are still maintaining the SCSI driver for Realtek card reader,
 and will release the latest source code in the Github in the future.
 But maybe we won't push it to the staging tree any more.
 Maybe we should just remove the staging code if it won't be fixed.
 That's sort of the point of staging.
 I agree.  wwang, want me to delet the staging driver now?  I don't want
 dead code in the tree, especially as you don't want to maintain it
 anymore.
 
 thanks,
 
 greg k-h
 Hi Greg:
 
 OK. You can delete it now, please.
 And I will push my new driver to MFD and MMC subsystem.
 Ok, just to confirm, you want me to delete the
 drivers/staging/rts_pstor/* code, right?
 
 thanks,
 
 greg k-h
 Hi Greg:
 
 Yes, you can delete drivers/staging/rts_pstor

Thanks, now done.

greg k-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: process hangs on do_exit when oom happens

2012-10-26 Thread Mike Galbraith 
On Fri, 2012-10-26 at 10:42 +0800, Qiang Gao wrote: 
 On Thu, Oct 25, 2012 at 5:57 PM, Michal Hocko mho...@suse.cz wrote:
  On Wed 24-10-12 11:44:17, Qiang Gao wrote:
  On Wed, Oct 24, 2012 at 1:43 AM, Balbir Singh bsinghar...@gmail.com 
  wrote:
   On Tue, Oct 23, 2012 at 3:45 PM, Michal Hocko mho...@suse.cz wrote:
   On Tue 23-10-12 18:10:33, Qiang Gao wrote:
   On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko mho...@suse.cz wrote:
On Tue 23-10-12 15:18:48, Qiang Gao wrote:
This process was moved to RT-priority queue when global oom-killer
happened to boost the recovery of the system..
   
Who did that? oom killer doesn't boost the priority (scheduling 
class)
AFAIK.
   
but it wasn't get properily dealt with. I still have no idea why 
where
the problem is ..
   
Well your configuration says that there is no runtime reserved for 
the
group.
Please refer to Documentation/scheduler/sched-rt-group.txt for more
information.
   
   [...]
   maybe this is not a upstream-kernel bug. the centos/redhat kernel
   would boost the process to RT prio when the process was selected
   by oom-killer.
  
   This still looks like your cpu controller is misconfigured. Even if the
   task is promoted to be realtime.
  
  
   Precisely! You need to have rt bandwidth enabled for RT tasks to run,
   as a workaround please give the groups some RT bandwidth and then work
   out the migration to RT and what should be the defaults on the distro.
  
   Balbir
 
 
  see https://patchwork.kernel.org/patch/719411/
 
  The patch surely fixes your problem but the primary fault here is the
  mis-configured cpu cgroup. If the value for the bandwidth is zero by
  default then all realtime processes in the group a screwed. The value
  should be set to something more reasonable.
  I am not familiar with the cpu controller but it seems that
  alloc_rt_sched_group needs some treat. Care to look into it and send a
  patch to the cpu controller and cgroup maintainers, please?
 
  --
  Michal Hocko
  SUSE Labs
 
 I'm trying to fix the problem. but no substantive progress yet.

The throttle tracks a finite resource for an arbitrary number of groups,
so there's no sane rt_runtime default other than zero.

Most folks only want the top level throttle warm fuzzy, so a complete
runtime RT_GROUP_SCHED on/off switch with default to off, ie rt tasks
cannot be moved until switched on would fix some annoying Oopsie, I
forgot allocation troubles.  If you turn it on, shame on you if you
fail to allocate, you asked for it, you're not just stuck with it
because your distro enabled it in their config.

Or, perhaps just make zero rt_runtime always mean traverse up to first
non-zero rt_runtime, ie zero allocation children may consume parental
runtime as they see fit on first come first served basis, when it's
gone, tough, parent/children all wait for refill.

Or whatever, as long as you don't bust distribution/tracking for those
crazy people who intentionally use RT_GROUP_SCHED ;-)

The bug is in the patch that used sched_setscheduler_nocheck().  Plain
sched_setscheduler() would have replied -EGOAWAY.

-Mike

--
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: process hangs on do_exit when oom happens

2012-10-26 Thread Mike Galbraith 
On Fri, 2012-10-26 at 10:03 -0700, Mike Galbraith wrote:

 The bug is in the patch that used sched_setscheduler_nocheck().  Plain
 sched_setscheduler() would have replied -EGOAWAY.

sched_setscheduler_nocheck() should say go away too methinks.  This
isn't about permissions, it's about not being stupid in general.

sched: fix __sched_setscheduler() RT_GROUP_SCHED conditionals

Remove user and rt_bandwidth_enabled() RT_GROUP_SCHED conditionals in
__sched_setscheduler().  The end result of kernel OR user promoting a
task in a group with zero rt_runtime allocated is the same bad thing,
and throttle switch position matters little.  It's safer to just say
no solely based upon bandwidth existence, may save the user a nasty
surprise if he later flips the throttle switch to 'on'.

The commit below came about due to sched_setscheduler_nocheck()
allowing a task in a task group with zero rt_runtime allocated to
be promoted by the kernel oom logic, thus marooning it forever.

quote
commit 341aea2bc48bf652777fb015cc2b3dfa9a451817
Author: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Date:   Thu Apr 14 15:22:13 2011 -0700

oom-kill: remove boost_dying_task_prio()

This is an almost-revert of commit 93b43fa (oom: give the dying task a
higher priority).

That commit dramatically improved oom killer logic when a fork-bomb
occurs.  But I've found that it has nasty corner case.  Now cpu cgroup has
strange default RT runtime.  It's 0!  That said, if a process under cpu
cgroup promote RT scheduling class, the process never run at all.
/quote

Signed-off-by: Mike Galbraith efa...@gmx.de

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..d3a35f8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3810,17 +3810,14 @@ recheck:
}
 
 #ifdef CONFIG_RT_GROUP_SCHED
-   if (user) {
-   /*
-* Do not allow realtime tasks into groups that have no runtime
-* assigned.
-*/
-   if (rt_bandwidth_enabled()  rt_policy(policy) 
-   task_group(p)-rt_bandwidth.rt_runtime == 0 
-   !task_group_is_autogroup(task_group(p))) {
-   task_rq_unlock(rq, p, flags);
-   return -EPERM;
-   }
+   /*
+* Do not allow realtime tasks into groups that have no runtime
+* assigned.
+*/
+   if (rt_policy(policy)  task_group(p)-rt_bandwidth.rt_runtime == 0 
+   !task_group_is_autogroup(task_group(p))) {
+   task_rq_unlock(rq, p, flags);
+   return -EPERM;
}
 #endif
 


--
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] powerpc/esdhc: enable the card insert/remove interrupt

2012-10-26 Thread Anton Vorontsov 
Hello Huang,

On Fri, Oct 26, 2012 at 02:42:36AM +, Huang Changming-R66093 wrote:
 For the current polling mode, driver will send CMD13 to poll the card status 
 periodically , which will cause too many interrupts.
 Once I sent patches to detect the card when using polling mode last year: 
 read the state register, instead of send CMD13. But, these patches were not 
 accepted. Now I attach them for you.

Was there any specific reason why the patches didn't get accepted?

I very briefly looked at them, and they seem to be OK (there are a few
cosmetic details I'd comment on, tho -- but please send them in a normal
way (i.e. not as attachments).

Thanks,
Anton.
--
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