* Re: 440gx GPIO
From: Eugene Surovegin @ 2006-02-14 17:01 UTC (permalink / raw)
To: Ed Goforth; +Cc: linuxppc-embedded
In-Reply-To: <75b39f010602140548u18f30145tf2ddf529467b2605@mail.gmail.com>
On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> I posted the original from home, and didn't have the contents of the
> config register. It is
> cfg 0x00103e00
> Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> from the manual.
>
> I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but got
> "unresolved symbol ioremap64". From inspection of ioremap(), the
> fixup for 0x40000700 translates to 0x140000700, and I get the same
> values in my code as I see from a "/proc/ocotea/gpio".
>
> Is my approach valid?
It seems to be.
Try writing the same GPIO output register value as you read from it
(without clearing bit 11). Also, try changing some other GPIO bit
(e.g. one which is not connected in your design). Maybe board hangs
exactly because you set GPIO bit 11 low :).
Also, connect scope to that GPIO pin and see what is really going on.
--
Eugene
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Vitaly Bordug @ 2006-02-14 16:42 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <449c76a00602140817k4cf1af22w6d6c930a9d847ba@mail.gmail.com>
Laurent,
btw, have you gived netperf test a try?
It is a commonly-used tool to measure network performance, and has dozens of settings to test...
On Tue, 14 Feb 2006 11:17:46 -0500
Pantelis Antoniou <pantelis.antoniou@gmail.com> wrote:
> Can you provide some more information?
>
> Actual timings, and a tcpdump fragment?
>
> On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
> >
> > Hi Pantelis,
> >
> > Thanks for the express reply.
> >
> > I know that what I say seems incredible. But I don't understand what NAPI
> > does.
> > My measure is very simple. I display a message on the client when 1000
> > exchanges are done.
> > I already check the ifconfig stats on the board after some seconds.
> > The measures seems the same with or without NAPI.
> >
> > More details ?
> > Thanks again
> > Laurent
> >
> >
> >
> > -----Message d'origine-----
> > *De :* Pantelis Antoniou [mailto:pantelis.antoniou@gmail.com]
> > *Envoyé :* mar. 14 février 2006 16:29
> > *À :* Laurent Lagrange
> > *Cc :* linuxppc-embedded@ozlabs.org
> > *Objet :* Re: Gianfar is slower than fcc_enet on MPC8541 ???
> >
> > Hi Laurent,
> >
> > I found that pretty hard to believe.
> >
> > What are you measuring exactly?
> >
> > Speed of replies? If so it's explainable since the TSECs use
> > NAPI.
> >
> > Regards
> >
> > Pantelis
> >
> > On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
> > >
> > >
> > > Hello,
> > >
> > > I work on a cutom MPC8541 board with Linux 2.6.9.
> > > The kernel activates the L1 cache (instructions and data)
> > > and the L2 cache (entirely used as cache and not as sram).
> > >
> > > I configure
> > > 1 FCC (FCC1),
> > > 2 TSECs with or without NAPI (no effect) but without stashing in L2
> > > sram.
> > > All PHYs are automatically configured in 100MB full duplex.
> > >
> > > eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> > > eth0: Running with NAPI disabled
> > > eth0: 64/64 RX/TX BD ring size
> > > eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> > > eth1: Running with NAPI disabled
> > > eth1: 64/64 RX/TX BD ring size
> > > eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
> > >
> > > Then I launch 3 simple TCP servers, one on each ports.
> > >
> > > From remote machines I runs 3 TCP clients.
> > > The client sends messages of 1000 bytes,
> > > The server receives and echoes the message
> > > The client receives the echoed message, check the content
> > > and sends a new message again.
> > >
> > > The result is that the 2 TSECs are 2 times slower than the FCC.
> > >
> > > If I run a "top" application on the board, I use less than 10% of the
> > > CPU
> > > Each port consumes about 1/3 of the CPU.
> > >
> > > Any idea on how to configure the gianfar driver ?
> > >
> > > Thanks
> > > Laurent
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Pantelis Antoniou @ 2006-02-14 16:17 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000201c63181$cf2c3180$5201a8c0@GEG2400>
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
Can you provide some more information?
Actual timings, and a tcpdump fragment?
On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
>
> Hi Pantelis,
>
> Thanks for the express reply.
>
> I know that what I say seems incredible. But I don't understand what NAPI
> does.
> My measure is very simple. I display a message on the client when 1000
> exchanges are done.
> I already check the ifconfig stats on the board after some seconds.
> The measures seems the same with or without NAPI.
>
> More details ?
> Thanks again
> Laurent
>
>
>
> -----Message d'origine-----
> *De :* Pantelis Antoniou [mailto:pantelis.antoniou@gmail.com]
> *Envoyé :* mar. 14 février 2006 16:29
> *À :* Laurent Lagrange
> *Cc :* linuxppc-embedded@ozlabs.org
> *Objet :* Re: Gianfar is slower than fcc_enet on MPC8541 ???
>
> Hi Laurent,
>
> I found that pretty hard to believe.
>
> What are you measuring exactly?
>
> Speed of replies? If so it's explainable since the TSECs use
> NAPI.
>
> Regards
>
> Pantelis
>
> On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
> >
> >
> > Hello,
> >
> > I work on a cutom MPC8541 board with Linux 2.6.9.
> > The kernel activates the L1 cache (instructions and data)
> > and the L2 cache (entirely used as cache and not as sram).
> >
> > I configure
> > 1 FCC (FCC1),
> > 2 TSECs with or without NAPI (no effect) but without stashing in L2
> > sram.
> > All PHYs are automatically configured in 100MB full duplex.
> >
> > eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> > eth0: Running with NAPI disabled
> > eth0: 64/64 RX/TX BD ring size
> > eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> > eth1: Running with NAPI disabled
> > eth1: 64/64 RX/TX BD ring size
> > eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
> >
> > Then I launch 3 simple TCP servers, one on each ports.
> >
> > From remote machines I runs 3 TCP clients.
> > The client sends messages of 1000 bytes,
> > The server receives and echoes the message
> > The client receives the echoed message, check the content
> > and sends a new message again.
> >
> > The result is that the 2 TSECs are 2 times slower than the FCC.
> >
> > If I run a "top" application on the board, I use less than 10% of the
> > CPU
> > Each port consumes about 1/3 of the CPU.
> >
> > Any idea on how to configure the gianfar driver ?
> >
> > Thanks
> > Laurent
> >
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
[-- Attachment #2: Type: text/html, Size: 5752 bytes --]
^ permalink raw reply
* RE: Gianfar is slower than fcc_enet on MPC8541 ???
From: Laurent Lagrange @ 2006-02-14 16:14 UTC (permalink / raw)
To: 'Pantelis Antoniou'; +Cc: linuxppc-embedded
In-Reply-To: <449c76a00602140728g3a9eb46sd70f23b894c4b96@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]
Hi Pantelis,
Thanks for the express reply.
I know that what I say seems incredible. But I don't understand what NAPI
does.
My measure is very simple. I display a message on the client when 1000
exchanges are done.
I already check the ifconfig stats on the board after some seconds.
The measures seems the same with or without NAPI.
More details ?
Thanks again
Laurent
-----Message d'origine-----
De : Pantelis Antoniou [mailto:pantelis.antoniou@gmail.com]
Envoyé : mar. 14 février 2006 16:29
À : Laurent Lagrange
Cc : linuxppc-embedded@ozlabs.org
Objet : Re: Gianfar is slower than fcc_enet on MPC8541 ???
Hi Laurent,
I found that pretty hard to believe.
What are you measuring exactly?
Speed of replies? If so it's explainable since the TSECs use
NAPI.
Regards
Pantelis
On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
Hello,
I work on a cutom MPC8541 board with Linux 2.6.9.
The kernel activates the L1 cache (instructions and data)
and the L2 cache (entirely used as cache and not as sram).
I configure
1 FCC (FCC1),
2 TSECs with or without NAPI (no effect) but without stashing in L2
sram.
All PHYs are automatically configured in 100MB full duplex.
eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
eth1: Running with NAPI disabled
eth1: 64/64 RX/TX BD ring size
eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
Then I launch 3 simple TCP servers, one on each ports.
From remote machines I runs 3 TCP clients.
The client sends messages of 1000 bytes,
The server receives and echoes the message
The client receives the echoed message, check the content
and sends a new message again.
The result is that the 2 TSECs are 2 times slower than the FCC.
If I run a "top" application on the board, I use less than 10% of the
CPU
Each port consumes about 1/3 of the CPU.
Any idea on how to configure the gianfar driver ?
Thanks
Laurent
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 5369 bytes --]
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Pantelis Antoniou @ 2006-02-14 15:28 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c6317b$148162c0$5201a8c0@GEG2400>
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
Hi Laurent,
I found that pretty hard to believe.
What are you measuring exactly?
Speed of replies? If so it's explainable since the TSECs use
NAPI.
Regards
Pantelis
On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
>
>
> Hello,
>
> I work on a cutom MPC8541 board with Linux 2.6.9.
> The kernel activates the L1 cache (instructions and data)
> and the L2 cache (entirely used as cache and not as sram).
>
> I configure
> 1 FCC (FCC1),
> 2 TSECs with or without NAPI (no effect) but without stashing in L2 sram.
> All PHYs are automatically configured in 100MB full duplex.
>
> eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> eth0: Running with NAPI disabled
> eth0: 64/64 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> eth1: Running with NAPI disabled
> eth1: 64/64 RX/TX BD ring size
> eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
>
> Then I launch 3 simple TCP servers, one on each ports.
>
> From remote machines I runs 3 TCP clients.
> The client sends messages of 1000 bytes,
> The server receives and echoes the message
> The client receives the echoed message, check the content
> and sends a new message again.
>
> The result is that the 2 TSECs are 2 times slower than the FCC.
>
> If I run a "top" application on the board, I use less than 10% of the CPU
> Each port consumes about 1/3 of the CPU.
>
> Any idea on how to configure the gianfar driver ?
>
> Thanks
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2485 bytes --]
^ permalink raw reply
* Gianfar is slower than fcc_enet on MPC8541 ???
From: Laurent Lagrange @ 2006-02-14 15:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I work on a cutom MPC8541 board with Linux 2.6.9.
The kernel activates the L1 cache (instructions and data)
and the L2 cache (entirely used as cache and not as sram).
I configure
1 FCC (FCC1),
2 TSECs with or without NAPI (no effect) but without stashing in L2 sram.
All PHYs are automatically configured in 100MB full duplex.
eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
eth1: Running with NAPI disabled
eth1: 64/64 RX/TX BD ring size
eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
Then I launch 3 simple TCP servers, one on each ports.
>From remote machines I runs 3 TCP clients.
The client sends messages of 1000 bytes,
The server receives and echoes the message
The client receives the echoed message, check the content
and sends a new message again.
The result is that the 2 TSECs are 2 times slower than the FCC.
If I run a "top" application on the board, I use less than 10% of the CPU
Each port consumes about 1/3 of the CPU.
Any idea on how to configure the gianfar driver ?
Thanks
Laurent
^ permalink raw reply
* Re: 440gx GPIO
From: Ed Goforth @ 2006-02-14 13:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060214065934.GA12465@gate.ebshome.net>
I posted the original from home, and didn't have the contents of the
config register. It is
cfg 0x00103e00
Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
from the manual.
I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but go=
t
"unresolved symbol ioremap64". From inspection of ioremap(), the
fixup for 0x40000700 translates to 0x140000700, and I get the same
values in my code as I see from a "/proc/ocotea/gpio".
Is my approach valid?
Thanks,
Ed
On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote:
> > I am struggling with a problem and I hope someone can give me some
> > pointers. We have a custom board with a 440gx. I need to drive GPIO11
> > low. The best as I can tell from the docs, I need to set bit 11 of the
> > TCR to 1 and bit 11 of the OR to 0 to do this.
>
> Check that this pin is enabled as GPIO not as a function pin
> (SDR0_PFC0 register).
>
> Also, just to be sure that you remapped GPIO registers correctly, use
> ioremap64 with full physical address (not just low 32 bits).
>
> --
> Eugene
>
>
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Jenkins, Clive @ 2006-02-14 13:31 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh), atul.sabharwal, linuxppc-dev
fw_printenv and fw_setenv _are_ normal userland Linux utilities, which
can be run from the shell command line. If you want your own program
to directly get/set environment variables, just call the appropriate
functions. Read and understand the code.
Clive
[continuing to top-post. sorry]
-----Original Message-----
From: Bizhan Gholikhamseh (bgholikh) [mailto:bgholikh@cisco.com]=20
Sent: 14 February 2006 12:45
To: Jenkins, Clive; atul.sabharwal@exgate.tek.com;
linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I am aware of fw_printenv and fw_setenv. But they are uboot utilities,
and I am trying to access the parameter from Linux, what am I missing?
Thanks,
Bizhan=20
-----Original Message-----
From: Jenkins, Clive [mailto:Clive.Jenkins@xerox.com]=20
Sent: Tuesday, February 14, 2006 2:56 AM
To: atul.sabharwal@exgate.tek.com; Bizhan Gholikhamseh (bgholikh);
linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
Have you not discovered internet search engines?
If you paste the original question ("How could I access the uboot
environment variables from Linux?") into Google, you get the answer as
the first result:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariables
InLinux
[Continuing the current style of top-posting. Sorry] Clive
=20
-----Original Message-----
From: linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org
[mailto:linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org] On
Behalf Of atul.sabharwal@exgate.tek.com
Sent: 14 February 2006 01:09
To: bgholikh@cisco.com; linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I think you will have to write a program to access and decode u-boot
environment setup format in linux.
If you come across some open source app for this, plz. share with me. It
should be a standard method but typically a small optimization if you
want your main code to be independent of the boot loader your are using
or if you have common code base which works across multiple
processors/multiple loaders.
=20
--
Atul
From: linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org
[mailto:linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org] On
Behalf Of Bizhan Gholikhamseh (bgholikh)
Sent: Monday, February 13, 2006 4:54 PM
To: linuxppc-dev@ozlabs.org
Subject: How to access uboot environment variables from Linux?
=20
All,
How could I access the uboot environment variables from Linux? For
example I would like to access the "serverip"
and change that to a different ip address during run time.
=20
Many thanks in advance,
Bizhan
^ permalink raw reply
* [PATCH] kprobes depends on xmon
From: Olaf Hering @ 2006-02-14 13:10 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
KPROBES depends on XMON.
arch/powerpc/lib/step.c is only compiled if CONFIG_XMON is enabled.
arch/powerpc/kernel/built-in.o:
In function `resume_execution':arch/powerpc/kernel/kprobes.c:331: undefined reference to
`.emulate_step'
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc3-olh/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.16-rc3-olh.orig/arch/powerpc/Kconfig
+++ linux-2.6.16-rc3-olh/arch/powerpc/Kconfig
@@ -963,7 +963,7 @@ source "arch/powerpc/oprofile/Kconfig"
config KPROBES
bool "Kprobes (EXPERIMENTAL)"
- depends on PPC64
+ depends on PPC64 && XMON
help
Kprobes allows you to trap at almost any kernel address and
execute a callback function. register_kprobe() establishes
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Bizhan Gholikhamseh (bgholikh) @ 2006-02-14 12:45 UTC (permalink / raw)
To: Jenkins, Clive, atul.sabharwal, linuxppc-dev
I am aware of fw_printenv and fw_setenv. But they are uboot utilities,
and I am trying to access the parameter from Linux, what am I missing?
Thanks,
Bizhan=20
-----Original Message-----
From: Jenkins, Clive [mailto:Clive.Jenkins@xerox.com]=20
Sent: Tuesday, February 14, 2006 2:56 AM
To: atul.sabharwal@exgate.tek.com; Bizhan Gholikhamseh (bgholikh);
linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
Have you not discovered internet search engines?
If you paste the original question ("How could I access the uboot
environment variables from Linux?") into Google, you get the answer as
the first result:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariables
InLinux
[Continuing the current style of top-posting. Sorry] Clive
=20
-----Original Message-----
From: linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org
[mailto:linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org] On
Behalf Of atul.sabharwal@exgate.tek.com
Sent: 14 February 2006 01:09
To: bgholikh@cisco.com; linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I think you will have to write a program to access and decode u-boot
environment setup format in linux.
If you come across some open source app for this, plz. share with me. It
should be a standard method but typically a small optimization if you
want your main code to be independent of the boot loader your are using
or if you have common code base which works across multiple
processors/multiple loaders.
=20
--
Atul
From: linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org
[mailto:linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org] On
Behalf Of Bizhan Gholikhamseh (bgholikh)
Sent: Monday, February 13, 2006 4:54 PM
To: linuxppc-dev@ozlabs.org
Subject: How to access uboot environment variables from Linux?
=20
All,
How could I access the uboot environment variables from Linux? For
example I would like to access the "serverip"
and change that to a different ip address during run time.
=20
Many thanks in advance,
Bizhan
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Andy Hawkins @ 2006-02-14 10:43 UTC (permalink / raw)
To: atul.sabharwal, bgholikh, linuxppc-dev
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA21A8@us-bv-m23.global.tektronix.net>
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi,
> I think you will have to write a program to access and decode u-boot
environment setup
> format in linux.
Or you could use the one that comes with u-boot...
Look in tools/env
Andy
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 1584 bytes --]
^ permalink raw reply
* How to access uboot environment variables from Linux?
From: Heiko Schocher @ 2006-02-14 11:31 UTC (permalink / raw)
To: linuxppc-dev
Hello Bizhan,
> How could I access the uboot environment variables from Linux? For
> example I would like to access the "serverip"
have a look at
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux
Best regards,
Heiko
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Jenkins, Clive @ 2006-02-14 10:56 UTC (permalink / raw)
To: atul.sabharwal, bgholikh, linuxppc-dev
Have you not discovered internet search engines?
If you paste the original question ("How could I access the uboot
environment variables from Linux?") into Google, you get the answer as
the first result:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariables
InLinux
[Continuing the current style of top-posting. Sorry]
Clive
=20
-----Original Message-----
From: linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org
[mailto:linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org] On
Behalf Of atul.sabharwal@exgate.tek.com
Sent: 14 February 2006 01:09
To: bgholikh@cisco.com; linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I think you will have to write a program to access and decode u-boot
environment setup format in linux.
If you come across some open source app for this, plz. share with me. It
should be a standard method
but typically a small optimization if you want your main code to be
independent of the boot loader
your are using or if you have common code base which works across
multiple processors/multiple loaders.
=20
--
Atul
From: linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org
[mailto:linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org] On
Behalf Of Bizhan Gholikhamseh (bgholikh)
Sent: Monday, February 13, 2006 4:54 PM
To: linuxppc-dev@ozlabs.org
Subject: How to access uboot environment variables from Linux?
=20
All,
How could I access the uboot environment variables from Linux? For
example I would like to access the "serverip"
and change that to a different ip address during run time.
=20
Many thanks in advance,
Bizhan
^ permalink raw reply
* RE: 82xx_io UART BRG's vs BUS CLK
From: Jenkins, Clive @ 2006-02-14 11:23 UTC (permalink / raw)
To: Russell McGuire, linuxppc-embedded
> I did some math on the BRG calculations and with 66Mhz the BRG divisor
is
> 17.8 I am assuming 17 gets written, and with 66.666Mhz then its 18.02
so
> thus 18 probably gets written. Should perhaps a constant minus 1 be
added to
> the code?
> Using:
> U-boot 1.1.2
> DENX Linux 2.4.25
> Is anyone aware of similar issues, or are there bug fixes past the
2.4.25
> Kernel for this?
> -Russ
Hi Russ
I am not familiar with your hardware, nor have I checked the code that
calculated the Baud rate divisor.
I would advise against "adding a constant -1", in favour of rounding
to the nearest integer. From your figures:
divisor =3D clock / (baudrate * 32)
To get a rounded result using real numbers:
divisor =3D integer_part_of((clock / (baudrate * 32)) + 1/2)
Using integer arithmetic, you can code this in C as:
divisor =3D ((clock / baudrate /16) + 1) >> 1;
I would check whether or not the code is doing this, or the equivalent,
and if not, change it. If the code is doing this, the divisor should be
18 in both cases.
Clive
^ permalink raw reply
* [PATCH] unify pfn_to_page take3 [14/23] ppc pfn_to_page
From: KAMEZAWA Hiroyuki @ 2006-02-14 10:43 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <43F1A753.2020003@jp.fujitsu.com>
PPC can use generic funcs.
Signed-Off-By: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Index: testtree/include/asm-ppc/page.h
===================================================================
--- testtree.orig/include/asm-ppc/page.h
+++ testtree/include/asm-ppc/page.h
@@ -149,8 +149,7 @@ extern int page_is_ram(unsigned long pfn
#define __pa(x) ___pa((unsigned long)(x))
#define __va(x) ((void *)(___va((unsigned long)(x))))
-#define pfn_to_page(pfn) (mem_map + ((pfn) - PPC_PGSTART))
-#define page_to_pfn(page) ((unsigned long)((page) - mem_map) + PPC_PGSTART)
+#define ARCH_PFN_OFFSET (PPC_PGSTART)
#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
#define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT)
@@ -175,5 +174,6 @@ extern __inline__ int get_order(unsigned
/* We do define AT_SYSINFO_EHDR but don't use the gate mecanism */
#define __HAVE_ARCH_GATE_AREA 1
+#include <asm-generic/memory_model.h>
#endif /* __KERNEL__ */
#endif /* _PPC_PAGE_H */
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: atul.sabharwal @ 2006-02-14 1:09 UTC (permalink / raw)
To: bgholikh, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
I think you will have to write a program to access and decode u-boot
environment setup format in linux.
If you come across some open source app for this, plz. share with me. It
should be a standard method
but typically a small optimization if you want your main code to be
independent of the boot loader
your are using or if you have common code base which works across
multiple processors/multiple loaders.
--
Atul
________________________________
From: linuxppc-dev-bounces+atul.sabharwal=tek.com@ozlabs.org
[mailto:linuxppc-dev-bounces+atul.sabharwal=tek.com@ozlabs.org] On
Behalf Of Bizhan Gholikhamseh (bgholikh)
Sent: Monday, February 13, 2006 4:54 PM
To: linuxppc-dev@ozlabs.org
Subject: How to access uboot environment variables from Linux?
All,
How could I access the uboot environment variables from Linux? For
example I would like to access the "serverip"
and change that to a different ip address during run time.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 4738 bytes --]
^ permalink raw reply
* [PATCH] unify pfn_to_page take3 [4/23] powerpc pfn_to_page
From: KAMEZAWA Hiroyuki @ 2006-02-14 10:02 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <43F1A753.2020003@jp.fujitsu.com>
PowerPC can use generic ones.
Signed-Off-By: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Index: testtree/include/asm-powerpc/page.h
===================================================================
--- testtree.orig/include/asm-powerpc/page.h
+++ testtree/include/asm-powerpc/page.h
@@ -69,8 +69,6 @@
#endif
#ifdef CONFIG_FLATMEM
-#define pfn_to_page(pfn) (mem_map + (pfn))
-#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
#define pfn_valid(pfn) ((pfn) < max_mapnr)
#endif
@@ -200,6 +198,7 @@ extern void copy_user_page(void *to, voi
struct page *p);
extern int page_is_ram(unsigned long pfn);
+#include <asm-generic/memory_model.h>
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply
* SD/MMC card driver?
From: Eberhard Stoll @ 2006-02-14 8:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've got a mpc5200 based board with a SD card socket connected to PSC2.
I'd like to use this SD Card as a block device, but didn't find any
driver for SD/MMC Cards in kernel 2.4 (denx 2.4.15). So my question is:
Are there any drivers for linux & SD/MMC Cards attached to a spi
interface (e.g. mpc5200)?
thanks in advance!
Eberhard
^ permalink raw reply
* Re: 440gx GPIO
From: Eugene Surovegin @ 2006-02-14 6:59 UTC (permalink / raw)
To: Ed Goforth; +Cc: linuxppc-embedded
In-Reply-To: <43F168A3.4020808@gmail.com>
On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote:
> I am struggling with a problem and I hope someone can give me some
> pointers. We have a custom board with a 440gx. I need to drive GPIO11
> low. The best as I can tell from the docs, I need to set bit 11 of the
> TCR to 1 and bit 11 of the OR to 0 to do this.
Check that this pin is enabled as GPIO not as a function pin
(SDR0_PFC0 register).
Also, just to be sure that you remapped GPIO registers correctly, use
ioremap64 with full physical address (not just low 32 bits).
--
Eugene
^ permalink raw reply
* 440gx GPIO
From: Ed Goforth @ 2006-02-14 5:20 UTC (permalink / raw)
To: linuxppc-embedded
I am struggling with a problem and I hope someone can give me some
pointers. We have a custom board with a 440gx. I need to drive GPIO11
low. The best as I can tell from the docs, I need to set bit 11 of the
TCR to 1 and bit 11 of the OR to 0 to do this. I'm using kernel
2.4.18-timesys-4.0
Here's what I've tried:
Prior to making an calls, the values of the registers are:
or 0x00101000
tcr 0x00101700
odr 0x00000000
ir 0xeffff820
(from ibm440gx.h)
#define PPC440GX_GPIO0_ADDR 0x0000000140000700
Attempt one: write the bit directly:
volatile gpio_t *gpio;
volatile u32 or_reg;
gpio = (gpio_t *) ioremap_nocache(0x40000700,
sizeof(gpio_t));
or_reg = gpio->or;
or_reg &= 0x00100000;
gpio->or = or_reg;
Attempt two: use the accessor routine:
extern int ibm_gpio_out(__u32 device, __u32 mask, __u32 data);
rc = ibm_gpio_out(0, 0x00100000, 0);
With either approach, I can read the registers fine. But as soon as I
either modify gpio->or or call ibm_gpio_out(), the board hangs hard.
Any hints would be greatly appreciated. On-list replies are fine; I am
a subscriber.
Thanks,
Ed
^ permalink raw reply
* [patch 11/47] generic fls64()
From: Akinobu Mita @ 2006-02-14 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, linux-mips, linux-ia64, Ian Molton, Andi Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
linux-m68k, Ivan Kokshaysky, Richard Henderson, Akinobu Mita,
Chris Zankel, dev-etrax, ultralinux, Linus Torvalds, linuxsh-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060214050351.252615000@localhost.localdomain>
This patch introduces the C-language equivalent of the function:
int fls64(__u64 x);
In include/asm-generic/bitops/fls64.h
This code largely copied from:
include/linux/bitops.h
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
include/asm-generic/bitops/fls64.h | 12 ++++++++++++
1 files changed, 12 insertions(+)
Index: 2.6-rc/include/asm-generic/bitops/fls64.h
===================================================================
--- /dev/null
+++ 2.6-rc/include/asm-generic/bitops/fls64.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_GENERIC_BITOPS_FLS64_H_
+#define _ASM_GENERIC_BITOPS_FLS64_H_
+
+static inline int fls64(__u64 x)
+{
+ __u32 h = x >> 32;
+ if (h)
+ return fls(h) + 32;
+ return fls(x);
+}
+
+#endif /* _ASM_GENERIC_BITOPS_FLS64_H_ */
--
^ permalink raw reply
* [patch 32/47] powerpc: use generic bitops
From: Akinobu Mita @ 2006-02-14 5:04 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, linuxppc-dev, Akinobu Mita
In-Reply-To: <20060214050351.252615000@localhost.localdomain>
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- remove generic_fls64()
- remove generic_hweight{64,32,16,8}()
- remove sched_find_first_bit()
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
arch/powerpc/Kconfig | 4 +
include/asm-powerpc/bitops.h | 105 +------------------------------------------
2 files changed, 8 insertions(+), 101 deletions(-)
Index: 2.6-rc/include/asm-powerpc/bitops.h
===================================================================
--- 2.6-rc.orig/include/asm-powerpc/bitops.h
+++ 2.6-rc/include/asm-powerpc/bitops.h
@@ -184,72 +184,7 @@ static __inline__ void set_bits(unsigned
: "cc");
}
-/* Non-atomic versions */
-static __inline__ int test_bit(unsigned long nr,
- __const__ volatile unsigned long *addr)
-{
- return 1UL & (addr[BITOP_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
-}
-
-static __inline__ void __set_bit(unsigned long nr,
- volatile unsigned long *addr)
-{
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- *p |= mask;
-}
-
-static __inline__ void __clear_bit(unsigned long nr,
- volatile unsigned long *addr)
-{
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- *p &= ~mask;
-}
-
-static __inline__ void __change_bit(unsigned long nr,
- volatile unsigned long *addr)
-{
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- *p ^= mask;
-}
-
-static __inline__ int __test_and_set_bit(unsigned long nr,
- volatile unsigned long *addr)
-{
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
- unsigned long old = *p;
-
- *p = old | mask;
- return (old & mask) != 0;
-}
-
-static __inline__ int __test_and_clear_bit(unsigned long nr,
- volatile unsigned long *addr)
-{
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
- unsigned long old = *p;
-
- *p = old & ~mask;
- return (old & mask) != 0;
-}
-
-static __inline__ int __test_and_change_bit(unsigned long nr,
- volatile unsigned long *addr)
-{
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
- unsigned long old = *p;
-
- *p = old ^ mask;
- return (old & mask) != 0;
-}
+#include <asm-generic/bitops/non-atomic.h>
/*
* Return the zero-based bit position (LE, not IBM bit numbering) of
@@ -310,16 +245,9 @@ static __inline__ int fls(unsigned int x
asm ("cntlzw %0,%1" : "=r" (lz) : "r" (x));
return 32 - lz;
}
-#define fls64(x) generic_fls64(x)
+#include <asm-generic/bitops/fls64.h>
-/*
- * hweightN: returns the hamming weight (i.e. the number
- * of bits set) of a N-bit word
- */
-#define hweight64(x) generic_hweight64(x)
-#define hweight32(x) generic_hweight32(x)
-#define hweight16(x) generic_hweight16(x)
-#define hweight8(x) generic_hweight8(x)
+#include <asm-generic/bitops/hweight.h>
#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 0)
unsigned long find_next_zero_bit(const unsigned long *addr,
@@ -397,32 +325,7 @@ unsigned long find_next_zero_le_bit(cons
#define minix_find_first_zero_bit(addr,size) \
find_first_zero_le_bit((unsigned long *)addr, size)
-/*
- * Every architecture must define this function. It's the fastest
- * way of searching a 140-bit bitmap where the first 100 bits are
- * unlikely to be set. It's guaranteed that at least one of the 140
- * bits is cleared.
- */
-static inline int sched_find_first_bit(const unsigned long *b)
-{
-#ifdef CONFIG_PPC64
- if (unlikely(b[0]))
- return __ffs(b[0]);
- if (unlikely(b[1]))
- return __ffs(b[1]) + 64;
- return __ffs(b[2]) + 128;
-#else
- if (unlikely(b[0]))
- return __ffs(b[0]);
- if (unlikely(b[1]))
- return __ffs(b[1]) + 32;
- if (unlikely(b[2]))
- return __ffs(b[2]) + 64;
- if (b[3])
- return __ffs(b[3]) + 96;
- return __ffs(b[4]) + 128;
-#endif
-}
+#include <asm-generic/bitops/sched.h>
#endif /* __KERNEL__ */
Index: 2.6-rc/arch/powerpc/Kconfig
===================================================================
--- 2.6-rc.orig/arch/powerpc/Kconfig
+++ 2.6-rc/arch/powerpc/Kconfig
@@ -37,6 +37,10 @@ config RWSEM_XCHGADD_ALGORITHM
bool
default y
+config GENERIC_HWEIGHT
+ bool
+ default y
+
config GENERIC_CALIBRATE_DELAY
bool
default y
--
^ permalink raw reply
* [patch 13/47] generic sched_find_first_bit()
From: Akinobu Mita @ 2006-02-14 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, linux-mips, linux-ia64, Ian Molton, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Linus Torvalds, Yoshinori Sato, Hirokazu Takata, linuxsh-dev,
linux-m68k, Akinobu Mita, Chris Zankel, dev-etrax, ultralinux,
Andi Kleen, linuxsh-shmedia-dev, linux390, Russell King,
parisc-linux
In-Reply-To: <20060214050351.252615000@localhost.localdomain>
This patch introduces the C-language equivalent of the function:
int sched_find_first_bit(const unsigned long *b);
In include/asm-generic/bitops/sched.h
This code largely copied from:
include/asm-powerpc/bitops.h
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
include/asm-generic/bitops/sched.h | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+)
Index: 2.6-rc/include/asm-generic/bitops/sched.h
===================================================================
--- /dev/null
+++ 2.6-rc/include/asm-generic/bitops/sched.h
@@ -0,0 +1,36 @@
+#ifndef _ASM_GENERIC_BITOPS_SCHED_H_
+#define _ASM_GENERIC_BITOPS_SCHED_H_
+
+#include <linux/compiler.h> /* unlikely() */
+#include <asm/types.h>
+
+/*
+ * Every architecture must define this function. It's the fastest
+ * way of searching a 140-bit bitmap where the first 100 bits are
+ * unlikely to be set. It's guaranteed that at least one of the 140
+ * bits is cleared.
+ */
+static inline int sched_find_first_bit(const unsigned long *b)
+{
+#if BITS_PER_LONG == 64
+ if (unlikely(b[0]))
+ return __ffs(b[0]);
+ if (unlikely(b[1]))
+ return __ffs(b[1]) + 64;
+ return __ffs(b[2]) + 128;
+#elif BITS_PER_LONG == 32
+ if (unlikely(b[0]))
+ return __ffs(b[0]);
+ if (unlikely(b[1]))
+ return __ffs(b[1]) + 32;
+ if (unlikely(b[2]))
+ return __ffs(b[2]) + 64;
+ if (b[3])
+ return __ffs(b[3]) + 96;
+ return __ffs(b[4]) + 128;
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+#endif /* _ASM_GENERIC_BITOPS_SCHED_H_ */
--
^ permalink raw reply
* [patch 15/47] generic hweight{64,32,16,8}()
From: Akinobu Mita @ 2006-02-14 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, linux-mips, linux-ia64, Ian Molton, Andi Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
linux-m68k, Ivan Kokshaysky, Richard Henderson, Akinobu Mita,
Chris Zankel, dev-etrax, ultralinux, Linus Torvalds, linuxsh-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060214050351.252615000@localhost.localdomain>
This patch introduces the C-language equivalents of the functions below:
unsigned int hweight32(unsigned int w);
unsigned int hweight16(unsigned int w);
unsigned int hweight8(unsigned int w);
unsigned long hweight64(__u64 w);
In include/asm-generic/bitops/hweight.h
This code largely copied from:
include/linux/bitops.h
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
include/asm-generic/bitops/hweight.h | 9 +++++
lib/Makefile | 1
lib/hweight.c | 54 +++++++++++++++++++++++++++++++++++
3 files changed, 64 insertions(+)
Index: 2.6-rc/include/asm-generic/bitops/hweight.h
===================================================================
--- /dev/null
+++ 2.6-rc/include/asm-generic/bitops/hweight.h
@@ -0,0 +1,9 @@
+#ifndef _ASM_GENERIC_BITOPS_HWEIGHT_H_
+#define _ASM_GENERIC_BITOPS_HWEIGHT_H_
+
+extern unsigned int hweight32(unsigned int w);
+extern unsigned int hweight16(unsigned int w);
+extern unsigned int hweight8(unsigned int w);
+extern unsigned long hweight64(__u64 w);
+
+#endif /* _ASM_GENERIC_BITOPS_HWEIGHT_H_ */
Index: 2.6-rc/lib/Makefile
===================================================================
--- 2.6-rc.orig/lib/Makefile
+++ 2.6-rc/lib/Makefile
@@ -21,6 +21,7 @@ lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) +=
lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
lib-$(CONFIG_SEMAPHORE_SLEEPERS) += semaphore-sleepers.o
lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += find_next_bit.o
+lib-$(CONFIG_GENERIC_HWEIGHT) += hweight.o
obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o
obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o
Index: 2.6-rc/lib/hweight.c
===================================================================
--- /dev/null
+++ 2.6-rc/lib/hweight.c
@@ -0,0 +1,54 @@
+#include <linux/module.h>
+#include <asm/types.h>
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+
+unsigned int 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);
+}
+EXPORT_SYMBOL(hweight32);
+
+unsigned int 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);
+}
+EXPORT_SYMBOL(hweight16);
+
+unsigned int hweight8(unsigned int w)
+{
+ unsigned int res = (w & 0x55) + ((w >> 1) & 0x55);
+ res = (res & 0x33) + ((res >> 2) & 0x33);
+ return (res & 0x0F) + ((res >> 4) & 0x0F);
+}
+EXPORT_SYMBOL(hweight8);
+
+unsigned long hweight64(__u64 w)
+{
+#if BITS_PER_LONG == 32
+ return hweight32((unsigned int)(w >> 32)) + hweight32((unsigned int)w);
+#elif BITS_PER_LONG == 64
+ 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);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+EXPORT_SYMBOL(hweight64);
--
^ permalink raw reply
* [patch 07/47] generic __{, test_and_}{set, clear, change}_bit() and test_bit()
From: Akinobu Mita @ 2006-02-14 5:03 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, linux-mips, dev-etrax, ultralinux, Ian Molton,
Hirokazu Takata, Akinobu Mita, linuxppc-dev, linuxsh-dev,
sparclinux, Chris Zankel, linuxsh-shmedia-dev, Russell King,
parisc-linux
In-Reply-To: <20060214050351.252615000@localhost.localdomain>
This patch introduces the C-language equivalents of the functions below:
void __set_bit(int nr, volatile unsigned long *addr);
void __clear_bit(int nr, volatile unsigned long *addr);
void __change_bit(int nr, volatile unsigned long *addr);
int __test_and_set_bit(int nr, volatile unsigned long *addr);
int __test_and_clear_bit(int nr, volatile unsigned long *addr);
int __test_and_change_bit(int nr, volatile unsigned long *addr);
int test_bit(int nr, const volatile unsigned long *addr);
In include/asm-generic/bitops/non-atomic.h
This code largely copied from:
asm-powerpc/bitops.h
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
include/asm-generic/bitops/non-atomic.h | 111 ++++++++++++++++++++++++++++++++
1 files changed, 111 insertions(+)
Index: 2.6-rc/include/asm-generic/bitops/non-atomic.h
===================================================================
--- /dev/null
+++ 2.6-rc/include/asm-generic/bitops/non-atomic.h
@@ -0,0 +1,111 @@
+#ifndef _ASM_GENERIC_BITOPS_NON_ATOMIC_H_
+#define _ASM_GENERIC_BITOPS_NON_ATOMIC_H_
+
+#include <asm/types.h>
+
+#define BITOP_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
+#define BITOP_WORD(nr) ((nr) / BITS_PER_LONG)
+
+/**
+ * __set_bit - Set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * Unlike set_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
+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);
+
+ *p |= mask;
+}
+
+static inline void __clear_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BITOP_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+
+ *p &= ~mask;
+}
+
+/**
+ * __change_bit - Toggle a bit in memory
+ * @nr: the bit to change
+ * @addr: the address to start counting from
+ *
+ * Unlike change_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
+static inline void __change_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BITOP_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+
+ *p ^= mask;
+}
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail. You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_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 old = *p;
+
+ *p = old | mask;
+ return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail. You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BITOP_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long old = *p;
+
+ *p = old & ~mask;
+ return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+ volatile unsigned long *addr)
+{
+ unsigned long mask = BITOP_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
+ unsigned long old = *p;
+
+ *p = old ^ mask;
+ return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile unsigned long *addr)
+{
+ return 1UL & (addr[BITOP_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
+}
+
+#endif /* _ASM_GENERIC_BITOPS_NON_ATOMIC_H_ */
--
^ 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