Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem

[Sergey Temerkhanov <temerkhanov@yandex.ru>]

On Monday 29 March 2010 19:56:15 Grant Likely wrote:
> On Mon, Mar 29, 2010 at 9:42 AM, Steven J. Magnani
> 
> <steve@digidescorp.com> wrote:
> > On Fri, 2010-03-26 at 17:53 -0600, Grant Likely wrote:
> >> I've not got time to review this patch right now, but Sergey and
> >> Steven, you both posted MPMC drivers on the same day; Steven on the
> >> microblaze list and Sergey on the powerpc list.  Can you two please
> >> coordinate and figure out how to mork toward a single driver that will
> >> meet both your needs?  I don't want to have 2 drivers (3 if you count
> >> the ll_temac driver) in mainline for the same hardware interface.
> >
> > I don't think we'll end up with a single driver. A MPMC DMA Engine
> > driver is useful only on "loopback" SDMA ports. Sergey's code looks like
> > a nice generic interface to Xilinx SDMA HW that could be used by the
> > xlldma and ll_temac drivers, for instance. Both of those will get
> > smaller, but won't go away.

Yes, it's like having IBM EMAC driver and MAL layer or something 

> >
> > For this to be useful to me, it would need to be located somewhere more
> > accessible than arch/powerpc and it would need to have initialization
> > methods that don't depend on OF. In my build I would have platform code
> > that binds to the xlldma platform attachment, which would call Sergey's
> > SDMA code to assign it the proper resources.
> 
> That should be fine.

Well, I'll look at my old code for the platform interface bindings. I remember 
it worked well on arch/ppc with my other drivers.

> 
> > Any objections to having Sergey's code live in drivers/dma, and putting
> > sdma.h out in include/linux? Might need to tweak the file/function names
> > some to head off namespace issues. Or is there some other strategy for
> > managing Xilinx-related drivers common to both Microblaze and PowerPC?
> 
> I have no objections.  This sounds like a good plan.

Or we can put Xilinx-related headers to, i.e., include/linux/xilinx. There 
might be some other candidates for this. 
> 
> g.
> 

Regards, Sergey Temerkhanov, Cifronic ZAO