Re: AMCC ppc440spe 2.6.23.10 kernel boot help
Dear Shubhada, In message 8a71b368a89016469f72cd08050ad33402d57...@maui.asicdesigners.com you wrote: I am kind of helpless regarding the kernel version, as our customer is using it and I need to replicate their environment. I just tried 2.6.28 with katmai_defconfig file and still face the same problem. You probably did not load (and use) the device tree blob which is needed with recent (arch/powerpc based) kernel versions. The config file that I sent before is provided by the customer. It is a working configuration for them. The exact board that I have is Katmai. It looks broken to me for a Katmai board. Are you sure your customer is also using Katmai? my printenv output is as follows. This is obviously an old setup for old (arch/ppc only) kernel versions, and heavily crippl^H^H^H^H^H modified from the default environment. You might consider to restart from the default environment settings (probably even with a recent version of U-Boot - your's is too old and does not include full device tree support). On the other hand, I don;t see a reason why the old (arch/ppc based) kernel should not boot - except that it might be misconfigured for that board. Did you try any of the released (and well tested) kernel images on our FTP server? See ftp://ftp.denx.de/pub/linux/images/amcc/katmai/ Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just think of a computer as hardware you can program. - Nigel de la Tierre ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PowerPC 7447A Paging table Search
How will i confirm if PowerPC 7447A processor has or does not have a dedicated hardware for page table search algorithm? If it does not have, then which interrupt handler is written for page address translation mechanism? -Sumedh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[MPC8272ADS]Problem adding flash partitions inside the device tree
Hi everybody !
I am currently trying to add the support of partitions for the Flash chip on
my MPC8272ADS board (the chips are Sharp LH28F016SCT-L90).
I have added this part:
fl...@0,0 {
compatible = jedec-flash;
reg = 0x0 0x0 0x200;
bank-width = 4;
device-width = 1;
partit...@ff80 {
label = kernel;
reg = 0xff80 0x0040;
read-only;
};
partit...@ffc0 {
label = user;
reg = 0xffc0 0x0030;
};
partit...@fff0 {
label = u-boot;
reg = 0xfff0 0x0010;
read-only;
};
};
But when I am compiling, I have these warnings:
Warning (reg_format): reg property in /local...@f0010100/fl...@0
,0/partit...@ff80 has invalid length (8 bytes) (#address-cells == 2,
#size-cells == 1)
Warning (reg_format): reg property in /local...@f0010100/fl...@0
,0/partit...@ffc0 has invalid length (8 bytes) (#address-cells == 2,
#size-cells == 1)
Warning (reg_format): reg property in /local...@f0010100/fl...@0
,0/partit...@fff0 has invalid length (8 bytes) (#address-cells == 2,
#size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /local...@f0010100/fl...@0,0/partit...@ff80
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/local...@f0010100/fl...@0,0/partit...@ff80
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /local...@f0010100/fl...@0,0/partit...@ffc0
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/local...@f0010100/fl...@0,0/partit...@ffc0
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /local...@f0010100/fl...@0,0/partit...@fff0
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/local...@f0010100/fl...@0,0/partit...@fff0
Can anyone help me ?
I can't understand what the address-cells is.
Thanks in advance !
Best Regards.
JM
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: request_irq return errno 38
Thanks for your replies ... I checked the irq.c and irq.h and found the prototype of irq_of_parse_and_map() and found from the comment that it is a wrapper function contains a chain of irq_map_one() and irq_create_mapping() ... It means that I can use irq_create_mapping() to know the virq also the same suggessted by michael ... what is the difference between these two i.e. irq_create_mapping() and irq_of_parse_and_map() ... I mean in usage what could be the difference ? ? ? If used the irq_of_parse_and_map() then the paraments I need to pass are device_node *dev and index irq_of_parse_and_map(struct device_node *dev, int index) ... then how I can pass the required information i.e. dev and index ? ? ? Also how I can read the device tree binary file ? ? ? Kindly please acknowledge ... thank you ... Kind Regards, Vijay Nikam On 2/12/09, Brad Boyer f...@allandria.com wrote: On Wed, Feb 11, 2009 at 03:43:26PM +0530, Vijay Nikam wrote: I read in LDD book, they give directly irq no. they have given parallel port example, here they have set or said irq no. defaults to 7 and they have not done any irq_mapping so what is the difference ? ? ? I mean how I should know when to use irq_mapping and when not ? ? ? Also is it some difference between writng drivers on embedded Linux level and Linux PC (i386) ? ? ? The basic request_irq() function is generic, but the value of the arguments (especially the number for the IRQ line) is architecture specific in many ways. This is one difference between the i386 code and the powerpc code inside Linux. Most i386 hardware is standard PC hardware with very clearly defined interrupt sources. Because of this, the mapping from the numeric IRQ value to a real hardware interrupt source is defined pretty clearly. The powerpc architecture code has to support almost arbitrarily complex hardware, and the embedded world is the source of most of the complexity. Because of this, the powerpc code has to dynamically allocate those numeric IRQ sources and tie them to a specific hardware interrupt. There is functionality to take the information from your device tree and convert it to a virtual IRQ. That happens automatically for some types of devices like PCI cards, but your driver may have to do that mapping itself in other cases. I believe the appropriate API for this is the function irq_of_parse_and_map(). It takes a device node and index into the interrupt list for that device and gives a virtual IRQ number. Brad Boyer f...@allandria.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
Jean-Michel Hautbois wrote:
Hi everybody !
I am currently trying to add the support of partitions for the Flash
chip on my MPC8272ADS board (the chips are Sharp LH28F016SCT-L90).
I have added this part:
fl...@0,0 {
compatible = jedec-flash;
reg = 0x0 0x0 0x200;
bank-width = 4;
device-width = 1;
partit...@ff80 {
label = kernel;
reg = 0xff80 0x0040;
read-only;
};
partit...@ffc0 {
label = user;
reg = 0xffc0 0x0030;
};
partit...@fff0 {
label = u-boot;
reg = 0xfff0 0x0010;
read-only;
};
};
But when I am compiling, I have these warnings:
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@ff80 has invalid length (8
bytes) (#address-cells == 2, #size-cells == 1)
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@ffc0 has invalid length (8
bytes) (#address-cells == 2, #size-cells == 1)
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@fff0 has invalid length (8
bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells
value for /local...@f0010100/fl...@0,0/partit...@ff80
Warning (avoid_default_addr_size): Relying on default #size-cells
value for /local...@f0010100/fl...@0,0/partit...@ff80
Warning (avoid_default_addr_size): Relying on default #address-cells
value for /local...@f0010100/fl...@0,0/partit...@ffc0
Warning (avoid_default_addr_size): Relying on default #size-cells
value for /local...@f0010100/fl...@0,0/partit...@ffc0
Warning (avoid_default_addr_size): Relying on default #address-cells
value for /local...@f0010100/fl...@0,0/partit...@fff0
Warning (avoid_default_addr_size): Relying on default #size-cells
value for /local...@f0010100/fl...@0,0/partit...@fff0
Can anyone help me ?
I can't understand what the address-cells is.
Thanks in advance !
Best Regards.
JM
You are missing some definitions, The #address-cells and #size-cells = 1;
tis is a snippet of teh dts i defined for my board.
fl...@0,0 {
#address-cells = 1;
#size-cells = 1;
compatible = cfi-flash;
reg = 0x0 0x0 0x0800;
bank-width = 4;
device-width = 1;
/* set flash partition to correspond tu mtd parts in
u-boot*/
/* 0xf800 */
partit...@0x0 {
label = factory-image;
reg = 0x 0x0100;
};
/* 0xf900 */
partit...@0x0100 {
label = app-image-1;
reg = 0x0100 0x0100;
};
cheers pieter
smime.p7s
Description: S/MIME Cryptographic Signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
2009/2/12 Pieter phenn...@vastech.co.za
Jean-Michel Hautbois wrote:
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@ff80 has invalid length (8
JM
You are missing some definitions, The #address-cells and #size-cells = 1;
tis is a snippet of teh dts i defined for my board.
fl...@0,0 {
#address-cells = 1;
#size-cells = 1;
compatible = cfi-flash;
reg = 0x0 0x0 0x0800;
bank-width = 4;
device-width = 1;
/* set flash partition to correspond tu mtd parts in
u-boot*/
/* 0xf800 */
partit...@0x0 {
label = factory-image;
reg = 0x 0x0100;
};
/* 0xf900 */
partit...@0x0100 {
label = app-image-1;
reg = 0x0100 0x0100;
};
cheers pieter
Hi do have these definitions, at a higher level:
local...@f0010100 {
compatible = fsl,mpc8272-localbus,
fsl,pq2-localbus;
#address-cells = 2;
#size-cells = 1;
reg = 0xf0010100 0x40;
ranges = 0x0 0x0 0xfe00 0x200
0x1 0x0 0xf450 0x8000
0x3 0x0 0xf820 0x8000;
fl...@0,0 {
etc.
Regards,
JM
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: next Feb 10: mm/slqb build break
Nick Piggin wrote: Actually, that's not the root cause here. You seem to have CONFIG_SMP disabled but CONFIG_NUMA enabled. That's not possible on x86 which makes me think it's a ppc kconfig bug. Hmm? If it is really a valid config, then we should be able to make slqb build with it... I am not sure if this is a valid config. According to arch/powerpc/Kconfig NUMA depends on PPC64 and defaults to y if SMP PPC_PSERIES is set. If this is not a valid config then may be the make randconfig rules need to be changed accordingly. Ben should know. Ben ?? Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 002/002] de2104x: support for systems lacking cache coherence
Here is a patch that helped me to get my de2104x NIC working on my PowerMac 5500. As an interesting side effect, it also made my mesh module crash. Background can be found here: http://www.spinics.net/lists/netdev/msg88488.html Risto Allow setting NOT_COHERENT_CACHE explicitly. Signed-off-by: Risto Suominen risto.suomi...@gmail.com --- The testing is done on kernel version 2.6.24. --- a/arch/powerpc/platforms/powermac/Kconfig.org 2008-01-25 00:58:37.0 +0200 +++ b/arch/powerpc/platforms/powermac/Kconfig 2009-02-10 17:44:24.0 +0200 @@ -18,4 +18,10 @@ config PPC_PMAC64 select PPC_970_NAP default y - +config NOT_COHERENT_CACHE + bool Incoherent cache + default n + help + Setting this option may be necessary for avoiding cache-related + problems with some network cards on some platforms. An example is + 2104x and PowerMac 5500. Allow setting NOT_COHERENT_CACHE explicitly. Signed-off-by: Risto Suominen risto.suomi...@gmail.com --- The testing is done on kernel version 2.6.24. --- a/arch/powerpc/platforms/powermac/Kconfig.org 2008-01-25 00:58:37.0 +0200 +++ b/arch/powerpc/platforms/powermac/Kconfig 2009-02-10 17:44:24.0 +0200 @@ -18,4 +18,10 @@ config PPC_PMAC64 select PPC_970_NAP default y - +config NOT_COHERENT_CACHE + bool Incoherent cache + default n + help + Setting this option may be necessary for avoiding cache-related + problems with some network cards on some platforms. An example is + 2104x and PowerMac 5500. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
SPI-Difference between MX1 and MX31
Hello, while working on a generic SPI-driver for the i.MX-platform I stumbled over the following: The MX1 can flush its FIFOs using the enable bit. Documentation says: SPI Module Enable - Enables/Disables the serial peripheral interface. SPIEN must be asserted before an exchange is initiated. Writing 0 to SPIEN flushes the receive and transmit FIFOs. Furthermore it has a dedicated reset register: Start - Executes soft reset. However, the MX31 does not have a reset register and the documentation says this regarding the enable bit: SPI Module Enable Control - This bit enables the CSPI. This bit must be asserted before writing to other registers or initiating an exchange. Writing zero to this bit disables the module and resets the internal logic with the exception of the CONREG. The module’s internal clocks are gated off whenever the module is disabled. So, as I read all this, disabling the enable bit on the MX31 is more like a soft reset on MX1, right? And there does not seem to be a way to flush the FIFOs. Can someone imagine what problems might arise if there is no way to flush the FIFOs? At least, the check for XCH should have ensured that the TXFIFO is empty... Looking forward to feedback :) Regards, Wolfram Sang -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
2009/2/12 Pieter phenn...@vastech.co.za
Jean-Michel Hautbois wrote:
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@ff80 has invalid length (8
JM
You are missing some definitions, The #address-cells and #size-cells = 1;
tis is a snippet of teh dts i defined for my board.
fl...@0,0 {
#address-cells = 1;
#size-cells = 1;
compatible = cfi-flash;
reg = 0x0 0x0 0x0800;
bank-width = 4;
device-width = 1;
/* set flash partition to correspond tu mtd parts in
u-boot*/
/* 0xf800 */
partit...@0x0 {
label = factory-image;
reg = 0x 0x0100;
};
/* 0xf900 */
partit...@0x0100 {
label = app-image-1;
reg = 0x0100 0x0100;
};
cheers pieter
Hi do have these definitions, at a higher level:
The address-cells and size-cells definitions are not inherited. They
cover only the immediate children of the node where they appear.
Otherwise the default values apply (address-cells == 2, size-cells ==
1), which are not right for your case.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
2009/2/12 David Gibson da...@gibson.dropbear.id.au
On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
2009/2/12 Pieter phenn...@vastech.co.za
Jean-Michel Hautbois wrote:
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@ff80 has invalid length
(8
JM
You are missing some definitions, The #address-cells and #size-cells =
1;
tis is a snippet of teh dts i defined for my board.
fl...@0,0 {
#address-cells = 1;
#size-cells = 1;
compatible = cfi-flash;
reg = 0x0 0x0 0x0800;
bank-width = 4;
device-width = 1;
/* set flash partition to correspond tu mtd parts in
u-boot*/
/* 0xf800 */
partit...@0x0 {
label = factory-image;
reg = 0x 0x0100;
};
/* 0xf900 */
partit...@0x0100 {
label = app-image-1;
reg = 0x0100 0x0100;
};
cheers pieter
Hi do have these definitions, at a higher level:
The address-cells and size-cells definitions are not inherited. They
cover only the immediate children of the node where they appear.
Otherwise the default values apply (address-cells == 2, size-cells ==
1), which are not right for your case.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_
_other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson http://www.ozlabs.org/%7Edgibson
OK, so, after having tested, I can't see any changes when booting.
I do not have more mtd in /proc/mtd.
JM
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
2009/2/12 Pieter phenn...@vastech.co.za
Jean-Michel Hautbois wrote:
2009/2/12 David Gibson da...@gibson.dropbear.id.au
mailto:da...@gibson.dropbear.id.au
On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
2009/2/12 Pieter phenn...@vastech.co.za
mailto:phenn...@vastech.co.za
Jean-Michel Hautbois wrote:
Warning (reg_format): reg property in
/local...@f0010100/fl...@0,0/partit...@ff80 has invalid
length (8
JM
You are missing some definitions, The #address-cells and
#size-cells = 1;
tis is a snippet of teh dts i defined for my board.
fl...@0,0 {
#address-cells = 1;
#size-cells = 1;
compatible = cfi-flash;
reg = 0x0 0x0 0x0800;
bank-width = 4;
device-width = 1;
/* set flash partition to correspond tu mtd parts in
u-boot*/
/* 0xf800 */
partit...@0x0 {
label = factory-image;
reg = 0x 0x0100;
};
/* 0xf900 */
partit...@0x0100 {
label = app-image-1;
reg = 0x0100 0x0100;
};
cheers pieter
Hi do have these definitions, at a higher level:
The address-cells and size-cells definitions are not inherited. They
cover only the immediate children of the node where they appear.
Otherwise the default values apply (address-cells == 2, size-cells ==
1), which are not right for your case.
--
David Gibson| I'll have my music baroque, and
my code
david AT gibson.dropbear.id.au http://gibson.dropbear.id.au |
minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson http://www.ozlabs.org/%7Edgibson
http://www.ozlabs.org/%7Edgibson
OK, so, after having tested, I can't see any changes when booting.
I do not have more mtd in /proc/mtd.
JM
have you defined the following in your kernel config
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_OF_PARTS=y
cheers pieter
I didn't have CONFIG_MTD_OF_PARTS=y.
Know, I have this output:
Found: Intel I28F016S3
fe00.flash: Found 4 x8 devices at 0x0 in 32-bit bank
fe00.flash: Found an alias at 0x80 for the chip at 0x0
fe00.flash: Found an alias at 0x100 for the chip at 0x0
fe00.flash: Found an alias at 0x180 for the chip at 0x0
erase region 0: offset=0x0,size=0x4,blocks=32
RedBoot partition parsing not available
Creating 3 MTD partitions on fe00.flash:
0xff80-0xffc0 : kernel
mtd: partition kernel is out of reach -- disabled
mtd: Giving out device 0 to kernel
0xffc0-0xfff0 : user
mtd: partition sofrel is out of reach -- disabled
mtd: Giving out device 1 to user
0xfff0-0x0001 : u-boot
mtd: partition u-boot is out of reach -- disabled
mtd: Giving out device 2 to u-boot
I think that the problem is in the reg part, but I can't understand why.
Isn't it the RAM mpping of my MTD that is the first address ?
Thanks agains,
Regards,
JM
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Only disable/enable LSI interrupts in EEH
Michael Ellerman wrote: On Tue, 2009-02-10 at 13:12 -0800, Mike Mason wrote: I'm resubmitting this patch with a couple changes suggested by Michael Ellerman. 1) the new functions should be static, and 2) some people may object to including unrelated formating changes. = The EEH code disables and enables interrupts during the device recovery process. This is unnecessary for MSI and MSI-X interrupts because they are effectively disabled by the DMA Stopped state when an EEH error occurs. The current code is also incorrect for MSI-X interrupts. It doesn't take into account that MSI-X interrupts are tracked in a different way than LSI/MSI interrupts. This patch ensures only LSI interrupts are disabled/enabled. Signed-off-by: Mike Mason mm...@us.ibm.com Acked-by: Linas Vepstas linasveps...@gmail.com Looks good. Assuming you've tested it :) Yes, it's been tested with network devices that use LSI, MSI and MSI-X interrupts. All recovered fine. Acked-by: Michael Ellerman mich...@ellerman.id.au ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Thu, 12 Feb 2009, Frederic Weisbecker wrote: On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote: The following set of patches are RFC and not for inclusion (unless everyone is fine with them as is). This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. 1) get generic code ready for other archs 2) get PowerPC 64-bit working with just static function tracing 3) get PowerPC 64-bit working with dynamic function tracing 4) get PowerPC 32-bit working with just static function tracing 5) get PowerPC 32-bit working with dynamic function tracing (with some clean ups in between) Thanks a lot Steven! I'm sad to not having a Power Pc to test it... BTW, Can I count that as an Acked-by: for the first patch. Since the first patch does modify your code. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Wed, 11 Feb 2009, Steven Rostedt wrote: The following set of patches are RFC and not for inclusion (unless everyone is fine with them as is). This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. 1) get generic code ready for other archs 2) get PowerPC 64-bit working with just static function tracing 3) get PowerPC 64-bit working with dynamic function tracing 4) get PowerPC 32-bit working with just static function tracing 5) get PowerPC 32-bit working with dynamic function tracing (with some clean ups in between) Ben, if you get some time (no rush really), can you give an acked-by on each of the PPC patches. The first patch is ftrace generic, so you can ignore that one. I'll keep it in the RFC state, until I have an ack from either you or Paul. I'm not sure if these changes should go via you or Ingo. I'm thinking that, since the first change modifies core ftrace code, I'll send it towards tip, since all the rest depends on that first change. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Thu, Feb 12, 2009 at 11:31:44AM -0500, Steven Rostedt wrote: On Thu, 12 Feb 2009, Frederic Weisbecker wrote: On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote: The following set of patches are RFC and not for inclusion (unless everyone is fine with them as is). This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. 1) get generic code ready for other archs 2) get PowerPC 64-bit working with just static function tracing 3) get PowerPC 64-bit working with dynamic function tracing 4) get PowerPC 32-bit working with just static function tracing 5) get PowerPC 32-bit working with dynamic function tracing (with some clean ups in between) Thanks a lot Steven! I'm sad to not having a Power Pc to test it... BTW, Can I count that as an Acked-by: for the first patch. Since the first patch does modify your code. -- Steve Yes of course, I knew most of it was architecture independant but I delayed this TODO for future ports, and you've done it. Thanks. Just a micro detail: the ftrace_push/pop_return_trace are parts of the core of the entry/return probe, something that could be used by other users than the function graph tracer itself. Perhaps it would be better to put them in kernel/trace/ftrace.c What do you think? Anyway, Acked-by: Frederic Weisbecker fweis...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: request_irq return errno 38
On Thu, Feb 12, 2009 at 4:51 AM, Vijay Nikam vijay.t.ni...@gmail.com wrote: Also how I can read the device tree binary file ? ? ? It would be a lot simpler if you just read the documentation (see booting-without-of.txt) and looked at other device drivers to see what they do. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Thu, 12 Feb 2009, Frederic Weisbecker wrote: Yes of course, I knew most of it was architecture independant but I delayed this TODO for future ports, and you've done it. Thanks. Just a micro detail: the ftrace_push/pop_return_trace are parts of the core of the entry/return probe, something that could be used by other users than the function graph tracer itself. Perhaps it would be better to put them in kernel/trace/ftrace.c What do you think? I'll go with your above method. We'll move it when it comes to that ;-) Anyway, Acked-by: Frederic Weisbecker fweis...@gmail.com Thanks! I'll update my repo. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PS3 ps3av_set_video_mode() make id signed
Roel Kluin wrote: Make id signed so a negative id will get noticed. Error out if ps3av_auto_videomode() fails. Signed-off-by: Roel Kluin roel.kl...@gmail.com --- arch/powerpc/include/asm/ps3av.h |2 +- drivers/ps3/ps3av.c | 16 2 files changed, 13 insertions(+), 5 deletions(-) Just FYI, I added this to ps3-linux.git, since it is not a critical fix, I will submit for 2.6.30. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
Hi Ben,
excuse me for so long time to reply.
Benjamin Herrenschmidt wrote:
This patch rewrites consistent dma allocations support to use vmalloc
layer to allocate virtual memory space from vmalloc pool and get rid
of CONFIG_CONSISTENT_{START,SIZE}.
So as commented before, please drop the defconfig updates.
Ok.
-/*
* Allocate DMA-coherent memory space and return both the kernel remapped
* virtual and bus address for that space.
*/
@@ -151,19 +41,17 @@ void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
{
struct page *page;
-struct vm_region *c;
unsigned long order;
+void *v;
+int i;
+struct page *pages[PAGE_ALIGN(size)PAGE_SHIFT];
I'm not -too- fan of that page list one the stack up there.
I understand why you don't wantto kmalloc something here etc... but
that's what __vmalloc_area() does and it's somewhat useful to keep track
of the page array that way, it might prove handy in the future.
I don't like array being on stack too... But I fear I didn't understand
what were you talking about here...
__vmalloc_area does kmalloc or vmalloc to allocate pages array and then
allocates pages one by one but we need physically contiguous pages
here... (And that is why we don't really need to store pages array)
So I just added kmalloc/vmalloc to allocate the pages array and stored
it in vm_struct structure.
Might even be worth adding a generic patch to add a VM_COHERENT_DMA flag
so they can be listed as such and make sure you set the caller field
yourself with your own caller.
I used __builtin_return_address(1) as the 'caller' so I get useful
output in /proc/vmallocinfo (btw, ioremap doesn't provide useful 'caller').
Do you think we have high chances of such a patch being accepted in
lkml? Well, I'll try to do this (for now I stick with VM_IOREMAP).
(Hint: look at the output of /proc/vmallocinfo)
Also, the mucking around with PG_Reserved shouldn't be of any use
anymore.
Ok, removed.
Please review the updated patch (I'll post it as a followup).
Regards, Ilya.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote: The Power ISA 2.06 added power of two page sizes to the embedded MMU architecture. Its done it such a way to be code compatiable with the existing HW. Made the minor code changes to support both power of two and power of four page sizes. Also added some new MAS bits and macros that are defined as part of the 2.06 ISA. Note, its still invalid to try and use a page size that isn't supported by cpu. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixed MAS6_ISIZE macro arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++ +-- Do you want to rename asm/mmu-fsl-booke.h = mmu-booke.h (per ISA 2.06 changes)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: AMCC ppc440spe 2.6.23.10 kernel boot help
Hi Wolfgang I could get 2.6.28 version up and running after using device tree blob. Also our customer is using Luan and our IT dept ordered Katmai. So looks like the problem is solved for now (basically my company needs to look into alternative setups) Thanks a lot for your prompt help. Shubhada -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, February 12, 2009 12:07 AM To: Shubhada Pugaonkar Cc: linuxppc-dev@ozlabs.org Subject: Re: AMCC ppc440spe 2.6.23.10 kernel boot help Dear Shubhada, In message 8a71b368a89016469f72cd08050ad33402d57...@maui.asicdesigners.com you wrote: I am kind of helpless regarding the kernel version, as our customer is using it and I need to replicate their environment. I just tried 2.6.28 with katmai_defconfig file and still face the same problem. You probably did not load (and use) the device tree blob which is needed with recent (arch/powerpc based) kernel versions. The config file that I sent before is provided by the customer. It is a working configuration for them. The exact board that I have is Katmai. It looks broken to me for a Katmai board. Are you sure your customer is also using Katmai? my printenv output is as follows. This is obviously an old setup for old (arch/ppc only) kernel versions, and heavily crippl^H^H^H^H^H modified from the default environment. You might consider to restart from the default environment settings (probably even with a recent version of U-Boot - your's is too old and does not include full device tree support). On the other hand, I don;t see a reason why the old (arch/ppc based) kernel should not boot - except that it might be misconfigured for that board. Did you try any of the released (and well tested) kernel images on our FTP server? See ftp://ftp.denx.de/pub/linux/images/amcc/katmai/ Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just think of a computer as hardware you can program. - Nigel de la Tierre ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: rework dma-noncoherent to use generic vmalloc layer (2nd rev)
This patch rewrites consistent dma allocations support to use vmalloc
layer to allocate virtual memory space from vmalloc pool and get rid
of CONFIG_CONSISTENT_{START,SIZE}.
I still use VM_IOREMAP flag for these allocations (I'll try to post
patch adding separate VM_COHERENT_DMA flag to lkml later).
Now I save pages array in vm_struct pages field and use
__builtin_return_address(1) as 'caller' argument to get usefull info
in /proc/vmallocinfo:
-bash-3.2# cat /proc/vmallocinfo
0xe100-0xe10020008192 __ioremap+0x184/0x194 ioremap
[...]
0xe1f9-0xe1f96000 24576 PrimeIocFifos+0x3a8/0x550 pages=5 ioremap
0xe1fa-0xe1fb1000 69632 __ioremap+0x184/0x194 ioremap
0xe1fc-0xe1fd1000 69632 __ioremap+0x184/0x194 ioremap
0xe200-0xe2f01000 15732736 __ioremap+0x184/0x194 ioremap
0xe2f32000-0xe2f340008192 __ioremap+0x184/0x194 ioremap
0xe2f38000-0xe2f3d000 20480 __ioremap+0x184/0x194 ioremap
0xe2f4-0xe2f46000 24576 PrimeIocFifos+0x3a8/0x550 pages=5 ioremap
0xe2f8-0xe3e81000 15732736 __ioremap+0x184/0x194 ioremap
0xe3f0-0xe3f48000 294912 PrimeIocFifos+0x204/0x550 pages=71 ioremap
0xe3f8-0xe3fc8000 294912 PrimeIocFifos+0x204/0x550 pages=71 ioremap
0xe3fe-0xe3fe6000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe3fe8000-0xe3fee000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe3fef000-0xe3ff8000 36864 bdx_open+0x10c/0x60c pages=8 vmalloc
0xe400-0xe4006000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe4007000-0xe400f000 32768 bdx_open+0x1f0/0x60c pages=7 vmalloc
0xe401-0xe401a000 40960 bdx_fifo_init+0x8c/0x12c pages=9 ioremap
(those ioremaps with pages=)
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
arch/powerpc/Kconfig | 25 ---
arch/powerpc/lib/dma-noncoherent.c | 299 +++-
2 files changed, 53 insertions(+), 271 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 74cc312..ecae53f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -815,31 +815,6 @@ config TASK_SIZE
default 0x8000 if PPC_PREP || PPC_8xx
default 0xc000
-config CONSISTENT_START_BOOL
- bool Set custom consistent memory pool address
- depends on ADVANCED_OPTIONS NOT_COHERENT_CACHE
- help
- This option allows you to set the base virtual address
- of the consistent memory pool. This pool of virtual
- memory is used to make consistent memory allocations.
-
-config CONSISTENT_START
- hex Base virtual address of consistent memory pool if
CONSISTENT_START_BOOL
- default 0xfd00 if (NOT_COHERENT_CACHE 8xx)
- default 0xff10 if NOT_COHERENT_CACHE
-
-config CONSISTENT_SIZE_BOOL
- bool Set custom consistent memory pool size
- depends on ADVANCED_OPTIONS NOT_COHERENT_CACHE
- help
- This option allows you to set the size of the
- consistent memory pool. This pool of virtual memory
- is used to make consistent memory allocations.
-
-config CONSISTENT_SIZE
- hex Size of consistent memory pool if CONSISTENT_SIZE_BOOL
- default 0x0020 if NOT_COHERENT_CACHE
-
config PIN_TLB
bool Pinned Kernel TLBs (860 ONLY)
depends on ADVANCED_OPTIONS 8xx
diff --git a/arch/powerpc/lib/dma-noncoherent.c
b/arch/powerpc/lib/dma-noncoherent.c
index b7dc4c1..2e321a9 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -29,121 +29,11 @@
#include linux/types.h
#include linux/highmem.h
#include linux/dma-mapping.h
+#include linux/vmalloc.h
#include asm/tlbflush.h
/*
- * This address range defaults to a value that is safe for all
- * platforms which currently set CONFIG_NOT_COHERENT_CACHE. It
- * can be further configured for specific applications under
- * the Advanced Setup menu. -Matt
- */
-#define CONSISTENT_BASE(CONFIG_CONSISTENT_START)
-#define CONSISTENT_END (CONFIG_CONSISTENT_START + CONFIG_CONSISTENT_SIZE)
-#define CONSISTENT_OFFSET(x) (((unsigned long)(x) - CONSISTENT_BASE)
PAGE_SHIFT)
-
-/*
- * This is the page table (2MB) covering uncached, DMA consistent allocations
- */
-static pte_t *consistent_pte;
-static DEFINE_SPINLOCK(consistent_lock);
-
-/*
- * VM region handling support.
- *
- * This should become something generic, handling VM region allocations for
- * vmalloc and similar (ioremap, module space, etc).
- *
- * I envisage vmalloc()'s supporting vm_struct becoming:
- *
- * struct vm_struct {
- *struct vm_region region;
- *unsigned longflags;
- *struct page **pages;
- *unsigned int nr_pages;
- *unsigned longphys_addr;
- * };
- *
- * get_vm_area() would then call vm_region_alloc with an appropriate
- * struct vm_region head (eg):
- *
- * struct vm_region vmalloc_head = {
- * .vm_list= LIST_HEAD_INIT(vmalloc_head.vm_list),
- * .vm_start = VMALLOC_START,
- * .vm_end = VMALLOC_END,
- * };
- *
- * However,
Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
On Thu, Feb 12, 2009 at 01:21:24PM -0600, Kumar Gala wrote: On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote: The Power ISA 2.06 added power of two page sizes to the embedded MMU architecture. Its done it such a way to be code compatiable with the existing HW. Made the minor code changes to support both power of two and power of four page sizes. Also added some new MAS bits and macros that are defined as part of the 2.06 ISA. Note, its still invalid to try and use a page size that isn't supported by cpu. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixed MAS6_ISIZE macro arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++ +-- Do you want to rename asm/mmu-fsl-booke.h = mmu-booke.h (per ISA 2.06 changes)? Misleading perhaps. ISA 2.06 is really new and we've been calling 4xx and FSL booke for a while now. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
btw, ioremap doesn't provide useful 'caller'). I fixed that :-) (see patches I posted to the list, though that's waiting for a patch to go upstream first that adds a __get_vm_area_caller() that I need for ppc64). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
On Thu, 2009-02-12 at 13:21 -0600, Kumar Gala wrote: On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote: The Power ISA 2.06 added power of two page sizes to the embedded MMU architecture. Its done it such a way to be code compatiable with the existing HW. Made the minor code changes to support both power of two and power of four page sizes. Also added some new MAS bits and macros that are defined as part of the 2.06 ISA. Note, its still invalid to try and use a page size that isn't supported by cpu. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixed MAS6_ISIZE macro arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++ +-- Do you want to rename asm/mmu-fsl-booke.h = mmu-booke.h (per ISA 2.06 changes)? I've actually been wondering about that indeed ... No objection if you want to move forward with that ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
Hi Ben, Benjamin Herrenschmidt wrote: btw, ioremap doesn't provide useful 'caller'). I fixed that :-) (see patches I posted to the list, though that's waiting for a patch to go upstream first that adds a __get_vm_area_caller() that I need for ppc64). Yep, I saw them. Btw, I've posted update consistent memory patch in a new thread please take a look. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: writel hangs system
On Tue, Feb 10, 2009 at 6:07 AM, Tobias Knutsson tobias.knuts...@gmail.com wrote: Hello, I'm in the process of porting a PCI-driver for a dsp-board from 2.4 to 2.6. The probing of the driver goes well, IRQs are setup, resources are claimed and remapped without any problems. Reading from I/O regions also works well. However, when i try to read or write to a memory region using readl/writel, the system instantly hangs. No stacktrace or anything, it just stops. Hmmm. Not good. Are you able to access the memory regions from the U-Boot console? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
On Feb 12, 2009, at 2:34 PM, Josh Boyer wrote: On Thu, Feb 12, 2009 at 01:21:24PM -0600, Kumar Gala wrote: On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote: The Power ISA 2.06 added power of two page sizes to the embedded MMU architecture. Its done it such a way to be code compatiable with the existing HW. Made the minor code changes to support both power of two and power of four page sizes. Also added some new MAS bits and macros that are defined as part of the 2.06 ISA. Note, its still invalid to try and use a page size that isn't supported by cpu. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixed MAS6_ISIZE macro arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++ +-- Do you want to rename asm/mmu-fsl-booke.h = mmu-booke.h (per ISA 2.06 changes)? Misleading perhaps. ISA 2.06 is really new and we've been calling 4xx and FSL booke for a while now. I can call it mmu-book3e.h if you think that might enough different to convey the ISA 2.06 fact that the FSL style MMU is now part of the 3e architecture. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
I can call it mmu-book3e.h if you think that might enough different to convey the ISA 2.06 fact that the FSL style MMU is now part of the 3e architecture. That's better. book3e is what I've been using internally... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
On Thu, Feb 12, 2009 at 03:26:58PM +0100, Jean-Michel Hautbois wrote: I think that the problem is in the reg part, but I can't understand why. Isn't it the RAM mpping of my MTD that is the first address ? No, it's the offset into the chipselect. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] powerpc/ps3: Move ps3_mm_add_memory to device_initcall
Change the PS3 hotplug memory routine ps3_mm_add_memory() from a core_initcall to a device_initcall. core_initcall routines run before the powerpc topology_init() startup routine, which is a subsys_initcall, resulting in failure of ps3_mm_add_memory() when CONFIG_NUMA=y. When ps3_mm_add_memory() fails the system will boot with just the 128 MiB of boot memory Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com --- Ben, Please send upstream for 2.6.29, as this effects the current Fedora 11 development kernel, and maybe other distros which are based on 2.6.29. arch/powerpc/platforms/ps3/mm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/platforms/ps3/mm.c +++ b/arch/powerpc/platforms/ps3/mm.c @@ -328,7 +328,7 @@ static int __init ps3_mm_add_memory(void return result; } -core_initcall(ps3_mm_add_memory); +device_initcall(ps3_mm_add_memory); /**/ /* dma routines */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] powerpc: fix numa reserve bootmem page selection
From: Dave Hansen d...@linux.vnet.ibm.com Fix the powerpc NUMA reserve bootmem page selection logic. commit 8f64e1f2d1e09267ac926e15090fd505c1c0cbcb (powerpc: Reserve in bootmem lmb reserved regions that cross NUMA nodes) changed the logic for how the powerpc LMB reserved regions were converted to bootmen reserved regions. As the folowing discussion reports, the new logic was not correct. mark_reserved_regions_for_nid() goes through each LMB on the system that specifies a reserved area. It searches for active regions that intersect with that LMB and are on the specified node. It attempts to bootmem-reserve only the area where the active region and the reserved LMB intersect. We can not reserve things on other nodes as they may not have bootmem structures allocated, yet. We base the size of the bootmem reservation on two possible things. Normally, we just make the reservation start and stop exactly at the start and end of the LMB. However, the LMB reservations are not aware of NUMA nodes and on occasion a single LMB may cross into several adjacent active regions. Those may even be on different NUMA nodes and will require separate calls to the bootmem reserve functions. So, the bootmem reservation must be trimmed to fit inside the current active region. That's all fine and dandy, but we trim the reservation in a page-aligned fashion. That's bad because we start the reservation at a non-page-aligned address: physbase. The reservation may only span 2 bytes, but that those bytes may span two pfns and cause a reserve_size of 2*PAGE_SIZE. Take the case where you reserve 0x2 bytes at 0x0fff and where the active region ends at 0x1000. You'll jump into that if() statment, but node_ar.end_pfn=0x1 and start_pfn=0x0. You'll end up with a reserve_size=0x1000, and then call reserve_bootmem_node(node, physbase=0xfff, size=0x1000); 0x1000 may not be on the same node as 0xfff. Oops. In almost all the vm code, end_anything is not inclusive. If you have an end_pfn of 0x1234, page 0x1234 is not included in the range. Using PFN_UP instead of the ( PAGE_SHIFT) will make this consistent with the other VM code. We also need to do math for the reserved size with physbase instead of start_pfn. node_ar.end_pfn PAGE_SHIFT is *precisely* the end of the node. However, (start_pfn PAGE_SHIFT) is *NOT* precisely the beginning of the reserved area. That is, of course, physbase. If we don't use physbase here, the reserve_size can be made too large. From: Dave Hansen d...@linux.vnet.ibm.com Tested-by: Geoff Levand geoffrey.lev...@am.sony.com Tested on PS3. --- linux-2.6.git-dave/arch/powerpc/mm/numa.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff -puN arch/powerpc/mm/numa.c~reserve-over-fix arch/powerpc/mm/numa.c --- a/arch/powerpc/mm/numa.c~reserve-over-fix +++ b/arch/powerpc/mm/numa.c @@ -19,6 +19,7 @@ #include linux/notifier.h #include linux/lmb.h #include linux/of.h +#include linux/pfn.h #include asm/sparsemem.h #include asm/prom.h #include asm/system.h @@ -882,7 +883,7 @@ static void mark_reserved_regions_for_ni unsigned long physbase = lmb.reserved.region[i].base; unsigned long size = lmb.reserved.region[i].size; unsigned long start_pfn = physbase PAGE_SHIFT; - unsigned long end_pfn = ((physbase + size) PAGE_SHIFT); + unsigned long end_pfn = PFN_UP(physbase + size); struct node_active_region node_ar; unsigned long node_end_pfn = node-node_start_pfn + node-node_spanned_pages; @@ -908,7 +909,7 @@ static void mark_reserved_regions_for_ni */ if (end_pfn node_ar.end_pfn) reserve_size = (node_ar.end_pfn PAGE_SHIFT) - - (start_pfn PAGE_SHIFT); + - physbase; /* * Only worry about *this* node, others may not * yet have valid NODE_DATA(). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
The Power ISA 2.06 added power of two page sizes to the embedded MMU
architecture. Its done it such a way to be code compatiable with the
existing HW. Made the minor code changes to support both power of two
and power of four page sizes. Also added some new MAS bits and macros
that are defined as part of the 2.06 ISA. Renamed some things to use
the 'Book-3e' concept to convey the new MMU that is based on the
Freescale Book-E MMU programming model.
Note, its still invalid to try and use a page size that isn't supported
by cpu.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Some minor changes to prime for the rename of mmu-fsl-booke.h - mmu-book3e.h
arch/powerpc/include/asm/mmu-fsl-booke.h | 66 +++---
arch/powerpc/kernel/head_fsl_booke.S | 14 +++---
arch/powerpc/mm/fsl_booke_mmu.c |2 +-
3 files changed, 50 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-fsl-booke.h
b/arch/powerpc/include/asm/mmu-fsl-booke.h
index 3f941c0..c5363c3 100644
--- a/arch/powerpc/include/asm/mmu-fsl-booke.h
+++ b/arch/powerpc/include/asm/mmu-fsl-booke.h
@@ -1,26 +1,42 @@
-#ifndef _ASM_POWERPC_MMU_FSL_BOOKE_H_
-#define _ASM_POWERPC_MMU_FSL_BOOKE_H_
+#ifndef _ASM_POWERPC_MMU_BOOK3E_H_
+#define _ASM_POWERPC_MMU_BOOK3E_H_
/*
- * Freescale Book-E MMU support
+ * Freescale Book-E/Book-3e (ISA 2.06+) MMU support
*/
-/* Book-E defined page sizes */
-#define BOOKE_PAGESZ_1K0
-#define BOOKE_PAGESZ_4K1
-#define BOOKE_PAGESZ_16K 2
-#define BOOKE_PAGESZ_64K 3
-#define BOOKE_PAGESZ_256K 4
-#define BOOKE_PAGESZ_1M5
-#define BOOKE_PAGESZ_4M6
-#define BOOKE_PAGESZ_16M 7
-#define BOOKE_PAGESZ_64M 8
-#define BOOKE_PAGESZ_256M 9
-#define BOOKE_PAGESZ_1GB 10
-#define BOOKE_PAGESZ_4GB 11
-#define BOOKE_PAGESZ_16GB 12
-#define BOOKE_PAGESZ_64GB 13
-#define BOOKE_PAGESZ_256GB 14
-#define BOOKE_PAGESZ_1TB 15
+/* Book-3e defined page sizes */
+#define BOOK3E_PAGESZ_1K 0
+#define BOOK3E_PAGESZ_2K 1
+#define BOOK3E_PAGESZ_4K 2
+#define BOOK3E_PAGESZ_8K 3
+#define BOOK3E_PAGESZ_16K 4
+#define BOOK3E_PAGESZ_32K 5
+#define BOOK3E_PAGESZ_64K 6
+#define BOOK3E_PAGESZ_128K 7
+#define BOOK3E_PAGESZ_256K 8
+#define BOOK3E_PAGESZ_512K 9
+#define BOOK3E_PAGESZ_1M 10
+#define BOOK3E_PAGESZ_2M 11
+#define BOOK3E_PAGESZ_4M 12
+#define BOOK3E_PAGESZ_8M 13
+#define BOOK3E_PAGESZ_16M 14
+#define BOOK3E_PAGESZ_32M 15
+#define BOOK3E_PAGESZ_64M 16
+#define BOOK3E_PAGESZ_128M 17
+#define BOOK3E_PAGESZ_256M 18
+#define BOOK3E_PAGESZ_512M 19
+#define BOOK3E_PAGESZ_1GB 20
+#define BOOK3E_PAGESZ_2GB 21
+#define BOOK3E_PAGESZ_4GB 22
+#define BOOK3E_PAGESZ_8GB 23
+#define BOOK3E_PAGESZ_16GB 24
+#define BOOK3E_PAGESZ_32GB 25
+#define BOOK3E_PAGESZ_64GB 26
+#define BOOK3E_PAGESZ_128GB27
+#define BOOK3E_PAGESZ_256GB28
+#define BOOK3E_PAGESZ_512GB29
+#define BOOK3E_PAGESZ_1TB 30
+#define BOOK3E_PAGESZ_2TB 31
#define MAS0_TLBSEL(x) ((x 28) 0x3000)
#define MAS0_ESEL(x) ((x 16) 0x0FFF)
@@ -29,8 +45,9 @@
#define MAS1_VALID 0x8000
#define MAS1_IPROT 0x4000
#define MAS1_TID(x)((x 16) 0x3FFF)
+#define MAS1_IND 0x2000
#define MAS1_TS0x1000
-#define MAS1_TSIZE(x) ((x 8) 0x0F00)
+#define MAS1_TSIZE(x) ((x 7) 0x0F80)
#define MAS2_EPN 0xF000
#define MAS2_X00x0040
@@ -40,7 +57,7 @@
#define MAS2_M 0x0004
#define MAS2_G 0x0002
#define MAS2_E 0x0001
-#define MAS2_EPN_MASK(size)(~0 (2*(size) + 10))
+#define MAS2_EPN_MASK(size)(~0 (size + 10))
#define MAS2_VAL(addr, size, flags)((addr) MAS2_EPN_MASK(size) | (flags))
#define MAS3_RPN 0xF000
@@ -56,7 +73,7 @@
#define MAS3_SR0x0001
#define MAS4_TLBSELD(x) MAS0_TLBSEL(x)
-#define MAS4_TIDDSEL 0x000F
+#define MAS4_INDD 0x8000
#define MAS4_TSIZED(x) MAS1_TSIZE(x)
#define MAS4_X0D 0x0040
#define MAS4_X1D 0x0020
@@ -68,6 +85,7 @@
#define MAS6_SPID0 0x3FFF
#define MAS6_SPID1 0x7FFE
+#define MAS6_ISIZE(x) MAS1_TSIZE(x)
#define MAS6_SAS 0x0001
#define MAS6_SPID MAS6_SPID0
@@ -82,4 +100,4 @@ typedef struct {
} mm_context_t;
#endif /* !__ASSEMBLY__ */
-#endif /* _ASM_POWERPC_MMU_FSL_BOOKE_H_ */
+#endif /* _ASM_POWERPC_MMU_BOOK3E_H_ */
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index 64ecb16..4ea6e1a 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -173,7 +173,7 @@ skpinv: addir6,r6,1 /*
Increment */
/* grab and fixup the RPN */
mfspr
[PATCH 2/2] powerpc/book-3e: Introduce concept of Book-3e MMU
The Power ISA 2.06 spec introduces a standard MMU programming model that
is based on the Freescale Book-E MMU programing model. The Freescale
version is pretty backwards compatiable with the ISA 2.06 definition so
we are starting to refactor some of the Freescale code so it can be
easily shared.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../include/asm/{mmu-fsl-booke.h = mmu-book3e.h} |0
arch/powerpc/include/asm/mmu.h |6 +++---
arch/powerpc/platforms/Kconfig.cputype |4
3 files changed, 7 insertions(+), 3 deletions(-)
rename arch/powerpc/include/asm/{mmu-fsl-booke.h = mmu-book3e.h} (100%)
diff --git a/arch/powerpc/include/asm/mmu-fsl-booke.h
b/arch/powerpc/include/asm/mmu-book3e.h
similarity index 100%
rename from arch/powerpc/include/asm/mmu-fsl-booke.h
rename to arch/powerpc/include/asm/mmu-book3e.h
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 6e76399..5c78079 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -71,9 +71,9 @@ extern unsigned int __start___mmu_ftr_fixup,
__stop___mmu_ftr_fixup;
#elif defined(CONFIG_44x)
/* 44x-style software loaded TLB */
# include asm/mmu-44x.h
-#elif defined(CONFIG_FSL_BOOKE)
-/* Freescale Book-E software loaded TLB */
-# include asm/mmu-fsl-booke.h
+#elif defined(CONFIG_PPC_BOOK3E_MMU)
+/* Freescale Book-E software loaded TLB or Book-3e (ISA 2.06+) MMU */
+# include asm/mmu-book3e.h
#elif defined (CONFIG_PPC_8xx)
/* Motorola/Freescale 8xx software loaded TLB */
# include asm/mmu-8xx.h
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index e868b5c..9428c0e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -210,6 +210,10 @@ config PPC_MMU_NOHASH
def_bool y
depends on !PPC_STD_MMU
+config PPC_BOOK3E_MMU
+ def_bool y
+ depends on FSL_BOOKE
+
config PPC_MM_SLICES
bool
default y if HUGETLB_PAGE || (PPC_STD_MMU_64 PPC_64K_PAGES)
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc/book-3e: Introduce concept of Book-3e MMU
The Power ISA 2.06 spec introduces a standard MMU programming model that
is based on the Freescale Book-E MMU programing model. The Freescale
version is pretty backwards compatiable with the ISA 2.06 definition so
we are starting to refactor some of the Freescale code so it can be
easily shared.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Changed a few more CONFIG_FSL_BOOKE - CONFIG_PPC_BOOK3E_MMU
.../include/asm/{mmu-fsl-booke.h = mmu-book3e.h} |0
arch/powerpc/include/asm/mmu.h |6 +++---
arch/powerpc/kernel/entry_32.S |6 +++---
arch/powerpc/platforms/Kconfig.cputype |4
4 files changed, 10 insertions(+), 6 deletions(-)
rename arch/powerpc/include/asm/{mmu-fsl-booke.h = mmu-book3e.h} (100%)
diff --git a/arch/powerpc/include/asm/mmu-fsl-booke.h
b/arch/powerpc/include/asm/mmu-book3e.h
similarity index 100%
rename from arch/powerpc/include/asm/mmu-fsl-booke.h
rename to arch/powerpc/include/asm/mmu-book3e.h
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 6e76399..5c78079 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -71,9 +71,9 @@ extern unsigned int __start___mmu_ftr_fixup,
__stop___mmu_ftr_fixup;
#elif defined(CONFIG_44x)
/* 44x-style software loaded TLB */
# include asm/mmu-44x.h
-#elif defined(CONFIG_FSL_BOOKE)
-/* Freescale Book-E software loaded TLB */
-# include asm/mmu-fsl-booke.h
+#elif defined(CONFIG_PPC_BOOK3E_MMU)
+/* Freescale Book-E software loaded TLB or Book-3e (ISA 2.06+) MMU */
+# include asm/mmu-book3e.h
#elif defined (CONFIG_PPC_8xx)
/* Motorola/Freescale 8xx software loaded TLB */
# include asm/mmu-8xx.h
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 6f7eb7e..301c646 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -63,7 +63,7 @@ debug_transfer_to_handler:
.globl crit_transfer_to_handler
crit_transfer_to_handler:
-#ifdef CONFIG_FSL_BOOKE
+#ifdef CONFIG_PPC_BOOK3E_MMU
mfspr r0,SPRN_MAS0
stw r0,MAS0(r11)
mfspr r0,SPRN_MAS1
@@ -78,7 +78,7 @@ crit_transfer_to_handler:
mfspr r0,SPRN_MAS7
stw r0,MAS7(r11)
#endif /* CONFIG_PHYS_64BIT */
-#endif /* CONFIG_FSL_BOOKE */
+#endif /* CONFIG_PPC_BOOK3E_MMU */
#ifdef CONFIG_44x
mfspr r0,SPRN_MMUCR
stw r0,MMUCR(r11)
@@ -914,7 +914,7 @@ exc_exit_restart_end:
mtspr SPRN_##exc_lvl_srr0,r9; \
mtspr SPRN_##exc_lvl_srr1,r10;
-#if defined(CONFIG_FSL_BOOKE)
+#if defined(CONFIG_PPC_BOOK3E_MMU)
#ifdef CONFIG_PHYS_64BIT
#defineRESTORE_MAS7
\
lwz r11,MAS7(r1); \
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index e868b5c..9428c0e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -210,6 +210,10 @@ config PPC_MMU_NOHASH
def_bool y
depends on !PPC_STD_MMU
+config PPC_BOOK3E_MMU
+ def_bool y
+ depends on FSL_BOOKE
+
config PPC_MM_SLICES
bool
default y if HUGETLB_PAGE || (PPC_STD_MMU_64 PPC_64K_PAGES)
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: request_irq return errno 38
On Thu, Feb 12, 2009 at 10:39:36AM -0600, Timur Tabi wrote: On Thu, Feb 12, 2009 at 4:51 AM, Vijay Nikam vijay.t.ni...@gmail.com wrote: Also how I can read the device tree binary file ? ? ? It would be a lot simpler if you just read the documentation (see booting-without-of.txt) and looked at other device drivers to see what they do. You don't need to directly read the device tree, the provided helper functions (irq_parse_and_map() and the like) will read the device tree for you. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-booke: Fix compile warning
arch/powerpc/mm/fsl_booke_mmu.c: In function 'adjust_total_lowmem': arch/powerpc/mm/fsl_booke_mmu.c:221: warning: format '%ld' expects type 'long int', but argument 3 has type 'phys_addr_t' Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/mm/fsl_booke_mmu.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index 6d38d77..985b6c3 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -218,7 +218,7 @@ adjust_total_lowmem(void) p += sprintf(p, 0/); p[-1] = '\0'; - pr_info(Memory CAM mapping: %s Mb, residual: %ldMb\n, buf, - (total_lowmem - __max_low_memory) 20); + pr_info(Memory CAM mapping: %s Mb, residual: %dMb\n, buf, + (unsigned int)((total_lowmem - __max_low_memory) 20)); __initial_memory_limit_addr = memstart_addr + __max_low_memory; } -- 1.5.6.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: rework dma-noncoherent to use generic vmalloc layer (3rd rev)
This patch rewrites consistent dma allocations support to use vmalloc
layer to allocate virtual memory space from vmalloc pool and get rid
of CONFIG_CONSISTENT_{START,SIZE}.
I still use VM_IOREMAP flag for these allocations (I'll try to post
patch adding separate VM_COHERENT_DMA flag to lkml later).
Now I save pages array in vm_struct pages field and use
__builtin_return_address(1) as 'caller' argument to get usefull info
in /proc/vmallocinfo:
-bash-3.2# cat /proc/vmallocinfo
0xe100-0xe10020008192 __ioremap+0x184/0x194 ioremap
[...]
0xe1f9-0xe1f96000 24576 PrimeIocFifos+0x3a8/0x550 pages=5 ioremap
0xe1fa-0xe1fb1000 69632 __ioremap+0x184/0x194 ioremap
0xe1fc-0xe1fd1000 69632 __ioremap+0x184/0x194 ioremap
0xe200-0xe2f01000 15732736 __ioremap+0x184/0x194 ioremap
0xe2f32000-0xe2f340008192 __ioremap+0x184/0x194 ioremap
0xe2f38000-0xe2f3d000 20480 __ioremap+0x184/0x194 ioremap
0xe2f4-0xe2f46000 24576 PrimeIocFifos+0x3a8/0x550 pages=5 ioremap
0xe2f8-0xe3e81000 15732736 __ioremap+0x184/0x194 ioremap
0xe3f0-0xe3f48000 294912 PrimeIocFifos+0x204/0x550 pages=71 ioremap
0xe3f8-0xe3fc8000 294912 PrimeIocFifos+0x204/0x550 pages=71 ioremap
0xe3fe-0xe3fe6000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe3fe8000-0xe3fee000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe3fef000-0xe3ff8000 36864 bdx_open+0x10c/0x60c pages=8 vmalloc
0xe400-0xe4006000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe4007000-0xe400f000 32768 bdx_open+0x1f0/0x60c pages=7 vmalloc
0xe401-0xe401a000 40960 bdx_fifo_init+0x8c/0x12c pages=9 ioremap
(those ioremaps with pages=)
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Previous version had a memory leak in error code path.
---
arch/powerpc/Kconfig | 25 ---
arch/powerpc/lib/dma-noncoherent.c | 303 +++-
2 files changed, 57 insertions(+), 271 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 74cc312..ecae53f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -815,31 +815,6 @@ config TASK_SIZE
default 0x8000 if PPC_PREP || PPC_8xx
default 0xc000
-config CONSISTENT_START_BOOL
- bool Set custom consistent memory pool address
- depends on ADVANCED_OPTIONS NOT_COHERENT_CACHE
- help
- This option allows you to set the base virtual address
- of the consistent memory pool. This pool of virtual
- memory is used to make consistent memory allocations.
-
-config CONSISTENT_START
- hex Base virtual address of consistent memory pool if
CONSISTENT_START_BOOL
- default 0xfd00 if (NOT_COHERENT_CACHE 8xx)
- default 0xff10 if NOT_COHERENT_CACHE
-
-config CONSISTENT_SIZE_BOOL
- bool Set custom consistent memory pool size
- depends on ADVANCED_OPTIONS NOT_COHERENT_CACHE
- help
- This option allows you to set the size of the
- consistent memory pool. This pool of virtual memory
- is used to make consistent memory allocations.
-
-config CONSISTENT_SIZE
- hex Size of consistent memory pool if CONSISTENT_SIZE_BOOL
- default 0x0020 if NOT_COHERENT_CACHE
-
config PIN_TLB
bool Pinned Kernel TLBs (860 ONLY)
depends on ADVANCED_OPTIONS 8xx
diff --git a/arch/powerpc/lib/dma-noncoherent.c
b/arch/powerpc/lib/dma-noncoherent.c
index b7dc4c1..005a28d 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -29,121 +29,11 @@
#include linux/types.h
#include linux/highmem.h
#include linux/dma-mapping.h
+#include linux/vmalloc.h
#include asm/tlbflush.h
/*
- * This address range defaults to a value that is safe for all
- * platforms which currently set CONFIG_NOT_COHERENT_CACHE. It
- * can be further configured for specific applications under
- * the Advanced Setup menu. -Matt
- */
-#define CONSISTENT_BASE(CONFIG_CONSISTENT_START)
-#define CONSISTENT_END (CONFIG_CONSISTENT_START + CONFIG_CONSISTENT_SIZE)
-#define CONSISTENT_OFFSET(x) (((unsigned long)(x) - CONSISTENT_BASE)
PAGE_SHIFT)
-
-/*
- * This is the page table (2MB) covering uncached, DMA consistent allocations
- */
-static pte_t *consistent_pte;
-static DEFINE_SPINLOCK(consistent_lock);
-
-/*
- * VM region handling support.
- *
- * This should become something generic, handling VM region allocations for
- * vmalloc and similar (ioremap, module space, etc).
- *
- * I envisage vmalloc()'s supporting vm_struct becoming:
- *
- * struct vm_struct {
- *struct vm_region region;
- *unsigned longflags;
- *struct page **pages;
- *unsigned int nr_pages;
- *unsigned longphys_addr;
- * };
- *
- * get_vm_area() would then call vm_region_alloc with an appropriate
- * struct vm_region head (eg):
- *
- * struct vm_region vmalloc_head = {
- * .vm_list= LIST_HEAD_INIT(vmalloc_head.vm_list),
- * .vm_start = VMALLOC_START,
- *
Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
On Thu, Feb 12, 2009 at 03:58:15PM -0600, Kumar Gala wrote: On Feb 12, 2009, at 2:34 PM, Josh Boyer wrote: On Thu, Feb 12, 2009 at 01:21:24PM -0600, Kumar Gala wrote: On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote: The Power ISA 2.06 added power of two page sizes to the embedded MMU architecture. Its done it such a way to be code compatiable with the existing HW. Made the minor code changes to support both power of two and power of four page sizes. Also added some new MAS bits and macros that are defined as part of the 2.06 ISA. Note, its still invalid to try and use a page size that isn't supported by cpu. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixed MAS6_ISIZE macro arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++ +-- Do you want to rename asm/mmu-fsl-booke.h = mmu-booke.h (per ISA 2.06 changes)? Misleading perhaps. ISA 2.06 is really new and we've been calling 4xx and FSL booke for a while now. I can call it mmu-book3e.h if you think that might enough different to convey the ISA 2.06 fact that the FSL style MMU is now part of the 3e architecture. Yep, sounds great. What's in a name.., right? :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Thu, 12 Feb 2009, Geoff Levand wrote: On 02/11/2009 05:10 PM, Steven Rostedt wrote: This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. I added these to my ps3-linux.git tree. Very casual testing shows they seem to work OK. Tested-by: Geoff Levand geoffrey.lev...@am.sony.com Working OK on PS3. Thanks! Is the ps3 64 or 32 bit? I'll put your tested by on the appropriate patches. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Thu, Feb 12, 2009 at 06:41:26PM -0500, Steven Rostedt wrote: On Thu, 12 Feb 2009, Geoff Levand wrote: On 02/11/2009 05:10 PM, Steven Rostedt wrote: This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. I added these to my ps3-linux.git tree. Very casual testing shows they seem to work OK. Tested-by: Geoff Levand geoffrey.lev...@am.sony.com Working OK on PS3. Thanks! Is the ps3 64 or 32 bit? I'll put your tested by on the appropriate patches. 64-bit. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On 02/12/2009 03:41 PM, Steven Rostedt wrote: On Thu, 12 Feb 2009, Geoff Levand wrote: On 02/11/2009 05:10 PM, Steven Rostedt wrote: This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. I added these to my ps3-linux.git tree. Very casual testing shows they seem to work OK. Tested-by: Geoff Levand geoffrey.lev...@am.sony.com Working OK on PS3. Thanks! Is the ps3 64 or 32 bit? I'll put your tested by on the appropriate patches. It uses the Cell processor, which is 64 bit. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix _PAGE_CHG_MASK
Fix _PAGE_CHG_MASK so that pte_modify() does not affect the _PAGE_SPECIAL bit. Signed-off-by: Philippe Gerum r...@xenomai.org -- arch/powerpc/include/asm/pgtable-4k.h|2 +- arch/powerpc/include/asm/pgtable-64k.h |2 +- arch/powerpc/include/asm/pgtable-ppc32.h |4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-4k.h b/arch/powerpc/include/asm/pgtable-4k.h index 6b18ba9..1dbca4e 100644 --- a/arch/powerpc/include/asm/pgtable-4k.h +++ b/arch/powerpc/include/asm/pgtable-4k.h @@ -60,7 +60,7 @@ /* It should be preserving the high 48 bits and then specifically */ /* preserving _PAGE_SECONDARY | _PAGE_GROUP_IX */ #define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \ - _PAGE_HPTEFLAGS) + _PAGE_HPTEFLAGS | _PAGE_SPECIAL) /* Bits to mask out from a PMD to get to the PTE page */ #define PMD_MASKED_BITS0 diff --git a/arch/powerpc/include/asm/pgtable-64k.h b/arch/powerpc/include/asm/pgtable-64k.h index 07b0d8f..7389003 100644 --- a/arch/powerpc/include/asm/pgtable-64k.h +++ b/arch/powerpc/include/asm/pgtable-64k.h @@ -114,7 +114,7 @@ static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd) * pgprot changes */ #define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \ - _PAGE_ACCESSED) + _PAGE_ACCESSED | _PAGE_SPECIAL) /* Bits to mask out from a PMD to get to the PTE page */ #define PMD_MASKED_BITS0x1ff diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h index 75dded6..8298afc 100644 --- a/arch/powerpc/include/asm/pgtable-ppc32.h +++ b/arch/powerpc/include/asm/pgtable-ppc32.h @@ -428,8 +428,8 @@ extern int icache_44x_need_flush; #define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE() #endif -#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_SPECIAL) - +#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \ +_PAGE_SPECIAL) #define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \ _PAGE_WRITETHRU | _PAGE_ENDIAN | \ -- Philippe. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
On Thu, 12 Feb 2009, Geoff Levand wrote: On 02/12/2009 03:41 PM, Steven Rostedt wrote: On Thu, 12 Feb 2009, Geoff Levand wrote: On 02/11/2009 05:10 PM, Steven Rostedt wrote: This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture. It is broken up into a series of logical steps. I added these to my ps3-linux.git tree. Very casual testing shows they seem to work OK. Tested-by: Geoff Levand geoffrey.lev...@am.sony.com Working OK on PS3. Thanks! Is the ps3 64 or 32 bit? I'll put your tested by on the appropriate patches. It uses the Cell processor, which is 64 bit. Thanks guys! -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add support for using doorbells for SMP IPI
The e500mc supports the new msgsnd/doorbell mechanisms that were added in
the Power ISA 2.05 architecture. We use the normal level doorbell for
doing SMP IPIs at this point.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/include/asm/cputable.h |4 ++-
arch/powerpc/include/asm/dbell.h | 43 +
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/dbell.c | 44 ++
arch/powerpc/kernel/head_fsl_booke.S |6 -
arch/powerpc/kernel/traps.c | 21
6 files changed, 117 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/include/asm/dbell.h
create mode 100644 arch/powerpc/kernel/dbell.c
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 4911104..fca1611 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -145,6 +145,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_USE_TB ASM_CONST(0x0040)
#define CPU_FTR_L2CSR ASM_CONST(0x0080)
#define CPU_FTR_601ASM_CONST(0x0100)
+#define CPU_FTR_DBELL ASM_CONST(0x0200)
#define CPU_FTR_CAN_NAPASM_CONST(0x0400)
#define CPU_FTR_L3CR ASM_CONST(0x0800)
#define CPU_FTR_L3_DISABLE_NAP ASM_CONST(0x1000)
@@ -373,7 +374,8 @@ extern const char *powerpc_base_platform;
CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
#define CPU_FTRS_E500MC(CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
- CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE)
+ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+ CPU_FTR_DBELL)
#define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
diff --git a/arch/powerpc/include/asm/dbell.h b/arch/powerpc/include/asm/dbell.h
new file mode 100644
index 000..501189a
--- /dev/null
+++ b/arch/powerpc/include/asm/dbell.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2009 Freescale Semicondutor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * provides masks and opcode images for use by code generation, emulation
+ * and for instructions that older assemblers might not know about
+ */
+#ifndef _ASM_POWERPC_DBELL_H
+#define _ASM_POWERPC_DBELL_H
+
+#include linux/smp.h
+#include linux/threads.h
+
+#include asm/ppc-opcode.h
+
+#define PPC_DBELL_MSG_BRDCAST (0x0400)
+#define PPC_DBELL_TYPE(x) (((x) 0xf) 28)
+enum ppc_dbell {
+ PPC_DBELL = 0, /* doorbell */
+ PPC_DBELL_CRIT = 1, /* critical doorbell */
+ PPC_G_DBELL = 2,/* guest doorbell */
+ PPC_G_DBELL_CRIT = 3, /* guest critical doorbell */
+ PPC_G_DBELL_MC = 4, /* guest mcheck doorbell */
+};
+
+#ifdef CONFIG_SMP
+extern unsigned long dbell_smp_message[NR_CPUS];
+extern void smp_dbell_message_pass(int target, int msg);
+#endif
+
+static inline void ppc_msgsnd(enum ppc_dbell type, u32 flags, u32 tag)
+{
+ u32 msg = PPC_DBELL_TYPE(type) | (flags PPC_DBELL_MSG_BRDCAST) |
+ (tag 0x07ff);
+
+ __asm__ __volatile__ (PPC_MSGSND(%0) : : r (msg));
+}
+
+#endif /* _ASM_POWERPC_DBELL_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index d159921..f420844 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -61,7 +61,7 @@ obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
obj64-$(CONFIG_HIBERNATION)+= swsusp_asm64.o
obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
-obj-$(CONFIG_FSL_BOOKE)+= cpu_setup_fsl_booke.o
+obj-$(CONFIG_FSL_BOOKE)+= cpu_setup_fsl_booke.o dbell.o
extra-$(CONFIG_PPC_STD_MMU):= head_32.o
extra-$(CONFIG_PPC64) := head_64.o
diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
new file mode 100644
index 000..1493734
--- /dev/null
+++ b/arch/powerpc/kernel/dbell.c
@@ -0,0 +1,44 @@
+/*
+ * Author: Kumar Gala ga...@kernel.crashing.org
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/stddef.h
+#include linux/kernel.h
+#include linux/smp.h
+#include linux/threads.h
+
+#include asm/dbell.h
+
+#ifdef CONFIG_SMP
Re: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
On Thu, Feb 12, 2009 at 05:51:57PM -0600, Kumar Gala wrote: On Feb 11, 2009, at 11:40 PM, Li Yang-R58472 wrote: Li, thanks for heads-up! One thing though: documentation says that Marvell PHY address is 0x3, while old device tree and this patch: http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add- default- dts.patch says 0x1... I don't have any rev. C boards, so it would be great if somebody could confirm that 0x1 is the actual address. The correct address is 0x3. The previous patch in revB BSP used a guess value before the revC documentation is available. The latest BSP has been updated to use the correct address. Anton, will you spin a new patch with this change? Since the correct address is 0x3, that means that the old device tree never worked on rev. C boards, thus there is no regression. And furthermore, it appears that U-Boot doesn't support Marvell PHY option either. So, I don't think that adding the new device tree makes any sense now. I think the better option would be to implement Marvell PHY support in U-Boot, and at the same time teach U-Boot to fixup 8313rdb's device tree depending on the environment variable (something like setenv marvell_phy_option yes/no), i.e. like I did for MPC8315E-RDB's ULPI/TSEC1 options: http://lists.denx.de/pipermail/u-boot/2008-July/036553.html Makes sense? If not, I'll readily respin this patch with the PHY address change. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/83xx: Revive Marvell PHY option onMPC8313E-RDB rev. C boards
-Original Message- From: Anton Vorontsov [mailto:avoront...@ru.mvista.com] Sent: Friday, February 13, 2009 9:18 AM To: Kumar Gala Cc: linuxppc-dev list; Li Yang-R58472 Subject: Re: [PATCH] powerpc/83xx: Revive Marvell PHY option onMPC8313E-RDB rev. C boards On Thu, Feb 12, 2009 at 05:51:57PM -0600, Kumar Gala wrote: On Feb 11, 2009, at 11:40 PM, Li Yang-R58472 wrote: Li, thanks for heads-up! One thing though: documentation says that Marvell PHY address is 0x3, while old device tree and this patch: http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add- default- dts.patch says 0x1... I don't have any rev. C boards, so it would be great if somebody could confirm that 0x1 is the actual address. The correct address is 0x3. The previous patch in revB BSP used a guess value before the revC documentation is available. The latest BSP has been updated to use the correct address. Anton, will you spin a new patch with this change? Since the correct address is 0x3, that means that the old device tree never worked on rev. C boards, thus there is no regression. And furthermore, it appears that U-Boot doesn't support Marvell PHY option either. No regression but to be more updated. RevC boards are newly introduced. So, I don't think that adding the new device tree makes any sense now. I think the better option would be to implement Marvell PHY support in U-Boot, and at the same time teach U-Boot to fixup 8313rdb's device tree depending on the environment variable (something like setenv marvell_phy_option yes/no), i.e. like I did for MPC8315E-RDB's ULPI/TSEC1 options: http://lists.denx.de/pipermail/u-boot/2008-July/036553.html This approach is surely more user friendly. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for using doorbells for SMP IPI
On Thu, 2009-02-12 at 17:54 -0600, Kumar Gala wrote: The e500mc supports the new msgsnd/doorbell mechanisms that were added in the Power ISA 2.05 architecture. We use the normal level doorbell for doing SMP IPIs at this point. Cool stuff. Haven't reviewed in details yet tho :-) But I was thinking... We should introduce a special xmon variant of local_irq_save/restore for use by xmon that masks MSR:CE and use a crit doorbell for xmon IPI, that would increase significantly the ability of xmon to catch deadlocked CPUs, and we could use external CRITs as a more generic way of doing IPIs, no ? In fact, we should expose a local_crit_irq_save/restore (disable/enable) too for things like watchdog drivers etc... which may want to use these. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix _PAGE_CHG_MASK
On Thu, 2009-02-12 at 23:18 +0100, Philippe Gerum wrote: Fix _PAGE_CHG_MASK so that pte_modify() does not affect the _PAGE_SPECIAL bit. Signed-off-by: Philippe Gerum r...@xenomai.org Good catch ! Thanks ! Ben. -- arch/powerpc/include/asm/pgtable-4k.h|2 +- arch/powerpc/include/asm/pgtable-64k.h |2 +- arch/powerpc/include/asm/pgtable-ppc32.h |4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-4k.h b/arch/powerpc/include/asm/pgtable-4k.h index 6b18ba9..1dbca4e 100644 --- a/arch/powerpc/include/asm/pgtable-4k.h +++ b/arch/powerpc/include/asm/pgtable-4k.h @@ -60,7 +60,7 @@ /* It should be preserving the high 48 bits and then specifically */ /* preserving _PAGE_SECONDARY | _PAGE_GROUP_IX */ #define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \ - _PAGE_HPTEFLAGS) + _PAGE_HPTEFLAGS | _PAGE_SPECIAL) /* Bits to mask out from a PMD to get to the PTE page */ #define PMD_MASKED_BITS 0 diff --git a/arch/powerpc/include/asm/pgtable-64k.h b/arch/powerpc/include/asm/pgtable-64k.h index 07b0d8f..7389003 100644 --- a/arch/powerpc/include/asm/pgtable-64k.h +++ b/arch/powerpc/include/asm/pgtable-64k.h @@ -114,7 +114,7 @@ static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd) * pgprot changes */ #define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \ - _PAGE_ACCESSED) + _PAGE_ACCESSED | _PAGE_SPECIAL) /* Bits to mask out from a PMD to get to the PTE page */ #define PMD_MASKED_BITS 0x1ff diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h index 75dded6..8298afc 100644 --- a/arch/powerpc/include/asm/pgtable-ppc32.h +++ b/arch/powerpc/include/asm/pgtable-ppc32.h @@ -428,8 +428,8 @@ extern int icache_44x_need_flush; #define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE() #endif -#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_SPECIAL) - +#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \ + _PAGE_SPECIAL) #define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \ _PAGE_WRITETHRU | _PAGE_ENDIAN | \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 002/002] de2104x: support for systems lacking cache coherence
On Thu, 2009-02-12 at 13:22 +0200, Risto Suominen wrote: Here is a patch that helped me to get my de2104x NIC working on my PowerMac 5500. As an interesting side effect, it also made my mesh module crash. Background can be found here: http://www.spinics.net/lists/netdev/msg88488.html I'll catch up with the discussion in netdev, I think the workaround should be in the driver... Or if not, we can do special dma-ops just for that device. Just to make sure I didn't miss something, please send me a tarball of /proc/device-tree of your machine. Cheers, Ben. Risto Allow setting NOT_COHERENT_CACHE explicitly. Signed-off-by: Risto Suominen risto.suomi...@gmail.com --- The testing is done on kernel version 2.6.24. --- a/arch/powerpc/platforms/powermac/Kconfig.org 2008-01-25 00:58:37.0 +0200 +++ b/arch/powerpc/platforms/powermac/Kconfig 2009-02-10 17:44:24.0 +0200 @@ -18,4 +18,10 @@ config PPC_PMAC64 select PPC_970_NAP default y - +config NOT_COHERENT_CACHE + bool Incoherent cache + default n + help + Setting this option may be necessary for avoiding cache-related + problems with some network cards on some platforms. An example is + 2104x and PowerMac 5500. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 002/002] de2104x: support for systems lacking cache coherence
On Thu, 2009-02-12 at 13:22 +0200, Risto Suominen wrote: Here is a patch that helped me to get my de2104x NIC working on my PowerMac 5500. As an interesting side effect, it also made my mesh module crash. Can you tell me more about the mesh crash ? Do you have a log ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7][RFC] powerpc64: port of the function graph tracer
On Wed, 2009-02-11 at 20:10 -0500, Steven Rostedt wrote: +# timers used by tracing +CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog endif That means no tracing of the timer interrupts etc... maybe we should just move the specific function that we don't want traced out to a separate file ? Appart from that, it looks ok, though I might have missed something :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/7][RFC] powerpc64, tracing: add function graph tracer with dynamic tracing
@@ -55,8 +56,9 @@ static unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr) */ addr = GET_ADDR(addr); - /* Set to bl addr */ - op = 0x4801 | (ftrace_calc_offset(ip, addr) 0x03fc); + /* if (link) set op to 'bl' else 'b' */ + op = 0x4800 | (link ? 1 : 0); + op |= (ftrace_calc_offset(ip, addr) 0x03fc); Any reason why you aren't using the code in arch/powerpc/lib/code-patching.c here ? new = ftrace_call_replace(ip, stub, 0); + memcpy(old, new, MCOUNT_INSN_SIZE); + new = ftrace_call_replace(ip, addr, 0); + + return ftrace_modify_code(ip, old, new); +} Heh, memcpy of 4 bytes :-) I hope gcc is smart enough to turn that into a simple load/store .. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7][RFC] powerpc64: port of the function graph tracer
On Fri, 13 Feb 2009, Benjamin Herrenschmidt wrote: On Wed, 2009-02-11 at 20:10 -0500, Steven Rostedt wrote: +# timers used by tracing +CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog endif That means no tracing of the timer interrupts etc... maybe we should just move the specific function that we don't want traced out to a separate file ? The function graph tracer calls cpu_clock, which calls sched_clock, to get the times. There's no protection against recursion here, since we want to let interrupts still be recorded, and we do not need to disable interrupts. But if the cpu_clock calls something that is traced, it will recurse, and cause a lockup. What ever functions those are, we could annotate with notrace. I just used the x86 blind method of 'dont trace this file'. Appart from that, it looks ok, though I might have missed something :-) Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
For some reason I didn't get 7/7 ... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/7][RFC] powerpc64, tracing: add function graph tracer with dynamic tracing
On Fri, 13 Feb 2009, Benjamin Herrenschmidt wrote: @@ -55,8 +56,9 @@ static unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr) */ addr = GET_ADDR(addr); - /* Set to bl addr */ - op = 0x4801 | (ftrace_calc_offset(ip, addr) 0x03fc); + /* if (link) set op to 'bl' else 'b' */ + op = 0x4800 | (link ? 1 : 0); + op |= (ftrace_calc_offset(ip, addr) 0x03fc); Any reason why you aren't using the code in arch/powerpc/lib/code-patching.c here ? new = ftrace_call_replace(ip, stub, 0); + memcpy(old, new, MCOUNT_INSN_SIZE); + new = ftrace_call_replace(ip, addr, 0); + + return ftrace_modify_code(ip, old, new); +} Heh, memcpy of 4 bytes :-) I hope gcc is smart enough to turn that into a simple load/store .. hehe, I hated writing that. I just did not want to touch the (already working code) of the dynamic ftrace. I guess I could still use longs and then typecast them to char pointers for the ftrace_modify_code. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix VSX alignment handler for regs 32-63
Fix the VSX alignment handler for VSX registers 32. 32-63 are stored
in the VMX part of the thread_struct not the FPR part.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/kernel/align.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/align.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/align.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/align.c
@@ -646,11 +646,16 @@ static int emulate_vsx(unsigned char __u
unsigned int areg, struct pt_regs *regs,
unsigned int flags, unsigned int length)
{
- char *ptr = (char *) current-thread.TS_FPR(reg);
+ char *ptr;
int ret = 0;
flush_vsx_to_thread(current);
+ if (reg 32)
+ ptr = (char *) current-thread.TS_FPR(reg);
+ else
+ ptr = (char *) current-thread.vr[reg - 32];
+
if (flags ST)
ret = __copy_to_user(addr, ptr, length);
else {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for using doorbells for SMP IPI
On Feb 12, 2009, at 8:46 PM, Benjamin Herrenschmidt wrote: On Thu, 2009-02-12 at 17:54 -0600, Kumar Gala wrote: The e500mc supports the new msgsnd/doorbell mechanisms that were added in the Power ISA 2.05 architecture. We use the normal level doorbell for doing SMP IPIs at this point. Cool stuff. Haven't reviewed in details yet tho :-) But I was thinking... We should introduce a special xmon variant of local_irq_save/restore for use by xmon that masks MSR:CE and use a crit doorbell for xmon IPI, that would increase significantly the ability of xmon to catch deadlocked CPUs, and we could use external CRITs as a more generic way of doing IPIs, no ? crit doorbell for xmon IPI sounds interesting. However, I don't following about use of external CRITs for IPIs. In fact, we should expose a local_crit_irq_save/restore (disable/ enable) too for things like watchdog drivers etc... which may want to use these. Yeah, probably a good thing for us to add. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for using doorbells for SMP IPI
crit doorbell for xmon IPI sounds interesting. However, I don't following about use of external CRITs for IPIs. Just a finger not following the brain :-) I meant for NMI's Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix _PAGE_CHG_MASK
On Fri, 2009-02-13 at 13:49 +1100, Benjamin Herrenschmidt wrote: diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h index 75dded6..8298afc 100644 --- a/arch/powerpc/include/asm/pgtable-ppc32.h +++ b/arch/powerpc/include/asm/pgtable-ppc32.h @@ -428,8 +428,8 @@ extern int icache_44x_need_flush; #define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE() #endif -#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_SPECIAL) - +#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \ +_PAGE_SPECIAL) #define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \ _PAGE_WRITETHRU | _PAGE_ENDIAN | \ BTW. That part of the patch looks bad (ie, the original line isn't what is upstream). I've fixed up locally. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: writel hangs system
There seems to be some magic force linked to this mailing list. Whenever I post a question, the matter seems to resolve itself. :) In order to stay as consistent as possible with the old 2.4 kernel, I used the same mapping that they had: 0x5000 - 0x60 for memory 0x6000 - 0x61 for I/O When I changed it to the default that was in the lite5200b device tree I could access the memory regions as well. Thanks for your help! On Thu, Feb 12, 2009 at 22:18, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Feb 10, 2009 at 6:07 AM, Tobias Knutsson tobias.knuts...@gmail.com wrote: Hello, I'm in the process of porting a PCI-driver for a dsp-board from 2.4 to 2.6. The probing of the driver goes well, IRQs are setup, resources are claimed and remapped without any problems. Reading from I/O regions also works well. However, when i try to read or write to a memory region using readl/writel, the system instantly hangs. No stacktrace or anything, it just stops. Hmmm. Not good. Are you able to access the memory regions from the U-Boot console? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- Hälsningar/Regards Tobias Knutsson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
