Re: Add packaging of .dtb files
On Thu, 2011-03-31 at 19:41 +0200, Loïc Minier wrote: [...] > However, it will likely be needed to copy this dtb in a place where > u-boot can read it, for instance in the boot partition probably as an > u-boot image: uDeviceTree just like uImage, uInitrd etc.; I don't care > too strongly about the name. I would suggest we don't use a 'u' prefix for the name of the device tree file as it doesn't have a U-Boot header, though its not really that important. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] net/fec: fix compile error introduced by dt support
On Thu, Mar 31, 2011 at 10:09:40AM -0600, Grant Likely wrote: > On Fri, Mar 25, 2011 at 03:13:58PM +0800, Shawn Guo wrote: > > After fec dt support is added, the following compile error will be > > seen when building a pure non-dt kernel. > > > > drivers/net/fec.c: In function ‘fec_probe’: > > drivers/net/fec.c:1383: error: implicit declaration of function > > ‘of_match_device’ > > drivers/net/fec.c:1383: warning: assignment makes pointer from integer > > without a cast > > Earlier today I suggested fixing this by adding an empty > implementation of of_match_device, but I forgot that an .of_match > pointer has been added to struct device for exactly this purpose. You > can use that instead. > > That change is currently in mainline, but it has not been backported > to the Linaro 2.6.38 tree (yet). > This simply is a fix to commit 54898b86fa9813313b3eb981c44610ff483b0067 "net/fec: add device tree matching support", which only sits on branch devicetree/test-2.6.38 right now. However, .of_match is not available on that tree yet. So I can not do anything until ether this patch shows on devicetree/test or .of_match is back ported on devicetree/test-2.6.38. Or you can simply ignore this patch since I just want let you know such a compile error. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Add packaging of .dtb files
On Thu, Mar 31, 2011 at 07:41:53PM +0200, Loïc Minier wrote: > On Fri, Apr 01, 2011, Shawn Guo wrote: > > As the .dtb files will be naturally generated in the same kernel > > folder as kernel image sits, why do not we ship .dtb in the same > > folder as kernel image /boot? > > You could say the same of kernel modules; problem is that there might Let me be more specific. We currently run 'make ARCH=arm mx51-babbage.dtb' to get mx51-babbage.dtb right in folder arch/arm/boot, which happens to where zImage sits. My point is since .dtb file is born in the same location as zImage and needs to be on boot partition just like zImage, we can get .dtb along with zImage during the packaging process. I do not think kernel modules are built out in where zImage sits and need to be on boot partition. > be many .dtbs and that would clutter /boot IMHO. So I think /lib is With folder /boot/dtbs? > more sensible, but I'm open to hear good arguments! > > > The .dtb files will be generated and shipped with unique name, which > > comes from .dts file name. But I intend to use the generic name, > > maybe something like board.dtb along with l-m-c, just like we use > > zImage and u-boot for all platforms in boot partition, so that l-m-c > > does not need to encode platform specific dtb filename. > > I don't think this would work in the upstream kernel or kernel We use platform specific filename anyway in kernel. > packaging: the same linux-image.deb will provide support for multiple > boards, for instance linux-image-mx51 supports for efikamx, efikasb, > mx51evk, so the package needs to ship three .dtb files. > Ah, I forgot this. Then we need to carry on platform specific filename in l-m-c till we copy them into boot partition, where should have only one dtb file, and generic filename should work. > However, it will likely be needed to copy this dtb in a place where > u-boot can read it, for instance in the boot partition probably as an > u-boot image: uDeviceTree just like uImage, uInitrd etc.; I don't care > too strongly about the name. > I will go 'board.dtb' if no one really cares :) -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
armhf progress: 2.6.38 kernel for the efikasb/mx, SD card bootable image
Hi all, I tried to upload the kernel debs to ftp.debian-ports.org, but I'm getting some upload errors, so I uploaded them to http://www.freevec.org/packages/ the armhf sd card image is finally uploaded here: http://www.freevec.org/packages/efikamx-armhf.img.xz it is very recent, includes pbuilder in case one wants to try building packages for armhf. But console only, though gnome/kde packages exist in the repo. Btw, there is no video display support for the smarttop yet, but ssh works. It includes PATA/fb/ethernet/wifi(untested). Default root password: efika, default hostname: efika-armhf Enjoy Konstantinos ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
IMPORTANT UPDATE: Details for Linaro Developer Summit in Budapest, 9-13 May
Hi All, A reminder that you need to book your hotel reservation by next Friday to guarantee getting a room. Also, make sure you register at the links below. Also, please check the Linaro@UDS website for additional details on getting involved, specifically: - We'll be organising a couple of sessions to explain how Linaro@UDSworks later this month: https://wiki.linaro.org/Events/2011-05-LDS#An%20Introduction%20to%20the%20Linaro@UDS%20Event. Contact matt.wadd...@linaro.org for more details - Please get involved in providing demos for the Linaro Showcase: https://wiki.linaro.org/Events/2011-05-LDS#Linaro%20Showcase%20Event%20on%2010%20May. Contact michael.opdenac...@linaro.org for more details Thx Stephen On 25 February 2011 14:59, Stephen Doel wrote: > Hi All, > > I want to bring to your attention some important logistic points around the > Developer Summit in Budapest from 9 - 13 May ( > https://wiki.linaro.org/Events/2011-05-LDS) > >1. Please register your attendance now: >https://forms.canonical.com/udsreg/ and here: >http://launchpad.net/sprints/uds-o. I'd like you to do this even if you >haven't yet booked your flights and so on, as we're using this attendee > list >to drive a lot of our planning for the week >2. You must make a room reservation at the hotel before* 8 April* to >benefit from our discounted rates, and to ensure you're staying where all >the action is happening ( >https://wiki.linaro.org/Events/2011-05-LDS#Hotel%20Booking) >3. Bookmark https://wiki.linaro.org/Events/2011-05-LDS and check it >regularly, as we will grow the amount of information there to explain > what's >happening and how to get the most out of the Summit as we get closer to May >(I'll also send periodic e-mails to update you all) > > -- > Thx > > Stephen Doel > Linaro Ltd > Chief Operating Officer > +44 77 66 014 247 > > -- Thx Stephen Doel Linaro Ltd Chief Operating Officer +44 77 66 014 247 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Add packaging of .dtb files
On Fri, Apr 01, 2011, Shawn Guo wrote: > With folder /boot/dtbs? I don't really like "dtbs" because it limits to storing exactly dtb files; if it's "device-tree" it's more generic and could be used for other things like dts if needed. I don't think it's impossible to put it in /boot; I'll let Grant argue for /boot versus /lib. I don't know how other platforms do this, but certainly there must be prior art on powerpc or other arches which we might build on? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH 1/2] ARMV7: Adding support for Samsung SMDKV310 Board
Dear Chander Kashyap,
On 31 March 2011 18:14, Chander Kashyap wrote:
> SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much
> similar to S5PC210.
>
> Signed-off-by: Chander Kashyap
> Signed-off-by: Tushar Behera
> ---
> board/samsung/smdkv310/Makefile | 46 +++
> board/samsung/smdkv310/config.mk | 1 +
> board/samsung/smdkv310/lowlevel_init.S | 549 +++
> board/samsung/smdkv310/mem_setup.S | 632
>
> board/samsung/smdkv310/smdkv310.c | 138 +++
> boards.cfg | 1 +
> include/configs/smdkv310.h | 199 ++
> 7 files changed, 1566 insertions(+), 0 deletions(-)
> create mode 100644 board/samsung/smdkv310/Makefile
> create mode 100644 board/samsung/smdkv310/config.mk
> create mode 100644 board/samsung/smdkv310/lowlevel_init.S
> create mode 100644 board/samsung/smdkv310/mem_setup.S
> create mode 100644 board/samsung/smdkv310/smdkv310.c
> create mode 100644 include/configs/smdkv310.h
You missing MAINTAINER entry.
> diff --git a/board/samsung/smdkv310/config.mk
> b/board/samsung/smdkv310/config.mk
> new file mode 100644
> index 000..19b9e2f
> --- /dev/null
> +++ b/board/samsung/smdkv310/config.mk
> @@ -0,0 +1 @@
> +CONFIG_SYS_TEXT_BASE = 0x43e0
Please remove this file.
And move this define to config file.
> diff --git a/board/samsung/smdkv310/lowlevel_init.S
> b/board/samsung/smdkv310/lowlevel_init.S
> new file mode 100644
> index 000..ead12b2
> --- /dev/null
> +++ b/board/samsung/smdkv310/lowlevel_init.S
> +#define MEM_DLLl_ON
> +
please remove this space.
> +
> +_TEXT_BASE:
> + .word CONFIG_SYS_TEXT_BASE
> +
> + .globl lowlevel_init
> +lowlevel_init:
> + push {lr}
ditto.
> +
> +
> + /* r5 has always zero */
> + mov r5, #0
> +
> + ldr r7, =S5PC210_GPIO_PART1_BASE
> + ldr r6, =S5PC210_GPIO_PART2_BASE
> +
> + /* check reset status */
> + ldr r0, =(S5PC210_POWER_BASE + 0x81C) @ INFORM7
> + ldr r1, [r0]
> +
> + /* AFTR wakeup reset */
> + ldr r2, =S5P_CHECK_DIDLE
> + cmp r1, r2
> + beq exit_wakeup
> +
> + /* Sleep wakeup reset */
> + ldr r2, =S5P_CHECK_SLEEP
> + cmp r1, r2
> + beq wakeup_reset
> +
> + /* when we already run in ram, we don't need to relocate U-Boot.
> + * and actually, memory controller must be configured before U-Boot
> + * is running in ram.
> + */
We don't allow this comment style.
Please check it.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle
> + ldr r0, =0x00ff /* r0 <- Mask Bits*/
> + bic r1, pc, r0 /* pc <- current addr of code */
> + /* r1 <- unmasked bits of pc */
> +
> + ldr r2, _TEXT_BASE /* r2 <- original base addr in ram */
> + bic r2, r2, r0 /* r2 <- unmasked bits of r2*/
> + cmp r1, r2 /* compare r1, r2 */
> + beq 1f /* r0 == r1 then skip sdram init */
> +
> + /* init system clock */
> + bl system_clock_init
> +
> + /* Memory initialize */
> + bl mem_ctrl_asm_init
Is it OK that memory initialize on u-boot?
Maybe only do on mmc spl?
> +
> +1:
> + /* for UART */
> + bl uart_asm_init
> + bl tzpc_init
> + pop {pc}
> +
> +wakeup_reset:
> + bl system_clock_init
> + bl mem_ctrl_asm_init
> + bl tzpc_init
> +
> +exit_wakeup:
> + /*Load return address and jump to kernel*/
> + ldr r0, =(S5PC210_POWER_BASE + 0x800) @ INFORM0
> +
> + /* r1 = physical address of s5pc210_cpu_resume function */
> + ldr r1, [r0]
> +
> + /* Jump to kernel*/
> + mov pc, r1
> + nop
> + nop
> +
> +/*
> + * system_clock_init: Initialize core clock and bus clock.
> + * void system_clock_init(void)
> + */
> +system_clock_init:
> + push {lr}
> + ldr r0, =S5PC210_CLOCK_BASE
> +
> + /* APLL(1), MPLL(1), CORE(0), HPM(0) */
> + ldr r1, =0x0101
> + ldr r2, =0x14200 @CLK_SRC_CPU
> + str r1, [r0, r2]
> +
> + /* wait ?us */
> + mov r1, #0x1
> +1: subs r1, r1, #1
> + bne 1b
> +
> + ldr r1, =0x0110
> + ldr r2, =0x0C210 @CLK_SRC_TOP0
> + str r1, [r0, r2]
> +
> + ldr r1, =0x00
> + ldr r2, =0x0C214 @CLK_SRC_TOP1_OFFSET
> + str r1, [r0, r2]
> +
> + /* DMC */
> + ldr r1, =0x00
> + ldr r2, =0x10200 @CLK_SRC_DMC_OFFSET
> + str r1, [r0, r2]
> +
> + /* SATA: SCLKMPLL(0), MMC[0:4]: SCLKMPLL(6) */
> +
> + ldr r1, =0x06
> +
Re: IMPORTANT UPDATE: Details for Linaro Developer Summit in Budapest, 9-13 May
On Fri, Apr 01, 2011, Stephen Doel wrote: >Contact matt.wadd...@linaro.org for more details matt.wad...@linaro.org -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Sound hardware device specifics for Linaro dev boards
Hi everyone, I am trying to assemble a reference for the sound device specifics for all the platforms. The catch is that I don't have all the dev platforms available to me. Here is where you can help! I have Panda and Beagle C4. I need everything else. If you have access to other platform(s), please do the following and email the output to me. With a Linaro image or Ubuntu image (an image with with pulseaudio installed), run the following: "pacmd list-sinks" and email it to me. You will get an output that resembles this: linaro@localhost:~$ pacmd list-sinks Welcome to PulseAudio! Use "help" for usage information. >>> 1 sink(s) available. * index: 0 name: driver: ... module-udev-detect.discovered = "1" device.icon_name = "audio-card" Thanks in advance! Kurt Taylor (irc krtaylor) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linus being annoyed by the ARM kernel code
Just FYI - lengthy but very interesting read, Linus was really good at wording, enjoy heh :-) https://lkml.org/lkml/2011/3/17/283 So maybe it's just a right time to talk about using linaro ARM kernel tree as a fork for quick merge of the ever expanding SoC and board support, and using it more as a productive kernel for downstream. And in the mean time, improve the mainline kernel into such a good shape that with less crappy code we could support more platforms? Just a bit thought on that possibility. - eric ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
Eric, yes, I found that interesting. I've been having discussions about how to do this better, I'm interested in your thoughts. Are you by any chance at ELC in SF? Dave On Fri, 2011-04-01 at 23:43 +0800, Eric Miao wrote: > Just FYI - lengthy but very interesting read, Linus was really good at > wording, enjoy heh :-) > > https://lkml.org/lkml/2011/3/17/283 > > So maybe it's just a right time to talk about using linaro ARM kernel > tree as a fork for quick merge of the ever expanding SoC and board > support, and using it more as a productive kernel for downstream. > And in the mean time, improve the mainline kernel into such a good > shape that with less crappy code we could support more platforms? > > Just a bit thought on that possibility. > > - eric > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Linus being annoyed by the ARM kernel code
Eric, >> So maybe it's just a right time to talk about using linaro ARM kernel >> tree as a fork for quick merge of the ever expanding SoC and board >> support, and using it more as a productive kernel for downstream. I don't think that a 'fork' is really a solution we are looking for. Using Linaro as a staging and consolidation tree and at the same time improving the upstream kernel is more what I would be looking for and what Linaro is currently working on. Regards, Philippe -Original Message- From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-boun...@lists.linaro.org] On Behalf Of Eric Miao Sent: 01 April 2011 16:44 To: Linaro Dev Subject: Linus being annoyed by the ARM kernel code Just FYI - lengthy but very interesting read, Linus was really good at wording, enjoy heh :-) https://lkml.org/lkml/2011/3/17/283 So maybe it's just a right time to talk about using linaro ARM kernel tree as a fork for quick merge of the ever expanding SoC and board support, and using it more as a productive kernel for downstream. And in the mean time, improve the mainline kernel into such a good shape that with less crappy code we could support more platforms? Just a bit thought on that possibility. - eric ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
On Fri, Apr 1, 2011 at 11:55 PM, David Rusling wrote: > Eric, > yes, I found that interesting. I've been having discussions about how > to do this better, I'm interested in your thoughts. Are you by any > chance at ELC in SF? Actually a bit busy with the involvement with Freescale, so I won't go this time. > > Dave > > On Fri, 2011-04-01 at 23:43 +0800, Eric Miao wrote: >> Just FYI - lengthy but very interesting read, Linus was really good at >> wording, enjoy heh :-) >> >> https://lkml.org/lkml/2011/3/17/283 >> >> So maybe it's just a right time to talk about using linaro ARM kernel >> tree as a fork for quick merge of the ever expanding SoC and board >> support, and using it more as a productive kernel for downstream. >> And in the mean time, improve the mainline kernel into such a good >> shape that with less crappy code we could support more platforms? >> >> Just a bit thought on that possibility. >> >> - eric >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > -- > David Rusling, CTO > http://www.linaro.org > > Linaro > Lockton House > Clarendon Rd > Cambridge > CB2 8FH > > > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
On Fri, Apr 1, 2011 at 11:57 PM, Philippe Robin wrote: > Eric, > >>> So maybe it's just a right time to talk about using linaro ARM kernel >>> tree as a fork for quick merge of the ever expanding SoC and board >>> support, and using it more as a productive kernel for downstream. > > I don't think that a 'fork' is really a solution we are looking for. Using > Linaro as a staging and consolidation tree and at the same time improving > the upstream kernel is more what I would be looking for and what Linaro is > currently working on. Yeah, staging is more close to what I meant, a 'fork' is not appropriate here, as getting the support into mainline will always be our goal. Yet there seems to be necessary to have such a temporary place for those patches to live before the mainline is in a good enough shape. And it should not be an arm-next tree, which is just for detecting merge conflict. I expect it to be more usable, end users can just download and build a basically usable kernel. > > Regards, > Philippe > > -Original Message- > From: linaro-dev-boun...@lists.linaro.org > [mailto:linaro-dev-boun...@lists.linaro.org] On Behalf Of Eric Miao > Sent: 01 April 2011 16:44 > To: Linaro Dev > Subject: Linus being annoyed by the ARM kernel code > > Just FYI - lengthy but very interesting read, Linus was really good at > wording, enjoy heh :-) > > https://lkml.org/lkml/2011/3/17/283 > > So maybe it's just a right time to talk about using linaro ARM kernel > tree as a fork for quick merge of the ever expanding SoC and board > support, and using it more as a productive kernel for downstream. > And in the mean time, improve the mainline kernel into such a good > shape that with less crappy code we could support more platforms? > > Just a bit thought on that possibility. > > - eric > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: USB issues on OMAP3 (beagle/overo) with latest linaro-2.6.38 tree
Is there a bug tracking this? if not, would you mind opening one? I fear this affects OMAP4 with the -omap flavor as well. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Notes & Actions: Linaro Graphics Working Group - Mar 30, 2011
Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-03-30 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%20Call Summary === * cairo-gles2: Patchset "Add r8g8b8a8 and r8g8b8x8 formats" accepted in pixman master (last commit: b514e63c). * glcompbench: finalizing initial version of profiling support. * skia: rebasing patches to support different upstream path. * Efikamx: 2 bugs fixed (lp #736924 and #736869). * compiz running on pandaboard * Branch http://git.compiz.org/~amaranth/mobilebling * Technical topics for 11.11 cycle presented to TSC. Risks / Issues == * Still no license update for Nux. * No feedback from landing teams on Mali kernel tree. * Progress on both of last week's issues (see above). Thanks, -- - Alexandros ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: USB issues on OMAP3 (beagle/overo) with latest linaro-2.6.38 tree
On Fri, 2011-04-01 at 19:02 +0200, Loïc Minier wrote: > Is there a bug tracking this? if not, would you mind opening one? > > I fear this affects OMAP4 with the -omap flavor as well. https://bugs.edge.launchpad.net/linux-linaro/+bug/747639 thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
On Sat, 2 Apr 2011, Eric Miao wrote: > Yeah, staging is more close to what I meant, a 'fork' is not appropriate here, > as getting the support into mainline will always be our goal. Yet there seems > to be necessary to have such a temporary place for those patches to live > before the mainline is in a good enough shape. No, that won't solve the problem. Patches will simply be pushed to that temporary place and rot there while their authors have moved on to the next SOC revision to enable. The problem is more fundamental due to the lack of better common infrastructure. We must come to a point where SOC code is obvious to write and right from the start. That's the only solution that scales. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: armhf progress: 2.6.38 kernel for the efikasb/mx, SD card bootable image
Hello Konstantinos, 2011/4/1 Konstantinos Margaritis : > I tried to upload the kernel debs to ftp.debian-ports.org, but I'm > getting some upload errors, so I uploaded them to Right now I am getting some issues trying to create a rootfs with multistrap from debian-ports.org The following packages have unmet dependencies: apt : Depends: libgcc1 but it is not installable Depends: libstdc++6 but it is not installable dpkg-dev : Depends: binutils but it is not going to be installed libc6 : Depends: libgcc1 but it is not installable E: Broken packages apt download failed. Exit value: 100 make: *** [rootfs] Error 100 In anycase I put up in git the config scripts, which right now generates a boot.scr for u-boot and a rootfs for armhf. git clone git://git.emdebian.org/efika/multistrap.git cd multistrap make Cheers, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OMAP4 MPU DVFS patches
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote: > Hi Nicolas, > > Pls find rebased OMAP DVFS patches attached. Apologies for the delay > as I had to rework some of the patches because of kernel migration. No problem. Merged, thanks. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre wrote: > On Sat, 2 Apr 2011, Eric Miao wrote: > >> Yeah, staging is more close to what I meant, a 'fork' is not appropriate >> here, >> as getting the support into mainline will always be our goal. Yet there seems >> to be necessary to have such a temporary place for those patches to live >> before the mainline is in a good enough shape. > > No, that won't solve the problem. Patches will simply be pushed to that > temporary place and rot there while their authors have moved on to the > next SOC revision to enable. > > The problem is more fundamental due to the lack of better common > infrastructure. We must come to a point where SOC code is obvious to > write and right from the start. That's the only solution that scales. > I understand it could be even worse to have a temporary place. Yet there is indeed a timeline gap before a generic enough infrastructure could be implemented, and please Linus and everyone. I noted some of my ideas in my mind last night below: The major problem I see now is the ever increasing support for more ARM SoC and more platforms, yet the mainline kernel so far is not in a good shape for this scalability, not at least until the below features are completed: * Device tree for hardware abstraction * Single kernel binary for most SoCs/boards * And very hardware specific code moved out to a controllable place, i.e. something like BIOS So that the kernel can be generic enough. There is a time gap before all these could be done. Thus, I'm thinking of a staging kernel tree that: 1. Merges support for more ARM SoCs and platforms 2. Code for different SoCs and boards do not conflict and impact each other, they live in a single branch 3. Will have a certain level of code quality, at least conforming to mainline kernel code quality, however, upstreamable, upstreamed or Acked-by mainline maintainers might be too strict here e.g. Most of Freescale's BSP code is quite in a good shape already, but won't probably make upstream maintainer happy in every place. Yet I believe it deserves a place somewhere, not only on freescale's extranet. 4. This kernel tree should be as much full feature as possible, unless some driver code quality doesn't conform 5. A usable Ubuntu kernel package, an Android kernel image or a kernel image for the LEBs that we will support could be automatically generated from this tree, daily build and automation test would make every player here happy 6. The tree will be sync'ed with mainline kernel constantly, I believe what Nico is doing is already very perfectly, that we will have: linux-linaro-2.6.38 linux-linaro-2.6.39 ... Our members are always busy working on kernel upgrade by their own, and each upgrade they chose a kernel version based on customer's or distro kernel's requirement. And they would normally be facing with a big kernel version delta, and make their upgrade a great pain. If there is already a Linaro kernel that's very usable and we help sync with every mainline kernel release, this will definitely make them happy. Keeping track to every mainline kernel release would also make the whole upgrade easier, because the delta would be much smaller. But that of course Linaro will have to do more work, which I think could be part of the landing team job. Even if we do little or none here, the upgrade itself, and the daily build and automation test would provide a great feedback to our members. 7. Due to a certain level of code requirement here, it could be the case that SoC member still need put something on top, e.g. some dirty patches which are necessary but could make other SoCs unusable, and they still need their own BSP kernel. However, in this case, they are losing nothing, because the only difference for them in this case is to base on a Linaro kernel or a mainline kernel. 8. For our SoC member's customers, they can either get a kernel from our members, or from Linaro. And for those very small customers that our members have no resource to support, they don't normally care if a kernel is coming from mainline or from Linaro, as long as it's usable. 9. And again, upstreaming effort to mainline remains unchanged, and this tree could serve as a great starting point. But this would definitely increase the maintainance effort. (I'm looking at Nico :-) So I think the Landing team could definitely help to get in our member's kernel support in there, as this increases our member's value. - eric > > Nicolas > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
On Sat, Apr 2, 2011 at 12:46 PM, Eric Miao wrote: > On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre > wrote: >> On Sat, 2 Apr 2011, Eric Miao wrote: >> >>> Yeah, staging is more close to what I meant, a 'fork' is not appropriate >>> here, >>> as getting the support into mainline will always be our goal. Yet there >>> seems >>> to be necessary to have such a temporary place for those patches to live >>> before the mainline is in a good enough shape. >> >> No, that won't solve the problem. Patches will simply be pushed to that >> temporary place and rot there while their authors have moved on to the >> next SOC revision to enable. My argument is that patches won't rot here. Patches rot in a kernel tree that is derived from our member SoC's BSP and pushed nowhere and very few developers involved as a pet project. Yeah, this reminds me of the zaurus 2.4 kernel tree. But it's a different case here, we have our members involved, and what we are going to support are those boards that's widely available and there's a community working on, we definitely don't want to merge all the craps that could be out of maintenance. And that we provide a playground so the kernel is actually usable with Ubuntu or Android, which in the contrary makes it easier to test and validate and get the patches mainlined. But I don't believe what we're doing >> >> The problem is more fundamental due to the lack of better common >> infrastructure. We must come to a point where SOC code is obvious to >> write and right from the start. That's the only solution that scales. >> > > I understand it could be even worse to have a temporary place. Yet there > is indeed a timeline gap before a generic enough infrastructure could be > implemented, and please Linus and everyone. I noted some of my ideas in > my mind last night below: > > The major problem I see now is the ever increasing support for more ARM > SoC and more platforms, yet the mainline kernel so far is not in a good > shape for this scalability, not at least until the below features are > completed: > > * Device tree for hardware abstraction > * Single kernel binary for most SoCs/boards > * And very hardware specific code moved out to a controllable place, > i.e. something like BIOS > > So that the kernel can be generic enough. There is a time gap before > all these could be done. Thus, I'm thinking of a staging kernel tree > that: > > 1. Merges support for more ARM SoCs and platforms > > 2. Code for different SoCs and boards do not conflict and impact each > other, they live in a single branch > > 3. Will have a certain level of code quality, at least conforming to > mainline kernel code quality, however, upstreamable, upstreamed or > Acked-by mainline maintainers might be too strict here > > e.g. Most of Freescale's BSP code is quite in a good shape already, > but won't probably make upstream maintainer happy in every place. > Yet I believe it deserves a place somewhere, not only on freescale's > extranet. > > 4. This kernel tree should be as much full feature as possible, unless > some driver code quality doesn't conform > > 5. A usable Ubuntu kernel package, an Android kernel image or a kernel > image for the LEBs that we will support could be automatically generated > from this tree, daily build and automation test would make every player > here happy > > 6. The tree will be sync'ed with mainline kernel constantly, I believe > what Nico is doing is already very perfectly, that we will have: > > linux-linaro-2.6.38 > linux-linaro-2.6.39 > ... > > Our members are always busy working on kernel upgrade by their own, > and each upgrade they chose a kernel version based on customer's or > distro kernel's requirement. And they would normally be facing with > a big kernel version delta, and make their upgrade a great pain. > > If there is already a Linaro kernel that's very usable and we help > sync with every mainline kernel release, this will definitely make > them happy. > > Keeping track to every mainline kernel release would also make the > whole upgrade easier, because the delta would be much smaller. But > that of course Linaro will have to do more work, which I think could > be part of the landing team job. Even if we do little or none here, > the upgrade itself, and the daily build and automation test would > provide a great feedback to our members. > > 7. Due to a certain level of code requirement here, it could be the > case that SoC member still need put something on top, e.g. some > dirty patches which are necessary but could make other SoCs unusable, > and they still need their own BSP kernel. However, in this case, they > are losing nothing, because the only difference for them in this case > is to base on a Linaro kernel or a mainline kernel. > > 8. For our SoC member's customers, they can either get a kernel from > our members, or from Linaro. And for those very small customers that > our members have no resource to support, they don't norma
