* Re: dtc: Remove bogus break statement
From: Jon Loeliger @ 2007-07-02 13:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, 5B
In-Reply-To: <20070628013231.GF15298@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Commit 0738774fcc34b78a708a127fb4b2f193d08c94ba introduced some
> incorrect indentation / bracketing in unflatten_tree(). By luck, the
> extra break statement intended to be within an if block, but actually
> afterwards has no semantic effect. Still, this patch gets rid of it
> for cleanliness.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH/RESENT] ehea: Whitespace cleanup
From: Jeff Garzik @ 2007-07-02 12:38 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200707021300.46813.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> This patch fixes several whitespace issues.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 12:03 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706292113240.4227@poirot.grange>
> + while ((node = of_get_next_child(adap_node, node))) {
of_for_each_child_node() or whatever it is called?
> + addr = of_get_property(node, "reg", &len);
> + if (!addr || len < sizeof(int) || *addr > 0xffff)
> + continue;
Addresses aren't 16 bit AFAIK?
> + name = of_get_property(node, "compatible", NULL);
> + if (!name)
> + name = node->name;
> + if (!name)
> + continue;
Look at "name" first, then look at "compatible", not
the other way around.
> + model = of_get_property(node, "model", NULL);
> + if (!model)
> + model = name;
No way. "model" and "name" have nothing in common
semantically.
> + /* FIXME: the i2c code should allow drivers to specify
> + * multiple match names; board code shouldn't need to
> + * know what driver will handle a given type.
> + */
This should be handled by the OF matching stuff, there
is no direct connection between device tree naming and
Linux driver naming. I don't want to see this patch
going in without this problem being fixed first.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 11:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <E6C54DC8-3152-4EE6-A1A1-389B41B23FC9@kernel.crashing.org>
>> Add of_register_i2c_devices(), which scans the children of the
>> specified
>> I2C adapter node, and registers them with the I2C code.
>>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
>
> I'm still against this patch since it means we are stating that I2C
> devices in the device tree must us the linux driver names. The two
> should be de-coupled.
Very much so. More comments as reply to the original post...
Segher
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Segher Boessenkool @ 2007-07-02 11:51 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <20070628100020.GA24215@iram.es>
>> + external-control;
>>
>> Really?
>
> Well, is anybody actually using eciwx/ecowx?
That's not the point -- the device tree should only
say "external-control" if the CPU actually supports
it; AFAIK, that's 601 only.
>> + pci@80000000 {
>> + device_type = "pci";
>> + compatible = "prep";
>>
>> Is that specific enough?
>
> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
> space is smaller and at a higher address.
Right, so it's not; "compatible" should specify the
model of PCI host bridge, instead.
>> What is the plan here -- have the bootwrapper build the
>> device tree / fill in the details from the residual data?
>
> I think so.
Right, good. What's the way forward then -- David, rename
this DTS file to <board name>.dts so you have something to
boot, and at the same time work on the bootwrapper?
> I might have some time to try a more recent kernel
> on MVME2400/2600 boards next week.
Great!
Segher
^ permalink raw reply
* [PATCH/RESENT] ehea: Whitespace cleanup
From: Jan-Bernd Themann @ 2007-07-02 11:00 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
This patch fixes several whitespace issues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0f81b5..abaf3ac 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0064"
+#define DRV_VERSION "EHEA_0065"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -136,10 +136,10 @@ void ehea_dump(void *adr, int len, char *msg);
(0xffffffffffffffffULL >> ((64 - (mask)) & 0xffff))
#define EHEA_BMASK_SET(mask, value) \
- ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
+ ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
#define EHEA_BMASK_GET(mask, value) \
- (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
+ (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
/*
* Generic ehea page
@@ -190,7 +190,7 @@ struct ehea_av;
* Queue attributes passed to ehea_create_qp()
*/
struct ehea_qp_init_attr {
- /* input parameter */
+ /* input parameter */
u32 qp_token; /* queue token */
u8 low_lat_rq1;
u8 signalingtype; /* cqe generation flag */
@@ -212,7 +212,7 @@ struct ehea_qp_init_attr {
u64 recv_cq_handle;
u64 aff_eq_handle;
- /* output parameter */
+ /* output parameter */
u32 qp_nr;
u16 act_nr_send_wqes;
u16 act_nr_rwqes_rq1;
@@ -279,12 +279,12 @@ struct ehea_qp {
* Completion Queue attributes
*/
struct ehea_cq_attr {
- /* input parameter */
+ /* input parameter */
u32 max_nr_of_cqes;
u32 cq_token;
u64 eq_handle;
- /* output parameter */
+ /* output parameter */
u32 act_nr_of_cqes;
u32 nr_pages;
};
diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h
index 1246757..1af7ca4 100644
--- a/drivers/net/ehea/ehea_hw.h
+++ b/drivers/net/ehea/ehea_hw.h
@@ -211,34 +211,34 @@ static inline void epa_store_acc(struct h_epa epa, u32 offset, u64 value)
}
#define epa_store_eq(epa, offset, value)\
- epa_store(epa, EQTEMM_OFFSET(offset), value)
+ epa_store(epa, EQTEMM_OFFSET(offset), value)
#define epa_load_eq(epa, offset)\
- epa_load(epa, EQTEMM_OFFSET(offset))
+ epa_load(epa, EQTEMM_OFFSET(offset))
#define epa_store_cq(epa, offset, value)\
- epa_store(epa, CQTEMM_OFFSET(offset), value)
+ epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
- epa_load(epa, CQTEMM_OFFSET(offset))
+ epa_load(epa, CQTEMM_OFFSET(offset))
#define epa_store_qp(epa, offset, value)\
- epa_store(epa, QPTEMM_OFFSET(offset), value)
+ epa_store(epa, QPTEMM_OFFSET(offset), value)
#define epa_load_qp(epa, offset)\
- epa_load(epa, QPTEMM_OFFSET(offset))
+ epa_load(epa, QPTEMM_OFFSET(offset))
#define epa_store_qped(epa, offset, value)\
- epa_store(epa, QPEDMM_OFFSET(offset), value)
+ epa_store(epa, QPEDMM_OFFSET(offset), value)
#define epa_load_qped(epa, offset)\
- epa_load(epa, QPEDMM_OFFSET(offset))
+ epa_load(epa, QPEDMM_OFFSET(offset))
#define epa_store_mrmw(epa, offset, value)\
- epa_store(epa, MRMWMM_OFFSET(offset), value)
+ epa_store(epa, MRMWMM_OFFSET(offset), value)
#define epa_load_mrmw(epa, offset)\
- epa_load(epa, MRMWMM_OFFSET(offset))
+ epa_load(epa, MRMWMM_OFFSET(offset))
#define epa_store_base(epa, offset, value)\
- epa_store(epa, HCAGR_OFFSET(offset), value)
+ epa_store(epa, HCAGR_OFFSET(offset), value)
#define epa_load_base(epa, offset)\
- epa_load(epa, HCAGR_OFFSET(offset))
+ epa_load(epa, HCAGR_OFFSET(offset))
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9e13433..bdb5241 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive queues, Default = 1 ");
static int port_name_cnt = 0;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
- const struct of_device_id *id);
+ const struct of_device_id *id);
static int __devexit ehea_remove(struct ibmebus_dev *dev);
@@ -236,7 +236,7 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
- | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
+ | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe->sg_list[0].l_key = pr->recv_mr.lkey;
rwqe->sg_list[0].vaddr = (u64)skb->data;
rwqe->sg_list[0].len = packet_size;
@@ -427,7 +427,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
break;
}
skb_copy_to_linear_data(skb, ((char*)cqe) + 64,
- cqe->num_bytes_transfered - 4);
+ cqe->num_bytes_transfered - 4);
ehea_fill_skb(port->netdev, skb, cqe);
} else if (rq == 2) { /* RQ2 */
skb = get_skb_by_index(skb_arr_rq2,
@@ -618,7 +618,7 @@ static struct ehea_port *ehea_get_port(struct ehea_adapter *adapter,
for (i = 0; i < EHEA_MAX_PORTS; i++)
if (adapter->port[i])
- if (adapter->port[i]->logical_port_id == logical_port)
+ if (adapter->port[i]->logical_port_id == logical_port)
return adapter->port[i];
return NULL;
}
@@ -1695,6 +1695,7 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
{
if (skb->protocol == htons(ETH_P_IP)) {
const struct iphdr *iph = ip_hdr(skb);
+
/* IPv4 */
swqe->tx_control |= EHEA_SWQE_CRC
| EHEA_SWQE_IP_CHECKSUM
@@ -1705,13 +1706,12 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
write_ip_start_end(swqe, skb);
if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
+ if ((iph->frag_off & IP_MF)
+ || (iph->frag_off & IP_OFFSET))
/* IP fragment, so don't change cs */
swqe->tx_control &= ~EHEA_SWQE_TCP_CHECKSUM;
else
write_udp_offset_end(swqe, skb);
-
} else if (iph->protocol == IPPROTO_TCP) {
write_tcp_offset_end(swqe, skb);
}
@@ -1739,6 +1739,7 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
if (skb->protocol == htons(ETH_P_IP)) {
const struct iphdr *iph = ip_hdr(skb);
+
/* IPv4 */
write_ip_start_end(swqe, skb);
@@ -1751,8 +1752,8 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
write_tcp_offset_end(swqe, skb);
} else if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
+ if ((iph->frag_off & IP_MF)
+ || (iph->frag_off & IP_OFFSET))
/* IP fragment, so don't change cs */
swqe->tx_control |= EHEA_SWQE_CRC
| EHEA_SWQE_IMM_DATA_PRESENT;
@@ -2407,7 +2408,7 @@ static void __devinit logical_port_release(struct device *dev)
}
static int ehea_driver_sysfs_add(struct device *dev,
- struct device_driver *driver)
+ struct device_driver *driver)
{
int ret;
@@ -2424,7 +2425,7 @@ static int ehea_driver_sysfs_add(struct device *dev,
}
static void ehea_driver_sysfs_remove(struct device *dev,
- struct device_driver *driver)
+ struct device_driver *driver)
{
struct device_driver *drv = driver;
@@ -2453,7 +2454,7 @@ static struct device *ehea_register_port(struct ehea_port *port,
}
ret = device_create_file(&port->ofdev.dev, &dev_attr_log_port_id);
- if (ret) {
+ if (ret) {
ehea_error("failed to register attributes, ret=%d", ret);
goto out_unreg_of_dev;
}
@@ -2601,6 +2602,7 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
{
struct device_node *lhea_dn;
struct device_node *eth_dn = NULL;
+
const u32 *dn_log_port_id;
int i = 0;
@@ -2608,7 +2610,7 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
dn_log_port_id = of_get_property(eth_dn, "ibm,hea-port-no",
- NULL);
+ NULL);
if (!dn_log_port_id) {
ehea_error("bad device node: eth_dn name=%s",
eth_dn->full_name);
@@ -2648,7 +2650,7 @@ static struct device_node *ehea_get_eth_dn(struct ehea_adapter *adapter,
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
dn_log_port_id = of_get_property(eth_dn, "ibm,hea-port-no",
- NULL);
+ NULL);
if (dn_log_port_id)
if (*dn_log_port_id == logical_port_id)
return eth_dn;
@@ -2789,7 +2791,7 @@ static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
adapter->ebus_dev = dev;
adapter_handle = of_get_property(dev->ofdev.node, "ibm,hea-handle",
- NULL);
+ NULL);
if (adapter_handle)
adapter->handle = *adapter_handle;
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index f24a886..29eaa46 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -211,7 +211,7 @@ u64 ehea_destroy_cq_res(struct ehea_cq *cq, u64 force)
u64 hret;
u64 adapter_handle = cq->adapter->handle;
- /* deregister all previous registered pages */
+ /* deregister all previous registered pages */
hret = ehea_h_free_resource(adapter_handle, cq->fw_handle, force);
if (hret != H_SUCCESS)
return hret;
@@ -362,7 +362,7 @@ int ehea_destroy_eq(struct ehea_eq *eq)
if (hret != H_SUCCESS) {
ehea_error("destroy EQ failed");
return -EIO;
- }
+ }
return 0;
}
@@ -507,44 +507,44 @@ out_freemem:
u64 ehea_destroy_qp_res(struct ehea_qp *qp, u64 force)
{
- u64 hret;
- struct ehea_qp_init_attr *qp_attr = &qp->init_attr;
+ u64 hret;
+ struct ehea_qp_init_attr *qp_attr = &qp->init_attr;
- ehea_h_disable_and_get_hea(qp->adapter->handle, qp->fw_handle);
- hret = ehea_h_free_resource(qp->adapter->handle, qp->fw_handle, force);
- if (hret != H_SUCCESS)
- return hret;
+ ehea_h_disable_and_get_hea(qp->adapter->handle, qp->fw_handle);
+ hret = ehea_h_free_resource(qp->adapter->handle, qp->fw_handle, force);
+ if (hret != H_SUCCESS)
+ return hret;
- hw_queue_dtor(&qp->hw_squeue);
- hw_queue_dtor(&qp->hw_rqueue1);
+ hw_queue_dtor(&qp->hw_squeue);
+ hw_queue_dtor(&qp->hw_rqueue1);
- if (qp_attr->rq_count > 1)
- hw_queue_dtor(&qp->hw_rqueue2);
- if (qp_attr->rq_count > 2)
- hw_queue_dtor(&qp->hw_rqueue3);
- kfree(qp);
+ if (qp_attr->rq_count > 1)
+ hw_queue_dtor(&qp->hw_rqueue2);
+ if (qp_attr->rq_count > 2)
+ hw_queue_dtor(&qp->hw_rqueue3);
+ kfree(qp);
- return hret;
+ return hret;
}
int ehea_destroy_qp(struct ehea_qp *qp)
{
- u64 hret;
- if (!qp)
- return 0;
+ u64 hret;
+ if (!qp)
+ return 0;
- if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
- ehea_error_data(qp->adapter, qp->fw_handle);
- hret = ehea_destroy_qp_res(qp, FORCE_FREE);
- }
+ if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
+ ehea_error_data(qp->adapter, qp->fw_handle);
+ hret = ehea_destroy_qp_res(qp, FORCE_FREE);
+ }
- if (hret != H_SUCCESS) {
- ehea_error("destroy QP failed");
- return -EIO;
- }
+ if (hret != H_SUCCESS) {
+ ehea_error("destroy QP failed");
+ return -EIO;
+ }
- return 0;
+ return 0;
}
int ehea_reg_kernel_mr(struct ehea_adapter *adapter, struct ehea_mr *mr)
^ permalink raw reply related
* [PATCH] Handle alignment faults on new FP load/store instructions
From: Paul Mackerras @ 2007-07-02 10:56 UTC (permalink / raw)
To: linuxppc-dev
This adds code to handle alignment traps generated by the following
new floating-point load/store instructions, by emulating the
instruction in the kernel (as is done for other instructions that
generate alignment traps):
lfiwax load floating-point as integer word algebraic indexed
stfiwx store floating-point as integer word indexed
lfdp load floating-point double pair
lfdpx load floating-point double pair indexed
stfdp store floating-point double pair
stfdpx store floating-point double pair indexed
All these except stfiwx are new in POWER6.
lfdp/lfdpx/stfdp/stfdpx load and store 16 bytes of memory into an
even/odd FP register pair. In little-endian mode each 8-byte value is
byte-reversed separately (i.e. not as a 16-byte unit). lfiwax/stfiwx
load or store the lower 4 bytes of a floating-point register from/to
memory; lfiwax sets the upper 4 bytes of the FP register to the sign
extension of the value loaded.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 5c9ff7f..4d01cf4 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -38,7 +38,7 @@ struct aligninfo {
/* Bits in the flags field */
#define LD 0 /* load */
#define ST 1 /* store */
-#define SE 2 /* sign-extend value */
+#define SE 2 /* sign-extend value, or FP ld/st as word */
#define F 4 /* to/from fp regs */
#define U 8 /* update index register */
#define M 0x10 /* multiple load/store */
@@ -87,9 +87,9 @@ static struct aligninfo aligninfo[128] = {
{ 8, LD+F+U }, /* 00 1 1001: lfdu */
{ 4, ST+F+S+U }, /* 00 1 1010: stfsu */
{ 8, ST+F+U }, /* 00 1 1011: stfdu */
- INVALID, /* 00 1 1100 */
+ { 16, LD+F }, /* 00 1 1100: lfdp */
INVALID, /* 00 1 1101 */
- INVALID, /* 00 1 1110 */
+ { 16, ST+F }, /* 00 1 1110: stfdp */
INVALID, /* 00 1 1111 */
{ 8, LD }, /* 01 0 0000: ldx */
INVALID, /* 01 0 0001 */
@@ -167,10 +167,10 @@ static struct aligninfo aligninfo[128] = {
{ 8, LD+F }, /* 11 0 1001: lfdx */
{ 4, ST+F+S }, /* 11 0 1010: stfsx */
{ 8, ST+F }, /* 11 0 1011: stfdx */
- INVALID, /* 11 0 1100 */
- { 8, LD+M }, /* 11 0 1101: lmd */
- INVALID, /* 11 0 1110 */
- { 8, ST+M }, /* 11 0 1111: stmd */
+ { 16, LD+F }, /* 11 0 1100: lfdpx */
+ { 4, LD+F+SE }, /* 11 0 1101: lfiwax */
+ { 16, ST+F }, /* 11 0 1110: stfdpx */
+ { 4, ST+F }, /* 11 0 1111: stfiwx */
{ 4, LD+U }, /* 11 1 0000: lwzux */
INVALID, /* 11 1 0001 */
{ 4, ST+U }, /* 11 1 0010: stwux */
@@ -356,6 +356,43 @@ static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
return 1;
}
+/*
+ * Emulate floating-point pair loads and stores.
+ * Only POWER6 has these instructions, and it does true little-endian,
+ * so we don't need the address swizzling.
+ */
+static int emulate_fp_pair(struct pt_regs *regs, unsigned char __user *addr,
+ unsigned int reg, unsigned int flags)
+{
+ char *ptr = (char *) ¤t->thread.fpr[reg];
+ int i, ret;
+ unsigned long p;
+
+ if (!(flags & F))
+ return 0;
+ if (reg & 1)
+ return 0; /* invalid form: FRS/FRT must be even */
+ if (!(flags & SW)) {
+ /* not byte-swapped - easy */
+ if (!(flags & ST))
+ ret = __copy_from_user(ptr, addr, 16);
+ else
+ ret = __copy_to_user(addr, ptr, 16);
+ } else {
+ /* each FPR value is byte-swapped separately */
+ ret = 0;
+ for (i = 0; i < 16; ++i) {
+ if (!(flags & ST))
+ ret |= __get_user(ptr[i^7], addr + i);
+ else
+ ret |= __put_user(ptr[i^7], addr + i);
+ }
+ }
+ if (ret)
+ return -EFAULT;
+ return 0;
+}
+
/*
* Called on alignment exception. Attempts to fixup
@@ -471,6 +508,10 @@ int fix_alignment(struct pt_regs *regs)
flush_fp_to_thread(current);
}
+ /* Special case for 16-byte FP loads and stores */
+ if (nb == 16)
+ return emulate_fp_pair(regs, addr, reg, flags);
+
/* If we are loading, get the data from user space, else
* get it from register values
*/
@@ -531,7 +572,8 @@ int fix_alignment(struct pt_regs *regs)
* or floating point single precision conversion
*/
switch (flags & ~(U|SW)) {
- case LD+SE: /* sign extend */
+ case LD+SE: /* sign extending integer loads */
+ case LD+F+SE: /* sign extend for lfiwax */
if ( nb == 2 )
data.ll = data.x16.low16;
else /* nb must be 4 */
^ permalink raw reply related
* Linux Process Address Space
From: SHIERA LYN DELUSA @ 2007-07-02 9:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
Hello,
Based on the following thread regarding Linux memory map:
http://ozlabs.org/pipermail/linuxppc-embedded/2000-May/001333.html
Obviously, I am still a newbie in Linux kernel and I find it hard to grasp
things especially Linux MM. I quoted some lines from this thread (from
Dan's post), then some follow-up questions. I do hope you could help me out
in these:
1.) *"Virtual addresses from 0 to 0x7fffffff are for user context."*
a.) If TASK_SIZE is defined as 0x80000000, does this necessarily mean
that 2G-2G split is used?
2.) *"For this reason, and since it followed prior PowerPC platform
examples, I chose to map the embedded 8xx kernel to the 0xc0000000 virtual
address."*
a.) This 0xc0000000 virtual address must be defined as the value of
PAGE_OFFSET, right?
b.) Does this mean that the kernel's .text section is located in this
address?
c.) If user space is only up to 0x80000000, and the kernel starts at
0xc0000000, what could possibly be located in between?
3.) *"Prior to this KVM initialization, we choose to map virtual to
physical addresses 1:1. That is, the kernel virtual address exactly matches
the physical address on the bus. These mappings are typically done in
arch/ppc/kernel/head.S, or arch/ppc/mm/init.c. Only absolutely necessary
mappings should be done at this time, for example board control registers or
a serial uart. Normal device driver initialization should map resources
later when necessary." *
a.) Is there any chance that the mapping done here is relocated later
in the initialization process?
I would really appreciate your input on this. Thank you very much!
Regards,
Shiera
[-- Attachment #2: Type: text/html, Size: 2525 bytes --]
^ permalink raw reply
* (no subject)
From: 陈苏铿 @ 2007-07-02 9:08 UTC (permalink / raw)
To: linuxppc-embedded
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-07-02 6:04 UTC (permalink / raw)
To: torvalds, linuxppc-dev
In-Reply-To: <18056.32340.502484.171937@cargo.ozlabs.ibm.com>
Linus,
I wrote:
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> My defconfig updates exposed some compile failures on powerpc, which
> these three commits fix.
I have added another commit with a defconfig update for the Freescale
embedded platforms, from Kumar Gala, so you'll get 4 commits when you
do the pull.
Thanks,
Paul.
arch/powerpc/configs/mpc7448_hpc2_defconfig | 212 +++++++-----------
arch/powerpc/configs/mpc8272_ads_defconfig | 293 +++++++++++++++----------
arch/powerpc/configs/mpc8313_rdb_defconfig | 310 +++++++++++++-------------
arch/powerpc/configs/mpc832x_mds_defconfig | 176 ++++++---------
arch/powerpc/configs/mpc832x_rdb_defconfig | 229 ++++++++-----------
arch/powerpc/configs/mpc834x_itx_defconfig | 265 +++++++++++-----------
arch/powerpc/configs/mpc834x_itxgp_defconfig | 232 ++++++++++---------
arch/powerpc/configs/mpc834x_mds_defconfig | 195 ++++++++--------
arch/powerpc/configs/mpc836x_mds_defconfig | 176 ++++++---------
arch/powerpc/configs/mpc8540_ads_defconfig | 201 ++++++++---------
arch/powerpc/configs/mpc8544_ds_defconfig | 193 +++++++---------
arch/powerpc/configs/mpc8560_ads_defconfig | 201 ++++++++---------
arch/powerpc/configs/mpc8568mds_defconfig | 191 +++++++---------
arch/powerpc/configs/mpc85xx_cds_defconfig | 206 +++++++++--------
arch/powerpc/configs/mpc8641_hpcn_defconfig | 200 ++++++++---------
arch/powerpc/configs/mpc866_ads_defconfig | 213 +++++++++---------
arch/powerpc/configs/mpc885_ads_defconfig | 222 +++++++++----------
17 files changed, 1763 insertions(+), 1952 deletions(-)
commit 795bb15e0735bd2b0015ca333fa157399b72c168
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Jul 2 00:04:36 2007 -0500
[POWERPC] Update defconfigs
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: [RFC: 2.6 patch] ppc: remove APUS support
From: Geert Uytterhoeven @ 2007-07-01 22:55 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-m68k, linux-kernel, linuxppc-dev, Paul Mackerras,
Kumar Gala, David Gibson
In-Reply-To: <20070701202206.GO10869@stusta.de>
On Sun, 1 Jul 2007, Adrian Bunk wrote:
> Current status of APUS:
> - arch/powerpc/: a patch to remove it is in powerpc.git
> - arch/ppc/: marked BROKEN since 2 years
>
> This patch therefore removes the remaining parts of APUS support.
> --- linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h.old 2007-06-30 01:23:33.000000000 +0200
> +++ linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h 2007-06-30 01:23:43.000000000 +0200
> @@ -107,8 +107,6 @@ extern void *empty_zero_page;
> /* 64-bit machines, beware! SRB. */
> #define SIZEOF_PTR_LOG2 2
>
> -#define mm_end_of_chunk(addr, len) 0
> -
> extern void kernel_set_cachemode(void *addr, unsigned long size, int cmode);
>
> /*
> --- linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c.old 2007-06-30 01:23:53.000000000 +0200
> +++ linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c 2007-06-30 01:24:08.000000000 +0200
> @@ -46,8 +46,7 @@ static int dma_setup(struct scsi_cmnd *c
> struct Scsi_Host *instance = cmd->device->host;
>
> /* don't allow DMA if the physical address is bad */
> - if (addr & A2091_XFER_MASK ||
> - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> + if (addr & A2091_XFER_MASK)
> {
> HDATA(instance)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> & ~0x1ff;
> --- linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c.old 2007-06-30 01:24:17.000000000 +0200
> +++ linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c 2007-06-30 01:24:26.000000000 +0200
> @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> * end of a physical memory chunk, then allocate a bounce
> * buffer
> */
> - if (addr & A3000_XFER_MASK ||
> - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> + if (addr & A3000_XFER_MASK)
> {
> HDATA(a3000_host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> & ~0x1ff;
> --- linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c.old 2007-06-30 01:24:35.000000000 +0200
> +++ linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c 2007-06-30 01:24:46.000000000 +0200
> @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> static int scsi_alloc_out_of_range = 0;
>
> /* use bounce buffer if the physical address is bad */
> - if (addr & HDATA(cmd->device->host)->dma_xfer_mask ||
> - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> + if (addr & HDATA(cmd->device->host)->dma_xfer_mask)
> {
> HDATA(cmd->device->host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> & ~0x1ff;
These seem to be completely unrelated to removing APUS support?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-07-02 4:25 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
My defconfig updates exposed some compile failures on powerpc, which
these three commits fix.
Thanks,
Paul.
arch/powerpc/kernel/irq.c | 6 ++++++
arch/powerpc/platforms/cell/cbe_cpufreq.c | 15 ++++++++++-----
drivers/net/Kconfig | 2 +-
include/asm-powerpc/irq.h | 5 +----
4 files changed, 18 insertions(+), 10 deletions(-)
commit 9f7905812e5919862acb6ede63e10d3d1bb4958e
Author: Olof Johansson <olof@lixom.net>
Date: Mon Jun 4 14:47:04 2007 +1000
[POWERPC] Uninline and export virq_to_hw() for the pasemi_mac driver
Uninline virq_to_hw and export it so modules can use it. The alternative
would be to export the irq_map array instead, but it's an infrequently
called function, and keeping the array unexported seems considerably
cleaner.
This is needed so that the pasemi_mac driver can be compiled as a module.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ee5d1b7f2a01ce4d95ca247b5a499b72f31cdbe8
Author: Christian Krafft <krafft@de.ibm.com>
Date: Thu Jun 28 21:14:38 2007 +1000
[POWERPC] Fix PMI breakage in cbe_cbufreq driver
The recent change to cell_defconfig to enable cpufreq on Cell exposed
the fact that the cbe_cpufreq driver currently needs the PMI interface
code to compile, but Kconfig doesn't make sure that the PMI interface
code gets built if cbe_cpufreq is enabled.
In fact cbe_cpufreq can work without PMI, so this ifdefs out the code
that deals with PMI. This is a minimal solution for 2.6.22; a more
comprehensive solution will be merged for 2.6.23.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 86affd5a00a92e491e5f00ed659492767519fdf7
Author: David Gibson <david@gibson.dropbear.id.au>
Date: Thu Jun 28 11:27:57 2007 +1000
[POWERPC] Disable old EMAC driver in arch/powerpc
The EMAC driver, in drivers/net/ibm_emac, for the embedded Ethernet
MAC found in PowerPC 4xx embedded chips is not suitable for
arch/powerpc. It will not build because it relies on the old arch/ppc
OCP mechanism. BenH has a new, device-tree aware version of the
driver which will work in arch/powerpc, but until it's merged, this
patch will disable the old, non-building version.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Anyone using QE UART mode?
From: Ying Lin @ 2007-07-02 2:49 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
How to enable TTY devices using QUICC Engine UCC UART Mode?
Are Linux kernel patches enough to enable them? Or, additional
programming required?
The kernel has QE patches, and I am able to use QE Ethernet. Also, I
can choose the QE slow UART mode in kernel configurations. But, can not
see TTY devices from QE.
Thanks,
Ying
[-- Attachment #2: Type: text/html, Size: 3856 bytes --]
^ permalink raw reply
* [PATCH] pseries: don't die if unknown/missing interrupt controller property
From: Sonny Rao @ 2007-07-02 0:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, miltonm
The pseries platform does not have a default function for init_IRQ and
does not install one if it doesn't find or doesn't recognize an
interrupt controller in the device tree. Currently, the kernel dies
when it tries to call the NULL init_IRQ() function. Clean that up.
Signed-off-by: Sonny Rao <sonny@burdell.org>
--- kernel/arch/powerpc/platforms/pseries/setup.c~orig 2007-06-26 16:23:38.000000000 -0500
+++ kernel/arch/powerpc/platforms/pseries/setup.c 2007-06-26 19:09:53.000000000 -0500
@@ -274,6 +274,12 @@ static void pseries_lpar_enable_pmcs(voi
get_lppaca()->pmcregs_in_use = 1;
}
+static void no_irq_init(void)
+{
+ printk(KERN_ERR "no_irq_init: failed to recognize"
+ " interrupt-controller\n");
+}
+
static void __init pseries_discover_pic(void)
{
struct device_node *np;
@@ -296,8 +302,6 @@ static void __init pseries_discover_pic(
return;
}
}
- printk(KERN_ERR "pSeries_discover_pic: failed to recognize"
- " interrupt-controller\n");
}
static void __init pSeries_setup_arch(void)
@@ -594,4 +598,5 @@ define_machine(pseries) {
.check_legacy_ioport = pSeries_check_legacy_ioport,
.system_reset_exception = pSeries_system_reset_exception,
.machine_check_exception = pSeries_machine_check_exception,
+ .init_IRQ = no_irq_init,
};
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Kumar Gala @ 2007-07-01 23:36 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706292113240.4227@poirot.grange>
On Jun 29, 2007, at 2:20 PM, Guennadi Liakhovetski wrote:
> Add of_register_i2c_devices(), which scans the children of the
> specified
> I2C adapter node, and registers them with the I2C code.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
I'm still against this patch since it means we are stating that I2C
devices in the device tree must us the linux driver names. The two
should be de-coupled.
- k
>
> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/
> prom_parse.c
> index 3786dcc..9caf96d 100644
> --- a/arch/powerpc/kernel/prom_parse.c
> +++ b/arch/powerpc/kernel/prom_parse.c
> @@ -1067,3 +1067,49 @@ void __iomem *of_iomap(struct device_node
> *np, int index)
> return ioremap(res.start, 1 + res.end - res.start);
> }
> EXPORT_SYMBOL(of_iomap);
> +
> +#ifdef CONFIG_I2C
> +#include <linux/i2c.h>
> +
> +void of_register_i2c_devices(struct device_node *adap_node, int
> bus_num)
> +{
> + struct device_node *node = NULL;
> +
> + while ((node = of_get_next_child(adap_node, node))) {
> + struct i2c_board_info info;
> + const u32 *addr;
> + const char *name, *model;
> + int len;
> +
> + addr = of_get_property(node, "reg", &len);
> + if (!addr || len < sizeof(int) || *addr > 0xffff)
> + continue;
> +
> + info.irq = irq_of_parse_and_map(node, 0);
> + if (info.irq == NO_IRQ)
> + info.irq = -1;
> +
> + name = of_get_property(node, "compatible", NULL);
> + if (!name)
> + name = node->name;
> + if (!name)
> + continue;
> +
> + model = of_get_property(node, "model", NULL);
> + if (!model)
> + model = name;
> +
> + /* FIXME: the i2c code should allow drivers to specify
> + * multiple match names; board code shouldn't need to
> + * know what driver will handle a given type.
> + */
> +
> + snprintf(info.driver_name, KOBJ_NAME_LEN, name);
> + snprintf(info.type, KOBJ_NAME_LEN, model);
> + info.platform_data = NULL;
> + info.addr = *addr;
> +
> + i2c_register_board_info(bus_num, &info, 1);
> + }
> +}
> +#endif /* CONFIG_I2C */
> diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
> index 6845af9..ed085e1 100644
> --- a/include/asm-powerpc/prom.h
> +++ b/include/asm-powerpc/prom.h
> @@ -305,6 +305,7 @@ extern int of_irq_map_raw(struct device_node
> *parent, const u32 *intspec,
> u32 ointsize, const u32 *addr,
> struct of_irq *out_irq);
>
> +void of_register_i2c_devices(struct device_node *adap_node, int
> bus_num);
>
> /**
> * of_irq_map_one - Resolve an interrupt for a device
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC: 2.6 patch] ppc: remove APUS support
From: Geert Uytterhoeven @ 2007-07-01 23:24 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-m68k, linux-kernel, linuxppc-dev, Paul Mackerras,
Kumar Gala, David Gibson
In-Reply-To: <20070701230843.GD10869@stusta.de>
On Mon, 2 Jul 2007, Adrian Bunk wrote:
> On Mon, Jul 02, 2007 at 12:55:36AM +0200, Geert Uytterhoeven wrote:
> > On Sun, 1 Jul 2007, Adrian Bunk wrote:
> > > Current status of APUS:
> > > - arch/powerpc/: a patch to remove it is in powerpc.git
> > > - arch/ppc/: marked BROKEN since 2 years
> > >
> > > This patch therefore removes the remaining parts of APUS support.
> >
> > > --- linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h.old 2007-06-30 01:23:33.000000000 +0200
> > > +++ linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h 2007-06-30 01:23:43.000000000 +0200
> > > @@ -107,8 +107,6 @@ extern void *empty_zero_page;
> > > /* 64-bit machines, beware! SRB. */
> > > #define SIZEOF_PTR_LOG2 2
> > >
> > > -#define mm_end_of_chunk(addr, len) 0
> > > -
> > > extern void kernel_set_cachemode(void *addr, unsigned long size, int cmode);
> > >
> > > /*
> > > --- linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c.old 2007-06-30 01:23:53.000000000 +0200
> > > +++ linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c 2007-06-30 01:24:08.000000000 +0200
> > > @@ -46,8 +46,7 @@ static int dma_setup(struct scsi_cmnd *c
> > > struct Scsi_Host *instance = cmd->device->host;
> > >
> > > /* don't allow DMA if the physical address is bad */
> > > - if (addr & A2091_XFER_MASK ||
> > > - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > > + if (addr & A2091_XFER_MASK)
> > > {
> > > HDATA(instance)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > > & ~0x1ff;
> > > --- linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c.old 2007-06-30 01:24:17.000000000 +0200
> > > +++ linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c 2007-06-30 01:24:26.000000000 +0200
> > > @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> > > * end of a physical memory chunk, then allocate a bounce
> > > * buffer
> > > */
> > > - if (addr & A3000_XFER_MASK ||
> > > - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > > + if (addr & A3000_XFER_MASK)
> > > {
> > > HDATA(a3000_host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > > & ~0x1ff;
> > > --- linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c.old 2007-06-30 01:24:35.000000000 +0200
> > > +++ linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c 2007-06-30 01:24:46.000000000 +0200
> > > @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> > > static int scsi_alloc_out_of_range = 0;
> > >
> > > /* use bounce buffer if the physical address is bad */
> > > - if (addr & HDATA(cmd->device->host)->dma_xfer_mask ||
> > > - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > > + if (addr & HDATA(cmd->device->host)->dma_xfer_mask)
> > > {
> > > HDATA(cmd->device->host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > > & ~0x1ff;
> >
> > These seem to be completely unrelated to removing APUS support?
>
> For APUS mm_end_of_chunk() was an actual function, otherwise it was
> always 0.
Oops, you're right.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC: 2.6 patch] ppc: remove APUS support
From: Adrian Bunk @ 2007-07-01 23:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, linux-kernel, linuxppc-dev, Paul Mackerras,
Kumar Gala, David Gibson
In-Reply-To: <Pine.LNX.4.64.0707020053530.30442@anakin>
On Mon, Jul 02, 2007 at 12:55:36AM +0200, Geert Uytterhoeven wrote:
> On Sun, 1 Jul 2007, Adrian Bunk wrote:
> > Current status of APUS:
> > - arch/powerpc/: a patch to remove it is in powerpc.git
> > - arch/ppc/: marked BROKEN since 2 years
> >
> > This patch therefore removes the remaining parts of APUS support.
>
> > --- linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h.old 2007-06-30 01:23:33.000000000 +0200
> > +++ linux-2.6.22-rc6-mm1/include/asm-m68k/pgtable.h 2007-06-30 01:23:43.000000000 +0200
> > @@ -107,8 +107,6 @@ extern void *empty_zero_page;
> > /* 64-bit machines, beware! SRB. */
> > #define SIZEOF_PTR_LOG2 2
> >
> > -#define mm_end_of_chunk(addr, len) 0
> > -
> > extern void kernel_set_cachemode(void *addr, unsigned long size, int cmode);
> >
> > /*
> > --- linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c.old 2007-06-30 01:23:53.000000000 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/scsi/a2091.c 2007-06-30 01:24:08.000000000 +0200
> > @@ -46,8 +46,7 @@ static int dma_setup(struct scsi_cmnd *c
> > struct Scsi_Host *instance = cmd->device->host;
> >
> > /* don't allow DMA if the physical address is bad */
> > - if (addr & A2091_XFER_MASK ||
> > - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > + if (addr & A2091_XFER_MASK)
> > {
> > HDATA(instance)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > & ~0x1ff;
> > --- linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c.old 2007-06-30 01:24:17.000000000 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/scsi/a3000.c 2007-06-30 01:24:26.000000000 +0200
> > @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> > * end of a physical memory chunk, then allocate a bounce
> > * buffer
> > */
> > - if (addr & A3000_XFER_MASK ||
> > - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > + if (addr & A3000_XFER_MASK)
> > {
> > HDATA(a3000_host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > & ~0x1ff;
> > --- linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c.old 2007-06-30 01:24:35.000000000 +0200
> > +++ linux-2.6.22-rc6-mm1/drivers/scsi/gvp11.c 2007-06-30 01:24:46.000000000 +0200
> > @@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *c
> > static int scsi_alloc_out_of_range = 0;
> >
> > /* use bounce buffer if the physical address is bad */
> > - if (addr & HDATA(cmd->device->host)->dma_xfer_mask ||
> > - (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
> > + if (addr & HDATA(cmd->device->host)->dma_xfer_mask)
> > {
> > HDATA(cmd->device->host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
> > & ~0x1ff;
>
> These seem to be completely unrelated to removing APUS support?
For APUS mm_end_of_chunk() was an actual function, otherwise it was
always 0.
> Gr{oetje,eeting}s,
>
> Geert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] power-management elements for 603e/fsl (version 2)
From: Guennadi Liakhovetski @ 2007-07-01 21:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Johannes Berg, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0705212225470.7562@poirot.grange>
On Mon, 21 May 2007, Guennadi Liakhovetski wrote:
> On Mon, 21 May 2007, Scott Wood wrote:
>
> > IRQs really shouldn't be enabled here without something like the "Handle
> > HID0_SLEEP in the TLF_NAPPING hack" patch I posted recently.
>
> Ok, I'd be happy to rely on those your patches... as long as they make it
> into the kernel. Paulus, what's the plan? I'll try to apply them locally
> for now and adjust my code accordingly. A recent powerpc.git should be
> fine, I guess - the arch_suspend_{disable,enable}_irqs hooks are already
> there, or are there any further dependencies?
Took some time, but now I did rebase my linkstation standby code on your
patches, and also used your mpc83xx_enter_sleep / ret_from_sleep functions
(former with a single modification - removed the first mtmsr to set EE and
POW in MSR with one insn) - all worked. So, we could put them into
something like arch/powerpc/sysdev/fsl_pm.S and name accordingly. That
could be an incremental patch after the present versions make it into some
tree.
Of course, I needed other your patches to, e.g., bypass calling the ISR on
resume too.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* A question about man_page in linux-kernel
From: kang shuo @ 2007-07-01 14:24 UTC (permalink / raw)
To: linuxppc-embedded
hi:
I had read some ppc code in linux-2.6.20. There is a question
about map_page function. map_page seems to implement the map between
virtual address and physical address. But I can not understand how the
tlb entry operation is done in the code in map_page. The map_page is
as the following:
int
map_page(unsigned long va, phys_addr_t pa, int flags)
{
pmd_t *pd;
pte_t *pg;
int err = -ENOMEM;
/* Use upper 10 bits of VA to index the first level map */
pd = pmd_offset(pgd_offset_k(va), va);
/* Use middle 10 bits of VA to index the second-level map */
pg = pte_alloc_kernel(pd, va);
if (pg != 0) {
err = 0;
set_pte_at(&init_mm, va, pg, pfn_pte(pa >> PAGE_SHIFT,
__pgprot(flags)));
if (mem_init_done)
flush_HPTE(0, va, pmd_val(*pd));
}
return err;
}
Could anyone give me some hints about where and when tlb entry
is setup according to map_page function. That is very appreciate.
-- Thanks
-- Michael.Kang
^ permalink raw reply
* Can anyone send me a copy of ac97 driver with interrupt function
From: silicom @ 2007-07-01 2:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
Hi I'm writing an ac97 driver with interrupt mode,below is my code:staticirqreturn_t ac97_interrupt_handler(int irq,void *dev_id,struct pt_regs *regs){ disable_irq(7); wake_up_interruptible(ac97_queue); return IRQ_HANDLED;} static int xilinx_ac97_write(struct file *filp,char *buffer,size_t count,loff_t *ppos){ ...... if(XAC97_isInFIFOFull(baseAddress)) wait_event_interruptible(ac97_queue,...); else XAC97_mSetInFifoData(baseAddress,...); ......} Int the write function,when the play back fifo is not full,I send the PCM code to the fifo,else I make the write process sleep,and in the interrupt handler(when the fifo half empty,an interrupt occure),I wake up the write process,and go on write PCM code to the fifo. But I find the play speed is rather faster than regular and can't hear the voice(I have set the pcm rate correctly),I don't know why,can anyone give some advice on writing interupt handler or send me a copy of ac97 driver with interrupt mode? thanks a lot
[-- Attachment #2: Type: text/html, Size: 2181 bytes --]
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Josh Boyer @ 2007-07-01 1:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: Bizhan Gholikhamseh, linuxppc-embedded
In-Reply-To: <2DD9CF30-5127-4EC1-8D8E-BC6552A832AE@kernel.crashing.org>
On Wed, 2007-06-27 at 20:20 -0500, Kumar Gala wrote:
> On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
>
> > Hi All,
> > Sorry for asking this question again, I am still not clear on some
> > of the issues.
> > Background:
> > We have developed a custom board based on Freescale reference
> > board: MPC8555_CDS with MPC8541E processor running Linux 2.6.11 and
> > uboot 1.1.2 version.
> >
> > I would like to update the Linux kernel to the latest available
> > kernel 2.6.21.
> > Here are my questions:
> > 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
>
> Move to ARCH=powerpc.
>
> > 2- I have seen similar filenames under arch/ppc and arch/powerpc,
> > which one applies to MPC8541E?
>
> There is support for MPC8541e in both arch/ppc & arch/powerpc.
Why? Shouldn't the arch/ppc support be killed if it's in arch/powerpc?
josh
^ permalink raw reply
* Re: difference between ppc and powerpc
From: Josh Boyer @ 2007-07-01 1:05 UTC (permalink / raw)
To: silicom; +Cc: linuxppc-embedded
In-Reply-To: <25584182.1710331183250229848.JavaMail.coremail@bj163app48.163.com>
On Sun, 2007-07-01 at 08:37 +0800, silicom wrote:
> Hi
> Can anybody tell me the difference between arch->ppc and
> arch->powerpc?
arch/ppc is the original tree for 32 bit PowerPC machines. arch/powerpc
is the merged tree for both 32 and 64 bit PowerPC machines. arch/ppc is
dying a slow death and really shouldn't be used for new submissions.
josh
^ permalink raw reply
* difference between ppc and powerpc
From: silicom @ 2007-07-01 0:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 93 bytes --]
Hi Can anybody tell me the difference between arch->ppc and arch->powerpc? thanks a lot
[-- Attachment #2: Type: text/html, Size: 515 bytes --]
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Michal Marek @ 2007-06-30 8:40 UTC (permalink / raw)
To: Andrew Morton
Cc: xfs-masters, linux-kernel, xfs, linuxppc-dev, Mariusz Kozlowski,
paulus, Jason Wessel
In-Reply-To: <20070629134748.71adba1e.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Fri, 29 Jun 2007 14:32:09 +0200
> Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
>> anyway after unselecting XMON we can see:
>>
>> CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o
>> fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat':
>> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat'
>> undeclared (first use in this function)
>> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is
>> reported only once
>> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
>> make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1
>> make[1]: *** [fs/xfs] Blad 2
>
> Michal cc'ed. I think this is the one which was already reported but
> I haven't seen a fix yet?
Hi, I sent you an updated patch yesterday (should I've changed the
subject / started a new thread? This was my first patch so bear with
me... :)). Anyway, the mail with the fix is here:
http://lkml.org/lkml/2007/6/29/87
Michal
^ permalink raw reply
* RE: 83xx: requesting external interrupts
From: Joakim Tjernlund @ 2007-06-30 14:02 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <1B23F0C1-3BDF-434B-BF90-E75BB4C3994B@freescale.com>
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: den 30 juni 2007 01:55
> To: Joakim Tjernlund
> Cc: bwarren@qstreams.com; linuxppc-embedded@ozlabs.org
> Subject: Re: 83xx: requesting external interrupts
>
>
> On Jun 29, 2007, at 06:34, Joakim Tjernlund wrote:
> > mdio@2320 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <2320 18>;
> > device_type = "mdio";
> > compatible = "ucc_geth_phy";
> >
> > phy1: ethernet-phy@0 {
> > interrupt-parent = <&ipic>;
> > interrupts = <12 2>; //EXT IRQ2
> > reg = <0>; // 0
> > device_type = "ethernet-phy";
> > interface = <3>; //ENET_100_MII
> > };
> >
> > Now the things is that the IRQ works with and without the
> > /* All external IRQs + Generic timer IRQs must be initialized by
> > BSP */
> > const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78,
> > 84, 72};
> > for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> > virq = irq_create_mapping(NULL, bsp_irqs[i]);
>
>
> This isn't how to use the device tree. That is, you *aren't* using
> the device tree. You want to read the node of every device you want
> to set up, and create the mapping. Look at irq_of_parse_and_map().
> Look in include/asm-powerpc/prom.h, at of_irq_to_resource(), which
> maps an irq in the device tree.
I use both!
I see that ipic.c does all the work for me, so I should just drop
the above code. It is strange though that the virq # changes if
I keep the code.
hmm, maybe if I sort the bsp_irqs[] list numerically it will be the same?
Am at home ATM so I can't verify.
Jocke
^ 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