On Fri, 22 Jan 2016, Moritz Fischer wrote:
> Alan,
>
> On Wed, Jan 20, 2016 at 8:24 PM, <atull@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > +static int fpga_area_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->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(&area->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",
> > + &area->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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
