[PATCH] [RFC] Xilinx MPMC SDMA subsystem
Sergey Temerkhanov
temerkhanov at yandex.ru
Tue Mar 30 06:04:39 EST 2010
On Monday 29 March 2010 19:56:15 Grant Likely wrote:
> On Mon, Mar 29, 2010 at 9:42 AM, Steven J. Magnani
>
> <steve at 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
More information about the Linuxppc-dev
mailing list