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

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

[Grant Likely]

On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> Can we have XILINX_DRIVERS, please? =A0That 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.

g.

>
> Steve
>
>> -----Original Message-----
>> From: owner-microblaze-uclinux@itee.uq.edu.au
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
>> Behalf Of monstr@monstr.eu
>> Sent: Thursday, April 16, 2009 2:57 AM
>> To: linux-kernel@vger.kernel.org
>> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
>> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> Enable drivers for Microblaze
>>
>> From: Michal Simek <monstr@monstr.eu>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>> =A0drivers/block/Kconfig | =A0 =A02 +-
>> =A0drivers/char/Kconfig =A0| =A0 =A02 +-
>> =A0drivers/gpio/Kconfig =A0| =A0 =A02 +-
>> =A0drivers/usb/Kconfig =A0 | =A0 =A01 +
>> =A04 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>> index ddea8e4..9f1665f 100644
>> --- a/drivers/block/Kconfig
>> +++ b/drivers/block/Kconfig
>> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
>>
>> =A0config XILINX_SYSACE
>> =A0 =A0 =A0 tristate "Xilinx SystemACE support"
>> - =A0 =A0 depends on 4xx
>> + =A0 =A0 depends on 4xx || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 Include support for the Xilinx SystemACE CompactFlash
> interface
>>
>> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
>> index 735bbe2..bb1a071 100644
>> --- a/drivers/char/Kconfig
>> +++ b/drivers/char/Kconfig
>> @@ -893,7 +893,7 @@ config DTLK
>>
>> =A0config XILINX_HWICAP
>> =A0 =A0 =A0 tristate "Xilinx HWICAP Support"
>> - =A0 =A0 depends on XILINX_VIRTEX
>> + =A0 =A0 depends on XILINX_VIRTEX || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 This option enables support for Xilinx Internal Configur=
ation
>> =A0 =A0 =A0 =A0 Access Port (ICAP) driver. =A0The ICAP is used on Xilinx=
 Virtex
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index edb0253..11f3739 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
>>
>> =A0config GPIO_XILINX
>> =A0 =A0 =A0 bool "Xilinx GPIO support"
>> - =A0 =A0 depends on PPC_OF
>> + =A0 =A0 depends on PPC_OF || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 Say yes here to support the Xilinx FPGA GPIO device
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index c6c816b..5eee3f8 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
>> =A0 =A0 =A0 default y if PCMCIA && !M32R =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0# sl811_cs
>> =A0 =A0 =A0 default y if ARM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0# SL-811
>> =A0 =A0 =A0 default y if SUPERH =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 # r8a66597-hcd
>> + =A0 =A0 default y if MICROBLAZE
>> =A0 =A0 =A0 default PCI
>>
>> =A0# many non-PCI SOC chips embed OHCI
>> --
>> 1.5.5.1
>>
>> ___________________________
>> microblaze-uclinux mailing list
>> microblaze-uclinux@itee.uq.edu.au
>> Project Home Page :
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
>> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>>
>
>
> This email and any attachments are intended for the sole use of the named=
 recipient(s) and contain(s) confidential information that may be proprieta=
ry, privileged or copyrighted under applicable law. If you are not the inte=
nded recipient, do not read, copy, or forward this email message or any att=
achments. Delete this email message and any attachments immediately.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[Stephen Neuendorffer]

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

On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>wrote:

> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> <stephen.neuendorffer@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...

Steve


>
> g.
>
> >
> > Steve
> >
> >> -----Original Message-----
> >> From: owner-microblaze-uclinux@itee.uq.edu.au
> > [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
> >> Behalf Of monstr@monstr.eu
> >> Sent: Thursday, April 16, 2009 2:57 AM
> >> To: linux-kernel@vger.kernel.org
> >> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
> >> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> > Enable drivers for Microblaze
> >>
> >> From: Michal Simek <monstr@monstr.eu>
> >>
> >> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >> ---
> >>  drivers/block/Kconfig |    2 +-
> >>  drivers/char/Kconfig  |    2 +-
> >>  drivers/gpio/Kconfig  |    2 +-
> >>  drivers/usb/Kconfig   |    1 +
> >>  4 files changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> >> index ddea8e4..9f1665f 100644
> >> --- a/drivers/block/Kconfig
> >> +++ b/drivers/block/Kconfig
> >> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
> >>
> >>  config XILINX_SYSACE
> >>       tristate "Xilinx SystemACE support"
> >> -     depends on 4xx
> >> +     depends on 4xx || MICROBLAZE
> >>       help
> >>         Include support for the Xilinx SystemACE CompactFlash
> > interface
> >>
> >> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> >> index 735bbe2..bb1a071 100644
> >> --- a/drivers/char/Kconfig
> >> +++ b/drivers/char/Kconfig
> >> @@ -893,7 +893,7 @@ config DTLK
> >>
> >>  config XILINX_HWICAP
> >>       tristate "Xilinx HWICAP Support"
> >> -     depends on XILINX_VIRTEX
> >> +     depends on XILINX_VIRTEX || MICROBLAZE
> >>       help
> >>         This option enables support for Xilinx Internal Configuration
> >>         Access Port (ICAP) driver.  The ICAP is used on Xilinx Virtex
> >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >> index edb0253..11f3739 100644
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
> >>
> >>  config GPIO_XILINX
> >>       bool "Xilinx GPIO support"
> >> -     depends on PPC_OF
> >> +     depends on PPC_OF || MICROBLAZE
> >>       help
> >>         Say yes here to support the Xilinx FPGA GPIO device
> >>
> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> >> index c6c816b..5eee3f8 100644
> >> --- a/drivers/usb/Kconfig
> >> +++ b/drivers/usb/Kconfig
> >> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
> >>       default y if PCMCIA && !M32R                    # sl811_cs
> >>       default y if ARM                                # SL-811
> >>       default y if SUPERH                             # r8a66597-hcd
> >> +     default y if MICROBLAZE
> >>       default PCI
> >>
> >>  # many non-PCI SOC chips embed OHCI
> >> --
> >> 1.5.5.1
> >>
> >> ___________________________
> >> microblaze-uclinux mailing list
> >> microblaze-uclinux@itee.uq.edu.au
> >> Project Home Page :
> > http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux<http://www.itee.uq.edu.au/%7Ejwilliams/mblaze-uclinux>
> >> Mailing List Archive :
> > http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/<http://www.itee.uq.edu.au/%7Elistarch/microblaze-uclinux/>
> >>
> >
> >
> > 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.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

[-- Attachment #2: Type: text/html, Size: 7341 bytes --]

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

[John Williams]

On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca=
>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > Can we have XILINX_DRIVERS, please? =A0That way this can also be enabl=
ed
>> > on any architecture that has FPGA peripherals.
>>
>> I've thought about this more, and I'd really rather not. =A0The list of
>> affected drivers is short and is not a large maintenance burden. =A0I
>> don't think a list of 2 or 3 architecture selects for each driver is
>> unreasonable. =A0A "XILINX_DRIVERS" config item doesn't really help much
>> anyway. =A0At any given time one of these drivers may be needed on
>> another platform. =A0ie. 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...=A0 A=
ll of
> these drivers
> could be needed and used on any OF-based platform.=A0 If you have a platf=
orm
> (for instance, a processor connected to an FPGA which has these periphera=
ls
> in the FPGA) then you should be able to enable these drivers.=A0 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
--=20
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

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

[Stephen Neuendorffer]

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


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

-----Original Message-----
From: John Williams [mailto:john.williams@petalogix.com]
Sent: Sun 4/19/2009 4:03 PM
To: microblaze-uclinux@itee.uq.edu.au
Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-kernel@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@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@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.


[-- Attachment #2: Type: text/html, Size: 3872 bytes --]

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

[John Linn]

> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Sunday, April 19, 2009 11:52 PM
> To: John Williams; microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.org=
; John Linn
> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enab=
le 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 so=
mehow.
> 
> 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@petalogix.com]
> Sent: Sun 4/19/2009 4:03 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-=
kernel@vger.kernel.org; John
> Linn
> Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enab=
le drivers for Microblaze
> =

> On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
> <stephen.neuendorffer@gmail.com> wrote:
> >
> >
> > On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.=
ca>
> > wrote:
> >>
> >> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> >> <stephen.neuendorffer@xilinx.com> wrote:
> >> >
> >> > Can we have XILINX_DRIVERS, please? =A0That way this can also be ena=
bled
> >> > on any architecture that has FPGA peripherals.
> >>
> >> I've thought about this more, and I'd really rather not. =A0The list o=
f
> >> affected drivers is short and is not a large maintenance burden. =A0I
> >> don't think a list of 2 or 3 architecture selects for each driver is
> >> unreasonable. =A0A "XILINX_DRIVERS" config item doesn't really help mu=
ch
> >> anyway. =A0At any given time one of these drivers may be needed on
> >> another platform. =A0ie. the SystemACE device is present on at least o=
ne
> >> non-virtex, non-spartan platform.
> >
> > Which is exactly why having it architecture dependent isn't right...=A0=
 All of
> > these drivers
> > could be needed and used on any OF-based platform.=A0 If you have a pla=
tform
> > (for instance, a processor connected to an FPGA which has these periphe=
rals
> > in the FPGA) then you should be able to enable these drivers.=A0 Just m=
y 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 r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

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

[Grant Likely]

On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>> -----Original Message-----
>> From: Stephen Neuendorffer
>> Sent: Sunday, April 19, 2009 11:52 PM
>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.or=
g; John Linn
>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Ena=
ble 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 s=
omehow.
>>
>> Steve
>
>
> It seems like John's suggestion of no arch filters would satisfy that als=
o. Since FPGAs are used in so many different applications this would seem t=
o open the drivers up to everyone regardless of what processor they're usin=
g. It's certainly less complex so I like it in that way.
>
> But maybe I'm missing something here and there's a downside?

No, I don't think there is.

I think CONFIG_OF is the right thing to do.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[John Williams]

On Tue, Apr 21, 2009 at 12:48 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>>> -----Original Message-----
>>> From: Stephen Neuendorffer
>>> Sent: Sunday, April 19, 2009 11:52 PM
>>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.o=
rg; John Linn
>>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: En=
able 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 al=
so. 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 usi=
ng. It's certainly less complex so I like it in that way.
>>
>> But maybe I'm missing something here and there's a downside?
>
> No, I don't think there is.
>
> I think CONFIG_OF is the right thing to do.

Some (most?) of the Xilinx drivers currently have this construct:

#ifdef CONFIG_OF

// probe using OF

#else

// probe using platform_device

#endif

so unless this is going to change some time soon, maybe even CONFIG_OF
is too restrictive?

John
--=20
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

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

[Arnd Bergmann]

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

On Tuesday 21 April 2009, John Williams wrote:
> Some (most?) of the Xilinx drivers currently have this construct:
> 
> #ifdef CONFIG_OF
> 
> // probe using OF
> 
> #else

If there are multiple ways of detecting the device, then
the driver should be compilable on any system that allows
either one.

At the very least, it should be restricted to CONFIG_HAS_IOMEM,
which is probably required for any of these, but not provided
on stuff like UML or s390.

Drivers that use of_* functions unconditionally need to
depend on CONFIG_OF.

Also, some of the xilinx drivers apparantly use DCR, which in turn is
only defined when you have CONFIG_PPC_DCR, and these
have so far only been used on powerpc. If other architectures
start using DCR (I hope that never happens), we will need a
global CONFIG_DCR option.

	Arnd <><

[-- Attachment #2: Type: text/html, Size: 5105 bytes --]

who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[derekzheng]

Hi all guys:

The Freescale MPC8536DS board Integrated TestFloat cases, and I do not =
know how to test this feature on this board.
Please tell me how to test it if you known

Thanks very much!

Derek

Re: who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[Kumar Gala]

On Apr 19, 2009, at 4:25 AM, derekzheng wrote:

> Hi all guys:
>
> The Freescale MPC8536DS board Integrated TestFloat cases, and I do  
> not know how to test this feature on this board.
> Please tell me how to test it if you known

1. why are you CC' the microblaze list on this question?
2. I assume you are talking about the FSL BSP for MPC8536DS
3. testfloat is a set of tests.  Its not clear what your question is.   
You build testfloat and run it and it reports pass/fails.

- k

Re:Re: who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[zhengxiang9]

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

thanks for you help.
i am sorry,i make a mistake , i can not update my mail list

derek  zheng 








在2009-04-20，"Kumar Gala" <galak@kernel.crashing.org> 写道：
>
>On Apr 19, 2009, at 4:25 AM, derekzheng wrote:
>
>> Hi all guys:
>>
>> The Freescale MPC8536DS board Integrated TestFloat cases, and I do  
>> not know how to test this feature on this board.
>> Please tell me how to test it if you known
>
>1. why are you CC' the microblaze list on this question?
>2. I assume you are talking about the FSL BSP for MPC8536DS
>3. testfloat is a set of tests.  Its not clear what your question is.   
>You build testfloat and run it and it reports pass/fails.
>
>- k

[-- Attachment #2: Type: text/html, Size: 949 bytes --]

RE: who know's what is "TestFloat cases" and how to test this feature onthe Freescale MPC8536DS board

[Liu Yu-B13201]

> -----Original Message-----
> From: linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of derekzheng
> Sent: Sunday, April 19, 2009 5:25 PM
> To: 'linuxppc-dev'; microblaze-uclinux@itee.uq.edu.au;=20
> linux-kernel@vger.kernel.org
> Subject: who know's what is "TestFloat cases" and how to test=20
> this feature onthe Freescale MPC8536DS board
>=20
> Hi all guys:
>=20
> The Freescale MPC8536DS board Integrated TestFloat cases, and=20
> I do not know how to test this feature on this board.
> Please tell me how to test it if you known
>=20

You can find the user manual "E500v2 SPE Floating Point" in BSP iso.