* 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
* Re: common flatdevtree code
From: Segher Boessenkool @ 2006-09-28 0:51 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1159401139.7584.82.camel@basalt.austin.ibm.com>
>> 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);
And then everything but ft_{un,}pack() don't actually operate on
a flat tree anymore; so change the prefix? How about using of_
instead :-)
[Do you see where this is going? :-) ]
Segher
^ permalink raw reply
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Kim Phillips @ 2006-09-28 4:43 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060927155853.GB2385@smtp.west.cox.net>
On Wed, 27 Sep 2006 08:58:53 -0700
Tom Rini <trini@kernel.crashing.org> wrote:
> 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).
>
this is indeed the case, as with the static assignment of the ppc_md rtc_time functions in define_machine. In the early assignment case, the kernel oopses early in rtc_class_open().
During testing I noticed hwclock get/set operations worked even without hooking up with the ppc_md rtc_time functions. Turns out this rtc_class provides access to the RTC to the whole kernel and userspace:
http://lkml.org/lkml/2005/12/20/220
so, both of these patches are really unnecessary, unless there's a genuine consumer in arch/powerpc that I can't find (I'm assuming get_boot_time() isn't one of them since it gets called way too early in the rtc-over-i2c based platform case).
So we should just configure RTC_CLASS and the specific chip and we're done. :)
Kim
^ permalink raw reply
* [PATCH] ppc: fix build break
From: Olof Johansson @ 2006-09-28 4:57 UTC (permalink / raw)
To: paulus, galak, Vitaly Bordug; +Cc: linuxppc-dev
Fix build break for some of the ARCH=ppc defconfigs
Signed-off-by: Olof Johansson <olof@lixom.net>
---
This was introduced by:
[PATCH] ppc32: board-specific part of fs_enet update
Index: linux-2.6/include/asm-ppc/cpm2.h
===================================================================
--- linux-2.6.orig/include/asm-ppc/cpm2.h
+++ linux-2.6/include/asm-ppc/cpm2.h
@@ -1186,7 +1186,7 @@ typedef struct im_idma {
#define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
#define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
-#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(2)
+#define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
#endif /* __CPM2__ */
#endif /* __KERNEL__ */
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Enable MSI on Powerpc
From: Michael Ellerman @ 2006-09-28 6:07 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1159386365.5542.115.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
On Wed, 2006-09-27 at 14:46 -0500, Jake Moilanen wrote:
> 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?
Maybe. If we use PPC then MSI will get built for arch/ppc as well which
won't work - so I think we should have a POWERPC symbol, I sent that as
a separate patch a while back but it seems to have hit the floor.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-28 6:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <C62AC4D8-39E5-44D0-88A3-E8D8042FC828@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, September 27, 2006 9:34 PM
> To: Li Yang-r58472
> Cc: Vitaly Bordug; linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> >>>> +memory {
> >>>> + device_type =3D "memory";
> >>>> + linux,phandle =3D <300>;
> >>>> + reg =3D <00000000 4000000 f4500000 00000020>;
> >>>> + };
> >>>> the second pair is about bcsr and its size.
> >>>>
> >>>> Just in case this may help (and wondering if I'm not violating
> >>> something :) )
> >>>
> >>> Well, this can make it work. But I would prefer to use a new node
> >>> because the BCSR is by no means a memory type of device. I have
> > made my
> >>> change to use node like this:
> >>>
> >>> bcsr@f8000000 {
> >>> device_type =3D "board-control";
> >>> reg =3D <f8000000 8000>;
> >>> };
> >>>
> >>
> >> I though about that approach, but saw somewhere a reference that we
> > should not summon
> >> new node types without utter necessity, and utilized memory because
> > bcsr is
> >> memory-mapped stuff. I can hardly imagine bcsr as a device (which
> > would require
> >> respective spec inclusion btw).
> >
> > Well I didn't see such a guideline. However BCSR is truly a device
> > like
> > any other peripherals on board. Usually it is an FPGA on local bus
to
> > control the board.
>=20
> Agree that a new node is better, calling it memory isn't right.
> However, I'm not sure this really needs a node in the device tree.
> The BCSR isn't really the same from board to board last time I
> checked. I'd be interested in Paul's thinking about why it should be
> in the tree.
>=20
> >> hence let's open a discussion what others think about that. The
> > problem seems common
> >> (and for some boards
> >> is called somewhat else apparently), but at this point we should
come
> > to some
> >> conclusion, document it, and use it.
> >
> > Agreed. As we are adding more devices to the device tree, we should
> > also have a guideline clearly stated for adding new nodes.
> >
> > I'm adding MURAM as a new node under QE bus. Please comment.
> > muram@10000 {
> > device_type =3D "memory";
> > ranges =3D <0 00010000 0000c000>;
> >
> > data-only@0{
> > reg =3D <0 c000>;
> > };
> > };
>=20
> What was the need for this?
Data-only defines MURAM area which can be allocated for data and
parameter ram. Some MURAM space can be occupied by microcode or
microcode patch, and should be excluded from allocation.
- Leo
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-28 6:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E1GSaAn-000340-DD@jdl.com>
> -----Original Message-----
> From: Jon Loeliger [mailto:jdl@jdl.com]
> Sent: Wednesday, September 27, 2006 10:14 PM
> To: Li Yang-r58472
> Cc: Vitaly Bordug; linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> So, like, the other day "Li Yang-r58472" mumbled:
>=20
> > Agreed. As we are adding more devices to the device tree, we should
> > also have a guideline clearly stated for adding new nodes.
> >
> > I'm adding MURAM as a new node under QE bus. Please comment.
> > muram@10000 {
> > device_type =3D "memory";
> > ranges =3D <0 00010000 0000c000>;
> >
> > data-only@0{
> > reg =3D <0 c000>;
> > };
> > };
> >
> > - Leo
>=20
> So, does it make sense for this node to participate in the early scan
> of memory available during the early_init_dt_scan_memory() pass?
>=20
Are all "memory" type nodes regarded as system memory during the early
scan? If so, it needs to use a new device_type "muram" I think.
> Out of curiosity, is "data-only" a standard thing, or did you make
> that up too? What's it mean?
Well, it is from kernel code of cpm/cpm2 era. It defines the MURAM area
which can be freely allocated. The base and size of such area vary
between chips and revisions, even boards.
- Leo
^ 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