Re: how to sync with mainline

[Barry Song]

Hi Lee,
Great! Thanks a lot. It looks like the communication between linaro
and mainline is that linaro can backport some bug fixes and features
from mainline to linaro tree. Linaro doesn't help to review patches
and send to mainline.
Then I have two more questions
1. is there a detailed list of backport and bug fix in linaro kernel
tree since those are the difference between mainline and linaro tree?
2. will linaro accept patches from non-member companies and help to
maintain, I mean a SoC company which doesn't join linaro?

Thanks
Barry

2011/3/8 Lee Jones :
> Hi Barry,
>
>> I am a freshman to linaro. I found people sent some patches to
>> linaro-dev@lists.linaro.org. Here I have 2 questions:
>> 1. Whether will linaro send those patches based on newest tree to
>> Linus' mainline or not?  Or developers need to send those patches to
>> mainline by themselves?
>
> Authors need to post their own patches to the relevant mailing lists [1]
> for inclusion into the Mainline kernel.
>
>> Is there any document to describe how linaro contribute patches to
> mainline?
>
> As above.
>
>> 2. If other SoC companies work based on linaro's
>> linux-linaro-next.git, whether it will not need to work based on
>> Linus' tree since linux-linaro-next.git will sync with mainline?
>
> If your patches are going into Mainline, they will need to be built
> against the Mainline tree. If they are not going upstream, then the
> chances are they won't be accepted into the Linaro tree either.
>
> [1] http://vger.kernel.org/vger-lists.html
>
> Kind regards,
> Lee
>



-- 
Barry Song, Linux Kernel Developer
http://21cnbao.blog.51cto.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: how to sync with mainline

[Amit Kucheria]

On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote:
> Hi Lee,
> Great! Thanks a lot. It looks like the communication between linaro
> and mainline is that linaro can backport some bug fixes and features
> from mainline to linaro tree. Linaro doesn't help to review patches
> and send to mainline.

We prefer to see it this way:

Develop against mainline and get those features integrated there. Keep
linaro-dev in cc if these are features might be something Linaro would
care about.

The Linaro kernel (maintained by Nicolas Pitre and packaged by John
Rigby) is a sort of technology demonstration to show what we achieve
every 6 months. Some patches in it are backports, others are features
that are still under review in mainline. But I doubt if Nicolas will
take un-reviewed code directly into his tree.

> Then I have two more questions
> 1. is there a detailed list of backport and bug fix in linaro kernel
> tree since those are the difference between mainline and linaro tree?

'git log' with the right incantations should be able to tell you that.
Look up Nicolas' email announcements for the high-level overview of
what he has integrated.

> 2. will linaro accept patches from non-member companies and help to
> maintain, I mean a SoC company which doesn't join linaro?

Linaro doesn't want to maintain dead code that isn't going upstream.
It won't even do it for member companies. At most it is the incubator
where the code lives and gets wider testing _while_ it is being
reworked for mainline.

/Amit

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 03:10:56PM +0800, Shawn Guo wrote:
> Hi Zygmunt,
> 
> On Mon, Mar 07, 2011 at 02:19:41PM +0100, Zygmunt Bazyli Krynicki wrote:
> > This will most lokalu not help. 
> > Try my hacking branch of linaro-image-tools. I had the same problem as you 
> > and I added a workaround.
> > 
> Thanks.  But using your branch make it fail at some other place.
> 
> --- quote begin ---
> [...]
> Ign http://ports.ubuntu.com natty/main Translation-en
> Ign http://ports.ubuntu.com natty/universe Translation-en
> Ign http://ports.ubuntu.com natty-updates/main Translation-en
> Ign http://ports.ubuntu.com natty-updates/universe Translation-en
> Fetched 15.0 MB in 10min 34s (23.6 kB/s)
> W: Failed to fetch 
> bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_natty_universe_binary-armel_Packages
>   Hash Sum mismatch
> 
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> Cleaning up ...Done
> [sudo] password for r65073:
> proc umounted
> Traceback (most recent call last):
>   File "/home/r65073/repos/linaro/lmc/hacking/linaro-media-create", line 128, 
> in 
> ROOTFS_DIR, TMP_DIR, lmc_dir, args.hwpack_force_yes, *hwpacks)
>   File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/hwpack.py", 
> line 58, in install_hwpacks
> install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes)
>   File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/hwpack.py", 
> line 78, in install_hwpack
> cmd_runner.run(args, as_root=True).wait()
>   File 
> "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/cmd_runner.py", 
> line 65, in wait
> raise SubcommandNonZeroReturnValue(self._my_args, returncode)
> linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process 
> "['sudo', 'chroot', '/tmp/tmp6xLw4j/binary', 'linaro-hwpack-install', 
> '/hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz']" returned a 
> non-zero value: 100
> --- quote end ---
> 
By looking the workaround on the hacking branch, I changed the sleep(1)
to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py,
and almost made it, but sadly it still fails at the last step.

--- quote begin ---
proc umounted
Checking that no-one is using this disk right now ...
OK
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Formating boot partition

mkfs.vfat 3.0.9 (31 Jan 2010)

Formating root partition

mke2fs 1.41.12 (17-May-2010)
Filesystem label=rootfs
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
237104 inodes, 947835 blocks
47391 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=973078528
29 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
162+1 records in
162+1 records out
166624 bytes (167 kB) copied, 0.0412763 s, 4.0 MB/s
mkimage: Write error on /tmp/tmpXkyS2N/boot-disc/uImage: Success
Traceback (most recent call last):
  File "/usr/bin/linaro-media-create", line 134, in 
args.device, args.is_live, args.is_lowmem, args.consoles)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/populate_boot.py", 
line 57, in populate_boot
boot_disk, boot_script, boot_device_or_file)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 118, 
in make_boot_files
boot_device_or_file)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 312, 
in _make_boot_files
cls.load_addr, uboot_parts_dir, cls.kernel_suffix, boot_dir)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 389, 
in make_uImage
'kernel', load_addr, load_addr, 'Linux', img_data, img)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 363, 
in _run_mkimage
proc.wait()
  File "/usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py", line 
65, in wait
raise SubcommandNonZeroReturnValue(self._my_args, returncode)
linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process 
"['sudo', 'mkimage', '-A', 'arm', '-O', 'linux', '-T', 'kernel', '-C', 'none', 
'-a', '0x90008000', '-e', '0x90008000', '-n', 'Linux', '-d', 
'/tmp/tmpXkyS2N/binary/boot/vmlinuz-2.6.38-1000-linaro-mx51', 
'/tmp/tmpXkyS2N/boot-disc/uImage']" returned a non-zero value: 1
--- quote end ---

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Linaro V4l2 meeting

[Benjamin Gaignard]

Hi all,

on March 7th MM WG has organize a v4l2 meeting to collect ideas for next
development cycle.

you can found the minutes of meeting here:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/2011-03-07-V4L2_meeting

mains outcomes:
- investigate/improve the library between v4l2 and Android camera interface
- work on memory allocators: pmem, UMP or hwmem
- design a thin, easy IPC layer in kernel space
- develop an OMX library on top of v4l2

v4l2 developers have demonstrated lot of interest on hwmem topic
v4l2 is active on ISP/DSP/co-processors topic

Benjamin
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Running linaro-media-create on machine behind firewall

[Shawn Guo]

I'm recently trying to install alpha-3 image using l-m-c on an AMD64
machine which is behind the company firewall.  Though I have apt proxy
set on host machine, l-m-c installing system (chroot env?) does not
know it.  Can we improve the l-m-c a little bit to copy apt proxy
setting if any on host machine into installing system?  So that the
machine behind proxy can survive with l-m-c too.

PS.
Actually, I have my machine home which can directly access natty
repository, but it's very slow (see below), probably because there
is no natty mirror in China yet.

Fetched 15.0 MB in 10min 22s (24.1 kB/s)

When I use vpn to connect company network, speed of accessing ubuntu
repository can reach ~200 kB/s.  Considering that I'm testing l-m-c
back and forth, I really need a faster apt speed within l-m-c.

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> > parted -s /dev/sdN mklabel msdos && sfdisk -L /dev/sdN
> 
> $ sudo parted -s /dev/sdb mklabel msdos && sfdisk -L /dev/sdb
> /dev/sdb: Permission denied
> 
> sfdisk: cannot open /dev/sdb read-write

 you want to sudo the sfdisk call too

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Spring Zhang]

On 8 March 2011 17:19, Shawn Guo  wrote:

> I'm recently trying to install alpha-3 image using l-m-c on an AMD64
> machine which is behind the company firewall.  Though I have apt proxy
> set on host machine, l-m-c installing system (chroot env?) does not
> know it.  Can we improve the l-m-c a little bit to copy apt proxy
> setting if any on host machine into installing system?  So that the
> machine behind proxy can survive with l-m-c too.
>
> PS.
> Actually, I have my machine home which can directly access natty
> repository, but it's very slow (see below), probably because there
> is no natty mirror in China yet.
>

Did you try to switch apt source to China in the updater-manager?
Can this work: http://ubuntu.cn99.com/ubuntu/dists/


> Fetched 15.0 MB in 10min 22s (24.1 kB/s)
>
> When I use vpn to connect company network, speed of accessing ubuntu
> repository can reach ~200 kB/s.  Considering that I'm testing l-m-c
> back and forth, I really need a faster apt speed within l-m-c.
>
> --
> Regards,
> Shawn
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>



-- 
Best wishes,
Spring Zhang
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> mkimage: Write error on /tmp/tmpXkyS2N/boot-disc/uImage: Success

 Could it be that your MMC is flaky?

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Dave Martin]

Looking at the packaging branch lp:ubuntu/linaro-image-tools, I see
there are now multiple binary packages generated from
linaro-image-tools.

The udisks dependency needs to be added somewhere -- does anyone know
which package needs it?  I'm guessing it's either linaro-image-tools
or python-linaro-image-tools (possibly both).

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Yet another memory provider: can linaro organize a meeting?

[Hans Verkuil]

Hi all,

We had a discussion yesterday regarding ways in which linaro can assist
V4L2 development. One topic was that of sorting out memory providers like
GEM and HWMEM.

Today I learned of yet another one: UMP from ARM.

http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/

This is getting out of hand. I think that organizing a meeting to solve this
mess should be on the top of the list. Companies keep on solving the same
problem time and again and since none of it enters the mainline kernel any
driver using it is also impossible to upstream.

All these memory-related modules have the same purpose: make it possible to
allocate/reserve large amounts of memory and share it between different
subsystems (primarily framebuffer, GPU and V4L).

It really shouldn't be that hard to get everyone involved together and settle
on a single solution (either based on an existing proposal or create a 'the
best of' vendor-neutral solution).

I am currently aware of the following solutions floating around the net
that all solve different parts of the problem:

In the kernel: GEM and TTM.
Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.

I'm sure that last list is incomplete.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> I'm recently trying to install alpha-3 image using l-m-c on an AMD64
> machine which is behind the company firewall.  Though I have apt proxy
> set on host machine, l-m-c installing system (chroot env?) does not
> know it.  Can we improve the l-m-c a little bit to copy apt proxy
> setting if any on host machine into installing system?  So that the
> machine behind proxy can survive with l-m-c too.

 Sounds like https://bugs.launchpad.net/linaro-image-tools/+bug/673570

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Alexander Sack]

On Tue, Mar 8, 2011 at 10:53 AM, Loïc Minier  wrote:
> On Tue, Mar 08, 2011, Shawn Guo wrote:
>> I'm recently trying to install alpha-3 image using l-m-c on an AMD64
>> machine which is behind the company firewall.  Though I have apt proxy
>> set on host machine, l-m-c installing system (chroot env?) does not
>> know it.  Can we improve the l-m-c a little bit to copy apt proxy
>> setting if any on host machine into installing system?  So that the
>> machine behind proxy can survive with l-m-c too.
>
>  Sounds like https://bugs.launchpad.net/linaro-image-tools/+bug/673570

yes, thats the proxy problem. But, fwiw, l-m-c shouldn't even try to
access the net if the hwpacks has the debs included, see:

 https://bugs.launchpad.net/linaro-image-tools/+bug/716479

-- 

 - Alexander

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Loïc Minier]

On Tue, Mar 08, 2011, Dave Martin wrote:
> Looking at the packaging branch lp:ubuntu/linaro-image-tools, I see
> there are now multiple binary packages generated from
> linaro-image-tools.
> 
> The udisks dependency needs to be added somewhere -- does anyone know
> which package needs it?  I'm guessing it's either linaro-image-tools
> or python-linaro-image-tools (possibly both).

 grep udisks to the rescue, and
 /usr/share/pyshared/linaro_media_create/check_device.py and
 /usr/share/pyshared/linaro_media_create/partitions.py seem to use it,
 so I'd say python-linaro-media-create needs it.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 10:23:17AM +0100, Loïc Minier wrote:
> On Tue, Mar 08, 2011, Shawn Guo wrote:
> > > parted -s /dev/sdN mklabel msdos && sfdisk -L /dev/sdN
> > 
> > $ sudo parted -s /dev/sdb mklabel msdos && sfdisk -L /dev/sdb
> > /dev/sdb: Permission denied
> > 
> > sfdisk: cannot open /dev/sdb read-write
> 
>  you want to sudo the sfdisk call too
> 
Have a look at the /dev/sdb change in device report before and after
the command you suggest ...

--- quote begin ---
r65073@S2101-09:~/image/linaro$ linaro-media-create --rootfs ext3 --mmc 
/dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack 
hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk

I see...
Device   Mount point  Size
/dev/sda5none 76048MB
/dev/dm-0/72868MB
/dev/dm-1none 3136MB
/dev/sdb1none 3780MB
/dev/sda none 76293MB
/dev/sda1/boot243MB
/dev/sda2none 76048MB
/dev/sr0 none 0MB
/dev/sdb none 3781MB
Are you 100% sure, on selecting [/dev/sdb] (y/n)? n
r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && sudo 
sfdisk -L /dev/sdb
/dev/sdb: No medium found

sfdisk: cannot open /dev/sdb read-write
r65073@S2101-09:~/image/linaro$ linaro-media-create --rootfs ext3 --mmc 
/dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack 
hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk

I see...
Device   Mount point  Size
/dev/sda5none 76048MB
/dev/dm-0/72868MB
/dev/dm-1none 3136MB
/dev/sda none 76293MB
/dev/sda1/boot243MB
/dev/sda2none 76048MB
/dev/sr0 none 0MB
/dev/sdb none 0MB
Are you 100% sure, on selecting [/dev/sdb] (y/n)? n
--- quote end ---

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Shawn Guo]

On Tue, Mar 08, 2011 at 10:53:00AM +0100, Loïc Minier wrote:
> On Tue, Mar 08, 2011, Shawn Guo wrote:
> > I'm recently trying to install alpha-3 image using l-m-c on an AMD64
> > machine which is behind the company firewall.  Though I have apt proxy
> > set on host machine, l-m-c installing system (chroot env?) does not
> > know it.  Can we improve the l-m-c a little bit to copy apt proxy
> > setting if any on host machine into installing system?  So that the
> > machine behind proxy can survive with l-m-c too.
> 
>  Sounds like https://bugs.launchpad.net/linaro-image-tools/+bug/673570
> 
Yes, it is.  Do we have a quick fix right now?  I need it ...

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Shawn Guo]

On Tue, Mar 08, 2011 at 11:04:08AM +0100, Alexander Sack wrote:
> On Tue, Mar 8, 2011 at 10:53 AM, Loïc Minier  wrote:
> > On Tue, Mar 08, 2011, Shawn Guo wrote:
> >> I'm recently trying to install alpha-3 image using l-m-c on an AMD64
> >> machine which is behind the company firewall.  Though I have apt proxy
> >> set on host machine, l-m-c installing system (chroot env?) does not
> >> know it.  Can we improve the l-m-c a little bit to copy apt proxy
> >> setting if any on host machine into installing system?  So that the
> >> machine behind proxy can survive with l-m-c too.
> >
> >  Sounds like https://bugs.launchpad.net/linaro-image-tools/+bug/673570
> 
> yes, thats the proxy problem. But, fwiw, l-m-c shouldn't even try to
> access the net if the hwpacks has the debs included, see:
> 
>  https://bugs.launchpad.net/linaro-image-tools/+bug/716479
> 
In that case, l-m-c becomes a very nice tool :)

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> Have a look at the /dev/sdb change in device report before and after
> the command you suggest ...

 Interesting :-)

 But the linaro-media-create "size" output is probably broken for the
 same reason: sdb appears to be unavailable for some time after changing
 the partition table:

> Are you 100% sure, on selecting [/dev/sdb] (y/n)? n
> r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && sudo 
> sfdisk -L /dev/sdb
> /dev/sdb: No medium found
> 
> sfdisk: cannot open /dev/sdb read-write

 That's pretty convincing to me; anything relevant in dmesg?

 We could do something like the attached shell script; would you mind
 running it to confirm this works without removing/reinserting the MMC?
 I'm curious to see how much time your drive needs to come back.

-- 
Loïc Minier
#!/bin/sh

set -e

sudo="sudo"
if [ $(id -u) -eq 0 ]; then
sudo=""
fi

usage() {
echo "Usage: $0 " >&2
exit 1
}

if [ $# -ne 1 ]; then
usage
fi

dev="$1"

if [ ! -b "$dev" ]; then
usage
fi

set -x

$sudo parted -s "$dev" mklabel msdos

#sync?

nap_time=0
while :; do
if $sudo sfdisk -L "$dev" >/dev/null 2>&1; then
break
fi
if [ $nap_time -ge 30 ]; then
echo "Giving up after $nap_time seconds failing to list partitions" >&2
exit 1
fi
sleep 1
nap_time=$(($nap_time + 1))
done

echo "Could list partitions after $nap_time seconds!" >&2

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> Yes, it is.  Do we have a quick fix right now?  I need it ...

 As a workaround, try disabling your (host's) network entirely before
 running linaro-media-create; I could run it completely networkless, but
 I think your proxy is confusing APT.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Shawn Guo]

On Tue, Mar 08, 2011 at 11:53:08AM +0100, Loïc Minier wrote:
> On Tue, Mar 08, 2011, Shawn Guo wrote:
> > Yes, it is.  Do we have a quick fix right now?  I need it ...
> 
>  As a workaround, try disabling your (host's) network entirely before
>  running linaro-media-create; I could run it completely networkless, but
>  I think your proxy is confusing APT.
> 
That's not an option for me.  Myself is on ssh terminal.  I do not
have a nice monitor for that machine :)

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Kyungmin Park]

Dear Jonghun,

It's also helpful to explain what's the original purpose of UMP (for
GPU, MALI) and what's the goal of UMP usage for multimedia stack.
Especially, what's the final goal of UMP from LSI.

Also consider the previous GPU memory management program, e.g., SGX.

Thank you,
Kyungmin Park

On Tue, Mar 8, 2011 at 5:13 PM, Hans Verkuil  wrote:
> Hi all,
>
> We had a discussion yesterday regarding ways in which linaro can assist
> V4L2 development. One topic was that of sorting out memory providers like
> GEM and HWMEM.
>
> Today I learned of yet another one: UMP from ARM.
>
> http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/
>
> This is getting out of hand. I think that organizing a meeting to solve this
> mess should be on the top of the list. Companies keep on solving the same
> problem time and again and since none of it enters the mainline kernel any
> driver using it is also impossible to upstream.
>
> All these memory-related modules have the same purpose: make it possible to
> allocate/reserve large amounts of memory and share it between different
> subsystems (primarily framebuffer, GPU and V4L).
>
> It really shouldn't be that hard to get everyone involved together and settle
> on a single solution (either based on an existing proposal or create a 'the
> best of' vendor-neutral solution).
>
> I am currently aware of the following solutions floating around the net
> that all solve different parts of the problem:
>
> In the kernel: GEM and TTM.
> Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
>
> I'm sure that last list is incomplete.
>
> Regards,
>
>        Hans
>
> --
> Hans Verkuil - video4linux developer - sponsored by Cisco
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Running linaro-media-create on machine behind firewall

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> That's not an option for me.  Myself is on ssh terminal.  I do not
> have a nice monitor for that machine :)

 Ok; I could propose various network tricks such as changing the routing
 table to mark your APT repo unreachable, but I guess we really have to
 fix support for proxies and/or offline.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: Yet another memory provider: can linaro organize a meeting?

[Jonghun Han]

Thanks for interesting.

As I know, the purpose of UMP is the buffer sharing especially inter-process
.
Maybe ARM can explain it more detail.

High resolution video/image processing requires zero-copy operation.
UMP allows zero-copy operation using system unique key, named SecureID.
UMP supports memory allocation. (custom memory allocator can be used.)
It gives a SecureID for each buffer during allocation.
And user virtual address for each process can be made by SecureID.
Application can access the buffer using its own virtual address made by
SecureID.
So application can share the buffer without copy operation.

For example, video playback application can share the buffer even though it
consists of multiple process.

Best regards,
Jonghun Han

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Kyungmin Park
> Sent: Tuesday, March 08, 2011 8:06 PM
> To: Hans Verkuil
> Cc: linaro-dev@lists.linaro.org; linux-me...@vger.kernel.org; Jonghun Han
> Subject: Re: Yet another memory provider: can linaro organize a meeting?
> 
> Dear Jonghun,
> 
> It's also helpful to explain what's the original purpose of UMP (for GPU,
> MALI) and what's the goal of UMP usage for multimedia stack.
> Especially, what's the final goal of UMP from LSI.
> 
> Also consider the previous GPU memory management program, e.g., SGX.
> 
> Thank you,
> Kyungmin Park
> 
> On Tue, Mar 8, 2011 at 5:13 PM, Hans Verkuil  wrote:
> > Hi all,
> >
> > We had a discussion yesterday regarding ways in which linaro can
> > assist
> > V4L2 development. One topic was that of sorting out memory providers
> > like GEM and HWMEM.
> >
> > Today I learned of yet another one: UMP from ARM.
> >
> > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-
> > open-source/page__cid__133__show__newcomment/
> >
> > This is getting out of hand. I think that organizing a meeting to
> > solve this mess should be on the top of the list. Companies keep on
> > solving the same problem time and again and since none of it enters
> > the mainline kernel any driver using it is also impossible to upstream.
> >
> > All these memory-related modules have the same purpose: make it
> > possible to allocate/reserve large amounts of memory and share it
> > between different subsystems (primarily framebuffer, GPU and V4L).
> >
> > It really shouldn't be that hard to get everyone involved together and
> > settle on a single solution (either based on an existing proposal or
> > create a 'the best of' vendor-neutral solution).
> >
> > I am currently aware of the following solutions floating around the
> > net that all solve different parts of the problem:
> >
> > In the kernel: GEM and TTM.
> > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
> >
> > I'm sure that last list is incomplete.
> >
> > Regards,
> >
> >        Hans
> >
> > --
> > Hans Verkuil - video4linux developer - sponsored by Cisco
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Benjamin Gaignard]

Hi,

hwmem basically use the same concept of handle (or SecureID).

The problem with this approach is that the middleware must be aware of this
handle and must provide a way to forward it between elements/component and
upper level. Today isn't the case in GStreamer (maybe in 1.0 it will), EGL,
X ... the list isn't complete.

Does one solution natively provide a way to not use a handle and to only get
a virtual address to manage in middleware?

While talking with hwmem owners, I came to the idea that a solution could be
to reserve, overs all process, a range of virtual address where only hwmem
could mmap physical buffers so the virtual address of the buffer could
become the "handle" of the underline buffer.

Benjamin

2011/3/8 Jonghun Han 

>
> Thanks for interesting.
>
> As I know, the purpose of UMP is the buffer sharing especially
> inter-process
> .
> Maybe ARM can explain it more detail.
>
> High resolution video/image processing requires zero-copy operation.
> UMP allows zero-copy operation using system unique key, named SecureID.
> UMP supports memory allocation. (custom memory allocator can be used.)
> It gives a SecureID for each buffer during allocation.
> And user virtual address for each process can be made by SecureID.
> Application can access the buffer using its own virtual address made by
> SecureID.
> So application can share the buffer without copy operation.
>
> For example, video playback application can share the buffer even though it
> consists of multiple process.
>
> Best regards,
> Jonghun Han
>
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Kyungmin Park
> > Sent: Tuesday, March 08, 2011 8:06 PM
> > To: Hans Verkuil
> > Cc: linaro-dev@lists.linaro.org; linux-me...@vger.kernel.org; Jonghun
> Han
> > Subject: Re: Yet another memory provider: can linaro organize a meeting?
> >
> > Dear Jonghun,
> >
> > It's also helpful to explain what's the original purpose of UMP (for GPU,
> > MALI) and what's the goal of UMP usage for multimedia stack.
> > Especially, what's the final goal of UMP from LSI.
> >
> > Also consider the previous GPU memory management program, e.g., SGX.
> >
> > Thank you,
> > Kyungmin Park
> >
> > On Tue, Mar 8, 2011 at 5:13 PM, Hans Verkuil  wrote:
> > > Hi all,
> > >
> > > We had a discussion yesterday regarding ways in which linaro can
> > > assist
> > > V4L2 development. One topic was that of sorting out memory providers
> > > like GEM and HWMEM.
> > >
> > > Today I learned of yet another one: UMP from ARM.
> > >
> > > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-
> > > open-source/page__cid__133__show__newcomment/
> > >
> > > This is getting out of hand. I think that organizing a meeting to
> > > solve this mess should be on the top of the list. Companies keep on
> > > solving the same problem time and again and since none of it enters
> > > the mainline kernel any driver using it is also impossible to upstream.
> > >
> > > All these memory-related modules have the same purpose: make it
> > > possible to allocate/reserve large amounts of memory and share it
> > > between different subsystems (primarily framebuffer, GPU and V4L).
> > >
> > > It really shouldn't be that hard to get everyone involved together and
> > > settle on a single solution (either based on an existing proposal or
> > > create a 'the best of' vendor-neutral solution).
> > >
> > > I am currently aware of the following solutions floating around the
> > > net that all solve different parts of the problem:
> > >
> > > In the kernel: GEM and TTM.
> > > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
> > >
> > > I'm sure that last list is incomplete.
> > >
> > > Regards,
> > >
> > >Hans
> > >
> > > --
> > > Hans Verkuil - video4linux developer - sponsored by Cisco
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-media"
> > > in the body of a message to majord...@vger.kernel.org More majordomo
> > > info at  http://vger.kernel.org/majordomo-info.html
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the
> > body of a message to majord...@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
>
> ___
> 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

Packaging Django applications and projects

[Zygmunt Krynickiu]

Hi.

This is my first post to this mailing list, and in fact to any Debian 
mailing list in general so I'd like to introduce myself first. To keep 
Your interest focused on the problem I moved this to the footer of this 
message. With that of the way here's the core topic:


I'd like to define and document the recommended best practice of 
packaging Django 1.0+ (and especially 1.3) web applications and projects 
for Debian. I started this on the Debian wiki at

http://wiki.debian.org/DjangoPackagingDraft

The topics I want to cover are:

* Packaging Django applications:
  - where to install code
  - where to install templates
  - where to install static files (as understood by 
http://docs.djangoproject.com/en/dev/howto/static-files/)

  - where to install documentation (if any)

* Packaging Django projects:
  - where to install code (like urls, settings, etc)
  - where to install templates
  - how to do settings (debconf integration / configuration files / 
python module vs real config file?)
  - what to with web server integration (aka 
http://localhost/packagename vs do-it-yourself-after-installation)

  - how do to database configuration and integration (dbconfig-common?)


There are some things I did not want to enforce because either there is 
no clear best method or I don't feel that the topic is relevant before 
specifying more fundamental pieces. In particular this includes:


- Shipping web server configuration files so that application can work 
out of the box after installation.
- Handling of project configuration (it's both executable code and 
administrator-oriented settings file)



I started a demo native package (still work in progress, comments 
welcome) called django-hello that contains a simple django project with 
one application. I deliberately used django-staticfiles as that's how 
upcoming web applications will distribute their static files. The code 
is at lp:~zkrynicki/+junk/django_hello. There is an Ubuntu PPA with 
python-django-staticfiles package that is required at 
https://launchpad.net/~zkrynicki/+archive/lava).



There are some compromises I needed to make though. This package is 
using python-support as I still need to target the current Ubuntu LTS 
release (lucid) where dh_python2 is not available. I'm more than happy 
to convert this package to dh_python2 assuming that the same rules can 
be applied in a backwards compatible manner to Lucid packages.



That's it.
I'd like to know what you think.

About me:

My name is Zygmunt Krynicki. I'm work in the Linaro Validation team and 
I'd like to start a process that will make the output of the Linaro 
Validation team available to Debian users. I'd like to maintain the 
packages we're making and learn to do those packages properly.


Most of my work revolves around server-side technology, specifically 
around Django web applications. I did not find any strong guidelines on 
how to package Django web applications and projects for Debian. 
Therefore I decided that I'd like to contribute to Debian and help 
define and apply those guidelines to various Django applications as they 
become available.



Best regards
Zygmunt Krynicki

PS: I cross-posted to linaro-dev to make sure people there that might be 
interested in this discussion can notice it and participate.


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Zygmunt Krynicki]

W dniu 08.03.2011 09:51, Shawn Guo pisze:


By looking the workaround on the hacking branch, I changed the sleep(1)
to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py,
and almost made it, but sadly it still fails at the last step.


You most likely missed another sleep (there should be two).
Could you please confirm that?

Thanks
ZK

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 03:16:32PM +0100, Zygmunt Krynicki wrote:
> W dniu 08.03.2011 09:51, Shawn Guo pisze:
> 
> >By looking the workaround on the hacking branch, I changed the sleep(1)
> >to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py,
> >and almost made it, but sadly it still fails at the last step.
> 
> You most likely missed another sleep (there should be two).
> Could you please confirm that?
> 
I only see one sleep in /usr/share/pyshared/linaro_media_create/partitions.py.
You meant there is another one in partitions.py or other files?

I attached the /usr/share/pyshared/linaro_media_create/partitions.py
for your checking.

-- 
Regards,
Shawn
# Copyright (C) 2010, 2011 Linaro
#
# Author: Guilherme Salgado 
#
# This file is part of Linaro Image Tools.
# 
# Linaro Image Tools is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# Linaro Image Tools is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with Linaro Image Tools.  If not, see .

import atexit
import glob
import re
import subprocess
import time

import dbus
from parted import (
Device,
Disk,
)

from linaro_media_create import cmd_runner


HEADS = 255
SECTORS = 63
SECTOR_SIZE = 512 # bytes
CYLINDER_SIZE = HEADS * SECTORS * SECTOR_SIZE
DBUS_PROPERTIES = 'org.freedesktop.DBus.Properties'
UDISKS = "org.freedesktop.UDisks"


# I wonder if it'd make sense to convert this into a small shim which calls
# the appropriate function for the given type of device?  I think it's still
# small enough that there's not much benefit in doing that, but if it grows we
# might want to do it.
def setup_partitions(board_config, media, image_size, bootfs_label,
 rootfs_label, rootfs_type, should_create_partitions,
 should_format_bootfs, should_format_rootfs):
"""Make sure the given device is partitioned to boot the given board.

:param board_config: A BoardConfig class.
:param media: The Media we should partition.
:param image_size: The size of the image file, in case we're setting up a
QEMU image.
:param should_create_partitions: Whether or not we should erase existing
partitions and create new ones.
"""
cylinders = None
if not media.is_block_device:
image_size_in_bytes = convert_size_to_bytes(image_size)
cylinders = image_size_in_bytes / CYLINDER_SIZE
image_size_in_bytes = cylinders * CYLINDER_SIZE
proc = cmd_runner.run(
['qemu-img', 'create', '-f', 'raw', media.path, image_size],
stdout=open('/dev/null', 'w'))
proc.wait()

if should_create_partitions:
create_partitions(
board_config, media, HEADS, SECTORS, cylinders)

if media.is_block_device:
bootfs, rootfs = get_boot_and_root_partitions_for_media(
media, board_config)
# It looks like KDE somehow automounts the partitions after you
# repartition a disk so we need to unmount them here to create the
# filesystem.
ensure_partition_is_not_mounted(bootfs)
ensure_partition_is_not_mounted(rootfs)
else:
bootfs, rootfs = get_boot_and_root_loopback_devices(media.path)

if should_format_bootfs:
print "\nFormating boot partition\n"
proc = cmd_runner.run(
['mkfs.vfat', '-F', str(board_config.fat_size), bootfs, '-n',
 bootfs_label],
as_root=True)
proc.wait()

if should_format_rootfs:
print "\nFormating root partition\n"
mkfs = 'mkfs.%s' % rootfs_type
proc = cmd_runner.run(
[mkfs, rootfs, '-L', rootfs_label],
as_root=True)
proc.wait()

return bootfs, rootfs


def get_uuid(partition):
"""Find UUID of the given partition."""
proc = cmd_runner.run(
['blkid', '-o', 'udev', '-p', '-c', '/dev/null', partition],
as_root=True,
stdout=subprocess.PIPE)
blkid_output, _ = proc.communicate()
return _parse_blkid_output(blkid_output)


def _parse_blkid_output(output):
for line in output.splitlines():
uuid_match = re.match("ID_FS_UUID=(.*)", line)
if uuid_match:
return uuid_match.group(1)
return None


def ensure_partition_is_not_mounted(partition):
"""Ensure the given partition is not mounted, umounting if necessary."""
if is_partition_mounted(partition):
cmd_runner.run(['umount', partition], as_root=True).wait()


def is_partition_mounted(partition):
"""Is the given partition mounted?

Re: problem with linaro-media-create

[Zygmunt Krynicki]

W dniu 08.03.2011 15:48, Shawn Guo pisze:

On Tue, Mar 08, 2011 at 03:16:32PM +0100, Zygmunt Krynicki wrote:

W dniu 08.03.2011 09:51, Shawn Guo pisze:


By looking the workaround on the hacking branch, I changed the sleep(1)
to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py,
and almost made it, but sadly it still fails at the last step.


You most likely missed another sleep (there should be two).
Could you please confirm that?


I only see one sleep in /usr/share/pyshared/linaro_media_create/partitions.py.
You meant there is another one in partitions.py or other files?

I attached the /usr/share/pyshared/linaro_media_create/partitions.py
for your checking.


I meant that I needed those two changes to make l-m-c work on my laptop:


http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/289

http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/290


The file you attached seems to have only one of them. Please look at the 
sleep call after "parted -s" in create_partitions()


Best regards
ZK



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Clark, Rob]

Then this sounds to me a bit like like GEM.. (or maybe I should say DRM and
either TTM/GEM below)?  If you can pass buffers back and forth between
kernel and various processes by integer id, and then optionally
read/write/mmap thru some ioctls if needed.. then the buffer sharing problem
is solved.  To me it sounds like how libdrm and libva above work.  If the
problem is already solved for video decode and render, then we just need to
extend it to add camera.

So if it is explicitly about buffer sharing, and not buffer allocation, then
it is still separate from what could/should fit beneath to allocate
contiguous memory..

BR,
-R

On Tue, Mar 8, 2011 at 6:08 AM, Jonghun Han  wrote:

>
> Thanks for interesting.
>
> As I know, the purpose of UMP is the buffer sharing especially
> inter-process
> .
> Maybe ARM can explain it more detail.
>
> High resolution video/image processing requires zero-copy operation.
> UMP allows zero-copy operation using system unique key, named SecureID.
> UMP supports memory allocation. (custom memory allocator can be used.)
> It gives a SecureID for each buffer during allocation.
> And user virtual address for each process can be made by SecureID.
> Application can access the buffer using its own virtual address made by
> SecureID.
> So application can share the buffer without copy operation.
>
> For example, video playback application can share the buffer even though it
> consists of multiple process.
>
> Best regards,
> Jonghun Han
>
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Kyungmin Park
> > Sent: Tuesday, March 08, 2011 8:06 PM
> > To: Hans Verkuil
> > Cc: linaro-dev@lists.linaro.org; linux-me...@vger.kernel.org; Jonghun
> Han
> > Subject: Re: Yet another memory provider: can linaro organize a meeting?
> >
> > Dear Jonghun,
> >
> > It's also helpful to explain what's the original purpose of UMP (for GPU,
> > MALI) and what's the goal of UMP usage for multimedia stack.
> > Especially, what's the final goal of UMP from LSI.
> >
> > Also consider the previous GPU memory management program, e.g., SGX.
> >
> > Thank you,
> > Kyungmin Park
> >
> > On Tue, Mar 8, 2011 at 5:13 PM, Hans Verkuil  wrote:
> > > Hi all,
> > >
> > > We had a discussion yesterday regarding ways in which linaro can
> > > assist
> > > V4L2 development. One topic was that of sorting out memory providers
> > > like GEM and HWMEM.
> > >
> > > Today I learned of yet another one: UMP from ARM.
> > >
> > > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-
> > > open-source/page__cid__133__show__newcomment/
> > >
> > > This is getting out of hand. I think that organizing a meeting to
> > > solve this mess should be on the top of the list. Companies keep on
> > > solving the same problem time and again and since none of it enters
> > > the mainline kernel any driver using it is also impossible to upstream.
> > >
> > > All these memory-related modules have the same purpose: make it
> > > possible to allocate/reserve large amounts of memory and share it
> > > between different subsystems (primarily framebuffer, GPU and V4L).
> > >
> > > It really shouldn't be that hard to get everyone involved together and
> > > settle on a single solution (either based on an existing proposal or
> > > create a 'the best of' vendor-neutral solution).
> > >
> > > I am currently aware of the following solutions floating around the
> > > net that all solve different parts of the problem:
> > >
> > > In the kernel: GEM and TTM.
> > > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
> > >
> > > I'm sure that last list is incomplete.
> > >
> > > Regards,
> > >
> > >Hans
> > >
> > > --
> > > Hans Verkuil - video4linux developer - sponsored by Cisco
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-media"
> > > in the body of a message to majord...@vger.kernel.org More majordomo
> > > info at  http://vger.kernel.org/majordomo-info.html
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the
> > body of a message to majord...@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
>
> ___
> 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: Yet another memory provider: can linaro organize a meeting?

[Andy Walls]

On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
> Hi all,
> 
> We had a discussion yesterday regarding ways in which linaro can assist
> V4L2 development. One topic was that of sorting out memory providers like
> GEM and HWMEM.
> 
> Today I learned of yet another one: UMP from ARM.
> 
> http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/
> 
> This is getting out of hand. I think that organizing a meeting to solve this
> mess should be on the top of the list. Companies keep on solving the same
> problem time and again and since none of it enters the mainline kernel any
> driver using it is also impossible to upstream.
> 
> All these memory-related modules have the same purpose: make it possible to
> allocate/reserve large amounts of memory and share it between different
> subsystems (primarily framebuffer, GPU and V4L).

I'm not sure that's the entire story regarding what the current
allocators for GPU do.  TTM and GEM create in kernel objects that can be
passed between applications.  TTM apparently has handling for VRAM
(video RAM).  GEM uses anonymous userspace memory that can be swapped
out.

TTM:
http://lwn.net/Articles/257417/
http://www.x.org/wiki/ttm
http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=mm.pdf
http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=xdevconf2006.pdf

GEM:
http://lwn.net/Articles/283798/

GEM vs. TTM:
http://lwn.net/Articles/283793/


The current TTM and GEM allocators appear to have API and buffer
processing and management functions tied in with memory allocation.

TTM has fences for event notification of buffer processing completion.
(maybe something v4l2 can do with v4l2_events?)

GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem
to mem API?)


Thanks to the good work of developers on the LMML in the past year or
two, V4L2 has separated out some of that functionality from video buffer
allocation: 

video buffer queue management and userspace access (videobuf2)
memory to memory buffer transformation/movement (m2m)
event notification (VIDIOC_SUBSCRIBE_EVENT)

http://lwn.net/Articles/389081/
http://lwn.net/Articles/420512/


> It really shouldn't be that hard to get everyone involved together and settle
> on a single solution (either based on an existing proposal or create a 'the
> best of' vendor-neutral solution).


"Single" might be making the problem impossibly hard to solve well.
One-size-fits-all solutions have a tendency to fall short on meeting
someone's critical requirement.  I will agree that "less than n", for
some small n, is certainly desirable.

The memory allocators and managers are ideally satisfying the
requirements imposed by device hardware, what userspace applications are
expected to do with the buffers, and system performance.  (And maybe the
platform architecture, I/O bus, and dedicated video memory?)



> I am currently aware of the following solutions floating around the net
> that all solve different parts of the problem:
> 
> In the kernel: GEM and TTM.
> Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.

Prior to a meeting one would probably want to capture for each
allocator:

1. What are the attributes of the memory allocated by this allocator?

2. For what domain was this allocator designed: GPU, video capture,
video decoder, etc.

3. How are applications expected to use objects from this allocator?

4. What are the estimated sizes and lifetimes of objects that would be
allocated this allocator?

5. Beyond memory allocation, what other functionality is built into this
allocator: buffer queue management, event notification, etc.?

6. Of the requirements that this allocator satisfies, what are the
performance critical requirements?


Maybe there are better question to ask.

Regards,
Andy



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On 8 March 2011 18:52, Loïc Minier  wrote:
> On Tue, Mar 08, 2011, Shawn Guo wrote:
>> Have a look at the /dev/sdb change in device report before and after
>> the command you suggest ...
>
>  Interesting :-)
>
>  But the linaro-media-create "size" output is probably broken for the
>  same reason: sdb appears to be unavailable for some time after changing
>  the partition table:
>
>> Are you 100% sure, on selecting [/dev/sdb] (y/n)? n
>> r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && 
>> sudo sfdisk -L /dev/sdb
>> /dev/sdb: No medium found
>>
>> sfdisk: cannot open /dev/sdb read-write
>
>  That's pretty convincing to me; anything relevant in dmesg?
>
>  We could do something like the attached shell script; would you mind
>  running it to confirm this works without removing/reinserting the MMC?
>  I'm curious to see how much time your drive needs to come back.

I'm scanning all 7 cards I have with the script wait_device, each card
with 10 iterations of the test.

1) Transend 4GB SD
2) SanDisk 2GB SD
3) KingMax MMC Mobile 2GB

All above 3 cards passed the test with giving "Could list partitions
after 0 seconds!"

4) SanDisk 4GB SD
5) SanDisk 4GB SD
6) SanDisk 4GB SD
7) SanDisk 4GB SD

All above 4 cards failed with giving "Giving up after 30 seconds
failing to list partitions".  The interesting thing is it does not
always fail from the beginning.  Some cards can even pass the test for
4~5 iterations, and then start failing.  If it starts failing, it
always fails until I remove the card and replug it.

Here are two more tests I will do.

* With adding two sleep(5) in partitions.py that Zygmunt suggests, I
will run l-m-c on the failing card to see if it can get through.
* With the original l-m-c installation, I will run l-m-c on one of
card 1) ~ 3), probably 1) to see how l-m-c goes with the card passed
wait_device.

Again, due to the slow apt-get natty speed, the tests are time
consuming.  I will update the result once it gets done.

-- 
Regards,
Shawn

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Jesse Barker]

Hi all,

Here's what I've cobbled together tentatively from prior threads involving
linaro-dev as well as folks from ARM, Samsung and ST-E:

https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement

The current goals within the graphics working group are to map these API
requirements to extant allocator functionality; in particular, we are
looking at the current UMP drop with respect to TTM (it's what we have
immediately to hand, but would be happy doing similar exercises with HWMEM,
etc.).  From there we can work out what needs to be done to add appropriate
support to TTM (or another allocator).

Please let me know if I've missed anything.

cheers,
Jesse

On Tue, Mar 8, 2011 at 6:01 AM, Andy Walls  wrote:

> On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
> > Hi all,
> >
> > We had a discussion yesterday regarding ways in which linaro can assist
> > V4L2 development. One topic was that of sorting out memory providers like
> > GEM and HWMEM.
> >
> > Today I learned of yet another one: UMP from ARM.
> >
> >
> http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/
> >
> > This is getting out of hand. I think that organizing a meeting to solve
> this
> > mess should be on the top of the list. Companies keep on solving the same
> > problem time and again and since none of it enters the mainline kernel
> any
> > driver using it is also impossible to upstream.
> >
> > All these memory-related modules have the same purpose: make it possible
> to
> > allocate/reserve large amounts of memory and share it between different
> > subsystems (primarily framebuffer, GPU and V4L).
>
> I'm not sure that's the entire story regarding what the current
> allocators for GPU do.  TTM and GEM create in kernel objects that can be
> passed between applications.  TTM apparently has handling for VRAM
> (video RAM).  GEM uses anonymous userspace memory that can be swapped
> out.
>
> TTM:
> http://lwn.net/Articles/257417/
> http://www.x.org/wiki/ttm
>
> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=mm.pdf
>
> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=xdevconf2006.pdf
>
> GEM:
> http://lwn.net/Articles/283798/
>
> GEM vs. TTM:
> http://lwn.net/Articles/283793/
>
>
> The current TTM and GEM allocators appear to have API and buffer
> processing and management functions tied in with memory allocation.
>
> TTM has fences for event notification of buffer processing completion.
> (maybe something v4l2 can do with v4l2_events?)
>
> GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem
> to mem API?)
>
>
> Thanks to the good work of developers on the LMML in the past year or
> two, V4L2 has separated out some of that functionality from video buffer
> allocation:
>
>video buffer queue management and userspace access (videobuf2)
>memory to memory buffer transformation/movement (m2m)
>event notification (VIDIOC_SUBSCRIBE_EVENT)
>
>http://lwn.net/Articles/389081/
>http://lwn.net/Articles/420512/
>
>
> > It really shouldn't be that hard to get everyone involved together and
> settle
> > on a single solution (either based on an existing proposal or create a
> 'the
> > best of' vendor-neutral solution).
>
>
> "Single" might be making the problem impossibly hard to solve well.
> One-size-fits-all solutions have a tendency to fall short on meeting
> someone's critical requirement.  I will agree that "less than n", for
> some small n, is certainly desirable.
>
> The memory allocators and managers are ideally satisfying the
> requirements imposed by device hardware, what userspace applications are
> expected to do with the buffers, and system performance.  (And maybe the
> platform architecture, I/O bus, and dedicated video memory?)
>
>
>
> > I am currently aware of the following solutions floating around the net
> > that all solve different parts of the problem:
> >
> > In the kernel: GEM and TTM.
> > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
>
> Prior to a meeting one would probably want to capture for each
> allocator:
>
> 1. What are the attributes of the memory allocated by this allocator?
>
> 2. For what domain was this allocator designed: GPU, video capture,
> video decoder, etc.
>
> 3. How are applications expected to use objects from this allocator?
>
> 4. What are the estimated sizes and lifetimes of objects that would be
> allocated this allocator?
>
> 5. Beyond memory allocation, what other functionality is built into this
> allocator: buffer queue management, event notification, etc.?
>
> 6. Of the requirements that this allocator satisfies, what are the
> performance critical requirements?
>
>
> Maybe there are better question to ask.
>
> Regards,
> Andy
>
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/l

Re: problem with linaro-media-create

[Loïc Minier]

On Tue, Mar 08, 2011, Shawn Guo wrote:
> I'm scanning all 7 cards I have with the script wait_device, each card
> with 10 iterations of the test.
> 
> 1) Transend 4GB SD
> 2) SanDisk 2GB SD
> 3) KingMax MMC Mobile 2GB
> 
> All above 3 cards passed the test with giving "Could list partitions
> after 0 seconds!"
> 
> 4) SanDisk 4GB SD
> 5) SanDisk 4GB SD
> 6) SanDisk 4GB SD
> 7) SanDisk 4GB SD
> 
> All above 4 cards failed with giving "Giving up after 30 seconds
> failing to list partitions".  The interesting thing is it does not
> always fail from the beginning.  Some cards can even pass the test for
> 4~5 iterations, and then start failing.  If it starts failing, it
> always fails until I remove the card and replug it.

 This is really valuable data; SanDisk 4 GB SDs seem to be a trend
 above!  It would be interesting if you could borrow another USB reader
 for some hours to run the tests on the same SD cards, but a different
 adapter.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Laurent Pinchart]

Hi Andy,

On Tuesday 08 March 2011 15:01:10 Andy Walls wrote:
> On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
> > Hi all,
> > 
> > We had a discussion yesterday regarding ways in which linaro can assist
> > V4L2 development. One topic was that of sorting out memory providers like
> > GEM and HWMEM.
> > 
> > Today I learned of yet another one: UMP from ARM.
> > 
> > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-ope
> > n-source/page__cid__133__show__newcomment/
> > 
> > This is getting out of hand. I think that organizing a meeting to solve
> > this mess should be on the top of the list. Companies keep on solving
> > the same problem time and again and since none of it enters the mainline
> > kernel any driver using it is also impossible to upstream.
> > 
> > All these memory-related modules have the same purpose: make it possible
> > to allocate/reserve large amounts of memory and share it between
> > different subsystems (primarily framebuffer, GPU and V4L).

[snip]

> > It really shouldn't be that hard to get everyone involved together and
> > settle on a single solution (either based on an existing proposal or
> > create a 'the best of' vendor-neutral solution).
> 
> "Single" might be making the problem impossibly hard to solve well.
> One-size-fits-all solutions have a tendency to fall short on meeting
> someone's critical requirement.  I will agree that "less than n", for
> some small n, is certainly desirable.
> 
> The memory allocators and managers are ideally satisfying the
> requirements imposed by device hardware, what userspace applications are
> expected to do with the buffers, and system performance.  (And maybe the
> platform architecture, I/O bus, and dedicated video memory?)

In the embedded world, a very common use case is to capture video data from an 
ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, ...) and display it 
on the GPU (OpenGL/ES). We need to be able to share a data buffer between the 
ISP and the DSP, and another buffer between the DSP and the GPU. If processing 
is not required, sharing a data buffer between the ISP and the GPU is 
required. Achieving zero-copy requires a single memory management solution 
used by the ISP, the DSP and the GPU.

-- 
Regards,

Laurent Pinchart

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 04:03:12PM +0100, Zygmunt Krynicki wrote:
> W dniu 08.03.2011 15:48, Shawn Guo pisze:
> >On Tue, Mar 08, 2011 at 03:16:32PM +0100, Zygmunt Krynicki wrote:
> >>W dniu 08.03.2011 09:51, Shawn Guo pisze:
> >>
> >>>By looking the workaround on the hacking branch, I changed the sleep(1)
> >>>to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py,
> >>>and almost made it, but sadly it still fails at the last step.
> >>
> >>You most likely missed another sleep (there should be two).
> >>Could you please confirm that?
> >>
> >I only see one sleep in 
> >/usr/share/pyshared/linaro_media_create/partitions.py.
> >You meant there is another one in partitions.py or other files?
> >
> >I attached the /usr/share/pyshared/linaro_media_create/partitions.py
> >for your checking.
> 
> I meant that I needed those two changes to make l-m-c work on my laptop:
> 
> 
> http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/289
> 
> http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/290
> 
> 
> The file you attached seems to have only one of them. Please look at
> the sleep call after "parted -s" in create_partitions()
> 
I just added this one, and it does not help.  The l-m-c still fails at
the last step.

mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Loïc Minier]

On Wed, Mar 09, 2011, Shawn Guo wrote:
> I just added this one, and it does not help.  The l-m-c still fails at
> the last step.
> mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success

 This error sounded a bit weird; I checked the u-boot sources, and this
 string is used in a bunch of places, but essentially it's either on
 write() or on close() that this fails.  I bet it's on write() as I
 don't see close() failing without an useful errno, but I could imagine
 the write tests failing:
if (write(ifd, tparams->hdr, tparams->header_size)
!= tparams->header_size) {
fprintf (stderr, "%s: Write error on %s: %s\n",
params.cmdname, params.imagefile, strerror(errno));
 notably if this is a partial write.

 We could change mkimage's write()s to actually account for the number
 of bytes written rather than just failing when not all bytes were
 written.

 Could you log a bug on the u-boot package on that one?  Or rather,
 could you check before hand where your mkimage comes from?
dpkg -S `which mkimage`

apt-cache policy name-of-the-package-returned-above

Thanks!
-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 11:44:36PM +0800, Shawn Guo wrote:
> On 8 March 2011 18:52, Loïc Minier  wrote:
> > On Tue, Mar 08, 2011, Shawn Guo wrote:
> >> Have a look at the /dev/sdb change in device report before and after
> >> the command you suggest ...
> >
> >  Interesting :-)
> >
> >  But the linaro-media-create "size" output is probably broken for the
> >  same reason: sdb appears to be unavailable for some time after changing
> >  the partition table:
> >
> >> Are you 100% sure, on selecting [/dev/sdb] (y/n)? n
> >> r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && 
> >> sudo sfdisk -L /dev/sdb
> >> /dev/sdb: No medium found
> >>
> >> sfdisk: cannot open /dev/sdb read-write
> >
> >  That's pretty convincing to me; anything relevant in dmesg?
> >
> >  We could do something like the attached shell script; would you mind
> >  running it to confirm this works without removing/reinserting the MMC?
> >  I'm curious to see how much time your drive needs to come back.
> 
> I'm scanning all 7 cards I have with the script wait_device, each card
> with 10 iterations of the test.
> 
> 1) Transend 4GB SD
> 2) SanDisk 2GB SD
> 3) KingMax MMC Mobile 2GB
> 
> All above 3 cards passed the test with giving "Could list partitions
> after 0 seconds!"
> 
> 4) SanDisk 4GB SD
> 5) SanDisk 4GB SD
> 6) SanDisk 4GB SD
> 7) SanDisk 4GB SD
> 
> All above 4 cards failed with giving "Giving up after 30 seconds
> failing to list partitions".  The interesting thing is it does not
> always fail from the beginning.  Some cards can even pass the test for
> 4~5 iterations, and then start failing.  If it starts failing, it
> always fails until I remove the card and replug it.
> 
> Here are two more tests I will do.
> 
> * With adding two sleep(5) in partitions.py that Zygmunt suggests, I
> will run l-m-c on the failing card to see if it can get through.

As I replied Zygmunt in another message, it still fails at 'mkimage:
Write error ...'.

> * With the original l-m-c installation, I will run l-m-c on one of
> card 1) ~ 3), probably 1) to see how l-m-c goes with the card passed
> wait_device.

It works good on card #1, and system boots on mx51evk board.

I also did the third test below suggested by Zygmunt and David on IRC.

* Create image_file and dd it to failing card

I did it on the failing card I used to report the issue originally,
and it works no problem, and system boots on mx51evk board.

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote:
> On Tue, Mar 08, 2011, Shawn Guo wrote:
> > I'm scanning all 7 cards I have with the script wait_device, each card
> > with 10 iterations of the test.
> > 
> > 1) Transend 4GB SD
> > 2) SanDisk 2GB SD
> > 3) KingMax MMC Mobile 2GB
> > 
> > All above 3 cards passed the test with giving "Could list partitions
> > after 0 seconds!"
> > 
> > 4) SanDisk 4GB SD
> > 5) SanDisk 4GB SD
> > 6) SanDisk 4GB SD
> > 7) SanDisk 4GB SD
> > 
> > All above 4 cards failed with giving "Giving up after 30 seconds
> > failing to list partitions".  The interesting thing is it does not
> > always fail from the beginning.  Some cards can even pass the test for
> > 4~5 iterations, and then start failing.  If it starts failing, it
> > always fails until I remove the card and replug it.
> 
>  This is really valuable data; SanDisk 4 GB SDs seem to be a trend
>  above!  It would be interesting if you could borrow another USB reader
>  for some hours to run the tests on the same SD cards, but a different
>  adapter.
> 
Will do when I'm in office tomorrow.

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: problem with linaro-media-create

[Shawn Guo]

On Tue, Mar 08, 2011 at 05:39:27PM +0100, Loïc Minier wrote:
> On Wed, Mar 09, 2011, Shawn Guo wrote:
> > I just added this one, and it does not help.  The l-m-c still fails at
> > the last step.
> > mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
> 
>  This error sounded a bit weird; I checked the u-boot sources, and this
>  string is used in a bunch of places, but essentially it's either on
>  write() or on close() that this fails.  I bet it's on write() as I
>  don't see close() failing without an useful errno, but I could imagine
>  the write tests failing:
> if (write(ifd, tparams->hdr, tparams->header_size)
> != tparams->header_size) {
> fprintf (stderr, "%s: Write error on %s: %s\n",
> params.cmdname, params.imagefile, strerror(errno));
>  notably if this is a partial write.
> 
>  We could change mkimage's write()s to actually account for the number
>  of bytes written rather than just failing when not all bytes were
>  written.
> 
>  Could you log a bug on the u-boot package on that one?  Or rather,
>  could you check before hand where your mkimage comes from?
> dpkg -S `which mkimage`
> 
> apt-cache policy name-of-the-package-returned-above
> 
$ apt-cache policy uboot-mkimage
uboot-mkimage:
  Installed: 0.4build1
  Candidate: 0.4build1
  Version table:
 *** 0.4build1 0
500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
100 /var/lib/dpkg/status

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Packaging Django applications and projects

[Zygmunt Krynicki]

W dniu 08.03.2011 18:10, Paul Wise pisze:

On Tue, Mar 8, 2011 at 9:50 PM, Zygmunt Krynickiu  wrote:


I'd like to define and document the recommended best practice of packaging
Django 1.0+ (and especially 1.3) web applications and projects for Debian. I
started this on the Debian wiki at
http://wiki.debian.org/DjangoPackagingDraft


Some things I (as a sysadmin user of Debian) would like to suggest for
all web apps, django based or not:

Use debconf to ask if the sysadmin wants to setup a site and then ask
for enough detail to do so. The package should ship a script that can
be called either manually by the sysadmin or automatically by the
maintainer scripts (using debconf answers) to setup a site or a
sub-path of a site.


The current web apps policy recommends [1] that by default the 
application should be accessible at http://SERVER/PACKAGE and I 
understand that decision (it should be possible to install all the web 
apps without conflicts).


The problem of how to do that generally is still valid (there are a lot 
of web servers to support potentially). I would start with an initial 
set that must support apache2 with mod_wsgi. In the future we can offer 
support for additional web servers.


Ideally this might work with some abstraction layer such as 
wwwconfig-common. Web applications could drop a file in 
/usr/share/wwwconfig-common/webapps.d/PACKAGE. Then if the administrator 
wants to reconfigure the "webapps" running on his server all he needs to 
do is edit something like /etc/webapps-common/webapps.conf and 
dpkg-reconfigure webapps-common.


Each application would only need to declare a few pieces:
 - stuff to serve statically (either as DOMAIN or URL-PREFIX)
 - wsgi file
 - name

For example, as JSON:

{
  "name": "django-hello",
  "static-content": [
{
  "pathname": "/var/lib/django-hello/static",
  "url_prefix": "static/",
  "domain_prefix": "static.",
  "description": "Static resources used by django-hello"
   },
   {
  "pathname": "/var/lib/django-hello/media",
  "url_prefix": "media/",
  "domain_prefix": "media."
  "description": "User submitted resources used by django-hello"
   }
 ],
 "wsgi": "/var/lib/django-hello/django.wsgi"
}


The www-common middleware would then store a record for each 
application. This record would contain:

 - enabled or disabled status
 - custom sub-URL if desired
 - custom DOMAIN if desired

Again, as JSON:

{
  "name": "django-hello",
  "custom_url": false,
  "custom_domain": false,
  "enabled": true
}

This would serve it as http://SERVER/django-hello/

Another example:

{
  "name": "django-hello",
  "custom_url": "/",
  "custom_domain": "hello.example.org",
  "enabled": true
}

This would serve it as http://hello.example.org/



All combinations of those two options would be supported. Sub URL could 
be set to / to mark a single application as main. A custom DOMAIN would 
limit such entries to the specified virtual host.


The glue code would then read the database of web applications, read the 
configuration of each web application and regenerate the 
webserver-specific configuration files.



Database (with South etc) and configuration upgrades (with
Config::Model or similar) are great, please do them as automatically
as possible after confirmation using debconf and or provide scripts
for the sysadmin to do them.


South support is rather easy. I still need to check what should happen 
in the downgrade use case and where exactly to store a backup of the 
database but in general it should be possible to support this correctly.


Configuration upgrade is more difficult as it really depends on what the 
maintainers of a web application desire to expose as configuration and 
what is merely an implementation detail that should not be configurable 
by the system administrator. I agree that supporting this is important 
(and especially supporting upgrades that don't break things). I tend to 
lean to a recommendation that application settings are handled 
explicitly by particular web application. That is: a web application 
should define a configuration file with all the things it publicly 
supports. IMHO this would be usually limited to email settings (do we 
have webapps-email-common?), database settings (dbconfig-common), 
administrator name, pathname of the "storage area" for user content. The 
rest should be implementation detail. We can have a django module for 
supporting such configuration system. It would have the advantage of not 
requiring code changes (the way django currently requires) and could be 
a healthy thing for the wider django community in general.


I'm a little worried about upgrade verbosity. In particular, I would 
like to allow silent (unattended) upgrades if possible. I think with 
proper debconf settings it's possible to ask the question "do you want 
to upgrade database schema to version $FOO" with "yes, I do" being the 
silent default. The issue here is that unless you upgrade you cannot 
rea

Re: problem with linaro-media-create

[Loïc Minier]

On Wed, Mar 09, 2011, Shawn Guo wrote:
> $ apt-cache policy uboot-mkimage
> uboot-mkimage:
>   Installed: 0.4build1
>   Candidate: 0.4build1
>   Version table:
>  *** 0.4build1 0
> 500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
> 100 /var/lib/dpkg/status

 Ok; natty has a more recent version built from u-boot upstream in the
 u-boot-tools package (superseding uboot-mkimage which was a fork); mind
 trying that out?

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Hans Verkuil]

On Tuesday, March 08, 2011 15:01:10 Andy Walls wrote:
> On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
> > Hi all,
> > 
> > We had a discussion yesterday regarding ways in which linaro can assist
> > V4L2 development. One topic was that of sorting out memory providers like
> > GEM and HWMEM.
> > 
> > Today I learned of yet another one: UMP from ARM.
> > 
> > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/
> > 
> > This is getting out of hand. I think that organizing a meeting to solve this
> > mess should be on the top of the list. Companies keep on solving the same
> > problem time and again and since none of it enters the mainline kernel any
> > driver using it is also impossible to upstream.
> > 
> > All these memory-related modules have the same purpose: make it possible to
> > allocate/reserve large amounts of memory and share it between different
> > subsystems (primarily framebuffer, GPU and V4L).
> 
> I'm not sure that's the entire story regarding what the current
> allocators for GPU do.  TTM and GEM create in kernel objects that can be
> passed between applications.  TTM apparently has handling for VRAM
> (video RAM).  GEM uses anonymous userspace memory that can be swapped
> out.
> 
> TTM:
> http://lwn.net/Articles/257417/
> http://www.x.org/wiki/ttm
> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=mm.pdf
> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=xdevconf2006.pdf
> 
> GEM:
> http://lwn.net/Articles/283798/
> 
> GEM vs. TTM:
> http://lwn.net/Articles/283793/
> 
> 
> The current TTM and GEM allocators appear to have API and buffer
> processing and management functions tied in with memory allocation.
> 
> TTM has fences for event notification of buffer processing completion.
> (maybe something v4l2 can do with v4l2_events?)
> 
> GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem
> to mem API?)
> 
> 
> Thanks to the good work of developers on the LMML in the past year or
> two, V4L2 has separated out some of that functionality from video buffer
> allocation: 
> 
>   video buffer queue management and userspace access (videobuf2)
>   memory to memory buffer transformation/movement (m2m)
>   event notification (VIDIOC_SUBSCRIBE_EVENT)
> 
>   http://lwn.net/Articles/389081/
>   http://lwn.net/Articles/420512/
> 
> 
> > It really shouldn't be that hard to get everyone involved together and 
> > settle
> > on a single solution (either based on an existing proposal or create a 'the
> > best of' vendor-neutral solution).
> 
> 
> "Single" might be making the problem impossibly hard to solve well.
> One-size-fits-all solutions have a tendency to fall short on meeting
> someone's critical requirement.  I will agree that "less than n", for
> some small n, is certainly desirable.

Actually, I think we really need one solution. I don't see how you can have
it any other way without requiring e.g. gstreamer to support multiple
'solutions'.

> The memory allocators and managers are ideally satisfying the
> requirements imposed by device hardware, what userspace applications are
> expected to do with the buffers, and system performance.  (And maybe the
> platform architecture, I/O bus, and dedicated video memory?)
> 

We discussed this before at the V4L2 brainstorm meeting in Oslo. The idea
was to have opaque buffer IDs (more like cookies) that both kernel and
userspace can use. You have some standard operations you can do with that
and tied to the buffer is the knowledge (probably a set of function pointers
in practice) of how to do each operation. So a buffer referring to video
memory might have different code to e.g. obtain the virtual address compared
to a buffer residing in regular memory.

This way you would hide all these details while still have enough flexibility.
It also allows you to support 'hidden' memory. It is my understanding that on
some platforms (particular those used for set-top boxes) the video buffers are
on memory that is not accessible from the CPU (rights management related). But
apparently you still have to be able to refer to it. I may be wrong, it's
something I was told.

> 
> 
> > I am currently aware of the following solutions floating around the net
> > that all solve different parts of the problem:
> > 
> > In the kernel: GEM and TTM.
> > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
> 
> Prior to a meeting one would probably want to capture for each
> allocator:
> 
> 1. What are the attributes of the memory allocated by this allocator?
> 
> 2. For what domain was this allocator designed: GPU, video capture,
> video decoder, etc.
> 
> 3. How are applications expected to use objects from this allocator?
> 
> 4. What are the estimated sizes and lifetimes of objects that would be
> allocated this allocator?
> 
> 5. Beyond memory allocation, what other functionality is built into this
> alloc

Re: Packaging Django applications and projects

[Paul Wise]

On Tue, Mar 8, 2011 at 9:50 PM, Zygmunt Krynickiu  wrote:

> I'd like to define and document the recommended best practice of packaging
> Django 1.0+ (and especially 1.3) web applications and projects for Debian. I
> started this on the Debian wiki at
> http://wiki.debian.org/DjangoPackagingDraft

Some things I (as a sysadmin user of Debian) would like to suggest for
all web apps, django based or not:

Use debconf to ask if the sysadmin wants to setup a site and then ask
for enough detail to do so. The package should ship a script that can
be called either manually by the sysadmin or automatically by the
maintainer scripts (using debconf answers) to setup a site or a
sub-path of a site.

Database (with South etc) and configuration upgrades (with
Config::Model or similar) are great, please do them as automatically
as possible after confirmation using debconf and or provide scripts
for the sysadmin to do them.

Data: I like to differentiate between data supporting the package and
data that belongs to the sysadmin/site. IMO the former belongs in /var
somewhere and the latter at a path chosen by the sysadmin. I don't
think this is gotten right by much software, including by all database
packages.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Jonathan Corbet]

On Tue, 8 Mar 2011 09:13:59 +0100
Hans Verkuil  wrote:

> All these memory-related modules have the same purpose: make it possible to
> allocate/reserve large amounts of memory and share it between different
> subsystems (primarily framebuffer, GPU and V4L).
> 
> It really shouldn't be that hard to get everyone involved together and settle
> on a single solution (either based on an existing proposal or create a 'the
> best of' vendor-neutral solution).

There is a memory management summit at the LF Collaboration Summit next
month.  Perhaps this would be a good topic to raise there?  I've added
Hugh to the Cc list in case he has any thoughts on the matter - and
besides, he doesn't have enough to do...:)

jon

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Laurent Pinchart]

Hi Andy,

On Tuesday 08 March 2011 20:12:45 Andy Walls wrote:
> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
> 
> [snip]
> 
> > > > It really shouldn't be that hard to get everyone involved together
> > > > and settle on a single solution (either based on an existing
> > > > proposal or create a 'the best of' vendor-neutral solution).
> > > 
> > > "Single" might be making the problem impossibly hard to solve well.
> > > One-size-fits-all solutions have a tendency to fall short on meeting
> > > someone's critical requirement.  I will agree that "less than n", for
> > > some small n, is certainly desirable.
> > > 
> > > The memory allocators and managers are ideally satisfying the
> > > requirements imposed by device hardware, what userspace applications
> > > are expected to do with the buffers, and system performance.  (And
> > > maybe the platform architecture, I/O bus, and dedicated video memory?)
> > 
> > In the embedded world, a very common use case is to capture video data
> > from an ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, ...)
> > and display it on the GPU (OpenGL/ES). We need to be able to share a
> > data buffer between the ISP and the DSP, and another buffer between the
> > DSP and the GPU. If processing is not required, sharing a data buffer
> > between the ISP and the GPU is required. Achieving zero-copy requires a
> > single memory management solution used by the ISP, the DSP and the GPU.
> 
> Ah.  I guess I misunderstood what was meant by "memory provider" to some
> extent.
> 
> So what I read is a common way of providing in kernel persistent buffers
> (buffer objects? buffer entities?) for drivers and userspace
> applications to pass around by reference (no copies).  Userspace may or
> may not want to see the contents of the buffer objects.

Exactly. How that memory is allocated in irrelevant here, and we can have 
several different allocators as long as the buffer objects can be managed 
through a single API. That API will probably have to expose buffer properties 
related to allocation, in order for all components in the system to verify 
that the buffers are suitable for their needs, but the allocation process 
itself is irrelevant.

> So I understand now why a single solution is desirable.

-- 
Regards,

Laurent Pinchart

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Andy Walls]

Hi Hans,

On Tue, 2011-03-08 at 18:23 +0100, Hans Verkuil wrote:

> > 
> > "Single" might be making the problem impossibly hard to solve well.
> > One-size-fits-all solutions have a tendency to fall short on meeting
> > someone's critical requirement.  I will agree that "less than n", for
> > some small n, is certainly desirable.
> 
> Actually, I think we really need one solution. I don't see how you can have
> it any other way without requiring e.g. gstreamer to support multiple
> 'solutions'.

Thanks.  Laurent's explanation sorted that out for me.


> > The memory allocators and managers are ideally satisfying the
> > requirements imposed by device hardware, what userspace applications are
> > expected to do with the buffers, and system performance.  (And maybe the
> > platform architecture, I/O bus, and dedicated video memory?)
> > 
> 
> We discussed this before at the V4L2 brainstorm meeting in Oslo. The idea
> was to have opaque buffer IDs (more like cookies) that both kernel and
> userspace can use.

Sounds like System V Shared Memory IPC.  It may be worth looking at the
issues one can get with SYS V Shared Memory: obtaining the resource
identifier, exhaustion of global resources, etc.


>  You have some standard operations you can do with that
> and tied to the buffer is the knowledge (probably a set of function pointers
> in practice) of how to do each operation. So a buffer referring to video
> memory might have different code to e.g. obtain the virtual address compared
> to a buffer residing in regular memory.

That is interesting.


> 
> This way you would hide all these details while still have enough flexibility.
> It also allows you to support 'hidden' memory. It is my understanding that on
> some platforms (particular those used for set-top boxes) the video buffers are
> on memory that is not accessible from the CPU (rights management related). But
> apparently you still have to be able to refer to it.

I can see that's something one would need to do with key material stored
inside any decent cryptographic engine (key material should not be
extractable from the engine, ever).  I guess it's needed for the video
ciphertext and video plaintext in STB DRM to impede someone with
physical access to the device from doing differential analysis on the
buffers to extract the key.


>  I may be wrong, it's
> something I was told.
> 
> > 
> > 
> > > I am currently aware of the following solutions floating around the net
> > > that all solve different parts of the problem:
> > > 
> > > In the kernel: GEM and TTM.
> > > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
> > 
> > Prior to a meeting one would probably want to capture for each
> > allocator:
> > 
> > 1. What are the attributes of the memory allocated by this allocator?
> > 
> > 2. For what domain was this allocator designed: GPU, video capture,
> > video decoder, etc.
> > 
> > 3. How are applications expected to use objects from this allocator?
> > 
> > 4. What are the estimated sizes and lifetimes of objects that would be
> > allocated this allocator?
> > 
> > 5. Beyond memory allocation, what other functionality is built into this
> > allocator: buffer queue management, event notification, etc.?
> > 
> > 6. Of the requirements that this allocator satisfies, what are the
> > performance critical requirements?
> > 
> > 
> > Maybe there are better question to ask.
> 
> It's a big topic with many competing and overlapping solutions. That really
> needs to change.

It also seems that the existing providers have different objectives.  

>From what I read, GEM could swap out buffers under system low memory
conditions, so the system still runs at the expense of video
performance.

IIRC, TTM locks pages into memory.

With the per buffer type operations you mentioned, I guess the
requirements that drive those sort of conflicting design decisions can
be satisfied by one mechanism?

Regards,
Andy



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Yet another memory provider: can linaro organize a meeting?

[Andy Walls]

Hi LAurent,

On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
> Hi Andy,

[snip]

> > > It really shouldn't be that hard to get everyone involved together and
> > > settle on a single solution (either based on an existing proposal or
> > > create a 'the best of' vendor-neutral solution).
> > 
> > "Single" might be making the problem impossibly hard to solve well.
> > One-size-fits-all solutions have a tendency to fall short on meeting
> > someone's critical requirement.  I will agree that "less than n", for
> > some small n, is certainly desirable.
> > 
> > The memory allocators and managers are ideally satisfying the
> > requirements imposed by device hardware, what userspace applications are
> > expected to do with the buffers, and system performance.  (And maybe the
> > platform architecture, I/O bus, and dedicated video memory?)
> 
> In the embedded world, a very common use case is to capture video data from 
> an 
> ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, ...) and display 
> it 
> on the GPU (OpenGL/ES). We need to be able to share a data buffer between the 
> ISP and the DSP, and another buffer between the DSP and the GPU. If 
> processing 
> is not required, sharing a data buffer between the ISP and the GPU is 
> required. Achieving zero-copy requires a single memory management solution 
> used by the ISP, the DSP and the GPU.

Ah.  I guess I misunderstood what was meant by "memory provider" to some
extent.  

So what I read is a common way of providing in kernel persistent buffers
(buffer objects? buffer entities?) for drivers and userspace
applications to pass around by reference (no copies).  Userspace may or
may not want to see the contents of the buffer objects.

So I understand now why a single solution is desirable.

Regards,
Andy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 05/12] Add blank Kconfig.distro fragment file

[John Stultz]

Here is the intial Kconfig.distro fragment file

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 Kconfig.distro |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)
 create mode 100644 Kconfig.distro

diff --git a/Kconfig.distro b/Kconfig.distro
new file mode 100644
index 000..17ea21c
--- /dev/null
+++ b/Kconfig.distro
@@ -0,0 +1,20 @@
+# This is the Kconfig.distro fragment.
+# It should be edited to include kconfig fragments
+# that is included by arch specific defconfigs to 
+# set generic CONFIG policy.
+#
+# For instance, this would be the approprate place
+# for selecting network options, common driver modules,
+# filesystems or kernel debugging options.
+#
+# Example:
+#
+#  config generateconfig_DISTRO_YES
+#  def_bool y
+#
+#  select AUDIT
+#  select NAMESPACES
+#  select EXT3_FS
+#
+#  config CUSE
+#  default m
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 07/12] Initial imx51 defconfig fragment

[John Stultz]

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 arch/arm/configs/Kconfig.imx51 |   84 
 1 files changed, 84 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/configs/Kconfig.imx51

diff --git a/arch/arm/configs/Kconfig.imx51 b/arch/arm/configs/Kconfig.imx51
new file mode 100644
index 000..512c9d5
--- /dev/null
+++ b/arch/arm/configs/Kconfig.imx51
@@ -0,0 +1,84 @@
+config generateconfig_MX51_YES
+   def_bool y
+   select ARM
+   select ARCH_MXC
+   select ARCH_MX5
+   select ARCH_MX51
+   select SOC_IMX51
+   select MACH_MX51_BABBAGE
+   select CPU_FREQ_IMX
+   select AEABI
+   select VFP
+   select NEON
+
+
+   select NET
+   select NET_ETHERNET
+   select NETDEVICES
+   select MMC
+   select GPIOLIB
+   select RTC_CLASS
+   select I2C
+   select USB
+   select EXPERIMENTAL
+   
+   select CPU_FREQ
+   select CPU_FREQ_STAT_DETAILS
+   select CPU_FREQ_GOV_POWERSAVE
+   select CPU_FREQ_GOV_USERSPACE
+   select CPU_FREQ_GOV_ONDEMAND
+   select CPU_FREQ_GOV_CONSERVATIVE
+
+   select USB_EHCI_HCD
+   select USB_EHCI_ROOT_HUB_TT
+
+   select PHYLIB
+   select USB_EHCI_MXC
+   select FEC
+   select SERIAL_IMX
+   select SERIAL_IMX_CONSOLE
+   select MMC_SDHCI
+   select I2C
+   select GPIO_SYSFS
+   select MMC_SDHCI_PLTFM
+   select MMC_SDHCI_ESDHC_IMX
+
+   select GPIO_PCA953X
+   select GPIO_PCA953X_IRQ
+   select GPIO_TWL4030
+
+   select FIXED_PHY
+   select TWL4030_CORE
+   select TWL4030_POWER
+
+   select DEBUG_KERNEL
+   select LATENCYTOP
+
+   select VT_HW_CONSOLE_BINDING
+
+   select RTC_DRV_M41T80_WDT
+   select RTC_DRV_TWL4030
+   select RTC_INTF_DEV_UIE_EMUL
+   select RTC_DRV_M41T80
+
+
+config MXC_DEBUG_BOARD
+   default n
+
+config DEFAULT_MMAP_MIN_ADDR
+   default 32768
+config LOG_BUF_SHIFT
+   default 18
+
+config MII
+   default m
+config LEDS_LP5521
+   default m
+config LEDS_LP5523
+   default m
+
+
+
+source "Kconfig.distro"
+
+source "arch/arm/Kconfig"
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 03/12] kbuild: Use kconfig defaults as defconfig starting point

[John Stultz]

Instead of using all no as the starting point for the defconfig
use the kconfig defaults.

CC: Grant Likely 
CC: Stephen Rothwell 
CC: linux-kbu...@vger.kernel.org,
CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 scripts/kconfig/Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index f1ef231..320ac75 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -129,7 +129,7 @@ $(old_defconfigs): %_defconfig: $(obj)/conf
$(Q)$< --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
 
 $(defconfigs): %_defconfig: $(obj)/conf
-   $(Q)$< -n arch/$(SRCARCH)/configs/Kconfig.$*
+   $(Q)$< --defconfig=/dev/null arch/$(SRCARCH)/configs/Kconfig.$*
 
 # Help text used by make help
 help:
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 04/12] kbuild: Avoid kconfig fragment defconfigs from having odd config order

[John Stultz]

Sort of a hack.

With the new kconfig framents, some config items may be defined
in a different order then usual. To preserve the normal order,
re-run sildentoldconfig after running defconfig.

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 scripts/kconfig/Makefile |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 320ac75..866dbca 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -130,6 +130,8 @@ $(old_defconfigs): %_defconfig: $(obj)/conf
 
 $(defconfigs): %_defconfig: $(obj)/conf
$(Q)$< --defconfig=/dev/null arch/$(SRCARCH)/configs/Kconfig.$*
+# use oldconfig reorder option properly
+   $(Q)$< --silentoldconfig $(Kconfig) > /dev/null
 
 # Help text used by make help
 help:
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 01/12] kbuild: Allow configs from choice blocks to be selected.

[John Stultz]

In looking at trying to replace defconfigs with kconfig fragments,
one limitation identified is that config items in choice blocks
cannot be selected by other config options.

One way to doge this would be to create non-visible meta options
that change the choice block's default, but that would require
additional meta-configs per-choice config, plus a conditional
default per meta-config. That just seemed too ugly.

So I looked into how to allow the choice default to be overrided
by a select statment, and the following patch is the result.

I'm very new to kconfig code, so I expect that my changes are
probably broken in some subtle way, but in my testing it seems
to work. The select only chagnes the default, which can be overrided
by the user via the menu. This allows kconfig fragments to work
for make defconfig, while not restricting user customization.

Thoughts and feedback (or alternate approaches) would be appreciated.

thanks
-john

CC: Grant Likely 
CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 scripts/kconfig/symbol.c |   15 +--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index af6e9f3..c4f3e49 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -203,8 +203,6 @@ static void sym_calc_visibility(struct symbol *sym)
sym->visible = tri;
sym_set_changed(sym);
}
-   if (sym_is_choice_value(sym))
-   return;
/* defaulting to "yes" if no explicit "depends on" are given */
tri = yes;
if (sym->dir_dep.expr)
@@ -235,9 +233,22 @@ static void sym_calc_visibility(struct symbol *sym)
 struct symbol *sym_choice_default(struct symbol *sym)
 {
struct symbol *def_sym;
+   struct symbol *ret = NULL;
struct property *prop;
struct expr *e;
 
+   /* check to see if any are selected */
+   prop = sym_get_choice_prop(sym);
+   expr_list_for_each_sym(prop->expr, e, def_sym)
+   if (def_sym->rev_dep.tri != no) {
+   if (ret)
+   printf("Error! Conflicting selects! %s\n", 
def_sym->name);
+   else
+   ret = def_sym;
+   }
+   if (ret)
+   return ret;
+
/* any of the defaults visible? */
for_all_defaults(sym, prop) {
prop->visible.tri = expr_calc_value(prop->visible.expr);
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 06/12] Initial omap3 Kconfig fragment

[John Stultz]

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 arch/arm/configs/Kconfig.omap3 |  141 
 1 files changed, 141 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/configs/Kconfig.omap3

diff --git a/arch/arm/configs/Kconfig.omap3 b/arch/arm/configs/Kconfig.omap3
new file mode 100644
index 000..82847cf
--- /dev/null
+++ b/arch/arm/configs/Kconfig.omap3
@@ -0,0 +1,141 @@
+config generateconfig_OMAP3_YES
+   def_bool y
+   
+   
+   select ARM
+   select ARCH_OMAP
+   select ARCH_OMAP3
+   select OMAP_RESET_CLOCKS
+
+   select SMP
+   select EXPERIMENTAL
+
+   select OMAP3_EMU
+
+   select ARM_THUMBEE
+   select ARM_ERRATA_430973
+
+   select CPU_FREQ
+   select CPU_FREQ_STAT_DETAILS
+   select CPU_FREQ_GOV_POWERSAVE
+   select CPU_FREQ_GOV_USERSPACE
+   select CPU_FREQ_GOV_ONDEMAND
+   select CPU_FREQ_GOV_CONSERVATIVE
+   select CPU_IDLE
+
+   select TI_DAVINCI_EMAC
+   select TI_DAVINCI_MDIO
+   select TI_DAVINCI_CPDMA
+
+   select USB_EHCI_HCD
+   select USB_EHCI_ROOT_HUB_TT
+
+   select NET
+   select NETDEVICES
+   select NET_ETHERNET
+
+   select SPI
+   select GPIOLIB
+   select SYSFS
+   
+   select SND
+   select SOUND
+   select SND_OMAP
+   select SND_SOC
+   
+   select USB_NET
+   select USB_USBNET
+   select USB
+   
+   select PARPORT
+
+   select FB
+   
+   select TWL4030_CORE
+   
+   select RTC_CLASS
+   select I2C
+   select RTC_DRV_M41T80
+
+   select MTD
+   select MTD_NAND
+   select MTD_ONENAND
+   
+   select MMC
+   
+   select LEDS
+
+   select FPE_NWFPE
+
+   select MTD_NAND_OMAP2
+   select MTD_NAND_OMAP_PREFETCH_DMA
+   select MTD_ONENAND_VERIFY_WRITE
+   select MTD_ONENAND_2X_PROGRAM
+
+   select PARPORT_1284
+
+   select MMC_OMAP_HS
+   select BACKLIGHT_LCD_SUPPORT
+   select OABI_COMPAT
+
+   select USB_NET_SMSC95XX
+
+   select GPIO_SYSFS
+   select SND_OMAP_SOC
+   
+   select OMAP2_DSS
+   select OMAP2_DSS_SDI
+
+   select FB_OMAP2
+   select PANEL_GENERIC_DPI
+   select PANEL_SHARP_LS037V7DW01
+   select PANEL_TPO_TD043MTEA1
+
+   select GPIO_TWL4030
+   select TWL4030_CORE
+   select REGULATOR_TWL4030
+   select TWL4030_POWER
+   select GPIO_PCA953X
+   select GPIO_PCA953X_IRQ
+
+   select SND_OMAP_SOC_MCBSP
+   select SND_OMAP_SOC_OVERO
+   select SND_OMAP_SOC_OMAP3EVM
+
+   select SND_OMAP_SOC_SDP3430
+   select SND_OMAP_SOC_SDP4430
+   select SND_OMAP_SOC_OMAP3_PANDORA
+   select SND_OMAP_SOC_OMAP3_BEAGLE
+   select SND_OMAP_SOC_ZOOM2
+   select SND_OMAP_SOC_IGEP0020
+
+   select INTF_ALARM
+   select RTC_DRV_TWL4030
+   select RTC_DRV_M41T80_WDT
+
+
+
+# Enabling OMAP2 makes beagle boards not boot
+config ARCH_OMAP2
+   default n
+
+config SWP_EMULATE
+   default n
+
+config MACH_DEVKIT8000
+   default n
+
+config MACH_CM_T35
+   default n
+
+config USB_DEVICE_CLASS
+   default n
+
+config OMAP2_VRAM_SIZE
+   default 6
+
+
+
+source "Kconfig.distro"
+
+source "arch/arm/Kconfig"
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 02/12] kbuild: Enable building defconfigs from Kconfig files

[John Stultz]

From: Stephen Rothwell 

After this change, doing a "make xxx_defconfig" will check first for
a file called arch//configs/Kconfig.xxx and use that to generate
the .config (effectively starting from an allnoconfig).  If that file
doesn't exist, it will use arch//configs/xxx_defconfig as now.

CC: Grant Likely 
CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: Stephen Rothwell 
Signed-off-by: John Stultz 
---
 scripts/kconfig/Makefile |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 368ae30..f1ef231 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -116,9 +116,21 @@ else
$(Q)$< --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) 
$(Kconfig)
 endif
 
-%_defconfig: $(obj)/conf
+configs_dir := $(srctree)/arch/$(SRCARCH)/configs
+# We check a level of sub directories because arch/powerpc
+# has its defconfig files arranged that way
+old_defconfigs := $(patsubst $(configs_dir)/%,%,\
+   $(wildcard $(configs_dir)/*_defconfig) \
+   $(wildcard $(configs_dir)/*/*_defconfig))
+defconfigs := $(patsubst $(configs_dir)/Kconfig.%,%_defconfig,\
+   $(wildcard $(configs_dir)/Kconfig.*))
+
+$(old_defconfigs): %_defconfig: $(obj)/conf
$(Q)$< --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
 
+$(defconfigs): %_defconfig: $(obj)/conf
+   $(Q)$< -n arch/$(SRCARCH)/configs/Kconfig.$*
+
 # Help text used by make help
 help:
@echo  '  config  - Update current config utilising a 
line-oriented program'
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 00/12][RFC] Intial Kconfig Fragment Demo

[John Stultz]

This patch set provides enough to demo how the Kconfig fragment
based defconfigs could be used to simplify both generating and
managing the configs used to build Linaro kernels.

This is for the kernel config managment tool and dependent bluprints:
https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-config-management-tool


The basic idea is to use a Kconfig fragment to generate the 
per-board defconfigs. The Kconfig fragments contain a meta-option
that defaults to yes, which then selects the needed config values
to enable a system.

This has been proposed by others, and we're using Stephen
Rothwell's initial patch to start things off.

Once we have the infrasturcture to use Kconfig fragments for
defconfigs we had to overcome some limitations:
1) We cannot select items from a choice block
2) We need a way to select for values and modules.

Limitation #1 is resolved by a patch to the kbuild system I 
made.

Limitation #2 is unsolved, but Jason Hui found a workaround that
is sufficient. Basically we can just redefine the default with a 
short declaration: 
config VAL
default 256
or 
config VAL
default m


With these two solutions, I went forward generating basic Kconfig
fragments for omap3, imx51 and vexpress. 

Getting per-board defconfigs is only of limited value, because 
we also want to be able to have a common policy settings for
Linaro kernels. Many distros run into this problem, and use 
.config fragments which are then assembled at package build 
time. 

My solution is to have a Kconfig.distro file, which is patched
with Distro specific policy config, such as which filesystems
should be enabled, networking policy, debug options, or periphrial 
driver modules that should be enabled. Basically anything that
isn't hardware specific (by that I mean, part of the architecture
or wired on the board).

>From there, I add in as much of the generic Linaro config policy
as I could, utilizing the config files that were used to build
the omap3, imx51 and vexpress hardware packs.

Since the Linaro config polciy is not unified at this point
(in other words, each board has totally different set of generic
policy options configured). I added the per target differences
into the board kconfig fragments.

Ideally we can review and settle down on specific linaro config
policy and this generic per-board stuff can go away.

These are initial and rough patches, but are the result of lots
of painful manual labor to match the Linaro .configs as closely
as possible.

There are a few remaining issues, but these can probably be
worked around:
1) Omap has a strange tristate choice option for the usb gadget
options. So you can only pick one, or you can pick multiple items
as modules. My choice selection patch doesn't yet address this.
I need to see how common this style of choice is and see if we
can either just make it a non-choice options block or if other
fixes are needed.

2) Not having a module selction is a little painful, as the 
module "default m" entries are numerous and annoyingly separate
from the meta-config selects.

3) The Kconfig.distro file should be probably broken up into 
policy topics, like networking, filesystems, peripherials, etc.

4) The current board Kconfig fragments are named slightly
differently from the standard defconfigs to allow testing
with both. That will need to be fixed, and the old defconfigs
removed prior to submitting.

5) The igep, overo, and panda configs all use the same omap3
config according to the hwpacks. I'm not sure I believe that,
but went along with it to get this out the door.


Many thanks to Jason for his help figuring out an approach here.

Feedback and thoughts would be greatly appreciated.

thanks
-john


CC: Grant Likely 
CC: Jason Hui 
CC: patc...@linaro.org


John Stultz (11):
  kbuild: Allow configs from choice blocks to be selected.
  kbuild: Use kconfig defaults as defconfig starting point
  kbuild: Avoid kconfig fragment defconfigs from having odd config
order
  Add blank Kconfig.distro fragment file
  Initial omap3 Kconfig fragment
  Initial imx51 defconfig fragment
  Add initial vexpress defconfig fragment
  Add Linaro config policy to Kconfig.distro
  omap3 kconfig fragment changes to align with linaro build
  Update imx51 to better match linaro configs
  Update vexpress to be closer to linaro config

Stephen Rothwell (1):
  kbuild: Enable building defconfigs from Kconfig files

 Kconfig.distro | 1754 +
 arch/arm/configs/Kconfig.imx51 |  503 +
 arch/arm/configs/Kconfig.omap3 | 2430 
 arch/arm/configs/Kconfig.vexp  |  234 
 scripts/kconfig/Makefile   |   16 +-
 scripts/kconfig/symbol.c   |   15 +-
 6 files changed, 4949 insertions(+), 3 deletions(-)
 create mode 100644 Kconfig.distro
 create mode 100644 arch/arm/configs/Kconfig.imx51
 create mode 100644 arch/arm/configs/Kconfig.omap3
 create mode 1006

[PATCH 11/12] Update imx51 to better match linaro configs

[John Stultz]

Once we have settled on a proper common Linaro config policy,
this should be able to go away.

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 arch/arm/configs/Kconfig.imx51 |  423 +++-
 1 files changed, 421 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/Kconfig.imx51 b/arch/arm/configs/Kconfig.imx51
index 512c9d5..5f6e50e 100644
--- a/arch/arm/configs/Kconfig.imx51
+++ b/arch/arm/configs/Kconfig.imx51
@@ -11,6 +11,9 @@ config generateconfig_MX51_YES
select VFP
select NEON
 
+   select MACH_MX53_EVK
+   select MACH_MX53_SMD
+   select MACH_MX53_LOCO
 
select NET
select NET_ETHERNET
@@ -59,7 +62,6 @@ config generateconfig_MX51_YES
select RTC_DRV_M41T80_WDT
select RTC_DRV_TWL4030
select RTC_INTF_DEV_UIE_EMUL
-   select RTC_DRV_M41T80
 
 
 config MXC_DEBUG_BOARD
@@ -69,14 +71,431 @@ config DEFAULT_MMAP_MIN_ADDR
default 32768
 config LOG_BUF_SHIFT
default 18
-
+config CMDLINE
+   default "noinitrd console=ttymxc0,115200 root=/dev/nfs 
nfsroot=192.168.0.101:/shared/nfs ip=dhcp"
 config MII
default m
 config LEDS_LP5521
default m
 config LEDS_LP5523
default m
+config RTC_DRV_M41T80
+   default m
+
+
+# The following should be Kconfig.distro policy
+config generateconfig_SHOULD_BE_DISTROCONF_YES
+   def_bool y
+   select CC_OPTIMIZE_FOR_SIZE
+   select EMBEDDED
+   select RELAY
+   select MODVERSIONS
+   select MODULE_SRCVERSION_ALL
+
+   select KALLSYMS_ALL
+   select PREEMPT_VOLUNTARY
+
+   select TICK_ONESHOT
+   select NO_HZ
+   select HIGH_RES_TIMERS
+
+   select RD_BZIP2
+   select RD_LZMA
+   select RD_LZO
+
+   select PM
+   select PM_RUNTIME
+select PM_SLEEP
+select SUSPEND
+select SUSPEND_FREEZER
+select PM_OPS
+
+   select PM_DEBUG
+   select PM_TEST_SUSPEND
+
+   select USB_SUSPEND
+
+
+   select IP_PNP
+   select IP_PNP_DHCP
+   select IP_PNP_BOOTP
+
+   select DNS_RESOLVER
+
+
+   select CONNECTOR
+   select PROC_EVENTS
+
+   select BLK_DEV_LOOP
+
+   select HW_RANDOM
+
+
+   select I2C
+   select GPIOLIB
+
+   select MFD_TC6393XB
+   select MFD_ASIC3
+   select HTC_I2CPLD
+   select HTC_EGPIO
+   select MFD_88PM860X
+   select MFD_TMIO
+   select MFD_T7L66XB
+   select MFD_TC6387XB
+   select PMIC_DA903X
+   select PMIC_ADP5520
+   select MFD_MAX8925
+   select MFD_WM8350_I2C
+   select MFD_WM8994
+   select ABX500_CORE
+   select AB3100_CORE
+   select AB3550_CORE
+
+
+
+   select MDIO_GPIO
+   select MDIO_BITBANG
+
+   select MTD_PARTITIONS
+
+   select MMC_SDHCI
+
+   select SCSI_MULTI_LUN
+   select SCSI_CONSTANTS
+   select SCSI_LOGGING
+   select SCSI_SCAN_ASYNC
+
+   select MARVELL_PHY
+   select DAVICOM_PHY
+   select QSEMI_PHY
+   select LXT_PHY
+   select CICADA_PHY
+   select VITESSE_PHY
+   select SMSC_PHY
+   select BROADCOM_PHY
+   select ICPLUS_PHY
+   select REALTEK_PHY
+   select NATIONAL_PHY
+   select STE10XP
+   select LSI_ET1011C_PHY
+
+   select MOUSE_PS2_ELANTECH
+
+
+   select NEW_LEDS
+   select LEDS_CLASS
+   select LEDS_TRIGGERS
+
+   select EXT2_FS_XATTR
+   select EXT2_FS_POSIX_ACL
+   select EXT2_FS_SECURITY
+
+   select EXT3_DEFAULTS_TO_ORDERED
+   select EXT3_FS_XATTR
+   select EXT3_FS_POSIX_ACL
+   select EXT3_FS_SECURITY
+
+   select EXT4_FS_XATTR
+   select EXT4_FS_POSIX_ACL
+   select EXT4_FS_SECURITY
+
+   select AUTOFS4_FS
+   select FAT_FS
+   select VFAT_FS
+
+   select GFS2_FS_LOCKING_DLM
+
+
+   select QUOTA
+   select QUOTA_NETLINK_INTERFACE
+   select QUOTACTL
+   select FUSE_FS
+   select UDF_NLS
+
+   select DEBUG_FS
+   select ECRYPT_FS
+
+   select NFS_V3_ACL
+   select NFS_V4
+
+   select NLS_CODEPAGE_437
+   select NLS_ASCII
+   select NLS_UTF8
+
+   select SCHEDSTATS
+   select EARLY_PRINTK
+
+   select ENABLE_WARN_DEPRECATED
+   select ENABLE_MUST_CHECK
+   select DEBUG_MEMORY_INIT
 
+   select KEYS
+
+   select CRYPTO_DES
+   select CRYPTO_DEFLATE
+   select CRYPTO_LZO
+
+   select CRC_T10DIF
+
+config UTS_NS
+   default n
+config IPC_NS
+   default n
+config USER_NS
+   default n
+config PID_NS
+   default n
+config NET_NS
+   default n
+config SLUB_DEBUG
+   default n
+config LBDAF
+   default n
+config OABI_COMPAT
+   default n
+config IP_SCTP
+   default n
+config WIRELESS
+   default n
+config NETDEV_1000
+   default n
+config NETDEV_1
+   default n
+config WLAN
+   default n
+config LEGACY_PTYS
+   default n
+config INET_XFRM_MODE_TRANSPORT
+  

[PATCH 12/12] Update vexpress to be closer to linaro config

[John Stultz]

Once we have settled on a proper common Linaro config policy,
this should be able to go away.

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 arch/arm/configs/Kconfig.vexp |  195 +
 1 files changed, 195 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/Kconfig.vexp b/arch/arm/configs/Kconfig.vexp
index ddcfe5d..7522884 100644
--- a/arch/arm/configs/Kconfig.vexp
+++ b/arch/arm/configs/Kconfig.vexp
@@ -27,12 +27,207 @@ config generateconfig_VXPRESS_YES
select RTC_CLASS
 
 
+config CMDLINE
+   default "root=/dev/nfs nfsroot=10.1.69.3:/work/nfsroot ip=dhcp 
console=ttyAMA0 mem=128M"
 config DEFAULT_MMAP_MIN_ADDR
default 32768
 
 config LOG_BUF_SHIFT
default 14
 
+# The following should be Kconfig.distro policy
+config generateconfig_SHOULD_BE_DISTROCONF_YES
+   def_bool y
+
+   select IP_PNP
+   select IP_PNP_DHCP
+   select IP_PNP_BOOTP
+
+   select DEFAULT_DEADLINE
+   select PREEMPT_NONE
+   select NL80211_TESTMODE
+   select CFG80211_REG_DEBUG
+   select MAC80211_MESH
+   select MTD_CONCAT
+   select MTD_PARTITIONS
+   select MTD_CMDLINE_PARTS
+   select MTD_CFI
+   select MTD_GEN_PROBE
+   select MTD_CFI_INTELEXT
+   select MTD_CFI_AMDSTD
+   select MTD_CFI_UTIL
+   select MTD_ARM_INTEGRATOR
+   select MISC_DEVICES
+   select SCSI_PROC_FS
+   select ATA_SFF
+   select ATA_BMDMA
+   select MII
+   select PHYLIB
+   select SMC911X
+   select SMSC911X
+   select HOSTAP_FIRMWARE
+   select HOSTAP_FIRMWARE_NVRAM
+   select MOUSE_PS2
+   select SERIO_AMBAKMI
+   select SERIAL_AMBA_PL011
+   select SERIAL_AMBA_PL011_CONSOLE
+   select SERIAL_CORE
+   select SERIAL_CORE_CONSOLE
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select FB_ARMCLCD
+   select LOGO
+   select LOGO_LINUX_CLUT224
+   select SOUND_OSS_CORE
+   select SOUND_OSS_CORE_PRECLAIM
+   select SND_TIMER
+   select SND_PCM
+   select SND_OSSEMUL
+   select SND_MIXER_OSS
+   select SND_PCM_OSS
+   select SND_PCM_OSS_PLUGINS
+   select SND_VMASTER
+   select SND_AC97_CODEC
+   select SND_VMASTER
+   select SND_ARMAACI
+   select AC97_BUS
+   select USB_ANNOUNCE_NEW_DEVICES
+   select USB_MON
+   select USB_ISP1760_HCD
+   select MMC_ARMMMCI
+   select RTC_DRV_PL031
+   select FAT_FS
+   select VFAT_FS
+   select JFFS2_FS
+   select JFFS2_FS_WRITEBUFFER
+   select JFFS2_ZLIB
+   select JFFS2_RTIME
+   select CRAMFS
+   select NLS_CODEPAGE_437
+   select ENABLE_WARN_DEPRECATED
+   select ENABLE_MUST_CHECK
+   select ZLIB_DEFLATE
+
+   select CC_OPTIMIZE_FOR_SIZE
+   
+config LEGACY_PTY_COUNT
+   default 16
+
+config UEVENT_HELPER_PATH
+   default "/sbin/hotplug"
+
+config NLS_DEFAULT
+   default "iso8859-1"
+
+
+config IOSCHED_CFQ
+   default n
+config UTS_NS
+   default n
+config IPC_NS
+   default n
+config USER_NS
+   default n
+config PID_NS
+   default n
+config NET_NS
+   default n
+config NETDEV_1000
+   default n
+config NETDEV_1
+   default n
+config HWMON
+   default n
+config INET_LRO
+   default n
+config ATA_VERBOSE_ERROR
+   default n
+config SATA_PMP
+   default n
+config EXT3_DEFAULTS_TO_ORDERED
+   default n
+config EXT3_FS_XATTR
+   default n
+config EXT4_FS_XATTR
+   default n
+config FTRACE
+   default n
+config SCHED_DEBUG
+   default n
+config SND_DRIVERS
+   default n
+config MFD_SUPPORT
+   default n
+config HW_RANDOM
+   default n
+config LOGO_LINUX_MONO
+   default n
+config LOGO_LINUX_VGA16
+   default n
+config SERIO_SERPORT
+   default n
+config CRYPTO_ANSI_CPRNG
+   default n
+config CRYPTO_HW
+   default n
+config SUNRPC_GSS
+   default n
+config RPCSEC_GSS_KRB5
+   default n
+
+config ATA
+   default m
+config CFG80211
+   default m
+config MAC80211
+   default m
+config ISCSI_TCP
+   default m
+config LIBFC
+   default m
+config LIBFCOE
+   default m
+config SCSI_DEBUG
+   default m
+config INET6_XFRM_MODE_TRANSPORT
+   default m
+config INET6_XFRM_MODE_TUNNEL
+   default m
+config INET6_XFRM_MODE_BEET
+   default m
+config USB_STORAGE
+   default m
+config CRYPTO_ALGAPI
+   default m
+config CRYPTO_ALGAPI2
+   default m
+config CRYPTO_AEAD2
+   default m
+config CRYPTO_BLKCIPHER
+   default m
+config CRYPTO_BLKCIPHER2
+   default m
+config CRYPTO_HASH
+   default m
+config CRYPTO_HASH2
+   default m
+config CRYPTO_RNG2
+   default m
+config CRYPTO_PCOMP2
+   default m
+config CRYPTO_MANAGER
+   default m
+config CRYPTO_MANAGER2
+   default m
+config CRYPTO_WORKQUEUE
+   default m
+config CRY

[PATCH 08/12] Add initial vexpress defconfig fragment

[John Stultz]

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 arch/arm/configs/Kconfig.vexp |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/configs/Kconfig.vexp

diff --git a/arch/arm/configs/Kconfig.vexp b/arch/arm/configs/Kconfig.vexp
new file mode 100644
index 000..ddcfe5d
--- /dev/null
+++ b/arch/arm/configs/Kconfig.vexp
@@ -0,0 +1,39 @@
+config generateconfig_VXPRESS_YES
+   def_bool y
+   select ARM
+   select ARCH_VEXPRESS
+   select ARCH_VEXPRESS_CA9X4
+
+   select IKCONFIG
+   select IKCONFIG_PROC
+
+   select SWP_EMULATE
+   select SMP
+
+   select AEABI
+   select OABI_COMPAT
+   select HIGHMEM
+   select BOUNCE
+   
+   select VFP
+   select VFPv3
+
+   select MTD_ARM_INTEGRATOR
+
+   select EXPERIMENTAL
+   select MTD
+   select MTD_CFI
+   select SOUND
+   select RTC_CLASS
+
+
+config DEFAULT_MMAP_MIN_ADDR
+   default 32768
+
+config LOG_BUF_SHIFT
+   default 14
+
+
+source "Kconfig.distro"
+
+source "arch/arm/Kconfig"
-- 
1.7.3.2.146.gca209


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 09/12] Add Linaro config policy to Kconfig.distro

[John Stultz]

Here's the initial pass of the Linaro config policy for
Kconfig.distro

CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 Kconfig.distro | 1734 
 1 files changed, 1734 insertions(+), 0 deletions(-)

diff --git a/Kconfig.distro b/Kconfig.distro
index 17ea21c..bbcd122 100644
--- a/Kconfig.distro
+++ b/Kconfig.distro
@@ -18,3 +18,1737 @@
 #
 #  config CUSE
 #  default m
+
+config generateconfig_DISTRO_YES
+   def_bool y
+   
+   select EXPERIMENTAL
+   select SYSVIPC
+   select POSIX_MQUEUE
+   select AUDIT
+
+   select NAMESPACES
+
+
+   select PERF_EVENTS
+
+   select MODULES
+   select MODULE_UNLOAD
+   
+   select BLOCK
+   select BLK_DEV_RAM
+   select BLK_DEV_INITRD
+   select BLK_DEV
+   select BLK_DEVL_LOOP
+   select BLK_DEV_SD
+
+
+
+   select SECCOMP
+   select CC_STACKPROTECTOR
+
+
+
+
+
+   select NET
+   select PACKET
+   select UNIX
+   select INET
+
+   select SYN_COOKIES
+
+
+   select IPV6
+   select IPV6_PRIVACY
+   select IPV6_MULTIPLE_TABLES
+   select IPV6_SIT_6RD
+
+
+   select NETLABEL
+   select NETWORK_SECMARK
+
+   select VLAN_8021Q_GVRP
+
+
+
+
+
+   select IRDA_ULTRA
+   select IRDA_CACHE_LAST_LSAP
+   select IRDA_FAST_RR
+   select IRDA_DEBUG
+
+
+
+
+   select DEVTMPFS
+   select DEVTMPFS_MOUNT
+
+
+   select MTD
+   select MTD_CMDLINE_PARTS
+   select MTD_CHAR
+   select MTD_BLKDEVS
+   select MTD_BLOCK
+
+
+
+   select PARPORT_1284
+
+   select SCSI
+   select SCSI_DMA
+
+   select SCSI_FC_TGT_ATTRS
+
+
+   select MD
+   select BLK_DEV_MD
+   select BLK_DEV_DM
+   select DM_SNAPSHOT
+   select DM_MIRROR
+   select DM_MULTIPATH
+   select DM_UEVENT
+
+
+   select NETDEVICES
+   select NET_ETHERNET
+
+
+
+   select USB_ALI_M5632
+   select USB_AN2720
+   select USB_EPSON2888
+   select USB_KC2190
+
+
+   select PPP
+   select PPP_MULTILINK
+   select PPP_FILTER
+
+
+
+
+   select INPUT_EVDEV
+
+   select INPUT_MISC
+   select INPUT_UINPUT
+
+   select DONGLE
+
+   select SOUND
+   select SND
+
+   select USB
+
+   select SSB_SDIOHOST
+
+
+
+
+
+   select FB
+
+
+   select FRAMEBUFFER_CONSOLE
+
+
+   select MMC
+   select MMC_BLOCK_BOUNCE
+   
+
+   select EXT2_FS
+
+   select EXT3_FS
+   
+   select EXT4_FS
+
+
+   select JFS_POSIX_ACL
+   select JFS_SECURITY
+   select JFS_STATISTICS
+
+
+   select BTRFS_FS_POSIX_ACL
+   select FS_POSIX_ACL
+
+   select NLS
+   
+   select TMPFS
+   select TMPFS_POSIX_ACL
+
+   select UBIFS_FS_XATTR
+
+   select NETWORK_FILESYSTEMS
+   select NFS_V3
+
+
+
+
+
+   select WL12XX_MENU
+
+
+
+   select SERIAL_CORE_CONSOLE
+
+   select RTC_CLASS
+   select RTC_HCTOSYS
+   select RTC_INTF_SYSFS
+   select RTC_INTF_PROC
+   select RTC_INTF_DEV
+
+
+   select MAGIC_SYSRQ
+   select DETECT_HUNG_TASK
+
+   select DEBUG_KERNEL
+   select DEBUG_INFO
+
+   select DEBUG_USER
+   select DEBUG_ERRORS
+   select DEBUG_LL
+
+   select SECURITY
+   select SECURITYFS
+   select SECURITY_NETWORK
+   select SECURITY_SELINUX
+   select SECURITY_SELINUX_BOOTPARAM
+   select SECURITY_SELINUX_DISABLE
+
+
+   select SECURITY_SMACK
+   select SECURITY_TOMOYO
+   select SECURITY_APPARMOR
+
+   select DEFAULT_SECURITY_APPARMOR
+
+   select STRICT_DEVMEM
+
+
+# Non bool values
+# XXX - Each of these should have justification
+
+config BLK_DEV_RAM_SIZE
+   default 65536
+
+config DEFAULT_MMAP_MIN_ADDR
+   default 32768
+
+config SERIAL_8250_NR_UARTS
+   default 32
+
+config LSM_MMAP_MIN_ADDR
+   default 0
+
+config NLS_DEFAULT
+   default "cp437"
+
+config LEGACY_PTY_COUNT
+   default 0
+
+config SECURITY_SELINUX_BOOTPARAM_VALUE
+   default 0
+
+config ZBOOT_ROM_TEXT
+   default 0x0
+
+config ZBOOT_ROM_BSS
+   default 0x0
+
+
+# Overriding default enabled:
+# XXX - Each of these should have justification
+
+config CC_OPTIMIZE_FOR_SIZE
+   default n
+
+config COMPAT_BRK
+   default n
+
+config HAVE_GENERIC_HARDIRQS
+   default n
+
+config LOCALVERSION_AUTO
+   default n
+
+config CORE_DUMP_DEFAULT_ELF_HEADERS
+   default n
+
+config ENABLE_WARN_DEPRECATED
+   default n
+
+config ENABLE_MUST_CHECK
+   default n
+
+config RCU_CPU_STALL_DETECTOR
+   default n
+
+config USB_EHCI_TT_NEWSCHED
+   default n
+
+config MUSB_PIO_ONLY
+   default n
+
+config SCSI_PROC_FS
+   default n
+
+config SCSI_SAS_LIBSAS_DEBUG
+   default n
+
+config DEVKMEM
+   default n

[PATCH 10/12] omap3 kconfig fragment changes to align with linaro build

[John Stultz]

Once we have settled on a proper common Linaro config policy,
this should be able to go away.


CC: Jason Hui 
CC: patc...@linaro.org
Signed-off-by: John Stultz 
---
 arch/arm/configs/Kconfig.omap3 | 2299 +++-
 1 files changed, 2294 insertions(+), 5 deletions(-)

diff --git a/arch/arm/configs/Kconfig.omap3 b/arch/arm/configs/Kconfig.omap3
index 82847cf..49af9a2 100644
--- a/arch/arm/configs/Kconfig.omap3
+++ b/arch/arm/configs/Kconfig.omap3
@@ -44,22 +44,17 @@ config generateconfig_OMAP3_YES
select SND_SOC

select USB_NET
-   select USB_USBNET
select USB

-   select PARPORT
-
select FB

select TWL4030_CORE

select RTC_CLASS
select I2C
-   select RTC_DRV_M41T80
 
select MTD
select MTD_NAND
-   select MTD_ONENAND

select MMC

@@ -109,12 +104,16 @@ config generateconfig_OMAP3_YES
select SND_OMAP_SOC_ZOOM2
select SND_OMAP_SOC_IGEP0020
 
+   select USB_MUSB_OMAP2PLUS
+
select INTF_ALARM
select RTC_DRV_TWL4030
select RTC_DRV_M41T80_WDT
 
 
 
+
+
 # Enabling OMAP2 makes beagle boards not boot
 config ARCH_OMAP2
default n
@@ -134,6 +133,2296 @@ config USB_DEVICE_CLASS
 config OMAP2_VRAM_SIZE
default 6
 
+config PARPORT
+   default m
+config USB_USBNET
+   default m
+config MTD_ONENAND
+   default m
+
+config RTC_DRV_M41T80
+   default m
+
+
+# The following should be Kconfig.distro policy
+config generateconfig_SHOULD_BE_DISTROCONF_YES
+   def_bool y
+   select BSD_PROCESS_ACCT
+   select BSD_PROCESS_ACCT_V3
+   select TASKSTATS
+   select TASK_DELAY_ACCT
+   select TASK_XACCT
+   select TASK_IO_ACCOUNTING
+
+   select CGROUPS
+   select CGROUP_NS
+   select CGROUP_FREEZER
+   select CGROUP_DEVICE
+   select CPUSETS
+   select CGROUP_CPUACCT
+   select RESOURCE_COUNTERS
+   select CGROUP_MEM_RES_CTLR
+   select CGROUP_SCHED
+   select RT_GROUP_SCHED
+
+   select RELAY
+   select MODVERSIONS
+   select MODULE_SRCVERSION_ALL
+
+   select KALLSYMS_ALL
+
+   select PREEMPT_VOLUNTARY
+
+
+   select TICK_ONESHOT
+   select NO_HZ
+   select HIGH_RES_TIMERS
+
+   select PM
+   select PM_RUNTIME
+select PM_SLEEP
+select SUSPEND
+select SUSPEND_FREEZER
+select PM_OPS
+
+   select USB_SUSPEND
+
+
+   select PERF_COUNTERS
+   select PROFILING
+   select TRACEPOINTS
+   select KPROBES
+
+   select BLK_DEV_INTEGRITY
+
+   select KEXEC
+   select ATAGS_PROC
+
+   select IP_MULTICAST
+   select IP_ADVANCED_ROUTER
+   select TCP_CONG_ADVANCED
+   select TCP_MD5SIG
+   select NETFILTER
+   select NF_CONNTRACK_SECMARK
+   select NF_CONNTRACK_ZONES
+   select NF_CONNTRACK_EVENTS
+
+   select IP_VS_PROTO_TCP
+   select IP_VS_PROTO_UDP
+   select IP_VS_PROTO_AH_ESP
+   select IP_VS_PROTO_ESP
+   select IP_VS_PROTO_AH
+   select IP_VS_PROTO_SCTP
+   select IP_MULTIPLE_TABLES
+   select IP_ROUTE_MULTIPATH
+   select IP_ROUTE_VERBOSE
+   select IP_MROUTE
+   select IP_VS_NFCT
+   select IP_PIMSM_V1
+   select IP_PIMSM_V2
+
+   select IP_VS_IPV6
+
+   select NET_DSA
+   select NET_DSA_TAG_DSA
+   select NET_DSA_TAG_EDSA
+   select NET_DSA_TAG_TRAILER
+   select NET_DSA_MV88E6XXX
+   select NET_DSA_MV88E6060
+   select NET_DSA_MV88E6XXX_NEED_PPU
+   select NET_DSA_MV88E6131
+   select NET_DSA_MV88E6123_61_65
+
+   select DNS_RESOLVER
+
+   select NET_SCHED
+   select DCB
+
+   select SLIP_COMPRESSED
+   select SLIP_SMART
+   select SLIP_MODE_SLIP6
+
+   select NET_EMATCH
+   select NET_CLS_ACT
+   select GACT_PROB
+
+   select ECONET_AUNUDP
+   select ECONET_NATIVE
+
+   select NL80211_TESTMODE
+   select CFG80211_REG_DEBUG
+   select CFG80211_DEBUGFS
+   select MAC80211_MESH
+
+   select ATM_BR2684_IPFILTER
+   
+   select ISDN
+   select ISDN_PPP
+   select ISDN_AUDIO
+   select ISDN_X25
+   select ISDN_PPP_VJ
+   select ISDN_MPP
+   select IPPP_FILTER
+   select ISDN_TTY_FAX
+
+   select HISAX_EURO
+   select DE_AOC
+   select HISAX_1TR6
+   select HISAX_NI1
+   select HISAX_16_3
+   select HISAX_S0BOX
+   select HISAX_FRITZPCI
+#causes warning
+#  select HISAX_AVM_A1_PCMCIA
+   select HISAX_ELSA
+   select HISAX_DIEHLDIVA
+   select HISAX_SEDLBAUER
+   select HISAX_NICCY
+   select HISAX_GAZEL
+   select HISAX_HFC_SX
+
+
+   select ISDN_CAPI_MIDDLEWARE
+   select ISDN_CAPI_CAPIFS_BOOL
+   select CAPI_AVM
+   select CAPI_EICON
+
+   select HAMRADIO
+
+   select BT_RFCOMM_TTY
+   select BT_BNEP_MC_FIL

Re: how to sync with mainline

[Barry Song]

Thanks. Amit.

2011/3/8 Amit Kucheria :
> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote:
>> Hi Lee,
>> Great! Thanks a lot. It looks like the communication between linaro
>> and mainline is that linaro can backport some bug fixes and features
>> from mainline to linaro tree. Linaro doesn't help to review patches
>> and send to mainline.
>
> We prefer to see it this way:
>
> Develop against mainline and get those features integrated there. Keep
> linaro-dev in cc if these are features might be something Linaro would
> care about.
>
> The Linaro kernel (maintained by Nicolas Pitre and packaged by John
> Rigby) is a sort of technology demonstration to show what we achieve
> every 6 months. Some patches in it are backports, others are features
> that are still under review in mainline. But I doubt if Nicolas will
> take un-reviewed code directly into his tree.
>
>> Then I have two more questions
>> 1. is there a detailed list of backport and bug fix in linaro kernel
>> tree since those are the difference between mainline and linaro tree?
>
> 'git log' with the right incantations should be able to tell you that.
> Look up Nicolas' email announcements for the high-level overview of
> what he has integrated.
>
>> 2. will linaro accept patches from non-member companies and help to
>> maintain, I mean a SoC company which doesn't join linaro?
>
> Linaro doesn't want to maintain dead code that isn't going upstream.
> It won't even do it for member companies. At most it is the incubator
> where the code lives and gets wider testing _while_ it is being
> reworked for mainline.

If patches are going mainline, but they are not from members TI,
Freescale, ST-E etc, can they be merged into linaro kernel?

>
> /Amit
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo

[Loïc Minier]

On Tue, Mar 08, 2011, John Stultz wrote:
> This patch set provides enough to demo how the Kconfig fragment
> based defconfigs could be used to simplify both generating and
> managing the configs used to build Linaro kernels.

 This is awesome, thanks!

> 5) The igep, overo, and panda configs all use the same omap3
> config according to the hwpacks. I'm not sure I believe that,
> but went along with it to get this out the door.

 They currently use the same binary kernel, so it's actually correct
 :-)  They are in different hwpacks because they have different
 u-boot.bin/MLO and boot args.



 If you resend this description:
> Once we have the infrasturcture to use Kconfig fragments for
  ^
> Since the Linaro config polciy is not unified at this point
 ^
-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

The android build service is now feature complete!

[Michael Hudson-Doyle]

tl;dr version: see https://android-build.linaro.org/mockup/index, click
around.  Don't expect to be able to do much unless you're in
~linaro-android-builders

Hi all,

The frontend to the build service that I've been working on for the last
couple of weeks is -- to my understanding  -- now feature
complete.  You can see it at:

https://android-build.linaro.org/mockup/index

It works better in chrome than firefox currently, although I hope to be
through the worst of that soon.

You can log in using your Launchpad ID, but access to the interesting
functionality (being able to trigger, edit and set up builds) is
restricted to members of the ~linaro-android-builders team (I've made
Loic, Alexander and Patryk admins of this team as well as myself).

There is another team, ~linaro-android-official-builders, whose members
can make "official" builds.

I've tried pretty hard to make things self explanatory so I don't want
to explain too much here.  One thing that probably needs explaining is
that a "configuration" is a snippet of shell that sets various
environment variables that are interpreted by the build scripts, such as
MANIFEST_REPO, MANIFEST_BRANCH and the various TARGET_* variables
understood by the android build tools.

If there's something missing from this or some aspect that seems really
badly designed, *please* tell me!  Otherwise I'll assume you all love
it.  I hear a rumour that Alexander wants simpler browsing of build
artefacts.  I also know it's not especially pretty and the error
handling & reporting is a bit inconsistent.



If you're curious as to how it works, the web interface is a frontend to
jenkins, which is serving at https://android-build.linaro.org/jenkins.
Each configuration corresponds to a job in jenkins, with the
configuration data stored as the default value for a parameter.  There's
a lot of javascript (using YUI 3) going on, and in particular most pages
get the data they display by making ajax requests directly to jenkins'
remote access API.  The rest of it is a Django web application, which
handles generating the html (though this are only very very lightly
templated) and handling the 'write' operations that need server side
access control.

The code is in lp:~mwhudson/linaro-android/frontend on Launchpad and is
pretty messy, although still fairly small (around 1500 lines of code).
I plan to spend some time over the next week making the code much more
maintainable, but I don't have any other plans for this code myself.
Now get criticizing!

Cheers,
mwh

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V3 0/5] Add MX51 basic DT support

[Jason Liu]

From: Jason Liu 

This patchset adds Freescale i.mx51 device tree support.
This is based on

git://git.secretlab.ca/git/linux-2.6 devicetree/test

This patch has been tested on MX51 babbage board and can
boot up succesfully to linux console with DT enabled.

Grant, I think it's almost ready for you to merge it.

V3:
- prefix the property name with the vendor name as like:
   "fsl,has-rts-cts" and "fsl,irda-mode"
- use the ttymxc0 as the console
- add FEC support, nfs can be used now

Jason Liu (5):
  arm/dt: add basic mx51 device tree support
  arm/dt: add very basic dts file for babbage board
  serial/imx: parse from device tree support
  net/fec: check id_entry pointer before using it
  net/fec: add device tree matching support

 arch/arm/boot/dts/babbage.dts   |  110 +++
 arch/arm/mach-mx5/Kconfig   |8 ++
 arch/arm/mach-mx5/Makefile  |1 +
 arch/arm/mach-mx5/board-dt.c|   64 ++
 arch/arm/mach-mx5/clock-mx51-mx53.c |   43 -
 arch/arm/plat-mxc/include/mach/common.h |1 +
 drivers/net/fec.c   |   25 +--
 drivers/tty/serial/imx.c|   79 +++---
 8 files changed, 314 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/boot/dts/babbage.dts
 create mode 100644 arch/arm/mach-mx5/board-dt.c


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V3 2/5] arm/dt: add very basic dts file for babbage board

[Jason Liu]

Signed-off-by: Jason Liu 
Singed-off-by: Rob Herring 
---
 arch/arm/boot/dts/babbage.dts |  110 +
 1 files changed, 110 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/babbage.dts b/arch/arm/boot/dts/babbage.dts
new file mode 100644
index 000..303dcd5
--- /dev/null
+++ b/arch/arm/boot/dts/babbage.dts
@@ -0,0 +1,110 @@
+/dts-v1/;
+
+/ {
+   model = "Freescale i.MX51 Babbage";
+   compatible = "fsl,mx51-babbage";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #interrupt-cells = <1>;
+   interrupt-parent = <&tzic>;
+
+   memory {
+   reg = <0x9000 0x2000>;
+   };
+
+   chosen {
+   bootargs = "console=ttymxc0,115200n8 debug earlyprintk ip=dhcp";
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges;
+
+   tzic: tz-interrupt-controller {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   reg = <0xe000 0x1000>;
+   compatible = "fsl,imx51-tzic";
+   };
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   uart0_clk: uart0 {
+   compatible = "clock";
+   clock-outputs = "imx-uart.0";
+   };
+
+   uart1_clk: uart1 {
+   compatible = "clock";
+   clock-outputs = "imx-uart.1";
+   };
+
+   uart2_clk: uart2 {
+   compatible = "clock";
+   clock-outputs = "imx-uart.2";
+   };
+
+   fec_clk: fec {
+   compatible = "clock";
+   clock-outputs = "fec.0";
+   };
+   };
+
+   aips@73f0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges = <0x0 0x73f0 0x10>;
+
+   imx-uart@bc000 {
+   compatible = "fsl,imx51-uart";
+   reg = <0xbc000 0x1000>;
+   interrupts = <0x1f>;
+   fsl,has-rts-cts;
+   uart-clock = <&uart0_clk>, "uart";
+   };
+
+   imx-uart@c {
+   compatible = "fsl,imx51-uart";
+   reg = <0xc 0x1000>;
+   interrupts = <0x20>;
+   fsl,has-rts-cts;
+   uart-clock = <&uart1_clk>, "uart";
+   };
+   };
+
+   spba@7000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges = <0x0 0x7000 0x10>;
+
+   imx-uart@c000 {
+   compatible = "fsl,imx51-uart";
+   reg = <0xc000 0x1000>;
+   interrupts = <0x21>;
+   fsl,has-rts-cts;
+   uart-clock = <&uart2_clk>, "uart";
+   };
+   };
+
+   aips@83f0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges = <0x0 0x83f0 0x10>;
+
+   fec@ec000 {
+   compatible = "fsl,imx-fec";
+   reg = <0xec000 0x1000>;
+   interrupts = <0x57>;
+   fec_clk-clock = <&fec_clk>, "fec";
+   };
+   };
+};
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V3 1/5] arm/dt: add basic mx51 device tree support

[Jason Liu]

Signed-off-by: Jason Liu 
---
 arch/arm/mach-mx5/Kconfig   |8 
 arch/arm/mach-mx5/Makefile  |1 +
 arch/arm/mach-mx5/board-dt.c|   64 +++
 arch/arm/mach-mx5/clock-mx51-mx53.c |   43 -
 arch/arm/plat-mxc/include/mach/common.h |1 +
 5 files changed, 116 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index de4fa99..6438f87 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -47,6 +47,14 @@ config MACH_MX51_BABBAGE
  u-boot. This includes specific configurations for the board and its
  peripherals.
 
+config MACH_MX51_DT
+   bool "Generic MX51 board (FDT support)"
+   select USE_OF
+   select SOC_IMX51
+   help
+Support for generic Freescale i.MX51 boards using Flattened Device
+Tree.
+
 config MACH_MX51_3DS
bool "Support MX51PDK (3DS)"
select SOC_IMX51
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0d43be9..540697e 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_MACH_EUKREA_CPUIMX51SD) += board-cpuimx51sd.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD51_BASEBOARD) += eukrea_mbimxsd-baseboard.o
 obj-$(CONFIG_MACH_MX51_EFIKAMX) += board-mx51_efikamx.o
 obj-$(CONFIG_MACH_MX50_RDP) += board-mx50_rdp.o
+obj-$(CONFIG_MACH_MX51_DT) += board-dt.o
diff --git a/arch/arm/mach-mx5/board-dt.c b/arch/arm/mach-mx5/board-dt.c
new file mode 100644
index 000..cfb3813
--- /dev/null
+++ b/arch/arm/mach-mx5/board-dt.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "devices.h"
+
+static struct of_device_id mx51_dt_match_table[] __initdata = {
+   { .compatible = "simple-bus", },
+   {}
+};
+
+static void __init mx51_dt_board_init(void)
+{
+   of_platform_bus_probe(NULL, mx51_dt_match_table, NULL);
+}
+
+static void __init mx51_dt_timer_init(void)
+{
+   mx51_clocks_init(32768, 2400, 22579200, 0);
+   mx5_clk_dt_init();
+}
+
+static struct sys_timer mxc_timer = {
+   .init = mx51_dt_timer_init,
+};
+
+static const char *mx51_dt_board_compat[] = {
+   "fsl,mx51-babbage",
+   NULL
+};
+
+DT_MACHINE_START(MX51_DT, "Freescale MX51 (Flattened Device Tree)")
+   .boot_params  = PHYS_OFFSET + 0x100,
+   .map_io   = mx51_map_io,
+   .init_irq = mx51_init_irq,
+   .init_machine = mx51_dt_board_init,
+   .dt_compat= mx51_dt_board_compat,
+   .timer= &mxc_timer,
+MACHINE_END
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c 
b/arch/arm/mach-mx5/clock-mx51-mx53.c
index 0a19e75..dedb7f9 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -15,13 +15,19 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include 
 #include 
 #include 
 
+#ifdef CONFIG_OF
+#include 
+#include 
+#include 
+#endif /* CONFIG_OF */
+
 #include "crm_regs.h"
 
 /* External clock values passed-in by the board code */
@@ -1432,3 +1438,38 @@ int __init mx53_clocks_init(unsigned long ckil, unsigned 
long osc,
MX53_INT_GPT);
return 0;
 }
+
+#ifdef CONFIG_OF
+static struct clk *mx5_dt_clk_get(struct device_node *np,
+   const char *output_id, void *data)
+{
+   return data;
+}
+
+static __init void mx5_dt_scan_clks(void)
+{
+   struct device_node *node;
+   struct clk *clk;
+   const char *id;
+   int rc;
+
+   for_each_compatible_node(node, NULL, "clock") {
+   id = of_get_property(node, "clock-outputs", NULL);
+   if (!id)
+   continue;
+
+   clk = clk_get_sys(id, NULL);
+   if (IS_ERR(clk))
+   continue;
+
+   rc = of_clk_add_provider(node, mx5_dt_clk_get, clk);
+   if (rc)
+   pr_err("error adding fixed clk %s\n", node->name);
+   }
+}
+
+void __init mx5_clk_dt_init(void)
+{
+   mx5_dt_scan_clks();
+}
+#endif
diff --git a/arch/arm/plat-mxc/include/mach/common.h 
b/arch/arm/plat-mxc/include/mach/common.h
index aea2cd3..a28e84a 100644
--- a/arch/arm/plat-mxc/include/mach/common.h
+++ b/arch/arm/plat-mxc/include/mach/common.h
@@ -58,4 +58,5 @@ extern void mxc91231_arch_reset(int, const char *);
 extern void mxc91231_prepare_idle(void);
 extern void mx51_efikamx_reset(void);
 extern int mx53_revis

[PATCH V3 3/5] serial/imx: parse from device tree support

[Jason Liu]

Signed-off-by: Jason Liu 
Signed-off-by: Jeremy Kerr 
---
 drivers/tty/serial/imx.c |   79 --
 1 files changed, 69 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index dfcf4b1..c9483d1 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -53,6 +53,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 /* Register definitions */
 #define URXD0 0x0  /* Receiver Register */
 #define URTX0 0x40 /* Transmitter Register */
@@ -1224,6 +1227,53 @@ static int serial_imx_resume(struct platform_device *dev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static int serial_imx_probe_dt(struct imx_port *sport,
+   struct platform_device *pdev)
+{
+   struct device_node *node = pdev->dev.of_node;
+   static int line;
+
+   if (!node)
+   return -ENODEV;
+
+   if (of_get_property(node, "fsl,has-rts-cts", NULL))
+   sport->have_rtscts = 1;
+
+   if (of_get_property(node, "fsl,irda-mode", NULL))
+   sport->use_irda = 1;
+
+   sport->port.line = line++;
+
+   return 0;
+}
+#else
+static int serial_imx_probe_dt(struct imx_port *sport,
+   struct platform_device *pdev)
+{
+   return -ENODEV;
+}
+#endif
+
+static int serial_imx_probe_pdata(struct imx_port *sport,
+   struct platform_device *pdev)
+{
+   struct imxuart_platform_data *pdata = pdev->dev.platform_data;
+
+   if (!pdata)
+   return 0;
+
+   if (pdata->flags & IMXUART_HAVE_RTSCTS)
+   sport->have_rtscts = 1;
+
+#ifdef CONFIG_IRDA
+   if (pdata->flags & IMXUART_IRDA)
+   sport->use_irda = 1;
+#endif
+   sport->port.line = pdev->id;
+
+   return 0;
+}
 static int serial_imx_probe(struct platform_device *pdev)
 {
struct imx_port *sport;
@@ -1236,6 +1286,12 @@ static int serial_imx_probe(struct platform_device *pdev)
if (!sport)
return -ENOMEM;
 
+   ret = serial_imx_probe_dt(sport, pdev);
+   if (ret == -ENODEV)
+   ret = serial_imx_probe_pdata(sport, pdev);
+   if (ret)
+   goto free;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
ret = -ENODEV;
@@ -1260,7 +1316,6 @@ static int serial_imx_probe(struct platform_device *pdev)
sport->port.fifosize = 32;
sport->port.ops = &imx_pops;
sport->port.flags = UPF_BOOT_AUTOCONF;
-   sport->port.line = pdev->id;
init_timer(&sport->timer);
sport->timer.function = imx_timeout;
sport->timer.data = (unsigned long)sport;
@@ -1274,17 +1329,13 @@ static int serial_imx_probe(struct platform_device 
*pdev)
 
sport->port.uartclk = clk_get_rate(sport->clk);
 
-   imx_ports[pdev->id] = sport;
+   if (imx_ports[sport->port.line]) {
+   ret = -EBUSY;
+   goto clkput;
+   }
+   imx_ports[sport->port.line] = sport;
 
pdata = pdev->dev.platform_data;
-   if (pdata && (pdata->flags & IMXUART_HAVE_RTSCTS))
-   sport->have_rtscts = 1;
-
-#ifdef CONFIG_IRDA
-   if (pdata && (pdata->flags & IMXUART_IRDA))
-   sport->use_irda = 1;
-#endif
-
if (pdata && pdata->init) {
ret = pdata->init(pdev);
if (ret)
@@ -1336,6 +1387,11 @@ static int serial_imx_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static struct of_device_id imx_uart_matches[] = {
+   { .compatible = "fsl,imx51-uart" },
+   {},
+};
+
 static struct platform_driver serial_imx_driver = {
.probe  = serial_imx_probe,
.remove = serial_imx_remove,
@@ -1345,6 +1401,9 @@ static struct platform_driver serial_imx_driver = {
.driver = {
.name   = "imx-uart",
.owner  = THIS_MODULE,
+#if defined(CONFIG_OF)
+   .of_match_table = imx_uart_matches,
+#endif
},
 };
 
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V3 4/5] net/fec: check id_entry pointer before using it

[Jason Liu]

The id_entry will possibly be NULL, So, need check
id_entry and make sure it not NULL before using it.

Signed-off-by: Jason Liu 
---
 drivers/net/fec.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 2a71373..02cdd71 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -293,7 +293,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device 
*dev)
 * the system that it's running on. As the result, driver has to
 * swap every frame going to and coming from the controller.
 */
-   if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+   if (id_entry && id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
swap_buffer(bufaddr, skb->len);
 
/* Save skb pointer */
@@ -529,7 +529,7 @@ fec_enet_rx(struct net_device *dev)
dma_unmap_single(NULL, bdp->cbd_bufaddr, bdp->cbd_datlen,
DMA_FROM_DEVICE);
 
-   if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
+   if (id_entry && id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
swap_buffer(data, pkt_len);
 
/* This does 16 byte alignment, exactly what we need.
@@ -808,7 +808,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
 * mdio interface in board design, and need to be configured by
 * fec0 mii_bus.
 */
-   if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id) {
+   if (id_entry && (id_entry->driver_data & FEC_QUIRK_ENET_MAC) && 
pdev->id) {
/* fec1 uses fec0 mii_bus */
fep->mii_bus = fec0_mii_bus;
return 0;
@@ -851,7 +851,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
goto err_out_free_mdio_irq;
 
/* save fec0 mii_bus */
-   if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+   if (id_entry && id_entry->driver_data & FEC_QUIRK_ENET_MAC)
fec0_mii_bus = fep->mii_bus;
 
return 0;
@@ -1238,7 +1238,7 @@ fec_restart(struct net_device *dev, int duplex)
 * enet-mac reset will reset mac address registers too,
 * so need to reconfigure it.
 */
-   if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+   if (id_entry && id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
@@ -1294,7 +1294,7 @@ fec_restart(struct net_device *dev, int duplex)
 * The phy interface and speed need to get configured
 * differently on enet-mac.
 */
-   if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+   if (id_entry && id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
val = readl(fep->hwp + FEC_R_CNTRL);
 
/* MII or RMII */
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH V3 5/5] net/fec: add device tree matching support

[Jason Liu]

Signed-off-by: Jason Liu 
---
 drivers/net/fec.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 02cdd71..fcb9768 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -45,6 +45,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 
 #ifndef CONFIG_ARM
@@ -1523,6 +1526,13 @@ static const struct dev_pm_ops fec_pm_ops = {
 };
 #endif
 
+#ifdef CONFIG_OF
+static struct of_device_id fec_matches[] = {
+   { .compatible = "fsl,imx-fec" },
+   {},
+};
+#endif
+
 static struct platform_driver fec_driver = {
.driver = {
.name   = DRIVER_NAME,
@@ -1530,6 +1540,9 @@ static struct platform_driver fec_driver = {
 #ifdef CONFIG_PM
.pm = &fec_pm_ops,
 #endif
+#ifdef CONFIG_OF
+   .of_match_table = fec_matches,
+#endif
},
.id_table = fec_devtype,
.probe  = fec_probe,
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: how to sync with mainline

[Amit Kucheria]

On Wed, Mar 9, 2011 at 4:44 AM, Barry Song <21cn...@gmail.com> wrote:
> Thanks. Amit.
>
> 2011/3/8 Amit Kucheria :



>> Linaro doesn't want to maintain dead code that isn't going upstream.
>> It won't even do it for member companies. At most it is the incubator
>> where the code lives and gets wider testing _while_ it is being
>> reworked for mainline.
>
> If patches are going mainline, but they are not from members TI,
> Freescale, ST-E etc, can they be merged into linaro kernel?
>

It would depend on the patches, I guess. You can post them here to find out.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] toolchain/build: Support linaro android toolchain

[Meng-Hsuan Cheng]

Add linaro-build.sh to support linaro android toolchain.
--prefix=   Specify where to install (default:
/tmp/android-toolchain-eabi)
--toolchain-src=Specify Android toolchain source dir (default:
/../)
--with-gcc= Specify GCC source (support: directory, bzr, url)
--apply-gcc-patch=(yes|no)   Apply gcc-patches (default: no)
--help  Print help message

Change-Id: I15478ba3b3dd4f49be3767724028e4e4dcade1ca
---
 linaro-build.sh |  195
+++
 1 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100755 linaro-build.sh

diff --git a/linaro-build.sh b/linaro-build.sh
new file mode 100755
index 000..57266dd
--- /dev/null
+++ b/linaro-build.sh
@@ -0,0 +1,195 @@
+#!/bin/bash
+
+# Copyright (C) 2011 Linaro
+#
+# This file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+
+ARG_PREFIX_DIR=/tmp/android-toolchain-eabi
+ARG_TOOLCHAIN_SRC_DIR=${PWD%/build}
+
+ARG_LINARO_GCC_SRC_DIR=
+ARG_WGET_LINARO_GCC_SRC=
+ARG_BZR_LINARO_GCC_SRC=
+
+ARG_WITH_GCC=
+
+ARG_APPLY_PATCH=no
+
+abort() {
+  echo $@
+  exec false
+}
+
+error() {
+  abort "[ERROR] $@"
+}
+
+warn() {
+  echo "[WARNING] $@"
+}
+
+info() {
+  echo "[INFO] $@"
+}
+
+note() {
+  echo "[NOTE] $@"
+}
+
+usage() {
+  echo
""
+  echo "--prefix=   Specify where to install (default:
/tmp/android-toolchain-eabi)"
+  echo "--toolchain-src=Specify Android toolchain source dir (default:
/../)"
+  echo "--with-gcc= Specify GCC source (support: directory, bzr,
url)"
+  echo "--apply-gcc-patch=(yes|no)   Apply gcc-patches (default: no)"
+  echo "--help  Print help message"
+  echo
""
+}
+
+ARG_LINARO_GCC_SRC_DIR=
+
+
+downloadFormBZR() {
+  local MY_LP_LINARO_GCC=$1
+  ARG_LINARO_GCC_SRC_DIR=${MY_LP_LINARO_GCC#*:}
+
+  [ ! -d ${ARG_TOOLCHAIN_SRC_DIR}/gcc ] && mkdir -p
"${ARG_TOOLCHAIN_SRC_DIR}/gcc"
+  if [ ! -d "${ARG_TOOLCHAIN_SRC_DIR}/gcc/${ARG_LINARO_GCC_SRC_DIR}" ];
then
+info "Use bzr to clone ${MY_LP_LINARO_GCC}"
+RUN=`bzr clone ${MY_LP_LINARO_GCC}
${ARG_TOOLCHAIN_SRC_DIR}/gcc/${ARG_LINARO_GCC_SRC_DIR}`
+[ $? -ne 0 ] && error "bzr ${MY_LP_LINARO_GCC} error"
+  else
+info "${ARG_TOOLCHAIN_SRC_DIR}/gcc/${ARG_LINARO_GCC_SRC_DIR} is already
exist, skip bzr clone"
+  fi
+}
+
+downloadFormHTTP() {
+  info "Use wget to get $1"
+  local MY_LINARO_GCC_FILE=`basename $1`
+  if [ -f "${MY_LINARO_GCC_FILE}" ]; then
+#TODO: Add md5 check
+info "${MY_LINARO_GCC_FILE} is already exist, skip download"
+  else
+RUN=`wget $1`
+[ $? -ne 0 ] && error "wget $1 error"
+#TODO: Add md5 check
+  fi
+
+  ARG_LINARO_GCC_SRC_DIR=`basename ${MY_LINARO_GCC_FILE} .tar.bz2`
+  [ ! -d ${ARG_TOOLCHAIN_SRC_DIR}/gcc ] && mkdir -p
"${ARG_TOOLCHAIN_SRC_DIR}/gcc"
+  if [ ! -d "${ARG_TOOLCHAIN_SRC_DIR}/gcc/${ARG_LINARO_GCC_SRC_DIR}" ];
then
+info "untar ${MY_LINARO_GCC_FILE} to ${ARG_TOOLCHAIN_SRC_DIR}/gcc"
+tar jxf ${MY_LINARO_GCC_FILE} -C ${ARG_TOOLCHAIN_SRC_DIR}/gcc
+  else
+info "${ARG_TOOLCHAIN_SRC_DIR}/gcc/${ARG_LINARO_GCC_SRC_DIR} is already
exist, skip untar"
+  fi
+}
+
+getGCCFrom() {
+  # set empty to detect error
+  ARG_LINARO_GCC_SRC_DIR=
+  ARG_LINARO_GCC_VER=
+
+  case $1 in
+lp:*) # bzr clone lp:gcc-linaro
+  downloadFormBZR $1
+  ;;
+http://*) # snapshot url
http://launchpad.net/gcc-linaro/4.5/4.5-2011.02-0/+download/gcc-linaro-4.5-2011.02-0.tar.bz2
+  downloadFormHTTP $1
+  ;;
+*) # local directory
+  [ ! -d "${ARG_TOOLCHAIN_SRC_DIR}/gcc/$1" ] && error
"$ARG_TOOLCHAIN_SRC_DIR/gcc/$ARG_LINARO_GCC_SRC_DIR not exist"
+  ARG_LINARO_GCC_SRC_DIR=$1
+  esac
+
+  ARG_LINARO_GCC_VER=`echo ${ARG_LINARO_GCC_SRC_DIR} | grep -o "4\.[5-9]"`
+  if [ ${ARG_LINARO_GCC_VER} = "" ]; then
+warn "Cannot detect version for ${ARG_LINARO_GCC_VER}, 4.5 is used"
+ARG_LINARO_GCC_VER=4.5
+  fi
+}
+
+while [ $# -gt 0 ]; do
+  ARG=$1
+  ARG_PARMS="$ARG_PARMS '$ARG'"
+  shift
+  case "$ARG" in
+--prefix=*)
+  ARG_PREFIX_DIR="${ARG#*=}"
+  ;;
+--toolchain-src=*)
+  ARG_TOOLCHAIN_SRC_DIR="${ARG#*=}"
+  ;;
+--with-gcc=*)
+  ARG_WITH_GCC="${ARG#*=}"
+  ;;
+--apply-gcc-patch=yes | --apply-gcc-patch=no)
+  ARG_APPLY_PATCH="${ARG#*=}"
+  ;;
+--help)
+  usage && abort
+  ;;
+*)
+  error "Unrecognized parameter $ARG"
+  ;;
+  esac
+done
+
+BUILD_ARCH=`uname -m`
+BUILD_WITH_LOCAL=
+BUILD_H

Re: how to sync with mainline

[Lee Jones]

On 09/03/11 02:44, Barry Song wrote:
> Thanks. Amit.
>
> 2011/3/8 Amit Kucheria :
>> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote:
>>> Hi Lee,
>>> Great! Thanks a lot. It looks like the communication between linaro
>>> and mainline is that linaro can backport some bug fixes and features
>>> from mainline to linaro tree. Linaro doesn't help to review patches
>>> and send to mainline.
>> We prefer to see it this way:
>>
>> Develop against mainline and get those features integrated there. Keep
>> linaro-dev in cc if these are features might be something Linaro would
>> care about.
>>
>> The Linaro kernel (maintained by Nicolas Pitre and packaged by John
>> Rigby) is a sort of technology demonstration to show what we achieve
>> every 6 months. Some patches in it are backports, others are features
>> that are still under review in mainline. But I doubt if Nicolas will
>> take un-reviewed code directly into his tree.
>>
>>> Then I have two more questions
>>> 1. is there a detailed list of backport and bug fix in linaro kernel
>>> tree since those are the difference between mainline and linaro tree?
>> 'git log' with the right incantations should be able to tell you that.
>> Look up Nicolas' email announcements for the high-level overview of
>> what he has integrated.
>>
>>> 2. will linaro accept patches from non-member companies and help to
>>> maintain, I mean a SoC company which doesn't join linaro?
>> Linaro doesn't want to maintain dead code that isn't going upstream.
>> It won't even do it for member companies. At most it is the incubator
>> where the code lives and gets wider testing _while_ it is being
>> reworked for mainline.
> If patches are going mainline, but they are not from members TI,
> Freescale, ST-E etc, can they be merged into linaro kernel?

I don't see any reason why not, but the overall decision will be made by Nico.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev