Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Mon, 25 Jan 2016, Rob Herring wrote:

> On Fri, Jan 22, 2016 at 6:07 PM, Moritz Fischer
>  wrote:
> > On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
> >> On Fri, 22 Jan 2016, Moritz Fischer wrote:
> >>
> >>> Alan,
> >>>
> >>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> >>>
> >>> > +static int fpga_area_probe(struct platform_device *pdev)
> >>> > +{
> >>> > +   struct device *dev = >dev;
> >>> > +   struct device_node *np = dev->of_node;
> >>> > +   struct fpga_area *area;
> >>> > +   int ret;
> >>> > +
> >>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> >>> > +   if (!area)
> >>> > +   return -ENOMEM;
> >>> > +
> >>> > +   INIT_LIST_HEAD(>bridge_list);
> >>> > +
> >>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> >>> > +   if (ret)
> >>> > +   return ret;
> >>> > +   area->br = dev_get_drvdata(dev);
> >>> > +
> >>> > +   if (of_property_read_string(np, "firmware-name",
> >>> > +   >firmware_name)) {
> >>> > +   of_platform_populate(np, of_default_bus_match_table, 
> >>> > NULL, dev);
> >>> > +   return 0;
> >>> > +   }
> >>>
> >>> This is the use case where the bootloader loaded the fpga, and you
> >>> just want to populate
> >>> the devices in the fabric, right?
> >>
> >> Hi Moritz,
> >>
> >> Yes
> 
> That is very strange logic. It should be fine to just call
> of_platform_populate unconditionally. If there are no children of np,
> then it will be a nop.

That's what it is doing.  It's coded this way to reduce indentation.  If there
is no FPGA image to load, call of_platform_populate() and return.  Otherwise do
a bunch of steps to load the FPGA image and handle the bridges, then call
of_platform_populate() and return.  If there's no children, no problem.

> 
> >>> > +   if (of_property_read_bool(np, "partial-reconfig"))
> >>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> >>> > +
> >>> > +   ret = fpga_area_get_bus(area);
> >>> > +   if (ret) {
> >>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> >>> > +   goto err_unreg;
> >>> > +   }
> >>>
> >>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> >>> need to become a subnode of fpgabus@0 at the same place?
> >>>
> >>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> >>>
> >>> and the ranges property would be used to translate to the fpga memory
> >>> mapped space?
> >>>
> >>> I know we're going back and forth on this. I think Rob brought up a
> >>> similar question:
> >>> "Does the bus really go thru the fpgamgr and then the bridge as this
> >>> implies? Or fpgamgr is a sideband controller?"
> >>>
> >>> To which I think the answer is 'sideband' controller, yet with the new
> >>> bindings it looks like
> >>> the bus goes through the fpgamgr.
> >>
> >> Yeah, let's get this right.  First, let's be clear on the reason for FPGA 
> >> Bus to
> >> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring 
> >> together
> >> the bridges and manager that are associated with a certain FPGA.  This 
> >> allows
> >> the system designer to specify which FPGA is getting programmed with which
> >> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
> >> with
> >> a FPGA Manager.
> >
> > I see your argument for the FPGA bus. I agree that we need to
> > distinguish different FPGAs,
> > and we need a way to associate an area with a manager (and potentially 
> > bridges).
> >
> >> As far as the target path is concerned, in the case of no bridges, we 
> >> could have
> >> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be 
> >> more
> >> logical.  This would just be a documentation change; I think fpga-area.c 
> >> will
> >> work OK if you specify the FPGA bus as your target (the manager still has 
> >> to
> >> be a child of the bus so the bus knows what manager to use).
> >
> > Could the bus not just use a phandle to the manager? Or the area a
> > phandle to the bus?
> 
> That may be better as it would avoid the virtual fpga-bus which is a
> bit questionable. I'm okay with allowing it, but will happily take any
> examples where it doesn't work. However, I'm not sure this case is
> one.

I have no problem with specifying FPGA manager with a phandle, seems
like it will be better in some cases.

I'm proposing FPGA Bus to specify all the things (manager and bridges) that are
needed to do a reprogramming cycle on a specific FPGA. The FPGA Bus may seem
less necessary in Moritz' case where there are no FPGA Bridges in the DT.

I'll discuss this more on the other thread.

> 
> > Like that one could have potentially disjunct groups. Say I have a SPI
> > device that is in an FPGA area.
> > With our current system, I'd have a FPGA Manager that needs to be a
> > child of the bus as child of the SPI controller
> > with the memory addresses being addresses on the SOC's 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Mon, 25 Jan 2016, Rob Herring wrote:

> On Fri, Jan 22, 2016 at 6:07 PM, Moritz Fischer
>  wrote:
> > On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
> >> On Fri, 22 Jan 2016, Moritz Fischer wrote:
> >>
> >>> Alan,
> >>>
> >>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> >>>
> >>> > +static int fpga_area_probe(struct platform_device *pdev)
> >>> > +{
> >>> > +   struct device *dev = >dev;
> >>> > +   struct device_node *np = dev->of_node;
> >>> > +   struct fpga_area *area;
> >>> > +   int ret;
> >>> > +
> >>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> >>> > +   if (!area)
> >>> > +   return -ENOMEM;
> >>> > +
> >>> > +   INIT_LIST_HEAD(>bridge_list);
> >>> > +
> >>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> >>> > +   if (ret)
> >>> > +   return ret;
> >>> > +   area->br = dev_get_drvdata(dev);
> >>> > +
> >>> > +   if (of_property_read_string(np, "firmware-name",
> >>> > +   >firmware_name)) {
> >>> > +   of_platform_populate(np, of_default_bus_match_table, 
> >>> > NULL, dev);
> >>> > +   return 0;
> >>> > +   }
> >>>
> >>> This is the use case where the bootloader loaded the fpga, and you
> >>> just want to populate
> >>> the devices in the fabric, right?
> >>
> >> Hi Moritz,
> >>
> >> Yes
> 
> That is very strange logic. It should be fine to just call
> of_platform_populate unconditionally. If there are no children of np,
> then it will be a nop.

That's what it is doing.  It's coded this way to reduce indentation.  If there
is no FPGA image to load, call of_platform_populate() and return.  Otherwise do
a bunch of steps to load the FPGA image and handle the bridges, then call
of_platform_populate() and return.  If there's no children, no problem.

> 
> >>> > +   if (of_property_read_bool(np, "partial-reconfig"))
> >>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> >>> > +
> >>> > +   ret = fpga_area_get_bus(area);
> >>> > +   if (ret) {
> >>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> >>> > +   goto err_unreg;
> >>> > +   }
> >>>
> >>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> >>> need to become a subnode of fpgabus@0 at the same place?
> >>>
> >>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> >>>
> >>> and the ranges property would be used to translate to the fpga memory
> >>> mapped space?
> >>>
> >>> I know we're going back and forth on this. I think Rob brought up a
> >>> similar question:
> >>> "Does the bus really go thru the fpgamgr and then the bridge as this
> >>> implies? Or fpgamgr is a sideband controller?"
> >>>
> >>> To which I think the answer is 'sideband' controller, yet with the new
> >>> bindings it looks like
> >>> the bus goes through the fpgamgr.
> >>
> >> Yeah, let's get this right.  First, let's be clear on the reason for FPGA 
> >> Bus to
> >> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring 
> >> together
> >> the bridges and manager that are associated with a certain FPGA.  This 
> >> allows
> >> the system designer to specify which FPGA is getting programmed with which
> >> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
> >> with
> >> a FPGA Manager.
> >
> > I see your argument for the FPGA bus. I agree that we need to
> > distinguish different FPGAs,
> > and we need a way to associate an area with a manager (and potentially 
> > bridges).
> >
> >> As far as the target path is concerned, in the case of no bridges, we 
> >> could have
> >> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be 
> >> more
> >> logical.  This would just be a documentation change; I think fpga-area.c 
> >> will
> >> work OK if you specify the FPGA bus as your target (the manager still has 
> >> to
> >> be a child of the bus so the bus knows what manager to use).
> >
> > Could the bus not just use a phandle to the manager? Or the area a
> > phandle to the bus?
> 
> That may be better as it would avoid the virtual fpga-bus which is a
> bit questionable. I'm okay with allowing it, but will happily take any
> examples where it doesn't work. However, I'm not sure this case is
> one.

I have no problem with specifying FPGA manager with a phandle, seems
like it will be better in some cases.

I'm proposing FPGA Bus to specify all the things (manager and bridges) that are
needed to do a reprogramming cycle on a specific FPGA. The FPGA Bus may seem
less necessary in Moritz' case where there are no FPGA Bridges in the DT.

I'll discuss this more on the other thread.

> 
> > Like that one could have potentially disjunct groups. Say I have a SPI
> > device that is in an FPGA area.
> > With our current system, I'd have a FPGA Manager that needs to be a
> > child of the bus as 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Rob Herring]

On Fri, Jan 22, 2016 at 6:07 PM, Moritz Fischer
 wrote:
> On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
>> On Fri, 22 Jan 2016, Moritz Fischer wrote:
>>
>>> Alan,
>>>
>>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
>>>
>>> > +static int fpga_area_probe(struct platform_device *pdev)
>>> > +{
>>> > +   struct device *dev = >dev;
>>> > +   struct device_node *np = dev->of_node;
>>> > +   struct fpga_area *area;
>>> > +   int ret;
>>> > +
>>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
>>> > +   if (!area)
>>> > +   return -ENOMEM;
>>> > +
>>> > +   INIT_LIST_HEAD(>bridge_list);
>>> > +
>>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
>>> > +   if (ret)
>>> > +   return ret;
>>> > +   area->br = dev_get_drvdata(dev);
>>> > +
>>> > +   if (of_property_read_string(np, "firmware-name",
>>> > +   >firmware_name)) {
>>> > +   of_platform_populate(np, of_default_bus_match_table, 
>>> > NULL, dev);
>>> > +   return 0;
>>> > +   }
>>>
>>> This is the use case where the bootloader loaded the fpga, and you
>>> just want to populate
>>> the devices in the fabric, right?
>>
>> Hi Moritz,
>>
>> Yes

That is very strange logic. It should be fine to just call
of_platform_populate unconditionally. If there are no children of np,
then it will be a nop.

>>> > +   if (of_property_read_bool(np, "partial-reconfig"))
>>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
>>> > +
>>> > +   ret = fpga_area_get_bus(area);
>>> > +   if (ret) {
>>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
>>> > +   goto err_unreg;
>>> > +   }
>>>
>>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
>>> need to become a subnode of fpgabus@0 at the same place?
>>>
>>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
>>>
>>> and the ranges property would be used to translate to the fpga memory
>>> mapped space?
>>>
>>> I know we're going back and forth on this. I think Rob brought up a
>>> similar question:
>>> "Does the bus really go thru the fpgamgr and then the bridge as this
>>> implies? Or fpgamgr is a sideband controller?"
>>>
>>> To which I think the answer is 'sideband' controller, yet with the new
>>> bindings it looks like
>>> the bus goes through the fpgamgr.
>>
>> Yeah, let's get this right.  First, let's be clear on the reason for FPGA 
>> Bus to
>> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
>> the bridges and manager that are associated with a certain FPGA.  This allows
>> the system designer to specify which FPGA is getting programmed with which
>> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
>> with
>> a FPGA Manager.
>
> I see your argument for the FPGA bus. I agree that we need to
> distinguish different FPGAs,
> and we need a way to associate an area with a manager (and potentially 
> bridges).
>
>> As far as the target path is concerned, in the case of no bridges, we could 
>> have
>> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be 
>> more
>> logical.  This would just be a documentation change; I think fpga-area.c will
>> work OK if you specify the FPGA bus as your target (the manager still has to
>> be a child of the bus so the bus knows what manager to use).
>
> Could the bus not just use a phandle to the manager? Or the area a
> phandle to the bus?

That may be better as it would avoid the virtual fpga-bus which is a
bit questionable. I'm okay with allowing it, but will happily take any
examples where it doesn't work. However, I'm not sure this case is
one.

> Like that one could have potentially disjunct groups. Say I have a SPI
> device that is in an FPGA area.
> With our current system, I'd have a FPGA Manager that needs to be a
> child of the bus as child of the SPI controller
> with the memory addresses being addresses on the SOC's memory bus:
>
> spi_ctrl@deadbeef {
> fpga_bus@0 {
> fpgamgr@f8007000 {
> mgr regs etc...
> ... and now the SPI slaves ...
> slave@42 {
> };
> };
> };
> };

I think Alan's assumption is there's always a memory mapped control
interface and the DT hierarchy follows that. While I see you could
have other interfaces like SPI, that would not be the control
interface related to FPGA programming AIUI. You could also have GPIOs,
I2C, or any other bus/interface we describe in DT in theory.

How to deal with additional connections like this is similar to
overlays for daughterboards (e.g. capes, hats, shields) where the need
for mapping slave devices on a connector to host controllers/buses
which can vary. In that case, you don't want to have to create a
different overlay for every host board just to change the parent
devices of each child. If 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Rob Herring]

On Fri, Jan 22, 2016 at 6:07 PM, Moritz Fischer
 wrote:
> On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
>> On Fri, 22 Jan 2016, Moritz Fischer wrote:
>>
>>> Alan,
>>>
>>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
>>>
>>> > +static int fpga_area_probe(struct platform_device *pdev)
>>> > +{
>>> > +   struct device *dev = >dev;
>>> > +   struct device_node *np = dev->of_node;
>>> > +   struct fpga_area *area;
>>> > +   int ret;
>>> > +
>>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
>>> > +   if (!area)
>>> > +   return -ENOMEM;
>>> > +
>>> > +   INIT_LIST_HEAD(>bridge_list);
>>> > +
>>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
>>> > +   if (ret)
>>> > +   return ret;
>>> > +   area->br = dev_get_drvdata(dev);
>>> > +
>>> > +   if (of_property_read_string(np, "firmware-name",
>>> > +   >firmware_name)) {
>>> > +   of_platform_populate(np, of_default_bus_match_table, 
>>> > NULL, dev);
>>> > +   return 0;
>>> > +   }
>>>
>>> This is the use case where the bootloader loaded the fpga, and you
>>> just want to populate
>>> the devices in the fabric, right?
>>
>> Hi Moritz,
>>
>> Yes

That is very strange logic. It should be fine to just call
of_platform_populate unconditionally. If there are no children of np,
then it will be a nop.

>>> > +   if (of_property_read_bool(np, "partial-reconfig"))
>>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
>>> > +
>>> > +   ret = fpga_area_get_bus(area);
>>> > +   if (ret) {
>>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
>>> > +   goto err_unreg;
>>> > +   }
>>>
>>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
>>> need to become a subnode of fpgabus@0 at the same place?
>>>
>>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
>>>
>>> and the ranges property would be used to translate to the fpga memory
>>> mapped space?
>>>
>>> I know we're going back and forth on this. I think Rob brought up a
>>> similar question:
>>> "Does the bus really go thru the fpgamgr and then the bridge as this
>>> implies? Or fpgamgr is a sideband controller?"
>>>
>>> To which I think the answer is 'sideband' controller, yet with the new
>>> bindings it looks like
>>> the bus goes through the fpgamgr.
>>
>> Yeah, let's get this right.  First, let's be clear on the reason for FPGA 
>> Bus to
>> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
>> the bridges and manager that are associated with a certain FPGA.  This allows
>> the system designer to specify which FPGA is getting programmed with which
>> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
>> with
>> a FPGA Manager.
>
> I see your argument for the FPGA bus. I agree that we need to
> distinguish different FPGAs,
> and we need a way to associate an area with a manager (and potentially 
> bridges).
>
>> As far as the target path is concerned, in the case of no bridges, we could 
>> have
>> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be 
>> more
>> logical.  This would just be a documentation change; I think fpga-area.c will
>> work OK if you specify the FPGA bus as your target (the manager still has to
>> be a child of the bus so the bus knows what manager to use).
>
> Could the bus not just use a phandle to the manager? Or the area a
> phandle to the bus?

That may be better as it would avoid the virtual fpga-bus which is a
bit questionable. I'm okay with allowing it, but will happily take any
examples where it doesn't work. However, I'm not sure this case is
one.

> Like that one could have potentially disjunct groups. Say I have a SPI
> device that is in an FPGA area.
> With our current system, I'd have a FPGA Manager that needs to be a
> child of the bus as child of the SPI controller
> with the memory addresses being addresses on the SOC's memory bus:
>
> spi_ctrl@deadbeef {
> fpga_bus@0 {
> fpgamgr@f8007000 {
> mgr regs etc...
> ... and now the SPI slaves ...
> slave@42 {
> };
> };
> };
> };

I think Alan's assumption is there's always a memory mapped control
interface and the DT hierarchy follows that. While I see you could
have other interfaces like SPI, that would not be the control
interface related to FPGA programming AIUI. You could also have GPIOs,
I2C, or any other bus/interface we describe in DT in theory.

How to deal with additional connections like this is similar to
overlays for daughterboards (e.g. capes, hats, shields) where the need
for mapping slave devices on a connector to host controllers/buses
which can vary. In that case, you don't want to have to create a
different 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Moritz Fischer]

On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
> On Fri, 22 Jan 2016, Moritz Fischer wrote:
>
>> Alan,
>>
>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
>>
>> > +static int fpga_area_probe(struct platform_device *pdev)
>> > +{
>> > +   struct device *dev = >dev;
>> > +   struct device_node *np = dev->of_node;
>> > +   struct fpga_area *area;
>> > +   int ret;
>> > +
>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
>> > +   if (!area)
>> > +   return -ENOMEM;
>> > +
>> > +   INIT_LIST_HEAD(>bridge_list);
>> > +
>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
>> > +   if (ret)
>> > +   return ret;
>> > +   area->br = dev_get_drvdata(dev);
>> > +
>> > +   if (of_property_read_string(np, "firmware-name",
>> > +   >firmware_name)) {
>> > +   of_platform_populate(np, of_default_bus_match_table, NULL, 
>> > dev);
>> > +   return 0;
>> > +   }
>>
>> This is the use case where the bootloader loaded the fpga, and you
>> just want to populate
>> the devices in the fabric, right?
>
> Hi Moritz,
>
> Yes
>
>>
>> > +   if (of_property_read_bool(np, "partial-reconfig"))
>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
>> > +
>> > +   ret = fpga_area_get_bus(area);
>> > +   if (ret) {
>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
>> > +   goto err_unreg;
>> > +   }
>>
>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
>> need to become a subnode of fpgabus@0 at the same place?
>>
>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
>>
>> and the ranges property would be used to translate to the fpga memory
>> mapped space?
>>
>> I know we're going back and forth on this. I think Rob brought up a
>> similar question:
>> "Does the bus really go thru the fpgamgr and then the bridge as this
>> implies? Or fpgamgr is a sideband controller?"
>>
>> To which I think the answer is 'sideband' controller, yet with the new
>> bindings it looks like
>> the bus goes through the fpgamgr.
>
> Yeah, let's get this right.  First, let's be clear on the reason for FPGA Bus 
> to
> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
> the bridges and manager that are associated with a certain FPGA.  This allows
> the system designer to specify which FPGA is getting programmed with which
> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
> with
> a FPGA Manager.

I see your argument for the FPGA bus. I agree that we need to
distinguish different FPGAs,
and we need a way to associate an area with a manager (and potentially bridges).

> As far as the target path is concerned, in the case of no bridges, we could 
> have
> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be more
> logical.  This would just be a documentation change; I think fpga-area.c will
> work OK if you specify the FPGA bus as your target (the manager still has to
> be a child of the bus so the bus knows what manager to use).

Could the bus not just use a phandle to the manager? Or the area a
phandle to the bus?
Like that one could have potentially disjunct groups. Say I have a SPI
device that is in an FPGA area.
With our current system, I'd have a FPGA Manager that needs to be a
child of the bus as child of the SPI controller
with the memory addresses being addresses on the SOC's memory bus:

spi_ctrl@deadbeef {
fpga_bus@0 {
fpgamgr@f8007000 {
mgr regs etc...
... and now the SPI slaves ...
slave@42 {
};
};
};
};

(or something like that, maybe I'm confused)

with my proposed one it looks like it would work with any bus (maybe
then areas would have to register with
the manager or something like that...)

spi_ctrl@deadbeef {
fpga_area {
fpga-mgr = <>;
slave0@42 {
};
};
};

I keep bringing up SPI because it's another bus with addresses, not
because I think we should particularly
optimize for that use case ;-)

Cheers,

Moritz

PS: Feel free to 'break' my suggestion above. It's just an idea

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Fri, 22 Jan 2016, Moritz Fischer wrote:

> Alan,
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> 
> > +static int fpga_area_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = >dev;
> > +   struct device_node *np = dev->of_node;
> > +   struct fpga_area *area;
> > +   int ret;
> > +
> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> > +   if (!area)
> > +   return -ENOMEM;
> > +
> > +   INIT_LIST_HEAD(>bridge_list);
> > +
> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> > +   if (ret)
> > +   return ret;
> > +   area->br = dev_get_drvdata(dev);
> > +
> > +   if (of_property_read_string(np, "firmware-name",
> > +   >firmware_name)) {
> > +   of_platform_populate(np, of_default_bus_match_table, NULL, 
> > dev);
> > +   return 0;
> > +   }
> 
> This is the use case where the bootloader loaded the fpga, and you
> just want to populate
> the devices in the fabric, right?

Hi Moritz,

Yes

> 
> > +   if (of_property_read_bool(np, "partial-reconfig"))
> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> > +
> > +   ret = fpga_area_get_bus(area);
> > +   if (ret) {
> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> > +   goto err_unreg;
> > +   }
> 
> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> need to become a subnode of fpgabus@0 at the same place?
> 
> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> 
> and the ranges property would be used to translate to the fpga memory
> mapped space?
> 
> I know we're going back and forth on this. I think Rob brought up a
> similar question:
> "Does the bus really go thru the fpgamgr and then the bridge as this
> implies? Or fpgamgr is a sideband controller?"
> 
> To which I think the answer is 'sideband' controller, yet with the new
> bindings it looks like
> the bus goes through the fpgamgr.

Yeah, let's get this right.  First, let's be clear on the reason for FPGA Bus to
exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
the bridges and manager that are associated with a certain FPGA.  This allows
the system designer to specify which FPGA is getting programmed with which
image/hardware.  So at minimum, we need some way of associating a FPGA Bus with
a FPGA Manager.

As far as the target path is concerned, in the case of no bridges, we could have
the overlay target the FPGA Bus instead of the FPGA Manager.  That may be more
logical.  This would just be a documentation change; I think fpga-area.c will
work OK if you specify the FPGA bus as your target (the manager still has to
be a child of the bus so the bus knows what manager to use).

Alan

> 
> Cheers,
> 
> Moritz
> 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Moritz Fischer]

Alan,

On Wed, Jan 20, 2016 at 8:24 PM,   wrote:

> +static int fpga_area_probe(struct platform_device *pdev)
> +{
> +   struct device *dev = >dev;
> +   struct device_node *np = dev->of_node;
> +   struct fpga_area *area;
> +   int ret;
> +
> +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> +   if (!area)
> +   return -ENOMEM;
> +
> +   INIT_LIST_HEAD(>bridge_list);
> +
> +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> +   if (ret)
> +   return ret;
> +   area->br = dev_get_drvdata(dev);
> +
> +   if (of_property_read_string(np, "firmware-name",
> +   >firmware_name)) {
> +   of_platform_populate(np, of_default_bus_match_table, NULL, 
> dev);
> +   return 0;
> +   }

This is the use case where the bootloader loaded the fpga, and you
just want to populate
the devices in the fabric, right?

> +   if (of_property_read_bool(np, "partial-reconfig"))
> +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> +
> +   ret = fpga_area_get_bus(area);
> +   if (ret) {
> +   dev_dbg(dev, "Should be child of a FPGA Bus");
> +   goto err_unreg;
> +   }

Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
need to become a subnode of fpgabus@0 at the same place?

i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000

and the ranges property would be used to translate to the fpga memory
mapped space?

I know we're going back and forth on this. I think Rob brought up a
similar question:
"Does the bus really go thru the fpgamgr and then the bridge as this
implies? Or fpgamgr is a sideband controller?"

To which I think the answer is 'sideband' controller, yet with the new
bindings it looks like
the bus goes through the fpgamgr.

Cheers,

Moritz

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Moritz Fischer]

Alan,

On Wed, Jan 20, 2016 at 8:24 PM,   wrote:

> +static int fpga_area_probe(struct platform_device *pdev)
> +{
> +   struct device *dev = >dev;
> +   struct device_node *np = dev->of_node;
> +   struct fpga_area *area;
> +   int ret;
> +
> +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> +   if (!area)
> +   return -ENOMEM;
> +
> +   INIT_LIST_HEAD(>bridge_list);
> +
> +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> +   if (ret)
> +   return ret;
> +   area->br = dev_get_drvdata(dev);
> +
> +   if (of_property_read_string(np, "firmware-name",
> +   >firmware_name)) {
> +   of_platform_populate(np, of_default_bus_match_table, NULL, 
> dev);
> +   return 0;
> +   }

This is the use case where the bootloader loaded the fpga, and you
just want to populate
the devices in the fabric, right?

> +   if (of_property_read_bool(np, "partial-reconfig"))
> +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> +
> +   ret = fpga_area_get_bus(area);
> +   if (ret) {
> +   dev_dbg(dev, "Should be child of a FPGA Bus");
> +   goto err_unreg;
> +   }

Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
need to become a subnode of fpgabus@0 at the same place?

i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000

and the ranges property would be used to translate to the fpga memory
mapped space?

I know we're going back and forth on this. I think Rob brought up a
similar question:
"Does the bus really go thru the fpgamgr and then the bridge as this
implies? Or fpgamgr is a sideband controller?"

To which I think the answer is 'sideband' controller, yet with the new
bindings it looks like
the bus goes through the fpgamgr.

Cheers,

Moritz

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Fri, 22 Jan 2016, Moritz Fischer wrote:

> Alan,
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> 
> > +static int fpga_area_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = >dev;
> > +   struct device_node *np = dev->of_node;
> > +   struct fpga_area *area;
> > +   int ret;
> > +
> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> > +   if (!area)
> > +   return -ENOMEM;
> > +
> > +   INIT_LIST_HEAD(>bridge_list);
> > +
> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> > +   if (ret)
> > +   return ret;
> > +   area->br = dev_get_drvdata(dev);
> > +
> > +   if (of_property_read_string(np, "firmware-name",
> > +   >firmware_name)) {
> > +   of_platform_populate(np, of_default_bus_match_table, NULL, 
> > dev);
> > +   return 0;
> > +   }
> 
> This is the use case where the bootloader loaded the fpga, and you
> just want to populate
> the devices in the fabric, right?

Hi Moritz,

Yes

> 
> > +   if (of_property_read_bool(np, "partial-reconfig"))
> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> > +
> > +   ret = fpga_area_get_bus(area);
> > +   if (ret) {
> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> > +   goto err_unreg;
> > +   }
> 
> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> need to become a subnode of fpgabus@0 at the same place?
> 
> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> 
> and the ranges property would be used to translate to the fpga memory
> mapped space?
> 
> I know we're going back and forth on this. I think Rob brought up a
> similar question:
> "Does the bus really go thru the fpgamgr and then the bridge as this
> implies? Or fpgamgr is a sideband controller?"
> 
> To which I think the answer is 'sideband' controller, yet with the new
> bindings it looks like
> the bus goes through the fpgamgr.

Yeah, let's get this right.  First, let's be clear on the reason for FPGA Bus to
exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
the bridges and manager that are associated with a certain FPGA.  This allows
the system designer to specify which FPGA is getting programmed with which
image/hardware.  So at minimum, we need some way of associating a FPGA Bus with
a FPGA Manager.

As far as the target path is concerned, in the case of no bridges, we could have
the overlay target the FPGA Bus instead of the FPGA Manager.  That may be more
logical.  This would just be a documentation change; I think fpga-area.c will
work OK if you specify the FPGA bus as your target (the manager still has to
be a child of the bus so the bus knows what manager to use).

Alan

> 
> Cheers,
> 
> Moritz
> 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Moritz Fischer]

On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
> On Fri, 22 Jan 2016, Moritz Fischer wrote:
>
>> Alan,
>>
>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
>>
>> > +static int fpga_area_probe(struct platform_device *pdev)
>> > +{
>> > +   struct device *dev = >dev;
>> > +   struct device_node *np = dev->of_node;
>> > +   struct fpga_area *area;
>> > +   int ret;
>> > +
>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
>> > +   if (!area)
>> > +   return -ENOMEM;
>> > +
>> > +   INIT_LIST_HEAD(>bridge_list);
>> > +
>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
>> > +   if (ret)
>> > +   return ret;
>> > +   area->br = dev_get_drvdata(dev);
>> > +
>> > +   if (of_property_read_string(np, "firmware-name",
>> > +   >firmware_name)) {
>> > +   of_platform_populate(np, of_default_bus_match_table, NULL, 
>> > dev);
>> > +   return 0;
>> > +   }
>>
>> This is the use case where the bootloader loaded the fpga, and you
>> just want to populate
>> the devices in the fabric, right?
>
> Hi Moritz,
>
> Yes
>
>>
>> > +   if (of_property_read_bool(np, "partial-reconfig"))
>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
>> > +
>> > +   ret = fpga_area_get_bus(area);
>> > +   if (ret) {
>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
>> > +   goto err_unreg;
>> > +   }
>>
>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
>> need to become a subnode of fpgabus@0 at the same place?
>>
>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
>>
>> and the ranges property would be used to translate to the fpga memory
>> mapped space?
>>
>> I know we're going back and forth on this. I think Rob brought up a
>> similar question:
>> "Does the bus really go thru the fpgamgr and then the bridge as this
>> implies? Or fpgamgr is a sideband controller?"
>>
>> To which I think the answer is 'sideband' controller, yet with the new
>> bindings it looks like
>> the bus goes through the fpgamgr.
>
> Yeah, let's get this right.  First, let's be clear on the reason for FPGA Bus 
> to
> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
> the bridges and manager that are associated with a certain FPGA.  This allows
> the system designer to specify which FPGA is getting programmed with which
> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
> with
> a FPGA Manager.

I see your argument for the FPGA bus. I agree that we need to
distinguish different FPGAs,
and we need a way to associate an area with a manager (and potentially bridges).

> As far as the target path is concerned, in the case of no bridges, we could 
> have
> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be more
> logical.  This would just be a documentation change; I think fpga-area.c will
> work OK if you specify the FPGA bus as your target (the manager still has to
> be a child of the bus so the bus knows what manager to use).

Could the bus not just use a phandle to the manager? Or the area a
phandle to the bus?
Like that one could have potentially disjunct groups. Say I have a SPI
device that is in an FPGA area.
With our current system, I'd have a FPGA Manager that needs to be a
child of the bus as child of the SPI controller
with the memory addresses being addresses on the SOC's memory bus:

spi_ctrl@deadbeef {
fpga_bus@0 {
fpgamgr@f8007000 {
mgr regs etc...
... and now the SPI slaves ...
slave@42 {
};
};
};
};

(or something like that, maybe I'm confused)

with my proposed one it looks like it would work with any bus (maybe
then areas would have to register with
the manager or something like that...)

spi_ctrl@deadbeef {
fpga_area {
fpga-mgr = <>;
slave0@42 {
};
};
};

I keep bringing up SPI because it's another bus with addresses, not
because I think we should particularly
optimize for that use case ;-)

Cheers,

Moritz

PS: Feel free to 'break' my suggestion above. It's just an idea

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Thu, 21 Jan 2016, Moritz Fischer wrote:

> Hi Alan,
> 
> minor nits inline:
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> 
> > v15: Add altr,fpga-bus implementation
> >  Change compatible string "fpga-area" -> "altr,fpga-area"
> 
> Doesn't look that way down there. Or am I reading the code wrong?

Hi Moritz,

Yes, I left that out accidentally.  But hopefully we won't have
pushback around this issue and I can leave it out permanently
and also change altr,fpga-bus to fpga-bus.

Alan

> 
> > +static const struct of_device_id fpga_area_of_match[] = {
> > +   { .compatible = "fpga-area", },
> 
> I'm fine with keeping it as fpga-area, this isn't altera specific imho
> 
> Cheers,
> 
> Moritz
> 

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Moritz Fischer]

Hi Alan,

minor nits inline:

On Wed, Jan 20, 2016 at 8:24 PM,   wrote:

> v15: Add altr,fpga-bus implementation
>  Change compatible string "fpga-area" -> "altr,fpga-area"

Doesn't look that way down there. Or am I reading the code wrong?

> +static const struct of_device_id fpga_area_of_match[] = {
> +   { .compatible = "fpga-area", },

I'm fine with keeping it as fpga-area, this isn't altera specific imho

Cheers,

Moritz

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[Moritz Fischer]

Hi Alan,

minor nits inline:

On Wed, Jan 20, 2016 at 8:24 PM,   wrote:

> v15: Add altr,fpga-bus implementation
>  Change compatible string "fpga-area" -> "altr,fpga-area"

Doesn't look that way down there. Or am I reading the code wrong?

> +static const struct of_device_id fpga_area_of_match[] = {
> +   { .compatible = "fpga-area", },

I'm fine with keeping it as fpga-area, this isn't altera specific imho

Cheers,

Moritz

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Thu, 21 Jan 2016, Moritz Fischer wrote:

> Hi Alan,
> 
> minor nits inline:
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> 
> > v15: Add altr,fpga-bus implementation
> >  Change compatible string "fpga-area" -> "altr,fpga-area"
> 
> Doesn't look that way down there. Or am I reading the code wrong?

Hi Moritz,

Yes, I left that out accidentally.  But hopefully we won't have
pushback around this issue and I can leave it out permanently
and also change altr,fpga-bus to fpga-bus.

Alan

> 
> > +static const struct of_device_id fpga_area_of_match[] = {
> > +   { .compatible = "fpga-area", },
> 
> I'm fine with keeping it as fpga-area, this isn't altera specific imho
> 
> Cheers,
> 
> Moritz
> 

[PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

From: Alan Tull 

FPGA Area and FPGA Bus support programming FPGA under control of
the Device Tree.

A FPGA Bus contains the devices necessary for programming an
FPGA.

When a Device Tree Overlay containing a FPGA Area is
applied, the FPGA Area will be probed and will:
 * check to see if there is an image to program to a FPGA
 * get references to the FPGA manager and bridges if any
 * disable FPGA bridges to prevent spurious data on busses
 * reprogram the FPGA
 * enable the specified FPGA bridges
 * populate the child devices

Removing the Device Tree Overlay is also supported.

This supports fpga use where hardware blocks on a fpga will
need drivers.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
v13: If no bridges are specified, assume we don't need any.
 Clean up debug messages
 Some dev_info -> dev_dbg
 Remove unneeded #include
 Fix size of array of pointers
 Don't need to specify .owner
 Use common binding: firmware-name
v14: OK it's not a simple bus.  Call it "FPGA Area"
 Remove bindings that specify FPGA manager and FPGA bridges
 Use parent FPGA bridge and bridges that are its peers
 Use ancestor FPGA Manager
v15: Add altr,fpga-bus implementation
 Change compatible string "fpga-area" -> "altr,fpga-area"
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-area.c |  352 ++
 3 files changed, 362 insertions(+)
 create mode 100644 drivers/fpga/fpga-area.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index b6cfd89..6ac916b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -31,6 +31,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config FPGA_AREA
+   bool "Device Tree Based FPGA Reprogramming"
+   depends on FPGA_BRIDGE
+   help
+ Enable FPGA Area which supports programming FPGAs under control of
+Device Tree.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 4baef00..4f7e49f 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,3 +11,6 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
+# High Level Interfaces
+obj-$(CONFIG_FPGA_AREA)+= fpga-area.o
diff --git a/drivers/fpga/fpga-area.c b/drivers/fpga/fpga-area.c
new file mode 100644
index 000..cec332f
--- /dev/null
+++ b/drivers/fpga/fpga-area.c
@@ -0,0 +1,352 @@
+/*
+ * FPGA Tree Area Support for Device Tree controlled FPGA reprogramming
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * In the case of a FPGA doing full reconfiguration, the area == the whole
+ * FPGA.  In the case of partial reconfiguration, several areas can be
+ * reconfigured separately.
+ */
+
+/**
+ * struct fpga_area
+ * @mgr:   FPGA Manager
+ * @flags: Flags for reconfiguration
+ * @firmware_name: Name of FPGA image file
+ * @bridge_list: Linked list of FPGA bridges controlled by area
+ * @br:FPGA Bridge corresponding to area
+ * @bus_np:device node of ancestor FPGA Bus
+ */
+struct fpga_area {
+   struct fpga_manager *mgr;
+   u32 flags;
+   const char *firmware_name;
+   struct list_head bridge_list;
+   struct fpga_bridge *br;
+   struct device_node *bus_np;
+};
+
+/**
+ * fpga_area_get_parent_peer_bridges - get bridges that are peers of parent
+ * @area: FPGA Area struct
+ *
+ * Intended to support case where multiple bridges need to be disabled
+ * during FPGA reprogramming.
+ *
+ * Finds the FPGA bridge that is the parent of @area in the device tree.
+ * Creates a linked list of FPGA bridges that includes the parent bridge and
+ * its peers.  Gets an exclusive reference to 

[PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

From: Alan Tull 

FPGA Area and FPGA Bus support programming FPGA under control of
the Device Tree.

A FPGA Bus contains the devices necessary for programming an
FPGA.

When a Device Tree Overlay containing a FPGA Area is
applied, the FPGA Area will be probed and will:
 * check to see if there is an image to program to a FPGA
 * get references to the FPGA manager and bridges if any
 * disable FPGA bridges to prevent spurious data on busses
 * reprogram the FPGA
 * enable the specified FPGA bridges
 * populate the child devices

Removing the Device Tree Overlay is also supported.

This supports fpga use where hardware blocks on a fpga will
need drivers.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
v13: If no bridges are specified, assume we don't need any.
 Clean up debug messages
 Some dev_info -> dev_dbg
 Remove unneeded #include
 Fix size of array of pointers
 Don't need to specify .owner
 Use common binding: firmware-name
v14: OK it's not a simple bus.  Call it "FPGA Area"
 Remove bindings that specify FPGA manager and FPGA bridges
 Use parent FPGA bridge and bridges that are its peers
 Use ancestor FPGA Manager
v15: Add altr,fpga-bus implementation
 Change compatible string "fpga-area" -> "altr,fpga-area"
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-area.c |  352 ++
 3 files changed, 362 insertions(+)
 create mode 100644 drivers/fpga/fpga-area.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index b6cfd89..6ac916b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -31,6 +31,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config FPGA_AREA
+   bool "Device Tree Based FPGA Reprogramming"
+   depends on FPGA_BRIDGE
+   help
+ Enable FPGA Area which supports programming FPGAs under control of
+Device Tree.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 4baef00..4f7e49f 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,3 +11,6 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
+# High Level Interfaces
+obj-$(CONFIG_FPGA_AREA)+= fpga-area.o
diff --git a/drivers/fpga/fpga-area.c b/drivers/fpga/fpga-area.c
new file mode 100644
index 000..cec332f
--- /dev/null
+++ b/drivers/fpga/fpga-area.c
@@ -0,0 +1,352 @@
+/*
+ * FPGA Tree Area Support for Device Tree controlled FPGA reprogramming
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * In the case of a FPGA doing full reconfiguration, the area == the whole
+ * FPGA.  In the case of partial reconfiguration, several areas can be
+ * reconfigured separately.
+ */
+
+/**
+ * struct fpga_area
+ * @mgr:   FPGA Manager
+ * @flags: Flags for reconfiguration
+ * @firmware_name: Name of FPGA image file
+ * @bridge_list: Linked list of FPGA bridges controlled by area
+ * @br:FPGA Bridge corresponding to area
+ * @bus_np:device node of ancestor FPGA Bus
+ */
+struct fpga_area {
+   struct fpga_manager *mgr;
+   u32 flags;
+   const char *firmware_name;
+   struct list_head bridge_list;
+   struct fpga_bridge *br;
+   struct device_node *bus_np;
+};
+
+/**
+ * fpga_area_get_parent_peer_bridges - get bridges that are peers of parent
+ * @area: FPGA Area struct
+ *
+ * Intended to support case where multiple bridges need to be disabled
+ * during FPGA reprogramming.
+ *
+ * Finds the FPGA bridge that is the parent of @area in the device tree.
+ * Creates a linked list of FPGA bridges that includes the parent