From: Dinh Nguyen <[email protected]>
There are certain drivers that are required to get loaded very early using
arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
This driver has to get loaded early because it needs to enable FPGA components
that are connected to the bridge.
This FPGA bridge driver will using the reset controller API to toggle it's
reset bits, thus, it needs the reset driver to be loaded as early as possible
in order for it to get used properly.
Signed-off-by: Dinh Nguyen <[email protected]>
---
drivers/reset/reset-socfpga.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 79c32ca..a5e8d37 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -139,7 +139,20 @@ static struct platform_driver socfpga_reset_driver = {
.of_match_table = socfpga_reset_dt_ids,
},
};
-module_platform_driver(socfpga_reset_driver);
+
+static int __init socfpga_reset_init(void)
+{
+ return platform_driver_probe(&socfpga_reset_driver,
+ socfpga_reset_probe);
+}
+
+static void __exit socfpga_reset_exit(void)
+{
+ platform_driver_unregister(&socfpga_reset_driver);
+}
+
+arch_initcall(socfpga_reset_init);
+module_exit(socfpga_reset_exit);
MODULE_AUTHOR("Steffen Trumtrar <[email protected]");
MODULE_DESCRIPTION("Socfpga Reset Controller Driver");
--
2.0.3
Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
[email protected]:
> From: Dinh Nguyen <[email protected]>
>
> There are certain drivers that are required to get loaded very early using
> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> This driver has to get loaded early because it needs to enable FPGA components
> that are connected to the bridge.
>
> This FPGA bridge driver will using the reset controller API to toggle it's
> reset bits, thus, it needs the reset driver to be loaded as early as possible
> in order for it to get used properly.
Without knowing the details, this sounds like the wrong approach. Can't
the bridge driver return -EPROBE_DEFER until the reset controller is
available?
regards
Philipp
Hi Philipp,
On 10/9/14, 4:03 AM, Philipp Zabel wrote:
> Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
> [email protected]:
>> From: Dinh Nguyen <[email protected]>
>>
>> There are certain drivers that are required to get loaded very early using
>> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
>> This driver has to get loaded early because it needs to enable FPGA components
>> that are connected to the bridge.
>>
>> This FPGA bridge driver will using the reset controller API to toggle it's
>> reset bits, thus, it needs the reset driver to be loaded as early as possible
>> in order for it to get used properly.
>
> Without knowing the details, this sounds like the wrong approach. Can't
> the bridge driver return -EPROBE_DEFER until the reset controller is
> available?
>
The bridge driver is also using arch_initcall, as it also needs to get
loaded early for FPGA IPs to work, and so later driver loading will work
for the FPGA IPs.
Dinh
On Thu, Oct 09, 2014 at 08:16:18AM -0500, Dinh Nguyen wrote:
> Hi Philipp,
>
> On 10/9/14, 4:03 AM, Philipp Zabel wrote:
> > Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
> > [email protected]:
> >> From: Dinh Nguyen <[email protected]>
> >>
> >> There are certain drivers that are required to get loaded very early using
> >> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> >> This driver has to get loaded early because it needs to enable FPGA components
> >> that are connected to the bridge.
> >>
> >> This FPGA bridge driver will using the reset controller API to toggle it's
> >> reset bits, thus, it needs the reset driver to be loaded as early as possible
> >> in order for it to get used properly.
> >
> > Without knowing the details, this sounds like the wrong approach. Can't
> > the bridge driver return -EPROBE_DEFER until the reset controller is
> > available?
> >
>
> The bridge driver is also using arch_initcall, as it also needs to get
> loaded early for FPGA IPs to work, and so later driver loading will work
> for the FPGA IPs.
>
For the bridge driver the same is true. I guess that there *might* be
IP cores where you need to be very early, but that shouldn't be the normal
case. If the driver can't get loaded properly, the right thing would be to
fix the driver.
I have developed a bridge driver, too (which only needs the devicetree binding
docu for a v1) and I have a driver+IP core that is directly connected to the
bridge. I don't need any messing around with the initcalls to work properly.
-EPROBE_DEFER works just fine.
What I do need however is loading the FPGA very early of course, if it is not
done in the bootloader.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
> On Thu, Oct 09, 2014 at 08:16:18AM -0500, Dinh Nguyen wrote:
> > Hi Philipp,
> >
> > On 10/9/14, 4:03 AM, Philipp Zabel wrote:
> > > Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
> > > [email protected]:
> > >> From: Dinh Nguyen <[email protected]>
> > >>
> > >> There are certain drivers that are required to get loaded very early using
> > >> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> > >> This driver has to get loaded early because it needs to enable FPGA components
> > >> that are connected to the bridge.
> > >>
> > >> This FPGA bridge driver will using the reset controller API to toggle it's
> > >> reset bits, thus, it needs the reset driver to be loaded as early as possible
> > >> in order for it to get used properly.
> > >
> > > Without knowing the details, this sounds like the wrong approach. Can't
> > > the bridge driver return -EPROBE_DEFER until the reset controller is
> > > available?
> > >
I don't think we can do deferred probing for arch_initcall.
> >
> > The bridge driver is also using arch_initcall, as it also needs to get
> > loaded early for FPGA IPs to work, and so later driver loading will work
> > for the FPGA IPs.
> >
>
> For the bridge driver the same is true. I guess that there *might* be
> IP cores where you need to be very early, but that shouldn't be the normal
> case. If the driver can't get loaded properly, the right thing would be to
> fix the driver.
Some fpga ip drivers will need to be early (and will assume that the fpga
was programmed by the bootloader). We want to support that case.
>
> I have developed a bridge driver, too (which only needs the devicetree binding
> docu for a v1) and I have a driver+IP core that is directly connected to the
> bridge. I don't need any messing around with the initcalls to work properly.
> -EPROBE_DEFER works just fine.
Is this based on the "proposed fpga bridge framework" that I posted?
What we are trying to do is update that bridge driver to use the reset driver for
submitting v2.
Alan
>
> What I do need however is loading the FPGA very early of course, if it is not
> done in the bootloader.
>
> Regards,
> Steffen
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
Hi!
On Thu, Oct 09, 2014 at 09:57:49AM -0500, atull wrote:
> On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
>
> > On Thu, Oct 09, 2014 at 08:16:18AM -0500, Dinh Nguyen wrote:
> > > Hi Philipp,
> > >
> > > On 10/9/14, 4:03 AM, Philipp Zabel wrote:
> > > > Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
> > > > [email protected]:
> > > >> From: Dinh Nguyen <[email protected]>
> > > >>
> > > >> There are certain drivers that are required to get loaded very early using
> > > >> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> > > >> This driver has to get loaded early because it needs to enable FPGA components
> > > >> that are connected to the bridge.
> > > >>
> > > >> This FPGA bridge driver will using the reset controller API to toggle it's
> > > >> reset bits, thus, it needs the reset driver to be loaded as early as possible
> > > >> in order for it to get used properly.
> > > >
> > > > Without knowing the details, this sounds like the wrong approach. Can't
> > > > the bridge driver return -EPROBE_DEFER until the reset controller is
> > > > available?
> > > >
>
> I don't think we can do deferred probing for arch_initcall.
>
> > >
> > > The bridge driver is also using arch_initcall, as it also needs to get
> > > loaded early for FPGA IPs to work, and so later driver loading will work
> > > for the FPGA IPs.
> > >
> >
> > For the bridge driver the same is true. I guess that there *might* be
> > IP cores where you need to be very early, but that shouldn't be the normal
> > case. If the driver can't get loaded properly, the right thing would be to
> > fix the driver.
>
> Some fpga ip drivers will need to be early (and will assume that the fpga
> was programmed by the bootloader). We want to support that case.
>
Do you have an example where this is really needed?
> >
> > I have developed a bridge driver, too (which only needs the devicetree binding
> > docu for a v1) and I have a driver+IP core that is directly connected to the
> > bridge. I don't need any messing around with the initcalls to work properly.
> > -EPROBE_DEFER works just fine.
>
> Is this based on the "proposed fpga bridge framework" that I posted?
> What we are trying to do is update that bridge driver to use the reset driver for
> submitting v2.
Are you talking about the FPGA manager patches? Then: no.
If not, I seem to have missed the patches.
The driver just probes and then releases the resets for the according bridge.
It shall however support the GPV configuration also (which it doesn't at the moment)
But this reminds me, why I didn't send the driver earlier. IIRC you want to reset
the bridges after writing the bitstream to the FPGA manager.
So, I would need to add that first so you can access that in your fpga manager
driver.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
Hi Steffen,
> Hi!
>
> On Thu, Oct 09, 2014 at 09:57:49AM -0500, atull wrote:
> > On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
> >
> > > On Thu, Oct 09, 2014 at 08:16:18AM -0500, Dinh Nguyen wrote:
> > > > Hi Philipp,
> > > >
> > > > On 10/9/14, 4:03 AM, Philipp Zabel wrote:
> > > > > Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
> > > > > [email protected]:
> > > > >> From: Dinh Nguyen <[email protected]>
> > > > >>
> > > > >> There are certain drivers that are required to get loaded very early using
> > > > >> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> > > > >> This driver has to get loaded early because it needs to enable FPGA components
> > > > >> that are connected to the bridge.
> > > > >>
> > > > >> This FPGA bridge driver will using the reset controller API to toggle it's
> > > > >> reset bits, thus, it needs the reset driver to be loaded as early as possible
> > > > >> in order for it to get used properly.
> > > > >
> > > > > Without knowing the details, this sounds like the wrong approach. Can't
> > > > > the bridge driver return -EPROBE_DEFER until the reset controller is
> > > > > available?
> > > > >
> >
> > I don't think we can do deferred probing for arch_initcall.
> >
> > > >
> > > > The bridge driver is also using arch_initcall, as it also needs to get
> > > > loaded early for FPGA IPs to work, and so later driver loading will work
> > > > for the FPGA IPs.
> > > >
> > >
> > > For the bridge driver the same is true. I guess that there *might* be
> > > IP cores where you need to be very early, but that shouldn't be the normal
> > > case. If the driver can't get loaded properly, the right thing would be to
> > > fix the driver.
> >
> > Some fpga ip drivers will need to be early (and will assume that the fpga
> > was programmed by the bootloader). We want to support that case.
> >
>
> Do you have an example where this is really needed?
My last version of the fpga manager framework
(https://lkml.org/lkml/2014/8/1/518)
added fpga_mgr_firmware_write(). This can be called from a device driver's
probe function to request a fpga image be loaded. I want to support FPGA
based functionality being seen pretty similar to really hard hardware. So
the FPGA could have a PCI bus or something else that would want to be
early.
>
> > >
> > > I have developed a bridge driver, too (which only needs the devicetree binding
> > > docu for a v1) and I have a driver+IP core that is directly connected to the
> > > bridge. I don't need any messing around with the initcalls to work properly.
> > > -EPROBE_DEFER works just fine.
> >
> > Is this based on the "proposed fpga bridge framework" that I posted?
> > What we are trying to do is update that bridge driver to use the reset driver for
> > submitting v2.
>
> Are you talking about the FPGA manager patches? Then: no.
> If not, I seem to have missed the patches.
>
> The driver just probes and then releases the resets for the according bridge.
> It shall however support the GPV configuration also (which it doesn't at the moment)
>
> But this reminds me, why I didn't send the driver earlier. IIRC you want to reset
> the bridges after writing the bitstream to the FPGA manager.
> So, I would need to add that first so you can access that in your fpga manager
> driver.
We need to hold the bridges in reset as long as the FPGA is not programmed
or is being programmed. We want to release the bridges from reset after
programming. If we are going to re-program the FPGA, we will need to
unload any device drivers, set the bridges into reset, then reprogram
the FPGA, release the bridges, load the appropriate device drivers.
The latest fpga manager code also handles reprogramming the FPGA when
device tree fragments are loaded.
Alan
>
> Regards,
> Steffen
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
Hi!
> From: Dinh Nguyen <[email protected]>
>
> There are certain drivers that are required to get loaded very early using
> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> This driver has to get loaded early because it needs to enable FPGA components
> that are connected to the bridge.
>
> This FPGA bridge driver will using the reset controller API to toggle it's
> reset bits, thus, it needs the reset driver to be loaded as early as possible
> in order for it to get used properly.
>
> Signed-off-by: Dinh Nguyen <[email protected]>
> +static int __init socfpga_reset_init(void)
> +{
> + return platform_driver_probe(&socfpga_reset_driver,
> + socfpga_reset_probe);
> +}
> +
> +static void __exit socfpga_reset_exit(void)
> +{
> + platform_driver_unregister(&socfpga_reset_driver);
> +}
> +
> +arch_initcall(socfpga_reset_init);
> +module_exit(socfpga_reset_exit);
That is quite a strange combination. Driver can be module but needs to
be initialized early? Should we make it always built in?
> MODULE_AUTHOR("Steffen Trumtrar <[email protected]");
> MODULE_DESCRIPTION("Socfpga Reset Controller Driver");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 10 Oct 2014, atull wrote:
> On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
>
> Hi Steffen,
>
> > Hi!
> >
> > On Thu, Oct 09, 2014 at 09:57:49AM -0500, atull wrote:
> > > On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
> > >
> > > > On Thu, Oct 09, 2014 at 08:16:18AM -0500, Dinh Nguyen wrote:
> > > > > Hi Philipp,
> > > > >
> > > > > On 10/9/14, 4:03 AM, Philipp Zabel wrote:
> > > > > > Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb
> > > > > > [email protected]:
> > > > > >> From: Dinh Nguyen <[email protected]>
> > > > > >>
> > > > > >> There are certain drivers that are required to get loaded very early using
> > > > > >> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> > > > > >> This driver has to get loaded early because it needs to enable FPGA components
> > > > > >> that are connected to the bridge.
> > > > > >>
> > > > > >> This FPGA bridge driver will using the reset controller API to toggle it's
> > > > > >> reset bits, thus, it needs the reset driver to be loaded as early as possible
> > > > > >> in order for it to get used properly.
> > > > > >
> > > > > > Without knowing the details, this sounds like the wrong approach. Can't
> > > > > > the bridge driver return -EPROBE_DEFER until the reset controller is
> > > > > > available?
> > > > > >
> > >
> > > I don't think we can do deferred probing for arch_initcall.
> > >
> > > > >
> > > > > The bridge driver is also using arch_initcall, as it also needs to get
> > > > > loaded early for FPGA IPs to work, and so later driver loading will work
> > > > > for the FPGA IPs.
> > > > >
> > > >
> > > > For the bridge driver the same is true. I guess that there *might* be
> > > > IP cores where you need to be very early, but that shouldn't be the normal
> > > > case. If the driver can't get loaded properly, the right thing would be to
> > > > fix the driver.
> > >
> > > Some fpga ip drivers will need to be early (and will assume that the fpga
> > > was programmed by the bootloader). We want to support that case.
> > >
> >
> > Do you have an example where this is really needed?
>
> My last version of the fpga manager framework
> (https://lkml.org/lkml/2014/8/1/518)
> added fpga_mgr_firmware_write(). This can be called from a device driver's
> probe function to request a fpga image be loaded. I want to support FPGA
> based functionality being seen pretty similar to really hard hardware. So
> the FPGA could have a PCI bus or something else that would want to be
> early.
>
> >
> > > >
> > > > I have developed a bridge driver, too (which only needs the devicetree binding
> > > > docu for a v1) and I have a driver+IP core that is directly connected to the
> > > > bridge. I don't need any messing around with the initcalls to work properly.
> > > > -EPROBE_DEFER works just fine.
> > >
> > > Is this based on the "proposed fpga bridge framework" that I posted?
> > > What we are trying to do is update that bridge driver to use the reset driver for
> > > submitting v2.
> >
> > Are you talking about the FPGA manager patches? Then: no.
> > If not, I seem to have missed the patches.
> >
> > The driver just probes and then releases the resets for the according bridge.
> > It shall however support the GPV configuration also (which it doesn't at the moment)
> >
> > But this reminds me, why I didn't send the driver earlier. IIRC you want to reset
> > the bridges after writing the bitstream to the FPGA manager.
> > So, I would need to add that first so you can access that in your fpga manager
> > driver.
>
> We need to hold the bridges in reset as long as the FPGA is not programmed
> or is being programmed. We want to release the bridges from reset after
> programming. If we are going to re-program the FPGA, we will need to
> unload any device drivers, set the bridges into reset, then reprogram
> the FPGA, release the bridges, load the appropriate device drivers.
> The latest fpga manager code also handles reprogramming the FPGA when
> device tree fragments are loaded.
>
> Alan
>
The FPGA bridge driver that I submitted last year handled the following
things:
* The bridges might have been brought out of reset in the bootloader. Some
of the bridges have write-only registers (!) so this information had to
be passed in DT
* fpga2sdram bridge widths configured in DT
* Supports enabling the following Altera fpga bridges:
* fpga2sdram
* fpga2hps
* hps2fpga
* lwhps2fpga
* interface in sysfs for each bridge to be put in reset/taken out of reset
* Enable (take out of reset):
$ echo 1 > /sys/class/fpga-bridge/fpga2hps/enable
* Disable (hold in reset):
$ echo 0 > /sys/class/fpga-bridge/fpga2hps/enable
* Check enable/disable status (checks for all bits set):
$ cat /sys/class/fpga-bridge/fpga2hps/enable
(will print '0' or '1')
Now that I'm enabling programming the FPGA from DT overlays, I also want
to support DT control of the bridges at the proper time. So that would
support the use case where adding a DT overlay would:
1. program the FPGA
2. bring the appropriate bridges out of reset
3. modprobe the driver
Deleting the DT overlay would undo these steps in reverse order.
I submitted it on 10/8/2013 (I copied you on it), but I don't see it on
lkml.org. Probably because I submitted it from a gmail email address and
that sometimes doesn't play well with lkml. I'm planning on resubmitting
when we have it better integrated with the reset subsystem. If you can
give me an early idea of how this fits in with your needs, that would be
great.
Alan
Hi!
On Tue, Oct 14, 2014 at 01:45:29PM -0500, atull wrote:
> The FPGA bridge driver that I submitted last year handled the following
> things:
> * The bridges might have been brought out of reset in the bootloader. Some
> of the bridges have write-only registers (!) so this information had to
> be passed in DT
Regmap has infrastructure to handle this.
> * fpga2sdram bridge widths configured in DT
This should hold true for all bridges but the LWHPS.
> * Supports enabling the following Altera fpga bridges:
> * fpga2sdram
> * fpga2hps
> * hps2fpga
> * lwhps2fpga
> * interface in sysfs for each bridge to be put in reset/taken out of reset
> * Enable (take out of reset):
> $ echo 1 > /sys/class/fpga-bridge/fpga2hps/enable
> * Disable (hold in reset):
> $ echo 0 > /sys/class/fpga-bridge/fpga2hps/enable
> * Check enable/disable status (checks for all bits set):
> $ cat /sys/class/fpga-bridge/fpga2hps/enable
> (will print '0' or '1')
>
I don't like that. The proper solution should be unloading/loading the
module for the bridge. On a reset the driver has to completely reset its state.
> Now that I'm enabling programming the FPGA from DT overlays, I also want
> to support DT control of the bridges at the proper time. So that would
> support the use case where adding a DT overlay would:
> 1. program the FPGA
> 2. bring the appropriate bridges out of reset
> 3. modprobe the driver
>
> Deleting the DT overlay would undo these steps in reverse order.
>
> I submitted it on 10/8/2013 (I copied you on it), but I don't see it on
> lkml.org. Probably because I submitted it from a gmail email address and
> that sometimes doesn't play well with lkml. I'm planning on resubmitting
> when we have it better integrated with the reset subsystem. If you can
> give me an early idea of how this fits in with your needs, that would be
> great.
>
I actually remember seeing that driver. The problem with the approach is,
that the bridges are not some IP that you just turn on/off.
The bridges are the busses that connect the FPGA to the SoC. So the driver
and the DT has to accommodate for that.
So, for the (LW)HPS that means we have a bus master driver, that has to
booting:
- check if FPGA manager is enabled in DT
- EPROBE_DEFER if FPGA manager isn't loaded
- check if FPGA is programmed
- EPROBE_DEFER otherwise
- probe subnodes of bridge DT node
dynamic:
- remove all drivers/devices previously probed by the bridge
- put bridge in reset (maybe the remove call should always do that ?)
- program FPGA with (different) bitstream
- (update the DT)
I haven't had time to really look at the overlay stuff, but I guess it will then
just
- probe bridge drivers with 'status = "okay"' which will probe subdevices
Question is: who will remove the bridge driver? Do the DT overlays do that kind
of stuff?
With the FPGA2HPS(SDRAM) bridges it gets a little difficult I guess.
Who is the master on the FPGA2HPS bridge? Depends on your FPGA config.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 10/15/14, 5:02 AM, Steffen Trumtrar wrote:
> Hi!
>
> On Tue, Oct 14, 2014 at 01:45:29PM -0500, atull wrote:
>> The FPGA bridge driver that I submitted last year handled the following
>> things:
>> * The bridges might have been brought out of reset in the bootloader. Some
>> of the bridges have write-only registers (!) so this information had to
>> be passed in DT
>
> Regmap has infrastructure to handle this.
>
The current implementation of Alan's bridge driver is using regmap to
toggle the reset manager bits. However, that required adding "syscon" to
the reset manager's DTS node. By doing this, the reset driver was not
able to load.
So that's the story behind why I'm looking to convert Alan's bridge
driver to use the reset driver.
Dinh
On Friday 10 October 2014 11:32:35 atull wrote:
> On Thu, 9 Oct 2014, Steffen Trumtrar wrote:
> > Do you have an example where this is really needed?
>
> My last version of the fpga manager framework
> (https://lkml.org/lkml/2014/8/1/518)
> added fpga_mgr_firmware_write(). This can be called from a device driver's
> probe function to request a fpga image be loaded. I want to support FPGA
> based functionality being seen pretty similar to really hard hardware. So
> the FPGA could have a PCI bus or something else that would want to be
> early.
Please be more specific. I agree we need a good reason for not just
using deferred probing, and PCI host bridges in general are no longer
something that needs to be probed early.
If you have a particular use case in mind that can't be solved in a
better way, we can talk about making this an earlier initcall (probably
not arch_initcall), but in general we try hard to avoid new ones
like this.
Arnd