Re: [PATCH (updated)]: PTHREAD_PRIO_INHERIT support for ARM.

Hello George,

> > A few weeks we mailed about the PTHREAD_PRIO_INHERIT patch.
> Apologies, vacation and busy on other tasks, so did not get
> back to this.

No problem! ( I already expected this, I hope you had a nice vacation!)

> > BTW: I noticed that the pi_stress tool makes the system completely
> > hang while using your patch. Have you noticed this also already?
>
> Now that you point it out, yes, I've recently run pi_stress and believe
> I see what you're referring to.  I won't be able to look at this until
> next Tuesday but will reply one way or another then.

There is one thing more that keeps on bugging me here:
A spinlock is used in your patch. On non-RT the spinlock disables
interrupts, but on RT it is a mutex and thus preemptible.
The piece of code we are talking about is part of the slow-path of the
futex implementation, there is thus also a fast-path. So, this piece
of code can thus only work properly if the userspace memory (that is
modified here) is only modified  in this slow-path, and nowhere else.
So, the fast-path, implemented in gLibc may not touch this memory,
otherwise we have a race condition here.
Regardless of how it is implemented in gibc, taking the 'never trust
the user'-kernel principle into account, I think it is not wise to
depend such a kernel futex implementation on how the counterpart in
glibc is implemented; someone might want to build a PI-futex
implementation in uClibc or another C-library and do it different than
in glibc, not knowing the restrictions in this ARM specific code.

Re: MMC error on 2G SD card

Stefan Schmidt wrote:
> 2.6.11 is really old, makes no real sense to debug on such an old
> kernel I think. On our S3C2410 based phone we use 2.6.22.5 kernel with
> the s3cmci driver with some small fixes and it works stable. I also
> tested it with an 4GB microSDHC card and all worked well.
> 
> You can find our patches here:
> https://svn.openmoko.org/trunk/src/target/kernel/patches/
> 
> Everything with a s3c_mci praefix could be interesting for you.
> 
> We also talked with Pierre Ossman to get a review to get this patches
> upstream.
> 
> regards
> Stefan Schmidt

Thanks Stefan. I'll try the patches to fix old products. We'll move to 
kernel 2.6.22 indeed.

Jim

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

[PATCH] Generic, platform independent matrix keyboard support

Hello all,

I am resending this patch to ALKM, because I have
received no reply from "linux-input" mailing list
and I expect, that this driver would be mainly
interresting for embedded system developers.

Our board specific part registering device for generic
matrix keyboard driver can be found there

 http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/pimx1-board-kbd.patch

The driver has been tested in IRQ and non-IRQ driven mode with i.MX
optimized functions and in generic platform independent GPIO
support. Unfortunately GPIO layer does not provide ability
to control internal pullups for input, so there has been one
line i.MX specific modification necessary in gpiomatrix_setup()
to test generic code.

Original message to "linux-input" mailing list is there

http://article.gmane.org/gmane.linux.kernel.input/2768

Please, inform me, if some code, like this is acceptable
for mainline and what should be changed for its acceptance.

Best wishes

            Pavel Pisa

[PATCH] s3c2442: HP rx1950 machine addition

From: Krzysztof Helt <krzysztof.h1 <at> wp.pl>

This patch adds HP rx1950 PDA machine to the Linux kernel.

Signed-off-by: Krzysztof Helt <krzysztof.h1 <at> wp.pl>

---

This machine is cheap, low end PDA from HP. It is almost identical
to the HP rx3715 but uses the S3C2442 cpu instead of the S3C2440.

This can be the first machine with only Samsung S3C442 cpu
in the Linux kernel. The only other S3C2442 machine in the kernel tree
is SMDK2440 with S3C2442 cpu, which forces selection of the
S3C2440 cpu as well.

This patch was diff-ed against 2.6.23-rc4-mm1. It applies cleanly to the
2.6.23-rc5 as well but it won't compile with the framebuffer enabled. 
The 2.6.23-rc4-mm1 has patches for the new s3c2410 framebuffer.

Regards,
Krzysztof

diff -uNrp linux-2.6.23/arch/arm/mach-s3c2442/Kconfig linux-arm/arch/arm/mach-s3c2442/Kconfig
--- linux-2.6.23/arch/arm/mach-s3c2442/Kconfig	2007-08-09 17:39:53.538175828 +0200
+++ linux-arm/arch/arm/mach-s3c2442/Kconfig	2007-08-19 07:43:10.489367637 +0200
 <at>  <at>  -23,6 +23,12  <at>  <at>  config SMDK2440_CPU2442
 	depends on ARCH_S3C2440
 	select CPU_S3C2442

NOHZ: local_softirq_pending 20 - messages

Hi, I'm running an AT91RM9200 board with Linux-2.6.23-rc3 + at91 patch set.

I was doing some heavy network testing and occasionally I saw this message:

NOHZ: local_softirq_pending 20

Is this cause for concern?

I was testing an FTP transfer of a 100MB file via USB ethernet gadget to a 
device with an NFS rootfs.

i.e. PC -> USB -> Linux device -> ethernet -> NFS share

So it's a reasonable stress on the system. I sent the file about 10 times, each 
time the transfer was successful (checked with md5sum)

Possible .config settings that are relevant are:

CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_TIMERFD=y
CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_HZ=100

regards,

Aras Vaichas

[BUGFIX] fix access to CP15 auxiliary control reg in arch/arm/mach-pxa/sleep.S

Hi,

the code in arch/arm/mach-pxa/sleep.S uses an invalid opcode to access
the CP15 auxiliary register.
According to the PXA255/PXA270 Developers' Manuals the auxiliary
control register is accessed with 'opcode_2 = 1' and not 'CRm = 1' as
it is done in arch/arm/mach-pxa/sleep.S.

--- linux-2.6.23-rc5/arch/arm/mach-pxa/sleep.S.orig	2007-09-03 13:34:57.000000000 +0200
+++ linux-2.6.23-rc5/arch/arm/mach-pxa/sleep.S	2007-09-03 13:35:58.000000000 +0200
 <at>  <at>  -29,7 +29,7  <at>  <at>  pxa_cpu_save_cp:
 	mrc	p15, 0, r5, c13, c0, 0		 <at>  PID
 	mrc 	p15, 0, r6, c3, c0, 0		 <at>  domain ID
 	mrc 	p15, 0, r7, c2, c0, 0		 <at>  translation table base addr
-	mrc	p15, 0, r8, c1, c1, 0            <at>  auxiliary control reg
+	mrc	p15, 0, r8, c1, c0, 1            <at>  auxiliary control reg
 	mrc 	p15, 0, r9, c1, c0, 0		 <at>  control reg

 	bic	r3, r3, #2			 <at>  clear frequency change bit
 <at>  <at>  -242,7 +242,7  <at>  <at>  ENTRY(pxa_cpu_resume)
 	mcr	p15, 0, r5, c13, c0, 0		 <at>  PID
 	mcr 	p15, 0, r6, c3, c0, 0		 <at>  domain ID
 	mcr 	p15, 0, r7, c2, c0, 0		 <at>  translation table base addr
-	mcr	p15, 0, r8, c1, c1, 0            <at>  auxiliary control reg
+	mcr	p15, 0, r8, c1, c0, 1            <at>  auxiliary control reg
 	b	resume_turn_on_mmu		 <at>  cache align execution

 	.align 5

[RFC] [PATCH 0/4] PXA2xx clock API

Hi All,

This is a request for comments on a clock API implementation for PXA2xx.
Patch #1 is the core implementation, and then you will find a set of 3 PXA
drivers conversion examples. Before going further in the conversion task,
I wanted to get some feedback on the core part, but the goal here is to
eventually get rid of the pxa_set_cken() routines from the PXA code.

I also wanted to get some feedback from the pxa3xx people and see if this
is duplicating something they're currently working on. If not, then any
feedback about how this code would fit their architecture is welcome.

Cheers,
Samuel.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: [RFC] [PATCH 0/4] PXA2xx clock API

On Mon, Sep 03, 2007 at 05:26:43PM +0200, Samuel Ortiz wrote:
> I also wanted to get some feedback from the pxa3xx people and see if this
> is duplicating something they're currently working on. If not, then any
> feedback about how this code would fit their architecture is welcome.

You didn't check

 http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/arm:pxa.diff

first then.  Marvell and myself are working hard at the moment to get
PXA3 support merged, and the ground work for that is to clean up PXA2
support, which includes getting a proper clock API in place.

The PXA2 work is virtually complete - there's an UDC issue, and the
SSP, SPI and OHCI drivers remaining to complete the transition;
however I believe they're for others who understand those subsystems
to resolve; certainly SPI and OHCI do not lend themselves well to
conversion.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: [RFC] [PATCH 0/4] PXA2xx clock API

On Mon, Sep 03, 2007 at 05:47:23PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 03, 2007 at 05:26:43PM +0200, Samuel Ortiz wrote:
> > I also wanted to get some feedback from the pxa3xx people and see if this
> > is duplicating something they're currently working on. If not, then any
> > feedback about how this code would fit their architecture is welcome.
> 
> You didn't check
> 
>  http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/arm:pxa.diff
> 
> first then.
No I didn't. The last time someone posted a PXA clock related patch to
LAKML you replied this way:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-April/039221.html

which let me believe that PXA2 needed some clock API related work.

I didn't know about those git patch sets. Maybe you could add a link to
them from the arm.linux.org.uk developer section ?

Cheers,
Samuel.

> The PXA2 work is virtually complete - there's an UDC issue, and the
> SSP, SPI and OHCI drivers remaining to complete the transition;
> however I believe they're for others who understand those subsystems
> to resolve; certainly SPI and OHCI do not lend themselves well to
> conversion.

-------------------------------------------------------------------

Re: [RFC] [PATCH 0/4] PXA2xx clock API

On Mon, Sep 03, 2007 at 07:15:16PM +0200, Samuel Ortiz wrote:
> On Mon, Sep 03, 2007 at 05:47:23PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 03, 2007 at 05:26:43PM +0200, Samuel Ortiz wrote:
> > > I also wanted to get some feedback from the pxa3xx people and see if this
> > > is duplicating something they're currently working on. If not, then any
> > > feedback about how this code would fit their architecture is welcome.
> > 
> > You didn't check
> > 
> >  http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/arm:pxa.diff
> > 
> > first then.
> No I didn't. The last time someone posted a PXA clock related patch to
> LAKML you replied this way:

Well, circumstances change.  I was trying to avoid being seen
*personally* as a replacement PXA maintainer - because that's what
will happen.

However, as I say, circumstances change, and consider that I'm
working on this for my *company*, not for me *personally*.

> I didn't know about those git patch sets. Maybe you could add a link to
> them from the arm.linux.org.uk developer section ?

The point of these patches is to provide a window on what's in my
tree(s).  They're not there to provide people with patch sets to
apply to their build trees.

Adding them to the website will lose this distinction.