linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Minutes and actions from MM WG call on 8th Feb 2011

by Sachin Gupta

Hi All, Please find enclosed link to minutes and actions for multimedia wg meeting on 8st Feb 2011. https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-02-08 Summary - Discussions with gstreamer lead architect on improvements in gstreamer for zero copy on going - Discussions with Mans Rullgarg from arm on worksplit for neon optimisation topics - Panda instablities causing delays in pulse audio activities - System metrics application work progressing fine, will need Panda for validation - Freescale engineers Jian and Kan on vacation on occasion of Chinese new year Thanks Sachin

13 years, 10 months

[RFC] dt: add of_platform_bus_snoop() which attaches nodes to devices

by Grant Likely

This patch implements an alternate method for using device tree data for populating machine device registration. Traditionally, board support has directly generated and registered devices based on nodes in the device tree. The board support code starts at the root of the tree and begins allocating devices for each device node it finds. Similarly, bus drivers (i2c, spi, etc.) use their child nodes to register child devices. This model can be seen in almost all the powerpc board ports (arch/powerpc/platforms/*). However, for many of the ARM SoCs, there already exists complete board support for many SoCs that have their own code for registering the basic set of platform devices with non-trivial dependencies on clock structure and machine specific platform code. While starting at the base of the tree and working up is certainly possible, it requires modifying a lot of machine support code to get it working. Instead, this patch provides an alternate approach. Instead of starting at the root of the tree and working up, this patch allows the SoC support code to register its standard set of platform devices in the normal way. However, it also registers a platform_bus notifier function which compares platform_device registrations with data in the device tree. Whenever it finds a matching node, it increments the node reference count and assigns it to the device's of_node pointer so that it is available for the device driver to use and bind against. For example, an spi master driver would have access to the spi node which contains information about all the spi slaves on the bus. An example usage of this facility is to allow a single 'devicetree' board support file to support multiple machines all using the same SoC. The common code would register SoC devices unconditionally, and the board support code would depend entirely on device tree data. Note: Board ports using this facility are still required to provide a fully populated device tree blob. It is not a shortcut to providing an accurate device tree model of the machine to the point that it would be reasonably possible to switch to a direct registration model for all devices without change the device tree. ie. The SoC still needs to be correctly identified and there should be nodes for all the discrete devices. I'm not convinced that this is the model to pursue over the long term, but it greatly simplifies the task of getting device tree support up and running, and it provides a migration path to full dt device registration (if it makes sense to do so). Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> --- This patch can be found in my devicetree/test branch (frequently rebased) git://git.secretlab.ca/git/linux-2.6 devicetree/test I'll move it to devicetree/arm (never rebased) once it is stable. g. arch/arm/mach-versatile/core.c | 3 + drivers/of/address.c | 14 ++ drivers/of/base.c | 3 + drivers/of/platform.c | 230 ++++++++++++++++++++++++++++++++++++++++ include/linux/of_address.h | 1 include/linux/of_platform.h | 2 6 files changed, 253 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c index 136c32e..86ad01d 100644 --- a/arch/arm/mach-versatile/core.c +++ b/arch/arm/mach-versatile/core.c @@ -21,6 +21,7 @@ #include <linux/init.h> #include <linux/device.h> #include <linux/dma-mapping.h> +#include <linux/of_platform.h> #include <linux/platform_device.h> #include <linux/sysdev.h> #include <linux/interrupt.h> @@ -873,6 +874,8 @@ void __init versatile_init(void) clkdev_add_table(lookups, ARRAY_SIZE(lookups)); + of_platform_bus_snoop(NULL, NULL); + platform_device_register(&versatile_flash_device); platform_device_register(&versatile_i2c_device); platform_device_register(&smc91x_device); diff --git a/drivers/of/address.c b/drivers/of/address.c index b4559c5..b43ff66 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -556,6 +556,20 @@ static int __of_address_to_resource(struct device_node *dev, } /** + * of_address_count - Return the number of entries in the reg property + */ +int of_address_count(struct device_node *np) +{ + struct resource temp_res; + int num_reg = 0; + + while (of_address_to_resource(np, num_reg, &temp_res) == 0) + num_reg++; + return num_reg; +} +EXPORT_SYMBOL_GPL(of_address_count); + +/** * of_address_to_resource - Translate device tree address and return as resource * * Note that if your address is a PIO address, the conversion will fail if diff --git a/drivers/of/base.c b/drivers/of/base.c index 710b53b..632ebae 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -496,6 +496,9 @@ EXPORT_SYMBOL(of_find_node_with_property); const struct of_device_id *of_match_node(const struct of_device_id *matches, const struct device_node *node) { + if (!matches) + return NULL; + while (matches->name[0] || matches->type[0] || matches->compatible[0]) { int match = 1; if (matches->name[0]) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index c01cd1a..559bfe3 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -11,11 +11,15 @@ * 2 of the License, or (at your option) any later version. * */ + +#define DEBUG + #include <linux/errno.h> #include <linux/module.h> #include <linux/device.h> #include <linux/dma-mapping.h> #include <linux/slab.h> +#include <linux/notifier.h> #include <linux/of_address.h> #include <linux/of_device.h> #include <linux/of_irq.h> @@ -767,4 +771,230 @@ int of_platform_bus_probe(struct device_node *root, return rc; } EXPORT_SYMBOL(of_platform_bus_probe); + + +struct of_platform_bus_snoop_node_data { + struct list_head list; + struct device_node *node; + struct device *dev; /* assigned device */ + + int num_resources; + struct resource resource[0]; +}; + +struct of_platform_bus_snoop_data { + struct list_head nodes; + struct notifier_block nb; +}; + +static bool of_pdev_match_resources(struct platform_device *pdev, + struct of_platform_bus_snoop_node_data *node_data) +{ + struct resource *node_res = node_data->resource; + struct resource *pdev_res = pdev->resource; + int i, j; + + /* Compare both resource tables and make sure every node resource + * is represented by the platform device. Here we check that each + * resource has corresponding entry with the same type and start + * values, and the end value falls inside the range specified + * in the device tree node. */ + for (i = 0; i < node_data->num_resources; i++, node_res++) { + for (j = 0; j < pdev->num_resources; j++, pdev_res++) { + if ((pdev_res->start == node_res->start) && + (pdev_res->end >= node_res->start) && + (pdev_res->end <= node_res->end) && + (pdev_res->flags == node_res->flags)) + break; + } + if (j >= pdev->num_resources) + return false; + } + return true; +} + +static int of_platform_bus_snoop_notifier_call(struct notifier_block *nb, + unsigned long event, void *_dev) +{ + struct platform_device *pdev = to_platform_device(_dev); + struct of_platform_bus_snoop_data *data; + struct of_platform_bus_snoop_node_data *node_data; + +#ifdef DEBUG + struct resource *res = pdev->resource; + int i; + pr_debug("snooping: '%s':\n", dev_name(&pdev->dev)); + for (i = 0; i < pdev->num_resources; i++, res++) + pr_debug("snooping: %2i:%.8x..%.8x[%lx]\n", i, + res->start, res->end, res->flags); +#endif + + if (pdev->dev.of_node) + return NOTIFY_DONE; + + data = container_of(nb, struct of_platform_bus_snoop_data, nb); + + switch (event) { + case BUS_NOTIFY_ADD_DEVICE: + list_for_each_entry(node_data, &data->nodes, list) { + if (node_data->dev) + continue; + + if (!of_pdev_match_resources(pdev, node_data)) + continue; + + pr_debug("%s: add reference to node %s\n", + dev_name(&pdev->dev), + node_data->node->full_name); + node_data->dev = get_device(&pdev->dev); + pdev->dev.of_node = of_node_get(node_data->node); + return NOTIFY_OK; + } + break; + + case BUS_NOTIFY_DEL_DEVICE: + list_for_each_entry(node_data, &data->nodes, list) { + if (node_data->dev == &pdev->dev) { + pr_debug("%s: removing reference to %s\n", + dev_name(&pdev->dev), + node_data->node->full_name); + of_node_put(pdev->dev.of_node); + put_device(node_data->dev); + pdev->dev.of_node = NULL; + node_data->dev = NULL; + return NOTIFY_OK; + } + } + break; + } + + return NOTIFY_DONE; +} + +int of_platform_bus_snoop_children(struct of_platform_bus_snoop_data *data, + struct device_node *parent, + const struct of_device_id *bus_match) +{ + struct device_node *child; + + /* Loop over children and record the details */ + for_each_child_of_node(parent, child) { + struct of_platform_bus_snoop_node_data *node_data; + struct resource *res; + int num_irq, num_reg, i, rc; + + /* Make sure it has a compatible property */ + if (!of_get_property(child, "compatible", NULL)) + continue; + + num_irq = of_irq_count(child); + num_reg = of_address_count(child); + node_data = kzalloc(sizeof(*node_data) + + (sizeof(struct resource) * (num_irq + num_reg)), + GFP_KERNEL); + if (!node_data) + return -ENOMEM; + INIT_LIST_HEAD(&node_data->list); + + res = &node_data->resource[0]; + for (i = 0; i < num_reg; i++, res++) + WARN_ON(of_address_to_resource(child, i, res)); + WARN_ON(of_irq_to_resource_table(child, res, num_irq) != num_irq); + node_data->num_resources = num_reg + num_irq; + node_data->node = of_node_get(child); + + list_add_tail(&node_data->list, &data->nodes); + + /* If this is a bus node, recursively inspect the children */ + if (of_match_node(bus_match, child)) { + rc = of_platform_bus_snoop_children(data, child, bus_match); + if (rc) + return rc; + } + } + + return 0; +} + +/** + * of_platform_bus_snoop - Attach device nodes to platform bus registrations. + * @root: parent of the first level to probe or NULL for the root of the tree + * @bus_match: match table for child bus nodes, or NULL + * + * This function sets up 'snooping' of device tree registrations and + * when a device registration is found that matches a node in the + * device tree, it populates the platform_device with a pointer to the + * matching node. + * + * A bus notifier is used to implement this behaviour. When this + * function is called, it will parse all the child nodes of @root and + * create a lookup table of eligible device nodes. A device node is + * considered eligible if it: + * a) has a compatible property, + * b) has memory mapped registers, and + * c) has a mappable interrupt. + * + * It will also recursively parse child buses providing + * a) the child bus node has a ranges property (children have + * memory-mapped registers), and + * b) it is compatible with the @matches list. + * + * The lookup table will be used as data for a platform bus notifier + * that will compare each new device registration with the table + * before a device driver is bound to it. If there is a match, then + * the of_node pointer will be added to the device. Therefore it is + * important to call this function *before* any platform devices get + * registered. + */ +int __init of_platform_bus_snoop(struct device_node *root, + const struct of_device_id *bus_match) +{ + struct of_platform_bus_snoop_data *data; + struct of_platform_bus_snoop_node_data *node_data, *tmp; + int rc; + + if (!root) + root = of_find_node_by_path("/"); + else + of_node_get(root); + if (root == NULL) + return -EINVAL; + + pr_debug("of_platform_bus_snoop()\n"); + pr_debug(" starting at: %s\n", root->full_name); + + data = kzalloc(sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + INIT_LIST_HEAD(&data->nodes); + + rc = of_platform_bus_snoop_children(data, root, bus_match); + if (rc) + goto bail; + +#ifdef DEBUG + list_for_each_entry(node_data, &data->nodes, list) { + struct resource *res = node_data->resource; + int i; + pr_info("snoop: '%s':\n", node_data->node->full_name); + for (i = 0; i < node_data->num_resources; i++, res++) + pr_info("snoop: %2i:%.8x..%.8x[%lx]\n", i, + res->start, res->end, res->flags); + } +#endif + + data->nb.notifier_call = of_platform_bus_snoop_notifier_call; + bus_register_notifier(&platform_bus_type, &data->nb); + + return 0; + + bail: + list_for_each_entry_safe(node_data, tmp, &data->nodes, list) { + list_del(&node_data->list); + of_node_put(node_data->node); + kfree(node_data); + } + kfree(data); + return rc; +} #endif /* !CONFIG_SPARC */ diff --git a/include/linux/of_address.h b/include/linux/of_address.h index 2feda6e..6711d5f 100644 --- a/include/linux/of_address.h +++ b/include/linux/of_address.h @@ -3,6 +3,7 @@ #include <linux/ioport.h> #include <linux/of.h> +extern int of_address_count(struct device_node *np); extern u64 of_translate_address(struct device_node *np, const __be32 *addr); extern int of_address_to_resource(struct device_node *dev, int index, struct resource *r); diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h index a68716a..bf40328 100644 --- a/include/linux/of_platform.h +++ b/include/linux/of_platform.h @@ -74,6 +74,8 @@ extern struct platform_device *of_platform_device_create(struct device_node *np, extern int of_platform_bus_probe(struct device_node *root, const struct of_device_id *matches, struct device *parent); +extern int of_platform_bus_snoop(struct device_node *root, + const struct of_device_id *bus_match); #endif /* !CONFIG_SPARC */ #endif /* CONFIG_OF_DEVICE */

13 years, 10 months

access to imx51, lt-s5pv310, overo and vexpress boards??

by Torez Smith

I'm investigating the powerdebug tool on all platforms for which there is a Linaro image. Can anyone with boards imx51, lt-s5pv310, overo and vexpress provide access for a short period of time?

13 years, 10 months

Fwd: Thermal Manager git

by Amit Kucheria

Steve, Forwarding to linaro-dev since this might be of general interest. Here is an experimental version of a thermal manager that allows us to take appropriate actions in case of overheating. Since temperature changes relatively slowly, the implementation is in userspace. If you're interested in this problem, please download it, take it for a spin and give us feedback. Regards, Amit ---------- Forwarded message ---------- From: Steve Jahnke <steve.jahnke(a)linaro.org> Date: Thu, Feb 10, 2011 at 8:37 PM Subject: Thermal Manager git To: Amit Kucheria <amit.kucheria(a)linaro.org> I have the initial user space thermal manager up on git.linaro.org - can clone as usual: git clone git://git.linaro.org/people/stevejahnke/thermal_manager.git Please review the README to get an idea of what it is/is not/will be. If anyone is so inclined to work on this, please let me know before making a bunch of additions or anything - there will be some massive additions over the next few weeks to start to flesh out the rest of the work and some coordination would be needed........ <snip> Best Regards, Steve

13 years, 10 months

Minutes & Actions: Kernel Working Group meeting of Feb 07, 2011

by Mounir Bsaibes

Greetings, Enclosed you'll find a link to the agenda, minutes and actions from the Linaro kernel working group weekly meeting of Feb 07, 2011. https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2011-02-… === Summary === * Redesigned flash remapper and started implementing UBD based remapper * Reposted omap3/4 Thumb-2 compatiblity patches, generally positive feedback and some positive test results * MX53 uboot support done, already in Wolfgang's master tree. * Posted proposal for clk_enable/clk_prepare API & locking semantics * Completed next revision of clk API patches with clk_prepare interface * Started proof of concept port of clk_prepare API for versatile, integrator and realview * Discussed Linaro Android platform goals and possible future work items, see minutes here: https://wiki.linaro.org/Platform/Android/2011-02-04 * Submitted CLOCK_BOOTTIME patches to lkml. * RTC re-work, large amount of changes to push for 2.6.39. * Developed algorithm for finding PLL multiplier/divider values automatically with least divisor (helps in faster locking) consulting with TI hw design team. * Moved bss to SDRAM as per community suggestions. * Linaro kernel maintenance, merged multiple ARM patches into Linaro tree * Device Tree * devicetree/arm on git://git.secretlab.ca/git/linux-2.6 has everything needed to turn on basic device tree support for any platform. * Similarly, u-boot just needs to have the CONFIG_OF_LIBFDT defined to turn on device tree support. * IRQ handling is still a problem and only one interrupt controller can be supported at the moment, but Lennert is working on a solution. * Posted a patch that will allow dt and non-dt device registration to co-exist peacefully by snooping platform device registrations. I could use some feedback and testing. * Looking into merging the the basic dt support into Nicolas' tree this * Added basic device tree support for Samsung's SMDKV310 board. * Bootargs and memory information is obtained from the device tree correctly. * Added device tree support in Samsung's watchdog timer driver and driver works fine in both DT and non-DT mode. * Submitted patches for enabling basic device tree support for SMDKV310 board. * Andy Green: TI looking to port their BSP from 2.6.35 to 2.6.38. They have been getting some of their patches into mainline-ready form, and will continue maintaining their BSP on recent mainline. Mounir

13 years, 10 months

Minutes & actions: Toolchain Working Group meetings of Feb 9 & 7, 2011

by Mounir Bsaibes

Greetings, Enclosed you'll find a link to the agenda, minutes and actions from the Linaro toolchain working group weekly meetings of Feb 07 & Feb 09, 2011. https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-02-07 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-02-09 == Summary == * Did the 2011.02 releases * Linaro GCC 4.4 and 4.5 * Third release of Linaro GDB (second one of interest) * First release of Linaro QEMU * Swing-modulo-scheduling based performance work is ready, pending copyright issues * Perparing to get the string routines into Ubuntu before the feature freeze * IFUNC work has started going upstream. EABI addition is partly approved Mounir

13 years, 10 months

Linaro 11.05 Weekly Testing 2011-02-10

by Jamie Bennett

Hi, This is a message sent out once per week to call on our community to help test the Linaro evaluation builds we produce. If you have supported hardware, as found on: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/ please help our initiative by testing: Headless: http://snapshots.linaro.org/11.05-daily/linaro-headless/ ALIP: http://snapshots.linaro.org/11.05-daily/linaro-alip/ Netbook: http://snapshots.linaro.org/11.05-daily/linaro-netbook-efl/ Developer Tools: http://snapshots.linaro.org/11.05-daily/linaro-developer/ Make your way to: http://wiki.linaro.org/Releases/DailyBuilds for an explanation on how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Regards, Jamie. -- Linaro Release Manager

13 years, 10 months

Fun with libtool and cross-builds

by Wookey

[This was also posted to debian-devel but I got the linaro addesss wrong: http://lists.debian.org/debian-devel/2011/02/msg00196.html] Libtool is intended to make library linking 'just work' whatever the details of your build mechanisms are. However in Debian/Ubuntu cross-building it seems to go out of its way to make it not-work. The problem is papered-over when using i386 machines, or amd64 machines and a new-enough (or old enough) version of binutils, but this seems to me to be a very poor solution as it has to be put into the linker for every cross-combination people might choose to build between. Making libtool actually do the right thing would be much better. In fact it would be correct, and we like correctness. This is not a new problem. In a bit of research I found a post suggesting it was actually broken in 2002 (I've not yet looked into this). (a long list of previous posts on the issue from OE, Debian, Ubuntu, astlinux and buildroot people is at the end of this mail). Now, before I get too carried away I want to check that I'm not just misunderstanding something. It seems faintly crazy that this very straightforward cross-comiling problem is not already solved. And I have to admit that I have always done my best to avoid understanding the details of libtool (like most people). However I think the time has come to sort this out properly, if in fact it hasn't been already. The problem ----------- We are crossbuilding Debian packages, that build libraries, which link to other libraries. There are lots of those, but I'm using unixodbc and libprce3 here as they seem fairly typical examples. The libraries to link against are installed into a directory, historically /usr/<triplet>/lib, but moving to /usr/lib/<host-multiarchtuple> using multiarch mechanisms. They could also be in sysroot locations if using sysroot mechanisms). The point is that they are _not_ in /usr/lib (or /usr/lib/<build-multiarchtuple> in multiarch world). libtool gets most of this process right (or at least not wrong), until the library is installed into the package location typically (debian/tmp/usr/lib) using libtool's 'install' mode, which then calls libtool with mode 'relink'. At this points it calls the linker and adds -L/usr/lib on the front - thereby adding this path in front of the default cross-compiler path. If called without this -L, or called with -L/usr/<triplet>/lib (i.e the correct path, wherever that is), then everything is fine because the libraries for the correct (host) architecture are found. So there are 2 ways to get this right and one way to get it wrong, which is the one libtool picks. The workarounds which mean this has not yet been fixed are that the linker used to just issue a warning and ignore libraries which it didn't understand: /usr/lib/libgcc_s.so: file not recognized: File format not recognized And more recently it has been taught to understand specific architectures enough to decide they are the wrong ones: /usr/arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc However on amd64 machine with armel toolchain and binutils-arm-linux-gnueabi_2.20.51.20100908-0ubuntu2cross1.52 the skipping fails for static libs: /usr/lib/libc.a: could not read symbols: File format not recognized and the build fails. on i386, or later versions of binutils, these are skipped the same as the .so s. However as stated above I don't think relying on this linker behaviour is any real sort of solution - we should get libtool to either leave it up to the toolchain, or pass the correct explicit path. Here is the example unixodbc case that illustrates the problem: (Built with: xdeb -a armel --apt-source unixodbc, which runs: dpkg-buildpackage -rfakeroot -d -us -uc -aarmel -b -tc ) make[4]: Entering directory /home/chroot-user/build/unixodbc-2.2.14p2/samples' test -z "/usr/lib" || mkdir -p -- "/home/chroot-user/build/unixodbc-2.2.14p2/debian/tmp/usr/lib" /bin/bash ../libtool --mode=install /usr/bin/install -c 'libboundparam.la' '/home/chroot-user/build/unixodbc-2.2.14p2/debian/tmp/usr/lib/libboundparam.la' libtool: install: warning: relinking libboundparam.la' libtool: install: (cd /home/chroot-user/build/unixodbc-2.2.14p2/samples; /bin/bash /home/chroot-user/build/unixodbc-2.2.14p2/libtool --tag CC --mode=relink arm-l$ libtool: relink: arm-linux-gnueabi-gcc -shared .libs/boundparam.o .libs/helper.o .libs/cboundtimestampparam.o -Wl,--whole-archive ../autotest/.libs/libgtrtstlc.$ /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/libc.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status libtool: install: error: relink libboundparam.la' with the above command before installing it make[4]: *** [install-libLTLIBRARIES] Error 1 I note that when doing this libtool --config shows that it does have an idea of where the right place is: maverick)wookey@kh:~/ubuntu/maverick/build/pcre3$ ./libtool --config | grep sys_lib sys_lib_search_path_spec="/usr/lib/gcc/arm-linux-gnueabi/4.4.5 /usr/arm-linux-gnueabi/lib" sys_lib_dlsearch_path_spec="/usr/arm-linux-gnueabi/lib /lib /usr/lib /usr/local/lib" I haven't worked out exactly when and where libtool applies those, but as it seems to get the compiling and linking part right they may be being used (or the compiler defaults are just working as they should). It's only the install/relink phase that is bust (so far as I can tell). pcre3 provides a simpler and quicker-to-build example of the same problem. Here are various previous postings on the subject: Simon Richter in march last year, to libtool list: http://lists.gnu.org/archive/html/libtool/2010-03/msg00013.html (no response) Loic Minier in October last year, to libtool list http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626 (response: yes that seems to be a bug, no time to fix now, does sysroot option fix it? 'Not for me' said lool) Philip Prindeville from astlinux, July 2010, to libtool list http://lists.gnu.org/archive/html/libtool/2010-07/msg00018.html (response: send us some reproducible examples, and 'heres a ptch for the sysroot-and-deleting-.la-files case') Martin Panter from Openembedded in December 2010, to libtool-patches-gnu http://osdir.com/ml/libtool-patches-gnu/2011-01/msg00025.html which includes a patch to fix it. (response: useful discussion of possible patches) Opinions on the best way to make libtool do the right thing both now and in the future are welcome. Ther are quite a few patches in the above threads providing different solutions, and I haven't yet determined which of them have been included where. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

13 years, 10 months

Proposal for a MIPI System Trace Module driver

by Philippe Langlais

Hi All, This proposal is a call for contribution for a STM driver and its possible usages in kernel tracing infrastructure. I'd like to know if another ARM SoC plan to use or already use STM or some similar hardware enabling the same kind of MIPI trace points. If yes, we can share our works. What's STM? Hardware overview: ------------------ This hardware collects and provides simple tracepoints, so a system processor (in our case the main ARM CPU, or some small CPUs and DSPs) can write some data, up to 8 bytes, into a register and out comes a log entry with a time stamp on one of 256 channels. Also hardware tracepoints are supported. This module external interface is a pad on the chip which complies to the MIPI System Trace Protocol v1.0, and the actual trace output can be read by an electronic probe, not by software so it cannot be intercepted by the CPU and reach Linux userspace. Bandwidth depends on number of lines & bus frequency (for example on ux500 SoC 4 lines at max 100MHz eg max 400Mbit/s shared between 7 cores). Transmit FIFO size: 256 samples up to 8 bytes. Software overview: ------------------ - Put this platform driver in drivers/misc kernel tree - API: Configuration functions (trace output clock frequency, trace mode) Enable/disable STM trace functions Alloc/free STM trace channel functions Set of low level atomic trace functions for 1, 2, 4 or 8 bytes with & w/o time stamp Higher level lockless trace function (alloc a channel, output the trace buffer with arbitrary length then free the channel) Expose a debugfs interface for example to read/reset overflow status File IO output console like interface (open, close, write) Implement mmap to expose all STM trace channels memory access to userspace IOCTLs interface for configuration, enable/disable STM, alloc/free STM channels ... - Write atomicity and write order on STM trace channels is ensured by the fact we allocate one channel by execution thread (no concurrent access) Possible usages: ---------------- - Provide multiple output consoles for traces - Use it in standard kernel tracing infrastucture, possibilities: - Insert STM trace calls before trace ring buffer write - Substitute time stamping & trace ring buffer by STM - Implement the same functionality than the Ftrace function tracer without lock problem & very low overhead (in 8bytes + auto time stamp on 32bits arch we can have the function entry & its caller like Ftrace do). Remark: Problem is around lock to extract trace in right order when tracepoints buffer size > 8bytes (real time disturbance when tracing), a prototype must be done to find a clever lock system (use multiple channels) - other ideas... Many experiments must be done to validate its usage in kernel tracing infrastructure (performance, trace overflow, real time behavior...) Regards, Philippe

13 years, 10 months

Re: [PATCH 2/3] xloader-panda / new patchset sent to x-loader list

by Andy Green

On 02/08/11 15:40, Somebody in the thread at some point said: > Andy Green wrote, on 02/08/2011 08:54 PM: > [..] >>> btw, could you fix the following checkpatch warnings as well: Hi - I just sent a 17-patch patchset to the x-loader list cleaning out all the checkpatch problems in OMAP4 and Panda specific .c files, as well as fixing the compiler warnings and enabling -Werror. The code is refactored and symbols added to remove the magic constant addresses. I also found what look like some small bugs in the original code and provide fixes. The original patches to fix the OTG power Panda issue are included uplevelled and modified according to yesterday's comments. I didn't see it on the x-loader list yet but that may be because I couldn't figure out how to join the x-loader google list with the linaro.org address and it's held in moderation. -Andy

13 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev