On Fri, Sep 21, 2012 at 10:48 PM, Felipe Balbi wrote:
> On Fri, Sep 21, 2012 at 10:47:30PM +0530, S, Venkatraman wrote:
>> On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman wrote:
>> > On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter wrote:
>> >> The EDMA DMAC has a har
On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman wrote:
> On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter wrote:
>> The EDMA DMAC has a hardware limitation that prevents supporting
>> scatter gather lists with any number of segments. Since the EDMA
>> DMA Engine driver sets th
On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter wrote:
> The EDMA DMAC has a hardware limitation that prevents supporting
> scatter gather lists with any number of segments. Since the EDMA
> DMA Engine driver sets the maximum segments to 16, we do the
> same.
>
> Note: this can be removed once the DM
On Fri, Sep 21, 2012 at 8:51 PM, Balaji T K wrote:
> clock divisor can take a max value of 1023
> update code as per TRM so that card init can be handled with
> higher IP clock frequencies from which clock to the card is
> derived.
>
This is difficult to read without some punctuation / capitalizat
On Thu, Sep 13, 2012 at 12:01 PM, Hebbar, Gururaja
wrote:
> From: Vaibhav Bedia
>
> In some cases mmc_suspend_host() is not able to claim the
> host and proceed with the suspend process. The core returns
> -EBUSY to the host controller driver. Unfortunately, the
> host controller driver does not
On Mon, Sep 17, 2012 at 1:45 PM, Peter Senna Tschudin
wrote:
> From: Peter Senna Tschudin
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccine
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja wrote:
> HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> Other platforms like TI81xx, OMAP4 may need this as-well. This depends
> on the HSMMC IP timing closure done for the high speed cards.
>
> From AM335x TRM (SPRUH73F - 1
On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja wrote:
> From: Vaibhav Bedia
>
> In some cases mmc_suspend_host() is not able to claim the
> host and proceed with the suspend process. The core returns
> -EBUSY to the host controller driver. Unfortunately, the
> host controller driver does not pa
On Sat, Sep 8, 2012 at 3:29 AM, Kevin Hilman
wrote:
> Venkatraman S writes:
>
>> omap hsmmc controller IP has a built in timer that can be programmed to
>> guard against unresponsive operations. But its range is very narrow,
>> and the maximum countable time is a few seconds.
>>
>> Card maintenan
On Mon, Aug 27, 2012 at 11:58 PM, wrote:
>
> On Fri, July 27, 2012 2:07 am, S, Venkatraman wrote:
>> On Fri, Jul 27, 2012 at 12:24 AM, wrote:
>>>
>>> On Thu, July 26, 2012 8:28 am, S, Venkatraman wrote:
>>>> On Tue, Jul 24, 2012 at 2:14 PM, wro
On Tue, Aug 21, 2012 at 9:08 PM, Shubhrajyoti Datta
wrote:
> Hi Venkat,
> Some doubts below.
>
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S wrote:
>> SYSCONFIG register of HSMMC IP is managed by the omap hwmod
>> abstraction layer.
>
> At init only right?
Yes.
>
>
>> Resetting the IP and con
On Tue, Aug 21, 2012 at 8:51 PM, T Krishnamoorthy, Balaji
wrote:
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S wrote:
>> Flushing spurious IRQs from HSMMC IP is done twice in
>> omap_hsmmc_irq and omap_hsmmc_do_irq.
>
> spurious IRQ is flushed in start of omap_hsmmc_do_irq
> and irq acked at
On Tue, Aug 21, 2012 at 4:12 PM, Felipe Balbi wrote:
> On Sat, Aug 18, 2012 at 12:22:29AM +0530, Venkatraman S wrote:
>> omap hsmmc controller IP has an inbuilt timer that can be programmed to
> ^^^
> built-in
>> guard against
On Fri, Aug 17, 2012 at 11:43 PM, Puttagunta, Viswanath wrote:
> On Fri, Aug 17, 2012 at 12:28 PM, S, Venkatraman wrote:
>> On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko
>> wrote:
>>> Errata description:
>>> Due to a bad behavior of an internal sig
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko wrote:
> Errata description:
> Due to a bad behavior of an internal signal, the Card Error interrupt bit
> MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
> card response.
>
> Workaround:
> After responses of type R1/R1b f
the cost of providing
> DMA-capable buffer from upper caller(but on-stack buffer is allowed
> with no performance gain).
>
> Signed-off-by: Kyungsik Lee
> Signed-off-by: S, Venkatraman
I don't think my sign off is warranted. I gave just an illustration.
You can add my
Revi
On Tue, Jul 31, 2012 at 7:30 AM, Kyungsik Lee wrote:
> It is expected that Extended CSD register(the size of this register
> is larger than CID/CSD) will be referenced more frequently as more
> fields have been added to Extended CSD and it seems that it is not
> a good option to double the memory
On Mon, Jul 30, 2012 at 7:34 AM, Kyungsik Lee wrote:
> It is expected that Extended CSD register(the size of this register
> is larger than CID/CSD) will be referenced more frequently as more
> fields have been added to Extended CSD and it seems that it is not
> a good option to double the memory
On Fri, Jul 27, 2012 at 12:24 AM, wrote:
>
> On Thu, July 26, 2012 8:28 am, S, Venkatraman wrote:
>> On Tue, Jul 24, 2012 at 2:14 PM, wrote:
>>> On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
>>>> On Mon, Jul 23, 2012 at 5:13 PM, wrote:
>>>>
On Wed, Jul 25, 2012 at 5:01 PM, Yaniv Gardi wrote:
> This feature delete the unmap memory region of the eMMC card,
> by writing to a specific register in the EXT_CSD
> unmap region is the memory region that were previously deleted
> (by erase, trim or discard operation)
>
> Signed-off-by: Yaniv G
On Tue, Jul 24, 2012 at 2:14 PM, wrote:
> On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
>> On Mon, Jul 23, 2012 at 5:13 PM, wrote:
>>> On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
>>>> Hi, [removing Jens and the documentation list, since now we'r
On Tue, Jul 24, 2012 at 7:26 AM, Jaehoon Chung wrote:
> Enable eMMC background operations (BKOPS) feature.
>
> If URGENT_BKOPS is set after a response, note that BKOPS
> are required. Immediately run BKOPS if required.
> read/write operations should be requested during BKOPS(LEVEL-1),
> then issue
On Mon, Jul 23, 2012 at 2:43 PM, Uwe Kleine-König
wrote:
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe':
> drivers/mmc/host/omap_hsmmc.c:1808: warning: ini
On Mon, Jul 23, 2012 at 5:13 PM, wrote:
> On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
>> Hi, [removing Jens and the documentation list, since now we're
>> talking about the MMC side only]
>>
>> On Wed, Jul 18 2012, me...@codeaurora.org wrote:
>>> Is there anything else that holds this patc
On Fri, Jul 20, 2012 at 2:58 PM, S, Venkatraman wrote:
> On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren wrote:
>> * Shilimkar, Santosh [120718 02:49]:
>>>
>>> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
>>> will select DMA_ENGINE aut
On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren wrote:
> * Shilimkar, Santosh [120718 02:49]:
>>
>> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
>> will select DMA_ENGINE automatically"
>>
>> This won't be true if the DMA selection are not done
>> at ARCH_OMAP level as discussed i
On Thu, Jul 19, 2012 at 10:35 AM, Chris Ball wrote:
> Hi Venkat -- please could you ACK/review this patch?
>
Chris,
I think we have to hold on to this patch just for today. There's
another thread about this same issue on linux-omap
> On Wed, Jul 04 2012, Ming Lei wrote:
>> Recent commits on oma
On Wed, Jul 18, 2012 at 2:08 PM, Girish K S
wrote:
> In some Soc'S that integrate Designware mmc host controllers, the
> HCON register is broken. The hardware configuration is not
> updated. One specific usecase is the IDMAC. In Exysons5 SoC
> there exist a internal DMA, but the HCON register's DM
t; wrote:
>>>> On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman wrote:
>>>>> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren wrote:
>>>>>> * Shilimkar, Santosh [120718 00:09]:
>>>>>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren
On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren wrote:
> * Shilimkar, Santosh [120718 00:09]:
>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren wrote:
>> > * Javier Martinez Canillas [120716 23:56]:
>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>> >> wrote:
>> >> > Hi,
>> >> >
>>
On Tue, Jul 10, 2012 at 2:25 PM, Aaron Lu wrote:
> Add a call to mmc_set_signal_voltage to set signal voltage to 3.3v in
> mmc_power_up so that we do not need to touch signal voltage setting in
> mmc/sd/sdio init functions and rescan function.
>
> For mmc/sd cards, when doing a suspend/resume cycl
On Fri, Jul 13, 2012 at 6:27 PM, Girish K S
wrote:
> The call to the mmc_power_up during the mmc_start_host breaks the card
> detection in design-ware host controller. This patch removes the call to
> mmc_power_up function during host start.
>
Please explain why. Which commit introduced it ?
> Th
Minor printk nits..
On Tue, Jul 17, 2012 at 8:14 AM, Jaehoon Chung wrote:
> This patch added the method to enable the bkops.
> In ext_csd register, BKOPS_EN bit is one-time programable.
> So if you want to use the bkops, use the this command.
>
>
> #mmc bkops enable /dev/mmcblk0
>
> Signed-off-b
Some minor nits..
On Tue, Jul 17, 2012 at 8:14 AM, Jaehoon Chung wrote:
> Enable eMMC background operations (BKOPS) feature.
>
> If URGENT_BKOPS is set after a response, note that BKOPS
> are required. After all I/O requests are finished, run
> BKOPS if required. Should read/write operations be r
On Mon, Jul 16, 2012 at 8:16 AM, Chris Ball wrote:
> Hi,
>
> On Sun, Jul 15 2012, Muthu Kumar wrote:
>>> I've already replied to a later version of the patch, but just to get
>>> this comment in at the appropriate point of the discussion as well:
>>>
>>> Even though it would result in a cleaner sy
On Wed, Jul 11, 2012 at 5:10 AM, Kevin Hilman wrote:
> If platform_get_resource_by_name() fails, driver probe is aborted an
> should return an error so the driver is not bound to the device.
>
> However, in the current error path of platform_get_resource_by_name(),
> probe returns zero since the r
On Tue, Jul 10, 2012 at 7:47 PM, Kevin Hilman wrote:
> "S, Venkatraman" writes:
>
>> On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman wrote:
>>> Due to the way the driver core takes runtime PM references during
>>> probe, a driver's runtime PM callba
On Tue, Jul 10, 2012 at 11:24 AM, Chris Ball wrote:
> Hi,
>
> On Fri, Jun 29 2012, Seungwon Jeon wrote:
>> This patch adds packed command feature of eMMC4.5.
>> The maximum number for packing read(or write) is offered
>> and exception event relevant to packed command which is
>> used for error han
On Wed, Jun 27, 2012 at 2:19 PM, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the hsmmc clocks.
>
> Signed-off-by: Rajendra Nayak
> Cc: Chris Ball
> Cc: Balaji T K
> Cc:
> Cc: Paul Walmsley
> Cc: Mike Turquette
On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman wrote:
> Due to the way the driver core takes runtime PM references during
> probe, a driver's runtime PM callbacks may not be called until probe
> returns. During probe, drvdata is set to the 'host' pointer but if
> probe fails, drvdata is set to NULL
On Thu, Jun 28, 2012 at 1:12 PM, S, Venkatraman wrote:
> On Fri, Jun 22, 2012 at 7:01 PM, Subhash Jadavani
> wrote:
>> Thanks Venkatraman. Looks good to me.
>> Reviewed-by: Subhash Jadavani
>>
> Thanks Subhash.
> Chris,
> Can you consider including this for
On Fri, Jun 22, 2012 at 7:01 PM, Subhash Jadavani
wrote:
> Thanks Venkatraman. Looks good to me.
> Reviewed-by: Subhash Jadavani
>
Thanks Subhash.
Chris,
Can you consider including this for 3.6 ?
Thanks and regards,
Venkat.
--
To unsubscribe from this list: send the line "unsubscribe linux-mm
On Mon, Jun 18, 2012 at 11:13 AM, Seungwon Jeon wrote:
> This patch supports packed write command of eMMC4.5 device.
> Several writes can be grouped in packed command and all data
> of the individual commands can be sent in a single transfer
> on the bus.
>
> Signed-off-by: Seungwon Jeon
> ---
>
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the mmc and hsmmc clocks as part of the drivers
> probe() and remove() routines.
>
> Signed-off-by: Rajendra Nayak
> Cc: Chris Ball
> Cc
On Fri, Jun 22, 2012 at 4:19 PM, Ming Lei wrote:
> This patch reverts the commit dba3c29ea4a1d5d544.
>
> After bisecting, this commit dba3c29 is found to ruin micro-SD card data
> (writing incorrect file, or fs is corrupt after several times mount)
> on the beagle-xm revB, and reverting the commit
On Thu, Jun 21, 2012 at 4:38 PM, Subhash Jadavani
wrote:
>
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of S, Venkatraman
>> Sent: Thursday, June 21, 2012 12:55 PM
>> To: Sub
On Wed, Jun 20, 2012 at 11:29 PM, Subhash Jadavani
wrote:
> Hi Venkatraman,
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Venkatraman S
>> Sent: Wednesday, June 20, 2012 3:04 PM
>> To: c...@laptop.org
>> Cc: linux
On Wed, Jun 20, 2012 at 10:31 PM, Chris Ball wrote:
> Hi, trivial style comments,
>
> On Wed, Jun 20 2012, Venkatraman S wrote:
>> switch (R1_CURRENT_STATE(status)) {
>>
>
> No newline here.
>
>> case R1_STATE_IDLE:
>> case R1_STATE_READY:
>> case R1_STATE_STBY: /* intentio
On Fri, Jun 15, 2012 at 9:38 AM, Saugata Das wrote:
> From: Saugata Das
>
> This is a rework of the existing POWER OFF NOTIFY patch. The current problem
> with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY
> together with SLEEP and misunderstanding on the usage of MMC_POWER_
On Tue, Jun 12, 2012 at 9:49 PM, Yaniv Gardi wrote:
>
>
> = > -Original Message-
> = > From: Dong, Chuanxiao [mailto:chuanxiao.d...@intel.com]
> = > Sent: Monday, June 11, 2012 6:04 AM
> = > To: Yaniv Gardi; 'S, Venkatraman'
> = > Cc: l
On Wed, Jun 13, 2012 at 12:45 AM, wrote:
>
>> S, Venkatraman wrote:
>>> On Mon, Jun 11, 2012 at 1:53 PM, Seungwon Jeon
>>> wrote:
>>> > This patch adds packed command feature of eMMC4.5.
>>> > The maximum number for packing read(or write) is o
On Wed, Jun 13, 2012 at 5:10 PM, Subhash Jadavani
wrote:
> If multi block write operation fails for SD card, during
> error handling we send the SD_APP_SEND_NUM_WR_BLKS (ACMD22)
> to know how many blocks were already programmed by card.
>
> But mmc_sd_num_wr_blocks() function which sends the ACMD2
On Fri, Jun 8, 2012 at 10:09 AM, Jaehoon Chung wrote:
> Enable eMMC background operations (BKOPS) feature.
>
> If URGENT_BKOPS is set after a response, note that BKOPS
> are required. After all I/O requests are finished, run
> BKOPS if required. Should read/write operations be requested
> during B
On Mon, Jun 11, 2012 at 12:50 PM, Ming Lei wrote:
> On Mon, Jun 11, 2012 at 2:21 PM, T Krishnamoorthy, Balaji
> wrote:
>> Hi Ming Lei,
>> Can you let me know if you noticed any write/timeout errors ?
>
> Nothing error logs found during writing.
>
> Below is one of my test case.
>
> root@beagleboa
On Mon, Jun 11, 2012 at 1:53 PM, Seungwon Jeon wrote:
> This patch adds packed command feature of eMMC4.5.
> The maximum number for packing read(or write) is offered
> and exception event relevant to packed command which is
> used for error handling is enabled. If host wants to use
> this feature,
On Tue, Jun 12, 2012 at 1:40 AM, wrote:
>
>> On Mon, Jun 11, 2012 at 7:25 PM, wrote:
>>>
Maya Erez wrote:
>
> > Hi,
> >
> > How can we check the effect?
> > Do you have any result?
> We ran parallel lmdd read and write operations and found out that the
> write
On Tue, Jun 12, 2012 at 1:49 AM, wrote:
>
>> On Sat, Jun 9, 2012 at 8:16 PM, wrote:
>>>
Hi,
How can we check the effect?
Do you have any result?
>>> We ran parallel lmdd read and write operations and found out that the
>>> write packing causes the read throughput to drop fro
On Sat, Jun 9, 2012 at 8:16 PM, wrote:
>
>> Hi,
>>
>> How can we check the effect?
>> Do you have any result?
> We ran parallel lmdd read and write operations and found out that the
> write packing causes the read throughput to drop from 24MB/s to 12MB/s.
Whoa! That's a big drop.
BTW, is there a
On Sat, Jun 9, 2012 at 8:24 PM, wrote:
>
>> On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez wrote:
>>> The test scheduler allows testing a block device by dispatching
>>> specific requests according to the test case and declare PASS/FAIL
>>> according to the requests completion error code
>>>
>> I can
carrier labs from a dedicated
> application through IOCTL that goes directly to the device. Note that no
> change to the FS is required for such operation.
>
> Thanks,
> Yaniv
>
> = > -Original Message-
> = > From: S, Venkatraman [mailto:svenk...@ti.com]
>
On Mon, Jun 11, 2012 at 7:25 PM, wrote:
>
>> Maya Erez wrote:
>>>
>>> > Hi,
>>> >
>>> > How can we check the effect?
>>> > Do you have any result?
>>> We ran parallel lmdd read and write operations and found out that the
>>> write packing causes the read throughput to drop from 24MB/s to 12MB/s.
On Mon, Jun 4, 2012 at 10:05 PM, Marc Dietrich wrote:
> Hi,
>
> somehow I hope this would go away by itself, but it didn't :-( I reported this
> problem some time ago (see: http://www.mail-archive.com/linux-
> m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix.
>
> In addition to
On Thu, Jun 7, 2012 at 8:08 PM, Yaniv Gardi wrote:
> *** adding and exposing SANITIZE capability to the user space via a unique
> IOCTL ***
Well, is this really needed ? As I understand, SANITIZE is identical
to REQ_SECURE + REQ_DISCARD.
Mapping the device function to an existing attribute is mo
On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez wrote:
> The test scheduler allows testing a block device by dispatching
> specific requests according to the test case and declare PASS/FAIL
> according to the requests completion error code
>
I can't get the point. Isn't this possible purely from userspa
On Thu, Jun 7, 2012 at 4:37 PM, Russell King
wrote:
> Remove the private DMA API implementation from omap_hsmmc, making it
> use entirely the DMA engine API.
>
> Signed-off-by: Russell King
Tested this on 4430SDP with rootfs usage, untarring the kernel source
and compiling it natively.
Tested-b
On Thu, May 17, 2012 at 5:41 PM, Seungwon Jeon wrote:
> This patch supports packed write command of eMMC4.5 device.
> Several writes can be grouped in packed command and all data
> of the individual commands can be sent in a single transfer
> on the bus.
>
> Signed-off-by: Seungwon Jeon
> ---
>
On Fri, May 25, 2012 at 1:44 AM, Viswanath Puttagunta wrote:
> Turn off IO & PBIAS cells and then SD card VMMC as soon
> as we get disconnect interrupt. Failure to do so might
> cause current spikes (latch-up issue) which can potentially
> burn the IO cells.
>
> Signed-off-by: Viswanath Puttagunta
On Fri, May 25, 2012 at 1:44 AM, Viswanath Puttagunta wrote:
>
> Enable debounce logic in TWL6030 so that erroneous
> disconnect/connect interrupts will be suppressed.
>
> This will fix issue where SD card is either plugged
> or unplugged very slowly.
>
> Change-Id: Icc3afa4c66b3bc7920f27ff9c9a3f3
On Fri, May 25, 2012 at 1:44 AM, Viswanath Puttagunta wrote:
> This patch set has fixes for SD card hotplug for OMAP SOCs.
>
> Viswanath Puttagunta (3):
> mmc: omap_hsmmc: Errata i705: SD hot unplug
> mmc: omap_hsmmc: Errata: Fix SD card removal detection
> mfd: Enable Debounce logic for SD hot
On Thu, May 3, 2012 at 8:35 PM, Guennadi Liakhovetski
wrote:
> GPIOs can be used in MMC/SD-card slots not only for hotplug detection, but
> also to implement the write-protection pin. Rename cd-gpio helpers to
> slot-gpio to make addition of further slot GPIO functions possible.
>
> Signed-off-by:
On Thu, May 17, 2012 at 7:57 AM, Ming Lei wrote:
> The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
> otherwise the following failure message should be dumped because
> hardware handler is defined as NULL:
>
> [ 3.383483] genirq: Threaded irq requested with handler=NULL and
>
On Tue, May 15, 2012 at 12:10 PM, Subhash Jadavani
wrote:
> On 5/14/2012 8:21 PM, Saugata Das wrote:
>>
>> On 14 May 2012 15:55, Subhash Jadavani wrote:
>>>
>>> On 5/9/2012 8:18 PM, Saugata Das wrote:
From: Saugata Das
This patch adds the support for large sector size of 4KB b
On Mon, May 14, 2012 at 2:09 PM, yongd wrote:
> Set sdio CMD52/53's retry time as MMC_CMD_RETRIES. As a result,
> sdio might benefit from core-internal CMD retry mechanism when
> some errors happen(CRC, etc).
>
> Signed-off-by: yongd
> ---
> drivers/mmc/core/sdio_ops.c | 3 ++-
> 1 file chan
On Wed, May 9, 2012 at 6:15 AM, Minchan Kim wrote:
> On 05/09/2012 01:31 AM, S, Venkatraman wrote:
>
>> On Tue, May 8, 2012 at 1:16 PM, Minchan Kim wrote:
>>> On 05/03/2012 11:22 PM, Venkatraman S wrote:
>>>
>>>> Standard eMMC (Embedded MultiMedia Card)
On Thu, May 10, 2012 at 7:07 PM, Jaehoon Chung wrote:
> Enable eMMC background operations (BKOPS) feature.
>
> If URGENT_BKOPS is set after a response, note that BKOPS
> are required. After all I/O requests are finished, run
> BKOPS if required. Should read/write operations be requested
> during B
On Wed, May 9, 2012 at 8:20 PM, Philip Rakity wrote:
>
> On Apr 13, 2012, at 7:39 AM, Namjae Jeon wrote:
>
>> Hi. Venkatraman.
>>
>> You fixed 10 times. why is it 10 times ?
>> and checking err from mmc_send_status is not needed ? is it also
>> infinite case ?
>>
>> Thanks.
>>
>> 2012/4/13 Venkat
On Wed, May 9, 2012 at 7:41 PM, Chris Ball wrote:
> Hi Venkat,
>
> On Fri, Apr 13 2012, Venkatraman S wrote:
>> The first 3 are straight forward / trivial fixes.
>> The last one is a functional change on how HPI should be invoked
>> on the card. This is required for my future foreground HPI
On Wed, May 9, 2012 at 7:36 PM, wrote:
>> On Wed, May 9, 2012 at 6:47 PM, wrote:
>
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +42
On Wed, May 9, 2012 at 2:05 PM, wrote:
>
>> +static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
>> + struct request *req, unsigned int thpi)
>> +{
>> +
>> + /*
>> + * If some time has elapsed since the issuing of previous write
>> + * command, or if the
On Wed, May 9, 2012 at 6:47 PM, wrote:
>> mmc_execute_hpi should send the HPI command only
>> once, only if the card is in PRG state.
>>
>> According to eMMC spec, the command's completion time is
>> not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
>> out of PRG STATE is guarded by OUT
On Wed, May 9, 2012 at 6:52 PM, wrote:
> Hi,
> I see 2 fixes for existing mmc_interrupt_hpi() function:
> - [PATCH 4/4] mmc: core: Send HPI only till it is successful"
> - [PATCH v2] mmc: core: Fix the HPI execution sequence
>
> They are exclusive. Can you explain how final solution will look l
On Tue, May 8, 2012 at 11:58 AM, mani wrote:
> How about adding the AS_DMPG flag in the file -> address_space when getting
> a filemap_fault()
> so that we can treat the page fault pages as the high priority pages over
> normal read requests.
> How about changing below lines for the support of the
On Tue, May 8, 2012 at 1:16 PM, Minchan Kim wrote:
> On 05/03/2012 11:22 PM, Venkatraman S wrote:
>
>> Standard eMMC (Embedded MultiMedia Card) specification expects to execute
>> one request at a time. If some requests are more important than others, they
>> can't be aborted while the flash proce
Mon, May 7, 2012 at 5:01 AM, Dave Chinner wrote:
> On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote:
>> From: Ilan Smith
>>
>> Add attribute to identify demand paging requests.
>> Mark readpages with demand paging attribute.
>>
>> Signed-off-by: Ilan Smith
>> Signed-off-by: Alex Lem
On Thu, May 3, 2012 at 8:08 PM, Jeff Moyer wrote:
> Venkatraman S writes:
>
>> From: Ilan Smith
>>
>> When exp_swapin and exp_dmpg are set, treat read requests
>> marked with DMPG and SWAPIN as high priority and move to
>> the front of the queue.
>>
> [...]
>> + if (bio_swapin(bio) && blk_qu
On Thu, Apr 19, 2012 at 7:05 PM, Chris Ball wrote:
> Hi,
>
> On Thu, Apr 19 2012, Venkatraman S wrote:
>> mmc_execute_hpi should send the HPI command only
>> once, only if the card is in PRG state.
>>
>> According to eMMC spec, the command's completion time is
>> not dependent on OUT_OF_INTERRUPT_
On Thu, Apr 19, 2012 at 9:59 AM, Chris Ball wrote:
> Hi,
>
> On Fri, Apr 13 2012, Venkatraman S wrote:
>> Try to send HPI only a fixed number of times till it is
>> successful. One successful transfer is enough - but wait
>> till the card comes out of transfer state.
>> Return an error if the card
On Thu, Apr 19, 2012 at 5:34 AM, Chris Ball wrote:
> Hi,
>
> On Wed, Apr 18 2012, Venkatraman S wrote:
>> From: Viswanath Puttagunta
>>
>> Add mmc functional clock frequency to list of
>> internal state variables to display for debug.
>>
>> Signed-off-by: Viswanath Puttagunta
>> Signed-off-by: V
On Thu, Apr 19, 2012 at 7:22 AM, Jaehoon Chung wrote:
> Acked-by: Jaehoon Chung
>
Thanks Jaehoon Chung.
BTW, would you consider looking into the foreground HPI series ?
Chris,
Can you please take this too for 3.5 ?
> On 04/18/2012 11:45 PM, Venkatraman S wrote:
>
>> mmc_execute_hpi should se
On Wed, Apr 18, 2012 at 6:24 PM, Jaehoon Chung wrote:
> On 04/18/2012 05:42 PM, S, Venkatraman wrote:
>
>> On Wed, Apr 18, 2012 at 1:53 PM, Namjae Jeon wrote:
>>> 2012/4/18 S, Venkatraman :
>>>> On Wed, Apr 18, 2012 at 10:15 AM, Namjae Jeon wrote:
>>>&g
On Wed, Apr 18, 2012 at 3:28 PM, Russell King - ARM Linux
wrote:
> On Wed, Apr 18, 2012 at 03:19:11PM +0530, Venkatraman S wrote:
>> From: Russell King - ARM Linux
>
> Please correct this to "Russell King "
>
Ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body
On Wed, Apr 18, 2012 at 1:53 PM, Namjae Jeon wrote:
> 2012/4/18 S, Venkatraman :
>> On Wed, Apr 18, 2012 at 10:15 AM, Namjae Jeon wrote:
>>> 2012/4/18 Jaehoon Chung :
>>>> On 04/18/2012 09:20 AM, Namjae Jeon wrote:
>>>>
>>>>> 2012/4/17 V
On Wed, Apr 18, 2012 at 10:15 AM, Namjae Jeon wrote:
> 2012/4/18 Jaehoon Chung :
>> On 04/18/2012 09:20 AM, Namjae Jeon wrote:
>>
>>> 2012/4/17 Venkatraman S :
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the c
On Sun, Apr 15, 2012 at 8:40 PM, Jae hoon Chung wrote:
> Hi Venkatraman
>
> 2012/4/14 Namjae Jeon :
>> 2012/4/14 S, Venkatraman :
>>> On Fri, Apr 13, 2012 at 8:09 PM, Namjae Jeon wrote:
>>>> Hi. Venkatraman.
>>>>
>>>> You fixed 10
On Tue, Apr 17, 2012 at 6:54 AM, H Hartley Sweeten
wrote:
> Include the linux/mmc/cd-gpio.h header to pickup the prototypes
> for the two exported symbols.
>
> This quiets the sparse warnings:
>
> warning: symbol 'mmc_cd_gpio_request' was not declared. Should it be static?
> warning: symbol 'mmc_c
On Sat, Apr 14, 2012 at 7:11 PM, Russell King - ARM Linux
wrote:
> res can be one of several resources, as this variable is re-used several
> times during probe. This can cause the wrong resource parameters to be
> passed to release_mem_region().
>
> Get the original memory resource before callin
On Fri, Apr 13, 2012 at 8:09 PM, Namjae Jeon wrote:
> Hi. Venkatraman.
>
> You fixed 10 times. why is it 10 times ?
There's no right number - I haven't seen it fail much in my tests but
should allow a few retries.
> and checking err from mmc_send_status is not needed ? is it also
> infinite case
On Sun, Apr 1, 2012 at 10:10 AM, Chris Ball wrote:
> Hi,
>
> On Fri, Mar 16 2012, Venkatraman S wrote:
>> Chris,
>> Here are a group of fixes posted by Felipe and Balaji for the
>> OMAP hsmmc driver in the past few days.
>> I've rebased them to the lastest mmc-next and posted them
>> here ag
On Thu, Mar 22, 2012 at 9:43 PM, Bedia, Vaibhav wrote:
> On Thu, Mar 22, 2012 at 21:36:36, S, Venkatraman wrote:
>> On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav wrote:
>> > On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
>> > [...]
>> >>
>&g
On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav wrote:
> On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
> [...]
>>
>> I see (in 3.3) that the host controller driver does a "return ret" and
>> that means the errors is propagated.
>> Where is the r
1 - 100 of 158 matches
Mail list logo
