* Re: writing CCSR_BAR register for relocation?
From: Parav Pandit @ 2006-07-28 12:01 UTC (permalink / raw)
To: Parav Pandit, linuxppc-embedded
In-Reply-To: <20060728112803.34466.qmail@web36610.mail.mud.yahoo.com>
I have read the MPC8555 RF.
section 4.3.1.1 says that CCSRBAR is points to itself.
Checked by the md command in u-boot.
it shows the same results, FF70:0000.
It shows the FF704600 also at that address for all the
addresses it shows the same content as address.
If this is the case, how come the u-boot works on
serial port? It should show some other value for the
configured devices such as serial port at least.
or somethign is missing on my side...
Regards,
Parav Pandit
--- Parav Pandit <paravpandit@yahoo.com> wrote:
> Hi,
>
> I am newbie to MPC8555, PowerPC family and u-boot.
> Please guide me.
>
> 1. How can I read/write registers from the u-boot
> similar to md/mm command? Basically I want to
> read/write CCSR_BAR from the u-boot.
>
> 2. How can I read/write CCSRBAR register value from
> my
> assembly program?
> mfspr.mtspr ??? what is the register name??
>
> 3. By changing the default value of 0xFF70:0000 to
> 0xE000:0000 is sufficient to relocate the 1MB block
> or
> anything else is also required?
>
> 4. I look at the u-boot code for tqm85xx, 8555cds,
> and
> 8555ads series of boards and it does something with
> TLB.
> I don't understand why it modifies the TLB registers
> whose purpose is only for the performance
> improvement?
> Or we can use the TLB for something else also?
>
> Regards,
> Parav Pandit
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* writing CCSR_BAR register for relocation in MPC8555?
From: Parav Pandit @ 2006-07-28 11:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am newbie to MPC8555, PowerPC family and u-boot.
Please guide me.
1. How can I read/write registers from the u-boot
similar to md/mm command? Basically I want to
read/write CCSR_BAR from the u-boot.
2. How can I read/write CCSRBAR register value from my
assembly program?
mfspr.mtspr ??? what is the register name??
3. By changing the default value of 0xFF70:0000 to
0xE000:0000 is sufficient to relocate the 1MB block or
anything else is also required?
4. I look at the u-boot code for tqm85xx, 8555cds, and
8555ads series of boards and it does something with
TLB.
I don't understand why it modifies the TLB registers
whose purpose is only for the performance improvement?
Or we can use the TLB for something else also?
Regards,
Parav Pandit
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* writing CCSR_BAR register for relocation?
From: Parav Pandit @ 2006-07-28 11:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am newbie to MPC8555, PowerPC family and u-boot.
Please guide me.
1. How can I read/write registers from the u-boot
similar to md/mm command? Basically I want to
read/write CCSR_BAR from the u-boot.
2. How can I read/write CCSRBAR register value from my
assembly program?
mfspr.mtspr ??? what is the register name??
3. By changing the default value of 0xFF70:0000 to
0xE000:0000 is sufficient to relocate the 1MB block or
anything else is also required?
4. I look at the u-boot code for tqm85xx, 8555cds, and
8555ads series of boards and it does something with
TLB.
I don't understand why it modifies the TLB registers
whose purpose is only for the performance improvement?
Or we can use the TLB for something else also?
Regards,
Parav Pandit
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Host USB on MPC8247
From: Uros Borovsak @ 2006-07-28 11:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44BF88A2.6080003@razvoj-verbic.si>
Hello,
Can you at least give me some idea how difficult would it be to patch
USB part of kernel from 2.6.13 to 2.6.10?
Are changes only in usb part of kernel, or are there also some changes
in other parts of kernel, that I would have to port?
Thanks,
Best regards
Uros
Uros Borovsak wrote:
> Hello,
>
> I'm looking for host USB driver for MPC8247. We are using MV kernel
> 2.6.10 and I'm wondering, if there is a driver for this specific kernel.
>
> I'm aware of cpm2usb project on sourceforge, but it is for kernel
> 2.6.13. How difficult would it be to patch only usb part of kernel from
> 2.6.10 to 2.6.13 so I could use that drivers. I only need suport for USB
> storage devices, so that driver is enough for me.
>
> Thanks,
>
> Best regards,
>
> Uros
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: System Ace Driver Hangs.
From: Ameet Patil @ 2006-07-28 11:10 UTC (permalink / raw)
To: Raja Chidambaram; +Cc: linuxppc-embedded
In-Reply-To: <20060728110356.90311.qmail@web53614.mail.yahoo.com>
Hi Raja,
Did you update the xparameters_ml300.h or xparameters_ml403.h file
with the right defines for your specific board? If not, then you need to
update the file first. This first is automatically generated by the EDK
toolset. However, you might also choose to do it manually if you know
the right values. The driver would work with the right base-address.
cheers,
-Ameet
Raja Chidambaram wrote:
>
> Hi all,
>
> I got the system Ace driver compiled in to linux
> 2.6.12 but once the board boot's up , the console
> shows
>
> Data machine check in kernel mode.
> and continously runs the call trace.
>
> when i debugged the this problem on xsyace driver
> codebase the it hangs at function in & calls call
> trace
>
> >adapter.c
>
> --> if (XSysAce_Initialize(&SysAce, cfg->DeviceId)
> != XST_SUCCESS)
>
> when further debugged the function XSysAce_Initialize
> it call the funtion XSysAce_RegWrite16
>
> >xsyace.c
>
> -->#if (XPAR_XSYSACE_MEM_WIDTH == 16)
> XSysAce_RegWrite16(InstancePtr->BaseAddress +
> XSA_BMR_OFFSET,XSA_BMR_16BIT_MASK);
>
> in further debugging on the function
> XSysAce_RegWrite16
> shows
> >xsysace_l.c
>
> --> #if (XPAR_XSYSACE_MEM_WIDTH == 16)
> void XSysAce_RegWrite16(u32 Address, u16 Data)
> {
> u16 ConvertedData;
>
>
>
> /*
> * The ACE registers are little-endian always.
> This code takes the incoming
> * 16-bit and endian converts it, then writes it
> to the ACE register.
> */
> XIo_ToLittleEndian16(Data, &ConvertedData);
> XIo_Out(Address, ConvertedData); /***** the
> execution
> runs the call trace from this point ******/
>
> }
>
>
>
> I beleive their problem with macro value in
> > xparameters.h
>
> XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
> can some one please explain how to specify the
> value for this macro mine is xccace-tq144i System ace
> or else is their any other problem to solve.please
> help me in this.thanks in advance.
>
> with regards
> k.raja
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
^ permalink raw reply
* RE:System Ace Driver Hangs.
From: Raja Chidambaram @ 2006-07-28 11:03 UTC (permalink / raw)
To: ammubhai, eemingliu, linuxppc-embedded
Hi all,
I got the system Ace driver compiled in to linux
2.6.12 but once the board boot's up , the console
shows
Data machine check in kernel mode.
and continously runs the call trace.
when i debugged the this problem on xsyace driver
codebase the it hangs at function in & calls call
trace
>adapter.c
--> if (XSysAce_Initialize(&SysAce, cfg->DeviceId)
!= XST_SUCCESS)
when further debugged the function XSysAce_Initialize
it call the funtion XSysAce_RegWrite16
>xsyace.c
-->#if (XPAR_XSYSACE_MEM_WIDTH == 16)
XSysAce_RegWrite16(InstancePtr->BaseAddress +
XSA_BMR_OFFSET,XSA_BMR_16BIT_MASK);
in further debugging on the function
XSysAce_RegWrite16
shows
>xsysace_l.c
--> #if (XPAR_XSYSACE_MEM_WIDTH == 16)
void XSysAce_RegWrite16(u32 Address, u16 Data)
{
u16 ConvertedData;
/*
* The ACE registers are little-endian always.
This code takes the incoming
* 16-bit and endian converts it, then writes it
to the ACE register.
*/
XIo_ToLittleEndian16(Data, &ConvertedData);
XIo_Out(Address, ConvertedData); /***** the
execution
runs the call trace from this point ******/
}
I beleive their problem with macro value in
> xparameters.h
XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
can some one please explain how to specify the
value for this macro mine is xccace-tq144i System ace
or else is their any other problem to solve.please
help me in this.thanks in advance.
with regards
k.raja
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: David H. Lynch Jr. @ 2006-07-28 8:03 UTC (permalink / raw)
To: Clint Thomas, linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
Clint Thomas wrote:
> Hey guys,
>
> I have gone through the Linuxppc embedded and dev lists for
> information related to what I am trying to do, but was unable to find
> exactly what i'm looking for.
>
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does
> not need it to boot the linux kernel. I want to load an uncompressed
> linux kernel into memory and start the execution of the kernel,
> without using any kind of bootloader. Is this possible? Or does linux
> need some kind of firmware or other software to tell it to start
> executing? Thanks for any info you might have.
You system powers on. It starts executing whatever is at the reset
vector, Something has to get you from the ppc powering up and going to
never never land, to starting to execute Linux.
The steps to get from Power on to booting Linux may not be that
complicated, Much of what needs to be done can likely be included as
part of the code for your board in arch/ppc/boot/simple.
But something still has to be done.
In my instance I am dealing with a Xilinx V4 (not an ML403). A small
"monitor" program is automatically loaded as part of the FPGA .bit
image. On power on it starts executing.
It sets up the CPU, cache, and very minimal hardware configuration,
and then loads Linux out of flash and executes it.
Linux does not have to have alot setup to boot. But something has to
to some minimal initial setup, get Linux into the memory of your system,
and jump to it.
>
> Clinton Thomas
> cthomas@soneticom.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 3667 bytes --]
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Benjamin Herrenschmidt @ 2006-07-28 4:56 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024154.29826.229.camel@goblue>
On Thu, 2006-07-27 at 13:15 -0500, Jake Moilanen wrote:
> Here is a rebased RTAS MSI which uses the IRQ layer rewrite. Please try
> getting it into 2.6.18.
>
> I mistakenly forgot to export the MSI symbols. So modules weren't too
> happy...
>
> The RTAS patch skips the intel-centric MSI layer and uses
> pci_enable/disable_msi() calls directly. It does not correctly handle
> multi-vector MSI either.
Multi-vector MSIs aren't handled by the linux API anyway it seems (the
doc says pci_enable_msi() only ever enables one MSI) so that's fine if
you don't handle them :) The word on the street is that multivector MSIs
aren't useful, MSI-X are.
Ben.
^ permalink raw reply
* [PATCH] Enable PURR sysfs entry correctly
From: Michael Neuling @ 2006-07-28 3:58 UTC (permalink / raw)
To: paulus, linuxppc-dev
We have CPU_FTR_PURR now, so let's use it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/sysfs.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/sysfs.c
@@ -231,7 +231,7 @@ static void register_cpu_online(unsigned
if (cur_cpu_spec->num_pmcs >= 8)
sysdev_create_file(s, &attr_pmc8);
- if (cpu_has_feature(CPU_FTR_SMT))
+ if (cpu_has_feature(CPU_FTR_PURR))
sysdev_create_file(s, &attr_purr);
}
@@ -273,7 +273,7 @@ static void unregister_cpu_online(unsign
if (cur_cpu_spec->num_pmcs >= 8)
sysdev_remove_file(s, &attr_pmc8);
- if (cpu_has_feature(CPU_FTR_SMT))
+ if (cpu_has_feature(CPU_FTR_PURR))
sysdev_remove_file(s, &attr_purr);
}
#endif /* CONFIG_HOTPLUG_CPU */
^ permalink raw reply
* [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Haren Myneni @ 2006-07-27 21:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: External List, Nathan Lynch, Milton Miller
In-Reply-To: <20060726220441.GZ19076@localdomain>
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Nathan Lynch wrote:
>Looks fine to me from a quick look, but we need to use
>rtas_set_indicator_fast in xics_setup_cpu as well (I think I neglected
>to mention I saw the warning in the cpu up path, sorry).
>
>
>
Posting the modified patch based on Nathan's comment - using
rtas_set_indicator_fast() in xics_setup_cpu(). If Ok, please send it to
upstream.
Thanks
Haren
Noticing the following might_sleep warning (dump_stack()) during kdump
testing when CONFIG_DEBUG_SPINLOCK_SLEEP is enabled. All secondary CPUs
will be calling rtas_set_indicator with interrupts disabled to remove
them from global interrupt queue.
BUG: sleeping function called from invalid context at
arch/powerpc/kernel/rtas.c:463
in_atomic():1, irqs_disabled():1
Call Trace:
[C00000000FFFB970] [C000000000010234] .show_stack+0x68/0x1b0 (unreliable)
[C00000000FFFBA10] [C000000000059354] .__might_sleep+0xd8/0xf4
[C00000000FFFBA90] [C00000000001D1BC] .rtas_busy_delay+0x20/0x5c
[C00000000FFFBB20] [C00000000001D8A8] .rtas_set_indicator+0x6c/0xcc
[C00000000FFFBBC0] [C000000000048BF4] .xics_teardown_cpu+0x118/0x134
[C00000000FFFBC40] [C00000000004539C]
.pseries_kexec_cpu_down_xics+0x74/0x8c
[C00000000FFFBCC0] [C00000000002DF08] .crash_ipi_callback+0x15c/0x188
[C00000000FFFBD50] [C0000000000296EC] .smp_message_recv+0x84/0xdc
[C00000000FFFBDC0] [C000000000048E08] .xics_ipi_dispatch+0xf0/0x130
[C00000000FFFBE50] [C00000000009EF10] .handle_IRQ_event+0x7c/0xf8
[C00000000FFFBF00] [C0000000000A0A14] .handle_percpu_irq+0x90/0x10c
[C00000000FFFBF90] [C00000000002659C] .call_handle_irq+0x1c/0x2c
[C00000000058B9C0] [C00000000000CA10] .do_IRQ+0xf4/0x1a4
[C00000000058BA50] [C0000000000044EC] hardware_interrupt_entry+0xc/0x10
--- Exception: 501 at .plpar_hcall_norets+0x14/0x1c
LR = .pseries_dedicated_idle_sleep+0x190/0x1d4
[C00000000058BD40] [C00000000058BDE0] 0xc00000000058bde0 (unreliable)
[C00000000058BDF0] [C00000000001270C] .cpu_idle+0x10c/0x1e0
[C00000000058BE70] [C000000000009274] .rest_init+0x44/0x5c
To fix this issue, rtas_set_indicator_fast() is added so that will not
wait for RTAS 'busy' delay and this new function is used for kdump (in
xics_teardown_cpu()) and for CPU hotplug ( xics_migrate_irqs_away() and
xics_setup_cpu()).
Signed-off-by: Haren Myneni <haren@us.ibm.com>
[-- Attachment #2: ppc64-add-rtas-set-indicator-fast.patch --]
[-- Type: text/x-patch, Size: 2754 bytes --]
diff -Naurp 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2618-rc2/arch/powerpc/kernel/rtas.c
--- 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2006-07-25 19:34:11.000000000 -0700
+++ 2618-rc2/arch/powerpc/kernel/rtas.c 2006-07-25 19:33:16.000000000 -0700
@@ -569,6 +569,27 @@ int rtas_set_indicator(int indicator, in
}
EXPORT_SYMBOL(rtas_set_indicator);
+/*
+ * Ignoring RTAS extended delay
+ */
+int rtas_set_indicator_fast(int indicator, int index, int new_value)
+{
+ int rc;
+ int token = rtas_token("set-indicator");
+
+ if (token == RTAS_UNKNOWN_SERVICE)
+ return -ENOENT;
+
+ rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
+
+ WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
+
+ if (rc < 0)
+ return rtas_error_rc(rc);
+
+ return rc;
+}
+
void rtas_restart(char *cmd)
{
if (rtas_flash_term_hook)
diff -Naurp 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2618-rc2/arch/powerpc/platforms/pseries/xics.c
--- 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2006-07-25 19:34:41.000000000 -0700
+++ 2618-rc2/arch/powerpc/platforms/pseries/xics.c 2006-07-26 16:30:16.000000000 -0700
@@ -467,7 +467,7 @@ void xics_setup_cpu(void)
*
* XXX: undo of teardown on kexec needs this too, as may hotplug
*/
- rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 - default_distrib_server, 1);
}
@@ -796,7 +796,7 @@ void xics_teardown_cpu(int secondary)
* so leave the master cpu in the group.
*/
if (secondary)
- rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 -
default_distrib_server, 0);
}
@@ -813,7 +813,7 @@ void xics_migrate_irqs_away(void)
xics_set_cpu_priority(cpu, 0);
/* remove ourselves from the global interrupt queue */
- status = rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 - default_distrib_server, 0);
WARN_ON(status < 0);
diff -Naurp 2618-rc2.orig/include/asm-powerpc/rtas.h 2618-rc2/include/asm-powerpc/rtas.h
--- 2618-rc2.orig/include/asm-powerpc/rtas.h 2006-07-25 19:34:27.000000000 -0700
+++ 2618-rc2/include/asm-powerpc/rtas.h 2006-07-25 19:33:57.000000000 -0700
@@ -170,6 +170,7 @@ extern int rtas_get_sensor(int sensor, i
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
extern int rtas_set_indicator(int indicator, int index, int new_value);
+extern int rtas_set_indicator_fast(int indicator, int index, int new_value);
extern void rtas_progress(char *s, unsigned short hex);
extern void rtas_initialize(void);
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 20:35 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154028871.29826.261.camel@goblue>
>> These two lines don't need the msi.o and msi-altix.o AFAICS.
>
> Yup, you are right...updated patch included below.
Looks fine now, thanks.
>>> +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
>>
>> I think this file should live in arch/powerpc, and so should this
>> Makefile fragment.
>
> I'm following the current MSI methodologies where arch specific MSI
> code
> lives in drivers/pci. This is just like msi-altix.c.
True, but our core support lives in arch/. The same is true for PHB
code etc.; if Altix messed this up, that doesn't mean we need to :-)
>> Other than that, can we please have the part that doesn't build the
>> "generic" MSI stuff included ASAP?
This would naturally fall out as a separate patch then, as well.
>>> Index: 2.6-msi/drivers/pci/msi-rtas.c
>>
>> Maybe msi-papr.c is a better name btw? Not that I care :-)
>
> IMHO I don't like PAPR names because they like changing them on a
> whim.
> RTAS is a bit more persistent.
Maybe msi-pseries then? Oh wait, they changed that name too ;-)
> I don't really care...If anyone feels real strongly about it, I'll
> change it.
If you move this code to arch/powerpc/platforms/pseries/, you could
just call it "msi.c". I don't like the msi-rtas name -- but, I don't
feel that strongly about it, just a suggestion.
Segher
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Jake Moilanen @ 2006-07-27 19:34 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <67FD272C-C378-4549-8B35-70912AFAB7EF@kernel.crashing.org>
On Thu, 2006-07-27 at 20:46 +0200, Segher Boessenkool wrote:
> > Index: 2.6-msi/drivers/pci/Makefile
> > ===================================================================
> > --- 2.6-msi.orig/drivers/pci/Makefile
> > +++ 2.6-msi/drivers/pci/Makefile
> > @@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
> > obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
> > obj-$(CONFIG_X86_VISWS) += setup-irq.o
> >
> > -msiobj-y := msi.o msi-apic.o
> > -msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
> > -msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
> > +msiobj-$(CONFIG_X86) += msi.o msi-apic.o
> > +msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
>
> > +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
> > +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
>
> These two lines don't need the msi.o and msi-altix.o AFAICS.
Yup, you are right...updated patch included below.
> > +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
>
> I think this file should live in arch/powerpc, and so should this
> Makefile fragment.
I'm following the current MSI methodologies where arch specific MSI code
lives in drivers/pci. This is just like msi-altix.c.
> > +
> > obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
> >
> > #
>
> Other than that, can we please have the part that doesn't build the
> "generic" MSI stuff included ASAP?
>
> > Index: 2.6-msi/drivers/pci/msi-rtas.c
>
> Maybe msi-papr.c is a better name btw? Not that I care :-)
IMHO I don't like PAPR names because they like changing them on a whim.
RTAS is a bit more persistent.
I don't really care...If anyone feels real strongly about it, I'll
change it.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/prom_init.c | 8 ++
arch/powerpc/platforms/pseries/setup.c | 4 +
arch/powerpc/platforms/pseries/xics.c | 5 -
drivers/pci/Kconfig | 2
drivers/pci/Makefile | 5 +
drivers/pci/msi-rtas.c | 111
+++++++++++++++++++++++++++++++++
include/asm-powerpc/rtas.h | 4 +
7 files changed, 134 insertions(+), 5 deletions(-)
Index: 2.6-msi/drivers/pci/Makefile
===================================================================
--- 2.6-msi.orig/drivers/pci/Makefile
+++ 2.6-msi/drivers/pci/Makefile
@@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
-msiobj-y := msi.o msi-apic.o
+msiobj-$(CONFIG_X86) += msi.o msi-apic.o
+msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
+msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
+
obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
#
Index: 2.6-msi/drivers/pci/msi-rtas.c
===================================================================
--- /dev/null
+++ 2.6-msi/drivers/pci/msi-rtas.c
@@ -0,0 +1,111 @@
+/*
+ * Jake Moilanen <moilanen@austin.ibm.com>
+ * Copyright (C) 2006 IBM
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/pci.h>
+#include <linux/irq.h>
+#include <asm/rtas.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+
+int rtas_enable_msi(struct pci_dev* pdev)
+{
+ static int seq_num = 1;
+ int i;
+ int rc;
+ int query_token = rtas_token("ibm,query-interrupt-source-number");
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ int dummy;
+ int n_intr;
+ int last_virq = NO_IRQ;
+ int virq;
+ unsigned int addr;
+ unsigned long buid = -1;
+ struct device_node * dn;
+
+ dn = pci_device_to_OF_node(pdev);
+
+ if (!of_find_property(dn, "ibm,req#msi", &dummy))
+ return -ENOENT;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return -ENXIO;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ do {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 0, 0, seq_num);
+
+ seq_num = ret[1];
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_WARNING "error[%d]: getting the number of "
+ "MSI interrupts for %s\n", rc, dn->name);
+ return -EIO;
+ }
+
+ /* Return if there's no MSI interrupts */
+ if (!ret[0])
+ return -ENOENT;
+
+ n_intr = ret[0];
+
+ for (i = 0; i < n_intr; i++) {
+ do {
+ rc = rtas_call(query_token, 4, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff, i);
+ } while (rtas_busy_delay(rc));
+
+ if (!rc) {
+ virq = irq_create_mapping(irq_find_host(dn), ret[0],
+ ret[1] ? IRQ_TYPE_EDGE_RISING :
+ IRQ_TYPE_LEVEL_LOW);
+
+ /* for now, take the last valid vector given out */
+ if (virq != NO_IRQ)
+ last_virq = virq;
+
+ } else {
+ printk(KERN_WARNING "error[%d]: "
+ "query-interrupt-source-number for %s\n",
+ rc, dn->name);
+ }
+ }
+
+ /*
+ * If we can't get any MSI vectors, fail and try falling
+ * back to LSI
+ */
+ if (last_virq == NO_IRQ)
+ return -EIO;
+
+ pdev->irq = last_virq;
+
+ return 0;
+}
+
+void rtas_disable_msi(struct pci_dev* pdev)
+{
+ /*
+ * for now, we don't give firmware back vectors to their pool
+ */
+}
Index: 2.6-msi/drivers/pci/Kconfig
===================================================================
--- 2.6-msi.orig/drivers/pci/Kconfig
+++ 2.6-msi/drivers/pci/Kconfig
@@ -4,7 +4,7 @@
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
+ depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || PPC_PSERIES
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
Index: 2.6-msi/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/setup.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/setup.c
@@ -267,6 +267,10 @@ static void __init pseries_discover_pic(
return;
} else if (strstr(typep, "ppc-xicp")) {
ppc_md.init_IRQ = xics_init_IRQ;
+#ifdef CONFIG_PCI_MSI
+ ppc_md.enable_msi = rtas_enable_msi;
+ ppc_md.disable_msi = rtas_disable_msi;
+#endif
#ifdef CONFIG_KEXEC
ppc_md.kexec_cpu_down = pseries_kexec_cpu_down_xics;
#endif
Index: 2.6-msi/include/asm-powerpc/rtas.h
===================================================================
--- 2.6-msi.orig/include/asm-powerpc/rtas.h
+++ 2.6-msi/include/asm-powerpc/rtas.h
@@ -4,6 +4,7 @@
#include <linux/spinlock.h>
#include <asm/page.h>
+#include <linux/pci.h>
/*
* Definitions for talking to the RTAS on CHRP machines.
@@ -186,6 +187,9 @@ extern int early_init_dt_scan_rtas(unsig
extern void pSeries_log_error(char *buf, unsigned int err_type, int
fatal);
+extern int rtas_enable_msi(struct pci_dev* pdev);
+extern void rtas_disable_msi(struct pci_dev * pdev);
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
Index: 2.6-msi/arch/powerpc/kernel/prom_init.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/kernel/prom_init.c
+++ 2.6-msi/arch/powerpc/kernel/prom_init.c
@@ -632,6 +632,12 @@ static void __init early_cmdline_parse(v
/* ibm,dynamic-reconfiguration-memory property supported */
#define OV5_DRCONF_MEMORY 0x20
#define OV5_LARGE_PAGES 0x10 /* large pages supported */
+/* PCIe/MSI support. Without MSI full PCIe is not supported */
+#ifdef CONFIG_PCI_MSI
+#define OV5_MSI 0x01 /* PCIe/MSI support */
+#else
+#define OV5_MSI 0x00
+#endif /* CONFIG_PCI_MSI */
/*
* The architecture vector has an array of PVR mask/value pairs,
@@ -675,7 +681,7 @@ static unsigned char ibm_architecture_ve
/* option vector 5: PAPR/OF options */
3 - 1, /* length */
0, /* don't ignore, don't halt */
- OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES,
+ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_MSI,
};
/* Old method - ELF header with PT_NOTE sections */
Index: 2.6-msi/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/xics.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/xics.c
@@ -526,11 +526,12 @@ static int xics_host_map_lpar(struct irq
pr_debug("xics: map_lpar virq %d, hwirq 0x%lx, flags: 0x%x\n",
virq, hw, flags);
- if (sense && sense != IRQ_TYPE_LEVEL_LOW)
+ if (sense && !(sense & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_RISING)))
printk(KERN_WARNING "xics: using unsupported sense 0x%x"
" for irq %d (h: 0x%lx)\n", flags, virq, hw);
- get_irq_desc(virq)->status |= IRQ_LEVEL;
+ if (sense && sense & IRQ_TYPE_LEVEL_LOW)
+ get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, &xics_pic_lpar, handle_fasteoi_irq);
return 0;
}
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: Sylvain Munaut @ 2006-07-27 19:15 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0607271030o7170e8dcn28bd3f62ec243426@mail.gmail.com>
Hi John,
Frankly ... I don't know, I don't get how this new thing works ...
if you figure it out, be my guest do it and explain it to me ;)
It would be great because I get this cleaned API sitting on my
tree along with the IDE DMA and the FEC code that I'd really
like to send ...
Sylvain
John Rigby wrote:
> Sylvain,
>
> How can I help getting the mpc5200 migrated to the powerpc tree?
> I should have some time to help with this.
>
> After we get it migrated we can get the bestcomm code in and
> the various drivers that use it.
>
> Also, did you ever get a liteb board? If not send me your address
> and I will try again to get you one.
>
> Thanks
> John
>
> On 7/17/06, Sylvain Munaut <tnt@246tnt.com> wrote:
>> Benjamin Herrenschmidt wrote:
>> >> But anyway, it's mainly internal cleanup and adapting drivers
>> >> from the public version on my git tree to this newest/cleaner
>> >> version is a 15 min work ;)
>> >>
>> >
>> > Any reason why you aren't regulary submitting those patches for
>> upstream
>> > inclusion ?
>> >
>> Yes. What's in there and not in main streams adds quite a lot to
>> arch/ppc ... So
>> MPC5200 should be adapted to arch/powerpc first and then those changes.
>> And since
>> no-one did that yet and I haven't done it yet either ... (I must admit I
>> had a quick look
>> and I didn't understand much on how to do the change ...)
>>
>>
>> Sylvain
>>
>>
>> PS: Sorry for the lag (like 15 days...) you know email
>> problem/appartement change/vacation/... the usual ;)
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 18:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <67FD272C-C378-4549-8B35-70912AFAB7EF@kernel.crashing.org>
>> +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
>> +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
>
> These two lines don't need the msi.o and msi-altix.o AFAICS.
s/altix/apic/. Duh.
Segher
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 18:46 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024834.29826.240.camel@goblue>
> Index: 2.6-msi/drivers/pci/Makefile
> ===================================================================
> --- 2.6-msi.orig/drivers/pci/Makefile
> +++ 2.6-msi/drivers/pci/Makefile
> @@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
> obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
> obj-$(CONFIG_X86_VISWS) += setup-irq.o
>
> -msiobj-y := msi.o msi-apic.o
> -msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
> -msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
> +msiobj-$(CONFIG_X86) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
> +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
These two lines don't need the msi.o and msi-altix.o AFAICS.
> +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
I think this file should live in arch/powerpc, and so should this
Makefile fragment.
> +
> obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
>
> #
Other than that, can we please have the part that doesn't build the
"generic" MSI stuff included ASAP?
> Index: 2.6-msi/drivers/pci/msi-rtas.c
Maybe msi-papr.c is a better name btw? Not that I care :-)
No comments on your actual code, sorry.
Segher
^ permalink raw reply
* Re: [PATCH][1/2] export msi symbols
From: Segher Boessenkool @ 2006-07-27 18:41 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024245.29826.231.camel@goblue>
> Forgot to export symbols for MSI.
>
> Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* [PATCH][2/2] RTAS MSI
From: Jake Moilanen @ 2006-07-27 18:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1154024154.29826.229.camel@goblue>
Rebased with the IRQ layer rewrite. The code is not deallocating the
vectors on a pci_disable_msi(). This is to work around a firmware
vector release bug. Plus it is really not needed, as
irq_create_mapping() just returns mappings to irqs that it knows of.
Additionally, the patch includes the client architecture bit for MSI,
and correctly identifying that MSI is edge triggered.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/prom_init.c | 8 ++
arch/powerpc/platforms/pseries/setup.c | 4 +
arch/powerpc/platforms/pseries/xics.c | 5 -
drivers/pci/Kconfig | 2
drivers/pci/Makefile | 9 +-
drivers/pci/msi-rtas.c | 111
+++++++++++++++++++++++++++++++++
include/asm-powerpc/rtas.h | 4 +
7 files changed, 136 insertions(+), 7 deletions(-)
Index: 2.6-msi/drivers/pci/Makefile
===================================================================
--- 2.6-msi.orig/drivers/pci/Makefile
+++ 2.6-msi/drivers/pci/Makefile
@@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
-msiobj-y := msi.o msi-apic.o
-msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
-msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
+msiobj-$(CONFIG_X86) += msi.o msi-apic.o
+msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
+msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
+msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
+msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
+
obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
#
Index: 2.6-msi/drivers/pci/msi-rtas.c
===================================================================
--- /dev/null
+++ 2.6-msi/drivers/pci/msi-rtas.c
@@ -0,0 +1,111 @@
+/*
+ * Jake Moilanen <moilanen@austin.ibm.com>
+ * Copyright (C) 2006 IBM
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/pci.h>
+#include <linux/irq.h>
+#include <asm/rtas.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+
+int rtas_enable_msi(struct pci_dev* pdev)
+{
+ static int seq_num = 1;
+ int i;
+ int rc;
+ int query_token = rtas_token("ibm,query-interrupt-source-number");
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ int dummy;
+ int n_intr;
+ int last_virq = NO_IRQ;
+ int virq;
+ unsigned int addr;
+ unsigned long buid = -1;
+ struct device_node * dn;
+
+ dn = pci_device_to_OF_node(pdev);
+
+ if (!of_find_property(dn, "ibm,req#msi", &dummy))
+ return -ENOENT;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return -ENXIO;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ do {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 0, 0, seq_num);
+
+ seq_num = ret[1];
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_WARNING "error[%d]: getting the number of "
+ "MSI interrupts for %s\n", rc, dn->name);
+ return -EIO;
+ }
+
+ /* Return if there's no MSI interrupts */
+ if (!ret[0])
+ return -ENOENT;
+
+ n_intr = ret[0];
+
+ for (i = 0; i < n_intr; i++) {
+ do {
+ rc = rtas_call(query_token, 4, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff, i);
+ } while (rtas_busy_delay(rc));
+
+ if (!rc) {
+ virq = irq_create_mapping(irq_find_host(dn), ret[0],
+ ret[1] ? IRQ_TYPE_EDGE_RISING :
+ IRQ_TYPE_LEVEL_LOW);
+
+ /* for now, take the last valid vector given out */
+ if (virq != NO_IRQ)
+ last_virq = virq;
+
+ } else {
+ printk(KERN_WARNING "error[%d]: "
+ "query-interrupt-source-number for %s\n",
+ rc, dn->name);
+ }
+ }
+
+ /*
+ * If we can't get any MSI vectors, fail and try falling
+ * back to LSI
+ */
+ if (last_virq == NO_IRQ)
+ return -EIO;
+
+ pdev->irq = last_virq;
+
+ return 0;
+}
+
+void rtas_disable_msi(struct pci_dev* pdev)
+{
+ /*
+ * for now, we don't give firmware back vectors to their pool
+ */
+}
Index: 2.6-msi/drivers/pci/Kconfig
===================================================================
--- 2.6-msi.orig/drivers/pci/Kconfig
+++ 2.6-msi/drivers/pci/Kconfig
@@ -4,7 +4,7 @@
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
+ depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || PPC_PSERIES
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
Index: 2.6-msi/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/setup.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/setup.c
@@ -267,6 +267,10 @@ static void __init pseries_discover_pic(
return;
} else if (strstr(typep, "ppc-xicp")) {
ppc_md.init_IRQ = xics_init_IRQ;
+#ifdef CONFIG_PCI_MSI
+ ppc_md.enable_msi = rtas_enable_msi;
+ ppc_md.disable_msi = rtas_disable_msi;
+#endif
#ifdef CONFIG_KEXEC
ppc_md.kexec_cpu_down = pseries_kexec_cpu_down_xics;
#endif
Index: 2.6-msi/include/asm-powerpc/rtas.h
===================================================================
--- 2.6-msi.orig/include/asm-powerpc/rtas.h
+++ 2.6-msi/include/asm-powerpc/rtas.h
@@ -4,6 +4,7 @@
#include <linux/spinlock.h>
#include <asm/page.h>
+#include <linux/pci.h>
/*
* Definitions for talking to the RTAS on CHRP machines.
@@ -186,6 +187,9 @@ extern int early_init_dt_scan_rtas(unsig
extern void pSeries_log_error(char *buf, unsigned int err_type, int
fatal);
+extern int rtas_enable_msi(struct pci_dev* pdev);
+extern void rtas_disable_msi(struct pci_dev * pdev);
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
Index: 2.6-msi/arch/powerpc/kernel/prom_init.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/kernel/prom_init.c
+++ 2.6-msi/arch/powerpc/kernel/prom_init.c
@@ -632,6 +632,12 @@ static void __init early_cmdline_parse(v
/* ibm,dynamic-reconfiguration-memory property supported */
#define OV5_DRCONF_MEMORY 0x20
#define OV5_LARGE_PAGES 0x10 /* large pages supported */
+/* PCIe/MSI support. Without MSI full PCIe is not supported */
+#ifdef CONFIG_PCI_MSI
+#define OV5_MSI 0x01 /* PCIe/MSI support */
+#else
+#define OV5_MSI 0x00
+#endif /* CONFIG_PCI_MSI */
/*
* The architecture vector has an array of PVR mask/value pairs,
@@ -675,7 +681,7 @@ static unsigned char ibm_architecture_ve
/* option vector 5: PAPR/OF options */
3 - 1, /* length */
0, /* don't ignore, don't halt */
- OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES,
+ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_MSI,
};
/* Old method - ELF header with PT_NOTE sections */
Index: 2.6-msi/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/xics.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/xics.c
@@ -526,11 +526,12 @@ static int xics_host_map_lpar(struct irq
pr_debug("xics: map_lpar virq %d, hwirq 0x%lx, flags: 0x%x\n",
virq, hw, flags);
- if (sense && sense != IRQ_TYPE_LEVEL_LOW)
+ if (sense && !(sense & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_RISING)))
printk(KERN_WARNING "xics: using unsupported sense 0x%x"
" for irq %d (h: 0x%lx)\n", flags, virq, hw);
- get_irq_desc(virq)->status |= IRQ_LEVEL;
+ if (sense && sense & IRQ_TYPE_LEVEL_LOW)
+ get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, &xics_pic_lpar, handle_fasteoi_irq);
return 0;
}
^ permalink raw reply
* [PATCH][1/2] export msi symbols
From: Jake Moilanen @ 2006-07-27 18:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1154024154.29826.229.camel@goblue>
Forgot to export symbols for MSI.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/irq.c | 5 +++++
1 files changed, 5 insertions(+)
Index: 2.6-msi/arch/powerpc/kernel/irq.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/kernel/irq.c
+++ 2.6-msi/arch/powerpc/kernel/irq.c
@@ -52,6 +52,7 @@
#include <linux/radix-tree.h>
#include <linux/mutex.h>
#include <linux/bootmem.h>
+#include <linux/pci.h>
#include <asm/uaccess.h>
#include <asm/system.h>
@@ -818,12 +819,14 @@ int pci_enable_msi(struct pci_dev * pdev
else
return -1;
}
+EXPORT_SYMBOL(pci_enable_msi);
void pci_disable_msi(struct pci_dev * pdev)
{
if (ppc_md.disable_msi)
ppc_md.disable_msi(pdev);
}
+EXPORT_SYMBOL(pci_disable_msi);
void pci_scan_msi_device(struct pci_dev *dev) {}
int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries,
int nvec) {return -1;}
@@ -831,6 +834,8 @@ void pci_disable_msix(struct pci_dev *de
void msi_remove_pci_irq_vectors(struct pci_dev *dev) {}
void disable_msi_mode(struct pci_dev *dev, int pos, int type) {}
void pci_no_msi(void) {}
+EXPORT_SYMBOL(pci_enable_msix);
+EXPORT_SYMBOL(pci_disable_msix);
#endif
^ permalink raw reply
* [PATCH][0/2] RTAS MSI
From: Jake Moilanen @ 2006-07-27 18:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Here is a rebased RTAS MSI which uses the IRQ layer rewrite. Please try
getting it into 2.6.18.
I mistakenly forgot to export the MSI symbols. So modules weren't too
happy...
The RTAS patch skips the intel-centric MSI layer and uses
pci_enable/disable_msi() calls directly. It does not correctly handle
multi-vector MSI either.
^ permalink raw reply
* Fw: AvNet FX12 Mini Modules
From: Ing.Gianfranco Morandi @ 2006-07-27 17:49 UTC (permalink / raw)
To: Linux PPC Embedded
Hello everyone,
I would like to start using the AvNet FX12 Mini module in our embedded
project and unfotunately I do not have a great knowledge on how to use linux
on FPGA.
Can anyone give me any suggestions or reference project where I can start?
any suggestions would be apreciated.
regards
Gianfranco
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: John Rigby @ 2006-07-27 17:30 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <44BC0B9A.5010103@246tNt.com>
Sylvain,
How can I help getting the mpc5200 migrated to the powerpc tree?
I should have some time to help with this.
After we get it migrated we can get the bestcomm code in and
the various drivers that use it.
Also, did you ever get a liteb board? If not send me your address
and I will try again to get you one.
Thanks
John
On 7/17/06, Sylvain Munaut <tnt@246tnt.com> wrote:
> Benjamin Herrenschmidt wrote:
> >> But anyway, it's mainly internal cleanup and adapting drivers
> >> from the public version on my git tree to this newest/cleaner
> >> version is a 15 min work ;)
> >>
> >
> > Any reason why you aren't regulary submitting those patches for upstream
> > inclusion ?
> >
> Yes. What's in there and not in main streams adds quite a lot to
> arch/ppc ... So
> MPC5200 should be adapted to arch/powerpc first and then those changes.
> And since
> no-one did that yet and I haven't done it yet either ... (I must admit I
> had a quick look
> and I didn't understand much on how to do the change ...)
>
>
> Sylvain
>
>
> PS: Sorry for the lag (like 15 days...) you know email
> problem/appartement change/vacation/... the usual ;)
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Where to store the Linux kernel.
From: Tony Lee @ 2006-07-27 16:52 UTC (permalink / raw)
To: Frank D Lombardo; +Cc: linuxppc-embedded
In-Reply-To: <44C8DC19.9030600@mdivac.com>
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
I used the VP20 before. You can use the Xilinx's tool to generate the .ace
file from the .elf, bit stream, etc and put it in the CF.
It is very simple ponce you do it once and Xilinx has very good app note to
tell you exactly what need to do.
-Tony
On 7/27/06, Frank D Lombardo <lombardo@mdivac.com> wrote:
>
> Ming,
>
> I am using an ML403 in a similar way. I have the download.bit file
> stored in platform flash. U-Boot, the Linux Kernel and initrd are stored
> in the linear flash.
>
> Frank
>
>
> Ming Liu wrote:
> > Hello everyone,
> > Now I am doing a embedded linux project on the board of ML403(virtex4,
> > ppc405). In my product, I cannot use CF card. So I have to use flash
> memory
> > to store the Linux kernel. Except for the Linux kernel, also I have to
> > store the hardware information of the system.bit file. I know in ml403
> > board, there are two types of flash. One is Platform Flash and the other
> is
> > Linear Flash. Can anyone tell me how can I arrange my hardware .bit file
> > and Linux kernel zImage.elf file and store them in the flash provided in
> > the board? Can I put both of them in the Platform Flash chip? Thanks for
> > the telling.
> >
> > Regards
> > Ming
> >
> > _________________________________________________________________
> > 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
-Tony
Having fun with FPGA, gige, mpeg, snmp, ppc, Linux
[-- Attachment #2: Type: text/html, Size: 2488 bytes --]
^ permalink raw reply
* Re: Where to store the Linux kernel.
From: Frank D Lombardo @ 2006-07-27 15:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY110-F64D7B98642F2626AA4E90B2580@phx.gbl>
Ming,
I am using an ML403 in a similar way. I have the download.bit file
stored in platform flash. U-Boot, the Linux Kernel and initrd are stored
in the linear flash.
Frank
Ming Liu wrote:
> Hello everyone,
> Now I am doing a embedded linux project on the board of ML403(virtex4,
> ppc405). In my product, I cannot use CF card. So I have to use flash memory
> to store the Linux kernel. Except for the Linux kernel, also I have to
> store the hardware information of the system.bit file. I know in ml403
> board, there are two types of flash. One is Platform Flash and the other is
> Linear Flash. Can anyone tell me how can I arrange my hardware .bit file
> and Linux kernel zImage.elf file and store them in the flash provided in
> the board? Can I put both of them in the Platform Flash chip? Thanks for
> the telling.
>
> Regards
> Ming
>
> _________________________________________________________________
> 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Can 750 user-mode binaries run on a 603e core?
From: Kumar Gala @ 2006-07-27 15:37 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Patrick J. Kelsey
In-Reply-To: <5744F4FC-32DC-4F24-9FD4-E6CAC4AFA6A4@freescale.com>
On Jul 27, 2006, at 10:30 AM, Andy Fleming wrote:
> Branch delay slots are evil, and PowerPC did not use them.
>
> 'nuff said.
>
> Pretty much any powerpc binary should work on any PowerPC system.
> Actually, we use a 603-compiled root file system for our e500
> processors (in our lab), and don't run into any problems. This is
Let's be clear, that is done by emulating the floating point
instructions in the kernel. (And there are a few user space integer/
control instructions that e500 doesn't implement, but your rarely run
into them).
- k
> On Jul 27, 2006, at 07:36, Jerry Van Baren wrote:
>
>> Patrick J. Kelsey wrote:
>>> (sorry about that last one. had a bit of trouble with a certain
>>> web based mail client...)
>>>
>>> Thanks for the reply, Kumar.
>>>
>>> That sounds encouraging. One of the things I was worried about with
>>> scheduling differences would be a differing number of branch delay
>>> slots between the two core versions. I'm still a bit new to the
>>> details of the PowerPC architecture, and at this point I'm not even
>>> sure if there are branch delay slots, although it does seem from my
>>> reading that the 603e and 750 pipelines are the same, in which case
>>> there would ceratinly be no worries here.
>>
>> FWIIW, the PowerPC architecture has hardware instruction interlocking
>> and scheduling and doesn't require the compiler to implement the
>> branch
>> delay slots like, for instance, the MIPS architecture. This is much
>> more compiler and portability friendly, but at the expense of more
>> logic
>> in the processor (the PowerPC is not nearly as minimalistic as the
>> MIPS).
>>
>>> At this point, I'm not concerned so much about an inefficient
>>> schedule resulting from running -mcpu=750 code on a 603e as long as
>>> the execution is correct.
>>>
>>> Pat
>>
>> gvb
>> _______________________________________________
>> 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
^ permalink raw reply
* Re: Can 750 user-mode binaries run on a 603e core?
From: Andy Fleming @ 2006-07-27 15:30 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Patrick J. Kelsey
In-Reply-To: <44C8B330.7030600@smiths-aerospace.com>
Branch delay slots are evil, and PowerPC did not use them.
'nuff said.
Pretty much any powerpc binary should work on any PowerPC system.
Actually, we use a 603-compiled root file system for our e500
processors (in our lab), and don't run into any problems. This is
On Jul 27, 2006, at 07:36, Jerry Van Baren wrote:
> Patrick J. Kelsey wrote:
>> (sorry about that last one. had a bit of trouble with a certain
>> web based mail client...)
>>
>> Thanks for the reply, Kumar.
>>
>> That sounds encouraging. One of the things I was worried about with
>> scheduling differences would be a differing number of branch delay
>> slots between the two core versions. I'm still a bit new to the
>> details of the PowerPC architecture, and at this point I'm not even
>> sure if there are branch delay slots, although it does seem from my
>> reading that the 603e and 750 pipelines are the same, in which case
>> there would ceratinly be no worries here.
>
> FWIIW, the PowerPC architecture has hardware instruction interlocking
> and scheduling and doesn't require the compiler to implement the
> branch
> delay slots like, for instance, the MIPS architecture. This is much
> more compiler and portability friendly, but at the expense of more
> logic
> in the processor (the PowerPC is not nearly as minimalistic as the
> MIPS).
>
>> At this point, I'm not concerned so much about an inefficient
>> schedule resulting from running -mcpu=750 code on a 603e as long as
>> the execution is correct.
>>
>> Pat
>
> gvb
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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