* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160029594.22232.22.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
>
> Regarding the "mess", it's the whole #ifdef junk in there that is
> driving me nuts and that I'll rip appart probably next week. A lot of
> this could be soft-tests or the ifdefs could be resolved at Kconfig
> instead of having a list of processors in 3 different headers if you
> really want to compile the changes in rather than do soft-tests.
Well, sent me changes for review, or become a maintainer, but this
time _real_ maintainer, not like last time when you touched this code.
--
Eugene
^ permalink raw reply
* [PATCH] powerpc: Don't get PCI IRQ from OF for devices with no IRQ
From: Benjamin Herrenschmidt @ 2006-10-05 6:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
This patch adds checking of the PCI_INTERRUPT_PIN register before
using standard OF parsing to retreive PCI interrupts. The reason is
that some PCI devices may have no PCI interrupt, though they may have
interrupts attached via other means. In this case, we shall not use
irq->pdev, but device-specific code can later retreive those interrupts
instead.
Without that patch, Maple and derivatives don't get the right interrupt
for the second IDE channel as the linux IDE code fallsback to the PCI
irq instead of trying to use the legacy ones for the on-board controller
(which has no PCI_INTERRUPT_PIN). Having no PCI IRQ assign to it (as it
doesn't request any) fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2006-10-03 12:41:03.000000000 +1000
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2006-10-05 16:33:25.000000000 +1000
@@ -914,6 +914,17 @@ int of_irq_map_pci(struct pci_dev *pdev,
u8 pin;
int rc;
+ /* We need to first check if the PCI device has a PCI interrupt at all
+ * since we have cases where the device-node might expose non-PCI
+ * interrupts, but the device has no PCI interrupt to it
+ */
+ rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
+ if (rc != 0)
+ return rc;
+ /* No pin, exit */
+ if (pin == 0)
+ return -ENODEV;
+
/* Check if we have a device node, if yes, fallback to standard OF
* parsing
*/
@@ -925,12 +936,6 @@ int of_irq_map_pci(struct pci_dev *pdev,
* interrupt spec. we assume #interrupt-cells is 1, which is standard
* for PCI. If you do different, then don't use that routine.
*/
- rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
- if (rc != 0)
- return rc;
- /* No pin, exit */
- if (pin == 0)
- return -ENODEV;
/* Now we walk up the PCI tree */
lspec = pin;
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-05 6:51 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <20061005063304.GD1985@gate.ebshome.net>
On Wed, 2006-10-04 at 23:33 -0700, Eugene Surovegin wrote:
> On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> >
> > Regarding the "mess", it's the whole #ifdef junk in there that is
> > driving me nuts and that I'll rip appart probably next week. A lot of
> > this could be soft-tests or the ifdefs could be resolved at Kconfig
> > instead of having a list of processors in 3 different headers if you
> > really want to compile the changes in rather than do soft-tests.
>
> Well, sent me changes for review, or become a maintainer, but this
> time _real_ maintainer, not like last time when you touched this code.
Well, last time I touched this code, I took something that was not
working at all and made it work for me and a couple of other people that
were working on it at the same time. If it had issues, they were never
reported to me back then. However, I never intended to do long term
maintainership of this driver and that was clear from the very
beginning. If you ran into other issues and fixed them afterward, that's
fine, but don't blame me for not fixing issues I didn't encounter nor
was told about for the short time while I was taking care of it.
Anyway, my point is, the per-processor ifdef lists are just fugly and
need to be turned into "soft" changes. The driver also needs to get some
OF probing and use the new DCR accessors to move over to powerpc and to
work with the EMAC cell within the new Cell southbridge.
I have some preliminary patches doing just the OF probing and DCR
changes. I still want to do some serious change of the #ifdef mess into
something more flexible to allow for runtime choice of the type of EMAC
and MAL.
I'll post patches (and possibly incremental "cleanup") to the list,
CC'ing you, as expected for a driver you maintain.
Ben.
^ permalink raw reply
* Re: booting 2.6 kernel on ML403
From: Ameet Patil @ 2006-10-05 8:27 UTC (permalink / raw)
To: Pradeep Sampath; +Cc: linuxppc-embedded
In-Reply-To: <20061004163517.17874.qmail@web83207.mail.mud.yahoo.com>
Hi Pradeep,
Pradeep Sampath wrote:
> Hello Ameet/Ming,
>
> First of all really appreciate your inputs on this...
> Problem 1 :
> I was using the factory shipped compact flash as is which comes with a
> DOS FAT16 partition and a linux 83 partition with ext3 filesystem.
> I tried it on 2 factory shipped CFs and its the same behavior - . When
> i plug-in the CF card reader to the linux box it always reads it as
> "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the
> device file for SCSI disk devices. Wonerding how you guys configured
> the root option as "/dev/xsa".
xsa and sda are nothing but the device name registered by the driver. It
is not related to whether the device is a SCSI or not. Since I wrote the
SysAce driver, I decided to name it as xsa (as opposed to the original
Monta Vista xsysace). Thus, all the partitions on this device will be
named xsa1 for the first partition, xsa2 for the second and so on.
When you access your CF card in your Linux PC, the driver names the
device as sda. Thats all... theres no much difference. Hope you got the
point.
cheers,
-Ameet
>
> Now i re-formatted my CF, created a ext2 filesystem using
> busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF
> card 1. FAT16 partition & 2. linux partition and then created 1. dos
> file system using mkdosfs and 2. linux ext2 filesystem using mke2fs.
>
> But the problem still persists and i get "Please append a correct
> "root=" boot option :"
> :(
>
> Problem 2: After i included the TEMAC driver and sysace drivers,
> the kernel just hangs. I thought i'll fix problem 1 before i get to
> problem 2...
>
> With your help i am getting the confidence that i can make this all work!
> thanks once again.
> -Pradeep
>
>
>
> */Ming Liu <eemingliu@hotmail.com>/* wrote:
>
> Hello Ameet,
> I am using that driver very well now. There is only one problem.
> It seems
> that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M
> adapted. But because I want to use the Gigabit enet, I don't care
> that. So
> it's OK, at lease for 1Gbit/s.
>
> So I don't think Pradeep's problem is caused by Temac. I still
> suspect that
> he didn't pass a right parameter to "root=", just like what I posted
> before.
>
> Regards
> Ming
>
>
> >From: Ameet Patil
> >To: Ming Liu
> >CC: pradeepsampath@yahoo.com, linuxppc-embedded@ozlabs.org
> >Subject: Re: booting 2.6 kernel on ML403
> >Date: Wed, 04 Oct 2006 09:35:07 +0100
> >
> >Ming Liu wrote:
> > > Hi,
> > >
> > >> [ 3.093694] TCP bic registered
> > >> [ 3.129458] NET: Registered protocol family 8
> > >> [ 3.181412] NET: Registered protocol family 20
> > >> [ 3.236744] VFS: Cannot open root device "xsa2" or
> unknown-block(0,0)
> > >> [ 3.313092] Please append a correct "root=" boot option
> > >
> > > It looks that some errors still exist in the parameters you
> passed to
> > > "root=". Please double check it, or post it in the maillist
> for deep
> > > analysis.
> > > Regards
> > > Ming
> > >
> > > _________________________________________________________________
> > > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£
> http://www.hotmail.com
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >Hi Ming,
> >IIRC, you are or were using the TEMAC driver along with my System Ace
> >driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for
> >you? I ask this because Pradeep is having some problems using it (see
> >Problem 2 in his email). Could you please update on this?
> >
> >Thanks,
> >-Ameet
>
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà 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: booting 2.6 kernel on ML403
From: Ameet Patil @ 2006-10-05 8:30 UTC (permalink / raw)
To: Pradeep Sampath; +Cc: linuxppc-embedded
In-Reply-To: <20061004164721.22885.qmail@web83207.mail.mud.yahoo.com>
Pradeep,
What you have pasted is only part of the messages displayed. I can't
tell anything from this apart from you 'root=' option. It would be nice
if you could paste the entire log of the boot messages right from
'loaded at: xxxxxxx xxxxxxxx' to 'Kernel Rebooting in 150 seconds'.
-Ameet
Pradeep Sampath wrote:
> Ameet,
>
> loaded at: 00400000 0051513C
> board data at: 00513124 0051313C
> relocated to: 004050E8 00405100
> zimage at: 004057FD 0051230A
> avail ram: 00516000 04000000
> Linux/PPC load: console=ttyS0,9600 root=/dev/xsa2
> Uncompressing Linux...done.
> Now booting the kernel
>
>
> Please could send me all the boot messages until the point where it
> stops. This will help me better identify the problem.
>
> Thanks,
> -Ameet
>
>
^ permalink raw reply
* Re: [PATCH] linux,tce-size property is 32 bits
From: Benjamin Herrenschmidt @ 2006-10-05 9:18 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, matthltc
In-Reply-To: <20061005032800.GH24705@localdomain>
On Wed, 2006-10-04 at 22:28 -0500, Nathan Lynch wrote:
> The "linux,tce-size" property is only 32 bits (see
> prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
> Treating it as an unsigned long in iommu_table_setparms() leads to
> access beyond the end of the property's buffer, so we pass garbage to
> the memset() in that function.
Probably needs to go into stable as well. Do you know if RHEL5 is
affected too ?
Cheers
Ben.
> [boot]0020 XICS Init
> i8259 legacy interrupt controller initialized
> [boot]0021 XICS Done
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> cpu 0x0: Vector: 300 (Data Access) at [c0000000fe783850]
> pc: c000000000035e90: .memset+0x60/0xfc
> lr: c000000000044fa4: .iommu_table_setparms+0xb0/0x158
> sp: c0000000fe783ad0
> msr: 9000000000009032
> dar: c000000100000000
> dsisr: 42010000
> current = 0xc00000000450e810
> paca = 0xc000000000411580
> pid = 1, comm = swapper
> enter ? for help
> [link register ] c000000000044fa4 .iommu_table_setparms+0xb0/0x158
> [c0000000fe783ad0] c000000000044f4c .iommu_table_setparms+0x58/0x158
> (unreliable)
> [c0000000fe783b70] c00000000004529c
> .iommu_bus_setup_pSeries+0x1c4/0x254
> [c0000000fe783c00] c00000000002b8ac .do_bus_setup+0x3c/0xe4
> [c0000000fe783c80] c00000000002c924 .pcibios_fixup_bus+0x64/0xd8
> [c0000000fe783d00] c0000000001a2d5c .pci_scan_child_bus+0x6c/0x10c
> [c0000000fe783da0] c00000000002be28 .scan_phb+0x17c/0x1b4
> [c0000000fe783e40] c0000000003cfa00 .pcibios_init+0x58/0x19c
> [c0000000fe783ec0] c0000000000094b4 .init+0x1e8/0x3d8
> [c0000000fe783f90] c000000000026e54 .kernel_thread+0x4c/0x68
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
>
> ---
>
> I believe this is a regression since 2.6.18, so please push for
> inclusion in 2.6.19.
>
>
> --- linux-2.6.git.orig/arch/powerpc/platforms/pseries/iommu.c
> +++ linux-2.6.git/arch/powerpc/platforms/pseries/iommu.c
> @@ -267,7 +267,8 @@ static void iommu_table_setparms(struct
> struct iommu_table *tbl)
> {
> struct device_node *node;
> - const unsigned long *basep, *sizep;
> + const unsigned long *basep;
> + const u32 *sizep;
>
> node = (struct device_node *)phb->arch_data;
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehea bug fix (port state notification, default queue sizes)
From: Jeff Garzik @ 2006-10-05 11:30 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
In-Reply-To: <200609281244.40887.ossthema@de.ibm.com>
which patch is to be applied first?
You failed to include an order, as described by
http://linux.yyz.us/patch-format.html and Documentation/SubmittingPatches.
Also, stuff like "hi Jeff" and "Thanks, Jan-Bernd" must be hand-edited
out before patch application. All comments not intended to be DIRECTLY
copied into the kernel changeset description should follow the "---"
separator.
Jeff
^ permalink raw reply
* Compiler Question
From: wei.li4 @ 2006-10-05 13:29 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
It seems that there is a rule that Compiler or Linker assigns r3, r4
... to the arguments of C function when it is called, and r1 is the
address of Stack Pointer, and how is for r0 and r2? where can I find
these rules? Thanks.
Wei
^ permalink raw reply
* Re: [PATCH] powerpc: Enable DEEPNAP power savings mode on 970MP
From: Olof Johansson @ 2006-10-05 14:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <1160026464.22232.16.camel@localhost.localdomain>
On Thu, 05 Oct 2006 15:34:24 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Isn't deep nap supposed to only get entered from F/4 which we never
> use ?
>
> Ben confused...
Nope.
The User Manual clearly talks about going in/out of deep nap from the
different powertune frequencies, see for example section 6.4.2 and 9.4.2.
-Olof
^ permalink raw reply
* Re: Compiler Question
From: Becky Bruce @ 2006-10-05 14:28 UTC (permalink / raw)
To: wei.li4; +Cc: linuxppc-embedded
In-Reply-To: <20061005092946.2004afu1wwc4kkcg@webmail.mcgill.ca>
These requirements are part of the Application Binary Interface, or
ABI for short. Since you're posting to the Linux embedded list, I
assume you want the general powerpc 32-bit ABI. This can be found at
http://refspecs.freestandards.org/elf/elfspec_ppc.pdf
and other places on the web.
There's also a 32-bit powerpc Embedded ABI (not used by Linux). Some
tool and OS vendors use this ABI instead of the one above. A quick
googling of this shows a copy can be found at http://
www.cloudcaptech.com/MPC555%20Resources/Programming%20Environment/
ppceabi.pdf#search=%22powerpc%20eabi%22
Cheers,
B
On Oct 5, 2006, at 8:29 AM, wei.li4@elf.mcgill.ca wrote:
> Hi All,
>
> It seems that there is a rule that Compiler or Linker assigns r3, r4
> ... to the arguments of C function when it is called, and r1 is the
> address of Stack Pointer, and how is for r0 and r2? where can I find
> these rules? Thanks.
>
> Wei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] linux,tce-size property is 32 bits
From: Nathan Lynch @ 2006-10-05 14:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, matthltc
In-Reply-To: <1160039899.22232.54.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Wed, 2006-10-04 at 22:28 -0500, Nathan Lynch wrote:
> > The "linux,tce-size" property is only 32 bits (see
> > prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
> > Treating it as an unsigned long in iommu_table_setparms() leads to
> > access beyond the end of the property's buffer, so we pass garbage to
> > the memset() in that function.
>
> Probably needs to go into stable as well. Do you know if RHEL5 is
> affected too ?
AFAICT this was introduced by the "Constify & voidify get_property()"
series which went in post-2.6.18 so no backport for -stable is
needed. Not sure about RHEL5.
^ permalink raw reply
* [PATCH 2.6.19-rc1 2/2] ehea: fix port state notification, default queue sizes
From: Jan-Bernd Themann @ 2006-10-05 14:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch includes a bug fix for the port state notification
and fixes the default queue sizes.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 13 +++++++------
drivers/net/ehea/ehea_main.c | 6 +++---
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 23b451a..b40724f 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include <asm/abs_addr.h>
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0028"
+#define DRV_VERSION "EHEA_0034"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -50,6 +50,7 @@ #define EHEA_MAX_ENTRIES_RQ3 16383
#define EHEA_MAX_ENTRIES_SQ 32767
#define EHEA_MIN_ENTRIES_QP 127
+#define EHEA_SMALL_QUEUES
#define EHEA_NUM_TX_QP 1
#ifdef EHEA_SMALL_QUEUES
@@ -59,11 +60,11 @@ #define EHEA_DEF_ENTRIES_RQ1 4095
#define EHEA_DEF_ENTRIES_RQ2 1023
#define EHEA_DEF_ENTRIES_RQ3 1023
#else
-#define EHEA_MAX_CQE_COUNT 32000
-#define EHEA_DEF_ENTRIES_SQ 16000
-#define EHEA_DEF_ENTRIES_RQ1 32080
-#define EHEA_DEF_ENTRIES_RQ2 4020
-#define EHEA_DEF_ENTRIES_RQ3 4020
+#define EHEA_MAX_CQE_COUNT 4080
+#define EHEA_DEF_ENTRIES_SQ 4080
+#define EHEA_DEF_ENTRIES_RQ1 8160
+#define EHEA_DEF_ENTRIES_RQ2 2040
+#define EHEA_DEF_ENTRIES_RQ3 2040
#endif
#define EHEA_MAX_ENTRIES_EQ 20
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 263d1c5..0edb2f8 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -769,7 +769,7 @@ static void ehea_parse_eqe(struct ehea_a
if (EHEA_BMASK_GET(NEQE_PORT_UP, eqe)) {
if (!netif_carrier_ok(port->netdev)) {
ret = ehea_sense_port_attr(
- adapter->port[portnum]);
+ port);
if (ret) {
ehea_error("failed resensing port "
"attributes");
@@ -821,7 +821,7 @@ static void ehea_parse_eqe(struct ehea_a
netif_stop_queue(port->netdev);
break;
default:
- ehea_error("unknown event code %x", ec);
+ ehea_error("unknown event code %x, eqe=0x%lX", ec, eqe);
break;
}
}
@@ -1845,7 +1845,7 @@ static int ehea_start_xmit(struct sk_buf
if (netif_msg_tx_queued(port)) {
ehea_info("post swqe on QP %d", pr->qp->init_attr.qp_nr);
- ehea_dump(swqe, sizeof(*swqe), "swqe");
+ ehea_dump(swqe, 512, "swqe");
}
ehea_post_swqe(pr->qp, swqe);
^ permalink raw reply related
* [PATCH 2.6.19-rc1 1/2] ehea: firmware (hvcall) interface changes
From: Jan-Bernd Themann @ 2006-10-05 14:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This eHEA patch covers required changes related to Anton Blanchard's new hvcall interface.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 4a85aca..0b51a8c 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -44,71 +44,99 @@ #define H_ALL_RES_TYPE_EQ 3
#define H_ALL_RES_TYPE_MR 5
#define H_ALL_RES_TYPE_MW 6
-static long ehea_hcall_9arg_9ret(unsigned long opcode,
- unsigned long arg1, unsigned long arg2,
- unsigned long arg3, unsigned long arg4,
- unsigned long arg5, unsigned long arg6,
- unsigned long arg7, unsigned long arg8,
- unsigned long arg9, unsigned long *out1,
- unsigned long *out2,unsigned long *out3,
- unsigned long *out4,unsigned long *out5,
- unsigned long *out6,unsigned long *out7,
- unsigned long *out8,unsigned long *out9)
+static long ehea_plpar_hcall_norets(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7)
{
- long hret;
+ long ret;
int i, sleep_msecs;
for (i = 0; i < 5; i++) {
- hret = plpar_hcall_9arg_9ret(opcode,arg1, arg2, arg3, arg4,
- arg5, arg6, arg7, arg8, arg9, out1,
- out2, out3, out4, out5, out6, out7,
- out8, out9);
- if (H_IS_LONG_BUSY(hret)) {
- sleep_msecs = get_longbusy_msecs(hret);
+ ret = plpar_hcall_norets(opcode, arg1, arg2, arg3, arg4,
+ arg5, arg6, arg7);
+
+ if (H_IS_LONG_BUSY(ret)) {
+ sleep_msecs = get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
- if (hret < H_SUCCESS)
- ehea_error("op=%lx hret=%lx "
- "i1=%lx i2=%lx i3=%lx i4=%lx i5=%lx i6=%lx "
- "i7=%lx i8=%lx i9=%lx "
- "o1=%lx o2=%lx o3=%lx o4=%lx o5=%lx o6=%lx "
- "o7=%lx o8=%lx o9=%lx",
- opcode, hret, arg1, arg2, arg3, arg4, arg5,
- arg6, arg7, arg8, arg9, *out1, *out2, *out3,
- *out4, *out5, *out6, *out7, *out8, *out9);
- return hret;
+ if (ret < H_SUCCESS)
+ ehea_error("opcode=%lx ret=%lx"
+ " arg1=%lx arg2=%lx arg3=%lx arg4=%lx"
+ " arg5=%lx arg6=%lx arg7=%lx ",
+ opcode, ret,
+ arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7);
+
+ return ret;
}
+
return H_BUSY;
}
-u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const u8 qp_category,
- const u64 qp_handle, const u64 sel_mask, void *cb_addr)
+static long ehea_plpar_hcall9(unsigned long opcode,
+ unsigned long *outs, /* array of 9 outputs */
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9)
{
- u64 dummy;
+ long ret;
+ int i, sleep_msecs;
- if ((((u64)cb_addr) & (PAGE_SIZE - 1)) != 0) {
- ehea_error("not on pageboundary");
- return H_PARAMETER;
+ for (i = 0; i < 5; i++) {
+ ret = plpar_hcall9(opcode, outs,
+ arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9);
+
+ if (H_IS_LONG_BUSY(ret)) {
+ sleep_msecs = get_longbusy_msecs(ret);
+ msleep_interruptible(sleep_msecs);
+ continue;
+ }
+
+ if (ret < H_SUCCESS)
+ ehea_error("opcode=%lx ret=%lx"
+ " arg1=%lx arg2=%lx arg3=%lx arg4=%lx"
+ " arg5=%lx arg6=%lx arg7=%lx arg8=%lx"
+ " arg9=%lx"
+ " out1=%lx out2=%lx out3=%lx out4=%lx"
+ " out5=%lx out6=%lx out7=%lx out8=%lx"
+ " out9=%lx",
+ opcode, ret,
+ arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9,
+ outs[0], outs[1], outs[2], outs[3],
+ outs[4], outs[5], outs[6], outs[7],
+ outs[8]);
+
+ return ret;
}
- return ehea_hcall_9arg_9ret(H_QUERY_HEA_QP,
- adapter_handle, /* R4 */
- qp_category, /* R5 */
- qp_handle, /* R6 */
- sel_mask, /* R7 */
- virt_to_abs(cb_addr), /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return H_BUSY;
+}
+
+u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const u8 qp_category,
+ const u64 qp_handle, const u64 sel_mask, void *cb_addr)
+{
+ return ehea_plpar_hcall_norets(H_QUERY_HEA_QP,
+ adapter_handle, /* R4 */
+ qp_category, /* R5 */
+ qp_handle, /* R6 */
+ sel_mask, /* R7 */
+ virt_to_abs(cb_addr), /* R8 */
+ 0, 0);
}
/* input param R5 */
@@ -180,6 +208,7 @@ u64 ehea_h_alloc_resource_qp(const u64 a
u64 *qp_handle, struct h_epas *h_epas)
{
u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
u64 allocate_controls =
EHEA_BMASK_SET(H_ALL_RES_QP_EQPO, init_attr->low_lat_rq1 ? 1 : 0)
@@ -219,45 +248,29 @@ u64 ehea_h_alloc_resource_qp(const u64 a
EHEA_BMASK_SET(H_ALL_RES_QP_TH_RQ2, init_attr->rq2_threshold)
| EHEA_BMASK_SET(H_ALL_RES_QP_TH_RQ3, init_attr->rq3_threshold);
- u64 r5_out = 0;
- u64 r6_out = 0;
- u64 r7_out = 0;
- u64 r8_out = 0;
- u64 r9_out = 0;
- u64 g_la_user_out = 0;
- u64 r11_out = 0;
- u64 r12_out = 0;
-
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- allocate_controls, /* R5 */
- init_attr->send_cq_handle, /* R6 */
- init_attr->recv_cq_handle, /* R7 */
- init_attr->aff_eq_handle, /* R8 */
- r9_reg, /* R9 */
- max_r10_reg, /* R10 */
- r11_in, /* R11 */
- threshold, /* R12 */
- qp_handle, /* R4 */
- &r5_out, /* R5 */
- &r6_out, /* R6 */
- &r7_out, /* R7 */
- &r8_out, /* R8 */
- &r9_out, /* R9 */
- &g_la_user_out, /* R10 */
- &r11_out, /* R11 */
- &r12_out); /* R12 */
-
- init_attr->qp_nr = (u32)r5_out;
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ allocate_controls, /* R5 */
+ init_attr->send_cq_handle, /* R6 */
+ init_attr->recv_cq_handle, /* R7 */
+ init_attr->aff_eq_handle, /* R8 */
+ r9_reg, /* R9 */
+ max_r10_reg, /* R10 */
+ r11_in, /* R11 */
+ threshold); /* R12 */
+
+ *qp_handle = outs[0];
+ init_attr->qp_nr = (u32)outs[1];
init_attr->act_nr_send_wqes =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_SWQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_SWQE, outs[2]);
init_attr->act_nr_rwqes_rq1 =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R1WQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R1WQE, outs[2]);
init_attr->act_nr_rwqes_rq2 =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R2WQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R2WQE, outs[2]);
init_attr->act_nr_rwqes_rq3 =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R3WQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R3WQE, outs[2]);
init_attr->act_wqe_size_enc_sq = init_attr->wqe_size_enc_sq;
init_attr->act_wqe_size_enc_rq1 = init_attr->wqe_size_enc_rq1;
@@ -265,25 +278,25 @@ u64 ehea_h_alloc_resource_qp(const u64 a
init_attr->act_wqe_size_enc_rq3 = init_attr->wqe_size_enc_rq3;
init_attr->nr_sq_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_SQ, r8_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_SQ, outs[4]);
init_attr->nr_rq1_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ1, r8_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ1, outs[4]);
init_attr->nr_rq2_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ2, r9_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ2, outs[5]);
init_attr->nr_rq3_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ3, r9_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ3, outs[5]);
init_attr->liobn_sq =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_SQ, r11_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_SQ, outs[7]);
init_attr->liobn_rq1 =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ1, r11_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ1, outs[7]);
init_attr->liobn_rq2 =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ2, r12_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ2, outs[8]);
init_attr->liobn_rq3 =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ3, r12_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ3, outs[8]);
if (!hret)
- hcp_epas_ctor(h_epas, g_la_user_out, g_la_user_out);
+ hcp_epas_ctor(h_epas, outs[6], outs[6]);
return hret;
}
@@ -292,31 +305,24 @@ u64 ehea_h_alloc_resource_cq(const u64 a
struct ehea_cq_attr *cq_attr,
u64 *cq_handle, struct h_epas *epas)
{
- u64 hret, dummy, act_nr_of_cqes_out, act_pages_out;
- u64 g_la_privileged_out, g_la_user_out;
-
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- H_ALL_RES_TYPE_CQ, /* R5 */
- cq_attr->eq_handle, /* R6 */
- cq_attr->cq_token, /* R7 */
- cq_attr->max_nr_of_cqes, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- cq_handle, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &act_nr_of_cqes_out, /* R7 */
- &act_pages_out, /* R8 */
- &g_la_privileged_out, /* R9 */
- &g_la_user_out, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
-
- cq_attr->act_nr_of_cqes = act_nr_of_cqes_out;
- cq_attr->nr_pages = act_pages_out;
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ H_ALL_RES_TYPE_CQ, /* R5 */
+ cq_attr->eq_handle, /* R6 */
+ cq_attr->cq_token, /* R7 */
+ cq_attr->max_nr_of_cqes, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
+
+ *cq_handle = outs[0];
+ cq_attr->act_nr_of_cqes = outs[3];
+ cq_attr->nr_pages = outs[4];
if (!hret)
- hcp_epas_ctor(epas, g_la_privileged_out, g_la_user_out);
+ hcp_epas_ctor(epas, outs[5], outs[6]);
return hret;
}
@@ -361,9 +367,8 @@ #define H_ALL_RES_EQ_ACT_EQ_IST_4 EHE
u64 ehea_h_alloc_resource_eq(const u64 adapter_handle,
struct ehea_eq_attr *eq_attr, u64 *eq_handle)
{
- u64 hret, dummy, eq_liobn, allocate_controls;
- u64 ist1_out, ist2_out, ist3_out, ist4_out;
- u64 act_nr_of_eqes_out, act_pages_out;
+ u64 hret, allocate_controls;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
/* resource type */
allocate_controls =
@@ -372,27 +377,20 @@ u64 ehea_h_alloc_resource_eq(const u64 a
| EHEA_BMASK_SET(H_ALL_RES_EQ_INH_EQE_GEN, !eq_attr->eqe_gen)
| EHEA_BMASK_SET(H_ALL_RES_EQ_NON_NEQ_ISN, 1);
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- allocate_controls, /* R5 */
- eq_attr->max_nr_of_eqes, /* R6 */
- 0, 0, 0, 0, 0, 0, /* R7-R10 */
- eq_handle, /* R4 */
- &dummy, /* R5 */
- &eq_liobn, /* R6 */
- &act_nr_of_eqes_out, /* R7 */
- &act_pages_out, /* R8 */
- &ist1_out, /* R9 */
- &ist2_out, /* R10 */
- &ist3_out, /* R11 */
- &ist4_out); /* R12 */
-
- eq_attr->act_nr_of_eqes = act_nr_of_eqes_out;
- eq_attr->nr_pages = act_pages_out;
- eq_attr->ist1 = ist1_out;
- eq_attr->ist2 = ist2_out;
- eq_attr->ist3 = ist3_out;
- eq_attr->ist4 = ist4_out;
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ allocate_controls, /* R5 */
+ eq_attr->max_nr_of_eqes, /* R6 */
+ 0, 0, 0, 0, 0, 0); /* R7-R10 */
+
+ *eq_handle = outs[0];
+ eq_attr->act_nr_of_eqes = outs[3];
+ eq_attr->nr_pages = outs[4];
+ eq_attr->ist1 = outs[5];
+ eq_attr->ist2 = outs[6];
+ eq_attr->ist3 = outs[7];
+ eq_attr->ist4 = outs[8];
return hret;
}
@@ -402,31 +400,22 @@ u64 ehea_h_modify_ehea_qp(const u64 adap
void *cb_addr, u64 *inv_attr_id, u64 *proc_mask,
u16 *out_swr, u16 *out_rwr)
{
- u64 hret, dummy, act_out_swr, act_out_rwr;
-
- if ((((u64)cb_addr) & (PAGE_SIZE - 1)) != 0) {
- ehea_error("not on page boundary");
- return H_PARAMETER;
- }
-
- hret = ehea_hcall_9arg_9ret(H_MODIFY_HEA_QP,
- adapter_handle, /* R4 */
- (u64) cat, /* R5 */
- qp_handle, /* R6 */
- sel_mask, /* R7 */
- virt_to_abs(cb_addr), /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- inv_attr_id, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &act_out_swr, /* R7 */
- &act_out_rwr, /* R8 */
- proc_mask, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- *out_swr = act_out_swr;
- *out_rwr = act_out_rwr;
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+
+ hret = ehea_plpar_hcall9(H_MODIFY_HEA_QP,
+ outs,
+ adapter_handle, /* R4 */
+ (u64) cat, /* R5 */
+ qp_handle, /* R6 */
+ sel_mask, /* R7 */
+ virt_to_abs(cb_addr), /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
+
+ *inv_attr_id = outs[0];
+ *out_swr = outs[3];
+ *out_rwr = outs[4];
+ *proc_mask = outs[5];
return hret;
}
@@ -435,122 +424,81 @@ u64 ehea_h_register_rpage(const u64 adap
const u8 queue_type, const u64 resource_handle,
const u64 log_pageaddr, u64 count)
{
- u64 dummy, reg_control;
+ u64 reg_control;
reg_control = EHEA_BMASK_SET(H_REG_RPAGE_PAGE_SIZE, pagesize)
| EHEA_BMASK_SET(H_REG_RPAGE_QT, queue_type);
- return ehea_hcall_9arg_9ret(H_REGISTER_HEA_RPAGES,
- adapter_handle, /* R4 */
- reg_control, /* R5 */
- resource_handle, /* R6 */
- log_pageaddr, /* R7 */
- count, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_REGISTER_HEA_RPAGES,
+ adapter_handle, /* R4 */
+ reg_control, /* R5 */
+ resource_handle, /* R6 */
+ log_pageaddr, /* R7 */
+ count, /* R8 */
+ 0, 0); /* R9-R10 */
}
u64 ehea_h_register_smr(const u64 adapter_handle, const u64 orig_mr_handle,
const u64 vaddr_in, const u32 access_ctrl, const u32 pd,
struct ehea_mr *mr)
{
- u64 hret, dummy, lkey_out;
-
- hret = ehea_hcall_9arg_9ret(H_REGISTER_SMR,
- adapter_handle , /* R4 */
- orig_mr_handle, /* R5 */
- vaddr_in, /* R6 */
- (((u64)access_ctrl) << 32ULL), /* R7 */
- pd, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &mr->handle, /* R4 */
- &dummy, /* R5 */
- &lkey_out, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- mr->lkey = (u32)lkey_out;
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+
+ hret = ehea_plpar_hcall9(H_REGISTER_SMR,
+ outs,
+ adapter_handle , /* R4 */
+ orig_mr_handle, /* R5 */
+ vaddr_in, /* R6 */
+ (((u64)access_ctrl) << 32ULL), /* R7 */
+ pd, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
+
+ mr->handle = outs[0];
+ mr->lkey = (u32)outs[2];
return hret;
}
u64 ehea_h_disable_and_get_hea(const u64 adapter_handle, const u64 qp_handle)
{
- u64 hret, dummy, ladr_next_sq_wqe_out;
- u64 ladr_next_rq1_wqe_out, ladr_next_rq2_wqe_out, ladr_next_rq3_wqe_out;
-
- hret = ehea_hcall_9arg_9ret(H_DISABLE_AND_GET_HEA,
- adapter_handle, /* R4 */
- H_DISABLE_GET_EHEA_WQE_P, /* R5 */
- qp_handle, /* R6 */
- 0, 0, 0, 0, 0, 0, /* R7-R12 */
- &ladr_next_sq_wqe_out, /* R4 */
- &ladr_next_rq1_wqe_out, /* R5 */
- &ladr_next_rq2_wqe_out, /* R6 */
- &ladr_next_rq3_wqe_out, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- return hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+
+ return ehea_plpar_hcall9(H_DISABLE_AND_GET_HEA,
+ outs,
+ adapter_handle, /* R4 */
+ H_DISABLE_GET_EHEA_WQE_P, /* R5 */
+ qp_handle, /* R6 */
+ 0, 0, 0, 0, 0, 0); /* R7-R12 */
}
u64 ehea_h_free_resource(const u64 adapter_handle, const u64 res_handle)
{
- u64 dummy;
-
- return ehea_hcall_9arg_9ret(H_FREE_RESOURCE,
- adapter_handle, /* R4 */
- res_handle, /* R5 */
- 0, 0, 0, 0, 0, 0, 0, /* R6-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_FREE_RESOURCE,
+ adapter_handle, /* R4 */
+ res_handle, /* R5 */
+ 0, 0, 0, 0, 0); /* R6-R10 */
}
u64 ehea_h_alloc_resource_mr(const u64 adapter_handle, const u64 vaddr,
const u64 length, const u32 access_ctrl,
const u32 pd, u64 *mr_handle, u32 *lkey)
{
- u64 hret, dummy, lkey_out;
-
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- 5, /* R5 */
- vaddr, /* R6 */
- length, /* R7 */
- (((u64) access_ctrl) << 32ULL),/* R8 */
- pd, /* R9 */
- 0, 0, 0, /* R10-R12 */
- mr_handle, /* R4 */
- &dummy, /* R5 */
- &lkey_out, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- *lkey = (u32) lkey_out;
-
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ 5, /* R5 */
+ vaddr, /* R6 */
+ length, /* R7 */
+ (((u64) access_ctrl) << 32ULL), /* R8 */
+ pd, /* R9 */
+ 0, 0, 0); /* R10-R12 */
+
+ *mr_handle = outs[0];
+ *lkey = (u32)outs[2];
return hret;
}
@@ -570,23 +518,14 @@ u64 ehea_h_register_rpage_mr(const u64 a
u64 ehea_h_query_ehea(const u64 adapter_handle, void *cb_addr)
{
- u64 hret, dummy, cb_logaddr;
+ u64 hret, cb_logaddr;
cb_logaddr = virt_to_abs(cb_addr);
- hret = ehea_hcall_9arg_9ret(H_QUERY_HEA,
- adapter_handle, /* R4 */
- cb_logaddr, /* R5 */
- 0, 0, 0, 0, 0, 0, 0, /* R6-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ hret = ehea_plpar_hcall_norets(H_QUERY_HEA,
+ adapter_handle, /* R4 */
+ cb_logaddr, /* R5 */
+ 0, 0, 0, 0, 0); /* R6-R10 */
#ifdef DEBUG
ehea_dmp(cb_addr, sizeof(struct hcp_query_ehea), "hcp_query_ehea");
#endif
@@ -597,36 +536,28 @@ u64 ehea_h_query_ehea_port(const u64 ada
const u8 cb_cat, const u64 select_mask,
void *cb_addr)
{
- u64 port_info, dummy;
+ u64 port_info;
u64 cb_logaddr = virt_to_abs(cb_addr);
u64 arr_index = 0;
port_info = EHEA_BMASK_SET(H_MEHEAPORT_CAT, cb_cat)
| EHEA_BMASK_SET(H_MEHEAPORT_PN, port_num);
- return ehea_hcall_9arg_9ret(H_QUERY_HEA_PORT,
- adapter_handle, /* R4 */
- port_info, /* R5 */
- select_mask, /* R6 */
- arr_index, /* R7 */
- cb_logaddr, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_QUERY_HEA_PORT,
+ adapter_handle, /* R4 */
+ port_info, /* R5 */
+ select_mask, /* R6 */
+ arr_index, /* R7 */
+ cb_logaddr, /* R8 */
+ 0, 0); /* R9-R10 */
}
u64 ehea_h_modify_ehea_port(const u64 adapter_handle, const u16 port_num,
const u8 cb_cat, const u64 select_mask,
void *cb_addr)
{
- u64 port_info, dummy, inv_attr_ident, proc_mask;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+ u64 port_info;
u64 arr_index = 0;
u64 cb_logaddr = virt_to_abs(cb_addr);
@@ -635,29 +566,21 @@ u64 ehea_h_modify_ehea_port(const u64 ad
#ifdef DEBUG
ehea_dump(cb_addr, sizeof(struct hcp_ehea_port_cb0), "Before HCALL");
#endif
- return ehea_hcall_9arg_9ret(H_MODIFY_HEA_PORT,
- adapter_handle, /* R4 */
- port_info, /* R5 */
- select_mask, /* R6 */
- arr_index, /* R7 */
- cb_logaddr, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &inv_attr_ident, /* R4 */
- &proc_mask, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall9(H_MODIFY_HEA_PORT,
+ outs,
+ adapter_handle, /* R4 */
+ port_info, /* R5 */
+ select_mask, /* R6 */
+ arr_index, /* R7 */
+ cb_logaddr, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
}
u64 ehea_h_reg_dereg_bcmc(const u64 adapter_handle, const u16 port_num,
const u8 reg_type, const u64 mc_mac_addr,
const u16 vlan_id, const u32 hcall_id)
{
- u64 r5_port_num, r6_reg_type, r7_mc_mac_addr, r8_vlan_id, dummy;
+ u64 r5_port_num, r6_reg_type, r7_mc_mac_addr, r8_vlan_id;
u64 mac_addr = mc_mac_addr >> 16;
r5_port_num = EHEA_BMASK_SET(H_REGBCMC_PN, port_num);
@@ -665,41 +588,21 @@ u64 ehea_h_reg_dereg_bcmc(const u64 adap
r7_mc_mac_addr = EHEA_BMASK_SET(H_REGBCMC_MACADDR, mac_addr);
r8_vlan_id = EHEA_BMASK_SET(H_REGBCMC_VLANID, vlan_id);
- return ehea_hcall_9arg_9ret(hcall_id,
- adapter_handle, /* R4 */
- r5_port_num, /* R5 */
- r6_reg_type, /* R6 */
- r7_mc_mac_addr, /* R7 */
- r8_vlan_id, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(hcall_id,
+ adapter_handle, /* R4 */
+ r5_port_num, /* R5 */
+ r6_reg_type, /* R6 */
+ r7_mc_mac_addr, /* R7 */
+ r8_vlan_id, /* R8 */
+ 0, 0); /* R9-R12 */
}
u64 ehea_h_reset_events(const u64 adapter_handle, const u64 neq_handle,
const u64 event_mask)
{
- u64 dummy;
-
- return ehea_hcall_9arg_9ret(H_RESET_EVENTS,
- adapter_handle, /* R4 */
- neq_handle, /* R5 */
- event_mask, /* R6 */
- 0, 0, 0, 0, 0, 0, /* R7-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_RESET_EVENTS,
+ adapter_handle, /* R4 */
+ neq_handle, /* R5 */
+ event_mask, /* R6 */
+ 0, 0, 0, 0); /* R7-R12 */
}
^ permalink raw reply related
* Re: [PATCH] linux,tce-size property is 32 bits
From: Olof Johansson @ 2006-10-05 15:36 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, matthltc
In-Reply-To: <20061005032800.GH24705@localdomain>
On Wed, 4 Oct 2006 22:28:00 -0500 Nathan Lynch <ntl@pobox.com> wrote:
> The "linux,tce-size" property is only 32 bits (see
> prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
> Treating it as an unsigned long in iommu_table_setparms() leads to
> access beyond the end of the property's buffer, so we pass garbage to
> the memset() in that function.
>
> [boot]0020 XICS Init
> i8259 legacy interrupt controller initialized
> [boot]0021 XICS Done
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> cpu 0x0: Vector: 300 (Data Access) at [c0000000fe783850]
> pc: c000000000035e90: .memset+0x60/0xfc
> lr: c000000000044fa4: .iommu_table_setparms+0xb0/0x158
> sp: c0000000fe783ad0
> msr: 9000000000009032
> dar: c000000100000000
> dsisr: 42010000
> current = 0xc00000000450e810
> paca = 0xc000000000411580
> pid = 1, comm = swapper
> enter ? for help
> [link register ] c000000000044fa4 .iommu_table_setparms+0xb0/0x158
> [c0000000fe783ad0] c000000000044f4c .iommu_table_setparms+0x58/0x158
> (unreliable)
> [c0000000fe783b70] c00000000004529c
> .iommu_bus_setup_pSeries+0x1c4/0x254
> [c0000000fe783c00] c00000000002b8ac .do_bus_setup+0x3c/0xe4
> [c0000000fe783c80] c00000000002c924 .pcibios_fixup_bus+0x64/0xd8
> [c0000000fe783d00] c0000000001a2d5c .pci_scan_child_bus+0x6c/0x10c
> [c0000000fe783da0] c00000000002be28 .scan_phb+0x17c/0x1b4
> [c0000000fe783e40] c0000000003cfa00 .pcibios_init+0x58/0x19c
> [c0000000fe783ec0] c0000000000094b4 .init+0x1e8/0x3d8
> [c0000000fe783f90] c000000000026e54 .kernel_thread+0x4c/0x68
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
It does not reproduce on the OpenPower box I have, but it's clearly a
bug. Good catch.
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: booting 2.6 kernel on ML403
From: Pradeep Sampath @ 2006-10-05 15:47 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
In-Reply-To: <4524C290.3090702@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
Hi Ameet,
As soon as i apply the sysace driver and temac drivers and copy the xparameters_ml300.h (from EDK) to xparameters_ml403.h all i get is this... meaning kernel hangs after displaying "Now booting the kernel".
When i disable sysace and TEMAC drivers, the system goes further till "root=" option and then tries to "Kernel Rebooting in 180 seconds". Yesterday i tried root=/dev/xsysace2 rw and creating block device files in /dev of the CF card. But it ran into the same problem.Is there a sysace driver patch that i can apply without applying the TEMAC driver patch?
So far i was using the EDK 8.1 SP2 (latest) which has the IP core TEMAC version 3.00. Now i downgraded to EDK 8.1 to get the version 2.00 (please see John Bonesio's post).
I thought the first step is to get the sysace driver running before applying the TEMAC drivers.
thanks very much!
Pradeep
Ameet Patil <ammubhai@gmail.com> wrote:
Pradeep,
What you have pasted is only part of the messages displayed. I can't
tell anything from this apart from you 'root=' option. It would be nice
if you could paste the entire log of the boot messages right from
'loaded at: xxxxxxx xxxxxxxx' to 'Kernel Rebooting in 150 seconds'.
-Ameet
Pradeep Sampath wrote:
> Ameet,
>
> loaded at: 00400000 0051513C
> board data at: 00513124 0051313C
> relocated to: 004050E8 00405100
> zimage at: 004057FD 0051230A
> avail ram: 00516000 04000000
> Linux/PPC load: console=ttyS0,9600 root=/dev/xsa2
> Uncompressing Linux...done.
> Now booting the kernel
>
>
> Please could send me all the boot messages until the point where it
> stops. This will help me better identify the problem.
>
> Thanks,
> -Ameet
>
>
[-- Attachment #2: Type: text/html, Size: 2150 bytes --]
^ permalink raw reply
* [PATCH 1/1] powerpc: Update pSeries defconfig for SATA
From: Brian King @ 2006-10-05 15:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Since the ipr driver now supports SATA and depends on libata,
enable libata to get built.
Signed-off-by: Brian King <brking@us.ibm.com>
---
linux-2.6-bjking1/arch/powerpc/configs/pseries_defconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/powerpc/configs/pseries_defconfig~powerpc_sata_config arch/powerpc/configs/pseries_defconfig
--- linux-2.6/arch/powerpc/configs/pseries_defconfig~powerpc_sata_config 2006-10-05 10:11:57.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/configs/pseries_defconfig 2006-10-05 10:12:40.000000000 -0500
@@ -506,7 +506,7 @@ CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
-# CONFIG_ATA is not set
+CONFIG_ATA=y
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
_
^ permalink raw reply
* Problems with SPI+I2S on MPC5200B
From: Grant Likely @ 2006-10-05 16:52 UTC (permalink / raw)
To: John Rigby, linuxppc-embedded list
John,
Kim Phillips pointed me in your direction. I've got a 5200B based
platform w/ two AIC26 codecs attached to PSC2 and PSC3 in I2S modes,
and both are also connected to the SPI pins in the PSC3 pin group.
Linux is running on the board.
In the early development of this board, we had some problems with the
MPC5200 SPI device, and so implemented a gpio bitbanging driver
instead just to get things working, and we've got an ALSA driver that
works with both codecs.
Of course, the bitbanged SPI driver is sub-optimal so dug back into
the SPI device and put together a working MPC5200 SPI device driver.
For Codec #1 on PSC2, this setup works perfectly. However, Codec #2
no longer works. An application can connect to the ALSA device, but
no audio data gets transfered in/out of the MPC5200. If I switch back
to bitbanging mode, everything works again.
Things I've verified:
1. SPI read/write to the Codec is correct. All the settings are
identical between the working codec and the non-working one
2. Both codecs are correctly generating I2S BitClk and Frame signals
3. On the working codec, PSC2+0x2210 reports 0x80000000, detected SYNC
4. On the non-working codec, PSC3+0x2410 reports 0x00000000, no detected SYNC
5. If I 'wrap' the spi transfers with modifications to port_config to
enable/disable SPI to the PSC3 pin group, then audio works again.
(However, this is not a viable solution because we have a lot of
transfers across the SPI bus).
Here is some of the relevant data:
Setup of port_config
printk("old port_config=%.8x\n", val);
/* 48Mhz internal, pin is GPIO */
val &= ~0x00800000;
/* USB port - Differential mode - USB1 only */
/* Commented out until Atmel has proper firmware loaded
val &= ~0x00007000;
val |= 0x00001000;
*/
/* CODEC2 + GPIO on PSC2 */
val &= ~0x00000070;
val |= 0x00000060;
#if !defined(CONFIG_MPC5200_SPI_BITBANG)
/* SPI+CODEC3 pins on PSC3 */
val &= ~0x00000F00;
val |= 0x00000F00; /* CODEC3 + SPI */
#else
/* GPIO+CODEC3 pins on PSC3 */
val &= ~0x00000F00;
val |= 0x00000600;
#endif
/* Commit port config */
out_be32(&gpio->port_config, val);
printk("new port_config=%.8x\n", val);
'Wrapper' code on SPI driver just to get things working (Called at the
start and end of an SPI transfer)
void port_config_enable_spi(void)
{
u32 val;
udelay(1);
val = in_be32(&gpio->port_config);
val |= 0x00000F00; /* CODEC3 + SPI */
out_be32(&gpio->port_config, val);
udelay(1);
}
void port_config_disable_spi(void)
{
u32 val;
udelay(1);
val = in_be32(&gpio->port_config);
val &= ~0x00000F00;
val |= 0x00000600;
out_be32(&gpio->port_config, val);
udelay(1);
}
I2S interface:
AIC26 is master, MPC5200 is slave
bitclk generated by AIC26
SPI interface
SS controlled by a CPLD
MPC5200 is master
SPI transfers are confirmed working for both bitbanging and SPI device drivers.
Register dump for PSC2 (working) and PSC3 (not working):
>md 0xf0002200
f0002200 : 07000000 1f000000 00000000 05165dd3 ..............].
f0002210 : 80000000 1b000000 00000000 00000000 ................
f0002220 : 00000000 00000000 00000000 00000000 ................
f0002230 : 00000000 bc000000 00000000 00000000 ................
f0002240 : 2f600000 00000000 00000000 36000000 /`..........6...
f0002250 : 00000000 00000000 02000000 00000000 ................
f0002260 : 05165dd3 00060000 04200000 00000100 ..]...... ......
f0002270 : 00000010 00000010 00000000 00000000 ................
f0002280 : 00000000 00230000 07200000 00000100 .....#... ......
f0002290 : 000001b0 000001b0 000001b0 000001b0 ................
f00022a0 : 00000000 00000000 00000000 00000000 ................
f00022b0 : 00000000 00000000 00000000 00000000 ................
f00022c0 : 00000000 00000000 00000000 00000000 ................
f00022d0 : 00000000 00000000 00000000 00000000 ................
f00022e0 : 00000000 00000000 00000000 00000000 ................
f00022f0 : 00000000 00000000 00000000 00000000 ................
>md 0xf0002400
f0002400 : 07000000 00000000 00000000 00000000 ................
f0002410 : 00000000 00000000 00000000 00000000 ................
f0002420 : 00000000 00000000 00000000 00000000 ................
f0002430 : 00000000 fc000000 00000000 00000000 ................
f0002440 : 2f600000 00000000 00000000 36000000 /`..........6...
f0002450 : 00000000 00000000 00000000 01e80000 ................
f0002460 : 00000000 00210000 04200000 00000100 .....!... ......
f0002470 : 00000000 00000000 00000000 00000000 ................
f0002480 : 10010000 00000000 07200000 00000100 ......... ......
f0002490 : 0000000c 000001f0 00000000 00000000 ................
f00024a0 : 00000000 00000000 00000000 00000000 ................
f00024b0 : 00000000 00000000 00000000 00000000 ................
f00024c0 : 00000000 00000000 00000000 00000000 ................
f00024d0 : 00000000 00000000 00000000 00000000 ................
f00024e0 : 00000000 00000000 00000000 00000000 ................
f00024f0 : 00000000 00000000 00000000 00000000 ................
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Update MTFSF_L() comment
From: Anton Blanchard @ 2006-10-05 16:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dwmw2, paulus
David Woodhouse points out that the comment accompanying the MTFSF_L
macro is misleading. We should make it clear that the L bit is ignored
on older CPUS, not the entire instruction.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
index 3a9fcc1..8fb9681 100644
--- a/include/asm-powerpc/reg.h
+++ b/include/asm-powerpc/reg.h
@@ -503,7 +503,7 @@ #endif
/*
* An mtfsf instruction with the L bit set. On CPUs that support this a
- * full 64bits of FPSCR is restored and on other CPUs it is ignored.
+ * full 64bits of FPSCR is restored and on other CPUs the L bit is ignored.
*
* Until binutils gets the new form of mtfsf, hardwire the instruction.
*/
^ permalink raw reply related
* Re: bdm/jtag interface for MPC834x with gdb access
From: Vitaly Bordug @ 2006-10-05 16:59 UTC (permalink / raw)
To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450610041500n60c31828l789cde20e99c912d@mail.gmail.com>
On Wed, 4 Oct 2006 22:00:12 +0000
"Reeve Yang" <yang.reeve@gmail.com> wrote:
> Can anyone share experience on bcm/jtag interface for MPC834x with gdb
> access? I'm using windriver usb jtag probe. Is there any bdm interface with
> gdb access available for it?
>
Abatron BDI2000 is just the best IMO.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: make U4 PCIe work
From: Nathan Lynch @ 2006-10-05 17:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1160024098.22232.13.camel@localhost.localdomain>
Hi-
Benjamin Herrenschmidt wrote:
> The Maple support code was missing code for U4/CPC945 PCIe. This adds
> it, enabling it to work on tigerwood boards, and possibly also js21
> using SLOF.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Patch just missed the merge window but should go in anyway. It's been
> hanging around for a while, I just forgot about it, and it's fairly
> harmless.
>
> Index: linux-work/arch/powerpc/platforms/maple/pci.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/platforms/maple/pci.c 2006-10-05 14:14:28.000000000 +1000
> +++ linux-work/arch/powerpc/platforms/maple/pci.c 2006-10-05 14:29:30.000000000 +1000
> @@ -8,7 +8,7 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> -#define DEBUG
> +#undef DEBUG
>
> #include <linux/kernel.h>
> #include <linux/pci.h>
> @@ -16,6 +16,7 @@
> #include <linux/string.h>
> #include <linux/init.h>
> #include <linux/bootmem.h>
> +#include <linux/irq.h>
>
> #include <asm/sections.h>
> #include <asm/io.h>
> @@ -33,7 +34,7 @@
> #define DBG(x...)
> #endif
>
> -static struct pci_controller *u3_agp, *u3_ht;
> +static struct pci_controller *u3_agp, *u3_ht, *u4_pcie;
>
> static int __init fixup_one_level_bus_range(struct device_node *node, int higher)
> {
> @@ -287,6 +288,110 @@ static struct pci_ops u3_ht_pci_ops =
> u3_ht_write_config
> };
>
> +#define U4_PCIE_CFA0(devfn, off) \
> + ((1 << ((unsigned int)PCI_SLOT(dev_fn))) \
> + | (((unsigned int)PCI_FUNC(dev_fn)) << 8) \
> + | ((((unsigned int)(off)) >> 8) << 28) \
> + | (((unsigned int)(off)) & 0xfcU))
This macro has the same kind of bug I just fixed for the U3 code in
this file. The macro parameter is named devfn but the body of the
macro refers to dev_fn. I see no reason that these shouldn't be
functions.
> +
> +#define U4_PCIE_CFA1(bus, devfn, off) \
> + ((((unsigned int)(bus)) << 16) \
> + |(((unsigned int)(devfn)) << 8) \
> + | ((((unsigned int)(off)) >> 8) << 28) \
> + |(((unsigned int)(off)) & 0xfcU) \
> + |1UL)
> +
> +static volatile void __iomem *u4_pcie_cfg_access(struct pci_controller* hose,
> + u8 bus, u8 dev_fn, int offset)
> +{
> + unsigned int caddr;
> +
> + if (bus == hose->first_busno) {
> + caddr = U4_PCIE_CFA0(dev_fn, offset);
> + } else
> + caddr = U4_PCIE_CFA1(bus, dev_fn, offset);
> +
> + /* Uninorth will return garbage if we don't read back the value ! */
> + do {
> + out_le32(hose->cfg_addr, caddr);
> + } while (in_le32(hose->cfg_addr) != caddr);
> +
> + offset &= 0x03;
> + return hose->cfg_data + offset;
> +}
> +
> +static int u4_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
> + int offset, int len, u32 *val)
> +{
> + struct pci_controller *hose;
> + volatile void __iomem *addr;
> +
> + hose = pci_bus_to_host(bus);
> + if (hose == NULL)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + if (offset >= 0x1000)
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
> + if (!addr)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + /*
> + * Note: the caller has already checked that offset is
> + * suitably aligned and that len is 1, 2 or 4.
> + */
> + switch (len) {
> + case 1:
> + *val = in_8(addr);
> + break;
> + case 2:
> + *val = in_le16(addr);
> + break;
> + default:
> + *val = in_le32(addr);
> + break;
> + }
> + return PCIBIOS_SUCCESSFUL;
> +}
> +static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
> + int offset, int len, u32 val)
> +{
> + struct pci_controller *hose;
> + volatile void __iomem *addr;
> +
> + hose = pci_bus_to_host(bus);
> + if (hose == NULL)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + if (offset >= 0x1000)
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
> + if (!addr)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + /*
> + * Note: the caller has already checked that offset is
> + * suitably aligned and that len is 1, 2 or 4.
> + */
> + switch (len) {
> + case 1:
> + out_8(addr, val);
> + (void) in_8(addr);
> + break;
> + case 2:
> + out_le16(addr, val);
> + (void) in_le16(addr);
> + break;
> + default:
> + out_le32(addr, val);
> + (void) in_le32(addr);
> + break;
> + }
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static struct pci_ops u4_pcie_pci_ops =
> +{
> + u4_pcie_read_config,
> + u4_pcie_write_config
> +};
> +
> static void __init setup_u3_agp(struct pci_controller* hose)
> {
> /* On G5, we move AGP up to high bus number so we don't need
> @@ -307,6 +412,26 @@ static void __init setup_u3_agp(struct p
> u3_agp = hose;
> }
>
> +static void __init setup_u4_pcie(struct pci_controller* hose)
> +{
> + /* We currently only implement the "non-atomic" config space, to
> + * be optimised later.
> + */
> + hose->ops = &u4_pcie_pci_ops;
> + hose->cfg_addr = ioremap(0xf0000000 + 0x800000, 0x1000);
> + hose->cfg_data = ioremap(0xf0000000 + 0xc00000, 0x1000);
> +
> + /* The bus contains a bridge from root -> device, we need to
> + * make it visible on bus 0 so that we pick the right type
> + * of config cycles. If we didn't, we would have to force all
> + * config cycles to be type 1. So we override the "bus-range"
> + * property here
> + */
> + hose->first_busno = 0x00;
> + hose->last_busno = 0xff;
> + u4_pcie = hose;
> +}
> +
> static void __init setup_u3_ht(struct pci_controller* hose)
> {
> hose->ops = &u3_ht_pci_ops;
> @@ -354,6 +479,10 @@ static int __init add_bridge(struct devi
> setup_u3_ht(hose);
> disp_name = "U3-HT";
> primary = 1;
> + } else if (device_is_compatible(dev, "u4-pcie")) {
> + setup_u4_pcie(hose);
> + disp_name = "U4-PCIE";
> + primary = 0;
> }
> printk(KERN_INFO "Found %s PCI host bridge. Firmware bus number: %d->%d\n",
> disp_name, hose->first_busno, hose->last_busno);
> @@ -361,7 +490,6 @@ static int __init add_bridge(struct devi
> /* Interpret the "ranges" property */
> /* This also maps the I/O region and sets isa_io/mem_base */
> pci_process_bridge_OF_ranges(hose, dev, primary);
> - pci_setup_phb_io(hose, primary);
>
> /* Fixup "bus-range" OF property */
> fixup_bus_range(dev);
> @@ -376,8 +504,17 @@ void __init maple_pcibios_fixup(void)
>
> DBG(" -> maple_pcibios_fixup\n");
>
> - for_each_pci_dev(dev)
> - pci_read_irq_line(dev);
> + for_each_pci_dev(dev) {
> + /* Fixup IRQ for PCIe host */
> + if (u4_pcie != NULL && dev->bus->number == 0 &&
> + pci_bus_to_host(dev->bus) == u4_pcie) {
> + printk(KERN_DEBUG "Fixup U4 PCIe IRQ\n");
> + dev->irq = irq_create_mapping(NULL, 1);
> + if (dev->irq != NO_IRQ)
> + set_irq_type(dev->irq, IRQ_TYPE_LEVEL_LOW);
> + } else
> + pci_read_irq_line(dev);
> + }
>
> DBG(" <- maple_pcibios_fixup\n");
> }
> @@ -388,8 +525,10 @@ static void __init maple_fixup_phb_resou
>
> list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
> +
> hose->io_resource.start += offset;
> hose->io_resource.end += offset;
> +
> printk(KERN_INFO "PCI Host %d, io start: %llx; io end: %llx\n",
> hose->global_number,
> (unsigned long long)hose->io_resource.start,
> @@ -431,6 +570,19 @@ void __init maple_pci_init(void)
> if (ht && add_bridge(ht) != 0)
> of_node_put(ht);
>
> + /*
> + * We need to call pci_setup_phb_io for the HT bridge first
> + * so it gets the I/O port numbers starting at 0, and we
> + * need to call it for the AGP bridge after that so it gets
> + * small positive I/O port numbers.
> + */
> + if (u3_ht)
> + pci_setup_phb_io(u3_ht, 1);
> + if (u3_agp)
> + pci_setup_phb_io(u3_agp, 0);
> + if (u4_pcie)
> + pci_setup_phb_io(u4_pcie, 0);
> +
> /* Fixup the IO resources on our host bridges as the common code
> * does it only for childs of the host bridges
> */
> @@ -479,6 +631,9 @@ int maple_pci_get_legacy_ide_irq(struct
> /* XXX: To remove once all firmwares are ok */
> static void fixup_maple_ide(struct pci_dev* dev)
> {
> + if (!machine_is(maple))
> + return;
> +
> #if 0 /* Enable this to enable IDE port 0 */
> {
> u8 v;
> @@ -495,7 +650,7 @@ static void fixup_maple_ide(struct pci_d
> dev->resource[4].start = 0xcc00;
> dev->resource[4].end = 0xcc10;
> #endif
> -#if 1 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
> +#if 0 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
> {
> struct pci_dev *apicdev;
> u32 v;
Do the changes to fixup_maple_ide have anything to do with the rest of
the patch? It's not clear from your description. And with that last
hunk the function now appears to do nothing.
Could we consider merging the powermac and maple pci code into a
common location that would be used by both platforms? There's quite a
bit of code duplication going on here...
^ permalink raw reply
* Re: powerpc: Fix make rules for dtc
From: Segher Boessenkool @ 2006-10-05 17:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20061004033753.GB20636@localhost.localdomain>
> clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
> - $(obj)/empty.c
> + $(obj)/empty.c *.dtb
If this wildcard works at all, it will still do the wrong thing:
deleting all .dtb files (even the ones that the Makefile cannot
create again, e.g., the user put them in the tree manually) is
at best not very polite.
Segher
^ permalink raw reply
* Re: [PATCH] clean up pseries hcall interfaces
From: Geoff Levand @ 2006-10-05 18:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <44D267EA.8050103@am.sony.com>
Geoff Levand wrote:
> Paul Mackerras wrote:
>> Geoff Levand writes:
>>
>>> Change the scope of some pSeries routines now called through
>>> ppc_md to static.
>>
>> With this I get:
>>
>> CC arch/powerpc/platforms/pseries/lpar.o
>> /home/paulus/kernel/powerpc/arch/powerpc/platforms/pseries/lpar.c:273: error: static declaration of ^[$B!F^[(BpSeries_lpar_hpte_insert^[$B!G^[(B follows non-static declaration
>> include2/asm/mmu.h:254: error: previous declaration of ^[$B!F^[(BpSeries_lpar_hpte_insert^[$B!G^[(B was here
>> make[3]: *** [arch/powerpc/platforms/pseries/lpar.o] Error 1
>
> OK, thanks for checking it. As I mentioned in my original
> mail, it just looked like there could be some cleanup done,
> but I didn't test it. I'll take a look at it some more and
> see if I can make a proper re-work.
Sorry it took so long to get this out. Updated patch follows.
-Geoff
Change the powerpc hpte_insert routines now called through ppc_md to static
scope.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Did build tests with pseries_defconfig, iseries_defconfig and a cell
platform.
Index: cell--common--5/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- cell--common--5.orig/arch/powerpc/platforms/pseries/lpar.c
+++ cell--common--5/arch/powerpc/platforms/pseries/lpar.c
@@ -268,7 +268,7 @@
cpu, hwcpu, vpa, ret);
}
-long pSeries_lpar_hpte_insert(unsigned long hpte_group,
+static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
unsigned long va, unsigned long pa,
unsigned long rflags, unsigned long vflags,
int psize)
@@ -494,7 +494,7 @@
* Take a spinlock around flushes to avoid bouncing the hypervisor tlbie
* lock.
*/
-void pSeries_lpar_flush_hash_range(unsigned long number, int local)
+static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
{
int i;
unsigned long flags = 0;
Index: cell--common--5/include/asm-powerpc/mmu.h
===================================================================
--- cell--common--5.orig/include/asm-powerpc/mmu.h
+++ cell--common--5/include/asm-powerpc/mmu.h
@@ -248,21 +248,6 @@
extern void hpte_init_lpar(void);
extern void hpte_init_iSeries(void);
-extern long pSeries_lpar_hpte_insert(unsigned long hpte_group,
- unsigned long va, unsigned long prpn,
- unsigned long rflags,
- unsigned long vflags, int psize);
-
-extern long native_hpte_insert(unsigned long hpte_group,
- unsigned long va, unsigned long prpn,
- unsigned long rflags,
- unsigned long vflags, int psize);
-
-extern long iSeries_hpte_insert(unsigned long hpte_group,
- unsigned long va, unsigned long prpn,
- unsigned long rflags,
- unsigned long vflags, int psize);
-
extern void stabs_alloc(void);
extern void slb_initialize(void);
extern void slb_flush_and_rebolt(void);
Index: cell--common--5/arch/powerpc/mm/hash_native_64.c
===================================================================
--- cell--common--5.orig/arch/powerpc/mm/hash_native_64.c
+++ cell--common--5/arch/powerpc/mm/hash_native_64.c
@@ -123,7 +123,7 @@
clear_bit(HPTE_LOCK_BIT, word);
}
-long native_hpte_insert(unsigned long hpte_group, unsigned long va,
+static long native_hpte_insert(unsigned long hpte_group, unsigned long va,
unsigned long pa, unsigned long rflags,
unsigned long vflags, int psize)
{
^ permalink raw reply
* [PATCH] powerpc: minor fix for bootargs property
From: Geoff Levand @ 2006-10-05 18:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Avoid the use of an uninitialized stack variable when the powerpc device tree
bootargs property is either missing or incorrectly defined. This also makes
CONFIG_CMDLINE work properly under these conditions. This change adds a test
for the existence of the bootargs property.
early_init_dt_scan_chosen() tests for a zero length bootargs property in its
CONFIG_CMDLINE processing, but the current implementation of
of_get_flat_dt_prop() doesn't assign a value to the length when no property is
found. Since an automatic variable is used, a stale value from the stack will
be used in the test.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: cell--common--5/arch/powerpc/kernel/prom.c
===================================================================
--- cell--common--5.orig/arch/powerpc/kernel/prom.c
+++ cell--common--5/arch/powerpc/kernel/prom.c
@@ -724,7 +724,7 @@
strlcpy(cmd_line, p, min((int)l, COMMAND_LINE_SIZE));
#ifdef CONFIG_CMDLINE
- if (l == 0 || (l == 1 && (*p) == 0))
+ if (p == NULL || l == 0 || (l == 1 && (*p) == 0))
strlcpy(cmd_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
#endif /* CONFIG_CMDLINE */
^ permalink raw reply
* Re: [PATCH] powerpc: make U4 PCIe work
From: Segher Boessenkool @ 2006-10-05 18:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1160024098.22232.13.camel@localhost.localdomain>
> + if (bus == hose->first_busno) {
> + caddr = U4_PCIE_CFA0(dev_fn, offset);
> + } else
> + caddr = U4_PCIE_CFA1(bus, dev_fn, offset);
Please fold CFA0 and CFA1 into one inline function, much
cleaner.
You also should check (at init time) whether indirect config
access mode is actually enabled -- or just enable it yourself.
> + /* Uninorth will return garbage if we don't read back the
> value ! */
> + do {
> + out_le32(hose->cfg_addr, caddr);
> + } while (in_le32(hose->cfg_addr) != caddr);
Not an issue on U4, kill this.
> +static int u4_pcie_read_config(struct pci_bus *bus, unsigned int
> devfn,
> + int offset, int len, u32 *val)
> +{
> + struct pci_controller *hose;
> + volatile void __iomem *addr;
> +
> + hose = pci_bus_to_host(bus);
> + if (hose == NULL)
> + return PCIBIOS_DEVICE_NOT_FOUND;
Is this check needed? Can this code ever be called if hose would
be 0? The variable isn't actually used anywhere else in this
function either.
> + struct pci_controller *hose;
> + volatile void __iomem *addr;
No need for the volatile, the inXX()/outXX() things should handle
this just fine.
> + /* The bus contains a bridge from root -> device, we need to
> + * make it visible on bus 0 so that we pick the right type
> + * of config cycles. If we didn't, we would have to force all
> + * config cycles to be type 1. So we override the "bus-range"
> + * property here
> + */
> + hose->first_busno = 0x00;
> + hose->last_busno = 0xff;
I don't understand the comment, nor the need for this code. Is this
just old garbage ported over from PowerMac?
> + for_each_pci_dev(dev) {
> + /* Fixup IRQ for PCIe host */
> + if (u4_pcie != NULL && dev->bus->number == 0 &&
> + pci_bus_to_host(dev->bus) == u4_pcie) {
> + printk(KERN_DEBUG "Fixup U4 PCIe IRQ\n");
> + dev->irq = irq_create_mapping(NULL, 1);
> + if (dev->irq != NO_IRQ)
> + set_irq_type(dev->irq, IRQ_TYPE_LEVEL_LOW);
Please do this in the platform code for boards that actually need
it, by fixing up the interrupt tree in the device tree. MPIC IRQ1
is the PCIe error interrupt only btw, I wonder if this code does
the right thing at all?
> + /*
> + * We need to call pci_setup_phb_io for the HT bridge first
> + * so it gets the I/O port numbers starting at 0, and we
> + * need to call it for the AGP bridge after that so it gets
> + * small positive I/O port numbers.
> + */
Comment out of date (doesn't mention PCIe). Oh and when do we
finally get real PCI domain support ;-)
> + if (!machine_is(maple))
> + return;
So the IDE wart fixup is now only executed on "real" Maples? Or
all 970-based non-Apple boxes? The naming starts to be confusing,
maybe the maple platform should be en-masse renamed to "ppc970" or
such.
Segher
^ permalink raw reply
* [PATCH] spufs: change ppc_rtas declaration to weak
From: Geoff Levand @ 2006-10-05 18:35 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Arnd Bergmann
The symbol ppc_rtas is defined as weak, but the declaration is missing the
weak attribute specifier. The improper declaration causes problems when
linking the ppc_rtas reference in spu_syscall_table[] (spu_callbacks.c)
when RTAS support is not enabled.
Fixes this powerpc build error with CONFIG_SPU_FS=y, CONFIG_PPC_RTAS=n:
arch/powerpc/platforms/built-in.o: undefined reference to `ppc_rtas'
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
I did a test build with pseries_defconfig and verified the proper routine is
linked in. No run time test done.
Index: cell--common--5/include/asm-powerpc/syscalls.h
===================================================================
--- cell--common--5.orig/include/asm-powerpc/syscalls.h
+++ cell--common--5/include/asm-powerpc/syscalls.h
@@ -37,7 +37,7 @@
asmlinkage int sys_ipc(uint call, int first, unsigned long second,
long third, void __user *ptr, long fifth);
asmlinkage long ppc64_personality(unsigned long personality);
-asmlinkage int ppc_rtas(struct rtas_args __user *uargs);
+asmlinkage int ppc_rtas(struct rtas_args __user *uargs) __attribute__((weak));
asmlinkage time_t sys64_time(time_t __user * tloc);
asmlinkage long ppc_newuname(struct new_utsname __user * name);
^ 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