* Re: Trying to understand initsenses and pci_irq_table
From: Kumar Gala @ 2005-11-30 7:11 UTC (permalink / raw)
To: Richard Danter; +Cc: linuxppc-embedded
In-Reply-To: <438374FE.4040608@ntlworld.com>
On Nov 22, 2005, at 1:43 PM, Richard Danter wrote:
> Richard Danter wrote:
>> The kernel crashes after starting init. I see some random
>> characters on the serial and then nothing. Looking in the log
>> buffer via JTAG I can see that the init process exited with signal
>> 11. I assume this is unrelated to the above, but any suggestions
>> where I should look?
>
> I managed to fix this problem, so I am now booted and running
> busybox from NFS :)
>
> I'd still like a pointer to any docs explaining the PCI and
> interrupt stuff if possible.
Well the PCI SIG has specs. If your talking about the code, its a
simple lookup table. The key is realizing that PCI_IRQ_TABLE_LOOKUP
is a macro.
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Kumar Gala @ 2005-11-30 7:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list, Paul Mackerras
In-Reply-To: <20051123120033.GA3551@logos.cnet>
> Hi Kumar,
>
> I dont really know the policy for driver placement, but it seems that
> it works on a case by case basis.
>
> The files in arch/ppc/8xx_io/ (which is what I think you refer to as
> candidates for drivers/), are:
We have been slowly working on moving drivers out of arch/ppc and
into drivers/ so that subsystem maintainers could get proper review
of them.
> 1) commproc.c
> Basic API for dpram access. Core code.
>
> 2) micropatch.c
> microcode update code/data. Core code.
Well #1 & #2 aren't what I would call drivers at all. I would
consider them syslib/ candidates. Hopefully, someone will
>
> 3) cs4218.h
> 4) cs4218_tdm.c
>
> cs4218 does not compile at the moment due to syntatical problems,
> I've fixed them up and the driver compiles, but I don't know
> if it works (patch attached).
>
> I would not be surprised if the driver has been broken since
> long time ago.
>
> Does anyone have hardware to test it? Dan?
>
> Otherwise we should remove it from the tree, since its unmaintained
> and unused.
If its still good, I would guessing /drivers/audio or snd, but
neither seem to exist. I wondering where sound card drivers live
these days.
>
> 5) enet.c
> 6) fec.c
>
> The ENET/FEC network drivers are obseleted by fs_enet.
>
> However there are some PHY descriptions in fec.c which are missing
> from
> fs_enet - we'd better make sure to have them all in the new driver
> before removing the old one.
Agreed.
> Aris, would you mind looking into this?
>
> Once we have that we can set a deadline at Documentation/feature-
> removal.txt
> if desired.
>
> Other than those there are no 8xx drivers in arch/ppc/ AFAIK.
>
> <cs42.patch>
Good deal. Are we really removing anything (except maybe cs4218)?
- kumar
^ permalink raw reply
* Re: USB on MPC8272
From: Kumar Gala @ 2005-11-30 7:03 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded, Nathael PAJANI
In-Reply-To: <438D4A03.4060500@compulab.co.il>
On Nov 30, 2005, at 12:43 AM, Mike Rapoport wrote:
> Nathael PAJANI wrote:
>
>> Hi all!
>>
>>
>> I have to support USB hcd for an Actis board based on a MPC8248
>> processor. I already have a 2.6.9 linux kernel running fine on it,
>> and actualy have to use it rather than a newer one.
>> I'm actualy looking for existing or ongoing jobs.
>
> Dear Nathael,
> As far as I understand there are several drivers for the MPC8272
> usb host controller, and none of them is in
> official kernel tree.
> There's a driver in Metrowerks BSP for linux 2.6 for MPC8272 (the
> Freescale driver), an orignally mpc8xx driver by Brad Parker ported
> to linux 2.4 for MPC8272 by Pantelis Antoniou, there ought to be
> USB driver by ArabellaSW also.
> My driver ("http://cpm2usb.sourceforge.net./") is a port of the
> Brad Parker's driver to linux 2.6 with some modifications.
And, ideally we would like to see one driver get into the linux
source tree that everyone is happy with. I'm told by someone that
the FSL driver is suppose to have working host support "was tested/
verified with keyboard/mouse/diskdrives/network".
- kumar
^ permalink raw reply
* Support for S29GL512N in U-boot
From: le tang @ 2005-11-30 7:00 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <20051129081052.77DA1353F54@atlas.denx.de>
Hi all,
My board has Flash memory type AMD, S29GL512N and
CPU8541, and I found in the /include/flash.h in u-boot
source, there is entry for flash memory S29GL064M-R6,
How can I add the support for S29GL512N flash memory?
Thanks,
Le
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
^ permalink raw reply
* Re: USB on MPC8272
From: Mike Rapoport @ 2005-11-30 6:43 UTC (permalink / raw)
To: Nathael PAJANI; +Cc: linuxppc-embedded
In-Reply-To: <438C8E8E.3030306@cpe.fr>
Nathael PAJANI wrote:
> Hi all!
>
>
> I have to support USB hcd for an Actis board based on a MPC8248
> processor. I already have a 2.6.9 linux kernel running fine on it, and
> actualy have to use it rather than a newer one.
> I'm actualy looking for existing or ongoing jobs.
Dear Nathael,
As far as I understand there are several drivers for the MPC8272 usb
host controller, and none of them is in
official kernel tree.
There's a driver in Metrowerks BSP for linux 2.6 for MPC8272 (the
Freescale driver), an orignally mpc8xx driver by Brad Parker ported to
linux 2.4 for MPC8272 by Pantelis Antoniou, there ought to be USB driver
by ArabellaSW also.
My driver ("http://cpm2usb.sourceforge.net./") is a port of the Brad
Parker's driver to linux 2.6 with some modifications.
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: MPC85xx i2c interface bug
From: Kumar Gala @ 2005-11-30 6:14 UTC (permalink / raw)
To: dwilson; +Cc: linuxppc-embedded
In-Reply-To: <23fdca41e44a84e4a32634a.20051129124254.qjvyfba@www.dslextreme.com>
Dan,
Did you see an issue this change fixed? If so can you provide more
details. Also, can you provide your diff as a unified diff (diff -u) so
its easier to see where the changes where.
I'm trying to figure out if the same issue exists in the 2.6 driver (and
if so, why we havent seen it)
thanks
- kumar
On Tue, 29 Nov 2005 dwilson@dslextreme.com wrote:
> We have found a problem in the i2c-mpc.c file (linux 2.4 kernel). The
> logic for the i2c transfer termination seems to have been inverted.
>
> The original function is:
>
> /* Perform one i2c_msg transfer. It could be a read, or a write.
> * This function assumes that the address byte has been sent
> * already, and only handles the message contents */
> static int mpc_i2c_xfer_bytes(struct mpc_i2c_private* priv, struct
> i2c_msg* pm)
> {
> volatile struct mpc_i2c *regs = priv->regs;
> char *buf = pm->buf;
> int len = pm->len;
> int i;
> int ret = 0;
>
> if(pm->flags & I2C_M_RD) {
> /* Change to read mode */
> priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
>
> /* If there is only one byte, we need to TXAK now */
> if(len == 1)
> priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
>
> /* Do a dummy read, to initiate the first read */
> priv->read(®s->i2cdr);
> }
>
> for(i = 0; i < len; ++i) {
> /* If this is a read, read a byte, otherwise, write a byte */
> if(pm->flags & I2C_M_RD) {
> /* Wait for the previous read to finish */
> ret = wait_for_txcomplete(priv);
>
> if (ret)
> return ret;
>
> /* If this is the 2nd to last byte, send
> * the TXAK signal */
> if(i == len - 2) {
> priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> }
>
> /* If this is the last byte, send STOP */
> if (i == len - 1)
> mpc_i2c_stop(priv);
>
> buf[i] = priv->read(®s->i2cdr);
>
> } else {
> /* Otherwise, it's a write */
> priv->write(®s->i2cdr, buf[i], MPC_I2C_FULLREG);
>
> /* Wait for the transaction to complete */
> ret = wait_for_txcomplete(priv);
>
> if(ret)
> return ret;
>
> /* Return error if we didn't get the ack */
> if((priv->read(®s->i2csr) & MPC_I2CSR_RXAK)) {
> printk(KERN_DEBUG "NO ACK!\n");
> ret = -EREMOTEIO;
> }
> }
>
> /* If there was an error, abort */
> if(ret)
> return ret;
> }
>
> return ret;
> }
>
> The problem is that the TXAK bit is set incorrectly: it should be set to a
> zero when acks are to be sent and then set to a 1 just before reading the
> next-to-last byte in the transfer (8555 Processor Reference Manual
> (MPC8555ERM rev1), section 11.3.1.3 and also Figure 11-8).
>
> Changes to the above code are thus:
>
> 302c302
> < priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
> ---
> > priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX | MPC_I2CCR_TXAK);
> 306c306
> < priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> ---
> > priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
> MPC_I2CCR_TXAK);
> 324c324
> < priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> ---
> > priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
> MPC_I2CCR_TXAK);
>
> Thanks,
>
> Dan.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* [PATCH] powerpc: Update OF address parsers
From: Benjamin Herrenschmidt @ 2005-11-30 5:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
This updates the OF address parsers to return the IO flags
indicating the type of address obtained. It also adds a PCI
call for converting physical addresses that hit IO space into
into IO tokens, and add routines that return the translated
addresses into struct resource
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
For powerpc tree, not for 2.6.15
Index: linux-work/include/asm-powerpc/prom.h
===================================================================
--- linux-work.orig/include/asm-powerpc/prom.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-powerpc/prom.h 2005-11-30 16:19:51.000000000 +1100
@@ -223,14 +223,36 @@ extern struct resource *request_OF_resou
int index, const char* name_postfix);
extern int release_OF_resource(struct device_node* node, int index);
+
/*
- * Address translation function(s)
+ * OF address retreival & translation
+ */
+
+
+/* Translate an OF address block into a CPU physical address
*/
#define OF_BAD_ADDR ((u64)-1)
extern u64 of_translate_address(struct device_node *np, u32 *addr);
-extern u32 *of_get_address(struct device_node *dev, int index, u64 *size);
-extern u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size);
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern u32 *of_get_address(struct device_node *dev, int index,
+ u64 *size, unsigned int *flags);
+extern u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+ u64 *size, unsigned int *flags);
+
+/* Get an address as a resource. Note that if your address is
+ * a PIO address, the conversion will fail if the physical address
+ * can't be internally converted to an IO token with
+ * pci_address_to_pio(), that is because it's either called to early
+ * or it can't be matched to any host bridge IO space
+ */
+extern int of_address_to_resource(struct device_node *dev, int index,
+ struct resource *r);
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r);
#endif /* __KERNEL__ */
#endif /* _POWERPC_PROM_H */
Index: linux-work/arch/powerpc/kernel/legacy_serial.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/legacy_serial.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/kernel/legacy_serial.c 2005-11-30 15:38:27.000000000 +1100
@@ -146,6 +146,7 @@ static int __init add_legacy_pci_port(st
{
phys_addr_t addr, base;
u32 *addrp;
+ unsigned int flags;
int iotype, index = -1, lindex = 0;
/* We only support ports that have a clock frequency properly
@@ -159,12 +160,12 @@ static int __init add_legacy_pci_port(st
return -1;
/* Get the PCI address. Assume BAR 0 */
- addrp = of_get_pci_address(pci_dev, 0, NULL);
+ addrp = of_get_pci_address(pci_dev, 0, NULL, &flags);
if (addrp == NULL)
return -1;
/* We only support BAR 0 for now */
- iotype = (addrp[0] & 0x02000000) ? UPIO_MEM : UPIO_PORT;
+ iotype = (flags & IORESOURCE_MEM) ? UPIO_MEM : UPIO_PORT;
addr = of_translate_address(pci_dev, addrp);
/* Set the IO base to the same as the translated address for MMIO,
Index: linux-work/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci_64.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci_64.c 2005-11-30 15:38:27.000000000 +1100
@@ -1181,6 +1181,20 @@ void phbs_remap_io(void)
remap_bus_range(hose->bus);
}
+unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ struct pci_controller *hose, *tmp;
+
+ list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
+ if (address >= hose->io_base_phys &&
+ address < (hose->io_base_phys + hose->pci_io_size))
+ return (unsigned int)hose->io_base_virt +
+ (address - hose->io_base_phys);
+ }
+ return (unsigned int)-1;
+}
+EXPORT_SYMBOL_GPL(pci_address_to_pio);
+
static void __devinit fixup_resource(struct resource *res, struct pci_dev *dev)
{
struct pci_controller *hose = pci_bus_to_host(dev->bus);
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2005-11-30 16:20:22.000000000 +1100
@@ -4,7 +4,9 @@
#include <linux/string.h>
#include <linux/pci_regs.h>
#include <linux/module.h>
+#include <linux/ioport.h>
#include <asm/prom.h>
+#include <asm/pci-bridge.h>
#ifdef DEBUG
#define DBG(fmt...) do { printk(fmt); } while(0)
@@ -54,6 +56,7 @@ struct of_bus {
int *addrc, int *sizec);
u64 (*map)(u32 *addr, u32 *range, int na, int ns, int pna);
int (*translate)(u32 *addr, u64 offset, int na);
+ unsigned int (*get_flags)(u32 *addr);
};
@@ -61,8 +64,8 @@ struct of_bus {
* Default translator (generic bus)
*/
-static void of_default_count_cells(struct device_node *dev,
- int *addrc, int *sizec)
+static void of_bus_default_count_cells(struct device_node *dev,
+ int *addrc, int *sizec)
{
if (addrc)
*addrc = prom_n_addr_cells(dev);
@@ -70,7 +73,7 @@ static void of_default_count_cells(struc
*sizec = prom_n_size_cells(dev);
}
-static u64 of_default_map(u32 *addr, u32 *range, int na, int ns, int pna)
+static u64 of_bus_default_map(u32 *addr, u32 *range, int na, int ns, int pna)
{
u64 cp, s, da;
@@ -86,7 +89,7 @@ static u64 of_default_map(u32 *addr, u32
return da - cp;
}
-static int of_default_translate(u32 *addr, u64 offset, int na)
+static int of_bus_default_translate(u32 *addr, u64 offset, int na)
{
u64 a = of_read_addr(addr, na);
memset(addr, 0, na * 4);
@@ -98,6 +101,11 @@ static int of_default_translate(u32 *add
return 0;
}
+static unsigned int of_bus_default_get_flags(u32 *addr)
+{
+ return IORESOURCE_MEM;
+}
+
/*
* PCI bus specific translator
@@ -139,7 +147,24 @@ static u64 of_bus_pci_map(u32 *addr, u32
static int of_bus_pci_translate(u32 *addr, u64 offset, int na)
{
- return of_default_translate(addr + 1, offset, na - 1);
+ return of_bus_default_translate(addr + 1, offset, na - 1);
+}
+
+static unsigned int of_bus_pci_get_flags(u32 *addr)
+{
+ unsigned int flags = 0;
+ u32 w = addr[0];
+
+ switch((w >> 24) & 0x03) {
+ case 0x01:
+ flags |= IORESOURCE_IO;
+ case 0x02: /* 32 bits */
+ case 0x03: /* 64 bits */
+ flags |= IORESOURCE_MEM;
+ }
+ if (w & 0x40000000)
+ flags |= IORESOURCE_PREFETCH;
+ return flags;
}
/*
@@ -182,9 +207,22 @@ static u64 of_bus_isa_map(u32 *addr, u32
static int of_bus_isa_translate(u32 *addr, u64 offset, int na)
{
- return of_default_translate(addr + 1, offset, na - 1);
+ return of_bus_default_translate(addr + 1, offset, na - 1);
}
+static unsigned int of_bus_isa_get_flags(u32 *addr)
+{
+ unsigned int flags = 0;
+ u32 w = addr[0];
+
+ if (w & 1)
+ flags |= IORESOURCE_IO;
+ else
+ flags |= IORESOURCE_MEM;
+ return flags;
+}
+
+
/*
* Array of bus specific translators
*/
@@ -198,6 +236,7 @@ static struct of_bus of_busses[] = {
.count_cells = of_bus_pci_count_cells,
.map = of_bus_pci_map,
.translate = of_bus_pci_translate,
+ .get_flags = of_bus_pci_get_flags,
},
/* ISA */
{
@@ -207,15 +246,17 @@ static struct of_bus of_busses[] = {
.count_cells = of_bus_isa_count_cells,
.map = of_bus_isa_map,
.translate = of_bus_isa_translate,
+ .get_flags = of_bus_isa_get_flags,
},
/* Default */
{
.name = "default",
.addresses = "reg",
.match = NULL,
- .count_cells = of_default_count_cells,
- .map = of_default_map,
- .translate = of_default_translate,
+ .count_cells = of_bus_default_count_cells,
+ .map = of_bus_default_map,
+ .translate = of_bus_default_translate,
+ .get_flags = of_bus_default_get_flags,
},
};
@@ -254,7 +295,8 @@ static int of_translate_one(struct devic
ranges = (u32 *)get_property(parent, "ranges", &rlen);
if (ranges == NULL || rlen == 0) {
offset = of_read_addr(addr, na);
- memset(addr, 0, pna);
+ memset(addr, 0, pna * 4);
+ DBG("OF: no ranges, 1:1 translation\n");
goto finish;
}
@@ -370,7 +412,8 @@ u64 of_translate_address(struct device_n
}
EXPORT_SYMBOL(of_translate_address);
-u32 *of_get_address(struct device_node *dev, int index, u64 *size)
+u32 *of_get_address(struct device_node *dev, int index, u64 *size,
+ unsigned int *flags)
{
u32 *prop;
unsigned int psize;
@@ -399,22 +442,106 @@ u32 *of_get_address(struct device_node *
if (i == index) {
if (size)
*size = of_read_addr(prop + na, ns);
+ if (flags)
+ *flags = bus->get_flags(prop);
return prop;
}
return NULL;
}
EXPORT_SYMBOL(of_get_address);
-u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size)
+u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size,
+ unsigned int *flags)
{
- u32 *addr;
- int index;
+ u32 *prop;
+ unsigned int psize;
+ struct device_node *parent;
+ struct of_bus *bus;
+ int onesize, i, na, ns;
- for (index = 0; (addr = of_get_address(dev, index, size)) != NULL;
- index++) {
- if ((addr[0] & 0xff) == ((bar_no * 4) + PCI_BASE_ADDRESS_0))
- return addr;
- }
+ /* Get parent & match bus type */
+ parent = of_get_parent(dev);
+ if (parent == NULL)
+ return NULL;
+ bus = of_match_bus(parent);
+ if (strcmp(bus->name, "pci"))
+ return NULL;
+ bus->count_cells(dev, &na, &ns);
+ of_node_put(parent);
+ if (!OF_CHECK_COUNTS(na, ns))
+ return NULL;
+
+ /* Get "reg" or "assigned-addresses" property */
+ prop = (u32 *)get_property(dev, bus->addresses, &psize);
+ if (prop == NULL)
+ return NULL;
+ psize /= 4;
+
+ onesize = na + ns;
+ for (i = 0; psize >= onesize; psize -= onesize, prop += onesize, i++)
+ if ((prop[0] & 0xff) == ((bar_no * 4) + PCI_BASE_ADDRESS_0)) {
+ if (size)
+ *size = of_read_addr(prop + na, ns);
+ if (flags)
+ *flags = bus->get_flags(prop);
+ return prop;
+ }
return NULL;
}
EXPORT_SYMBOL(of_get_pci_address);
+
+static int __of_address_to_resource(struct device_node *dev, u32 *addrp,
+ u64 size, unsigned int flags,
+ struct resource *r)
+{
+ u64 taddr;
+
+ if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
+ return -EINVAL;
+ taddr = of_translate_address(dev, addrp);
+ if (taddr == OF_BAD_ADDR)
+ return -EINVAL;
+ memset(r, 0, sizeof(struct resource));
+ if (flags & IORESOURCE_IO) {
+ unsigned int port;
+ port = pci_address_to_pio(taddr);
+ if (port == (unsigned int)-1)
+ return -EINVAL;
+ r->start = port;
+ r->end = port + size - 1;
+ } else {
+ r->start = taddr;
+ r->end = taddr + size - 1;
+ }
+ r->flags = flags;
+ r->name = dev->name;
+ return 0;
+}
+
+int of_address_to_resource(struct device_node *dev, int index,
+ struct resource *r)
+{
+ u32 *addrp;
+ u64 size;
+ unsigned int flags;
+
+ addrp = of_get_address(dev, index, &size, &flags);
+ if (addrp == NULL)
+ return -EINVAL;
+ return __of_address_to_resource(dev, addrp, size, flags, r);
+}
+EXPORT_SYMBOL_GPL(of_address_to_resource);
+
+int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r)
+{
+ u32 *addrp;
+ u64 size;
+ unsigned int flags;
+
+ addrp = of_get_pci_address(dev, bar, &size, &flags);
+ if (addrp == NULL)
+ return -EINVAL;
+ return __of_address_to_resource(dev, addrp, size, flags, r);
+}
+EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2005-11-30 16:19:51.000000000 +1100
@@ -2672,7 +2672,7 @@ static void __init probe_one_macio(const
printk(KERN_ERR "pmac_feature: %s skipped\n", node->full_name);
return;
}
- addrp = of_get_pci_address(node, 0, &size);
+ addrp = of_get_pci_address(node, 0, &size, NULL);
if (addrp == NULL) {
printk(KERN_ERR "pmac_feature: %s: can't find base !\n",
node->full_name);
Index: linux-work/arch/ppc/kernel/pci.c
===================================================================
--- linux-work.orig/arch/ppc/kernel/pci.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/ppc/kernel/pci.c 2005-11-30 15:38:27.000000000 +1100
@@ -1805,6 +1805,21 @@ void pci_iounmap(struct pci_dev *dev, vo
EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
+unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ struct pci_controller* hose = hose_head;
+
+ for (; hose; hose = hose->next) {
+ unsigned int size = hose->io_resource.end -
+ hose->io_resource.start + 1;
+ if (address >= hose->io_base_phys &&
+ address < (hose->io_base_phys + size))
+ return (unsigned int)hose->io_base_virt +
+ (address - hose->io_base_phys);
+ }
+ return (unsigned int)-1;
+}
+EXPORT_SYMBOL(pci_address_to_pio);
/*
* Null PCI config access functions, for the case when we can't
Index: linux-work/drivers/macintosh/macio_asic.c
===================================================================
--- linux-work.orig/drivers/macintosh/macio_asic.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/drivers/macintosh/macio_asic.c 2005-11-30 16:19:51.000000000 +1100
@@ -332,18 +332,14 @@ static void macio_setup_resources(struct
struct resource *parent_res)
{
struct device_node *np = dev->ofdev.node;
- u32 *addr;
- u64 size;
+ struct resource r;
int index;
- for (index = 0; (addr = of_get_address(np, index, &size)) != NULL;
- index++) {
+ for (index = 0; of_address_to_resource(np, index, &r) == 0; index++) {
struct resource *res = &dev->resource[index];
if (index >= MACIO_DEV_COUNT_RESOURCES)
break;
- res->start = of_translate_address(np, addr);
- res->end = res->start + (unsigned long)size - 1;
- res->flags = IORESOURCE_MEM;
+ *res = r;
res->name = dev->ofdev.dev.bus_id;
if (macio_resource_quirks(np, res, index)) {
@@ -353,7 +349,7 @@ static void macio_setup_resources(struct
/* Currently, we consider failure as harmless, this may
* change in the future, once I've found all the device
* tree bugs in older machines & worked around them
- */
+l */
if (insert_resource(parent_res, res)) {
printk(KERN_WARNING "Can't request resource "
"%d for MacIO device %s\n",
Index: linux-work/include/asm-powerpc/pci-bridge.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pci-bridge.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-powerpc/pci-bridge.h 2005-11-30 15:38:27.000000000 +1100
@@ -157,6 +157,15 @@ extern struct pci_controller *
pcibios_alloc_controller(struct device_node *dev);
extern void pcibios_free_controller(struct pci_controller *phb);
+#ifdef CONFIG_PCI
+extern unsigned int pci_address_to_pio(phys_addr_t address);
+#else
+static inline unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ return (unsigned int)-1;
+}
+#endif
+
/* Return values for ppc_md.pci_probe_mode function */
#define PCI_PROBE_NONE -1 /* Don't look at this bus at all */
#define PCI_PROBE_NORMAL 0 /* Do normal PCI probing */
Index: linux-work/include/asm-ppc/pci-bridge.h
===================================================================
--- linux-work.orig/include/asm-ppc/pci-bridge.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-ppc/pci-bridge.h 2005-11-30 15:38:27.000000000 +1100
@@ -137,5 +137,14 @@ static inline unsigned char bridge_swizz
*/
extern int pciauto_bus_scan(struct pci_controller *, int);
+#ifdef CONFIG_PCI
+extern unsigned int pci_address_to_pio(phys_addr_t address);
+#else
+static inline unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ return (unsigned int)-1;
+}
+#endif
+
#endif
#endif /* __KERNEL__ */
Index: linux-work/include/asm-ppc/prom.h
===================================================================
--- linux-work.orig/include/asm-ppc/prom.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-ppc/prom.h 2005-11-30 15:38:27.000000000 +1100
@@ -138,12 +138,34 @@ extern unsigned long sub_reloc_offset(un
/*
- * Address translation function(s)
+ * OF address retreival & translation
+ */
+
+
+/* Translate an OF address block into a CPU physical address
*/
#define OF_BAD_ADDR ((u64)-1)
extern u64 of_translate_address(struct device_node *np, u32 *addr);
-extern u32 *of_get_address(struct device_node *dev, int index, u64 *size);
-extern u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size);
+
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern u32 *of_get_address(struct device_node *dev, int index,
+ u64 *size, unsigned int *flags);
+extern u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+ u64 *size, unsigned int *flags);
+
+/* Get an address as a resource. Note that if your address is
+ * a PIO address, the conversion will fail if the physical address
+ * can't be internally converted to an IO token with
+ * pci_address_to_pio(), that is because it's either called to early
+ * or it can't be matched to any host bridge IO space
+ */
+extern int of_address_to_resource(struct device_node *dev, int index,
+ struct resource *r);
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r);
#endif /* _PPC_PROM_H */
^ permalink raw reply
* [PATCH] powerpc: udbg updates
From: Benjamin Herrenschmidt @ 2005-11-30 5:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The udbg low level io layer has an issue with udbg_getc() returning a
char (unsigned on ppc) instead of an int, thus the -1 if you had no
available input device could end up turned into 0xff, filling your
display with bogus characters. This fixes it, along with adding a little
blob to xmon to do a delay before exiting when getting an EOF and fixing
the detection of ADB keyboards in udbg_adb.c
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
For the powerpc tree, not for 2.6.15.
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2005-11-30 15:23:47.000000000 +1100
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2005-11-30 15:30:17.000000000 +1100
@@ -276,7 +276,7 @@ static int of_translate_one(struct devic
finish:
of_dump_addr("OF: parent translation for:", addr, pna);
- DBG("OF: with offset: %lx\n", offset);
+ DBG("OF: with offset: "PRu64"\n", offset);
/* Translate it into parent bus space */
return pbus->translate(addr, offset, pna);
Index: linux-work/arch/powerpc/kernel/udbg.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/udbg.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/kernel/udbg.c 2005-11-30 15:30:40.000000000 +1100
@@ -17,7 +17,7 @@
#include <asm/processor.h>
void (*udbg_putc)(char c);
-char (*udbg_getc)(void);
+int (*udbg_getc)(void);
int (*udbg_getc_poll)(void);
/* udbg library, used by xmon et al */
@@ -57,8 +57,8 @@ int udbg_write(const char *s, int n)
int udbg_read(char *buf, int buflen)
{
- char c, *p = buf;
- int i;
+ char *p = buf;
+ int i, c;
if (!udbg_getc)
return 0;
@@ -66,8 +66,11 @@ int udbg_read(char *buf, int buflen)
for (i = 0; i < buflen; ++i) {
do {
c = udbg_getc();
+ if (c == -1 && i == 0)
+ return -1;
+
} while (c == 0x11 || c == 0x13);
- if (c == 0)
+ if (c == 0 || c == -1)
break;
*p++ = c;
}
Index: linux-work/arch/powerpc/kernel/udbg_16550.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/udbg_16550.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/kernel/udbg_16550.c 2005-11-30 15:24:47.000000000 +1100
@@ -69,14 +69,14 @@ static int udbg_550_getc_poll(void)
return -1;
}
-static char udbg_550_getc(void)
+static int udbg_550_getc(void)
{
if (udbg_comport) {
while ((in_8(&udbg_comport->lsr) & LSR_DR) == 0)
/* wait for char */;
return in_8(&udbg_comport->rbr);
}
- return 0;
+ return -1;
}
void udbg_init_uart(void __iomem *comport, unsigned int speed,
Index: linux-work/arch/powerpc/platforms/powermac/udbg_adb.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/udbg_adb.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/udbg_adb.c 2005-11-30 15:24:47.000000000 +1100
@@ -29,7 +29,7 @@
*/
static void (*udbg_adb_old_putc)(char c);
-static char (*udbg_adb_old_getc)(void);
+static int (*udbg_adb_old_getc)(void);
static int (*udbg_adb_old_getc_poll)(void);
static enum {
@@ -73,7 +73,7 @@ static unsigned char xmon_shift_keytab[1
"\0.\0*\0+\0\0\0\0\0/\r\0-\0" /* 0x40 - 0x4f */
"\0\0000123456789\0\0\0"; /* 0x50 - 0x5f */
-static char udbg_adb_local_getc(void)
+static int udbg_adb_local_getc(void)
{
int k, t, on;
@@ -116,7 +116,7 @@ static char udbg_adb_local_getc(void)
}
#endif /* CONFIG_BOOTX_TEXT */
-static char udbg_adb_getc(void)
+static int udbg_adb_getc(void)
{
#ifdef CONFIG_BOOTX_TEXT
if (udbg_adb_use_btext && input_type != input_adb_none)
@@ -192,7 +192,7 @@ int udbg_adb_init(int force_btext)
*/
for (np = NULL; (np = of_find_node_by_name(np, "keyboard")) != NULL;) {
struct device_node *parent = of_get_parent(np);
- int found = (parent && !strcmp(parent->type, "adb") == 0);
+ int found = (parent && strcmp(parent->type, "adb") == 0);
of_node_put(parent);
if (found)
break;
Index: linux-work/arch/powerpc/platforms/powermac/udbg_scc.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/udbg_scc.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/udbg_scc.c 2005-11-30 15:24:47.000000000 +1100
@@ -47,14 +47,14 @@ static int udbg_scc_getc_poll(void)
return -1;
}
-static char udbg_scc_getc(void)
+static int udbg_scc_getc(void)
{
if (sccc) {
while ((in_8(sccc) & SCC_RXRDY) == 0)
;
return in_8(sccd);
}
- return 0;
+ return -1;
}
static unsigned char scc_inittab[] = {
Index: linux-work/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/pseries/lpar.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/platforms/pseries/lpar.c 2005-11-30 15:24:47.000000000 +1100
@@ -112,7 +112,7 @@ static int udbg_hvsi_getc_poll(void)
return ch;
}
-static char udbg_hvsi_getc(void)
+static int udbg_hvsi_getc(void)
{
int ch;
for (;;) {
@@ -173,7 +173,7 @@ static int udbg_getc_pollLP(void)
return ch;
}
-static char udbg_getcLP(void)
+static int udbg_getcLP(void)
{
int ch;
for (;;) {
Index: linux-work/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-work.orig/arch/powerpc/xmon/xmon.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/xmon/xmon.c 2005-11-30 15:24:47.000000000 +1100
@@ -450,7 +450,6 @@ int xmon_core(struct pt_regs *regs, int
leave:
cpu_clear(cpu, cpus_in_xmon);
xmon_fault_jmp[cpu] = NULL;
-
#else
/* UP is simple... */
if (in_xmon) {
@@ -805,7 +804,10 @@ cmds(struct pt_regs *excp)
break;
case 'x':
case 'X':
+ return cmd;
case EOF:
+ printf(" <no input ...>\n");
+ mdelay(2000);
return cmd;
case '?':
printf(help_string);
Index: linux-work/include/asm-powerpc/udbg.h
===================================================================
--- linux-work.orig/include/asm-powerpc/udbg.h 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/include/asm-powerpc/udbg.h 2005-11-30 15:24:47.000000000 +1100
@@ -14,7 +14,7 @@
#include <linux/init.h>
extern void (*udbg_putc)(char c);
-extern char (*udbg_getc)(void);
+extern int (*udbg_getc)(void);
extern int (*udbg_getc_poll)(void);
extern void udbg_puts(const char *s);
Index: linux-work/drivers/macintosh/via-pmu.c
===================================================================
--- linux-work.orig/drivers/macintosh/via-pmu.c 2005-11-30 15:23:50.000000000 +1100
+++ linux-work/drivers/macintosh/via-pmu.c 2005-11-30 15:30:20.000000000 +1100
@@ -313,7 +313,7 @@ int __init find_via_pmu(void)
goto fail;
}
taddr = of_translate_address(vias, reg);
- if (taddr == 0) {
+ if (taddr == OF_BAD_ADDR) {
printk(KERN_ERR "via-pmu: Can't translate address !\n");
goto fail;
}
@@ -376,7 +376,7 @@ int __init find_via_pmu(void)
return 0;
}
- printk(KERN_INFO "PMU driver %d initialized for %s, firmware: %02x\n",
+ printk(KERN_INFO "PMU driver v%d initialized for %s, firmware: %02x\n",
PMU_DRIVER_VERSION, pbook_type[pmu_kind], pmu_version);
sys_ctrler = SYS_CTRLER_PMU;
^ permalink raw reply
* Re: [RFC] add PHY support to AM79C874
From: Kumar Gala @ 2005-11-30 5:51 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20051128141042.GR7163@cathedrallabs.org>
I would suggest sending this to the netdev list for review and
acceptance.
- kumar
On Nov 28, 2005, at 8:10 AM, Aristeu Sergio Rozanski Filho wrote:
> This is a simple port from old fec driver to PHY layer to support AMD
> AM79C874 PHY.
> As I don't have the hardware to test this, all kinds of feedback are
> most welcome.
> Thanks,
>
> --
> Aristeu
>
> <phy-add_am79c874_phy.patch>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: spi on mpc82xx
From: Kumar Gala @ 2005-11-30 5:49 UTC (permalink / raw)
To: Thomas Arvanitis; +Cc: linuxppc-embedded
In-Reply-To: <20051129111442.GB27630@inaccessnetworks.com>
On Nov 29, 2005, at 5:14 AM, Thomas Arvanitis wrote:
> Hi,
>
> I was wondering what is the status for supporting spi devices with 2.6
> on an mpc82xx device (I use an mpc8275). I checked and the kernel from
> kernel.org does not include anything. Is there an spi bus
> infrastructure (like i2c) coming any time soon, where one can add
> support for specific chips, and then write a driver on top of that?
> Or a plan for these things?
>
> I found a patch for something like that, by Grant Likely, but I don't
> know whether I should go that way.
>
> I want to write a driver for controlling the micrel ks8995 ethernet
> switch through spi. Should I just go for a self contained driver?
There has be some patches on the lkml list for the creation of a SPI
layer similar to I2C. I'm not sure what the latest status is. I'd
google search for SPI on lkml.
Once something like that gets in I'm sure someone will get around to
contributing a SPI driver for the 82xx line of processors.
- kumar
^ permalink raw reply
* Re: Is there some articles discussing how to change bare-board code to linux driver?
From: David H. Lynch Jr @ 2005-11-30 2:03 UTC (permalink / raw)
To: T Ziomek, linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0511291821320.3620@holyoke.labs.mot.com>
Where can I find the ./drivers/net/xilinx_enet, ... etc files.
I can not find them in the 2.6.14.2 tree
T Ziomek wrote:
>> Where can i find them?thanks.
>
> In addition to LDD3 (for 2.6 kernels, or the freely available LDD2 for
> 2.4 kernels), you might want to look at some existing Linux drivers
> that are
> based on "bare metal" / "no OS" drivers. The ones I know of are for
> Xilinx
> peripherals, for example (within the Linux kernel tree),
> - ./drivers/net/xilinx_enet
> - ./drivers/char/xilinx_uartlite
> - ./drivers/char/xilinx_gpio
>
> Tom
^ permalink raw reply
* re: Is there some articles discussing how to change bare-board code to linux driver?
From: T Ziomek @ 2005-11-30 0:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051125214126.15F9E6884D@ozlabs.org>
> Where can i find them?thanks.
In addition to LDD3 (for 2.6 kernels, or the freely available LDD2 for 2.4
kernels), you might want to look at some existing Linux drivers that are
based on "bare metal" / "no OS" drivers. The ones I know of are for Xilinx
peripherals, for example (within the Linux kernel tree),
- ./drivers/net/xilinx_enet
- ./drivers/char/xilinx_uartlite
- ./drivers/char/xilinx_gpio
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Kernel 2.6 support for MVME5500?
From: Henry A. Leinhos @ 2005-11-29 20:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
Hi,
Does anyone have any information regarding support for the Motorola
MVME5500 SBC under kernel 2.6.x? Motorola has 2.4.x patches on their
website, but I can't seem to find anything for 2.6.x.
Thanks,
Henry
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2562 bytes --]
^ permalink raw reply
* MPC85xx i2c interface bug
From: dwilson @ 2005-11-29 20:42 UTC (permalink / raw)
To: linuxppc-embedded
We have found a problem in the i2c-mpc.c file (linux 2.4 kernel). The
logic for the i2c transfer termination seems to have been inverted.
The original function is:
/* Perform one i2c_msg transfer. It could be a read, or a write.
* This function assumes that the address byte has been sent
* already, and only handles the message contents */
static int mpc_i2c_xfer_bytes(struct mpc_i2c_private* priv, struct
i2c_msg* pm)
{
volatile struct mpc_i2c *regs = priv->regs;
char *buf = pm->buf;
int len = pm->len;
int i;
int ret = 0;
if(pm->flags & I2C_M_RD) {
/* Change to read mode */
priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
/* If there is only one byte, we need to TXAK now */
if(len == 1)
priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
/* Do a dummy read, to initiate the first read */
priv->read(®s->i2cdr);
}
for(i = 0; i < len; ++i) {
/* If this is a read, read a byte, otherwise, write a byte */
if(pm->flags & I2C_M_RD) {
/* Wait for the previous read to finish */
ret = wait_for_txcomplete(priv);
if (ret)
return ret;
/* If this is the 2nd to last byte, send
* the TXAK signal */
if(i == len - 2) {
priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
}
/* If this is the last byte, send STOP */
if (i == len - 1)
mpc_i2c_stop(priv);
buf[i] = priv->read(®s->i2cdr);
} else {
/* Otherwise, it's a write */
priv->write(®s->i2cdr, buf[i], MPC_I2C_FULLREG);
/* Wait for the transaction to complete */
ret = wait_for_txcomplete(priv);
if(ret)
return ret;
/* Return error if we didn't get the ack */
if((priv->read(®s->i2csr) & MPC_I2CSR_RXAK)) {
printk(KERN_DEBUG "NO ACK!\n");
ret = -EREMOTEIO;
}
}
/* If there was an error, abort */
if(ret)
return ret;
}
return ret;
}
The problem is that the TXAK bit is set incorrectly: it should be set to a
zero when acks are to be sent and then set to a 1 just before reading the
next-to-last byte in the transfer (8555 Processor Reference Manual
(MPC8555ERM rev1), section 11.3.1.3 and also Figure 11-8).
Changes to the above code are thus:
302c302
< priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
---
> priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX | MPC_I2CCR_TXAK);
306c306
< priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
---
> priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
MPC_I2CCR_TXAK);
324c324
< priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
---
> priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
MPC_I2CCR_TXAK);
Thanks,
Dan.
^ permalink raw reply
* [PATCH] powerpc ppc32 clean up available memory models
From: Andy Whitcroft @ 2005-11-29 19:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andy Whitcroft
In-Reply-To: <438B5523.40903@shadowen.org>
Ok, attempt #2 at cleaning up the memory models for powerpc/ppc32.
Made it very explicit which combinations require FLATMEM and left
the defaults alone for SPARSEMEM. Seems to do what I expect.
Comments.
-apw
=== 8< ===
powerpc: ppc32 clean up available memory models
Clean up the currently available memory models for ppc32 under
the powerpc architecture. We need FLATMEM for ppc32 enable it.
SPARSEMEM is not parameterised for ppc32 so disable that. Take this
opportunity to clean up white space for FLATMEM_ENABLE.
Against 2.6.15-rc3 with Anton's flatmem disable patch.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff -upN reference/arch/powerpc/Kconfig current/arch/powerpc/Kconfig
--- reference/arch/powerpc/Kconfig
+++ current/arch/powerpc/Kconfig
@@ -578,11 +578,12 @@ config ARCH_SELECT_MEMORY_MODEL
depends on PPC64
config ARCH_FLATMEM_ENABLE
- def_bool y
- depends on PPC64 && !NUMA
+ def_bool y
+ depends on (PPC64 && !NUMA) || PPC32
config ARCH_SPARSEMEM_ENABLE
def_bool y
+ depends on PPC64
config ARCH_SPARSEMEM_DEFAULT
def_bool y
^ permalink raw reply
* [PATCH] powerpc ppc32 fix definition of distribute_irqs
From: Andy Whitcroft @ 2005-11-29 19:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andy Whitcroft
Now that I can attempt to compile powerpc/ppc32 it appears there is
a problem with the definition of distribute_irqs, this patch
seems to fix it for me.
-apw
=== 8< ===
powerpc: ppc32 fix definition of distribute_irqs
When we select ppc32 under the powerpc architecture we get the
error below. This relates to defining distribute_irqs when this
configuratiom option is undefined.
CC arch/powerpc/sysdev/mpic.o
.../arch/powerpc/sysdev/mpic.c: In function `mpic_setup_this_cpu':
.../arch/powerpc/sysdev/mpic.c:788: error: `CONFIG_IRQ_ALL_CPUS'
undeclared (first use in this function)
Against 2.6.15-rc3.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff -upN reference/arch/powerpc/sysdev/mpic.c current/arch/powerpc/sysdev/mpic.c
--- reference/arch/powerpc/sysdev/mpic.c
+++ current/arch/powerpc/sysdev/mpic.c
@@ -45,7 +45,11 @@ static struct mpic *mpic_primary;
static DEFINE_SPINLOCK(mpic_lock);
#ifdef CONFIG_PPC32 /* XXX for now */
-#define distribute_irqs CONFIG_IRQ_ALL_CPUS
+#ifdef CONFIG_IRQ_ALL_CPUS
+#define distribute_irqs (1)
+#else
+#define distribute_irqs (0)
+#endif
#endif
/*
^ permalink raw reply
* [PATCH] Export __flush_icache_range since flush_icache_range is defined as inline
From: Otavio Salvador @ 2005-11-29 17:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc
[-- Attachment #1.1: Type: text/plain, Size: 1718 bytes --]
This change makes MOL work again since it need to use that specific symbol.
Signed-off-by: Otavio Salvador <otavio@debian.org>
---
arch/powerpc/kernel/ppc_ksyms.c | 2 +-
arch/ppc/kernel/ppc_ksyms.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 9253bd3b562d6c59044b6175883724f591697da4
b634f3ccf73ca6502b1dd42f372a6ec6bea15ffb
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index af4d1bc..2647933 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -167,7 +167,7 @@ EXPORT_SYMBOL(giveup_spe);
EXPORT_SYMBOL(__flush_icache_range);
#else
EXPORT_SYMBOL(flush_instruction_cache);
-EXPORT_SYMBOL(flush_icache_range);
+EXPORT_SYMBOL(__flush_icache_range);
EXPORT_SYMBOL(flush_tlb_kernel_range);
EXPORT_SYMBOL(flush_tlb_page);
EXPORT_SYMBOL(_tlbie);
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 66073f7..bb6a5c6 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -184,7 +184,7 @@ EXPORT_SYMBOL(kernel_thread);
EXPORT_SYMBOL(flush_instruction_cache);
EXPORT_SYMBOL(giveup_fpu);
-EXPORT_SYMBOL(flush_icache_range);
+EXPORT_SYMBOL(__flush_icache_range);
EXPORT_SYMBOL(flush_dcache_range);
EXPORT_SYMBOL(flush_icache_user_range);
EXPORT_SYMBOL(flush_dcache_page);
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
you the whole house."
[-- Attachment #2: Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply related
* Re: immap with 8xx.
From: Dan Malek @ 2005-11-29 18:13 UTC (permalink / raw)
To: ihornberger; +Cc: linuxppc-devel list
In-Reply-To: <1133275187.2664.32.camel@iho.sysgo.com>
On Nov 29, 2005, at 9:39 AM, Ingo Hornberger wrote:
> But it seems that there was some generalization work done, which didn't
> reach the 8xx part. Particularly this means that some parts of
> 'asm/commproc.h' as well as (at least) 'asm/immap_8260.h' built up a
> new
> header 'asm/immap_cpm2.h'.
That's because the cpm2 is used in more parts than just the 82xx,
so we carved up the files to make it more useful.
> Actally I miss a file like 'asm/immap_cpm1.h'.
The 8xx is the only processor to use the CPM1, so just update
the immap or 8xx files to accommodate the differences you may
need. There isn't a similar requirement to create a immap_cpm1.h
file like there was for the CPM2. What kind of updates do you need?
Thanks.
-- Dan
^ permalink raw reply
* USB on MPC8272
From: Nathael PAJANI @ 2005-11-29 17:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
I have to support USB hcd for an Actis board based on a MPC8248
processor. I already have a 2.6.9 linux kernel running fine on it, and
actualy have to use it rather than a newer one.
I'm actualy looking for existing or ongoing jobs.
Mike Rapoport:
When you say "I'm running linux 2.6.12.3 with "custom" USB host driver."
Are you speaking of this one: "http://cpm2usb.sourceforge.net./" or another?
Kumar Gala:
On the thread "MPC8555 USB host support" you're asking:
"Also, are you aware of Freescale's driver for this?"
Where is this support located? (which files or directories)
Thanks.
PS: Thanks a lot for people who helped me when porting linux 2.6.13 to
the Actis board VSBX6560 whith MPC8560 processor. It's finished. (Or at
least, no bug reports yet :)
How to commit a patch to the main kernel tree?
^ permalink raw reply
* Re: [PATCH] 3/3 Generic sys_rt_sigsuspend
From: Daniel Jacobowitz @ 2005-11-29 15:53 UTC (permalink / raw)
To: David Woodhouse
Cc: drepper, linuxppc-dev, Mika Penttilä, akpm, linux-kernel
In-Reply-To: <1133260923.31573.131.camel@baythorne.infradead.org>
On Tue, Nov 29, 2005 at 10:42:03AM +0000, David Woodhouse wrote:
> I believe not. The previous versions would loop until do_signal()
> returned non-zero; i.e. until a signal was actually delivered.
> By returning -ERESTARTNOHAND we achieve the same effect. If there's a
> signal delivered, that gets magically converted to -EINTR, but if
> there's no signal delivered, the syscall gets restarted.
And, crazy coincidence, I think this will fix the recently reported
ptrace attach bug. Right now if you ptrace a process stuck in
sigsuspend, you can't easily force it to return to userspace.
I'll test that if these patches are merged.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Parag Warudkar @ 2005-11-29 16:11 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linuxppc-dev, debian-powerpc, linux-kernel
In-Reply-To: <20051129075047.GA26460@hansmi.ch>
On Nov 29, 2005, at 2:50 AM, Michael Hanselmann wrote:
> The mouse moves, but slowly. Maybe something isn't correct yet, but it
> works basically.
Yeah, mine works like that too - but sometimes it will go left->right
when you moved the finger
right->left and vice versa.
> I get 256 bytes in each transfer as well, but didn't look at the bytes
> behind 40. Maybe that'll help to make it more responsive.
Nope, if yours works with 80 bytes, it only sends 80. It will still
work with anything > 80 but that's superfluous data.
(E,g, Mine works even with 1024 - anything above 256 seems junk, but
with < 256 it dies with EOVERFLOW )
Right now I have detected that byte # 13 increases when moving finger
along the bottom from left corner to right,
and byte #11 changes when moved from bottom left corner to top left.
Gotta figure out the rest of the movement patterns
along with how many total sensors X and Y are there and how to relate
the data to something to report to the input device!
Hopefully Johannes will have a PowerBook with either of the 0x0214 or
0x0215 touchpads
and we will make some headway!
Parag
^ permalink raw reply
* Re: [PATCH] 3/3 Generic sys_rt_sigsuspend
From: David Woodhouse @ 2005-11-29 16:09 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: drepper, linuxppc-dev, Mika Penttilä, akpm, linux-kernel
In-Reply-To: <20051129155346.GA25431@nevyn.them.org>
On Tue, 2005-11-29 at 10:53 -0500, Daniel Jacobowitz wrote:
> And, crazy coincidence, I think this will fix the recently reported
> ptrace attach bug. Right now if you ptrace a process stuck in
> sigsuspend, you can't easily force it to return to userspace.
> I'll test that if these patches are merged.
That seems to be true. What I get with my patches is...
# strace -p `pidof sigsusptest`
Process 1954 attached - interrupt to quit
rt_sigsuspend([]) = ? ERESTARTNOHAND (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 64), ...}) = 0
ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000
write(1, "r is -1\n", 8) = 8
munmap(0x3001f000, 4096) = 0
exit_group(8) = ?
Process 1954 detached
... whereas without them I get not only a failure to attach, until
there's a signal, but an unexplained SIGSEGV too...
# strace -p `pidof sigsusptest`
Process 3105 attached - interrupt to quit
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigsuspend([]) = 14
rt_sigsuspend([] <unfinished ...>
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 3105 detached
--
dwmw2
^ permalink raw reply
* RE: Which way to store log in flash on mpc8xx?
From: Fillod Stephane @ 2005-11-29 15:37 UTC (permalink / raw)
To: David Jander; +Cc: linux-mtd, linuxppc-embedded
David Jander wrote:
[..]
>After getting some advice from peoble at mtd-list, I switched to 2.6.14
for=20
>our new developments, and jffs2 seems a lot more stable now. I can only
>recommend you to consider switching. Besides consuming a little more
RAM and=20
>Flash, 2.6.14 is miles ahead in terms of almost anything else, plus
it's a=20
>bit faster on 8xx than 2.4.25!!
Strange. I heard a different song here[1], but haven't checked the fact=20
myself. From what I've seen, mtd/jffs2 is faster on 2.6.x than 2.4.x.
[1] http://www.denx.de/wiki/Know/Linux24vs26
>I have to warn you though, that it still seems not to be as rock-solid
as one=20
>might want for an embedded system: We have a stress test running for a
few=20
>weeks now simulating power-failures during writes to files on jffs2,
and mtd=20
>has some occasional hick-ups. Those hick-ups seem to be far less
serious than=20
>gc.c crashing, but we will have to take them into account in our
application.
>This is the situation: Sometimes the test application crashes giving a=20
>write-error on the mtd device, preceded by an error message from the=20
>mtd-driver (and jffs2, but the problem seems to come from mtd). The
error=20
>message is like "MTD do_write_buffer(): software timeout", which
normally=20
See the patch past my sig. It changes the timeout from couple ms to 1
second.
RTAI & Xenomai users should need it. IMHO, the WANT_SHORT_WTIMEOUT
embraced code should simply go away, or get a decent explanation.
>means a flash programming error, most probably due to sector beeing
worn out,=20
>but I don't think that is the case, since those problems began
appearing=20
>quite early and went away all by them selves. Flash doesn't magically
"fix"=20
itself over time, does it?
>Maybe it's a problem in the AMD flash driver (our device is a Spansion=20
Mirror-bit S29GL256M11)
Regards,
--=20
Stephane
--- drivers/mtd/chips/cfi_cmdset_0002.c 12 Sep 2005 09:27:29 -0000
+++ drivers/mtd/chips/cfi_cmdset_0002.c 29 Nov 2005 15:30:30 -0000
@@ -935,6 +935,12 @@
struct cfi_private *cfi =3D map->fldrv_priv;
unsigned long timeo =3D jiffies + HZ;
/*
+ * Hardware errors should be infrequent,
+ * so a short timeout is of no benefit.
+ * And it just hurts with RTAI.
+ */
+#ifdef WANT_SHORT_WTIMEOUT
+ /*
* We use a 1ms + 1 jiffies generic timeout for writes (most
devices
* have a max write time of a few hundreds usec). However, we
should
* use the maximum timeout value given by the chip at probe time
@@ -944,6 +950,7 @@
* timeout of 0 jiffies if HZ is smaller than 1000.
*/
unsigned long uWriteTimeout =3D ( HZ / 1000 ) + 1;
+#endif
int ret =3D 0;
map_word oldd;
int retry_cnt =3D 0;
@@ -987,8 +994,10 @@
adr, map_bankwidth(map),
chip->word_write_time);
=20
+#ifdef WANT_SHORT_WTIMEOUT
/* See comment above for timeout value. */
timeo =3D jiffies + uWriteTimeout;=20
+#endif
for (;;) {
if (chip->state !=3D FL_WRITING) {
/* Someone's suspended the write. Sleep */
@@ -1189,8 +1198,15 @@
{
struct cfi_private *cfi =3D map->fldrv_priv;
unsigned long timeo =3D jiffies + HZ;
+ /*
+ * Hardware errors should be infrequent,
+ * so a short timeout is of no benefit.
+ * And it just hurts with RTAI.
+ */
+#ifdef WANT_SHORT_WTIMEOUT
/* see comments in do_write_oneword() regarding uWriteTimeo. */
unsigned long uWriteTimeout =3D ( HZ / 1000 ) + 1;
+#endif
int ret =3D -EIO;
unsigned long cmd_adr;
int z, words;
@@ -1248,7 +1264,9 @@
adr, map_bankwidth(map),
chip->word_write_time);
=20
+#ifdef WANT_SHORT_WTIMEOUT
timeo =3D jiffies + uWriteTimeout;=20
+#endif
=09
for (;;) {
if (chip->state !=3D FL_WRITING) {
^ permalink raw reply
* immap with 8xx.
From: Ingo Hornberger @ 2005-11-29 14:39 UTC (permalink / raw)
To: linuxppc-devel list
Hi,
I'm currently porting an old 2.4 kernel driver to 2.6.14. I got some
problems with the immap and idma stuff. The driver is very special and
uses it's own dma handling, because it's too different from the default.
So it strongly depends on the underlying hardware. (In this case 8xx)
With kernel 2.4 it used the headers:
- asm/commproc.h
- asm/8xx_immap.h
But it seems that there was some generalization work done, which didn't
reach the 8xx part. Particularly this means that some parts of
'asm/commproc.h' as well as (at least) 'asm/immap_8260.h' built up a new
header 'asm/immap_cpm2.h'.
Actally I miss a file like 'asm/immap_cpm1.h'.
If it would be the right solution to create a file like this, that's no
problem. I only wanted to make sure that I don't do duplicated work this
time.
regards,
Ingo
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: David Jander @ 2005-11-29 14:17 UTC (permalink / raw)
To: David Ho; +Cc: linuxppc-embedded
In-Reply-To: <4dd15d180511281706q388def30r42d3452c392bc92@mail.gmail.com>
Hi,
On Tuesday 29 November 2005 02:06, David Ho wrote:
> Hi, just catching up on this problem as I have another unit that
> showed the same symptom.
> My system looks like this
>
> MPC852T
> 128Mbytes SDRAM
> 64Mbytes Flash
>
> Flash partitions
> 2*1.25Mbytes partitions for Kernel
> 61.5Mbytes for rootfs and applications.
> Remaining 1Mbyte for U-boot, u-boot env and spare.
>
> I get that same problem as well. kernel BUG at gc.c: 139
>
> I have compiled Perl, Openssl, Openssh, etc running NFS so SDRAM is
> definitely not the issue.
I have done almost the same (compiling Perl didn't succeed because of an
out-of memory condition), and never had any other reason to suspect hardware
problems.
After getting some advice from peoble at mtd-list, I switched to 2.6.14 for
our new developments, and jffs2 seems a lot more stable now. I can only
recommend you to consider switching. Besides consuming a little more RAM and
Flash, 2.6.14 is miles ahead in terms of almost anything else, plus it's a
bit faster on 8xx than 2.4.25!!
I have to warn you though, that it still seems not to be as rock-solid as one
might want for an embedded system: We have a stress test running for a few
weeks now simulating power-failures during writes to files on jffs2, and mtd
has some occasional hick-ups. Those hick-ups seem to be far less serious than
gc.c crashing, but we will have to take them into account in our application.
This is the situation: Sometimes the test application crashes giving a
write-error on the mtd device, preceded by an error message from the
mtd-driver (and jffs2, but the problem seems to come from mtd). The error
message is like "MTD do_write_buffer(): software timeout", which normally
means a flash programming error, most probably due to sector beeing worn out,
but I don't think that is the case, since those problems began appearing
quite early and went away all by them selves. Flash doesn't magically "fix"
itself over time, does it?
Maybe it's a problem in the AMD flash driver (our device is a Spansion
Mirror-bit S29GL256M11)
> David: have you gotten any new insights since?
Yes, see above.
Please keep me informed if you get to know something more about the
problem ;-)
If you want more detail about what tests we are doing, and the problems we had
so far, feel free to ask, or read my posts to the MTD list. Right now its
46268 power-cycles and counting.
Greetings,
--
David Jander
Protonic Holland.
^ 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