SystemACE but not V2PRO

SystemACE but not V2PRO

[Stephen Williams]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]


The attached patch is my spin at getting the existing xsysace
block driver working on systems that have SystemACE chips, but
do not use Virtex-II-Pro chips. The adapter.c file assumes that
the system ace halt will halt the processor. This is not the
case in general, so this patch ifdefs that part of the code out
using CONFIG_VIRTEX_II_PRO.

This is only part of the story for getting the systemace
working in general, but the remaining bits are configuration
issues, not code/driver support.

Question: Who is the maintainer for this section of code? It
is maybe MonteVista?
--
Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[-- Attachment #2: sysace-without-v2pro.patch --]
[-- Type: text/plain, Size: 1836 bytes --]

Index: drivers/block/xilinx_sysace/adapter.c
===================================================================
RCS file: /cvsroot/linuxppc_2_4_devel/drivers/block/xilinx_sysace/adapter.c,v
retrieving revision 1.3
diff -p -u -r1.3 adapter.c
--- drivers/block/xilinx_sysace/adapter.c	30 Oct 2003 00:32:49 -0000	1.3
+++ drivers/block/xilinx_sysace/adapter.c	2 Apr 2004 02:27:37 -0000
@@ -74,7 +74,9 @@ MODULE_LICENSE("GPL");
 static const int dont_spin = 0;

 static u32 save_BaseAddress;	/* Saved physical base address */
+#ifdef CONFIG_VIRTEX_II_PRO
 static void (*old_restart) (char *cmd) = NULL;	/* old ppc_md.restart */
+#endif

 static unsigned char heads;
 static unsigned char sectors;
@@ -277,6 +279,13 @@ proc_cleanup(void)
 }
 #endif

+#ifdef CONFIG_VIRTEX_II_PRO
+/*
+ * The XSysAce_ResetCfg function causes the SystemACE to reset the
+ * Xilinx chain that is attached to it. If I am a Virtex II Pro, then
+ * presumably that includes me. Thus, The ResetCfg will ultimately
+ * reset me, the processor, end of story.
+ */
 static void
 xsysace_restart(char *cmd)
 {
@@ -285,6 +294,7 @@ xsysace_restart(char *cmd)
 	/* Wait for reset. */
 	for (;;) ;
 }
+#endif

 /*
  * The code to handle the block device starts here.
@@ -725,8 +735,10 @@ cleanup(void)
 	iounmap((void *) cfg->BaseAddress);
 	cfg->BaseAddress = save_BaseAddress;

+#ifdef CONFIG_VIRTEX_II_PRO
 	if (old_restart)
 		ppc_md.restart = old_restart;
+#endif
 }

 static int __init
@@ -837,9 +849,11 @@ xsysace_init(void)
 	       DEVICE_NAME, save_BaseAddress, cfg->BaseAddress, XSA_IRQ,
 	       size / 2);

+#ifdef CONFIG_VIRTEX_II_PRO
 	/* Hook our reset function into system's restart code. */
 	old_restart = ppc_md.restart;
 	ppc_md.restart = xsysace_restart;
+#endif

 	if (proc_init())
 		printk(KERN_WARNING "%s: could not register /proc interface.\n",

Re: SystemACE but not V2PRO

[Scott Anderson]

Hi there,
The current ML300 maintainer is Andrei Konovalov
<akonovalov@ru.mvista.com>
(cc'ed on this message).  I'm guessing he didn't reply to your message
last week because he's swamped, but hopefully having this directly
addressed to him will prompt a response.

   Scott

On Apr 1, 2004, at 6:38 PM, Stephen Williams wrote:

>
> The attached patch is my spin at getting the existing xsysace
> block driver working on systems that have SystemACE chips, but
> do not use Virtex-II-Pro chips. The adapter.c file assumes that
> the system ace halt will halt the processor. This is not the
> case in general, so this patch ifdefs that part of the code out
> using CONFIG_VIRTEX_II_PRO.
>
> This is only part of the story for getting the systemace
> working in general, but the remaining bits are configuration
> issues, not code/driver support.
>
> Question: Who is the maintainer for this section of code? It
> is maybe MonteVista?
> --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at XXXXXXXXXX           But I have promises to keep,
> http://www.XXXXXXXXXX         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> Index: drivers/block/xilinx_sysace/adapter.c
> ===================================================================
> RCS file:
> /cvsroot/linuxppc_2_4_devel/drivers/block/xilinx_sysace/adapter.c,v
> retrieving revision 1.3
> diff -p -u -r1.3 adapter.c
> --- drivers/block/xilinx_sysace/adapter.c	30 Oct 2003 00:32:49
> -0000	1.3
> +++ drivers/block/xilinx_sysace/adapter.c	2 Apr 2004 02:27:37 -0000
> @@ -74,7 +74,9 @@ MODULE_LICENSE("GPL");
>  static const int dont_spin = 0;
>
>  static u32 save_BaseAddress;	/* Saved physical base address */
> +#ifdef CONFIG_VIRTEX_II_PRO
>  static void (*old_restart) (char *cmd) = NULL;	/* old ppc_md.restart
> */
> +#endif
>
>  static unsigned char heads;
>  static unsigned char sectors;
> @@ -277,6 +279,13 @@ proc_cleanup(void)
>  }
>  #endif
>
> +#ifdef CONFIG_VIRTEX_II_PRO
> +/*
> + * The XSysAce_ResetCfg function causes the SystemACE to reset the
> + * Xilinx chain that is attached to it. If I am a Virtex II Pro, then
> + * presumably that includes me. Thus, The ResetCfg will ultimately
> + * reset me, the processor, end of story.
> + */
>  static void
>  xsysace_restart(char *cmd)
>  {
> @@ -285,6 +294,7 @@ xsysace_restart(char *cmd)
>  	/* Wait for reset. */
>  	for (;;) ;
>  }
> +#endif
>
>  /*
>   * The code to handle the block device starts here.
> @@ -725,8 +735,10 @@ cleanup(void)
>  	iounmap((void *) cfg->BaseAddress);
>  	cfg->BaseAddress = save_BaseAddress;
>
> +#ifdef CONFIG_VIRTEX_II_PRO
>  	if (old_restart)
>  		ppc_md.restart = old_restart;
> +#endif
>  }
>
>  static int __init
> @@ -837,9 +849,11 @@ xsysace_init(void)
>  	       DEVICE_NAME, save_BaseAddress, cfg->BaseAddress, XSA_IRQ,
>  	       size / 2);
>
> +#ifdef CONFIG_VIRTEX_II_PRO
>  	/* Hook our reset function into system's restart code. */
>  	old_restart = ppc_md.restart;
>  	ppc_md.restart = xsysace_restart;
> +#endif
>
>  	if (proc_init())
>  		printk(KERN_WARNING "%s: could not register /proc interface.\n",


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: SystemACE but not V2PRO

[Andrei Konovalov]

I've looked at this patch.
At first glance it looks OK, but I'd like to think a little bit more about
it.
I'll come back on Monday, or Tuesday (in worst case).

Thanks,
Andrei

> -----Original Message-----
> From: Scott Anderson [mailto:scott_anderson@mvista.com]
> Sent: Friday, April 02, 2004 8:36 PM
> To: Stephen Williams
> Cc: linuxppc-embedded@lists.linuxppc.org; Andrei Konovalov
> Subject: Re: SystemACE but not V2PRO
>
>
> Hi there,
> The current ML300 maintainer is Andrei Konovalov
> <akonovalov@ru.mvista.com>
> (cc'ed on this message).  I'm guessing he didn't reply to your message
> last week because he's swamped, but hopefully having this directly
> addressed to him will prompt a response.
>
>    Scott
>
> On Apr 1, 2004, at 6:38 PM, Stephen Williams wrote:
>
> >
> > The attached patch is my spin at getting the existing xsysace
> > block driver working on systems that have SystemACE chips, but
> > do not use Virtex-II-Pro chips. The adapter.c file assumes that
> > the system ace halt will halt the processor. This is not the
> > case in general, so this patch ifdefs that part of the code out
> > using CONFIG_VIRTEX_II_PRO.
> >
> > This is only part of the story for getting the systemace
> > working in general, but the remaining bits are configuration
> > issues, not code/driver support.
> >
> > Question: Who is the maintainer for this section of code? It
> > is maybe MonteVista?
> > --
> > Steve Williams                "The woods are lovely, dark and deep.
> > steve at XXXXXXXXXX           But I have promises to keep,
> > http://www.XXXXXXXXXX         and lines to code before I sleep,
> > http://www.picturel.com       And lines to code before I sleep."
> > Index: drivers/block/xilinx_sysace/adapter.c
> > ===================================================================
> > RCS file:
> > /cvsroot/linuxppc_2_4_devel/drivers/block/xilinx_sysace/adapter.c,v
> > retrieving revision 1.3
> > diff -p -u -r1.3 adapter.c
> > --- drivers/block/xilinx_sysace/adapter.c	30 Oct 2003 00:32:49
> > -0000	1.3
> > +++ drivers/block/xilinx_sysace/adapter.c	2 Apr 2004 02:27:37 -0000
> > @@ -74,7 +74,9 @@ MODULE_LICENSE("GPL");
> >  static const int dont_spin = 0;
> >
> >  static u32 save_BaseAddress;	/* Saved physical base address */
> > +#ifdef CONFIG_VIRTEX_II_PRO
> >  static void (*old_restart) (char *cmd) = NULL;	/* old
> ppc_md.restart
> > */
> > +#endif
> >
> >  static unsigned char heads;
> >  static unsigned char sectors;
> > @@ -277,6 +279,13 @@ proc_cleanup(void)
> >  }
> >  #endif
> >
> > +#ifdef CONFIG_VIRTEX_II_PRO
> > +/*
> > + * The XSysAce_ResetCfg function causes the SystemACE to reset the
> > + * Xilinx chain that is attached to it. If I am a Virtex II Pro, then
> > + * presumably that includes me. Thus, The ResetCfg will ultimately
> > + * reset me, the processor, end of story.
> > + */
> >  static void
> >  xsysace_restart(char *cmd)
> >  {
> > @@ -285,6 +294,7 @@ xsysace_restart(char *cmd)
> >  	/* Wait for reset. */
> >  	for (;;) ;
> >  }
> > +#endif
> >
> >  /*
> >   * The code to handle the block device starts here.
> > @@ -725,8 +735,10 @@ cleanup(void)
> >  	iounmap((void *) cfg->BaseAddress);
> >  	cfg->BaseAddress = save_BaseAddress;
> >
> > +#ifdef CONFIG_VIRTEX_II_PRO
> >  	if (old_restart)
> >  		ppc_md.restart = old_restart;
> > +#endif
> >  }
> >
> >  static int __init
> > @@ -837,9 +849,11 @@ xsysace_init(void)
> >  	       DEVICE_NAME, save_BaseAddress, cfg->BaseAddress, XSA_IRQ,
> >  	       size / 2);
> >
> > +#ifdef CONFIG_VIRTEX_II_PRO
> >  	/* Hook our reset function into system's restart code. */
> >  	old_restart = ppc_md.restart;
> >  	ppc_md.restart = xsysace_restart;
> > +#endif
> >
> >  	if (proc_init())
> >  		printk(KERN_WARNING "%s: could not register /proc
> interface.\n",
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: SystemACE but not V2PRO

[Andrei Konovalov]

The patch is OK for me.

Thanks,
Andrei

Andrei Konovalov wrote:
> I've looked at this patch.
> At first glance it looks OK, but I'd like to think a little bit more about
> it.
> I'll come back on Monday, or Tuesday (in worst case).
>
> Thanks,
> Andrei
>
>
>>-----Original Message-----
>>From: Scott Anderson [mailto:scott_anderson@mvista.com]
>>Sent: Friday, April 02, 2004 8:36 PM
>>To: Stephen Williams
>>Cc: linuxppc-embedded@lists.linuxppc.org; Andrei Konovalov
>>Subject: Re: SystemACE but not V2PRO
>>
>>
>>Hi there,
>>The current ML300 maintainer is Andrei Konovalov
>><akonovalov@ru.mvista.com>
>>(cc'ed on this message).  I'm guessing he didn't reply to your message
>>last week because he's swamped, but hopefully having this directly
>>addressed to him will prompt a response.
>>
>>   Scott
>>
>>On Apr 1, 2004, at 6:38 PM, Stephen Williams wrote:
>>
>>
>>>The attached patch is my spin at getting the existing xsysace
>>>block driver working on systems that have SystemACE chips, but
>>>do not use Virtex-II-Pro chips. The adapter.c file assumes that
>>>the system ace halt will halt the processor. This is not the
>>>case in general, so this patch ifdefs that part of the code out
>>>using CONFIG_VIRTEX_II_PRO.
>>>
>>>This is only part of the story for getting the systemace
>>>working in general, but the remaining bits are configuration
>>>issues, not code/driver support.
>>>
>>>Question: Who is the maintainer for this section of code? It
>>>is maybe MonteVista?
>>>--
>>>Steve Williams                "The woods are lovely, dark and deep.
>>>steve at XXXXXXXXXX           But I have promises to keep,
>>>http://www.XXXXXXXXXX         and lines to code before I sleep,
>>>http://www.picturel.com       And lines to code before I sleep."
>>>Index: drivers/block/xilinx_sysace/adapter.c
>>>===================================================================
>>>RCS file:
>>>/cvsroot/linuxppc_2_4_devel/drivers/block/xilinx_sysace/adapter.c,v
>>>retrieving revision 1.3
>>>diff -p -u -r1.3 adapter.c
>>>--- drivers/block/xilinx_sysace/adapter.c	30 Oct 2003 00:32:49
>>>-0000	1.3
>>>+++ drivers/block/xilinx_sysace/adapter.c	2 Apr 2004 02:27:37 -0000
>>>@@ -74,7 +74,9 @@ MODULE_LICENSE("GPL");
>>> static const int dont_spin = 0;
>>>
>>> static u32 save_BaseAddress;	/* Saved physical base address */
>>>+#ifdef CONFIG_VIRTEX_II_PRO
>>> static void (*old_restart) (char *cmd) = NULL;	/* old
>>
>>ppc_md.restart
>>
>>>*/
>>>+#endif
>>>
>>> static unsigned char heads;
>>> static unsigned char sectors;
>>>@@ -277,6 +279,13 @@ proc_cleanup(void)
>>> }
>>> #endif
>>>
>>>+#ifdef CONFIG_VIRTEX_II_PRO
>>>+/*
>>>+ * The XSysAce_ResetCfg function causes the SystemACE to reset the
>>>+ * Xilinx chain that is attached to it. If I am a Virtex II Pro, then
>>>+ * presumably that includes me. Thus, The ResetCfg will ultimately
>>>+ * reset me, the processor, end of story.
>>>+ */
>>> static void
>>> xsysace_restart(char *cmd)
>>> {
>>>@@ -285,6 +294,7 @@ xsysace_restart(char *cmd)
>>> 	/* Wait for reset. */
>>> 	for (;;) ;
>>> }
>>>+#endif
>>>
>>> /*
>>>  * The code to handle the block device starts here.
>>>@@ -725,8 +735,10 @@ cleanup(void)
>>> 	iounmap((void *) cfg->BaseAddress);
>>> 	cfg->BaseAddress = save_BaseAddress;
>>>
>>>+#ifdef CONFIG_VIRTEX_II_PRO
>>> 	if (old_restart)
>>> 		ppc_md.restart = old_restart;
>>>+#endif
>>> }
>>>
>>> static int __init
>>>@@ -837,9 +849,11 @@ xsysace_init(void)
>>> 	       DEVICE_NAME, save_BaseAddress, cfg->BaseAddress, XSA_IRQ,
>>> 	       size / 2);
>>>
>>>+#ifdef CONFIG_VIRTEX_II_PRO
>>> 	/* Hook our reset function into system's restart code. */
>>> 	old_restart = ppc_md.restart;
>>> 	ppc_md.restart = xsysace_restart;
>>>+#endif
>>>
>>> 	if (proc_init())
>>> 		printk(KERN_WARNING "%s: could not register /proc
>>
>>interface.\n",
>>
>>
>>
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/