* Re: [PATCH] ib_core: Add missing device link to class device
From: Roland Dreier @ 2007-04-24 18:27 UTC (permalink / raw)
To: Joachim Fenkes; +Cc: LinuxPPC-Dev, LKML, OF-General
In-Reply-To: <OF8C8AA8EC.A66DAC49-ONC12572C7.00416B4B-C12572C7.00428AF7@de.ibm.com>
> I had a look at the kernel code -- currently, all device drivers except
> ehca do this by themselves:
> So I think it makes a lot of sense to put the class_dev.dev assignment
> into generic ib_core code instead of repeating it in all the drivers.
> The respective lines could move out of the drivers in the future but
> won't hurt anyone until then.
Actually I think we should delete the duplicate code now while merging
this. So I queued this up for 2.6.22:
commit f19c8d7cbe3153d68f0a559afd02f66655310238
Author: Joachim Fenkes <fenkes@de.ibm.com>
Date: Mon Apr 23 18:20:27 2007 +0200
IB: Set class_dev->dev in core for nice device symlink
All RDMA drivers except ehca set class_dev->dev to their dma_device
value (ehca leaves this unset). dma_device is the only value that
makes any sense, so move this assignment to core/sysfs.c. This reduce
the duplicated code in the rest of the drivers and gives ehca a nice
/sys/class/infiniband/ehcaX/device symlink.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniband/core/sysfs.c
index 000c086..08c299e 100644
--- a/drivers/infiniband/core/sysfs.c
+++ b/drivers/infiniband/core/sysfs.c
@@ -683,6 +683,7 @@ int ib_device_register_sysfs(struct ib_device *device)
class_dev->class = &ib_class;
class_dev->class_data = device;
+ class_dev->dev = device->dma_device;
strlcpy(class_dev->class_id, device->name, BUS_ID_SIZE);
INIT_LIST_HEAD(&device->port_list);
diff --git a/drivers/infiniband/hw/amso1100/c2_provider.c b/drivers/infiniband/hw/amso1100/c2_provider.c
index fef9727..607c09b 100644
--- a/drivers/infiniband/hw/amso1100/c2_provider.c
+++ b/drivers/infiniband/hw/amso1100/c2_provider.c
@@ -796,7 +796,6 @@ int c2_register_device(struct c2_dev *dev)
memcpy(&dev->ibdev.node_guid, dev->pseudo_netdev->dev_addr, 6);
dev->ibdev.phys_port_cnt = 1;
dev->ibdev.dma_device = &dev->pcidev->dev;
- dev->ibdev.class_dev.dev = &dev->pcidev->dev;
dev->ibdev.query_device = c2_query_device;
dev->ibdev.query_port = c2_query_port;
dev->ibdev.modify_port = c2_modify_port;
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index 24e0df0..af28a31 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -1108,7 +1108,6 @@ int iwch_register_device(struct iwch_dev *dev)
memcpy(dev->ibdev.node_desc, IWCH_NODE_DESC, sizeof(IWCH_NODE_DESC));
dev->ibdev.phys_port_cnt = dev->rdev.port_info.nports;
dev->ibdev.dma_device = &(dev->rdev.rnic_info.pdev->dev);
- dev->ibdev.class_dev.dev = &(dev->rdev.rnic_info.pdev->dev);
dev->ibdev.query_device = iwch_query_device;
dev->ibdev.query_port = iwch_query_port;
dev->ibdev.modify_port = iwch_modify_port;
diff --git a/drivers/infiniband/hw/ipath/ipath_verbs.c b/drivers/infiniband/hw/ipath/ipath_verbs.c
index f5604b8..18c6df2 100644
--- a/drivers/infiniband/hw/ipath/ipath_verbs.c
+++ b/drivers/infiniband/hw/ipath/ipath_verbs.c
@@ -1559,7 +1559,6 @@ int ipath_register_ib_device(struct ipath_devdata *dd)
dev->node_type = RDMA_NODE_IB_CA;
dev->phys_port_cnt = 1;
dev->dma_device = &dd->pcidev->dev;
- dev->class_dev.dev = dev->dma_device;
dev->query_device = ipath_query_device;
dev->modify_device = ipath_modify_device;
dev->query_port = ipath_query_port;
diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c b/drivers/infiniband/hw/mthca/mthca_provider.c
index 0725ad7..47e6fd4 100644
--- a/drivers/infiniband/hw/mthca/mthca_provider.c
+++ b/drivers/infiniband/hw/mthca/mthca_provider.c
@@ -1293,7 +1293,6 @@ int mthca_register_device(struct mthca_dev *dev)
dev->ib_dev.node_type = RDMA_NODE_IB_CA;
dev->ib_dev.phys_port_cnt = dev->limits.num_ports;
dev->ib_dev.dma_device = &dev->pdev->dev;
- dev->ib_dev.class_dev.dev = &dev->pdev->dev;
dev->ib_dev.query_device = mthca_query_device;
dev->ib_dev.query_port = mthca_query_port;
dev->ib_dev.modify_device = mthca_modify_device;
^ permalink raw reply related
* unsubscribe
From: mike @ 2007-04-24 18:07 UTC (permalink / raw)
To: linuxppc-dev
Michael J. Kelly
VP Engineering
Cogent Computer Systems, Inc.
17 Industrial Dr.
Smithfield, RI 02917
tel:401-223-3441 fax:401-223-3442
www.cogcomp.com
alternate email: mkelly6505@hotmail.com
^ permalink raw reply
* Re: [PATCH 1/6] Start split out of common open firmware code
From: Segher Boessenkool @ 2007-04-24 18:18 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus, sfr
In-Reply-To: <20070424.110456.124867547.davem@davemloft.net>
> I totally disagree that you should be changing anything
> during these consolidations.
And I didn't say so, I actually *said* I don't think
that should be done.
I was just remarking some really bad workarounds end
up in more generic code now, and as such need to be
fixed. Not now, but *later*.
> Move the code around in one pass where you can _VERIFY_
> that things are precisely the same and won't break.
>
> Then later you can get fancy and change things however you
> wish.
Yes exactly.
> Everything so far is pure whining, and has nothing to do with
> the substance of what Stephen is trying to accomplish, a
> _CODE CONSOLIDATION_. So please don't get in the way of that
> effort.
I'm not standing in the way here, I'm quite happy with
what Stephen is doing, great job.
I'm just pointing out some bugs/workarounds in the
merged code (that were there before, sure) -- it would
be lovely if they at least could be commented as being
not-quite-right in the new code so no one reading the
code will assume it is doing the "right thing".
Segher
^ permalink raw reply
* Re: [PATCH 1/6] Start split out of common open firmware code
From: David Miller @ 2007-04-24 18:04 UTC (permalink / raw)
To: jdl; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <AF0367BA48C55940A43CCF08DF35553C011ECCD1@az33exm24.fsl.freescale.net>
From: "Loeliger Jon-LOELIGER" <jdl@freescale.com>
Date: Tue, 24 Apr 2007 07:47:10 -0700
>
> > > +int of_n_addr_cells(struct device_node *np)
> > > +{
> > > + const int *ip;
> > > +
> > > + do {
> > > + if (np->parent)
> > > + np = np->parent;
> > > + ip = of_get_property(np, "#address-cells", NULL);
> > > + if (ip)
> > > + return *ip;
> > > + } while (np->parent);
> > > + /* No #address-cells property for the root node */
> > > + return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
> > > +}
> > > +EXPORT_SYMBOL(of_n_addr_cells);
> >
> > While I realise your patch is just moving stuff around,
> > can this be fixed please? A missing "#address-cells"
> > property means "two cells", not "inherit from parent".
> > The few platforms with a broken tree should just be
> > fixed (patch the tree in the bootwrapper, or perhaps
> > _do_ use this workaround, but only on the affected
> > platforms).
> >
> > > +int of_n_size_cells(struct device_node *np)
> >
> > Same here (the default is one cell though).
>
> Agreed. We actually discussed this quite some time ago.
I totally disagree that you should be changing anything
during these consolidations.
Move the code around in one pass where you can _VERIFY_
that things are precisely the same and won't break.
Then later you can get fancy and change things however you
wish.
You people giving comments like this have your priorities totally
screwed up and you are doing nothing but unnecessarily slowing down
this wonderful consolidation. Even worse you might even be giving
Stephen a disincentive to keep working actively on this.
So please STOP THIS CRAP now, thanks.
Everything so far is pure whining, and has nothing to do with
the substance of what Stephen is trying to accomplish, a
_CODE CONSOLIDATION_. So please don't get in the way of that
effort.
^ permalink raw reply
* Re: [PATCH] ehea: fix for dlpar and sysfs entries
From: Jeff Garzik @ 2007-04-24 18:01 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200704051122.28428.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> This patch includes:
> - dlpar fix:
> certain resources may only be allocated when first
> logical port is available, and must be removed when
> last logical port has been removed
>
> - sysfs entries:
> create symbolic link from each logical port to ehea driver
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
What Arnd said... this should be two patches
^ permalink raw reply
* [PATCH] pasemi: remove build warning
From: Olof Johansson @ 2007-04-24 18:01 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
arch/powerpc/platforms/pasemi/setup.c: In function 'pasemi_publish_devices':
arch/powerpc/platforms/pasemi/setup.c:220: warning: implicit declaration of function 'of_platform_bus_probe'
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 9944ffc..a7bf88e 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -35,6 +35,7 @@
#include <asm/mpic.h>
#include <asm/smp.h>
#include <asm/time.h>
+#include <asm/of_platform.h>
#include "pasemi.h"
^ permalink raw reply related
* [PATCH] pasemi: Kconfig for mdio_gpio
From: Olof Johansson @ 2007-04-24 17:58 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, arnd
arch/powerpc/platforms/pasemi/gpio_mdio.c really depends on CONFIG_PHYLIB.
Add a config option for it, allow for it to be disabled if needed and fix
the dependency.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 64e5525..4b5f137 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -19,4 +19,12 @@ config PPC_PASEMI_IOMMU
help
IOMMU support for PA6T-1682M
+config PPC_PASEMI_MDIO
+ depends on PPC_PASEMI
+ bool "MDIO support via GPIO"
+ default y
+ select PHYLIB
+ help
+ Driver for MDIO via GPIO on PWRficient platforms
+
endmenu
diff --git a/arch/powerpc/platforms/pasemi/Makefile b/arch/powerpc/platforms/pasemi/Makefile
index e90265f..7ffd43b 100644
--- a/arch/powerpc/platforms/pasemi/Makefile
+++ b/arch/powerpc/platforms/pasemi/Makefile
@@ -1,2 +1,2 @@
-obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o gpio_mdio.o
-
+obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o
+obj-$(CONFIG_PPC_PASEMI_MDIO) += gpio_mdio.o
^ permalink raw reply related
* Re: [PATCH] eHCA: Add "Modify Port" verb
From: Roland Dreier @ 2007-04-24 17:52 UTC (permalink / raw)
To: Joachim Fenkes; +Cc: LinuxPPC-Dev, LKML, OF-General
In-Reply-To: <200704241744.31691.fenkes@de.ibm.com>
Looks good, applied for 2.6.22.
^ permalink raw reply
* Re: 2.6 Kernel , Xilinx Virtex and PPC 405 On chip memory controllers ( DSOCM and ISOCM )
From: Grant Likely @ 2007-04-24 17:43 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: linuxppc-embedded
In-Reply-To: <BAY115-W14E65268F6A301B98090EEB24A0@phx.gbl>
On 4/24/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>
> Then in mailing list I saw some where that AVNET mini-modules are using a version of FX12 FPGA which has problem with PPC caches and as the solution the caches should be off.
>
> Does the kernel always turns on the caches? Or If I choose in the base system builder to not to use caches, the kernel will not use them?
I'm pretty sure that specific issue was due to a certain version of
silicon. You'll need to check the Xilinx errata sheets.
>
> Any special config parameter for this in xparameters.h?
No. You need to hack the startup code to turn off caches.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Linas Vepstas @ 2007-04-24 17:35 UTC (permalink / raw)
To: Christoph Hellwig, Eric W. Biederman, <Andrew Morton,
containers, Oleg Nesterov, linux-kernel, Paul Mackerras,
linux-s390, linuxppc-dev
In-Reply-To: <20070422123155.GF20763@infradead.org>
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> This patch modifies the startup of eehd to use kthread_run
> not a combination of kernel_thread and daemonize. Making
> the code slightly simpler and more maintainable.
For the patch that touched arch/powerpc/platforms/pseries/eeh_event.c,
I ran a variety of tests, and couldn't see/find/evoke any adverse
effects, so ..
Acked-by: Linas Vepstas <linas@austin.ibm.com>
> The second question is whether this is the right implementation.
> kthread_create already works by using a workqueue to create the thread
> and then waits for it. If we really want to support creating threads
> asynchronously on demand we should have a proper API in kthread.c for
> this instead of spreading workqueues.
Yes, exactly; all I really want is to start a thread from an
interrupt context, and pass a structure to it. This is pretty much
all that arch/powerpc/platforms/pseries/eeh_event.c is trying to do,
and little else.
--linas
^ permalink raw reply
* Re: [PATCH 3/4] bootwrapper: Add ppcboot.h.
From: Scott Wood @ 2007-04-24 17:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17965.37623.561459.64174@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Wolfgang Denk writes:
>
>
>>Shouldn't we finally get this straight and call the file "u-boot.h" as
>>it is called in U-Boot?
>
>
> Is it identical to the one in U-Boot?
It's missing the MPC8220 and NX823 bits and the phynum/mode bits for 4xx
other than 440GP (which I guess were added after the kernel's ppcboot.h
forked), and u-boot's has been changed to have CONFIG_HAS_ETH1/2/etc.
rather than a list of targets, but otherwise it appears to be
functionally identical.
Do you want me to resubmit using the current u-boot file (as well as an
updated 83xx platform file to define CONFIG_HAS_ETH1)?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: uninline of_iomap function
From: Arnd Bergmann @ 2007-04-24 17:27 UTC (permalink / raw)
To: Christian Krafft; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070424173202.15e5ce42@localhost>
On Tuesday 24 April 2007, Christian Krafft wrote:
> From: Christian Krafft <krafft@de.ibm.com>
> There is no big reason to have that function inlined.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Linas Vepstas @ 2007-04-24 17:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Paul Mackerras, Eric W. Biederman, containers,
Oleg Nesterov
In-Reply-To: <1177378733.14873.52.camel@localhost.localdomain>
On Tue, Apr 24, 2007 at 11:38:53AM +1000, Benjamin Herrenschmidt wrote:
> > The only reason for using threads here is to get the error recovery
> > out of an interrupt context (where errors may be detected), and then,
> > an hour later, decrement a counter (which is how we limit these to
> > 6 per hour). Thread reaping is "trivial", the thread just exits
> > after an hour.
>
> In addition, it should be a thread and not done from within keventd
> because :
>
> - It can take a long time (well, relatively but still too long for a
> work queue)
Uhh, 15 or 20 seconds even. That's a long time by any kernel standard.
> - The driver callbacks might need to use keventd or do flush_workqueue
> to synchronize with their own workqueues when doing an internal
> recovery.
>
> > Since these are events rare, I've no particular concern about
> > performance or resource consumption. The current code seems
> > to work just fine. :-)
>
> I think moving to kthread's is cleaner (just a wrapper around kernel
> threads that simplify dealing with reaping them out mostly) and I agree
> with Christoph that it would be nice to be able to "fire off" kthreads
> from interrupt context.. in many cases, we abuse work queues for things
> that should really done from kthreads instead (basically anything that
> takes more than a couple hundred microsecs or so).
It would be nice to have threads that can be "fired off" from an
interrupt context. That would simplify the EEH code slightly
(removing a few dozen lines of code that do this bounce).
I presume that various device drivers might find this useful as well.
--linas
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Andrei Konovalov @ 2007-04-24 17:11 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <10165159.post@talk.nabble.com>
AFAICT, the TEMAC device has not been registered on the platform bus.
You should add this stuff to arch/ppc/syslib/virtex_devices.c
(if you use the recent patches by Grant Likely).
xtemac_g.c is not used in 2.6 TEMAC driver(s I have seen).
Thanks,
Andrei
Mirek23 wrote:
> Thanks for the suggestions. I have changed the command line argument:
> console:ttl0 -> ttyUL0 and kernel has booted up to the point to mount the
> root file system.
>
> I have set up the kernel to mount the root file systems via the nfs. I have
> started the nfs server on the remote pc.
> Unfortunately the kernel did not mount the nfs root file system. The strange
> thing is that during booting the kernel I did not see any entry which refers
> to the TEMAC driver (which I have enabled in the kernel).
>
> I have noticed that in the drivers/net/xilinx_temac directory there is a
> file xtemac_g.c. It creates the global variable (a table) which contains all
> fo the definitions to configure TEMAC interface. All of the definitions used
> in the xtemac_g.c file come from xparameters_ml403.h. The strange thing is
> that this xtemac_g.c is not include in the Makefile to be compiled.
>
> I have incluede that file to the Makefile in order to use the TEMAC config
> parameters but when booting the kernel I did not find any diffrence
> compering to the driver which was originaly built without the xtemac_g.c
>
> The kernel boots as following:
>
> loaded at: 00400000 004F9138
> board data at: 004F7120 004F7138
> relocated to: 004040B8 004040D0
> zimage at: 00404E45 004F6D1F
> avail ram: 004FA000 04000000
>
> Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
> nfsroot=129.129.130.106:/opt/eldk41/ppc_4xx,tcp
> ip=129.129.129.29:255.255.255.0:LM200:eth0:off panic=1
>
> Uncompressing Linux...done.
> Now booting the kernel
> [ 0.000000] Linux version 2.6.21-rc6-gd4bba4bf-dirty (root@pc5215) (gcc
> version 4.0.2) #8 Tue Apr 24 14:51:35 CEST 2007
> [ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0 -> 16384
> [ 0.000000] Normal 16384 -> 16384
> [ 0.000000] early_node_map[1] active PFN ranges
> [ 0.000000] 0: 0 -> 16384
> [ 0.000000] Built 1 zonelists. Total pages: 16256
> [ 0.000000] Kernel command line: console=ttyUL0,9600 root=/dev/nfs rw
> nfsroot=129.129.130.106:/opt/eldk41/ppc_4xx,tcp
> ip=129.129.129.29:255.255.255.0:LM200:eth0:off panic=1
> [ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> [ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
> [ 0.000418] Console: colour dummy device 80x25
> [ 0.001487] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.003212] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> [ 0.034378] Memory: 62720k available (1568k kernel code, 512k data, 96k
> init, 0k highmem)
> [ 0.121194] Mount-cache hash table entries: 512
> [ 0.129484] NET: Registered protocol family 16
> [ 0.162553] NET: Registered protocol family 2
> [ 0.196706] IP route cache hash table entries: 1024 (order: 0, 4096
> bytes)
> [ 0.197898] TCP established hash table entries: 2048 (order: 2, 16384
> bytes)
> [ 0.198605] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> [ 0.199040] TCP: Hash tables configured (established 2048 bind 2048)
> [ 0.199126] TCP reno registered
> [ 0.219619] io scheduler noop registered
> [ 0.219727] io scheduler anticipatory registered (default)
> [ 0.219807] io scheduler deadline registered
> [ 0.220367] io scheduler cfq registered
> [ 0.321949] uartlite.0: ttyUL0 at MMIO 0x40600003 (irq = 0) is a uartlite
> [ 2.254924] RAMDISK driver initialized: 1 RAM disks of 8192K size 1024
> blocksize
> [ 2.346633] tun: Universal TUN/TAP device driver, 1.6
> [ 2.407407] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [ 2.485482] mice: PS/2 mouse device common for all mice
> [ 2.548404] TCP cubic registered
> [ 2.587334] NET: Registered protocol family 1
> [ 2.639671] NET: Registered protocol family 17
> [ 3.197934] IP-Config: No network devices available.
> [ 3.259979] Looking up port of RPC 100003/2 on 129.129.130.106
> [ 3.331237] Root-NFS: Unable to get nfsd port number from server, using
> default
> [ 3.419194] Looking up port of RPC 100005/1 on 129.129.130.106
> [ 3.490204] Root-NFS: Unable to get mountd port number from server, using
> default
> [ 3.581337] Root-NFS: Server returned error -5 while mounting
> /opt/eldk41/ppc_4xx
> [ 3.671568] VFS: Unable to mount root fs via NFS, trying floppy.
> [ 3.747080] VFS: Cannot open root device "nfs" or unknown-block(2,0)
> [ 3.823496] Please append a correct "root=" boot option
> [ 3.886242] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> [ 3.985551] Rebooting in 1 seconds..<NULL>
>
>
>
> Would you have any idea why it did not recognise the TEMAC interface and how
> to configure the kernel that it recognises the network device.
>
> Mirek
^ permalink raw reply
* Re: powerpc: Abolish PHYS_FMT macro from arch/powerpc
From: Linas Vepstas @ 2007-04-24 17:00 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20070424050518.GC30007@localhost.localdomain>
On Tue, Apr 24, 2007 at 03:05:18PM +1000, David Gibson wrote:
> 32-bit powerpc systems define a macro, PHYS_FMT, giving a printf
Your patch removed the use of the macro, but does not remove the definition
of the macro.
--linas
^ permalink raw reply
* RE: zImage.elf loads but does not start
From: Mirek23 @ 2007-04-24 16:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C0159BAAE@ehost011-3.exch011.intermedia.net>
Thanks for the suggestions. I have changed the command line argument:
console:ttl0 -> ttyUL0 and kernel has booted up to the point to mount the
root file system.
I have set up the kernel to mount the root file systems via the nfs. I have
started the nfs server on the remote pc.
Unfortunately the kernel did not mount the nfs root file system. The strange
thing is that during booting the kernel I did not see any entry which refers
to the TEMAC driver (which I have enabled in the kernel).
I have noticed that in the drivers/net/xilinx_temac directory there is a
file xtemac_g.c. It creates the global variable (a table) which contains all
fo the definitions to configure TEMAC interface. All of the definitions used
in the xtemac_g.c file come from xparameters_ml403.h. The strange thing is
that this xtemac_g.c is not include in the Makefile to be compiled.
I have incluede that file to the Makefile in order to use the TEMAC config
parameters but when booting the kernel I did not find any diffrence
compering to the driver which was originaly built without the xtemac_g.c
The kernel boots as following:
loaded at: 00400000 004F9138
board data at: 004F7120 004F7138
relocated to: 004040B8 004040D0
zimage at: 00404E45 004F6D1F
avail ram: 004FA000 04000000
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.129.130.106:/opt/eldk41/ppc_4xx,tcp
ip=129.129.129.29:255.255.255.0:LM200:eth0:off panic=1
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.21-rc6-gd4bba4bf-dirty (root@pc5215) (gcc
version 4.0.2) #8 Tue Apr 24 14:51:35 CEST 2007
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists. Total pages: 16256
[ 0.000000] Kernel command line: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.129.130.106:/opt/eldk41/ppc_4xx,tcp
ip=129.129.129.29:255.255.255.0:LM200:eth0:off panic=1
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000418] Console: colour dummy device 80x25
[ 0.001487] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.003212] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.034378] Memory: 62720k available (1568k kernel code, 512k data, 96k
init, 0k highmem)
[ 0.121194] Mount-cache hash table entries: 512
[ 0.129484] NET: Registered protocol family 16
[ 0.162553] NET: Registered protocol family 2
[ 0.196706] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.197898] TCP established hash table entries: 2048 (order: 2, 16384
bytes)
[ 0.198605] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.199040] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.199126] TCP reno registered
[ 0.219619] io scheduler noop registered
[ 0.219727] io scheduler anticipatory registered (default)
[ 0.219807] io scheduler deadline registered
[ 0.220367] io scheduler cfq registered
[ 0.321949] uartlite.0: ttyUL0 at MMIO 0x40600003 (irq = 0) is a uartlite
[ 2.254924] RAMDISK driver initialized: 1 RAM disks of 8192K size 1024
blocksize
[ 2.346633] tun: Universal TUN/TAP device driver, 1.6
[ 2.407407] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 2.485482] mice: PS/2 mouse device common for all mice
[ 2.548404] TCP cubic registered
[ 2.587334] NET: Registered protocol family 1
[ 2.639671] NET: Registered protocol family 17
[ 3.197934] IP-Config: No network devices available.
[ 3.259979] Looking up port of RPC 100003/2 on 129.129.130.106
[ 3.331237] Root-NFS: Unable to get nfsd port number from server, using
default
[ 3.419194] Looking up port of RPC 100005/1 on 129.129.130.106
[ 3.490204] Root-NFS: Unable to get mountd port number from server, using
default
[ 3.581337] Root-NFS: Server returned error -5 while mounting
/opt/eldk41/ppc_4xx
[ 3.671568] VFS: Unable to mount root fs via NFS, trying floppy.
[ 3.747080] VFS: Cannot open root device "nfs" or unknown-block(2,0)
[ 3.823496] Please append a correct "root=" boot option
[ 3.886242] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)
[ 3.985551] Rebooting in 1 seconds..<NULL>
Would you have any idea why it did not recognise the TEMAC interface and how
to configure the kernel that it recognises the network device.
Mirek
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10165159
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] generic check_legacy_ioport
From: Milton Miller @ 2007-04-24 15:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: ppcdev
In-Reply-To: <20070424112530.GA11489@aepfle.de>
On Tue Apr 24 21:25:30 EST 2007, Olaf Hering wrote:
> Thats how it may look finally, currently only compile tested.
>
> int check_legacy_ioport(unsigned long base_port)
> {
> struct device_node *parent, *np = NULL;
> int ret = -ENODEV;
...
> if (np) {
> parent = of_get_parent(np);
> if (parent) {
> ret = strcmp(parent->type, "isa");
This calculates the return as 0 / anything, vs 0 / -ENODEV.
> of_node_put(parent);
> }
> of_node_put(np);
> }
> return ret;
> }
^ permalink raw reply
* [PATCH] eHCA: Add "Modify Port" verb
From: Joachim Fenkes @ 2007-04-24 15:44 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier
Add "Modify Port" verb support to eHCA driver.
ib_cm needs this to initialize properly.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
This is the shiny new version of this patch with proper locking.
Tested and works.
ehca_classes.h | 1 +
ehca_hca.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
ehca_main.c | 1 +
hcp_if.c | 24 ++++++++++++++++++++++++
hcp_if.h | 4 ++++
5 files changed, 83 insertions(+), 2 deletions(-)
diff -urp a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
--- a/drivers/infiniband/hw/ehca/ehca_classes.h 2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h 2007-04-24 14:51:38.000000000 +0200
@@ -96,6 +96,7 @@ struct ehca_shca {
struct ehca_mr *maxmr;
struct ehca_pd *pd;
struct h_galpas galpas;
+ struct mutex modify_mutex;
};
struct ehca_pd {
diff -urp a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
--- a/drivers/infiniband/hw/ehca/ehca_hca.c 2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c 2007-04-24 14:50:43.000000000 +0200
@@ -147,6 +147,7 @@ int ehca_query_port(struct ib_device *ib
break;
}
+ props->port_cap_flags = rblock->capability_mask;
props->gid_tbl_len = rblock->gid_tbl_len;
props->max_msg_sz = rblock->max_msg_sz;
props->bad_pkey_cntr = rblock->bad_pkey_cntr;
@@ -233,10 +234,60 @@ query_gid1:
return ret;
}
+const u32 allowed_port_caps = (
+ IB_PORT_SM | IB_PORT_LED_INFO_SUP | IB_PORT_CM_SUP |
+ IB_PORT_SNMP_TUNNEL_SUP | IB_PORT_DEVICE_MGMT_SUP |
+ IB_PORT_VENDOR_CLASS_SUP);
+
int ehca_modify_port(struct ib_device *ibdev,
u8 port, int port_modify_mask,
struct ib_port_modify *props)
{
- /* Not implemented yet */
- return -EFAULT;
+ int ret = 0;
+ struct ehca_shca *shca = container_of(ibdev, struct ehca_shca, ib_device);
+ struct hipz_query_port *rblock;
+ u32 cap;
+ u64 hret;
+
+ if ((props->set_port_cap_mask | props->clr_port_cap_mask)
+ & ~allowed_port_caps) {
+ ehca_err(&shca->ib_device, "Non-changeable bits set in masks "
+ "set=%x clr=%x allowed=%x", props->set_port_cap_mask,
+ props->clr_port_cap_mask, allowed_port_caps);
+ return -EINVAL;
+ }
+
+ if (mutex_lock_interruptible(&shca->modify_mutex))
+ return -ERESTARTSYS;
+
+ rblock = ehca_alloc_fw_ctrlblock(GFP_KERNEL);
+ if (!rblock) {
+ ehca_err(&shca->ib_device, "Can't allocate rblock memory.");
+ ret = -ENOMEM;
+ goto modify_port1;
+ }
+
+ if (hipz_h_query_port(shca->ipz_hca_handle, port, rblock) != H_SUCCESS) {
+ ehca_err(&shca->ib_device, "Can't query port properties");
+ ret = -EINVAL;
+ goto modify_port2;
+ }
+
+ cap = (rblock->capability_mask | props->set_port_cap_mask)
+ & ~props->clr_port_cap_mask;
+
+ hret = hipz_h_modify_port(shca->ipz_hca_handle, port,
+ cap, props->init_type, port_modify_mask);
+ if (hret != H_SUCCESS) {
+ ehca_err(&shca->ib_device, "Modify port failed hret=%lx", hret);
+ ret = -EINVAL;
+ }
+
+modify_port2:
+ ehca_free_fw_ctrlblock(rblock);
+
+modify_port1:
+ mutex_unlock(&shca->modify_mutex);
+
+ return ret;
}
diff -urp a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
--- a/drivers/infiniband/hw/ehca/ehca_main.c 2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/infiniband/hw/ehca/ehca_main.c 2007-04-24 14:50:43.000000000 +0200
@@ -583,6 +583,7 @@ static int __devinit ehca_probe(struct i
ehca_gen_err("Cannot allocate shca memory.");
return -ENOMEM;
}
+ mutex_init(&shca->modify_mutex);
shca->ibmebus_dev = dev;
shca->ipz_hca_handle.handle = *handle;
diff -urp a/drivers/infiniband/hw/ehca/hcp_if.c b/drivers/infiniband/hw/ehca/hcp_if.c
--- a/drivers/infiniband/hw/ehca/hcp_if.c 2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/infiniband/hw/ehca/hcp_if.c 2007-04-23 18:06:09.000000000 +0200
@@ -70,6 +70,10 @@
#define H_ALL_RES_QP_SQUEUE_SIZE_PAGES EHCA_BMASK_IBM(0, 31)
#define H_ALL_RES_QP_RQUEUE_SIZE_PAGES EHCA_BMASK_IBM(32, 63)
+#define H_MP_INIT_TYPE EHCA_BMASK_IBM(44, 47)
+#define H_MP_SHUTDOWN EHCA_BMASK_IBM(48, 48)
+#define H_MP_RESET_QKEY_CTR EHCA_BMASK_IBM(49, 49)
+
/* direct access qp controls */
#define DAQP_CTRL_ENABLE 0x01
#define DAQP_CTRL_SEND_COMP 0x20
@@ -364,6 +368,26 @@ u64 hipz_h_query_port(const struct ipz_a
return ret;
}
+u64 hipz_h_modify_port(const struct ipz_adapter_handle adapter_handle,
+ const u8 port_id, const u32 port_cap,
+ const u8 init_type, const int modify_mask)
+{
+ u64 port_attributes = port_cap;
+
+ if (modify_mask & IB_PORT_SHUTDOWN)
+ port_attributes |= EHCA_BMASK_SET(H_MP_SHUTDOWN, 1);
+ if (modify_mask & IB_PORT_INIT_TYPE)
+ port_attributes |= EHCA_BMASK_SET(H_MP_INIT_TYPE, init_type);
+ if (modify_mask & IB_PORT_RESET_QKEY_CNTR)
+ port_attributes |= EHCA_BMASK_SET(H_MP_RESET_QKEY_CTR, 1);
+
+ return ehca_plpar_hcall_norets(H_MODIFY_PORT,
+ adapter_handle.handle, /* r4 */
+ port_id, /* r5 */
+ port_attributes, /* r6 */
+ 0, 0, 0, 0);
+}
+
u64 hipz_h_query_hca(const struct ipz_adapter_handle adapter_handle,
struct hipz_query_hca *query_hca_rblock)
{
diff -urp a/drivers/infiniband/hw/ehca/hcp_if.h b/drivers/infiniband/hw/ehca/hcp_if.h
--- a/drivers/infiniband/hw/ehca/hcp_if.h 2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/infiniband/hw/ehca/hcp_if.h 2007-04-23 18:06:09.000000000 +0200
@@ -85,6 +85,10 @@ u64 hipz_h_query_port(const struct ipz_a
const u8 port_id,
struct hipz_query_port *query_port_response_block);
+u64 hipz_h_modify_port(const struct ipz_adapter_handle adapter_handle,
+ const u8 port_id, const u32 port_cap,
+ const u8 init_type, const int modify_mask);
+
u64 hipz_h_query_hca(const struct ipz_adapter_handle adapter_handle,
struct hipz_query_hca *query_hca_rblock);
^ permalink raw reply
* RE: 2.6 Kernel , Xilinx Virtex and PPC 405 On chip memory controllers ( DSOCM and ISOCM )
From: Mohammad Sadegh Sadri @ 2007-04-24 15:37 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
Then in mailing list I saw some where that AVNET mini-modules are using a v=
ersion of FX12 FPGA which has problem with PPC caches and as the solution t=
he caches should be off.
Does the kernel always turns on the caches? Or If I choose in the base syst=
em builder to not to use caches, the kernel will not use them?=20
Any special config parameter for this in xparameters.h?
thanks
----------------------------------------
> Date: Tue, 24 Apr 2007 08:59:37 -0600
> From: grant.likely@secretlab.ca
> To: mamsadegh@hotmail.com
> Subject: Re: 2.6 Kernel , Xilinx Virtex and PPC 405 On chip memory contro=
llers ( DSOCM and ISOCM )
> CC: linuxppc-embedded@ozlabs.org
>=20
> On 4/24/07, Mohammad Sadegh Sadri wrote:
> >
> >
> > what about the cache?
> > Does the current kernel use the cache efficiently?
>=20
> Yes, the caches work and are turned on by the kernel.
>=20
> g.
>=20
> --=20
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx=
^ permalink raw reply
* Re: [PATCH] powerpc: uninline of_iomap function
From: Christian Krafft @ 2007-04-24 15:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann, Arnd Bergmann
In-Reply-To: <1177378533.14873.48.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]
From: Christian Krafft <krafft@de.ibm.com>
There is no big reason to have that function inlined.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux-2.6.21-rc4/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-2.6.21-rc4.orig/arch/powerpc/kernel/prom_parse.c
+++ linux-2.6.21-rc4/arch/powerpc/kernel/prom_parse.c
@@ -1042,3 +1042,15 @@ const void *of_get_mac_address(struct de
}
EXPORT_SYMBOL(of_get_mac_address);
+void __iomem *of_iomap(struct device_node *np, int index)
+{
+ struct resource res;
+
+ if (of_address_to_resource(np, index, &res))
+ return NULL;
+
+ return ioremap(res.start, 1 + res.end - res.start);
+}
+EXPORT_SYMBOL(of_iomap);
+
+
Index: linux-2.6.21-rc4/include/asm-powerpc/prom.h
===================================================================
--- linux-2.6.21-rc4.orig/include/asm-powerpc/prom.h
+++ linux-2.6.21-rc4/include/asm-powerpc/prom.h
@@ -19,7 +19,6 @@
#include <linux/proc_fs.h>
#include <linux/platform_device.h>
#include <asm/atomic.h>
-#include <asm/io.h>
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
@@ -352,16 +351,14 @@ static inline int of_irq_to_resource(str
return irq;
}
-static inline void __iomem *of_iomap(struct device_node *np, int index)
-{
- struct resource res;
-
- if (of_address_to_resource(np, index, &res))
- return NULL;
-
- return ioremap(res.start, 1 + res.end - res.start);
-}
-
+/**
+ * of_iomap - Maps the memory mapped IO for a given device_node
+ * @device: the device whose io range will be mapped
+ * @index: index of the io range
+ *
+ * Returns a pointer to the mapped memory
+ */
+extern void __iomem *of_iomap(struct device_node *device, int index);
#endif /* __KERNEL__ */
#endif /* _POWERPC_PROM_H */
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Using Xilinx Framebuffer on ML405 and 2.6.20.4
From: Lorenz Kolb @ 2007-04-24 15:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1028.1177426735.26657.linuxppc-embedded@ozlabs.org>
> Message: 1
> Date: Tue, 24 Apr 2007 17:58:13 +0400
> From: Andrei Konovalov <akonovalov@ru.mvista.com>
> Subject: Re: Using Xilinx Framebuffer on ML405 and 2.6.20.4
> To: Grant Likely <grant.likely@secretlab.ca>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID: <462E0CF5.4060402@ru.mvista.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Grant Likely wrote:
>> On 4/24/07, Peter Mendham <petermendham@computing.dundee.ac.uk> wrote:
>>> Dear all,
>>>
>>> I am wanting to use the Xilinx TFT controller from the ML403/5 reference
>>> project (probably from ML300 as well) under a 2.6.20.4 kernel. I have
>>> Grant Likely's patchset applied in which there is a platform device
>>> entry for the framebuffer. Does anyone know if there is mainline
>>> support for the Xilinx-style framebuffer? If so, how do I enable it? I
>>> have included framebuffer support in my kernel build, but I assume I
>>> need a driver also? Any tips greatly appreciated.
>>
>> Heh, I've got a driver. I just haven't published it yet. Give me a few
days...
>>
>> g.
>>
>
> We have one too :)
To be continued: we have one too :)
I guess fb support is too simple, as too many people have wrote that driver
...
Greetings,
Lorenz
^ permalink raw reply
* Re: 2.6 Kernel , Xilinx Virtex and PPC 405 On chip memory controllers ( DSOCM and ISOCM )
From: Grant Likely @ 2007-04-24 14:59 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: linuxppc-embedded
In-Reply-To: <BAY115-W63BB55D8630825D7BBEAFB24A0@phx.gbl>
On 4/24/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>
>
> what about the cache?
> Does the current kernel use the cache efficiently?
Yes, the caches work and are turned on by the kernel.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ML403, root=/dev/xsa3 rw, bonnie++
From: Grant Likely @ 2007-04-24 14:58 UTC (permalink / raw)
To: Andrei Konovalov, Linux PPC
In-Reply-To: <462E17BF.3080404@ru.mvista.com>
On 4/24/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> Hi Grant,
>
> I've discovered the IBM Microdrive fits perfectly into the ML403 CF slot :)
> So I've repeated the bonnie++ stress test on ML403 with the hard disk.
> The log is below.
> The test completed OK, but there was one message from the driver in the middle
> of the test:
> "[ 776.712206] xsysace xsa: kicking stalled fsm; state=3 task=3 iter=7829 dc=0"
I added a kernel timer to the sysace driver to give the state machine
a nudge if there is no activity after a short amount of time; for
example, if an interrupt is missed. It is a rare condition, but if it
happens, then the timer keeps the driver from hanging up completely.
I don't know how to avoid the condition. It seems to be related to
the CFBSY and DATARDY status bits. It seems that sometimes the sysace
raises a DATARDY irq, but the driver cannot do anything because CFBSY
is set. Then, after clearing that condition and yielding for a bit a
subsequent DATARDY irq is lost and the state machine stalls.
Thanks for the testing, it's a big help.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: 2.6 Kernel , Xilinx Virtex and PPC 405 On chip memory controllers ( DSOCM and ISOCM )
From: Mohammad Sadegh Sadri @ 2007-04-24 14:52 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
what about the cache?
Does the current kernel use the cache efficiently?
----------------------------------------
> Date: Tue, 24 Apr 2007 07:55:48 -0600
> From: grant.likely@secretlab.ca
> To: mamsadegh@hotmail.com
> Subject: Re: 2.6 Kernel , Xilinx Virtex and PPC 405 On chip memory contro=
llers ( DSOCM and ISOCM )
> CC: linuxppc-embedded@ozlabs.org
>=20
> On 4/24/07, Mohammad Sadegh Sadri wrote:
> >
> > suppose that in my base system I have included 8kbytes of memory for DS=
OCM and 8K for IS OCM,
> > I have generated the proper xparameters.h and copied it into kernel
> >
> > Now I want to know if kernel will use this portion of memory during it'=
s operation?
> > Does this increase performance?
>=20
> No, it won't use that memory as general purpose RAM. You can make use
> of it in device drivers (ie. for DMA space), but you'll need to write
> the code to support it.
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
_________________________________________________________________
Connect to the next generation of MSN Messenger=A0
http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc=
e=3Dwlmailtagline=
^ permalink raw reply
* RE: [PATCH 1/6] Start split out of common open firmware code
From: Loeliger Jon-LOELIGER @ 2007-04-24 14:47 UTC (permalink / raw)
To: Segher Boessenkool, Stephen Rothwell; +Cc: ppc-dev, paulus, David S. Miller
In-Reply-To: <f64705c9250a93dcb7a4015b9a0d5667@kernel.crashing.org>
=20
> > +int of_n_addr_cells(struct device_node *np)
> > +{
> > + const int *ip;
> > +
> > + do {
> > + if (np->parent)
> > + np =3D np->parent;
> > + ip =3D of_get_property(np, "#address-cells", NULL);
> > + if (ip)
> > + return *ip;
> > + } while (np->parent);
> > + /* No #address-cells property for the root node */
> > + return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
> > +}
> > +EXPORT_SYMBOL(of_n_addr_cells);
>=20
> While I realise your patch is just moving stuff around,
> can this be fixed please? A missing "#address-cells"
> property means "two cells", not "inherit from parent".
> The few platforms with a broken tree should just be
> fixed (patch the tree in the bootwrapper, or perhaps
> _do_ use this workaround, but only on the affected
> platforms).
>=20
> > +int of_n_size_cells(struct device_node *np)
>=20
> Same here (the default is one cell though).
Agreed. We actually discussed this quite some time ago.
Thanks,
jdl
PS -- Any fixes for the DTC would be welcomed patches too! :-)
^ 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