Re: Announcement: Monthly Milestones
On 20 June 2011 23:52, Michael Hope michael.h...@linaro.org wrote: Some minor nits. The names are product-version-.mm - some of the slides use -mm. fixed. It should be dot. I see the first release as having an implicit -0 so the first respin is -1, not -2. fixed. Thanks Michael. Cheers, Fathi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Meeting request
On Wed, Jun 22, 2011 at 2:01 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 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, 2011 at 8:29 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 5:52 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, 2011 at 6:24 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 3:28 PM To: Ashish Jangam; Ying-Chun Liu (PaulLiu) Cc: eric.m...@linaro.org; Steve Cozens; linaro-dev@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande Subject: Re: Meeting request On Tue, Jun 21, 2011 at 5:57 PM, Eric Miao eric.m...@canonical.com wrote: On Tue, Jun 21, 2011 at 4:21 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: Hi Eric, I recently saw your mail to Dajun, on your people eagerness to get the patches upstream soon. We also hold the same vision to get the patches upstream as quick as possible. In this regard we like to have a discussion so please let us know your convenient time. Please note that as of now we do not have any technical issues on patches but there is a need to understand the patch submission process so we can focus our discussion accordingly. Thanks Ashish to bring this forword. I'm in TZ GMT+8, and I think Mark is in Scottland, which is GMT+1? Anyway, tomorrow and Friday will be fine to me, depending on your location and a time slot that works for all of us, there could be not many choices :- ) Include Paul Liu, he's working on the PMIC upstreaming as well, he's in the same TZ as I am. Below are time slots in preference order (hopefully for all) for Wednesday meeting:- 1) GMT+8 == 05:00pm; GMT+1 == 10:00am; GMT+5.5 == 02:30pm 2) GMT+8 == 04:00pm; GMT+1 == 09:00am; GMT+5.5 == 01:30pm 3) GMT+8 == 06:00pm; GMT+1 == 11:00am; GMT+5.5 == 03:30pm Let me know which time slot suits you all. Hi Ashish, Option 1) works for me and Paul Liu. Thanks. Kindly share your contact details so that we can get connected. You can use my linaro email address of cuz: eric.m...@linaro.org For today's conference please dial:- +91 20 6652 5000 - press 1 - press 80867 - press 1. For any assistance please call the telecom team on 91 20 66525000. Kindly note, that this is not a Toll free number. In case your all not comfortable with this number then give me your phone number so that I can put all of us in a conference call. I can use skype to dial in. Yet not really sure about the other guys. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 01/11] mmc: add non-blocking mmc request function
On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin per.for...@linaro.org 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
of that request and start the new one and return.
Does not wait for the new command to complete.
This patch also adds new function members in struct mmc_host_ops
only called from core.c
* pre_req - asks the host driver to prepare for the next job
* post_req - asks the host driver to clean up after a completed job
The intention is to use pre_req() and post_req() to do cache maintenance
while a request is active. pre_req() can be called while a request is active
to minimize latency to start next job. post_req() can be used after the next
job is started to clean up the request. This will minimize the host driver
request end latency. post_req() is typically used before ending the block
request and handing over the buffer to the block layer.
Add a host-private member in mmc_data to be used by
pre_req to mark the data. The host driver will then
check this mark to see if the data is prepared or not.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/core.c | 110 +
include/linux/mmc/core.h | 6 ++-
include/linux/mmc/host.h | 21 +
3 files changed, 126 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 68091dd..c82fa3b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -198,9 +198,106 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
static void mmc_wait_done(struct mmc_request *mrq)
{
- complete(mrq-done_data);
+ complete(mrq-completion);
}
+static void __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
+{
+ init_completion(mrq-completion);
+ mrq-done = mmc_wait_done;
+ mmc_start_request(host, mrq);
+}
+
+static void mmc_wait_for_req_done(struct mmc_host *host,
+ struct mmc_request *mrq)
+{
+ wait_for_completion(mrq-completion);
+}
+
+/**
+ * mmc_pre_req - Prepare for a new request
+ * @host: MMC host to prepare command
+ * @mrq: MMC request to prepare for
+ * @is_first_req: true if there is no previous started request
+ * that may run in parellel to this call, otherwise false
+ *
+ * mmc_pre_req() is called in prior to mmc_start_req() to let
+ * host prepare for the new request. Preparation of a request may be
+ * performed while another request is running on the host.
+ */
+static void mmc_pre_req(struct mmc_host *host, struct mmc_request *mrq,
+ bool is_first_req)
+{
+ if (host-ops-pre_req)
+ host-ops-pre_req(host, mrq, is_first_req);
+}
+
+/**
+ * mmc_post_req - Post process a completed request
+ * @host: MMC host to post process command
+ * @mrq: MMC request to post process for
+ * @err: Error, if non zero, clean up any resources made in pre_req
+ *
+ * Let the host post process a completed request. Post processing of
+ * a request may be performed while another reuqest is running.
+ */
+static void mmc_post_req(struct mmc_host *host, struct mmc_request *mrq,
+ int err)
+{
+ if (host-ops-post_req)
+ host-ops-post_req(host, mrq, err);
+}
+
+/**
+ * mmc_start_req - start a non-blocking request
+ * @host: MMC host to start command
+ * @areq: async request to start
+ * @error: out parameter returns 0 for success, otherwise non zero
+ *
+ * Start a new MMC custom command request for a host.
+ * If there is on ongoing async request wait for completion
+ * of that request and start the new one and return.
+ * Does not wait for the new request to complete.
+ *
+ * Returns the completed async request, NULL in case of none completed.
+ */
+struct mmc_async_req *mmc_start_req(struct mmc_host *host,
+ struct mmc_async_req *areq, int *error)
+{
+ int err = 0;
+ struct mmc_async_req *data = host-areq;
+
+ /* Prepare a new request */
+ if (areq)
+ mmc_pre_req(host, areq-mrq, !host-areq);
+
+ if (host-areq) {
+ mmc_wait_for_req_done(host, host-areq-mrq);
+ err = host-areq-err_check(host-card, host-areq);
+ if (err) {
+ mmc_post_req(host, host-areq-mrq, 0);
+ if (areq)
+ mmc_post_req(host, areq-mrq, -EINVAL);
+
+ host-areq = NULL;
+ goto out;
In this sequence, would the return value (data) have the previous areq ?
Is that intentional - doesn't seem
Re: Launchpad blueprints for the 11.11 work - part 1
On 22/06/11 09:16, Joe Yu wrote: Hi Ilias, This is Joe Yu from ARM Shanghai. We're very interested in adding a TR blueprint to Linaro 12.05 for a DirectFB project targeted at optimization for ARM with Mali GPU and NEON. What shall we do? Shall we create a TR blueprint ourselves at lanchpad? Could you please provide some directions? Another question is: Can we attend Linaro Platform Sprint in August? We're also working on x264 codec optimization and we want to discuss it in that meeting face to face with some of you. Thanks, Hello Joe! TR blueprints are generally for larger umbrella activities - usually those get broken into the so called engineering (you may also see the term work) blueprints upon which the TR blueprints depend in order to cover the themes for the cycle. For example I would consider this work to fall under the umbrella of a NEON TR blueprint, being one of the areas where work is being done by you. I am currently updating the TR blueprints as per the information I got from Kurt, so I will ping you when the update is complete and what to do next. Related to August sprint: I believe that you should attend. Please visit https://wiki.linaro.org/Events/2011-08-LDS for more information, registration and instructions on what you'd need to do. Let me know if you need anything else, as said I will contact you later today with more info for the blueprint work. Cheers -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Meeting request
-Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 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, 2011 at 8:29 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 5:52 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, 2011 at 6:24 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 3:28 PM To: Ashish Jangam; Ying-Chun Liu (PaulLiu) Cc: eric.m...@linaro.org; Steve Cozens; linaro-dev@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande Subject: Re: Meeting request On Tue, Jun 21, 2011 at 5:57 PM, Eric Miao eric.m...@canonical.com wrote: On Tue, Jun 21, 2011 at 4:21 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: Hi Eric, I recently saw your mail to Dajun, on your people eagerness to get the patches upstream soon. We also hold the same vision to get the patches upstream as quick as possible. In this regard we like to have a discussion so please let us know your convenient time. Please note that as of now we do not have any technical issues on patches but there is a need to understand the patch submission process so we can focus our discussion accordingly. Thanks Ashish to bring this forword. I'm in TZ GMT+8, and I think Mark is in Scottland, which is GMT+1? Anyway, tomorrow and Friday will be fine to me, depending on your location and a time slot that works for all of us, there could be not many choices :- ) Include Paul Liu, he's working on the PMIC upstreaming as well, he's in the same TZ as I am. Below are time slots in preference order (hopefully for all) for Wednesday meeting:- 1) GMT+8 == 05:00pm; GMT+1 == 10:00am; GMT+5.5 == 02:30pm 2) GMT+8 == 04:00pm; GMT+1 == 09:00am; GMT+5.5 == 01:30pm 3) GMT+8 == 06:00pm; GMT+1 == 11:00am; GMT+5.5 == 03:30pm Let me know which time slot suits you all. Hi Ashish, Option 1) works for me and Paul Liu. Thanks. Kindly share your contact details so that we can get connected. You can use my linaro email address of cuz: eric.m...@linaro.org For today's conference please dial:- +91 20 6652 5000 - press 1 - press 80867 - press 1. For any assistance please call the telecom team on 91 20 66525000. Kindly note, that this is not a Toll free number. In case your all not comfortable with this number then give me your phone number so that I can put all of us in a conference call. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Launchpad blueprints for the 11.11 work - part 1
On 22/06/11 10:43, Ilias Biris wrote: On 22/06/11 09:16, Joe Yu wrote: Hi Ilias, TR blueprints are generally for larger umbrella activities - usually those get broken into the so called engineering (you may also see the term work) blueprints upon which the TR blueprints depend in order to cover the themes for the cycle. Hi Joe, I have now created for you a blueprint to capture the requirements for the directfb optimization work for 12.05. Keep in mind that Linaro is now moving to a monthly cadence, with quarterly reviews of the plans and requirements. So it's possible your work can be targeted earlier than May.2012. The blueprint is in https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/engr-multimedia-directfb-neon-optimization Blueprint instructions: https://wiki.linaro.org/Process/Blueprints Your task would be to use the blueprint whiteboard to summarize any requirements or action items. You could also start writing a more detailed specification using the Linaro wiki. Let me know if you are ready to proceed writing a spec now, so that I can create a template wiki page which you can use to fill in the technical details. There is a clear separation between a blueprint (in launchpad, just a summary-assignment-timeline info, holds the work items list), and specification (in wiki, can be a lengthier technical account of what the design decisions are) If you let me know your launchpad id I can also add you as assignee of the said blueprint above. Thanks! -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH android/toolchain/build] Fix host-libbfd installation problem caused by undefined $(INSTALL)
Merged in AOSP: http://android.git.kernel.org/?p=toolchain/build.git;a=commit;h=7ee395d10100fc9ed2c03c49b949033600082a4f On 27 May 2011 01:29, Jim Huang jim.hu...@linaro.org wrote: While executing target install-host-libbfd, the build system complains: make -C libbfd-binutils-2.20.1/bfd install \ bfdlibdir=/tmp/android-toolchain-eabi/lib bfdincludedir=/tmp/android-toolchain-eabi/include \ -m 644 libbfd-binutils-2.20.1/intl/libintl.a \ /tmp/android-toolchain-eabi/lib \ -m 644 libbfd-binutils-2.20.1/libiberty/libiberty.a \ /tmp/android-toolchain-eabi/lib /bin/sh: line 2: -m: command not found The problem was caused by undefined $(INSTALL). The patch attempts to configure `install' program by autotool in order to set $(INSTALL) properly and replace $(INSTALL) -m 644 with multi-platform friendly $(INSTALL_DATA). Code Review: https://review.source.android.com/#change,23179 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 01/11] mmc: add non-blocking mmc request function
On 22 June 2011 09:42, Venkatraman S svenk...@ti.com wrote:
On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin per.for...@linaro.org 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
of that request and start the new one and return.
Does not wait for the new command to complete.
This patch also adds new function members in struct mmc_host_ops
only called from core.c
* pre_req - asks the host driver to prepare for the next job
* post_req - asks the host driver to clean up after a completed job
The intention is to use pre_req() and post_req() to do cache maintenance
while a request is active. pre_req() can be called while a request is active
to minimize latency to start next job. post_req() can be used after the next
job is started to clean up the request. This will minimize the host driver
request end latency. post_req() is typically used before ending the block
request and handing over the buffer to the block layer.
Add a host-private member in mmc_data to be used by
pre_req to mark the data. The host driver will then
check this mark to see if the data is prepared or not.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/core.c | 110
+
include/linux/mmc/core.h | 6 ++-
include/linux/mmc/host.h | 21 +
3 files changed, 126 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 68091dd..c82fa3b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -198,9 +198,106 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
static void mmc_wait_done(struct mmc_request *mrq)
{
- complete(mrq-done_data);
+ complete(mrq-completion);
}
+static void __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
+{
+ init_completion(mrq-completion);
+ mrq-done = mmc_wait_done;
+ mmc_start_request(host, mrq);
+}
+
+static void mmc_wait_for_req_done(struct mmc_host *host,
+ struct mmc_request *mrq)
+{
+ wait_for_completion(mrq-completion);
+}
+
+/**
+ * mmc_pre_req - Prepare for a new request
+ * @host: MMC host to prepare command
+ * @mrq: MMC request to prepare for
+ * @is_first_req: true if there is no previous started request
+ * that may run in parellel to this call, otherwise
false
+ *
+ * mmc_pre_req() is called in prior to mmc_start_req() to let
+ * host prepare for the new request. Preparation of a request may be
+ * performed while another request is running on the host.
+ */
+static void mmc_pre_req(struct mmc_host *host, struct mmc_request *mrq,
+ bool is_first_req)
+{
+ if (host-ops-pre_req)
+ host-ops-pre_req(host, mrq, is_first_req);
+}
+
+/**
+ * mmc_post_req - Post process a completed request
+ * @host: MMC host to post process command
+ * @mrq: MMC request to post process for
+ * @err: Error, if non zero, clean up any resources made in pre_req
+ *
+ * Let the host post process a completed request. Post processing of
+ * a request may be performed while another reuqest is running.
+ */
+static void mmc_post_req(struct mmc_host *host, struct mmc_request *mrq,
+ int err)
+{
+ if (host-ops-post_req)
+ host-ops-post_req(host, mrq, err);
+}
+
+/**
+ * mmc_start_req - start a non-blocking request
+ * @host: MMC host to start command
+ * @areq: async request to start
+ * @error: out parameter returns 0 for success, otherwise non zero
+ *
+ * Start a new MMC custom command request for a host.
+ * If there is on ongoing async request wait for completion
+ * of that request and start the new one and return.
+ * Does not wait for the new request to complete.
+ *
+ * Returns the completed async request, NULL in case of none completed.
+ */
+struct mmc_async_req *mmc_start_req(struct mmc_host *host,
+ struct mmc_async_req *areq, int *error)
+{
+ int err = 0;
+ struct mmc_async_req *data = host-areq;
+
+ /* Prepare a new request */
+ if (areq)
+ mmc_pre_req(host, areq-mrq, !host-areq);
+
+ if (host-areq) {
+ mmc_wait_for_req_done(host, host-areq-mrq);
+ err = host-areq-err_check(host-card, host-areq);
+ if (err) {
+ mmc_post_req(host, host-areq-mrq, 0);
+ if (areq)
+ mmc_post_req(host, areq-mrq, -EINVAL);
+
+ host-areq = NULL;
+ goto out;
In this sequence, would the return value
[PATCH android/bionic] strftime: Use snprintf() instead of sprintf()
Code Review: https://review.source.android.com/#change,23997 From afd989ca9f3415df9807847745e854522866f66f Mon Sep 17 00:00:00 2001 From: Jim Huang jim.hu...@linaro.org Date: Thu, 16 Jun 2011 22:35:16 +0800 Subject: [PATCH 1/2] strftime: Use snprintf() instead of sprintf() Change-Id: I112ac012894eddc96e5f3e77cb87bb300596e3ce --- libc/tzcode/strftime.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libc/tzcode/strftime.c b/libc/tzcode/strftime.c index ab713fb..d35d58a 100644 --- a/libc/tzcode/strftime.c +++ b/libc/tzcode/strftime.c @@ -407,9 +407,9 @@ label: tm = *t; mkt = mktime64(tm); if (TYPE_SIGNED(time64_t)) -(void) sprintf(buf, %lld, +(void) snprintf(buf, %lld, sizeof(buf), (long long) mkt); -else(void) sprintf(buf, %llu, +else(void) snprintf(buf, %llu, sizeof(buf), (unsigned long long) mkt); pt = _add(buf, pt, ptlim, modifier); } -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 01/11] mmc: add non-blocking mmc request function
On Wed, Jun 22, 2011 at 2:15 PM, Per Forlin per.for...@linaro.org wrote:
On 22 June 2011 09:42, Venkatraman S svenk...@ti.com wrote:
On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin per.for...@linaro.org 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
of that request and start the new one and return.
Does not wait for the new command to complete.
This patch also adds new function members in struct mmc_host_ops
only called from core.c
* pre_req - asks the host driver to prepare for the next job
* post_req - asks the host driver to clean up after a completed job
The intention is to use pre_req() and post_req() to do cache maintenance
while a request is active. pre_req() can be called while a request is active
to minimize latency to start next job. post_req() can be used after the next
job is started to clean up the request. This will minimize the host driver
request end latency. post_req() is typically used before ending the block
request and handing over the buffer to the block layer.
Add a host-private member in mmc_data to be used by
pre_req to mark the data. The host driver will then
check this mark to see if the data is prepared or not.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/core.c | 110
+
include/linux/mmc/core.h | 6 ++-
include/linux/mmc/host.h | 21 +
3 files changed, 126 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 68091dd..c82fa3b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -198,9 +198,106 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
static void mmc_wait_done(struct mmc_request *mrq)
{
- complete(mrq-done_data);
+ complete(mrq-completion);
}
+static void __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
+{
+ init_completion(mrq-completion);
+ mrq-done = mmc_wait_done;
+ mmc_start_request(host, mrq);
+}
+
+static void mmc_wait_for_req_done(struct mmc_host *host,
+ struct mmc_request *mrq)
+{
+ wait_for_completion(mrq-completion);
+}
+
+/**
+ * mmc_pre_req - Prepare for a new request
+ * @host: MMC host to prepare command
+ * @mrq: MMC request to prepare for
+ * @is_first_req: true if there is no previous started request
+ * that may run in parellel to this call, otherwise
false
+ *
+ * mmc_pre_req() is called in prior to mmc_start_req() to let
+ * host prepare for the new request. Preparation of a request may be
+ * performed while another request is running on the host.
+ */
+static void mmc_pre_req(struct mmc_host *host, struct mmc_request *mrq,
+ bool is_first_req)
+{
+ if (host-ops-pre_req)
+ host-ops-pre_req(host, mrq, is_first_req);
+}
+
+/**
+ * mmc_post_req - Post process a completed request
+ * @host: MMC host to post process command
+ * @mrq: MMC request to post process for
+ * @err: Error, if non zero, clean up any resources made in pre_req
+ *
+ * Let the host post process a completed request. Post processing of
+ * a request may be performed while another reuqest is running.
+ */
+static void mmc_post_req(struct mmc_host *host, struct mmc_request *mrq,
+ int err)
+{
+ if (host-ops-post_req)
+ host-ops-post_req(host, mrq, err);
+}
+
+/**
+ * mmc_start_req - start a non-blocking request
+ * @host: MMC host to start command
+ * @areq: async request to start
+ * @error: out parameter returns 0 for success, otherwise non zero
+ *
+ * Start a new MMC custom command request for a host.
+ * If there is on ongoing async request wait for completion
+ * of that request and start the new one and return.
+ * Does not wait for the new request to complete.
+ *
+ * Returns the completed async request, NULL in case of none completed.
+ */
+struct mmc_async_req *mmc_start_req(struct mmc_host *host,
+ struct mmc_async_req *areq, int *error)
+{
+ int err = 0;
+ struct mmc_async_req *data = host-areq;
+
+ /* Prepare a new request */
+ if (areq)
+ mmc_pre_req(host, areq-mrq, !host-areq);
+
+ if (host-areq) {
+ mmc_wait_for_req_done(host, host-areq-mrq);
+ err = host-areq-err_check(host-card, host-areq);
+ if (err) {
+ mmc_post_req(host, host-areq-mrq, 0);
+ if (areq)
+ mmc_post_req(host, areq-mrq, -EINVAL);
+
+ host-areq = NULL;
+
[PATCH android/bionic] time: Improve C99 compliance
Quote from Linux Programmer's Manual:
If t is non-NULL, the return value is also stored in the memory
pointed to by t.
Code Review:
https://review.source.android.com/#change,23998
From 30a19b9cdbe509d62c7d4c5df9a6daab13ff8857 Mon Sep 17 00:00:00 2001
From: Jim Huang jim.hu...@linaro.org
Date: Thu, 16 Jun 2011 22:40:10 +0800
Subject: [PATCH 2/2] time: Improve C99 compliance
Quote from Linux Programmer's Manual:
If t is non-NULL, the return value is also stored in the memory
pointed to by t.
Change-Id: I8cb66b67e5f34c536ce2f0db76a6dc337c42ea3f
---
libc/unistd/time.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/libc/unistd/time.c b/libc/unistd/time.c
index 13d7366..7b450c7 100644
--- a/libc/unistd/time.c
+++ b/libc/unistd/time.c
@@ -34,12 +34,15 @@ time_t
time(time_t *t)
{
struct timeval tt;
+ time_t ret;
if (gettimeofday(tt, (struct timezone *)0) 0)
- return (-1);
- if (t)
- *t = (time_t)tt.tv_sec;
- return (tt.tv_sec);
+ ret = -1;
+ else
+ ret = tt.tv_sec;
+ if (t != NULL)
+ *t = ret;
+ return ret;
}
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 01/11] mmc: add non-blocking mmc request function
On 22 June 2011 10:53, S, Venkatraman svenk...@ti.com wrote:
On Wed, Jun 22, 2011 at 2:15 PM, Per Forlin per.for...@linaro.org wrote:
On 22 June 2011 09:42, Venkatraman S svenk...@ti.com wrote:
On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin per.for...@linaro.org 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
of that request and start the new one and return.
Does not wait for the new command to complete.
This patch also adds new function members in struct mmc_host_ops
only called from core.c
* pre_req - asks the host driver to prepare for the next job
* post_req - asks the host driver to clean up after a completed job
The intention is to use pre_req() and post_req() to do cache maintenance
while a request is active. pre_req() can be called while a request is
active
to minimize latency to start next job. post_req() can be used after the
next
job is started to clean up the request. This will minimize the host driver
request end latency. post_req() is typically used before ending the block
request and handing over the buffer to the block layer.
Add a host-private member in mmc_data to be used by
pre_req to mark the data. The host driver will then
check this mark to see if the data is prepared or not.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/core.c | 110
+
include/linux/mmc/core.h | 6 ++-
include/linux/mmc/host.h | 21 +
3 files changed, 126 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 68091dd..c82fa3b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -198,9 +198,106 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
static void mmc_wait_done(struct mmc_request *mrq)
{
- complete(mrq-done_data);
+ complete(mrq-completion);
}
+static void __mmc_start_req(struct mmc_host *host, struct mmc_request
*mrq)
+{
+ init_completion(mrq-completion);
+ mrq-done = mmc_wait_done;
+ mmc_start_request(host, mrq);
+}
+
+static void mmc_wait_for_req_done(struct mmc_host *host,
+ struct mmc_request *mrq)
+{
+ wait_for_completion(mrq-completion);
+}
+
+/**
+ * mmc_pre_req - Prepare for a new request
+ * @host: MMC host to prepare command
+ * @mrq: MMC request to prepare for
+ * @is_first_req: true if there is no previous started request
+ * that may run in parellel to this call, otherwise
false
+ *
+ * mmc_pre_req() is called in prior to mmc_start_req() to let
+ * host prepare for the new request. Preparation of a request may be
+ * performed while another request is running on the host.
+ */
+static void mmc_pre_req(struct mmc_host *host, struct mmc_request *mrq,
+ bool is_first_req)
+{
+ if (host-ops-pre_req)
+ host-ops-pre_req(host, mrq, is_first_req);
+}
+
+/**
+ * mmc_post_req - Post process a completed request
+ * @host: MMC host to post process command
+ * @mrq: MMC request to post process for
+ * @err: Error, if non zero, clean up any resources made in pre_req
+ *
+ * Let the host post process a completed request. Post processing of
+ * a request may be performed while another reuqest is running.
+ */
+static void mmc_post_req(struct mmc_host *host, struct mmc_request *mrq,
+ int err)
+{
+ if (host-ops-post_req)
+ host-ops-post_req(host, mrq, err);
+}
+
+/**
+ * mmc_start_req - start a non-blocking request
+ * @host: MMC host to start command
+ * @areq: async request to start
+ * @error: out parameter returns 0 for success, otherwise non zero
+ *
+ * Start a new MMC custom command request for a host.
+ * If there is on ongoing async request wait for completion
+ * of that request and start the new one and return.
+ * Does not wait for the new request to complete.
+ *
+ * Returns the completed async request, NULL in case of none
completed.
+ */
+struct mmc_async_req *mmc_start_req(struct mmc_host *host,
+ struct mmc_async_req *areq, int *error)
+{
+ int err = 0;
+ struct mmc_async_req *data = host-areq;
+
+ /* Prepare a new request */
+ if (areq)
+ mmc_pre_req(host, areq-mrq, !host-areq);
+
+ if (host-areq) {
+ mmc_wait_for_req_done(host, host-areq-mrq);
+ err = host-areq-err_check(host-card, host-areq);
+ if (err) {
+ mmc_post_req(host, host-areq-mrq, 0);
+ if (areq)
+ mmc_post_req(host,
Re: [RFC] Add Arm cpu topology definition
On Tue, Jun 21, 2011 at 01:36:15PM -0700, Stephen Boyd wrote: On 06/16/2011 11:54 PM, Vincent Guittot wrote: On 16 June 2011 21:40, Stephen Boyd sb...@codeaurora.org wrote: The ARM ARM says these fields are IMPLEMENTATION DEFINED meaning that different vendors may attribute different meaning to these fields if they wish. Does that mean this should be a platform_*() function? The ARM ARM also provides a recommended use of the fields of this register and the TRM of each Cortex adds some details. On the cortex A9, each platform can only set the value of the Cluster ID with the CLUSTERID pins. I have tried to consolidate the value of MPIDR across several platforms and they all match with the description. Have you got an example of a MPIDR register which doesn't match with the implementation ? Not that I know of. I'm more concerned with how the ARM ARM has two recommended usages for these fields depending on virtualization or not. I suppose we can handle that issue when it arises (or does your implementation already handle that?) According to the ARM ARM: MPIDR provides a mechanism with up to three levels of affinity information, but the meaning of those levels of affinity is entirely IMPLEMENTATION DEFINED. So we can't really tell the meaning of the affinity bits. There are two recommended ways indeed (with or without virtualisation) which are not that different with regards to the topology (just introducing another level for virtual CPUs). But I think a more general solution would be for the CPU topology to be provided via the FDT. -- Catalin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Meeting request
On Wed, Jun 22, 2011 at 3:11 PM, Eric Miao eric.m...@canonical.com wrote: On Wed, Jun 22, 2011 at 2:01 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 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, 2011 at 8:29 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 5:52 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, 2011 at 6:24 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 3:28 PM To: Ashish Jangam; Ying-Chun Liu (PaulLiu) Cc: eric.m...@linaro.org; Steve Cozens; linaro-dev@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande Subject: Re: Meeting request On Tue, Jun 21, 2011 at 5:57 PM, Eric Miao eric.m...@canonical.com wrote: On Tue, Jun 21, 2011 at 4:21 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: Hi Eric, I recently saw your mail to Dajun, on your people eagerness to get the patches upstream soon. We also hold the same vision to get the patches upstream as quick as possible. In this regard we like to have a discussion so please let us know your convenient time. Please note that as of now we do not have any technical issues on patches but there is a need to understand the patch submission process so we can focus our discussion accordingly. Thanks Ashish to bring this forword. I'm in TZ GMT+8, and I think Mark is in Scottland, which is GMT+1? Anyway, tomorrow and Friday will be fine to me, depending on your location and a time slot that works for all of us, there could be not many choices :- ) Include Paul Liu, he's working on the PMIC upstreaming as well, he's in the same TZ as I am. Below are time slots in preference order (hopefully for all) for Wednesday meeting:- 1) GMT+8 == 05:00pm; GMT+1 == 10:00am; GMT+5.5 == 02:30pm 2) GMT+8 == 04:00pm; GMT+1 == 09:00am; GMT+5.5 == 01:30pm 3) GMT+8 == 06:00pm; GMT+1 == 11:00am; GMT+5.5 == 03:30pm Let me know which time slot suits you all. Hi Ashish, Option 1) works for me and Paul Liu. Thanks. Kindly share your contact details so that we can get connected. You can use my linaro email address of cuz: eric.m...@linaro.org For today's conference please dial:- +91 20 6652 5000 - press 1 - press 80867 - press 1. For any assistance please call the telecom team on 91 20 66525000. Kindly note, that this is not a Toll free number. In case your all not comfortable with this number then give me your phone number so that I can put all of us in a conference call. I can use skype to dial in. Yet not really sure about the other guys. Guys, Sorry seems I have problem to get my skype back online. Can we reschedule this to another time slot? And thanks Ashish to bring this up - this really helps a lot for us to co-work. I'll send some basic ideas a bit later. - eric ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ARM Blog : Linux debug with the DS-5 Debugger
a recently-released blog describing Linux debug with the DS-5 Debugger: http://blogs.arm.com/software-enablement/486-porting-linux-made-easy-with-ds-5/ This was originally triggered by successful use of DS-5 in porting Linux to Tuscan dual-A9 platform. Ta -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 02/11] omap_hsmmc: add support for pre_req and post_req
On 22 June 2011 10:51, Nickolay Nickolaev nicknickol...@gmail.com wrote: Hello, this one's causing me compilation trouble troubles when CONFIG_DMA_ENGINE is not defined. I don't see this issue when I compile the kernel for a Pandaboard without CONFIG_DMA_ENGINE being set. Could you please clarify or show me your build log? I don't see how host-next_data.cookie is connected to DMA_ENGINE. On Wed, Jun 22, 2011 at 2:38 AM, Per Forlin per.for...@linaro.org wrote: @@ -2077,6 +2155,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-mapbase = res-start; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; + host-next_data.cookie = 1; platform_set_drvdata(pdev, host); INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect); -- 1.7.4.1 Maybe we can wrap it in a function as the others. regards, Nikolay Nikolaev Regards, Per ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
OMAP3 Core dpll fix
Hi Nicolas, Can you pls pull below patch from 2.6.39 mainline kernel into 11.5 Linaro kernel? This would fix some of the DVFS related issues seen on OMAP3. Patch: commit 5fd2a84ab3c8b87176e25db1d98c5cc34043a669 Author: Avinash H.M avinas...@ti.com OMAP3: set the core dpll clk rate in its set_rate function Vishwa ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 02/11] omap_hsmmc: add support for pre_req and post_req
On 22 June 2011 11:31, Per Forlin per.for...@linaro.org wrote: On 22 June 2011 10:51, Nickolay Nickolaev nicknickol...@gmail.com wrote: Hello, this one's causing me compilation trouble troubles when CONFIG_DMA_ENGINE is not defined. I don't see this issue when I compile the kernel for a Pandaboard without CONFIG_DMA_ENGINE being set. Could you please clarify or show me your build log? I don't see how host-next_data.cookie is connected to DMA_ENGINE. I think you are referring to the mmci-patch. I'll fix the issue in mmci. On Wed, Jun 22, 2011 at 2:38 AM, Per Forlin per.for...@linaro.org wrote: @@ -2077,6 +2155,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-mapbase = res-start; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; + host-next_data.cookie = 1; platform_set_drvdata(pdev, host); INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect); -- 1.7.4.1 Maybe we can wrap it in a function as the others. regards, Nikolay Nikolaev Regards, Per ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Launchpad blueprints for the 11.11 work - part 1
On 22/06/11 10:43, Ilias Biris wrote: On 22/06/11 09:16, Joe Yu wrote: Hi Ilias, TR blueprints are generally for larger umbrella activities - usually those get broken into the so called engineering (you may also see the term work) blueprints upon which the TR blueprints depend in order to cover the themes for the cycle. Hi Joe, I have now created for you a blueprint to capture the requirements for the directfb optimization work for 12.05. Keep in mind that Linaro is now moving to a monthly cadence, with quarterly reviews of the plans and requirements. So it's possible your work can be targeted earlier than May.2012. The blueprint is in https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/engr-multimedia -directfb-neon-optimization Blueprint instructions: https://wiki.linaro.org/Process/Blueprints Your task would be to use the blueprint whiteboard to summarize any requirements or action items. You could also start writing a more detailed specification using the Linaro wiki. Let me know if you are ready to proceed writing a spec now, so that I can create a template wiki page which you can use to fill in the technical details. There is a clear separation between a blueprint (in launchpad, just a summary-assignment-timeline info, holds the work items list), and specification (in wiki, can be a lengthier technical account of what the design decisions are) If you let me know your launchpad id I can also add you as assignee of the said blueprint above. HI Ilias, This is Kui, working on DirectFB optimization, ARM Shanghai. Pls help to add me as assignee, my launchpad id is kui.zheng Then, I'll draft blueprint and spec. Thanks -Kui -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Please help us setup patches.linaro.org
On Tue, Jun 21, 2011 at 03:27:07PM -0300, Guilherme Salgado wrote: Hi Dave, Thanks for reporting it. This was fallout from when IS restarted the machine to add more disk, and they're working on it right now. It should be fixed RSN. It seems to be working again now. Thanks! ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 03/11] mmci: implement pre_req() and post_req()
On 22 June 2011 01:38, Per Forlin per.for...@linaro.org wrote: pre_req() runs dma_map_sg() and prepares the dma descriptor for the next mmc data transfer. post_req() runs dma_unmap_sg. If not calling pre_req() before mmci_request(), mmci_request() will prepare the cache and dma just like it did it before. It is optional to use pre_req() and post_req() for mmci. Signed-off-by: Per Forlin per.for...@linaro.org --- drivers/mmc/host/mmci.c | 146 ++ drivers/mmc/host/mmci.h | 8 +++ 2 files changed, 141 insertions(+), 13 deletions(-) ... @@ -1005,6 +1123,8 @@ static int __devinit mmci_probe(struct amba_device *dev, host-gpio_cd = -ENOSYS; host-gpio_cd_irq = -1; + host-next_data.cookie = 1; + Doesn't compile without DMA_ENGINE. Issue reported by Nickolay. I simply move the initialization to mmci_dma_setup. I will update in the next patchset. @@ -215,6 +215,9 @@ static void __devinit mmci_dma_setup(struct mmci_host *host) + /* initialize pre request cookie */ + host-next_data.cookie = 1; + @@ -1121,8 +1124,6 @@ static int __devinit mmci_probe(struct amba_device *dev, - host-next_data.cookie = 1; ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2] Add ARM cpu topology definition
Some nits below.
After you fix them, you can add a
Reviewed-by: Amit Kucheria amit.kuche...@linaro.org
On 11 Jun 20, Vincent Guittot wrote:
The affinity between ARM processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency.We can define the
^^ space between full-stop
and next word
cpu topology of ARM platform, which is used by sched_mc and sched_smt.
change to 'that is then'
The default state of sched_mc and sched_smt config is disable.
Change to sched_mc and sched_smt is disabled by default
When enable, the behavior of the scheduler can be modified with
^ enabled
sched_mc_power_savings and sched_smt_power_savings sysfs interfaces.
Changes since v1 :
* Update the commit message
* Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h
* Modify header of arch/arm/kernel/topology.c
* Modify tests and manipulation of MPIDR's bitfields
* Modify the place and dependancy of the config
* Modify Noop functions
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
arch/arm/Kconfig| 25 +++
arch/arm/include/asm/cputype.h |6 ++
arch/arm/include/asm/topology.h | 33 +
arch/arm/kernel/Makefile|1 +
arch/arm/kernel/smp.c |6 ++
arch/arm/kernel/topology.c | 145
+++
6 files changed, 216 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/kernel/topology.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..c7b4ff9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1344,6 +1344,31 @@ config SMP_ON_UP
If you don't know what to do here, say Y.
+config ARM_CPU_TOPOLOGY
+ bool Support cpu topology definition
+ depends on SMP CPU_V7
+ default y
+ help
+ Support ARM cpu topology definition. The MPIDR register defines
+ affinity between processors which is used to set the cpu
^ change to
'which is then
used to describe the'
+ topology of an ARM System.
+
+config SCHED_MC
+ bool Multi-core scheduler support
+ depends on ARM_CPU_TOPOLOGY
+ help
+ Multi-core scheduler support improves the CPU scheduler's decision
+ making when dealing with multi-core CPU chips at a cost of slightly
+ increased overhead in some places. If unsure say N here.
+
+config SCHED_SMT
+ bool SMT scheduler support
+ depends on ARM_CPU_TOPOLOGY
+ help
+ Improves the CPU scheduler's decision making when dealing with
+ MultiThreading at a cost of slightly increased overhead in some
+ places. If unsure say N here.
+
config HAVE_ARM_SCU
bool
depends on SMP
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index cd4458f..cb47d28 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -8,6 +8,7 @@
#define CPUID_CACHETYPE 1
#define CPUID_TCM2
#define CPUID_TLBTYPE3
+#define CPUID_MPIDR 5
#define CPUID_EXT_PFR0 c1, 0
#define CPUID_EXT_PFR1 c1, 1
@@ -70,6 +71,11 @@ static inline unsigned int __attribute_const__
read_cpuid_tcmstatus(void)
return read_cpuid(CPUID_TCM);
}
+static inline unsigned int __attribute_const__ read_cpuid_mpidr(void)
+{
+ return read_cpuid(CPUID_MPIDR);
+}
+
/*
* Intel's XScale3 core supports some v6 features (supersections, L2)
* but advertises itself as v5 as it does not support the v6 ISA. For
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index accbd7c..63a7454 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -1,6 +1,39 @@
#ifndef _ASM_ARM_TOPOLOGY_H
#define _ASM_ARM_TOPOLOGY_H
+#ifdef CONFIG_ARM_CPU_TOPOLOGY
+
+#include linux/cpumask.h
+
+struct cputopo_arm {
+ int thread_id;
+ int core_id;
+ int socket_id;
+ cpumask_t thread_sibling;
+ cpumask_t core_sibling;
+};
+
+extern struct cputopo_arm cpu_topology[NR_CPUS];
+
+#define topology_physical_package_id(cpu)(cpu_topology[cpu].socket_id)
+#define topology_core_id(cpu)(cpu_topology[cpu].core_id)
+#define topology_core_cpumask(cpu) ((cpu_topology[cpu].core_sibling))
+#define topology_thread_cpumask(cpu) ((cpu_topology[cpu].thread_sibling))
These #defines are not used anywhere.
+#define mc_capable() (cpu_topology[0].socket_id != -1)
+#define smt_capable()(cpu_topology[0].thread_id != -1)
Neither are these.
+void init_cpu_topology(void);
+void store_cpu_topology(unsigned int cpuid);
+const struct cpumask *cpu_coregroup_mask(unsigned
[PATCH] mmci: move dmaengine dependent access from mmci_probe to mmci_dma_setup
From: Per Forlin per.for...@linaro.org Move dmaengine dependent host-next_data variable from mmci_probe to mmci_dma_setup. The mmci fails to compile without CONFIG_DMA_ENGINE if using next_data in mmci_probe. Signed-off-by: Per Forlin per.for...@linaro.org --- drivers/mmc/host/mmci.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index f8c837b..04b9856 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -213,6 +213,9 @@ static void __devinit mmci_dma_setup(struct mmci_host *host) return; } + /* initialize pre request cookie */ + host-next_data.cookie = 1; + /* Try to acquire a generic DMA engine slave channel */ dma_cap_zero(mask); dma_cap_set(DMA_SLAVE, mask); @@ -1123,8 +1126,6 @@ static int __devinit mmci_probe(struct amba_device *dev, host-gpio_cd = -ENOSYS; host-gpio_cd_irq = -1; - host-next_data.cookie = 1; - host-hw_designer = amba_manf(dev); host-hw_revision = amba_rev(dev); dev_dbg(mmc_dev(mmc), designer ID = 0x%02x\n, host-hw_designer); -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Add Arm cpu topology definition
On 11 Jun 22, Catalin Marinas wrote: On Tue, Jun 21, 2011 at 01:36:15PM -0700, Stephen Boyd wrote: On 06/16/2011 11:54 PM, Vincent Guittot wrote: On 16 June 2011 21:40, Stephen Boyd sb...@codeaurora.org wrote: The ARM ARM says these fields are IMPLEMENTATION DEFINED meaning that different vendors may attribute different meaning to these fields if they wish. Does that mean this should be a platform_*() function? The ARM ARM also provides a recommended use of the fields of this register and the TRM of each Cortex adds some details. On the cortex A9, each platform can only set the value of the Cluster ID with the CLUSTERID pins. I have tried to consolidate the value of MPIDR across several platforms and they all match with the description. Have you got an example of a MPIDR register which doesn't match with the implementation ? Not that I know of. I'm more concerned with how the ARM ARM has two recommended usages for these fields depending on virtualization or not. I suppose we can handle that issue when it arises (or does your implementation already handle that?) According to the ARM ARM: MPIDR provides a mechanism with up to three levels of affinity information, but the meaning of those levels of affinity is entirely IMPLEMENTATION DEFINED. So we can't really tell the meaning of the affinity bits. There are two recommended ways indeed (with or without virtualisation) which are not that different with regards to the topology (just introducing another level for virtual CPUs). But I think a more general solution would be for the CPU topology to be provided via the FDT. Agreed. That will be the next step. We decided on doing it this way to allow non-DT-enabled platforms to be able to use the feature and to allow DT-enabled platforms to settle down in the mean time. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 01/11] mmc: add non-blocking mmc request function
On Wed, Jun 22, 2011 at 2:38 PM, Per Forlin per.for...@linaro.org wrote:
On 22 June 2011 10:53, S, Venkatraman svenk...@ti.com wrote:
On Wed, Jun 22, 2011 at 2:15 PM, Per Forlin per.for...@linaro.org wrote:
On 22 June 2011 09:42, Venkatraman S svenk...@ti.com wrote:
On Wed, Jun 22, 2011 at 5:08 AM, Per Forlin per.for...@linaro.org 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
of that request and start the new one and return.
Does not wait for the new command to complete.
This patch also adds new function members in struct mmc_host_ops
only called from core.c
* pre_req - asks the host driver to prepare for the next job
* post_req - asks the host driver to clean up after a completed job
The intention is to use pre_req() and post_req() to do cache maintenance
while a request is active. pre_req() can be called while a request is
active
to minimize latency to start next job. post_req() can be used after the
next
job is started to clean up the request. This will minimize the host driver
request end latency. post_req() is typically used before ending the block
request and handing over the buffer to the block layer.
Add a host-private member in mmc_data to be used by
pre_req to mark the data. The host driver will then
check this mark to see if the data is prepared or not.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/core.c | 110
+
include/linux/mmc/core.h | 6 ++-
include/linux/mmc/host.h | 21 +
3 files changed, 126 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 68091dd..c82fa3b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -198,9 +198,106 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
static void mmc_wait_done(struct mmc_request *mrq)
{
- complete(mrq-done_data);
+ complete(mrq-completion);
}
+static void __mmc_start_req(struct mmc_host *host, struct mmc_request
*mrq)
+{
+ init_completion(mrq-completion);
+ mrq-done = mmc_wait_done;
+ mmc_start_request(host, mrq);
+}
+
+static void mmc_wait_for_req_done(struct mmc_host *host,
+ struct mmc_request *mrq)
+{
+ wait_for_completion(mrq-completion);
+}
+
+/**
+ * mmc_pre_req - Prepare for a new request
+ * @host: MMC host to prepare command
+ * @mrq: MMC request to prepare for
+ * @is_first_req: true if there is no previous started request
+ * that may run in parellel to this call, otherwise
false
+ *
+ * mmc_pre_req() is called in prior to mmc_start_req() to let
+ * host prepare for the new request. Preparation of a request may be
+ * performed while another request is running on the host.
+ */
+static void mmc_pre_req(struct mmc_host *host, struct mmc_request *mrq,
+ bool is_first_req)
+{
+ if (host-ops-pre_req)
+ host-ops-pre_req(host, mrq, is_first_req);
+}
+
+/**
+ * mmc_post_req - Post process a completed request
+ * @host: MMC host to post process command
+ * @mrq: MMC request to post process for
+ * @err: Error, if non zero, clean up any resources made in pre_req
+ *
+ * Let the host post process a completed request. Post processing of
+ * a request may be performed while another reuqest is running.
+ */
+static void mmc_post_req(struct mmc_host *host, struct mmc_request *mrq,
+ int err)
+{
+ if (host-ops-post_req)
+ host-ops-post_req(host, mrq, err);
+}
+
+/**
+ * mmc_start_req - start a non-blocking request
+ * @host: MMC host to start command
+ * @areq: async request to start
+ * @error: out parameter returns 0 for success, otherwise non zero
+ *
+ * Start a new MMC custom command request for a host.
+ * If there is on ongoing async request wait for completion
+ * of that request and start the new one and return.
+ * Does not wait for the new request to complete.
+ *
+ * Returns the completed async request, NULL in case of none
completed.
+ */
+struct mmc_async_req *mmc_start_req(struct mmc_host *host,
+ struct mmc_async_req *areq, int
*error)
+{
+ int err = 0;
+ struct mmc_async_req *data = host-areq;
+
+ /* Prepare a new request */
+ if (areq)
+ mmc_pre_req(host, areq-mrq, !host-areq);
+
+ if (host-areq) {
+ mmc_wait_for_req_done(host, host-areq-mrq);
+ err = host-areq-err_check(host-card, host-areq);
+ if (err) {
+ mmc_post_req(host, host-areq-mrq, 0);
+
Re: Patches from the Linaro Android Team team
Hi Jim, (I'm CCing linaro-dev@ because I figure others might have similar questions) This is because the android patches are going to the 'Unknown' project[1], which is ignored when generating the statistics[2]. We currently can't automatically detect the correct project for such patches because they are all sent to linaro-dev@ instead of their own mailing list like other projects. Maybe we could try and detect the correct project from the subject's prefix (e.g. [android/bionic]), but even then I suspect these patches are not really going to AOSP, in which case they wouldn't be included in the statistics either (much like the gcc-linaro and linaro-kernel projects). If I'm mistaken we can just create android projects and move the patches from the Unknown project to them. A thread I started recently (Subject: Please help us setup patches.linaro.org) on linaro-dev@ has more information on how to do that. [1] http://patches.linaro.org/patchwork/project/other-unknown/list/?state=* [2] http://patches.linaro.org/faq Cheers, On Wed, 2011-06-22 at 18:22 +0800, Jim Huang wrote: hi Guilherme, I just checked the stat of Patches from the Linaro Android Team team: http://patches.linaro.org/team/linaro-android/ I am quite confused about the number. I did submit patches to linaro-dev and Cc. to patc...@linaro.org and you can find out the recent merged patches here: (Recently closed) https://review.source.android.com//#dashboard,1002471 Is there any problem for stat? Or, can I help to improve it? Thanks, -jserv -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: This is a digitally signed message part ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2] Add ARM cpu topology definition
On 22 June 2011 12:14, Amit Kucheria amit.kuche...@linaro.org wrote:
Some nits below.
After you fix them, you can add a
Reviewed-by: Amit Kucheria amit.kuche...@linaro.org
On 11 Jun 20, Vincent Guittot wrote:
The affinity between ARM processors is defined in the MPIDR register.
We can identify which processors are in the same cluster,
and which ones have performance interdependency.We can define the
^^ space between full-stop
and next word
cpu topology of ARM platform, which is used by sched_mc and sched_smt.
change to 'that is then'
The default state of sched_mc and sched_smt config is disable.
Change to sched_mc and sched_smt is disabled by default
When enable, the behavior of the scheduler can be modified with
^ enabled
sched_mc_power_savings and sched_smt_power_savings sysfs interfaces.
Changes since v1 :
* Update the commit message
* Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h
* Modify header of arch/arm/kernel/topology.c
* Modify tests and manipulation of MPIDR's bitfields
* Modify the place and dependancy of the config
* Modify Noop functions
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
arch/arm/Kconfig | 25 +++
arch/arm/include/asm/cputype.h | 6 ++
arch/arm/include/asm/topology.h | 33 +
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/smp.c | 6 ++
arch/arm/kernel/topology.c | 145
+++
6 files changed, 216 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/kernel/topology.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..c7b4ff9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1344,6 +1344,31 @@ config SMP_ON_UP
If you don't know what to do here, say Y.
+config ARM_CPU_TOPOLOGY
+ bool Support cpu topology definition
+ depends on SMP CPU_V7
+ default y
+ help
+ Support ARM cpu topology definition. The MPIDR register defines
+ affinity between processors which is used to set the cpu
^ change to
'which is then
used to describe the'
+ topology of an ARM System.
+
+config SCHED_MC
+ bool Multi-core scheduler support
+ depends on ARM_CPU_TOPOLOGY
+ help
+ Multi-core scheduler support improves the CPU scheduler's decision
+ making when dealing with multi-core CPU chips at a cost of slightly
+ increased overhead in some places. If unsure say N here.
+
+config SCHED_SMT
+ bool SMT scheduler support
+ depends on ARM_CPU_TOPOLOGY
+ help
+ Improves the CPU scheduler's decision making when dealing with
+ MultiThreading at a cost of slightly increased overhead in some
+ places. If unsure say N here.
+
config HAVE_ARM_SCU
bool
depends on SMP
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index cd4458f..cb47d28 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -8,6 +8,7 @@
#define CPUID_CACHETYPE 1
#define CPUID_TCM 2
#define CPUID_TLBTYPE 3
+#define CPUID_MPIDR 5
#define CPUID_EXT_PFR0 c1, 0
#define CPUID_EXT_PFR1 c1, 1
@@ -70,6 +71,11 @@ static inline unsigned int __attribute_const__
read_cpuid_tcmstatus(void)
return read_cpuid(CPUID_TCM);
}
+static inline unsigned int __attribute_const__ read_cpuid_mpidr(void)
+{
+ return read_cpuid(CPUID_MPIDR);
+}
+
/*
* Intel's XScale3 core supports some v6 features (supersections, L2)
* but advertises itself as v5 as it does not support the v6 ISA. For
diff --git a/arch/arm/include/asm/topology.h
b/arch/arm/include/asm/topology.h
index accbd7c..63a7454 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -1,6 +1,39 @@
#ifndef _ASM_ARM_TOPOLOGY_H
#define _ASM_ARM_TOPOLOGY_H
+#ifdef CONFIG_ARM_CPU_TOPOLOGY
+
+#include linux/cpumask.h
+
+struct cputopo_arm {
+ int thread_id;
+ int core_id;
+ int socket_id;
+ cpumask_t thread_sibling;
+ cpumask_t core_sibling;
+};
+
+extern struct cputopo_arm cpu_topology[NR_CPUS];
+
+#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id)
+#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
+#define topology_core_cpumask(cpu) ((cpu_topology[cpu].core_sibling))
+#define topology_thread_cpumask(cpu) ((cpu_topology[cpu].thread_sibling))
These #defines are not used anywhere.
They are used in topology.c driver and sched.c
+#define mc_capable() (cpu_topology[0].socket_id != -1)
+#define smt_capable() (cpu_topology[0].thread_id != -1)
Neither are these.
They are used in
Re: [RFC PATCH v2] Add ARM cpu topology definition
On Wed, Jun 22, 2011 at 3:20 PM, Vincent Guittot vincent.guit...@linaro.org wrote: On 22 June 2011 12:14, Amit Kucheria amit.kuche...@linaro.org wrote: + +#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id) +#define topology_core_id(cpu) (cpu_topology[cpu].core_id) +#define topology_core_cpumask(cpu) ((cpu_topology[cpu].core_sibling)) +#define topology_thread_cpumask(cpu) ((cpu_topology[cpu].thread_sibling)) These #defines are not used anywhere. They are used in topology.c driver and sched.c +#define mc_capable() (cpu_topology[0].socket_id != -1) +#define smt_capable() (cpu_topology[0].thread_id != -1) Neither are these. They are used in sched.c Ahh, sorry for the noise. Documentation/cputopology.txt is most illuminating. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Meeting request
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
Re: OMAP3 Core dpll fix
On Wed, Jun 22, 2011 at 3:50 PM, Amit Kucheria amit.kuche...@linaro.org wrote: On 11 Jun 22, Vishwanath Sripathy wrote: Hi Nicolas, Can you pls pull below patch from 2.6.39 mainline kernel into 11.5 Linaro kernel? This would fix some of the DVFS related issues seen on OMAP3. Patch: commit 5fd2a84ab3c8b87176e25db1d98c5cc34043a669 Author: Avinash H.M avinas...@ti.com OMAP3: set the core dpll clk rate in its set_rate function Vishwa After this fix, can CPU_FREQ be re-enabled on OMAP3? cpufreq as such will work as expected and will scale MPU and L3 frequency based on system load. However if any driver is not requesting for the required l3 frequency, then we might start seeing issues at driver level (like FIFO underflow etc due to l3 running at lower rate). So my suggestion is not to keep ondemand as the default governor and if someone wants to experiment, they can enable it. Vishwa Vishwa /Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcement: Monthly Milestones
It would be nice if there was some example of how this new process works overall. The Toolchain team has been mentioned in some discussions as following the practice with the blueprints/milestone pages and deliverable component tarballs. Perhaps someone from the release team could prepare a set of examples from Launchpad to cover the items/steps in the presentation and send to all? Thanks, Ilias On 21/06/11 01:58, Joey Stanford wrote: Hi Gang, As you have no doubt heard, we're moving to monthly milestones. In an effort to set some perspective and also to answer any questions you might have, Alexander and I have built a presentation that describes what's happen in detail. We've also added an extensive list of FAQs at the end of the presentation. I've attached the presentation as a PDF or you can view it online at: https://docs.google.com/a/linaro.org/present/edit?id=0ATjleYdzD02NZGcyNTM4amZfNjNoZ3dianE3cQhl=en_USpli=1 If you have any questions, please contact your Team Lead and/or Project Manager. They will raise any issues to Alexander, myself, and the rest of the Team Leads. Enjoy! Joey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OMAP3 Core dpll fix
On Wed, 22 Jun 2011, Vishwanath Sripathy wrote: On Wed, Jun 22, 2011 at 3:50 PM, Amit Kucheria amit.kuche...@linaro.org wrote: On 11 Jun 22, Vishwanath Sripathy wrote: Hi Nicolas, Can you pls pull below patch from 2.6.39 mainline kernel into 11.5 Linaro kernel? This would fix some of the DVFS related issues seen on OMAP3. Patch: commit 5fd2a84ab3c8b87176e25db1d98c5cc34043a669 Author: Avinash H.M avinas...@ti.com OMAP3: set the core dpll clk rate in its set_rate function Vishwa After this fix, can CPU_FREQ be re-enabled on OMAP3? cpufreq as such will work as expected and will scale MPU and L3 frequency based on system load. However if any driver is not requesting for the required l3 frequency, then we might start seeing issues at driver level (like FIFO underflow etc due to l3 running at lower rate). So my suggestion is not to keep ondemand as the default governor and if someone wants to experiment, they can enable it. I merged the fix to linaro-2.6.38 and pushed out. What about linaro-2.6.39 which is the base for the 11.06 release due next week? Does it work properly there? The above commit is already included, but I would like to know how things are working wrt power management in that kernel. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Public IRC logs now available
Hi, http://irclogs.linaro.org/ Logs are now kept from our public channels so that you can refer back to previous converations and catch up on things that happened while you were away if needed. They can also come up in google searches which can be useful. If you would like a channel added/removed from the logging then please file an RT ticket by emailing lin...@rt.canonical.com and explaining your request. Note that only public channels can currently be logged. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RFC: Community Mumble
Hi Gang, In the past few days I've received a few requests to allow community members access to our Mumble server. I don't feel comfortable adding in the large and open linaro-community team so I am considering making a linaro-community-mumble team to allow for access. Right now you have to be in ~linaro to have access to Mumble. 1) I'd like to hear your comments on this, especially if you have alternative suggestions. 2) If there are community members who should have mumble access, can you please send me their Launchpad IDs so I can start assembling a list. Thanks, Joey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Community Mumble
Joey, I think this is great! We have a combination need for this: 1) Upstream project interaction where phone-type interaction is desirable. 2) The working group meeting where representatives from member companies who are not Linaro assignees want to participate (for replacing the old conference line). I can send you a short list of launchpad IDs for these two categories. cheers, Jesse On Wed, Jun 22, 2011 at 8:29 AM, Joey Stanford j...@linaro.org wrote: Hi Gang, In the past few days I've received a few requests to allow community members access to our Mumble server. I don't feel comfortable adding in the large and open linaro-community team so I am considering making a linaro-community-mumble team to allow for access. Right now you have to be in ~linaro to have access to Mumble. 1) I'd like to hear your comments on this, especially if you have alternative suggestions. 2) If there are community members who should have mumble access, can you please send me their Launchpad IDs so I can start assembling a list. Thanks, Joey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver
Hi Grant,
On 20 June 2011 22:13, Grant Likely grant.lik...@secretlab.ca wrote:
Okay, this is getting ugly (not your fault, but this pattern has
become too common. Can you craft and post a patch that adds the
following functions to drivers/of/base.c and include/linux/of.h
/* offset in cells, not bytes */
int dt_decode_u32(struct *property, int offset, u32 *out_val)
{
if (!property || !property-value)
return -EINVAL;
if ((offset + 1) * 4 property-length)
return -EINVAL;
*out_val = of_read_number(property-value + (offset * 4), 1);
return 0;
}
int dt_decode_u64(struct *property, int offset, u64 *out_val)
{
...
}
int dt_decode_string(struct *property, int index, char **out_string);
{
...
}
Plus a set of companion functions:
int dt_getprop_u32(struct device_node *np, char *propname, int offset,
u32 *out_val)
{
return dt_decode_u32(of_find_property(np, propname, NULL),
offset, out_val);
}
int dt_getprop_u64(struct *device_node, char *propname, int offset,
u64 *out_val);
{
...
}
int dt_getprop_string(struct *device_node, char *propname, int index,
char **out_string);
{
...
}
Then you'll be able to simply do the following to decode each
property, with fifosize being left alone if the property cannot be
found or decoded:
dt_getprop_u32(pdev-dev.of_node, samsung,fifosize, fifosize);
I have added the functions as you have suggested and the diff is
listed below. Could you please review the diff and suggest any changes
required.
drivers/of/base.c | 129
include/linux/of.h | 10
2 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 632ebae..73f0144 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -596,6 +596,135 @@ struct device_node
*of_find_node_by_phandle(phandle handle)
EXPORT_SYMBOL(of_find_node_by_phandle);
/**
+ * of_read_property_u32 - Reads a indexed 32-bit property value
+ * @prop: property to read from.
+ * @offset:cell number to read.
+ * value: returned cell value
+ *
+ * Returns a indexed 32-bit value of a property cell, -EINVAL in case the cell
+ * does not exist
+ */
+int of_read_property_u32(struct property *prop, u32 offset, u32 *value)
+{
+ if (!prop || !prop-value)
+ return -EINVAL;
+ if ((offset + 1) * 4 prop-length)
+ return -EINVAL;
+
+ *value = of_read_ulong(prop-value + (offset * 4), 1);
+ return 0;
+}
+EXPORT_SYMBOL(of_read_property_u32);
+
+/**
+ * of_getprop_u32 - Find a property in a device node and read a 32-bit value
+ * @np:device node from which the property value is to be read.
+ * @propname name of the property to be searched.
+ * @offset:cell number to read.
+ * @value: returned value of the cell
+ *
+ * Search for a property in a device node and read a indexed 32-bit value of a
+ * property cell. Returns the 32-bit cell value, -EINVAL in case the
property or
+ * the indexed cell does not exist.
+ */
+int
+of_getprop_u32(struct device_node *np, char *propname, int offset, u32 *value)
+{
+ return of_read_property_u32(of_find_property(np, propname, NULL),
+ offset, value);
+}
+EXPORT_SYMBOL(of_getprop_u32);
+
+/**
+ * of_read_property_u64 - Reads a indexed 64-bit property value
+ * @prop: property to read from.
+ * @offset:cell number to read (each cell is 64-bits).
+ * @value: returned cell value
+ *
+ * Returns a indexed 64-bit value of a property cell, -EINVAL in case the cell
+ * does not exist
+ */
+int of_read_property_u64(struct property *prop, int offset, u64 *value)
+{
+ if (!prop || !prop-value)
+ return -EINVAL;
+ if ((offset + 1) * 8 prop-length)
+ return -EINVAL;
+
+ *value = of_read_number(prop-value + (offset * 8), 2);
+ return 0;
+}
+EXPORT_SYMBOL(of_read_property_u64);
+
+/**
+ * of_getprop_u64 - Find a property in a device node and read a 64-bit value
+ * @np:device node from which the property value is to be read.
+ * @propname name of the property to be searched.
+ * @offset:cell number to read (each cell is 64-bits).
+ * @value: returned value of the cell
+ *
+ * Search for a property in a device node and read a indexed 64-bit value of a
+ * property cell. Returns the 64-bit cell value, -EINVAL in case the
property or
+ * the indexed cell does not exist.
+ */
+int
+of_getprop_u64(struct device_node *np, char *propname, int offset, u64 *value)
+{
+ return of_read_property_u64(of_find_property(np, propname, NULL),
+ offset, value);
+}
+EXPORT_SYMBOL(of_getprop_u64);
+
+/**
+ * of_read_property_string - Returns a pointer to a indexed null terminated
+ * property value string
+ * @prop: property to read from.
+ * @offset:
Re: Switch to ubuntu-build.linaro.org
On Wed, 22 Jun 2011 00:16:27 -0300, Ricardo Salveti ricardo.salv...@linaro.org wrote: The unhandled fault shouldn't be related with the usb errors. From my experience with Beagle xM the USB port will trigger the reset once the disk is consuming more power than beagle can provide. As I know this is probably a powered USB disk, it'd be good to check the same hardware on another beagle to see if we're able to reproduce the problem, as in the end it could be just a normal hardware failure. I believe we have seen this on more than one of our builders (they have identical setups as far as I know). I think it has been confined mainly to one or two builders as they are the most frequently used. Would you still recommend a particular test here? I've heard a rumour that the problems are related to the USB subsytem and the USB hard disks, but nothing more concrete than that. They are running beagleXMs for what it is worth. Do you know why we're using beagle xM and not panda for the builders? Pandas weren't readily available when we set this up. It'd also be good to have the correct board revision ID to know if the xM is a prototype or a final release (A, A2, B or even C now). I'll ask. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Clarify Licensing terms of build/tools/{isprelinked,soslim,apriori} in Android source tree
Hello list, I am not sure if android-platform@ is the right place to discuss licensing terms in Android or not. Please ignore the post if it was mistaken. Recently, we at Linaro are trying to integrate gcc-linaro[1] into Android build system as the optional toolchain optimized for latest ARM cores. We encounter some unknown prelinker issues, and it is an opportunities for us to look into the implementations of relevant utilities in Android. However, I am a bit confused about the licensing terms of some packages. libelfcopy[2], derived from some parts in binutils, provides the facilities about DWARF/ELF, and it is quite obvious that libelfcopy is licensed under GNU GPL version 2+ as the file MODULE_LICENSE_GPL denotes. There are three system tools depending on libelfcopy: - isprelinked - soslim - apriori build/tools$ grep -r libelfcopy * apriori/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl #dl isprelinked/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl libebl_arm #dl soslim/Android.mk:LOCAL_STATIC_LIBRARIES := libelfcopy libelf libebl libebl_arm #dl These tools are linking libelfcopy statically, which explicitly complies with the licensing terms of GNU GPL. But, after checking the source files (*.[ch]), no license term is claimed.[3] The proper declaration should put file MODULE_LICENSE_GPL into individual directories at least. Is my understanding correct? Sincerely, Jim Huang Android Team, Linaro [1] https://launchpad.net/gcc-linaro [2] http://android.git.kernel.org/?p=platform/external/elfcopy.git;a=summary [3] http://android.git.kernel.org/?p=platform/build.git;a=summary ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Tue, 21 Jun 2011 09:04:41 +, Fathi Boudra fathi.bou...@linaro.org wrote: If not, what are the blockers to doing so? Today, the builders are unstable. They have just had new hard disk enclosures added, and should be more stable now. Let's monitor for a few days and see if they are more stable. On what day should we re-assess the situation and make another go/no-go call? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Community Mumble
On 22 June 2011 11:29, Joey Stanford j...@linaro.org wrote: Hi Gang, In the past few days I've received a few requests to allow community members access to our Mumble server. I don't feel comfortable adding in the large and open linaro-community team so I am considering making a linaro-community-mumble team to allow for access. Right now you have to be in ~linaro to have access to Mumble. As long as we can a private space for the LTs, I think it is a great idea. anmar ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Community Mumble
On Wed, 22 Jun 2011 17:57:03 -0400, anmar.ou...@linaro.org anmar.ou...@linaro.org wrote: As long as we can a private space for the LTs, I think it is a great idea. It looks as though mumble may support password-protecting channels, which may be a good idea for LTs anyway? I don't think it uses encryption or anything though, and I don't know if there's a greater risk from having attackers able to access the mumble server if you are using this. It's certianly something to look in to if you aren't happy with leaving the LT channels unprotected. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Community Mumble
I think its cool. It would be a big help. On 22 June 2011 10:29, Joey Stanford j...@linaro.org wrote: Hi Gang, In the past few days I've received a few requests to allow community members access to our Mumble server. I don't feel comfortable adding in the large and open linaro-community team so I am considering making a linaro-community-mumble team to allow for access. Right now you have to be in ~linaro to have access to Mumble. 1) I'd like to hear your comments on this, especially if you have alternative suggestions. 2) If there are community members who should have mumble access, can you please send me their Launchpad IDs so I can start assembling a list. Thanks, Joey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Meeting request
-Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Wednesday, June 22, 2011 2:47 PM To: Ashish Jangam Cc: Ying-Chun Liu (PaulLiu); Steve Cozens; linaro-dev@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande Subject: Re: Meeting request On Wed, Jun 22, 2011 at 3:11 PM, Eric Miao eric.m...@canonical.com wrote: On Wed, Jun 22, 2011 at 2:01 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 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, 2011 at 8:29 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 5:52 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, 2011 at 6:24 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: -Original Message- From: eric.y.m...@gmail.com [mailto:eric.y.m...@gmail.com] On Behalf Of Eric Miao Sent: Tuesday, June 21, 2011 3:28 PM To: Ashish Jangam; Ying-Chun Liu (PaulLiu) Cc: eric.m...@linaro.org; Steve Cozens; linaro-dev@lists.linaro.org; Mark Brown; Dajun Chen; Prashant Deshpande Subject: Re: Meeting request On Tue, Jun 21, 2011 at 5:57 PM, Eric Miao eric.m...@canonical.com wrote: On Tue, Jun 21, 2011 at 4:21 PM, Ashish Jangam ashish.jan...@kpitcummins.com wrote: Hi Eric, I recently saw your mail to Dajun, on your people eagerness to get the patches upstream soon. We also hold the same vision to get the patches upstream as quick as possible. In this regard we like to have a discussion so please let us know your convenient time. Please note that as of now we do not have any technical issues on patches but there is a need to understand the patch submission process so we can focus our discussion accordingly. Thanks Ashish to bring this forword. I'm in TZ GMT+8, and I think Mark is in Scottland, which is GMT+1? Anyway, tomorrow and Friday will be fine to me, depending on your location and a time slot that works for all of us, there could be not many choices :- ) Include Paul Liu, he's working on the PMIC upstreaming as well, he's in the same TZ as I am. Below are time slots in preference order (hopefully for all) for Wednesday meeting:- 1) GMT+8 == 05:00pm; GMT+1 == 10:00am; GMT+5.5 == 02:30pm 2) GMT+8 == 04:00pm; GMT+1 == 09:00am; GMT+5.5 == 01:30pm 3) GMT+8 == 06:00pm; GMT+1 == 11:00am; GMT+5.5 == 03:30pm Let me know which time slot suits you all. Hi Ashish, Option 1) works for me and Paul Liu. Thanks. Kindly share your contact details so that we can get connected. You can use my linaro email address of cuz: eric.m...@linaro.org For today's conference please dial:- +91 20 6652 5000 - press 1 - press 80867 - press 1. For any assistance please call the telecom team on 91 20 66525000. Kindly note, that this is not a Toll free number. In case your all not comfortable with this number then give me your phone number so that I can put all of us in a conference call. I can use skype to dial in. Yet not really sure about the other guys. Guys, Sorry seems I have problem to get my skype back online. Can we reschedule this to another time slot? And thanks Ashish to bring this up - this really helps a lot for us to co- work. I'll send some basic ideas a bit later. - eric Will the same time slot for Friday works for you all? Also thanks for extending the help. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/6] watchdog: s3c2410: Add support for device tree based probe
Hi Thomas, Grant, On Mon, Jun 20, 2011 at 5:02 AM, Thomas Abraham thomas.abra...@linaro.org wrote: This patch adds the of_match_table to enable s3c2410-wdt driver to be probed when watchdog device node is found in the device tree. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca You need to send this to Wim and the linux-watchdog mailing lists. As far as I'm concerned, it can be merged immediately. Yep, it looks OK. Please sent the patch so that it can be included. Kind regards, Wim. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro monthly release cycle
Or we could just use continuous integration where there are no freezes, just per change regression tests. -Zach On 15 June 2011 11:17, Peter Maydell peter.mayd...@linaro.org wrote: On 15 June 2011 15:40, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Wed, 15 Jun 2011, Peter Maydell wrote: if we want to guarantee that QEMU and the kernel work together I think we really need to pretty much freeze the kernel two weeks before QEMU's release date, in order to have a fighting chance at catching and fixing problems. I don't think it is reasonable to freeze the kernel for two weeks in a ~4 week cycle. Therefore we might have to consider simply not having the same release dates for all components. We could pipeline the dependencies instead of being all synchronous. This would mostly work, although you'd end up with the slightly odd effect that qemu-linaro released at the same time as the rest of the toolchain components but nominally as part of the previous month's release... -- PMM ___ linaro-kernel mailing list linaro-ker...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Android libjpeg
Hi there, I took a look at the AOSP libjpeg code which is included in git://android.git.kernel.org/platform/external/jpeg during my flight back home (which incidentally had been diverted and landed me in Rio de Janeiro; not sure if I celebrate or cry) and noted the following things: - There is a v6 implementation of the fast IDCT algorithm which lives in armv6_idct.S. - The commit which adds this implementation was added October 2010, and there haven't been any changes since. - The code that selects the decoder IDCT implementation in jddctmgr.c always uses that implementation if ANDROID_ARMV6_IDCT is defined. - Google have an ashmem backing store implementation, and have code to enable tile-based mode. It's a fairly non-intrusive change to use ashmem since it just replaces jpeg_open_backing_store. - The code is pretty much standard libjpeg without any structural changes to it. - There isn't any NEON code in this branch. - Mans has an optimized version here: http://git.mansr.com/?p=libjpeg;a=summary I don't know if he's submitted this to AOSP or not. This suggests to me that a simple drop-in of libjpeg-turbo might be actually easy to do, and that there is probably a significant performance benefit to be achieved. One thing to keep in mind is that this code still supports armv6, so we'd probably want to preserve that. Thanks! -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: implementing queues safely in (generic) SQL
W dniu 22.06.2011 00:21, Michael Hudson-Doyle pisze: Fortunately django almost never runs in autocommit mode. There is an implicit transaction around the whole request. It is easy to control the transaction processing around a piece of code, see [1]. I got very confused by this, I admit. In general, calling .save() on a model does a COMMIT, unless you're managing the transactions yourself (or using TransactionMiddleware)? Something like that. It's easier to read the source than read my explanations. django.db.models.base:Model.base_save() calls transaction.commit_unless_managed(). In practice, django is almost always managed so save is never commits. The transaction middleware you mentioned makes django views managed using commit_on_success decorator on the request method. You need to disable that manually and I don't see any reason why someone would such a thing. And of course, the way this is being done in the scheduler at the moment is not part of the web app, so the usual stuff doesn't always apply. On PostgreSQL we also need to properly implement handling of IngegrityError as it differs significantly from SQLite [2] It's just that it dooms transactions, right? Not really, it just makes supporting them a little trickier. I do that with deserialization of bundles. In practice it's quite easy if you remember to use save points correctly. See my 1-4 points below for explanation why. The approach we'll take on integrity errors is to rollback and retry so that's easy. You can rollback to a savepoint. (it's confusing that https://docs.djangoproject.com/en/dev/topics/db/transactions/#transaction-rollback says that the changes made by a.save() will be lost when the default is for .save() to commit, so they must be assuming that you're using TransactionMiddleware). It's not only transaction middleware. Any code that earlier (in the call history of a particular function) enabled transactions will behave this way. In reality this is all manageable: 1) Proper code will work regardless autocommit mode :-) 2) PostgreSQL does not break things, you just need to take account for savepoints. 3) Handling transactions manually implies you use savepoints and thus get 1 and 2 right. 4) Handling transactions automatically (around a view) implies you get shielded from most of the complexity, if your actual application logic is happy not to use explicit manual transactions in such cases. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Meeting request
(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://lists.linaro.org/mailman/listinfo/linaro-dev
Re: implementing queues safely in (generic) SQL
On Thu, 23 Jun 2011 03:59:49 +0200, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: W dniu 22.06.2011 00:21, Michael Hudson-Doyle pisze: Fortunately django almost never runs in autocommit mode. There is an implicit transaction around the whole request. It is easy to control the transaction processing around a piece of code, see [1]. I got very confused by this, I admit. In general, calling .save() on a model does a COMMIT, unless you're managing the transactions yourself (or using TransactionMiddleware)? Something like that. It's easier to read the source than read my explanations. django.db.models.base:Model.base_save() calls transaction.commit_unless_managed(). OK. In practice, django is almost always managed so save is never commits. Really? TransactionMiddleware isn't installed by the settings file that django-admin startapp creates. Is this just a crummy default that everyone changes? The transaction middleware you mentioned makes django views managed using commit_on_success decorator on the request method. You need to disable that manually and I don't see any reason why someone would such a thing. See above. And of course, the way this is being done in the scheduler at the moment is not part of the web app, so the usual stuff doesn't always apply. On PostgreSQL we also need to properly implement handling of IngegrityError as it differs significantly from SQLite [2] It's just that it dooms transactions, right? Not really, it just makes supporting them a little trickier. I do that with deserialization of bundles. In practice it's quite easy if you remember to use save points correctly. See my 1-4 points below for explanation why. The approach we'll take on integrity errors is to rollback and retry so that's easy. You can rollback to a savepoint. Yeah, but there's no reason to do that in getJobForBoard. (it's confusing that https://docs.djangoproject.com/en/dev/topics/db/transactions/#transaction-rollback says that the changes made by a.save() will be lost when the default is for .save() to commit, so they must be assuming that you're using TransactionMiddleware). It's not only transaction middleware. Any code that earlier (in the call history of a particular function) enabled transactions will behave this way. Sure, but it's a bit disingenuous to not mention that in the documentation I think. I guess I should file a ticket. In reality this is all manageable: 1) Proper code will work regardless autocommit mode :-) 2) PostgreSQL does not break things, you just need to take account for savepoints. 3) Handling transactions manually implies you use savepoints and thus get 1 and 2 right. s/savepoints/savepoints or transactions/ -- there's no requirement to involve savepoints if you don't need to. 4) Handling transactions automatically (around a view) implies you get shielded from most of the complexity, if your actual application logic is happy not to use explicit manual transactions in such cases. Yeah, it's very good default for webapps. Launchpad does that, but goes even further: it automatically does a rollback when a GET method completes, and uses SERIALIZABLE isolation level, retrying a method if the commit fails due to a serialization violation. However the code I'm working on is not part of a webapp :) https://code.launchpad.net/~mwhudson/lava-scheduler/daemon-v1/+merge/65616 btw. Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH powertop2.0] Modification to fix the removal of lock_depth field
lock_depth field is removed from the power frequency events in the
new linux kernel(2.6.38 onwards). So this creates issue to retrieve
the lower members of the trace data. To fix this problem 2 separate
structures are created and their use depends upon the format of the
power_frequency events. These changes have been tested to work fine
with both old and new kernels as well as on x86 and ARM platform.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
This patch is for powertop2.0 and fixes the issue of frequency
reported as always 0 in kernel from 2.6.38 onwards.
cpu/cpu.cpp |7 +---
perf/perf_bundle.cpp | 98 -
2 files changed, 82 insertions(+), 23 deletions(-)
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index b901b87..1193d7b 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -742,11 +742,8 @@ void w_display_cpu_pstates(void)
struct power_entry {
-#ifndef __i386__
- int dummy;
-#endif
- int64_t type;
- int64_t value;
+ uint64_ttype;
+ uint64_tvalue;
} __attribute__((packed));
diff --git a/perf/perf_bundle.cpp b/perf/perf_bundle.cpp
index 2276c3a..f4c8912 100644
--- a/perf/perf_bundle.cpp
+++ b/perf/perf_bundle.cpp
@@ -27,6 +27,7 @@
#include algorithm
#include string.h
#include stdint.h
+#include dirent.h
#include perf_bundle.h
#include perf_event.h
@@ -110,11 +111,30 @@ void perf_bundle::add_event(const char *event_name)
}
}
}
-
+static int lock_depth = 0;
void perf_bundle::start(void)
{
unsigned int i;
class perf_event *ev;
+ char line[1023];
+ FILE *file;
+char filename[PATH_MAX];
+
+ /*check the format of power_frequency event*/
+ strcpy(filename,
+/sys/kernel/debug/tracing/events/power/power_frequency/format);
+ if (!lock_depth) {
+ file = fopen(filename, r);
+ if (file) {
+ while (fgets(line, 1023,file) != NULL) {
+ if (strstr(line, lock_depth)) {
+ lock_depth = 1;
+ break;
+ }
+ }
+ fclose(file);
+ }
+ }
for (i = 0; i events.size(); i++) {
ev = events[i];
@@ -154,34 +174,57 @@ void perf_bundle::clear(void)
records.resize(0);
}
-
-struct trace_entry {
+/*Trace entry for the common fields of perf events*/
+struct trace_entry_common {
uint64_ttime;
uint32_tcpu;
uint32_tres;
__u32 size;
+} __attribute__((packed));
+
+/*Trace entry for the fields specific to each perf events.
+* lock_depth field to support old kernels*/
+struct trace_data_lockdepth {
unsigned short type;
unsigned char flags;
unsigned char preempt_count;
int pid;
int lock_depth;
+#ifndef __i386__
+ int filler;
+#endif
} __attribute__((packed));;
+/*Trace entry for the fields specific to each perf events*/
+struct trace_data_normal {
+ unsigned short type;
+ unsigned char flags;
+ unsigned char preempt_count;
+ int pid;
+} __attribute__((packed));;
-struct perf_sample {
+struct perf_sample_normal {
struct perf_event_headerheader;
- struct trace_entry trace;
+ struct trace_entry_common trace_common;
+ struct trace_data_normaltrace_data;
unsigned char data[0];
} __attribute__((packed));
+struct perf_sample_lockdepth {
+ struct perf_event_headerheader;
+ struct trace_entry_common trace_common;
+ struct trace_data_lockdepth trace_data;
+ unsigned char data[0];
+} __attribute__((packed));;
+
static uint64_t timestamp(perf_event_header *event)
{
- struct perf_sample *sample;
+ struct perf_sample_lockdepth *sample;
if (event-type != PERF_RECORD_SAMPLE)
return 0;
- sample = (struct perf_sample *)event;
+ sample = (struct perf_sample_lockdepth *)event;
#if 0
int i;
@@ -207,7 +250,7 @@ static uint64_t timestamp(perf_event_header *event)
printf(%02x , *(x+i));
printf(\n);
#endif
- return sample-trace.time;
+ return sample-trace_common.time;
}
@@ -235,16 +278,35 @@ void perf_bundle::process(void)
sort(records.begin(), records.end(), event_sort_function);
for (i = 0; i records.size(); i++) {
- struct perf_sample *sample;
-
- sample = (struct perf_sample *)records[i];
- if (!sample)
- continue;
-
-
Re: [PATCH powertop2.0] Modification to fix the removal of lock_depth field
On 23 June 2011 10:41, Arjan van de Ven ar...@linux.intel.com wrote: On 6/22/2011 10:12 PM, Amit Daniel Kachhap wrote: lock_depth field is removed from the power frequency events in the new linux kernel(2.6.38 onwards). So this creates issue to retrieve the lower members of the trace data. To fix this problem 2 separate structures are created and their use depends upon the format of the power_frequency events. These changes have been tested to work fine with both old and new kernels as well as on x86 and ARM platform. eh no while it was temporarily removed in an -rc, it was added back (as padding) after it was found to break powertop (and abi). or am I missing something??? Ohh the padding field fixes this issue. Then this patch may not be needed. Thanks Arjan for quick review. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
