* Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 19:59 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
I know this is probably a really dumb question, but a wise man once said th=
at the only stupid question is the one that is not asked.
So, I have written a flash driver in VxWorks that simply addresses the flas=
h directly and handles all the hardware accesses just fine. I am porting t=
hat to Linux and need it to run in user space (mainly to simplify the inter=
face with the user - I want to keep it the same as in VxWorks). Here is a =
snippet of what my question is:
static uint8_t bflashEraseSector(int sa, int verbose)
{
uint16_t * flash =3D (uint16_t *) NOR_FLASH_BASE_ADRS;
uint32_t offset;
...
/* We divide by 2 here to adjust for the 16-bit offset into the address */
offset =3D sa * NOR_FLASH_SECTOR_SIZE / 2;
flash[BFLASH_SECTOR_ERASE_ADDR1] =3D BFLASH_SECTOR_ERASE_BYTE1;
...
}
I am trying to get a pointer to NOR_FLASH_BASE_ADRS which is defined to be =
0xFC000000. I then dereference that directly to write to the flash.
How can I get that pointer? Unfortunately I cannot simply use the address =
of the flash. Is there some magical function call that gives me access to =
that portion of the memory space?
Thanks for the help!
Jonathan
PS - I know that I could simply use the MTD driver provided by the kernel, =
but I need to be able to keep the interface the same so we can use previous=
ly written code.
^ permalink raw reply
* Re: Micrel PHY KSZ8001 on MPC5200B FEC
From: Grant Likely @ 2009-10-27 20:08 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200910272054.47398.roman.fietze@telemotive.de>
On Tue, Oct 27, 2009 at 1:54 PM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> Hello Suvidh,
>
> On Tuesday 27 October 2009 17:47:51 suvidh kankariya wrote:
>
>> A driver for micrel phy exists in /drivers/net/phy/micrel.c. in
>> 2.6.30.
>
> Am I somewhat blind, or do you have access to other 2.6.30's than I
> have?
>
> I searched git.kernel.org, git.denx.de and git.secretlab.ca, but could
> not find that file, neither in the current master, nor in older tags
> somewhat related to "2.6.30", nor in any local clone in any version of
> the 2.6 since "He" created the repos.
No, there is a marvell driver, but not a micrel one. If the generic
phy driver doesn't work for you, then yes, add a new micrel driver.
To hook it up to the MPC5200 FEC, you just need to have the correct
PHY address in your board's .dts file.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Accessing flash directly from User Space
From: Bill Gatliff @ 2009-10-27 20:13 UTC (permalink / raw)
To: Jonathan Haws; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330D3666C@midas.usurf.usu.edu>
Jonathan Haws wrote:
>
> How can I get that pointer? Unfortunately I cannot simply use the address of the flash. Is there some magical function call that gives me access to that portion of the memory space?
>
$ man 2 mmap
You want MAP_SHARED and O_SYNC.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* RE: Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 20:15 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4AE7545F.80805@billgatliff.com>
> > How can I get that pointer? Unfortunately I cannot simply use the
> address of the flash. Is there some magical function call that
> gives me access to that portion of the memory space?
> >
>=20
> $ man 2 mmap
>=20
> You want MAP_SHARED and O_SYNC.
To use that I need to have a file descriptor to a device, do I not? Howeve=
r, I do not have a base flash driver to give me that file descriptor. Am I=
missing something with that call?
Thanks!
^ permalink raw reply
* Re: Accessing flash directly from User Space
From: Bill Gatliff @ 2009-10-27 20:30 UTC (permalink / raw)
To: Jonathan Haws; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330D366B6@midas.usurf.usu.edu>
Jonathan Haws wrote:
>>> How can I get that pointer? Unfortunately I cannot simply use the
>>>
>> address of the flash. Is there some magical function call that
>> gives me access to that portion of the memory space?
>>
>> $ man 2 mmap
>>
>> You want MAP_SHARED and O_SYNC.
>>
>
>
> To use that I need to have a file descriptor to a device, do I not? However, I do not have a base flash driver to give me that file descriptor. Am I missing something with that call?
>
/dev/mem
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* RE: Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 20:31 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4AE75859.5050108@billgatliff.com>
> Jonathan Haws wrote:
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
> >> $ man 2 mmap
> >>
> >> You want MAP_SHARED and O_SYNC.
> >>
> >
> >
> > To use that I need to have a file descriptor to a device, do I
> not? However, I do not have a base flash driver to give me that
> file descriptor. Am I missing something with that call?
> >
>=20
> /dev/mem
Ah, yes. I told you this was going to be a dumb question.
Thanks, Bill.
Jonathan
^ permalink raw reply
* RE: Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 22:24 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4AE75859.5050108@billgatliff.com>
> >>> How can I get that pointer? Unfortunately I cannot simply use
> the
> >>>
> >> address of the flash. Is there some magical function call that
> >> gives me access to that portion of the memory space?
> >>
> >> $ man 2 mmap
> >>
> >> You want MAP_SHARED and O_SYNC.
> >>
> >
> >
> > To use that I need to have a file descriptor to a device, do I
> not? However, I do not have a base flash driver to give me that
> file descriptor. Am I missing something with that call?
> >
>=20
> /dev/mem
>=20
Okay, I now have access to the flash memory, however when I write to it the=
writes do not take. I have tried calling msync() on the mapping to no ava=
il. I have opened the fd with O_SYNC, but cannot get things to work right.
Here are the calls:
int fd =3D open("/dev/mem", O_SYNC | O_RDWR);
uint16_t * flash =3D (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
(PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
NOR_FLASH_BASE_ADRS);
When I do flash[0] =3D 0x1234, and then check the value, they do not match.
flash[0] =3D 0x1234;
msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
printf("flash[0] =3D %#04x\n", flash[0]);
That prints flash[0] =3D 0x7f45. I have verified that I am reading the cor=
rect values. I can display the flash contents in U-Boot and 7f45 is what i=
s in the first 16 bits of flash.
Why can I not write to flash? What am I doing wrong?
Thanks!
Jonathan
^ permalink raw reply
* Re: Accessing flash directly from User Space
From: Scott Wood @ 2009-10-27 22:32 UTC (permalink / raw)
To: Jonathan Haws; +Cc: Bill Gatliff, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330D3688B@midas.usurf.usu.edu>
Jonathan Haws wrote:
> Okay, I now have access to the flash memory, however when I write to it the writes do not take. I have tried calling msync() on the mapping to no avail. I have opened the fd with O_SYNC, but cannot get things to work right.
>
> Here are the calls:
>
> int fd = open("/dev/mem", O_SYNC | O_RDWR);
> uint16_t * flash = (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
> (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
> NOR_FLASH_BASE_ADRS);
>
> When I do flash[0] = 0x1234, and then check the value, they do not match.
>
> flash[0] = 0x1234;
> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> printf("flash[0] = %#04x\n", flash[0]);
>
> That prints flash[0] = 0x7f45. I have verified that I am reading the correct values. I can display the flash contents in U-Boot and 7f45 is what is in the first 16 bits of flash.
>
> Why can I not write to flash? What am I doing wrong?
Flash does not work that way -- you must send it commands to erase a
block, and then further commands to program new data.
It sounds like what you really want is the /dev/mtd or /dev/mtdblock
interface, not raw access to the flash chip.
-Scott
^ permalink raw reply
* RE: Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 22:33 UTC (permalink / raw)
To: rubini@gnudd.com; +Cc: bgat@billgatliff.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20091027223221.GA11293@mail.gnudd.com>
> > Okay, I now have access to the flash memory, however when I write
> to
> > it the writes do not take.
>=20
>=20
> > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
>=20
> MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local
> in-ram copy of the data, not to the original one.
I apologize, that MAP_PRIVATE was leftover from me trying to get it to work=
. With MAP_SHARED I am having the problem.
Sorry for the confusion.
^ permalink raw reply
* RE: Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 22:35 UTC (permalink / raw)
To: Scott Wood; +Cc: Bill Gatliff, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4AE774ED.8050502@freescale.com>
> > Okay, I now have access to the flash memory, however when I write
> to it the writes do not take. I have tried calling msync() on the
> mapping to no avail. I have opened the fd with O_SYNC, but cannot
> get things to work right.
> >
> > Here are the calls:
> >
> > int fd =3D open("/dev/mem", O_SYNC | O_RDWR);
> > uint16_t * flash =3D (uint16_t *)mmap(NULL, NOR_FLASH_SIZE,
> > (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
> > NOR_FLASH_BASE_ADRS);
> >
> > When I do flash[0] =3D 0x1234, and then check the value, they do not
> match.
> >
> > flash[0] =3D 0x1234;
> > msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> > printf("flash[0] =3D %#04x\n", flash[0]);
> >
> > That prints flash[0] =3D 0x7f45. I have verified that I am reading
> the correct values. I can display the flash contents in U-Boot and
> 7f45 is what is in the first 16 bits of flash.
> >
> > Why can I not write to flash? What am I doing wrong?
>=20
> Flash does not work that way -- you must send it commands to erase a
> block, and then further commands to program new data.
I realize that. I have a driver written that does exactly that. However, =
I need to be able to write to certain registers to setup the erasure. The =
driver works perfectly in VxWorks, now I am porting it to Linux.
> It sounds like what you really want is the /dev/mtd or /dev/mtdblock
> interface, not raw access to the flash chip.
As mentioned in my initial post, I need to use my custom driver to maintain=
the interface to the application that uses the flash for data storage.
I had thought about using MTD, but decided against it because with previous=
benchmarking that we did with MTD and our custom driver, we found that our=
custom driver was about 10x faster.
^ permalink raw reply
* Re: Accessing flash directly from User Space
From: Alessandro Rubini @ 2009-10-27 22:32 UTC (permalink / raw)
To: Jonathan.Haws; +Cc: bgat, linuxppc-dev
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330D3688B@midas.usurf.usu.edu >
> Okay, I now have access to the flash memory, however when I write to
> it the writes do not take.
> (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local
in-ram copy of the data, not to the original one.
/alessandro
^ permalink raw reply
* Re: Accessing flash directly from User Space
From: Scott Wood @ 2009-10-27 22:42 UTC (permalink / raw)
To: Jonathan Haws; +Cc: Bill Gatliff, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330D368AA@midas.usurf.usu.edu>
Jonathan Haws wrote:
>>> flash[0] = 0x1234;
>>> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
>>> printf("flash[0] = %#04x\n", flash[0]);
>>>
>>> That prints flash[0] = 0x7f45. I have verified that I am reading
>> the correct values. I can display the flash contents in U-Boot and
>> 7f45 is what is in the first 16 bits of flash.
>>> Why can I not write to flash? What am I doing wrong?
>> Flash does not work that way -- you must send it commands to erase a
>> block, and then further commands to program new data.
>
> I realize that. I have a driver written that does exactly that.
> However, I need to be able to write to certain registers to setup the
> erasure.
Will the device respond to 0x1234 being written at offset zero? You
generally have to poke these things pretty specifically in order to get
them to go into command mode.
> The driver works perfectly in VxWorks,
Including the 0x1234 thing?
>> It sounds like what you really want is the /dev/mtd or /dev/mtdblock
>> interface, not raw access to the flash chip.
>
> As mentioned in my initial post, I need to use my custom driver to maintain the interface to the application that uses the flash for data storage.
>
> I had thought about using MTD, but decided against it because with
> previous benchmarking that we did with MTD and our custom driver, we
> found that our custom driver was about 10x faster.
Ouch. Any idea where the slowdown is coming from?
-Scott
^ permalink raw reply
* Re: Accessing flash directly from User Space
From: Alessandro Rubini @ 2009-10-27 22:42 UTC (permalink / raw)
To: Jonathan.Haws; +Cc: scottwood, bgat, linuxppc-dev
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330D368AA@midas.usurf.usu.edu >
> I realize that. I have a driver written that does exactly that.
> However, I need to be able to write to certain registers to setup
> the erasure. The driver works perfectly in VxWorks, now I am
> porting it to Linux.
Most likey you are hit by the compiler reordering the accesses and
caching data in registers. You should try to use volatile pointers
(but also read the "volatile considered harmful" file in the kernel
sources -- anyways you are doing bad things nonetheless), or add
memory barriers (copy the mb() and wmb() macros defined for kernel
space).
Then, the first-word-access you show is wrong, as Scott Wood told you,
so the fact that _that_ access is not working even across msync
that's another matter.
I usually have no serious problems with driving hardware from
/dev/mem, although I've never done flash specifically as mtd is there.
hope this helps
/alessandro
^ permalink raw reply
* RE: Accessing flash directly from User Space
From: Jonathan Haws @ 2009-10-27 22:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Bill Gatliff, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4AE7775D.8080502@freescale.com>
> Jonathan Haws wrote:
> >>> flash[0] =3D 0x1234;
> >>> msync(flash, NOR_FLASH_SIZE, MS_SYNC | MS_INVALIDATE);
> >>> printf("flash[0] =3D %#04x\n", flash[0]);
> >>>
> >>> That prints flash[0] =3D 0x7f45. I have verified that I am
> reading
> >> the correct values. I can display the flash contents in U-Boot
> and
> >> 7f45 is what is in the first 16 bits of flash.
> >>> Why can I not write to flash? What am I doing wrong?
> >> Flash does not work that way -- you must send it commands to
> erase a
> >> block, and then further commands to program new data.
> >
> > I realize that. I have a driver written that does exactly that.
> > However, I need to be able to write to certain registers to setup
> the
> > erasure.
>=20
> Will the device respond to 0x1234 being written at offset zero? You
> generally have to poke these things pretty specifically in order to
> get
> them to go into command mode.
>=20
It should because that is the first data location in flash. Also, just to =
be sure I am telling the truth, I tried writing to one of the registers to =
setup an erase and got the same results - the value did not get written.
> > The driver works perfectly in VxWorks,
>=20
> Including the 0x1234 thing?
Actually, I have not tried that - I have not had to since the driver worked=
.
> >> It sounds like what you really want is the /dev/mtd or
> /dev/mtdblock
> >> interface, not raw access to the flash chip.
> >
> > As mentioned in my initial post, I need to use my custom driver to
> maintain the interface to the application that uses the flash for
> data storage.
> >
> > I had thought about using MTD, but decided against it because with
> > previous benchmarking that we did with MTD and our custom driver,
> we
> > found that our custom driver was about 10x faster.
>=20
> Ouch. Any idea where the slowdown is coming from?
>From what I remember (I would have to dig up notes to make sure) it is some=
thing to do with MTD looking for a signal to go high that is processed a bu=
nch before MTD even sees it. Our flash produces a hardware ready signal th=
at we are triggering off of to move on. MTD took much longer to report to =
us that the hardware was ready.
Thanks
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-10-27 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <1256627452.11607.90.camel@pasglop>
On Tue, 2009-10-27 at 18:11 +1100, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Some of these might have been better in -rc4 or earlier, all my fault
> for having some backlog that I'm still going through. So we have some
> bug fixes (not necessarily regressions but also generally simple
> enough that I decided to go for 2.6.32 anyways) and a few very trivial
> Kconfig cleanups (outside of arch/powerpc but related to our symbols)
> from Kumar that could go anytime.
I also had a pending pull request from Grant that I had forgotten. I
added that, it's also minor stuff (device-tree and defconfig updates
mostly and a couple of bug fixes).
New consolidated pull request below.
Cheers,
Ben.
The following changes since commit 964fe080d94db82a3268443e9b9ece4c60246414:
Linus Torvalds (1):
Merge git://git.kernel.org/.../rusty/linux-2.6-for-linus
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Andreas Schwab (2):
powerpc: Fix segment mapping in vdso32
powerpc: Align vDSO base address
Benjamin Herrenschmidt (2):
powerpc/ppc64: Use preempt_schedule_irq instead of preempt_schedule
Merge commit 'gcl/merge' into merge
Grant Likely (1):
powerpc/5200: Update defconfigs
Heiko Schocher (2):
mpc5200: support for the MAN mpc5200 based board uc101
mpc5200: support for the MAN mpc5200 based board mucmc52
Josh Boyer (1):
powerpc/booke: Fix xmon single step on PowerPC Book-E
Julia Lawall (1):
drivers/serial/mpc52xx_uart.c: Use UPIO_MEM rather than SERIAL_IO_MEM
Jérôme Pouiller (1):
of: Remove nested function
Kumar Gala (7):
powerpc: Add a Book-3E 64-bit defconfig
powerpc: Fix compile errors found by new ppc64e_defconfig
powerpc: Limit hugetlbfs support to PPC64 Book-3S machines
powerpc: Limit memory hotplug support to PPC64 Book-3S machines
powerpc: Minor cleanup to init/Kconfig
powerpc: Minor cleanup to sound/ppc/Kconfig
powerpc: Minor cleanup to lib/Kconfig.debug
Michael Neuling (1):
powerpc/perf_events: Fix priority of MSR HV vs PR bits
Stephen Rothwell (1):
powerpc/iseries: Remove compiler version dependent hack
Wolfram Sang (1):
powerpc/boot/dts: drop obsolete 'fsl5200-clocking'
arch/powerpc/boot/dts/cm5200.dts | 1 -
arch/powerpc/boot/dts/digsy_mtc.dts | 1 -
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/boot/dts/media5200.dts | 2 -
arch/powerpc/boot/dts/motionpro.dts | 1 -
arch/powerpc/boot/dts/mpc5121ads.dts | 3 -
arch/powerpc/boot/dts/mucmc52.dts | 332 ++++
arch/powerpc/boot/dts/pcm030.dts | 2 -
arch/powerpc/boot/dts/pcm032.dts | 2 -
arch/powerpc/boot/dts/tqm5200.dts | 1 -
arch/powerpc/boot/dts/uc101.dts | 284 ++++
arch/powerpc/configs/52xx/cm5200_defconfig | 136 +-
arch/powerpc/configs/52xx/lite5200b_defconfig | 153 ++-
arch/powerpc/configs/52xx/motionpro_defconfig | 146 +-
arch/powerpc/configs/52xx/pcm030_defconfig | 142 +-
arch/powerpc/configs/52xx/tqm5200_defconfig | 148 +-
arch/powerpc/configs/mpc5200_defconfig | 192 ++-
arch/powerpc/configs/ppc64e_defconfig | 2199 +++++++++++++++++++++++++
arch/powerpc/kernel/entry_64.S | 41 +-
arch/powerpc/kernel/pci_64.c | 2 +
arch/powerpc/kernel/perf_event.c | 17 +-
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/setup_64.c | 1 -
arch/powerpc/kernel/vdso.c | 11 +-
arch/powerpc/kernel/vdso32/vdso32.lds.S | 4 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 2 +
arch/powerpc/platforms/iseries/Makefile | 11 +-
arch/powerpc/platforms/iseries/dt.c | 56 +-
arch/powerpc/xmon/xmon.c | 20 +-
drivers/of/of_mdio.c | 13 +-
drivers/serial/mpc52xx_uart.c | 2 +-
fs/Kconfig | 2 +-
init/Kconfig | 2 +-
lib/Kconfig.debug | 2 +-
mm/Kconfig | 2 +-
sound/ppc/Kconfig | 2 +-
37 files changed, 3490 insertions(+), 451 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mucmc52.dts
create mode 100644 arch/powerpc/boot/dts/uc101.dts
create mode 100644 arch/powerpc/configs/ppc64e_defconfig
^ permalink raw reply
* Re: Is there a patch for MPC8548 XOR?
From: Kim Phillips @ 2009-10-27 23:28 UTC (permalink / raw)
To: hank peng; +Cc: linuxppc-dev
In-Reply-To: <389deec70910262043v34bcd7edy6f00241d126b1816@mail.gmail.com>
On Tue, 27 Oct 2009 11:43:34 +0800
hank peng <pengxihan@gmail.com> wrote:
> I want to use its' XOR engine to compute raid5 parity, but I can't
> find this function in 2.6.30 downloaded from kernel.org, someone know
> if there is a patch?
try this:
http://patchwork.ozlabs.org/patch/36067/
Kim
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
From: Steven Rostedt @ 2009-10-27 22:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Frederic Weisbecker, Ingo Molnar, linuxppc-dev
In-Reply-To: <20091027044742.GB3085@kryten>
I have no problem with any of these changes. I guess this is up to Ben
and company to decide the rest.
-- Steve
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
From: Benjamin Herrenschmidt @ 2009-10-27 23:41 UTC (permalink / raw)
To: rostedt; +Cc: Frederic Weisbecker, Ingo Molnar, linuxppc-dev, Anton Blanchard
In-Reply-To: <1256680832.26028.469.camel@gandalf.stny.rr.com>
On Tue, 2009-10-27 at 18:00 -0400, Steven Rostedt wrote:
> I have no problem with any of these changes. I guess this is up to Ben
> and company to decide the rest.
I'll stick them into my -next branch, hopefully today or tomorrow.
The ppc "perf_events" specific bits are going to go via paulus first.
Cheers,
Ben.
^ permalink raw reply
* Re: help with unhandled IRQ error with mpt2sas driver and powerpc 460EX
From: Benjamin Herrenschmidt @ 2009-10-28 0:22 UTC (permalink / raw)
To: Ayman El-Khashab; +Cc: linuxppc-dev
In-Reply-To: <4AE72D83.7000404@elkhashab.com>
On Tue, 2009-10-27 at 12:27 -0500, Ayman El-Khashab wrote:
>
> The first problem I noticed is that the physical address is read into a
> 32 bit variable, but the 460ex has a 36 bit bus so the ioremap would
> always fail. I've change the defn of chip_phys in mpt2sas_base.h to u64
> and that cleared up that issue.
That looks indeed like a common driver bug. Please make sure you submit
the fix upstream. The "right" type to use is resource_size_t in fact.
> As soon as the unmask_interrupts
> method is called (or not long after),
What exactly is that "method" ? IE. A driver function that enables
emission of interrupts on the device ?
> I get an interrupt -- presumably
> from the sas controller. If I comment out the unmask, the interrupt
> never occurs. If I unmask them, I get the interrupt. I've traced the
> code through the interrupt handler all the way to ~ line 757.
Unmask at what level ? The linux level (enable_irq() -> UIC unmask) or
the card level ?
> rpf = &ioc->reply_post_free[ioc->reply_post_host_index];
>
> I've verified that at the end of this, IRQ_NONE is returned. At this
> point the kernel prints the following -- the last statements lead me to
> think that the sas controller expected something but never got it. I am
> unsure how to proceed at this point. I am using a denx kernel head
> pulled from git today since there were some changes to thsi driver for
> endian issues.
Well, if the interrupt is indeed coming from the card and the driver's
interrupt handler can't figure it out, then you are facing a bug in the
driver. I would recommend you work with whoever is maintaining that
driver to help sort it out.
Cheers,
Ben.
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [c0367df0] [c0005eac] show_stack+0x44/0x16c (unreliable)
> [c0367e30] [c004eedc] __report_bad_irq+0x34/0xb8
> [c0367e50] [c004f118] note_interrupt+0x1b8/0x224
> [c0367e80] [c004ff50] handle_level_irq+0xa0/0x11c
> [c0367e90] [c0018ba4] uic_irq_cascade+0xf8/0x12c
> [c0367eb0] [c00041d0] do_IRQ+0x98/0xb4
> [c0367ed0] [c000df40] ret_from_except+0x0/0x18
> [c0367f90] [c0006ed8] cpu_idle+0x50/0xd8
> [c0367fb0] [c000197c] rest_init+0x5c/0x70
> [c0367fc0] [c0320848] start_kernel+0x224/0x2a0
> [c0367ff0] [c0000200] skpinv+0x190/0x1cc
> handlers:
> [<c01aba98>] (_base_interrupt+0x0/0x8f8)
> Disabling IRQ #18
> mpt2sas0: _base_event_notification: timeout
> mf:
> 07000000 00000000 00000000 00000000 00000000 0f2f3fff fffffffc
> ffffffff
> ffffffff 00000000 00000000
> mpt2sas0: sending diag reset !!
> mpt2sas0: diag reset: SUCCESS
> mpt2sas0: failure at
> drivers/scsi/mpt2sas/mpt2sas_scsih.c:5989/_scsih_probe()!
>
> Thanks
> Ayman
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: Is there a patch for MPC8548 XOR?
From: hank peng @ 2009-10-28 0:45 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20091027182830.8e99be49.kim.phillips@freescale.com>
2009/10/28 Kim Phillips <kim.phillips@freescale.com>:
> On Tue, 27 Oct 2009 11:43:34 +0800
> hank peng <pengxihan@gmail.com> wrote:
>
>> I want to use its' XOR engine to compute raid5 parity, but I can't
>> find this function in 2.6.30 downloaded from kernel.org, someone know
>> if there is a patch?
>
> try this:
>
> http://patchwork.ozlabs.org/patch/36067/
>
Thanks, but I have three questions:
1. Will the patch be added to kernel in the future?
2. If I have problem in using this patch, will you or other guys help
me to fix it?
3. Is this patch based on 2.6.30, because we are using this version of kernel.
> Kim
>
--
The simplest is not all best but the best is surely the simplest!
^ permalink raw reply
* linux-next: manual merge of the sh tree with the powerpc-merge tree
From: Stephen Rothwell @ 2009-10-28 2:13 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-kernel, linuxppc-dev, linux-next, Paul Mackerras
Hi Paul,
Today's linux-next merge of the sh tree got a conflict in fs/Kconfig
between commit 0cd9ad73b8d181737005ff4e506b9b6bd043f4dd ("powerpc: Limit
hugetlbfs support to PPC64 Book-3S machines") from the powerpc-merge tree
and commit ffb4a73d8906f71910e6c83ec2b499e70025ee8e ("sh: Fix hugetlbfs
dependencies for SH-3 && MMU configurations") from the sh tree.
I fixed it up (see below) and can carry the fix for a while (the
powerpc-merge commit should be in Linus' tree soon).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/Kconfig
index f93d0ed,48b81f9..0000000
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@@ -135,8 -135,8 +135,8 @@@ config TMPFS_POSIX_AC
config HUGETLBFS
bool "HugeTLB file system support"
- depends on X86 || IA64 || PPC_BOOK3S_64 || SPARC64 || (SUPERH && MMU) || \
- depends on X86 || IA64 || PPC64 || SPARC64 || (S390 && 64BIT) || \
- SYS_SUPPORTS_HUGETLBFS || BROKEN
++ depends on X86 || IA64 || PPC_BOOK3S_64 || SPARC64 || \
+ (S390 && 64BIT) || SYS_SUPPORTS_HUGETLBFS || BROKEN
help
hugetlbfs is a filesystem backing for HugeTLB pages, based on
ramfs. For architectures that support it, say Y here and read
^ permalink raw reply
* [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
From: santosh shukla @ 2009-10-27 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: john.linn
From: Santosh Shukla <sshukla@sh.mvista.com>
Date: Tue, 13 Oct 2009 18:55:57 +0530
Subject: [PATCH] Xilinx LL-TEMAC: Add Netpoll controller support
Adding Netpoll controller support to Xilinx LL-TEMAC ethernet
driver.Replaced Rx, Tx tasklet schedule call with their handlers,
Added correct version of call which can execute interrupt on/off
context i.e. dev_kfree_skb_any().
---
drivers/net/xilinx_lltemac/xlltemac_main.c | 41 +++++++++++++++++++++++++++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/net/xilinx_lltemac/xlltemac_main.c b/drivers/net/xilinx_lltemac/xlltemac_main.c
index b245422..697f474 100644
--- a/drivers/net/xilinx_lltemac/xlltemac_main.c
+++ b/drivers/net/xilinx_lltemac/xlltemac_main.c
@@ -87,11 +87,18 @@
#define BUFFER_ALIGNSEND_PERF(adr) ((ALIGNMENT_SEND_PERF - ((u32) adr)) % 32)
#define BUFFER_ALIGNRECV(adr) ((ALIGNMENT_RECV - ((u32) adr)) % 32)
+#ifndef CONFIG_NET_POLL_CONTROLLER
/* Default TX/RX Threshold and waitbound values for SGDMA mode */
#define DFT_TX_THRESHOLD 24
#define DFT_TX_WAITBOUND 254
#define DFT_RX_THRESHOLD 4
#define DFT_RX_WAITBOUND 254
+#else
+#define DFT_TX_THRESHOLD 1
+#define DFT_TX_WAITBOUND 0
+#define DFT_RX_THRESHOLD 1
+#define DFT_RX_WAITBOUND 0
+#endif
#define XTE_AUTOSTRIPPING 1
@@ -1097,7 +1104,11 @@ static irqreturn_t xenet_dma_rx_interrupt(int irq, void *dev_id)
list_add_tail(&lp->rcv, &receivedQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.RxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaRecvBH);
+#else
+ DmaRecvHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&receivedQueueSpin, flags);
}
@@ -1134,7 +1145,11 @@ static irqreturn_t xenet_dma_tx_interrupt(int irq, void *dev_id)
list_add_tail(&lp->xmit, &sentQueue);
XLlDma_mBdRingIntDisable(&lp->Dma.TxBdRing,
XLLDMA_CR_IRQ_ALL_EN_MASK);
+#ifndef CONFIG_NET_POLL_CONTROLLER
tasklet_schedule(&DmaSendBH);
+#else
+ DmaSendHandlerBH(0);
+#endif
}
spin_unlock_irqrestore(&sentQueueSpin, flags);
}
@@ -1711,11 +1726,15 @@ static int xenet_DmaSend(struct sk_buff *skb, struct net_device *dev)
* SgAlloc, SgCommit sequence, which also exists in DmaSendHandlerBH Bottom
* Half, or triggered by other processor in SMP case.
*/
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_lock_bh(&XTE_tx_spinlock);
+#endif
xenet_DmaSend_internal(skb, dev);
+#ifndef CONFIG_NET_POLL_CONTROLLER
spin_unlock_bh(&XTE_tx_spinlock);
+#endif
return 0;
}
@@ -1764,7 +1783,7 @@ static void DmaSendHandlerBH(unsigned long p)
skb = (struct sk_buff *)
XLlDma_mBdGetId(BdCurPtr);
if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
/* reset BD id */
XLlDma_mBdSetId(BdCurPtr, NULL);
@@ -3220,6 +3239,23 @@ static int detect_phy(struct net_local *lp, char *dev_name)
return 0; /* default to zero */
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void
+lltemac_poll_controller(struct net_device *ndev)
+{
+ struct net_local *lp = netdev_priv(ndev);
+
+ disable_irq(lp->dma_irq_s);
+ disable_irq(lp->dma_irq_r);
+
+ xenet_dma_tx_interrupt(lp->dma_irq_s, ndev);
+ xenet_dma_rx_interrupt(lp->dma_irq_r, ndev);
+
+ enable_irq(lp->dma_irq_s);
+ enable_irq(lp->dma_irq_r);
+}
+#endif
+
static struct net_device_ops xilinx_netdev_ops;
/* From include/linux/ethtool.h */
@@ -3491,6 +3527,9 @@ static struct net_device_ops xilinx_netdev_ops = {
.ndo_change_mtu = xenet_change_mtu,
.ndo_tx_timeout = xenet_tx_timeout,
.ndo_get_stats = xenet_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = lltemac_poll_controller,
+#endif
};
static struct of_device_id xtenet_fifo_of_match[] = {
--
1.6.3.3.220.g609a0
^ permalink raw reply related
* [PATCH] powerpc/perf_counter: Enable SDAR in continous sample mode
From: Anton Blanchard @ 2009-10-28 4:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20090922030109.GG31801@kryten>
In continuous sampling mode we want the SDAR to update. While we can
select between dcache misses and erat misses, a decent default is to
enable both.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Moved MMCRA definitions into asm/reg.h.
Index: linux.trees.git/arch/powerpc/kernel/power7-pmu.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/power7-pmu.c 2009-10-28 14:02:08.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/power7-pmu.c 2009-10-28 14:03:04.000000000 +1100
@@ -51,10 +51,6 @@
#define MMCR1_PMCSEL_MSK 0xff
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
* 3210987654321098765432109876543210987654321098765432109876543210
@@ -230,7 +226,7 @@ static int power7_compute_mmcr(u64 event
unsigned int hwc[], unsigned long mmcr[])
{
unsigned long mmcr1 = 0;
- unsigned long mmcra = 0;
+ unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
unsigned int pmc, unit, combine, l2sel, psel;
unsigned int pmc_inuse = 0;
int i;
Index: linux.trees.git/arch/powerpc/kernel/power5-pmu.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/power5-pmu.c 2009-10-28 14:02:08.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/power5-pmu.c 2009-10-28 14:03:04.000000000 +1100
@@ -73,10 +73,6 @@
#define MMCR1_PMCSEL_MSK 0x7f
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
* 3210987654321098765432109876543210987654321098765432109876543210
@@ -390,7 +386,7 @@ static int power5_compute_mmcr(u64 event
unsigned int hwc[], unsigned long mmcr[])
{
unsigned long mmcr1 = 0;
- unsigned long mmcra = 0;
+ unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
unsigned int pmc, unit, byte, psel;
unsigned int ttm, grp;
int i, isbus, bit, grsel;
Index: linux.trees.git/arch/powerpc/kernel/power6-pmu.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/power6-pmu.c 2009-10-28 14:02:08.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/power6-pmu.c 2009-10-28 14:03:04.000000000 +1100
@@ -178,7 +178,7 @@ static int p6_compute_mmcr(u64 event[],
unsigned int hwc[], unsigned long mmcr[])
{
unsigned long mmcr1 = 0;
- unsigned long mmcra = 0;
+ unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
int i;
unsigned int pmc, ev, b, u, s, psel;
unsigned int ttmset = 0;
Index: linux.trees.git/arch/powerpc/include/asm/reg.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/reg.h 2009-10-28 14:02:08.000000000 +1100
+++ linux.trees.git/arch/powerpc/include/asm/reg.h 2009-10-28 14:03:33.000000000 +1100
@@ -489,6 +489,8 @@
#define SPRN_MMCR1 798
#define SPRN_MMCRA 0x312
#define MMCRA_SDSYNC 0x80000000UL /* SDAR synced with SIAR */
+#define MMCRA_SDAR_DCACHE_MISS 0x40000000UL
+#define MMCRA_SDAR_ERAT_MISS 0x20000000UL
#define MMCRA_SIHV 0x10000000UL /* state of MSR HV when SIAR set */
#define MMCRA_SIPR 0x08000000UL /* state of MSR PR when SIAR set */
#define MMCRA_SLOT 0x07000000UL /* SLOT bits (37-39) */
Index: linux.trees.git/arch/powerpc/kernel/power5+-pmu.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/power5+-pmu.c 2009-10-28 14:03:57.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/power5+-pmu.c 2009-10-28 14:03:58.000000000 +1100
@@ -73,10 +73,6 @@
#define MMCR1_PMCSEL_MSK 0x7f
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
* 3210987654321098765432109876543210987654321098765432109876543210
Index: linux.trees.git/arch/powerpc/kernel/ppc970-pmu.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/ppc970-pmu.c 2009-10-28 14:03:57.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/ppc970-pmu.c 2009-10-28 14:03:58.000000000 +1100
@@ -84,10 +84,6 @@ static short mmcr1_adder_bits[8] = {
};
/*
- * Bits in MMCRA
- */
-
-/*
* Layout of constraint bits:
* 6666555555555544444444443333333333222222222211111111110000000000
* 3210987654321098765432109876543210987654321098765432109876543210
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Create PPC_WARN_ALIGNMENT to match PPC_WARN_EMULATED
From: Anton Blanchard @ 2009-10-28 4:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: a.p.zijlstra, linux-kernel, linuxppc-dev, paulus, mingo
In-Reply-To: <20091018233749.0a17ff78.sfr@canb.auug.org.au>
Hi Stephen,
> I think this last line is not needed?
Right you are!
Anton
--
perf_event wants a separate event for alignment and emulation faults,
so create another emulation event. This will make it easy to hook in
perf_event at one spot.
We pass in regs which will be required for these events.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Updated to remove unused define, as suggested by Stephen.
Index: linux.trees.git/arch/powerpc/include/asm/emulated_ops.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/emulated_ops.h 2009-10-19 09:46:58.000000000 +1100
+++ linux.trees.git/arch/powerpc/include/asm/emulated_ops.h 2009-10-21 14:57:00.000000000 +1100
@@ -57,7 +57,7 @@ extern u32 ppc_warn_emulated;
extern void ppc_warn_emulated_print(const char *type);
-#define PPC_WARN_EMULATED(type) \
+#define __PPC_WARN_EMULATED(type) \
do { \
atomic_inc(&ppc_emulated.type.val); \
if (ppc_warn_emulated) \
@@ -66,8 +66,11 @@ extern void ppc_warn_emulated_print(cons
#else /* !CONFIG_PPC_EMULATED_STATS */
-#define PPC_WARN_EMULATED(type) do { } while (0)
+#define __PPC_WARN_EMULATED(type) do { } while (0)
#endif /* !CONFIG_PPC_EMULATED_STATS */
+#define PPC_WARN_EMULATED(type, regs) __PPC_WARN_EMULATED(type)
+#define PPC_WARN_ALIGNMENT(type, regs) __PPC_WARN_EMULATED(type)
+
#endif /* _ASM_POWERPC_EMULATED_OPS_H */
Index: linux.trees.git/arch/powerpc/kernel/align.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/align.c 2009-10-19 09:46:58.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/align.c 2009-10-21 10:21:35.000000000 +1100
@@ -732,7 +732,7 @@ int fix_alignment(struct pt_regs *regs)
#ifdef CONFIG_SPE
if ((instr >> 26) == 0x4) {
- PPC_WARN_EMULATED(spe);
+ PPC_WARN_ALIGNMENT(spe, regs);
return emulate_spe(regs, reg, instr);
}
#endif
@@ -786,7 +786,7 @@ int fix_alignment(struct pt_regs *regs)
flags |= SPLT;
nb = 8;
}
- PPC_WARN_EMULATED(vsx);
+ PPC_WARN_ALIGNMENT(vsx, regs);
return emulate_vsx(addr, reg, areg, regs, flags, nb);
}
#endif
@@ -794,7 +794,7 @@ int fix_alignment(struct pt_regs *regs)
* the exception of DCBZ which is handled as a special case here
*/
if (instr == DCBZ) {
- PPC_WARN_EMULATED(dcbz);
+ PPC_WARN_ALIGNMENT(dcbz, regs);
return emulate_dcbz(regs, addr);
}
if (unlikely(nb == 0))
@@ -804,7 +804,7 @@ int fix_alignment(struct pt_regs *regs)
* function
*/
if (flags & M) {
- PPC_WARN_EMULATED(multiple);
+ PPC_WARN_ALIGNMENT(multiple, regs);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
}
@@ -825,11 +825,11 @@ int fix_alignment(struct pt_regs *regs)
/* Special case for 16-byte FP loads and stores */
if (nb == 16) {
- PPC_WARN_EMULATED(fp_pair);
+ PPC_WARN_ALIGNMENT(fp_pair, regs);
return emulate_fp_pair(addr, reg, flags);
}
- PPC_WARN_EMULATED(unaligned);
+ PPC_WARN_ALIGNMENT(unaligned, regs);
/* If we are loading, get the data from user space, else
* get it from register values
Index: linux.trees.git/arch/powerpc/kernel/traps.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/traps.c 2009-10-19 09:46:58.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/traps.c 2009-10-21 10:21:35.000000000 +1100
@@ -759,7 +759,7 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & PPC_INST_MFSPR_PVR_MASK) == PPC_INST_MFSPR_PVR) {
- PPC_WARN_EMULATED(mfpvr);
+ PPC_WARN_EMULATED(mfpvr, regs);
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
@@ -767,7 +767,7 @@ static int emulate_instruction(struct pt
/* Emulating the dcba insn is just a no-op. */
if ((instword & PPC_INST_DCBA_MASK) == PPC_INST_DCBA) {
- PPC_WARN_EMULATED(dcba);
+ PPC_WARN_EMULATED(dcba, regs);
return 0;
}
@@ -776,7 +776,7 @@ static int emulate_instruction(struct pt
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf0000000UL >> shift;
- PPC_WARN_EMULATED(mcrxr);
+ PPC_WARN_EMULATED(mcrxr, regs);
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf0000000UL;
return 0;
@@ -784,19 +784,19 @@ static int emulate_instruction(struct pt
/* Emulate load/store string insn. */
if ((instword & PPC_INST_STRING_GEN_MASK) == PPC_INST_STRING) {
- PPC_WARN_EMULATED(string);
+ PPC_WARN_EMULATED(string, regs);
return emulate_string_inst(regs, instword);
}
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & PPC_INST_POPCNTB_MASK) == PPC_INST_POPCNTB) {
- PPC_WARN_EMULATED(popcntb);
+ PPC_WARN_EMULATED(popcntb, regs);
return emulate_popcntb_inst(regs, instword);
}
/* Emulate isel (Integer Select) instruction */
if ((instword & PPC_INST_ISEL_MASK) == PPC_INST_ISEL) {
- PPC_WARN_EMULATED(isel);
+ PPC_WARN_EMULATED(isel, regs);
return emulate_isel(regs, instword);
}
@@ -995,7 +995,7 @@ void SoftwareEmulation(struct pt_regs *r
#ifdef CONFIG_MATH_EMULATION
errcode = do_mathemu(regs);
if (errcode >= 0)
- PPC_WARN_EMULATED(math);
+ PPC_WARN_EMULATED(math, regs);
switch (errcode) {
case 0:
@@ -1018,7 +1018,7 @@ void SoftwareEmulation(struct pt_regs *r
#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
errcode = Soft_emulate_8xx(regs);
if (errcode >= 0)
- PPC_WARN_EMULATED(8xx);
+ PPC_WARN_EMULATED(8xx, regs);
switch (errcode) {
case 0:
@@ -1129,7 +1129,7 @@ void altivec_assist_exception(struct pt_
flush_altivec_to_thread(current);
- PPC_WARN_EMULATED(altivec);
+ PPC_WARN_EMULATED(altivec, regs);
err = emulate_altivec(regs);
if (err == 0) {
regs->nip += 4; /* skip emulated instruction */
^ permalink raw reply
* [PATCH 1/7] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Akinobu Mita @ 2009-10-28 8:43 UTC (permalink / raw)
To: linux-kernel, akpm
Cc: linux-usb, linux-ia64, linuxppc-dev, Paul Mackerras,
H. Peter Anvin, sparclinux, Lothar Wassmann, x86, linux-altix,
Ingo Molnar, Fenghua Yu, Joerg Roedel, Akinobu Mita,
Yevgeny Petrilin, Thomas Gleixner, Tony Luck, netdev,
Greg Kroah-Hartman, FUJITA Tomonori, David S. Miller
This introduces new bitmap functions:
bitmap_set: Set specified bit area
bitmap_clear: Clear specified bit area
bitmap_find_next_zero_area: Find free bit area
These are mostly stolen from iommu helper. The differences are:
- Use find_next_bit instead of doing test_bit for each bit
- Rewrite bitmap_set and bitmap_clear
Instead of setting or clearing for each bit.
- Check the last bit of the limit
iommu-helper doesn't want to find such area
- The return value if there is no zero area
find_next_zero_area in iommu helper: returns -1
bitmap_find_next_zero_area: return >= bitmap size
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: linux-usb@vger.kernel.org
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Cc: netdev@vger.kernel.org
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: linux-altix@sgi.com
Cc: Joerg Roedel <joerg.roedel@amd.com>
---
include/linux/bitmap.h | 11 ++++++
lib/bitmap.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 756d78b..daf8c48 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -42,6 +42,9 @@
* bitmap_empty(src, nbits) Are all bits zero in *src?
* bitmap_full(src, nbits) Are all bits set in *src?
* bitmap_weight(src, nbits) Hamming Weight: number set bits
+ * bitmap_set(dst, pos, nbits) Set specified bit area
+ * bitmap_clear(dst, pos, nbits) Clear specified bit area
+ * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area
* bitmap_shift_right(dst, src, n, nbits) *dst = *src >> n
* bitmap_shift_left(dst, src, n, nbits) *dst = *src << n
* bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src)
@@ -108,6 +111,14 @@ extern int __bitmap_subset(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits);
extern int __bitmap_weight(const unsigned long *bitmap, int bits);
+extern void bitmap_set(unsigned long *map, int i, int len);
+extern void bitmap_clear(unsigned long *map, int start, int nr);
+extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask);
+
extern int bitmap_scnprintf(char *buf, unsigned int len,
const unsigned long *src, int nbits);
extern int __bitmap_parse(const char *buf, unsigned int buflen, int is_user,
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 7025658..11bf497 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -271,6 +271,87 @@ int __bitmap_weight(const unsigned long *bitmap, int bits)
}
EXPORT_SYMBOL(__bitmap_weight);
+#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) % BITS_PER_LONG))
+
+void bitmap_set(unsigned long *map, int start, int nr)
+{
+ unsigned long *p = map + BIT_WORD(start);
+ const int size = start + nr;
+ int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
+ unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
+
+ while (nr - bits_to_set >= 0) {
+ *p |= mask_to_set;
+ nr -= bits_to_set;
+ bits_to_set = BITS_PER_LONG;
+ mask_to_set = ~0UL;
+ p++;
+ }
+ if (nr) {
+ mask_to_set &= BITMAP_LAST_WORD_MASK(size);
+ *p |= mask_to_set;
+ }
+}
+EXPORT_SYMBOL(bitmap_set);
+
+void bitmap_clear(unsigned long *map, int start, int nr)
+{
+ unsigned long *p = map + BIT_WORD(start);
+ const int size = start + nr;
+ int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
+ unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
+
+ while (nr - bits_to_clear >= 0) {
+ *p &= ~mask_to_clear;
+ nr -= bits_to_clear;
+ bits_to_clear = BITS_PER_LONG;
+ mask_to_clear = ~0UL;
+ p++;
+ }
+ if (nr) {
+ mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
+ *p &= ~mask_to_clear;
+ }
+}
+EXPORT_SYMBOL(bitmap_clear);
+
+/*
+ * bitmap_find_next_zero_area - find a contiguous aligned zero area
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @align_mask: Alignment mask for zero area
+ *
+ * The @align_mask should be one less than a power of 2; the effect is that
+ * the bit offset of all zero areas this function finds is multiples of that
+ * power of 2. A @align_mask of 0 means no alignment is required.
+ */
+unsigned long bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = __ALIGN_MASK(index, align_mask);
+
+ end = index + nr;
+ if (end > size)
+ return end;
+ i = find_next_bit(map, end, index);
+ if (i < end) {
+ start = i + 1;
+ goto again;
+ }
+ return index;
+}
+EXPORT_SYMBOL(bitmap_find_next_zero_area);
+
/*
* Bitmap printing & parsing functions: first version by Bill Irwin,
* second version by Paul Jackson, third by Joe Korty.
--
1.6.5.1
^ permalink raw reply related
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