[RFC] handle access to non-present IO ports on 8xx
On Thu, 2005-06-02 at 14:02 -0300, Marcelo Tosatti wrote: Hi Ben, On Thu, Jun 02, 2005 at 12:46:32PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote: Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With proper PCMCIA controllers, those are swallowed properly when the card is removed. The eating of the machine check is a bit too hackish to my taste... Better is to not do that by making sure the legacy crap isn't trying to tap unexisting ports, but then, if PCMCIA is also a problem... Well, cardmgr calls the driver's shutdown/close routine as soon as the card is removed. Some of those methods write to IO registers in the process (eg net/pcmcia/pcnet_cs.c). I dont see any elegant change that could be done in PCMCIA. I know, the thing is, on platforms with a classical PCI-PCMCIA bridge, the bridge will not issue machine checks when the card is removed. I don't know if that is possible with your HW setup, I suppose you are hooking PCMCIA directly to the CPU IO bus ... One possibility that comes to mind would be to enforce the rule that drivers should not writeout in case of a removal event, They can't know, they get the removal even too late. The driver may be in the middle of writing when you remove the card. If there is no HW way to prevent the machine check, then you'll need software recovery. but that does not sound feasible to me: It just looks too messy, however I have no good argument against it. Well, its restricted to 8xx (maybe 32-bit PPC) with PCMCIA, so its just not worth the trouble? Hehe... dunno. Hmmm... I'll look that up. My limited testing on HW in question does not exhibit longer MCE delays than twi/isync/nop sequence - actually, it is always triggered during the IO access instruction itself. I suppose the 8xx may actually be quite synchronous on IOs then... Where can I find information about write posting on 8xx? Is there a term for it used in PPC documentation? I can't find anything... Well, do you have a store queue ? What does the 8xx manual says about ordering queueing of non cacheable loads stores ? Maybe the chip is fully synchronous on IOs ?
Getting ownership for various boards/platforms configs
Hi, Kumar Gala wrote: apus I have such a beast and would like to get 2.6 to compile and work again for APUS. Simon -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 374 bytes Desc: OpenPGP digital signature Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050603/be4510d9/attachment.pgp
Getting ownership for various boards/platforms configs
On Thu, 2005-06-02 at 17:00 -0700, Mark A. Greer wrote: Two things: 1) What is common in your list? 2) On a slightly different note...if no one volunteers to look after the following ones, I vote to remove them: k2 lopec mcpn765 menf1Dead (Matt Porter) pmac :) What is pmac here ? PowerMac or some other board ? :) Ben.
Getting ownership for various boards/platforms configs
On Thu, 2005-06-02 at 19:09 -0500, Kumar Gala wrote: On Jun 2, 2005, at 7:00 PM, Mark A. Greer wrote: Two things: 1) What is common in your list? Good question, hopefully Paul knows. I just did an ls in arch/ppc/configs/ to create the list. it's pmac+chrp+prep in a single image Ben.
Getting ownership for various boards/platforms configs
Ben, Can I put you do for maintainer of pmac and common? any others? - kumar On Jun 2, 2005, at 7:22 PM, Benjamin Herrenschmidt wrote: On Thu, 2005-06-02 at 19:09 -0500, Kumar Gala wrote: On Jun 2, 2005, at 7:00 PM, Mark A. Greer wrote: Two things: 1) What is common in your list? Good question, hopefully Paul knows. I just did an ls in arch/ppc/configs/ to create the list. it's pmac+chrp+prep in a single image Ben.
[RFC] PlatformDevice definitions for 82xx
On Jun 2, 2005, at 11:16 AM, Vitaly Bordug wrote: Hi! This adds platform definition files for 82xx, while the platform_info is filled in board-specific .C file residing in platforms/82xx. Another disputable thing I did - I moved m8260_setup.c from the syslib/ up to platforms/82xx/. The file was slightly changed - added 2 prototypes from the cpm2_pic.h and removed the respective include. Why the move of m8260_setup.c? Also, if this is required can we do this as two different patches so we can see clearly any changes also maded to m8260_setup.c mpc82xx_devices.c need a bit of work we need to at least cover the same set of devices that 85xx does for the CPM: SPI, I2C, USB, SCC1-4, FCC1-3, MCC1-2, SMC1-2 Additionally, the device name can not me FS_ENET_NAME, which assumes that FCC is only used for enet. mpc82xx_sys.c: what is the .value field? is this the IMMR and if so why bother shifting it? Also there are a whole bunch of variants that need to be captured Let's get clean versions of these two files before we worry about how to handle FCC enet specific bits. - kumar
[PATCH][1/5] RapidIO support: core
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.
And why the __rio* stuff for public functions? You should drop the __
part.
+RIO_OP_READ(8, u8, 1)
+RIO_OP_READ(16, u16, 2)
+RIO_OP_READ(32, u32, 4)
+RIO_OP_WRITE(8, u8, 1)
+RIO_OP_WRITE(16, u16, 2)
+RIO_OP_WRITE(32, u32, 4)
+
+EXPORT_SYMBOL(rio_mport_read_config_8);
+EXPORT_SYMBOL(rio_mport_read_config_16);
+EXPORT_SYMBOL(rio_mport_read_config_32);
+EXPORT_SYMBOL(rio_mport_write_config_8);
+EXPORT_SYMBOL(rio_mport_write_config_16);
+EXPORT_SYMBOL(rio_mport_write_config_32);
Again the odd indenting.
+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.
+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.
+static struct bin_attribute rio_config_attr = {
+ .attr = {
+ .name = config,
+ .mode = S_IRUGO | S_IWUSR,
+ .owner = THIS_MODULE,
+ },
+ .size = 0x20,
+ .read = rio_read_config,
+ .write = rio_write_config,
+};
Wow, that's a huge config space (just a comment, not an issue...)
thanks,
greg k-h
[PATCH][1/5] RapidIO support: core
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/ ?
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...
thanks,
greg k-h
Booting the linux-ppc64 kernel flattened device tree v0.4
On Wed, 2005-06-01 at 18:28 +1000, Benjamin Herrenschmidt wrote:
Here is the kernel patch. It applies on top of the various prom_init.c
bug fixes that I already posted today on the linuxppc-dev
linuxppc64-dev lists (those will be in the next -mm and maybe in
2.6.12).
This patch is intended to hit upstream by 2.6.13
Ok, the patch I posted with version 0.4 implementing version 0x10 of the
format was broken, here is a fixed version against current linus git
as of today:
Index: linux-work/arch/ppc64/kernel/prom_init.c
===
--- linux-work.orig/arch/ppc64/kernel/prom_init.c 2005-06-03
16:52:28.0 +1000
+++ linux-work/arch/ppc64/kernel/prom_init.c2005-06-03 16:58:01.0
+1000
@@ -1534,7 +1534,8 @@
*/
#define MAX_PROPERTY_NAME 64
-static void __init scan_dt_build_strings(phandle node, unsigned long
*mem_start,
+static void __init scan_dt_build_strings(phandle node,
+unsigned long *mem_start,
unsigned long *mem_end)
{
unsigned long offset = reloc_offset();
@@ -1547,16 +1548,21 @@
/* get and store all property names */
prev_name = RELOC();
for (;;) {
- int rc;
-
/* 64 is max len of name including nul. */
namep = make_room(mem_start, mem_end, MAX_PROPERTY_NAME, 1);
- rc = call_prom(nextprop, 3, 1, node, prev_name, namep);
- if (rc != 1) {
+ if (call_prom(nextprop, 3, 1, node, prev_name, namep) != 1) {
/* No more nodes: unwind alloc */
*mem_start = (unsigned long)namep;
break;
}
+
+ /* skip name */
+ if (strcmp(namep, RELOC(name)) == 0) {
+ *mem_start = (unsigned long)namep;
+ prev_name = RELOC(name);
+ continue;
+ }
+ /* get/create string entry */
soff = dt_find_string(namep);
if (soff != 0) {
*mem_start = (unsigned long)namep;
@@ -1571,7 +1577,7 @@
/* do all our children */
child = call_prom(child, 1, 1, node);
- while (child != (phandle)0) {
+ while (child != 0) {
scan_dt_build_strings(child, mem_start, mem_end);
child = call_prom(peer, 1, 1, child);
}
@@ -1580,16 +1586,13 @@
static void __init scan_dt_build_struct(phandle node, unsigned long *mem_start,
unsigned long *mem_end)
{
- int l, align;
phandle child;
- char *namep, *prev_name, *sstart, *p, *ep;
+ char *namep, *prev_name, *sstart, *p, *ep, *lp, *path;
unsigned long soff;
unsigned char *valp;
unsigned long offset = reloc_offset();
- char pname[MAX_PROPERTY_NAME];
- char *path;
-
- path = RELOC(prom_scratch);
+ static char pname[MAX_PROPERTY_NAME];
+ int l;
dt_push_token(OF_DT_BEGIN_NODE, mem_start, mem_end);
@@ -1599,23 +1602,33 @@
namep, *mem_end - *mem_start);
if (l = 0) {
/* Didn't fit? Get more room. */
- if (l+1 *mem_end - *mem_start) {
+ if ((l+1) (*mem_end - *mem_start)) {
namep = make_room(mem_start, mem_end, l+1, 1);
call_prom(package-to-path, 3, 1, node, namep, l);
}
namep[l] = '\0';
+
/* Fixup an Apple bug where they have bogus \0 chars in the
* middle of the path in some properties
*/
for (p = namep, ep = namep + l; p ep; p++)
if (*p == '\0') {
memmove(p, p+1, ep - p);
- ep--; l--;
+ ep--; l--; p--;
}
- *mem_start = _ALIGN(((unsigned long) namep) + strlen(namep) +
1, 4);
+
+ /* now try to extract the unit name in that mess */
+ for (p = namep, lp = NULL; *p; p++)
+ if (*p == '/')
+ lp = p + 1;
+ if (lp != NULL)
+ memmove(namep, lp, strlen(lp) + 1);
+ *mem_start = _ALIGN(((unsigned long) namep) +
+ strlen(namep) + 1, 4);
}
/* get it again for debugging */
+ path = RELOC(prom_scratch);
memset(path, 0, PROM_SCRATCH_SIZE);
call_prom(package-to-path, 3, 1, node, path, PROM_SCRATCH_SIZE-1);
@@ -1623,23 +1636,27 @@
prev_name = RELOC();
sstart = (char *)RELOC(dt_string_start);
for (;;) {
- int rc;
-
- rc = call_prom(nextprop, 3, 1, node, prev_name, pname);
-
Getting ownership for various boards/platforms configs
Dnia 2005-06-03 01:19, U?ytkownik Kumar Gala napisa?: 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've started with a list of all the _defconfigs that we have and would like to see if we can get contacts for the boards. All this list is meant to be is a contact point. There is another issue.. May I suggest to add one full-custom board? There are a lot of changes to do inside uart,fec,fcc drivers with a lot of #ifdefs, just because different use of mpc resources on different boards. Why it's not configured via menuconfig? Another nice example is inside status_led.h...
Getting ownership for various boards/platforms configs
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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
starting RAM adress for linux kernel
Hello, We have a platform similar to MPC885ADS (xith Kernel version 2.4.26) except that : - the RAM is at 0x0300 (size 0x1000) - the flash is at 0x0280 (size 0x0020) - IMMR = 0x0220 After u-boot on MPC885ADS, we get the following platform information : - RAM at 0 size 0x0080 - FLASH at 0xFE00 size 0x0020 - IMMR at 0xFF00 This information is different from the documentation of MPC885ADS : - FLASH at 0x0280 size 0x0080 - IMMR at 0x0220 1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 : it isn't true on our board : - can linux work with RAM not beginning at 0 on this board ? - what modifications should we make in the kernel to accept RAM at 0x0300 ? 2) is brd_info the only structure given to kernel by u-boot ? That is to say is it the only way for the kernel to have information about the boad ? 4) are the following values important if CONFIG_HIGHMEM is not defined (they are automatically generated by our Metrowerks PCS tool in autoconf.h ) ? #define CONFIG_HIGHMEM_START 0xfe00 #define CONFIG_LOWMEM_SIZE 0x3000 #define CONFIG_KERNEL_START 0xc000 #define CONFIG_TASK_SIZE 0x8000 Should we change these values if CONFIG_HIGHMEM is not defined ? 5) is the base value of IMMR very important (real value in u-boot different from documentation) ? Thanks really for your help. Sophie CARAYOL.
RTnet broadcast
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. best regards P.G _ ?? MSN Messenger: http://messenger.msn.com/cn
[RFC] handle access to non-present IO ports on 8xx
Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With proper PCMCIA controllers, those are swallowed properly when the card is removed. The eating of the machine check is a bit too hackish to my taste... Better is to not do that by making sure the legacy crap isn't trying to tap unexisting ports, but then, if PCMCIA is also a problem... Well, cardmgr calls the driver's shutdown/close routine as soon as the card is removed. Some of those methods write to IO registers in the process (eg net/pcmcia/pcnet_cs.c). I dont see any elegant change that could be done in PCMCIA. I know, the thing is, on platforms with a classical PCI-PCMCIA bridge, the bridge will not issue machine checks when the card is removed. I don't know if that is possible with your HW setup, I suppose you are hooking PCMCIA directly to the CPU IO bus ... I forget if I pointed this out already or not, but there's a good chance the mchecks you are seeing are from a bad PCMCIA implementation, not the 8xx itself. PCMCIA uses WAIT, which is a negative ACK really, and that must be pulled up externally, so if you remove the card any active WAIT goes away. I'd be glad to take a look at the schematics if available and tell you if I think there might be a problem there. Then again, maybe it doesn't matter where the mchecks are coming from, you just need to handle them... Mark Chambers
Booting the linux-ppc64 kernel flattened device tree v0.4
On Thu, Jun 02, 2005 at 05:09:18PM +1000, David Gibson wrote: On Wed, Jun 01, 2005 at 06:26:30PM +1000, Benjamin Herrenschmidt wrote: DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies). Here's the fourth version of my document along with new kernel patches for the new improved flattened format, and the first release of the device-tree compiler tool. The patches will be posted as a reply to this email. The compiler, dtc, can be downloaded, the URL is in the document. [snip] IV - dtc, the device tree compiler dtc source code can be found at http://ozlabs.org/~dgibson/dtc/dtc.tar.gz I've just updated the dtc tarball with a new version. Notable changes: - Corrected comment parsing - Corrected handling of #address-cells, #size-cells properties - Input from device tree blobs should actually work now - Corrected autogeneration of name properties in blob/asm output version 0x10 - Added a TODO list And yet another. Notable changes: - Basic generation of the reserve map in blob output, use -R command line option to leave space for a number of reserve map entries to be filled in by bootloader. - Rewrite blob and assembler output to better share code, and produce more readable assembler output. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson
starting RAM adress for linux kernel
Dear Sophie, in message OFED9D0639.75930571-ONC1257015.0031274C at brime.fr you wrote: We have a platform similar to MPC885ADS (xith Kernel version 2.4.26) except that : - the RAM is at 0x0300 (size 0x1000) - the flash is at 0x0280 (size 0x0020) - IMMR = 0x0220 Ummm - just to avoid any misunderstandings: there is no technical reason for such a memory map, and no other good reason either as such a configuration will not be able to run Linux. After u-boot on MPC885ADS, we get the following platform information : - RAM at 0 size 0x0080 - FLASH at 0xFE00 size 0x0020 - IMMR at 0xFF00 This information is different from the documentation of MPC885ADS : - FLASH at 0x0280 size 0x0080 - IMMR at 0x0220 So what is your problem? The memory map ist just something you define as it fits your project. The values in the MPC885ADS are not really useful for any practical purposes, so U-Boot choses to define different, more useful values. This is perfectly fine. 1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 : it isn't true on our board : This applies for your board, too. - can linux work with RAM not beginning at 0 on this board ? You can make it work, but there is no good reason to do this. Juts change your memory map to use a more sensible configuration. - what modifications should we make in the kernel to accept RAM at 0x0300 ? Please forget this idea. 2) is brd_info the only structure given to kernel by u-boot ? That is to say is it the only way for the kernel to have information about the boad ? It also gets passed the kernel commandline and some other data in registers. 4) are the following values important if CONFIG_HIGHMEM is not defined You don't want to play with these data unless you know exactly what you are doing. (they are automatically generated by our Metrowerks PCS tool in autoconf.h ) ? Then please ask Metrowerks support who provided such a tool which is unknown to me. 5) is the base value of IMMR very important (real value in u-boot different from documentation) ? Yes, it is very important. Your current memory map cannot work with Linux. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Fascinating is a word I use for the unexpected. -- Spock, The Squire of Gothos, stardate 2124.5
[PATCH] Fix PPC440 pagetable attributes
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. Signed-off-by: Geoff Levand geoffrey.levand at am.sony.com for CELF -- Index: linux-2.6.12-bhpm/include/asm-ppc/pgtable.h === --- linux-2.6.12-bhpm.orig/include/asm-ppc/pgtable.h 2005-06-02 15:09:24.0 -0700 +++ linux-2.6.12-bhpm/include/asm-ppc/pgtable.h 2005-06-02 15:47:53.0 -0700 @@ -202,18 +202,64 @@ * * 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. + * Kernel PTE entry holds arch-dependent swp_entry structure under certain + * situation. In other words, in such situation, some portion of PTE bits + * are used as swp_entry. In PPC implementation, 3-24th LSB are shared with + * swp_entry, however 0-2nd three LSB still hold protection values. + * That means three protection bits are reserved for both PTE and SWAP + * entry at the most three LSBs. + * + * There are three protection bits available for SWAP entry; + * _PAGE_PRESENT + * _PAGE_FILE + * _PAGE_HASHPTE (if HW has) + * + * So those three bits have to be inside of 0-2nd LSB of PTE. + * */ + #define _PAGE_PRESENT0x0001 /* S: PTE valid */ #define _PAGE_RW0x0002 /* S: Write permission */ -#define _PAGE_DIRTY 0x0004 /* S: Page dirty */ +#define _PAGE_FILE 0x0004 /* S: nonlinear file mapping */ #define _PAGE_ACCESSED 0x0008 /* S: Page referenced */ #define _PAGE_HWWRITE0x0010 /* H: Dirty RW */ #define _PAGE_HWEXEC 0x0020 /* H: Execute permission */ #define _PAGE_USER 0x0040 /* S: User page */ #define _PAGE_ENDIAN0x0080 /* H: E bit */ #define _PAGE_GUARDED 0x0100 /* H: G bit */ -#define _PAGE_COHERENT 0x0200 /* H: M bit */ -#define _PAGE_FILE 0x0400 /* S: nonlinear file mapping */ +#define _PAGE_DIRTY 0x0200 /* S: Page dirty */ #define _PAGE_NO_CACHE 0x0400 /* H: I bit */ #define _PAGE_WRITETHRU 0x0800 /* H: W bit */ - kumar
Réf. : Re: starting RAM adress for linux kernel
Dear Wolfgang, we need to have the start of Ram at 0x0300 because we use the command mem=40M (for uboot) to force Linux in the low part of memory and to reserve the high part of memory (218M exactly ) for ioremap (for our application) but we keep the same flash mapping (to avoid more problems). So how can we do that ? The boot seems OK but there is some problems in Kernel after uncompressing the kernel image. Is the only solution is to inverse the mapping with Ram from 0 to 258M and the flash above ? Finally, will Busybox work with Ram starting at 0x0300 ? Thank you really for your help. Sophie CARAYOL. Wolfgang Denk wd at denx.de Pour : scarayol at assystembrime.com Envoy? par : cc :linuxppc-embedded at ozlabs.org, ctrichet at assystembrime.com wd at denx.de Objet : Re: starting RAM adress for linux kernel 03/06/05 16:14 Dear Sophie, in message OFED9D0639.75930571-ONC1257015.0031274C at brime.fr you wrote: We have a platform similar to MPC885ADS (xith Kernel version 2.4.26) except that : - the RAM is at 0x0300 (size 0x1000) - the flash is at 0x0280 (size 0x0020) - IMMR = 0x0220 Ummm - just to avoid any misunderstandings: there is no technical reason for such a memory map, and no other good reason either as such a configuration will not be able to run Linux. After u-boot on MPC885ADS, we get the following platform information : - RAM at 0 size 0x0080 - FLASH at 0xFE00 size 0x0020 - IMMR at 0xFF00 This information is different from the documentation of MPC885ADS : - FLASH at 0x0280 size 0x0080 - IMMR at 0x0220 So what is your problem? The memory map ist just something you define as it fits your project. The values in the MPC885ADS are not really useful for any practical purposes, so U-Boot choses to define different, more useful values. This is perfectly fine. 1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 : it isn't true on our board : This applies for your board, too. - can linux work with RAM not beginning at 0 on this board ? You can make it work, but there is no good reason to do this. Juts change your memory map to use a more sensible configuration. - what modifications should we make in the kernel to accept RAM at 0x0300 ? Please forget this idea. 2) is brd_info the only structure given to kernel by u-boot ? That is to say is it the only way for the kernel to have information about the boad ? It also gets passed the kernel commandline and some other data in registers. 4) are the following values important if CONFIG_HIGHMEM is not defined You don't want to play with these data unless you know exactly what you are doing. (they are automatically generated by our Metrowerks PCS tool in autoconf.h ) ? Then please ask Metrowerks support who provided such a tool which is unknown to me. 5) is the base value of IMMR very important (real value in u-boot different from documentation) ? Yes, it is very important. Your current memory map cannot work with Linux. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Fascinating is a word I use for the unexpected. -- Spock, The Squire of Gothos, stardate 2124.5
RE: Réf. : Re: starting RAM adress for linux kernel
we need to have the start of Ram at 0x0300 because we use the command mem=40M (for uboot) to force Linux in the low part of memory and to reserve the high part of memory (218M exactly ) for ioremap (for our application) but we keep the same flash mapping (to avoid more problems). So how can we do that ? The boot seems OK but there is some problems in Kernel after uncompressing the kernel image. Is the only solution is to inverse the mapping with Ram from 0 to 258M and the flash above ? RAM should always start at address 0x0 in your chip select mapping. When you pass mem=40M Linux will claim RAM from 0x0 to 0x0280. The rest of the RAM, 0x0280 to the end will be available for ioremap. The reason your kernel does nothing after being uncompressed is because it has no idea where it is and probably is not being uncompressed to a valid RAM address. The sensible place to map FLASH is the end of memory, or anywhere out of the way. I assume you are low booting and that is why you think FLASH needs to be at the beginning of memory. It does not, even though that is where you boot from you can remap the FLASH. Finally, will Busybox work with Ram starting at 0x0300 ? Busy box is part of your ramdisk, it does not know anything about the memory map. If your kernel does not get past uncompressing then you did not get anywhere near busy box running.
[RFC] PlatformDevice definitions for 82xx
Kumar Gala wrote: On Jun 2, 2005, at 11:16 AM, Vitaly Bordug wrote: Hi! This adds platform definition files for 82xx, while the platform_info is filled in board-specific .C file residing in platforms/82xx. Another disputable thing I did - I moved m8260_setup.c from the syslib/ up to platforms/82xx/. The file was slightly changed - added 2 prototypes from the cpm2_pic.h and removed the respective include. Why the move of m8260_setup.c? Also, if this is required can we do this as two different patches so we can see clearly any changes also maded to m8260_setup.c To my opinion platforms/82xx/m8260_setup.c is more relevant than in syslib. This is not a vital requirement though, I just want to know whether someone considers the same. mpc82xx_devices.c need a bit of work we need to at least cover the same set of devices that 85xx does for the CPM: SPI, I2C, USB, SCC1-4, FCC1-3, MCC1-2, SMC1-2 OK. These stuff is not there yet because I wasn't sure what should come first - the platform stuff or driver that will utilize it. So, the correct way is to define PD first, than add drivers. Additionally, the device name can not me FS_ENET_NAME, which assumes that FCC is only used for enet. OK mpc82xx_sys.c: what is the .value field? is this the IMMR and if so why bother shifting it? Because I want only partnum masknum (RM, Fig. 4.26), remaining part is HRCW-dependent and can be written so couldn't be used as a device identification. Also there are a whole bunch of variants that need to be captured What exactly do you mean by this? Enumerate all the 82xx boards in mpc82xx_sys.c identifying them by immr, or? Let's get clean versions of these two files before we worry about how to handle FCC enet specific bits. Agreed. - kumar -- Sincerely, Vitaly
[RFC] PlatformDevice definitions for 82xx
On Jun 3, 2005, at 10:21 AM, Vitaly Bordug wrote: Kumar Gala wrote: On Jun 2, 2005, at 11:16 AM, Vitaly Bordug wrote: Hi! This adds platform definition files for 82xx, while the platform_info is filled in board-specific .C file residing in platforms/82xx. Another disputable thing I did - I moved m8260_setup.c from the syslib/ up to platforms/82xx/. The file was slightly changed - added 2 prototypes from the cpm2_pic.h and removed the respective include. Why the move of m8260_setup.c? Also, if this is required can we do this as two different patches so we can see clearly any changes also maded to m8260_setup.c To my opinion platforms/82xx/m8260_setup.c is more relevant than in syslib. This is not a vital requirement though, I just want to know whether someone considers the same. Let's leave it where it is for now. mpc82xx_devices.c need a bit of work we need to at least cover the same set of devices that 85xx does for the CPM: SPI, I2C, USB, SCC1-4, FCC1-3, MCC1-2, SMC1-2 OK. These stuff is not there yet because I wasn't sure what should come first - the platform stuff or driver that will utilize it. So, the correct way is to define PD first, than add drivers. Additionally, the device name can not me FS_ENET_NAME, which assumes that FCC is only used for enet. OK mpc82xx_sys.c: what is the .value field? is this the IMMR and if so why bother shifting it? Because I want only partnum masknum (RM, Fig. 4.26), remaining part is HRCW-dependent and can be written so couldn't be used as a device identification. Ok, but is there any need to shift it? Just setup the mask up correctly. Also there are a whole bunch of variants that need to be captured What exactly do you mean by this? Enumerate all the 82xx boards in mpc82xx_sys.c identifying them by immr, or? Not boards, but chips. Yes, enumerating the various IMMRs, I will ask one of our engineers to help with this. - kumar
Réf. : Re: starting RAM adress for lin ux kernel
Dear Sphie, in message OFF1C6B550.9120AF42-ONC1257015.004EFCD3 at brime.fr you wrote: we need to have the start of Ram at 0x0300 because we use the command mem=40M (for uboot) to force Linux in the low part of memory and to reserve the high part of memory (218M exactly ) for ioremap (for our application) but we keep I don't see any reason why this would prevent you from mapping the RAM at physical address 0. the same flash mapping (to avoid more problems). I don't know which problems you want to avoid by your chosen memory map, but I guess that the problems you *cause* by this choice are more, and more severe. Is the only solution is to inverse the mapping with Ram from 0 to 258M and the flash above ? Yes. Finally, will Busybox work with Ram starting at 0x0300 ? No, it will not, as BB is application code which requires a running kernel, and your kernel will not run with such a mapping. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It may be that our role on this planet is not to worship God but to create him. - Arthur C. Clarke
[PATCH] Fix PPC440 pagetable attributes
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. If not, could you be more specific. -Geoff
Discuss: Adding OF Flat Dev Tree to ppc32
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
Getting ownership for various boards/platforms configs
-Original Message- From: linuxppc-dev-bounces at ozlabs.org [mailto:linuxppc-dev-bounces at 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 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've started with a list of all the _defconfigs that we have and would like to see if we can get contacts for the boards. All this list is meant to be is a contact point. The following is the list, I'll keep a live copy at http://gate.crashing.org/~galak/platform-owners. Once it gets flushed out I'll turn it into file that looks more like the toplevel MAINTAINERS file. If we dont have any owners for a board we can discuss if support for it should be removed. Please email me if you feel you are the owner of any board/config. thanks - kumar gemini I'll take this one. rbaxter at curtisswright.com Rob Baxter Curtiss-Wright Controls, Embedded Computing
[PATCH] ppc32: Converted MPC10X bridge to use platform devices instead of OCP
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 at freescale.com
Signed-off-by: Kumar Gala kumar.gala at freescale.com
---
commit c4fa624a5c007f17142ab5225d1085564ffa8f83
tree 63546f2e7de561696db29a0a481bf40c449e9f0e
parent e832e0d9e4878d02ab2ef6bad5971dc9f9cd7679
author Kumar K. Gala kumar.gala at freescale.com Fri, 03 Jun 2005 14:20:50
-0500
committer Kumar K. Gala kumar.gala at 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 / (50/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,
+
[PATCH] Fix PPC440 pagetable attributes
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
[PATCH][1/5] RapidIO support: core
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 = 0x20,
+ .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
[PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
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 at mvista.com
---
commit f95cc4d276cc332225bd823a2ae3be553c119990
tree bd11f3262e29c13b6d56383415c634371394e913
parent b56ae7a07ed0304bbc1dd61d3527dccdbcc467e9
author Randy Vinson rvinson at linuxbox.(none) Fri, 03 Jun 2005 13:50:59 -0700
committer Randy Vinson rvinson at 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 at mvista.com
+ *
+ * Based on the m41t00.c by Mark Greer mgreer at 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_TOD00x00
+#define DS1374_REG_TOD10x01
+#define DS1374_REG_TOD20x02
+#define DS1374_REG_TOD30x03
+#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
+
+#defineDS1374_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);
[PATCH][1/5] RapidIO support: core
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
[PATCH 2/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
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 at mvista.com
---
commit 07fb1bd27347f7f0df1309c40d09a2f1a9a98731
tree b3ac3ac93679372aa5111268b623c5dda4a5039e
parent f95cc4d276cc332225bd823a2ae3be553c119990
author Randy Vinson rvinson at linuxbox.(none) Fri, 03 Jun 2005 13:57:46 -0700
committer Randy Vinson rvinson at 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)
{
[PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
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 at mvista.com
---
commit f95cc4d276cc332225bd823a2ae3be553c119990
tree bd11f3262e29c13b6d56383415c634371394e913
parent b56ae7a07ed0304bbc1dd61d3527dccdbcc467e9
author Randy Vinson rvinson at linuxbox.(none) Fri, 03 Jun 2005
13:50:59 -0700
committer Randy Vinson rvinson at 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 at mvista.com
+ *
+ * Based on the m41t00.c by Mark Greer mgreer at 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_WDALM00x04
+#define DS1374_REG_WDALM10x05
+#define DS1374_REG_WDALM20x06
+#define DS1374_REG_CR0x07
+#define DS1374_REG_SR0x08
+#define DS1374_REG_SR_OSF0x80
+#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 = {
[PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
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
RTnet broadcast
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
[PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
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
[PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
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
[PATCH][5/5] RapidIO support: net driver over messaging
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
kernel ported from ELDK 3.0 hangs (loops in idled()) on my custom MPC870 Board
I am trying to bring up Linux on a custom MPC870 Board using ELDK 3.0. The ported kernel from ELDK 3.0 hangs (loops in idled()) and the kernel_thread 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 = 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: 0x20 Loading: # # ## done Bytes transferred = 691764 (a8e34 hex) ## Booting image at 0020 ... 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 = 675.5 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.4.24-pre2 (ehong at chico) (gcc version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)) #8 Fri Jun 3 10:13:10 MDT 2005 On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs rw nfsroot=10.15.10.170:/opt/eldk/ppc_8xx ip=10.15.2.101:10.15.10.170eth0:off panic=1 Decrementer Frequency = 49500/60 Calibrating delay loop... 131.48 BogoMIPS Memory: 63132k available (1204k kernel code, 360k data, 60k init, 0k highmem) 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().) Here is the board info printed under u-boot: = bdinfo memstart= 0x memsize = 0x0400 flashstart = 0xF000 flashsize = 0x0400 flashoffset = 0x0001F100 sramstart = 0x sramsize= 0x immr_base = 0xFFF0 bootflags = 0x0001 intfreq =132 MHz busfreq = 66 MHz ethaddr = 00:D0:1C:01:02:00 IP addr = 10.15.2.101 baudrate= 38400 bps The bd_info of kernel is copied from u-boot. The IMAP_ADDR of kernel uses the same value as the U-Boot CFG_IMMR. Thanks in advance for your help! Edward
[PATCH] [1/2] PM support for Ebony
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 at 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.0 -0700
+++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/Kconfig2005-06-03
16:15:07.0 -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.0 -0700
+++ linux-2.6.12-bhpm/arch/ppc/platforms/4xx/Makefile 2005-06-03
16:15:07.0 -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.c2005-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.0 -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);
+
+
[PATCH] [2/2] PM support for emac driver
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 at 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.0 -0700
+++ linux-2.6.12-bhpm/drivers/net/ibm_emac/ibm_emac_core.c 2005-06-02
17:11:02.0 -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
[PATCH][UPDATE] ppc32: Converted MPC10X bridge to use platform devices instead of OCP
(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 at freescale.com
Signed-off-by: Kumar Gala kumar.gala at freescale.com
---
commit c4fa624a5c007f17142ab5225d1085564ffa8f83
tree 63546f2e7de561696db29a0a481bf40c449e9f0e
parent e832e0d9e4878d02ab2ef6bad5971dc9f9cd7679
author Kumar K. Gala kumar.gala at freescale.com Fri, 03 Jun 2005 14:20:50
-0500
committer Kumar K. Gala kumar.gala at 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 / (50/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 +
+
[PATCH] [1/2] PM support for Ebony
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.0 -0700 I think it should be in arch/ppc/syslib not in arch/ppc/platforms/4xx. -- Eugene
[PATCH] [2/2] PM support for emac driver
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
cpm_uart initializes scm/scc for console only?
We're tracking down an issue trying to use both SMC1 and SMC2 as ttyCPM devices. SMC1 as console (and ttyCPM/0) is working fine, but it appears that SMC2 is not being completely initialized. It looks as though the cause is that cpm_uart_init_smc (or cpm_uart_init_scc) is only called from cpm_uart_console_setup[1], ie. only when CONFIG_SERIAL_CPM_CONSOLE is set, and then only for the one port that is defined as the console. It looks like cpu_uart_init_smc/scc should be called at some point for all ports that are defined for use, but there's no other place it's called from. Before we try fixing the wrong thing, is this (using multiple SMC/SCC ports out of the box) known to work? Is there a reason why calling cpu_uart_init_smc/scc wouldn't have been implemented? This was found with Linux 2.6.10 and I've reviewed the updates through 2.6.12-rc5 and the patch tracking system. Sanity check much appreciated, -- Ken [1] http://lxr.linux.no/source/drivers/serial/cpm_uart/cpm_uart_core.c#L1079
[PATCH] Fix PPC440 pagetable attributes
Kumar Gala wrote: On Jun 3, 2005, at 11:30 AM, Geoff Levand wrote: * 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. OK, attached is an updated patch. -Geoff -- next part -- A non-text attachment was scrubbed... Name: ppc440-page-attrib-fix.patch Type: text/x-patch Size: 3655 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050603/3b645bf7/attachment.bin
