| Message ID | 55E59ADA.3080403@boschrexroth.de |
|---|---|
| State | RFC |
| Delegated to: | Marek Vasut |
| Headers | show |
On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote: > Hi Marek, Hi! > On 01.09.2015 14:03, Marek Vasut wrote: > > On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote: > ----snip---- > > >> What about calling socfpga_sdram_apply_static_cfg() direct in > >> socfpga_load() in drivers/fpga/socfpga.c to make it generic? > > > > Which code exactly do you refer to ? > > I mean something like this. > > diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c > index 4448250..d0f67f6 100644 > --- a/drivers/fpga/socfpga.c > +++ b/drivers/fpga/socfpga.c > @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void > *rbf_data, size_t rbf_size) > return status; > > /* Ensure the FPGA entering user mode */ > - return fpgamgr_program_poll_usermode(); > + status = fpgamgr_program_poll_usermode(); > + if (status) > + return status; > + > + /* Latch FPGA2SDRAM bridge configuration */ > + socfpga_sdram_apply_static_cfg(); > + > + return 0; > } > > >> socfpga_load() already did step 1 and 2. > >> Is there any side effect when fpga2sdram bridge is not used? > > > > The idea is to keep the FPGA programming code and the code which > > controls the bridges separate. The reason for that is that you can have > > content in the FPGA which is running completely independent of the HPS > > software. You don't always need to enable the bridges. > > No, it's the other way around here. > socfpga_load() runs eventually when command "fpga load" is called. > So when I explicitly use "fpga load" command, the old FPGA program is > expected to stop running, right? Right > And I don't want to enable the bridge here, just to latch the SDRAM > configuration. So what you want to do is "bridge disable ; fpga load ... ; bridge enable", isn't that the correct sequence ? I might be missing something though, sorry. > > The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff > > like framebuffers implemented in the FPGA, so that the FPGA can fetch > > data from the SDRAM. > > > > Best regards, > > Marek Vasut > > Best regards, > > Jian Luo Best regards, Marek Vasut
Hi Marek, On 02.09.2015 12:27, Marek Vasut wrote: > On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote: >> Hi Marek, > > Hi! > >> On 01.09.2015 14:03, Marek Vasut wrote: >> > On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote: >> ----snip---- >> >> >> What about calling socfpga_sdram_apply_static_cfg() direct in >> >> socfpga_load() in drivers/fpga/socfpga.c to make it generic? >> > >> > Which code exactly do you refer to ? >> >> I mean something like this. >> >> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c >> index 4448250..d0f67f6 100644 >> --- a/drivers/fpga/socfpga.c >> +++ b/drivers/fpga/socfpga.c >> @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void >> *rbf_data, size_t rbf_size) >> return status; >> >> /* Ensure the FPGA entering user mode */ >> - return fpgamgr_program_poll_usermode(); >> + status = fpgamgr_program_poll_usermode(); >> + if (status) >> + return status; >> + >> + /* Latch FPGA2SDRAM bridge configuration */ >> + socfpga_sdram_apply_static_cfg(); >> + >> + return 0; >> } >> >> >> socfpga_load() already did step 1 and 2. >> >> Is there any side effect when fpga2sdram bridge is not used? >> > >> > The idea is to keep the FPGA programming code and the code which >> > controls the bridges separate. The reason for that is that you can have >> > content in the FPGA which is running completely independent of the HPS >> > software. You don't always need to enable the bridges. >> >> No, it's the other way around here. >> socfpga_load() runs eventually when command "fpga load" is called. >> So when I explicitly use "fpga load" command, the old FPGA program is >> expected to stop running, right? > > Right > >> And I don't want to enable the bridge here, just to latch the SDRAM >> configuration. > > So what you want to do is "bridge disable ; fpga load ... ; bridge enable", > isn't that the correct sequence ? I might be missing something though, sorry. No, you are right. Sorry, I didn't think it through. My original thought was, that "fpga load" should not depend on "bridge e/d" regardless of how fpga2sdram is configured. Now I think the dependency is a bad idea. Sorry for the confusion. > >> > The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff >> > like framebuffers implemented in the FPGA, so that the FPGA can fetch >> > data from the SDRAM. >> > >> > Best regards, >> > Marek Vasut >> >> Best regards, >> >> Jian Luo > > Best regards, > Marek Vasut Best regards, Jian Luo
On Wednesday, September 02, 2015 at 01:29:36 PM, Jian Luo wrote: > Hi Marek, Hi! > On 02.09.2015 12:27, Marek Vasut wrote: > > On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote: > >> Hi Marek, > > > > Hi! > > > >> On 01.09.2015 14:03, Marek Vasut wrote: > >> > On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote: > >> ----snip---- > >> > >> >> What about calling socfpga_sdram_apply_static_cfg() direct in > >> >> socfpga_load() in drivers/fpga/socfpga.c to make it generic? > >> > > >> > Which code exactly do you refer to ? > >> > >> I mean something like this. > >> > >> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c > >> index 4448250..d0f67f6 100644 > >> --- a/drivers/fpga/socfpga.c > >> +++ b/drivers/fpga/socfpga.c > >> @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void > >> *rbf_data, size_t rbf_size) > >> > >> return status; > >> > >> /* Ensure the FPGA entering user mode */ > >> > >> - return fpgamgr_program_poll_usermode(); > >> + status = fpgamgr_program_poll_usermode(); > >> + if (status) > >> + return status; > >> + > >> + /* Latch FPGA2SDRAM bridge configuration */ > >> + socfpga_sdram_apply_static_cfg(); > >> + > >> + return 0; > >> > >> } > >> > >> >> socfpga_load() already did step 1 and 2. > >> >> Is there any side effect when fpga2sdram bridge is not used? > >> > > >> > The idea is to keep the FPGA programming code and the code which > >> > controls the bridges separate. The reason for that is that you > > can have > > >> > content in the FPGA which is running completely independent of > > the HPS > > >> > software. You don't always need to enable the bridges. > >> > >> No, it's the other way around here. > >> socfpga_load() runs eventually when command "fpga load" is called. > >> So when I explicitly use "fpga load" command, the old FPGA program is > >> expected to stop running, right? > > > > Right > > > >> And I don't want to enable the bridge here, just to latch the SDRAM > >> configuration. > > > > So what you want to do is "bridge disable ; fpga load ... ; bridge > > enable", > > > isn't that the correct sequence ? I might be missing something > > though, sorry. > > No, you are right. Sorry, I didn't think it through. > > My original thought was, that "fpga load" should not depend on "bridge e/d" > regardless of how fpga2sdram is configured. Now I think the dependency > is a bad idea. Yeah, you should be able to control the bridges between the FPGA and the FPGA loading independently for the particular case where the FPGA runs independently of the HPS. > Sorry for the confusion. Well, I'm glad it got sorted out :)
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 4448250..d0f67f6 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) return status; /* Ensure the FPGA entering user mode */ - return fpgamgr_program_poll_usermode(); + status = fpgamgr_program_poll_usermode(); + if (status) + return status; + + /* Latch FPGA2SDRAM bridge configuration */ + socfpga_sdram_apply_static_cfg(); + + return 0;