[microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

John Linn John.Linn at xilinx.com
Tue Apr 21 00:36:05 EST 2009


> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Sunday, April 19, 2009 11:52 PM
> To: John Williams; microblaze-uclinux at itee.uq.edu.au
> Cc: grant.likely at secretlab.ca; linuxppc-dev; linux-kernel at vger.kernel.org; John Linn
> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
> 
> 
> My thinking is that these drivers are likely to be used as a group,
> hence it would be nice to make it easy to get them all visible/enabled somehow.
> 
> Steve


It seems like John's suggestion of no arch filters would satisfy that also. Since FPGAs are used in so many different applications this would seem to open the drivers up to everyone regardless of what processor they're using. It's certainly less complex so I like it in that way.

But maybe I'm missing something here and there's a downside?

-- John

> 
> -----Original Message-----
> From: John Williams [mailto:john.williams at petalogix.com]
> Sent: Sun 4/19/2009 4:03 PM
> To: microblaze-uclinux at itee.uq.edu.au
> Cc: grant.likely at secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-kernel at vger.kernel.org; John
> Linn
> Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
> 
> On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
> <stephen.neuendorffer at gmail.com> wrote:
> >
> >
> > On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely at secretlab.ca>
> > wrote:
> >>
> >> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> >> <stephen.neuendorffer at xilinx.com> wrote:
> >> >
> >> > Can we have XILINX_DRIVERS, please?  That way this can also be enabled
> >> > on any architecture that has FPGA peripherals.
> >>
> >> I've thought about this more, and I'd really rather not.  The list of
> >> affected drivers is short and is not a large maintenance burden.  I
> >> don't think a list of 2 or 3 architecture selects for each driver is
> >> unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
> >> anyway.  At any given time one of these drivers may be needed on
> >> another platform.  ie. the SystemACE device is present on at least one
> >> non-virtex, non-spartan platform.
> >
> > Which is exactly why having it architecture dependent isn't right...  All of
> > these drivers
> > could be needed and used on any OF-based platform.  If you have a platform
> > (for instance, a processor connected to an FPGA which has these peripherals
> > in the FPGA) then you should be able to enable these drivers.  Just my 2
> > cents...
> 
> What about the radical approach of having NO architecture
> filters/selectors?  Even if some random i386 user selects one of these
> drivers, so what?  It will still compile cleanly (if it doesn't we
> have to fix it), but there'll be no platform_device_register() call in
> their machine startup to actually cause driver / device binding.
> 
> No harm, no foul.  Problem goes away.
> 
> Then, as Grant points out, the rare cases where non-Xilinx platforms
> do use this stuff, they'll presumably know what they're doing and it's
> their responsibility to register the appropriate platform_device
> structures and make the magic happen.
> 
> John
> --
> John Williams, PhD, B.Eng, B.IT
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
> 


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.





More information about the Linuxppc-dev mailing list