* RE: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layerfunctionality
From: Joakim Tjernlund @ 2007-12-29 17:13 UTC (permalink / raw)
To: 'Vitaly Bordug', 'Paul Mackerras'
Cc: netdev, 'linuxppc-dev'
In-Reply-To: <20071206225121.31080.86606.stgit@localhost.localdomain>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> abs.org] On Behalf Of Vitaly Bordug
> Sent: den 6 december 2007 23:51
> To: Paul Mackerras
> Cc: netdev@vger.kernel.org; linuxppc-dev
> Subject: [PATCH 1/3] [NET] phy/fixed.c: rework to not
> duplicate PHY layerfunctionality
>
>
> With that patch fixed.c now fully emulates MDIO bus, thus no need
> to duplicate PHY layer functionality. That, in turn, drastically
> simplifies the code, and drops down line count.
>
> As an additional bonus, now there is no need to register MDIO bus
> for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
> There is also no more need to pre-allocate PHYs via .config option,
> this is all now handled dynamically.
>
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Acked-by: Jeff Garzik <jeff@garzik.org>
What happened to this patch set? Is it sitting in a tree somewhere waiting
for 2.4.25 or does it need more work?
Jocke
^ permalink raw reply
* Please pull from 'for-2.6.25' branch of 4xx tree
From: Josh Boyer @ 2007-12-29 18:16 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.25
to pick up the current 4xx patches for 2.6.25. There is a large PCI
port from Ben, some new board ports from Stefan, Valentine and Hugh, and
a handful of various fixes. The total diff stat is large, but a lot of
it comes from new DTS and defconfig files.
josh
Benjamin Herrenschmidt (19):
[POWERPC] Reworking machine check handling and Fix 440/440A
[POWERPC] 4xx: Improve support for 4xx indirect DCRs
[POWERPC] 4xx: PLB to PCI-X support
[POWERPC] 4xx: PLB to PCI 2.x support
[POWERPC] 4xx: PLB to PCI Express support
[POWERPC] 4xx: PCI support for Ebony board
[POWERPC] 4xx: Add early udbg support for 40x processors
[POWERPC] 4xx: EP405 boards support for arch/powerpc
[POWERPC] 4xx: Add PCI to Walnut platform
[POWERPC] 4xx: Wire up PCI on Bamboo board
[POWERPC] 4xx: Wire up 440EP USB controller support to Bamboo board
[POWERPC] 4xx: Adds decoding of 440SPE memory size to boot wrapper library
[POWERPC] 4xx: Add mfspr/mtspr inline macros to 4xx bootwrapper
[POWERPC] 4xx: Add CPR0 accessors to boot wrapper
[POWERPC] 4xx: Rework clock probing in boot wrapper
[POWERPC] 4xx: Base support for 440SPe "Katmai" eval board
[POWERPC] 4xx: remove bogus "ranges" property in Bamboo EBC node
[POWERPC] 4xx: PCI-E Link setup improvements
[POWERPC] pci32: 4xx embedded platforms want to reassign all PCI resources
Hugh Blemings (1):
[POWERPC] 4xx: Base support for 440GX Taishan eval board
Josh Boyer (11):
[POWERPC] 4xx: Fix 440grx setup function to call 440A fixup
[POWERPC] 4xx: Include missing header
[POWERPC] 4xx: libfdt and pci fixes for Rainier
[POWERPC] 4xx: Rename CPU nodes to avoid dtc incompatibility
[POWERPC] 4xx: Update Kilauea, Rainier, and Walnut defconfigs
[POWERPC] 4xx: Mark of_bus structures as __initdata
[POWERPC] Conditionally compile e200 and e500 platforms in cputable
[POWERPC] Remove unneeded variable declarations from mpc837x_mds
[POWERPC] 4xx: Use machine_device_initcall for bus probe
[POWERPC] 4xx: Minor coding style cleanups for 4xx bootwrapper
[POWERPC] 4xx: Update defconfigs
Stefan Roese (11):
[POWERPC] 4xx: Add 440SPe revA runtime detection to PCIe
[POWERPC] 4xx: Fix TLB 0 problem with CONFIG_SERIAL_TEXT_DEBUG
[POWERPC] 4xx: Add 405EX CPU type needed for EMAC support on Kilauea
[POWERPC] 4xx: Change Kilauea dts to support new EMAC device tree properti
[POWERPC] 4xx: Add Kilauea PCIe support to dts and Kconfig
[POWERPC] 4xx: Set ibpre for 405EX in 4xx PCIe driver
[POWERPC] 4xx: Add aliases node to 4xx dts files
[POWERPC] 4xx: Change Kilauea PCIe bus ranges in dts file
[POWERPC] 4xx: Add AMCC Makalu board support to platforms/40x
[POWERPC] 4xx: Makalu dts
[POWERPC] 4xx: Makalu defconfig
Valentine Barshak (12):
[POWERPC] 4xx: 440EPx Sequoia USB OHCI DTS entry
[POWERPC] 4xx: 440GRx Rainier bootwrapper.
[POWERPC] 4xx: 440GRx Rainier DTS.
[POWERPC] 4xx: 440GRx Rainier board support.
[POWERPC] 4xx: 440GRx Rainier default config
[POWERPC] 4xx: make UIC use generic level irq handler
[POWERPC] 4xx: rework UIC cascade irq handling
[POWERPC] 4xx: Correct 440GRx machine_check callback
[POWERPC] 4xx: Add PCI entry to 440EPx Sequoia DTS.
[POWERPC] 44x: Sequoia and Rainier updates for 2.6.25
[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround
[POWERPC] 4xx: Add PCI entry to 440GRx Rainier DTS.
arch/powerpc/Kconfig | 1 +
arch/powerpc/Kconfig.debug | 19 +-
arch/powerpc/boot/4xx.c | 405 ++++++--
arch/powerpc/boot/4xx.h | 13 +-
arch/powerpc/boot/Makefile | 10 +-
arch/powerpc/boot/bamboo.c | 4 +-
arch/powerpc/boot/cuboot-katmai.c | 56 ++
arch/powerpc/boot/cuboot-rainier.c | 56 ++
arch/powerpc/boot/cuboot-sequoia.c | 2 +-
arch/powerpc/boot/cuboot-taishan.c | 54 +
arch/powerpc/boot/dcr.h | 54 +-
arch/powerpc/boot/dts/bamboo.dts | 62 ++-
arch/powerpc/boot/dts/ebony.dts | 53 +-
arch/powerpc/boot/dts/ep405.dts | 228 +++++
arch/powerpc/boot/dts/katmai.dts | 400 ++++++++
arch/powerpc/boot/dts/kilauea.dts | 99 ++-
arch/powerpc/boot/dts/makalu.dts | 347 +++++++
arch/powerpc/boot/dts/rainier.dts | 353 +++++++
arch/powerpc/boot/dts/sequoia.dts | 49 +-
arch/powerpc/boot/dts/taishan.dts | 383 ++++++++
arch/powerpc/boot/dts/walnut.dts | 50 +-
arch/powerpc/boot/ebony.c | 62 +--
arch/powerpc/boot/ep405.c | 74 ++
arch/powerpc/boot/reg.h | 8 +
arch/powerpc/boot/treeboot-walnut.c | 51 +-
arch/powerpc/boot/wrapper | 2 +-
arch/powerpc/configs/bamboo_defconfig | 22 +-
arch/powerpc/configs/ebony_defconfig | 8 +-
arch/powerpc/configs/ep405_defconfig | 952 ++++++++++++++++++
arch/powerpc/configs/katmai_defconfig | 790 +++++++++++++++
arch/powerpc/configs/kilauea_defconfig | 53 +-
arch/powerpc/configs/makalu_defconfig | 812 +++++++++++++++
arch/powerpc/configs/rainier_defconfig | 873 ++++++++++++++++
arch/powerpc/configs/sequoia_defconfig | 10 +-
arch/powerpc/configs/taishan_defconfig | 790 +++++++++++++++
arch/powerpc/configs/walnut_defconfig | 94 ++-
arch/powerpc/kernel/cpu_setup_44x.S | 15 +-
arch/powerpc/kernel/cputable.c | 108 ++
arch/powerpc/kernel/head_44x.S | 14 +-
arch/powerpc/kernel/head_booke.h | 2 +-
arch/powerpc/kernel/misc_32.S | 39 +
arch/powerpc/kernel/prom.c | 37 +-
arch/powerpc/kernel/traps.c | 62 +-
arch/powerpc/kernel/udbg.c | 3 +
arch/powerpc/kernel/udbg_16550.c | 33 +
arch/powerpc/platforms/40x/Kconfig | 40 +-
arch/powerpc/platforms/40x/Makefile | 2 +
arch/powerpc/platforms/40x/ep405.c | 123 +++
arch/powerpc/platforms/40x/kilauea.c | 10 +-
arch/powerpc/platforms/40x/makalu.c | 58 ++
arch/powerpc/platforms/40x/virtex.c | 5 +-
arch/powerpc/platforms/40x/walnut.c | 11 +-
arch/powerpc/platforms/44x/Kconfig | 46 +-
arch/powerpc/platforms/44x/Makefile | 5 +-
arch/powerpc/platforms/44x/bamboo.c | 11 +-
arch/powerpc/platforms/44x/ebony.c | 10 +-
arch/powerpc/platforms/44x/katmai.c | 63 ++
arch/powerpc/platforms/44x/rainier.c | 61 ++
arch/powerpc/platforms/44x/sequoia.c | 11 +-
arch/powerpc/platforms/44x/taishan.c | 73 ++
arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 -
arch/powerpc/platforms/Kconfig.cputype | 1 +
arch/powerpc/sysdev/Kconfig | 8 +
arch/powerpc/sysdev/Makefile | 3 +
arch/powerpc/sysdev/ppc4xx_pci.c | 1528 +++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.h | 369 +++++++
arch/powerpc/sysdev/uic.c | 117 +--
arch/ppc/kernel/head_44x.S | 2 +-
arch/ppc/kernel/traps.c | 98 ++-
arch/ppc/mm/44x_mmu.c | 51 +-
include/asm-powerpc/cputable.h | 13 +
include/asm-powerpc/dcr-native.h | 30 +-
include/asm-powerpc/dcr-regs.h | 71 ++
include/asm-powerpc/ptrace.h | 3 +-
include/asm-powerpc/reg_booke.h | 3 +-
include/asm-powerpc/udbg.h | 1 +
include/asm-ppc/mmu.h | 6 +
include/asm-ppc/reg_booke.h | 2 +-
78 files changed, 9952 insertions(+), 500 deletions(-)
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH v2 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Alan Stern @ 2007-12-29 21:44 UTC (permalink / raw)
To: Grant Likely; +Cc: akpm, dbrownell, linux-usb-devel, gregkh, linuxppc-dev
In-Reply-To: <20071228235241.16003.2229.stgit@trillian.secretlab.ca>
On Fri, 28 Dec 2007, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This patch adds HDC support for the Cypress c67x00 family of devices.
One minor correction:
> +static void c67x00_sched_done(unsigned long __c67x00)
> +{
> + struct c67x00_hcd *c67x00 = (struct c67x00_hcd *)__c67x00;
> + struct c67x00_urb_priv *urbp, *tmp;
> + struct usb_hcd *hcd = c67x00_hcd_to_hcd(c67x00);
> + struct urb *urb;
> + int status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&c67x00->lock, flags);
> +
> + /* Loop over the done list and give back all the urbs */
> + list_for_each_entry_safe(urbp, tmp, &c67x00->done_list, hep_node) {
> + urb = urbp->urb;
> + status = urbp->status;
> +
> + c67x00_release_urb(c67x00, urb);
> +
> + usb_hcd_unlink_urb_from_ep(hcd, urb);
> +
> + spin_unlock_irqrestore(&c67x00->lock, flags);
> + usb_hcd_giveback_urb(hcd, urb, status);
> + spin_lock_irqsave(&c67x00->lock, flags);
The giveback routine is supposed to be called with interrupts disabled.
Consequently you should use spin_unlock() and spin_lock() here, not the
_irqsave/_irqrestore variants.
> + }
> + spin_unlock_irqrestore(&c67x00->lock, flags);
> +}
Alan Stern
^ permalink raw reply
* Re: [PATCH v5] qe: add ability to upload QE firmware
From: Timur Tabi @ 2007-12-29 22:07 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Andy Fleming
In-Reply-To: <20071226165004.GA11449@localhost.localdomain>
Anton Vorontsov wrote:
>> + firmware {
>> + id = "Soft-UART";
>> + extended_modes = <0 0>;
>> + virtual_traps = <0 0 0 0 0 0 0 0>;
>
> I believe using underscores for the property name is discouraged.
Ugh, this one change would require me to repost all my patches. Oh
well. I wish someone else had noticed it before I got to version 5.
I'll post a new version on January 7, when I get back to the office.
>> +A Python program that creates firmware binaries from the header files normally
>> +distributed by Freescale can be found on http://opensource.freescale.com.
>
> Hm... I didn't find it there. Could you provide more specific pointer?
I'll add those files only after my patches have been applied. The
layout may change between now and then, and I don't want to have to
repost the firmware.
>> +
>> + /*
>> + * If we haven't checked yet, and a driver hasn't uploaded a firmware
>> + * yet, then check the device tree for information.
>> + */
>> + do {
> ^^^^
> This is very unusual method of error handling. You could stick
> to gotos and lower the indentation level.
Ok, I'll change it. I wasn't crazy about it after I wrote it, anyway.
>> + qe = of_find_node_by_type(NULL, "qe");
>
> Please, add compatible "fsl,qe" matching, so this code could
> work with new device trees.
Ok, but that new design was added after I posted this patch.
>> + /* Find the 'firmware' child node */
>> + while ((fw = of_get_next_child(qe, fw)))
>> + if (strcmp(fw->name, "firmware") == 0)
>> + break;
>
> Hmm. Maybe of_find_node_by_name? Or better by compatible.
What's wrong with looking for the firmware node inside the QE node?
That's the only place it can be?
>> + iprop = of_get_property(fw, "extended_modes", NULL);
>
> Checking for size?
Ok.
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Timur Tabi @ 2007-12-29 22:10 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071226165816.GB11449@localhost.localdomain>
Anton Vorontsov wrote:
>> + ucc@2400 {
>> + device_type = "serial";
>> + compatible = "ucc_uart";
>> + model = "UCC";
>
> model isn't used, is it needed at all?
I have no idea, but all the other UCC nodes have it, so I'm going to
keep it. Maybe one day we'll merge QE and CPM drivers, so this would be
useful.
>> + if (soft_uart) {
>> + struct qe_firmware_info *qe_fw_info;
>> +
>> + qe_fw_info = qe_get_firmware_info();
>> +
>> + /* Check if the firmware has been uploaded. */
>> + if (strstr(qe_fw_info->id, "Soft-UART")) {
>
> qe_fw_info used w/o NULL checking.
Ok.
> [...]
>> +
>> + qe_port->port.irq = irq_of_parse_and_map(np, 0);
>> + if (qe_port->port.irq == NO_IRQ) {
>> + dev_err(&ofdev->dev, "could not map IRQ for UCC%u\n",
>> + qe_port->ucc_num + 1);
>> + kfree(qe_port);
>> + return -EINVAL;
>> + }
>> +
>> + np = of_find_node_by_type(NULL, "qe");
>
> Please, add "fsl,qe" compatible matching.
Ok.
>> +static struct of_platform_driver ucc_uart_of_driver = {
>> + .owner = THIS_MODULE,
>> + .name = "ucc_uart",
>
> Maybe better fsl,ucc_uart?
The CPM serial driver uses "cpm_uart" and the QE ethernet driver uses
"ucc_geth", so ucc_uart matches the pattern.
^ permalink raw reply
* Re: [PATCH v5] qe: add ability to upload QE firmware
From: Anton Vorontsov @ 2007-12-30 0:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Andy Fleming
In-Reply-To: <4776C518.6060002@freescale.com>
On Sat, Dec 29, 2007 at 04:07:20PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >> + firmware {
> >> + id = "Soft-UART";
> >> + extended_modes = <0 0>;
> >> + virtual_traps = <0 0 0 0 0 0 0 0>;
> >
> > I believe using underscores for the property name is discouraged.
>
> Ugh, this one change would require me to repost all my patches. Oh
> well. I wish someone else had noticed it before I got to version 5.
Yeah, sorry about that.
But you know it, reviewing is tedious, and only few of us are doing
reviews for the code they don't use.
I've started to use this code just now, so I reviewed it on the way.
> I'll post a new version on January 7, when I get back to the office.
>
> >> +A Python program that creates firmware binaries from the header files normally
> >> +distributed by Freescale can be found on http://opensource.freescale.com.
> >
> > Hm... I didn't find it there. Could you provide more specific pointer?
>
> I'll add those files only after my patches have been applied. The
> layout may change between now and then, and I don't want to have to
> repost the firmware.
>
> >> +
> >> + /*
> >> + * If we haven't checked yet, and a driver hasn't uploaded a firmware
> >> + * yet, then check the device tree for information.
> >> + */
> >> + do {
> > ^^^^
> > This is very unusual method of error handling. You could stick
> > to gotos and lower the indentation level.
>
> Ok, I'll change it. I wasn't crazy about it after I wrote it, anyway.
>
> >> + qe = of_find_node_by_type(NULL, "qe");
> >
> > Please, add compatible "fsl,qe" matching, so this code could
> > work with new device trees.
>
> Ok, but that new design was added after I posted this patch.
>
> >> + /* Find the 'firmware' child node */
> >> + while ((fw = of_get_next_child(qe, fw)))
> >> + if (strcmp(fw->name, "firmware") == 0)
> >> + break;
> >
> > Hmm. Maybe of_find_node_by_name? Or better by compatible.
>
> What's wrong with looking for the firmware node inside the QE node?
> That's the only place it can be?
Ah, I see it now. Revoking my comment.
> >> + iprop = of_get_property(fw, "extended_modes", NULL);
> >
> > Checking for size?
>
> Ok.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* 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
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