* Re: Yosemite/440EP is there a global interrupt enable mask?
From: Eugene Surovegin @ 2006-01-25 20:13 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43D7D5A1.70704@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 11:46:41AM -0800, David Hawkins wrote:
> Hi Eugene,
>
> >>Now while looking at some of the other drivers, I noticed the use
> >>of the following syntax:
> >>
> >> unsigned long flags;
> >> local_irq_save(flags);
> >>
> >> ... mfdcr, mtdcr, etc operations ...
> >>
> >> local_irq_restore(flags);
> >>
> >>which is treating the operations on the DCRs as a critical section.
> >>
> >>I should probably be doing the same when I enable the external IRQs
> >>and modify the GPIO registers.
> >
> >You have to use locks if you access GPIO registers, because other bits
> >can be used by other device drivers, although there is no drivers in
> >the official tree which use GPIO (I have tons of them in my private
> >tree and I added global "gpio_lock" to serialize GPIO access).
>
> What kind of global lock; a spinlock?
yes, spinlock.
> What is the advantage of say using the gpio_lock, rather than
> the irq_save/restore sequence above - which is what is used in
> the emac and usb code?
emac doesn't use GPIO registers :). Also, if there is no IRQ code
accesses GPIO registers, you don't need IRQ disabling lock, and
spin_lock effectively becomes just a preemption lock. Personally, I use
spinlocks just out of habit, I think it's a good style, even if you
know your chip doesn't support SMP (but some day might :).
> >DCRs are a little different, there are separate DCR for different
> >peripherals, so generally, you don't have to use locks, because those
> >DCR accesses are implicitly bound to particular device anyway and
> >device "owns" them.
>
> Right, but I was accessing the DCR for the UIC status register,
> which, I assume, is also used by the Linux IRQ handling subsystem.
DO NOT access UIC registers directly. DO NOT.
> Well, ok perhaps that is not a good example, I have not tested
> whether the IRQ handler in the example code I posted needs to
> clear the UIC1_SR bit, or whether the Linux IRQ handling code
> already takes care of it. I suspect the latter, since the IRQ
> could be shared, and Linux needs to go through and call all
> handlers on that IRQ line.
>
> But in a debug context of reading those registers, I would
> expect some form of lock holding would be recommended.
> Do you happen to know if the Linux IRQ handling code uses a
> lock?
4xx IRQ code takes care of all this. You don't need to mess with UIC
registers. 4xx PIC code doesn't use locks because it's being called
from special context (IRQs disabled), 4xx doesn't support SMP and PIC
code "owns" those DCRs.
> I'm just learning, so feel free to enlighten me.
>
> What drivers do you have in your 'private' tree that you might
> be willing to share?
Nothing that can be of interest for a general public. They are
board-specific (lots of bit-banging SPI stuff). All other drivers I
wrote are already in public tree.
--
Eugene
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Russell King @ 2006-01-25 20:02 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Chris Zankel,
dev-etrax, ultralinux, linux-m68k, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060125113206.GD18584@miraclelinux.com>
On Wed, Jan 25, 2006 at 08:32:06PM +0900, Akinobu Mita wrote:
> +#ifndef HAVE_ARCH___FFS_BITOPS
> +
> +/**
> + * __ffs - find first bit in word.
> + * @word: The word to search
> + *
> + * Returns 0..BITS_PER_LONG-1
> + * Undefined if no bit exists, so code should check against 0 first.
> + */
> +static inline unsigned long __ffs(unsigned long word)
> {
> - int mask;
> + int b = 0, s;
>
> - addr += nr >> 5;
> - mask = 1 << (nr & 0x1f);
> - return ((mask & *addr) != 0);
> +#if BITS_PER_LONG == 32
> + s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
> + s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
> + s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
> + s = 2; if (word << 30 != 0) s = 0; b += s; word >>= s;
> + s = 1; if (word << 31 != 0) s = 0; b += s;
> +
> + return b;
> +#elif BITS_PER_LONG == 64
> + s = 32; if (word << 32 != 0) s = 0; b += s; word >>= s;
> + s = 16; if (word << 48 != 0) s = 0; b += s; word >>= s;
> + s = 8; if (word << 56 != 0) s = 0; b += s; word >>= s;
> + s = 4; if (word << 60 != 0) s = 0; b += s; word >>= s;
> + s = 2; if (word << 62 != 0) s = 0; b += s; word >>= s;
> + s = 1; if (word << 63 != 0) s = 0; b += s;
> +
> + return b;
> +#else
> +#error BITS_PER_LONG not defined
> +#endif
This code generates more expensive shifts than our (ARMs) existing C
version. This is a backward step.
Basically, shifts which depend on a variable are more expensive than
constant-based shifts.
I've not really looked at the rest because I haven't figured out which
bits will be used on ARM and which won't - which I think is another
problem with this patch set. I'll look again later tonight.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* RE: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Chen, Kenneth W @ 2006-01-25 20:02 UTC (permalink / raw)
To: 'Geert Uytterhoeven'
Cc: Akinobu Mita, linux-m68k, linux-ia64, ultralinux,
Linux Kernel Development, Andi Kleen, Linux/PPC Development,
sparclinux, linux390, linuxsh-dev, parisc-linux
In-Reply-To: <Pine.LNX.4.62.0601251814350.19174@pademelon.sonytel.be>
Geert Uytterhoeven wrote on Wednesday, January 25, 2006 9:19 AM
> > I don't think you need to change the flags size.
>
> Passing a pointer to a 32-bit entity to a function that takes a
> pointer to a 64-bit entity is a classical endianness bug. So it's
> better to change it, before people copy the code to a big endian
> platform.
Well, x86-64 and linux-ia64 both use little endian. I don't
understand why you are barking at us with big endian issue.
- Ken
Side-note: cc list trimmed.
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: David Hawkins @ 2006-01-25 19:46 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060125185518.GB7425@gate.ebshome.net>
Hi Eugene,
>>Now while looking at some of the other drivers, I noticed the use
>>of the following syntax:
>>
>> unsigned long flags;
>> local_irq_save(flags);
>>
>> ... mfdcr, mtdcr, etc operations ...
>>
>> local_irq_restore(flags);
>>
>>which is treating the operations on the DCRs as a critical section.
>>
>>I should probably be doing the same when I enable the external IRQs
>>and modify the GPIO registers.
>
> You have to use locks if you access GPIO registers, because other bits
> can be used by other device drivers, although there is no drivers in
> the official tree which use GPIO (I have tons of them in my private
> tree and I added global "gpio_lock" to serialize GPIO access).
What kind of global lock; a spinlock?
What is the advantage of say using the gpio_lock, rather than
the irq_save/restore sequence above - which is what is used in
the emac and usb code?
> DCRs are a little different, there are separate DCR for different
> peripherals, so generally, you don't have to use locks, because those
> DCR accesses are implicitly bound to particular device anyway and
> device "owns" them.
Right, but I was accessing the DCR for the UIC status register,
which, I assume, is also used by the Linux IRQ handling subsystem.
Well, ok perhaps that is not a good example, I have not tested
whether the IRQ handler in the example code I posted needs to
clear the UIC1_SR bit, or whether the Linux IRQ handling code
already takes care of it. I suspect the latter, since the IRQ
could be shared, and Linux needs to go through and call all
handlers on that IRQ line.
But in a debug context of reading those registers, I would
expect some form of lock holding would be recommended.
Do you happen to know if the Linux IRQ handling code uses a
lock?
I'm just learning, so feel free to enlighten me.
What drivers do you have in your 'private' tree that you might
be willing to share?
I'm planning on putting the 440EP on custom boards with a
number of Altera FPGAs located in the peripheral bus. I'll
post results and code as I go. Ulimately I'll open-source
the lot (hardware and all).
Here's the existing hardware I'm revising:
http://www.ovro.caltech.edu/~dwh/correlator
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Eugene Surovegin @ 2006-01-25 19:48 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43D7D334.3070709@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 11:36:20AM -0800, David Hawkins wrote:
[snip]
> I haven't looked for it yet, but do you know if there is a driver
> for the Yosemite board I2C temperature sensor already written?
I have no idea what temp sensor is used in this board, but it's very
likely that lm-sensors project already has a driver for it (look
under Drivers/Hardware Monitoring support).
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-25 19:36 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060125185131.GA7425@gate.ebshome.net>
Hi Eugene,
>
> use in_/out_ accessors, not pointers. Look at other 4xx drivers (i2c,
> emac)
>
> Also, you don't have worry about this code being non-portable, because
> every chip has it's own GPIO impl anyway.
>
Thanks for the feedback.
I haven't looked for it yet, but do you know if there is a driver
for the Yosemite board I2C temperature sensor already written?
If its not, that might be a nice little exercise for me.
Thanks,
Dave
^ permalink raw reply
* Re: 2.4.x vs 2.6.x performance
From: Otto Solares @ 2006-01-25 18:41 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <c8c05211d33576b79dee80725822322b@embeddedalley.com>
On Wed, Jan 25, 2006 at 07:45:38AM -0800, Dan Malek wrote:
> I wouldn't say "considerably" slower, but there are some
> performance differences. It's most evident on the
> smaller, slower processors, like the 8xx, but we have
> taken steps to alleviate that. The problem is 2.6 is just
> bigger with more stuff in it. You want the new features,
> you have to pay for that somewhere. I think it would
> help if the kernel was a little more configurable for
> embedded systems. It seems there is just too much
> stuff in a basic kernel that I wish could be stripped out.
Many things can be stripped out with LinuxTiny patches:
http://www.selenic.com/linux-tiny/
-otto
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: Eugene Surovegin @ 2006-01-25 18:55 UTC (permalink / raw)
To: David Hawkins; +Cc: Stefan Roese, linuxppc-embedded
In-Reply-To: <43D7C3C6.8020709@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 10:30:30AM -0800, David Hawkins wrote:
>
> Hi Stephan,
>
> > You seem to have used the wrong IRQ number though. Please see below.
> >
> > You are using the "External IRQ 8". This results in IRQ number 19 of the 2nd
> > interrupt controller of the 440ep. So please try (19+32) as the IRQ number
> > upon requesting the interrupt.
>
> Yep, that was it!
>
> Now while looking at some of the other drivers, I noticed the use
> of the following syntax:
>
> unsigned long flags;
> local_irq_save(flags);
>
> ... mfdcr, mtdcr, etc operations ...
>
> local_irq_restore(flags);
>
> which is treating the operations on the DCRs as a critical section.
>
> I should probably be doing the same when I enable the external IRQs
> and modify the GPIO registers.
You have to use locks if you access GPIO registers, because other bits
can be used by other device drivers, although there is no drivers in
the official tree which use GPIO (I have tons of them in my private
tree and I added global "gpio_lock" to serialize GPIO access).
DCRs are a little different, there are separate DCR for different
peripherals, so generally, you don't have to use locks, because those
DCR accesses are implicitly bound to particular device anyway and
device "owns" them.
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Eugene Surovegin @ 2006-01-25 18:51 UTC (permalink / raw)
To: David Hawkins; +Cc: Stefan Roese, linuxppc-embedded
In-Reply-To: <43D7C2EF.5060508@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 10:26:55AM -0800, David Hawkins wrote:
> Hi Stefan,
>
> >>readl() and ioread32() read the registers in little-endian format!
> >
> > Correct. That's how it is implemented on all platforms. Think for example of
> > an pci device driver. Using these IO functions, the driver will become
> > platform independent, running without modifications on little- and big-endian
> > machines.
>
> Ok, I figured that was probably the case. Thanks for the confirmation.
>
> >>Should I just be using pointers for remapped processor
> >>registers, and only use readl(), ioread32(), etc, on external
> >>memory?
> >
> > That's how I do it. Only use readl() and friends for pci spaces (or other
> > little endian memory mapped areas).
>
> I took a look at the Yosemite network and USB drivers, it looks like
> the authors of those drivers chose to use in_be32() and out_be32().
>
> Personally I like the concept of using pointers, or more usefully
> pointers to structure overlays for device control. However, the
> impression I have is that this is inherently more non-portable
> than using the readl()/writel(), ioread32()/iowrite32(), and
> now I guess I can add in_be32()/out_be32() to that list.
>
> But if you use pointers, thats good enough for me!
use in_/out_ accessors, not pointers. Look at other 4xx drivers (i2c,
emac)
Also, you don't have worry about this code being non-portable, because
every chip has it's own GPIO impl anyway.
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: David Hawkins @ 2006-01-25 18:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601251128.05370.sr@denx.de>
Hi Stephan,
> You seem to have used the wrong IRQ number though. Please see below.
>
> You are using the "External IRQ 8". This results in IRQ number 19 of the 2nd
> interrupt controller of the 440ep. So please try (19+32) as the IRQ number
> upon requesting the interrupt.
Yep, that was it!
Now while looking at some of the other drivers, I noticed the use
of the following syntax:
unsigned long flags;
local_irq_save(flags);
... mfdcr, mtdcr, etc operations ...
local_irq_restore(flags);
which is treating the operations on the DCRs as a critical section.
I should probably be doing the same when I enable the external IRQs
and modify the GPIO registers.
Any comments on that?
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-25 18:26 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601251057.47619.sr@denx.de>
Hi Stefan,
>>readl() and ioread32() read the registers in little-endian format!
>
> Correct. That's how it is implemented on all platforms. Think for example of
> an pci device driver. Using these IO functions, the driver will become
> platform independent, running without modifications on little- and big-endian
> machines.
Ok, I figured that was probably the case. Thanks for the confirmation.
>>Should I just be using pointers for remapped processor
>>registers, and only use readl(), ioread32(), etc, on external
>>memory?
>
> That's how I do it. Only use readl() and friends for pci spaces (or other
> little endian memory mapped areas).
I took a look at the Yosemite network and USB drivers, it looks like
the authors of those drivers chose to use in_be32() and out_be32().
Personally I like the concept of using pointers, or more usefully
pointers to structure overlays for device control. However, the
impression I have is that this is inherently more non-portable
than using the readl()/writel(), ioread32()/iowrite32(), and
now I guess I can add in_be32()/out_be32() to that list.
But if you use pointers, thats good enough for me!
Cheers
Dave
^ permalink raw reply
* RE: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Geert Uytterhoeven @ 2006-01-25 17:19 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: Linux/MIPS Development, linux-m68k, linux-ia64, Ian Molton,
Andi Kleen, David Howells, Linux/PPC Development, Greg Ungerer,
sparclinux, Miles Bader, Yoshinori Sato, Hirokazu Takata,
linuxsh-shmedia-dev, Linus Torvalds, Ivan Kokshaysky,
Richard Henderson, Akinobu Mita, Chris Zankel, dev-etrax,
ultralinux, Linux Kernel Development, linuxsh-dev, linux390,
Russell King, parisc-linux
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB509780224@scsmsx401.amr.corp.intel.com>
On Wed, 25 Jan 2006, Chen, Kenneth W wrote:
> Geert Uytterhoeven wrote on Wednesday, January 25, 2006 4:29 AM
> > On Wed, 25 Jan 2006, Akinobu Mita wrote:
> > > If the arechitecture is
> > > - BITS_PER_LONG == 64
> > > - struct thread_info.flag 32 is bits
> > > - second argument of test_bit() was void *
> > >
> > > Then compiler print error message on test_ti_thread_flags()
> > > in include/linux/thread_info.h
> > >
> > > Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
> > > ---
> > > thread_info.h | 2 +-
> > > 1 files changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Index: 2.6-git/include/linux/thread_info.h
> > > ===================================================================
> > > --- 2.6-git.orig/include/linux/thread_info.h 2006-01-25
> 19:07:12.000000000 +0900
> > > +++ 2.6-git/include/linux/thread_info.h 2006-01-25
> 19:14:26.000000000 +0900
> > > @@ -49,7 +49,7 @@
> > >
> > > static inline int test_ti_thread_flag(struct thread_info *ti, int
> flag)
> > > {
> > > - return test_bit(flag,&ti->flags);
> > > + return test_bit(flag, (void *)&ti->flags);
> > > }
> >
> > This is not safe. The bitops are defined to work on unsigned long
> only, so
> > flags should be changed to unsigned long instead, or you should use a
> > temporary.
> >
> > Affected platforms:
> > - alpha: flags is unsigned int
> > - ia64, sh, x86_64: flags is __u32
> >
> > The only affected 64-platforms are little endian, so it will silently
> work
> > after your change, though...
>
> I thought test_bit can operate on array beyond unsigned long.
> It's perfectly legitimate to do: test_bit(999, bit_array) as
> long as bit_array is indeed big enough to hold 999 bits. It
> is the responsibility of the caller to make sure that the
> underlying array is big enough for the bit that is being tested.
Yes, it can operate on arrays of unsigned long.
> I don't think you need to change the flags size.
Passing a pointer to a 32-bit entity to a function that takes a pointer to a
64-bit entity is a classical endianness bug. So it's better to change it,
before people copy the code to a big endian platform.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Chen, Kenneth W @ 2006-01-25 17:08 UTC (permalink / raw)
To: Geert Uytterhoeven, Akinobu Mita
Cc: Linux/MIPS Development, linux-m68k, linux-ia64, Ian Molton,
Andi Kleen, David Howells, Linux/PPC Development, Greg Ungerer,
sparclinux, Miles Bader, Yoshinori Sato, Hirokazu Takata,
linuxsh-shmedia-dev, Linus Torvalds, Ivan Kokshaysky,
Richard Henderson, Chris Zankel, dev-etrax, ultralinux,
Linux Kernel Development, linuxsh-dev, linux390, Russell King,
parisc-linux
Geert Uytterhoeven wrote on Wednesday, January 25, 2006 4:29 AM
> On Wed, 25 Jan 2006, Akinobu Mita wrote:
> > If the arechitecture is
> > - BITS_PER_LONG =3D=3D 64
> > - struct thread_info.flag 32 is bits
> > - second argument of test_bit() was void *
> >=20
> > Then compiler print error message on test_ti_thread_flags()
> > in include/linux/thread_info.h
> >=20
> > Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
> > ---
> > thread_info.h | 2 +-
> > 1 files changed, 1 insertion(+), 1 deletion(-)
> >=20
> > Index: 2.6-git/include/linux/thread_info.h
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- 2.6-git.orig/include/linux/thread_info.h 2006-01-25
19:07:12.000000000 +0900
> > +++ 2.6-git/include/linux/thread_info.h 2006-01-25
19:14:26.000000000 +0900
> > @@ -49,7 +49,7 @@
> > =20
> > static inline int test_ti_thread_flag(struct thread_info *ti, int
flag)
> > {
> > - return test_bit(flag,&ti->flags);
> > + return test_bit(flag, (void *)&ti->flags);
> > }
>=20
> This is not safe. The bitops are defined to work on unsigned long
only, so
> flags should be changed to unsigned long instead, or you should use a
> temporary.
>=20
> Affected platforms:
> - alpha: flags is unsigned int
> - ia64, sh, x86_64: flags is __u32
>=20
> The only affected 64-platforms are little endian, so it will silently
work
> after your change, though...
I thought test_bit can operate on array beyond unsigned long.
It's perfectly legitimate to do: test_bit(999, bit_array) as
long as bit_array is indeed big enough to hold 999 bits. It
is the responsibility of the caller to make sure that the
underlying array is big enough for the bit that is being tested.
I don't think you need to change the flags size.
- Ken
^ permalink raw reply
* Re: Enable Billionton PCMCIA Bluetooth in MPC860 system (again)
From: Lo Chun Chung @ 2006-01-25 16:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]
I also found a such message here: http://ozlabs.org/pipermail/linuxppc-embedded/2000-May/001402.html
it says:
"... The 8250/16550 driver (serial.c) probes at init-time which will cause
problems. .... "
I want to know are there anyone fixed this problem?
Thanks all.
Best regards,
Lo Chun Chung
Lo Chun Chung <lcsquare2@yahoo.com.hk> 說：
Dear all,
Hi again, I have asked a same question here before (http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021617.html), now I have some discoveries ... but I still do not know how to solve.
(My system is a MPC860 Processor Card, plus a custom made PCB to provide a PCMCIA interface, now the latest progress is I can use PCMCIA WLAN cards in this system without any problem. But my main target is use a PCMCIA Bluetooth card ... )
I have noticed when I load up the "serial.o", function "rs_init" must be executed, inside this function call, a function "autoconfig" will be called.
My problem is due to this "autoconfig", it will try to parse a standard uart to determine what is its model. But my case is my standard uart is a PCMCIA Bluetooth Card.
I can simply comment out the function "rs_init" to let the "serial.o" do not run this function. But later when I load the module "serial_cs", many problems happened. (seems "rs_init" will initialize other things that I have not done ...)
Since "serial_cs" (the pcmcia uart driver) needs two function calls in "serial.o" (they are: resgister_serial() and unregister_serial() ), so I really need load up "serial.o" before I can load up "serial_cs.o"
So my problem is, how can I setup such driver in MPC860 environment with a PCMCIA ?
Thanks all~
Best regards,
Chung
Best regards,
Chung _______________________________________
YM - 離線訊息
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
http://messenger.yahoo.com.hk
_______________________________________
YM - 離線訊息
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
http://messenger.yahoo.com.hk
[-- Attachment #2: Type: text/html, Size: 2856 bytes --]
^ permalink raw reply
* Re: Misunderstanding with function cpm_dpalloc in Linux 2.6.x
From: Pantelis Antoniou @ 2006-01-25 16:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000001c621b5$f8e45ab0$5201a8c0@GEG2400>
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
On Wednesday 25 January 2006 15:48, Laurent Lagrange wrote:
>
> Hello,
>
> I work on MPC boards with Linux 2.6.9 and I have a problem with the
> cpm_dpalloc function.
>
> In the file cpm2_common.c the function "uint cpm_dpalloc(uint size, uint
> align)" is intended
> to allocate a piece of memory in the dpram. This piece of memory has at
> least "size" bytes
> and I beleived that the returned address should be aligned on "align" bytes.
>
> This function calls "void *rh_alloc(rh_info_t * info, int size, const char
> *owner)" from rheap.c file.
> In this function the alignment is only used to calculate the right size with
> the formula :
> size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
> It seems to be right but the alignment is not used to retreive an aligned
> start address.
>
> So if I do the following sequential calls, I have the following results :
> cpm_dpalloc(16, 8) -> 0XC0 -> right aligned
> cpm_dpalloc(64, 64) -> 0XD0 -> wrong aligned -> must be 0x100
> cpm_dpalloc(16, 8) -> 0X110 -> right aligned but wrong to use
> cpm_dpalloc(24, 8) -> 0X1200 -> right aligned but wrong to use
>
> I can have the wanted values if instead of size, I try to allocate (size +
> align - 1) bytes
> but I don't think it is the solution.
>
> Perhaps, I don't understand the allocation theory.
> Any idea ?
>
> Thanks all
> Laurent
>
>
Laurent Hi,
Yes this is a know bug. This patch fixes it.
Marcelo, please apply - we have this hanging for quite a while.
Pantelis
[-- Attachment #2: cpm2-dpalloc.patch --]
[-- Type: text/x-diff, Size: 4160 bytes --]
diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignment - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+ start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
EXPORT_SYMBOL(cpm_dpfree);
/* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
{
void *start;
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
extern cpm8xx_t *cpmp; /* Pointer to comm processor */
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern cpm_cpm2_t *cpmp; /* Pointer to
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t *
/* Detach a free region */
extern void *rh_detach_region(rh_info_t * info, void *start, int size);
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+ const char *owner);
+
/* Allocate the given size from the remote heap */
extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
^ permalink raw reply
* Re: Trouble with SMC serial port in ppc/boot/simple on Embedded Planet8248 board
From: Laurent Pinchart @ 2006-01-25 16:09 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB942B7F8@ep-01.EmbeddedPlanet.local>
> > I'm trying to port the Linux kernel (2.6.15.1) to the
> > Embedded Planet 8248 board. The board has a proprietary boot
> > loader and uses SMC1 has a serial console.
>
> Do you have SCC1 enabled also? In arch/ppc/boot/simple/m8260_tty.c you
> will see that if SCC1 is enabled the early text tries to print to it,
> even if SMC1 is selected as the console in the config. That was about
> the only trick to do to get the early text.
I commented that line to fix the problem, and I was thinking about either a
configuration option (CONFIG_SERIAL_CONSOLE_SCCx and
CONFIG_SERIAL_CONSOLE_SMCx) or a macro in the platform-specifix header file
to override that. Any comment ?
Laurent Pinchart
^ permalink raw reply
* Enable Billionton PCMCIA Bluetooth in MPC860 system (again)
From: Lo Chun Chung @ 2006-01-25 16:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]
Dear all,
Hi again, I have asked a same question here before (http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021617.html), now I have some discoveries ... but I still do not know how to solve.
(My system is a MPC860 Processor Card, plus a custom made PCB to provide a PCMCIA interface, now the latest progress is I can use PCMCIA WLAN cards in this system without any problem. But my main target is use a PCMCIA Bluetooth card ... )
I have noticed when I load up the "serial.o", function "rs_init" must be executed, inside this function call, a function "autoconfig" will be called.
My problem is due to this "autoconfig", it will try to parse a standard uart to determine what is its model. But my case is my standard uart is a PCMCIA Bluetooth Card.
I can simply comment out the function "rs_init" to let the "serial.o" do not run this function. But later when I load the module "serial_cs", many problems happened. (seems "rs_init" will initialize other things that I have not done ...)
Since "serial_cs" (the pcmcia uart driver) needs two function calls in "serial.o" (they are: resgister_serial() and unregister_serial() ), so I really need load up "serial.o" before I can load up "serial_cs.o"
So my problem is, how can I setup such driver in MPC860 environment with a PCMCIA ?
Thanks all~
Best regards,
Chung
Best regards,
Chung
_______________________________________
YM - 離線訊息
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
http://messenger.yahoo.com.hk
[-- Attachment #2: Type: text/html, Size: 1907 bytes --]
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Laurent Pinchart @ 2006-01-25 16:02 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <bc2424c0c5f69931784ea76791f8ee39@embeddedalley.com>
> > Should I submit a patch, or leave the code as it is ?
>
> Port Das U-Boot.
Of course, that's another solution. We will use Das U-Boot for our custom
design.
What I wanted to do here is completely different. As the board comes with a
proprietary boot loader, I thought it would be interesting for future users
to have the board supported in the vanilla kernel, like many other boards
are. Is that a mistake ?
Laurent Pinchart
^ permalink raw reply
* Re: 2.4.x vs 2.6.x performance
From: Frank @ 2006-01-25 15:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <c8c05211d33576b79dee80725822322b@embeddedalley.com>
--- Dan MaleMalekn@daneembeddedalley> wrote:
>
> On Jan 22, 2006, at 8:24 PM, Frank wrote:
>
> > I remember reading a while back that the 2.6 kernel is
> > considerably slower
>
> I wouldn't say "considerably" slower, but there are some
> performance differences. It's most evident on the
> smaller, slower processors, like the 8xx, but we have
> taken steps to alleviate that. The problem is 2.6 is just
> bigger with more stuff in it. You want the new features,
> you have to pay for that somewhere. I think it would
> help if the kernel was a little more configurable for
> embedded systems. It seems there is just too much
> stuff in a basic kernel that I wish could be stripped out.
>
> > I'm thinking about moving to 2.6 since a lot of open source
> > projects have stopped suposuporting 2.4 kernel.
>
> You know, this is a "community effort", not "when are you
> going to fix it for me" :-) Use 2.6, measure it using your
> application, and submit updates that improve it. Some of
> us have already done quite a bit, so do your part, too.
>
> Thanks.
>
> -- Dan
I wasn't implying problems with 2.6 kernel would preclude me
from using it and fixing problems. I just wanted to know what to
expect so I can adjust my schedule accordingly
Thanks for the reply...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Dan Malek @ 2006-01-25 15:48 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200601251215.10816.laurent.pinchart@tbox.biz>
On Jan 25, 2006, at 3:15 AM, Laurent Pinchart wrote:
> Should I submit a patch, or leave the code as it is ?
Port Das U-Boot.
-- Dan
^ permalink raw reply
* Re: 2.4.x vs 2.6.x performance
From: Dan Malek @ 2006-01-25 15:45 UTC (permalink / raw)
To: Frank; +Cc: linuxppc-embedded
In-Reply-To: <20060123042413.806.qmail@web32201.mail.mud.yahoo.com>
On Jan 22, 2006, at 8:24 PM, Frank wrote:
> I remember reading a while back that the 2.6 kernel is
> considerably slower
I wouldn't say "considerably" slower, but there are some
performance differences. It's most evident on the
smaller, slower processors, like the 8xx, but we have
taken steps to alleviate that. The problem is 2.6 is just
bigger with more stuff in it. You want the new features,
you have to pay for that somewhere. I think it would
help if the kernel was a little more configurable for
embedded systems. It seems there is just too much
stuff in a basic kernel that I wish could be stripped out.
> I'm thinking about moving to 2.6 since a lot of open source
> projects have stopped suporting the 2.4 kernel.
You know, this is a "community effort", not "when are you
going to fix it for me" :-) Use 2.6, measure it using your
application, and submit updates that improve it. Some of
us have already done quite a bit, so do your part, too.
Thanks.
-- Dan
^ permalink raw reply
* Misunderstanding with function cpm_dpalloc in Linux 2.6.x
From: Laurent Lagrange @ 2006-01-25 13:48 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I work on MPC boards with Linux 2.6.9 and I have a problem with the
cpm_dpalloc function.
In the file cpm2_common.c the function "uint cpm_dpalloc(uint size, uint
align)" is intended
to allocate a piece of memory in the dpram. This piece of memory has at
least "size" bytes
and I beleived that the returned address should be aligned on "align" bytes.
This function calls "void *rh_alloc(rh_info_t * info, int size, const char
*owner)" from rheap.c file.
In this function the alignment is only used to calculate the right size with
the formula :
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
It seems to be right but the alignment is not used to retreive an aligned
start address.
So if I do the following sequential calls, I have the following results :
cpm_dpalloc(16, 8) -> 0XC0 -> right aligned
cpm_dpalloc(64, 64) -> 0XD0 -> wrong aligned -> must be 0x100
cpm_dpalloc(16, 8) -> 0X110 -> right aligned but wrong to use
cpm_dpalloc(24, 8) -> 0X1200 -> right aligned but wrong to use
I can have the wanted values if instead of size, I try to allocate (size +
align - 1) bytes
but I don't think it is the solution.
Perhaps, I don't understand the allocation theory.
Any idea ?
Thanks all
Laurent
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Geert Uytterhoeven @ 2006-01-25 12:28 UTC (permalink / raw)
To: Akinobu Mita
Cc: Linux/MIPS Development, linux-m68k, linux-ia64, Ian Molton,
Andi Kleen, David Howells, Linux/PPC Development, Greg Ungerer,
sparclinux, Miles Bader, Yoshinori Sato, Hirokazu Takata,
linuxsh-shmedia-dev, Linus Torvalds, Ivan Kokshaysky,
Richard Henderson, Chris Zankel, dev-etrax, ultralinux,
Linux Kernel Development, linuxsh-dev, linux390, Russell King,
parisc-linux
In-Reply-To: <20060125113446.GF18584@miraclelinux.com>
On Wed, 25 Jan 2006, Akinobu Mita wrote:
> If the arechitecture is
> - BITS_PER_LONG == 64
> - struct thread_info.flag 32 is bits
> - second argument of test_bit() was void *
>
> Then compiler print error message on test_ti_thread_flags()
> in include/linux/thread_info.h
>
> Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
> ---
> thread_info.h | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> Index: 2.6-git/include/linux/thread_info.h
> ===================================================================
> --- 2.6-git.orig/include/linux/thread_info.h 2006-01-25 19:07:12.000000000 +0900
> +++ 2.6-git/include/linux/thread_info.h 2006-01-25 19:14:26.000000000 +0900
> @@ -49,7 +49,7 @@
>
> static inline int test_ti_thread_flag(struct thread_info *ti, int flag)
> {
> - return test_bit(flag,&ti->flags);
> + return test_bit(flag, (void *)&ti->flags);
> }
This is not safe. The bitops are defined to work on unsigned long only, so
flags should be changed to unsigned long instead, or you should use a
temporary.
Affected platforms:
- alpha: flags is unsigned int
- ia64, sh, x86_64: flags is __u32
The only affected 64-platforms are little endian, so it will silently work
after your change, though...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 001/001 Updated again] PMAC HD runtime blinking control
From: Andreas Schwab @ 2006-01-25 12:44 UTC (permalink / raw)
To: Cedric Pradalier; +Cc: Linuxppc-dev
In-Reply-To: <20060125212702.360ba063.cedric.pradalier@inrialpes.fr>
Cedric Pradalier <cedric.pradalier@inrialpes.fr> writes:
> I tend to favor readability first in my coding.
linux-kernel@ has a different opinion.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Keith Owens @ 2006-01-25 11:54 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, Linus Torvalds,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, linux-m68k, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060125113206.GD18584@miraclelinux.com>
Akinobu Mita (on Wed, 25 Jan 2006 20:32:06 +0900) wrote:
>o generic {,test_and_}{set,clear,change}_bit() (atomic bitops)
...
>+static __inline__ void set_bit(int nr, volatile unsigned long *addr)
>+{
>+ unsigned long mask = BITOP_MASK(nr);
>+ unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
>+ unsigned long flags;
>+
>+ _atomic_spin_lock_irqsave(p, flags);
>+ *p |= mask;
>+ _atomic_spin_unlock_irqrestore(p, flags);
>+}
Be very, very careful about using these generic *_bit() routines if the
architecture supports non-maskable interrupts.
NMI events can occur at any time, including when interrupts have been
disabled by *_irqsave(). So you can get NMI events occurring while a
*_bit fucntion is holding a spin lock. If the NMI handler also wants
to do bit manipulation (and they do) then you can get a deadlock
between the original caller of *_bit() and the NMI handler.
Doing any work that requires spinlocks in an NMI handler is just asking
for deadlock problems. The generic *_bit() routines add a hidden
spinlock behind what was previously a safe operation. I would even say
that any arch that supports any type of NMI event _must_ define its own
bit routines that do not rely on your _atomic_spin_lock_irqsave() and
its hash of spinlocks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox