* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-27 15:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060913132817.GD18263@igloo.df.lth.se>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Wed 13 Sep 15:28 CEST 2006, Fredrik Roubert wrote:
> > Matt's u-boot patches address the issue well for 85xx, they are
> > straightforward to adapt to 83xx:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_id=15518792&forum_id=12898
>
> OK, I've adapted and applied those patches now.
In case someone else also is interested in using Matt's flat device tree
patches with U-Boot 1.1.4, I've posted my backport of the relevant parts
of the patch to the u-boot-users mailing list now.
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Tom Rini @ 2006-09-27 15:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B35FD5A1-2C71-41E2-A014-A2C8D37F10C2@kernel.crashing.org>
On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
[snip]
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > powerpc/platforms/83xx/mpc834x_itx.c
> > index 969fbb6..8c676d7 100644
> > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > return 1;
> > }
> >
> > +#ifdef CONFIG_RTC_CLASS
> > +late_initcall(rtc_class_hookup);
> > +#endif
>
> Any reason we can't just do this in setup_arch?
I think because of rtc-over-i2c and similar where we need the whole rest
of the system 'up' before we can try and use the RTC (which might not be
the case for this specific board, but for consistency it looks like a
good thing to always do it like this).
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 1/2] Add powerpc get/set_rtc_time interface to new generic rtc class
From: Tom Rini @ 2006-09-27 15:59 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060926174637.1f70938d.kim.phillips@freescale.com>
On Tue, Sep 26, 2006 at 05:46:37PM -0500, Kim Phillips wrote:
[snip]
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -39,6 +39,10 @@ extern void generic_calibrate_decr(void)
> extern void wakeup_decrementer(void);
> extern void snapshot_timebase(void);
>
> +#ifdef CONFIG_RTC_CLASS
> +extern int __init rtc_class_hookup(void);
> +#endif
Conditional code doesn't usually get externs ifdef'd, unless I'm
mistaken.
--
Tom Rini
^ permalink raw reply
* RE: Asterisk on Embedded Linux
From: Stelios Koroneos @ 2006-09-27 16:01 UTC (permalink / raw)
To: Iwan Koenig, Linuxppc-embedded
In-Reply-To: <20060926064451.71706.qmail@web26012.mail.ukl.yahoo.com>
> -----Original Message-----
> Does anyone known how to compile Asterisk for a
> powerpc-processor?
Asterisk + bristuff (for isdn support) for uclibc does crosscompile (and
run) but needs patching in several places (make files and asterisk itself).
We got the zaptel drivers to cross-compile also but it seems there are
endianess issues with the drivers we now try to iron out.
The main "difference" is that we have used OpenEmbedded as our build system
in order to get going.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Olof Johansson @ 2006-09-27 16:22 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Paul, Mackerras
In-Reply-To: <CE624A83-809E-4180-800E-660A578FFCFC@embeddedalley.com>
On Wed, 27 Sep 2006 10:42:17 -0400 Dan Malek <dan@embeddedalley.com> wrote:
> Since BCSRs are board specific, does anyone remember
> the day when a simple #define, ioremap, and a few lines
> of code in the board setup file was all that was needed? :-)
Yes, also called "board port hell". One of the major points with the
device tree is that the needed information for the system is in there,
not compiled into the kernel. So you can boot the same kernel binary on
several boards, as long as the drivers are built in and the correct
device tree is used. Has everyone missed/forgotten that objective
completely?
> What wrong with still doing that? It seems everyone is
> obsessed with device tree syntax and forget that a
> few lines of code may still be a reasonable solution.
The device tree describes the system, not how to program it. I think
that's where the confusion might be.
I.e. create a generic "board-controller" device node, and put a
suitable "compatible" property in there, so the right board controller
driver can be chosen based on it. Having the address of the controller
in there helps too, especially if there are two boards out there with
the same controller but at different memory location.
-Olof
^ permalink raw reply
* iommu hypervisor hypothetical
From: John Rose @ 2006-09-27 16:47 UTC (permalink / raw)
To: Santiago Leon, benh, External List
Suppose the hypervisor added new failure codes for the hcall that does
tce_build(). Suppose that the device driver needed to expect such
failures when alloc_[coherent,consistent] is not successful, and handle
that case accordingly.
Is this something we can accommodate without rewriting the iommu stuff
for various platforms? All these functions in machdep.h are defined to
return NULL. Is this because we haven't had a reasonable expectation of
failure, or because device drivers _have_ to assume success for such
operations?
Thanks-
John
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Esben Nielsen @ 2006-09-27 16:52 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <4518FA21.8050801@cambridgebroadband.com>
On Tue, 26 Sep 2006, Alex Zeffertt wrote:
> Hi list,
>
> I'm having a strange problem with interrupts. My platform is the
> MPC832xEMDS and the BSP I'm using (from Freescale) uses Linux-2.6.11.
>
> In the code below I enter a critical section with local_irq_save(),
> call request_irq() (from mpc832xemds_phy_interrupt_enable) 4 times,
> then exit the critical section using local_irq_restore.
>
> /* Enable interrupts from PHYs */
> local_irq_save(flags);
> for (i = 0; i < driver_data->num_phys; i++) {
> struct atm_dev *dev = driver_data->dev_data[i]->dev;
> printk("%s/%d\n",__FUNCTION__,__LINE__);
> RETURN_ON_ERROR(mpc832xemds_phy_interrupt_enable(dev));
> }
> local_irq_restore(flags);
>
This is a pure side-comment:
Please, don't use local_irq_save() for a critical region. Use
spin_lock_irqsave(), for 3 reasons:
1) SMP.
2) Preempt-realtime is like SMP not happy about using local_irq_save().
3) Read-ability: It is more clear what data is protected when there is a
named lock object in the code.
You might not care about 1) and 2) but 3) should matter for you. And
remember: When CONFIG_SMP is not set spin_lock_irqsave() will just
become a local_irq_save().
Esben
^ permalink raw reply
* Re: iommu hypervisor hypothetical
From: Olof Johansson @ 2006-09-27 17:07 UTC (permalink / raw)
To: John Rose; +Cc: External, Santiago Leon, List
In-Reply-To: <1159375671.19103.3.camel@sinatra.austin.ibm.com>
On Wed, 27 Sep 2006 11:47:51 -0500 John Rose <johnrose@austin.ibm.com> wrote:
> Suppose the hypervisor added new failure codes for the hcall that does
> tce_build(). Suppose that the device driver needed to expect such
> failures when alloc_[coherent,consistent] is not successful, and handle
> that case accordingly.
>
> Is this something we can accommodate without rewriting the iommu stuff
> for various platforms? All these functions in machdep.h are defined to
> return NULL. Is this because we haven't had a reasonable expectation of
> failure, or because device drivers _have_ to assume success for such
> operations?
iommu_alloc can already fail. So just change the prototype of tce_build
to return success/failure, and handle it accordingly in iommu_alloc
(DMA_ERROR_CODE). The error should move on up the stack from there.
Or did I misunderstand your question in the first place? It's sort of
sparse on details. :-)
-Olof
^ permalink raw reply
* [PATCH 2.6.19-rc1] ehea firmware interface based on Anton Blanchard's new hvcall interface
From: Jan-Bernd Themann @ 2006-09-27 16:47 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, pmac, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
Hi Jeff,
the last patch did not work, so here is the new patch. The patch is build against
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev.2.6.git HEAD today.
Could you give it a try?
This eHEA patch reflects changes according to Anton's new hvcall interface
which has been commited in Paul's git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
In addition to the above changes the patch includes a bug fix (port state
notification) and minor changes (default queue length, coding style updates).
Thanks,
Jan-Bernd
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 13
drivers/net/ehea/ehea_ethtool.c | 2
drivers/net/ehea/ehea_main.c | 6
drivers/net/ehea/ehea_phyp.c | 559 ++++++++++++++++------------------------
4 files changed, 242 insertions(+), 338 deletions(-)
diff -Nurp netdev-2.6/drivers/net/ehea/ehea.h netdev-2.6_patched/drivers/net/ehea/ehea.h
--- netdev-2.6/drivers/net/ehea/ehea.h 2006-09-26 10:27:38.000000000 +0200
+++ netdev-2.6_patched/drivers/net/ehea/ehea.h 2006-09-26 19:28:22.000000000 +0200
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0028"
+#define DRV_VERSION "EHEA_0033"
#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_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_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 -Nurp netdev-2.6/drivers/net/ehea/ehea_ethtool.c netdev-2.6_patched/drivers/net/ehea/ehea_ethtool.c
--- netdev-2.6/drivers/net/ehea/ehea_ethtool.c 2006-09-26 10:27:38.000000000 +0200
+++ netdev-2.6_patched/drivers/net/ehea/ehea_ethtool.c 2006-09-26 19:28:22.000000000 +0200
@@ -270,7 +270,7 @@ static void ehea_get_ethtool_stats(struc
kfree(cb6);
}
-const struct ethtool_ops ehea_ethtool_ops = {
+struct ethtool_ops ehea_ethtool_ops = {
.get_settings = ehea_get_settings,
.get_drvinfo = ehea_get_drvinfo,
.get_msglevel = ehea_get_msglevel,
diff -Nurp netdev-2.6/drivers/net/ehea/ehea_main.c netdev-2.6_patched/drivers/net/ehea/ehea_main.c
--- netdev-2.6/drivers/net/ehea/ehea_main.c 2006-09-26 10:27:38.000000000 +0200
+++ netdev-2.6_patched/drivers/net/ehea/ehea_main.c 2006-09-26 19:28:22.000000000 +0200
@@ -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);
diff -Nurp netdev-2.6/drivers/net/ehea/ehea_phyp.c netdev-2.6_patched/drivers/net/ehea/ehea_phyp.c
--- netdev-2.6/drivers/net/ehea/ehea_phyp.c 2006-09-26 10:27:38.000000000 +0200
+++ netdev-2.6_patched/drivers/net/ehea/ehea_phyp.c 2006-09-26 19:28:22.000000000 +0200
@@ -44,71 +44,99 @@ static inline u16 get_order_of_qentries(
#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 */
+ 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 */
- init_attr->qp_nr = (u32)r5_out;
+ *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 */
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- cq_attr->act_nr_of_cqes = act_nr_of_cqes_out;
- cq_attr->nr_pages = act_pages_out;
+ 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 @@ u64 ehea_h_alloc_resource_cq(const u64 a
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;
- }
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- 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;
+ 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;
+ 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 */
- 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;
+ 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;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- 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;
+ 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;
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- 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;
+ 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
* Re: iommu hypervisor hypothetical
From: John Rose @ 2006-09-27 18:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: Santiago Leon, External List
In-Reply-To: <20060927120723.678eee22@localhost.localdomain>
> So just change the prototype of tce_build
> to return success/failure, and handle it accordingly in iommu_alloc
> (DMA_ERROR_CODE). The error should move on up the stack from there.
I'm thinking of functions like dma_map_single(), which returns the
unsigned type dma_addr_t. Suppose H_HCE_PUT fails, and this gets
propagated up to the device driver through DMA_ERROR_CODE. The PAPR
currently defines 2 ways in which this could fail, and we're considering
at least one more. One error code doesn't seem sufficient.
> Or did I misunderstand your question in the first place? It's sort of
> sparse on details. :-)
You know how it goes :) I guess my question is whether passing specific
failure conditions up the call chain is permissible/feasible, and
whether the prototypes for the various device driver DMA utilities are
set in stone.
Thanks-
John
^ permalink raw reply
* Re: iommu hypervisor hypothetical
From: Olof Johansson @ 2006-09-27 18:40 UTC (permalink / raw)
To: John Rose; +Cc: External, Santiago Leon, List
In-Reply-To: <1159381557.19103.17.camel@sinatra.austin.ibm.com>
On Wed, 27 Sep 2006 13:25:57 -0500 John Rose <johnrose@austin.ibm.com> wrote:
> > So just change the prototype of tce_build
> > to return success/failure, and handle it accordingly in iommu_alloc
> > (DMA_ERROR_CODE). The error should move on up the stack from there.
>
> I'm thinking of functions like dma_map_single(), which returns the
> unsigned type dma_addr_t. Suppose H_HCE_PUT fails, and this gets
> propagated up to the device driver through DMA_ERROR_CODE. The PAPR
> currently defines 2 ways in which this could fail, and we're considering
> at least one more. One error code doesn't seem sufficient.
So you need to know in the driver why it failed, to take separate
actions based on why? Driver/device events aren't communicated in any
other manner?
> > Or did I misunderstand your question in the first place? It's sort of
> > sparse on details. :-)
>
> You know how it goes :) I guess my question is whether passing specific
> failure conditions up the call chain is permissible/feasible, and
> whether the prototypes for the various device driver DMA utilities are
> set in stone.
You could expand to other DMA_ERROR_.* codes, as long as you modify
dma_mapping_error accordingly.
-Olof
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Enable MSI on Powerpc
From: Jake Moilanen @ 2006-09-27 19:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060818081331.E6F7267B5D@ozlabs.org>
On Fri, 2006-08-18 at 18:13 +1000, Michael Ellerman wrote:
> Allow PCI_MSI to build on POWERPC.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> drivers/pci/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: git/drivers/pci/Kconfig
> ===================================================================
> --- git.orig/drivers/pci/Kconfig
> +++ git/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 || POWERPC
Shouldn't this be PPC?
> help
> This allows device drivers to enable MSI (Message Signaled
> Interrupts). Message Signaled Interrupts enable a device to
^ permalink raw reply
* Allocalting > 4M
From: Rune Torgersen @ 2006-09-27 20:34 UTC (permalink / raw)
To: linuxppc-embedded
We have an embedded board with 1G of memory.
Is there any way, short of using mem=3D on kernel command line and
reserving memory, to allocate more than 4M of contigous physical memory?
We're trying to allocalte a 8M buffer for use in some DMA transfers for
a bank of DSP's.
We were using get_Free_pages to allocate the meory before we made the
buffer bigger. It seems that get_free_pages cannot allocate more than
2^10 pages (4M on ppc)
I also tried alloc_bootmem, but it fails also.
^ permalink raw reply
* Re: Allocalting > 4M
From: Arnd Bergmann @ 2006-09-27 21:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0189DF9C@ismail.innsys.innovsys.com>
Am Wednesday 27 September 2006 22:34 schrieb Rune Torgersen:
> Is there any way, short of using mem= on kernel command line and
> reserving memory, to allocate more than 4M of contigous physical memory?
> We're trying to allocalte a 8M buffer for use in some DMA transfers for
> a bank of DSP's.
> We were using get_Free_pages to allocate the meory before we made the
> buffer bigger. It seems that get_free_pages cannot allocate more than
> 2^10 pages (4M on ppc)
> I also tried alloc_bootmem, but it fails also.
alloc_bootmem is supposed to handle this case, but you can only call
that very early in your code, before the buddy allocator kicks in
(free_all_bootmem()). Maybe you should just check why it fails for you.
Arnd <><
^ permalink raw reply
* RE: Allocalting > 4M
From: Rune Torgersen @ 2006-09-27 21:29 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <200609272300.16962.arnd@arndb.de>
=20
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]=20
> alloc_bootmem is supposed to handle this case, but you can only call
> that very early in your code, before the buddy allocator kicks in
> (free_all_bootmem()). Maybe you should just check why it=20
> fails for you.
I was calling it in the wrong board init function.=20
m82xx_board_init was too early, and our platform_init was too late.
It works now.
^ permalink raw reply
* Re: Allocalting > 4M
From: Roger Larsson @ 2006-09-27 20:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0189DF9C@ismail.innsys.innovsys.com>
On Wednesday 27 September 2006 22:34, Rune Torgersen wrote:
> We have an embedded board with 1G of memory.
>
> Is there any way, short of using mem= on kernel command line and
> reserving memory, to allocate more than 4M of contigous physical memory?
> We're trying to allocalte a 8M buffer for use in some DMA transfers for
> a bank of DSP's.
> We were using get_Free_pages to allocate the meory before we made the
> buffer bigger. It seems that get_free_pages cannot allocate more than
> 2^10 pages (4M on ppc)
> I also tried alloc_bootmem, but it fails also.
There is a 'bigphysmem' patch for 2.4 that might help. There might be
alternative solutions to this problem, they should refere to bigphysmem
- might help when googling...
/RogerL
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehea firmware interface based on Anton Blanchard's new hvcall interface
From: Jeff Garzik @ 2006-09-27 21:52 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, pmac, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
In-Reply-To: <200609271847.34258.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Hi Jeff,
>
> the last patch did not work, so here is the new patch. The patch is build against
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev.2.6.git HEAD today.
> Could you give it a try?
Per the standard patch format in Documentation/SubmittingPatches, these
sort of comments should go beneath the "---" separator. Otherwise, if
they are not hand-edited out, they will go into the final changeset
description.
> This eHEA patch reflects changes according to Anton's new hvcall interface
> which has been commited in Paul's git tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
When is this going upstream? I don't want things to get too out-of-sync.
> In addition to the above changes the patch includes a bug fix (port state
> notification) and minor changes (default queue length, coding style updates).
These changes should be in a separate patch. Makes 'git bisect' work
better, makes the changes more reviewable, and in general follows the
"separate logical changes" rule.
> diff -Nurp netdev-2.6/drivers/net/ehea/ehea_ethtool.c netdev-2.6_patched/drivers/net/ehea/ehea_ethtool.c
> --- netdev-2.6/drivers/net/ehea/ehea_ethtool.c 2006-09-26 10:27:38.000000000 +0200
> +++ netdev-2.6_patched/drivers/net/ehea/ehea_ethtool.c 2006-09-26 19:28:22.000000000 +0200
> @@ -270,7 +270,7 @@ static void ehea_get_ethtool_stats(struc
> kfree(cb6);
> }
>
> -const struct ethtool_ops ehea_ethtool_ops = {
> +struct ethtool_ops ehea_ethtool_ops = {
> .get_settings = ehea_get_settings,
> .get_drvinfo = ehea_get_drvinfo,
> .get_msglevel = ehea_get_msglevel,
This is an obvious regression.
Jeff
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehea firmware interface based on Anton Blanchard's new hvcall interface
From: Paul Mackerras @ 2006-09-27 22:23 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, pmac, Jan-Bernd Themann, linux-kernel,
Christoph Raisch, linux-ppc, Marcus Eder
In-Reply-To: <451AF29D.2030102@garzik.org>
Jeff,
> > This eHEA patch reflects changes according to Anton's new hvcall interface
> > which has been commited in Paul's git tree:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>
> When is this going upstream? I don't want things to get too out-of-sync.
It's upstream already, and currently the ehea driver in Linus' tree
doesn't compile as a result.
Paul.
^ permalink raw reply
* Re: [PATCH 2.6.19-rc1] ehea firmware interface based on Anton Blanchard's new hvcall interface
From: Jeff Garzik @ 2006-09-27 22:30 UTC (permalink / raw)
To: Paul Mackerras
Cc: Thomas Klein, pmac, Jan-Bernd Themann, linux-kernel,
Christoph Raisch, linux-ppc, Marcus Eder
In-Reply-To: <17690.63978.373862.727933@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Jeff,
>
>>> This eHEA patch reflects changes according to Anton's new hvcall interface
>>> which has been commited in Paul's git tree:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>> When is this going upstream? I don't want things to get too out-of-sync.
>
> It's upstream already, and currently the ehea driver in Linus' tree
> doesn't compile as a result.
Thanks for the clarification. The original quoted text sorta implied
the opposite.
Jeff
^ permalink raw reply
* Re: common flatdevtree code
From: Paul Mackerras @ 2006-09-27 22:32 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20060919194527.GD11361@mag.az.mvista.com>
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 581 bytes --]
Here's the latest version of my version of the flatdevtree code...
I talked to David Gibson about this and he pointed out that there is a
problem with using a void * to identify nodes (i.e. returned from
ft_find_device and passed to ft_set_prop etc.). The problem is that
if we reallocate the space for the tree, then any void * handles that
the user of the library has are then invalid. Perhaps we have to use
offsets from the beginning of the struct region instead - the offset
for a node will be stable across changes of the node or any of its
descendents, at least.
Paul.
[-- Attachment #2: flatdevtree.c --]
[-- Type: application/x-csrc, Size: 18790 bytes --]
[-- Attachment #3: flatdevtree.h --]
[-- Type: application/x-chdr, Size: 4049 bytes --]
^ permalink raw reply
* Re: common flatdevtree code
From: Hollis Blanchard @ 2006-09-27 22:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17690.64482.319084.61866@cargo.ozlabs.ibm.com>
On Thu, 2006-09-28 at 08:32 +1000, Paul Mackerras wrote:
> Here's the latest version of my version of the flatdevtree code...
>
> I talked to David Gibson about this and he pointed out that there is a
> problem with using a void * to identify nodes (i.e. returned from
> ft_find_device and passed to ft_set_prop etc.). The problem is that
> if we reallocate the space for the tree, then any void * handles that
> the user of the library has are then invalid. Perhaps we have to use
> offsets from the beginning of the struct region instead - the offset
> for a node will be stable across changes of the node or any of its
> descendents, at least.
That is a non-obvious requirement and therefore a poor API.
Using offsets instead of pointers barely helps. All pointers break if
you need to realloc space for the tree. Almost all offsets break in the
exact same way (except for the ancestors of a particular node).
This may be a good reason to go back to the
ft_set_prop("/node/property", value, len);
interface, instead of
n = ft_find_node("/node");
ft_set_prop(n, "property", value, len);
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: iommu hypervisor hypothetical
From: Benjamin Herrenschmidt @ 2006-09-27 23:11 UTC (permalink / raw)
To: John Rose; +Cc: Olof Johansson, External List, Santiago Leon
In-Reply-To: <1159381557.19103.17.camel@sinatra.austin.ibm.com>
On Wed, 2006-09-27 at 13:25 -0500, John Rose wrote:
> > So just change the prototype of tce_build
> > to return success/failure, and handle it accordingly in iommu_alloc
> > (DMA_ERROR_CODE). The error should move on up the stack from there.
>
> I'm thinking of functions like dma_map_single(), which returns the
> unsigned type dma_addr_t. Suppose H_HCE_PUT fails, and this gets
> propagated up to the device driver through DMA_ERROR_CODE. The PAPR
> currently defines 2 ways in which this could fail, and we're considering
> at least one more. One error code doesn't seem sufficient.
That's a design issue with the linux API that has been around for some
time. At first, there was no possible error return from dma_map_single()
in fact :( DMA_ERROR_CODE was added, and I see no way to do something
better from that function...
> > Or did I misunderstand your question in the first place? It's sort of
> > sparse on details. :-)
>
> You know how it goes :) I guess my question is whether passing specific
> failure conditions up the call chain is permissible/feasible, and
> whether the prototypes for the various device driver DMA utilities are
> set in stone.
>
> Thanks-
> John
^ permalink raw reply
* Uncompressing Kernel Image ... Error: inflate() returned -3 GUNZIP ERROR - must RESET board to recover
From: Henry Bausley @ 2006-09-27 22:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <HOECLKEKOHLAMMGDLLBHGEKJHLAA.stelios@stelioscellar.com>
I am getting the error
Uncompressing Kernel Image ... Error: inflate() returned -3
GUNZIP ERROR - must RESET board to recover
OK
when u-boot tries to uncompress the kernel. I am using a board based upon a
Yosemite AMCC 440EP.
I do have some boards that work. Does anyone know what could cause this
problem. Bad Flash , Bad DDR ?
U-Boot 1.1.4 (Jun 30 2006 - 14:55:59)
CPU: AMCC PowerPC 440EP Rev. B at 533.333 MHz (PLB=133, OPB=66, EBC=66
MHz)
I2C boot EEPROM enabled
Internal PCI arbiter disabled, PCI async ext clock used
32 kB I-Cache 32 kB D-Cache
Board: Yosemite - AMCC PPC440EP Evaluation Board
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
Net: ppc_4xx_eth0, ppc_4xx_eth1
Hit any key to stop autoboot: 0
## Booting image at fc000000 ...
Image Name: Linux-2.6.14-rtl
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1250069 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... Error: inflate() returned -3
GUNZIP ERROR - must RESET board to recover
OK
^ permalink raw reply
* Re: common flatdevtree code
From: Segher Boessenkool @ 2006-09-27 23:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <17690.64482.319084.61866@cargo.ozlabs.ibm.com>
> I talked to David Gibson about this and he pointed out that there is a
> problem with using a void * to identify nodes (i.e. returned from
> ft_find_device and passed to ft_set_prop etc.). The problem is that
> if we reallocate the space for the tree, then any void * handles that
> the user of the library has are then invalid. Perhaps we have to use
> offsets from the beginning of the struct region instead - the offset
> for a node will be stable across changes of the node or any of its
> descendents, at least.
Or unpack the tree before you operate on it. You can pack it
again later if you need to pass it as a flat tree again (or the
bootwrapper could implement a real OF client interface, which
is useful for many more things!)
A flat contiguous blob of bytes is convenient to pass around,
but not such a great data structure for basically anything else ;-)
Segher
^ permalink raw reply
* Re: common flatdevtree code
From: Hollis Blanchard @ 2006-09-27 23:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <6897081F-DDAC-462A-8D4D-EE613231CA4B@kernel.crashing.org>
On Thu, 2006-09-28 at 01:41 +0200, Segher Boessenkool wrote:
> > I talked to David Gibson about this and he pointed out that there is a
> > problem with using a void * to identify nodes (i.e. returned from
> > ft_find_device and passed to ft_set_prop etc.). The problem is that
> > if we reallocate the space for the tree, then any void * handles that
> > the user of the library has are then invalid. Perhaps we have to use
> > offsets from the beginning of the struct region instead - the offset
> > for a node will be stable across changes of the node or any of its
> > descendents, at least.
>
> Or unpack the tree before you operate on it. You can pack it
> again later if you need to pass it as a flat tree again (or the
> bootwrapper could implement a real OF client interface, which
> is useful for many more things!)
>
> A flat contiguous blob of bytes is convenient to pass around,
> but not such a great data structure for basically anything else ;-)
I agree; I think this data structure's design is explicitly static, and
now we're trying to dynamically edit it.
We essentially need to do unpack/pack now whenever the size of the
structure changes (e.g. changing a property size, adding or removing
anything). Making that explicit (and one-time) might be a good idea:
tree = ft_unpack(blob);
n = ft_find_node(tree, "/node");
ft_set_prop(n, "property", value, len);
...
blob = ft_pack(tree);
--
Hollis Blanchard
IBM Linux Technology Center
^ 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