Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1257876 > unrolled thread

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

Started byJosh Cartwright <joshc@ni.com>
First post2015-10-28 11:10 +0100
Last post2015-10-29 05:10 +0100
Articles 8 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Josh Cartwright <joshc@ni.com> - 2015-10-28 11:10 +0100
    Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Moritz Fischer <moritz.fischer@ettus.com> - 2015-10-28 16:40 +0100
      Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Josh Cartwright <joshc@ni.com> - 2015-10-28 17:20 +0100
        Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Moritz Fischer <moritz.fischer@ettus.com> - 2015-10-28 17:30 +0100
          Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Josh Cartwright <joshc@ni.com> - 2015-10-28 19:00 +0100
            Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Josh Cartwright <joshc@ni.com> - 2015-10-28 19:10 +0100
            Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Moritz Fischer <moritz.fischer@ettus.com> - 2015-10-28 21:40 +0100
        Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Rob Herring <robh+dt@kernel.org> - 2015-10-29 05:10 +0100

#1257876 — Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

FromJosh Cartwright <joshc@ni.com>
Date2015-10-28 11:10 +0100
SubjectRe: [PATCH v12 3/6] fpga: add simple-fpga-bus
Message-ID<qovQ6-1eB-5@gated-at.bofh.it>
On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
> From: Alan Tull <atull@opensource.altera.com>
> 
> The Simple FPGA bus uses the FPGA Manager Framework and the
> FPGA Bridge Framework to provide a manufactorer-agnostic
> interface for reprogramming FPGAs that is Device Tree
> Overlays-based.

Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
all, from what I can tell.

Therefore, I would have expected the FPGA Bridge drivers to sit under
the fpga-socfpga driver, and not be a first class feature of the
kernels' FPGA manager subsystem.

  Josh
--
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/

[toc] | [next] | [standalone]


#1258265

FromMoritz Fischer <moritz.fischer@ettus.com>
Date2015-10-28 16:40 +0100
Message-ID<qoAZt-4r5-63@gated-at.bofh.it>
In reply to#1257876
On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright <joshc@ni.com> wrote:
> On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
>> From: Alan Tull <atull@opensource.altera.com>
>>
>> The Simple FPGA bus uses the FPGA Manager Framework and the
>> FPGA Bridge Framework to provide a manufactorer-agnostic
>> interface for reprogramming FPGAs that is Device Tree
>> Overlays-based.
>
> Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> all, from what I can tell.

For Zynq the zynq-fpga driver takes care of the level shifters on full
reconfiguration,
and doesn't for partial reconfiguration. Now depending on which parts
of the fabric
are partial reconfigured (say AXI masters), one might run into issues
with a setup like that.

My first plan was to counter that by using zynq-reset to hold the
reset high during
reconfiguration of that part of the FPGA.

I'm happy to rethink that part and maybe redo the level shifters and
resets together in a bridge
driver under devicetree control gives finer grained control.

Cheers,

Moritz
--
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/

[toc] | [prev] | [next] | [standalone]


#1258282

FromJosh Cartwright <joshc@ni.com>
Date2015-10-28 17:20 +0100
Message-ID<qoBC9-4V4-7@gated-at.bofh.it>
In reply to#1258265
On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright <joshc@ni.com> wrote:
> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
> >> From: Alan Tull <atull@opensource.altera.com>
> >>
> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> >> interface for reprogramming FPGAs that is Device Tree
> >> Overlays-based.
> >
> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> > all, from what I can tell.
> 
> For Zynq the zynq-fpga driver takes care of the level shifters on full
> reconfiguration,
> and doesn't for partial reconfiguration. Now depending on which parts
> of the fabric
> are partial reconfigured (say AXI masters), one might run into issues
> with a setup like that.
> 
> My first plan was to counter that by using zynq-reset to hold the
> reset high during
> reconfiguration of that part of the FPGA.
> 
> I'm happy to rethink that part and maybe redo the level shifters and
> resets together in a bridge
> driver under devicetree control gives finer grained control.

There is already a framework which is used to describe and manipulate
level shifting/other IO properties, and that is pinctrl, and if we
wanted to use an appropriate abstraction, I think pinctrl would be the
best bet.

Implementing the FPGA Bridge interface in the Zynq driver because it's
what the core expects is just backwards.  It's an abstraction inversion.

  Josh
--
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/

[toc] | [prev] | [next] | [standalone]


#1258288

FromMoritz Fischer <moritz.fischer@ettus.com>
Date2015-10-28 17:30 +0100
Message-ID<qoBLQ-4Ye-21@gated-at.bofh.it>
In reply to#1258282
On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright <joshc@ni.com> wrote:
> On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
>> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright <joshc@ni.com> wrote:
>> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
>> >> From: Alan Tull <atull@opensource.altera.com>
>> >>
>> >> The Simple FPGA bus uses the FPGA Manager Framework and the
>> >> FPGA Bridge Framework to provide a manufactorer-agnostic
>> >> interface for reprogramming FPGAs that is Device Tree
>> >> Overlays-based.
>> >
>> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
>> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
>> > all, from what I can tell.
>>
>> For Zynq the zynq-fpga driver takes care of the level shifters on full
>> reconfiguration,
>> and doesn't for partial reconfiguration. Now depending on which parts
>> of the fabric
>> are partial reconfigured (say AXI masters), one might run into issues
>> with a setup like that.
>>
>> My first plan was to counter that by using zynq-reset to hold the
>> reset high during
>> reconfiguration of that part of the FPGA.
>>
>> I'm happy to rethink that part and maybe redo the level shifters and
>> resets together in a bridge
>> driver under devicetree control gives finer grained control.
>
> There is already a framework which is used to describe and manipulate
> level shifting/other IO properties, and that is pinctrl, and if we
> wanted to use an appropriate abstraction, I think pinctrl would be the
> best bet.

Alright, I'll investigate that. Again, for the non-partial reconfig
case I'm happy
with the behavior as implemented, for the partial reconfig I just
haven't run into
issues with not dealing with the level shifters.

> Implementing the FPGA Bridge interface in the Zynq driver because it's
> what the core expects is just backwards.  It's an abstraction inversion.

Yeah, you're probably right.

Thanks,

Moritz
--
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/

[toc] | [prev] | [next] | [standalone]


#1258338

FromJosh Cartwright <joshc@ni.com>
Date2015-10-28 19:00 +0100
Message-ID<qoDaW-5OU-9@gated-at.bofh.it>
In reply to#1258288
On Wed, Oct 28, 2015 at 12:03:41PM -0500, atull wrote:
> On Wed, 28 Oct 2015, Moritz Fischer wrote:
> 
> > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright <joshc@ni.com> wrote:
> > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright <joshc@ni.com> wrote:
> > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
> > >> >> From: Alan Tull <atull@opensource.altera.com>
> > >> >>
> > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> > >> >> interface for reprogramming FPGAs that is Device Tree
> > >> >> Overlays-based.
> > >> >
> > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> > >> > all, from what I can tell.
> > >>
> > >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> > >> reconfiguration,
> > >> and doesn't for partial reconfiguration. Now depending on which parts
> > >> of the fabric
> > >> are partial reconfigured (say AXI masters), one might run into issues
> > >> with a setup like that.
> > >>
> > >> My first plan was to counter that by using zynq-reset to hold the
> > >> reset high during
> > >> reconfiguration of that part of the FPGA.
> > >>
> > >> I'm happy to rethink that part and maybe redo the level shifters and
> > >> resets together in a bridge
> > >> driver under devicetree control gives finer grained control.
> > >
> > > There is already a framework which is used to describe and manipulate
> > > level shifting/other IO properties, and that is pinctrl, and if we
> > > wanted to use an appropriate abstraction, I think pinctrl would be the
> > > best bet.
> > 
> > Alright, I'll investigate that. Again, for the non-partial reconfig
> > case I'm happy
> > with the behavior as implemented, for the partial reconfig I just
> > haven't run into
> > issues with not dealing with the level shifters.
> 
> Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?

I'm suggesting that for the set of operations/configuration states that
need to be managed _for the Zynq[1]_ during reprogramming, I think
pinctrl might be a good fit.

But the pinctrl state activation would happen in the context of the zynq
fpga_mgr_ops write

I do not think it's a good fit for the socfpga, or for the lower level
fpga drivers _in general_.  Nor do I think that the FPGA Bridge
framework, as written, is a good fit for fpgas in general.

  Josh

[1]: Speaking only of the Zynq 7000-series, I don't know anything about
     the fancy new Zynq MPSoC :)
--
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/

[toc] | [prev] | [next] | [standalone]


#1258344

FromJosh Cartwright <joshc@ni.com>
Date2015-10-28 19:10 +0100
Message-ID<qoDkB-67B-13@gated-at.bofh.it>
In reply to#1258338
On Wed, Oct 28, 2015 at 12:59:16PM -0500, Josh Cartwright wrote:
> On Wed, Oct 28, 2015 at 12:03:41PM -0500, atull wrote:
> > On Wed, 28 Oct 2015, Moritz Fischer wrote:
> > 
> > > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright <joshc@ni.com> wrote:
> > > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> > > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright <joshc@ni.com> wrote:
> > > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
> > > >> >> From: Alan Tull <atull@opensource.altera.com>
> > > >> >>
> > > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> > > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> > > >> >> interface for reprogramming FPGAs that is Device Tree
> > > >> >> Overlays-based.
> > > >> >
> > > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> > > >> > all, from what I can tell.
> > > >>
> > > >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> > > >> reconfiguration,
> > > >> and doesn't for partial reconfiguration. Now depending on which parts
> > > >> of the fabric
> > > >> are partial reconfigured (say AXI masters), one might run into issues
> > > >> with a setup like that.
> > > >>
> > > >> My first plan was to counter that by using zynq-reset to hold the
> > > >> reset high during
> > > >> reconfiguration of that part of the FPGA.
> > > >>
> > > >> I'm happy to rethink that part and maybe redo the level shifters and
> > > >> resets together in a bridge
> > > >> driver under devicetree control gives finer grained control.
> > > >
> > > > There is already a framework which is used to describe and manipulate
> > > > level shifting/other IO properties, and that is pinctrl, and if we
> > > > wanted to use an appropriate abstraction, I think pinctrl would be the
> > > > best bet.
> > > 
> > > Alright, I'll investigate that. Again, for the non-partial reconfig
> > > case I'm happy
> > > with the behavior as implemented, for the partial reconfig I just
> > > haven't run into
> > > issues with not dealing with the level shifters.
> > 
> > Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?
> 
> I'm suggesting that for the set of operations/configuration states that
> need to be managed _for the Zynq[1]_ during reprogramming, I think
> pinctrl might be a good fit.
> 
> But the pinctrl state activation would happen in the context of the zynq
> fpga_mgr_ops write

*grr*... in the context of the zynq's write_init(), and write_complete()
callbacks.

  Josh
--
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/

[toc] | [prev] | [next] | [standalone]


#1258402

FromMoritz Fischer <moritz.fischer@ettus.com>
Date2015-10-28 21:40 +0100
Message-ID<qoFFM-7u4-1@gated-at.bofh.it>
In reply to#1258338
[..]
> I do not think it's a good fit for the socfpga, or for the lower level
> fpga drivers _in general_.  Nor do I think that the FPGA Bridge
> framework, as written, is a good fit for fpgas in general.

Could you elaborate a bit more on why you feel that way? For all
configurations that I could
create in my mind (even hierarchical) I could come up with a way to
model that using the
proposed architecture in a very natural way. I'm of course aware that
my imagination is limited ;-)

Cheers,

Moritz
--
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/

[toc] | [prev] | [next] | [standalone]


#1258555

FromRob Herring <robh+dt@kernel.org>
Date2015-10-29 05:10 +0100
Message-ID<qoMHg-3Jy-9@gated-at.bofh.it>
In reply to#1258282
On Wed, Oct 28, 2015 at 11:18 AM, Josh Cartwright <joshc@ni.com> wrote:
> On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
>> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright <joshc@ni.com> wrote:
>> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:
>> >> From: Alan Tull <atull@opensource.altera.com>
>> >>
>> >> The Simple FPGA bus uses the FPGA Manager Framework and the
>> >> FPGA Bridge Framework to provide a manufactorer-agnostic
>> >> interface for reprogramming FPGAs that is Device Tree
>> >> Overlays-based.
>> >
>> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
>> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
>> > all, from what I can tell.
>>
>> For Zynq the zynq-fpga driver takes care of the level shifters on full
>> reconfiguration,
>> and doesn't for partial reconfiguration. Now depending on which parts
>> of the fabric
>> are partial reconfigured (say AXI masters), one might run into issues
>> with a setup like that.
>>
>> My first plan was to counter that by using zynq-reset to hold the
>> reset high during
>> reconfiguration of that part of the FPGA.
>>
>> I'm happy to rethink that part and maybe redo the level shifters and
>> resets together in a bridge
>> driver under devicetree control gives finer grained control.
>
> There is already a framework which is used to describe and manipulate
> level shifting/other IO properties, and that is pinctrl, and if we
> wanted to use an appropriate abstraction, I think pinctrl would be the
> best bet.

I'm not all that familiar with FPGAs, but using pinctrl seems like
overkill to me. We're talking about isolating things while doing
reconfiguration, right? That seems more similar to power domain
controls than I/O pin control to me.

> Implementing the FPGA Bridge interface in the Zynq driver because it's
> what the core expects is just backwards.  It's an abstraction inversion.

+1

Rob
--
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/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web