* Discuss: Adding OF Flat Dev Tree to ppc32
From: Jon Loeliger @ 2005-06-03 17:19 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org, linuxppc64-dev
In-Reply-To: <1117783104.31082.151.camel@gaston>
Ben and Folks,
I've read through ppc64/kernel/prom.c and done some minor
call-chain analysis rooted at the two functions:
early_init_devtree()
unflatten_device_tree()
as they are apparently the only two referenced in the
initial early boot up process.
My notion was to take the portion of prom.c rooted at
these two functions and add them to the ppc32 line.
First, what portions of pp64/kernel/prom.c are obsolete?
Anything? You alluded to cleaning this up some, but I
am not too familiar with it to know where that was headed.
Second, there is already a fairly similar prom.c file
hanging out over in ppc32 land. I _think_ it houses
roughly the complementary code out of ppc64's prom.c
that is NOT derived from the call chain derived from
the above two functions.
Which leads me to the questions: Is there, or should
we create, a plan to factor the flat-dev-tree handling
code into common or shared ppc code? I am reluctant
to just outright clone and copy that code if it will
ultimately "be the same" or even "mostly the same".
It seems that the early_init_devtree() might then need
to be refactored or duplicated for ppc32-land.
Are you anticipating the same r3,r4,r5 interface outlined
in your 0.4 rev of the ppc4 OF spec to be used by the
ppc32 world as well? Seems like it just might...
Naturally, I'm willing to jump in here, just looking
for a bit of global-direction from you. :-)
jdl
^ permalink raw reply
* RE: Getting ownership for various boards/platforms configs
From: Baxter, Robert @ 2005-06-03 18:43 UTC (permalink / raw)
To: Kumar Gala, Linux PPC Embedded list, linuxppc-dev list
> -----Original Message-----
> From: linuxppc-dev-bounces@ozlabs.org=20
> [mailto:linuxppc-dev-bounces@ozlabs.org] On Behalf Of Kumar Gala
> Sent: Thursday, June 02, 2005 4:19 PM
> To: Linux PPC Embedded list; linuxppc-dev list
> Subject: Getting ownership for various boards/platforms configs
>=20
> One issue that comes up from time to time is knowing who to contact=20
> about some of the various boards that are supported for PPC. I've=20
> suggested in the past that we create a MAINTAINERS file in=20
> arch/ppc/platforms. I've started with a list of all the _defconfigs=20
> that we have and would like to see if we can get contacts for the=20
> boards. All this list is meant to be is a contact point.
>=20
> The following is the list, I'll keep a live copy at=20
> http://gate.crashing.org/~galak/platform-owners. Once it=20
> gets flushed=20
> out I'll turn it into file that looks more like the toplevel=20
> MAINTAINERS file. If we dont have any owners for a board we can=20
> discuss if support for it should be removed. Please email me if you=20
> feel you are the owner of any board/config.
>=20
> thanks
>=20
> - kumar
>=20
> gemini
I'll take this one.
rbaxter@curtisswright.com
Rob Baxter
Curtiss-Wright Controls, Embedded Computing
^ permalink raw reply
* [PATCH] ppc32: Converted MPC10X bridge to use platform devices instead of OCP
From: Kumar Gala @ 2005-06-03 20:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Converted the MPC10x bridge support (used by MPC10x and 8240/1/5) to
used the standard platform device model.
Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit c4fa624a5c007f17142ab5225d1085564ffa8f83
tree 63546f2e7de561696db29a0a481bf40c449e9f0e
parent e832e0d9e4878d02ab2ef6bad5971dc9f9cd7679
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 03 Jun 2005 14:20:50 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 03 Jun 2005 14:20:50 -0500
arch/ppc/Kconfig | 5 -
arch/ppc/kernel/setup.c | 4
arch/ppc/syslib/Makefile | 2
arch/ppc/syslib/mpc10x_common.c | 177 +++++++++++++++++++++++++++++----------
include/asm-ppc/mpc10x.h | 6 +
include/asm-ppc/ppc_sys.h | 2
6 files changed, 144 insertions(+), 52 deletions(-)
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -826,11 +826,6 @@ config MPC10X_BRIDGE
depends on PCORE || POWERPMC250 || LOPEC || SANDPOINT
default y
-config FSL_OCP
- bool
- depends on MPC10X_BRIDGE
- default y
-
config MPC10X_OPENPIC
bool
depends on POWERPMC250 || LOPEC || SANDPOINT
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -41,7 +41,7 @@
#include <asm/xmon.h>
#include <asm/ocp.h>
-#if defined(CONFIG_85xx) || defined(CONFIG_83xx)
+#if defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_MPC10X_BRIDGE)
#include <asm/ppc_sys.h>
#endif
@@ -249,7 +249,7 @@ int show_cpuinfo(struct seq_file *m, voi
seq_printf(m, "bogomips\t: %lu.%02lu\n",
lpj / (500000/HZ), (lpj / (5000/HZ)) % 100);
-#if defined(CONFIG_85xx) || defined(CONFIG_83xx)
+#if defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_MPC10X_BRIDGE)
if (cur_ppc_sys_spec->ppc_sys_name)
seq_printf(m, "chipset\t\t: %s\n",
cur_ppc_sys_spec->ppc_sys_name);
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -92,7 +92,7 @@ ifeq ($(CONFIG_SERIAL_MPSC_CONSOLE),y)
obj-$(CONFIG_SERIAL_TEXT_DEBUG) += mv64x60_dbg.o
endif
obj-$(CONFIG_BOOTX_TEXT) += btext.o
-obj-$(CONFIG_MPC10X_BRIDGE) += mpc10x_common.o indirect_pci.o
+obj-$(CONFIG_MPC10X_BRIDGE) += mpc10x_common.o indirect_pci.o ppc_sys.o
obj-$(CONFIG_MPC10X_OPENPIC) += open_pic.o
obj-$(CONFIG_40x) += dcr.o
obj-$(CONFIG_BOOKE) += dcr.o
diff --git a/arch/ppc/syslib/mpc10x_common.c b/arch/ppc/syslib/mpc10x_common.c
--- a/arch/ppc/syslib/mpc10x_common.c
+++ b/arch/ppc/syslib/mpc10x_common.c
@@ -21,6 +21,9 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/slab.h>
+#include <linux/serial_8250.h>
+#include <linux/fsl_devices.h>
+#include <linux/device.h>
#include <asm/byteorder.h>
#include <asm/io.h>
@@ -30,16 +33,7 @@
#include <asm/pci-bridge.h>
#include <asm/open_pic.h>
#include <asm/mpc10x.h>
-#include <asm/ocp.h>
-
-/* The OCP structure is fixed by code below, before OCP initialises.
- paddr depends on where the board places the EUMB.
- - fixed in mpc10x_bridge_init().
- irq depends on two things:
- > does the board use the EPIC at all? (PCORE does not).
- > is the EPIC in serial or parallel mode?
- - fixed in mpc10x_set_openpic().
-*/
+#include <asm/ppc_sys.h>
#ifdef CONFIG_MPC10X_OPENPIC
#ifdef CONFIG_EPIC_SERIAL_MODE
@@ -51,34 +45,127 @@
#define MPC10X_DMA0_IRQ (EPIC_IRQ_BASE + 1 + NUM_8259_INTERRUPTS)
#define MPC10X_DMA1_IRQ (EPIC_IRQ_BASE + 2 + NUM_8259_INTERRUPTS)
#else
-#define MPC10X_I2C_IRQ OCP_IRQ_NA
-#define MPC10X_DMA0_IRQ OCP_IRQ_NA
-#define MPC10X_DMA1_IRQ OCP_IRQ_NA
+#define MPC10X_I2C_IRQ -1
+#define MPC10X_DMA0_IRQ -1
+#define MPC10X_DMA1_IRQ -1
#endif
-
-struct ocp_def core_ocp[] = {
- { .vendor = OCP_VENDOR_INVALID
- }
+static struct fsl_i2c_platform_data mpc10x_i2c_pdata = {
+ .device_flags = 0,
};
-static struct ocp_fs_i2c_data mpc10x_i2c_data = {
- .flags = 0
+static struct plat_serial8250_port serial_platform_data[] = {
+ { },
};
-static struct ocp_def mpc10x_i2c_ocp = {
- .vendor = OCP_VENDOR_MOTOROLA,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .additions = &mpc10x_i2c_data
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC10X_IIC1] = {
+ .name = "fsl-i2c",
+ .id = 1,
+ .dev.platform_data = &mpc10x_i2c_pdata,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_I2C_OFFSET,
+ .end = MPC10X_EUMB_I2C_OFFSET +
+ MPC10X_EUMB_I2C_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ
+ },
+ },
+ },
+ [MPC10X_DMA0] = {
+ .name = "fsl-dma",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_DMA_OFFSET + 0x10,
+ .end = MPC10X_EUMB_DMA_OFFSET + 0x1f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC10X_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_DMA_OFFSET + 0x20,
+ .end = MPC10X_EUMB_DMA_OFFSET + 0x2f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC10X_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_DMA_OFFSET + 0x20,
+ .end = MPC10X_EUMB_DMA_OFFSET + 0x2f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC10X_DUART] = {
+ .name = "serial8250",
+ .id = 0,
+ .dev.platform_data = serial_platform_data,
+ },
};
-static struct ocp_def mpc10x_dma_ocp[2] = {
-{ .vendor = OCP_VENDOR_MOTOROLA,
- .function = OCP_FUNC_DMA,
- .index = 0 },
-{ .vendor = OCP_VENDOR_MOTOROLA,
- .function = OCP_FUNC_DMA,
- .index = 1 }
+/* We use the PCI ID to match on */
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ {
+ .ppc_sys_name = "8245",
+ .mask = 0xFFFFFFFF,
+ .value = MPC10X_BRIDGE_8245,
+ .num_devices = 4,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC10X_IIC1, MPC10X_DMA0, MPC10X_DMA1, MPC10X_DUART,
+ },
+ },
+ {
+ .ppc_sys_name = "8240",
+ .mask = 0xFFFFFFFF,
+ .value = MPC10X_BRIDGE_8240,
+ .num_devices = 3,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC10X_IIC1, MPC10X_DMA0, MPC10X_DMA1,
+ },
+ },
+ {
+ .ppc_sys_name = "107",
+ .mask = 0xFFFFFFFF,
+ .value = MPC10X_BRIDGE_107,
+ .num_devices = 3,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC10X_IIC1, MPC10X_DMA0, MPC10X_DMA1,
+ },
+ },
+ { /* default match */
+ .ppc_sys_name = "",
+ .mask = 0x00000000,
+ .value = 0x00000000,
+ },
};
/* Set resources to match bridge memory map */
@@ -273,7 +360,7 @@ mpc10x_bridge_init(struct pci_controller
printk("Host bridge in Agent mode\n");
/* Read or Set LMBAR & PCSRBAR? */
}
-
+
/* Set base addr of the 8240/107 EUMB. */
early_write_config_dword(hose,
0,
@@ -287,17 +374,6 @@ mpc10x_bridge_init(struct pci_controller
ioremap(phys_eumb_base + MPC10X_EUMB_EPIC_OFFSET,
MPC10X_EUMB_EPIC_SIZE);
#endif
- mpc10x_i2c_ocp.paddr = phys_eumb_base + MPC10X_EUMB_I2C_OFFSET;
- mpc10x_i2c_ocp.irq = MPC10X_I2C_IRQ;
- ocp_add_one_device(&mpc10x_i2c_ocp);
- mpc10x_dma_ocp[0].paddr = phys_eumb_base +
- MPC10X_EUMB_DMA_OFFSET + 0x100;
- mpc10x_dma_ocp[0].irq = MPC10X_DMA0_IRQ;
- ocp_add_one_device(&mpc10x_dma_ocp[0]);
- mpc10x_dma_ocp[1].paddr = phys_eumb_base +
- MPC10X_EUMB_DMA_OFFSET + 0x200;
- mpc10x_dma_ocp[1].irq = MPC10X_DMA1_IRQ;
- ocp_add_one_device(&mpc10x_dma_ocp[1]);
}
#ifdef CONFIG_MPC10X_STORE_GATHERING
@@ -330,7 +406,7 @@ mpc10x_bridge_init(struct pci_controller
* 8245 (Rev 2., dated 10/2003) says PICR2[0] is reserverd.
*/
if (host_bridge == MPC10X_BRIDGE_8245) {
- ulong picr2;
+ u32 picr2;
early_read_config_dword(hose, 0, PCI_DEVFN(0,0),
MPC10X_CFG_PICR2_REG, &picr2);
@@ -340,6 +416,19 @@ mpc10x_bridge_init(struct pci_controller
early_write_config_dword(hose, 0, PCI_DEVFN(0,0),
MPC10X_CFG_PICR2_REG, picr2);
}
+
+ ppc_sys_fixup_mem_resource (ppc_sys_platform_devices,
+ phys_eumb_base);
+
+ /* IRQ's are determined at runtime */
+ ppc_sys_platform_devices[MPC10X_IIC1].resource[1].start = MPC10X_I2C_IRQ;
+ ppc_sys_platform_devices[MPC10X_IIC1].resource[1].end = MPC10X_I2C_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA0].resource[1].start = MPC10X_DMA0_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA0].resource[1].end = MPC10X_DMA0_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA1].resource[1].start = MPC10X_DMA1_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA1].resource[1].end = MPC10X_DMA1_IRQ;
+
+ identify_ppc_sys_by_id (host_bridge);
if (ppc_md.progress) ppc_md.progress("mpc10x:exit", 0x100);
return 0;
diff --git a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
--- a/include/asm-ppc/mpc10x.h
+++ b/include/asm-ppc/mpc10x.h
@@ -159,6 +159,12 @@ extern unsigned long ioremap_base;
#define MPC10X_MAPA_EUMB_BASE (ioremap_base - MPC10X_EUMB_SIZE)
#define MPC10X_MAPB_EUMB_BASE MPC10X_MAPA_EUMB_BASE
+enum ppc_sys_devices {
+ MPC10X_IIC1,
+ MPC10X_DMA0,
+ MPC10X_DMA1,
+ MPC10X_DUART,
+};
int mpc10x_bridge_init(struct pci_controller *hose,
uint current_map,
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -27,6 +27,8 @@
#include <asm/mpc85xx.h>
#elif defined(CONFIG_PPC_MPC52xx)
#include <asm/mpc52xx.h>
+#elif defined(CONFIG_MPC10X_BRIDGE)
+#include <asm/mpc10x.h>
#else
#error "need definition of ppc_sys_devices"
#endif
^ permalink raw reply
* Re: [PATCH] Fix PPC440 pagetable attributes
From: Kumar Gala @ 2005-06-03 20:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-embedded
In-Reply-To: <42A085AD.3070005@am.sony.com>
On Jun 3, 2005, at 11:30 AM, Geoff Levand wrote:
> Kumar Gala wrote:
>> On Jun 2, 2005, at 6:00 PM, Geoff Levand wrote:
>>
>>
>>> This patch fixes a bug in the PPC440 pagetable attributes that breaks
>>> swap support. It also adds some notes on the PPC440 attribute
>>> fields.
>>>
>>> *
>>> * Note that these bits preclude future use of a page size
>>> * less than 4KB.
>>> + *
>>> + *
>>> + * PPC 440 core has following TLB attribute fields;
>>> + *
>>> + * TLB1:
>>> + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
>>> 31
>>> + * RPN................................. - - - - - -
>>> ERPN.......
>>> + *
>>> + * TLB2:
>>> + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
>>> 31
>>> + * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW
>>> SR
>>> + *
>>> + * There are some constrains and options, to decide mapping software
>>> bits
>>> + * into TLB entry.
>>> + *
>>> + * - PRESENT *must* be in the bottom three bits because swap cache
>>> + * entries use the top 29 bits for TLB2.
>>> + *
>>> + * - FILE *must* be in the bottom three bits because swap cache
>>> + * entries use the top 29 bits for TLB2.
>>> + *
>>> + * - CACHE COHERENT bit (M) has no effect on PPC440 core, because
>>> it
>>> + * doesn't support SMP. So we can use this as software bit, like
>>> + * DIRTY.
>>> + *
>>> + * PPC Book-E Linux implementation uses PPC HW PTE bit field
>>> definition,
>>> + * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory
>>> + * protection-related function. (See PTE structure in
>>> include/asm-ppc/mmu.h)
>>> + * Definition of _PAGE_XXX in "include/asm-ppc/pagetable.h" stands
>>> for
>>> + * above bits. Note that those bits values are CPU dependent, not
>>> + * architecture.
>>> + *
>>
>> I disagree with this comment. PPC Book-E PTE format has nothing to do
>> with PPC HW PTE format.
>>
>
> OK, is this more agreeable?
>
> * With the PPC Book-E Linux implementation, 0-11th LSB of PTE stand
> for memory
> * protection-related function. (See PTE structure in
> include/asm-ppc/mmu.h)
> * Definition of _PAGE_XXX here stands for above bits. Note that those
> bits
> * values are CPU dependent, not architecture.
That's more reasonable, however I would make it say PPC 44x ... instead
of Book-E, the e500 is also a Book-E processor and if you notice if we
use a 64-bit PTE we end up using more than the 12 LSBs for PTE flags.
- kumar
^ permalink raw reply
* Re: [PATCH][1/5] RapidIO support: core
From: Matt Porter @ 2005-06-03 21:24 UTC (permalink / raw)
To: Greg KH; +Cc: akpm, torvalds, linux-kernel, linuxppc-embedded
In-Reply-To: <20050603071133.GB30292@kroah.com>
On Fri, Jun 03, 2005 at 12:11:33AM -0700, Greg KH wrote:
> On Thu, Jun 02, 2005 at 02:03:59PM -0700, Matt Porter wrote:
> > +RIO_LOP_READ(8, u8, 1)
> > + RIO_LOP_READ(16, u16, 2)
> > + RIO_LOP_READ(32, u32, 4)
> > + RIO_LOP_WRITE(8, u8, 1)
> > + RIO_LOP_WRITE(16, u16, 2)
> > + RIO_LOP_WRITE(32, u32, 4)
> > +
> > + EXPORT_SYMBOL(__rio_local_read_config_8);
> > +EXPORT_SYMBOL(__rio_local_read_config_16);
> > +EXPORT_SYMBOL(__rio_local_read_config_32);
> > +EXPORT_SYMBOL(__rio_local_write_config_8);
> > +EXPORT_SYMBOL(__rio_local_write_config_16);
> > +EXPORT_SYMBOL(__rio_local_write_config_32);
>
> Odd indenting here.
Lindent got me here. I didn't doublecheck its munging on this file.
Updated that.
> And why the __rio* stuff for public functions? You should drop the "__"
> part.
This may seem silly but I was trying to have the automagic DocBook
stuff pick up the complete set of kernel interfaces without have
to duplicate anything in the DocBook template. Since these functions
are macro-generated I could have a comment block for each one that
the docs stuff would pick up. So, I put rio_local_*() up in
include/linux/rio_drv.h as inline wrappers around these implementations.
Too ugly to live? Maybe there's a better way to make this work, it
would nice to have it autogenerate the docs.
<snip>
> > +EXPORT_SYMBOL(rio_mport_send_doorbell);
>
> Just a question, should these be EXPORT_SYMBOL_GPL() as this is GPL
> code? Just to be explicit that is.
Good point. I'm going to go through and make all RIO interfaces
EXPORT_SYMBOL_GPL(). Embedded folks need the extra encouragement
to do the right thing when writing drivers.
> > +static ssize_t
> > +rio_read_config(struct kobject *kobj, char *buf, loff_t off, size_t count)
>
> <snip>
>
> You might want to compare this to the recent changes in the 2.6.12-rc
> kernels in the pci sysfs config code. There were some 64 and endian
> issues fixed up there that you might want to make sure are also done
> properly here.
I see that in the current git tree. I think some of it applies (note
that RIO is a big-endian system, not surprising since it originates
from Motorola/Fscale), I'll look more closely and add the appropriate
fixes into the next patch. Since Andrew took these into -mm I will
just post patches against -mm.
> > +static struct bin_attribute rio_config_attr = {
> > + .attr = {
> > + .name = "config",
> > + .mode = S_IRUGO | S_IWUSR,
> > + .owner = THIS_MODULE,
> > + },
> > + .size = 0x200000,
> > + .read = rio_read_config,
> > + .write = rio_write_config,
> > +};
>
> Wow, that's a huge config space (just a comment, not an issue...)
Heh, yes. The "maintenance packets" that are used to access config
space on RIO devices have a 21-bit offset field. I guess the
spec guys didn't want to run out of config space too quickly. :)
-Matt
^ permalink raw reply
* [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Randy Vinson @ 2005-06-03 21:36 UTC (permalink / raw)
To: Greg KH; +Cc: sensors, linuxppc-embedded
Greetings,
I've put together a small I2C client for the Maxim/Dallas DS1374 RTC
chip and tested it on a Freescale MPC8349ADS board that uses the chip.
The attached patch adds support for the chip itself and a follow-up patch
will add support to the Freescale board.
Please CC: me on any replies as I am not subscribed to the sensors list.
Thanks,
Randy Vinson
Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
This change adds support for the Maxim/Dallas DS1374 RTC chip. This chip
is an I2C-based RTC that maintains a simple 32-bit binary seconds count
with battery backup support.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
commit f95cc4d276cc332225bd823a2ae3be553c119990
tree bd11f3262e29c13b6d56383415c634371394e913
parent b56ae7a07ed0304bbc1dd61d3527dccdbcc467e9
author Randy Vinson <rvinson@linuxbox.(none)> Fri, 03 Jun 2005 13:50:59 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Fri, 03 Jun 2005 13:50:59 -0700
drivers/i2c/chips/Kconfig | 11 ++
drivers/i2c/chips/Makefile | 1
drivers/i2c/chips/ds1374.c | 266 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/i2c-id.h | 1
4 files changed, 279 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -376,6 +376,17 @@ config SENSORS_DS1337
This driver can also be built as a module. If so, the module
will be called ds1337.
+config SENSORS_DS1374
+ tristate "Maxim/Dallas Semiconductor DS1374 Real Time Clock"
+ depends on I2C && EXPERIMENTAL
+ select I2C_SENSOR
+ help
+ If you say yes here you get support for Dallas Semiconductor
+ DS1374 real-time clock chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called ds1374.
+
config SENSORS_EEPROM
tristate "EEPROM reader"
depends on I2C && EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_ADM1025) += adm1025
obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o
obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o
obj-$(CONFIG_SENSORS_DS1337) += ds1337.o
+obj-$(CONFIG_SENSORS_DS1374) += ds1374.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_FSCHER) += fscher.o
diff --git a/drivers/i2c/chips/ds1374.c b/drivers/i2c/chips/ds1374.c
new file mode 100644
--- /dev/null
+++ b/drivers/i2c/chips/ds1374.c
@@ -0,0 +1,266 @@
+/*
+ * drivers/i2c/chips/ds1374.c
+ *
+ * I2C client/driver for the Maxim/Dallas DS1374 Real-Time Clock
+ *
+ * Author: Randy Vinson <rvinson@mvista.com>
+ *
+ * Based on the m41t00.c by Mark Greer <mgreer@mvista.com>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
+ * interface and the SMBus interface of the i2c subsystem.
+ * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
+ * recommened in .../Documentation/i2c/writing-clients section
+ * "Sending and receiving", using SMBus level communication is preferred.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/rtc.h>
+#include <linux/bcd.h>
+
+#include <asm/time.h>
+#include <asm/rtc.h>
+
+#define DS1374_REG_TOD0 0x00
+#define DS1374_REG_TOD1 0x01
+#define DS1374_REG_TOD2 0x02
+#define DS1374_REG_TOD3 0x03
+#define DS1374_REG_WDALM0 0x04
+#define DS1374_REG_WDALM1 0x05
+#define DS1374_REG_WDALM2 0x06
+#define DS1374_REG_CR 0x07
+#define DS1374_REG_SR 0x08
+#define DS1374_REG_SR_OSF 0x80
+#define DS1374_REG_TCR 0x09
+
+#define DS1374_DRV_NAME "ds1374"
+
+static DECLARE_MUTEX(ds1374_mutex);
+
+static struct i2c_driver ds1374_driver;
+static struct i2c_client *save_client;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
+
+static struct i2c_client_address_data addr_data = {
+ .normal_i2c = normal_addr,
+ .normal_i2c_range = ignore,
+ .probe = ignore,
+ .probe_range = ignore,
+ .ignore = ignore,
+ .ignore_range = ignore,
+ .force = ignore,
+};
+
+static ulong ds1374_read_rtc(void)
+{
+ ulong time = 0;
+ int reg = DS1374_REG_WDALM0;
+
+ while (reg--) {
+ s32 tmp;
+ if ((tmp = i2c_smbus_read_byte_data(save_client, reg)) < 0) {
+ dev_warn(&save_client->dev,
+ "can't read from rtc chip\n");
+ return 0;
+ }
+ time = (time << 8) | (tmp & 0xff);
+ }
+ return time;
+}
+
+static void ds1374_write_rtc(ulong time)
+{
+ int reg;
+
+ for (reg = DS1374_REG_TOD0; reg < DS1374_REG_WDALM0; reg++) {
+ if (i2c_smbus_write_byte_data(save_client, reg, time & 0xff)
+ < 0) {
+ dev_warn(&save_client->dev,
+ "can't write to rtc chip\n");
+ break;
+ }
+ time = time >> 8;
+ }
+}
+
+static void ds1374_check_rtc_status(void)
+{
+ s32 tmp;
+
+ tmp = i2c_smbus_read_byte_data(save_client, DS1374_REG_SR);
+ if (tmp < 0) {
+ dev_warn(&save_client->dev,
+ "can't read status from rtc chip\n");
+ return;
+ }
+ if (tmp & DS1374_REG_SR_OSF) {
+ dev_warn(&save_client->dev,
+ "oscillator discontinuity flagged, time unreliable\n");
+ tmp &= ~DS1374_REG_SR_OSF;
+ tmp = i2c_smbus_write_byte_data(save_client, DS1374_REG_SR,
+ tmp & 0xff);
+ if (tmp < 0)
+ dev_warn(&save_client->dev,
+ "can't clear discontinuity notification\n");
+ }
+}
+
+ulong ds1374_get_rtc_time(void)
+{
+ ulong t1, t2;
+ int limit = 10; /* arbitrary retry limit */
+
+ down(&ds1374_mutex);
+
+ /*
+ * Since the reads are being performed one byte at a time using
+ * the SMBus vs a 4-byte i2c transfer, there is a chance that a
+ * carry will occur during the read. To detect this, 2 reads are
+ * performed and compared.
+ */
+ do {
+ t1 = ds1374_read_rtc();
+ t2 = ds1374_read_rtc();
+ } while (t1 != t2 && limit--);
+
+ up(&ds1374_mutex);
+
+ if (t1 != t2) {
+ dev_warn(&save_client->dev,
+ "can't get consistent time from rtc chip\n");
+ t1 = 0;
+ }
+
+ return t1;
+}
+
+static void ds1374_set_tlet(ulong arg)
+{
+ ulong t1, t2;
+ int limit = 10; /* arbitrary retry limit */
+
+ t1 = *(ulong *) arg;
+
+ down(&ds1374_mutex);
+
+ /*
+ * Since the writes are being performed one byte at a time using
+ * the SMBus vs a 4-byte i2c transfer, there is a chance that a
+ * carry will occur during the write. To detect this, the write
+ * value is read back and compared.
+ */
+ do {
+ ds1374_write_rtc(t1);
+ t2 = ds1374_read_rtc();
+ } while (t1 != t2 && limit--);
+
+ up(&ds1374_mutex);
+
+ if (t1 != t2)
+ dev_warn(&save_client->dev,
+ "can't confirm time set from rtc chip\n");
+}
+
+ulong new_time;
+
+DECLARE_TASKLET_DISABLED(ds1374_tasklet, ds1374_set_tlet, (ulong) & new_time);
+
+int ds1374_set_rtc_time(ulong nowtime)
+{
+ new_time = nowtime;
+
+ if (in_interrupt())
+ tasklet_schedule(&ds1374_tasklet);
+ else
+ ds1374_set_tlet((ulong) & new_time);
+
+ return 0;
+}
+
+/*
+ *****************************************************************************
+ *
+ * Driver Interface
+ *
+ *****************************************************************************
+ */
+static int ds1374_probe(struct i2c_adapter *adap, int addr, int kind)
+{
+ struct i2c_client *client;
+ int rc;
+
+ client = kmalloc(sizeof(struct i2c_client), GFP_KERNEL);
+ if (!client)
+ return -ENOMEM;
+
+ memset(client, 0, sizeof(struct i2c_client));
+ strncpy(client->name, DS1374_DRV_NAME, I2C_NAME_SIZE);
+ client->flags = I2C_DF_NOTIFY;
+ client->addr = addr;
+ client->adapter = adap;
+ client->driver = &ds1374_driver;
+
+ if ((rc = i2c_attach_client(client)) != 0) {
+ kfree(client);
+ return rc;
+ }
+
+ save_client = client;
+
+ ds1374_check_rtc_status();
+
+ return 0;
+}
+
+static int ds1374_attach(struct i2c_adapter *adap)
+{
+ return i2c_probe(adap, &addr_data, ds1374_probe);
+}
+
+static int ds1374_detach(struct i2c_client *client)
+{
+ int rc;
+
+ if ((rc = i2c_detach_client(client)) == 0) {
+ kfree(i2c_get_clientdata(client));
+ tasklet_kill(&ds1374_tasklet);
+ }
+ return rc;
+}
+
+static struct i2c_driver ds1374_driver = {
+ .owner = THIS_MODULE,
+ .name = DS1374_DRV_NAME,
+ .id = I2C_DRIVERID_DS1374,
+ .flags = I2C_DF_NOTIFY,
+ .attach_adapter = ds1374_attach,
+ .detach_client = ds1374_detach,
+};
+
+static int __init ds1374_init(void)
+{
+ return i2c_add_driver(&ds1374_driver);
+}
+
+static void __exit ds1374_exit(void)
+{
+ i2c_del_driver(&ds1374_driver);
+}
+
+module_init(ds1374_init);
+module_exit(ds1374_exit);
+
+MODULE_AUTHOR("Randy Vinson <rvinson@mvista.com>");
+MODULE_DESCRIPTION("Maxim/Dallas DS1374 RTC I2C Client Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h
--- a/include/linux/i2c-id.h
+++ b/include/linux/i2c-id.h
@@ -108,6 +108,7 @@
#define I2C_DRIVERID_TDA7313 62 /* TDA7313 audio processor */
#define I2C_DRIVERID_MAX6900 63 /* MAX6900 real-time clock */
#define I2C_DRIVERID_SAA7114H 64 /* video decoder */
+#define I2C_DRIVERID_DS1374 65 /* DS1374 real time clock */
#define I2C_DRIVERID_EXP0 0xF0 /* experimental use id's */
^ permalink raw reply
* Re: [PATCH][1/5] RapidIO support: core
From: Matt Porter @ 2005-06-03 21:35 UTC (permalink / raw)
To: Greg KH; +Cc: akpm, torvalds, linux-kernel, linuxppc-embedded
In-Reply-To: <20050603072027.GD30292@kroah.com>
On Fri, Jun 03, 2005 at 12:20:27AM -0700, Greg KH wrote:
> On Thu, Jun 02, 2005 at 02:03:59PM -0700, Matt Porter wrote:
> > +static struct device rio_bus = {
> > + .bus_id = "rapidio",
> > +};
>
> Why do you need this device? You shouldn't have a static struct device
> to start with. Or you just don't like having your root rio device
> showing up in /sys/devices/ ?
Exactly. There's no hierarchy in this interconnect. So it seemed
that having a static rio_bus device made the most sense. Everything
exists as peers since it works more like a network than a hierarchical
bus like PCI. Right now, you can't see the endpoint which actually
implements your port into the switch fabric...there's no device
created for it. I'm still trying to determine if that should change
but it's not critical to usability with the current generation
hardware.
One argument I have _for_ it is that it would be easy to show
and manipulate a network from userspace if all nodes had a device
associated with them. That's not a real world problem yet so
I decided not to complicate things yet.
> If so, just create a kobject and put it there, and then base your
> devices off of it, no need for a real device.
>
> Oh wait, that's what the platform and system code does. bah,
> nevermind...
Ok. I did pull this part right from the platform code, in fact.
-Matt
^ permalink raw reply
* [PATCH 2/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Randy Vinson @ 2005-06-03 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Greg KH, sensors, linuxppc-embedded
In-Reply-To: <42A0CD46.60300@mvista.com>
Greetings,
This is part 2 of the patch to add support for the DS1374 I2C RTC chip
from Maxim/Dallas.
Randy Vinson
Add support for the I2C Real-Time Clock on the MPC8349ADS board.
This change provides support for the DS1374 Real-Time Clock chip present
on the MPC8349ADS board. It depends on a previous patch which adds I2C
support for the DS1374.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
commit 07fb1bd27347f7f0df1309c40d09a2f1a9a98731
tree b3ac3ac93679372aa5111268b623c5dda4a5039e
parent f95cc4d276cc332225bd823a2ae3be553c119990
author Randy Vinson <rvinson@linuxbox.(none)> Fri, 03 Jun 2005 13:57:46 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Fri, 03 Jun 2005 13:57:46 -0700
arch/ppc/platforms/83xx/mpc834x_sys.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -227,6 +227,26 @@ mpc834x_sys_init_IRQ(void)
ipic_set_default_priority();
}
+#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
+extern ulong ds1374_get_rtc_time(void);
+extern int ds1374_set_rtc_time(ulong);
+
+static int __init
+mpc834x_rtc_hookup(void)
+{
+ struct timespec tv;
+
+ ppc_md.get_rtc_time = ds1374_get_rtc_time;
+ ppc_md.set_rtc_time = ds1374_set_rtc_time;
+
+ tv.tv_nsec = 0;
+ tv.tv_sec = (ppc_md.get_rtc_time)();
+ do_settimeofday(&tv);
+
+ return 0;
+}
+late_initcall(mpc834x_rtc_hookup);
+#endif
static __inline__ void
mpc834x_sys_set_bat(void)
{
^ permalink raw reply
* Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Kumar Gala @ 2005-06-03 21:41 UTC (permalink / raw)
To: Randy Vinson; +Cc: Greg KH, sensors, linuxppc-embedded
In-Reply-To: <42A0CD46.60300@mvista.com>
Randy,
I was planning on cloning the DS1337 driver once all of the latest
patches for it got into Linus's tree. Not sure if you looked at it,
but when I was looking at RTC on 8349 the DS1337 seemed similar. Not
sure if we can unify the DS1337 driver such that can also support the
DS1374.
(Also, I'll wait on acceptance of the driver before pushing the board
code).
- kumar
On Jun 3, 2005, at 4:36 PM, Randy Vinson wrote:
> Greetings,
> I've put together a small I2C client for the Maxim/Dallas DS1374 RTC
> chip and tested it on a Freescale MPC8349ADS board that uses the chip.
> The attached patch adds support for the chip itself and a follow-up
> patch
> will add support to the Freescale board.
>
> Please CC: me on any replies as I am not subscribed to the sensors
> list.
>
> Thanks,
> Randy Vinson
>
>
> Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
>
> This change adds support for the Maxim/Dallas DS1374 RTC chip. This
> chip
> is an I2C-based RTC that maintains a simple 32-bit binary seconds count
> with battery backup support.
>
> Signed-off-by: Randy Vinson <rvinson@mvista.com>
>
> ---
> commit f95cc4d276cc332225bd823a2ae3be553c119990
> tree bd11f3262e29c13b6d56383415c634371394e913
> parent b56ae7a07ed0304bbc1dd61d3527dccdbcc467e9
> author Randy Vinson <rvinson@linuxbox.(none)> Fri, 03 Jun 2005
> 13:50:59 -0700
> committer Randy Vinson <rvinson@linuxbox.(none)> Fri, 03 Jun 2005
> 13:50:59 -0700
>
> drivers/i2c/chips/Kconfig | 11 ++
> drivers/i2c/chips/Makefile | 1
> drivers/i2c/chips/ds1374.c | 266
> ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/i2c-id.h | 1
> 4 files changed, 279 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
> --- a/drivers/i2c/chips/Kconfig
> +++ b/drivers/i2c/chips/Kconfig
> @@ -376,6 +376,17 @@ config SENSORS_DS1337
> This driver can also be built as a module. If so, the module
> will be called ds1337.
>
> +config SENSORS_DS1374
> + tristate "Maxim/Dallas Semiconductor DS1374 Real Time Clock"
> + depends on I2C && EXPERIMENTAL
> + select I2C_SENSOR
> + help
> + If you say yes here you get support for Dallas Semiconductor
> + DS1374 real-time clock chips.
> +
> + This driver can also be built as a module. If so, the module
> + will be called ds1374.
> +
> config SENSORS_EEPROM
> tristate "EEPROM reader"
> depends on I2C && EXPERIMENTAL
> diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
> --- a/drivers/i2c/chips/Makefile
> +++ b/drivers/i2c/chips/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_ADM1025) += adm1025
> obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o
> obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o
> obj-$(CONFIG_SENSORS_DS1337) += ds1337.o
> +obj-$(CONFIG_SENSORS_DS1374) += ds1374.o
> obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
> obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
> obj-$(CONFIG_SENSORS_FSCHER) += fscher.o
> diff --git a/drivers/i2c/chips/ds1374.c b/drivers/i2c/chips/ds1374.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/i2c/chips/ds1374.c
> @@ -0,0 +1,266 @@
> +/*
> + * drivers/i2c/chips/ds1374.c
> + *
> + * I2C client/driver for the Maxim/Dallas DS1374 Real-Time Clock
> + *
> + * Author: Randy Vinson <rvinson@mvista.com>
> + *
> + * Based on the m41t00.c by Mark Greer <mgreer@mvista.com>
> + *
> + * 2005 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> + */
> +/*
> + * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
> + * interface and the SMBus interface of the i2c subsystem.
> + * It would be more efficient to use i2c msgs/i2c_transfer directly
> but, as
> + * recommened in .../Documentation/i2c/writing-clients section
> + * "Sending and receiving", using SMBus level communication is
> preferred.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/i2c.h>
> +#include <linux/rtc.h>
> +#include <linux/bcd.h>
> +
> +#include <asm/time.h>
> +#include <asm/rtc.h>
> +
> +#define DS1374_REG_TOD0 0x00
> +#define DS1374_REG_TOD1 0x01
> +#define DS1374_REG_TOD2 0x02
> +#define DS1374_REG_TOD3 0x03
> +#define DS1374_REG_WDALM0 0x04
> +#define DS1374_REG_WDALM1 0x05
> +#define DS1374_REG_WDALM2 0x06
> +#define DS1374_REG_CR 0x07
> +#define DS1374_REG_SR 0x08
> +#define DS1374_REG_SR_OSF 0x80
> +#define DS1374_REG_TCR 0x09
> +
> +#define DS1374_DRV_NAME "ds1374"
> +
> +static DECLARE_MUTEX(ds1374_mutex);
> +
> +static struct i2c_driver ds1374_driver;
> +static struct i2c_client *save_client;
> +
> +static unsigned short ignore[] = { I2C_CLIENT_END };
> +static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
> +
> +static struct i2c_client_address_data addr_data = {
> + .normal_i2c = normal_addr,
> + .normal_i2c_range = ignore,
> + .probe = ignore,
> + .probe_range = ignore,
> + .ignore = ignore,
> + .ignore_range = ignore,
> + .force = ignore,
> +};
> +
> +static ulong ds1374_read_rtc(void)
> +{
> + ulong time = 0;
> + int reg = DS1374_REG_WDALM0;
> +
> + while (reg--) {
> + s32 tmp;
> + if ((tmp = i2c_smbus_read_byte_data(save_client, reg)) < 0) {
> + dev_warn(&save_client->dev,
> + "can't read from rtc chip\n");
> + return 0;
> + }
> + time = (time << 8) | (tmp & 0xff);
> + }
> + return time;
> +}
> +
> +static void ds1374_write_rtc(ulong time)
> +{
> + int reg;
> +
> + for (reg = DS1374_REG_TOD0; reg < DS1374_REG_WDALM0; reg++) {
> + if (i2c_smbus_write_byte_data(save_client, reg, time & 0xff)
> + < 0) {
> + dev_warn(&save_client->dev,
> + "can't write to rtc chip\n");
> + break;
> + }
> + time = time >> 8;
> + }
> +}
> +
> +static void ds1374_check_rtc_status(void)
> +{
> + s32 tmp;
> +
> + tmp = i2c_smbus_read_byte_data(save_client, DS1374_REG_SR);
> + if (tmp < 0) {
> + dev_warn(&save_client->dev,
> + "can't read status from rtc chip\n");
> + return;
> + }
> + if (tmp & DS1374_REG_SR_OSF) {
> + dev_warn(&save_client->dev,
> + "oscillator discontinuity flagged, time unreliable\n");
> + tmp &= ~DS1374_REG_SR_OSF;
> + tmp = i2c_smbus_write_byte_data(save_client, DS1374_REG_SR,
> + tmp & 0xff);
> + if (tmp < 0)
> + dev_warn(&save_client->dev,
> + "can't clear discontinuity notification\n");
> + }
> +}
> +
> +ulong ds1374_get_rtc_time(void)
> +{
> + ulong t1, t2;
> + int limit = 10; /* arbitrary retry limit */
> +
> + down(&ds1374_mutex);
> +
> + /*
> + * Since the reads are being performed one byte at a time using
> + * the SMBus vs a 4-byte i2c transfer, there is a chance that a
> + * carry will occur during the read. To detect this, 2 reads are
> + * performed and compared.
> + */
> + do {
> + t1 = ds1374_read_rtc();
> + t2 = ds1374_read_rtc();
> + } while (t1 != t2 && limit--);
> +
> + up(&ds1374_mutex);
> +
> + if (t1 != t2) {
> + dev_warn(&save_client->dev,
> + "can't get consistent time from rtc chip\n");
> + t1 = 0;
> + }
> +
> + return t1;
> +}
> +
> +static void ds1374_set_tlet(ulong arg)
> +{
> + ulong t1, t2;
> + int limit = 10; /* arbitrary retry limit */
> +
> + t1 = *(ulong *) arg;
> +
> + down(&ds1374_mutex);
> +
> + /*
> + * Since the writes are being performed one byte at a time using
> + * the SMBus vs a 4-byte i2c transfer, there is a chance that a
> + * carry will occur during the write. To detect this, the write
> + * value is read back and compared.
> + */
> + do {
> + ds1374_write_rtc(t1);
> + t2 = ds1374_read_rtc();
> + } while (t1 != t2 && limit--);
> +
> + up(&ds1374_mutex);
> +
> + if (t1 != t2)
> + dev_warn(&save_client->dev,
> + "can't confirm time set from rtc chip\n");
> +}
> +
> +ulong new_time;
> +
> +DECLARE_TASKLET_DISABLED(ds1374_tasklet, ds1374_set_tlet, (ulong) &
> new_time);
> +
> +int ds1374_set_rtc_time(ulong nowtime)
> +{
> + new_time = nowtime;
> +
> + if (in_interrupt())
> + tasklet_schedule(&ds1374_tasklet);
> + else
> + ds1374_set_tlet((ulong) & new_time);
> +
> + return 0;
> +}
> +
> +/*
> +
> ***********************************************************************
> ******
> + *
> + * Driver Interface
> + *
> +
> ***********************************************************************
> ******
> + */
> +static int ds1374_probe(struct i2c_adapter *adap, int addr, int kind)
> +{
> + struct i2c_client *client;
> + int rc;
> +
> + client = kmalloc(sizeof(struct i2c_client), GFP_KERNEL);
> + if (!client)
> + return -ENOMEM;
> +
> + memset(client, 0, sizeof(struct i2c_client));
> + strncpy(client->name, DS1374_DRV_NAME, I2C_NAME_SIZE);
> + client->flags = I2C_DF_NOTIFY;
> + client->addr = addr;
> + client->adapter = adap;
> + client->driver = &ds1374_driver;
> +
> + if ((rc = i2c_attach_client(client)) != 0) {
> + kfree(client);
> + return rc;
> + }
> +
> + save_client = client;
> +
> + ds1374_check_rtc_status();
> +
> + return 0;
> +}
> +
> +static int ds1374_attach(struct i2c_adapter *adap)
> +{
> + return i2c_probe(adap, &addr_data, ds1374_probe);
> +}
> +
> +static int ds1374_detach(struct i2c_client *client)
> +{
> + int rc;
> +
> + if ((rc = i2c_detach_client(client)) == 0) {
> + kfree(i2c_get_clientdata(client));
> + tasklet_kill(&ds1374_tasklet);
> + }
> + return rc;
> +}
> +
> +static struct i2c_driver ds1374_driver = {
> + .owner = THIS_MODULE,
> + .name = DS1374_DRV_NAME,
> + .id = I2C_DRIVERID_DS1374,
> + .flags = I2C_DF_NOTIFY,
> + .attach_adapter = ds1374_attach,
> + .detach_client = ds1374_detach,
> +};
> +
> +static int __init ds1374_init(void)
> +{
> + return i2c_add_driver(&ds1374_driver);
> +}
> +
> +static void __exit ds1374_exit(void)
> +{
> + i2c_del_driver(&ds1374_driver);
> +}
> +
> +module_init(ds1374_init);
> +module_exit(ds1374_exit);
> +
> +MODULE_AUTHOR("Randy Vinson <rvinson@mvista.com>");
> +MODULE_DESCRIPTION("Maxim/Dallas DS1374 RTC I2C Client Driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h
> --- a/include/linux/i2c-id.h
> +++ b/include/linux/i2c-id.h
> @@ -108,6 +108,7 @@
> #define I2C_DRIVERID_TDA7313 62 /* TDA7313 audio processor */
> #define I2C_DRIVERID_MAX6900 63 /* MAX6900 real-time clock */
> #define I2C_DRIVERID_SAA7114H 64 /* video decoder */
> +#define I2C_DRIVERID_DS1374 65 /* DS1374 real time clock */
>
>
> #define I2C_DRIVERID_EXP0 0xF0 /* experimental use id's */
^ permalink raw reply
* Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Eugene Surovegin @ 2005-06-03 21:46 UTC (permalink / raw)
To: Randy Vinson; +Cc: Greg KH, sensors, linuxppc-embedded
In-Reply-To: <42A0CD46.60300@mvista.com>
On Fri, Jun 03, 2005 at 02:36:06PM -0700, Randy Vinson wrote:
> Greetings,
> I've put together a small I2C client for the Maxim/Dallas DS1374 RTC
> chip and tested it on a Freescale MPC8349ADS board that uses the chip.
> The attached patch adds support for the chip itself and a follow-up patch
> will add support to the Freescale board.
[snip]
> + down(&ds1374_mutex);
> +
> + /*
> + * Since the reads are being performed one byte at a time using
> + * the SMBus vs a 4-byte i2c transfer, there is a chance that a
> + * carry will occur during the read. To detect this, 2 reads are
> + * performed and compared.
> + */
> + do {
> + t1 = ds1374_read_rtc();
> + t2 = ds1374_read_rtc();
> + } while (t1 != t2 && limit--);
I wonder, why you chose to use those 1-byte SMBus transfers instead of
i2c transfer.
I wrote similar DS1374 driver some time ago which used those transfers
and they worked just fine.
--
Eugene
^ permalink raw reply
* Re: RTnet broadcast
From: Ralph Siemsen @ 2005-06-03 21:37 UTC (permalink / raw)
To: peng gu; +Cc: linuxppc-embedded
In-Reply-To: <BAY14-F221B4CA9C143B0241EEF01C1070@phx.gbl>
peng gu wrote:
> hello
> I am a postgraduate. I only want to use RT-net to generate UDP-packets
> every 10 millisecond(broadcast).
> I had post my question to the RTnet mailing list to find someone to help
> ,but no one answer me. may be it is too simple and funny to answer for
> them,. but it is hard to me . If I use RTnet only for a packet generator
> not for building real-time Ethernet , whether there are something
> different from the socket programming to generate UDP packets on a
> "normal" network? (for example ,a local network that have one switch,
> and only one station broadcasting message to itself,) , If yes, Would
> you kind to tell me, and to list the functions of RTnet and RTAI that I
> must used to do this work. and tell me where I can find the similar
> application would someone give me a hand.
Have you tried looking at the examples that come with RTnet?
http://www.rts.uni-hannover.de/rtnet/lxr/source/addons/examples
in particular the "raw-packets" example should show you how to do what
you want.
-R
^ permalink raw reply
* Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Randy Vinson @ 2005-06-03 22:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: Greg KH, sensors, linuxppc-embedded
In-Reply-To: <5e2620f079e946d884175372dbf7e37e@freescale.com>
Kumar Gala wrote:
> Randy,
>
> I was planning on cloning the DS1337 driver once all of the latest
> patches for it got into Linus's tree.
I haven't seen any patches for the DS1337, but I admit that I wasn't
looking very hard.
Not sure if you looked at it,
> but when I was looking at RTC on 8349 the DS1337 seemed similar. Not
> sure if we can unify the DS1337 driver such that can also support the
> DS1374.
I looked at the DS1337 driver, but that chip uses individual registers
for the various time bits, whereas the DS1374 uses a 32-bit seconds
count spread across 4 registers. I wasn't convinced that I could find a
reliable way to differenciate between the 2 types at run time since they
use the same I2C address (0x68). So, I choose to create a new driver to
keep it simple. If there is a reliable way to handle both types in the
same driver, I'll drop my DS1374-specific driver.
>
> (Also, I'll wait on acceptance of the driver before pushing the board
> code).
Agreed.
Randy Vinson
^ permalink raw reply
* Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Randy Vinson @ 2005-06-03 22:17 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Greg KH, sensors, linuxppc-embedded
In-Reply-To: <20050603214653.GA15314@gate.ebshome.net>
Eugene Surovegin wrote:
[snip]
>
> I wonder, why you chose to use those 1-byte SMBus transfers instead of
> i2c transfer.
I was simply following the guidelines in
Documentation/i2c/writing-clients as noted in the driver header. This
note was in the driver I used as my base, so I just followed along.
>
> I wrote similar DS1374 driver some time ago which used those transfers
> and they worked just fine.
I checked http://secure.netroedge.com/~lm78/supported.html,
http://secure.netroedge.com/~lm78/newdrivers.html and looked in the
lm_sensors-2.9.1 tarball before I started and didn't see a driver for
the DS1374 listed. That's why I threw mine together. Maybe I missed it.
I would have used I2C transfers myself, but was simply following what I
thought were current practices. Since this is my first I2C client, I
just blindly followed the documentation :) Oh well, wouldn't be the
first time I wandered down the wrong path.
Randy Vinson
^ permalink raw reply
* Re: [PATCH][5/5] RapidIO support: net driver over messaging
From: Matt Porter @ 2005-06-03 22:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: akpm, netdev, linux-kernel, torvalds, linuxppc-embedded, jgarzik
In-Reply-To: <20050602150543.7e4326b6@dxpl.pdx.osdl.net>
On Thu, Jun 02, 2005 at 03:05:43PM -0700, Stephen Hemminger wrote:
> How much is this like ethernet? does it still do ARP?
It's nothing like Ethernet, the only relation is that an Ethernet network
driver is easy to implement over top of raw message ports on a switched
fabric network. It gives easy access to RIO messaging from userspace
without inventing a new interface.
ARP works by the driver emulating a broadcast over RIO by sending the
same ARP packet to each node that is participating in the rionet. Nodes
join/leave the rionet by sending RIO-specific doorbell messages to
potential participants on the switched fabric. A table is kept to
flag active participants such that a fast lookup can be made to translate
the dst MAC address to a RIO device struct that is used to actually
send the Ethernet packet encapsulated into a standard RIO message
to the appropriate node(s).
> Can it do promiscious receive?
No.
> > +LIST_HEAD(rionet_peers);
>
> Does this have to be global?
Nope, should be static. Fixing.
> Not sure about the locking of this stuff, are you
> relying on the RTNL?
Yes, last I looked that was sufficient for all the entry points.
I protect the driver-specific data (tx skb rings, etc.) with
a private lock.
> > +
> > +static int rionet_change_mtu(struct net_device *ndev, int new_mtu)
> > +{
> > + struct rionet_private *rnet = ndev->priv;
> > +
> > + if (netif_msg_drv(rnet))
> > + printk(KERN_WARNING
> > + "%s: rionet_change_mtu(): not implemented\n", DRV_NAME);
> > +
> > + return 0;
> > +}
>
> If you can allow any mtu then don't need this at all.
> Or if you are limited then better return an error for bad values.
Ok, I do have a upper limit of 4082 as the RIO messages have a
max 4096 byte payload. That's the default on open as well. I'll
fix this up.
> > +static void rionet_set_multicast_list(struct net_device *ndev)
> > +{
> > + struct rionet_private *rnet = ndev->priv;
> > +
> > + if (netif_msg_drv(rnet))
> > + printk(KERN_WARNING
> > + "%s: rionet_set_multicast_list(): not implemented\n",
> > + DRV_NAME);
> > +}
>
> If you can't handle it then just leave dev->set_multicast_list
> as NULL and all attempts to add or delete will get -EINVAL
Will do. It was a placeholder at one point when I thought I might
emulate multicast in the driver...it's fallen down my priority
list.
> > +
> > +static int rionet_open(struct net_device *ndev)
> > +{
>
>
> > + /* Initialize inbound message ring */
> > + for (i = 0; i < RIONET_RX_RING_SIZE; i++)
> > + rnet->rx_skb[i] = NULL;
> > + rnet->rx_slot = 0;
> > + rionet_rx_fill(ndev, 0);
> > +
> > + rnet->tx_slot = 0;
> > + rnet->tx_cnt = 0;
> > + rnet->ack_slot = 0;
> > +
> > + spin_lock_init(&rnet->lock);
> > +
> > + rnet->msg_enable = RIONET_DEFAULT_MSGLEVEL;
>
> Better to do all initialization of the per device data
> in the place it is allocated (rio_setup_netdev)
Right, will do.
> > +static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
> > +{
> > + return -EOPNOTSUPP;
> > +}
>
> Unneeded, if dev->do_ioctl is NULL, then all private ioctl's will
> return -EINVAL that is what you want.
Ah, ok. Good, none of the MII stuff applies in this case.
> > +static u32 rionet_get_link(struct net_device *ndev)
> > +{
> > + return netif_carrier_ok(ndev);
> > +}
>
> Use ethtool_op_get_link
Ok
<snip>
> > + /* Fill in the driver function table */
> > + ndev->open = &rionet_open;
> > + ndev->hard_start_xmit = &rionet_start_xmit;
> > + ndev->stop = &rionet_close;
> > + ndev->get_stats = &rionet_stats;
> > + ndev->change_mtu = &rionet_change_mtu;
> > + ndev->set_mac_address = &rionet_set_mac_address;
> > + ndev->set_multicast_list = &rionet_set_multicast_list;
> > + ndev->do_ioctl = &rionet_ioctl;
> > + SET_ETHTOOL_OPS(ndev, &rionet_ethtool_ops);
> > +
> > + ndev->mtu = RIO_MAX_MSG_SIZE - 14;
> > +
> > + SET_MODULE_OWNER(ndev);
>
> Can you set any ndev->features to get better performance.
> Can you take >32bit data addresses? then set HIGHDMA
> You are doing your on locking, can you use LLTX?
> Does the hardware support scatter gather?
Some of these get tricky. In general, rionet could support
SG and with driver help we can flag IP_CSUM. In practice, the
current generation MPC85xx HW on my development system have
some problems with their message port dma queues. In short,
their implementation is such that the arch-specific code is
forced to do a copy of the skb on both tx and rx. Because of
this, adding SG/IP_CSUM doesn't have any value yet...it'll make
sense to add the addtional features once we get a platform with
better messaging hardware. HIGHDMA may not be suitable on all
platforms. Since rionet sits on top of a hardware abstraction,
it doesn't have full knowledge of the DMA capabilities of the
hardware. We can eventually have some interfaces to the arch
code to learn that info, but it's not there yet. I have to
look into LLTX, I know what it stands for, but I'm not sure
of the details. Do you have a good LLTX example reference?
That said, my goal is to enable as many features as possible
when we have hw to take advantage of them.
-Matt
^ permalink raw reply
* Re: ppc32: Rework power management take #3
From: Benjamin Herrenschmidt @ 2005-06-03 22:43 UTC (permalink / raw)
To: Wolfram Quester; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <20050603093316.GA4777@halley.zuhause>
> Normally I use rivafb, but I tried video=ofonly and did not get a
> freeze. I tried it three times and I hope that this is good statistics.
> With 2.6.12-rc2 and riva fb I got the freeze in about 80% of all initial
> suspends, with rc{4,5-git6} and riva fb I had it everytime. But it may
> still well be that there is a random component since I learned to
> workaround the problem by switching to tty1 and thus don't trigger the
> freeze condition that often.
Ok, what happens if you run rivafb, ssh into the box, and open a new tty
(that is leave the box on X, but do something like echo "toto"
>/dev/tty8) to create a new tty in the background.
Does that trigger the freeze ?
Ben.
^ permalink raw reply
* kernel ported from ELDK 3.0 hangs (loops in idled()) on my custom MPC870 Board
From: Edward Hong @ 2005-06-03 23:10 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to bring up Linux on a custom MPC870 Board using ELDK 3.0.=20
The ported kernel from ELDK 3.0 hangs (loops in idled()) and the kernel_thr=
ead=20
init never gets started!???
The board boots with the following messages:
U-Boot 1.0.2 (May 12 2005 - 15:05:46)
CPU: MPC885ZPnn at 132 MHz: 8 kB I-Cache 8 kB D-Cache FEC present
Board: Custom MPC870
I2C: ready
DRAM: 64 MB
FLASH: 64 MB
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET, FEC2 ETHERNET
Hit any key to stop autoboot: 0=20
=3D> run net_nfs
Using FEC ETHERNET device
TFTP from server 10.15.10.170; our IP address is 10.15.2.101
Filename 'vmlinux.UBoot'.
Load address: 0x200000
Loading: #################################################################
#################################################################
######
done
Bytes transferred =3D 691764 (a8e34 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.4.24-pre2
Created: 2005-06-03 16:17:44 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 691700 Bytes =3D 675.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.4.24-pre2 (ehong@chico) (gcc version 3.2.2 20030217 (Yellow=
=20
Dog Linux 3.0 3.2.2-2a_1)) #8 Fri Jun 3 10:13:10 MDT 2005 On node 0=20
totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs rw nfsroot=3D10.15.10.170:/opt/eldk/pp=
c_8xx=20
ip=3D10.15.2.101:10.15.10.170::::eth0:off panic=3D1
Decrementer Frequency =3D 495000000/60
Calibrating delay loop... 131.48 BogoMIPS
Memory: 63132k available (1204k kernel code, 360k data, 60k init, 0k highme=
m)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
(kernel loops in idled() after kernel_thread(init, ...) in rest_init().)=20
Here is the board info printed under u-boot:
=3D> bdinfo
memstart =3D 0x00000000
memsize =3D 0x04000000
flashstart =3D 0xF0000000
flashsize =3D 0x04000000
flashoffset =3D 0x0001F100
sramstart =3D 0x00000000
sramsize =3D 0x00000000
immr_base =3D 0xFFF00000
bootflags =3D 0x00000001
intfreq =3D 132 MHz
busfreq =3D 66 MHz
ethaddr =3D 00:D0:1C:01:02:00
IP addr =3D 10.15.2.101
baudrate =3D 38400 bps
The bd_info of kernel is copied from u-boot. The IMAP_ADDR of kernel uses=
=20
the same value as the U-Boot CFG_IMMR.=20
Thanks in advance for your help!
Edward
^ permalink raw reply
* [PATCH] [1/2] PM support for Ebony
From: Geoff Levand @ 2005-06-03 23:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded
I rebased this to apply to Benjamin's ppc32-rework-pm.diff, but
didn't recode it to take advantage of the extra hooks. More work
is certainly needed for wake-on-lan. Any comments on improvement
would be most welcome.
I could also make one available against a 2.6.12-rc if requested.
-Geoff
* pm-on-ebony.patch
This patch provides power management support for the IBM PPC440GP Ebony
Reference Platform. The main portion of the patch implements the platform
specific pm_ops structure required by the kernel power management sub-system.
The current implementation only supports suspend-to-memory (PM_SUSPEND_MEM),
though unpublished suspend-to-disk work has been started.
This implementation arranges for the U44 switch on the Ebony platform,
connected to the SMI interrupt handler, to be used as a system resume trigger.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
--
Index: linux-2.6.12-bhpm/arch/ppc/platforms/4xx/Kconfig
===================================================================
--- linux-2.6.12-bhpm.orig/arch/ppc/platforms/4xx/Kconfig 2005-06-03 16:14:44.000000000 -0700
+++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/Kconfig 2005-06-03 16:15:07.000000000 -0700
@@ -214,10 +214,6 @@
depends on 4xx
default y
-config PM
- bool "Power Management support (EXPERIMENTAL)"
- depends on 4xx && EXPERIMENTAL
-
choice
prompt "TTYS0 device and default console"
depends on 40x
Index: linux-2.6.12-bhpm/arch/ppc/platforms/4xx/Makefile
===================================================================
--- linux-2.6.12-bhpm.orig/arch/ppc/platforms/4xx/Makefile 2005-06-03 16:14:44.000000000 -0700
+++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/Makefile 2005-06-03 16:15:07.000000000 -0700
@@ -25,3 +25,6 @@
obj-$(CONFIG_405EP) += ibm405ep.o
obj-$(CONFIG_405GPR) += ibm405gpr.o
obj-$(CONFIG_VIRTEX_II_PRO) += virtex-ii_pro.o
+ifeq ($(CONFIG_PM),y)
+obj-$(CONFIG_EBONY) += ebony_pm.o ibm440gp_sleep.o
+endif
Index: linux-2.6.12-bhpm/arch/ppc/platforms/4xx/ebony_pm.c
===================================================================
--- linux-2.6.12-bhpm.orig/arch/ppc/platforms/4xx/ebony_pm.c 2005-06-01 08:52:49.947684744 -0700
+++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/ebony_pm.c 2005-06-03 16:15:07.000000000 -0700
@@ -0,0 +1,202 @@
+/*
+ * ebony_pm.c - This file contains the PM functions for Ebony.
+ *
+ * Copyright 2004 Sony Corp.
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/types.h>
+#include <linux/suspend.h>
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <asm/ibm44x.h>
+
+#define IBM_CPM_ALL (IBM_CPM_IIC0 | IBM_CPM_IIC1 | IBM_CPM_PCI | \
+ IBM_CPM_CPU | IBM_CPM_DMA | IBM_CPM_BGO | IBM_CPM_BGI | \
+ IBM_CPM_EBC | IBM_CPM_EBM | IBM_CPM_DMC | IBM_CPM_PLB | IBM_CPM_SRAM | \
+ IBM_CPM_PPM | IBM_CPM_UIC1 | IBM_CPM_GPIO0 | IBM_CPM_UART0 | IBM_CPM_UART1 | \
+ IBM_CPM_UIC0 | IBM_CPM_TMRCLK )
+
+#define UIC0_EIR5_BIT (1<<(31-28)) /* External Intr 5 == SMI */
+#define UIC0_UIC1NC_BIT (1<<(31-30))
+
+extern void serial8250_suspend_port_busy(int line);
+extern void serial8250_resume_port_busy(int line);
+
+void ibm440gp_sleep(__u32 CPM, __u32 MSR_OR);
+
+#define DEBUG
+
+#ifdef DEBUG
+
+/* #define USE_ETHER_TO_RESUME */
+
+static int __tm_printk(const char *fmt, ...)
+{
+ char buf[512];
+ va_list args;
+ int i;
+ unsigned long long tt;
+ unsigned long us, ms;
+
+ tt = sched_clock();
+ ms = tt >> 10; /* convert to usec */
+ us = ms % 1000;
+ ms = ms / 1000;
+
+ i = sprintf(buf, "%6.6lu.%3.3lums:", ms,us);
+ va_start(args, fmt);
+ i = vsnprintf(buf+i, sizeof(buf)-i, fmt, args);
+ va_end(args);
+ printk(buf);
+
+ return i;
+}
+
+#endif /* DEBUG */
+
+
+/*
+ * PM ops for EBONY board.
+ */
+
+static int ebony_pm_enter(suspend_state_t state)
+{
+ __u32 uic_save_er;
+ __u32 save_msr;
+ __u32 cpm_save_er;
+ __u32 cpm_er;
+
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ /* Save MSR and Stop all interrupts */
+ save_msr = mfmsr();
+ _nmask_and_or_msr((MSR_CE|MSR_EE), 0);
+
+ /* save current CPM */
+ cpm_save_er = mfdcr(DCRN_CPC0_ER);
+
+ /* save UIC0 enable registers */
+ uic_save_er = mfdcr(DCRN_UIC_ER(UIC0));
+
+#ifdef USE_ETHER_TO_RESUME
+ mtdcr(DCRN_UIC_ER(UIC0), UIC0_EIR5_BIT|UIC0_UIC1NC_BIT);
+#else
+ /* mask UIC0 interrupts, except External Intr #5 */
+ mtdcr(DCRN_UIC_ER(UIC0), UIC0_EIR5_BIT);
+#endif
+
+#ifdef DEBUG
+ __tm_printk("UIC0_ER:0x%8.8x -> 0x%8.8x\n",uic_save_er, mfdcr(DCRN_UIC_ER(UIC0)));
+#endif
+
+ /* set up CPM */
+ cpm_er = IBM_CPM_ALL & ~IBM_CPM_UIC0;
+#ifdef USE_ETHER_TO_RESUME
+ cpm_er &= ~CPM_UIC1;
+#endif
+
+#ifdef DEBUG
+ __tm_printk("UIC0_SR:0x%8.8x\n", mfdcr(DCRN_UIC_SR(UIC0)));
+ __tm_printk("CPM_ER:0x%8.8x\n", cpm_er);
+ __tm_printk("SLEEP\n");
+#endif
+
+ /* we need this to work with printk on serial console */
+ serial8250_suspend_port_busy(0);
+
+ /* Enable interrupts and Enter SLEEP mode */
+ ibm440gp_sleep(cpm_er, (MSR_EE|MSR_WE));
+
+ /* Stop all interrupts, again */
+ _nmask_and_or_msr((MSR_CE|MSR_EE), 0);
+
+ /* Restore CPM, before resume serials for printk() */
+ mtdcr(DCRN_CPC0_ER, cpm_save_er);
+
+ /* we need this to work with printk on serial console */
+ serial8250_resume_port_busy(0);
+
+ __tm_printk("WAKEUP\n");
+
+ /* Restore UIC0 enable registers */
+ mtdcr(DCRN_UIC_ER(UIC0), uic_save_er);
+
+ /* Restore MSR */
+ mtmsr(save_msr);
+
+ return 0;
+}
+
+static int ebony_pm_prepare(suspend_state_t state)
+{
+
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int ebony_pm_finish(suspend_state_t state)
+{
+ return 0;
+}
+
+static struct pm_ops ebony_pm_ops = {
+ .pm_disk_mode = PM_DISK_FIRMWARE,
+ .prepare = ebony_pm_prepare,
+ .enter = ebony_pm_enter,
+ .finish = ebony_pm_finish,
+};
+
+static int __init ebony_pm_init(void)
+{
+ pm_set_ops(&ebony_pm_ops);
+ return 0;
+}
+
+late_initcall(ebony_pm_init);
+
+/*
+ * SMI handler for resume
+ */
+
+#define PPC440GP_EXT_INT5_INTR 28 /* SMI: See ebony.c */
+
+static irqreturn_t
+smi_handler(int cpl, void *dev_id, struct pt_regs *regs)
+{
+#ifdef DEBUG
+ printk("SMI INTR\n");
+#endif
+ return IRQ_HANDLED;
+}
+
+static int __init init_smi(void)
+{
+ /* Enable SMI interrupt */
+ if (request_irq(PPC440GP_EXT_INT5_INTR, smi_handler,
+ SA_INTERRUPT, "SMI", NULL)) {
+ printk(KERN_ERR "SMI: cannot register IRQ:%d\n", PPC440GP_EXT_INT5_INTR);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+late_initcall(init_smi);
+
+
Index: linux-2.6.12-bhpm/arch/ppc/platforms/4xx/ibm440gp_sleep.S
===================================================================
--- linux-2.6.12-bhpm.orig/arch/ppc/platforms/4xx/ibm440gp_sleep.S 2005-06-01 08:52:49.947684744 -0700
+++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/ibm440gp_sleep.S 2005-06-03 16:15:07.000000000 -0700
@@ -0,0 +1,44 @@
+/*
+ * ibm440gp_sleep.S - This file contains the sleep function for 440GP CPU.
+ *
+ * Copyright 2004 Sony Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+#include <linux/config.h>
+#include <asm/processor.h>
+#include <asm/ppc_asm.h>
+
+
+ .text
+
+/*
+ * ibm440gp_sleep (CPC0_ER_VAL, MSR_OR_VAL)
+ * r3: new CPC0_ER value
+ * r4: MSR value to be OR
+ */
+_GLOBAL(ibm440gp_sleep)
+ mfmsr r0
+ or r0,r0,r4
+ sync
+ mtdcr 177,r3 // 177: DCRN_CPC0_ER
+ sync
+ mtmsr r0
+ sync
+
+ blr
+
+
Index: linux-2.6.12-bhpm/include/asm-ppc/ocp.h
===================================================================
--- linux-2.6.12-bhpm.orig/include/asm-ppc/ocp.h 2005-06-03 16:14:44.000000000 -0700
+++ linux-2.6.12-bhpm/include/asm-ppc/ocp.h 2005-06-03 16:15:07.000000000 -0700
@@ -151,13 +151,21 @@
static inline void
ocp_force_power_off(struct ocp_device *odev)
{
+#ifdef CONFIG_44x
+ mtdcr(DCRN_CPC0_FR, mfdcr(DCRN_CPC0_FR) | odev->def->pm);
+#else
mtdcr(DCRN_CPMFR, mfdcr(DCRN_CPMFR) | odev->def->pm);
+#endif
}
static inline void
ocp_force_power_on(struct ocp_device *odev)
{
+#ifdef CONFIG_44x
+ mtdcr(DCRN_CPC0_FR, mfdcr(DCRN_CPC0_FR) & ~odev->def->pm);
+#else
mtdcr(DCRN_CPMFR, mfdcr(DCRN_CPMFR) & ~odev->def->pm);
+#endif
}
#else
#define ocp_force_power_off(x) (void)(x)
-EOF
^ permalink raw reply
* [PATCH] [2/2] PM support for emac driver
From: Geoff Levand @ 2005-06-03 23:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded
This is a first attempt to add PM support to the PPC 440 emac
driver. Still needed are code to take care of the PHY chip,
and to support wake-on-lan. Any comments on how to do
those would be most welcome.
The 'PM support for Ebony' patch I posted can be used to test
on that platform.
-Geoff
* emac-pm.patch
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
--
Index: linux-2.6.12-bhpm/drivers/net/ibm_emac/ibm_emac_core.c
===================================================================
--- linux-2.6.12-bhpm.orig/drivers/net/ibm_emac/ibm_emac_core.c 2005-06-02 15:09:23.000000000 -0700
+++ linux-2.6.12-bhpm/drivers/net/ibm_emac/ibm_emac_core.c 2005-06-02 17:11:02.000000000 -0700
@@ -1306,7 +1306,7 @@
ep->ack_slot = 0;
}
-static void emac_reset_configure(struct ocp_enet_private *fep)
+static void emac_reset(struct ocp_enet_private *fep)
{
emac_t *emacp = fep->emacp;
int i;
@@ -1338,6 +1338,14 @@
/* Switch IRQs off for now */
out_be32(&emacp->em0iser, 0);
+}
+
+static void emac_reset_configure(struct ocp_enet_private *fep)
+{
+ emac_t *emacp = fep->emacp;
+
+ /* Reset EMAC */
+ emac_reset(fep);
/* Configure MAL rx channel */
mal_set_rcbs(fep->mal, fep->mal_rx_chan, DESC_BUF_SIZE_REG);
@@ -1615,20 +1623,10 @@
}
}
-static int emac_open(struct net_device *dev)
+static int emac_up(struct net_device *dev)
{
- struct ocp_enet_private *fep = dev->priv;
int rc;
-
- spin_lock_irq(&fep->lock);
-
- fep->opened = 1;
- netif_carrier_off(dev);
-
- /* Reset & configure the chip */
- emac_reset_configure(fep);
-
- spin_unlock_irq(&fep->lock);
+ struct ocp_enet_private *fep = dev->priv;
/* Request our interrupt lines */
rc = request_irq(dev->irq, emac_mac_irq, 0, "IBM EMAC MAC", dev);
@@ -1646,6 +1644,24 @@
return rc;
}
+static int emac_open(struct net_device *dev)
+{
+ struct ocp_enet_private *fep = dev->priv;
+
+ spin_lock_irq(&fep->lock);
+
+ fep->opened = 1;
+ netif_carrier_off(dev);
+
+ /* Reset & configure the chip */
+ emac_reset_configure(fep);
+
+ spin_unlock_irq(&fep->lock);
+
+ return emac_up(dev);
+
+}
+
static int emac_close(struct net_device *dev)
{
struct ocp_enet_private *fep = dev->priv;
@@ -1975,6 +1991,71 @@
return 0;
}
+#ifdef CONFIG_PM
+static int emac_suspend(struct ocp_device *pdev, u32 state)
+{
+ struct net_device *netdev = ocp_get_drvdata(pdev);
+ struct ocp_enet_private *fep = netdev->priv;
+
+ pr_debug("PM:emac_suspend:%d\n", state);
+
+ if(netif_running(netdev))
+ emac_close(netdev);
+
+ /* Stop timer and Reset the chip */
+ spin_lock_irq(&fep->lock);
+ del_timer(&fep->link_timer);
+ fep->opened = 0;
+ emac_reset(fep);
+ spin_unlock_irq(&fep->lock);
+
+ /* detach */
+ netif_device_detach(netdev);
+
+ /*
+ * Save current states then turn off EMAC and PHY
+ * according to specified state.
+ * make WOL(WakeupOnLan) enable, if needed
+ */
+ // XXX:TBD
+ pdev->current_state = state;
+
+ return 0;
+}
+
+static int emac_resume(struct ocp_device *pdev)
+{
+ struct net_device *netdev = ocp_get_drvdata(pdev);
+ struct ocp_enet_private *fep = netdev->priv;
+
+ pr_debug("emac_resume:\n");
+
+ /* Turn on EMAC and PHY and restore state */
+ // XXX:TBD
+ pdev->current_state = 0;
+
+ /* Reset & configure the chip then Restart Timer */
+ spin_lock_irq(&fep->lock);
+
+ fep->opened = 1;
+ netif_carrier_off(netdev);
+ emac_reset_configure(fep);
+
+ (fep->link_timer).expires = jiffies+1;
+ add_timer(&fep->link_timer);
+
+ spin_unlock_irq(&fep->lock);
+
+ /* attach */
+ netif_device_attach(netdev);
+
+ if(netif_running(netdev))
+ emac_up(netdev);
+
+ return 0;
+}
+#endif
+
/* Structure for a device driver */
static struct ocp_device_id emac_ids[] = {
{.vendor = OCP_ANY_ID,.function = OCP_FUNC_EMAC},
@@ -1987,6 +2068,10 @@
.probe = emac_probe,
.remove = emac_remove,
+#ifdef CONFIG_PM
+ .suspend = emac_suspend,
+ .resume = emac_resume,
+#endif
};
static int __init emac_init(void)
-EOF
^ permalink raw reply
* Re: [PATCH] [1/2] PM support for Ebony
From: Benjamin Herrenschmidt @ 2005-06-03 23:23 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-embedded
In-Reply-To: <42A0E640.4020304@am.sony.com>
On Fri, 2005-06-03 at 16:22 -0700, Geoff Levand wrote:
> I rebased this to apply to Benjamin's ppc32-rework-pm.diff, but
> didn't recode it to take advantage of the extra hooks. More work
> is certainly needed for wake-on-lan. Any comments on improvement
> would be most welcome.
>
> I could also make one available against a 2.6.12-rc if requested.
Ok, well, part of the issue here is that I'm about to rework the
rework ... I discussed with Pat Mochel, and we are about to kill pm_ops
completely and have the code structured differently. Instead of hooks,
have the arch code be called on state change and be "in charge".
I'll try to setup an Ebony here asap so I can keep your patches in sync
as well.
Ben.
^ permalink raw reply
* [PATCH] ppc32: Fix incorrect CPU_FTR fixup usage for unified caches
From: Kumar Gala @ 2005-06-03 23:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
(This fixes a bug and should go into 2.6.12 if possible.)
ppc32: Fix incorrect CPU_FTR fixup usage for unified caches
Runtime feature support for unified caches was testing a userland feature
flag (PPC_FEATURE_UNIFIED_CACHE) instead of a cpu feature flag
(CPU_FTR_SPLIT_ID_CACHE). Luckily the current defined bit mask for cpu
features and userland features do not overlap so this only causes an issue on
machines with a unified cache, which is extremely rare on PPC today.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 5366c2d4a4190a10bd39f383647c933db5d3a090
tree cd28d190cf8742bb01c13c02f4199db217298ca4
parent 22774efc1bef9f9a0fd9b34d44bf10da787e3d91
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 03 Jun 2005 18:45:19 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 03 Jun 2005 18:45:19 -0500
arch/ppc/kernel/misc.S | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
--- a/arch/ppc/kernel/misc.S
+++ b/arch/ppc/kernel/misc.S
@@ -619,7 +619,7 @@ _GLOBAL(flush_instruction_cache)
_GLOBAL(flush_icache_range)
BEGIN_FTR_SECTION
blr /* for 601, do nothing */
-END_FTR_SECTION_IFSET(PPC_FEATURE_UNIFIED_CACHE)
+END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE)
li r5,L1_CACHE_LINE_SIZE-1
andc r3,r3,r5
subf r4,r3,r4
@@ -736,7 +736,7 @@ _GLOBAL(flush_dcache_all)
_GLOBAL(__flush_dcache_icache)
BEGIN_FTR_SECTION
blr /* for 601, do nothing */
-END_FTR_SECTION_IFSET(PPC_FEATURE_UNIFIED_CACHE)
+END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE)
rlwinm r3,r3,0,0,19 /* Get page base address */
li r4,4096/L1_CACHE_LINE_SIZE /* Number of lines in a page */
mtctr r4
@@ -764,7 +764,7 @@ END_FTR_SECTION_IFSET(PPC_FEATURE_UNIFIE
_GLOBAL(__flush_dcache_icache_phys)
BEGIN_FTR_SECTION
blr /* for 601, do nothing */
-END_FTR_SECTION_IFSET(PPC_FEATURE_UNIFIED_CACHE)
+END_FTR_SECTION_IFCLR(CPU_FTR_SPLIT_ID_CACHE)
mfmsr r10
rlwinm r0,r10,0,28,26 /* clear DR */
mtmsr r0
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Benjamin Herrenschmidt @ 2005-06-03 23:56 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux PPC Embedded list, linuxppc-dev list
In-Reply-To: <Pine.LNX.4.62.0506031001180.15256@numbat.sonytel.be>
On Fri, 2005-06-03 at 10:01 +0200, Geert Uytterhoeven wrote:
> On Fri, 3 Jun 2005, Simon Richter wrote:
> > Kumar Gala wrote:
> >
> > > apus
> >
> > I have such a beast and would like to get 2.6 to compile and work again
> > for APUS.
>
> Please coordinate with Roman Zippel.
Damn ! I had hoped APUS would just die ... :)
Ben.
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Benjamin Herrenschmidt @ 2005-06-03 23:56 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0506031001460.15256@numbat.sonytel.be>
On Fri, 2005-06-03 at 10:02 +0200, Geert Uytterhoeven wrote:
> On Fri, 3 Jun 2005, Pavel Fedin wrote:
> > Kumar Gala wrote:
> > > One issue that comes up from time to time is knowing who to contact about
> > > some of the various boards that are supported for PPC. I've suggested in
> > > the past that we create a MAINTAINERS file in arch/ppc/platforms.
> >
> > I am an owner of PegasosII board. You didn't mention it here.
>
> Pegasos II is CHRP, hence under common (and BenH will take care of it? ;-).
Yup, and Sven Luther is the actual maintainer of that bit of chrp.
Ben.
^ permalink raw reply
* [PATCH][UPDATE] ppc32: Converted MPC10X bridge to use platform devices instead of OCP
From: Kumar Gala @ 2005-06-04 0:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0506031532120.8389@nylon.am.freescale.net>
(The previous version of the patch had a minor bug)
Converted the MPC10x bridge support (used by MPC10x and 8240/1/5) to
used the standard platform device model.
Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit c4fa624a5c007f17142ab5225d1085564ffa8f83
tree 63546f2e7de561696db29a0a481bf40c449e9f0e
parent e832e0d9e4878d02ab2ef6bad5971dc9f9cd7679
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 03 Jun 2005 14:20:50 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 03 Jun 2005 14:20:50 -0500
arch/ppc/Kconfig | 5 -
arch/ppc/kernel/setup.c | 4
arch/ppc/syslib/Makefile | 2
arch/ppc/syslib/mpc10x_common.c | 183 ++++++++++++++++++++++++++++++----------
include/asm-ppc/mpc10x.h | 6 +
include/asm-ppc/ppc_sys.h | 2
6 files changed, 149 insertions(+), 53 deletions(-)
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -826,11 +826,6 @@ config MPC10X_BRIDGE
depends on PCORE || POWERPMC250 || LOPEC || SANDPOINT
default y
-config FSL_OCP
- bool
- depends on MPC10X_BRIDGE
- default y
-
config MPC10X_OPENPIC
bool
depends on POWERPMC250 || LOPEC || SANDPOINT
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -41,7 +41,7 @@
#include <asm/xmon.h>
#include <asm/ocp.h>
-#if defined(CONFIG_85xx) || defined(CONFIG_83xx)
+#if defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_MPC10X_BRIDGE)
#include <asm/ppc_sys.h>
#endif
@@ -249,7 +249,7 @@ int show_cpuinfo(struct seq_file *m, voi
seq_printf(m, "bogomips\t: %lu.%02lu\n",
lpj / (500000/HZ), (lpj / (5000/HZ)) % 100);
-#if defined(CONFIG_85xx) || defined(CONFIG_83xx)
+#if defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_MPC10X_BRIDGE)
if (cur_ppc_sys_spec->ppc_sys_name)
seq_printf(m, "chipset\t\t: %s\n",
cur_ppc_sys_spec->ppc_sys_name);
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -92,7 +92,7 @@ ifeq ($(CONFIG_SERIAL_MPSC_CONSOLE),y)
obj-$(CONFIG_SERIAL_TEXT_DEBUG) += mv64x60_dbg.o
endif
obj-$(CONFIG_BOOTX_TEXT) += btext.o
-obj-$(CONFIG_MPC10X_BRIDGE) += mpc10x_common.o indirect_pci.o
+obj-$(CONFIG_MPC10X_BRIDGE) += mpc10x_common.o indirect_pci.o ppc_sys.o
obj-$(CONFIG_MPC10X_OPENPIC) += open_pic.o
obj-$(CONFIG_40x) += dcr.o
obj-$(CONFIG_BOOKE) += dcr.o
diff --git a/arch/ppc/syslib/mpc10x_common.c b/arch/ppc/syslib/mpc10x_common.c
--- a/arch/ppc/syslib/mpc10x_common.c
+++ b/arch/ppc/syslib/mpc10x_common.c
@@ -21,6 +21,9 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/slab.h>
+#include <linux/serial_8250.h>
+#include <linux/fsl_devices.h>
+#include <linux/device.h>
#include <asm/byteorder.h>
#include <asm/io.h>
@@ -30,16 +33,7 @@
#include <asm/pci-bridge.h>
#include <asm/open_pic.h>
#include <asm/mpc10x.h>
-#include <asm/ocp.h>
-
-/* The OCP structure is fixed by code below, before OCP initialises.
- paddr depends on where the board places the EUMB.
- - fixed in mpc10x_bridge_init().
- irq depends on two things:
- > does the board use the EPIC at all? (PCORE does not).
- > is the EPIC in serial or parallel mode?
- - fixed in mpc10x_set_openpic().
-*/
+#include <asm/ppc_sys.h>
#ifdef CONFIG_MPC10X_OPENPIC
#ifdef CONFIG_EPIC_SERIAL_MODE
@@ -51,34 +45,127 @@
#define MPC10X_DMA0_IRQ (EPIC_IRQ_BASE + 1 + NUM_8259_INTERRUPTS)
#define MPC10X_DMA1_IRQ (EPIC_IRQ_BASE + 2 + NUM_8259_INTERRUPTS)
#else
-#define MPC10X_I2C_IRQ OCP_IRQ_NA
-#define MPC10X_DMA0_IRQ OCP_IRQ_NA
-#define MPC10X_DMA1_IRQ OCP_IRQ_NA
+#define MPC10X_I2C_IRQ -1
+#define MPC10X_DMA0_IRQ -1
+#define MPC10X_DMA1_IRQ -1
#endif
-
-struct ocp_def core_ocp[] = {
- { .vendor = OCP_VENDOR_INVALID
- }
+static struct fsl_i2c_platform_data mpc10x_i2c_pdata = {
+ .device_flags = 0,
};
-static struct ocp_fs_i2c_data mpc10x_i2c_data = {
- .flags = 0
+static struct plat_serial8250_port serial_platform_data[] = {
+ { },
};
-static struct ocp_def mpc10x_i2c_ocp = {
- .vendor = OCP_VENDOR_MOTOROLA,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .additions = &mpc10x_i2c_data
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC10X_IIC1] = {
+ .name = "fsl-i2c",
+ .id = 1,
+ .dev.platform_data = &mpc10x_i2c_pdata,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_I2C_OFFSET,
+ .end = MPC10X_EUMB_I2C_OFFSET +
+ MPC10X_EUMB_I2C_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ
+ },
+ },
+ },
+ [MPC10X_DMA0] = {
+ .name = "fsl-dma",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_DMA_OFFSET + 0x10,
+ .end = MPC10X_EUMB_DMA_OFFSET + 0x1f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC10X_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_DMA_OFFSET + 0x20,
+ .end = MPC10X_EUMB_DMA_OFFSET + 0x2f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC10X_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC10X_EUMB_DMA_OFFSET + 0x20,
+ .end = MPC10X_EUMB_DMA_OFFSET + 0x2f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC10X_DUART] = {
+ .name = "serial8250",
+ .id = 0,
+ .dev.platform_data = serial_platform_data,
+ },
};
-static struct ocp_def mpc10x_dma_ocp[2] = {
-{ .vendor = OCP_VENDOR_MOTOROLA,
- .function = OCP_FUNC_DMA,
- .index = 0 },
-{ .vendor = OCP_VENDOR_MOTOROLA,
- .function = OCP_FUNC_DMA,
- .index = 1 }
+/* We use the PCI ID to match on */
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ {
+ .ppc_sys_name = "8245",
+ .mask = 0xFFFFFFFF,
+ .value = MPC10X_BRIDGE_8245,
+ .num_devices = 4,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC10X_IIC1, MPC10X_DMA0, MPC10X_DMA1, MPC10X_DUART,
+ },
+ },
+ {
+ .ppc_sys_name = "8240",
+ .mask = 0xFFFFFFFF,
+ .value = MPC10X_BRIDGE_8240,
+ .num_devices = 3,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC10X_IIC1, MPC10X_DMA0, MPC10X_DMA1,
+ },
+ },
+ {
+ .ppc_sys_name = "107",
+ .mask = 0xFFFFFFFF,
+ .value = MPC10X_BRIDGE_107,
+ .num_devices = 3,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC10X_IIC1, MPC10X_DMA0, MPC10X_DMA1,
+ },
+ },
+ { /* default match */
+ .ppc_sys_name = "",
+ .mask = 0x00000000,
+ .value = 0x00000000,
+ },
};
/* Set resources to match bridge memory map */
@@ -132,7 +219,7 @@ mpc10x_bridge_init(struct pci_controller
uint new_map,
uint phys_eumb_base)
{
- int host_bridge, picr1, picr1_bit;
+ int host_bridge, picr1, picr1_bit, i;
ulong pci_config_addr, pci_config_data;
u_char pir, byte;
@@ -273,7 +360,7 @@ mpc10x_bridge_init(struct pci_controller
printk("Host bridge in Agent mode\n");
/* Read or Set LMBAR & PCSRBAR? */
}
-
+
/* Set base addr of the 8240/107 EUMB. */
early_write_config_dword(hose,
0,
@@ -287,17 +374,6 @@ mpc10x_bridge_init(struct pci_controller
ioremap(phys_eumb_base + MPC10X_EUMB_EPIC_OFFSET,
MPC10X_EUMB_EPIC_SIZE);
#endif
- mpc10x_i2c_ocp.paddr = phys_eumb_base + MPC10X_EUMB_I2C_OFFSET;
- mpc10x_i2c_ocp.irq = MPC10X_I2C_IRQ;
- ocp_add_one_device(&mpc10x_i2c_ocp);
- mpc10x_dma_ocp[0].paddr = phys_eumb_base +
- MPC10X_EUMB_DMA_OFFSET + 0x100;
- mpc10x_dma_ocp[0].irq = MPC10X_DMA0_IRQ;
- ocp_add_one_device(&mpc10x_dma_ocp[0]);
- mpc10x_dma_ocp[1].paddr = phys_eumb_base +
- MPC10X_EUMB_DMA_OFFSET + 0x200;
- mpc10x_dma_ocp[1].irq = MPC10X_DMA1_IRQ;
- ocp_add_one_device(&mpc10x_dma_ocp[1]);
}
#ifdef CONFIG_MPC10X_STORE_GATHERING
@@ -306,6 +382,23 @@ mpc10x_bridge_init(struct pci_controller
mpc10x_disable_store_gathering(hose);
#endif
+ /* setup platform devices for MPC10x bridges */
+ identify_ppc_sys_by_id (host_bridge);
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ unsigned int dev_id = cur_ppc_sys_spec->device_list[i];
+ ppc_sys_fixup_mem_resource(&ppc_sys_platform_devices[dev_id],
+ phys_eumb_base);
+ }
+
+ /* IRQ's are determined at runtime */
+ ppc_sys_platform_devices[MPC10X_IIC1].resource[1].start = MPC10X_I2C_IRQ;
+ ppc_sys_platform_devices[MPC10X_IIC1].resource[1].end = MPC10X_I2C_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA0].resource[1].start = MPC10X_DMA0_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA0].resource[1].end = MPC10X_DMA0_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA1].resource[1].start = MPC10X_DMA1_IRQ;
+ ppc_sys_platform_devices[MPC10X_DMA1].resource[1].end = MPC10X_DMA1_IRQ;
+
/*
* 8240 erratum 26, 8241/8245 erratum 29, 107 erratum 23: speculative
* PCI reads may return stale data so turn off.
@@ -330,7 +423,7 @@ mpc10x_bridge_init(struct pci_controller
* 8245 (Rev 2., dated 10/2003) says PICR2[0] is reserverd.
*/
if (host_bridge == MPC10X_BRIDGE_8245) {
- ulong picr2;
+ u32 picr2;
early_read_config_dword(hose, 0, PCI_DEVFN(0,0),
MPC10X_CFG_PICR2_REG, &picr2);
diff --git a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
--- a/include/asm-ppc/mpc10x.h
+++ b/include/asm-ppc/mpc10x.h
@@ -159,6 +159,12 @@ extern unsigned long ioremap_base;
#define MPC10X_MAPA_EUMB_BASE (ioremap_base - MPC10X_EUMB_SIZE)
#define MPC10X_MAPB_EUMB_BASE MPC10X_MAPA_EUMB_BASE
+enum ppc_sys_devices {
+ MPC10X_IIC1,
+ MPC10X_DMA0,
+ MPC10X_DMA1,
+ MPC10X_DUART,
+};
int mpc10x_bridge_init(struct pci_controller *hose,
uint current_map,
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -27,6 +27,8 @@
#include <asm/mpc85xx.h>
#elif defined(CONFIG_PPC_MPC52xx)
#include <asm/mpc52xx.h>
+#elif defined(CONFIG_MPC10X_BRIDGE)
+#include <asm/mpc10x.h>
#else
#error "need definition of ppc_sys_devices"
#endif
^ permalink raw reply
* Re: [PATCH] [1/2] PM support for Ebony
From: Eugene Surovegin @ 2005-06-04 0:51 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-embedded
In-Reply-To: <42A0E640.4020304@am.sony.com>
On Fri, Jun 03, 2005 at 04:22:40PM -0700, Geoff Levand wrote:
[snip]
> + /* save current CPM */
> + cpm_save_er = mfdcr(DCRN_CPC0_ER);
> +
> + /* save UIC0 enable registers */
> + uic_save_er = mfdcr(DCRN_UIC_ER(UIC0));
> +
> +#ifdef USE_ETHER_TO_RESUME
> + mtdcr(DCRN_UIC_ER(UIC0), UIC0_EIR5_BIT|UIC0_UIC1NC_BIT);
> +#else
> + /* mask UIC0 interrupts, except External Intr #5 */
> + mtdcr(DCRN_UIC_ER(UIC0), UIC0_EIR5_BIT);
> +#endif
Why UIC PM code is here and not in ppc4xx_pic.c? I don't think this is
the right place to mess with UIC registers.
[snip]
> ===================================================================
> --- linux-2.6.12-bhpm.orig/arch/ppc/platforms/4xx/ibm440gp_sleep.S 2005-06-01 08:52:49.947684744 -0700
> +++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/ibm440gp_sleep.S 2005-06-03 16:15:07.000000000 -0700
I think it should be in arch/ppc/syslib not in arch/ppc/platforms/4xx.
--
Eugene
^ permalink raw reply
* Re: [PATCH] [2/2] PM support for emac driver
From: Eugene Surovegin @ 2005-06-04 0:53 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-embedded
In-Reply-To: <42A0E647.80604@am.sony.com>
On Fri, Jun 03, 2005 at 04:22:47PM -0700, Geoff Levand wrote:
> This is a first attempt to add PM support to the PPC 440 emac
> driver. Still needed are code to take care of the PHY chip,
> and to support wake-on-lan. Any comments on how to do
> those would be most welcome.
Just FYI, there are plans to get rid of the current buggy EMAC driver
and replace it with the new NAPI one (http://kernel.ebshome.net).
--
Eugene
^ 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