Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi Fathi, Sorry for the top post. Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. Due to release manager timezone etc. we aim for cutting ready to RC images by 1600 UTC on Monday. Can't we do the base-files update on Friday. Are there any other packages like kernel that need more up-front integration time? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
Hi Ricardo, On 27 September 2011 06:23, Ricardo Salveti ricardo.salv...@linaro.org wrote: Any specific reason why using the build from 0926 as the RC instead of 0927? According to the schedule, RC images are delivered 3 days before the release, Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926. This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. For your specific example, base-files should be updated on Thursday, with Linaro components release. This changes doesn't affect the testing. IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility. Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images? An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images. Cheers, Fathi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
On Tue, Sep 27, 2011 at 3:17 AM, Alexander Sack a...@linaro.org wrote: On Tue, Sep 27, 2011 at 5:23 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi Fathi, Sorry for the top post. Any specific reason why using the build from 0926 as the RC instead of 0927? This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. Due to release manager timezone etc. we aim for cutting ready to RC images by 1600 UTC on Monday. Can't we do the base-files update on Friday. Are there any other packages like kernel that need more up-front integration time? The base-files package was just one example, but it's also common to integrate other components, mostly from the landing teams. This time, for example, we were just able to push the TI LT kernel after the 0926 build, as the tree was properly rebased and tagged at friday. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pin control subsystem v7
On Wed, Sep 21, 2011 at 9:45 PM, Stephen Warren swar...@nvidia.com wrote: Linus Walleij wrote at Wednesday, September 21, 2011 3:17 AM: Great, I'm hunting your Acked-by/Reviewed-by ... Very close; I was just holding off until we resolved the discussion on hog'd non-system mapping table entries, and I figured I'd wait until v8 which presumably would delete the pinmux_config function from the header? Yep, I will submit that soon. After this I plan to request its inclusion into linux-next. Yours, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pin control subsystem v7
On Wed, Sep 21, 2011 at 9:45 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Wednesday, September 21, 2011 3:17 AM:
To abstract things the stuff we can do with the group should be
something enumerated too. So:
pinctrl_config_group(const char *pinctrl_device, const char *group,
const char *mode);
pinctrl_config_pin(const char *pinctrl_device, int pin, const char *mode);
So the driver need an API to enumerate pin and group modes.
I might want to save this thing for post-merge of the basic API and
pinmux stuff though so we don't try to push too much upfront
design at once.
Yes, adding in a replacement _config API can certainly be a later patch.
If I'm efficient enough we might get that add-on before the v3.2
merge window, I'll iterate that patch separately though.
One comment on the API above: I think you want mode (or setting?)
/and/ a value parameter; Tegra's pull strength definition for example
is:
enum tegra_pull_strength {
TEGRA_PULL_0 = 0,
TEGRA_PULL_1,
// ... (every value in between)
TEGRA_PULL_30,
TEGRA_PULL_31,
TEGRA_MAX_PULL,
};
And it seems better to represent that as (pull, 0) ... (pull, 31) than
pull0 .. pull31 such that the value needs to be parsed out of the mode
string somehow by the driver.
OK so we might want some public defintion of things you can do
with pins, then an opaque parameter.
like:
#define PINCTRL_PULL pull
#define PINCTRL_BIAS bias
#define PINCTRL_LOADCAP load-capacitance
#define PINCTRL_DRIVE drive
...but then it's just simple enumerators, and we might be better off
with a simple enum after all:
enum pinctrl_pin_ops {
PINCTRL_PULL,
PINCTRL_BIAS,
PINCTRL_LOADCAP,
PINCTRL_DRIVE,
}
Surely the device tree will have to translate that enum into strings
(I guess? Sorry for my low DT competence) but that is more of a
DT pecularity and can be kept in the DT pin control parser?
Yours,
Linus Walleij
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux
On Wed, Sep 21, 2011 at 9:39 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Wednesday, September 21, 2011 2:25 AM:
On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
+ for (i = 0; i ARRAY_SIZE(u300_mux_hogs); i++) {
+ struct pinmux *pmx;
+ int ret;
+
+ pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
+ if (IS_ERR(pmx)) {
+ pr_err(u300: could not get pinmux hog %s\n,
+ u300_mux_hogs[i].name);
+ continue;
+ }
+ ret = pinmux_enable(pmx);
+ if (ret) {
+ pr_err(u300: could enable pinmux hog %s\n,
+ u300_mux_hogs[i].name);
+ continue;
+ }
+ u300_mux_hogs[i].pmx = pmx;
+ }
+ return 0;
+}
+subsys_initcall(u300_pinmux_fetch);
Why not just have the pinmux core support hogging on non-system mapping
entries; then everything I quoted above except u300_pinmux_map[] could
be deleted, and the hog flag set on the last 3 u300_pinmux_map[] entries.
Very good question, luckily I have a good answer.
There is no way for the pinmux core to traverse the system and look
up the apropriate struct device * pointers.
It's unclear to me why that would be needed.
For non-system mappings, either the device-driver in question will be
get'ing and enabling them (this case isn't relevant to this discussion),
or they'll be hogged. In the hog case, I doubt anything would ever want
to disable them and switch the device to a different mapping entry; if
that were the case, the entries shouldn't be hogged, but get/enabled by
the device anyway. Hence, I don't see the need for an activation of a
hog'd non-system mapping entry to care about the device fields that are
in the mapping table at all; they could just be ignored couldn't they?
I don't think so, atleast not in this case. I think it is helpful for the system
to know which device is related to the specific hog, so it turns up in
debugfs etc aha, it is hogged for that device etc. Not doing that
makes the subsystem loose relevant information.
So for that reason I prefer to pass in the relevant struct device *
pointers, atleast when they're readily available as in this boardfile.
If they are not available, or hard to get at, we could just redefine
them as system mappings and remove the device fields, but
in this case I'd say let's keep it around.
Yours,
Linus Walleij
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.09 Release Candidate
On Tue, Sep 27, 2011 at 9:23 AM, Fathi Boudra fathi.bou...@linaro.orgwrote: On 27 September 2011 09:59, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra fathi.bou...@linaro.org wrote: Hi Ricardo, On 27 September 2011 06:23, Ricardo Salveti ricardo.salv...@linaro.org wrote: Any specific reason why using the build from 0926 as the RC instead of 0927? According to the schedule, RC images are delivered 3 days before the release, Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926. This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release. For your specific example, base-files should be updated on Thursday, with Linaro components release. This changes doesn't affect the testing. Don't know if updating it on thursday would be the best case, but sure, it can be done at least at friday. And it doesn't change the testing, but we need an image respin. IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility. We could just have a build job scheduled at 16 UTC at offspring, so we avoid requiring manual builds. I believe this would be our best option (and it usually takes around 3 hours to build all images). sounds a good compromise. Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images? An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images. Sure, but I also believe we should have a better way to communicate the community and others about an image respin, so we avoid people testing the images provided by the call for testing email when another one is already available. I'll try to better communicate to our wider community on the testing progress on linaro-dev ml by doing follow-up on the call for testing mail. I got this idea to setup a linaro-release twitter/google+ feed to update folks about RC, release progress, critical bugs discovered during testing, respins etc. You would probably announce one time before release week on linaro-dev that detailed release updates go there there and folks can then opt-into following the release team. Next, we can also write a bot that auto posts respins during release week there. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.07 oprofile on panda busted?
On Mon, Sep 26, 2011 at 8:27 AM, David Long dave.l...@linaro.org wrote: Andy made an interesting suggestion to me. What if the profile event code allocated all the counters to the requested event. It could reallocate half of them if a second event was also requested, and so on, till we're down to one (unreliably interrupting) counter. Or we could set a limit requiring at least three counters per event. The problem would still exist, but this should throw the maximum amount of ammunition we have towards minimizing it. Would this be worth the effort to implement? Please just do something :) I don't see why you can't supply the kernels with oprofile working in timer mode with a usable sampling frequency *right now*. That should be enough for the helpless users who can't or don't want to tweak and build their own kernels. And some kind of workaround for A8/A9 PMU can be always applied later once/if you get it working reliable enough. Also I don't know any details about A9 PMU problems, but the chance of encountering the missed PMU interrupt bug on A8 really depends on the use case which you are profiling. The code which uses lots of syscalls and spends a lot of time in the parts of the kernel accessing the problematic CP14/CP15 registers naturally has a *much* higher chance of triggering the bug. So if somebody says that the failure rate is very close to 0% and can be ignored, this may be not always the case. The whole situation reminds me of one part of some stupid Seagal movie: * 'mad scientist' villain : babbling something about how complex his system is and how it can't be stopped * the hero : shoots at the laptop * 'mad scientist' villain : I didn't think of that Come on, making oprofile practically usable on all ARM boards and devices is not that difficult. -- Best regards, Siarhei Siamashka ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Reboot not working with the newly built upstream custom kernel
Hello, I am trying to build the upstream kernel like linux-linaro-3.0, linux(linus), linux-next, linux-arm-soc for next builds with omap2plus defconfig, Create a kernel debian package and use this debian package to verify the build. The builds are enabled with ext3 file system. The scripts that is used to build the kernel for example is http://bazaar.launchpad.net/~linaro-infrastructure/linaro-ci/lci-build-tools/view/head:/jenkins_kernel_build_inst . The builddeb used contains modifications submitted to work for cross compilation and the changes are available at http://permalink.gmane.org/gmane.linux.linaro.devel/7443. Other than that there is no hand made changes to any files. An example hwpack that I created using the linaro-hwpack-replace can be downloaded from http://ci.linaro.org/kernel_hwpack/panda/hwpack_linaro-panda_20110927-0741_armel_supported.tar.gz . This consists of the kernel debian package built from linux-linaro-3.0 with omap2 defconfig to work on a panda board. [PS: linaro-hwpack-replace which is part of the linaro-image-tools is a tool that replaces the old kernel debian package in a given hwpack with the supplied kernel debian package ] I see that the kernel builds successfully, and the hwpack containing this newly built kernel debian package boots fine on the boards, but it fails to execute the reboot command and it hangs with the following message: # The system is going down for reboot NOW! root@linaro-nano:~# init: tty4 main process (3205) killed by TERM signal init: tty5 main process (3211) killed by TERM signal init: auto-serial-console main process (3213) killed by TERM signal init: tty2 main process (3215) killed by TERM signal init: tty3 main process (3218) killed by TERM signal init: tty6 main process (3224) killed by TERM signal init: openvt main process (3276) killed by TERM signal init: plymouth-upstart-bridge main process (3341) terminated with status 1 [ OK ]ing all remaining processes to terminate... [ OK ] processes ended within 1 seconds [ OK ]onfiguring network interfaces... [ OK ]ctivating swap... [ OK ]ounting weak filesystems... * Will now restart [ 2216.347167] Restarting system. # The board needs to be hard reset to boot back to the system. Has anyone seen this issue before, or do you suspect some problem with the kernel I built ?? I would be very thankful if someone can help me triage the problem. Thanks and Regards, Deepti. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.07 oprofile on panda busted?
On Tue, 2011-09-27 at 16:29 +0300, Siarhei Siamashka wrote: Please just do something :) I don't see why you can't supply the kernels with oprofile working in timer mode with a usable sampling frequency *right now*. That should be enough for the helpless users who can't or don't want to tweak and build their own kernels. And some kind of workaround for A8/A9 PMU can be always applied later once/if you get it working reliable enough. Be assured we consider timer mode granularity the highest priority aspect of this problem. My questions about using counter mode are to see if there is anything that could also be done there. Addressing issues with counter mode operation is lower priority but I have to ask the question while I have the attention of those that have the answers. -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root filesystem to ext4
On Monday 26 September 2011, Robert Schwebel wrote: On Thu, Aug 18, 2011 at 02:28:07PM +0200, Arnd Bergmann wrote: ext4 has optimizations for flash media in it and btrfs is better by design. Do you have a pointer to more info about what kind of optimizations for flash media ext4 has? We tried to find something, but didn't so far. No, sorry. I think the block allocation work rather differently, and the move from block pointers to extents should also help, but I don't know how much of that was done specifically for flash, or what other optimizations are there. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Announcing linaro-media-create and live-build integration
Hi All, As part of the 11.09 cycle I've completed an extension to live-build3 that add linaro-media-create. This means with this branch of linaro's live-build 3 one is able to build your custom image and directly output it to either your SD media or to a file which you an dd directly to the media of your choice. The extension lives in a bzr branch at lp:~tom-gall/live-build/integrate-linaro-media-create This code should be considered beta quality. There are bugs. The code is however useful. It will be especially useful when combined with the cross build support for live-build that was announced as part of the 11.07 cycle. I've updated my HOWTO which can be found here: https://wiki.linaro.org/LiveHelper/Hacking If you run into issues please either file a bug in launchpad https://bugs.launchpad.net/linaro-ubuntu , post to the list, or grab me on irc. (tgall_foo or Dr_Who) -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pin control subsystem v7
+static int pin_request(struct pinctrl_dev *pctldev,
+ int pin, const char *function, bool gpio,
+ struct pinctrl_gpio_range *gpio_range)
+{
+ struct pin_desc *desc;
+ const struct pinmux_ops *ops = pctldev-desc-pmxops;
+ int status = -EINVAL;
+
+ dev_dbg(pctldev-dev, request pin %d for %s\n, pin, function);
+
+ if (!pin_is_valid(pctldev, pin)) {
+ dev_err(pctldev-dev, pin is invalid\n);
+ return -EINVAL;
+ }
+
+ if (!function) {
+ dev_err(pctldev-dev, no function name given\n);
+ return -EINVAL;
+ }
+
+ desc = pin_desc_get(pctldev, pin);
+ if (desc == NULL) {
+ dev_err(pctldev-dev,
+ pin is not registered so it cannot be requested\n);
+ goto out;
+ }
+
+ spin_lock(desc-lock);
+ if (desc-mux_requested) {
+ spin_unlock(desc-lock);
+ dev_err(pctldev-dev,
+ pin already requested\n);
+ goto out;
+ }
+ spin_unlock(desc-lock);
Now this is racing with...
+
+ /* Let each pin increase references to this module */
+ if (!try_module_get(pctldev-owner)) {
+ dev_err(pctldev-dev,
+ could not increase module refcount for pin %d\n,
+ pin);
+ status = -EINVAL;
+ goto out;
+ }
+
+ /*
+ * 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)
+ /* This requests and enables a single GPIO pin */
+ status = ops-gpio_request_enable(pctldev, gpio_range, pin);
+ else if (ops-request)
+ status = ops-request(pctldev, pin);
+ else
+ status = 0;
+
+ if (status) {
+ dev_err(pctldev-dev, -request on device %s failed
+ for pin %d\n,
+ pctldev-desc-name, pin);
+ goto out;
+ }
+
... this:
+ spin_lock(desc-lock);
+ desc-mux_requested = true;
+ strncpy(desc-mux_function, function, sizeof(desc-mux_function));
+ spin_unlock(desc-lock);
+
2 threads can pass through when mux_requested is false and they might
both acquire
the pin, depending on specific driver implementation.
Regards,
Stijn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Infrastructure status report (2011-09-20 to 2011-09-26)
Enclosed please find a link to the Weekly Status report from the Infrastructure team for 2011-09-20 to 2011-09-26 period. == Meeting Minutes == https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-09-27 == Weekly Status Report == https://wiki.linaro.org/Platform/Infrastructure/Status/2011-09-28 == Team Highlights == * Offspring changes will be reviewed by Steve Magoun on Oct 1. * limited bot access granted to Mattias, greater permissions needed. * Released svammel. * l-i-t released * omapzoom kernel mirror moved to android.git.linaro.org, tests syncs using linaro-aosp-sync-bot user. * review/testing fgiff's Gerrit/Android Build integration * Completed the Blueprint initial-metadata-for-kernel-ci-jobs, all-ci-jobs-to-bzr, deliver-announce-beta-kernel-ci-service, kernel-build-results-to-lava BP's * Improved the jenkins jobs to build the kernel debian package to build in the jobs workspace than in the parent directory * Modified the jenkins job script to include the job name, so that the bundle stream now has a human readable and meaningful name. * Merged all django-group-access changes needed to use it for private projects in Offspring * Rebased 3 old Offspring branches on top of current trunk and proposed them for merging again. == Risks / Issues == * There is a problem with Vexpress V2 hwpacks in l-i-t 2011.09. Fix available * The kernel hwpack built seems to work fine for booting and running the tests, but it fails to reboot successfully. Reported in [[ https://bugs.launchpad.net/linaro-ci/+bug/860556|Bughttps://bugs.launchpad.net/linaro-ci/+bug/860556%7CBug860556]] == Miscellaneous == * N/A -- David Zinman Linaro Release Manager | Project Manager 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: Making it easier for Linaro users to help themselves
I think this would be worthwhile session. Coming from Gentoo, one thing we always put time into was our documentation. It was/is generally goal based and smoke tested. As an example, it's a worthwhile exercise to bring someone into the picture who is completely unfamiliar with your area. Give them a goal and point them at the wiki page(s) you think address the issue. If they are able to accomplish the task without help great, if not, the help you needed to give is what should have been in the document in the first place. It's too bad our wiki pages don't have a feedback mechanism to allow people to comment on the quality of the information there, and post problems/issues/questions left unanswered that they need. Regards, Tom On Tue, Sep 27, 2011 at 11:57 AM, Dave Martin dave.mar...@linaro.org wrote: Hi all, Over recent months I've had a steady stream of comments from external people trying to use the Linaro deliverables about the difficulty of getting started, understanding what Linaro produces and how to use it. My experience with supporting users is that using and making sense of the linaro output is often not nearly as easy as we would like to believe. Part of the problem seems to be that we may not do a good job of passing on the knowledge and understanding necessary to allow users to help themselves. Is it worth a session at Linaro Connect to discuss how we could improve the situation? This probably falls in the community area. Key things to discuss might be: * identifying and understanding our audience * providing the missing manual (what knowledge do we tend to assume in linaro that our audience may lack) * wiki ownership and maintenance (how do we _manage_ the information we produce to maximise its relevance and usefulness) (This includes identifying stale/obsolete information, removing duplicates and providing useful indices, contents lists and introductory material.) Ideally, we should get some users external to linaro to attend and/or provide input. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making it easier for Linaro users to help themselves
On 27 September 2011 20:42, Tom Gall tom.g...@linaro.org wrote: It's too bad our wiki pages don't have a feedback mechanism to allow people to comment on the quality of the information there, and post problems/issues/questions left unanswered that they need. You can fill bugs on linaro-documentation: https://launchpad.net/linaro-documentation https://bugs.launchpad.net/linaro-documentation ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making it easier for Linaro users to help themselves
On 09/27/2011 01:19 PM, Fathi Boudra wrote: On 27 September 2011 20:42, Tom Gall tom.g...@linaro.org wrote: It's too bad our wiki pages don't have a feedback mechanism to allow people to comment on the quality of the information there, and post problems/issues/questions left unanswered that they need. You can fill bugs on linaro-documentation: https://launchpad.net/linaro-documentation https://bugs.launchpad.net/linaro-documentation Also - we can add commenting ability to our wiki: http://moinmo.in/MacroMarket/MoinComments I'll take a look at prototyping. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making it easier for Linaro users to help themselves
On 09/27/2011 11:57 AM, Dave Martin wrote: Hi all, Over recent months I've had a steady stream of comments from external people trying to use the Linaro deliverables about the difficulty of getting started, understanding what Linaro produces and how to use it. My experience with supporting users is that using and making sense of the linaro output is often not nearly as easy as we would like to believe. Part of the problem seems to be that we may not do a good job of passing on the knowledge and understanding necessary to allow users to help themselves. Is it worth a session at Linaro Connect to discuss how we could improve the situation? This probably falls in the community area. Michael was just discussing doing a community session in Orlando. So I think this fits well with what he had in mind. Dave - In the meantime, please feel free to contact Michael and myself with specific problems you've encountered. We are very interested in making any improvements. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Graphics WG status report - wk38.2011 (20110919-20110923)
Status: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-09-21 == Highlights == - For the release : the only item which should be highlighted, was the glproxy not making a release after all due to bug https://bugs.launchpad.net/glproxy/+bug/855524. As a consequence the glcompbench release had to become simpler, containing a number of small fixes. Other components released as planned - the status link given above contains more details. - Team has started planning 1110 - Requirements for the next quarter - some draft requirements are so far added and are being reviewed in papyrs. Here are their public links UMM - Buffer sharing : https://linaro-public.papyrs.com/public/4147/GWG2011-UMM-BUFFER-SHARING# UMM - DMA mapping API: https://linaro-public.papyrs.com/public/4524/GWG2011-UMM-DMA-MAPPING# Benchmarking: https://linaro-public.papyrs.com/public/4143/GWG2011-BENCHMARK-DASHBOARD Webkit port using CAIRO-GLES: https://linaro-public.papyrs.com/public/4146/GWG2011-WEBKIT-CAIRO-GLES/# Best, -- Ilias Biris - ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris, Skype: ilias_biris Linaro.orf | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/2] drivers: create a pin control subsystem v7
Linus Walleij wrote at Tuesday, September 27, 2011 1:51 AM:
On Wed, Sep 21, 2011 at 9:45 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Wednesday, September 21, 2011 3:17 AM:
To abstract things the stuff we can do with the group should be
something enumerated too. So:
pinctrl_config_group(const char *pinctrl_device, const char *group,
const char *mode);
pinctrl_config_pin(const char *pinctrl_device, int pin, const char *mode);
So the driver need an API to enumerate pin and group modes.
I might want to save this thing for post-merge of the basic API and
pinmux stuff though so we don't try to push too much upfront
design at once.
Yes, adding in a replacement _config API can certainly be a later patch.
If I'm efficient enough we might get that add-on before the v3.2
merge window, I'll iterate that patch separately though.
One comment on the API above: I think you want mode (or setting?)
/and/ a value parameter; Tegra's pull strength definition for example
is:
enum tegra_pull_strength {
TEGRA_PULL_0 = 0,
TEGRA_PULL_1,
// ... (every value in between)
TEGRA_PULL_30,
TEGRA_PULL_31,
TEGRA_MAX_PULL,
};
And it seems better to represent that as (pull, 0) ... (pull, 31) than
pull0 .. pull31 such that the value needs to be parsed out of the mode
string somehow by the driver.
OK so we might want some public defintion of things you can do
with pins, then an opaque parameter.
like:
#define PINCTRL_PULL pull
#define PINCTRL_BIAS bias
#define PINCTRL_LOADCAP load-capacitance
#define PINCTRL_DRIVE drive
Yes although Tegra has quite a few more weird options than that; I'm not
sure exactly how many of the options that Tegra supports would be useful
for other SoCs, or what the best way to represent all the device-specific
knobs is. I guess we need another survey of a bunch of SoCs like you did
when designing the pinmux API.
...but then it's just simple enumerators, and we might be better off
with a simple enum after all:
enum pinctrl_pin_ops {
PINCTRL_PULL,
PINCTRL_BIAS,
PINCTRL_LOADCAP,
PINCTRL_DRIVE,
}
Surely the device tree will have to translate that enum into strings
(I guess? Sorry for my low DT competence) but that is more of a
DT pecularity and can be kept in the DT pin control parser?
DT as a data format can handle strings or integers just fine. However,
there's currently no support for named constants (i.e. #defines) in the
device-tree source format, so strings end up being a lot more self-
documenting. Whatever the DT format ends up being, we can certainly
map from whatever-dt-contains to whatever-Linux-APIs-need inside
whatever kernel function is written to extract the data from DT.
--
nvpublic
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux
Linus Walleij wrote at Tuesday, September 27, 2011 2:01 AM:
On Wed, Sep 21, 2011 at 9:39 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Wednesday, September 21, 2011 2:25 AM:
On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren swar...@nvidia.com
wrote:
Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
+ for (i = 0; i ARRAY_SIZE(u300_mux_hogs); i++) {
+ struct pinmux *pmx;
+ int ret;
+
+ pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
+ if (IS_ERR(pmx)) {
+ pr_err(u300: could not get pinmux hog %s\n,
+ u300_mux_hogs[i].name);
+ continue;
+ }
+ ret = pinmux_enable(pmx);
+ if (ret) {
+ pr_err(u300: could enable pinmux hog %s\n,
+ u300_mux_hogs[i].name);
+ continue;
+ }
+ u300_mux_hogs[i].pmx = pmx;
+ }
+ return 0;
+}
+subsys_initcall(u300_pinmux_fetch);
Why not just have the pinmux core support hogging on non-system mapping
entries; then everything I quoted above except u300_pinmux_map[] could
be deleted, and the hog flag set on the last 3 u300_pinmux_map[]
entries.
Very good question, luckily I have a good answer.
There is no way for the pinmux core to traverse the system and look
up the apropriate struct device * pointers.
It's unclear to me why that would be needed.
For non-system mappings, either the device-driver in question will be
get'ing and enabling them (this case isn't relevant to this discussion),
or they'll be hogged. In the hog case, I doubt anything would ever want
to disable them and switch the device to a different mapping entry; if
that were the case, the entries shouldn't be hogged, but get/enabled by
the device anyway. Hence, I don't see the need for an activation of a
hog'd non-system mapping entry to care about the device fields that are
in the mapping table at all; they could just be ignored couldn't they?
I don't think so, atleast not in this case. I think it is helpful for the
system
to know which device is related to the specific hog, so it turns up in
debugfs etc aha, it is hogged for that device etc. Not doing that
makes the subsystem loose relevant information.
So for that reason I prefer to pass in the relevant struct device *
pointers, atleast when they're readily available as in this boardfile.
If they are not available, or hard to get at, we could just redefine
them as system mappings and remove the device fields, but
in this case I'd say let's keep it around.
Yes, it makes perfect sense to show this in debugfs.
But can't debugfs just get its information from the device name field in
the mapping table? I'm not sure why the need to use that information for
debugfs prevents the having entries with both the hog flag set and a
device name set?
--
nvpublic
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Reboot not working with the newly built upstream custom kernel
Just out of curiosity, have you tried building an image locally using this hwpack and booting it? Thanks, Paul Larson On Tue, Sep 27, 2011 at 8:55 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: Hello, I am trying to build the upstream kernel like linux-linaro-3.0, linux(linus), linux-next, linux-arm-soc for next builds with omap2plus defconfig, Create a kernel debian package and use this debian package to verify the build. The builds are enabled with ext3 file system. The scripts that is used to build the kernel for example is http://bazaar.launchpad.net/~linaro-infrastructure/linaro-ci/lci-build-tools/view/head:/jenkins_kernel_build_inst . The builddeb used contains modifications submitted to work for cross compilation and the changes are available at http://permalink.gmane.org/gmane.linux.linaro.devel/7443. Other than that there is no hand made changes to any files. An example hwpack that I created using the linaro-hwpack-replace can be downloaded from http://ci.linaro.org/kernel_hwpack/panda/hwpack_linaro-panda_20110927-0741_armel_supported.tar.gz . This consists of the kernel debian package built from linux-linaro-3.0 with omap2 defconfig to work on a panda board. [PS: linaro-hwpack-replace which is part of the linaro-image-tools is a tool that replaces the old kernel debian package in a given hwpack with the supplied kernel debian package ] I see that the kernel builds successfully, and the hwpack containing this newly built kernel debian package boots fine on the boards, but it fails to execute the reboot command and it hangs with the following message: # The system is going down for reboot NOW! root@linaro-nano:~# init: tty4 main process (3205) killed by TERM signal init: tty5 main process (3211) killed by TERM signal init: auto-serial-console main process (3213) killed by TERM signal init: tty2 main process (3215) killed by TERM signal init: tty3 main process (3218) killed by TERM signal init: tty6 main process (3224) killed by TERM signal init: openvt main process (3276) killed by TERM signal init: plymouth-upstart-bridge main process (3341) terminated with status 1 [ OK ]ing all remaining processes to terminate... [ OK ] processes ended within 1 seconds [ OK ]onfiguring network interfaces... [ OK ]ctivating swap... [ OK ]ounting weak filesystems... * Will now restart [ 2216.347167] Restarting system. # The board needs to be hard reset to boot back to the system. Has anyone seen this issue before, or do you suspect some problem with the kernel I built ?? I would be very thankful if someone can help me triage the problem. Thanks and Regards, Deepti. ___ 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: Reboot not working with the newly built upstream custom kernel
Hello Paul, On Wed, Sep 28, 2011 at 7:05 AM, Paul Larson paul.lar...@linaro.org wrote: Just out of curiosity, have you tried building an image locally using this hwpack and booting it? I have not tried this specifically, but I have tried other hwpacks coming out of the same job. Thanks, Paul Larson Thanks and Regards, Deepti. On Tue, Sep 27, 2011 at 8:55 AM, Deepti Kalakeri deepti.kalak...@linaro.org wrote: Hello, I am trying to build the upstream kernel like linux-linaro-3.0, linux(linus), linux-next, linux-arm-soc for next builds with omap2plus defconfig, Create a kernel debian package and use this debian package to verify the build. The builds are enabled with ext3 file system. The scripts that is used to build the kernel for example is http://bazaar.launchpad.net/~linaro-infrastructure/linaro-ci/lci-build-tools/view/head:/jenkins_kernel_build_inst . The builddeb used contains modifications submitted to work for cross compilation and the changes are available at http://permalink.gmane.org/gmane.linux.linaro.devel/7443. Other than that there is no hand made changes to any files. An example hwpack that I created using the linaro-hwpack-replace can be downloaded from http://ci.linaro.org/kernel_hwpack/panda/hwpack_linaro-panda_20110927-0741_armel_supported.tar.gz . This consists of the kernel debian package built from linux-linaro-3.0 with omap2 defconfig to work on a panda board. [PS: linaro-hwpack-replace which is part of the linaro-image-tools is a tool that replaces the old kernel debian package in a given hwpack with the supplied kernel debian package ] I see that the kernel builds successfully, and the hwpack containing this newly built kernel debian package boots fine on the boards, but it fails to execute the reboot command and it hangs with the following message: # The system is going down for reboot NOW! root@linaro-nano:~# init: tty4 main process (3205) killed by TERM signal init: tty5 main process (3211) killed by TERM signal init: auto-serial-console main process (3213) killed by TERM signal init: tty2 main process (3215) killed by TERM signal init: tty3 main process (3218) killed by TERM signal init: tty6 main process (3224) killed by TERM signal init: openvt main process (3276) killed by TERM signal init: plymouth-upstart-bridge main process (3341) terminated with status 1 [ OK ]ing all remaining processes to terminate... [ OK ] processes ended within 1 seconds [ OK ]onfiguring network interfaces... [ OK ]ctivating swap... [ OK ]ounting weak filesystems... * Will now restart [ 2216.347167] Restarting system. # The board needs to be hard reset to boot back to the system. Has anyone seen this issue before, or do you suspect some problem with the kernel I built ?? I would be very thankful if someone can help me triage the problem. Thanks and Regards, Deepti. ___ 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
