Amit,
> On Fri, Sep 24, 2010 at 12:13 PM, Amit Kucheria
> wrote:
> Vishwa,
>
>
> > On 10 Sep 23, Vishwanath Sripathy wrote:
> > From: Vishwanath BS
> >
> > This patch series has some clean up in OMAP3 sleep code.
> >
> > Vishwanath BS (2):
> > OMAP3 PM: move omap3 sleep to ddr
> > OMAP3 PM:
Vishwa,
On 10 Sep 23, Vishwanath Sripathy wrote:
> From: Vishwanath BS
>
> This patch series has some clean up in OMAP3 sleep code.
>
> Vishwanath BS (2):
> OMAP3 PM: move omap3 sleep to ddr
> OMAP3 PM: sleep code clean up
>
> arch/arm/mach-omap2/pm34xx.c |9 +-
> arch/ar
Hi,
I've recently changed l-m-c to take an hwpack, which is installed before
the image is built. To keep that change simple I had to unpack the
binary tarball into a tmp directory, install the hwpack, repack the
tarball and then continue with the image generation. This extra
unpacking/repacking
Hi,
I've recently changed l-m-c to take an hwpack, which is installed before
the image is built. To keep that change simple I had to unpack the
binary tarball into a tmp directory, install the hwpack, repack the
tarball and then continue with the image generation. This extra
unpacking/repacking
On Thu, 23 Sep 2010, Catalin Marinas wrote:
> On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> > On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > > This highmem topic comes from the fact that highmem will be needed in
> > > > the period of time between now and LPAE where we hav
On Thursday 23 September 2010 19:03:42 Catalin Marinas wrote:
> On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> > On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > > This highmem topic comes from the fact that highmem will be needed in
> > > > the period of time between now and
On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > This highmem topic comes from the fact that highmem will be needed in
> > > the period of time between now and LPAE where we have boards with lots
> > > of memory but we can't addr
From: Vishwanath BS
This patch has done some clean up of omap3 sleep code.
Basically all possible hardcodings are removed.
Reorganized code into more logical buckets for better readability.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/sleep34xx.S | 375
From: Vishwanath BS
There is no need to keep omap3 sleep code in SRAM. This code can be run very
well on DDR. This would help us to instrument CPUIdle latencies.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+),
From: Vishwanath BS
This patch series has some clean up in OMAP3 sleep code.
Vishwanath BS (2):
OMAP3 PM: move omap3 sleep to ddr
OMAP3 PM: sleep code clean up
arch/arm/mach-omap2/pm34xx.c |9 +-
arch/arm/mach-omap2/sleep34xx.S | 375 ++-
On Thu, Sep 23, 2010, Arnd Bergmann wrote:
> The current state is mostly that people put unaligned partitions on their
> SD card, stick an ext3 fs on a partition and watch performance suck
> while destroying their cards.
Agreed :-)
> There has been a study by Thomas Gleixner on what CF cards do
On Thursday 23 September 2010, Nicolas Pitre wrote:
> > This highmem topic comes from the fact that highmem will be needed in
> > the period of time between now and LPAE where we have boards with lots
> > of memory but we can't address it all without highmem (unless we want
> > to revisit the 3
On Thursday 23 September 2010, Loïc Minier wrote:
> On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > Right. Having an intelligent file system is the only way I can see for
> > getting good speedups, by avoiding erase-cycles inside the SD card,
> > which commonly happen when you write to sectors at ra
On Thu, Sep 23, 2010 at 08:18:06AM +1200, Michael Hope wrote:
> >> I had been thinking about this as well, would you see more benefit for this
> >> to focus on testing the latest image, or qemu itself?
> >
> > I think the image (and the kernel) are going to churn at a much faster
> > rate than qemu
On Thu, Sep 23, 2010, Nicolas Pitre wrote:
> The runtime patching of the kernel is useful for simple and
> straight-forward cases such as SMP ops which are performed in assembly.
> But in this case I'm afraid this could add even more overhead in the
> end, especially when highmem is active. But
On Thu, Sep 23, 2010, Amit Arora wrote:
> BTW, which file system is it ? From last I know, fallocate was
> supported on only ext4, ocfs and xfs.
It's probably the linaro-media-create default, ext3, which we should at
least bump to ext4 I guess.
--
Loïc Minier
_
On Thu, 23 Sep 2010, Loïc Minier wrote:
> On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > > Wrt highmem: I can't see the link with highmem and SMP. As far as I
> > > know, highmem on ARM should be SMP safe already (the only SMP related
> > > issue I've seen has been fixed in commit 831e8047eb).
On Thu, 23 Sep 2010, Loïc Minier wrote:
> When you say SDIO, you mean just SDIO or SD and SDIO?
I wrote a driver for one SD/SDIO host controller, played with the code
for two other controllers, and wrote part of the SDIO stack. All this
share common infrastructure with pure SD cards. Hence m
On Thu, Sep 23, 2010 at 2:24 PM, Loïc Minier wrote:
> On Wed, Sep 22, 2010, Matt Waddel wrote:
>> fallocate01 1 TFAIL : fallocate(5, 0, 49152, 4096) failed:
>> TEST_ERRNO=EFBIG(27): File too large
>> fallocate01 2 TFAIL : fallocate(6, 1, 49152, 4096) failed:
>> TEST_ERRNO=EFBIG(27):
On Mon, Sep 20, 2010, Nicolas Pitre wrote:
> I'm also interested in both of those topics as 1) I participated in the
> design of the SDIO stack (closely related to SD), and 2) I did the
> highmem implementation for ARM.
(You're awesome! :-)
When you say SDIO, you mean just SDIO or SD and SDI
On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > Wrt highmem: I can't see the link with highmem and SMP. As far as I
> > know, highmem on ARM should be SMP safe already (the only SMP related
> > issue I've seen has been fixed in commit 831e8047eb).
>
> Right, it's not related to SMP, I was thinki
On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> Right. Having an intelligent file system is the only way I can see for
> getting good speedups, by avoiding erase-cycles inside the SD card,
> which commonly happen when you write to sectors at random addresses.
>
> There has been a lot of research in o
On Thu, Sep 23, 2010, Michael Hope wrote:
> To overdo things, it would be nice to mix the compiler in as well.
> I've been planning to add a test case to the compiler build that
> builds the current Ubuntu kernel and boots it inside QEMU.
I think we should have batteries of test cases of each com
The weekly report for the Linaro Infrastructure team may be found at:
Status report:
https://wiki.linaro.org/Platform/Infrastructure/Status/2010-09-23
Burndown
chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastructure.html
The burndown chart shows that a number of w
On Wed, Sep 22, 2010, Matt Waddel wrote:
> fallocate011 TFAIL : fallocate(5, 0, 49152, 4096) failed:
> TEST_ERRNO=EFBIG(27): File too large
> fallocate012 TFAIL : fallocate(6, 1, 49152, 4096) failed:
> TEST_ERRNO=EFBIG(27): File too large
> fallocate027 TFAIL : fallocate(tfil
25 matches
Mail list logo
