Hi Ricardo,
With working HDMI output on the original panda board, and Wei's new
release of patches to alsa-lib and pulseaudio, I've updated both
alsa-lib and pulseaudio for 11.12 in ppa:linaro-maintainers/overlay.
Sound on the panda over HDMI from my testing works out of the box.
It's not perfect but it works. I will repeat this same test with my
imx53 shortly.
For all on the dev list, be aware that audio is in a state of flux and
while we'd like to avoid defects they are likely. The Multimedia WG is
putting substantial effort into having a "just works" level of quality
for supported boards.
A very bit thank you is in order for Wei Feng for his hard work on
11.12! Good job! One small sound for an ARM board, but a big noise for
Linaro when we can say, "It just works."
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | 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
Hi All:
Since Panda board is now officially supported by Google, I decided to do a quick testing between Linaro build (release 11.11 - v2.3.7), Linaro ICS preview (v4.0.1) and Google's ICS build for Panda-board (v4.0.1).
Here are what I found:
1. Google's ICS build detects the resolution to be 672(H)x1280(W) on my monitor while Linaro builds default to 480x640.
I manually changed the screen resolution in boot.scr to be omapfb.mode=dvi:1280x672MR-24@60. The linaro ICS preview can now come up with 672x1280 resolution, but I encountered graph driver crash in 11.11 release (v2.3.7).
The video output came out on HDMI port for 11.11 release instead of DVI port as in Linaro ICS previous & Google's ICS build.
This seems to tell me that there is a problem with graphic driver in 11.11 official release and EDID detection is not working for Linaro builds.
2. I ran Sunspider & 0xbench in Linaro ICS preview (in 480x640 resolution) & Google's ICS build for Panda-board (in 1280x672 resolution).
Linaro ICS preview has slightly better result in Sunspider testing, but falls significantly behind in 0xbench. Changing the resolution to 1280x672 on the Linaro ICS preview build shows noticeable lag in UI performance.
This seems to suggest that Linaro ICS preview doesn't enable GPU.
I simply followed the instructions in the release note to populate SD cards with proper images for testing.
Has anyone done similar testing? Is the above observation consistent with your result?
Thanks,
Alan Chuang
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi folks,
I went ahead and checked what is the status of the UMM effort as 2011 is
closing to an end. What follows is my attempt to summarise the status,
collating the pieces from the latest announcements and changelogs and
having discussed it briefly with Jesse and Rob. Feel free to comment if
there is something missing or not correct:
A. CMA - Contiguous memory allocator. This is in its v17 incarnation at
the moment (a v18 is in preparation but not released yet). v17 shares
the code with memory compaction subsystem, not the hotplug like it was
before (change has been suggested by Mel Gorman) and there are also a
few fixes here and there, like addressing most of the comments from
Andrew Morton and Mel Gorman in the rest of the CMA code, fixing broken
initialization on ARM systems with DMA zone enabled and rebasing the
code on v3.2-rc2 kernel.
An issue has been noted in linaro-dev from the TI landing team : without
any highmem the code is working great, but with HIGHMEM inclusion of
the CMA v17 consistently causes failure during DMA init. This is
expected to be fixed soon (perhaps in v18?). In meantime it is
suggested using 2G/2G memory split as a workaround (Kernel Features ->
Memory split -> 2G/2G user/kernel split).
B. dma mapping API - DMA-mapping framework redesign for ARM
architecture: this is in the v4 now. It includes a few minor changes
since last version. The changes are mainly on the IOMMU mapper, keeping
the DMA-mapping redesign patches almost unchanged. The code is rebased
onto v3.2-rc4 kernel + IOMMU/next branch to include latest changes from
IOMMU kernel tree. This series also contains support for mapping with
pages larger than 4KiB using new, extended IOMMU API, and did a general
cleanup of the DMA mapping implementation. However it seems that this
patchset "attempts to fix everyone at once". It has been suggested
that instead of trying to do that the implementation should give
sufficient transition period - for example just adding the new methods
now and only removing them in the following merge window when all the
architectures have had a chance to migrate.
C. dmabuf - a DMA-buf object sharing framework: this is now in its 3rd
version. The newest version incorporates changes as requested during the
review, such as - replacing BUG_ON with WARN_ON at various places,
removing mmap() fop and dma_buf_op, also the sg_sync* operations, and
documenting that mmap is not allowed for exported buffer, adding error
checks, replacing EXPORT_SYMBOL with EXPORT_SYMBOL_GPL and fixing some
cosmetic/documentation items. There are still some items under
discusion such as userspace mmap support, more advanced (and more
strictly specified) coherency models and shared infrastructure for
implementing exporters. However, there is a suggestion that these items
will become much clearer once we have a few example drivers at hand
and a better understanding of what cases need to be handled better.
D. Finally some repositories - where can you find the code to try it out:
* git://git.linaro.org/people/jessebarker/linaro-mm-sig/linux.git
contains (for the moment) 6 branches:
+ cma-v17 == unadulterated v3.2-rc4 + cma v17 patchset
+ dma-mapping-v4 == unadulterated v3.2-rc4 + dma-mapping v4 patchset
+ android-cma-v17 == john stultz's androidization tree based upon
unadulterated v3.2-rc4 + cma v17 patchset
+ android-dma-mapping-v4 == john stultz's androidization tree based
upon unadulterated v3.2-rc4 + dma-mapping v4 patchset
Also note these repos:
- https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
contains patches to enable sharing of buffers between drm and v4l2,
Rob commented that it isn't really identified yet which tree to push
dmabuf through.. airlied has volunteered to push via drm tree, which is ok
- git://git.linaro.org/people/bgaignard/linux-snowball-cma-test.git
contains a first version of the CMA testing scripts for LAVA (snowball
specific at least for now)
Best regards,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hello,
This should have gone more than a week ago, but was "lost" in
click-thru work. Anyway, we now finally have automatic syncing with
upstreams for our tree - that includes AOSP and other components we
mirror. It runs for more than 2 weeks now and works pretty well. For
AOSP, some components may be missing with upstream version upgrades,
then just please submit a ticket to have them picked up (manual op),
like this one:
https://bugs.launchpad.net/linaro-android-infrastructure/+bug/905664
to ensure timely processing.
Thanks, and Merry Christmas!
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi guys,
i tried cpuhotplug on pandaboard for both
Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
work stably.
On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
# echo 0 > /sys/devices/system/cpu/cpu1/online
CPU1: shutdown
if i enable the cpu1 again by "echo 1 >
/sys/devices/system/cpu/cpu1/online", the system will restore to 3
random status: hang, normal, panic.
Using Linaro 11.11 release, "echo 0 >
/sys/devices/system/cpu/cpu1/online" will make system hang and the
whole system will not be able to reset by pressing reset key, the only
way to reset system is pulling out AV power.
i am sorry i can't get more time to debug and find more clues. just
want to ask people whether this is a version the cpuhotplug works
normal on?
Thanks
barry
Hi,
I have one pandboard (4430), however, it's said the audio and
audiohw not supported in the Linaro android release 11.11 or 11.12,
so is there one way to add the support manually ? if yes, where to
begin ? I am also interested in enabling the video hw support for the
board, but no idea until now.
Thanks.
Yuping Luo
The driver support single core and multi core ARM SoCs. For multi core,
it assume all cores share the same clock and voltage.
TODO:
- Add each core seperate freq/volt support (MSM).
Changes in v3:
- move adjusting smp loops_per_jiffy to arm common code,
and also adjust global loops_per_jiffy.
- remove adjusting loops_per_jiffy in imx and omap cpufreq drivers.
- check compatible "generic-cpufreq" when module_init
- change printk to pr_xxx
- add generic-cpufreq DT binding doc
Changes in v2:
- add volatage change support
- change '_' in property name to '-'
- use initial value to calculate loops_per_jiffy
- fix reading cpu_volts property bug
- let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min
- don't change freq in arm_cpufreq_exit, because every core share the same freq.
- use unsigned long describe frequency as much as possible. Because clk use
unsigned long, but cpufreq use unsigned int.
[PATCH V3 1/7] ARM: add cpufreq transiton notifier to adjust
[PATCH V3 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate
[PATCH V3 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for
[PATCH V3 4/7] cpufreq: add generic cpufreq driver
[PATCH V3 5/7] dts/imx6q: add cpufreq property
[PATCH V3 6/7] arm/imx6q: register arm_clk as cpu to clkdev
[PATCH V3 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ
The patch d795e2c "Adding omap_gpu drm display driver" introduces
following compilation warning when the kernel is compiled for x86
architecture (i386_defconfig). Also the kernel compilation is
unsuccessful because of calls to omap specific platform header files.
warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which
has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
The problem is fixed by making DRM_OMAP depend on ARCH_OMAP2.
Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org>
---
drivers/gpu/drm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fdef87b..0949995 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -169,7 +169,7 @@ config DRM_SAVAGE
config DRM_OMAP
tristate "OMAP GPU (EXPERIMENTAL)"
- depends on DRM && !CONFIG_FB_OMAP2
+ depends on DRM && ARCH_OMAP2 && !CONFIG_FB_OMAP2
select DRM_KMS_HELPER
select OMAP2_VRAM
select OMAP2_DSS
--
1.7.1
