* Re: How can I support 2GB of memory in Linux kernel on 440SPe
From: Vincitore @ 2007-12-30 15:31 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03C7D08F@ismail.innsys.innovsys.com>
Hi Rune,
I tried what you suggested. With no luck.
I enabled CONFIG_HIGHMEM=y
Now I panic when when unpacking_rootfs.
...
Memory: 2076148k available (2160k kernel code, 764k data, 144k init,
1048572k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...Oops: kernel access of bad area, sig: 11 [#1]
NIP: A02A9618 LR: A02A9598 CTR: A002EAE8
REGS: dfc01e60 TRAP: 0300 Not tainted (2.6.19.2)
MSR: 00029000 <EE,ME> CR: 24000084 XER: 00000000
DAR: 1FDEA000, DSISR: 00000000
TASK = a13e4ba0[1] 'swapper' THREAD: dfc00000
GPR00: 00000000 DFC01F10 A13E4BA0 DFC10000 000000D0 00000001 2D89B700 A02C0000
GPR08: DFC01D18 A02C0000 00000000 A02C3F78 24000084 70000000 A02D0000 00000000
GPR16: 00000001 00800000 7FFFF0FC 00000000 A02C0000 A02C0000 7FFEE61C 00000001
GPR24: 00000000 007FFE70 00000D80 00184F9D 1FDEA000 A02D0000 A00012F8 A02D0000
NIP [A02A9618] unpack_to_rootfs+0xdc/0xa54
LR [A02A9598] unpack_to_rootfs+0x5c/0xa54
Call Trace:
[DFC01F10] [A02A9598] unpack_to_rootfs+0x5c/0xa54 (unreliable)
[DFC01F60] [A02AA050] populate_rootfs+0x7c/0x104
[DFC01F80] [A0001328] init+0x30/0x2a4
[DFC01FF0] [A00047E0] kernel_thread+0x44/0x60
Instruction dump:
912b0000 3ce0a02c 3d20a02c 914b0004 90074038 90093f8c 3ce0a02c 80074038
2f800000 409e0054 2f9b0000 419e004c <881c0000> 39753f78 2f800030 82cb0000
This is the same if I have CONFIG_HIGHMEM disabled. The only
difference is highmem now shows up as 0k.
Memory: 2076148k available (2160k kernel code, 764k data, 144k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...Oops: kernel access of bad area, sig: 11 [#1]
...
Vincitore
On 12/28/07, Rune Torgersen <runet@innovsys.com> wrote:
> > From: linuxppc-embedded-bounces+runet=innovsys.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces+runet=innovsys.com@ozlabs.or
> > g] On Behalf Of Vincitore
> > Sent: Friday, December 28, 2007 8:00 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: How can I support 2GB of memory in Linux kernel on 440SPe
> >
> > Hi,
> >
> > I need to support 2GB of memory on a custom 440SPe board.
> >
> > I see to support 1GB of memory on the 440SPe yucca board the following
> > configuration changes were done.
>
> Just leave the configuration for 1 GB, and enable CONFIG_HIGHMEM
> That gives you 2 (or more) GB of RAM, with 1G as lowmwm.
>
^ permalink raw reply
* Re: How can I support 2GB of memory in Linux kernel on 440SPe
From: Vincitore @ 2007-12-30 15:36 UTC (permalink / raw)
To: Michele Pallaro; +Cc: linuxppc-embedded
In-Reply-To: <47751456.7010600@alcatel-lucent.it>
Hi Michele,
I also tried this and it did not work. It also panics while unpacking rootfs
Onced your system is up do you see all of the 2GB of Memory.
# cat /proc/meminfo
Thank You,
Vincitore
On 12/28/07, Michele Pallaro <michele.pallaro@alcatel-lucent.it> wrote:
> CONFIG_ADVANCED_OPTIONS=y
> # CONFIG_HIGHMEM_START_BOOL is not set
> CONFIG_HIGHMEM_START=0xfe000000
> # CONFIG_LOWMEM_SIZE_BOOL is not set
> CONFIG_LOWMEM_SIZE=0x30000000
> CONFIG_KERNEL_START_BOOL=y
> CONFIG_KERNEL_START=0x80000000
> # CONFIG_TASK_SIZE_BOOL is not set
> CONFIG_TASK_SIZE=0x80000000
>
> I use ppc 8555E with 2G
>
> Michele
>
>
> Vincitore wrote:
> > Hi,
> >
> > I need to support 2GB of memory on a custom 440SPe board.
> >
> > I see to support 1GB of memory on the 440SPe yucca board the following
> > configuration changes were done.
> >
> > #
> > # Advanced setup
> > #
> >
> > CONFIG_ADVANCED_OPTIONS=y
> > CONFIG_HIGHMEM_START=0xfe000000
> > CONFIG_LOWMEM_SIZE_BOOL=y
> > CONFIG_LOWMEM_SIZE=0x40000000
> > CONFIG_KERNEL_START_BOOL=y
> > CONFIG_KERNEL_START=0xa0000000
> > # CONFIG_TASK_SIZE_BOOL is not set
> > CONFIG_TASK_SIZE=0x80000000
> > # CONFIG_CONSISTENT_START_BOOL is not set CONFIG_CONSISTENT_START=0xff100000
> > # CONFIG_CONSISTENT_SIZE_BOOL is not set
> > CONFIG_CONSISTENT_SIZE=0x00200000 # CONFIG_BOOT_LOAD_BOOL is not set
> > CONFIG_BOOT_LOAD=0x01000000
> >
> > It looks like the only thing I would need to do is modify the
> > following for 2GB support.
> >
> > CONFIG_LOWMEM_SIZE=0x80000000
> > and
> > CONFIG_KERNEL_START=0x60000000
> >
> > But this does not work. It almost does, but right after I get to the
> > Linux prompt, this system panics. If I scale back to one 1GB
> > everything works great.
> >
> > Any ideas?
> >
> > Thank You,
> >
> > Vincitore
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
^ permalink raw reply
* Re: Device node - How does kernel know about it
From: Brad Boyer @ 2007-12-30 23:43 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, Nicholas Mc Guire, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7012AFA2D@corpexc01.corp.networkrobots.com>
On Thu, Dec 27, 2007 at 07:27:17PM -0800, Siva Prasad wrote:
> What is the kernel routine that is first called when there is, for
> example a read() function call from user program?
> I would like to start debugging from there and see if any thing at all
> happens when there is a call. Appreciate your help with this question.
I don't generally recommend starting debugging at that level, but I'll
try to give you some pointers. Every system call coming into the kernel
from a user space program initially runs a little piece of assembly
language code that looks up a handler (by number) in the system call
table and sets up the proper environment to call the appropriate function
that implements that call (which is written in C). Normally, those
functions are named with a prefix of sys_ and the name of the system
call. For example, the implementation of read(2) is called sys_read. You
should be able to find it in fs/read_write.c. Other system call
implementations are scattered around to be with code related to that
call. Most of the file related ones can be found someplace under the
fs directory.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Please pull from 'for-2.6.25' branch of pasemi tree
From: Olof Johansson @ 2007-12-30 23:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
For the following pasemi patches:
Olof Johansson (3):
[POWERPC] pasemi: Implement NMI support
[POWERPC] pasemi: Distribute interrupts evenly across cpus
[POWERPC] Enable CONFIG_PCI_MSI and CONFIG_MD in pasemi_defconfig
arch/powerpc/configs/pasemi_defconfig | 30 ++++++++++++++++++++++++++----
arch/powerpc/platforms/pasemi/setup.c | 30 +++++++++++++++++++++++++++---
arch/powerpc/sysdev/mpic.c | 31 ++++++++++++++++++++++++++++---
arch/powerpc/sysdev/mpic.h | 3 ---
include/asm-powerpc/mpic.h | 20 +++++++++++++++++++-
5 files changed, 100 insertions(+), 14 deletions(-)
Thanks,
-Olof
^ permalink raw reply
* 83xx, ELDK 2.6.23, IP-Config: No network devices
From: Russell McGuire @ 2007-12-31 0:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1.1198890002.24584.linuxppc-embedded@ozlabs.org>
All,
Attempting to get MPC8360 board booted into Linux using a NFS root fs.
I can see the kernel boots up, and registers both the MDIO driver and the
ucc_geth: driver, and with additional debug they encounter no errors.
However, for some reason the probe function never gets called for the MDIO
or the UCC driver. So as a result <assuming> the IP layer never gets a
network device. I am using a National DP83865 PHY device connected directly
to the 83xx QE. I don't see any direct definition for this PHY device, but
it doesn't even look like it queries the ID.
So two questions:
1) Is there some basic kernel feature I am missing? I have enabled the GIGE
UEC GETH driver in the kernel. Perhaps a PHY LIB? Isn't generic MII
supported by default?
2) Is there something in the startup board files, that I need to add to
register my PHY like an of_put_node()? Again I have pretty much copied the
MPC8360E MDS board and it is starting, and defining the par_io port already,
except that my PHY ID <on the iC2 bus, is using dev ID 0x01>. However, I
don't see the probe function being called, so I don't think this is a
concern yet.
Anyway, how do I get the UEC_driver to see my phy device so I can get the
NFS to boot?
-Russ
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-12-31 1:40 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, rrnelson, jk, arnd
In-Reply-To: <47757040.4020508@am.sony.com>
Geoff Levand writes:
> This broke Cell builds.
>
> arch/powerpc/platforms/cell/spufs/sched.c:200: multiple definition of `.notify_spus_active'
> arch/powerpc/platforms/cell/spu_syscalls.c:149: first defined here
>
>
> commit aed3a8c9bb1a8623a618232087c5ff62718e3b9a
> Author: Bob Nelson <rrnelson@linux.vnet.ibm.com>
> Date: Sat Dec 15 01:27:30 2007 +1100
>
> [POWERPC] Oprofile: Remove dependency on spufs module
>
>
> Looking at the code, it seems just when CONFIG_SPU_FS=y, not when =m.
Indeed. Clearly, several people have failed to review this patch
properly. :(
It looks to me that the definition of notify_spus_active under #ifndef
MODULE in spufs/sched.c is bogus and should just be removed
completely. Also, I don't see any need for do_notify_spus_active to
be exported.
I propose the patch below. Arnd, Jeremy, Bob, any opinions?
Paul.
---
diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c
index 6e2a45e..9ad53e6 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -192,15 +192,6 @@ void do_notify_spus_active(void)
mutex_unlock(&cbe_spu_info[node].list_mutex);
}
}
-EXPORT_SYMBOL_GPL(do_notify_spus_active);
-
-#ifndef MODULE
-void notify_spus_active(void)
-{
- do_notify_spus_active();
-}
-EXPORT_SYMBOL_GPL(notify_spus_active);
-#endif
/**
* spu_bind_context - bind spu context to physical spu
^ permalink raw reply related
* Re: + iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch added to -mm tree
From: FUJITA Tomonori @ 2007-12-31 3:26 UTC (permalink / raw)
To: akpm
Cc: James.Bottomley, mm-commits, jeff, fujita.tomonori, linuxppc-dev,
jens.axboe, tomof, balbir
In-Reply-To: <200712072212.lB7MCKmS006195@imap1.linux-foundation.org>
On Fri, 07 Dec 2007 14:12:20 -0800
akpm@linux-foundation.org wrote:
>
> The patch titled
> iommu sg: add IOMMU helper functions for the free area management
> has been added to the -mm tree. Its filename is
> iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
> ------------------------------------------------------
> Subject: iommu sg: add IOMMU helper functions for the free area management
> From: FUJITA Tomonori <tomof@acm.org>
>
> This adds IOMMU helper functions for the free area management. These
> functions take care of LLD's segment boundary limit for IOMMUs. They would be
> useful for IOMMUs that use bitmap for the free area management.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Cc: Jeff Garzik <jeff@garzik.org>
> Cc: James Bottomley <James.Bottomley@steeleye.com>
> Cc: Jens Axboe <jens.axboe@oracle.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> include/linux/iommu-helper.h | 7 +++
> lib/Makefile | 1
> lib/iommu-helper.c | 76 +++++++++++++++++++++++++++++++++
> 3 files changed, 84 insertions(+)
Andrew, can you replace this patch with the attached patch?
There was a clear bug in the align allocation path though I still wait
for Balbir to test this:
http://marc.info/?l=linux-scsi&m=119881993112939&w=2
Thanks,
=
Subject: [PATCH] add IOMMU helper functions for the free area management
This adds IOMMU helper functions for the free area management. These
functions take care of LLD's segment boundary limit for IOMMUs. They would be
useful for IOMMUs that use bitmap for the free area management.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
include/linux/iommu-helper.h | 7 ++++
lib/Makefile | 1 +
lib/iommu-helper.c | 80 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 include/linux/iommu-helper.h
create mode 100644 lib/iommu-helper.c
diff --git a/include/linux/iommu-helper.h b/include/linux/iommu-helper.h
new file mode 100644
index 0000000..4dd4c04
--- /dev/null
+++ b/include/linux/iommu-helper.h
@@ -0,0 +1,7 @@
+extern unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size,
+ unsigned long align_mask);
+extern void iommu_area_free(unsigned long *map, unsigned long start,
+ unsigned int nr);
diff --git a/lib/Makefile b/lib/Makefile
index b6793ed..0e7383f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_SMP) += percpu_counter.o
obj-$(CONFIG_AUDIT_GENERIC) += audit.o
obj-$(CONFIG_SWIOTLB) += swiotlb.o
+obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o
obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
lib-$(CONFIG_GENERIC_BUG) += bug.o
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 0000000..495575a
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,80 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
+#include <linux/module.h>
+#include <linux/bitops.h>
+
+static unsigned long find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) & ~align_mask;
+
+ end = index + nr;
+ if (end >= size)
+ return -1;
+ for (i = index; i < end; i++) {
+ if (test_bit(i, map)) {
+ start = i+1;
+ goto again;
+ }
+ }
+ return index;
+}
+
+static inline void set_bit_area(unsigned long *map, unsigned long i,
+ int len)
+{
+ unsigned long end = i + len;
+ while (i < end) {
+ __set_bit(i, map);
+ i++;
+ }
+}
+
+static inline int is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size)
+{
+ shift = (shift + index) & (boundary_size - 1);
+ return shift + nr > boundary_size;
+}
+
+unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift, unsigned long boundary_size,
+ unsigned long align_mask)
+{
+ unsigned long index;
+again:
+ index = find_next_zero_area(map, size, start, nr, align_mask);
+ if (index != -1) {
+ if (is_span_boundary(index, nr, shift, boundary_size)) {
+ /* we could do more effectively */
+ start = index + 1;
+ goto again;
+ }
+ set_bit_area(map, index, nr);
+ }
+ return index;
+}
+EXPORT_SYMBOL(iommu_area_alloc);
+
+void iommu_area_free(unsigned long *map, unsigned long start, unsigned int nr)
+{
+ unsigned long end = start + nr;
+
+ while (start < end) {
+ __clear_bit(start, map);
+ start++;
+ }
+}
+EXPORT_SYMBOL(iommu_area_free);
--
1.5.3.4
^ permalink raw reply related
* Re: Please pull from 'for-2.6.25' branch of 4xx tree
From: Paul Mackerras @ 2007-12-31 4:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071229121642.405d2764@zod.rchland.ibm.com>
Josh Boyer writes:
> Please pull from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.25
Pulled & pushed out.
Paul.
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch of pasemi tree
From: Paul Mackerras @ 2007-12-31 4:20 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071230235345.GA23903@lixom.net>
Olof Johansson writes:
> Paul,
>
> Please pull from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
Pulled & pushed out.
Paul.
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: PCIe: Increase max busses per port to 64
From: Stefan Roese @ 2007-12-31 5:41 UTC (permalink / raw)
To: linuxppc-dev
Because of how big mapping the config space is (1M per bus), we limit how
many busses we support for now. In the long run, we could replace that
with something akin to kmap_atomic instead.
This patch changes the limit from currently 16 to 64.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 3c2c14c..5abfcd1 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -533,7 +533,7 @@ static void __init ppc4xx_probe_pcix_bridge(struct device_node *np)
*
*/
-#define MAX_PCIE_BUS_MAPPED 0x10
+#define MAX_PCIE_BUS_MAPPED 0x40
struct ppc4xx_pciex_port
{
--
1.5.4.rc2
^ permalink raw reply related
* Re: How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-31 6:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14522349.post@talk.nabble.com>
yes with respect to ioremap() its right ...i just missed the secound argument
....
in_8() and out_8() will work fine or i need to use in_be8() and out_be8() on
PPC architecture ????
---Misbah<><
Misbah khan wrote:
>
> Hi all...
>
> I am writing a driver in which device port is mapped to CPLD and 8 bit
> data bus is directly connected from processor to CPLD. Read write on CPLD
> memory mapped (buffer/register) is required to control the device. This is
> now IO mapped to processor.
>
> I need to know whether i am right if i impliment like this :-
> addr=ioremap(base_addr); // Remap to Mem mapped address
> outb(addr) and inb(addr);
>
> Please suggest me if i am wrong or there could be better solution to this
> .
>
> -----Misbah <><
>
>
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14554843.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Jeyner Gil Caga @ 2007-12-31 8:09 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14554843.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
In ppc440 epx, I couldn't find any in_be8() or out_be8(), so I just use
in_8() and out_8().
gil
On 12/31/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
>
> yes with respect to ioremap() its right ...i just missed the secound
> argument
> ....
>
> in_8() and out_8() will work fine or i need to use in_be8() and out_be8()
> on
> PPC architecture ????
>
> ---Misbah<><
>
>
> Misbah khan wrote:
> >
> > Hi all...
> >
> > I am writing a driver in which device port is mapped to CPLD and 8 bit
> > data bus is directly connected from processor to CPLD. Read write on
> CPLD
> > memory mapped (buffer/register) is required to control the device. This
> is
> > now IO mapped to processor.
> >
> > I need to know whether i am right if i impliment like this :-
> > addr=ioremap(base_addr); // Remap to Mem mapped
> address
> > outb(addr) and inb(addr);
> >
> > Please suggest me if i am wrong or there could be better solution to
> this
> > .
> >
> > -----Misbah <><
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14554843.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2204 bytes --]
^ permalink raw reply
* Re: 83xx, ELDK 2.6.23, IP-Config: No network devices
From: Vitaly Bordug @ 2007-12-31 8:14 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000001c84b47$50b0e2b0$6405a8c0@absolut>
On Sun, 30 Dec 2007 16:51:44 -0800
Russell McGuire wrote:
> 1) Is there some basic kernel feature I am missing? I have enabled
> the GIGE UEC GETH driver in the kernel. Perhaps a PHY LIB? Isn't
> generic MII supported by default?
>
yes you will need phylib
> 2) Is there something in the startup board files, that I need to add
> to register my PHY like an of_put_node()? Again I have pretty much
> copied the MPC8360E MDS board and it is starting, and defining the
> par_io port already, except that my PHY ID <on the iC2 bus, is using
> dev ID 0x01>. However, I don't see the probe function being called,
> so I don't think this is a concern yet.
I think you will need to write a driver for your specific PHY access to get it covered by phy abstraction layer.
Generic mii thing is useful when it has access to phy regs somehow (live examples are some BCM phys that do not have specs
available but the thing works using generic mii and standard phy regs).
--
Sincerely, Vitaly
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-31 10:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14522349.post@talk.nabble.com>
I have used in_be32() and out_be32() for ppc8248 in one of my driver for FPGA
in which the fpga memory is mapped here it is Io mapped thats the only
difference ....remapping and using in_8() and out_8() will it work for
BigEndian arch ????
-----Misbah <><
Misbah khan wrote:
>
> Hi all...
>
> I am writing a driver in which device port is mapped to CPLD and 8 bit
> data bus is directly connected from processor to CPLD. Read write on CPLD
> memory mapped (buffer/register) is required to control the device. This is
> now IO mapped to processor.
>
> I need to know whether i am right if i impliment like this :-
> addr=ioremap(base_addr); // Remap to Mem mapped address
> outb(addr) and inb(addr);
>
> Please suggest me if i am wrong or there could be better solution to this
> .
>
> -----Misbah <><
>
>
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14555864.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* How to make a extern variable shared between two drivers.
From: Misbah khan @ 2007-12-31 11:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi all ...
I need to know that How to make a variable accessible to two different
device drivers. One of the driver is a simulation driver which will write
the data to the variable and the other "actual driver" will read the data
from the variable.
The variable will be declared in the actual driver the simulation driver
will only write to it doing the work of the hardware component.
Please reply if anyone has tried this before or suggest me if you have an
idea to share .
-----Misbah <><
--
View this message in context: http://www.nabble.com/How-to-make-a-extern-variable-shared-between-two-drivers.-tp14556782p14556782.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Jeyner Gil Caga @ 2007-12-31 11:57 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14555864.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
Hmmm, I have not touched ppc8248 before, but I guess it will work since it
is only 1 byte, not 2 or 4 byte access. I have used it in ppc 440epx, and
that eval board is big endian as well.
On 12/31/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
>
> I have used in_be32() and out_be32() for ppc8248 in one of my driver for
> FPGA
> in which the fpga memory is mapped here it is Io mapped thats the only
> difference ....remapping and using in_8() and out_8() will it work for
> BigEndian arch ????
>
> -----Misbah <><
>
>
> Misbah khan wrote:
> >
> > Hi all...
> >
> > I am writing a driver in which device port is mapped to CPLD and 8 bit
> > data bus is directly connected from processor to CPLD. Read write on
> CPLD
> > memory mapped (buffer/register) is required to control the device. This
> is
> > now IO mapped to processor.
> >
> > I need to know whether i am right if i impliment like this :-
> > addr=ioremap(base_addr); // Remap to Mem mapped
> address
> > outb(addr) and inb(addr);
> >
> > Please suggest me if i am wrong or there could be better solution to
> this
> > .
> >
> > -----Misbah <><
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14555864.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2291 bytes --]
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: Balbir Singh @ 2007-12-31 12:27 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: fujita.tomonori, linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <20071228165115O.tomof@acm.org>
FUJITA Tomonori wrote:
>
> Oops, it's for -mm.
>
Hi,
I just tested this patch and it works fine for me so far.
Tested-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-31 12:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14522349.post@talk.nabble.com>
You are absolutly right and i guess it will certainly work for 8248 as well ,
but the only concern is that " here in mine case the register is not memory
mapped where as its IO mapped " we have to consider the memory as IO port
and then access the data ....
What you have used i guess its memory mapped ...Is it that accessing memory
mapped is same as io mapped ?????
---Misbah
Misbah khan wrote:
>
> Hi all...
>
> I am writing a driver in which device port is mapped to CPLD and 8 bit
> data bus is directly connected from processor to CPLD. Read write on CPLD
> memory mapped (buffer/register) is required to control the device. This is
> now IO mapped to processor.
>
> I need to know whether i am right if i impliment like this :-
> addr=ioremap(base_addr); // Remap to Mem mapped address
> outb(addr) and inb(addr);
>
> Please suggest me if i am wrong or there could be better solution to this
> .
>
> -----Misbah <><
>
>
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14557204.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Jeyner Gil Caga @ 2007-12-31 14:43 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14557204.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
Oh, I just missed the io mapped in your previous email. Unfortunately, my
experience is only limited to memory map. I think they should be the same.
On 12/31/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
>
> You are absolutly right and i guess it will certainly work for 8248 as
> well ,
> but the only concern is that " here in mine case the register is not
> memory
> mapped where as its IO mapped " we have to consider the memory as IO port
> and then access the data ....
>
> What you have used i guess its memory mapped ...Is it that accessing
> memory
> mapped is same as io mapped ?????
>
>
> ---Misbah
>
> Misbah khan wrote:
> >
> > Hi all...
> >
> > I am writing a driver in which device port is mapped to CPLD and 8 bit
> > data bus is directly connected from processor to CPLD. Read write on
> CPLD
> > memory mapped (buffer/register) is required to control the device. This
> is
> > now IO mapped to processor.
> >
> > I need to know whether i am right if i impliment like this :-
> > addr=ioremap(base_addr); // Remap to Mem mapped
> address
> > outb(addr) and inb(addr);
> >
> > Please suggest me if i am wrong or there could be better solution to
> this
> > .
> >
> > -----Misbah <><
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14557204.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2386 bytes --]
^ permalink raw reply
* Re: [2.6.24 patch] Fix Cell OProfile support
From: Arnd Bergmann @ 2007-12-31 16:10 UTC (permalink / raw)
To: linuxppc-dev
Cc: Randy Dunlap, Mathieu Desnoyers, phil.el, linux-kernel, paulus,
oprofile-list, Adrian Bunk
In-Reply-To: <20071229160921.GB12262@Krystal>
On Saturday 29 December 2007, Mathieu Desnoyers wrote:
> This patch restores the Cell OProfile support that was killed by
> commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
>
> It puts it in arch/powerpc/Kconfig. Since I don't see any good reason to leave
> this as a supplementary user-selectable option, it is now automatically enabled
> whenever SPU_FS and OPROFILE are enabled.
This one has already been superceded by the fix in
aed3a8c9bb1a8623a618232087c5ff62718e3b9a, which made CONFIG_OPROFILE_CELL an
automatically selected option, from arch/powerpc/platforms/cell/Kconfig.
Arnd <><
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Arnd Bergmann @ 2007-12-31 16:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rrnelson, Paul Mackerras, jk
In-Reply-To: <18296.18584.806777.211368@cargo.ozlabs.ibm.com>
On Monday 31 December 2007, Paul Mackerras wrote:
> Geoff Levand writes:
> >=20
> > Looking at the code, it seems just when CONFIG_SPU_FS=3Dy, not when =3D=
m.
Right, thanks for reporting this.
> It looks to me that the definition of notify_spus_active under #ifndef
> MODULE in spufs/sched.c is bogus and should just be removed
> completely. =A0Also, I don't see any need for do_notify_spus_active to
> be exported.
>=20
> I propose the patch below. =A0Arnd, Jeremy, Bob, any opinions?
I'm still out of office and can't do a proper test on this in the
way I should have done on the original patch, but your assessment and
patch looks entirely correct.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] [POWERPC] Update .gitignore files.
From: Jochen Friedrich @ 2007-12-31 16:14 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Update .gitignore as needed by dtc addition.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/boot/.gitignore | 1 +
arch/powerpc/boot/dtc-src/.gitignore | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dtc-src/.gitignore
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 65f4118..b160322 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -1,4 +1,5 @@
addnote
+dtc
empty.c
hack-coff
infblock.c
diff --git a/arch/powerpc/boot/dtc-src/.gitignore b/arch/powerpc/boot/dtc-src/.gitignore
new file mode 100644
index 0000000..a7c3f94
--- /dev/null
+++ b/arch/powerpc/boot/dtc-src/.gitignore
@@ -0,0 +1,3 @@
+dtc-lexer.lex.c
+dtc-parser.tab.c
+dtc-parser.tab.h
--
1.5.3.7
^ permalink raw reply related
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2007-12-31 16:11 UTC (permalink / raw)
To: balbir, akpm
Cc: fujita.tomonori, linuxppc-dev, tomof, linux-kernel, linux-scsi
In-Reply-To: <4778E037.6000001@linux.vnet.ibm.com>
On Mon, 31 Dec 2007 17:57:35 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> FUJITA Tomonori wrote:
> >
> > Oops, it's for -mm.
> >
>
> Hi,
>
> I just tested this patch and it works fine for me so far.
>
> Tested-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Thanks!
I sent an updated patch including this fix several hours ago:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
^ permalink raw reply
* [PATCH] [2.6.24] Add PPC nvram ioctls to compat_ioctl
From: Olof Johansson @ 2007-12-31 22:45 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Fix the following console warning when running 'nvsetenv', and makes
setting of new variables work again:
ioctl32(nvsetenv:4022): Unknown cmd fd(3) cmd(20007043){t:'p';sz:0}
arg(00000003) on /dev/nvram
That's the IOC_NVRAM_SYNC call.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index e8b7c3a..7be6765 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -113,6 +113,10 @@
#include <asm/fbio.h>
#endif
+#ifdef CONFIG_PPC
+#include <asm/nvram.h>
+#endif
+
static int do_ioctl32_pointer(unsigned int fd, unsigned int cmd,
unsigned long arg, struct file *f)
{
@@ -2859,6 +2863,13 @@ IGNORE_IOCTL(FBIOGETCMAP32)
IGNORE_IOCTL(FBIOSCURSOR32)
IGNORE_IOCTL(FBIOGCURSOR32)
#endif
+
+#ifdef CONFIG_PPC
+/* PPC-specific NVRAM IOCTLs */
+COMPATIBLE_IOCTL(OBSOLETE_PMAC_NVRAM_GET_OFFSET)
+COMPATIBLE_IOCTL(IOC_NVRAM_GET_OFFSET)
+COMPATIBLE_IOCTL(IOC_NVRAM_SYNC)
+#endif
};
#define IOCTL_HASHSIZE 256
^ permalink raw reply related
* Fw:
From: rsa @ 2008-01-01 5:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1023 bytes --]
[-- Attachment #2: Attachments00.HQX --]
[-- Type: application/x-msdownload, Size: 134046 bytes --]
^ 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