—Write replies above—
Hi Linaro Dev Mailman List,
Andy Doan added you as a participant on a request:
"Austin colo offline?"
https://servicedesk.linaro.org/servicedesk/customer/portal/4/SYS-88?sda_source=notification-email
- Systems Support
Renato Golin created this request. Ryan Arn
—Write replies above—
as noted in email to linaro-devel
Renato Golin created this request. Ryan Arnold, Maxim Kuvyrkov, Linaro Dev
Mailman List and 2 more are participating.
You can reply directly to this email to add any further comments or attachments.
See request details and updates for
On 5 August 2015 at 13:20, Max Krummenacher wrote:
> Hi
>
> Can we cherry-pick 723442fbdfaa9da91ea113b381c4d49a2a17ae66 (from
> dizzy) into the fido and master branch.
Certainly! I didn't notice the build breakage because the linaro setup
is picking up the oe-core gdb for reasons unknown. Anyway,
Hi
Can we cherry-pick 723442fbdfaa9da91ea113b381c4d49a2a17ae66 (from
dizzy) into the fido and master branch.
Regards
Max
commit 723442fbdfaa9da91ea113b381c4d49a2a17ae66
Author: Max Krummenacher
Date: Tue Dec 30 16:20:08 2014 +0100
gdb-cross_linaro-7.8: remove elf_prstatus-size.patch
n 11
> April 2013:
>
> https://lkml.org/lkml/2013/4/11/101
>
> Would anyone like to merge the patch to fix this compiling error?
It is queued in mfd-fixes, and I will send a pull request for that either
tonight or tomorrow.
Cheers,
Samuel.
--
Intel Open Source Technology Cen
Hi,
There is a build failure for STE Snowball on "linux-arm-soc-for-next"
branch in Linaro Kernel CI system:
https://ci.linaro.org/jenkins/job/linux-arm-soc-for-next/hwpack=snowball,label=kernel_cloud/46/console
which is caused by:
01:31:32
/mnt/ci_build/workspace/linux-arm-soc-for-next/hwpack/
On 9 October 2012 23:16, Sudeep KarkadaNagesha
wrote:
> Please pull the following changes(v2) for the multiple CPU PMU support
> (re-based to v3.6).
http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=shortlog;h=refs/heads/arm-multi_pmu_v2
___
linar
On 9 October 2012 23:16, Sudeep KarkadaNagesha
wrote:
> Hi Viresh,
>
> Please pull the following changes(v2) for the multiple CPU PMU support
> (re-based to v3.6).
Thanks.. Will be included in this release.
--
viresh
___
linaro-dev mailing list
linaro
Hi Viresh,
Please pull the following changes(v2) for the multiple CPU PMU support
(re-based to v3.6).
Changes v1->v2:
1. Incorporated review comments from Will for few patches(which he will
be queuing for v3.8)
2. Dropped "ARM: perf: register the init functions with the bindings",
still lo
On 14 September 2012 14:56, Sudeep KarkadaNagesha
wrote:
> Please pull the following changes for the multiple CPU PMU support
> (re-based to v3.6-rc5). Few patches in the list below are already
> queued up for 3.7.
>
> Since you have access to internal repository, I am posting patches on
> the sam
On 14 September 2012 14:56, Sudeep KarkadaNagesha
wrote:
> Please pull the following changes for the multiple CPU PMU support
> (re-based to v3.6-rc5). Few patches in the list below are already
> queued up for 3.7.
>
> Since you have access to internal repository, I am posting patches on
> the sam
Hi Viresh,
Please pull the following changes for the multiple CPU PMU support
(re-based to v3.6-rc5). Few patches in the list below are already
queued up for 3.7.
Since you have access to internal repository, I am posting patches on
the same.
Let me know if you face any issues.
On 20/04/12 17:46, Laura Czajkowski wrote:
Hi
I've involved in organising a conference to take place on October 6th
& 7th this year in Limerick Ireland. It's a technical conference
speaking to students, lecturers and businesses involved in open
source. The event is SkyCon which is the Skynet
Hi
I've involved in organising a conference to take place on October 6th &
7th this year in Limerick Ireland. It's a technical conference speaking
to students, lecturers and businesses involved in open source. The
event is SkyCon which is the Skynet computer society 20th birthday.
It's a 2
and stay tuned for future mails on this
topic.
To make things clear: this means that beagle will not go EOL in January.
Sorry for any confusion and have a great christmas time and a happy new
year.
On Thu, Dec 1, 2011 at 8:14 PM, David Zinman wrote:
> A request has been received to disconti
request has been received to discontinue Linaro's support for the
Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle:
* There will be no more LEB or Linaro Developer builds.
* No more testing will be applied by Linaro to the boards a
On 2 December 2011 08:31, Andy Green wrote:
> On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
>>
>> On 2 December 2011 11:19, Dave Martin wrote:
>>>
>>> On Thu, Dec 1, 2011 at 7:14 PM, David Zinman
>>> wrote:
>>>>
&g
On 2 December 2011 13:31, Andy Green wrote:
> On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
>>
>> On 2 December 2011 11:19, Dave Martin wrote:
>>>
>>> On Thu, Dec 1, 2011 at 7:14 PM, David Zinman
>>> wrote:
>>>>
&g
On Fri, Dec 2, 2011 at 5:56 AM, Wookey wrote:
> +++ Dave Martin [2011-12-02 11:19 +]:
>> On Thu, Dec 1, 2011 at 7:14 PM, David Zinman wrote:
>> > A request has been received to discontinue Linaro's support for the
>> > Beagleboard and Beagleboard-xM hardware.
On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
On 2 December 2011 11:19, Dave Martin wrote:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinman wrote:
A request has been received to discontinue Linaro's support for the
Beagleboard and Beagleboard-xM hardware.
The foll
On 2 December 2011 11:19, Dave Martin wrote:
> On Thu, Dec 1, 2011 at 7:14 PM, David Zinman wrote:
>> A request has been received to discontinue Linaro's support for the
>> Beagleboard and Beagleboard-xM hardware.
>>
>> The following conditions will be appli
+++ Dave Martin [2011-12-02 11:19 +]:
> On Thu, Dec 1, 2011 at 7:14 PM, David Zinman wrote:
> > A request has been received to discontinue Linaro's support for the
> > Beagleboard and Beagleboard-xM hardware.
>
> Although they are starting to be replaced
On Thu, Dec 1, 2011 at 7:14 PM, David Zinman wrote:
> A request has been received to discontinue Linaro's support for the
> Beagleboard and Beagleboard-xM hardware.
>
> The following conditions will be applied for the 2012.01 release cycle:
> * There will be no more LEB
On 1 December 2011 19:14, David Zinman wrote:
> A request has been received to discontinue Linaro's support for the
> Beagleboard and Beagleboard-xM hardware.
>
> The following conditions will be applied for the 2012.01 release cycle:
> * There will be no more LEB or Lin
On 1 December 2011 19:14, David Zinman wrote:
> A request has been received to discontinue Linaro's support for the
> Beagleboard and Beagleboard-xM hardware.
This raises the question of what effect this should have on what
we do with the Beagleboard models in Linaro QEMU, since we d
A request has been received to discontinue Linaro's support for the
Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle:
* There will be no more LEB or Linaro Developer builds.
* No more testing will be applied by Linaro to the b
Kishore,
Yeah, could you tell me a little more?
On 15 November 2011 02:22, KISHORE CHORNOOR wrote:
>
>
> We are developing UFS driver on Poseidon Board and we would like to
> release this to Linaro, can you please help us regarding how do we submit
> the UFS driver patch?
>
>
>
> -rgds
>
>
> __
On Sat, October 22, 2011 3:52 pm, Konstantinos Margaritis wrote:
> On 22 October 2011 16:17, Joop Boonen wrote:
>> Hi all,
>>
>> Most of the (ARM) distros are currently working on or in the transition
>> to
>> hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
>> hardfp drivers
Hi all,
Most of the (ARM) distros are currently working on or in the transition to
hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
hardfp drivers yet.
To be able to have a ARM hardfp compiled X Window desktop system/notebook
with 3D support we need hardfp compiled drivers.
On 22 October 2011 16:17, Joop Boonen wrote:
> Hi all,
>
> Most of the (ARM) distros are currently working on or in the transition to
> hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
> hardfp drivers yet.
>
> To be able to have a ARM hardfp compiled X Window desktop system/n
Hi all,
Most of the (ARM) distros are currently working on or in the transition to
hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
hardfp drivers yet.
To be able to have a ARM hardfp compiled X Window desktop system/notebook
with 3D support we need hardfp compiled drivers.
/exynos4.h |1 +
Thanks,
Amit Daniel
On 21 October 2011 02:19, Nicolas Pitre wrote:
> On Thu, 20 Oct 2011, Amit Kachhap wrote:
>
>> Hi Nicolas,
>>
>> This is a request to pull L2 retention cpuidle implementation from
>> git://git.linaro.org/people
On Thu, 20 Oct 2011, Amit Kachhap wrote:
> Hi Nicolas,
>
> This is a request to pull L2 retention cpuidle implementation from
> git://git.linaro.org/people/amitdanielk/linux.git (branch-
> samsung_cpuidle_l2_retention)
>
> The top 5 patches on this refers to the work and
October 2011 14:33, Amit Kachhap wrote:
> Hi Nicolas,
>
> This is a request to pull L2 retention cpuidle implementation from
> git://git.linaro.org/people/amitdanielk/linux.git (branch-
> samsung_cpuidle_l2_retention)
>
> The top 5 patches on this refers to the work and this
Hi Nicolas,
This is a request to pull L2 retention cpuidle implementation from
git://git.linaro.org/people/amitdanielk/linux.git (branch-
samsung_cpuidle_l2_retention)
The top 5 patches on this refers to the work and this is heavily based
on Russell's rmk-next tree. So if it is possible to
ARM cpuidle code to handle this. The commits contained in this
pull request address the other minor issues discussed in the community
submission. I am working on a common ARM implementation will occur
but it will take longer. In the mean time, i.MX platform coul use
this imx cpuidle
t accepted
> as there is some common functionality being duplicated by many of the
> ARM SoC cpuidle implementations and Russell King wants there to be
> common ARM cpuidle code to handle this. The commits contained in this
> pull request address the other minor issues discussed in the commu
implementations and Russell King wants there to be
common ARM cpuidle code to handle this. The commits contained in this
pull request address the other minor issues discussed in the community
submission. I am working on a common ARM implementation will occur
but it will take longer. In the mean time
On Thursday 01 September 2011, John Stultz wrote:
> On Thu, 2011-09-01 at 10:45 +0100, Jon Medhurst (Tixy) wrote:
> > On Wed, 2011-08-31 at 21:05 -0700, John Stultz wrote:
> > > It seems the linaro-dev list isn't configed to avoid mailing folks who
> > > are already recipients of the email.
> >
>
On Fri, 2 Sep 2011 17:36:54 +0530, Vishal Bhoj wrote:
> I had question, Can we commit multiple projects into gerrit in a single
> commit so that review would be easy ?
pfefferz: we struggled above a bit how we can make a multi project
change show up as a single gerrit change/review?
pfefferz:
Hello Vishal,
On Fri, 2 Sep 2011 17:36:54 +0530
Vishal Bhoj wrote:
[]
> I had question, Can we commit multiple projects into gerrit in a
> single commit so that review would be easy ?
Some people wonder if that possible at all either, but Zach said he did
it once ;-). So, up to you to try (but
On Fri, Sep 2, 2011 at 2:06 PM, Vishal Bhoj wrote:
> Hi,
>
>
> Bluetooth is working now on pandaboard now.I could scan and pair with my
> phone.I have not tried file transfer yet.
>
>
Thats really great news Vishal. Well done!
>
> These are multiple commits to gerrit to enable single feature i
Hi,
Bluetooth is working now on pandaboard now.I could scan and pair with my
phone.I have not tried file transfer yet.
These are multiple commits to gerrit to enable single feature i.e bluetooth
on pandaboard.
I had question, Can we commit multiple projects into gerrit in a single
commit so t
On Thu, Sep 01, 2011, Christian Robottom Reis wrote:
> On Wed, Aug 31, 2011 at 09:05:55PM -0700, John Stultz wrote:
> > It seems the linaro-dev list isn't configed to avoid mailing folks who
> > are already recipients of the email. So if you're on linaro-dev and
> > you're also To/CC'ed in the emai
On Thu, 2011-09-01 at 10:45 +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2011-08-31 at 21:05 -0700, John Stultz wrote:
> > It seems the linaro-dev list isn't configed to avoid mailing folks who
> > are already recipients of the email.
>
> Go to http://lists.linaro.org/mailman/options/linaro-dev
>
On Wed, Aug 31, 2011 at 09:05:55PM -0700, John Stultz wrote:
> It seems the linaro-dev list isn't configed to avoid mailing folks who
> are already recipients of the email. So if you're on linaro-dev and
> you're also To/CC'ed in the email, you get it twice (three times if your
> other work email w
On Wed, 2011-08-31 at 21:05 -0700, John Stultz wrote:
> It seems the linaro-dev list isn't configed to avoid mailing folks who
> are already recipients of the email.
Go to http://lists.linaro.org/mailman/options/linaro-dev
and select "Avoid duplicate copies of messages".
Interestingly, for me, t
From: Linus Walleij
This makes the AMBA PrimeCell drivers request padmuxing for
themselves in the same manner as clocks and voltage is currently
requested.
Signed-off-by: Linus Walleij
---
drivers/amba/bus.c | 49 -
include/linux/amba/bus.h
On Wed, 31 Aug 2011, John Stultz wrote:
> So being on vacation for a few days and checking my mail and have found
> an explosion of emails. Unfortunately most of them are duplicates.
>
> It seems the linaro-dev list isn't configed to avoid mailing folks who
> are already recipients of the email.
So being on vacation for a few days and checking my mail and have found
an explosion of emails. Unfortunately most of them are duplicates.
It seems the linaro-dev list isn't configed to avoid mailing folks who
are already recipients of the email. So if you're on linaro-dev and
you're also To/CC'ed
-- Forwarded message --
From: Peter Maydell
Date: 30 August 2011 13:07
Subject: request for testing: qemu-linaro git tree
To: linaro-toolchain
Hi; I've just completed a tricky rebase of qemu-linaro on upstream;
there were several invasive upstream changes which have l
Jagan,
That's awesome. Looping in linaro-dev and David Brown who's the MSM
maintainer.
On 29 August 2011 10:09, jagan <402ja...@gmail.com> wrote:
> Hi,
> I am working as kernel bsp developer in android-2.3 for Qualcomm QSD8X50
> target.
> Currently I am porting linux-3.0 on qsd8250_surf.
> I am a
From: Linus Walleij
This makes the AMBA PrimeCell drivers request padmuxing for
themselves in the same manner as clocks and voltage is currently
requested.
Signed-off-by: Linus Walleij
---
drivers/amba/bus.c | 49 -
include/linux/amba/bus.h
From: Linus Walleij
This makes the AMBA PrimeCell drivers request padmuxing for
themselves in the same manner as clocks and voltage is currently
requested.
Signed-off-by: Linus Walleij
---
drivers/amba/bus.c | 49 -
include/linux/amba/bus.h
Hy Andy,
These are the required changes to make SGX to work with the external
module, as we had for 2.6.38.
These patches are just a forward port of the same patches from 2.6.38,
will try to ping the original authors to see why this is still not
upstream.
Cheers!
The following changes since com
Hi Per,
On Sun, Jul 10 2011, Per Forlin wrote:
> Documentation about the background and the design of mmc non-blocking.
> Host driver guidelines to minimize request preparation overhead.
>
> Signed-off-by: Per Forlin
> Acked-by: Randy Dunlap
Pushed v6 to mmc-next for 3.1, t
From: Amit Kucheria
(Please bear with pull-request for a single patch, but we're creating a
consolidation tree through which we will offer various topic branches for
merge into the Linaro kernel in the future)
The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc:
may implement in order to move work to before and after the actual
>> +mmc_host_ops.request() function is called. In the DMA case pre_req() may
>> do
>> +dma_map_sg() and prepare the DMA descriptor, and post_req() runs
>> +the dma_unmap_sg().
>> +
>
> One question: I
On 07/10/2011 12:21 PM, Per Forlin wrote:
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
Acked-by: Randy Dunlap
---
ChangeLog:
v2: - Minor updates after proofreading comments
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
Acked-by: Randy Dunlap
---
ChangeLog:
v2: - Minor updates after proofreading comments from Chris
v3: - Minor updates after more
On 07/05/2011 11:30 PM, Per Forlin wrote:
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
I'd like to make a couple suggestions on the documentation when
documenting actual function names. In ge
are dma_map_sg and dma_unmap_sg)
> +a request and how fast the memory is. The faster the MMC/SD is
> +the more significant the prepare request time becomes. Roughly the expected
> +performance gain is 5% for large writes and 10% on large reads on a L2 cache
> +platform. In power save mo
On Tue, 5 Jul 2011 21:43:28 +0200 Per Forlin wrote:
> Documentation about the background and the design of mmc non-blocking.
> Host driver guidelines to minimize request preparation overhead.
>
> Signed-off-by: Per Forlin
> ---
It would be better to omit the introductory email
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
Acked-by: Randy Dunlap
---
ChangeLog:
v2: - Minor updates after proofreading comments from Chris
v3: - Minor updates after more
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
---
ChangeLog:
v2: - Minor updates after proofreading comments from Chris
v3: - Minor updates after more comments from Chris
v4
On 5 July 2011 22:27, Randy Dunlap wrote:
> On Tue, 5 Jul 2011 21:43:28 +0200 Per Forlin wrote:
>
>> Documentation about the background and the design of mmc non-blocking.
>> Host driver guidelines to minimize request preparation overhead.
>>
>> Signed-off-by: Per
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
---
Documentation/mmc/00-INDEX |2 +
Documentation/mmc/mmc-async-req.txt | 86 +++
2
changes since v2:
* Minor updates after more comments from Chris
Per Forlin (1):
mmc: documentation of mmc non-blocking request usage and design.
Documentation/mmc/00-INDEX |2 +
Documentation/mmc/mmc-async-req.txt | 86 +++
2 files changed, 88
Documentation about the background and the design of mmc non-blocking.
Host driver guidelines to minimize request preparation overhead.
Signed-off-by: Per Forlin
---
Documentation/mmc/00-INDEX |2 +
Documentation/mmc/mmc-async-req.txt | 86 +++
2
changes since v1:
* Minor updates after proofreading comments from Chris
Per Forlin (1):
mmc: documentation of mmc non-blocking request usage and design.
Documentation/mmc/00-INDEX |2 +
Documentation/mmc/mmc-async-req.txt | 86 +++
2 files
On 5 July 2011 17:24, Chris Ball wrote:
> Hi Per, minor proofreading,
>
Hi Chris,
Thanks for all your comments. I'll update and send out a v2.
Thanks,
Per
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo
Hi Per, minor proofreading,
On Tue, Jul 05 2011, Per Forlin wrote:
> Documentation about the background and the design of mmc non-blocking.
> Host driver guide lines to minimize request preparation over head.
guidelines, overhead
>
> Signed-off-by: Per Forlin
> ---
> Do
Documentation about the background and the design of mmc non-blocking.
Host driver guide lines to minimize request preparation over head.
Signed-off-by: Per Forlin
---
Documentation/mmc/00-INDEX |2 +
Documentation/mmc/mmc-async-req.txt | 85 +++
2
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity. This helps when handling more
than one active block request.
Signed-off-by: Per Forlin
Acked-by: Kyungmin Park
Acked-by: Arnd Bergmann
Reviewed-by: Venkatraman S
T
Add an additional mmc queue request instance to make way for
two active block requests. One request may be active while the
other request is being prepared.
Signed-off-by: Per Forlin
Acked-by: Kyungmin Park
Acked-by: Arnd Bergmann
Reviewed-by: Venkatraman S
Tested-by: Sourav Poddar
Tested-by
The way the request data is organized in the mmc queue struct
it only allows processing of one request at the time.
This patch adds a new struct to hold mmc queue request data such as
sg list, request, blk request and bounce buffers, and updates any functions
depending on the mmc queue struct
Previously there has only been one function mmc_wait_for_req()
to start and wait for a request. This patch adds
* mmc_start_req() - starts a request wihtout waiting
If there is on ongoing request wait for completion
of that request and start the new one and return.
Does not wait for the
The way the request data is organized in the mmc queue struct
it only allows processing of one request at the time.
This patch adds a new struct to hold mmc queue request data such as
sg list, request, blk request and bounce buffers, and updates any functions
depending on the mmc queue struct
Add an additional mmc queue request instance to make way for
two active block requests. One request may be active while the
other request is being prepared.
Signed-off-by: Per Forlin
---
drivers/mmc/card/queue.c | 44 ++--
drivers/mmc/card/queue.h
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity. This helps when handling more
than one active block request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c |
Previously there has only been one function mmc_wait_for_req()
to start and wait for a request. This patch adds
* mmc_start_req() - starts a request wihtout waiting
If there is on ongoing request wait for completion
of that request and start the new one and return.
Does not wait for the
(2011年06月22日 21:08), Eric Miao wrote:
>> Will the same time slot for Friday works for you all? Also thanks for
>> extending
>> the help.
>
> That works for me.
I'm ok with that too.. :)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://l
n; Prashant Deshpande
> Subject: Re: Meeting request
>
> On Wed, Jun 22, 2011 at 3:11 PM, Eric Miao wrote:
> > On Wed, Jun 22, 2011 at 2:01 PM, Ashish Jangam
> > wrote:
> >>> -Original Message-
> >>> From: eric.y.m...@gmail.com [mailto:eric.y.
> Will the same time slot for Friday works for you all? Also thanks for
> extending
> the help.
That works for me.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
t;>>> Previously there has only been one function mmc_wait_for_req()
>>>>> to start and wait for a request. This patch adds
>>>>> * mmc_start_req() - starts a request wihtout waiting
>>>>> If there is on ongoing request wait for completion
&
une 21, 2011 6:55 PM
>>> To: Ashish Jangam
>>> Cc: Ying-Chun Liu (PaulLiu); eric.m...@linaro.org; Steve Cozens; linaro-
>>> d...@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande
>>> Subject: Re: Meeting request
>>>
>>> On Tue, Jun 21
q()
>>>> to start and wait for a request. This patch adds
>>>> * mmc_start_req() - starts a request wihtout waiting
>>>> If there is on ongoing request wait for completion
>>>> of that request and start the new one and return.
>>>>
On Wed, Jun 22, 2011 at 2:15 PM, Per Forlin wrote:
> On 22 June 2011 09:42, Venkatraman S wrote:
>> On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin wrote:
>>> Previously there has only been one function mmc_wait_for_req()
>>> to start and wait for a request. This patc
On 22 June 2011 09:42, Venkatraman S wrote:
> On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin wrote:
>> Previously there has only been one function mmc_wait_for_req()
>> to start and wait for a request. This patch adds
>> * mmc_start_req() - starts a request wihtout waitin
ark Brown; Dajun Chen; Prashant Deshpande
> Subject: Re: Meeting request
>
> On Tue, Jun 21, 2011 at 8:29 PM, Ashish Jangam
> wrote:
> >
> >> -Original Message-
> >> From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of
> Eric
> &g
On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin wrote:
> Previously there has only been one function mmc_wait_for_req()
> to start and wait for a request. This patch adds
> * mmc_start_req() - starts a request wihtout waiting
> If there is on ongoing request wait for completion
>
aulLiu); eric.m...@linaro.org; Steve Cozens; linaro-
>> d...@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande
>> Subject: Re: Meeting request
>>
>> On Tue, Jun 21, 2011 at 8:29 PM, Ashish Jangam
>> wrote:
>> >
>> >> -Original Message
Add an additional mmc queue request instance to make way for
two active block requests. One request may be active while the
other request is being prepared.
Signed-off-by: Per Forlin
---
drivers/mmc/card/queue.c | 44 ++--
drivers/mmc/card/queue.h
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity. This helps when handling more
than one active block request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c |
The way the request data is organized in the mmc queue struct
it only allows processing of one request at the time.
This patch adds a new struct to hold mmc queue request data such as
sg list, request, blk request and bounce buffers, and updates any functions
depending on the mmc queue struct
Previously there has only been one function mmc_wait_for_req()
to start and wait for a request. This patch adds
* mmc_start_req() - starts a request wihtout waiting
If there is on ongoing request wait for completion
of that request and start the new one and return.
Does not wait for the
ark Brown; Dajun Chen; Prashant Deshpande
> Subject: Re: Meeting request
>
> On Tue, Jun 21, 2011 at 6:24 PM, Ashish Jangam
> wrote:
> >> -Original Message-
> >> From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of
> Eric
> >>
(PaulLiu); eric.m...@linaro.org; Steve Cozens; linaro-
>> d...@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande
>> Subject: Re: Meeting request
>>
>> On Tue, Jun 21, 2011 at 6:24 PM, Ashish Jangam
>> wrote:
>> >> -Original Message-
>
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity. This helps when handling more
than one active block request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 170 ---
Add an additional mmc queue request instance to make way for
two active block requests. One request may be active while the
other request is being prepared.
Signed-off-by: Per Forlin
---
drivers/mmc/card/queue.c | 44 ++--
drivers/mmc/card/queue.h
1 - 100 of 201 matches
Mail list logo
