linaro-dev February 2011

linaro-dev@lists.linaro.org

120 participants
166 discussions

[PATCH] ARM: S5P: Fix length of memory resource definition for UART devices

by thomas.abraham＠linaro.org

From: Thomas Abraham <thomas.abraham(a)linaro.org> The length of memory resource definition for UART devices in all the s5p platforms is one byte more than the intended value. This patch fixes the UART memory resource definition for all s5p platforms. Signed-off-by: Thomas Abraham <thomas.abraham(a)linaro.org> --- arch/arm/mach-s5p6442/include/mach/map.h | 2 +- arch/arm/mach-s5p64x0/include/mach/map.h | 2 +- arch/arm/mach-s5pc100/include/mach/map.h | 2 +- arch/arm/mach-s5pv210/include/mach/map.h | 2 +- arch/arm/mach-s5pv310/include/mach/map.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-s5p6442/include/mach/map.h b/arch/arm/mach-s5p6442/include/mach/map.h index 203dd5a..59464f9 100644 --- a/arch/arm/mach-s5p6442/include/mach/map.h +++ b/arch/arm/mach-s5p6442/include/mach/map.h @@ -46,7 +46,7 @@ #define S5P_PA_UART0 (S5P6442_PA_UART + 0x0) #define S5P_PA_UART1 (S5P6442_PA_UART + 0x400) #define S5P_PA_UART2 (S5P6442_PA_UART + 0x800) -#define S5P_SZ_UART SZ_256 +#define S5P_SZ_UART (SZ_256 - 1) #define S5P6442_PA_IIC0 (0xEC100000) diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h b/arch/arm/mach-s5p64x0/include/mach/map.h index a9365e5..c32c117 100644 --- a/arch/arm/mach-s5p64x0/include/mach/map.h +++ b/arch/arm/mach-s5p64x0/include/mach/map.h @@ -51,7 +51,7 @@ #define S5P_PA_UART4 S5P6450_PA_UART(4) #define S5P_PA_UART5 S5P6450_PA_UART(5) -#define S5P_SZ_UART SZ_256 +#define S5P_SZ_UART (SZ_256 - 1) #define S5P6440_PA_IIC0 (0xEC104000) #define S5P6440_PA_IIC1 (0xEC20F000) diff --git a/arch/arm/mach-s5pc100/include/mach/map.h b/arch/arm/mach-s5pc100/include/mach/map.h index ccbe6b7..f999021 100644 --- a/arch/arm/mach-s5pc100/include/mach/map.h +++ b/arch/arm/mach-s5pc100/include/mach/map.h @@ -128,6 +128,6 @@ #define S5P_PA_UART2 S5P_PA_UART(2) #define S5P_PA_UART3 S5P_PA_UART(3) -#define S5P_SZ_UART SZ_256 +#define S5P_SZ_UART (SZ_256 - 1) #endif /* __ASM_ARCH_MAP_H */ diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-s5pv210/include/mach/map.h index 1dd5883..89b4f0b 100644 --- a/arch/arm/mach-s5pv210/include/mach/map.h +++ b/arch/arm/mach-s5pv210/include/mach/map.h @@ -130,6 +130,6 @@ #define S5P_PA_UART2 S5P_PA_UART(2) #define S5P_PA_UART3 S5P_PA_UART(3) -#define S5P_SZ_UART SZ_256 +#define S5P_SZ_UART (SZ_256 - 1) #endif /* __ASM_ARCH_MAP_H */ diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-s5pv310/include/mach/map.h index 901657f..5235024 100644 --- a/arch/arm/mach-s5pv310/include/mach/map.h +++ b/arch/arm/mach-s5pv310/include/mach/map.h @@ -139,6 +139,6 @@ #define S5P_PA_UART3 S5P_PA_UART(3) #define S5P_PA_UART4 S5P_PA_UART(4) -#define S5P_SZ_UART SZ_256 +#define S5P_SZ_UART (SZ_256 - 1) #endif /* __ASM_ARCH_MAP_H */ -- 1.6.6.rc2

14 years, 2 months

Minutes from the Infrastructure team meeting - 2011-02-08

by James Westby

Hi, You can read the full transcript on https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-02-08 === Attendees === * James Westby * Michael Hudson * Mattias Backman * Guilherme Salgado === Agenda === * Team status reports * Action items from last meeting. * status.linaro.org overview * AOB === Action Items === * James to talk with Michael about requirement driving not wanting to host artefacts on Hudson === Action Items from Previous Meeting === * None === Minutes === * Team status reports * James Westby * series support for status.linaro.org was rolled out, so we now have burndowns that end at the right date * more things keep being requested for the status.linaro.org project, and most are worthy, so it's hard to draw it to a close * Guilherme Salgado * linaro-image-tools 0.4.3 release didn't have any regressions and there isn't any high priority bugs left there (for now) * plan: finish writing implementation plan for PatchTracking and start hacking Patchwork to do what we want it to * Mattias Backman * Borrowing some dev hardware to work with * Got approval for Budapest travel * A lot of overhead to request holes in the firewall * Michael Hudson * still don't really know what variants of android we want to build * people confusing requirements and implementation and not being very clear about either * plan: to talk to people such as patryk about what variants to build (doing that now in fact) * Michael said that something James had passed on from asac was implementation, not requirements. James will look at it further with Michael. * Actions from last meeting: None * status.linaro.org overview: James gave an overview of the architecture of the status.linaro.org code, where to get it, and some of the implementation details. * AOB * It was agreed that the new format for the meetings should be trialled for longer. Thanks, James

14 years, 2 months

Lava: Scope

by Paul Miles

Greetings Linaro-dev, I have joined the mailing list today and as a newbie Codethink(er) I am looking at contributing around the Linaro Validation area, especially Lava. My background is as a programme manager, generally around embedded mobile and have just completed a significant webkit based development project. First up on Linaro I have been digesting blueprints to get a feel for the Lava project scope and produce a system use-case (or story) list. The blueprints are not really giving me a system level picture that pulls together all the threads at the moment. Once I get this I can then spot some gaps where we can add value. Typical questions I am trying to answer are: What Mechanism is used by the community member to trigger/request an evaluation run? What needs to be provided by the community member in the evaluation package? What is the minimum? What will be present on the boards? Will the test run content be configurable by the evaluation requester? To this end, is there a Lava system-level requirement/scope? I have come across Linaro burn-down graphs, so maybe there is a Scrum type requirements backlog I can pick up on. Regards, Paul paul.miles(a)codethink.co.uk

14 years, 2 months

[PATCH 1/3] xloader-panda-add-0map4-gpio-base.patch

by Andy Green

From: Andy Green <andy.green(a)linaro.org> Signed-off-by: Andy Green <andy(a)warmcat.com> --- include/asm/arch-omap4/cpu.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/asm/arch-omap4/cpu.h b/include/asm/arch-omap4/cpu.h index 4971ba4..b273356 100644 --- a/include/asm/arch-omap4/cpu.h +++ b/include/asm/arch-omap4/cpu.h @@ -442,6 +442,9 @@ #define I2C_BASE2 (OMAP44XX_L4_PER + 0x72000) #define I2C_BASE3 (OMAP44XX_L4_PER + 0x60000) +#define O4_GPIO_BASE 0x4a310000 +#define O4_GPIO_BASE2 0x48055000 + #ifdef CONFIG_LCD extern void lcd_disable(void); extern void lcd_panel_disable(void);

14 years, 2 months

Re: Re: v4l2 vs omx for camera

by SUBASH PATEL

14 years, 2 months

Re: v4l2 vs omx for camera

by SUBASH PATEL

Hi Sachin, I think when we speak of OMX, we are referring to the OMX-IL layer. This layer is supported as middleware component. I am putting down my experiences as below: - Generally Camera gives two streams. One is preview which can be YUV/RGB and another is capture (YUV/RGB/JPEG). Preview frame format must be in one of display systems supported(YUV/RGB) format. Else color conversion is required in the path. This adds overhead and latency. - If we have a camera sensor which is smart, i.e., it is capable of providing the processed image(RGB, YUV) frame rather than RAW pixel dump, and ARM is able to control the sensor interface, then V4L2 framework camera driver would work. User space wrapper/app would be invoking the V4L2 ioctl's to control the camera. - If we have a RAW sensor which produces, say Bayer pixel format, we will have to have an image pipe to process it before converting this to one of RGB/YUV formats. Image pipes involves conversions, resizing etc. It would be an overhead to do these stages in ARM, and some vendors have proprietary imaging processors for it. These processors may run a custom RTOS. They may have built a private IPC layer into linux kernel and proprietary OS. OMX layer works in such scenarios. A concept called distributed OMX works on RPC mechanism. OMX client calls will now land up on the image processor from ARM. Again some proprietary driver/s will be invoked from the remote OMX component which would do the image processing mentioned above. User space wrapper/app aka OMX client, is a set of OMX calls, which will get routed to proper OMX component through OMX core. This is similar to V4L2 client, but instead of controlling camera through IOCTL's, we use OMX specific functions Get/Set methods. From my view, the choice of choosing V4L2 or OMX is basically depending on the type of sensors and presence of dedicated hardware. If we already have a dedicated imaging processor, V4L2 can be absent, and we will have to leverage the OMX because of its capability. But if we are integrating a new sensor which has in-built accelerator, it makes sense to reduce the silicon area on SoC and use V4L2 instead. Regards, Subash -------Original Message-------- Sent: Sachin Gupta <sachin.gupta(a)linaro.org> Date: Tue, 8 Feb 2011 14:25:21 +0530 Subject: Re: v4l2 vs omx for camera Arnd, you are correct that omx and v4l2 sit at different levels one being userside API and other being kernel API.But from the point of view of integrating these API's in OS frameworks like gstreamer,Android camera service they are at the same level.I mean one will have to implement gstreamer source plugin based on either v4l2 or Omx.Also the way vendors(STE and TI) have gone about implementing OMX, they completely bypass v4l2 .The major reason being code sharing among different OS environments.The kernel side for OMX implementation just facilitates RPC between imaging coprocessor and ARM side.. Sachin On Tue, Feb 8, 2011 at 2:00 PM, Lee Jones <lee.jones(a)linaro.org> wrote: Bringing in my boys. Robert, Linus, what say you? On 07/02/11 12:33, Arnd Bergmann wrote: > On Monday 07 February 2011, Sachin Gupta wrote: >> In Multimedia WG we have been posed with a question regarding best way >> to expose low level API for camera.so this a questions mainly about pros and >> cons of v4l2 and omx over each other.So to involve a wider community to >> discuss this topic I am floating this mail on linaro-dev.Please share your >> view/experiences.Also please involve any body else in this mail who can >> provide valuable inputs on this. > I've had to look up with "omx" actually stands for [1][2], but from > an outsider view, they don't seem to be mutually exclusive or even > competing interfaces. v4l2 is the interface you use to get at camera > data, in whatever format the camera gives you. There are no alternatives > to that. OpenMax gives you a way to accelerate video codecs, which > is good, but this sits a layer higher up in the stack. Supporting omx > is probably a good idea, but would be totally optional. > > Arnd > > [1] http://www.khronos.org/openmax/ > [2] http://www.freedesktop.org/wiki/GstOpenMAX > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -------Original Message-------- Sent: Loïc Minier <loic.minier(a)linaro.org> Date: Tue, 8 Feb 2011 10:35:38 +0100 Subject: Re: Efikamx bootloader help hey adding my bits where I can On Tue, Feb 08, 2011, Eric Miao wrote: > 2. The three possible boot up methods: a) Internal SPI NOR flash, b) the > MicroSD card behind the battery and c) the normal SD card at the left > side, not really sure about the situation on Efika MX (smart top) as > I don't have one in my hands efikamx only has SD and internal flash; there might be other boot methods like serial or USB, but I don't think we need to care too much about these > 4. The boot sequence of the Internal SPI NOR flash, as it looks to me that > it's trying to find boot.scr from either the MicroSD or SD card on the > first partition? Also it would be helpful to document the envionment > variables of this specific u-boot. on my efikamx, this is the bootcmd it had when I received it and corresponding variables: bootcmd=run pata_boot pata_boot=run bootargs_base bootargs_pata bootargs_base=setenv bootargs noinitrd console=ttymxc0,115200 console=tty1 bootargs_pata=setenv bootargs ${bootargs} root=/dev/sda2 ${bootinfo};run boot_pata bootinfo=rw boot_pata=run base_cmds;ide reset;fatload ide 0:1 ${loadaddr} ${kernel}; bootm ${loadaddr} base_cmds=run base_cmd1;run base_cmd2;run base_cmd3;run base_cmd4;run base_cmd5;run base_cmd99 loadaddr=0x90007FC0 kernel=uImage base_cmd1=pmic 15 0x00400022;mw.l 0x73fa84b8 0xe7 1;mw.l 0x73fd4014 0x59239100 1 base_cmd2=mw.l 0x83fd9010 0xcaaaf6d0 1;mw.l 0x73f88000 0x01025200 1;mw.l 0x73f84000 0x20 1 base_cmd3=mw.l 0x83fd9004 0x333574aa 1;mw.l 0x83fd900c 0x333574aa 1; base_cmd4=mw.l 0x83fd9020 0x00f48b00 1;mw.l 0x83fd9024 0x00f49700 1;mw.l 0x83fd9028 0x00f48700 1 base_cmd5=mw.l 0x83fd902c 0x00f48400 1;mw.l 0x83fd9030 0x00f44e00 1; > 5. If Linaro is going to support u-boot for Efika MX/SB, it's better to > follow what is in upstream. However, there could be some differences > between the u-boot in the recovery/installing image downloadable from > powerdeveloper.org and the one in upstream. We might need to figure > out those differences and see how to handle them. That was indeed the case; Marex, who developed the upstream u-boot bits, told me the same u-boot would work on SD and on flash; the one I've built from mainline uses the default imximage.cfg settings which is "BOOT_FROM spi", yet works fine from a SD card. So it seems the same u-boot can be used for both SD and flash -- just with different bootcmd. Cheers, -- Loïc Minier

14 years, 2 months

Device Tree on ARM status report

by Grant Likely

Hi all, With several more engineers working on ARM device tree support, I'm going to start collecting the status of all the work that is going on (and I know about) and posting it in a regular status report, hopefully weekly, for the next few months until the all of the major features are implemented and working on several arm platforms. I'll try to use roughly the following format: 1) latest news and status updates 2) list of tasks with current state and who is responsible for them in the same format as Launchpad blueprint whiteboards[1]. (In fact, I'll probably move much, if not all, of this into Launchpad anyway, in which case these emails will be a summary of all the blueprints. not all of us work with Linaro, but it is a useful method for tracking progress). 3) List of active engineers [1] https://wiki.linaro.org/Process/Blueprints Please read through and reply with comments/corrections. Feel free to add or remove tasks from the list I've given below. Thanks, g. 1 - Latest news --------------- - 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. - I've 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. - hopefully the basic dt support can be merged into Nicolas' tree this week if I get a cleaned up branch pushed out for him quickly. 2 - Task status --------------- Core infrastructure: [glikely] basic infrastructure to enable dt: DONE [r-herring] Allow dtb to be located anywhere in RAM: DONE [bones] Debug dtb corruption during init: INPROGRESS [glikely] OF clock bindings: INPROGRESS [glikely] Correctly handle dtb reserved memory sections: TODO [glikely] merge basic dt support into nico's tree: TODO [buytenh] virtual irq infrastructure: INPROGRESS Remove u-boot restriction of first 16k for dtb: TODO add processing of dtb reserved regions: TODO verify dt gpio infrastructure works: TODO [glikely] Remove early validation of machine type number: INPROGRESS imx51 tasks enable dtb support in u-boot: TODO enable basic kernel dtb support: TODO enable registration of devices form dt: TODO ... add more details here, specific devices, etc... OMAP tasks [buytenh] enable dtb support in u-boot: DONE [buytenh] enable basic kernel dtb support on OMAP3: INPROGRESS enable basic kernel dtb support on OMAP4: TODO [buytenh] enable registration of devices form dt: TODO ... add more details here, specific devices, etc... qemu support tasks: Cleanup and mainline arm dtb support patches: TODO configure qemu emulation from dtb (like microblaze): TODO ... add more details here, specific devices, etc... Samsung S5PV310 tasks: [thomas-ab] enable dtb support in u-boot: DONE? [thomas-ab] enable basic kernel dtb support on S5PV310: DONE? [thomas-ab] make gpio driver dt-aware: TODO [thomas-ab] Register devices from dt: INPROGRESS ... add more details here, specific devices, etc... Tegra tasks: [glikely] enable dtb support in u-boot: DONE [glikely] enable basic kernel dtb support on Harmony board: DONE [glikely] probe irq controllers from device tree: TODO [glikely] make gpio controller driver dt aware: TODO [glikely] register devices from dt: INPROGRESS ... add more details here, specific devices, etc... Versatile tasks: enable dtb support in u-boot: TODO [jk-ozlabs] enable basic kernel dtb support on versatile: DONE [jk-ozlabs] probe clocks from dt: DONE [jk-ozlabs] register devices from dt: DONE decode irqs from dt: TODO Versatile express tasks: [lorenzo-pieralisi] enable dtb support in u-boot: DONE? [lorenzo-pieralisi] enable basic kernel dtb support on versatile express: DONE [lorenzo-pieralisi] probe clocks from dt: DONE? [lorenzo-pieralisi] probe irq controllers from device tree: TODO [lorenzo-pieralisi] register devices from dt: DONE? ... add more details here, specific devices, etc... Xilinx arm tasks: [john linn] enable dtb support in u-boot: TODO? [john linn] enable basic kernel dtb support on xilinx arm devboard: DONE [john linn] probe irq controllers from device tree: TODO [john linn] register devices from dt: INPROGRESS? ... add more details here, specific devices, etc... A15 tasks: nothing yet As far as I know, Rob's dtb anywhere patch is pending mainline, but I'll carry it in devicetree/arm until it is merged. Same for the patch that eliminates early vetting of the machine type number. Active engineering list: Thomas Abraham [thomas-ab] Samsung Lennert Buytenhek [no launchpad id] core infrastructure and OMAP Andy Green [] OMAP Shawn Guo [] imx51 Rob Herring [r-herring] clock bindings, boot code Jason Hui [] imx51 Jeremy Kerr [jk-ozlabs] clock bindings, imx51, versatile John Linn [no launchpad id] Xilinx ARM dev board Grant Likely [glikely] core infrastructure, tegra, versatile Lorenzo Pieralisi [lorenzo-pieralisi] versatile express

14 years, 2 months

Talk: Embedded GPUs at LCA

by Christian Robottom Reis

Hi there, I did a talk at LCA yesterday evening that covered Embedded GPUs and Open Source (or the lack thereof); slides are available here: https://wiki.linaro.org/ChristianReis and a video recording may be available as well later; I'll tack it into the thread if I get a URL for it. I'm happy to answer questions about the presentations or to talk about the problems and possible solutions. One interesting outcome was the idea of a one-day cross-vendor summit that we could tack onto an existing open source event; Plumbers would be an interesting event for that and if enough people are interested I'd be willing to put effort into helping make that happen. Thanks to Jesse and Paul for the help they put into preparing for the presentation. Your comments welcome, -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

14 years, 2 months

Re: problem with linaro-media-create

by Guilherme Salgado

On Mon, 2011-02-07 at 16:55 +0000, David Gilbert wrote: > On 7 February 2011 16:50, Guilherme Salgado > <guilherme.salgado(a)linaro.org> wrote: > > In lmc we already have some code which checks if a given utility is > > present and if not, install (via apt-get) a package which provides that. > > We could extend it to check for a specific version and try to install a > > version greater or equal that (can we tell apt-get to install only if it > > finds a package whose version is greater than X?). > > > > When it fails to install, we would direct the user to the README, which > > has pointers for the things that are not available in the usual > > channels. > > Be careful about forcing the use of apt to install a newer package than is > available in the distro; please check whether there is a working qemu first in > case the user has got one from another source. > Currently the easiest way on Lucid of getting lmc > to work is to copy a qemu-arm-static binary from a natty install; not a pretty > solution but it works. Ok, so ISTM that to keep this solution working we'll need to do something like running qemu-arm-static with no arguments and parse its output for the version string. Unless there's another way to easily trigger the bug without running something inside the chroot (I don't want to wait until we have the chroot ready to find out that the existing qemu-arm-static doesn't work). -- Guilherme Salgado <https://launchpad.net/~salgado>

14 years, 2 months

[PM] cpufreq test

by Vincent Guittot

Hi vishwa, I have passed cpufreq-bench on my platform. The results below have been reached with a sampling rate of 20ms and a sampling_down factor set to 10. I have a question about the sampling_down feature : The ondemand delay value is calculated before calling dbs_check_cpu, but dbs_check_cpu can modify rate_mult. This implies that if the rate_mult is set to 1 in dbs_check_cpu because we set something else than the max frequency, the next sampling period will be sampling_rate*sampling_down_factor (the one used for max freq) but the frequency can be the lowest one. We should rather calculate the delay after dbs_check_cpu or i miss something ? Vincent Test results with current implementation, 20ms sampling rate, sampling_down = 10: _round 1: 59.14% _round 2: 56.87% _round 3: 77.31% _round 4: 88.44% _round 5: 89.56% _round 6: 83.17% _round 7: 89.87% _round 8: 94.33% _round 9: 92.98% _round 10: 91.12% Test results when the delay is calculated after dbs_check_cpu, 20ms sampling rate, sampling_down = 10 : _round 1: 86.75% _round 2: 91.18% _round 3: 93.23% _round 4: 96.70% _round 5: 95.87% _round 6: 96.04% _round 7: 97.39% _round 8: 97.37% _round 9: 98.88% _round 10: 97.78%

14 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2011