* Re: 2.6.23-rc6-mm1
From: Andrew Morton @ 2007-09-18 16:53 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: Benjamin, linuxppc-dev, linux-kernel
In-Reply-To: <46EFBF9E.6060208@linux.vnet.ibm.com>
On Tue, 18 Sep 2007 17:37:58 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2007-09-18 at 10:34 +0100, Andy Whitcroft wrote:
> >
> >> On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
> >>
> >>> Andrew Morton wrote:
> >>>
> >>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >>>>
> >>>> 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
> >>>>
> >>>>
> >>>>
> >>> <snip>
> >>>
> >>> Hi Andrew,
> >>>
> >>> The 2.6.23-rc6-mm1build fails at
> >>>
> >>> CC drivers/pci/hotplug/rpadlpar_core.o
> >>> CC drivers/pci/hotplug/rpadlpar_sysfs.o
> >>> drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
> >>> specified in initializer
> >>> drivers/pci/hotplug/rpadlpar_sysfs.c: In function `dlpar_sysfs_init':
> >>> drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member
> >>> named `name'
> >>> make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> >>> make[2]: *** [drivers/pci/hotplug] Error 2
> >>> make[1]: *** [drivers/pci] Error 2
> >>> make: *** [drivers] Error 2
> >>>
> >> This seems to be occuring across a number of the powerpc systems we test
> >> with. That driver is a power dynamic lpar IO partitioning driver.
> >>
> >> Relevant Cc: added.
> >>
> >
> > That's because somebody is breaking sysfs/kobject interfaces without
> > fixing all users :-) (Fair enough... it's just that we need to make sure
> > whoever takes care of that driver nowadays is aware of the breakage).
> >
> > Ben.
> >
> Hi Andrew,
>
> Using the kobject_set_name function to set the kobject k_name.
>
> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> ---
> --- linux-2.6.23-rc6/drivers/pci/hotplug/rpadlpar_sysfs.c
> 2007-09-18 14:56:05.000000000 +0530
> +++ linux-2.6.23-rc6/drivers/pci/hotplug/~rpadlpar_sysfs.c
> 2007-09-18 16:51:55.000000000 +0530
> @@ -129,17 +129,17 @@ struct kobj_type ktype_dlpar_io = {
> };
>
> struct kset dlpar_io_kset = {
> - .kobj = {.name = DLPAR_KOBJ_NAME,
> - .ktype = &ktype_dlpar_io,
> - .parent = &pci_hotplug_slots_subsys.kobj},
> + .kobj = {.ktype = &ktype_dlpar_io,
> + .parent = &pci_hotplug_slots_subsys.kobj},
> .ktype = &ktype_dlpar_io,
> };
>
> int dlpar_sysfs_init(void)
> {
> + kobject_set_name(&dlpar_io_kset.kobj, DLPAR_KOBJ_NAME);
> if (kset_register(&dlpar_io_kset)) {
> printk(KERN_ERR "rpadlpar_io: cannot register kset for
> %s\n",
> - dlpar_io_kset.kobj.name);
> + dlpar_io_kset.kobj.k_name);
> return -EINVAL;
> }
>
Thanks.
Your email client replaces tabs with spaces, and is performing wordwrapping.
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 16:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070918152302.GB788@ld0162-tx32.am.freescale.net>
On Sep 18, 2007, at 10:23 AM, Scott Wood wrote:
> On Tue, Sep 18, 2007 at 10:19:05AM -0500, Kumar Gala wrote:
>> Mainly that 8xx has been doing this for a vast number of years and I
>> see no reason to stop doing it at this point.
>>
>> While I can see that it might be misleading, clearly 8xx linux users
>> haven't had issues with it.
>
> Or they haven't said anything. :-P
:)
> How about a three-way choice of full emulation, minimal emulation,
> and no
> emulation?
I think I'd be ok with that.
- k
^ permalink raw reply
* [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Valentine Barshak @ 2007-09-18 16:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <DF9456FB-459D-4800-B994-D9B198096069@kernel.crashing.org>
Currently pci_32 doesn't support 64-bit physical addresses, while
PowerPC440 platform has PCI space typically mapped above 4GB range.
The patch adds 64-bit physical address support to 32-bit PCI code
in order to bring-up PCI on 44x platform.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/iomap.c | 4 +--
arch/powerpc/kernel/pci_32.c | 56 +++++++++++++++++++++++++++++--------------
2 files changed, 41 insertions(+), 19 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/iomap.c linux-2.6/arch/powerpc/kernel/iomap.c
--- linux-2.6.orig/arch/powerpc/kernel/iomap.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/iomap.c 2007-09-18 17:26:35.000000000 +0400
@@ -119,8 +119,8 @@
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
- unsigned long start = pci_resource_start(dev, bar);
- unsigned long len = pci_resource_len(dev, bar);
+ resource_size_t start = pci_resource_start(dev, bar);
+ resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
if (!len)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/pci_32.c linux-2.6/arch/powerpc/kernel/pci_32.c
--- linux-2.6.orig/arch/powerpc/kernel/pci_32.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/pci_32.c 2007-09-18 18:17:00.000000000 +0400
@@ -105,7 +105,7 @@
{
struct pci_controller* hose = (struct pci_controller *)dev->sysdata;
int i;
- unsigned long offset;
+ resource_size_t offset;
if (!hose) {
printk(KERN_ERR "No hose for PCI dev %s!\n", pci_name(dev));
@@ -115,7 +115,7 @@
struct resource *res = dev->resource + i;
if (!res->flags)
continue;
- if (res->end == 0xffffffff) {
+ if (res->end == (resource_size_t) -1) {
DBG("PCI:%s Resource %d [%016llx-%016llx] is unassigned\n",
pci_name(dev), i, (u64)res->start, (u64)res->end);
res->end -= res->start;
@@ -148,7 +148,7 @@
void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
struct resource *res)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -163,7 +163,7 @@
void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
struct pci_bus_region *region)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -439,7 +439,7 @@
u8 io_base_lo, io_limit_lo;
u16 mem_base, mem_limit;
u16 cmd;
- unsigned long start, end, off;
+ resource_size_t start, end, off;
struct pci_controller *hose = dev->sysdata;
if (!hose) {
@@ -843,16 +843,28 @@
}
EXPORT_SYMBOL(pci_device_from_OF_node);
+
+static inline u64 pci_get_range64(u32 *r)
+{
+ return (((u64)r[0] << 32) | r[1]);
+}
+
+
void __init
pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
static unsigned int static_lc_ranges[256] __initdata;
const unsigned int *dt_ranges;
- unsigned int *lc_ranges, *ranges, *prev, size;
+ unsigned int *lc_ranges, *ranges, *prev;
int rlen = 0, orig_rlen;
int memno = 0;
struct resource *res;
+ u32 prev_pci_space, pci_space;
+ u64 prev_pci_addr, pci_addr;
+ u64 prev_size, size;
+ phys_addr_t cpu_phys_addr;
+
int np, na = of_n_addr_cells(dev);
np = na + 5;
@@ -879,11 +891,18 @@
prev = NULL;
while ((rlen -= np * sizeof(unsigned int)) >= 0) {
if (prev) {
- if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
- (prev[2] + prev[na+4]) == ranges[2] &&
- (prev[na+2] + prev[na+4]) == ranges[na+2]) {
- prev[na+4] += ranges[na+4];
+ prev_pci_space = prev[0];
+ prev_pci_addr = pci_get_range64(&prev[1]);
+ prev_size = pci_get_range64(&prev[na+3]);
+ pci_space = ranges[0];
+ pci_addr = pci_get_range64(&ranges[1]);
+ if ((prev_pci_space == pci_space) &&
+ ((prev_pci_addr + prev_size) == pci_addr)) {
+ size = pci_get_range64(&ranges[na+3]);
+ prev_size += size;
ranges[0] = 0;
+ prev[na+3] = (u32)((prev_size >> 32) & 0xffffffff);
+ prev[na+4] = (u32)(prev_size & 0xffffffff);
ranges += np;
continue;
}
@@ -904,21 +923,22 @@
rlen = orig_rlen;
while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
res = NULL;
- size = ranges[na+4];
- switch ((ranges[0] >> 24) & 0x3) {
+ size = pci_get_range64(&ranges[na+3]);
+ pci_space = ranges[0] >> 24;
+ switch (pci_space & 0x3) {
case 1: /* I/O space */
if (ranges[2] != 0)
break;
- hose->io_base_phys = ranges[na+2];
+ hose->io_base_phys = of_translate_address(dev, &ranges[3]);
/* limit I/O space to 16MB */
if (size > 0x01000000)
size = 0x01000000;
- hose->io_base_virt = ioremap(ranges[na+2], size);
+ hose->io_base_virt = ioremap(hose->io_base_phys, size);
if (primary)
isa_io_base = (unsigned long) hose->io_base_virt;
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
- res->start = ranges[2];
+ res->start = pci_get_range64(&ranges[1]);
DBG("PCI: IO 0x%llx -> 0x%llx\n",
(u64)res->start, (u64)res->start + size - 1);
break;
@@ -933,14 +953,16 @@
}
while (memno < 3 && hose->mem_resources[memno].flags)
++memno;
+ pci_addr = pci_get_range64(&ranges[1]);
+ cpu_phys_addr = of_translate_address(dev, &ranges[3]);
if (memno == 0)
- hose->pci_mem_offset = ranges[na+2] - ranges[2];
+ hose->pci_mem_offset = (u64)cpu_phys_addr - pci_addr;
if (memno < 3) {
res = &hose->mem_resources[memno];
res->flags = IORESOURCE_MEM;
if(ranges[0] & 0x40000000)
res->flags |= IORESOURCE_PREFETCH;
- res->start = ranges[na+2];
+ res->start = cpu_phys_addr;
DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
(u64)res->start, (u64)res->start + size - 1);
}
^ permalink raw reply
* [PATCH 2/2] [FS_ENET] Add polling support
From: Vitaly Bordug @ 2007-09-18 16:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20070918160527.13525.80935.stgit@localhost.localdomain>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/fs_enet/fs_enet-main.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 927cd9e..0e2d2b2 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -61,6 +61,9 @@ module_param(fs_enet_debug, int, 0);
MODULE_PARM_DESC(fs_enet_debug,
"Freescale bitmapped debugging message enable value");
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void fs_enet_netpoll(struct net_device *dev);
+#endif
static void fs_set_multicast_list(struct net_device *dev)
{
@@ -1049,6 +1052,10 @@ static struct net_device *fs_init_instance(struct device *dev,
ndev->stop = fs_enet_close;
ndev->get_stats = fs_enet_get_stats;
ndev->set_multicast_list = fs_set_multicast_list;
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev->poll_controller = fs_enet_netpoll;
+#endif
if (fpi->use_napi) {
ndev->poll = fs_enet_rx_napi;
ndev->weight = fpi->napi_weight;
@@ -1275,6 +1282,15 @@ static void __exit fs_cleanup(void)
cleanup_immap();
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void fs_enet_netpoll(struct net_device *dev)
+{
+ disable_irq(dev->irq);
+ fs_enet_interrupt(dev->irq, dev, NULL);
+ enable_irq(dev->irq);
+}
+#endif
+
/**************************************************************************************/
module_init(fs_init);
^ permalink raw reply related
* [PATCH 1/2] [FS_ENET] TX stuff should use fep->tx_lock, instead of fep->lock.
From: Vitaly Bordug @ 2007-09-18 16:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/fs_enet/fs_enet-main.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index a4a2a0e..927cd9e 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -348,7 +348,7 @@ static void fs_enet_tx(struct net_device *dev)
int dirtyidx, do_wake, do_restart;
u16 sc;
- spin_lock(&fep->lock);
+ spin_lock(&fep->tx_lock);
bdp = fep->dirty_tx;
do_wake = do_restart = 0;
@@ -428,7 +428,7 @@ static void fs_enet_tx(struct net_device *dev)
if (do_restart)
(*fep->ops->tx_restart)(dev);
- spin_unlock(&fep->lock);
+ spin_unlock(&fep->tx_lock);
if (do_wake)
netif_wake_queue(dev);
@@ -826,7 +826,9 @@ static int fs_enet_close(struct net_device *dev)
phy_stop(fep->phydev);
spin_lock_irqsave(&fep->lock, flags);
+ spin_lock(&fep->tx_lock);
(*fep->ops->stop)(dev);
+ spin_unlock(&fep->tx_lock);
spin_unlock_irqrestore(&fep->lock, flags);
/* release any irqs */
^ permalink raw reply related
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Scott Wood @ 2007-09-18 15:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <027F3363-3154-4A16-A251-C56D8DC339A1@kernel.crashing.org>
On Tue, Sep 18, 2007 at 10:19:05AM -0500, Kumar Gala wrote:
> Mainly that 8xx has been doing this for a vast number of years and I
> see no reason to stop doing it at this point.
>
> While I can see that it might be misleading, clearly 8xx linux users
> haven't had issues with it.
Or they haven't said anything. :-P
How about a three-way choice of full emulation, minimal emulation, and no
emulation?
-Scott
^ permalink raw reply
* Re: Problem booting linux with device tree table
From: Scott Wood @ 2007-09-18 15:17 UTC (permalink / raw)
To: Andrew Liu; +Cc: linuxppc-embedded
In-Reply-To: <46EF93D8.6050201@windriver.com>
On Tue, Sep 18, 2007 at 05:01:12PM +0800, Andrew Liu wrote:
> Latest U-boot need a chosen node in your DTS file,
It does not.
> So u need to add a chosen node in your DTS file.
>
> Take mpc8272ads for example: in its DTS, has the following:
>
> chosen {
> name = "chosen";
> linux,platform = <0>;
> interrupt-controller = <&Cpm_pic>;
> };
Please don't use that file as an example. :-)
-Scott
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Domen Puncer @ 2007-09-18 15:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709171508s76c842c8hca236249617cbb44@mail.gmail.com>
(I edited Cc: -jeff, +sven, hope you don't mind)
On 17/09/07 18:08 -0400, Jon Smirl wrote:
> On 9/17/07, Domen Puncer <domen@coderock.org> wrote:
> > Export phy_mii_ioctl, so network drivers can use it when built
> > as modules too.
>
> Domen, do you want to collect all of these changes for MPC5200 FEC in
> to a single patch series? The code is getting scattered around, I'll
> check it over to make sure it is all working. I have these patches
> applied individually and they all work.
>
> It builds on this series:
> [PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
>
> If you can put this together is a clean series, I should be able to
> layer support for the Phytec pcm030 on top of it.
>
> It would be these three combined...
>
> http://coderock.org/tmp/fec-v3rc1/
http://coderock.org/tmp/fec-v3rc2/
export_phy_mii_ioctl
fec_driver-bestcomm
fec_driver-dts
fec_driver-fec
fec_driver-phy
Built (on top of 7 bestcomm patches) and ran it built-in and as module
on Efika.
Order of applying only matters for phy part, which has to be after
the fec driver.
More testing and getting it to work properly on Phytec pcm030 would
be great.
Domen
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 15:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070918151147.GB736@ld0162-tx32.am.freescale.net>
On Sep 18, 2007, at 10:11 AM, Scott Wood wrote:
> On Tue, Sep 18, 2007 at 10:08:50AM -0500, Kumar Gala wrote:
>>
>> On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
>>
>>> On arch/ppc, Soft_emulate_8xx was used when full math emulation was
>>> turned off to emulate a minimal subset of floating point load/store
>>> instructions, to avoid needing a soft-float toolchain. This
>>> function
>>> is called, but not present, on arch/powerpc, causing a build error
>>> if floating point emulation is turned off.
>>>
>>> As:
>>> 1. soft-float toolchains are now common,
>>> 2. partial emulation could mislead someone into thinking they have
>>> a soft-float userspace because things usually work, only to have it
>>> fail when actual FP gets executed under unusual circumstances, and
>>> 3. full emulation is still available for those who need to run
>>> non-soft-float userspace,
>>>
>>> I'm deleting the call rather than moving Soft_emulate_8xx over to
>>> arch/powerpc.
>>>
>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>
>> I'm still not in favor of this and think we should move the
>> Soft_emulate_8xx code over.
>
> Any particular reasons that outweigh the reasons I gave, especially
> #2?
Mainly that 8xx has been doing this for a vast number of years and I
see no reason to stop doing it at this point.
While I can see that it might be misleading, clearly 8xx linux users
haven't had issues with it.
- k
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Scott Wood @ 2007-09-18 15:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <58472170-34D3-43F4-A816-87AF0020A086@kernel.crashing.org>
On Tue, Sep 18, 2007 at 10:08:50AM -0500, Kumar Gala wrote:
>
> On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
>
> >On arch/ppc, Soft_emulate_8xx was used when full math emulation was
> >turned off to emulate a minimal subset of floating point load/store
> >instructions, to avoid needing a soft-float toolchain. This function
> >is called, but not present, on arch/powerpc, causing a build error
> >if floating point emulation is turned off.
> >
> >As:
> >1. soft-float toolchains are now common,
> >2. partial emulation could mislead someone into thinking they have
> >a soft-float userspace because things usually work, only to have it
> >fail when actual FP gets executed under unusual circumstances, and
> >3. full emulation is still available for those who need to run
> >non-soft-float userspace,
> >
> >I'm deleting the call rather than moving Soft_emulate_8xx over to
> >arch/powerpc.
> >
> >Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> I'm still not in favor of this and think we should move the
> Soft_emulate_8xx code over.
Any particular reasons that outweigh the reasons I gave, especially #2?
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Kumar Gala @ 2007-09-18 15:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EFE849.7080508@ru.mvista.com>
On Sep 18, 2007, at 10:01 AM, Valentine Barshak wrote:
> Kumar Gala wrote:
>> On Sep 18, 2007, at 9:44 AM, Valentine Barshak wrote:
>>> Add 64-bit physical address support to PCI.
>> Can you expand on your commit message. for example why do this?
>> is it address a bug fix, etc..
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>> arch/powerpc/kernel/iomap.c | 4 +--
>>> arch/powerpc/kernel/pci_32.c | 56 ++++++++++++++++++++++++++++
>>> +--------------
>>> 2 files changed, 41 insertions(+), 19 deletions(-)
>> - k
>
> Currently 32-bit pci code doesn't support 64-bit physical addresses.
> We have to add 64-bit addr support in order to bring-up pci on
> PowerPC 440. Actually, this refers to the conversation started here:
I can guess as to why, but its useful for the commit messages to be
more descriptive so when some goes back a year from now they know why
someone added this patch.
- k
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 15:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070917165746.GP6563@loki.buserror.net>
On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
> On arch/ppc, Soft_emulate_8xx was used when full math emulation was
> turned off to emulate a minimal subset of floating point load/store
> instructions, to avoid needing a soft-float toolchain. This function
> is called, but not present, on arch/powerpc, causing a build error
> if floating point emulation is turned off.
>
> As:
> 1. soft-float toolchains are now common,
> 2. partial emulation could mislead someone into thinking they have
> a soft-float userspace because things usually work, only to have it
> fail when actual FP gets executed under unusual circumstances, and
> 3. full emulation is still available for those who need to run
> non-soft-float userspace,
>
> I'm deleting the call rather than moving Soft_emulate_8xx over to
> arch/powerpc.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I'm still not in favor of this and think we should move the
Soft_emulate_8xx code over.
- k
^ permalink raw reply
* Re: dtc: Whitespace cleanup
From: Jon Loeliger @ 2007-09-18 15:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070918014404.GB30766@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This large patch removes all trailing whitespace from dtc (including
> libfdt, the testsuite and documentation). It also removes a handful
> of redundant blank lines (at the end of functions, or when there are
> two blank lines together for no particular reason).
>
> As well as anything else, this means that quilt won't whinge when I go
> to convert the whole of libfdt into a patch to apply to the kernel.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Add basic testcases for dtc
From: Jon Loeliger @ 2007-09-18 15:02 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070918003340.GA30766@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds a handful of simple testcases for dtc. It adds a dts
> file which should generate the same sample tree as is used for the
> libfdt testcases, and tests invoking dtc on this dts, plus the
> standard batch of libfdt cases on the resulting dtb, which effectively
> checks that the dtb is correct.
>
> Because the test framework assumes each testcase is an executable with
> the right output conventions, we use a little shell script, dtc.sh, as
> a wrapper around dtc itself. It simply invokes dtc and returns a PASS
> or FAIL depending on whether dtc returned an error.
>
> It's not much, but it's a start.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
> NB: Jon, you won't be able to simply git-applymbox this and have it
> work. You'll need to manually add execute permission to tests/dtc.sh
> before git commiting it, since I can't encode the permissions in a
> patch. Sorry for the inconvenience, but it didn't really seem worth
> setting up my own git to pull from just for that.
No problem. Too bad you can't just use git, though... :-)
jdl
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Valentine Barshak @ 2007-09-18 15:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2E339F78-F42B-4FCE-A97E-FFE9AE4C44F1@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 18, 2007, at 9:44 AM, Valentine Barshak wrote:
>
>> Add 64-bit physical address support to PCI.
>
> Can you expand on your commit message. for example why do this? is it
> address a bug fix, etc..
>
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> arch/powerpc/kernel/iomap.c | 4 +--
>> arch/powerpc/kernel/pci_32.c | 56
>> +++++++++++++++++++++++++++++--------------
>> 2 files changed, 41 insertions(+), 19 deletions(-)
>
> - k
>
Currently 32-bit pci code doesn't support 64-bit physical addresses.
We have to add 64-bit addr support in order to bring-up pci on PowerPC
440. Actually, this refers to the conversation started here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042267.html
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH 03/28] Document local bus nodes in the device tree.
From: Kumar Gala @ 2007-09-18 15:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070917165731.GC6563@loki.buserror.net>
On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
> cuboot-pq2 is updated to match the binding, and get rid of phandle
> linkage.
A slight more descriptive commit message is desired.
- k
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 38 +++++++++++++++
> +++++++++++
> arch/powerpc/boot/cuboot-pq2.c | 29 ++++
> +--------------
> 2 files changed, 46 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Kumar Gala @ 2007-09-18 14:52 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070918144426.GA22102@ru.mvista.com>
On Sep 18, 2007, at 9:44 AM, Valentine Barshak wrote:
> Add 64-bit physical address support to PCI.
Can you expand on your commit message. for example why do this? is
it address a bug fix, etc..
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/kernel/iomap.c | 4 +--
> arch/powerpc/kernel/pci_32.c | 56 ++++++++++++++++++++++++++++
> +--------------
> 2 files changed, 41 insertions(+), 19 deletions(-)
- k
^ permalink raw reply
* RE: [PATCH 23/28] mpc82xx: Define CPU_FTR_NEED_COHERENT
From: Rune Torgersen @ 2007-09-18 14:34 UTC (permalink / raw)
To: Scott Wood, galak; +Cc: linuxppc-dev
In-Reply-To: <20070917165815.GW6563@loki.buserror.net>
> -----Original Message-----
> From: Scott Wood
> Sent: Monday, September 17, 2007 11:58 AM
>=20
> The 8272 (and presumably other PCI PQ2 chips) appear to have the
> same issue as the 83xx regarding PCI streaming DMA.
>=20
Can you explain what this isssue is? We're using a 8280 and have had
some PCI busmaster DMA problems, and wonder if it is related.
^ permalink raw reply
* [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Valentine Barshak @ 2007-09-18 14:44 UTC (permalink / raw)
To: linuxppc-dev
Add 64-bit physical address support to PCI.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/iomap.c | 4 +--
arch/powerpc/kernel/pci_32.c | 56 +++++++++++++++++++++++++++++--------------
2 files changed, 41 insertions(+), 19 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/iomap.c linux-2.6/arch/powerpc/kernel/iomap.c
--- linux-2.6.orig/arch/powerpc/kernel/iomap.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/iomap.c 2007-09-18 17:26:35.000000000 +0400
@@ -119,8 +119,8 @@
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
- unsigned long start = pci_resource_start(dev, bar);
- unsigned long len = pci_resource_len(dev, bar);
+ resource_size_t start = pci_resource_start(dev, bar);
+ resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
if (!len)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/pci_32.c linux-2.6/arch/powerpc/kernel/pci_32.c
--- linux-2.6.orig/arch/powerpc/kernel/pci_32.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/pci_32.c 2007-09-18 18:17:00.000000000 +0400
@@ -105,7 +105,7 @@
{
struct pci_controller* hose = (struct pci_controller *)dev->sysdata;
int i;
- unsigned long offset;
+ resource_size_t offset;
if (!hose) {
printk(KERN_ERR "No hose for PCI dev %s!\n", pci_name(dev));
@@ -115,7 +115,7 @@
struct resource *res = dev->resource + i;
if (!res->flags)
continue;
- if (res->end == 0xffffffff) {
+ if (res->end == (resource_size_t) -1) {
DBG("PCI:%s Resource %d [%016llx-%016llx] is unassigned\n",
pci_name(dev), i, (u64)res->start, (u64)res->end);
res->end -= res->start;
@@ -148,7 +148,7 @@
void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
struct resource *res)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -163,7 +163,7 @@
void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
struct pci_bus_region *region)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -439,7 +439,7 @@
u8 io_base_lo, io_limit_lo;
u16 mem_base, mem_limit;
u16 cmd;
- unsigned long start, end, off;
+ resource_size_t start, end, off;
struct pci_controller *hose = dev->sysdata;
if (!hose) {
@@ -843,16 +843,28 @@
}
EXPORT_SYMBOL(pci_device_from_OF_node);
+
+static inline u64 pci_get_range64(u32 *r)
+{
+ return (((u64)r[0] << 32) | r[1]);
+}
+
+
void __init
pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
static unsigned int static_lc_ranges[256] __initdata;
const unsigned int *dt_ranges;
- unsigned int *lc_ranges, *ranges, *prev, size;
+ unsigned int *lc_ranges, *ranges, *prev;
int rlen = 0, orig_rlen;
int memno = 0;
struct resource *res;
+ u32 prev_pci_space, pci_space;
+ u64 prev_pci_addr, pci_addr;
+ u64 prev_size, size;
+ phys_addr_t cpu_phys_addr;
+
int np, na = of_n_addr_cells(dev);
np = na + 5;
@@ -879,11 +891,18 @@
prev = NULL;
while ((rlen -= np * sizeof(unsigned int)) >= 0) {
if (prev) {
- if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
- (prev[2] + prev[na+4]) == ranges[2] &&
- (prev[na+2] + prev[na+4]) == ranges[na+2]) {
- prev[na+4] += ranges[na+4];
+ prev_pci_space = prev[0];
+ prev_pci_addr = pci_get_range64(&prev[1]);
+ prev_size = pci_get_range64(&prev[na+3]);
+ pci_space = ranges[0];
+ pci_addr = pci_get_range64(&ranges[1]);
+ if ((prev_pci_space == pci_space) &&
+ ((prev_pci_addr + prev_size) == pci_addr)) {
+ size = pci_get_range64(&ranges[na+3]);
+ prev_size += size;
ranges[0] = 0;
+ prev[na+3] = (u32)((prev_size >> 32) & 0xffffffff);
+ prev[na+4] = (u32)(prev_size & 0xffffffff);
ranges += np;
continue;
}
@@ -904,21 +923,22 @@
rlen = orig_rlen;
while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
res = NULL;
- size = ranges[na+4];
- switch ((ranges[0] >> 24) & 0x3) {
+ size = pci_get_range64(&ranges[na+3]);
+ pci_space = ranges[0] >> 24;
+ switch (pci_space & 0x3) {
case 1: /* I/O space */
if (ranges[2] != 0)
break;
- hose->io_base_phys = ranges[na+2];
+ hose->io_base_phys = of_translate_address(dev, &ranges[3]);
/* limit I/O space to 16MB */
if (size > 0x01000000)
size = 0x01000000;
- hose->io_base_virt = ioremap(ranges[na+2], size);
+ hose->io_base_virt = ioremap(hose->io_base_phys, size);
if (primary)
isa_io_base = (unsigned long) hose->io_base_virt;
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
- res->start = ranges[2];
+ res->start = pci_get_range64(&ranges[1]);
DBG("PCI: IO 0x%llx -> 0x%llx\n",
(u64)res->start, (u64)res->start + size - 1);
break;
@@ -933,14 +953,16 @@
}
while (memno < 3 && hose->mem_resources[memno].flags)
++memno;
+ pci_addr = pci_get_range64(&ranges[1]);
+ cpu_phys_addr = of_translate_address(dev, &ranges[3]);
if (memno == 0)
- hose->pci_mem_offset = ranges[na+2] - ranges[2];
+ hose->pci_mem_offset = (u64)cpu_phys_addr - pci_addr;
if (memno < 3) {
res = &hose->mem_resources[memno];
res->flags = IORESOURCE_MEM;
if(ranges[0] & 0x40000000)
res->flags |= IORESOURCE_PREFETCH;
- res->start = ranges[na+2];
+ res->start = cpu_phys_addr;
DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
(u64)res->start, (u64)res->start + size - 1);
}
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Valentine Barshak @ 2007-09-18 14:38 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070918182704.640c677f@localhost.localdomain>
Vitaly Bordug wrote:
> Hello Valentine,
>
> On Tue, 18 Sep 2007 16:03:50 +0400
> Valentine Barshak wrote:
>
>> Vitaly Bordug wrote:
>>> +
>>> + hose->io_base_phys = cpu_phys_addr - pci_addr;
>> This is not gonna work on 32-bit platform (unless pci_addr == 0).
>> Should be
>> hose->io_base_phys = cpu_phys_addr;
>> The other way we should adjust io size like we do on 64-bit and rewrite
>> resource fixup functions.
>>
> I think the second sounds like a plan then. We should not "assume" where we can make things to behave properly.
>
>>> + /* handle from 0 to top of I/O window */
>>> +#ifdef CONFIG_PPC64
>>> + hose->pci_io_size = pci_addr + size;
>>> +#endif
>>> + hose->io_base_virt = ioremap(hose->io_base_phys, size);
>> Do we need to ioremap on 64-bit? I think 64-bit uses different approach
>> in handling io space.
>>
> Correct - 64 bit code does __get_vm_area() so the upper line is ppc32-specific.
>>> +#ifdef CONFIG_PPC32
>>> + if (prim)
>>> + isa_io_base = (unsigned long)hose->io_base_virt;
>>> +#endif
>> What's exactly the point of merging this single function?
>> If this was intended to add 64-bit physical address support to 32-bit
>> platforms (like ppc440), then it does not seem sufficient to make pci
>> stuff work right.
>> What about the 32-bit pcibios_fixup_resources(),
>> pcibios_resource_to_bus(), pcibios_bus_to_resource() stuff?
>> There's still no 64-bit support. You'll get
>> "PCI Cannot allocate resource region" attempting to initialize resources
>> at PCI start-up.
> Because this function is critical to get the stuff going. You can have some devices working even without PCI resources initted
> (what in fact I had with mpc8272). I am in process of moving the mentioned to the common_... domain but I suspect there are other 32-bit-stick stuff still. So if you want to assist in cleaning this up, feel free to join the club...
Well, thanks for the invitation :)
I've been trying to work on the pci support here too. But I've used a
bit different approach. I tried to add 64-bit phys addr support to
pci_32.c. The patch seems to work on Sequoia. Actually, I thought
merging was too risky at this point and might cause more problems
breaking both 64 and 32-bit pci support.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-09-18 14:27 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EFBEA6.4050406@ru.mvista.com>
Hello Valentine,
On Tue, 18 Sep 2007 16:03:50 +0400
Valentine Barshak wrote:
> Vitaly Bordug wrote:
> > +
> > + hose->io_base_phys = cpu_phys_addr - pci_addr;
>
> This is not gonna work on 32-bit platform (unless pci_addr == 0).
> Should be
> hose->io_base_phys = cpu_phys_addr;
> The other way we should adjust io size like we do on 64-bit and rewrite
> resource fixup functions.
>
I think the second sounds like a plan then. We should not "assume" where we can make things to behave properly.
> > + /* handle from 0 to top of I/O window */
> > +#ifdef CONFIG_PPC64
> > + hose->pci_io_size = pci_addr + size;
> > +#endif
> > + hose->io_base_virt = ioremap(hose->io_base_phys, size);
>
> Do we need to ioremap on 64-bit? I think 64-bit uses different approach
> in handling io space.
>
Correct - 64 bit code does __get_vm_area() so the upper line is ppc32-specific.
> > +#ifdef CONFIG_PPC32
> > + if (prim)
> > + isa_io_base = (unsigned long)hose->io_base_virt;
> > +#endif
>
> What's exactly the point of merging this single function?
> If this was intended to add 64-bit physical address support to 32-bit
> platforms (like ppc440), then it does not seem sufficient to make pci
> stuff work right.
> What about the 32-bit pcibios_fixup_resources(),
> pcibios_resource_to_bus(), pcibios_bus_to_resource() stuff?
> There's still no 64-bit support. You'll get
> "PCI Cannot allocate resource region" attempting to initialize resources
> at PCI start-up.
Because this function is critical to get the stuff going. You can have some devices working even without PCI resources initted
(what in fact I had with mpc8272). I am in process of moving the mentioned to the common_... domain but I suspect there are other 32-bit-stick stuff still. So if you want to assist in cleaning this up, feel free to join the club...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] sysdev/commproc.c: fix build caused by undefined symbols
From: Kumar Gala @ 2007-09-18 14:26 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070918122925.GA17481@localhost.localdomain>
On Sep 18, 2007, at 7:29 AM, Anton Vorontsov wrote:
> cpm_install_handler and cpm_free_handler neither used nor defined
> for arch/powerpc.
>
> This causes MPC8xx build failure, patch used to fix that.
can you add the __res fix, and EXPORT() and do these three as one
patch and improve the commit message. I'm guessing this all shows up
when we try to build with CONFIG_MODULES=y. Put the actual compile
failures in the commit message.
- k
^ permalink raw reply
* Re: [PATCH 01/28] CPM: Change from fsl, brg-frequency to brg/clock-frequency
From: Scott Wood @ 2007-09-18 14:21 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070918061141.GE30766@localhost.localdomain>
On Tue, Sep 18, 2007 at 04:11:41PM +1000, David Gibson wrote:
> > + /* Legacy device binding -- will go away when no users are left. */
> > + node = of_find_node_by_type(NULL, "cpm");
> > + if (node) {
> > + prop = of_get_property(node, "brg-frequency", &size);
>
> Shouldn't you check for "fsl,brg-frequency" here, in case of old
> device trees?
What old device trees? fsl,brg-frequency has never hit mainline; it's
only been in Kumar's tree for a week or so.
-Scott
^ permalink raw reply
* RE: Ethernet adapter not found in Xilinx ppc, with linux 2.6.22
From: Junqiang Hu @ 2007-09-18 14:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY138-F271854679106F05A7C7117B2B80@phx.gbl>
Hi, Ming,
I do have the Xilinx generated Ethernet driver in hand, but could you
suggest how to add that driver into my 2.6.22 version?
Thanks!
mliu wrote:
>=20
> Hi,
>>
>>After several days of struggling I'm now able to boot the linux 2.6.22 an=
d
>>run the busybox-1.7.1 root system. Yet I could not find the Ethernet
>>adapter using Xilinx GMAC core. Pretty sure that I've chosen the 10/100
>>Ethernet drivers. Should I use the Xilinx driver xemac, or other drivers=
,
>>or any other way to apply a patch?
>=20
> If you are using gigabit ethernet, you must have the corresponding driver=
=20
> (gigabit or tri-state) instead of 10/100 one included.=20
>=20
> BR
> Ming
>=20
> _________________________________________________________________
> =E5=85=8D=E8=B4=B9=E4=B8=8B=E8=BD=BD MSN Explorer: http://explorer.msn.=
com/lccn/ =20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
View this message in context: http://www.nabble.com/Ethernet-adapter-not-fo=
und-in-Xilinx-ppc%2C-with-linux-2.6.22-tf4470255.html#a12758059
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
From: Kumar Gala @ 2007-09-18 14:11 UTC (permalink / raw)
To: tnt, Sylvain Munaut; +Cc: PowerPC dev list
In-Reply-To: <58950.87.65.18.190.1190089793.squirrel@www.opensources.be>
On Sep 17, 2007, at 11:29 PM, tnt@blacksnow.net wrote:
>> On 9/16/07, Sylvain Munaut <tnt@246tnt.com> wrote:
>>> Hello Paul, Hi everyone,
>>>
>>> This series of patch is mainly the bestcomm support for
>>> the mpc5200. It was posted a while ago and received some
>>> comments. Theses are all addressed here (afaik).
>>
>> Does this series supersede these pacthes out of your older series?
>
> Yes.
> Those are the patches I wrote to fix the comments received last time.
> They are now merged inside the main patches.
>
> Apparently I forgot to fix some other comments so I'll have to do
> that and repost again.
>
One of the big things I'd like to see for the core bestcomm lib is
proper kernel doc support for the APIs. I think we should be going
more of this for things like QE and will push on the guys doing
working there to better document the 'library' APIs.
Also, I remember you wrote up some documentation/email about what the
APIs did. Is that in a clean enough state to add do Documentation/
powerpc/?
- k
^ 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