Hi Konstantin
I didn't see the level-3, but have seen the level-2.
URGENT_BKOPS should be triggered when the levels is either 2 or 3.
So maybe you can see the URGENT_BKOPS with level-2.
Best Regards,
Jaehoon Chung
On 02/21/2012 11:21 PM, Jae hoon Chung wrote:
> 2012/2/21 Konstantin Dorfman :
>>
On 02/21/2012 11:00 PM, Yaniv Gardi wrote:
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/mmc/card/block.c | 58 ++---
> drivers/mmc/card/queue.c | 12 -
> include/linux/mmc/card.h |7 +
> include/linux/mmc/host.h |1 +
> 4 files c
On Tue, Feb 21, 2012 at 8:14 PM, Stephen Warren wrote:
> Ignoring WARs like we're discussing, it's typically true that a given pin
> should either be a special function or a GPIO for any given board. If
> we do allow a pin to be owned/used by both, then how do we indicate, on
> a per-board rather
Linus Walleij wrote at Tuesday, February 21, 2012 5:40 AM:
> On Tue, Feb 21, 2012 at 12:06 PM, Russell King - ARM Linux
> wrote:
>
> >> It's a bit kludgy but works and makes sure the pins are only used
> >> for one thing at a time.
> >
> > No. The case which I'm thinking of is for the Assabet au
> Maya Erez wrote:
>> > @@ -1262,21 +1608,32 @@ static int mmc_blk_issue_rw_rq(struct
>> mmc_queue
>> > *mq, struct request *rqc)
>> >int ret = 1, disable_multi = 0, retry = 0, type;
>> >enum mmc_blk_status status;
>> >struct mmc_queue_req *mq_rq;
>> > - struct request *req;
>> > + s
Linus Walleij wrote at Tuesday, February 21, 2012 3:45 AM:
> On Mon, Feb 20, 2012 at 7:27 AM, Stephen Warren wrote:
>
> > Recent pinctrl discussions concluded that gpio_request() and other gpiolib
> > APIs should in fact do whatever is required to mux a GPIO onto pins, by
> > calling pinctrl APIs
Linus Walleij wrote at Tuesday, February 21, 2012 3:42 AM:
> On Mon, Feb 20, 2012 at 8:39 AM, Russell King - ARM Linux
> wrote:
> > On Sun, Feb 19, 2012 at 11:27:42PM -0700, Stephen Warren wrote:
> >> Update gpio.txt based on recent discussions regarding interaction with the
> >> pinctrl subsystem
On 02/21/12 06:00, Yaniv Gardi wrote:
> @@ -922,6 +918,44 @@ out:
> return err ? 0 : 1;
> }
>
> +int mmc_blk_issue_sanitize_rq(struct mmc_queue *mq,
> +struct request *req)
> +{
> + struct mmc_blk_data *md = mq->data;
> + struct mmc_card *card = md->queu
2012/2/21 Konstantin Dorfman :
> Hello Jaehoon,
> I'm testing your patch and will post review soon.
> Have you ever seen urgent BKOPS triggered?
> I have BUGON() on such event and till now never seen it.
Hi Konstantin..
Actually, i didn't urgent BKOPS(level-3), but i have seen the level-2.
I think
Hi Subhash.
Right..sorry..my misunderstanding.
Thank you for your explanation.
Best Regards,
Jaehoon Chung
2012/2/21 Subhash Jadavani :
>
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Jaehoon Chung
>> Sent: Tues
Signed-off-by: Yaniv Gardi
---
drivers/mmc/card/block.c | 58 ++---
drivers/mmc/card/queue.c | 12 -
include/linux/mmc/card.h |7 +
include/linux/mmc/host.h |1 +
4 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/driv
Signed-off-by: Yaniv Gardi
---
block/blk-core.c | 15 ---
block/blk-lib.c | 44
block/blk-merge.c |6 ++
block/elevator.c |8 +++-
block/ioctl.c |9 +
include/
*** exposing SANITIZE capability to the user space via a unique IOCTL ***
changes patch v3:
split the patch into 2 commits - block and mmc/card
added capability MMC_CAP2_SANITIZE to mmc controller
Yaniv Gardi (2):
block: IOCTL support for Sanitize in eMMC v4.5
mmc: card: Adding support for Sa
Hi,
On Tue, Feb 21 2012, Kukjin Kim wrote:
> I created topic branch for this we talked. You can pull that following:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v3.4-for-cjb
>
> If any problems, please kindly let me know.
Pushed to mmc-next, thanks. (I'm expecting
On Tue, Feb 21, 2012 at 1:44 PM, Russell King - ARM Linux
wrote:
>> (It'd probably need the SA1100 to be a bit more strict in using
>> gpiolib in place for the direct assignments though, else the
>> abstractions get a bit pointless anyway.)
>
> That's mostly happened through my recent set of 100
On Tue, Feb 21, 2012 at 12:44:09PM +, Russell King - ARM Linux wrote:
> On Tue, Feb 21, 2012 at 01:40:05PM +0100, Linus Walleij wrote:
> > Of course it assumes the SA1100 being converted to use pin control,
> > I looked at it a bit and it seems simple enough since the GAFR
> > register is a sin
On Tue, Feb 21, 2012 at 01:40:05PM +0100, Linus Walleij wrote:
> Of course it assumes the SA1100 being converted to use pin control,
> I looked at it a bit and it seems simple enough since the GAFR
> register is a single "GPIO or something else"-switch for the GPIOs.
> (It'd probably need the SA110
On Tuesday 21 February 2012 05:50 PM, Russell King - ARM Linux wrote:
On Tue, Feb 21, 2012 at 05:43:54PM +0530, S, Venkatraman wrote:
On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak wrote:
@@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
m
On Tue, Feb 21, 2012 at 12:06 PM, Russell King - ARM Linux
wrote:
>> It's a bit kludgy but works and makes sure the pins are only used
>> for one thing at a time.
>
> No. The case which I'm thinking of is for the Assabet audio, where
> we have the following situation.
OK... (thanks for the expl
On Tue, Feb 21, 2012 at 05:43:54PM +0530, S, Venkatraman wrote:
> On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak wrote:
> > @@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> > *host)
> > mmc_slot(host).ocr_mask = ocr_value;
> > } else
On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak wrote:
>
> MMC1 is not the only instance that can be used/wired for SD.
> So remove this assumption from the driver.
>
> Now that all the mmc id based usage is removed, get rid
> of all the DEVID defines and also the 'id' field from the
> omap_hsmmc_
Chris Ball wrote:
>
> Hi,
>
Hi,
> On Thu, Feb 16 2012, Kukjin Kim wrote:
> > I mean if I or you create topic branch for this whole series, can be
> > merged into both tree for avoiding conflicts with further working. Of
> > course, the topic branch don't have to rebase after merging into each
>
On Tue, Feb 21, 2012 at 11:41:31AM +0100, Linus Walleij wrote:
> I remember this case very well and we designed for it, so it should
> be handled by pin control and GPIO thusly:
>
> Example: use pins 1,2 as I2C, then convert them to GPIO for a while
> then back again:
>
> // This call looks up a
On Mon, Feb 20, 2012 at 7:27 AM, Stephen Warren wrote:
> Update gpio.txt based on recent discussions regarding interaction with the
> pinctrl subsystem.
>
> Previously, gpio_request() was described as explicitly not performing any
> required mux setup operations etc.
>
> Now, gpio_request() is ex
On Mon, Feb 20, 2012 at 7:27 AM, Stephen Warren wrote:
> Recent pinctrl discussions concluded that gpio_request() and other gpiolib
> APIs should in fact do whatever is required to mux a GPIO onto pins, by
> calling pinctrl APIs if required. This change implements this for the
> Tegra GPIO driver
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of hyeonsu@samsung.com
> Sent: Friday, February 17, 2012 3:45 PM
> To: linux-mmc@vger.kernel.org; c...@laptop.org
> Cc: kyungmin.p...@samsung.com; jh80.ch...@samsung.com;
On Mon, Feb 20, 2012 at 8:39 AM, Russell King - ARM Linux
wrote:
> On Sun, Feb 19, 2012 at 11:27:42PM -0700, Stephen Warren wrote:
>> Update gpio.txt based on recent discussions regarding interaction with the
>> pinctrl subsystem.
>>
>> Previously, gpio_request() was described as explicitly not pe
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Jaehoon Chung
> Sent: Tuesday, February 21, 2012 10:02 AM
> To: linux-mmc
> Cc: Chris Ball; Kyungmin Park; hyeonsu@samsung.com
> Subject: [PATCH] mmc: core: fix wrong
Hello Jaehoon,
I'm testing your patch and will post review soon.
Have you ever seen urgent BKOPS triggered?
I have BUGON() on such event and till now never seen it.
--
Konstantin Dorfman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Fo
29 matches
Mail list logo
