* MV64360 MPSC - console problem
From: Hegde Ashok-aah024 @ 2005-03-07 10:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am trying to bring up linux-2.6.10 on ppc based system with
MV64360(marvell controller).
I am unable to use mpsc as the console, serial text debug messages are
coming fine i.e. ppc_md.progress able to print properly on the serial port.
I observed that when console_init() is being called from init/main.c none
of our "mpsc" init functions are called.
Also I see that there is no call to "console_initcall" in mpsc driver.
According to my understanding this call is required in serial drivers used
as consoles.
I took this mpsc driver from "bk://source.mvista.com/linux-2.5-marvell" as
mentioned in ppc mailinglist.
Hardware has been tested with linux-2.4.20 flavour and it is absolutely
fine.
Appreciate any help.
Thanks,
Ashok
^ permalink raw reply
* Re: Adding machine types to the kernel tree...
From: Jakob Viketoft @ 2005-03-07 10:07 UTC (permalink / raw)
To: acmay; +Cc: Linux PPC Embedded list
In-Reply-To: <1109875809.25252.24.camel@mud>
Thanks for the comments!
Andrew May wrote:
> I think a huge first step would be to banish xparameters.h from all the
> kernel code.
> Our HW guys just seem to do the strangest things without checking.
> So I have 2 spins of a board with 2 Virtex-II pro's each.
> The 2 spins have a small refrence clock change and the 2 CPU's have
> different IRQ mappings.
I understand that there is numerous resentment against having this file
in the kernel and I've been thinking of a solution without it. One such
path would be serving the kernel with a OCP list of the devices used,
but I'm unsure about the current status of OCP. Is this The Right Way to
do it, or are OCP likely to be abandoned further along the 2.6 road?
Matt (Porter), I've seen that you've "ported" this to the 2.6 kernel,
what do you say?
> There is no way I wanted to build 4 kernels to handle these.
> I don't have the code with me, but the basic thing I did was fixup
> the compiled in arrays like rs_table in the board_io_mapping.
>
> So the quick way to start tracking things down may be to just
> replace all the constants in xparmaters.h with function calls
> that got the info from the boot loader if possible.
> You will get plenty of compile errors for the arrays, but then
> just this type of code needs to be fixed up to setup the arrary
> at run time rather than just get the pointer to it at run time.
The question is, do you want to have a bootloader (as U-boot) on a small
embedded system? In the FPGA case, you might need something that puts
the bitstream in the right place, but I'm not quite sure it would
constitute a bootloader. Maybe just having a static OCP list at a
certain location in flash and let the little bitstream prog send the
pointer to it as a kernel parameter at startup?
Reactions appreciated!
Cheers!
/Jakob
^ permalink raw reply
* Re: [patch 1/4] delete unused file arch_ppc_kernel_find_name.c
From: Paul Mackerras @ 2005-03-07 9:13 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev, domen
In-Reply-To: <20050307073721.GB15637@Redstar.dorchain.net>
Joerg Dorchain writes:
> To me it looks more like a devloper aid than a kernel file. Ok, it
> functionality could be replaced by a grep -C, but really delete it?
Last time I looked, grep didn't have the ability to find a string that
isn't in the file. The address you are searching for might be between
two addresses listed in System.map, in which case find_name.c will
print the symbol corresponding to the lower of the two addresses. Not
that I use find_name.c myself. I agree that arch/ppc/kernel is a bad
place for it too.
Paul.
^ permalink raw reply
* Re: [patch 1/4] delete unused file arch_ppc_kernel_find_name.c
From: Domen Puncer @ 2005-03-07 8:25 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev, paulus
In-Reply-To: <20050307073721.GB15637@Redstar.dorchain.net>
On 07/03/05 08:37 +0100, Joerg Dorchain wrote:
> On Sun, Mar 06, 2005 at 11:22:56PM +0100, domen@coderock.org wrote:
> > Remove nowhere referenced file. (egrep "filename\." didn't find anything)
>
> To me it looks more like a devloper aid than a kernel file. Ok, it
> functionality could be replaced by a grep -C, but really delete it?
I believe every kernel developer has grep :-)
Or maybe it could be moved to scripts/ or somewhere?
Domen
^ permalink raw reply
* Re: [patch 1/4] delete unused file arch_ppc_kernel_find_name.c
From: Joerg Dorchain @ 2005-03-07 7:37 UTC (permalink / raw)
To: domen; +Cc: linuxppc-dev, paulus
In-Reply-To: <20050306222256.A3F911F1FF@trashy.coderock.org>
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
On Sun, Mar 06, 2005 at 11:22:56PM +0100, domen@coderock.org wrote:
> Remove nowhere referenced file. (egrep "filename\." didn't find anything)
To me it looks more like a devloper aid than a kernel file. Ok, it
functionality could be replaced by a grep -C, but really delete it?
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Sven Luther @ 2005-03-07 6:52 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050307010058.GB22642@xyzzy>
On Sun, Mar 06, 2005 at 06:00:58PM -0700, Dale Farnsworth wrote:
> On Sun, Mar 06, 2005 at 08:10:34PM +0100, Sven Luther wrote:
> > On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote:
> > > MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
> > > CHESTNUT. If I understand correctly, it should be defined for any
> > > board using the MV64360. I don't think we want the PPC_CHRP dependency.
> >
> > Ah, i guess that was the missing bit. Basically i need to set MV64360 for my
> > board, but since it is a generic PPC_CHRP, how is that supposed to work ?
> >
> > Could you send me maybe a list of files which need merging yet, compared to
> > 2.6.11 ? I guess it just doesn't work because i am missing pieces.
>
> I would be guessing, since I've focused on the ethernet driver. Mark
> Greer <mgreer@mvista.com> has done the core mv64[34]60 core support.
> Nicholas is working with regarding Pegasos II support.
Nicolas even, and i work with him on this.
> > The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
> > (only port1 is wired though) mapped at interrupt 9, shared with other devices.
> > I guess that would be the only real difference with the other currently
> > supported hardware, right ?
>
> Nicholas implied that the PCI IRQs are different as well.
The real problem as far as i see it, is that the mv6[34]60 code does too much.
The pegasos OpenFirmware implementation initializes the chip, and we really
only need the ethernet part. It seems that the code from Mark Greer
initializes the whole stuff, since it has no usefull firmware under it anyway,
and thus mis-initializes some of it and thus fully break everything.
Mark, any comment on this ?
But i hear Nicolas has done some useful work yesterday evening, i will review
it as soon as he is back from dreamland :)
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Dale Farnsworth @ 2005-03-07 1:00 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050306191034.GA10975@pegasos>
On Sun, Mar 06, 2005 at 08:10:34PM +0100, Sven Luther wrote:
> On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote:
> > MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
> > CHESTNUT. If I understand correctly, it should be defined for any
> > board using the MV64360. I don't think we want the PPC_CHRP dependency.
>
> Ah, i guess that was the missing bit. Basically i need to set MV64360 for my
> board, but since it is a generic PPC_CHRP, how is that supposed to work ?
>
> Could you send me maybe a list of files which need merging yet, compared to
> 2.6.11 ? I guess it just doesn't work because i am missing pieces.
I would be guessing, since I've focused on the ethernet driver. Mark
Greer <mgreer@mvista.com> has done the core mv64[34]60 core support.
Nicholas is working with regarding Pegasos II support.
> The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
> (only port1 is wired though) mapped at interrupt 9, shared with other devices.
> I guess that would be the only real difference with the other currently
> supported hardware, right ?
Nicholas implied that the PCI IRQs are different as well.
-Dale
^ permalink raw reply
* [patch 4/4] ppc: Lindent cleanup to arch/ppc/4xx_io/serial_sicc.c
From: Domen Puncer @ 2005-03-06 23:33 UTC (permalink / raw)
To: paulus; +Cc: james4765, linuxppc-dev, domen
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
[Was too big for the list, sending as gzipped attachment]
This is a massive whitespace cleanup of a badly-formatted file in arch/ppc.
Signed-off-by: James Nelson <james4765@gmail.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj-domen/arch/ppc/4xx_io/serial_sicc.c | 3118 ++++++++++++++++-----------------
1 files changed, 1564 insertions(+), 1554 deletions(-)
[-- Attachment #2: lindent-arch_ppc_4xx_io_serial_sicc.patch.gz --]
[-- Type: application/x-gunzip, Size: 20840 bytes --]
^ permalink raw reply
* [patch 3/4] delete unused file arch_ppc_syslib_ppc4xx_serial.c
From: domen @ 2005-03-06 22:23 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, domen
Remove nowhere referenced file. (egrep "filename\." didn't find anything)
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj/arch/ppc/syslib/ppc4xx_serial.c | 171 -------------------------------------
1 files changed, 171 deletions(-)
diff -L arch/ppc/syslib/ppc4xx_serial.c -puN arch/ppc/syslib/ppc4xx_serial.c~remove_file-arch_ppc_syslib_ppc4xx_serial.c /dev/null
--- kj/arch/ppc/syslib/ppc4xx_serial.c
+++ /dev/null 2005-03-02 11:34:59.000000000 +0100
@@ -1,171 +0,0 @@
-/*
- * arch/ppc/syslib/ppc405_serial.c
- *
- * Author: MontaVista Software, Inc.
- * frank_rowand@mvista.com or source@mvista.com
- * debbie_chu@mvista.com
- *
- * This is a fairly standard 165xx type device that will eventually
- * be merged with other similar processor/boards. -- Dan
- *
- * 2000 (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.
- *
- * Console I/O support for Early kernel bringup.
- */
-
-#include <linux/config.h>
-
-#if defined(CONFIG_IBM405GP) || defined(CONFIG_IBM405CR)
-
-#ifdef CONFIG_KGDB
-#include <asm/kgdb.h>
-#include <linux/init.h>
-#endif
-
-#ifdef CONFIG_DEBUG_BRINGUP
-
-#include <linux/console.h>
-
-extern void ftr_reset_preferred_console(void);
-
-
-static int ppc405_sercons_setup(struct console *co, char *options)
-{
-#ifdef CONFIG_UART0_DEBUG_CONSOLE
- volatile unsigned char *uart_dll = (char *)0xef600300;
- volatile unsigned char *uart_fcr = (char *)0xef600302;
- volatile unsigned char *uart_lcr = (char *)0xef600303;
-#endif
-
-#ifdef CONFIG_UART1_DEBUG_CONSOLE
- volatile unsigned char *uart_dll = (char *)0xef600400;
- volatile unsigned char *uart_fcr = (char *)0xef600402;
- volatile unsigned char *uart_lcr = (char *)0xef600403;
-#endif
-
- *uart_lcr = *uart_lcr | 0x80; /* DLAB on */
-
-/* ftr revisit - there is no config option for this
-** also see include/asm-ppc/ppc405_serial.h
-**
-** #define CONFIG_IBM405GP_INTERNAL_CLOCK
-*/
-
-
-#ifdef CONFIG_IBM405GP_INTERNAL_CLOCK
- /* ftr revisit
- ** why is bit 19 of chcr0 (0x1000) being set?
- */
- /* 0x2a results in data corruption, kgdb works with 0x28 */
- *uart_dll = 0x28; /* 9600 baud */
- _put_CHCR0((_get_CHCR0() & 0xffffe000) | 0x103e);
-#else
- *uart_dll = 0x48; /* 9600 baud */
-#endif
- *uart_lcr = *uart_lcr & 0x7f; /* DLAB off */
-
- return 0;
-}
-
-
-/*
- * This is a bringup hack, writing directly to uart0 or uart1
- */
-
-static void
-ppc405_sercons_write(struct console *co, const char *ptr,
- unsigned nb)
-{
- int i;
-
-#ifdef CONFIG_UART0_DEBUG_CONSOLE
- volatile unsigned char *uart_xmit = (char *)0xef600300;
- volatile unsigned char *uart_lsr = (char *)0xef600305;
-#endif
-
-#ifdef CONFIG_UART1_DEBUG_CONSOLE
- volatile unsigned char *uart_xmit = (char *)0xef600400;
- volatile unsigned char *uart_lsr = (char *)0xef600405;
-#endif
-
- for (i = 0; i < nb; ++i) {
-
- /* wait for transmit reg (possibly fifo) to empty */
- while ((*uart_lsr & 0x40) == 0)
- ;
-
- *uart_xmit = (ptr[i] & 0xff);
-
- if (ptr[i] == '\n') {
-
- /* add a carriage return */
-
- /* wait for transmit reg (possibly fifo) to empty */
- while ((*uart_lsr & 0x40) == 0)
- ;
-
- *uart_xmit = '\r';
- }
- }
-
- return;
-}
-
-
-static int
-ppc405_sercons_read(struct console *co, char *ptr, unsigned nb)
-{
-#ifdef CONFIG_UART0_DEBUG_CONSOLE
- volatile unsigned char *uart_rcv = (char *)0xef600300;
- volatile unsigned char *uart_lsr = (char *)0xef600305;
-#endif
-
-#ifdef CONFIG_UART1_DEBUG_CONSOLE
- volatile unsigned char *uart_rcv = (char *)0xef600400;
- volatile unsigned char *uart_lsr = (char *)0xef600405;
-#endif
-
-
- /* ftr revisit: not tested */
-
- if (nb == 0)
- return(0);
-
- if (!ptr)
- return(-1);
-
- /* wait for receive reg (possibly fifo) to contain data */
- while ((*uart_lsr & 0x01) == 0)
- ;
-
- *ptr = *uart_rcv;
-
- return(1);
-}
-
-static struct console ppc405_sercons = {
- .name = "dbg_cons",
- .write = ppc405_console_write,
- .setup = ppc405_console_setup,
- .flags = CON_PRINTBUFFER,
- .index = -1,
-};
-
-void
-register_debug_console(void)
-{
- register_console(&ppc405_sercons);
-}
-
-void
-unregister_debug_console(void)
-{
- unregister_console(&ppc405_sercons);
-}
-
-#endif /* CONFIG_DEBUG_BRINGUP */
-
-#endif /* #if defined(CONFIG_IBM405GP) || defined(CONFIG_IBM405CR) */
_
^ permalink raw reply
* [patch 2/4] delete unused file arch_ppc_syslib_ppc4xx_pm.c
From: domen @ 2005-03-06 22:22 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, domen
Remove nowhere referenced file. (egrep "filename\." didn't find anything)
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj/arch/ppc/syslib/ppc4xx_pm.c | 47 -----------------------------------------
1 files changed, 47 deletions(-)
diff -L arch/ppc/syslib/ppc4xx_pm.c -puN arch/ppc/syslib/ppc4xx_pm.c~remove_file-arch_ppc_syslib_ppc4xx_pm.c /dev/null
--- kj/arch/ppc/syslib/ppc4xx_pm.c
+++ /dev/null 2005-03-02 11:34:59.000000000 +0100
@@ -1,47 +0,0 @@
-/*
- * Author: Armin Kuster <akuster@mvista.com>
- *
- * 2002 (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 an attempt to get Power Management going for the IBM 4xx processor.
- * This was derived from the ppc4xx._setup.c file
- */
-
-#include <linux/config.h>
-#include <linux/init.h>
-
-#include <asm/ibm4xx.h>
-
-void __init
-ppc4xx_pm_init(void)
-{
-
- unsigned int value = 0;
-
- /* turn off unused hardware to save power */
-#ifdef CONFIG_405GP
- value |= CPM_DCP; /* CodePack */
-#endif
-
-#if !defined(CONFIG_IBM_OCP_GPIO)
- value |= CPM_GPIO0;
-#endif
-
-#if !defined(CONFIG_PPC405_I2C_ADAP)
- value |= CPM_IIC0;
-#ifdef CONFIG_STB03xxx
- value |= CPM_IIC1;
-#endif
-#endif
-
-
-#if !defined(CONFIG_405_DMA)
- value |= CPM_DMA;
-#endif
-
- mtdcr(DCRN_CPMFR, value);
-
-}
_
^ permalink raw reply
* [patch 1/4] delete unused file arch_ppc_kernel_find_name.c
From: domen @ 2005-03-06 22:22 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, domen
Remove nowhere referenced file. (egrep "filename\." didn't find anything)
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj/arch/ppc/kernel/find_name.c | 48 -----------------------------------------
1 files changed, 48 deletions(-)
diff -L arch/ppc/kernel/find_name.c -puN arch/ppc/kernel/find_name.c~remove_file-arch_ppc_kernel_find_name.c /dev/null
--- kj/arch/ppc/kernel/find_name.c
+++ /dev/null 2005-03-02 11:34:59.000000000 +0100
@@ -1,48 +0,0 @@
-#include <stdio.h>
-#include <asm/page.h>
-#include <sys/mman.h>
-#include <strings.h>
-/*
- * Finds a given address in the System.map and prints it out
- * with its neighbors. -- Cort
- */
-
-int main(int argc, char **argv)
-{
- unsigned long addr, cmp, i;
- FILE *f;
- char s[256], last[256];
-
- if ( argc < 2 )
- {
- fprintf(stderr, "Usage: %s <address>\n", argv[0]);
- return -1;
- }
-
- for ( i = 1 ; argv[i] ; i++ )
- {
- sscanf( argv[i], "%0lx", &addr );
- /* adjust if addr is relative to kernelbase */
- if ( addr < PAGE_OFFSET )
- addr += PAGE_OFFSET;
-
- if ( (f = fopen( "System.map", "r" )) == NULL )
- {
- perror("fopen()\n");
- exit(-1);
- }
-
- while ( !feof(f) )
- {
- fgets(s, 255 , f);
- sscanf( s, "%0lx", &cmp );
- if ( addr < cmp )
- break;
- strcpy( last, s);
- }
-
- printf( "%s%s", last, s );
- }
- fclose(f);
- return 0;
-}
_
^ permalink raw reply
* Re: [PATCH] WDT Driver for Book-E [2/2] Device driver part.
From: Josh Boyer @ 2005-03-06 21:11 UTC (permalink / raw)
To: Takeharu KATO; +Cc: ppcembed
In-Reply-To: <422B56CD.9020708@ybb.ne.jp>
On Mon, 2005-03-07 at 04:15 +0900, Takeharu KATO wrote:
> Hi, Josh:
>
> Takeharu KATO wrote:
> >>
> > To tell the truth, this matter has been examined, but I forgot this.
> > Thank you for making it recall(^^
> >
> I performed minor fixes which you pointed out.
> But I leaves WDT_WP[0123] on purpose.
> The interpretation of this value is different between PPC4xx and e500.
> To unite them, I leaves this.
Ok, that makes sense.
>
> >>
> >> In include/linux/device.h there are dev_printk and dev_dbg macros that
> >> do pretty much the same thing. Could you use those instead?
> >>
> > I did not know such thing.
> > I'll try to use them.
> >
> On second thought, I found that it is not so good idea.
> If I change this according to what you said, it is not
> easy to find which driver outputs messages when we can
> use multiple WDT in a system.
>
> Macros in include/linux/device.h will use name member in miscdevice
> struct as driver's name, and this is commonly named as "watchdog".
>
Ok, that's fine too. No complaints here.
> FYI, I show the difference with the patch submitted last time.
>
>
> Regards,I'll test this driver today, just in case, before I post the
> revised edition of this driver.
Thanks! Looks good.
josh
^ permalink raw reply
* Re: mv64x60 updates
From: Nicolas DET @ 2005-03-06 19:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050306191034.GA10975@pegasos>
Hello Sven,
On 06/03/2005, you wrote:
> Ah, i guess that was the missing bit. Basically i need to set MV64360 for
> my board, but since it is a generic PPC_CHRP, how is that supposed to
> work ?
> Could you send me maybe a list of files which need merging yet, compared
> to 2.6.11 ? I guess it just doesn't work because i am missing pieces.
I fixed that here.
TheKconfig issue is really minor compared to the rest :-)
>> > Anyway, how do you probe for the chip ? On the pegasos we used to map
>> > on the marvell pci id :
>> >
>> > 0000:00:00.0 Host bridge: Marvell Technology Group Ltd.
>> > MV64360/64361/64362 System Controller (rev 03)
>> >
>> > too bad Marvell didn't do the logical thing and made the ethernet port
>> > appear as separated devices on a third internal pci bus.
>>
>> The mv643xx_eth probe is dependent on having the appropriate
>> platform device entry. See eth0_device and mv64x60_add_pds() in
>> arch/ppc/syslib/mv643x60.c .
> The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
> (only port1 is wired though) mapped at interrupt 9, shared with other
> devices. I guess that would be the only real difference with the other
> currently supported hardware, right ?
Yeah, and also, Pegasos II kernel shouldn't call all the chipset init call
which has been added.
Pegasos II chipset init is done by the OFW. OSs kernel shouldn't have to
touch it much.
> Will look at the above mentioned files and function and try to enable it.
I already patch a bit the kernel. However, enabling new Marvell code means
not booting anymore ATM.
I'm trying to find a way to patch the current source, without breaking
Katana & friends support.
The smartest could be to move all unneeded/board specific code somewhere
else (chipset init...) and to keep ony the minimal (only
platform_get_resource() realted stuff), in arch/ppc/syslib/mv64x60*
Regards
--
Nicolas DET
MorphOS & Linux developer
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Sven Luther @ 2005-03-06 19:10 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050306102924.GA32386@xyzzy>
On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote:
> On Sun, Mar 06, 2005 at 08:02:48AM +0100, Sven Luther wrote:
> > On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote:
> > > By all means, try it. Several people are using it without complaints, but
> > > I'd appreciate your feedback. There isn't anything dangerous in there.
> > > Gigabit works for me. I'm not sure what Kconfig parts would be needed
> > > specifically for gigabit support.
> >
> > I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to
> > build it, and even insmod it, but the module doesn't do a thing, and not even
> > a single line shows up in dmesg. I guess i am either missing a part of the
> > patch or there is something wrong with the probe code.
> >
> > I have gotten the diff against :
> >
> > include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig,
> > adding :
> >
> > config MV643XX_ETH
> > tristate "MV-643XX Ethernet support"
> > - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
> > + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
> > help
> > This driver supports the gigabit Ethernet on the Marvell MV643XX
> > - chipset which is used in the Momenco Ocelot C and Jaguar ATX.
> > + chipset which is used in the Momenco Ocelot C and Jaguar ATX and
> > + Pegasos II, amongst other PPC and MIPS boards.
> >
> > I have no idea where your MV64360 comes from, it seems to be not existent in
> > any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a
> > recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find
> > combo :/ Will have to look more.
>
> MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
> CHESTNUT. If I understand correctly, it should be defined for any
> board using the MV64360. I don't think we want the PPC_CHRP dependency.
Ah, i guess that was the missing bit. Basically i need to set MV64360 for my
board, but since it is a generic PPC_CHRP, how is that supposed to work ?
Could you send me maybe a list of files which need merging yet, compared to
2.6.11 ? I guess it just doesn't work because i am missing pieces.
> > Anyway, how do you probe for the chip ? On the pegasos we used to map on the
> > marvell pci id :
> >
> > 0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362
> > System Controller (rev 03)
> >
> > too bad Marvell didn't do the logical thing and made the ethernet port appear
> > as separated devices on a third internal pci bus.
>
> The mv643xx_eth probe is dependent on having the appropriate
> platform device entry. See eth0_device and mv64x60_add_pds() in
> arch/ppc/syslib/mv643x60.c .
The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
(only port1 is wired though) mapped at interrupt 9, shared with other devices.
I guess that would be the only real difference with the other currently
supported hardware, right ?
Will look at the above mentioned files and function and try to enable it.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] WDT Driver for Book-E [2/2] Device driver part.
From: Takeharu KATO @ 2005-03-06 19:15 UTC (permalink / raw)
To: Takeharu KATO; +Cc: ppcembed
In-Reply-To: <422969B9.6040303@ybb.ne.jp>
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
Hi, Josh:
Takeharu KATO wrote:
>>
>>
>> Most of this is in include/asm-ppc/reg_booke.h. Could you use that
>> instead of redefining most of it?
>>
> To tell the truth, this matter has been examined, but I forgot this.
> Thank you for making it recall(^^
>
I performed minor fixes which you pointed out.
But I leaves WDT_WP[0123] on purpose.
The interpretation of this value is different between PPC4xx and e500.
To unite them, I leaves this.
>>
>> In include/linux/device.h there are dev_printk and dev_dbg macros that
>> do pretty much the same thing. Could you use those instead?
>>
> I did not know such thing.
> I'll try to use them.
>
On second thought, I found that it is not so good idea.
If I change this according to what you said, it is not
easy to find which driver outputs messages when we can
use multiple WDT in a system.
Macros in include/linux/device.h will use name member in miscdevice
struct as driver's name, and this is commonly named as "watchdog".
FYI, I show the difference with the patch submitted last time.
Regards,I'll test this driver today, just in case, before I post the
revised edition of this driver.
Regards,
--
Takeharu KATO
[-- Attachment #2: inter-booke_wdt.diff --]
[-- Type: text/plain, Size: 10446 bytes --]
--- linux-2.6.11-booke-wdt/drivers/char/watchdog/booke_wdt.c 2005-03-04 16:38:58.000000000 +0900
+++ linux-2.6.11-wdt/drivers/char/watchdog/booke_wdt.c 2005-03-07 03:35:34.000000000 +0900
@@ -76,86 +76,43 @@
/* Panic notifier */
extern struct notifier_block *panic_notifier_list;
/*
- * External linkage functions
- */
-void booke_wdt_heartbeat(void);
-void booke_wdt_setup_options(char *cmd_line);
-void booke_wdt_exception(struct pt_regs *regs);
-/*
- * Internal linkage functions
- */
-static __inline__ void __booke_wdt_setup_val(int period,int reset);
-static __inline__ void __booke_wdt_enable(void);
-static __inline__ void __booke_wdt_disable(void);
-static __inline__ int __booke_wdt_is_enabled(void);
-static __inline__ void __booke_wdt_clear_int_stat(void);
-static __inline__ void __booke_wdt_set_timeout(int t);
-static __inline__ void booke_wdt_init_device(void);
-static __inline__ int booke_wdt_is_enabled(void);
-static __inline__ int booke_wdt_start(void);
-static __inline__ int booke_wdt_stop(void);
-static __inline__ int booke_wdt_ping(void);
-static __inline__ int booke_wdt_set_timeout(int t);
-static __inline__ int booke_wdt_get_status(int *status);
-static ssize_t booke_wdt_write(struct file *file, const char *buf, size_t count, loff_t *ppos);
-static int booke_wdt_ioctl(struct inode *inode, struct file *file, unsigned int cmd,unsigned long arg);
-static int booke_wdt_open(struct inode *inode, struct file *file);
-static int booke_wdt_release(struct inode *inode, struct file *file);
-static int booke_wdt_notify_sys(struct notifier_block *this, unsigned long code,void *unused);
-static int __init booke_wdt_init(void);
-static void __exit booke_wdt_exit(void);
-
-/*
* Watchdog operations on PPC4xx/e500 MPU
*/
-
/**
* __booke_wdt_setup_val
* Enable Watchdog, sets up passed in values for TCR[WP],
* TCR[WRC]
*
* @period: Input Watchdog Period - TCR[WP]
- * 0 = 217 clocks
- * 1 = 221 clocks
- * 2 = 225 clocks
- * 3 = 229 clocks
- * @reset: Watchdog reset control - TCR[WRC]
+ * 0...2^17(PPC405) or 2^21(PPC440/e500) clocks
+ * 1...2^21(PPC405) or 2^25(PPC440/e500) clocks
+ * 2...2^25(PPC405) or 2^29(PPC440/e500) clocks
+ * 3...2^25(PPC405) or 2^29(PPC440/e500) clocks
+ * @reset: Watchdog reset control - TCR[WRC]
* 0 = No reset
* 1 = PPC Core reset only
* 2 = PPC Chip reset
* 3 = System reset
- * Note: The meaning of period number is differ PPC440GP from PPC440GX.
+ * Note: The meaning of period number is differ PPC405 from PPC440.
+ * Current version assume that this function called with
+ * WRC_NONE as reset, if someone who want to remove this
+ * constraint, please note that when we disable WDT, we should
+ * set WRC with WRC_NONE and s/he should also modify
+ * disable/enable_wdt function.
+ *
*/
-#if defined(CONFIG_4xx)
static __inline__ void
__booke_wdt_setup_val(int period,int reset)
{
unsigned long val;
/* Set up TCR */
- val=((period)<<WDT_TCR_WP_SHIFT|(reset)<<WDT_TCR_WRC_SHIFT)|mfspr(SPRN_TCR);
- /* Disable WDT */
- val &= ~(WDT_TCR_WDT_ENABLE);
-
- mtspr(SPRN_TCR,val);
-}
-#else
-/* e500 */
-static __inline__ void
-__booke_wdt_setup_val(int period,int reset)
-{
- unsigned long val;
- /* Set up TCR */
-
- val=(((period)&(WDT_TCR_WP_BITMSK)) << WDT_TCR_WP_SHIFT|
- ( ( (period) >> 2 )&(WDT_TCR_WPEXT_BITMSK)) << WDT_TCR_WPEXT_SHIFT|
- (reset)<<WDT_TCR_WRC_SHIFT)|mfspr(SPRN_TCR);
+ val=wdt_calculate_tcr(period,reset)| mfspr(SPRN_TCR);
/* Disable WDT */
- val &= ~(WDT_TCR_WDT_ENABLE);
+ val &= ~(TCR_WIE);
mtspr(SPRN_TCR,val);
}
-#endif /* CONFIG_E500 */
/**
* __booke_wdt_enable
* Enable Watchdog
@@ -163,7 +120,7 @@
static __inline__ void
__booke_wdt_enable(void)
{
- mtspr(SPRN_TCR,(mfspr(SPRN_TCR)|WDT_TCR_WDT_ENABLE));
+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)|TCR_WIE));
}
/**
* __booke_wdt_disable
@@ -172,7 +129,7 @@
static __inline__ void
__booke_wdt_disable(void)
{
- mtspr(SPRN_TCR,(mfspr(SPRN_TCR)&(~(WDT_TCR_WDT_ENABLE))));
+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)&(~(TCR_WIE))));
}
/**
* __booke_wdt_is_enabled
@@ -181,7 +138,7 @@
static __inline__ int
__booke_wdt_is_enabled(void)
{
- return (mfspr(SPRN_TCR) & WDT_TCR_WDT_ENABLE);
+ return (mfspr(SPRN_TCR) & TCR_WIE);
}
/**
* __booke_wdt_clear_init_stat
@@ -272,6 +229,7 @@
void
booke_wdt_exception(struct pt_regs *regs)
{
+
wdt_enable=0;
__booke_wdt_disable();
printk("WDT Exception at PC: %lx, MSR: %lx, vector=%lx %s\n",
@@ -294,6 +252,7 @@
static __inline__ int
booke_wdt_start(void)
{
+
__booke_wdt_enable();
return 0;
}
@@ -306,6 +265,7 @@
static __inline__ int
booke_wdt_stop (void)
{
+
__booke_wdt_disable();
return 0;
}
@@ -318,6 +278,7 @@
static __inline__ int
booke_wdt_ping(void)
{
+
/* Disable watchdog */
__booke_wdt_disable();
/* Write a watchdog value */
@@ -340,6 +301,7 @@
static __inline__ int
booke_wdt_set_timeout(int t)
{
+
if ((t < WDT_HEARTBEAT_MIN) || (t > WDT_HEARTBEAT_MAX))
return -EINVAL;
@@ -360,6 +322,7 @@
static __inline__ int
booke_wdt_get_status(int *status)
{
+
if (wdt_enable)
*status = WDIOS_ENABLECARD;
else
@@ -378,11 +341,12 @@
static void
booke_wdt_init_device(void)
{
- /* Hardware WDT provided by the processor.
+
+ /* Hardware WDT provided by the processor.
* So, we set firmware version as processor version number.
*/
ident.firmware_version=mfspr(PVR);
- __booke_wdt_setup_val(WDT_WP,WDT_RESET_NONE);
+ __booke_wdt_setup_val(WDT_WP,WRC_NONE);
}
/**
* booke_wdt_write:
@@ -401,22 +365,22 @@
{
size_t i;
- if (!nowayout) {
- /* In case it was set long ago */
- clear_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+ if (!nowayout) {
+ /* In case it was set long ago */
+ clear_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
- for (i = 0; i < count; i++) {
- char c;
+ for (i = 0; i < count; i++) {
+ char c;
- if (get_user(c, buf + i))
- return -EFAULT;
+ if (get_user(c, buf + i))
+ return -EFAULT;
- if (c == 'V') {
- set_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
- }
+ if (c == 'V') {
+ set_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
}
}
- booke_wdt_ping();
+ }
+ booke_wdt_ping();
return count;
}
@@ -523,12 +487,12 @@
booke_wdt_release(struct inode *inode, struct file *file)
{
if (test_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state)) {
- booke_wdt_note("WDT device is stopped.\n");
+ booke_wdt_info("WDT device is stopped.\n");
booke_wdt_stop();
wdt_enable=0;
} else {
if ( (booke_wdt_is_enabled()) && (!nowayout) ) {
- booke_wdt_note("WDT device may be closed unexpectedly. WDT will not stop!\n");
+ booke_wdt_info("WDT device may be closed unexpectedly. WDT will not stop!\n");
booke_wdt_ping();
}
}
--- linux-2.6.11-booke-wdt/drivers/char/watchdog/booke_wdt.h 2005-03-04 16:38:58.000000000 +0900
+++ linux-2.6.11-wdt/drivers/char/watchdog/booke_wdt.h 2005-03-07 04:08:46.702851618 +0900
@@ -22,6 +22,7 @@
#include <linux/kernel.h>
#include <linux/ptrace.h>
#include <linux/watchdog.h>
+#include <asm/reg_booke.h>
/*
* Driver state flags(bit position)
@@ -32,32 +33,10 @@
* Configurations
*/
#define WDT_TIMO 60000 /* Default timeout = 60000 ms(1min) */
-#define WDT_HEARTBEAT_MIN 100 /* Minimum timeout = 100 ms */
-#define WDT_HEARTBEAT_MAX 600000 /* Maximum timeout = 600000ms(1hour) */
+#define WDT_HEARTBEAT_MIN 100 /* Minimum timeout = 100 ms */
+#define WDT_HEARTBEAT_MAX 600000 /* Maximum timeout = 600000ms(1hour) */
#ifdef __KERNEL__
//#define BOOKE_WDT_DEBUG /* Debug switch */
-/*
- * Reset type
- */
-#define WDT_RESET_NONE 0
-#define WDT_RESET_CORE 1
-#define WDT_RESET_CHIP 2
-#define WDT_RESET_SYS 3
-/*
- * Bit positions in TCR register on PPC4xx/e500 series.
- */
-#define WDT_TCR_WP_BIT 1 /* WP bit in TCR (bit[0..1]) */
-#define WDT_TCR_WRC_BIT 3 /* WRC bit in TCR (bit[2..3]) */
-#define WDT_TCR_WIE_BIT 4 /* WIE bit in TCR (bit[4]) */
-/*
- * TCR[WP] relevant definitions
- */
-#define WDT_TCR_WP_SHIFT (31 - WDT_TCR_WP_BIT)
-#define WDT_TCR_WRC_SHIFT (31 - WDT_TCR_WRC_BIT)
-#define WDT_TCR_WIE_SHIFT (31 - WDT_TCR_WIE_BIT)
-#define WDT_TCR_WDT_ENABLE (1<<WDT_TCR_WIE_SHIFT)
-/* MASK value to obatain TCR[WP] */
-#define WDT_TCR_WP_MASK (3<<(WDT_TCR_WP_SHIFT))
/* Watchdog timer periods can be set on PPC 4xx cpus. */
#if defined(CONFIG_4xx)
@@ -68,6 +47,7 @@
#define WDT_WP1 1
#define WDT_WP2 2
#define WDT_WP3 3
+#define wdt_calculate_tcr(period,reset) ( TCR_WP(period) | TCR_WRC(reset) )
#else
#if defined(CONFIG_E500)
/*
@@ -81,9 +61,16 @@
#define WDT_WP1 25
#define WDT_WP2 29
#define WDT_WP3 33
-#define WDT_TCR_WP_BITMSK 0x3 /* 2bit length */
+#define WDT_TCR_WP_BITLEN 2 /* 2bit length */
+#define WDT_TCR_WP_BITMSK ((1<<(WDT_TCR_WP_BITLEN))-1) /* mask */
#define WDT_TCR_WPEXT_BITMSK 0xf /* 4bit length */
-#define WDT_TCR_WPEXT_SHIFT 17
+#define WDT_TCR_WPEXT_SHIFT 17
+#define WDT_WPEXT_VAL(period) (((period)>>WDT_TCR_WP_BITLEN)& \
+ (WDT_TCR_WPEXT_BITMSK))
+#define wdt_calculate_tcr(period,reset) \
+ ( TCR_WP((period)&(WDT_TCR_WP_BITMSK)) |\
+ TCR_WRC((reset)) |\
+ ( WDT_WPEXT_VAL(period) << WDT_TCR_WPEXT_SHIFT))
#else
#error "Book E WDT detects invalid configuration(Unknown CPU)"
#endif /* CONFIG_E500 */
@@ -111,8 +98,6 @@
printk(KERN_NOTICE __BOOKE_WDT_MSG fmt,##arg)
#define booke_wdt_err(fmt,arg...) \
printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
-#define booke_wdt_crit(fmt,arg...) \
- printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
#if defined(BOOKE_WDT_DEBUG)
#define booke_wdt_dbg(fmt,arg...) \
printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
^ permalink raw reply
* [patch 2/3] macintosh/mediabay: replace schedule_timeout() with msleep_interruptible()
From: domen @ 2005-03-06 10:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, domen, nacc
Use msleep_interruptible() instead of schedule_timeout() to
guarantee the task delays as expected. Also remove macro MS_TO_HZ() and
replace with msecs_to_jiffies().
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj-domen/drivers/macintosh/mediabay.c | 32 +++++++++++++-------------------
1 files changed, 13 insertions(+), 19 deletions(-)
diff -puN drivers/macintosh/mediabay.c~msleep_interruptible-drivers_macintosh_mediabay drivers/macintosh/mediabay.c
--- kj/drivers/macintosh/mediabay.c~msleep_interruptible-drivers_macintosh_mediabay 2005-03-05 16:09:14.000000000 +0100
+++ kj-domen/drivers/macintosh/mediabay.c 2005-03-05 16:09:14.000000000 +0100
@@ -98,11 +98,6 @@ int media_bay_count = 0;
#define MB_IDE_READY(i) ((readb(media_bays[i].cd_base + 0x70) & 0x80) == 0)
#endif
-/* Note: All delays are not in milliseconds and converted to HZ relative
- * values by the macro below
- */
-#define MS_TO_HZ(ms) ((ms * HZ + 999) / 1000)
-
/*
* Wait that number of ms between each step in normal polling mode
*/
@@ -384,7 +379,7 @@ static inline void __pmac set_mb_power(s
bay->state = mb_powering_down;
MBDBG("mediabay%d: powering down\n", bay->index);
}
- bay->timer = MS_TO_HZ(MB_POWER_DELAY);
+ bay->timer = msecs_to_jiffies(MB_POWER_DELAY);
}
static void __pmac poll_media_bay(struct media_bay_info* bay)
@@ -393,8 +388,8 @@ static void __pmac poll_media_bay(struct
if (id == bay->last_value) {
if (id != bay->content_id) {
- bay->value_count += MS_TO_HZ(MB_POLL_DELAY);
- if (bay->value_count >= MS_TO_HZ(MB_STABLE_DELAY)) {
+ bay->value_count += msecs_to_jiffies(MB_POLL_DELAY);
+ if (bay->value_count >= msecs_to_jiffies(MB_STABLE_DELAY)) {
/* If the device type changes without going thru
* "MB_NO", we force a pass by "MB_NO" to make sure
* things are properly reset
@@ -504,7 +499,7 @@ static void __pmac media_bay_step(int i)
/* If timer expired or polling IDE busy, run state machine */
if ((bay->state != mb_ide_waiting) && (bay->timer != 0)) {
- bay->timer -= MS_TO_HZ(MB_POLL_DELAY);
+ bay->timer -= msecs_to_jiffies(MB_POLL_DELAY);
if (bay->timer > 0)
return;
bay->timer = 0;
@@ -517,13 +512,13 @@ static void __pmac media_bay_step(int i)
set_mb_power(bay, 0);
break;
}
- bay->timer = MS_TO_HZ(MB_RESET_DELAY);
+ bay->timer = msecs_to_jiffies(MB_RESET_DELAY);
bay->state = mb_enabling_bay;
MBDBG("mediabay%d: enabling (kind:%d)\n", i, bay->content_id);
break;
case mb_enabling_bay:
bay->ops->un_reset(bay);
- bay->timer = MS_TO_HZ(MB_SETUP_DELAY);
+ bay->timer = msecs_to_jiffies(MB_SETUP_DELAY);
bay->state = mb_resetting;
MBDBG("mediabay%d: waiting reset (kind:%d)\n", i, bay->content_id);
break;
@@ -537,7 +532,7 @@ static void __pmac media_bay_step(int i)
#ifdef CONFIG_BLK_DEV_IDE
MBDBG("mediabay%d: waiting IDE reset (kind:%d)\n", i, bay->content_id);
bay->ops->un_reset_ide(bay);
- bay->timer = MS_TO_HZ(MB_IDE_WAIT);
+ bay->timer = msecs_to_jiffies(MB_IDE_WAIT);
bay->state = mb_ide_resetting;
#else
printk(KERN_DEBUG "media-bay %d is ide (not compiled in kernel)\n", i);
@@ -547,7 +542,7 @@ static void __pmac media_bay_step(int i)
#ifdef CONFIG_BLK_DEV_IDE
case mb_ide_resetting:
- bay->timer = MS_TO_HZ(MB_IDE_TIMEOUT);
+ bay->timer = msecs_to_jiffies(MB_IDE_TIMEOUT);
bay->state = mb_ide_waiting;
MBDBG("mediabay%d: waiting IDE ready (kind:%d)\n", i, bay->content_id);
break;
@@ -583,7 +578,7 @@ static void __pmac media_bay_step(int i)
}
break;
} else if (bay->timer > 0)
- bay->timer -= MS_TO_HZ(MB_POLL_DELAY);
+ bay->timer -= msecs_to_jiffies(MB_POLL_DELAY);
if (bay->timer <= 0) {
printk("\nIDE Timeout in bay %d !, IDE state is: 0x%02x\n",
i, readb(bay->cd_base + 0x70));
@@ -641,8 +636,7 @@ static int __pmac media_bay_task(void *x
up(&media_bays[i].lock);
}
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(MS_TO_HZ(MB_POLL_DELAY));
+ msleep_interruptible(MB_POLL_DELAY);
if (signal_pending(current))
return 0;
}
@@ -691,7 +685,7 @@ static int __devinit media_bay_attach(st
msleep(MB_POWER_DELAY);
bay->content_id = MB_NO;
bay->last_value = bay->ops->content(bay);
- bay->value_count = MS_TO_HZ(MB_STABLE_DELAY);
+ bay->value_count = msecs_to_jiffies(MB_STABLE_DELAY);
bay->state = mb_empty;
do {
msleep(MB_POLL_DELAY);
@@ -747,8 +741,8 @@ static int __pmac media_bay_resume(struc
}
set_mb_power(bay, 1);
bay->last_value = bay->content_id;
- bay->value_count = MS_TO_HZ(MB_STABLE_DELAY);
- bay->timer = MS_TO_HZ(MB_POWER_DELAY);
+ bay->value_count = msecs_to_jiffies(MB_STABLE_DELAY);
+ bay->timer = msecs_to_jiffies(MB_POWER_DELAY);
#ifdef CONFIG_BLK_DEV_IDE
bay->cd_retry = 0;
#endif
_
^ permalink raw reply
* [patch 1/3] list_for_each_entry: drivers-macintosh-via-pmu.c
From: domen @ 2005-03-06 10:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, janitor, domen
Make code more readable with list_for_each_entry.
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj-domen/drivers/macintosh/via-pmu.c | 18 ++++--------------
1 files changed, 4 insertions(+), 14 deletions(-)
diff -puN drivers/macintosh/via-pmu.c~list-for-each-entry-drivers_macintosh_via-pmu drivers/macintosh/via-pmu.c
--- kj/drivers/macintosh/via-pmu.c~list-for-each-entry-drivers_macintosh_via-pmu 2005-03-05 16:09:01.000000000 +0100
+++ kj-domen/drivers/macintosh/via-pmu.c 2005-03-05 16:09:01.000000000 +0100
@@ -2054,12 +2054,9 @@ static LIST_HEAD(sleep_notifiers);
int
pmu_register_sleep_notifier(struct pmu_sleep_notifier *n)
{
- struct list_head *list;
struct pmu_sleep_notifier *notifier;
- for (list = sleep_notifiers.next; list != &sleep_notifiers;
- list = list->next) {
- notifier = list_entry(list, struct pmu_sleep_notifier, list);
+ list_for_each_entry(notifier, &sleep_notifiers, list) {
if (n->priority > notifier->priority)
break;
}
@@ -2085,8 +2082,7 @@ broadcast_sleep(int when, int fallback)
struct list_head *list;
struct pmu_sleep_notifier *notifier;
- for (list = sleep_notifiers.prev; list != &sleep_notifiers;
- list = list->prev) {
+ list_for_each_prev(list, &sleep_notifiers) {
notifier = list_entry(list, struct pmu_sleep_notifier, list);
ret = notifier->notifier_call(notifier, when);
if (ret != PBOOK_SLEEP_OK) {
@@ -2107,14 +2103,10 @@ static int __pmac
broadcast_wake(void)
{
int ret = PBOOK_SLEEP_OK;
- struct list_head *list;
struct pmu_sleep_notifier *notifier;
- for (list = sleep_notifiers.next; list != &sleep_notifiers;
- list = list->next) {
- notifier = list_entry(list, struct pmu_sleep_notifier, list);
+ list_for_each_entry(notifier, &sleep_notifiers, list)
notifier->notifier_call(notifier, PBOOK_WAKE);
- }
return ret;
}
@@ -2716,15 +2708,13 @@ static void __pmac
pmu_pass_intr(unsigned char *data, int len)
{
struct pmu_private *pp;
- struct list_head *list;
int i;
unsigned long flags;
if (len > sizeof(pp->rb_buf[0].data))
len = sizeof(pp->rb_buf[0].data);
spin_lock_irqsave(&all_pvt_lock, flags);
- for (list = &all_pmu_pvt; (list = list->next) != &all_pmu_pvt; ) {
- pp = list_entry(list, struct pmu_private, list);
+ list_for_each_entry(pp, &all_pmu_pvt, list) {
spin_lock(&pp->lock);
i = pp->rb_put + 1;
if (i >= RB_SIZE)
_
^ permalink raw reply
* [patch 3/3] drivers/macintoshisdn/*: convert to pci_register_driver
From: domen @ 2005-03-06 10:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, c.lucas, domen
convert from pci_module_init to pci_register_driver
Signed-off-by: Christophe Lucas <c.lucas@ifrance.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
kj-domen/drivers/macintosh/macio_asic.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/macintosh/macio_asic.c~pci_register_driver-drivers_macintosh_macio_asic drivers/macintosh/macio_asic.c
--- kj/drivers/macintosh/macio_asic.c~pci_register_driver-drivers_macintosh_macio_asic 2005-03-05 16:12:26.000000000 +0100
+++ kj-domen/drivers/macintosh/macio_asic.c 2005-03-05 16:12:26.000000000 +0100
@@ -617,7 +617,7 @@ static int __init macio_module_init (voi
#ifdef CONFIG_PCI
int rc;
- rc = pci_module_init(&macio_pci_driver);
+ rc = pci_register_driver(&macio_pci_driver);
if (rc)
return rc;
#endif /* CONFIG_PCI */
_
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Dale Farnsworth @ 2005-03-06 10:29 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050306070248.GA6673@pegasos>
On Sun, Mar 06, 2005 at 08:02:48AM +0100, Sven Luther wrote:
> On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote:
> > By all means, try it. Several people are using it without complaints, but
> > I'd appreciate your feedback. There isn't anything dangerous in there.
> > Gigabit works for me. I'm not sure what Kconfig parts would be needed
> > specifically for gigabit support.
>
> I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to
> build it, and even insmod it, but the module doesn't do a thing, and not even
> a single line shows up in dmesg. I guess i am either missing a part of the
> patch or there is something wrong with the probe code.
>
> I have gotten the diff against :
>
> include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig,
> adding :
>
> config MV643XX_ETH
> tristate "MV-643XX Ethernet support"
> - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
> + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
> help
> This driver supports the gigabit Ethernet on the Marvell MV643XX
> - chipset which is used in the Momenco Ocelot C and Jaguar ATX.
> + chipset which is used in the Momenco Ocelot C and Jaguar ATX and
> + Pegasos II, amongst other PPC and MIPS boards.
>
> I have no idea where your MV64360 comes from, it seems to be not existent in
> any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a
> recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find
> combo :/ Will have to look more.
MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
CHESTNUT. If I understand correctly, it should be defined for any
board using the MV64360. I don't think we want the PPC_CHRP dependency.
> Anyway, how do you probe for the chip ? On the pegasos we used to map on the
> marvell pci id :
>
> 0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362
> System Controller (rev 03)
>
> too bad Marvell didn't do the logical thing and made the ethernet port appear
> as separated devices on a third internal pci bus.
The mv643xx_eth probe is dependent on having the appropriate
platform device entry. See eth0_device and mv64x60_add_pds() in
arch/ppc/syslib/mv643x60.c .
-Dale
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Sven Luther @ 2005-03-06 7:02 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050305225128.GC16904@xyzzy>
On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote:
> On Sat, Mar 05, 2005 at 09:32:54PM +0100, Sven Luther wrote:
> > On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> > > On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > > > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
> > >
> > > I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> > > direct related code between the ppc specific mv64x60 stuff, and the mips
> > > related ethernet one.
> >
> > Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of
> > those are just 64340-> 643xx replacements though.
>
> Yes, renames and Lindent make for big diffs.
Ah, ...
Well, maybe i will need to do a minimal patch without renaming for the debian
2.6.11 kernel, but we will see.
> > What are your plans for mainline inclusion of the rest of those, and is it ok
>
> I've submitted it for mainline inclusion. Jeff Garzik put it in
> netdev-2.6 (and thus in the mm patches) for testing and it's on track
> for going into mainline. I hope it will happen in the next few days,
> but that's up to Jeff.
Ok.
> > to work directly with your stuff ? Do you have any experimental or dangerous
> > parts in the above ? And did you ever get the gigabit ethernet port working on
> > a powerpc board ? Or are there some Kconfig parts i have missed ?
>
> By all means, try it. Several people are using it without complaints, but
> I'd appreciate your feedback. There isn't anything dangerous in there.
> Gigabit works for me. I'm not sure what Kconfig parts would be needed
> specifically for gigabit support.
I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to
build it, and even insmod it, but the module doesn't do a thing, and not even
a single line shows up in dmesg. I guess i am either missing a part of the
patch or there is something wrong with the probe code.
I have gotten the diff against :
include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig,
adding :
config MV643XX_ETH
tristate "MV-643XX Ethernet support"
- depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
+ depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
help
This driver supports the gigabit Ethernet on the Marvell MV643XX
- chipset which is used in the Momenco Ocelot C and Jaguar ATX.
+ chipset which is used in the Momenco Ocelot C and Jaguar ATX and
+ Pegasos II, amongst other PPC and MIPS boards.
I have no idea where your MV64360 comes from, it seems to be not existent in
any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a
recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find
combo :/ Will have to look more.
Anyway, how do you probe for the chip ? On the pegasos we used to map on the
marvell pci id :
0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362
System Controller (rev 03)
too bad Marvell didn't do the logical thing and made the ethernet port appear
as separated devices on a third internal pci bus.
> Updates are coming though. James Chapman has sent me several patches
> that provide: use of the mii library for phy management, additional
> ethtool support, message level support, compile fix for non-NAPI, and
> much cleanup. We're working the kinks out now and I expect to submit
> these patches in the next few days.
Ok, let's make sure it works on pegasos before then.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Dale Farnsworth @ 2005-03-05 22:51 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050305203254.GB30151@pegasos>
On Sat, Mar 05, 2005 at 09:32:54PM +0100, Sven Luther wrote:
> On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> > On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
> >
> > I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> > direct related code between the ppc specific mv64x60 stuff, and the mips
> > related ethernet one.
>
> Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of
> those are just 64340-> 643xx replacements though.
Yes, renames and Lindent make for big diffs.
> What are your plans for mainline inclusion of the rest of those, and is it ok
I've submitted it for mainline inclusion. Jeff Garzik put it in
netdev-2.6 (and thus in the mm patches) for testing and it's on track
for going into mainline. I hope it will happen in the next few days,
but that's up to Jeff.
> to work directly with your stuff ? Do you have any experimental or dangerous
> parts in the above ? And did you ever get the gigabit ethernet port working on
> a powerpc board ? Or are there some Kconfig parts i have missed ?
By all means, try it. Several people are using it without complaints, but
I'd appreciate your feedback. There isn't anything dangerous in there.
Gigabit works for me. I'm not sure what Kconfig parts would be needed
specifically for gigabit support.
Updates are coming though. James Chapman has sent me several patches
that provide: use of the mii library for phy management, additional
ethtool support, message level support, compile fix for non-NAPI, and
much cleanup. We're working the kinks out now and I expect to submit
these patches in the next few days.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Dale Farnsworth @ 2005-03-05 21:58 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050305192752.GA28491@pegasos>
On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > All of my changes to the mv643xx ethernet driver have been posted to
> > LKML or the netdev list. I have removed all arch-specific code from
> > the ethernet driver itself.
>
> What is the status of this with regard to the 2.6.11 mainline kernel ?
I'm hopeful they will go in this week to make 2.6.12
> > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
>
> I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> direct related code between the ppc specific mv64x60 stuff, and the mips
> related ethernet one.
Yes.
> Well, as i am doing the powerpc debian 2.6.11 kernel, i really would like to
> port your work to the pegasos, but what i have seen from the code in the
> mainline kernel doesn't really make sense.
Benh also mentioned porting it to pegasos, but I haven't heard that he's
gotten to it.
-Dale
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Sven Luther @ 2005-03-05 20:32 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050305192752.GA28491@pegasos>
On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > On Thu, Feb 24, 2005 at 04:04:11PM +0000, Sven Luther wrote:
> > > > >I am a bit bewildered by what you are doing here. How does this mv64x60
> > > > >code relate to the mv643xx_eth driver from the mips folk ?
> > >
> > > [...]
> > >
> > > On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
> > > > has spent a lot of time making it work on both MIPS and PPC. The code
> > > > you see in the mv64x60.c file is a part of that. I believe that Dale's
> > >
> > > Ok, so the code in question is in addition to the existing driver from the
> > > mips guys and works with it ? I had the impression that it was a separate
> > > driver development or something.
> >
> > The code in mv64x60.c is related to but separate from the ethernet driver.
> > It is platform-specific code that passes register addresses, irqs,
> > mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.
> >
> > All of my changes to the mv643xx ethernet driver have been posted to
> > LKML or the netdev list. I have removed all arch-specific code from
> > the ethernet driver itself.
>
> What is the status of this with regard to the 2.6.11 mainline kernel ?
>
> > > Ok. Do you know if Dale's patches are available separatedly while they are not
> > > yet in mainline, so Nicolas Det can work on them and make sure they also work
> > > on the Pegasos board, which is not an embedded board but from the chrp
> >
> > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
>
> I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> direct related code between the ppc specific mv64x60 stuff, and the mips
> related ethernet one.
Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of
those are just 64340-> 643xx replacements though.
What are your plans for mainline inclusion of the rest of those, and is it ok
to work directly with your stuff ? Do you have any experimental or dangerous
parts in the above ? And did you ever get the gigabit ethernet port working on
a powerpc board ? Or are there some Kconfig parts i have missed ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Sven Luther @ 2005-03-05 19:27 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Nicolas DET, linuxppc-embedded
In-Reply-To: <20050224172420.GA6932@xyzzy>
On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> On Thu, Feb 24, 2005 at 04:04:11PM +0000, Sven Luther wrote:
> > > >I am a bit bewildered by what you are doing here. How does this mv64x60
> > > >code relate to the mv643xx_eth driver from the mips folk ?
> >
> > [...]
> >
> > On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
> > > has spent a lot of time making it work on both MIPS and PPC. The code
> > > you see in the mv64x60.c file is a part of that. I believe that Dale's
> >
> > Ok, so the code in question is in addition to the existing driver from the
> > mips guys and works with it ? I had the impression that it was a separate
> > driver development or something.
>
> The code in mv64x60.c is related to but separate from the ethernet driver.
> It is platform-specific code that passes register addresses, irqs,
> mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.
>
> All of my changes to the mv643xx ethernet driver have been posted to
> LKML or the netdev list. I have removed all arch-specific code from
> the ethernet driver itself.
What is the status of this with regard to the 2.6.11 mainline kernel ?
> > Ok. Do you know if Dale's patches are available separatedly while they are not
> > yet in mainline, so Nicolas Det can work on them and make sure they also work
> > on the Pegasos board, which is not an embedded board but from the chrp
>
> See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
direct related code between the ppc specific mv64x60 stuff, and the mips
related ethernet one.
> > lineage. Nicolas already did some mv643xx ethernet driver work last summer,
> > but apparently had trouble integrating this in the mainline kernel, and it
>
> I'm sorry I wasn't aware of Nicolas' work on the driver.
>
> > seems his work has now been redone by Dale or something. Do you know who the
> > right person to communicate with about this would be ? The MIPS folk didn't
> > reply to any of our mails about this subject.
>
> Sounds familiar. Fortunately, Jeff Garzik picked up my changes.
> I would appreciate feedback from you or Nicolas on the current driver.
Well, as i am doing the powerpc debian 2.6.11 kernel, i really would like to
port your work to the pegasos, but what i have seen from the code in the
mainline kernel doesn't really make sense.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] WDT Driver for Book-E [2/2] Device driver part.
From: Takeharu KATO @ 2005-03-05 8:11 UTC (permalink / raw)
To: Josh Boyer; +Cc: ppcembed
In-Reply-To: <1109982868.1479.22.camel@jdub.homelinux.org>
Dear Josh:
Thank you for your thorough review.
Josh Boyer wrote:
> This is slightly wrong. Not all 4xx processors are BOOKE. 403 and 405
> aren't to be specific. But it's not really that big of a deal I guess.
>
>
I know this.
As you said, I regard this with minor thing.
>>+
>>+#ifdef CONFIG_WATCHDOG_NOWAYOUT
>>+static int nowayout = 1;
>>+#else
>>+static int nowayout = 0;
>>+#endif
>
>
> Couldn't you just use the #ifdef in the release function and not
> "disable" the watchdog? It would save a global variable at least.
>
At first, I examined to remove the release file operation
to eliminate this global variable.
On second thought, I decided to use this global variable as
drivers/char/watchdog/wdt.c.
I think that the release file operation is necessary to control
so as not to open the device more than twice.
This behavior is commonly used in other watch dog drivers,
doesn't it?
>>+static int __init booke_wdt_init(void);
>>+static void __exit booke_wdt_exit(void);
>
>
> If you order these in the right way, you don't need to declare them in
> advance.
>
Ok, I'll remove them.
>
>>+/**
>>+ * __booke_wdt_enable
>>+ * Enable Watchdog
>>+ */
>>+static __inline__ void
>>+__booke_wdt_enable(void)
>>+{
>>+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)|WDT_TCR_WDT_ENABLE));
>>+}
>>+/**
>>+ * __booke_wdt_disable
>>+ * Disable Watchdog
>>+ */
>>+static __inline__ void
>>+__booke_wdt_disable(void)
>>+{
>>+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)&(~(WDT_TCR_WDT_ENABLE))));
>>+}
>
>
> These two functions are somewhat misleading. On 4xx the timer is
> essentially always enabled. The bit you are setting and clearing here
> is just to enable the exception after the expiration of the 2nd WP. The
> reason I bring this up is because if you ever set TCR[WRC] to something
> non-zero and this bit is off, the processor will just be reset after 3
> watchdog periods. In other words, if TCR[WRC] is ever non-zero there is
> no such thing as disabling the timer. You will always need to do the
> ping to keep the processor from resetting.
>
I agree that function names like XXX_wdt_enable(or disable) are not
reflected on precise meaning.
But in this driver, we set TCR[WRC] as zero.It is needed to detect and
logging WDT timeout with software before MPU reset. I want to leave the
way to find where the system hang up.
IMHO, this is the reason to use WDT in the system.
So, I will not support non-zero TCR[WRC].
From the above-mentioned viewpoint, making WDT exception enabled (or
disabled) means start/stop WDT itself in this driver.
This is the reason to adopt these names.
Please note that the system will panic before the CPU attempt to reset
CPU when we use this driver.
Please let me hear it if there are some opinions.
>
> Since you're using WDT_RESET_NONE, I think what you have here should
> work.
>
Yes, however, it is implemented on purpose.
>>+/*
>>+ * WP relevant values used in our driver.
>>+ * Note:WDT period must be more than HZ(Timer ticks)
>>+ */
>>+#define WDT_WP WDT_WP3
>
>
> Most of this is in include/asm-ppc/reg_booke.h. Could you use that
> instead of redefining most of it?
>
To tell the truth, this matter has been examined, but I forgot this.
Thank you for making it recall(^^
>
> In include/linux/device.h there are dev_printk and dev_dbg macros that
> do pretty much the same thing. Could you use those instead?
>
I did not know such thing.
I'll try to use them.
Regards,
--
Takeharu KATO
^ 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