* Re: [PATCH] Document Linux's memory barriers [try #5]
From: David Howells @ 2006-03-23 18:34 UTC (permalink / raw)
To: paulmck, davem; +Cc: akpm, linux-arch, linux-kernel, torvalds, linuxppc64-dev
In-Reply-To: <20060316231723.GB1323@us.ibm.com>
Paul E. McKenney <paulmck@us.ibm.com> wrote:
> smp_mb__before_atomic_dec() and friends as well?
These seem to be something Sparc64 related; or, at least, Sparc64 seems to do
something weird with them.
What are these meant to achieve anyway? They seems to just be barrier() on a
lot of systems, even SMP ones.
> Some architectures have more expansive definition of data dependency,
> including then- and else-clauses being data-dependent on the if-condition,
> but this is probably too much detail.
Linus calls that a "control dependency" and doesn't seem to think that's a
problem as it's sorted out by branch prediction. What you said makes me
wonder about conditional instructions (such as conditional move).
Anyway, I've incorporated your comments as well as reworking the document,
which I'll shortly push upstream once again.
David
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-23 17:54 UTC (permalink / raw)
To: Mark Chambers; +Cc: Linuxppc-Embedded ((E-Mail))
In-Reply-To: <00be01c64ea1$4c6e0e20$6401a8c0@CHUCK2>
>
> PCI is actually endian-agnostic, so we're really 'fixing' the
> Freescale PCI implementation with endian swapping.
>
Hi Mark,
Its not agnostic, its little-endian.
The configuration space layout of parameters larger than a
byte are defined in little endian format.
The wiring on the PCI bus is little-endian, and 32-bit
quantities on the bus are represented by a logic analyzer
in little endian format.
But once you start talking about BAR regions, then yeah,
they're your bytes, do with them what you will. My hardware
uses a little-endian TI DSP, and an x86 host, so I
had been using compatible machines.
But the PLX PCI-9054 PCI chipset exposes BAR[0] and BAR[1]
as control registers that are little-endian format.
Conversely, we also use some Janz CAN cards, and their
messaging protocol over PCI uses big-endian format
structures in their protocol.
Dave
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-23 17:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: Chris Wyse, Linuxppc-Embedded ((E-Mail))
In-Reply-To: <CCA437BF-E204-4652-9E6D-25388225EFE8@kernel.crashing.org>
Hi Kumar,
>> When I was testing the Yosemite board as the host, I found
>> that I could set the endian flag on the mmapped page, which
>> then made the PCI device registers read as 32-bit quantities
>> read back with the same layout under both x86 and PPC
>> hosts.
>
> Hmm, I guess I would handle this like how the reset of the kernel
> handle is with the io routines handling the swapping. Not sure if
> there is any advantage to using the endian flag. I guess if you have
> something you are treating as just memory there would be.
I haven't used the feature, I just tested it to see what it did.
The application case I thought of was this; the PCI boards I built
(that I am revising, and replacing the DSP with a PPC) have an
8MB PCI region that I can mmap from the host. I have a test
suite that runs from the host that manipulates registers on the boards
to download FPGAs etc. When the boards are used in a real system,
the onboard DSP is generally used, and the host just talks to
the DSP.
However, for the test suite, if I have a header with definitions
like:
#define CONTROL_FPGA_ENABLE (1 << 0)
#define CONTROL_FPGA_DONE_BIT (1 << 1)
that correspond to bits in a 32-bit PCI mmapped register. Then
code in the user-space test suite that did something like
pci_addr[CONTROL_OFFSET] |= CONTROL_FPGA_ENABLE;
would instead need to be re-written, eg.,
write_le32(&pci_addr[CONTROL_OFFSET], CONTROL_FPGA_ENABLE);
to be portable.
I definitely agree that this is how kernel-level code should be
written, but user-space code ... well, if I want to reuse code
already written, setting the page endian flag and reusing the
code would seem like the way to go. (This isn't what I need
to do, since my host will still be an x86, the PPC will
be a target device, but I still need to think about the
endian issues).
Now of course that I have seen the consequences of my coding,
I'll be more careful to deal with endianness more appropriately.
Its a tricky trade-off though. I could define control ioctl's
that hide all the endianness issues ... but then the driver just
gets bigger. I think the appropriate solution for the user-space
test code would be to use CPU-to-little-endian routines, and
wrap the lot in a re-usable library that the test suite
links against.
> There isn't a sysfs flag for the endianness page attribute since thats
> a PPC book-e specific feature. We could possible expand things to
> support it but, I've been trying to actively avoid using the 'E' bit.
Ok, I haven't received the 8349E board that I am waiting
on, so I hadn't spotted that the PAGE_ENDIAN flag was
Book E specific.
Thanks for your insight.
Cheers
Dave
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: Mark Chambers @ 2006-03-23 17:43 UTC (permalink / raw)
To: Linuxppc-Embedded ((E-Mail))
In-Reply-To: <CCA437BF-E204-4652-9E6D-25388225EFE8@kernel.crashing.org>
>>
>> When I was testing the Yosemite board as the host, I found
>> that I could set the endian flag on the mmapped page, which
>> then made the PCI device registers read as 32-bit quantities
>> read back with the same layout under both x86 and PPC
>> hosts.
>
> Hmm, I guess I would handle this like how the reset of the kernel
> handle is with the io routines handling the swapping. Not sure if
> there is any advantage to using the endian flag. I guess if you have
> something you are treating as just memory there would be.
>
>> So, if someone planned on using that 'feature', that would
>> be a reason for writing your own mmap() implementation.
>> I didn't see any option in the sysfs file for setting that
>> page flag (but, I didn't look around in other sysfs files).
>
> There isn't a sysfs flag for the endianness page attribute since
> thats a PPC book-e specific feature. We could possible expand things
> to support it but, I've been trying to actively avoid using the 'E' bit.
>
Framebuffer applications could care about this. Also, on the MPC8247
(maybe others, but I know about this one) you can make the PCI space
big- or little-endian.
Seems to me this is really not an endian issue but a PCI implementation
issue. PCI is actually endian-agnostic, so we're really 'fixing' the
Freescale
PCI implementation with endian swapping.
Mark Chambers
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: Kumar Gala @ 2006-03-23 17:19 UTC (permalink / raw)
To: David Hawkins; +Cc: Chris Wyse, Linuxppc-Embedded ((E-Mail))
In-Reply-To: <4422D6E3.1010407@ovro.caltech.edu>
On Mar 23, 2006, at 11:12 AM, David Hawkins wrote:
>
>
>> Why don't use the mmap file exposed by sysfs so you dont have to
>> write your own code?
>> See Documentation/filesystems/sysfs-pci.txt. But effectively
>> down under /sys/bus/pci/devices/[domain:bus:dev:func]/ you will
>> get resource[0..N-1] that corresponds to each BAR on the device.
>> This is a mmap file to access that region.
>
> Hi Kumar,
>
> Most likely he didn't know about it, I didn't :)
>
> When I was testing the Yosemite board as the host, I found
> that I could set the endian flag on the mmapped page, which
> then made the PCI device registers read as 32-bit quantities
> read back with the same layout under both x86 and PPC
> hosts.
Hmm, I guess I would handle this like how the reset of the kernel
handle is with the io routines handling the swapping. Not sure if
there is any advantage to using the endian flag. I guess if you have
something you are treating as just memory there would be.
> So, if someone planned on using that 'feature', that would
> be a reason for writing your own mmap() implementation.
> I didn't see any option in the sysfs file for setting that
> page flag (but, I didn't look around in other sysfs files).
There isn't a sysfs flag for the endianness page attribute since
thats a PPC book-e specific feature. We could possible expand things
to support it but, I've been trying to actively avoid using the 'E' bit.
> Thanks for the pointer to the sysfs node!
No problem, its what we're here for :)
- kumar
^ permalink raw reply
* Re: swizzling pci irqs
From: Kumar Gala @ 2006-03-23 17:15 UTC (permalink / raw)
To: David Updegraff; +Cc: linuxppc-embedded
In-Reply-To: <dvuj1k$318$1@sea.gmane.org>
On Mar 23, 2006, at 10:40 AM, David Updegraff wrote:
> Kumar Gala wrote:
>> On Mar 22, 2006, at 2:59 PM, David Updegraff wrote:
>>
>>
>>> Hi.
>>>
>>> If there were a noswizzle option to the kernel command line that
>>> resulted in pci scan simply trusting that the bootrom/u-boot had
>>> already
>>> correctly assigned the PCI irqs.... every tom,dick,harry, and
>>> yours-truly wouldn't have to make a new platform to define the
>>> swizzle-o-the-day. Or have I already missed this argument?
>>
>>
>> Sure, I do this now. Just don't build pci_auto into your pci support
>> and don't explicitly rescan in your pci setup. The 83xx pci code
>> under arch/powerpc should effective do this.
>>
>> - kumar
>
> Hmm; I must be missing something... cuz to me it looks like pci_32.c
> will allways call pcibios_init, which will will scan the bus, which
> will
> swizzle irqs if the platform has non-null swizzle and map_irq function
> pointers defined.. Perhaps a setting I've missed somewhere re.
> 'pci_auto', which I thought was a 'ppc' thing, not a 'powerpc'
> thing..??
Ahh, why do you have swizzle and map_irq functions? I guess I forgot
that part. In my setup I have u-boot do all IRQ assignment (via PCI
IRQ line register) as well as all BAR config. I just leave swizzle
and map_irq null.
- kumar
^ permalink raw reply
* Re: new sound driver
From: Johannes Berg @ 2006-03-23 17:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Alastair Poole
In-Reply-To: <1143064237.3823.29.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]
On Thu, 2006-03-23 at 08:50 +1100, Benjamin Herrenschmidt wrote:
> that would make soundbus totally pmac specific, in which case you should
> call it aoa-bus or something like that.
Yeah, well, I just did it differently now with the dbdma stuff done by
the i2sbus objects.
> Regarding your previous question well... I think the soundbus can create
> the pcm streams. Alsa has 2 levels: PCM objects and PCM substreams. We
> need the former. Substreams are used when the harware has several
> streams that are hw mixed to the same mixers which isn't the case with
> apple layout. When we have multiple i2s busses, they are really
> independant with separate codecs, frame rates & formats etc.. thus
> separate PCM objects.
>
> I think the sound bus should create the PCMs. Now I don't remember from
> Alsa API but do we need to know the available rates in advance ? In that
> case, we may want to have the bitmask provided by the fabric (from the
> layout array for example).
Right. I was still confused on the notion of PCM streams vs. objects.
Got that sorted out, and yes, it is creating pcm objects.
> I'm also not sure how Alsa handle changes there. For example, if you
> plug a digital input, the entire bus where this input is has to be
> clocked from that, thus limiting dynamically what rates/formats are
> available. I'm not sure Alsa API can cope with that yet.
Well, if we're unlucky the Alsa API must just return -EINVAL to users
trying to use other bitrates, if we're lucky then it copes better ;)
> > Actually, this isn't quite possible. On the newer machines where you
> > have two codecs on the same i2s bus, we need to have the layout fabric
> > create the one pcm stream and have it ask the codecs what it should
> > advertise. Then it needs to advertise the lowest common denominator of
> > the multiple codecs... (Or can alsa handle pcms that change their
> > supported rates/formats?) Then it refers to the soundbus functions for
> > actual data transmission.
>
> The problem is that codec objects have to be created asynchronously
> since they use asynchronous i2c discovery. Unless you instanciate them
> all but simply mark them "offline" and then mark them "online" later
> when the hardware actually shows up. That is fine except for .. topaz
> where you need to access the hw to know the chip type, thus you can't
> really know everything you need early enough (or maybe you can ...)
What I'm currently thinking of is creating one PCM per codec, and then
if you can't use them at the same time just forbid access to it.
> Just sleep on it for now :) We definitely need a "core" module that
> handles all of the gpio mess. ..
Yeah. Haven't even opened that can of worms yet...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-23 17:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wyse, Chris, +linux-embedded, linuxppc-embedded
In-Reply-To: <204E7000-3E88-4497-86C0-5AF786D72F75@kernel.crashing.org>
> Why don't use the mmap file exposed by sysfs so you dont have to
> write your own code?
>
> See Documentation/filesystems/sysfs-pci.txt. But effectively down
> under /sys/bus/pci/devices/[domain:bus:dev:func]/ you will get
> resource[0..N-1] that corresponds to each BAR on the device. This is
> a mmap file to access that region.
Hi Kumar,
Most likely he didn't know about it, I didn't :)
When I was testing the Yosemite board as the host, I found
that I could set the endian flag on the mmapped page, which
then made the PCI device registers read as 32-bit quantities
read back with the same layout under both x86 and PPC
hosts.
So, if someone planned on using that 'feature', that would
be a reason for writing your own mmap() implementation.
I didn't see any option in the sysfs file for setting that
page flag (but, I didn't look around in other sysfs files).
Thanks for the pointer to the sysfs node!
Cheers
Dave
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-23 17:04 UTC (permalink / raw)
To: Wyse, Chris; +Cc: +linux-embedded, linuxppc-embedded
In-Reply-To: <B1E46DE837A394458BB1A58F74A66A780596CB@ala-mail02.corp.ad.wrs.com>
> I'm trying to map a PCI memory region 1 into user space from my driver
> (PPC440GX, Linux 2.6.10). Here's the mmap routine of the driver that
> I'm using:
Hi Chris,
I wrote a generic PCI IO driver when testing the
Yosemite 440EP, take a look at the code, its fairly
well commented. You probably just need to add the
PCI vendor ID for your target board:
(or you can echo the deviceID:vendorID to the
sysfs node for the driver)
http://www.ovro.caltech.edu/~dwh/pci_io.tar.gz
There's some comments in here on it:
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
For example, on an x86 system, I was looking for
a PLX PCI9054 10b5:9054, and then on the yosemite
board I was looking for the same hardware.
In your case, its not clear from your email whether you
are on a 440GX looking for another device, or on a host
looking for a 440GX. Either way, the driver should work.
Cheers
Dave
^ permalink raw reply
* Re: new sound driver
From: Johannes Berg @ 2006-03-23 17:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alastair Poole
In-Reply-To: <1143020119.11724.41.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]
Obviously, I'm still collecting information. For future reference and
archiving, here's the contents of a file I just added to my code
describing how apple derives i2s clocks. Well, as far as I can see from
their code.
Short description of the i2s clock derivation system Apple uses.
The i2s chip Apple uses has three available clocks: 18432000, 45158400 and
49152000 Hz. These are used to drive the codec's system clock as well as the
i2s transfer bus.
The clocks for these are derived as follows:
First, you need to know the sampling frequency you want to use, and the
system clock the codec requires. The pcm3052 (onyx) for example requires a
system clock of 256*sampling frequency.
Thus, you divide the clock source speed by the sampling frequency and then
the factor the codec chip requires. This is the 'mclk divisor'.
Now you can derive the system clock from the clock source by taking only
every 'mclk divisor' transition of the clock, and thus you get a system
clock of the required speed.
Next, you need to know the i2s bus speed wrt. the sampling frequency. For
Sony and I2S 32x serial formats, this is 32*sampling frequency, for the I2S
64x format it is 64*sampling frequency. Since the i2s wire clock is derived
from the system clock we have already derived from the clock source, you
need to put as 'sclk divisor' the factor between the system clock of the
codec and the bus clock, for example 256/32 (=8) if the codec is driven in
Sony mode.
For the 'sclk divisor' you have to take care that it is an even number or 1
or 3, other values cannot be represented to the i2s chip (see logic in
i2sbus.h).
With a codec system clock (MClk) of 256*sampling frequency, you can have the
following frequencies (in the range from 8KHz to 96KHz) depending on the
clock source you use:
18432000: 9000 12000 14400 18000 24000 36000 72000
45158400: 8820 9800 11025 12600 14700 17640 22050 29400 35280 44100 58800 88200
49152000: 8000 9600 12000 16000 19200 24000 32000 38400 48000 64000 96000
(this is exactly what we can do with the onyx chip)
to create this table use calc (debian package apcalc):
min=8000
max=96000
clock=49152000
factor=256
for (f=min;f<=max;f++) {
if ((clock%f==0) && ((clock/f)%factor == 0)) {
div = clock/f/factor ;
n = ceil(div/2-1) ;
if ((div==1||div==3||div==5||div==14||(2*(n+1)==div && n<0x1f))
&& (1))
print f,
}
}
print ''
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: swizzling pci irqs
From: David Updegraff @ 2006-03-23 16:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <E895715F-A853-4A27-8076-90A1973273E2@kernel.crashing.org>
Kumar Gala wrote:
> On Mar 22, 2006, at 2:59 PM, David Updegraff wrote:
>
>
>>Hi.
>>
>>If there were a noswizzle option to the kernel command line that
>>resulted in pci scan simply trusting that the bootrom/u-boot had
>>already
>>correctly assigned the PCI irqs.... every tom,dick,harry, and
>>yours-truly wouldn't have to make a new platform to define the
>>swizzle-o-the-day. Or have I already missed this argument?
>
>
> Sure, I do this now. Just don't build pci_auto into your pci support
> and don't explicitly rescan in your pci setup. The 83xx pci code
> under arch/powerpc should effective do this.
>
> - kumar
Hmm; I must be missing something... cuz to me it looks like pci_32.c
will allways call pcibios_init, which will will scan the bus, which will
swizzle irqs if the platform has non-null swizzle and map_irq function
pointers defined.. Perhaps a setting I've missed somewhere re.
'pci_auto', which I thought was a 'ppc' thing, not a 'powerpc' thing..??
-dbu.
^ permalink raw reply
* Support for Motorola Platforms
From: CJ Anderson @ 2006-03-23 16:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 976 bytes --]
I found this email from a Google search for MVME761-001 boards.
I am looking for a supply of these boards.
Can you help? I need 32.
CJ
"Coming together is a beginning. Keeping
<http://www.aerotechcomp.com/> together is progress. Working together is
success. Quality in a service or product is not what you put into it, it is
what the customer gets out of it. If we don't take care of our customers,
someone else will."
CJ Anderson
Account Executive Aero Technical Components
8601 4th Street North
<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=8601+4th+Street+North&csz=St
.+Petersburg%2C+FL+33702&country=us>
St. Petersburg, FL 33702
canderson@aerotechcomp.com
IM: cj-1311@hotmail.com
www.aerotechcomp.com <http://www.aerotechcomp.com/>
tel:
fax: (727) 577-6115
(727) 563-9134
<https://www.plaxo.com/add_me?u=4295630737&v0=1321534&k0=640037876> Add me
to your address book... <http://www.plaxo.com/signature> Want a signature
like this?
[-- Attachment #1.2: Type: text/html, Size: 5775 bytes --]
[-- Attachment #2: ATC10t.jpg --]
[-- Type: image/jpeg, Size: 6907 bytes --]
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: Kumar Gala @ 2006-03-23 15:44 UTC (permalink / raw)
To: Wyse, Chris; +Cc: +linux-embedded, linuxppc-embedded
In-Reply-To: <B1E46DE837A394458BB1A58F74A66A780596CB@ala-mail02.corp.ad.wrs.com>
On Mar 23, 2006, at 8:21 AM, Wyse, Chris wrote:
> Hi,
>
> I'm trying to map a PCI memory region 1 into user space from my
> driver (PPC440GX, Linux 2.6.10). Here's the mmap routine of the
> driver that I'm using:
Why don't use the mmap file exposed by sysfs so you dont have to
write your own code?
See Documentation/filesystems/sysfs-pci.txt. But effectively down
under /sys/bus/pci/devices/[domain:bus:dev:func]/ you will get
resource[0..N-1] that corresponds to each BAR on the device. This is
a mmap file to access that region.
- kumar
>
>
> staticfun
> int phob_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> struct phob_file *fptr = filp->private_data;
> struct phob_struct *dev = fptr->dev;
> struct phob_region *rptr = &dev->region[1];
> phys_addr_t physAddr;
>
> physAddr = rptr->address + PPC44x_PCIMEM_PAGE;
> if (io_remap_page_range(vma, vma->vm_start,
> physAddr,
> rptr->len,
> vma->vm_page_prot))
> return -EAGAIN;
> }
> Am I using the correct routine to do this?
>
> When I use this routine, the pfn_pte (pgtable.h):
>
> #define pfn_pte(pfn, prot) __pte(((pfn) << PAGE_SHIFT) |
> pgprot_val(prot))
>
> macro shifted out the high order bits of the pfn, which I didn't
> think was correct, so I changed it to:
>
> #define pfn_pte(pfn, prot) __pte((((unsigned long long) (pfn))
> << PAGE_SHIFT) | pgprot_val(prot))
>
> For reference, the call stack up to the pfn_pte macro is:
>
> remap_pte_range()
> remap_pmd_range()
> remap_pfn_range()
> io_remap_page_range()
>
> After changing the macro, the value seems to be saved properly, and
> the TLB gets updated properly when I get a TLB miss. However, when
> if I try to write to the PCI from user space, I get an error from
> do_wp_page() stating that it is a bogus pfn. If I try to read from
> user space, the processor goes out to lunch and I need to reboot.
>
> Am I missing something obvious? Anyone have any ideas on how to do
> this and/or ways to debug it?
>
> Thanks.
>
> Chris Wyse
> Member of Technical Staff
> Embedded Technologies
> 860-749-1556 office
> 860-978-0849 cell
> 413-778-9101 fax
> http://www.windriver.com
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: pci-x
From: Kumar Gala @ 2006-03-23 15:41 UTC (permalink / raw)
To: Carlos Mitidieri; +Cc: linuxppc-embedded
In-Reply-To: <200603231435.01008.carlos.mitidieri@sysgo.com>
On Mar 23, 2006, at 7:35 AM, Carlos Mitidieri wrote:
> Is there PCI-X support for the mpc8540ads?
Yes. You have to make sure the board is setup (switches in the right
place) properly for it.
- k
^ permalink raw reply
* Memory mapping PCI memory region to user space
From: Wyse, Chris @ 2006-03-23 14:21 UTC (permalink / raw)
To: linuxppc-embedded, +linux-embedded
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
Hi,
I'm trying to map a PCI memory region 1 into user space from my driver
(PPC440GX, Linux 2.6.10). Here's the mmap routine of the driver that
I'm using:
staticfun
int phob_mmap(struct file *filp, struct vm_area_struct *vma)
{
struct phob_file *fptr = filp->private_data;
struct phob_struct *dev = fptr->dev;
struct phob_region *rptr = &dev->region[1];
phys_addr_t physAddr;
physAddr = rptr->address + PPC44x_PCIMEM_PAGE;
if (io_remap_page_range(vma, vma->vm_start,
physAddr,
rptr->len,
vma->vm_page_prot))
return -EAGAIN;
}
Am I using the correct routine to do this?
When I use this routine, the pfn_pte (pgtable.h):
#define pfn_pte(pfn, prot) __pte(((pfn) << PAGE_SHIFT) |
pgprot_val(prot))
macro shifted out the high order bits of the pfn, which I didn't think
was correct, so I changed it to:
#define pfn_pte(pfn, prot) __pte((((unsigned long long) (pfn)) <<
PAGE_SHIFT) | pgprot_val(prot))
For reference, the call stack up to the pfn_pte macro is:
remap_pte_range()
remap_pmd_range()
remap_pfn_range()
io_remap_page_range()
After changing the macro, the value seems to be saved properly, and the
TLB gets updated properly when I get a TLB miss. However, when if I try
to write to the PCI from user space, I get an error from do_wp_page()
stating that it is a bogus pfn. If I try to read from user space, the
processor goes out to lunch and I need to reboot.
Am I missing something obvious? Anyone have any ideas on how to do this
and/or ways to debug it?
Thanks.
Chris Wyse
Member of Technical Staff
Embedded Technologies
860-749-1556 office
860-978-0849 cell
413-778-9101 fax
http://www.windriver.com <http://www.windriver.com/>
[-- Attachment #2: Type: text/html, Size: 6392 bytes --]
^ permalink raw reply
* pci-x
From: Carlos Mitidieri @ 2006-03-23 13:35 UTC (permalink / raw)
To: linuxppc-embedded
Is there PCI-X support for the mpc8540ads?
Thank you.
--
Carlos Mitidieri
SYSGO AG
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Rename and export ppc64_firmware_features
From: Stephen Rothwell @ 2006-03-23 13:17 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060323123348.4815367C10@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
On Thu, 23 Mar 2006 23:33:11 +1100 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> +EXPORT_SYMBOL_GPL(powerpc_firmware_features);
This should be in firmware.c not a header file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH 4/4] powerpc: Cope with duplicate node & property names in /proc/device-tree
From: Michael Ellerman @ 2006-03-23 12:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <1143117144.850591.48752080269.qpush@concordia>
Various dodgy firmware might give us nodes and/or properties in the device
tree with conflicting names. That's generally ok, except for when we export
the device tree via /proc, so check when we're creating the proc device tree
and munge names accordingly.
Tested on a faked device tree with kexec, would be good if someone with
actual bogus firmware could try it, but just for completeness.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
fs/proc/proc_devtree.c | 93 +++++++++++++++++++++++++++++++++++++------------
1 files changed, 72 insertions(+), 21 deletions(-)
Index: to-merge/fs/proc/proc_devtree.c
===================================================================
--- to-merge.orig/fs/proc/proc_devtree.c
+++ to-merge/fs/proc/proc_devtree.c
@@ -52,7 +52,8 @@ static int property_read_proc(char *page
* Add a property to a node
*/
static struct proc_dir_entry *
-__proc_device_tree_add_prop(struct proc_dir_entry *de, struct property *pp)
+__proc_device_tree_add_prop(struct proc_dir_entry *de, struct property *pp,
+ char *name)
{
struct proc_dir_entry *ent;
@@ -60,14 +61,14 @@ __proc_device_tree_add_prop(struct proc_
* Unfortunately proc_register puts each new entry
* at the beginning of the list. So we rearrange them.
*/
- ent = create_proc_read_entry(pp->name,
- strncmp(pp->name, "security-", 9)
+ ent = create_proc_read_entry(name,
+ strncmp(name, "security-", 9)
? S_IRUGO : S_IRUSR, de,
property_read_proc, pp);
if (ent == NULL)
return NULL;
- if (!strncmp(pp->name, "security-", 9))
+ if (!strncmp(name, "security-", 9))
ent->size = 0; /* don't leak number of password chars */
else
ent->size = pp->length;
@@ -78,7 +79,7 @@ __proc_device_tree_add_prop(struct proc_
void proc_device_tree_add_prop(struct proc_dir_entry *pde, struct property *prop)
{
- __proc_device_tree_add_prop(pde, prop);
+ __proc_device_tree_add_prop(pde, prop, prop->name);
}
void proc_device_tree_remove_prop(struct proc_dir_entry *pde,
@@ -106,6 +107,61 @@ void proc_device_tree_update_prop(struct
}
/*
+ * Various dodgy firmware might give us nodes and/or properties with
+ * conflicting names. That's generally ok, except for exporting via /proc,
+ * so munge names here to ensure they're unique.
+ */
+
+static int duplicate_name(struct proc_dir_entry *de, char *name)
+{
+ struct proc_dir_entry *ent;
+
+ for (ent = de->subdir; ent != NULL; ent = ent->next)
+ if (strcmp(ent->name, name) == 0)
+ return 1;
+
+ return 0;
+}
+
+static char *fixup_name(struct device_node *np, struct proc_dir_entry *de,
+ char *name)
+{
+ char *fixed_name;
+ int fixup_len = strlen(name) + 2 + 1; /* name + #x + \0 */
+ int i = 1, size;
+
+realloc:
+ fixed_name = kmalloc(fixup_len, GFP_KERNEL);
+ if (fixed_name == NULL) {
+ printk(KERN_ERR "device-tree: Out of memory trying to fixup "
+ "name \"%s\"\n", name);
+ return name;
+ }
+
+retry:
+ size = snprintf(fixed_name, fixup_len, "%s#%d", name, i);
+ size++; /* account for NULL */
+
+ if (size > fixup_len) {
+ /* We ran out of space, free and reallocate. */
+ kfree(fixed_name);
+ fixup_len = size;
+ goto realloc;
+ }
+
+ if (duplicate_name(de, fixed_name)) {
+ /* Multiple duplicates. Retry with a different offset. */
+ i++;
+ goto retry;
+ }
+
+ printk(KERN_WARNING "device-tree: Duplicate name in %s, "
+ "renamed to \"%s\"\n", np->full_name, fixed_name);
+
+ return fixed_name;
+}
+
+/*
* Process a node, adding entries for its children and its properties.
*/
void proc_device_tree_add_node(struct device_node *np,
@@ -118,35 +174,30 @@ void proc_device_tree_add_node(struct de
set_node_proc_entry(np, de);
for (child = NULL; (child = of_get_next_child(np, child));) {
+ /* Use everything after the last slash, or the full name */
p = strrchr(child->full_name, '/');
if (!p)
p = child->full_name;
else
++p;
+
+ if (duplicate_name(de, p))
+ p = fixup_name(np, de, p);
+
ent = proc_mkdir(p, de);
if (ent == 0)
break;
proc_device_tree_add_node(child, ent);
}
of_node_put(child);
+
for (pp = np->properties; pp != 0; pp = pp->next) {
- /*
- * Yet another Apple device-tree bogosity: on some machines,
- * they have properties & nodes with the same name. Those
- * properties are quite unimportant for us though, thus we
- * simply "skip" them here, but we do have to check.
- */
- for (ent = de->subdir; ent != NULL; ent = ent->next)
- if (!strcmp(ent->name, pp->name))
- break;
- if (ent != NULL) {
- printk(KERN_WARNING "device-tree: property \"%s\" name"
- " conflicts with node in %s\n", pp->name,
- np->full_name);
- continue;
- }
+ p = pp->name;
+
+ if (duplicate_name(de, p))
+ p = fixup_name(np, de, p);
- ent = __proc_device_tree_add_prop(de, pp);
+ ent = __proc_device_tree_add_prop(de, pp, p);
if (ent == 0)
break;
}
^ permalink raw reply
* [PATCH 3/4] powerpc: Rename and export ppc64_firmware_features
From: Michael Ellerman @ 2006-03-23 12:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <1143117144.850591.48752080269.qpush@concordia>
We need to export ppc64_firmware_features for modules. Before we do that
I think we should probably rename it to powerpc_firmware_features.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/firmware.c | 2 +-
arch/powerpc/platforms/iseries/setup.c | 4 ++--
arch/powerpc/platforms/pseries/firmware.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
include/asm-powerpc/firmware.h | 5 +++--
5 files changed, 8 insertions(+), 7 deletions(-)
Index: to-merge/arch/powerpc/kernel/firmware.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/firmware.c
+++ to-merge/arch/powerpc/kernel/firmware.c
@@ -17,4 +17,4 @@
#include <asm/firmware.h>
-unsigned long ppc64_firmware_features;
+unsigned long powerpc_firmware_features;
Index: to-merge/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/setup.c
+++ to-merge/arch/powerpc/platforms/iseries/setup.c
@@ -680,8 +680,8 @@ static int __init iseries_probe(int plat
if (PLATFORM_ISERIES_LPAR != platform)
return 0;
- ppc64_firmware_features |= FW_FEATURE_ISERIES;
- ppc64_firmware_features |= FW_FEATURE_LPAR;
+ powerpc_firmware_features |= FW_FEATURE_ISERIES;
+ powerpc_firmware_features |= FW_FEATURE_LPAR;
return 1;
}
Index: to-merge/arch/powerpc/platforms/pseries/firmware.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/pseries/firmware.c
+++ to-merge/arch/powerpc/platforms/pseries/firmware.c
@@ -91,7 +91,7 @@ void __init fw_feature_init(void)
continue;
/* we have a match */
- ppc64_firmware_features |=
+ powerpc_firmware_features |=
firmware_features_table[i].val;
break;
}
Index: to-merge/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/pseries/setup.c
+++ to-merge/arch/powerpc/platforms/pseries/setup.c
@@ -386,7 +386,7 @@ static int __init pSeries_probe(int plat
*/
if (platform == PLATFORM_PSERIES_LPAR)
- ppc64_firmware_features |= FW_FEATURE_LPAR;
+ powerpc_firmware_features |= FW_FEATURE_LPAR;
return 1;
}
Index: to-merge/include/asm-powerpc/firmware.h
===================================================================
--- to-merge.orig/include/asm-powerpc/firmware.h
+++ to-merge/include/asm-powerpc/firmware.h
@@ -82,11 +82,12 @@ enum {
/* This is used to identify firmware features which are available
* to the kernel.
*/
-extern unsigned long ppc64_firmware_features;
+extern unsigned long powerpc_firmware_features;
+EXPORT_SYMBOL_GPL(powerpc_firmware_features);
#define firmware_has_feature(feature) \
((FW_FEATURE_ALWAYS & (feature)) || \
- (FW_FEATURE_POSSIBLE & ppc64_firmware_features & (feature)))
+ (FW_FEATURE_POSSIBLE & powerpc_firmware_features & (feature)))
extern void system_reset_fwnmi(void);
extern void machine_check_fwnmi(void);
^ permalink raw reply
* [PATCH 2/4] powerpc: Change firmware_has_feature() to a macro
From: Michael Ellerman @ 2006-03-23 12:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <1143117144.850591.48752080269.qpush@concordia>
So that we can use firmware_has_feature() in a BUG_ON() and have the compiler
elide the code entirely if the feature can never be set, change
firmware_has_feature to a macro. Unfortunate, but necessary at least until
GCC bug #26724 is fixed.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
include/asm-powerpc/firmware.h | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
Index: to-merge/include/asm-powerpc/firmware.h
===================================================================
--- to-merge.orig/include/asm-powerpc/firmware.h
+++ to-merge/include/asm-powerpc/firmware.h
@@ -84,11 +84,9 @@ enum {
*/
extern unsigned long ppc64_firmware_features;
-static inline unsigned long firmware_has_feature(unsigned long feature)
-{
- return (FW_FEATURE_ALWAYS & feature) ||
- (FW_FEATURE_POSSIBLE & ppc64_firmware_features & feature);
-}
+#define firmware_has_feature(feature) \
+ ((FW_FEATURE_ALWAYS & (feature)) || \
+ (FW_FEATURE_POSSIBLE & ppc64_firmware_features & (feature)))
extern void system_reset_fwnmi(void);
extern void machine_check_fwnmi(void);
^ permalink raw reply
* [PATCH 1/4] powerpc: Make BUG_ON & WARN_ON play nice with compile-time optimisations
From: Michael Ellerman @ 2006-03-23 12:32 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
Change BUG_ON and WARN_ON to give the compiler a chance to perform
compile-time optimsations. Depending on the complexity of the condition,
the compiler may not do this very well, so if it's important check the
object code.
Current GCC's (4.x) produce good code as long as the condition does not
include a function call, including a static inline.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
include/asm-powerpc/bug.h | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
Index: to-merge/include/asm-powerpc/bug.h
===================================================================
--- to-merge.orig/include/asm-powerpc/bug.h
+++ to-merge/include/asm-powerpc/bug.h
@@ -30,6 +30,12 @@ struct bug_entry *find_bug(unsigned long
#ifdef CONFIG_BUG
+/*
+ * BUG_ON() and WARN_ON() do their best to cooperate with compile-time
+ * optimisations. However depending on the complexity of the condition
+ * some compiler versions may not produce optimal results.
+ */
+
#define BUG() do { \
__asm__ __volatile__( \
"1: twi 31,0,0\n" \
@@ -40,17 +46,36 @@ struct bug_entry *find_bug(unsigned long
} while (0)
#define BUG_ON(x) do { \
- __asm__ __volatile__( \
+ if (__builtin_constant_p(x)) { \
+ if (x) \
+ BUG(); \
+ } else { \
+ __asm__ __volatile__( \
"1: "PPC_TLNEI" %0,0\n" \
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%1,%2,%3\n" \
".previous" \
: : "r" ((long)(x)), "i" (__LINE__), \
"i" (__FILE__), "i" (__FUNCTION__)); \
+ } \
} while (0)
-#define WARN_ON(x) do { \
+#define WARN() do { \
__asm__ __volatile__( \
+ "1: twi 31,0,0\n" \
+ ".section __bug_table,\"a\"\n" \
+ "\t"PPC_LONG" 1b,%0,%1,%2\n" \
+ ".previous" \
+ : : "i" (__LINE__ + BUG_WARNING_TRAP), \
+ "i" (__FILE__), "i" (__FUNCTION__)); \
+} while (0)
+
+#define WARN_ON(x) do { \
+ if (__builtin_constant_p(x)) { \
+ if (x) \
+ WARN(); \
+ } else { \
+ __asm__ __volatile__( \
"1: "PPC_TLNEI" %0,0\n" \
".section __bug_table,\"a\"\n" \
"\t"PPC_LONG" 1b,%1,%2,%3\n" \
@@ -58,6 +83,7 @@ struct bug_entry *find_bug(unsigned long
: : "r" ((long)(x)), \
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__)); \
+ } \
} while (0)
#define HAVE_ARCH_BUG
^ permalink raw reply
* ibmveth initialisation failure
From: Anton Blanchard @ 2006-03-23 11:36 UTC (permalink / raw)
To: santil; +Cc: michael, linuxppc-dev
Hi,
While testing kdump I hit the register_logical_lan issue already under
discussion. Unfortunately we end up oopsing shortly after this.
It turns out we call ibmveth_change_mtu early in ->open, before we have
set everything up. ibmveth_change_mtu calls ibmveth_interrupt and
shortly after we call ibmveth_poll regardless of whether the device came
up properly:
(/drivers/net/ibmveth.c:515 ua:30000002) ERROR: h_register_logical_lan failed with -4
(drivers/net/ibmveth.c:520 ua:30000002) ERROR: buffer TCE:0x0 filter TCE:0x1000 rxq desc:0x8000701000002000 MAC:0xdad230003002
Unable to handle kernel paging request for data at address 0x00000000
cpu 0x2: Vector: 300 (Data Access) at [c00000000778bab0]
pc: c0000000022c44fc: .ibmveth_poll+0x94/0x77c
lr: c0000000023997f4: .net_rx_action+0xe4/0x220
dar: 0
[c00000000778be40] c0000000023997f4 .net_rx_action+0xe4/0x220
[c00000000778bef0] c0000000020538e8 .__do_softirq+0x98/0x164
[c00000000778bf90] c0000000020224d0 .call_do_softirq+0x14/0x24
[c0000000066e3790] c00000000200b73c .do_softirq+0x94/0xe0
[c0000000066e3820] c000000002053400 .local_bh_enable+0x58/0x8c
[c0000000066e38a0] c00000000242bb64 ._spin_unlock_bh+0x1c/0x30
[c0000000066e3920] c00000000238e3f4 .lock_sock+0xd4/0xf8
[c0000000066e39e0] c00000000238b87c .sock_fasync+0x9c/0x1b0
[c0000000066e3aa0] c00000000238c998 .sock_close+0x3c/0x60
[c0000000066e3b20] c0000000020b1904 .__fput+0xf8/0x238
[c0000000066e3bc0] c0000000020af054 .filp_close+0xac/0xd4
[c0000000066e3c50] c00000000204e7dc .put_files_struct+0xbc/0x148
[c0000000066e3cf0] c0000000020500e8 .do_exit+0x224/0x970
[c0000000066e3da0] c000000002050910 .sys_exit_group+0x0/0x8
[c0000000066e3e30] c00000000200871c syscall_exit+0x0/0x40
Shift ibmveth_change_mtu until after we have set everything up and
cannot fail.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/drivers/net/ibmveth.c
===================================================================
--- build.orig/drivers/net/ibmveth.c 2006-02-13 13:24:22.000000000 +1100
+++ build/drivers/net/ibmveth.c 2006-03-23 21:56:22.000000000 +1100
@@ -489,9 +489,6 @@ static int ibmveth_open(struct net_devic
adapter->rx_queue.num_slots = rxq_entries;
adapter->rx_queue.toggle = 1;
- /* call change_mtu to init the buffer pools based in initial mtu */
- ibmveth_change_mtu(netdev, netdev->mtu);
-
memcpy(&mac_address, netdev->dev_addr, netdev->addr_len);
mac_address = mac_address >> 16;
@@ -533,6 +530,9 @@ static int ibmveth_open(struct net_devic
return rc;
}
+ /* call change_mtu to init the buffer pools based in initial mtu */
+ ibmveth_change_mtu(netdev, netdev->mtu);
+
ibmveth_debug_printk("initial replenish cycle\n");
ibmveth_interrupt(netdev->irq, netdev, NULL);
^ permalink raw reply
* [PATCH] powerpc: fix various sparse warnings
From: Stephen Rothwell @ 2006-03-23 6:38 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/legacy_serial.c | 4 ++--
arch/powerpc/kernel/nvram_64.c | 3 ++-
arch/powerpc/kernel/process.c | 6 +++++-
arch/powerpc/kernel/setup_32.c | 2 +-
arch/powerpc/lib/sstep.c | 2 +-
arch/powerpc/platforms/powermac/bootx_init.c | 2 +-
arch/powerpc/platforms/powermac/nvram.c | 12 ++++++------
arch/powerpc/platforms/powermac/udbg_scc.c | 2 +-
8 files changed, 19 insertions(+), 14 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
7debffaf860554fd5ff8029d306140094e8b5022
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index c7a799a..09d9c82 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -37,7 +37,7 @@ static int legacy_serial_console = -1;
static int __init add_legacy_port(struct device_node *np, int want_index,
int iotype, phys_addr_t base,
phys_addr_t taddr, unsigned long irq,
- unsigned int flags)
+ upf_t flags)
{
u32 *clk, *spd, clock = BASE_BAUD * 16;
int index;
@@ -113,7 +113,7 @@ static int __init add_legacy_soc_port(st
{
phys_addr_t addr;
u32 *addrp;
- unsigned int flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
+ upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
/* We only support ports that have a clock frequency properly
* encoded in the device-tree.
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index fd7db8d..6c3989f 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -174,8 +174,9 @@ static int dev_nvram_ioctl(struct inode
return 0;
}
#endif /* CONFIG_PPC_PMAC */
+ default:
+ return -EINVAL;
}
- return -EINVAL;
}
struct file_operations nvram_fops = {
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1770a06..10a8363 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -363,7 +363,11 @@ static void show_instructions(struct pt_
if (!(i % 8))
printk("\n");
- if (BAD_PC(pc) || __get_user(instr, (unsigned int *)pc)) {
+ /* We use __get_user here *only* to avoid an OOPS on a
+ * bad address because the pc *should* only be a
+ * kernel address.
+ */
+ if (BAD_PC(pc) || __get_user(instr, (unsigned int __user *)pc)) {
printk("XXXXXXXX ");
} else {
if (regs->nip == pc)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index db72a92..1861b73 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -111,7 +111,7 @@ unsigned long __init early_init(unsigned
/* First zero the BSS -- use memset_io, some platforms don't have
* caches on yet */
- memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
+ memset_io((void __iomem *)PTRRELOC(&__bss_start), 0, _end - __bss_start);
/*
* Identify the CPU type and fix up code sections
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 666c2aa..c251d99 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -18,7 +18,7 @@ extern char system_call_common[];
#ifdef CONFIG_PPC64
/* Bits in SRR1 that are copied from MSR */
-#define MSR_MASK 0xffffffff87c0ffff
+#define MSR_MASK 0xffffffff87c0ffffUL
#else
#define MSR_MASK 0x87c0ffff
#endif
diff --git a/arch/powerpc/platforms/powermac/bootx_init.c b/arch/powerpc/platforms/powermac/bootx_init.c
index fa8b4d7..a94571b 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -493,7 +493,7 @@ void __init bootx_init(unsigned long r3,
&& (strcmp(model, "iMac,1") == 0
|| strcmp(model, "PowerMac1,1") == 0)) {
bootx_printf("iMac,1 detected, shutting down USB \n");
- out_le32((unsigned *)0x80880008, 1); /* XXX */
+ out_le32((unsigned __iomem *)0x80880008, 1); /* XXX */
}
}
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index 5fd2899..3aa3477 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -74,7 +74,7 @@ struct core99_header {
* Read and write the non-volatile RAM on PowerMacs and CHRP machines.
*/
static int nvram_naddrs;
-static volatile unsigned char *nvram_data;
+static volatile unsigned char __iomem *nvram_data;
static int is_core_99;
static int core99_bank = 0;
static int nvram_partitions[3];
@@ -148,7 +148,7 @@ static ssize_t core99_nvram_size(void)
}
#ifdef CONFIG_PPC32
-static volatile unsigned char *nvram_addr;
+static volatile unsigned char __iomem *nvram_addr;
static int nvram_mult;
static unsigned char direct_nvram_read_byte(int addr)
@@ -285,7 +285,7 @@ static int sm_erase_bank(int bank)
int stat, i;
unsigned long timeout;
- u8* base = (u8 *)nvram_data + core99_bank*NVRAM_SIZE;
+ u8 __iomem *base = (u8 __iomem *)nvram_data + core99_bank*NVRAM_SIZE;
DBG("nvram: Sharp/Micron Erasing bank %d...\n", bank);
@@ -317,7 +317,7 @@ static int sm_write_bank(int bank, u8* d
int i, stat = 0;
unsigned long timeout;
- u8* base = (u8 *)nvram_data + core99_bank*NVRAM_SIZE;
+ u8 __iomem *base = (u8 __iomem *)nvram_data + core99_bank*NVRAM_SIZE;
DBG("nvram: Sharp/Micron Writing bank %d...\n", bank);
@@ -352,7 +352,7 @@ static int amd_erase_bank(int bank)
int i, stat = 0;
unsigned long timeout;
- u8* base = (u8 *)nvram_data + core99_bank*NVRAM_SIZE;
+ u8 __iomem *base = (u8 __iomem *)nvram_data + core99_bank*NVRAM_SIZE;
DBG("nvram: AMD Erasing bank %d...\n", bank);
@@ -399,7 +399,7 @@ static int amd_write_bank(int bank, u8*
int i, stat = 0;
unsigned long timeout;
- u8* base = (u8 *)nvram_data + core99_bank*NVRAM_SIZE;
+ u8 __iomem *base = (u8 __iomem *)nvram_data + core99_bank*NVRAM_SIZE;
DBG("nvram: AMD Writing bank %d...\n", bank);
diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c b/arch/powerpc/platforms/powermac/udbg_scc.c
index c4352a8..b4fa9f0 100644
--- a/arch/powerpc/platforms/powermac/udbg_scc.c
+++ b/arch/powerpc/platforms/powermac/udbg_scc.c
@@ -116,7 +116,7 @@ void udbg_scc_init(int force_scc)
/* Setup for 57600 8N1 */
if (ch == ch_a)
addr += 0x20;
- sccc = (volatile u8 * __iomem) ioremap(addr & PAGE_MASK, PAGE_SIZE) ;
+ sccc = ioremap(addr & PAGE_MASK, PAGE_SIZE) ;
sccc += addr & ~PAGE_MASK;
sccd = sccc + 0x10;
--
1.2.4
^ permalink raw reply related
* [PATCH] powerpc: work around sparse warnings in cputable.h
From: Stephen Rothwell @ 2006-03-23 6:36 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Christoph noticed that sparse warned about all the enum tags in cuptable.h
that had values that required them to be type log. (enum tags are ints
according to the standard.)
This patch attempts to fix them in the least intrusive way possible by
turning them all into #defines except for the 32 bit CPU_FTRS_POSSIBLE and
CPU_FTRS_ALWAYS which are hard to construct that way. This works because
these last two contain no bits above 2^31.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/cputable.h | 299 ++++++++++++++++++++--------------------
1 files changed, 152 insertions(+), 147 deletions(-)
This has been built for ppc64 and a previous version was built for ppc32.
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
533676ca33803d3ebe85eea9009cc2fd7e79c1d7
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index fe45f6f..4321483 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -188,153 +188,154 @@ extern void do_cpu_ftr_fixups(unsigned l
!defined(CONFIG_POWER3) && !defined(CONFIG_POWER4) && \
!defined(CONFIG_BOOKE))
-enum {
- CPU_FTRS_PPC601 = CPU_FTR_COMMON | CPU_FTR_601 | CPU_FTR_HPTE_TABLE,
- CPU_FTRS_603 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP,
- CPU_FTRS_604 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_604_PERF_MON | CPU_FTR_HPTE_TABLE,
- CPU_FTRS_740_NOTAU = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP,
- CPU_FTRS_740 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP,
- CPU_FTRS_750 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP,
- CPU_FTRS_750FX1 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP |
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_NO_DPM,
- CPU_FTRS_750FX2 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP |
- CPU_FTR_NO_DPM,
- CPU_FTRS_750FX = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP |
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS,
- CPU_FTRS_750GX = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
- CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU |
- CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP |
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS,
- CPU_FTRS_7400_NOTAU = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE |
- CPU_FTR_MAYBE_CAN_NAP,
- CPU_FTRS_7400 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR |
- CPU_FTR_TAU | CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE |
- CPU_FTR_MAYBE_CAN_NAP,
- CPU_FTRS_7450_20 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NEED_COHERENT,
- CPU_FTRS_7450_21 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP |
- CPU_FTR_NEED_COHERENT,
- CPU_FTRS_7450_23 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT,
- CPU_FTRS_7455_1 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR |
- CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_HAS_HIGH_BATS |
- CPU_FTR_NEED_COHERENT,
- CPU_FTRS_7455_20 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP |
- CPU_FTR_NEED_COHERENT | CPU_FTR_HAS_HIGH_BATS,
- CPU_FTRS_7455 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS |
- CPU_FTR_NEED_COHERENT,
- CPU_FTRS_7447_10 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS |
- CPU_FTR_NEED_COHERENT | CPU_FTR_NO_BTIC,
- CPU_FTRS_7447 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS |
- CPU_FTR_NEED_COHERENT,
- CPU_FTRS_7447A = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 |
- CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS |
- CPU_FTR_NEED_COHERENT,
- CPU_FTRS_82XX = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB,
- CPU_FTRS_G2_LE = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
- CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
- CPU_FTRS_E300 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
- CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS |
- CPU_FTR_COMMON,
- CPU_FTRS_CLASSIC32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
- CPU_FTRS_POWER3_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
- CPU_FTRS_POWER4_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_NODSISRALIGN,
- CPU_FTRS_970_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN,
- CPU_FTRS_8XX = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB,
- CPU_FTRS_40X = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_NODSISRALIGN,
- CPU_FTRS_44X = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_NODSISRALIGN,
- CPU_FTRS_E200 = CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN,
- CPU_FTRS_E500 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_NODSISRALIGN,
- CPU_FTRS_E500_2 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_BIG_PHYS | CPU_FTR_NODSISRALIGN,
- CPU_FTRS_GENERIC_32 = CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN,
+#define CPU_FTRS_PPC601 (CPU_FTR_COMMON | CPU_FTR_601 | CPU_FTR_HPTE_TABLE)
+#define CPU_FTRS_603 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP)
+#define CPU_FTRS_604 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | CPU_FTR_604_PERF_MON | CPU_FTR_HPTE_TABLE)
+#define CPU_FTRS_740_NOTAU (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP)
+#define CPU_FTRS_740 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP)
+#define CPU_FTRS_750 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP)
+#define CPU_FTRS_750FX1 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
+ CPU_FTR_DUAL_PLL_750FX | CPU_FTR_NO_DPM)
+#define CPU_FTRS_750FX2 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
+ CPU_FTR_NO_DPM)
+#define CPU_FTRS_750FX (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
+ CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_750GX (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE | \
+ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_TAU | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
+ CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_7400_NOTAU (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE | \
+ CPU_FTR_MAYBE_CAN_NAP)
+#define CPU_FTRS_7400 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+ CPU_FTR_TAU | CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE | \
+ CPU_FTR_MAYBE_CAN_NAP)
+#define CPU_FTRS_7450_20 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_7450_21 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
+ CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_7450_23 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_7455_1 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | CPU_FTR_HAS_HIGH_BATS | \
+ CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_7455_20 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
+ CPU_FTR_NEED_COHERENT | CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_7455 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
+ CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_7447_10 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
+ CPU_FTR_NEED_COHERENT | CPU_FTR_NO_BTIC)
+#define CPU_FTRS_7447 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_L3CR | CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
+ CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_7447A (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_SPEC7450 | \
+ CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_HAS_HIGH_BATS | \
+ CPU_FTR_NEED_COHERENT)
+#define CPU_FTRS_82XX (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB)
+#define CPU_FTRS_G2_LE (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE | \
+ CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_E300 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE | \
+ CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS | \
+ CPU_FTR_COMMON)
+#define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE)
+#define CPU_FTRS_POWER3_32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE)
+#define CPU_FTRS_POWER4_32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_970_32 (CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE | \
+ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_ALTIVEC_COMP | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_8XX (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB)
+#define CPU_FTRS_40X (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_44X (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_E500 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_E500_2 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_BIG_PHYS | CPU_FTR_NODSISRALIGN)
+#define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
#ifdef __powerpc64__
- CPU_FTRS_POWER3 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_IABR,
- CPU_FTRS_RS64 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_IABR |
- CPU_FTR_MMCRA | CPU_FTR_CTRL,
- CPU_FTRS_POWER4 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_MMCRA,
- CPU_FTRS_PPC970 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 |
- CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA,
- CPU_FTRS_POWER5 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 |
- CPU_FTR_MMCRA | CPU_FTR_SMT |
- CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE |
- CPU_FTR_MMCRA_SIHV | CPU_FTR_PURR,
- CPU_FTRS_CELL = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 |
- CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT |
- CPU_FTR_CTRL | CPU_FTR_PAUSE_ZERO,
- CPU_FTRS_COMPATIBLE = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2,
+#define CPU_FTRS_POWER3 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_IABR)
+#define CPU_FTRS_RS64 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_IABR | \
+ CPU_FTR_MMCRA | CPU_FTR_CTRL)
+#define CPU_FTRS_POWER4 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_MMCRA)
+#define CPU_FTRS_PPC970 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA)
+#define CPU_FTRS_POWER5 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_MMCRA | CPU_FTR_SMT | \
+ CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
+ CPU_FTR_MMCRA_SIHV | CPU_FTR_PURR)
+#define CPU_FTRS_CELL (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
+ CPU_FTR_CTRL | CPU_FTR_PAUSE_ZERO)
+#define CPU_FTRS_COMPATIBLE (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2)
#endif
- CPU_FTRS_POSSIBLE =
#ifdef __powerpc64__
- CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |
- CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_CELL |
- CPU_FTR_CI_LARGE_PAGE |
+#define CPU_FTRS_POSSIBLE \
+ (CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 | \
+ CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_CELL | \
+ CPU_FTR_CI_LARGE_PAGE)
#else
+enum {
+ CPU_FTRS_POSSIBLE =
#if CLASSIC_PPC
CPU_FTRS_PPC601 | CPU_FTRS_603 | CPU_FTRS_604 | CPU_FTRS_740_NOTAU |
CPU_FTRS_740 | CPU_FTRS_750 | CPU_FTRS_750FX1 |
@@ -368,14 +369,18 @@ enum {
#ifdef CONFIG_E500
CPU_FTRS_E500 | CPU_FTRS_E500_2 |
#endif
-#endif /* __powerpc64__ */
0,
+};
+#endif /* __powerpc64__ */
- CPU_FTRS_ALWAYS =
#ifdef __powerpc64__
- CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 &
- CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_CELL &
+#define CPU_FTRS_ALWAYS \
+ (CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 & \
+ CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_CELL & \
+ CPU_FTRS_POSSIBLE)
#else
+enum {
+ CPU_FTRS_ALWAYS =
#if CLASSIC_PPC
CPU_FTRS_PPC601 & CPU_FTRS_603 & CPU_FTRS_604 & CPU_FTRS_740_NOTAU &
CPU_FTRS_740 & CPU_FTRS_750 & CPU_FTRS_750FX1 &
@@ -409,9 +414,9 @@ enum {
#ifdef CONFIG_E500
CPU_FTRS_E500 & CPU_FTRS_E500_2 &
#endif
-#endif /* __powerpc64__ */
CPU_FTRS_POSSIBLE,
};
+#endif /* __powerpc64__ */
static inline int cpu_has_feature(unsigned long feature)
{
--
1.2.4
^ permalink raw reply related
* Re: [PATCH] kdump: Fix for machine checkstop on DMA fault
From: Olof Johansson @ 2006-03-23 6:19 UTC (permalink / raw)
To: Michael Ellerman
Cc: Milton Miller, linuxppc-dev, Paul Mackerras, Olaf Hering,
ellerman
In-Reply-To: <200603231706.35508.michael@ellerman.id.au>
On Thu, Mar 23, 2006 at 05:06:27PM +1100, Michael Ellerman wrote:
> On Thu, 23 Mar 2006 16:38, Olof Johansson wrote:
> > On Wed, Mar 22, 2006 at 08:30:26PM -0800, Haren Myneni wrote:
> > > Paul, If you are OK with this fix, please send it upstream.
> > >
> > > Thanks
> > > Haren
> > >
> > > - Some machines checkstop on dma protection fault for ongoing DMA left
> > > in the first kernel. Since, we do not shutdown devices before the kdump
> > > boot, let them continue DMA to old kernel space.
> >
> > How is this solved for regular kexec, doesn't the same problem exist
> > there?
>
> The idea for normal kexec is that the kernel should have shut everything down
> properly. It's a bug if there are still DMAs going on. Hopefully.
Thanks Michael.
In that case, I have to NACK the original patch.
Out of luck, it'll probably work in most cases, but there's always
the risk of a DMA still going on, the crash kernel remapping an entry,
and getting memory scribbled over.
The crash kernel needs to be even more careful, and instead read out
the entries that are mapped and reserve them. This would require a bit
more plumbing since there's no way to read an entry right now, but it'd
remove that hole.
-Olof
^ 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