* [PATCH 1/4] ppc32: platform_device conversion from OCP
From: Kumar Gala @ 2005-01-18 15:35 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, linuxppc-embedded
System platform_device description, discovery and management:
On most embedded PPC systems we either have a core CPU and chipset
(MPC10x, TSI10x, Marvell, etc.) or a system-on-chip device (4xx, 8xx,
82xx, 85xx, etc.). Some of these sub-archs have been using the On Chip
Peripheral (OCP) driver model. The functionality that OCP provide has
been replaced by the generic driver model and platform_device. Also, some
of these device may exist across a number of architectures (PPC, MIPS,
ARM) such that some information that is shared between the architecture
and driver needs to exist outside of either.
The ppc_sys changes add a standard way for PowerPC systems to describe the
devices and systems that exist in the sub-arch. Additionally, we are able
to discover which system we are and manage which devices are actually
registered and any platform specific fixups that may be needed.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/syslib/Makefile 2005-01-17 22:31:44 -06:00
@@ -92,7 +92,8 @@
obj-$(CONFIG_MPC10X_OPENPIC) += open_pic.o
obj-$(CONFIG_40x) += dcr.o
obj-$(CONFIG_BOOKE) += dcr.o
-obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o
+obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o \
+ ppc_sys.o
ifeq ($(CONFIG_85xx),y)
obj-$(CONFIG_PCI) += indirect_pci.o pci_auto.o
endif
diff -Nru a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/syslib/ppc_sys.c 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,103 @@
+/*
+ * arch/ppc/syslib/ppc_sys.c
+ *
+ * PPC System library functions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <asm/ppc_sys.h>
+
+int (*ppc_sys_device_fixup) (struct platform_device * pdev);
+
+static int ppc_sys_inited;
+
+void __init identify_ppc_sys_by_id(u32 id)
+{
+ unsigned int i = 0;
+ while (1) {
+ if ((ppc_sys_specs[i].mask & id) == ppc_sys_specs[i].value)
+ break;
+ i++;
+ }
+
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
+
+ return;
+}
+
+void __init identify_ppc_sys_by_name(char *name)
+{
+ /* TODO */
+ return;
+}
+
+/* Update all memory resources by paddr, call before platform_device_register */
+void __init
+ppc_sys_fixup_mem_resource(struct platform_device *pdev, phys_addr_t paddr)
+{
+ int i;
+ for (i = 0; i < pdev->num_resources; i++) {
+ struct resource *r = &pdev->resource[i];
+ if ((r->flags & IORESOURCE_MEM) == IORESOURCE_MEM) {
+ r->start += paddr;
+ r->end += paddr;
+ }
+ }
+}
+
+/* Get platform_data pointer out of platform device, call before platform_device_register */
+void *__init ppc_sys_get_pdata(enum ppc_sys_devices dev)
+{
+ return ppc_sys_platform_devices[dev].dev.platform_data;
+}
+
+void ppc_sys_device_remove(enum ppc_sys_devices dev)
+{
+ unsigned int i;
+
+ if (ppc_sys_inited) {
+ platform_device_unregister(&ppc_sys_platform_devices[dev]);
+ } else {
+ if (cur_ppc_sys_spec == NULL)
+ return;
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++)
+ if (cur_ppc_sys_spec->device_list[i] == dev)
+ cur_ppc_sys_spec->device_list[i] = -1;
+ }
+}
+
+static int __init ppc_sys_init(void)
+{
+ unsigned int i, dev_id, ret = 0;
+
+ BUG_ON(cur_ppc_sys_spec == NULL);
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ dev_id = cur_ppc_sys_spec->device_list[i];
+ if (dev_id != -1) {
+ if (ppc_sys_device_fixup != NULL)
+ ppc_sys_device_fixup(&ppc_sys_platform_devices
+ [dev_id]);
+ if (platform_device_register
+ (&ppc_sys_platform_devices[dev_id])) {
+ ret = 1;
+ printk(KERN_ERR
+ "unable to register device %d\n",
+ dev_id);
+ }
+ }
+ }
+
+ ppc_sys_inited = 1;
+ return ret;
+}
+
+subsys_initcall(ppc_sys_init);
diff -Nru a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/asm-ppc/ppc_sys.h 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,65 @@
+/*
+ * include/asm-ppc/ppc_sys.h
+ *
+ * PPC system definitions and library functions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_PPC_SYS_H
+#define __ASM_PPC_SYS_H
+
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/types.h>
+
+#if defined(CONFIG_85xx)
+#include <asm/mpc85xx.h>
+#else
+#error "need definition of ppc_sys_devices"
+#endif
+
+struct ppc_sys_spec {
+ /* PPC sys is matched via (ID & mask) == value, id could be
+ * PVR, SVR, IMMR, * etc. */
+ u32 mask;
+ u32 value;
+ u32 num_devices;
+ char *ppc_sys_name;
+ enum ppc_sys_devices *device_list;
+};
+
+/* describes all specific chips and which devices they have on them */
+extern struct ppc_sys_spec ppc_sys_specs[];
+extern struct ppc_sys_spec *cur_ppc_sys_spec;
+
+/* determine which specific SOC we are */
+extern void identify_ppc_sys_by_id(u32 id) __init;
+extern void identify_ppc_sys_by_name(char *name) __init;
+
+/* describes all devices that may exist in a given family of processors */
+extern struct platform_device ppc_sys_platform_devices[];
+
+/* allow any platform_device fixup to occur before device is registered */
+extern int (*ppc_sys_device_fixup) (struct platform_device * pdev);
+
+/* Update all memory resources by paddr, call before platform_device_register */
+extern void ppc_sys_fixup_mem_resource(struct platform_device *pdev,
+ phys_addr_t paddr) __init;
+
+/* Get platform_data pointer out of platform device, call before platform_device_register */
+extern void *ppc_sys_get_pdata(enum ppc_sys_devices dev) __init;
+
+/* remove a device from the system */
+extern void ppc_sys_device_remove(enum ppc_sys_devices dev);
+
+#endif /* __ASM_PPC_SYS_H */
+#endif /* __KERNEL__ */
diff -Nru a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/linux/fsl_devices.h 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,78 @@
+/*
+ * include/linux/fsl_devices.h
+ *
+ * Definitions for any platform device related flags or structures for
+ * Freescale processor devices
+ *
+ * Maintainer: Kumar Gala (kumar.gala@freescale.com)
+ *
+ * Copyright 2004 Freescale Semiconductor, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifdef __KERNEL__
+#ifndef _FSL_DEVICE_H_
+#define _FSL_DEVICE_H_
+
+#include <linux/types.h>
+
+/*
+ * Some conventions on how we handle peripherals on Freescale chips
+ *
+ * unique device: a platform_device entry in fsl_plat_devs[] plus
+ * associated device information in its platform_data structure.
+ *
+ * A chip is described by a set of unique devices.
+ *
+ * Each sub-arch has its own master list of unique devices and
+ * enumerates them by enum fsl_devices in a sub-arch specific header
+ *
+ * The platform data structure is broken into two parts. The
+ * first is device specific information that help identify any
+ * unique features of a peripheral. The second is any
+ * information that may be defined by the board or how the device
+ * is connected externally of the chip.
+ *
+ * naming conventions:
+ * - platform data structures: <driver>_platform_data
+ * - platform data device flags: FSL_<driver>_DEV_<FLAG>
+ * - platform data board flags: FSL_<driver>_BRD_<FLAG>
+ *
+ */
+
+struct gianfar_platform_data {
+ /* device specific information */
+ u32 device_flags;
+ u32 phy_reg_addr;
+
+ /* board specific information */
+ u32 board_flags;
+ u32 phyid;
+ u32 interruptPHY;
+ u8 mac_addr[6];
+};
+
+/* Flags related to gianfar device features */
+#define FSL_GIANFAR_DEV_HAS_GIGABIT 0x00000001
+#define FSL_GIANFAR_DEV_HAS_COALESCE 0x00000002
+#define FSL_GIANFAR_DEV_HAS_RMON 0x00000004
+#define FSL_GIANFAR_DEV_HAS_MULTI_INTR 0x00000008
+
+/* Flags in gianfar_platform_data */
+#define FSL_GIANFAR_BRD_HAS_PHY_INTR 0x00000001 /* if not set use a timer */
+
+struct fsl_i2c_platform_data {
+ /* device specific information */
+ u32 device_flags;
+};
+
+/* Flags related to I2C device features */
+#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
+#define FSL_I2C_DEV_CLOCK_5200 0x00000002
+
+#endif /* _FSL_DEVICE_H_ */
+#endif /* __KERNEL__ */
^ permalink raw reply
* [PATCH 0/4] ppc32: platform_device conversion from OCP
From: Kumar Gala @ 2005-01-18 15:34 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, linuxppc-embedded
Linus,
I would like to try to get these patches into 2.6.11. They add
infrastructure for all ppc sub-archs to use platform_devices instead of
OCP. Additionally, I've converted the 85xx sub-arch and gianfar enet
driver (used by 85xx) over to using platform_device and the new
infrastructure.
The sooner these get in the easier it will be to convert the other
sub-archs and drivers to platform_device and remove OCP.
- kumar
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-18 19:43 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050118190848.GM28724@smtp.west.cox.net>
Tom Rini wrote:
>On Tue, Jan 18, 2005 at 11:58:25AM -0700, Mark A. Greer wrote:
>
>
>>Tom Rini wrote:
>>
>>
>>
>>>I think one of us wasn't clear. I'm not arguing for nuking
>>>ppc_md.{get,set}_rtc_time(), I'm arguing for nuking
>>>get_rtc_time()/set_rtc_time() inlines from <asm-ppc/rtc.h> (which are
>>>used by drivers/char/genrtc.c) in favor of todc_time et al providing the
>>>functions for genrtc. So all of the other places we use
>>>ppc_md.{get,set}_rtc_time() are unchanged.
>>>
>>>
>>Ahh. Okay, that's good but it should be done in drivers/rtc or
>>something like and not just another arch specific solution.
>>
>>
>
>It's not an arch specific solution today.
>
Okay, I see what you mean and yes moving that up (or something
equivalent) would be a good idea.
That's not what my patch is about though. My patch is just so I can
provide a generic solution with what is there today. Its not
redesigning anything, its just getting asm-ppc/rtc.h out of the way so I
can make my own, generic get_rtc_time(), etc.
> It's just that no one that's
>written an rtc chip library (*cough* todc_time.c *cough*)
>
Heh!
> has placed one
>in drivers/char/ and let the chips (or the file) be selected. genrtc.c
>already says "someone else tell me how to get the time". I kinda sorta
>think arch/arm/common/rtctime.c does too, except it has hooks for alarm.
>
Yeah, its probably time for a better solution to what's there today...
Maybe I can get to it but it won't be for a while.
Mark
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-18 19:33 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050118190514.GL28724@smtp.west.cox.net>
Tom Rini wrote:
>On Tue, Jan 18, 2005 at 11:55:54AM -0700, Mark A. Greer wrote:
>
>
>>Tom Rini wrote:
>>
>>
>[snip]
>
>
>>>>Is there a better way to do this?
>>>>
>>>>
>>>>
>>>>
>>>How about we try borrowing the MIPS abstraction and force todc_time,
>>>pmac_time (any others?) to directly define (and EXPORT_SYMBOL)
>>>get_rtc_time / set_rtc_time / etc.
>>>
>>>
>>>
>>Yep, MIPS has a solution...and so does ARM...and so does PPC. This is
>>sort of my point.
>>
>>
>
>And my point was to use someone elses solution, 'cuz that's how we go
>from N to N-1 to 1 :)
>
If effort is going to be put into this then why not just go from N
directly to 1? BTW, I am not volunteering. ;)
>
>
>
>>If we really want to do it right then someone needs to architect a
>>generic solution. What I have done is generic but does not handle the
>>case that Geert mentioned when you have one kernel binary and several
>>possible rtc chips. In the meantime, what I have done works fine for
>>all but that case.
>>
>>
>
>I guess there's two points:
>- How does your solution differ from what MIPS does, and probably ARM
> does of saying the backend (todc_time, i2c-foo) provides
> get_rtc_time/set_rtc_time?
>
First, I want to make sure we all on the same page. There are really
two issues being discussed and I think we're all swinging back and forth
between the two.
Issue 1) - My patch:
I had to write some support for an ST m41t00 rtc w/ an i2c interface. I
could have made it ppc only or generic with the same amount of effort so
I chose the generic one. The gereric one I chose was to use the code in
genrtc and interface directly to the bottom of that code b/c that's
where things become arch-specific. However, that is where I collided
with asm-ppc/rtc.h, hence the patch.
What I did is generic because genrtc.c is generic, the rtc "driver" is
generic, and you can plug in any generic i2c algo/adapter driver
underneath the entire thing.
Issue 2) - What should the *real* rtc architecture be?
RMK's solution may be fine, I'd have to look. I think a discussion like
this is good but I know I don't have the time right now to do it.
This is the one I think you, Tom, are talking about. That's good but
just understand that my patch has nothing to do with a generic solution
for all rtc's. I'm just trying to get this one to work (issue 1).
>- I horribly briefly talked with rmk about this a long time ago, and I
> think he has the generic solution, siting in arch/arm/common/rtctime.c
> (sure it would need to be moved to drivers/char/something, but..).
>
Yep, if it isn't in the right place, it doesn't help (for now anyway).
>- I lied, #3 how does ARM, which I think lets you select multiple
> boards, and thus probably end up with multiple rtc chip choices, deal
> with it.
>
Yep, ARM has a reasonable solution but its ARM only and I'm not trying
to rewrite anything at this point (see above).
Mark
^ permalink raw reply
* RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 19:08 UTC (permalink / raw)
To: 'John W. Linville'
Cc: 'Steven Blakeslee',
'linuxppc-embedded@ozlabs.org'
My board is using:
bd->bi_intfreq = 50000000;
bd->bi_busfreq = 50000000;
While RPX-Lite is using
bd->bi_intfreq = 48000000;
bd->bi_busfreq = 48000000;
Is this what makes RPX-Lite work and my (MPC 880) not ?
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, January 18, 2005 1:53 PM
To: 'John W. Linville'
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
The "one, I am using" from my previous e-mail relates to 2.6.10-rc3
My processor is MPC880.
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, January 18, 2005 1:19 PM
To: 'John W. Linville'
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
>Aren't there still generic problems w/ 8xx and 2.6.x?
Allegedly - yes (with memory initialization) but ...
both Tom Rini and Steve Blakeslee were able to boot their
RPXLite Variant of 8xx on 2.6.10-rc3 (the one I am using)
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Tuesday, January 18, 2005 1:11 PM
To: Povolotsky, Alexander
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'
Subject: Re: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
On Tue, Jan 18, 2005 at 10:45:53AM -0500, Povolotsky, Alexander wrote:
> Forgot to mention - this board boots (and works) well with Linux 2.4.26
Aren't there still generic problems w/ 8xx and 2.6.x?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-18 19:08 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <41ED5C51.8020809@mvista.com>
On Tue, Jan 18, 2005 at 11:58:25AM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
>
> >On Tue, Jan 18, 2005 at 11:25:33AM -0500, Dan Malek wrote:
> >
> >
> >>On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
> >>
> >>
> >>
> >>>On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
> >>>
> >>>
> >>>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
> >>>>interfaces:
> >>>>1) They are called before the i2c driver is initialized and even
> >>>>loaded
> >>>>if its a module.
> >>>>
> >>>>
> >>There are three reasons. You don't want to use an I2c rtc clock at
> >>all in these functions because they get can get called from the
> >>clock interrupt to update the time in the rtc. If it does happen to
> >>work,
> >>it creates long latencies in the timer interrupt. If the i2c requires
> >>an
> >>interrupt, they system will crash or hang.
> >>
> >>
> >
> >I think one of us wasn't clear. I'm not arguing for nuking
> >ppc_md.{get,set}_rtc_time(), I'm arguing for nuking
> >get_rtc_time()/set_rtc_time() inlines from <asm-ppc/rtc.h> (which are
> >used by drivers/char/genrtc.c) in favor of todc_time et al providing the
> >functions for genrtc. So all of the other places we use
> >ppc_md.{get,set}_rtc_time() are unchanged.
>
> Ahh. Okay, that's good but it should be done in drivers/rtc or
> something like and not just another arch specific solution.
It's not an arch specific solution today. It's just that no one that's
written an rtc chip library (*cough* todc_time.c *cough*) has placed one
in drivers/char/ and let the chips (or the file) be selected. genrtc.c
already says "someone else tell me how to get the time". I kinda sorta
think arch/arm/common/rtctime.c does too, except it has hooks for alarm.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-18 19:05 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <41ED5BBA.2090808@mvista.com>
On Tue, Jan 18, 2005 at 11:55:54AM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
[snip]
> >>Is there a better way to do this?
> >>
> >>
> >
> >How about we try borrowing the MIPS abstraction and force todc_time,
> >pmac_time (any others?) to directly define (and EXPORT_SYMBOL)
> >get_rtc_time / set_rtc_time / etc.
> >
>
> Yep, MIPS has a solution...and so does ARM...and so does PPC. This is
> sort of my point.
And my point was to use someone elses solution, 'cuz that's how we go
from N to N-1 to 1 :)
> If we really want to do it right then someone needs to architect a
> generic solution. What I have done is generic but does not handle the
> case that Geert mentioned when you have one kernel binary and several
> possible rtc chips. In the meantime, what I have done works fine for
> all but that case.
I guess there's two points:
- How does your solution differ from what MIPS does, and probably ARM
does of saying the backend (todc_time, i2c-foo) provides
get_rtc_time/set_rtc_time?
- I horribly briefly talked with rmk about this a long time ago, and I
think he has the generic solution, siting in arch/arm/common/rtctime.c
(sure it would need to be moved to drivers/char/something, but..).
- I lied, #3 how does ARM, which I think lets you select multiple
boards, and thus probably end up with multiple rtc chip choices, deal
with it.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Eugene Surovegin @ 2005-01-18 19:01 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Linux/PPC Development, Geert Uytterhoeven
In-Reply-To: <41ED5832.2040602@mvista.com>
On Tue, Jan 18, 2005 at 11:40:50AM -0700, Mark A. Greer wrote:
> However, it does rely on a startup script to do a 'hwclock
> --hctosys' which happen after driver initialization. From what I can
> tell sysvinit used to do the hwclock but doesn't anymore so you need a
> script. The mvl userland has a startup script that does this; others
> probably do too. Note that using a startup script to do a hwclock is
> pretty standard AFAICT.
You can always call do_settimeofday from your i2c driver
initialization. No scripts will be required and system behavior will
be similar to the case when ppc_md.get_rtc_time is called during init
to get correct time from RTC.
--
Eugene
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Eugene Surovegin @ 2005-01-18 18:54 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <93780AB0-696D-11D9-81BE-003065F9B7DC@embeddededge.com>
On Tue, Jan 18, 2005 at 11:25:33AM -0500, Dan Malek wrote:
> There are three reasons. You don't want to use an I2c rtc clock at
> all in these functions because they get can get called from the
> clock interrupt to update the time in the rtc. If it does happen to
> work,
> it creates long latencies in the timer interrupt. If the i2c requires
> an
> interrupt, they system will crash or hang.
>
> A system using an I2C RTC should find some way to access the
> clock from application space as a standard I2C device and manage
> time/clock from the application, not from the kernel.
Well, it was discussed numerous times before with solutions how to use
i2c based RTC as well.
I use i2c RTC which requires interrupt and guess what, my kernel
doesn't crash when timer_interrupt calls ppc_md.set_rtc_time.
It's just a matter of writing correct i2c RTC driver.
Dan, please, stop spreading "i2c-RTC" FUD :).
--
Eugene
^ permalink raw reply
* [PATCH 3/4] ppc32: platform_device conversion from OCP
From: Kumar Gala @ 2005-01-18 15:35 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, linuxppc-embedded
Convert MPC8540 ADS, MPC8560 ADS, MPC8555 CDS and SBC8560 reference boards
from using OCP to platform_device.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-17 22:31:44 -06:00
@@ -32,6 +32,7 @@
#include <linux/serial_core.h>
#include <linux/initrd.h>
#include <linux/module.h>
+#include <linux/fsl_devices.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -48,50 +49,11 @@
#include <asm/irq.h>
#include <asm/immap_85xx.h>
#include <asm/kgdb.h>
-#include <asm/ocp.h>
+#include <asm/ppc_sys.h>
#include <mm/mmu_decl.h>
-#include <syslib/ppc85xx_common.h>
#include <syslib/ppc85xx_setup.h>
-struct ocp_gfar_data mpc85xx_tsec1_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
- .interruptError = MPC85xx_IRQ_TSEC1_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC1_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
- | GFAR_HAS_RMON
- | GFAR_HAS_PHY_INTR | GFAR_HAS_COALESCE),
- .phyid = 0,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_tsec2_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC2_TX,
- .interruptError = MPC85xx_IRQ_TSEC2_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC2_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
- | GFAR_HAS_RMON
- | GFAR_HAS_PHY_INTR | GFAR_HAS_COALESCE),
- .phyid = 1,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_fec_def = {
- .interruptTransmit = MPC85xx_IRQ_FEC,
- .interruptError = MPC85xx_IRQ_FEC,
- .interruptReceive = MPC85xx_IRQ_FEC,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = 0,
- .phyid = 3,
- .phyregidx = 0,
-};
-
-struct ocp_fs_i2c_data mpc85xx_i2c1_def = {
- .flags = FS_I2C_SEPARATE_DFSRR,
-};
-
/* ************************************************************************
*
* Setup the architecture
@@ -100,10 +62,9 @@
static void __init
mpc8540ads_setup_arch(void)
{
- struct ocp_def *def;
- struct ocp_gfar_data *einfo;
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
+ struct gianfar_platform_data *pdata;
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -130,23 +91,30 @@
invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
#endif
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 0);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enetaddr, 6);
- }
-
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 1);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet1addr, 6);
- }
-
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 2);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet2addr, 6);
- }
+ /* setup the board related information for the enet controllers */
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 0;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 1;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_FEC);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 3;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet2addr, 6);
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
@@ -158,8 +126,6 @@
#else
ROOT_DEV = Root_HDA1;
#endif
-
- ocp_for_each_device(mpc85xx_update_paddr_ocp, &(binfo->bi_immr_base));
}
/* ************************************************************************ */
@@ -205,6 +171,8 @@
*(char *) (r7 + KERNELBASE) = 0;
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+
+ identify_ppc_sys_by_id(mfspr(SVR));
/* setup the PowerPC module struct */
ppc_md.setup_arch = mpc8540ads_setup_arch;
diff -Nru a/arch/ppc/platforms/85xx/mpc8555_cds.h b/arch/ppc/platforms/85xx/mpc8555_cds.h
--- a/arch/ppc/platforms/85xx/mpc8555_cds.h 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8555_cds.h 2005-01-17 22:31:44 -06:00
@@ -18,7 +18,7 @@
#define __MACH_MPC8555CDS_H__
#include <linux/config.h>
-#include <linux/serial.h>
+#include <syslib/ppc85xx_setup.h>
#include <platforms/85xx/mpc85xx_cds_common.h>
#define CPM_MAP_ADDR (CCSRBAR + MPC85xx_CPM_OFFSET)
diff -Nru a/arch/ppc/platforms/85xx/mpc8560_ads.c b/arch/ppc/platforms/85xx/mpc8560_ads.c
--- a/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-01-17 22:31:44 -06:00
@@ -32,6 +32,7 @@
#include <linux/serial_core.h>
#include <linux/initrd.h>
#include <linux/module.h>
+#include <linux/fsl_devices.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -48,7 +49,7 @@
#include <asm/irq.h>
#include <asm/immap_85xx.h>
#include <asm/kgdb.h>
-#include <asm/ocp.h>
+#include <asm/ppc_sys.h>
#include <asm/cpm2.h>
#include <mm/mmu_decl.h>
@@ -58,34 +59,6 @@
extern void cpm2_reset(void);
-struct ocp_gfar_data mpc85xx_tsec1_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
- .interruptError = MPC85xx_IRQ_TSEC1_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC1_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
- | GFAR_HAS_RMON | GFAR_HAS_COALESCE
- | GFAR_HAS_PHY_INTR),
- .phyid = 0,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_tsec2_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC2_TX,
- .interruptError = MPC85xx_IRQ_TSEC2_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC2_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
- | GFAR_HAS_RMON | GFAR_HAS_COALESCE
- | GFAR_HAS_PHY_INTR),
- .phyid = 1,
- .phyregidx = 0,
-};
-
-struct ocp_fs_i2c_data mpc85xx_i2c1_def = {
- .flags = FS_I2C_SEPARATE_DFSRR,
-};
-
/* ************************************************************************
*
* Setup the architecture
@@ -95,11 +68,10 @@
static void __init
mpc8560ads_setup_arch(void)
{
- struct ocp_def *def;
- struct ocp_gfar_data *einfo;
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
-
+ struct gianfar_platform_data *pdata;
+
cpm2_reset();
/* get the core frequency */
@@ -117,17 +89,22 @@
mpc85xx_setup_hose();
#endif
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 0);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enetaddr, 6);
- }
-
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 1);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet1addr, 6);
- }
+ /* setup the board related information for the enet controllers */
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 0;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 1;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
@@ -139,8 +116,6 @@
#else
ROOT_DEV = Root_HDA1;
#endif
-
- ocp_for_each_device(mpc85xx_update_paddr_ocp, &(binfo->bi_immr_base));
}
static irqreturn_t cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
@@ -221,6 +196,8 @@
*(char *) (r7 + KERNELBASE) = 0;
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+
+ identify_ppc_sys_by_id(mfspr(SVR));
/* setup the PowerPC module struct */
ppc_md.setup_arch = mpc8560ads_setup_arch;
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-01-17 22:31:44 -06:00
@@ -43,7 +43,6 @@
#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <asm/immap_85xx.h>
-#include <asm/ocp.h>
#include <mm/mmu_decl.h>
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-01-17 22:31:44 -06:00
@@ -32,6 +32,7 @@
#include <linux/initrd.h>
#include <linux/tty.h>
#include <linux/serial_core.h>
+#include <linux/fsl_devices.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -48,7 +49,7 @@
#include <asm/irq.h>
#include <asm/immap_85xx.h>
#include <asm/immap_cpm2.h>
-#include <asm/ocp.h>
+#include <asm/ppc_sys.h>
#include <asm/kgdb.h>
#include <mm/mmu_decl.h>
@@ -129,32 +130,6 @@
#endif
};
-struct ocp_gfar_data mpc85xx_tsec1_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
- .interruptError = MPC85xx_IRQ_TSEC1_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC1_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR |
- GFAR_HAS_PHY_INTR),
- .phyid = 0,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_tsec2_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC2_TX,
- .interruptError = MPC85xx_IRQ_TSEC2_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC2_RX,
- .interruptPHY = MPC85xx_IRQ_EXT5,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR |
- GFAR_HAS_PHY_INTR),
- .phyid = 1,
- .phyregidx = 0,
-};
-
-struct ocp_fs_i2c_data mpc85xx_i2c1_def = {
- .flags = FS_I2C_SEPARATE_DFSRR,
-};
-
/* ************************************************************************ */
int
mpc85xx_cds_show_cpuinfo(struct seq_file *m)
@@ -335,11 +310,10 @@
static void __init
mpc85xx_cds_setup_arch(void)
{
- struct ocp_def *def;
- struct ocp_gfar_data *einfo;
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
-
+ struct gianfar_platform_data *pdata;
+
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -372,17 +346,23 @@
invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
#endif
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 0);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enetaddr, 6);
- }
+ /* setup the board related information for the enet controllers */
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 0;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+ pdata->phyid = 1;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 1);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet1addr, 6);
- }
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
@@ -394,8 +374,6 @@
#else
ROOT_DEV = Root_HDA1;
#endif
-
- ocp_for_each_device(mpc85xx_update_paddr_ocp, &(binfo->bi_immr_base));
}
/* ************************************************************************ */
@@ -443,6 +421,8 @@
*(char *) (r7 + KERNELBASE) = 0;
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+
+ identify_ppc_sys_by_id(mfspr(SVR));
/* setup the PowerPC module struct */
ppc_md.setup_arch = mpc85xx_cds_setup_arch;
diff -Nru a/arch/ppc/platforms/85xx/sbc8560.c b/arch/ppc/platforms/85xx/sbc8560.c
--- a/arch/ppc/platforms/85xx/sbc8560.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/sbc8560.c 2005-01-17 22:31:44 -06:00
@@ -32,6 +32,7 @@
#include <linux/serial_core.h>
#include <linux/initrd.h>
#include <linux/module.h>
+#include <linux/fsl_devices.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -48,37 +49,12 @@
#include <asm/irq.h>
#include <asm/immap_85xx.h>
#include <asm/kgdb.h>
-#include <asm/ocp.h>
+#include <asm/ppc_sys.h>
#include <mm/mmu_decl.h>
#include <syslib/ppc85xx_common.h>
#include <syslib/ppc85xx_setup.h>
-struct ocp_gfar_data mpc85xx_tsec1_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
- .interruptError = MPC85xx_IRQ_TSEC1_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC1_RX,
- .interruptPHY = MPC85xx_IRQ_EXT6,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR | GFAR_HAS_PHY_INTR),
- .phyid = 25,
- .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_tsec2_def = {
- .interruptTransmit = MPC85xx_IRQ_TSEC2_TX,
- .interruptError = MPC85xx_IRQ_TSEC2_ERROR,
- .interruptReceive = MPC85xx_IRQ_TSEC2_RX,
- .interruptPHY = MPC85xx_IRQ_EXT7,
- .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR | GFAR_HAS_PHY_INTR),
- .phyid = 26,
- .phyregidx = 0,
-};
-
-struct ocp_fs_i2c_data mpc85xx_i2c1_def = {
- .flags = FS_I2C_SEPARATE_DFSRR,
-};
-
-
#ifdef CONFIG_SERIAL_8250
static void __init
sbc8560_early_serial_map(void)
@@ -125,10 +101,9 @@
static void __init
sbc8560_setup_arch(void)
{
- struct ocp_def *def;
- struct ocp_gfar_data *einfo;
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
+ struct gianfar_platform_data *pdata;
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -153,18 +128,22 @@
invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
#endif
- /* Set up MAC addresses for the Ethernet devices */
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 0);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enetaddr, 6);
- }
-
- def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 1);
- if (def) {
- einfo = (struct ocp_gfar_data *) def->additions;
- memcpy(einfo->mac_addr, binfo->bi_enet1addr, 6);
- }
+ /* setup the board related information for the enet controllers */
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT6;
+ pdata->phyid = 25;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
+
+ pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
+ pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+ pdata->interruptPHY = MPC85xx_IRQ_EXT7;
+ pdata->phyid = 26;
+ /* fixup phy address */
+ pdata->phy_reg_addr += binfo->bi_immr_base;
+ memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
@@ -176,8 +155,6 @@
#else
ROOT_DEV = Root_HDA1;
#endif
-
- ocp_for_each_device(mpc85xx_update_paddr_ocp, &(binfo->bi_immr_base));
}
/* ************************************************************************ */
@@ -220,6 +197,8 @@
*(char *) (r7 + KERNELBASE) = 0;
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+
+ identify_ppc_sys_by_id(mfspr(SVR));
/* setup the PowerPC module struct */
ppc_md.setup_arch = sbc8560_setup_arch;
diff -Nru a/arch/ppc/platforms/85xx/sbc85xx.c b/arch/ppc/platforms/85xx/sbc85xx.c
--- a/arch/ppc/platforms/85xx/sbc85xx.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/sbc85xx.c 2005-01-17 22:31:44 -06:00
@@ -42,7 +42,6 @@
#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <asm/immap_85xx.h>
-#include <asm/ocp.h>
#include <mm/mmu_decl.h>
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-18 18:58 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050118181330.GJ28724@smtp.west.cox.net>
Tom Rini wrote:
>On Tue, Jan 18, 2005 at 11:25:33AM -0500, Dan Malek wrote:
>
>
>>On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
>>
>>
>>
>>>On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>>>
>>>
>>>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
>>>>interfaces:
>>>>1) They are called before the i2c driver is initialized and even
>>>>loaded
>>>>if its a module.
>>>>
>>>>
>>There are three reasons. You don't want to use an I2c rtc clock at
>>all in these functions because they get can get called from the
>>clock interrupt to update the time in the rtc. If it does happen to
>>work,
>>it creates long latencies in the timer interrupt. If the i2c requires
>>an
>>interrupt, they system will crash or hang.
>>
>>
>
>I think one of us wasn't clear. I'm not arguing for nuking
>ppc_md.{get,set}_rtc_time(), I'm arguing for nuking
>get_rtc_time()/set_rtc_time() inlines from <asm-ppc/rtc.h> (which are
>used by drivers/char/genrtc.c) in favor of todc_time et al providing the
>functions for genrtc. So all of the other places we use
>ppc_md.{get,set}_rtc_time() are unchanged.
>
>
Ahh. Okay, that's good but it should be done in drivers/rtc or
something like and not just another arch specific solution. I want to
stress again that rtc chips typically have no care in the world what
processor happens to be stuck on the board that they are also stuck on.
There is no reason our software should either.
Mark
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 18:52 UTC (permalink / raw)
To: 'John W. Linville'
Cc: 'Steven Blakeslee',
'linuxppc-embedded@ozlabs.org'
The "one, I am using" from my previous e-mail relates to 2.6.10-rc3
My processor is MPC880.
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, January 18, 2005 1:19 PM
To: 'John W. Linville'
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
>Aren't there still generic problems w/ 8xx and 2.6.x?
Allegedly - yes (with memory initialization) but ...
both Tom Rini and Steve Blakeslee were able to boot their
RPXLite Variant of 8xx on 2.6.10-rc3 (the one I am using)
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Tuesday, January 18, 2005 1:11 PM
To: Povolotsky, Alexander
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'
Subject: Re: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
On Tue, Jan 18, 2005 at 10:45:53AM -0500, Povolotsky, Alexander wrote:
> Forgot to mention - this board boots (and works) well with Linux 2.4.26
Aren't there still generic problems w/ 8xx and 2.6.x?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-18 18:55 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050118161515.GI28724@smtp.west.cox.net>
Tom Rini wrote:
>On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>
>
>
>><snip>
>>
>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al. interfaces:
>>1) They are called before the i2c driver is initialized and even loaded
>>if its a module.
>>
>>
>
>But they check if it's set, so they can be assigned later and this is
>OK.
>
But looking at ppc_md.<anything> automatically makes it ppc only.
Pretty much any of the rtc chips that we use on ppc platforms could
appear on almost any other platform with a different processor
architecture. So the question is, why do we keep adding ppc-only
support for rtc chips? Why are we not putting our effort into making
code that works on all architectures? Its easy enough to do...
>>2) Its ppc-specific. Implementing get_rtc_time() et. al. directly makes
>>it generic across all architectures.
>>
>>
>
>Guessing, this is for a marvell chipset that's found on MIPS too.
>
That's an example but like I said above rtc chips are not tied to any
particular processor architecture.
>>Is there a better way to do this?
>>
>>
>
>How about we try borrowing the MIPS abstraction and force todc_time,
>pmac_time (any others?) to directly define (and EXPORT_SYMBOL)
>get_rtc_time / set_rtc_time / etc.
>
Yep, MIPS has a solution...and so does ARM...and so does PPC. This is
sort of my point.
If we really want to do it right then someone needs to architect a
generic solution. What I have done is generic but does not handle the
case that Geert mentioned when you have one kernel binary and several
possible rtc chips. In the meantime, what I have done works fine for
all but that case.
Mark
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-18 18:40 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.GSO.4.61.0501181017110.20681@waterleaf.sonytel.be>
Geert Uytterhoeven wrote:
>On Mon, 17 Jan 2005, Mark A. Greer wrote:
>
>
>><snip>
>>
>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al. interfaces:
>>1) They are called before the i2c driver is initialized and even loaded if its
>>a module.
>>
>>
>
>How is this solved by your patch if genrtc is builtin?
>
It solved because the rtc interface isn't called until you do an hwclock
presumably in a startup script.
> How is your solution
>different from setting ppc_md.get_rtc_time to your get_rtc_time routine?
>
It arch independent which was the whole motivation for doing it this
way. However, it does rely on a startup script to do a 'hwclock
--hctosys' which happen after driver initialization. From what I can
tell sysvinit used to do the hwclock but doesn't anymore so you need a
script. The mvl userland has a startup script that does this; others
probably do too. Note that using a startup script to do a hwclock is
pretty standard AFAICT.
>>2) Its ppc-specific. Implementing get_rtc_time() et. al. directly makes it
>>generic across all architectures.
>>
>>
>
>... but prevents you from building a kernel that supports both normal RTCs and
>your i2c RTC.
>
Well, yes but you aren't going to be able to do this and be
arch-agnostic. If you don't care about running on anything but ppc then
you can to it the way i2c rtc's have been done before and either kludge
into the i2c driver during early startup or setup ppc_md.get_rtc_time()
once the i2c/rtc driver(s) are initialized. This patch will not
interfere with that unless you deliberately set that option.
I think the real question you should be ask is are the
ppc_md.get_rtc_time() et. al. calls really necessary? Or to put it
another way, should we be grilling the people who are submitting
ppc-only solutions and not the ones submitting generic solutions? :)
Mark
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-18 18:33 UTC (permalink / raw)
To: Tolunay Orkun; +Cc: linuxppc-dev
In-Reply-To: <41ED49E2.5050401@orkun.us>
On Tue, Jan 18, 2005 at 11:39:46AM -0600, Tolunay Orkun wrote:
> Dan Malek wrote:
> >
> >On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
> >
> >>On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
> >
> >
> >>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
> >>>interfaces:
> >>>1) They are called before the i2c driver is initialized and even loaded
> >>>if its a module.
> >
> >
> >There are three reasons. You don't want to use an I2c rtc clock at
> >all in these functions because they get can get called from the
> >clock interrupt to update the time in the rtc. If it does happen to work,
> >it creates long latencies in the timer interrupt. If the i2c requires an
> >interrupt, they system will crash or hang.
> >
> >A system using an I2C RTC should find some way to access the
> >clock from application space as a standard I2C device and manage
> >time/clock from the application, not from the kernel.
>
> This is exactly what I've done for our PPC405GP based Linux port
> (2.4.25). I've written a clone of hwclock utility using /dev/i2c0 to
> access Dallas RTC chip with I2C interface. I setthe system clock from
> RTC within /etc/rcS (Busybox). It is less than perfect as early logs
> have the date wrong but it was the direction of least resistance.
>
> Still, I think there should be a better standardized RTC interface to
> help deal with I2C/SMBus based RTC chips.
There kind of is now, arch/arm/common/rtctime.c (thought of for I2C RTCs
and has alarm support).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 18:18 UTC (permalink / raw)
To: 'John W. Linville'
Cc: 'Steven Blakeslee',
'linuxppc-embedded@ozlabs.org'
>Aren't there still generic problems w/ 8xx and 2.6.x?
Allegedly - yes (with memory initialization) but ...
both Tom Rini and Steve Blakeslee both were able to boot their
RPXLite Variant of 8xx on 2.6.10-rc3 (the one I am using)
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Tuesday, January 18, 2005 1:11 PM
To: Povolotsky, Alexander
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'
Subject: Re: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
On Tue, Jan 18, 2005 at 10:45:53AM -0500, Povolotsky, Alexander wrote:
> Forgot to mention - this board boots (and works) well with Linux 2.4.26
with
Aren't there still generic problems w/ 8xx and 2.6.x?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-18 18:13 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <93780AB0-696D-11D9-81BE-003065F9B7DC@embeddededge.com>
On Tue, Jan 18, 2005 at 11:25:33AM -0500, Dan Malek wrote:
>
> On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
>
> >On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>
> >>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
> >>interfaces:
> >>1) They are called before the i2c driver is initialized and even
> >>loaded
> >>if its a module.
>
> There are three reasons. You don't want to use an I2c rtc clock at
> all in these functions because they get can get called from the
> clock interrupt to update the time in the rtc. If it does happen to
> work,
> it creates long latencies in the timer interrupt. If the i2c requires
> an
> interrupt, they system will crash or hang.
I think one of us wasn't clear. I'm not arguing for nuking
ppc_md.{get,set}_rtc_time(), I'm arguing for nuking
get_rtc_time()/set_rtc_time() inlines from <asm-ppc/rtc.h> (which are
used by drivers/char/genrtc.c) in favor of todc_time et al providing the
functions for genrtc. So all of the other places we use
ppc_md.{get,set}_rtc_time() are unchanged.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: John W. Linville @ 2005-01-18 18:11 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <313680C9A886D511A06000204840E1CF0A6474FF@whq-msgusr-02.pit.comms.marconi.com>
On Tue, Jan 18, 2005 at 10:45:53AM -0500, Povolotsky, Alexander wrote:
> Forgot to mention - this board boots (and works) well with Linux 2.4.26 with
Aren't there still generic problems w/ 8xx and 2.6.x?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [linux-usb-devel] USB host on Freescale MPC880
From: Bryan O'Donoghue @ 2005-01-18 17:29 UTC (permalink / raw)
To: Dayton, Dean; +Cc: linux-usb-devel, linuxppc-embedded
In-Reply-To: <C0170D0AF1277849A4B4518034F855DD09A9ED@aiexchange.ai.aiinet.com>
Dayton, Dean wrote:
> I need to provide a USB host interface on a propietary board using a
> Freescale (Motorola) MPC880. The MPC880 has a USB implemented in the
> CPM, but I haven't found any Linux support for it. Can anyone point me
> to existing drivers? Does anyone know of any problems that would/should
> prevent me from using the MPC880's USB interface?
>
> Thanks
Greetings Dean *list*.
There are some propiatery drivers... but... it's an oxymoron, to pay
licensing fees for Linux... I'd sooner eat nails then use the propiatery
offerings, to be quite honest, I'd have to quit my job before being
associated with such a thing.
Right now the Freescale 870-885 has minimal support in Linux, but, I do
have some patches for a 2.4.x which map out this family of chip's memory
map as per the specification and I have a very primitive USB loopback
tester working for this architecture. Said patches are not really ready
for public consumption, not to mention only being usable on a 2.4.
A propiatery board being developed by my company wants USB host
support... and I'm fairly confident I can do that... and hopefully I can
get some serious development work done on this over the next three to
four months and release a patch/(s) for public consumption.
I estimate it will take another four months to get USB host working
properly and perhaps a month to get USB-device support working properly
(touch wood on both counts), I'm not sure about the required development
time on that to be honest... but, if I don't get it finished in time for
our propiatery board, the powers that be in my company will use a
propiatery Linux offering... and I'll have to resign on the grounds of
being an Open Source Evangalist ! I need to eat/pay rent... so I really
need to get this board + USB working. *grin*.
Are you guys planning on devoting any development effort to hardware
support of this freescale part ? If so, would it be prudent to
co-ordinate the development effort ?
Bryan
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. Imetrex Technologies Ltd shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Imetrex Technologies Ltd does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. This communication does not create or modify any contract, and unless otherwise stated, is not intended to be contractually binding. Views or opinions expressed in this e-mail message are those of the author only.
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Dan Malek @ 2005-01-18 16:25 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050118161515.GI28724@smtp.west.cox.net>
On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
> On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>> There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
>> interfaces:
>> 1) They are called before the i2c driver is initialized and even
>> loaded
>> if its a module.
There are three reasons. You don't want to use an I2c rtc clock at
all in these functions because they get can get called from the
clock interrupt to update the time in the rtc. If it does happen to
work,
it creates long latencies in the timer interrupt. If the i2c requires
an
interrupt, they system will crash or hang.
A system using an I2C RTC should find some way to access the
clock from application space as a standard I2C device and manage
time/clock from the application, not from the kernel.
-- Dan
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-18 16:15 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <41EC29A8.1040703@mvista.com>
On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
> All,
>
> I have a platform with an i2c rtc chip. Since much of the code for an
> rtc driver is already in drivers/char/genrtc.c, I would like to reuse
> that code and directly implement get_rtc_time(), et. al. in the rtc
> driver. The problem is that include/asm-ppc/rtc.h assumes that
> get_rtc_time(), et. al. should be mapped to ppc_md.get_rtc_time() et.
> al. To work around this, I made an option to turn off that assumption.
> The patch is included.
>
> There are 2 reasons to not use the ppc_md.get_rtc_time() et. al. interfaces:
> 1) They are called before the i2c driver is initialized and even loaded
> if its a module.
But they check if it's set, so they can be assigned later and this is
OK.
> 2) Its ppc-specific. Implementing get_rtc_time() et. al. directly makes
> it generic across all architectures.
Guessing, this is for a marvell chipset that's found on MIPS too.
> Is there a better way to do this?
How about we try borrowing the MIPS abstraction and force todc_time,
pmac_time (any others?) to directly define (and EXPORT_SYMBOL)
get_rtc_time / set_rtc_time / etc.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 15:45 UTC (permalink / raw)
To: 'Mark Chambers'; +Cc: 'linuxppc-embedded@ozlabs.org'
Hi Mark,
Forgot to mention - this board boots (and works) well with Linux 2.4.26 with
the
same bootloader structure
and
same embed_config(bd_t **bdp) function (in
arch/ppc/boot/simple/embed_config.c))
as listed before
Regards,
Alex
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 15:24 UTC (permalink / raw)
To: 'Mark Chambers'; +Cc: linuxppc-embedded
Sorry - no hardware instruments, support (and skills ;-) ) here ...
anything else to try software-wise (no JTAG debugging is available either) ?
-----Original Message-----
From: Mark Chambers [mailto:markc@mail.com]
Sent: Tuesday, January 18, 2005 10:23 AM
To: Povolotsky, Alexander; linuxppc-embedded@ozlabs.org
Subject: Re: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of
bd_in fo structure in the kernel booting code
>
> So what could go wrong here in terms of setting the baudrate for the
serial
> uart
> (which "presumably" causes printing 3 good characters and then garbage
> during kernel booting) ?
>
If you can get your hands on an oscilloscope and look at the TxD from your
board, you can get an exact measurement of your baudrate and make sure
you are on the right track. (Baudrate = 1/shortest-high-or-low-time)
Mark Chambers
^ permalink raw reply
* Re: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of bd_in fo structure in the kernel booting code
From: Mark Chambers @ 2005-01-18 15:23 UTC (permalink / raw)
To: Povolotsky, Alexander, linuxppc-embedded
In-Reply-To: <313680C9A886D511A06000204840E1CF0A6474FD@whq-msgusr-02.pit.comms.marconi.com>
>
> So what could go wrong here in terms of setting the baudrate for the
serial
> uart
> (which "presumably" causes printing 3 good characters and then garbage
> during kernel booting) ?
>
If you can get your hands on an oscilloscope and look at the TxD from your
board, you can get an exact measurement of your baudrate and make sure
you are on the right track. (Baudrate = 1/shortest-high-or-low-time)
Mark Chambers
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 15:01 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi,
my "custom" bd_info structure (passed from my custom bootloader) looks as
following:
typedef struct bd_info {
unsigned long bi_memstart; /* start of DRAM memory */
unsigned long bi_memsize; /* size of DRAM memory in bytes */
unsigned long bi_flashstart; /* start of FLASH memory */
unsigned long bi_flashsize; /* size of FLASH memory */
unsigned long bi_flashoffset; /* reserved area for startup monitor
*/
unsigned long bi_sramstart; /* start of SRAM memory */
unsigned long bi_sramsize; /* size of SRAM memory */
unsigned long bi_immr_base; /* base of IMMR register */
unsigned long bi_bootflags; /* boot / reboot flag (for LynxOS)
*/
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet adress */
unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
unsigned long bi_intfreq; /* Internal Freq, in MHz */
unsigned long bi_busfreq; /* Bus Freq, in MHz */
unsigned long bi_baudrate; /* Console Baudrate */
unsigned char bi_run_bank; /* Running Bank */
} bd_t;
My embed_config(bd_t **bdp) function (in
arch/ppc/boot/simple/embed_config.c)
does the following (using above structure) :
bd->bi_baudrate = 38400; /* changed from 115200 for debug - Alex */
bd->bi_memstart = 0;
bd->bi_memsize = (32 * 1024 * 1024);
bd->bi_intfreq = 50000000;
bd->bi_busfreq = 50000000;
Then we have, as Hans noted to me, the cpm_setbrg() function
(in arch/ppc/8xx_io/commproc.c):
/* Set a baud rate generator. This needs lots of work. There are
* four BRGs, any of which can be wired to any channel.
* The internal baud rate clock is the system clock divided by 16.
* This assumes the baudrate is 16x oversampled by the uart.
*/
#define BRG_INT_CLK (((bd_t *)__res)->bi_intfreq)
#define BRG_UART_CLK (BRG_INT_CLK/16)
#define BRG_UART_CLK_DIV16 (BRG_UART_CLK/16)
void
cpm_setbrg(uint brg, uint rate)
{
volatile uint *bp;
/* This is good enough to get SMCs running.....
*/
bp = (uint *)&cpmp->cp_brgc1;
bp += brg;
/* The BRG has a 12-bit counter. For really slow baud rates (or
* really fast processors), we may have to further divide by 16.
*/
if (((BRG_UART_CLK / rate) - 1) < 4096)
*bp = (((BRG_UART_CLK / rate) - 1) << 1) | CPM_BRG_EN;
else
*bp = (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
CPM_BRG_EN | CPM_BRG_DIV16;
}
So what could go wrong here in terms of setting the baudrate for the serial
uart
(which "presumably" causes printing 3 good characters and then garbage
during kernel booting) ?
^ 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