linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[Francis J. Lacoste] Announcing Launchpad Squads

by James Westby

Hi, Since we use Launchpad so much within Linaro this may be of interest to some. I am the Launchpad stakeholder representative for Linaro, so if you wish to request any features or escalate any bugs then please feel free to talk to me. Thanks, James

13 years, 11 months

[RFC PATCH] SDHCI: S3C: Add support for retrieving memory and irq resource information from device tree.

by thomas.abraham＠linaro.org

From: Thomas Abraham <thomas.abraham(a)linaro.com> Add support for retrieving memory and irq resource information from device tree for Samsung's SDHCI controller driver. Signed-off-by: Thomas Abraham <thomas.abraham(a)linaro.org> --- The modification will be made more generic to support both DT and non-DT versions of the driver without the #ifdef's. For now, this patch is for review and to understand if the approach adopted to obtain resource information from the device tree is appropriate. drivers/mmc/host/sdhci-s3c.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c index 1720358..f536061 100644 --- a/drivers/mmc/host/sdhci-s3c.c +++ b/drivers/mmc/host/sdhci-s3c.c @@ -19,6 +19,9 @@ #include <linux/clk.h> #include <linux/io.h> #include <linux/gpio.h> +#include <linux/of.h> +#include <linux/of_irq.h> +#include <linux/of_address.h> #include <linux/mmc/host.h> @@ -348,23 +351,52 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev) struct sdhci_s3c *sc; struct resource *res; int ret, irq, ptr, clks; + struct device_node *np = NULL; +#ifdef CONFIG_OF + struct resource iores; +#endif if (!pdata) { dev_err(dev, "no device data specified\n"); return -ENOENT; } +#ifdef CONFIG_OF + for_each_compatible_node(np, NULL, "samsung,sdhci-s3c") { + const u32 *id = of_get_property(np, "cell-index", NULL); + if (be32_to_cpu(*id) == pdev->id) + break; + } + + if (!np) { + dev_err(dev, "no matching device node specified in device tree\n"); + return -ENOENT; + } +#endif + +#ifndef CONFIG_OF irq = platform_get_irq(pdev, 0); +#else + irq = of_irq_to_resource(np, 0, NULL); +#endif if (irq < 0) { dev_err(dev, "no irq specified\n"); return irq; } +#ifndef CONFIG_OF res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(dev, "no memory specified\n"); return -ENOENT; } +#else + if (of_address_to_resource(np, 0, &iores)) { + dev_err(dev, "no memory specified in device tree\n"); + return -ENOENT; + } + res = &iores; +#endif host = sdhci_alloc_host(dev, sizeof(struct sdhci_s3c)); if (IS_ERR(host)) { -- 1.6.6.rc2

13 years, 11 months

Tidying up some ARM boards

by Michael Hope

My office was getting a bit messy so I re-purposed an old PC case and mounted my ARM boards, a switch, and far too many power supplies into it: http://people.linaro.org/~michaelh/racked/IMG_20110131_145444.jpg The Stagecoach board goes where the motherboard used to: http://people.linaro.org/~michaelh/racked/IMG_20110131_145403.jpg It turns out that a PandaBoard fits well in a floppy drive adapter slotted into a 5 1/4" drive bay. 2x PandaBoards, 2x BeagleBoards, and a Stagecoach gives 12 cores for a total of 9.76 GHz of processing... not as cool as David's box, but I like it :) -- Michael

13 years, 11 months

Fwd: Generating ancilliary sections with gas

by Dave Martin

[Forwarding this to linaro-dev too ... should have sent it there in the first place! ---Dave] ---------- Forwarded message ---------- From: Dave Martin <dave.martin(a)linaro.org> Date: Fri, Jan 28, 2011 at 11:52 AM Subject: Generating ancilliary sections with gas To: linaro-toolchain <linaro-toolchain(a)lists.linaro.org> Hi all, With gas, does anyone know of a way to create a section whose name is based on that of the current section? The specific requirement is to be able to define a generic macro like the example "fixup" below, whose purpose is to record ancilliary data related to some other section. To illustrate: .macro fixup 100\@ : .pushsection fixup<current section name>, "a" .long 100\@b .popsection .endm .text ... fixup .long sym1 ... .section .other, "ax" ... fixup .long sym2 The linux kernel uses a technique just like this for patching SMP kernels at bootup to work on uniprocessor platforms (when CONFIG_SMP_ON_UP is enabled), resulting in code looking something like this: void exit __attribute__ (( __section__ (".text.exit") )) { ... asm( ... FIXUP("something") ... ); } Note that the inline asm may actually come out of a generic header file rather than being explitly written for this invocation. So it may have to be truly generic. Is far as I have been able to determine, it's not possible to generate sections named based on the current section. In practice, the kernel puts all the fixups into a single section. The downside of this is that when sections are selectively discarded at link time (which in general may happen -- for example, Linux discards the "module exit" code for drivers which are built into the kernel and therefore never exit) there is no way to selectively discard the related fixup entries. Currently the only solution is to include all the module exit code in the image and discard it at run-time when the kernel boots. This is obviously wasteful. Attempting to discard that code at like time results in a link error, since fixups refer to the removed sections. Of course, the "fixup" macro could be given an extra parameter to name the containing section, but the macro can then no longer be called in a generic way: all the calls to that macro must be manually (and buggily) maintained to ensure that the referenced section name is correct, some object post-processing must be done before linking, and/or a tool must be created to implement the missing assembler functionality. Unfortunately, such solutions are likely to be too fragile or complex to make it upstream. It's interesting to note that the same problem will apply for any section containing ancilliary data for another section. In particular, it looks like either the ABI or the assembler has had to grow a special-case workaround for this in order to support exception unwind information sections generated by .fnstart ... .fnend in a sane way: the unwind information sections get called .ARM.ex{idx,tab} for .text, and .ARM.ex{idx,tab}<section> for any other section. As a consequence, link-time discarding can handle this information properly, but IMHO this is a bit of a cheat and admits the general need to create sections with names based transparently on those of other sections, without satisfying that need. .popsection is also an example of such a cheat: most other aspects of assmbler state still cannot be saved and restored. In general, it would be useful if gas supported some general reflective abilities: i.e., the ability to query the current assembler state (section, subsection, active instruction set, active macro mode, etc.) and/or the ability to wrap or hook existing pseudo-ops. For example, the above problem would almost certainly solvable using assembler macros (albeit painfully) if wrapper macros could be defined for the section manipulation directives (section, .text, .data, .bss, .pushsection, .popsection, .previous). However, supporting some magic macro parameters reflecting the assembler state would be a lot simpler. As an example of the kind of behaviour I think would be useful, the macro argument qualifier could be extended to allow macros to query the assembler state in a backwards-compatible way; something like: .macro fixup base_section:gas_current_section_name, old_altmacro:gas_macro_mode .altmacro LOCAL fixup_location fixup_location: .pushsection \base_section\().fixup .long 100\@b .popsection \old_altmacro .endm Existing assembler code will continue to work just fine with this approach. Note how this also enables a local label to be generated hygenically, by making it possible to save and restore the macro mode. Otherwise, .altmacro (and hence LOCAL) is hard to use safely, since the initial macro mode is unknown and can't be restored. Any thoughts / comments? Cheers. ---Dave

13 years, 11 months

Notes & Actions: Linaro Developer Platform Weekly Status Meeting 1/26

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on January 26th in #linaro-meeting on irc.freenode.net at 15:00 UTC. https://wiki.linaro.org/Platform/Foundations/2011-01-26 Actions from the meeting where as follows: * wookey rewarded for great work on omxil components FTBFS by also helping get the ffmpeg-dist component building * slangasek to get tgall_foo his uboot env settings for a BB Regards, Tom (tgall_foo) Developer Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 11 months

Hudson bzr branches

by Loïc Minier

Hey I'd like to propose moving our Hudson stuff to Launchpad hosted branches. This would be useful to: * share our stuff, perhaps in common repos across hudson instances (see below) * have everybody follow best practices of keeping as much as possible under a VCS * help move/factor hudson instances (e.g. factor two instances in one, move from home server or cloud to Linaro/Canonical IS datacenter) I see two ways to approach this problem: * each team owns a hudson instance, and stores its config and scripts in the team's namespace; this doesn't encourage factoring instances together though * we create a virtual team of people caring for hudson stuff, e.g. ~linaro-hudson-hackers, and we put branches below that We will need to keep the hudson configs private because they might hold private data like hudson's secret key or the userdb, perhaps with some private bzr branches? or can we move to openid and avoid storing the other secret keys already? The branch with build script would of course be public. We could have some cron committing each config (changed from the web UI) hourly, and pushing it to LP, and a cron pulling the latest version of the scripts hourly (or a special hudson job which does either). For scripts, we'd have to agree on some conventions such as namespaces for Android build scripts (e.g. android-list-changes), hudson job definitions (e.g. job-build-u-boot, or job-build-android). Two things which might slow us down if we want to proceed: * Hudson might get renamed due to the situation with Oracle * getting private branches * we need some kind of Launchpad accounts for the hudson instances to commit stuff Paul, James, Michael Hudson, (Alexander?), and anybody, what are your thoughts? Cheers, -- Loïc Minier

13 years, 11 months

[RFC] C-state map for i.MX51

by Yong Shen

Hi there, I am trying to implement cpuidle driver for imx51, and for better understanding how various c-state map to ARM soc, I would like to get some comments. First of all, we basically have 3 major state for imx51, which are defined in specification of the soc. Like: RUN - Core is active, clocks are on, the peripheral modules required are active. SW can close clocks of modules that are not in use. In addition CCM can enable power gating for the modules described above. WAIT - Core is disabled and clock gated, bus clocks to peripherals can be on as required. PG [power gating] and SRPG[state retention PG] can be applied to Cortex_A8 and the different blocks as described on the section above. STOP - Core is disabled, peripherals are disabled, bus clocks are off, PLLs off. PG and SRPG can be applied to Cortex_A8 and the different blocks as described on the section above. Naturely, I think the maping can be: RUN - c0 WAIT - c1 STOP - c2 Or, if possible, some extra states can be assert into each c-state to get c3, c4.... Since other SOCs, like omap or samsung's chip, already have cpuidle driver, I would like to especially compare imx51 with those. thanks Yong

13 years, 11 months

Re: [PATCH 0/5] mmc: add double buffering for mmc block requests

by Per Forlin

On 18 January 2011 03:35, Jaehoon Chung <jh80.chung(a)samsung.com> wrote: > Hi Per.. > > it is interesting approach..so > we want to test your double buffering in our environment(Samsung SoC). > > Did you test with SDHCI? So far I have only tested on mmci for board u5500 and u8500. I happily test on a different board if I can get hold of one. > If you tested with SDHCI, i want to know how much increase the performance. > > Thanks, > Jaehoon Chung

13 years, 11 months

Re: Linaro Image Tools 0.4.2 released

by Loïc Minier

On Sat, Jan 29, 2011, Loïc Minier wrote: > Backports to Ubuntu 10.04 and Ubuntu 10.10 will be provided shortly. A backport to Ubuntu 10.04 willl take longer to prepare, but a backport to Ubuntu 10.10 is now available in ppa:linaro-maintainers/tools. -- Loïc Minier

13 years, 11 months

Booting Versatile Express Made Easy

by Pawel Moll

Hi Folks, I believe that every Versatile Express board user would agree that booting Linux kernel on it is "slightly" more complex than on, say, Beagle... I wrote a short text describing how do I do this: https://wiki.linaro.org/PawelMoll/BootingVEMadeEasy The interesting bit may be lack of U-boot in my flow. In future the VE Boot Monitor will be able to boot the kernel on its own, but it is effectively possible already, with a few tricks. So the only case one would have to use U-boot is to download kernel over network. Anyway, any feedback appreciated, especially if all thing is absolutely pointless. Don't hesitate to use the Wiki "Edit" button :-) Additionally I think that using similar technique, it would be possible to prepare a U-boot-less MMC card automatically booting kernel. Let me know if anyone is interested - it could be potentially useful for the media-create script? Cheers! Paweł

13 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev