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 at mvista.com]
> Sent: Friday, April 02, 2004 8:36 PM
> To: Stephen Williams
> Cc: linuxppc-embedded at lists.linuxppc.org; Andrei Konovalov
> Subject: Re: SystemACE but not V2PRO
>
>
> Hi there,
> The current ML300 maintainer is Andrei Konovalov
> <akonovalov at 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/