Re: CALL FOR TESTING: proposed enhancements for OMAP4
Is the plan to include the "testing" branch for this cycle? On Wed, Apr 20, 2011 at 11:58 AM, Nicolas Pitre wrote: > Andy Green has worked on a set of patches adding many features to OMAP4 > such as HDMI audio/video, FM receiver, etc. Before I merge that into > the Linaro kernel tree I need some assurance that this won't break > existing OMAP3 support, especially video. The branch is available in > the linux-linaro-2.6.38 Git repository on git.linaro.org, in the > "testing" branch. > > So please if you have an OMAP3 board and can perform some testing that > would be appreciated. > > > Nicolas > > ___ > linaro-kernel mailing list > linaro-ker...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Panda boards and 1GB of RAM.
Hi, https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227 seems to suggest we can now use 1GB of RAM on a Panda board. Creating a new image using the following images and hwpacks for my Panda : BOARD=panda linaro-media-create --rootfs ext4 --mmc /dev/mmcblk1 --binary linaro-n-developer-tar-20110426-0.tar.gz --hwpack hwpack_linaro-panda_20110426-0_armel_supported.tar.gz --dev panda I see that : root@linaro:~# uname -a Linux liliput-panda 2.6.38-1002-linaro-omap #3-Ubuntu SMP Fri Apr 15 14:00:54 UTC 2011 armv7l armv7l armv7l GNU/Linux root@linaro:~# free -m total used free sharedbuffers cached Mem: 662538123 0 14494 -/+ buffers/cache: 30631 Swap:0 0 0 Is there something else that I'm missing here ? cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH android/device/linaro/pandaboard] vold.fstab: Change the sys path for mmc device
After kernel bumped to 2.6.38.3, mmc sys path changed Signed-off-by: Jeremy Chang --- vold.fstab |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/vold.fstab b/vold.fstab index 04b9690..10fe0c4 100644 --- a/vold.fstab +++ b/vold.fstab @@ -12,4 +12,4 @@ ## - List of sysfs paths to source devices ## -dev_mount sdcard /mnt/sdcard 6 /devices/platform/mmci-omap-hs.0/mmc_host/mmc0 +dev_mount sdcard /mnt/sdcard 6 /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0 -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH android/device/linaro/beagleboard] vold.fstab: Change the sys path for mmc device
After kernel bumped to 2.6.38.3, mmc sys path changed Signed-off-by: Jeremy Chang --- vold.fstab |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/vold.fstab b/vold.fstab index 04b9690..10fe0c4 100644 --- a/vold.fstab +++ b/vold.fstab @@ -12,4 +12,4 @@ ## - List of sysfs paths to source devices ## -dev_mount sdcard /mnt/sdcard 6 /devices/platform/mmci-omap-hs.0/mmc_host/mmc0 +dev_mount sdcard /mnt/sdcard 6 /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0 -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CALL FOR TESTING: proposed enhancements for OMAP4
On Wed, 27 Apr 2011, John Rigby wrote: > Is the plan to include the "testing" branch for this cycle? I'd like to have confirmation that it doesn't break OMAP3 first. The OMAP4 support in that branch comes from sources that have expressed in the past that OMAP3 could be broken as a result. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PM] 27/04/2011 - Minutes for the Power Management WG weekly call
Hi All, The minutes of the power management weekly call can be found at : https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-04-27 Highlights: 11.11 planning Regards, Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[NOTES] Minutes & Actions: Kernel Working Group meetings of April 25, 2011
Enclosed you'll find a link to the agenda, minutes, actions and IRC logs from the Linaro kernel working group weekly meetings of April 25, 2011. https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-04-25 == Summary == * Introduce Deepak Saxena (AKA dsaxena1), who will be taking over the Kernel WG lead starting on May 1st. * Cycle 11.11 planning - See https://wiki.linaro.org/Cycles//TechnicalTopics/Kernel for technical requirements description * K9 One UDS Session for Improve Linux Kernel RAS * K8 One UDS session for Improve Linux Kernel General Performance * K7 One UDS session for Improve Linux Storage performance * K6 One UDS session for monthly releases to be combined with validation discussion - Nico & Paul Larson * K5 One UDS session Standard Architecture and H/W support - Nico, Dave, Tixy * K4 Android - John * K3 boot architecture Grant already registered a session * K2 Grant is covering the sessions * K1 One UDS session for planning * K1.1 5 daily sessions for ARM / Linux interface 1.5-3 hours each (as a mini-summit) * Paul to cover for John at UDS Regards, Mounir ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: devicetree: Tegra I2C muxing, and of_i2c_register_devices
[cc'ing devicetree-discuss, and also John Bonesio who is working on
Tegra device tree support]
On Tue, Apr 26, 2011 at 5:13 PM, Stephen Warren wrote:
> Tegra's I2C driver has a unique feature built in (although not mainlined
> yet); it can multiplex the I2C bus onto different sets of pins using the
> Tegra pinmux module, and hence can register more than 1 I2C bus with the
> I2C core for each controller. The exact number of busses registers, and
> the pinmux settings to be used, are provided by platform data. See:
>
> http://git.chromium.org/git/kernel-next.git chromeos-2.6.38
> include/linux/i2c-tegra.h
> arch/arm/mach-tegra/board-seaboard.c
>
> If I understand the direction of devicetree on ARM, there should be a
> single devicetree node for the Tegra I2C controller, which will get
> matched up with a static platform device registration in e.g.
> mach-tegra/board-dt.c
>
> I can easily see how to provide the appropriate platform data to the
> Tegra I2C driver, by definining the appropriate fields in a custom
> devicetree binding.
>
> To cater for the multiple child busses, the simplest solution seems to
> be to define each child node's reg property to be a tuple, i2c_address> (c.f. existing ). E.g.:
>
> IIC0: i2c@ {
> compatible = "nvidia,tegra250-iic";
> #address-cells = <2>;
> #size-cells = <0>;
> bus_muxes = ;
> rtc@68 {
> compatible = "stm,m41t80";
> reg = <0 0x68>;
> };
> sttm@48 {
> compatible = "ad,ad7414";
> reg = <1 0x48>;
> };
> };
>
> The problem is then that of_i2c_register_devices won't work well for the
> Tegra I2C controller, since it enforces that each child node's reg
> property be a single value, the I2C address.
>
> To solve this, should we:
>
> a) Have each mux'd bus have a separate devicetree node underneath the
> main I2C device, e.g.:
Yes, this is exactly what you should do.
> IIC0: i2c@ {
> compatible = "nvidia,tegra250-iic";
> // @0 doesn't really end up matching a
> // reg property within the child though
> bus@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> pinmux_group = ;
> pinmux_value = ;
>
> rtc@68 {
> compatible = "stm,m41t80";
> reg = <0x68>;
> };
> }
>
> bus@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> pinmux_group = ;
> pinmux_value = ;
>
> sttm@48 {
> compatible = "ad,ad7414";
> reg = <0x48>;
> };
> }
> };
>
> Then, the bus@0 or bus@1 nodes could be placed into adap->dev.of_node,
> since the devices are hung off there.
Right.
>
> b)
>
> Implement custom devicetree child enumeration code in the Tegra I2C
> driver to replace of_i2c_register_devices, which implements the
> two-entry reg format. The first devicetree example in this email could
> then be used.
Blech!!! :-)
>
> c)
>
> Perhaps remove the bus mux functionality from the Tegra I2C driver, and
> implement a separate I2C mux driver for it.
This would also be useful. There are other systems that I think would
find this to be a useful feature. The device tree layout would look
much the same as for option a), but the support code would become more
generic. I've been thinking about trying to implement both i2c and
spi 'gateway' or 'bridge' drivers for a while now, so I think this is
worth exploring.
>
> I'm not sure if devicetree has a defined representation for I2C bus
> muxes, and even if it does, since the mux control isn't accessed by I2C
> registers (as most standalone I2C bus muxes are), but rather Tegra-
> specific pinmux API calls, I'm not quite sure how to represent it in
> device-tree.
There isn't an existing binding, but it will be pretty easy to key the
required behaviour off a new compatible value for the specific i2c
mux. You just need a node for the i2c mux, and another node for each
child bus. Alternately, the mux could do what you suggest for option
b which might end up being cleaner. *HOWEVER* it is only cleaner if
the common i2c bus population code is modified to support it instead
of creating something custom.
g.
>
> Thanks for any thoughts!
>
> --
> nvpublic
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda boards and 1GB of RAM.
On Wed, Apr 27, 2011 at 02:28:35PM +0100, Ramana Radhakrishnan wrote: > https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227 > seems to suggest we can now use 1GB of RAM on a Panda board. > Creating a new image using the following images and hwpacks for my Panda : > BOARD=panda linaro-media-create --rootfs ext4 --mmc /dev/mmcblk1 > --binary linaro-n-developer-tar-20110426-0.tar.gz --hwpack > hwpack_linaro-panda_20110426-0_armel_supported.tar.gz --dev panda > I see that : > root@linaro:~# uname -a > Linux liliput-panda 2.6.38-1002-linaro-omap #3-Ubuntu SMP Fri Apr 15 > 14:00:54 UTC 2011 armv7l armv7l armv7l GNU/Linux > root@linaro:~# free -m > total used free sharedbuffers cached > Mem: 662538123 0 14494 > -/+ buffers/cache: 30631 > Swap:0 0 0 > Is there something else that I'm missing here ? https://bugs.launchpad.net/linaro-image-tools/+bug/707047 This bug has been marked "fix released" for linaro-image-tools, but there has not been an update of linaro-image-tools in Ubuntu natty since February. If you use linaro-media-create from the bzr branch when writing to the SD card, you should see more memory available. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[NOTES] 4/27 Linaro Developer Platforms Weekly Status Meeting
Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on April 27th in #linaro-meeting on irc.freenode.net at 15:00 UTC. https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-04-27 Action carried over was: * hrw to write improved test cases for QA tracker, to cover https://wiki.linaro.org/Platform/Ubuntu/EvaluationBuild/MemberDeliverables New Actions: * tgall_foo to seed a wiki page to discuss how to approach TR P1 (LEB as base for product builders) 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda boards and 1GB of RAM.
https://bugs.launchpad.net/linaro-image-tools/+bug/707047 This bug has been marked "fix released" for linaro-image-tools, but there has not been an update of linaro-image-tools in Ubuntu natty since February. If you use linaro-media-create from the bzr branch when writing to the SD card, you should see more memory available. I am using linaro-media-create from the PPA - given that my host is a Maverick system and this was updated to this mornings version which appears to be 0.4.4 Please note that the cmdline I have at the minute has the following line : mem=456M@0x8000 mem=512M@0xA000 Thus I would expect there to be atleast 968M of RAM rather than just 662M ! cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: devicetree: Tegra I2C muxing, and of_i2c_register_devices
On 4/27/2011 6:05 AM, Grant Likely wrote:
[cc'ing devicetree-discuss, and also John Bonesio who is working on
Tegra device tree support]
On Tue, Apr 26, 2011 at 5:13 PM, Stephen Warren wrote:
Tegra's I2C driver has a unique feature built in (although not mainlined
yet); it can multiplex the I2C bus onto different sets of pins using the
Tegra pinmux module, and hence can register more than 1 I2C bus with the
I2C core for each controller. The exact number of busses registers, and
the pinmux settings to be used, are provided by platform data. See:
http://git.chromium.org/git/kernel-next.git chromeos-2.6.38
include/linux/i2c-tegra.h
arch/arm/mach-tegra/board-seaboard.c
If I understand the direction of devicetree on ARM, there should be a
single devicetree node for the Tegra I2C controller, which will get
matched up with a static platform device registration in e.g.
mach-tegra/board-dt.c
I can easily see how to provide the appropriate platform data to the
Tegra I2C driver, by definining the appropriate fields in a custom
devicetree binding.
To cater for the multiple child busses, the simplest solution seems to
be to define each child node's reg property to be a tuple, (c.f. existing). E.g.:
IIC0: i2c@ {
compatible = "nvidia,tegra250-iic";
#address-cells =<2>;
#size-cells =<0>;
bus_muxes =;
rtc@68 {
compatible = "stm,m41t80";
reg =<0 0x68>;
};
sttm@48 {
compatible = "ad,ad7414";
reg =<1 0x48>;
};
};
The problem is then that of_i2c_register_devices won't work well for the
Tegra I2C controller, since it enforces that each child node's reg
property be a single value, the I2C address.
To solve this, should we:
a) Have each mux'd bus have a separate devicetree node underneath the
main I2C device, e.g.:
Yes, this is exactly what you should do.
IIC0: i2c@ {
compatible = "nvidia,tegra250-iic";
// @0 doesn't really end up matching a
// reg property within the child though
bus@0 {
#address-cells =<1>;
#size-cells =<0>;
pinmux_group =;
pinmux_value =;
rtc@68 {
compatible = "stm,m41t80";
reg =<0x68>;
};
}
bus@1 {
#address-cells =<1>;
#size-cells =<0>;
pinmux_group =;
pinmux_value =;
sttm@48 {
compatible = "ad,ad7414";
reg =<0x48>;
};
}
};
The right way to name this is:
i2cmux@ {
i2c@0 {
rtc@68 {
}
}
i2c@1 {
sttm@48 {
}
}
}
The reason is because the rtc and sttm devices are i2c devices so their
parents should be i2c buses. Those intermediate "bus" things are in
fact actual i2c buses as far as the children are concerned.
In a full OFW implementation, it would have to be set up that way so
that the children would see the correct set of support methods in their
direct parent, regardless of whether they were attached to simple
one-bus controllers or to a muxing controller.
As further evidence for the correctness of this approach, the existence
of the "pinmux_group" properties in the intermediate nodes make it clear
that the toplevel parent (tegra250-iic) is not exactly an iic bus
device, but rather something special that needs such properties.
The same sort of situation existed for PCI IDE controllers, which had
primary and secondary IDE strings, each of which could have master and
slave IDE devices. The best hierarchy turned out to be:
pci-ide@ {
ide@0 { // Primary string
disk@0 { // Master
}
disk@1 { // Slave
}
}
ide@ {// Secondary string
disk@0 { // Master
}
disk@1 { // Slave
}
}
}
Then, the bus@0 or bus@1 nodes could be placed into adap->dev.of_node,
since the devices are hung off there.
Right.
b)
Implement custom devicetree child enumeration code in the Tegra I2C
driver to replace of_i2c_register_devices, which implements the
two-entry reg format. The first devicetree example in this email could
then be used.
Blech!!! :-)
c)
Perhaps remove the bus mux functionality from the Tegra I2C driver, and
implement a separate I2C mux driver for it.
This would also be useful. There are other systems that I think would
find this to be a useful feature. The device tree layout would look
much the same as for option a), but the support code would become more
generic. I've been thinking about trying to implement both i2c and
spi 'gateway' or 'bridge' drivers for a while now, so I think this is
worth exploring.
I'm not sure if devicetree has a defined representation for I2C bus
muxes, and even if it does, since the mux cont
Re: [PATCH v2 01/12] mmc: add none blocking mmc request function
On 20/04/11 08:17, Per Forlin wrote: > >> Using a MMC request queue has other benefits -- it allows multiple users >> without having to claim/release the host. This would be useful for >> (especially multi-function) SDIO. > > You mean claim and release would be done only within the mmc core. The > timed saved here would equal the time it takes to release and claim > the host. > Claim and release can also be used for power management to indicate if > any client is using the host, if not the power can be switched off. Isn't there a separate runtime power management API that different from claim/release? > I just want to make sure I understand the multi-function SDIO case, I > haven't done any work with SDIO. > Can the SDIO functions compete over the same claim_host at the same time? > Example: if function 1 claims the host, function 2 and function 3 also > want to claim the host but have to wait for function 1 to release the > host. This is the case. Each function driver has to claim exclusive access to the host. > What is the extra benefit of having the internal request queue for > multi function SDIO? It reduces the delays between commands if multiple drivers are sending commands. I estimated performance improvements with 2-3% from just removing the need to claim/release in one particular SDIO function driver. Performance improvements for multi-function cards would be a bit more (5% perhaps?). The more important benefit is the simplification of the API. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CALL FOR TESTING: proposed enhancements for OMAP4
On 04/22/2011 02:50 PM, Somebody in the thread at some point said: Hi - Still, the fact is before you can just copy a whole config from arch/arm/configs to be .config and vice-versa which has been my usage pattern. Now with these optimized defconfigs, that doesn't work; it doesn't hurt to document how to use the new way (even better with your make target method). Sure. And you can still copy arch/arm/configs/foo_defconfig to .config and it should work (maybe a "make oldconfig" needed not to be prompted My build scripts among other things do a silentoldconfig every time before the main build, that is not enough anyway to use it directly. Otherwise I wouldn't've noticed there was any issue. for all missing options). But "make foo_defconfig" is shorter. It's possible I'm the only guy who missed the day at school where they talked about arbitrary defconfig targets in Makefile but I doubt it. Well, most people are not aware of those goodies, so don't feel ashamed. I'm sure you weren't alone at the beach that day. ;-) Sure, I appreciate your telling me and everyone else on the lists that it existed. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Toolchain performance 2011-04-26 minutes
Hi there. Minutes from this weeks toolchain performance call are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-26 These meetings discuss current and future work on improving the performance of GCC. Future minutes will be added to the toolchain meetings page at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings and announced on the linaro-toolch...@lists.linaro.org list. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Image Tools 0.4.5 released
On behalf of the Linaro Infrastructure team I'm pleased to announce the release of Linaro Image Tools 0.4.5. Linaro Image Tools offer a set of tools for use with Linaro images. This release features installing Linaro Android images. These images can be found on https://android-build.linaro.org/ Please note that Android image support still is considered experimental, meaning that the command line interface is subject to change. The source tarball is available from: https://launchpad.net/linaro-image-tools/trunk/0.4.5 Thanks, Mattias Backman ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
