* increase lowmem value for ppc
From: Ruksen INANIR @ 2008-07-17 10:32 UTC (permalink / raw)
To: linuxppc-embedded
Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM is
defined as max 768 MB. But a value around 1.5 G works with no problem.
But when i try to increase this value to 1520 or more, kernel complaints
about no space for memory allocation when loading kernel modules.
I do not want to use HIGHMEM config. What is the max lowmem value for a
ppc system? What other setting are needed to use 1520 MB (or more) as
lowmem .
The ppc card has 2G on board memory. 2.4.22 kernel is used.
Thanks
^ permalink raw reply
* Is there relationship between address translation enabled and PLB timeout error?
From: Evangelion @ 2008-07-17 10:20 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <487E57F6.7020602@grandegger.com>
Hello, all:
I am building a Linux kernel module for PPC405EP. My developing
board is PPChameleonEVB. I am debugging with BDI2000 and GDB, and my
problem is:
In GDB, a section of the codes is disassembled to:
mfmsr r0
ori r0,r0,32768
mtmsr r0
blr
From BDI2000, I have checked that after "ori", GPR0 contains
"0x00029030". This value should be written into MSR by "mtmsr" to set EE
bit of MSR as 1, but after single step in BDI, "mtmsr" does not work as
hoped. MSR becomes "0x00000030", GPR0 becomes some weird number, and
there is "Step timeout detected". Meanwhile, the board traps into "Data
machine check in kernel mode". I also have tried "wrteei 1" instead of
the codes above, but failed again. However, those codes works well in
PPC440EP Yosemite board.
I have compared PPChameleonEVB and Yosemite. It seems the most
significant difference is for PPChameleonEVB, address translation is
enabled by default (MSR[IR, DR] = 1), while for Yosemite, it is disabled
(MSR[IR, DR] = 0). And from the error message, I think there is a
problem with PLB because PLB0_BESR becomes 0x00c00000 from 0x00000000
and PLB0_BEAR becomes 0x03066004 when machine check happens. Based on
the processor manual, the PLB0_BESR shows the PLB Timeout Error Status
and the value means the error operation is reading the processor core
DCU. The PLB0_BEAR shows the address of the access on which a bus
timeout error occurred. So I have the following questions for this
moment:
1. Is it possible or not that address translation leads to the PLB
timeout error? If that is the cause, how to fix the problem?
2. Is the address in PLB0_BEAR a memory address (real address or
effective address) or a bus address (not an address in any kind of
memory)?
3. Are there other reasons for the machine check in this situation?
4. Is it an unrecoverable hardware problem (bug) or not?
Here is the debugging log:
405EP>ti
Core number : 0
Core state : debug mode
Debug entry cause : single step
Current PC : 0xc32b1008
Current CR : 0x84000084
Current MSR : 0x00021030
Current LR : 0xc32b46c4
405EP>rd
GPR00: 00029030 c1dd9d60 c1fe7bf0 00000000
GPR04: 00000001 00000000 c32b2c8c 00000000
GPR08: c3068000 c3068000 00000001 c3062000
GPR12: 00000000 10019dd8 c32c0000 c32b0000
GPR16: 00000001 c32b0000 00000002 7ff4f670
GPR20: 00000028 c32b0000 c32b0000 10011000
GPR24: c306a000 00000000 00000000 10012c6c
GPR28: c18e4000 c32c0000 00000000 00000000
CR : 84000084 MSR: 00021030
405EP>ti
Core number : 0
Core state : debug mode
Debug entry cause : JTAG stop request
Current PC : 0xc000490c
Current CR : 0x42000082
Current MSR : 0x00000030
Current LR : 0xc001f1b8
# Step timeout detected
405EP>rd
GPR00: 03929800 c02f3e60 c3066000 000102f1
GPR04: 00005424 00000007 c0146f3c c0260000
GPR08: 00000000 c02d0000 c3062000 00000000
GPR12: 00000000 10019dd8 c32c0000 c32b0000
GPR16: 00000001 c32b0000 00000002 7ff4f670
GPR20: 00000028 c32b0000 c32b0000 10011000
GPR24: c306a000 00000000 00000000 10012c6c
GPR28: c02f0000 00000152 c3066000 c02f0000
CR : 42000082 MSR: 00000030
==========================================
Here is the error message:
Data machine check in kernel mode.
PLB0: BEAR= 0x03066004 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x04000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00002AD0 LR: 000005A0 CTR: C000CC58
REGS: c02f3f50 TRAP: 0202 Not tainted (2.6.19.2-eldk)
MSR: 00021000 <ME> CR: 24000084 XER: 20000000
TASK = c3066000[0] '' THREAD: c02d2000
GPR00: 00029030 C1DD9CA0 C3066000 C1DD9CB0 00000001 00000000 C32B2C8C
00000000
GPR08: C3068000 00000000 00021032 01DD9CA0 030661B0 10019DD8 C32C0000
C32B0000
GPR16: 00000001 C32B0000 00000002 7FF4F670 00000028 C32B0000 C32B0000
10011000
GPR24: C306A000 00000000 00000000 10012C6C C18E4000 C32C0000 00000000
00000000
NIP [00002AD0] 0x2ad0
LR [000005A0] 0x5a0
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Attempted to kill the idle task!
<0>Rebooting in 180 seconds..
Thanks a lot for advice!
Best Regards
Evangelion
July 17th, 2008
__________________________________________________
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com
^ permalink raw reply
* [bugme-daemon@bugzilla.kernel.org: [Bug 7306] Yenta-socket causes oops on insertion of any PCMCIA card]
From: Dominik Brodowski @ 2008-07-17 9:14 UTC (permalink / raw)
To: linuxppc-dev
Hi,
on an Apple Powerbook G3 (Lombard) with a PPC 740 running at 333 MHz, the
PCI host bridge is condigured to allow "downstream" devices to use iomem
0xfd000000 - 0xfdffffff
However, when using it for PCMCIA purposes, there's a machine check. Any
ideas on why this PCI host bridge is mis-configured, and how to resolve this
issue (besides adding reserved=0xfd000000,0xffffff as kernel boot option)?
Best,
Dominik
----- Forwarded message from bugme-daemon@bugzilla.kernel.org -----
Subject: [Bug 7306] Yenta-socket causes oops on insertion of any PCMCIA card
To: linux-pcmcia@lists.infradead.org
From: bugme-daemon@bugzilla.kernel.org
Date: Thu, 17 Jul 2008 01:45:44 -0700 (PDT)
http://bugzilla.kernel.org/show_bug.cgi?id=7306
------- Comment #17 from linux@brodo.de 2008-07-17 01:45 -------
Now this contains interesting information:
pcmcia: parent PCI bridge Memory window:
means the PCI host bridge is configured to allow "downstream" devices to use
this memory area. However, when the PCMCIA socket tries to do so, you get the
machine check. So my question would be to the powerpc folks: why is the PCI
host bridge configured this way, even if this memory area is not usable?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
----- End forwarded message -----
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Marco Stornelli @ 2008-07-17 9:04 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18503965.post@talk.nabble.com>
Misbah khan ha scritto:
>>> You can use the mem option to tell to the kernel that you've got less
>>> ram you really have.
> I really didnt got the point you made. Can you please elaborate it for my
> understanding.
If you've got 128MB of ram you can use the mem option to tell to the
kernel the it can use only (128 - 9) MB of ram, after that you can use
that chunk of ram, however I think it's not the case if your goal is to
use a sdram as you said in the previous message.
>>> However you can read Linux device drivers chapter 8
> i dont need to allocate large memory at the boot time also vmalloc and
> kmalloc i cant use as it can allocate free page up to 128kb, hence if you
> could suggest me a better technique i would really appriciate .
>
The problem about 128KB is only for kmalloc. If I understood correctly
you need only to remap the 9MB of your sdram.
> ---Misbah <><
>
>
> Marco Stornelli wrote:
>> Misbah khan ha scritto:
>>> Hi all,
>>>
>>> I need to allocate 9 MB of memory in to the kernel space which i need to
>>> mmap for the application to access.
>>>
>>> I need to know what could be the best possible way of doing the same.
>>>
>>> Please share your experience in this regard .
>>>
>>> Thank you in advance
>>>
>>> ----Misbah <><
>> You can use the mem option to tell to the kernel that you've got less
>> ram you really have. However you can read Linux device drivers chapter 8
>> "Obtaining Large Buffers" :).
>>
>> Regards,
>>
>> --
>> Marco Stornelli
>> Embedded Software Engineer
>> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
>> http://www.coritel.it
>>
>> marco.stornelli@coritel.it
>> +39 06 72582838
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* mpc5200b PSC interrupt load on high baud rates
From: Oliver Rutsch @ 2008-07-17 9:02 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
We're using the latest 2.4.25-Kernel from DENX on a custom mpc5200b board.
We have a RS485 device which sends continuously its data at a rate of
1.25 MBit/s. The problem here is that it takes nearly 90% of system time
just to read these data. I had a look into the driver
(arch/ppc/5xxx_io/psc.c) and the problem seems to be the RxRDY interrupt
of the PSCs. This interrupt is inserted every time when there's any data
in the FIFO. I found out, that most of the time the isr is reading only
1 or 2 bytes out of the FIFO, so the system is very busy to serve
thousands of interrupts.
Then I set the FFULL flag as the interrupt source in the mr1 register of
the PSC. I set an rx alarm level of 112 bytes (means that an interrupt
will be generated when FIFO>=400 bytes!) and rx granularity of 7.
With this the system load drops down under 1 percent!
But this approach has one big drawback: There will be no interrupt if I
receive less than 400 bytes. So this is not usable for "normal" SIO
operation.
Although not tested it looks like the same problem is in the driver for
the 2.6.25-Kernel (correct me when I'm wrong here).
So I have two ideas for better performance of this driver:
1. The interrupt will be generated by the FFULL flag. An endless kernel
timer will have every jiffy a look at the PSC FIFO status and pull out
any data if necessary. A look on the PSC FIFO status is a very short
operation so this timer shouldn't affect the system performance too
much. But maybe this adds some more latency when receiving only a few bytes.
2. The interrupt will be generated by the RxRDY flag. The isr only
starts reading if there are more than 400 bytes into the FIFO. But it
will start a kernel timer in order to pull out data less than 400 bytes.
Some pseudo code will look like this:
psc_isr()
{
if (FIFO>400)
read_fifo_data()
else
{
if (timer_not_already_started)
start_psc_timer()
}
[...]
}
psc_timer()
{
if (FIFO>0)
read_fifo_data()
}
So, any suggestions are welcome, what do you think?
Bye,
--
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com · Tel.:+49 5323 717514
Sympatec GmbH · Am Pulverhaus 1 · D-38678 Clausthal-Zellerfeld · Germany
Geschaeftsfuehrer: Dr.-Ing. E.h. Stephan Roethele · Handelsregister:
Amtsgericht Braunschweig, HRB 110809
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 8:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <d194b8ce0807170102x4be8b7ccx33a6a09e6129a45b@mail.gmail.com>
In have a sdram of size 9MB which i would map to kernel space (ioremap woul=
d
do that ) the whole 9 MB kernel virtual memory i need to map to the
application , the application would read when driver has complited writing
and vice versa this implimentation would be in a circular buffer type. The
size of my RAM is 128 MB=20
Sylvain Joyeau wrote:
>=20
> Misbah,
>=20
> Please, give some more details about your application: the answer(s)
> heavily depends on the kind of memory you want to allocate: contiguous
> (implied in DMA purpose) or not (for process memory sharing only).
>=20
> --
> sj
>=20
>=20
> 2008/7/17 Misbah khan <misbah_khan@engineer.com>:
>>
>> Hi all,
>>
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>> Please share your experience in this regard .
>>
>> Thank you in advance
>>
>> ----Misbah <><
>> --
>> View this message in context:
>> http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp185030=
22p18503022.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>=20
>=20
>=20
> --=20
> ------------------
> Sylvain JOYEAU
> Freelance Engineer
> Software RT-OS R&D
> sylvain.joyeau@gmail.com
> T=C3=A9l: +33-(0)667 477 052
> "A good idea is one side of the coin. The other side is the practical
> usefulness". J. Liedke.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
--=20
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-=
memory-in-kernel---tp18503022p18504063.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 8:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <487EFA1E.8060804@coritel.it>
>>You can use the mem option to tell to the kernel that you've got less
>>ram you really have.
I really didnt got the point you made. Can you please elaborate it for my
understanding.
>>However you can read Linux device drivers chapter 8
i dont need to allocate large memory at the boot time also vmalloc and
kmalloc i cant use as it can allocate free page up to 128kb, hence if you
could suggest me a better technique i would really appriciate .
---Misbah <><
Marco Stornelli wrote:
>
> Misbah khan ha scritto:
>> Hi all,
>>
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>> Please share your experience in this regard .
>>
>> Thank you in advance
>>
>> ----Misbah <><
> You can use the mem option to tell to the kernel that you've got less
> ram you really have. However you can read Linux device drivers chapter 8
> "Obtaining Large Buffers" :).
>
> Regards,
>
> --
> Marco Stornelli
> Embedded Software Engineer
> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
> http://www.coritel.it
>
> marco.stornelli@coritel.it
> +39 06 72582838
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18503965.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-17 8:24 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18503765.post@talk.nabble.com>
On Thursday 17 July 2008, Misbah khan wrote:
> vmalloc can only allocate 128k i guess where in i need 9MB allocated when
> driver is inserted and would be released only when its removed. mapping to
> user space is not a concern
The 128kb limitation is in kmalloc, not vmalloc. The latter is
specifically meant to have no limitations on the memory size
(other than the available resources), at the expense of having
to create a new virtual mapping.
Arnd <><
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 8:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200807170956.52101.arnd@arndb.de>
vmalloc can only allocate 128k i guess where in i need 9MB allocated when
driver is inserted and would be released only when its removed. mapping to
user space is not a concern
--- Misbah <><
Arnd Bergmann wrote:
>
> On Thursday 17 July 2008, Misbah khan wrote:
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>
> If you don't need the memory to be physically contiguous, you can use
> vmalloc to get the memory, but then you need to use remap_vmalloc_range
> for mapping the memory into a user address space.
>
> Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18503765.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Sylvain Joyeau @ 2008-07-17 8:02 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18503022.post@talk.nabble.com>
Misbah,
Please, give some more details about your application: the answer(s)
heavily depends on the kind of memory you want to allocate: contiguous
(implied in DMA purpose) or not (for process memory sharing only).
--
sj
2008/7/17 Misbah khan <misbah_khan@engineer.com>:
>
> Hi all,
>
> I need to allocate 9 MB of memory in to the kernel space which i need to
> mmap for the application to access.
>
> I need to know what could be the best possible way of doing the same.
>
> Please share your experience in this regard .
>
> Thank you in advance
>
> ----Misbah <><
> --
> View this message in context: http://www.nabble.com/how-to-allocate-9MB-o=
f-memory-in-kernel---tp18503022p18503022.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--=20
------------------
Sylvain JOYEAU
Freelance Engineer
Software RT-OS R&D
sylvain.joyeau@gmail.com
T=E9l: +33-(0)667 477 052
"A good idea is one side of the coin. The other side is the practical
usefulness". J. Liedke.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-17 7:56 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18503022.post@talk.nabble.com>
On Thursday 17 July 2008, Misbah khan wrote:
> I need to allocate 9 MB of memory in to the kernel space which i need to
> mmap for the application to access.
>
> I need to know what could be the best possible way of doing the same.
>
If you don't need the memory to be physically contiguous, you can use
vmalloc to get the memory, but then you need to use remap_vmalloc_range
for mapping the memory into a user address space.
Arnd <><
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Marco Stornelli @ 2008-07-17 7:51 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18503022.post@talk.nabble.com>
Misbah khan ha scritto:
> Hi all,
>
> I need to allocate 9 MB of memory in to the kernel space which i need to
> mmap for the application to access.
>
> I need to know what could be the best possible way of doing the same.
>
> Please share your experience in this regard .
>
> Thank you in advance
>
> ----Misbah <><
You can use the mem option to tell to the kernel that you've got less
ram you really have. However you can read Linux device drivers chapter 8
"Obtaining Large Buffers" :).
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Grant Likely @ 2008-07-17 7:33 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Jean Delvare, Linuxppc-dev, Alan Clucas, Detlev Zundel,
lm-sensors
In-Reply-To: <487EF54C.5020007@grandegger.com>
On Thu, Jul 17, 2008 at 09:31:24AM +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
>> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>>> I've found this thread now. Why can't we totally remove probing from
>>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>>> i2c client hasn't been converted to the new model yet, convert it
>>> before deploying with the new i2c-mpc driver. It's not very hard to
>>> convert the client drivers.
>>
>> I tend to agree. And the number of unconverted drivers is getting very
>> low these days. Only 2 RTC drivers are left, and by the end of the day,
>> almost all hwmon drivers will be converted as well.
>
> Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag
> completely. It just affects HWMON devices anyhow and if there is still
> an old style driver around, it should be converted.
I'm cool with that.
g.
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-17 7:31 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, lm-sensors, Detlev Zundel, Alan Clucas
In-Reply-To: <20080716162942.6fcb526d@hyperion.delvare>
Jean Delvare wrote:
> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>> On 7/16/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
>>> > On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
>>> > > Jean Delvare wrote:
>>> > >
>>>
>>>>> Yep, as probing might not be acceptable in some cases, I makes sense to
>>> > > add a property to suppress probing:
>>> >
>>> > It'd rather make no-probing the default if possible. My understanding
>>> > is that all systems using i2c-mpc should have proper platform data.
>>>
>>>
>>> Total ACK. From my perspective, probing should be off by default because the
>>> typical use case in powerpc land is to trust data in the device tree. Add the
>>> property to turn on probing, not to turn it off. Also, you'll need to
>>> document the semantics of such a property. ie. what exactly does it
>>> mean when the probing property is present and the spi bus node has child
>>> nodes?
>> I've found this thread now. Why can't we totally remove probing from
>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>> i2c client hasn't been converted to the new model yet, convert it
>> before deploying with the new i2c-mpc driver. It's not very hard to
>> convert the client drivers.
>
> I tend to agree. And the number of unconverted drivers is getting very
> low these days. Only 2 RTC drivers are left, and by the end of the day,
> almost all hwmon drivers will be converted as well.
Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag
completely. It just affects HWMON devices anyhow and if there is still
an old style driver around, it should be converted.
Wolfgang.
^ permalink raw reply
* how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 7:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I need to allocate 9 MB of memory in to the kernel space which i need to
mmap for the application to access.
I need to know what could be the best possible way of doing the same.
Please share your experience in this regard .
Thank you in advance
----Misbah <><
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18503022.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 4/4] powerpc: ftrace: Use PPC_LONG and PPC_LONG_ALIGN asm macros
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
In-Reply-To: <d452d52afbde7001bf85070ee528d21bfa814d8d.1216279290.git.michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 13 +++----------
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 49a2049..0e9fc10 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/list.h>
+#include <asm/asm-compat.h>
#include <asm/cacheflush.h>
#include <asm/code-patching.h>
#include <asm/ftrace.h>
@@ -49,14 +50,6 @@ notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
return (unsigned char *)&op;
}
-#ifdef CONFIG_PPC64
-# define _ASM_ALIGN " .align 3 "
-# define _ASM_PTR " .llong "
-#else
-# define _ASM_ALIGN " .align 2 "
-# define _ASM_PTR " .long "
-#endif
-
notrace int
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
@@ -85,8 +78,8 @@ ftrace_modify_code(unsigned long ip, unsigned char *old_code,
" b 2b\n"
".previous\n"
".section __ex_table,\"a\"\n"
- _ASM_ALIGN "\n"
- _ASM_PTR "1b, 3b\n"
+ PPC_LONG_ALIGN "\n"
+ PPC_LONG "1b, 3b\n"
".previous"
: "=r"(faulted), "=r"(replaced)
: "r"(ip), "r"(new),
--
1.5.5
^ permalink raw reply related
* [PATCH 3/4] powerpc: ftrace: Use create_branch() and cope with errors
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
In-Reply-To: <d452d52afbde7001bf85070ee528d21bfa814d8d.1216279290.git.michael@ellerman.id.au>
Use create_branch() rather than doing it by hand. It's possible that
we are unable to create a branch to the address, if it's too far away,
in which case just return a nop. This will break the tracing, but
shouldn't crash the kernel at least.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 20 ++++++++------------
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1d6f174..49a2049 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -19,11 +19,6 @@
#include <asm/ftrace.h>
-static unsigned int notrace ftrace_calc_offset(long ip, long addr)
-{
- return (int)(addr - ip);
-}
-
notrace unsigned char *ftrace_nop_replace(void)
{
static unsigned int ftrace_nop = PPC_NOP_INSTR;
@@ -35,16 +30,17 @@ notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
{
static unsigned int op;
- /*
- * It would be nice to just use create_function_call, but that will
- * update the code itself. Here we need to just return the
- * instruction that is going to be modified, without modifying the
- * code.
- */
addr = ppc_function_entry((void *)addr);
/* Set to "bl addr" */
- op = 0x48000001 | (ftrace_calc_offset(ip, addr) & 0x03fffffc);
+ op = create_branch((unsigned int *)ip, addr, BRANCH_SET_LINK);
+
+ /*
+ * This routine is not allowed to fail, but create_branch() can.
+ * In that case, just return nop and cross our fingers.
+ */
+ if (!op)
+ return ftrace_nop_replace();
/*
* No locking needed, this must be called via kstop_machine
--
1.5.5
^ permalink raw reply related
* [PATCH 2/4] powerpc: ftrace: Use ppc_function_entry() rather than hand-rolled macro
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
In-Reply-To: <d452d52afbde7001bf85070ee528d21bfa814d8d.1216279290.git.michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 78f4423..1d6f174 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -19,14 +19,6 @@
#include <asm/ftrace.h>
-#ifdef CONFIG_PPC32
-# define GET_ADDR(addr) addr
-#else
-/* PowerPC64's functions are data that points to the functions */
-# define GET_ADDR(addr) *(unsigned long *)addr
-#endif
-
-
static unsigned int notrace ftrace_calc_offset(long ip, long addr)
{
return (int)(addr - ip);
@@ -49,7 +41,7 @@ notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
* instruction that is going to be modified, without modifying the
* code.
*/
- addr = GET_ADDR(addr);
+ addr = ppc_function_entry((void *)addr);
/* Set to "bl addr" */
op = 0x48000001 | (ftrace_calc_offset(ip, addr) & 0x03fffffc);
--
1.5.5
^ permalink raw reply related
* [PATCH 1/4] powerpc: ftrace: Use PPC_NOP_INSTR #define for NOP
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
And move ftrace_nop into the only function it's used in.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 3855ceb..78f4423 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -15,11 +15,10 @@
#include <linux/list.h>
#include <asm/cacheflush.h>
+#include <asm/code-patching.h>
#include <asm/ftrace.h>
-static unsigned int ftrace_nop = 0x60000000;
-
#ifdef CONFIG_PPC32
# define GET_ADDR(addr) addr
#else
@@ -35,6 +34,8 @@ static unsigned int notrace ftrace_calc_offset(long ip, long addr)
notrace unsigned char *ftrace_nop_replace(void)
{
+ static unsigned int ftrace_nop = PPC_NOP_INSTR;
+
return (char *)&ftrace_nop;
}
--
1.5.5
^ permalink raw reply related
* [PATCH 3/3] powerpc: Use PPC_LONG and PPC_LONG_ALIGN in lib/string.S
From: Michael Ellerman @ 2008-07-17 7:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3756cbfb076b2fa0b93ec990aabfee73296443d9.1216279070.git.michael@ellerman.id.au>
No change to the generated code.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/lib/string.S | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S
index 49eb1f1..64e2e49 100644
--- a/arch/powerpc/lib/string.S
+++ b/arch/powerpc/lib/string.S
@@ -13,13 +13,7 @@
#include <asm/ppc_asm.h>
.section __ex_table,"a"
-#ifdef CONFIG_PPC64
- .align 3
-#define EXTBL .llong
-#else
- .align 2
-#define EXTBL .long
-#endif
+ PPC_LONG_ALIGN
.text
_GLOBAL(strcpy)
@@ -160,9 +154,9 @@ _GLOBAL(__clear_user)
blr
.section __ex_table,"a"
- EXTBL 11b,90b
- EXTBL 1b,91b
- EXTBL 8b,92b
+ PPC_LONG 11b,90b
+ PPC_LONG 1b,91b
+ PPC_LONG 8b,92b
.text
_GLOBAL(__strncpy_from_user)
@@ -183,7 +177,7 @@ _GLOBAL(__strncpy_from_user)
blr
.section __ex_table,"a"
- EXTBL 1b,99b
+ PPC_LONG 1b,99b
.text
/* r3 = str, r4 = len (> 0), r5 = top (highest addr) */
@@ -208,4 +202,4 @@ _GLOBAL(__strnlen_user)
blr
.section __ex_table,"a"
- EXTBL 1b,99b
+ PPC_LONG 1b,99b
--
1.5.5
^ permalink raw reply related
* [PATCH 2/3] powerpc: Use PPC_LONG_ALIGN in uaccess.h
From: Michael Ellerman @ 2008-07-17 7:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3756cbfb076b2fa0b93ec990aabfee73296443d9.1216279070.git.michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
include/asm-powerpc/uaccess.h | 21 +++++++++------------
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 1a0736f..bd0fb84 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -6,6 +6,7 @@
#include <linux/sched.h>
#include <linux/errno.h>
+#include <asm/asm-compat.h>
#include <asm/processor.h>
#include <asm/page.h>
@@ -141,12 +142,11 @@ extern long __put_user_bad(void);
" b 2b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,3b\n" \
".previous" \
: "=r" (err) \
- : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err),\
- "i"(sizeof(unsigned long)))
+ : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
#ifdef __powerpc64__
#define __put_user_asm2(x, ptr, retval) \
@@ -162,13 +162,12 @@ extern long __put_user_bad(void);
" b 3b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,4b\n" \
PPC_LONG "2b,4b\n" \
".previous" \
: "=r" (err) \
- : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err),\
- "i"(sizeof(unsigned long)))
+ : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
#endif /* __powerpc64__ */
#define __put_user_size(x, ptr, size, retval) \
@@ -226,12 +225,11 @@ extern long __get_user_bad(void);
" b 2b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,3b\n" \
".previous" \
: "=r" (err), "=r" (x) \
- : "b" (addr), "i" (-EFAULT), "0" (err), \
- "i"(sizeof(unsigned long)))
+ : "b" (addr), "i" (-EFAULT), "0" (err))
#ifdef __powerpc64__
#define __get_user_asm2(x, addr, err) \
@@ -249,13 +247,12 @@ extern long __get_user_bad(void);
" b 3b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,4b\n" \
PPC_LONG "2b,4b\n" \
".previous" \
: "=r" (err), "=&r" (x) \
- : "b" (addr), "i" (-EFAULT), "0" (err), \
- "i"(sizeof(unsigned long)))
+ : "b" (addr), "i" (-EFAULT), "0" (err))
#endif /* __powerpc64__ */
#define __get_user_size(x, ptr, size, retval) \
--
1.5.5
^ permalink raw reply related
* [PATCH 1/3] powerpc: Add a #define for aligning to a long-sized boundary
From: Michael Ellerman @ 2008-07-17 7:17 UTC (permalink / raw)
To: linuxppc-dev
Add a #define for aligning to a long-sized boundary. It would be nice
to use sizeof(long) for this, but that requires generating the value
with asm-offsets.c, and asm-offsets.c includes asm-compat.h and we
descend into some sort of recursive include hell.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
include/asm-powerpc/asm-compat.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/asm-compat.h b/include/asm-powerpc/asm-compat.h
index 8ec2e1d..8f0fe79 100644
--- a/include/asm-powerpc/asm-compat.h
+++ b/include/asm-powerpc/asm-compat.h
@@ -22,6 +22,7 @@
#define PPC_STL stringify_in_c(std)
#define PPC_LCMPI stringify_in_c(cmpdi)
#define PPC_LONG stringify_in_c(.llong)
+#define PPC_LONG_ALIGN stringify_in_c(.balign 8)
#define PPC_TLNEI stringify_in_c(tdnei)
#define PPC_LLARX stringify_in_c(ldarx)
#define PPC_STLCX stringify_in_c(stdcx.)
@@ -43,6 +44,7 @@
#define PPC_STL stringify_in_c(stw)
#define PPC_LCMPI stringify_in_c(cmpwi)
#define PPC_LONG stringify_in_c(.long)
+#define PPC_LONG_ALIGN stringify_in_c(.balign 4)
#define PPC_TLNEI stringify_in_c(twnei)
#define PPC_LLARX stringify_in_c(lwarx)
#define PPC_STLCX stringify_in_c(stwcx.)
--
1.5.5
^ permalink raw reply related
* Re: Videomode 800x480
From: Alex_SYS @ 2008-07-17 7:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <18482586.post@talk.nabble.com>
Alex_SYS wrote:
>=20
> <Here is the Kernel Bootup message that it gives when it crashes!
>=20
> U-Boot 1.2.0-mpc5200b-tiny-3 (Dec 11 2007 - 11:25:01)
>=20
> CPU: MPC5200 v2.2, Core v1.4 at 399.999 MHz
> Bus 133 MHz, IPB 133 MHz, PCI 33 MHz
> Board: phyCORE-MPC5200B-tiny
> I2C: ready
> DRAM: 64 MB
> SP: 0x03f73768
> FLASH: 16 MB
> Using pcm030 machine description
> Linux version 2.6.23.1-rt5-pcm030-1trunk (aschmid@LINUX) (gcc version
> 4.1.2) #39
> 4 PREEMPT RT Tue Dec 11 17:58:48 CET 2007
> Zone PFN ranges:
> DMA 0 -> 16384
> Normal 16384 -> 16384
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 16384
> Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
> Built 1 zonelists in Zone order. Total pages: 16256
> Kernel command line: video=3D0x0-16@60 , console=3DttyPSC0,115200
> mtdparts=3Dphysmap-f
> lash.0:256k(ubootl),1792k(kernel),13312k(jffs2),256k(uboot)ro,256k(oftree=
),-(spa
> ce) rw root=3D/dev/mtdblock2 rootfstype=3Djffs2
> WARNING: experimental RCU implementation.
> MPC52xx PIC is up and running!
> PID hash table entries: 256 (order: 8, 1024 bytes)
> Console: colour dummy device 80x25
> console [ttyPSC0] enabled
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 61960k/65536k available (2624k kernel code, 3508k reserved, 144k
> data, 1
> 06k bss, 124k init)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> DMA: MPC52xx BestComm driver
> DMA: MPC52xx BestComm engine @f0001200 ok !
> Generic PHY: Registered new driver
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 2048 (order: 4, 73728 bytes)
> TCP bind hash table entries: 2048 (order: 3, 57344 bytes)
> TCP: Hash tables configured (established 2048 bind 2048)
> TCP reno registered
> JFFS2 version 2.2. (NAND) =C3=82=C2=A9 2001-2006 Red Hat, Inc.
> io scheduler noop registered (default)
> No Options from U-Boot
> Lime Driver PROBE
> No Mode
> Name des Strings 0x0-16@60 with L=C3=83=C2=A4nge 9
> Schleife mode Options
> Schleife @
> Schleife -
> Schleife x
> DONE vor CVT xres=3D 0 , yres=3D0 , cvt=3D
> 0******************************************
> ************CVT Mode: Trying specified video mode 0x0
> Trying mode 800x480-16@60 800x600-16@20
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x400-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x480-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 800x600-16@56
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1024x768-16@87
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x400-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x480-16@72
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x480-16@75
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 800x600-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x480-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x864-16@69
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 800x600-16@72
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1024x768-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 640x480-16@100
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x864-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 800x600-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1024x768-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@87
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 800x600-16@100
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1024x768-16@76
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x864-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@61
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1400x1050-16@68
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1400x1050-16@75
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1400x1050-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1024x768-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x864-16@78
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1600x1200-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x864-16@84
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@74
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1024x768-16@100
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@76
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1600x1200-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x864-16@100
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1600x1200-16@75
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1680x1050-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1600x1200-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1280x1024-16@100
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1800x1440-16@64
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1800x1440-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 512x384-16@78
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 512x384-16@85
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 320x200-16@70
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 320x240-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 320x240-16@72
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 400x300-16@56
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 400x300-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 400x300-16@72
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 480x300-16@56
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 480x300-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 480x300-16@63
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 480x300-16@72
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1920x1200-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1152x768-16@60
> Error=3D
> 0********************************************************************Tryi
> ng mode noname 1366x768-16@60
> Error=3D
> 0********************************************************************Tryi
> ng default video mode
> Trying mode noname 800x480-16@60
> Error=3D
> 0********************************************************************Tryi
> ng default mode
> Console: switching to colour frame buffer device 114x34
> stopped custom tracer.
> Oops: Exception in kernel mode, sig: 4 [#1]
> PREEMPT pcm030
> Modules linked in:
> NIP: 00000900 LR: c011d94c CTR: c011daf4
> REGS: c3fe7a30 TRAP: 0700 Not tainted (2.6.23.1-rt5-pcm030-1trunk)
> MSR: 00081000 <ME> CR: 42042022 XER: 00000000
> TASK =3D c3fe5c00[1] 'swapper' THREAD: c3fe6000
> GPR00: ffffffff c3fe7ae0 c3fe5c00 c5128bfc 00000000 00010001 00000020
> 00000020
> GPR08: 00000000 00010001 ffffffff 00000020 c3f5f800 fffffffb 03fcb000
> ffffffff
> GPR16: 00000001 00000000 c3fe7f78 c024a748 00000000 00000000 00000002
> 000001e0
> GPR24: 00010001 c011daf4 00000020 c3f5f800 c5128bfc 00000000 00000005
> 000001b0
> NIP [00000900] 0x900
> LR [c011d94c] cfb_fillrect+0x144/0x2ec
> Call Trace:
> [c3fe7ae0] [c00fd90c] number+0x354/0x374 (unreliable)
> [c3fe7b20] [c011c9c4] bit_clear_margins+0x100/0x104
> [c3fe7b60] [c0116254] fbcon_clear_margins+0x7c/0x80
> [c3fe7b70] [c011ba34] fbcon_switch+0x45c/0x630
> [c3fe7c40] [c01350cc] redraw_screen+0x158/0x200
> [c3fe7c60] [c0137878] bind_con_driver+0x2ec/0x428
> [c3fe7ca0] [c01379f4] take_over_console+0x40/0x58
> [c3fe7cc0] [c01199d0] fbcon_takeover+0x88/0xf8
> [c3fe7cd0] [c011a694] fbcon_event_notify+0x8e4/0x908
> [c3fe7da0] [c002e5a4] notifier_call_chain+0x60/0xb0
> [c3fe7dc0] [c002f2bc] __blocking_notifier_call_chain+0x50/0x74
> [c3fe7de0] [c011165c] fb_notifier_call_chain+0x24/0x34
> [c3fe7df0] [c0112600] register_framebuffer+0x120/0x1d0
> [c3fe7e50] [c0283380] vfb_probe+0x164/0x220
> [c3fe7e70] [c0142284] platform_drv_probe+0x20/0x30
> [c3fe7e80] [c01408e0] driver_probe_device+0xb8/0x1ec
> [c3fe7ea0] [c0140a98] __driver_attach+0x84/0x88
> [c3fe7ec0] [c013fbbc] bus_for_each_dev+0x58/0x94
> [c3fe7ef0] [c01406f0] driver_attach+0x24/0x34
> [c3fe7f00] [c0140018] bus_add_driver+0x98/0x1d8
> [c3fe7f20] [c0140c40] driver_register+0x58/0xa0
> [c3fe7f30] [c0142618] platform_driver_register+0x98/0xa8
> [c3fe7f40] [c0283534] vfb_init+0xf8/0x120
> [c3fe7f70] [c02711c4] kernel_init+0xa8/0x2bc
> [c3fe7ff0] [c000fd2c] kernel_thread+0x44/0x60
> Instruction dump:
> Unable to handle kernel paging request for data at address 0xffff83bc
> Faulting instruction address: 0xc00fd970
> Oops: Kernel access of bad area, sig: 11 [#2]
> PREEMPT pcm030
> Modules linked in:
> NIP: c00fd970 LR: c00fe29c CTR: 00000000
> REGS: c3fe7790 TRAP: 0300 Not tainted (2.6.23.1-rt5-pcm030-1trunk)
> MSR: 00001032 <ME,IR,DR> CR: 28044088 XER: 00000000
> DAR: ffff83bc, DSISR: 20000000
> TASK =3D c3fe5c00[1] 'swapper' THREAD: c3fe6000
> GPR00: c00fe29c c3fe7840 c3fe5c00 00000000 00000400 ffff83bc c3fe78f8
> 00004000
> GPR08: 00000000 00000002 ffff83bc c0296cc8 28042088 fffffffb 03fcb000
> ffffffff
> GPR16: 00000001 00000000 c3fe7f78 c024a748 00000000 00000000 c0290000
> c0290000
> GPR24: 00001032 c02bd934 c3fe78f8 c0250000 ffff83bc c02c0000 c02bdd34
> c02bd934
> NIP [c00fd970] vsnprintf+0x44/0x80c
> LR [c00fe29c] vscnprintf+0x18/0x1ac
> Call Trace:
> [c3fe7840] [c0045948] rt_down_trylock+0x20/0x70 (unreliable)
> [c3fe7870] [c00fe29c] vscnprintf+0x18/0x1ac
> [c3fe7880] [c001fb88] vprintk+0x94/0x3c4
> [c3fe78f0] [c001ff08] printk+0x50/0x60
> [c3fe7930] [c0008890] show_regs+0x2c4/0x2e8
> [c3fe7960] [c000d3bc] die+0xe8/0x198
> [c3fe7980] [c000d5e8] _exception+0x38/0x104
> [c3fe7a20] [c000f534] ret_from_except_full+0x0/0x4c
> --- Exception: 700 at 0x900
> LR =3D cfb_fillrect+0x144/0x2ec
> [c3fe7ae0] [c00fd90c] number+0x354/0x374 (unreliable)
> [c3fe7b20] [c011c9c4] bit_clear_margins+0x100/0x104
> [c3fe7b60] [c0116254] fbcon_clear_margins+0x7c/0x80
> [c3fe7b70] [c011ba34] fbcon_switch+0x45c/0x630
> [c3fe7c40] [c01350cc] redraw_screen+0x158/0x200
> [c3fe7c60] [c0137878] bind_con_driver+0x2ec/0x428
> [c3fe7ca0] [c01379f4] take_over_console+0x40/0x58
> [c3fe7cc0] [c01199d0] fbcon_takeover+0x88/0xf8
> [c3fe7cd0] [c011a694] fbcon_event_notify+0x8e4/0x908
> [c3fe7da0] [c002e5a4] notifier_call_chain+0x60/0xb0
> [c3fe7dc0] [c002f2bc] __blocking_notifier_call_chain+0x50/0x74
> [c3fe7de0] [c011165c] fb_notifier_call_chain+0x24/0x34
> [c3fe7df0] [c0112600] register_framebuffer+0x120/0x1d0
> [c3fe7e50] [c0283380] vfb_probe+0x164/0x220
> [c3fe7e70] [c0142284] platform_drv_probe+0x20/0x30
> [c3fe7e80] [c01408e0] driver_probe_device+0xb8/0x1ec
> [c3fe7ea0] [c0140a98] __driver_attach+0x84/0x88
> [c3fe7ec0] [c013fbbc] bus_for_each_dev+0x58/0x94
> [c3fe7ef0] [c01406f0] driver_attach+0x24/0x34
> [c3fe7f00] [c0140018] bus_add_driver+0x98/0x1d8
> [c3fe7f20] [c0140c40] driver_register+0x58/0xa0
> [c3fe7f30] [c0142618] platform_driver_register+0x98/0xa8
> [c3fe7f40] [c0283534] vfb_init+0xf8/0x120
> [c3fe7f70] [c02711c4] kernel_init+0xa8/0x2bc
> [c3fe7ff0] [c000fd2c] kernel_thread+0x44/0x60
> Instruction dump:
> 7c791b78 7cda3378 90010034 91810010 90a10008 419007bc 7fc32214 7f83f040
> 419d0260 81410008 7f3fcb78 38600000 <880a0000> 2f800000 419e0044 7f3fcb78
> Kernel panic - not syncing: Attempted to kill init!
> Call Trace:
> [c3fe7690] [c0007dfc] show_stack+0x3c/0x194 (unreliable)
> [c3fe76c0] [c001f004] panic+0x9c/0x174
> [c3fe7710] [c0023214] do_exit+0x6ec/0x884
> [c3fe7750] [c000d46c] kernel_bad_stack+0x0/0x4c
> [c3fe7770] [c00120ac] bad_page_fault+0x90/0xd8
> [c3fe7780] [c000f388] handle_page_fault+0x7c/0x80
> --- Exception: 300 at vsnprintf+0x44/0x80c
> LR =3D vscnprintf+0x18/0x1ac
> [c3fe7840] [c0045948] rt_down_trylock+0x20/0x70 (unreliable)
> [c3fe7870] [c00fe29c] vscnprintf+0x18/0x1ac
> [c3fe7880] [c001fb88] vprintk+0x94/0x3c4
> [c3fe78f0] [c001ff08] printk+0x50/0x60
> [c3fe7930] [c0008890] show_regs+0x2c4/0x2e8
> [c3fe7960] [c000d3bc] die+0xe8/0x198
> [c3fe7980] [c000d5e8] _exception+0x38/0x104
> [c3fe7a20] [c000f534] ret_from_except_full+0x0/0x4c
> --- Exception: 700 at 0x900
> LR =3D cfb_fillrect+0x144/0x2ec
> [c3fe7ae0] [c00fd90c] number+0x354/0x374 (unreliable)
> [c3fe7b20] [c011c9c4] bit_clear_margins+0x100/0x104
> [c3fe7b60] [c0116254] fbcon_clear_margins+0x7c/0x80
> [c3fe7b70] [c011ba34] fbcon_switch+0x45c/0x630
> [c3fe7c40] [c01350cc] redraw_screen+0x158/0x200
> [c3fe7c60] [c0137878] bind_con_driver+0x2ec/0x428
> [c3fe7ca0] [c01379f4] take_over_console+0x40/0x58
> [c3fe7cc0] [c01199d0] fbcon_takeover+0x88/0xf8
> [c3fe7cd0] [c011a694] fbcon_event_notify+0x8e4/0x908
> [c3fe7da0] [c002e5a4] notifier_call_chain+0x60/0xb0
> [c3fe7dc0] [c002f2bc] __blocking_notifier_call_chain+0x50/0x74
> [c3fe7de0] [c011165c] fb_notifier_call_chain+0x24/0x34
> [c3fe7df0] [c0112600] register_framebuffer+0x120/0x1d0
> [c3fe7e50] [c0283380] vfb_probe+0x164/0x220
> [c3fe7e70] [c0142284] platform_drv_probe+0x20/0x30
> [c3fe7e80] [c01408e0] driver_probe_device+0xb8/0x1ec
> [c3fe7ea0] [c0140a98] __driver_attach+0x84/0x88
> [c3fe7ec0] [c013fbbc] bus_for_each_dev+0x58/0x94
> [c3fe7ef0] [c01406f0] driver_attach+0x24/0x34
> [c3fe7f00] [c0140018] bus_add_driver+0x98/0x1d8
> [c3fe7f20] [c0140c40] driver_register+0x58/0xa0
> [c3fe7f30] [c0142618] platform_driver_register+0x98/0xa8
> [c3fe7f40] [c0283534] vfb_init+0xf8/0x120
> [c3fe7f70] [c02711c4] kernel_init+0xa8/0x2bc
> [c3fe7ff0] [c000fd2c] kernel_thread+0x44/0x60
> Rebooting in 180 seconds..
> =20
> Hello,
>=20
> Alex_SYS wrote:
>> Hello, I have the problem that I need a Framebuffer resolution 800x480!
>> Since now I have filled the fb_info, var and fix Structs!
>> But there was the problem with the resolution!
>> I have found out that the problem is the videomode!
>> In modedb there is unfortunately no 800x480 Videomode, and I have tried
>> my
>> own 800x480 Struct, but the Kernel does`t want my settings (I tried to
>> change an 800x600 to 800x480 only by changing yres to 480).
>> Can someone tell me please a working fb_videomode struct for 800x480?
>=20
> Values for 800x480 fb_videomode depend on the TFT-panel that
> you are using. Without the spec of this panel it is hard to guess.
> It is also hard to guess the value for .pixclock as we do not know
> if internal or external clock is used as the source for display
> reference clock. What is the value of GDC DCM0 register (at
> offset 0x1fd0000 or 0x1fd0100 from the GDC base)?
>=20
> Try something like this:
> .xres =3D 800
> .yres =3D 480
> .pixclock =3D 40000
> .left_margin =3D 86
> .right_margin =3D 42
> .upper_margin =3D 33
> .lower_margin =3D 10
> .hsync_len =3D 128
> .vsync_len =3D 2
>=20
>> The syncs are setted up by U-Boot .
>=20
>>then you probably should retrieve proper values for fb_videomode
>>from display controller registers set up by U-Boot. If you do not
>>have the spec for your panel, it is the way to go. Consult the
>>GDC manual (Display control registers section) and
>>Documentation/fb/framebuffer.txt in the linux source tree.
>=20
> Hello, the physical settings for sync are made by U-Boot and working!
> But in Lunux when I use 800x480, the screen is well, but the Kernel
> crashes at Bootup!
> Using 800x600 works!
> Now I need only "Dummy" settings, that I can tell Linux I would like
> 800x480 and the Kernel doesn`t crash!
> I don`t know exactly why the Kernel crashes, I know only that the modedB
> 800x600 and so on work!
> I will try your settings immediately!
> Thanks
>=20
> Alex
>=20
> Best regards,
> Anatolij
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
>=20
--=20
View this message in context: http://www.nabble.com/Videomode-800x480-tp184=
70632p18502863.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] elf loader support for auxvec base platform string
From: Andrew Morton @ 2008-07-17 7:09 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Nathan Lynch, Linus Torvalds, linux-kernel, roland
In-Reply-To: <1216276539.7740.309.camel@pasglop>
On Thu, 17 Jul 2008 16:35:39 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Hi Linus, Andrew !
>
> Should I seek somebody's ack before merging a patch like the one below ?
I think it's good to do so.
> I'm a bit reluctant to merge via the powerpc.git tree some changes to
> generic files without at least an ack from somebody else :-)
It tends to happen. People often don't notice unless it a) crashes or
b) spits warnings or c) screws up my tree or d) all the above plus
more.
> There have been some debate on whether this AT_BASE_PLATFORM is the
> right approach, though I haven't seen them reach any useful conclusion
> and our toolchain people internally are screaming for it...
>
> Cheers,
> Ben.
>
> On Tue, 2008-07-15 at 18:58 -0500, Nathan Lynch wrote:
> > Some IBM POWER-based platforms have the ability to run in a
> > mode which mostly appears to the OS as a different processor from the
> > actual hardware. For example, a Power6 system may appear to be a
> > Power5+, which makes the AT_PLATFORM value "power5+". This means that
> > programs are restricted to the ISA supported by Power5+;
> > Power6-specific instructions are treated as illegal.
> >
> > However, some applications (virtual machines, optimized libraries) can
> > benefit from knowledge of the underlying CPU model. A new aux vector
> > entry, AT_BASE_PLATFORM, will denote the actual hardware. For
> > example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
> > will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
> > that AT_PLATFORM indicates the instruction set supported, while
> > AT_BASE_PLATFORM indicates the underlying microarchitecture.
> >
> > If the architecture has defined ELF_BASE_PLATFORM, copy that value to
> > the user stack in the same manner as ELF_PLATFORM.
> >
> > Signed-off-by: Nathan Lynch <ntl@pobox.com>
> > ---
> > fs/binfmt_elf.c | 23 +++++++++++++++++++++++
> > include/linux/auxvec.h | 5 ++++-
> > 2 files changed, 27 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index d48ff5f..834c2c4 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -131,6 +131,10 @@ static int padzero(unsigned long elf_bss)
> > #define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
> > #endif
> >
> > +#ifndef ELF_BASE_PLATFORM
> > +#define ELF_BASE_PLATFORM NULL
> > +#endif
Please add a comment which explains what this is.
Please also add a comment telling the world in which header file the
architecture *must* define this macro and then ensure that that header is
included into this file by reliable means. asm/elf.h looks OK.
> > static int
> > create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> > unsigned long load_addr, unsigned long interp_load_addr)
> > @@ -142,7 +146,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> > elf_addr_t __user *envp;
> > elf_addr_t __user *sp;
> > elf_addr_t __user *u_platform;
> > + elf_addr_t __user *u_base_platform;
> > const char *k_platform = ELF_PLATFORM;
> > + const char *k_base_platform = ELF_BASE_PLATFORM;
> > int items;
> > elf_addr_t *elf_info;
> > int ei_index = 0;
> > @@ -172,6 +178,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> > return -EFAULT;
> > }
> >
> > + /*
> > + * If this architecture has a "base" platform capability
> > + * string, copy it to userspace.
> > + */
> > + u_base_platform = NULL;
> > + if (k_base_platform) {
> > + size_t len = strlen(k_base_platform) + 1;
> > +
> > + u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
> > + if (__copy_to_user(u_base_platform, k_base_platform, len))
> > + return -EFAULT;
> > + }
>From my reading, this change will result in no additional code
generation on non-powerpc architectures. This is good. If poss, could
you please verify that theory and perhaps drop a note in the changelog
about that?
Apart from that - acked-by-me
^ permalink raw reply
* Re: [PATCH] powerpc: Introduce local (non-broadcast) forms of tlb invalidates
From: Benjamin Herrenschmidt @ 2008-07-17 6:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807151627020.29665@blarg.am.freescale.net>
On Tue, 2008-07-15 at 16:27 -0500, Kumar Gala wrote:
> Introduced a new set of low level tlb invalidate functions that do not
> broadcast invalidates on the bus:
>
> _tlbil_all - invalidate all
> _tlbil_pid - invalidate based on process id (or mm context)
> _tlbil_va - invalidate based on virtual address (ea + pid)
>
> On non-SMP configs _tlbil_all should be functionally equivalent to _tlbia and
> _tlbil_va should be functionally equivalent to _tlbie.
>
> The intent of this change is to handle SMP based invalidates via IPIs instead
> of broadcasts as the mechanism scales better for larger number of cores.
>
> On e500 (fsl-booke mmu) based cores move to using MMUCSR for invalidate alls
> and tlbsx/tlbwe for invalidate virtual address.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Any reason why we have to continue doing those in asm .S files ?
mfspr/mtspr in C work fine and inline asm statements for the
tlbilx instructions proper too :-)
Cheers,
Ben.
> ---
> arch/powerpc/kernel/misc_32.S | 53 +++++++++++++++++++++++++++++++++++++++
> arch/powerpc/kernel/ppc_ksyms.c | 1 +
> include/asm-powerpc/reg_booke.h | 7 +++++
> include/asm-powerpc/tlbflush.h | 13 ++++++---
> 4 files changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
> index 6321ae3..9245b75 100644
> --- a/arch/powerpc/kernel/misc_32.S
> +++ b/arch/powerpc/kernel/misc_32.S
> @@ -274,6 +274,9 @@ _GLOBAL(real_writeb)
> /*
> * Flush MMU TLB
> */
> +#ifndef CONFIG_FSL_BOOKE
> +_GLOBAL(_tlbil_all)
> +#endif
> _GLOBAL(_tlbia)
> #if defined(CONFIG_40x)
> sync /* Flush to memory before changing mapping */
> @@ -344,6 +347,9 @@ _GLOBAL(_tlbia)
> /*
> * Flush MMU TLB for a particular address
> */
> +#ifndef CONFIG_FSL_BOOKE
> +_GLOBAL(_tlbil_va)
> +#endif
> _GLOBAL(_tlbie)
> #if defined(CONFIG_40x)
> /* We run the search with interrupts disabled because we have to change
> @@ -436,6 +442,53 @@ _GLOBAL(_tlbie)
> #endif /* ! CONFIG_40x */
> blr
>
> +#if defined(CONFIG_FSL_BOOKE)
> +/*
> + * Flush MMU TLB, but only on the local processor (no broadcast)
> + */
> +_GLOBAL(_tlbil_all)
> +#define MMUCSR0_TLBFI (MMUCSR0_TLB0FI | MMUCSR0_TLB1FI | \
> + MMUCSR0_TLB2FI | MMUCSR0_TLB3FI)
> + li r3,(MMUCSR0_TLBFI)@l
> + mtspr SPRN_MMUCSR0, r3
> +1:
> + mfspr r3,SPRN_MMUCSR0
> + andi. r3,r3,MMUCSR0_TLBFI@l
> + bne 1b
> + blr
> +
> +/*
> + * Flush MMU TLB for a particular process id, but only on the local processor
> + * (no broadcast)
> + */
> +_GLOBAL(_tlbil_pid)
> + li r3,(MMUCSR0_TLBFI)@l
> + mtspr SPRN_MMUCSR0, r3
> +1:
> + mfspr r3,SPRN_MMUCSR0
> + andi. r1,r2,MMUCSR0_TLBFI@l
> + bne 1b
> + blr
> +
> +/*
> + * Flush MMU TLB for a particular address, but only on the local processor
> + * (no broadcast)
> + */
> +_GLOBAL(_tlbil_va)
> + slwi r4,r4,16
> + mtspr SPRN_MAS6,r4 /* assume AS=0 for now */
> + tlbsx 0,r3
> + mfspr r4,SPRN_MAS1 /* check valid */
> + andis. r3,r4,MAS1_VALID@h
> + beq 1f
> + rlwinm r4,r4,0,1,31
> + mtspr SPRN_MAS1,r4
> + tlbwe
> +1:
> + blr
> +#endif /* CONFIG_FSL_BOOKE */
> +
> +
> /*
> * Flush instruction cache.
> * This is a no-op on the 601.
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index 958ecb9..b7e4ff0 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -114,6 +114,7 @@ EXPORT_SYMBOL(flush_instruction_cache);
> EXPORT_SYMBOL(flush_tlb_kernel_range);
> EXPORT_SYMBOL(flush_tlb_page);
> EXPORT_SYMBOL(_tlbie);
> +EXPORT_SYMBOL(_tlbil_va);
> #endif
> EXPORT_SYMBOL(__flush_icache_range);
> EXPORT_SYMBOL(flush_dcache_range);
> diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h
> index be980f4..6745376 100644
> --- a/include/asm-powerpc/reg_booke.h
> +++ b/include/asm-powerpc/reg_booke.h
> @@ -109,6 +109,7 @@
> #define SPRN_EVPR 0x3D6 /* Exception Vector Prefix Register */
> #define SPRN_L1CSR0 0x3F2 /* L1 Cache Control and Status Register 0 */
> #define SPRN_L1CSR1 0x3F3 /* L1 Cache Control and Status Register 1 */
> +#define SPRN_MMUCSR0 0x3F4 /* MMU Control and Status Register 0 */
> #define SPRN_PIT 0x3DB /* Programmable Interval Timer */
> #define SPRN_BUCSR 0x3F5 /* Branch Unit Control and Status */
> #define SPRN_L2CSR0 0x3F9 /* L2 Data Cache Control and Status Register 0 */
> @@ -410,6 +411,12 @@
> #define L2CSR0_L2LOA 0x00000080 /* L2 Cache Lock Overflow Allocate */
> #define L2CSR0_L2LO 0x00000020 /* L2 Cache Lock Overflow */
>
> +/* Bit definitions for MMUCSR0 */
> +#define MMUCSR0_TLB1FI 0x00000002 /* TLB1 Flash invalidate */
> +#define MMUCSR0_TLB0FI 0x00000004 /* TLB0 Flash invalidate */
> +#define MMUCSR0_TLB2FI 0x00000040 /* TLB2 Flash invalidate */
> +#define MMUCSR0_TLB3FI 0x00000020 /* TLB3 Flash invalidate */
> +
> /* Bit definitions for SGR. */
> #define SGR_NORMAL 0 /* Speculative fetching allowed. */
> #define SGR_GUARDED 1 /* Speculative fetching disallowed. */
> diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
> index 5c91081..29da561 100644
> --- a/include/asm-powerpc/tlbflush.h
> +++ b/include/asm-powerpc/tlbflush.h
> @@ -29,6 +29,9 @@
> #include <linux/mm.h>
>
> extern void _tlbie(unsigned long address, unsigned int pid);
> +extern void _tlbil_all(void);
> +extern void _tlbil_pid(unsigned int pid);
> +extern void _tlbil_va(unsigned long address, unsigned int pid);
>
> #if defined(CONFIG_40x) || defined(CONFIG_8xx)
> #define _tlbia() asm volatile ("tlbia; sync" : : : "memory")
> @@ -38,31 +41,31 @@ extern void _tlbia(void);
>
> static inline void flush_tlb_mm(struct mm_struct *mm)
> {
> - _tlbia();
> + _tlbil_all();
> }
>
> static inline void flush_tlb_page(struct vm_area_struct *vma,
> unsigned long vmaddr)
> {
> - _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
> + _tlbil_va(vmaddr, vma ? vma->vm_mm->context.id : 0);
> }
>
> static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
> unsigned long vmaddr)
> {
> - _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
> + flush_tlb_page(vma, vmaddr);
> }
>
> static inline void flush_tlb_range(struct vm_area_struct *vma,
> unsigned long start, unsigned long end)
> {
> - _tlbia();
> + _tlbil_all();
> }
>
> static inline void flush_tlb_kernel_range(unsigned long start,
> unsigned long end)
> {
> - _tlbia();
> + _tlbil_all();
> }
>
> #elif defined(CONFIG_PPC32)
^ 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