-------- Original Message --------
Subject: Re: FW: STM Drviers update patch
Date: Mon, 14 May 2012 21:46:40 +0800
From: Andy Green <andy.green(a)linaro.org>
To: Deao, Douglas <d-deao(a)ti.com>
CC: inaro-dev(a)lists.linaro.org <inaro-dev(a)lists.linaro.org>, Ryan
Harkin <ryan.harkin(a)linaro.org>, Arnd Bergmann <arnd(a)arndb.de>
On 14/05/12 21:41, Somebody in the thread at some point said:
Hi -
> The commit to my clone was right after "config tilt stm and omap driver"
> on tracking-topic-stm. I used "git format-patch -1" to generate the
> patch.
>
> I sent my patch before Ryan's showed up on the landing team site.
OK I'll have another go at gluing it on tomorrow, unless Ryan prefers to
deal with it. I had Ryan's patches locally for a couple of weeks but
was unable to push tracking for several days due to crash bugs I fixed
late last week.
> The Framework driver is not using /sys in any way, just /debugfs, so
> anything with /sys was added by Ryan.
You're quite right, if I looked a little further along I would have seen
it's /sys/kernel/debugfs. Sorry for the noise.
> The Framework driver has always had a debugfs fops API. The first
> release supported only character based messages, but the new patch
> supports binary transfers using the same fops API. Trying to keep
> it easy to use for both cases.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
Hello all,
I'm interesting in obtaining perf.data files recorded on a different ARM boards.
For those who has no ideas about what is it, you may take a quick look at
https://perf.wiki.kernel.org/index.php/Main_Page. If you're able to use
apt-get or other ways to install a few packages on your board, you can help.
I also prepared two perf binaries (hard- and soft-float) - if one of these
matches your system, the whole procedure takes just a few minutes.
1. Make sure your kernel has tracing subsystem enabled:
a) zcat /proc/config.gz and look for CONFIG_PERF_EVENTS=y, or
b) check whether /sys/kernel/debug/tracing/events directory exists.
2. Install a few required packages:
apt-get install libelf1 libdw1 liblzma5 binutils libbz2-1.0 zlib1g
3. Select an appropriate perf binary:
a) soft-float from http://78.153.153.8/tmp/arm-linux-gnueabi-perf.gz or
b) hard-float from http://78.153.153.8/tmp/arm-linux-gnueabihf-perf.gz
and use ldd to check whether all runtime dependencies are resolved.
4. Run (this is one line):
perf record -a -R -f -m 8192 -c 1 -e sched:sched_switch -e sched:sched_process_exit \
-e sched:sched_process_fork -e sched:sched_wakeup -e sched:sched_migrate_task ls -la /
and make sure perf.data is created.
5. Run:
perf report --stdio
and save an output.
6. Send perf.data and output from step 5) to me, by e-mail directly or via pastebin;
don't forget to mention your board type.
Thanks in advance,
Dmitry
Hi,
I've previously read (probably on Phoronix) that Linaro is working out
a 'standard' kernel interface for 2D blitters IPs as commonly found on
SoCs.
Has it ever been the case? If yes, are there any
documentation/references online?
Thanks,
-Ilyes
Hello All
Just discovered something, wanted to share, might be that many out there
will be knowing this, for the unknowns sharing this:
We do few source file change and then end up building the entire stuff
using "make" command. Mid way through the build we see that a single
annoying COMPILE ERROR and see its such a waste of time.
So the ideal thing is to just compile and link only the changed file which
will be quick and rest assured FULL the build will succeed. So here's how
it is to be done:
In my below example I am building the Sensor file which is in the path,
kernel/drivers/hwmon:
*The build command is:* make -C ../out/target/product/snowball/obj/kernel/
SUBDIRS=drivers/hwmon ARCH=arm CROSS_COMPILE=arm-eabi-
*Replace the "drivers/hwmon" to your location where the file you modified
is present and it builds.*
For eg:
venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ vim
drivers/hwmon/lsm303dlh_m.c
venkatr@build1:~/snowball_board_branch_0.0.3/kernel$ make -C
../out/target/product/snowball/obj/kernel/ SUBDIRS=drivers/hwmon ARCH=arm
CROSS_COMPILE=arm-eabi-
make: Entering directory
`/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel'
make -C /u/home01/venkatr/snowball_board_branch_0.0.3/kernel
O=/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel/.
CC drivers/hwmon/lsm303dlh_m.o
LD drivers/hwmon/built-in.o
Building modules, stage 2.
MODPOST 0 modules
make: Leaving directory
`/u/home01/venkatr/snowball_board_branch_0.0.3/out/target/product/snowball/obj/kernel'
venkatr@build1:~/snowball_board_branch_0.0.3/kernel$
BR,
Venkat.
Hey folks.
Initial batch of LAVA tests in fast models are now running in the Linaro
validation lab. This initial run is designed to see how behaves in
practice and to check for omissions occurring away from my computer.
The branch that I've deployed is lp:~zkrynicki/lava-core/demo-3 (it
depends on unreleased json-document tree from github if you want to try
it out, there are instructions in the tree).
We've got the licensing server setup for production usage and started a
(arguably dummy) stream lava-test test based on
hwpack_linaro-vexpressdt-rtsm_20120511-22_armhf_supported.tar.gz and
linaro-precise-developer-20120426-86.tar.gz which is the combination I
was using locally.
Over the next few days we'll be working on improving the process so that
we can start accepting more realistic tests. Initially do expect high
failure rate due to imperfections in the technology, configuration
issues, etc.
The plan is to quickly move to practical use cases. So far I'm aware of
the switcher tests that the QA team is using, and the kvm tests but I
have not checked either, in practice, on a fast model yet.
My question to you, is to give me pointers (ideally as simple, practical
instructions that show it works) for things that you want to run. I'm
pretty ignorant about Android side of the story so any message from our
android team would be appreciated.
Please note that iteraction cycle is very slow. It takes 10+ hours to do
trivial things (doing apt-get update, installing a few packages,
compiling trivial program and getting it to run for a short moment).
Please don't ask us to run monkey for you as we'll be wasting time at
this point.
My goal is to understand what's missing and to estimate how long given
tests typically takes so that we can compare how our infrastructure
compares to your needs.
Many thanks
Zygmunt Krynicki
--
Zygmunt Krynicki
Linaro Validation Team
(CC'd "inaro-dev" as opposed to "linaro-dev" as I guess that was a previous
typo)
On 14 May 2012 14:41, Deao, Douglas <d-deao(a)ti.com> wrote:
> Andy,
>
> The commit to my clone was right after "config tilt stm and omap driver"
> on tracking-topic-stm. I used "git format-patch -1" to generate the
> patch.
>
> I sent my patch before Ryan's showed up on the landing team site.
>
My patches are only a new "driver" (stm_arm.c) and the Kconfig/makefile
changes needed.
This new driver doesn't do anything yet, BTW, it's just a load of debug
code. But it shouldn't effect your patch merging over the top of your
existing stm_fw.c as I haven't touched that file.
>
> The Framework driver is not using /sys in any way, just /debugfs, so
> anything with /sys was added by Ryan.
>
Not guilty :-) I think Andy was simply referring to the /debugfs stuff,
but called it /sys.
>
> The Framework driver has always had a debugfs fops API. The first
> release supported only character based messages, but the new patch
> supports binary transfers using the same fops API. Trying to keep
> it easy to use for both cases.
>
> Regards,
> Doug
>
> > -----Original Message-----
> > From: Andy Green [mailto:andy.green@linaro.org]
> > Sent: Sunday, May 13, 2012 10:29 PM
> > To: Deao, Douglas
> > Cc: inaro-dev(a)lists.linaro.org; Ryan Harkin; Arnd Bergmann
> > Subject: Re: FW: STM Drviers update patch
> >
> > On 11/05/12 01:29, Somebody in the thread at some point said:
> >
> > (looping Ryan and Arnd)
> >
> > > This time without the copy/paste error.
> > >
> > > -----Original Message-----
> > > From: Deao, Douglas
> > > Sent: Thursday, May 10, 2012 12:26 PM
> > > To: 'Andy Green'
> > > Cc: 'mailto:patches@linaro.org'; 'mailto:linaro-dev@lists.linaro.org'
> > > Subject: STM Drviers update patch
> > >
> > > Andy,
> > >
> > > Just found the Linaro "Process/UpstreamPatches" page.
> > >
> > > Anything else that's not obvious to a newbie I need to be aware of?
> >
> > Hi Doug -
> >
> > I'm not sure I'm the integration point for these patches or it should
> > be
> > Ryan... he has sent some refactor patches for omap support recently for
> > OMAP5 testing.
> >
> > Either way patches(a)linaro.org only cares about patches when they're
> > sent
> > upstream, and we're not there yet.
> >
> > I wasn't able to get this patch to apply to tracking-topic-stm with or
> > without Ryan's changes... is it intended to replace what's there?
> > That's fine if so, otherwise what should it apply to? Is it aware of
> > Ryan's changes?
> >
> > http://git.linaro.org/gitweb?p=landing-
> > teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-stm
> >
> > Something I noticed when testing for Ryan was there's a kind of shell
> > command type interface via /sys nodes, with commandlines like
> >
> > echo "rm xyz" > /sys/blah
> >
> > In the past, I believe there has been some resistance to this kind of
> > thing upstream, with a hardline one-token-one-sys-node approach
> > demanded. In other /sys based subsystems, they seem to use the idea of
> > elaborating the possible commands as /sys nodes themselves, so you
> > would
> > echo > /sys/.../rm to delete. Maybe Arnd can guide us if that's still
> > a
> > problem.
> >
> > Also while we're bothering Arnd, IIRC at one point there was a char
> > device, but I can't see it any more with a quick look through the
> > framework code. Did you replace it? If so what's the way to transfer
> > the bulk data now?
> >
> > -Andy
> >
> > > -----Original Message-----
> > > From: Deao, Douglas
> > > Sent: Tuesday, May 08, 2012 4:40 PM
> > > To: Andy Green
> > > Cc: Loic Pallardy; scott.bambrough(a)linaro.org; Ryan Harkin; Lee
> > Jones; Philippe Langlais
> > > Subject: STM Drviers update patch
> > >
> > > Andy,
> > >
> > > I have attached a patch for tracking-topic-stm that contains both my
> > latest updates and feedback/patches I merged from Loic Pallardy.
> > >
> > > This patch includes:
> > > - Binary data transport
> > > - mmap support for mapping channels to user space
> > > - PID change notification
> > > - Added patched/feedback provided by Loic Pallardy for:
> > > echo support improvement
> > > API improvements
> > >
> > > Let me know if there is any additional process for adding patches
> > beyond simply sending you the patch.
> > >
> > > P.S Just noticed you have a change to stm_omap_ti1.0.c that I did not
> > manage to update. Let me know if applying the patch causes you any
> > grief.
> > >
> > > Thanks,
> > > Doug
> >
> >
> > --
> > Andy Green | TI Landing Team Leader
> > Linaro.org │ Open source software for ARM SoCs | Follow Linaro
> > http://facebook.com/pages/Linaro/155974581091106 -
> > http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
>
On 14 May 2012 14:46, Andy Green <andy.green(a)linaro.org> wrote:
> On 14/05/12 21:41, Somebody in the thread at some point said:
>
> Hi -
>
>
> The commit to my clone was right after "config tilt stm and omap driver"
>> on tracking-topic-stm. I used "git format-patch -1" to generate the
>> patch.
>>
>> I sent my patch before Ryan's showed up on the landing team site.
>>
>
> OK I'll have another go at gluing it on tomorrow, unless Ryan prefers to
> deal with it. I had Ryan's patches locally for a couple of weeks but was
> unable to push tracking for several days due to crash bugs I fixed late
> last week.
Andy, you can just remove my patches from the tree if you like. I can send
you a fresh set of patches that apply cleanly over the STM topic when I
have something else for you to test.
As mentioned in the previous mail, my current set of patches just do some
debugging stuff and don't really constitute a "driver" for ARM's STM.
>
>
> The Framework driver is not using /sys in any way, just /debugfs, so
>> anything with /sys was added by Ryan.
>>
>
> You're quite right, if I looked a little further along I would have seen
> it's /sys/kernel/debugfs. Sorry for the noise.
>
>
> The Framework driver has always had a debugfs fops API. The first
>> release supported only character based messages, but the new patch
>> supports binary transfers using the same fops API. Trying to keep
>> it easy to use for both cases.
>>
>
> -Andy
>
>
>
> --
> Andy Green | TI Landing Team Leader
> Linaro.org │ Open source software for ARM SoCs | Follow Linaro
> http://facebook.com/pages/**Linaro/155974581091106<http://facebook.com/pages/Linaro/155974581091106> -
> http://twitter.com/#!/**linaroorg <http://twitter.com/#%21/linaroorg> -
> http://linaro.org/linaro-blog
>