* 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
* [PATCH 2/6] use non atomic operations for minix_*_bit() and ext2_*_bit()
From: Akinobu Mita @ 2006-01-25 11:30 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, Ian Molton, David Howells, linuxppc-dev,
Greg Ungerer, sparclinux, Miles Bader, Linus Torvalds,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev, linux-m68k,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, Andi Kleen, linuxsh-dev, linux390, Russell King,
parisc-linux
In-Reply-To: <20060125112625.GA18584@miraclelinux.com>
Bitmap functions for the minix filesystem and the ext2 filesystem do not
require the atomic guarantees except ext2_set_bit_atomic() and
ext2_clear_bit_atomic().
But they are defined by using atomic bit operations on several architectures.
(h8300, ia64, mips, s390, sh, sh64, sparc, v850, and xtensa)
This patch switches to non atomic bit operation.
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
---
asm-h8300/bitops.h | 6 +++---
asm-ia64/bitops.h | 10 +++++-----
asm-mips/bitops.h | 6 +++---
asm-s390/bitops.h | 10 +++++-----
asm-sh/bitops.h | 16 +++++-----------
asm-sh64/bitops.h | 16 +++++-----------
asm-sparc/bitops.h | 6 +++---
asm-sparc64/bitops.h | 6 +++---
asm-v850/bitops.h | 10 +++++-----
asm-xtensa/bitops.h | 6 +++---
10 files changed, 40 insertions(+), 52 deletions(-)
Index: 2.6-git/include/asm-h8300/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-h8300/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-h8300/bitops.h 2006-01-25 19:14:01.000000000 +0900
@@ -397,9 +397,9 @@
}
/* Bitmap functions for the minix filesystem. */
-#define minix_test_and_set_bit(nr,addr) test_and_set_bit(nr,addr)
-#define minix_set_bit(nr,addr) set_bit(nr,addr)
-#define minix_test_and_clear_bit(nr,addr) test_and_clear_bit(nr,addr)
+#define minix_test_and_set_bit(nr,addr) __test_and_set_bit(nr,addr)
+#define minix_set_bit(nr,addr) __set_bit(nr,addr)
+#define minix_test_and_clear_bit(nr,addr) __test_and_clear_bit(nr,addr)
#define minix_test_bit(nr,addr) test_bit(nr,addr)
#define minix_find_first_zero_bit(addr,size) find_first_zero_bit(addr,size)
Index: 2.6-git/include/asm-ia64/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-ia64/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-ia64/bitops.h 2006-01-25 19:14:02.000000000 +0900
@@ -394,18 +394,18 @@
#define __clear_bit(nr, addr) clear_bit(nr, addr)
-#define ext2_set_bit test_and_set_bit
+#define ext2_set_bit __test_and_set_bit
#define ext2_set_bit_atomic(l,n,a) test_and_set_bit(n,a)
-#define ext2_clear_bit test_and_clear_bit
+#define ext2_clear_bit __test_and_clear_bit
#define ext2_clear_bit_atomic(l,n,a) test_and_clear_bit(n,a)
#define ext2_test_bit test_bit
#define ext2_find_first_zero_bit find_first_zero_bit
#define ext2_find_next_zero_bit find_next_zero_bit
/* Bitmap functions for the minix filesystem. */
-#define minix_test_and_set_bit(nr,addr) test_and_set_bit(nr,addr)
-#define minix_set_bit(nr,addr) set_bit(nr,addr)
-#define minix_test_and_clear_bit(nr,addr) test_and_clear_bit(nr,addr)
+#define minix_test_and_set_bit(nr,addr) __test_and_set_bit(nr,addr)
+#define minix_set_bit(nr,addr) __set_bit(nr,addr)
+#define minix_test_and_clear_bit(nr,addr) __test_and_clear_bit(nr,addr)
#define minix_test_bit(nr,addr) test_bit(nr,addr)
#define minix_find_first_zero_bit(addr,size) find_first_zero_bit(addr,size)
Index: 2.6-git/include/asm-mips/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-mips/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-mips/bitops.h 2006-01-25 19:14:05.000000000 +0900
@@ -956,9 +956,9 @@
* FIXME: These assume that Minix uses the native byte/bitorder.
* This limits the Minix filesystem's value for data exchange very much.
*/
-#define minix_test_and_set_bit(nr,addr) test_and_set_bit(nr,addr)
-#define minix_set_bit(nr,addr) set_bit(nr,addr)
-#define minix_test_and_clear_bit(nr,addr) test_and_clear_bit(nr,addr)
+#define minix_test_and_set_bit(nr,addr) __test_and_set_bit(nr,addr)
+#define minix_set_bit(nr,addr) __set_bit(nr,addr)
+#define minix_test_and_clear_bit(nr,addr) __test_and_clear_bit(nr,addr)
#define minix_test_bit(nr,addr) test_bit(nr,addr)
#define minix_find_first_zero_bit(addr,size) find_first_zero_bit(addr,size)
Index: 2.6-git/include/asm-s390/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-s390/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-s390/bitops.h 2006-01-25 19:14:05.000000000 +0900
@@ -871,11 +871,11 @@
*/
#define ext2_set_bit(nr, addr) \
- test_and_set_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr)
+ __test_and_set_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr)
#define ext2_set_bit_atomic(lock, nr, addr) \
test_and_set_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr)
#define ext2_clear_bit(nr, addr) \
- test_and_clear_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr)
+ __test_and_clear_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr)
#define ext2_clear_bit_atomic(lock, nr, addr) \
test_and_clear_bit((nr)^(__BITOPS_WORDSIZE - 8), (unsigned long *)addr)
#define ext2_test_bit(nr, addr) \
@@ -1014,11 +1014,11 @@
/* Bitmap functions for the minix filesystem. */
/* FIXME !!! */
#define minix_test_and_set_bit(nr,addr) \
- test_and_set_bit(nr,(unsigned long *)addr)
+ __test_and_set_bit(nr,(unsigned long *)addr)
#define minix_set_bit(nr,addr) \
- set_bit(nr,(unsigned long *)addr)
+ __set_bit(nr,(unsigned long *)addr)
#define minix_test_and_clear_bit(nr,addr) \
- test_and_clear_bit(nr,(unsigned long *)addr)
+ __test_and_clear_bit(nr,(unsigned long *)addr)
#define minix_test_bit(nr,addr) \
test_bit(nr,(unsigned long *)addr)
#define minix_find_first_zero_bit(addr,size) \
Index: 2.6-git/include/asm-sh/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-sh/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-sh/bitops.h 2006-01-25 19:14:06.000000000 +0900
@@ -339,8 +339,8 @@
}
#ifdef __LITTLE_ENDIAN__
-#define ext2_set_bit(nr, addr) test_and_set_bit((nr), (addr))
-#define ext2_clear_bit(nr, addr) test_and_clear_bit((nr), (addr))
+#define ext2_set_bit(nr, addr) __test_and_set_bit((nr), (addr))
+#define ext2_clear_bit(nr, addr) __test_and_clear_bit((nr), (addr))
#define ext2_test_bit(nr, addr) test_bit((nr), (addr))
#define ext2_find_first_zero_bit(addr, size) find_first_zero_bit((addr), (size))
#define ext2_find_next_zero_bit(addr, size, offset) \
@@ -349,30 +349,24 @@
static __inline__ int ext2_set_bit(int nr, volatile void * addr)
{
int mask, retval;
- unsigned long flags;
volatile unsigned char *ADDR = (unsigned char *) addr;
ADDR += nr >> 3;
mask = 1 << (nr & 0x07);
- local_irq_save(flags);
retval = (mask & *ADDR) != 0;
*ADDR |= mask;
- local_irq_restore(flags);
return retval;
}
static __inline__ int ext2_clear_bit(int nr, volatile void * addr)
{
int mask, retval;
- unsigned long flags;
volatile unsigned char *ADDR = (unsigned char *) addr;
ADDR += nr >> 3;
mask = 1 << (nr & 0x07);
- local_irq_save(flags);
retval = (mask & *ADDR) != 0;
*ADDR &= ~mask;
- local_irq_restore(flags);
return retval;
}
@@ -459,9 +453,9 @@
})
/* Bitmap functions for the minix filesystem. */
-#define minix_test_and_set_bit(nr,addr) test_and_set_bit(nr,addr)
-#define minix_set_bit(nr,addr) set_bit(nr,addr)
-#define minix_test_and_clear_bit(nr,addr) test_and_clear_bit(nr,addr)
+#define minix_test_and_set_bit(nr,addr) __test_and_set_bit(nr,addr)
+#define minix_set_bit(nr,addr) __set_bit(nr,addr)
+#define minix_test_and_clear_bit(nr,addr) __test_and_clear_bit(nr,addr)
#define minix_test_bit(nr,addr) test_bit(nr,addr)
#define minix_find_first_zero_bit(addr,size) find_first_zero_bit(addr,size)
Index: 2.6-git/include/asm-sh64/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-sh64/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-sh64/bitops.h 2006-01-25 19:14:07.000000000 +0900
@@ -382,8 +382,8 @@
#define hweight8(x) generic_hweight8(x)
#ifdef __LITTLE_ENDIAN__
-#define ext2_set_bit(nr, addr) test_and_set_bit((nr), (addr))
-#define ext2_clear_bit(nr, addr) test_and_clear_bit((nr), (addr))
+#define ext2_set_bit(nr, addr) __test_and_set_bit((nr), (addr))
+#define ext2_clear_bit(nr, addr) __test_and_clear_bit((nr), (addr))
#define ext2_test_bit(nr, addr) test_bit((nr), (addr))
#define ext2_find_first_zero_bit(addr, size) find_first_zero_bit((addr), (size))
#define ext2_find_next_zero_bit(addr, size, offset) \
@@ -392,30 +392,24 @@
static __inline__ int ext2_set_bit(int nr, volatile void * addr)
{
int mask, retval;
- unsigned long flags;
volatile unsigned char *ADDR = (unsigned char *) addr;
ADDR += nr >> 3;
mask = 1 << (nr & 0x07);
- local_irq_save(flags);
retval = (mask & *ADDR) != 0;
*ADDR |= mask;
- local_irq_restore(flags);
return retval;
}
static __inline__ int ext2_clear_bit(int nr, volatile void * addr)
{
int mask, retval;
- unsigned long flags;
volatile unsigned char *ADDR = (unsigned char *) addr;
ADDR += nr >> 3;
mask = 1 << (nr & 0x07);
- local_irq_save(flags);
retval = (mask & *ADDR) != 0;
*ADDR &= ~mask;
- local_irq_restore(flags);
return retval;
}
@@ -502,9 +496,9 @@
})
/* Bitmap functions for the minix filesystem. */
-#define minix_test_and_set_bit(nr,addr) test_and_set_bit(nr,addr)
-#define minix_set_bit(nr,addr) set_bit(nr,addr)
-#define minix_test_and_clear_bit(nr,addr) test_and_clear_bit(nr,addr)
+#define minix_test_and_set_bit(nr,addr) __test_and_set_bit(nr,addr)
+#define minix_set_bit(nr,addr) __set_bit(nr,addr)
+#define minix_test_and_clear_bit(nr,addr) __test_and_clear_bit(nr,addr)
#define minix_test_bit(nr,addr) test_bit(nr,addr)
#define minix_find_first_zero_bit(addr,size) find_first_zero_bit(addr,size)
Index: 2.6-git/include/asm-sparc/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-sparc/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-sparc/bitops.h 2006-01-25 19:14:08.000000000 +0900
@@ -523,11 +523,11 @@
/* Bitmap functions for the minix filesystem. */
#define minix_test_and_set_bit(nr,addr) \
- test_and_set_bit((nr),(unsigned long *)(addr))
+ __test_and_set_bit((nr),(unsigned long *)(addr))
#define minix_set_bit(nr,addr) \
- set_bit((nr),(unsigned long *)(addr))
+ __set_bit((nr),(unsigned long *)(addr))
#define minix_test_and_clear_bit(nr,addr) \
- test_and_clear_bit((nr),(unsigned long *)(addr))
+ __test_and_clear_bit((nr),(unsigned long *)(addr))
#define minix_test_bit(nr,addr) \
test_bit((nr),(unsigned long *)(addr))
#define minix_find_first_zero_bit(addr,size) \
Index: 2.6-git/include/asm-sparc64/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-sparc64/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-sparc64/bitops.h 2006-01-25 19:14:08.000000000 +0900
@@ -280,11 +280,11 @@
/* Bitmap functions for the minix filesystem. */
#define minix_test_and_set_bit(nr,addr) \
- test_and_set_bit((nr),(unsigned long *)(addr))
+ __test_and_set_bit((nr),(unsigned long *)(addr))
#define minix_set_bit(nr,addr) \
- set_bit((nr),(unsigned long *)(addr))
+ __set_bit((nr),(unsigned long *)(addr))
#define minix_test_and_clear_bit(nr,addr) \
- test_and_clear_bit((nr),(unsigned long *)(addr))
+ __test_and_clear_bit((nr),(unsigned long *)(addr))
#define minix_test_bit(nr,addr) \
test_bit((nr),(unsigned long *)(addr))
#define minix_find_first_zero_bit(addr,size) \
Index: 2.6-git/include/asm-v850/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-v850/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-v850/bitops.h 2006-01-25 19:14:08.000000000 +0900
@@ -336,18 +336,18 @@
#define hweight16(x) generic_hweight16 (x)
#define hweight8(x) generic_hweight8 (x)
-#define ext2_set_bit test_and_set_bit
+#define ext2_set_bit __test_and_set_bit
#define ext2_set_bit_atomic(l,n,a) test_and_set_bit(n,a)
-#define ext2_clear_bit test_and_clear_bit
+#define ext2_clear_bit __test_and_clear_bit
#define ext2_clear_bit_atomic(l,n,a) test_and_clear_bit(n,a)
#define ext2_test_bit test_bit
#define ext2_find_first_zero_bit find_first_zero_bit
#define ext2_find_next_zero_bit find_next_zero_bit
/* Bitmap functions for the minix filesystem. */
-#define minix_test_and_set_bit test_and_set_bit
-#define minix_set_bit set_bit
-#define minix_test_and_clear_bit test_and_clear_bit
+#define minix_test_and_set_bit __test_and_set_bit
+#define minix_set_bit __set_bit
+#define minix_test_and_clear_bit __test_and_clear_bit
#define minix_test_bit test_bit
#define minix_find_first_zero_bit find_first_zero_bit
Index: 2.6-git/include/asm-xtensa/bitops.h
===================================================================
--- 2.6-git.orig/include/asm-xtensa/bitops.h 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/include/asm-xtensa/bitops.h 2006-01-25 19:14:08.000000000 +0900
@@ -436,9 +436,9 @@
/* Bitmap functions for the minix filesystem. */
-#define minix_test_and_set_bit(nr,addr) test_and_set_bit(nr,addr)
-#define minix_set_bit(nr,addr) set_bit(nr,addr)
-#define minix_test_and_clear_bit(nr,addr) test_and_clear_bit(nr,addr)
+#define minix_test_and_set_bit(nr,addr) __test_and_set_bit(nr,addr)
+#define minix_set_bit(nr,addr) __set_bit(nr,addr)
+#define minix_test_and_clear_bit(nr,addr) __test_and_clear_bit(nr,addr)
#define minix_test_bit(nr,addr) test_bit(nr,addr)
#define minix_find_first_zero_bit(addr,size) find_first_zero_bit(addr,size)
^ permalink raw reply
* [PATCH 1/6] {set,clear,test}_bit() related cleanup
From: Akinobu Mita @ 2006-01-25 11:28 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, Ian Molton, David Howells, linuxppc-dev,
Greg Ungerer, sparclinux, Miles Bader, Linus Torvalds,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev, linux-m68k,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, Andi Kleen, linuxsh-dev, linux390, Russell King,
parisc-linux
In-Reply-To: <20060125112625.GA18584@miraclelinux.com>
While working on these patch set, I found several possible cleanup
on x86-64 and ia64.
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
---
arch/ia64/kernel/mca.c | 3 ++-
arch/x86_64/kernel/mce.c | 3 +--
arch/x86_64/kernel/setup.c | 3 +--
arch/x86_64/pci/mmconfig.c | 4 ++--
include/asm-x86_64/mmu_context.h | 6 +++---
include/asm-x86_64/pgtable.h | 6 +++---
6 files changed, 12 insertions(+), 13 deletions(-)
Index: 2.6-git/arch/x86_64/kernel/mce.c
===================================================================
--- 2.6-git.orig/arch/x86_64/kernel/mce.c 2006-01-25 19:07:15.000000000 +0900
+++ 2.6-git/arch/x86_64/kernel/mce.c 2006-01-25 19:13:59.000000000 +0900
@@ -139,8 +139,7 @@
static int mce_available(struct cpuinfo_x86 *c)
{
- return test_bit(X86_FEATURE_MCE, &c->x86_capability) &&
- test_bit(X86_FEATURE_MCA, &c->x86_capability);
+ return cpu_has(c, X86_FEATURE_MCE) && cpu_has(c, X86_FEATURE_MCA);
}
static inline void mce_get_rip(struct mce *m, struct pt_regs *regs)
Index: 2.6-git/arch/x86_64/kernel/setup.c
===================================================================
--- 2.6-git.orig/arch/x86_64/kernel/setup.c 2006-01-25 19:07:15.000000000 +0900
+++ 2.6-git/arch/x86_64/kernel/setup.c 2006-01-25 19:13:59.000000000 +0900
@@ -1334,8 +1334,7 @@
{
int i;
for ( i = 0 ; i < 32*NCAPINTS ; i++ )
- if ( test_bit(i, &c->x86_capability) &&
- x86_cap_flags[i] != NULL )
+ if (cpu_has(c, i) && x86_cap_flags[i] != NULL )
seq_printf(m, " %s", x86_cap_flags[i]);
}
Index: 2.6-git/include/asm-x86_64/mmu_context.h
===================================================================
--- 2.6-git.orig/include/asm-x86_64/mmu_context.h 2006-01-25 19:07:15.000000000 +0900
+++ 2.6-git/include/asm-x86_64/mmu_context.h 2006-01-25 19:13:59.000000000 +0900
@@ -34,12 +34,12 @@
unsigned cpu = smp_processor_id();
if (likely(prev != next)) {
/* stop flush ipis for the previous mm */
- clear_bit(cpu, &prev->cpu_vm_mask);
+ cpu_clear(cpu, prev->cpu_vm_mask);
#ifdef CONFIG_SMP
write_pda(mmu_state, TLBSTATE_OK);
write_pda(active_mm, next);
#endif
- set_bit(cpu, &next->cpu_vm_mask);
+ cpu_set(cpu, next->cpu_vm_mask);
load_cr3(next->pgd);
if (unlikely(next->context.ldt != prev->context.ldt))
@@ -50,7 +50,7 @@
write_pda(mmu_state, TLBSTATE_OK);
if (read_pda(active_mm) != next)
out_of_line_bug();
- if(!test_and_set_bit(cpu, &next->cpu_vm_mask)) {
+ if(!cpu_test_and_set(cpu, next->cpu_vm_mask)) {
/* We were in lazy tlb mode and leave_mm disabled
* tlb flush IPI delivery. We must reload CR3
* to make sure to use no freed page tables.
Index: 2.6-git/arch/x86_64/pci/mmconfig.c
===================================================================
--- 2.6-git.orig/arch/x86_64/pci/mmconfig.c 2006-01-25 19:07:15.000000000 +0900
+++ 2.6-git/arch/x86_64/pci/mmconfig.c 2006-01-25 19:13:59.000000000 +0900
@@ -46,7 +46,7 @@
static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned int devfn)
{
char __iomem *addr;
- if (seg == 0 && bus == 0 && test_bit(PCI_SLOT(devfn), &fallback_slots))
+ if (seg == 0 && bus == 0 && test_bit(PCI_SLOT(devfn), fallback_slots))
return NULL;
addr = get_virt(seg, bus);
if (!addr)
@@ -134,7 +134,7 @@
continue;
addr = pci_dev_base(0, 0, PCI_DEVFN(i, 0));
if (addr == NULL|| readl(addr) != val1) {
- set_bit(i, &fallback_slots);
+ set_bit(i, fallback_slots);
}
}
}
Index: 2.6-git/include/asm-x86_64/pgtable.h
===================================================================
--- 2.6-git.orig/include/asm-x86_64/pgtable.h 2006-01-25 19:07:15.000000000 +0900
+++ 2.6-git/include/asm-x86_64/pgtable.h 2006-01-25 19:13:59.000000000 +0900
@@ -293,19 +293,19 @@
{
if (!pte_dirty(*ptep))
return 0;
- return test_and_clear_bit(_PAGE_BIT_DIRTY, ptep);
+ return test_and_clear_bit(_PAGE_BIT_DIRTY, &ptep->pte);
}
static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep)
{
if (!pte_young(*ptep))
return 0;
- return test_and_clear_bit(_PAGE_BIT_ACCESSED, ptep);
+ return test_and_clear_bit(_PAGE_BIT_ACCESSED, &ptep->pte);
}
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
- clear_bit(_PAGE_BIT_RW, ptep);
+ clear_bit(_PAGE_BIT_RW, &ptep->pte);
}
/*
Index: 2.6-git/arch/ia64/kernel/mca.c
===================================================================
--- 2.6-git.orig/arch/ia64/kernel/mca.c 2006-01-25 19:07:14.000000000 +0900
+++ 2.6-git/arch/ia64/kernel/mca.c 2006-01-25 19:14:01.000000000 +0900
@@ -69,6 +69,7 @@
#include <linux/kernel.h>
#include <linux/smp.h>
#include <linux/workqueue.h>
+#include <linux/cpumask.h>
#include <asm/delay.h>
#include <asm/kdebug.h>
@@ -1430,7 +1431,7 @@
ti->cpu = cpu;
p->thread_info = ti;
p->state = TASK_UNINTERRUPTIBLE;
- __set_bit(cpu, &p->cpus_allowed);
+ cpu_set(cpu, p->cpus_allowed);
INIT_LIST_HEAD(&p->tasks);
p->parent = p->real_parent = p->group_leader = p;
INIT_LIST_HEAD(&p->children);
^ permalink raw reply
* [PATCH 0/6] RFC: use include/asm-generic/bitops.h
From: Akinobu Mita @ 2006-01-25 11:26 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, Ian Molton, David Howells, linuxppc-dev,
Greg Ungerer, sparclinux, Miles Bader, Linus Torvalds,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev, linux-m68k,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, Andi Kleen, linuxsh-dev, linux390, Russell King,
parisc-linux
Large number of boilerplate bit operations written in C-language
are scattered around include/asm-*/bitops.h.
These patch series gather them into include/asm-generic/bitops.h. And
- kill duplicated code and comment (about 4000lines)
- use better C-language equivalents
- help porting new architecture (now include/asm-generic/bitops.h is not
referenced from anywhere)
^ permalink raw reply
* Re: Linux kernel and u-boot debugging with Eclipse IDE
From: Wolfgang Denk @ 2006-01-25 11:42 UTC (permalink / raw)
To: IGOR LURI; +Cc: linuxppc-embedded
In-Reply-To: <918EB199DDDFFA42BEA2EB3A1C6021F399AFAD@correo.fagorautomation.net>
In message <918EB199DDDFFA42BEA2EB3A1C6021F399AFAD@correo.fagorautomation.net> you wrote:
>
> We have a MPC5200Lite board running Linux 2.4.25 and u-boot 1.1.4. We
> are able to debug Linux kernel and U-boot using DDD/GDB and BDI2000, and
> we are trying to use Eclipse IDE (with CDT plugin) / BDI2000 to develop
> and debug software.
Are you sure that U-Boot and Kernel debugging works fine with GDB? So
is this a rev. B CPU then? If not, please read the errata!
> Eclipse works well to remote debugging aplications over ethernet,
> however, we are not able to debug Linux kernel or u-boot using Eclipse.
> When it stops in the first breakpoint, I can´t view some variables and
> stepping into a function, it shows another. It seems that Eclipse has
> problems with Linux kernel and u-boot symbols.
My guess is that what you see is the effects of the chip errata -
please read the errata sheet.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery
^ permalink raw reply
* [PATCH 6/6] remove unused generic bitops in include/linux/bitops.h
From: Akinobu Mita @ 2006-01-25 11:35 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, Ian Molton, David Howells, linuxppc-dev,
Greg Ungerer, sparclinux, Miles Bader, Linus Torvalds,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev, linux-m68k,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, Andi Kleen, linuxsh-dev, linux390, Russell King,
parisc-linux
In-Reply-To: <20060125112625.GA18584@miraclelinux.com>
generic_{ffs,fls,fls64,hweight{64,32,16,8}}() were moved into
include/asm-generic/bitops.h. So all architectures don't use them.
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
---
bitops.h | 124 ---------------------------------------------------------------
1 files changed, 1 insertion(+), 123 deletions(-)
Index: 2.6-git/include/linux/bitops.h
===================================================================
--- 2.6-git.orig/include/linux/bitops.h 2006-01-25 19:07:12.000000000 +0900
+++ 2.6-git/include/linux/bitops.h 2006-01-25 19:14:27.000000000 +0900
@@ -3,88 +3,11 @@
#include <asm/types.h>
/*
- * ffs: find first bit set. This is defined the same way as
- * the libc and compiler builtin ffs routines, therefore
- * differs in spirit from the above ffz (man ffs).
- */
-
-static inline int generic_ffs(int x)
-{
- int r = 1;
-
- if (!x)
- return 0;
- if (!(x & 0xffff)) {
- x >>= 16;
- r += 16;
- }
- if (!(x & 0xff)) {
- x >>= 8;
- r += 8;
- }
- if (!(x & 0xf)) {
- x >>= 4;
- r += 4;
- }
- if (!(x & 3)) {
- x >>= 2;
- r += 2;
- }
- if (!(x & 1)) {
- x >>= 1;
- r += 1;
- }
- return r;
-}
-
-/*
- * fls: find last bit set.
- */
-
-static __inline__ int generic_fls(int x)
-{
- int r = 32;
-
- if (!x)
- return 0;
- if (!(x & 0xffff0000u)) {
- x <<= 16;
- r -= 16;
- }
- if (!(x & 0xff000000u)) {
- x <<= 8;
- r -= 8;
- }
- if (!(x & 0xf0000000u)) {
- x <<= 4;
- r -= 4;
- }
- if (!(x & 0xc0000000u)) {
- x <<= 2;
- r -= 2;
- }
- if (!(x & 0x80000000u)) {
- x <<= 1;
- r -= 1;
- }
- return r;
-}
-
-/*
* Include this here because some architectures need generic_ffs/fls in
* scope
*/
#include <asm/bitops.h>
-
-static inline int generic_fls64(__u64 x)
-{
- __u32 h = x >> 32;
- if (h)
- return fls(x) + 32;
- return fls(x);
-}
-
static __inline__ int get_bitmask_order(unsigned int count)
{
int order;
@@ -103,54 +26,9 @@
return order;
}
-/*
- * hweightN: returns the hamming weight (i.e. the number
- * of bits set) of a N-bit word
- */
-
-static inline unsigned int generic_hweight32(unsigned int w)
-{
- unsigned int res = (w & 0x55555555) + ((w >> 1) & 0x55555555);
- res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
- res = (res & 0x0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F);
- res = (res & 0x00FF00FF) + ((res >> 8) & 0x00FF00FF);
- return (res & 0x0000FFFF) + ((res >> 16) & 0x0000FFFF);
-}
-
-static inline unsigned int generic_hweight16(unsigned int w)
-{
- unsigned int res = (w & 0x5555) + ((w >> 1) & 0x5555);
- res = (res & 0x3333) + ((res >> 2) & 0x3333);
- res = (res & 0x0F0F) + ((res >> 4) & 0x0F0F);
- return (res & 0x00FF) + ((res >> 8) & 0x00FF);
-}
-
-static inline unsigned int generic_hweight8(unsigned int w)
-{
- unsigned int res = (w & 0x55) + ((w >> 1) & 0x55);
- res = (res & 0x33) + ((res >> 2) & 0x33);
- return (res & 0x0F) + ((res >> 4) & 0x0F);
-}
-
-static inline unsigned long generic_hweight64(__u64 w)
-{
-#if BITS_PER_LONG < 64
- return generic_hweight32((unsigned int)(w >> 32)) +
- generic_hweight32((unsigned int)w);
-#else
- u64 res;
- res = (w & 0x5555555555555555ul) + ((w >> 1) & 0x5555555555555555ul);
- res = (res & 0x3333333333333333ul) + ((res >> 2) & 0x3333333333333333ul);
- res = (res & 0x0F0F0F0F0F0F0F0Ful) + ((res >> 4) & 0x0F0F0F0F0F0F0F0Ful);
- res = (res & 0x00FF00FF00FF00FFul) + ((res >> 8) & 0x00FF00FF00FF00FFul);
- res = (res & 0x0000FFFF0000FFFFul) + ((res >> 16) & 0x0000FFFF0000FFFFul);
- return (res & 0x00000000FFFFFFFFul) + ((res >> 32) & 0x00000000FFFFFFFFul);
-#endif
-}
-
static inline unsigned long hweight_long(unsigned long w)
{
- return sizeof(w) == 4 ? generic_hweight32(w) : generic_hweight64(w);
+ return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
}
/*
^ 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