W dniu 11.11.2011 03:55, Adilson Oliveira pisze:
Hi.
I'm re-posting a question from a canonical folk about Efika MX, I think
the audience here will be more capable of helping out.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello
>
> I got an Efika MX and I wondered if anyone qwas able to instrall a
> more recent Ubuntu on it. I tried Linaro's image but the SD is not
> recognized at boot time. Am I missing something or was the SD supposed
> to be detected automatically?
>
> TIA
>
> Adilson.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk68jroACgkQYaKG37RGLIp/pACdFvTB3hVssnVCeXNL9EulVb9Z
> UccAn3z3YUvON/ji1gdRDaRuHq/IZrA1
> =73EU
> -----END PGP SIGNATURE-----
Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
completely different manner than they select which function to mux out of
that pin. In order to support a single "free" pinmux_op, the driver would
need to maintain a per-pin state of requested-for-gpio vs. requested-for-
function. However, that's a lot of work when the core already has explicit
separate paths for gpio request/free and function request/free.
So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
call it when appropriate.
When doing this, I noticed that when calling pin_request():
!!gpio == (gpio_range != NULL)
... and so I collapsed those two parameters in both pin_request(), and
when adding writing the new code in pin_free().
Also, for pin_free():
!!free_func == (gpio_range != NULL)
However, I didn't want pin_free() to know about the GPIO function naming
special case, so instead, I reworked pin_free() to always return the pin's
previously requested function, and now pinmux_free_gpio() calls
kfree(function). This is much more balanced with the allocation having
been performed in pinmux_request_gpio().
Signed-off-by: Stephen Warren <swarren(a)nvidia.com>
---
drivers/pinctrl/pinmux.c | 39 +++++++++++++++++++++++++--------------
include/linux/pinctrl/pinmux.h | 3 +++
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index a5467f8..8a95e45 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -98,12 +98,11 @@ struct pinmux_hog {
* @function: a functional name to give to this pin, passed to the driver
* so it knows what function to mux in, e.g. the string "gpioNN"
* means that you want to mux in the pin for use as GPIO number NN
- * @gpio: if this request concerns a single GPIO pin
* @gpio_range: the range matching the GPIO pin if this is a request for a
* single GPIO pin
*/
static int pin_request(struct pinctrl_dev *pctldev,
- int pin, const char *function, bool gpio,
+ int pin, const char *function,
struct pinctrl_gpio_range *gpio_range)
{
struct pin_desc *desc;
@@ -152,7 +151,7 @@ static int pin_request(struct pinctrl_dev *pctldev,
* If there is no kind of request function for the pin we just assume
* we got it by default and proceed.
*/
- if (gpio && ops->gpio_request_enable)
+ if (gpio_range && ops->gpio_request_enable)
/* This requests and enables a single GPIO pin */
status = ops->gpio_request_enable(pctldev, gpio_range, pin);
else if (ops->request)
@@ -182,29 +181,39 @@ out:
* pin_free() - release a single muxed in pin so something else can be muxed
* @pctldev: pin controller device handling this pin
* @pin: the pin to free
- * @free_func: whether to free the pin's assigned function name string
+ * @gpio_range: the range matching the GPIO pin if this is a request for a
+ * single GPIO pin
*/
-static void pin_free(struct pinctrl_dev *pctldev, int pin, int free_func)
+static const char *pin_free(struct pinctrl_dev *pctldev, int pin,
+ struct pinctrl_gpio_range *gpio_range)
{
const struct pinmux_ops *ops = pctldev->desc->pmxops;
struct pin_desc *desc;
+ const char *func;
desc = pin_desc_get(pctldev, pin);
if (desc == NULL) {
dev_err(&pctldev->dev,
"pin is not registered so it cannot be freed\n");
- return;
+ return NULL;
}
- if (ops->free)
+ /*
+ * If there is no kind of request function for the pin we just assume
+ * we got it by default and proceed.
+ */
+ if (gpio_range && ops->gpio_disable_free)
+ ops->gpio_disable_free(pctldev, gpio_range, pin);
+ else if (ops->free)
ops->free(pctldev, pin);
spin_lock(&desc->lock);
- if (free_func)
- kfree(desc->mux_function);
+ func = desc->mux_function;
desc->mux_function = NULL;
spin_unlock(&desc->lock);
module_put(pctldev->owner);
+
+ return func;
}
/**
@@ -234,7 +243,7 @@ int pinmux_request_gpio(unsigned gpio)
if (!function)
return -EINVAL;
- ret = pin_request(pctldev, pin, function, true, range);
+ ret = pin_request(pctldev, pin, function, range);
if (ret < 0)
kfree(function);
@@ -252,6 +261,7 @@ void pinmux_free_gpio(unsigned gpio)
struct pinctrl_gpio_range *range;
int ret;
int pin;
+ const char *func;
ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range);
if (ret)
@@ -260,7 +270,8 @@ void pinmux_free_gpio(unsigned gpio)
/* Convert to the pin controllers number space */
pin = gpio - range->base;
- pin_free(pctldev, pin, true);
+ func = pin_free(pctldev, pin, range);
+ kfree(func);
}
EXPORT_SYMBOL_GPL(pinmux_free_gpio);
@@ -350,7 +361,7 @@ static int acquire_pins(struct pinctrl_dev *pctldev,
/* Try to allocate all pins in this group, one by one */
for (i = 0; i < num_pins; i++) {
- ret = pin_request(pctldev, pins[i], func, false, NULL);
+ ret = pin_request(pctldev, pins[i], func, NULL);
if (ret) {
dev_err(&pctldev->dev,
"could not get pin %d for function %s "
@@ -360,7 +371,7 @@ static int acquire_pins(struct pinctrl_dev *pctldev,
/* On error release all taken pins */
i--; /* this pin just failed */
for (; i >= 0; i--)
- pin_free(pctldev, pins[i], false);
+ pin_free(pctldev, pins[i], NULL);
return -ENODEV;
}
}
@@ -390,7 +401,7 @@ static void release_pins(struct pinctrl_dev *pctldev,
return;
}
for (i = 0; i < num_pins; i++)
- pin_free(pctldev, pins[i], false);
+ pin_free(pctldev, pins[i], NULL);
}
/**
diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h
index 3c430e7..350e32a 100644
--- a/include/linux/pinctrl/pinmux.h
+++ b/include/linux/pinctrl/pinmux.h
@@ -73,6 +73,9 @@ struct pinmux_ops {
int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned offset);
+ void (*gpio_disable_free) (struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned offset);
};
/* External interface to pinmux */
--
1.7.0.4
Enclosed please find the link to the Weekly Status & Individual Activity
reports
for the kernel working group for the week ending 2011-11-11
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-11-10
== Individual Activity Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2011-11-04
== Summary ==
(For more details, refer to the Weekly Status & Individual Activity
Reports)
* Most of the KWG team has attended Linaro Connect, many good sessions,
discussion and hacking has happened.
Deepak has summarized the event for KWG:
http://www.linaro.org/linaro-blog/2011/11/09/kernel-working-group-a-linaro-…
* Due to Thanksgiving holiday, this month's Linaro kernel release will be
as follows: Freeze on Monday 2011-11-14 and release on Thursday 2011-11-17.
* Based on discussions at LCQ4.11 Connect in Orlando, there will be a new
process for the Kernel WG, new sub-team will be designated for each major
area.
* Device Tree
* Submitted rebased version of the samsung's sdhci driver DT patches.
* Regulator core DT patches Acked by Mark. Some more minor comments from
Olof, will need another final repost.
* Initial omap hsmmc DT patches posted.
* Pinctrl
* Linus Torvalds has pulled the pinctrl subssystem for Linux v3.2.
* All GPIO cleanups initially started in the Cambourne sprint in
cooperation with Ben Dooks, have been pulled into Linus Torvalds' tree.
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Hi,
I have made some modification to the SMSC LAN911X driver for both UBoot and QEMU in order to be able to use SMSC LAN9X based network drivers during the u-boot stage.
1) U-Boot
In UBoot, when the LAN911X device is reseted, the READY bit is checked and device is wake up by writing onto the TEST_BYTE register if the READY bit cleared (0b). But from the datasheet of the SMSC LAN9118/LAN9115/LAN9220 in the section Power Management (3.10), it is said that READY bit is cleared when PM_MODE is set to D1 or D2 and set only when in D0 mode.
3.10.2
Functional Description
There is one normal operating power state, D0 and there are two power saving states: D1, and D2.
Upon entry into either of the two power saving states, only the PMT_CTRL register is accessible for
read operations. In either of the power saving states the READY bit in the PMT_CTRL register will be
cleared. Reads of any other addresses are forbidden until the READY bit is set. All writes, with the
exception of the wakeup write to BYTE_TEST, are also forbidden until the READY bit is set. Only when
in the D0 (Normal) state, when the READY bit is set, can the rest of the device be accessed.
So I modified the code (drivers/net/smc911x.h) to wake up the device only if the READY bit is cleared (0b). If it is set (1b) then we just do nothing.
Patch is contained in following commit : https://bitbucket.org/bca/u-boot-linaro-stable/changeset/b870326105da
2) QEMU
In the driver for the SMSC LAN9118 device (hw/lan9118.c), I modify the code to update the PM_CTRL register (switch PM_MODE bits to D0 and set (1b) READY bit ) when writing to the BYTE_TEST register.
Writing to PM_CTRL was not permitted before this modification => raise an harware error => QEMU crash when happen. So when you try to perform network connection in u-boot stage in QEMU, QEMU crashed.
Patch is contained in the following commit : https://bitbucket.org/bca/qemu-linaro/changeset/0aa1f76e5141
If you have any question, or if you find any mistake in my understanding, please feel free to contact me.
Hope it helps others and a bit thanks for the Linaro initiative
--
Bertrand Cachet, Ingénieur CPE (Lyon, France)
Institut REDS, Reconfigurable & Embedded Digital Systems
Tél : +41 24/55 77 372
Email : bertrand.cachet(a)heig-vd.ch<mailto:bertrand.cachet@heig-vd.ch>
Internet: http://www.reds.ch
HEIG-VD, Haute Ecole d'Ingénierie et de Gestion du Canton de Vaud
Rte de Cheseaux 1
CH-1401 Yverdon-les-Bains
Internet: http://www.heig-vd.ch
Here's a quick status update on the server upgrade we performed today. The
major things we were doing were:
* Memory upgrades - we now have about 7.5x the memory we had previously,
things are *much* faster now
* OS updates - We're now running on the latest version of Ubuntu Server
* LAVA updates
If you take a look at http://validation.linaro.org, you will now see the
version we had in staging last week at the connect, with more Linaro
theming, menu improvements, and bug fixes.
Jobs are running again, and we've mostly cleared the backlog but seem to be
having some network problems that are unrelated to the upgrades, causing
failures in some of the jobs. The validation team is currently looking at
what can be done to improve this soon.
Thanks,
Paul Larson
On Thu, Nov 10, 2011 at 2:31 AM, Dave Pigott <dave.pigott(a)linaro.org> wrote:
> Hi all,
>
> Just a reminder that validation.linaro.org will be taken down in 30
> minutes, at 09:00 UTC.
>
> Thanks
>
> Dave Pigott
> Validation Engineer
> T: +44 1223 45 00 24 | M +44 7940 45 93 44
> Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM
> SoCs****
> Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter<http://twitter.com/#%21/linaroorg>
> | Blog <http://www.linaro.org/linaro-blog/>
>
>
I'm working on the dispatcher again, and as usual I'm getting a bit
grumpy. Partly this is because the abstractions I added a couple of
weeks ago aren't really working, but that's my problem. What I want to
complain about is the error handling.
I've always found the error handling in the dispatcher to be a little
strange, so in this mail I'm going to try to set out the issue and maybe
propose a solution.
A lot of the confusion comes from the fact that there are many things
that could be called an error in the dispatcher, and some overloading in
the way we try to handle and report errors.
Kinds of error that I can think of immediately:
1) Flat out bugs in the dispatcher
2) Errors in the job file (e.g. typoing an action name)
3) Failing tests
4) Tests that fail to even run
5) The board hanging at some point
6) Infrastructure failures, like l-m-c or deployment failing
7) Recoverable errors, e.g. where we want to be in the master image but
might be in the linaro image
Category 1 bugs we can't really do *too* much about -- if we have
incorrect code, who's to say that the error handling code will be
correct? -- but in general dispatcher bugs should IMO cause the
dispatcher to exit with an exit code != 0 (we talked at the connect
about having the scheduler display jobs that exited like this
differently). Currently because we have lots of "except:"s all over the
place, I think we risk swallowing genuine bugs (indeed, we had one of
these for a while, where we said "self.in_master_shell()" instead of
"self.client.in_master_shell()" but the AttributeError was caught).
If we hit this sort of thing, I don't think we should try to continue to
execute other actions and in particular I'm not too bothered if this
kind of error does not result in a bundle being submitted to the
dashboard.
Category 2 -- errors in the job file -- we should try to detect as early
as possible. Maybe we should even create the action objects and do a
simple argument check before doing anything else? I think this sort of
error should also result in an exit code != 0. To the extent that its
reasonable, invalid job files should be rejected by the submit_job api
call.
As for bugs, I don't think we should try to continue to execute other
actions and I'm not too bothered if this kind of error does not result
in a bundle being submitted to the dashboard.
Category 3 -- failing tests -- is not something the dispatcher itself
should care about, at all.
Category 4 -- tests that fail to run, I guess this includes things like
lava-test hanging or crashing -- I think this should result in a failure
in the magic 'lava' test run of the submitted bundle (and I think this
is the case today). If this happens, I don't know if we should try to
continue to execute other actions (apart from submit_results I guess).
Category 5 -- things like the board hanging at some point -- I guess
this depends a bit when this happens. If it's during deployment say,
that's pretty bad -- certainly we shouldn't try to execute other
non-reporting actions if this happens.
Category 6 -- infrastructure failures -- seem to fall into the same kind
of area as the previous 2: we should report a failure and stop executing
any other actions.
Category 7 -- recoverable failures -- are a bit different. We should
log that they have happened and continue.
After all this thinking and typing I think I've come to some
conclusions:
1) There is a category of error where we should just stop. As far as I
know, this isn't really handled today.
2) There is another category of error where we should report failure,
but not execute any other actions. This makes me thing that having
'report results' as an action is a bit strange -- perhaps the
dashboard and bundle stream should really be directly in the job,
rather than an action?
3) I need to write another, probably equally long, email about
dependencies between actions :-)
Cheers,
mwh
Key Points for wider discussion
===============================
* Toolchain build modified to generate both arm-eabi and
arm-linux-androideabi toolchains
Team Highlights
===============================
* ALmost all Team members attended Connect
* Progress on Androidizing Snowball GLK3.1 kernel
* Workaround created for gdbserver crash on startup
* All board kernels generates config.gz by default
* A bot metrics script to determine the bot's contributions to gerrit done
* Solution to LAVA test iMX53, Origen and Snowball on review
* Progress on video recording bug
* libpng 1.5.5 integration issues solved
* Android builds on tool chain tip build
* Progress on linphone on panda.
Miscellaneous
===============================
* New members Amit Pundir and Prashanth Srinivasan
Issues
===============================
* Slow progress on "Build the Non-Proprietary Igloo Android A Release with
Linaro Tools"
Blueprints
===============================
https://launchpad.net/linaro-android/+milestone/11.11
Hello, All
Does anyone who know where to get the test files defined in
file src/com/android/mediaframeworktest/MediaNames.java.
or how to generate those files.
like
public static final String MP3CBR =
"/sdcard/media_api/music/MP3_256kbps_2ch.mp3";
public static final String MP3VBR =
"/sdcard/media_api/music/MP3_256kbps_2ch_VBR.mp3";
public static final String SHORTMP3 =
"/sdcard/media_api/music/SHORTMP3.mp3";
public static final String MIDI = "/sdcard/media_api/music/ants.mid";
public static final String WMA9 = "/sdcard/media_api/music/WMA9.wma";
public static final String WMA10 = "/sdcard/media_api/music/WMA10.wma";
public static final String WAV =
"/sdcard/media_api/music/rings_2ch.wav";
public static final String AMR =
"/sdcard/media_api/music/test_amr_ietf.amr";
public static final String OGG =
"/sdcard/media_api/music/Revelation.ogg";
public static final String SINE_200_1000 =
"/sdcard/media_api/music/sine_200+1000Hz_44K_mo.wav";
public static String[] MP3FILES = {
"/sdcard/media_api/music_perf/MP3/NIN_56kbps_32khz_stereo_VBR_MCA.MP3",
"/sdcard/media_api/music_perf/MP3/NIN_80kbps_32khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_80kbps_44.1khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_80kbps_48khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_112kbps_32khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_112kbps_44.1khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_112kbps_48khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_192kbps_32khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_192kbps_44.1khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_192kbps_48khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_256kbps_44.1khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_256kbps_48khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_112kbps_32khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_112kbps_44.1khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_112kbps_48khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_192kbps_32khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_256kbps_44.1khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_256kbps_48khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/WC_256kbps_44.1khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/MP3/WC_256kbps_48khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Apologize.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Because_Of_You.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Complicated.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Glamorous.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Im_With_You.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Smile.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Suddenly_I_See.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/When You Say
Nothing At All.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/my_happy_ending.mp3"};
Thanks,
Yongqin Liu
