From: Thor Thayer <[email protected]>
Addition of the Altera SDRAM controller bindings and device
tree changes to the Altera SoC project.
Signed-off-by: Thor Thayer <[email protected]>
To: Rob Herring <[email protected]>
To: Pawel Moll <[email protected]>
To: Mark Rutland <[email protected]>
To: Ian Campbell <[email protected]>
To: Kumar Gala <[email protected]>
To: Rob Landley <[email protected]>
To: Russell King <[email protected]>
To: Dinh Nguyen <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
.../bindings/arm/altera/socfpga-sdram.txt | 14 ++++++++++++++
arch/arm/boot/dts/socfpga.dtsi | 5 +++++
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
new file mode 100644
index 0000000..525cb76
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
@@ -0,0 +1,14 @@
+Altera SOCFPGA SDRAM Controller
+
+Required properties:
+- compatible : "altr,sdr-ctl", "syscon";
+ Note that syscon is invoked for this device to support the FPGA
+ bridge driver, EDAC driver and other devices that share the
+ registers.
+- reg : Should contain 1 register ranges(address and length)
+
+Example:
+ sdrctl@ffc25000 {
+ compatible = "altr,sdr-ctl", "syscon";
+ reg = <0xffc25000 0x1000>;
+ };
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index df43702..6ce912e 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -676,6 +676,11 @@
clocks = <&l4_sp_clk>;
};
+ sdrctl@ffc25000 {
+ compatible = "altr,sdr-ctl", "syscon";
+ reg = <0xffc25000 0x1000>;
+ };
+
rstmgr@ffd05000 {
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
--
1.7.9.5
On Mon, Apr 07, 2014 at 10:54:07PM +0100, [email protected] wrote:
> From: Thor Thayer <[email protected]>
>
> Addition of the Altera SDRAM controller bindings and device
> tree changes to the Altera SoC project.
>
> Signed-off-by: Thor Thayer <[email protected]>
> To: Rob Herring <[email protected]>
> To: Pawel Moll <[email protected]>
> To: Mark Rutland <[email protected]>
> To: Ian Campbell <[email protected]>
> To: Kumar Gala <[email protected]>
> To: Rob Landley <[email protected]>
> To: Russell King <[email protected]>
> To: Dinh Nguyen <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> .../bindings/arm/altera/socfpga-sdram.txt | 14 ++++++++++++++
> arch/arm/boot/dts/socfpga.dtsi | 5 +++++
> 2 files changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> new file mode 100644
> index 0000000..525cb76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> @@ -0,0 +1,14 @@
> +Altera SOCFPGA SDRAM Controller
> +
> +Required properties:
> +- compatible : "altr,sdr-ctl", "syscon";
> + Note that syscon is invoked for this device to support the FPGA
> + bridge driver, EDAC driver and other devices that share the
> + registers.
Is the SDRAM controller really a bag of bits that necessitates the use
of syscon? Or are the "other devices" just sub-components of the SDRAM
controller?
If they are, just describe the SDRAM controller and related interrupts
as a single node, and only use the EDAC portion in the Linux driver.
Cheers,
Mark.
> +- reg : Should contain 1 register ranges(address and length)
> +
> +Example:
> + sdrctl@ffc25000 {
> + compatible = "altr,sdr-ctl", "syscon";
> + reg = <0xffc25000 0x1000>;
> + };
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index df43702..6ce912e 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -676,6 +676,11 @@
> clocks = <&l4_sp_clk>;
> };
>
> + sdrctl@ffc25000 {
> + compatible = "altr,sdr-ctl", "syscon";
> + reg = <0xffc25000 0x1000>;
> + };
> +
> rstmgr@ffd05000 {
> compatible = "altr,rst-mgr";
> reg = <0xffd05000 0x1000>;
> --
> 1.7.9.5
>
>
Hi!
On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
> From: Thor Thayer <[email protected]>
>
> Addition of the Altera SDRAM controller bindings and device
> tree changes to the Altera SoC project.
>
> Signed-off-by: Thor Thayer <[email protected]>
> To: Rob Herring <[email protected]>
> To: Pawel Moll <[email protected]>
> To: Mark Rutland <[email protected]>
> To: Ian Campbell <[email protected]>
> To: Kumar Gala <[email protected]>
> To: Rob Landley <[email protected]>
> To: Russell King <[email protected]>
> To: Dinh Nguyen <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> .../bindings/arm/altera/socfpga-sdram.txt | 14 ++++++++++++++
> arch/arm/boot/dts/socfpga.dtsi | 5 +++++
> 2 files changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> new file mode 100644
> index 0000000..525cb76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> @@ -0,0 +1,14 @@
> +Altera SOCFPGA SDRAM Controller
> +
> +Required properties:
> +- compatible : "altr,sdr-ctl", "syscon";
> + Note that syscon is invoked for this device to support the FPGA
> + bridge driver, EDAC driver and other devices that share the
> + registers.
> +- reg : Should contain 1 register ranges(address and length)
I haven't really thought this through, but why would the FPGA bridge driver
access the sdram controller? For releasing the resets in fpgaportrst ? Or is
there more?
Wouldn't it be more appropriate to represent those bits as a reset-controller to
some hypothetical IP core driver?
Then you could have something like
hps2fpga@c0000000 {
ipcore@0 {
resets = <&sdr 1>;
reset-names = "foo";
resets = <&rst 96>;
reset-names = "bar";
(...)
};
ipcore@1000 {
resets = <&rst 96>;
reset-names = "baz";
(...)
};
};
And you would always have the correct bridges released out of reset for your
IP core. Does the FPGA bridge driver do more? I think that is basically it.
Where we maybe could run into problems though is the early_init stuff.
I think syscon is nice for some things, but we should try not to overuse it.
Regards,
Steffen
> +Example:
> + sdrctl@ffc25000 {
> + compatible = "altr,sdr-ctl", "syscon";
> + reg = <0xffc25000 0x1000>;
> + };
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index df43702..6ce912e 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -676,6 +676,11 @@
> clocks = <&l4_sp_clk>;
> };
>
> + sdrctl@ffc25000 {
> + compatible = "altr,sdr-ctl", "syscon";
> + reg = <0xffc25000 0x1000>;
> + };
> +
> rstmgr@ffd05000 {
> compatible = "altr,rst-mgr";
> reg = <0xffd05000 0x1000>;
--
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 Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> Hi!
>
> On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
> > From: Thor Thayer <[email protected]>
> >
> > Addition of the Altera SDRAM controller bindings and device
> > tree changes to the Altera SoC project.
> >
[snip]
> > +
> > +Required properties:
> > +- compatible : "altr,sdr-ctl", "syscon";
> > + Note that syscon is invoked for this device to support the FPGA
> > + bridge driver, EDAC driver and other devices that share the
> > + registers.
> > +- reg : Should contain 1 register ranges(address and length)
>
> I haven't really thought this through, but why would the FPGA bridge driver
> access the sdram controller? For releasing the resets in fpgaportrst ? Or is
> there more?
Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
path. Our SDRAM controller allows FPGA master access to the SDRAM.
> Wouldn't it be more appropriate to represent those bits as a reset-controller to
> some hypothetical IP core driver?
> Then you could have something like
>
> hps2fpga@c0000000 {
> ipcore@0 {
> resets = <&sdr 1>;
> reset-names = "foo";
> resets = <&rst 96>;
> reset-names = "bar";
> (...)
> };
>
> ipcore@1000 {
> resets = <&rst 96>;
> reset-names = "baz";
> (...)
> };
> };
>
> And you would always have the correct bridges released out of reset for your
> IP core. Does the FPGA bridge driver do more? I think that is basically it.
> Where we maybe could run into problems though is the early_init stuff.
>
> I think syscon is nice for some things, but we should try not to overuse it.
Understood. In this case, syscon seems to be appropriate.
>
> Regards,
> Steffen
>
> > +Example:
> > + sdrctl@ffc25000 {
> > + compatible = "altr,sdr-ctl", "syscon";
> > + reg = <0xffc25000 0x1000>;
> > + };
> > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> > index df43702..6ce912e 100644
> > --- a/arch/arm/boot/dts/socfpga.dtsi
> > +++ b/arch/arm/boot/dts/socfpga.dtsi
> > @@ -676,6 +676,11 @@
> > clocks = <&l4_sp_clk>;
> > };
> >
> > + sdrctl@ffc25000 {
> > + compatible = "altr,sdr-ctl", "syscon";
> > + reg = <0xffc25000 0x1000>;
> > + };
> > +
> > rstmgr@ffd05000 {
> > compatible = "altr,rst-mgr";
> > reg = <0xffd05000 0x1000>;
>
On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> > Hi!
> >
> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
> > > From: Thor Thayer <[email protected]>
> > >
> > > Addition of the Altera SDRAM controller bindings and device
> > > tree changes to the Altera SoC project.
> > >
> [snip]
> > > +
> > > +Required properties:
> > > +- compatible : "altr,sdr-ctl", "syscon";
> > > + Note that syscon is invoked for this device to support the FPGA
> > > + bridge driver, EDAC driver and other devices that share the
> > > + registers.
> > > +- reg : Should contain 1 register ranges(address and length)
> >
> > I haven't really thought this through, but why would the FPGA bridge driver
> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
> > there more?
>
> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
> path. Our SDRAM controller allows FPGA master access to the SDRAM.
>
Yes. But what you have to do to enable the path is let the FPGA port you use
out of reset. And that is it as far as I can see. The rest happens in the
bitstream. Or is there more to enable the path?
The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
please elaborate.
> > Wouldn't it be more appropriate to represent those bits as a reset-controller to
> > some hypothetical IP core driver?
> > Then you could have something like
> >
> > hps2fpga@c0000000 {
> > ipcore@0 {
> > resets = <&sdr 1>;
> > reset-names = "foo";
> > resets = <&rst 96>;
> > reset-names = "bar";
> > (...)
> > };
> >
> > ipcore@1000 {
> > resets = <&rst 96>;
> > reset-names = "baz";
> > (...)
> > };
> > };
> >
> > And you would always have the correct bridges released out of reset for your
> > IP core. Does the FPGA bridge driver do more? I think that is basically it.
> > Where we maybe could run into problems though is the early_init stuff.
> >
> > I think syscon is nice for some things, but we should try not to overuse it.
>
> Understood. In this case, syscon seems to be appropriate.
I'm not convinced yet.
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 Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
<[email protected]> wrote:
> On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
>> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
>> > Hi!
>> >
>> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
>> > > From: Thor Thayer <[email protected]>
>> > >
>> > > Addition of the Altera SDRAM controller bindings and device
>> > > tree changes to the Altera SoC project.
>> > >
>> [snip]
>> > > +
>> > > +Required properties:
>> > > +- compatible : "altr,sdr-ctl", "syscon";
>> > > + Note that syscon is invoked for this device to support the FPGA
>> > > + bridge driver, EDAC driver and other devices that share the
>> > > + registers.
>> > > +- reg : Should contain 1 register ranges(address and length)
>> >
>> > I haven't really thought this through, but why would the FPGA bridge driver
>> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
>> > there more?
>>
>> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
>> path. Our SDRAM controller allows FPGA master access to the SDRAM.
>>
>
> Yes. But what you have to do to enable the path is let the FPGA port you use
> out of reset. And that is it as far as I can see. The rest happens in the
> bitstream. Or is there more to enable the path?
> The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
> please elaborate.
Hi Steffen,
The sdram controller is used by two drivers. That's why we want to
specify "syscon" here. The other driver is the FPGA bridge driver.
Its functionality is very separate from what this driver is doing (we
are not enabling the bridge in this driver; we are enabling the
monitoring and resetting the interrupt bit of the EDAC). We wanted to
specify "syscon" her so that we don't have to have to change it for
the other driver.
Alan Tull
On Tue, Apr 8, 2014 at 11:02 AM, delicious quinoa
<[email protected]> wrote:
> On Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
> <[email protected]> wrote:
>> On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
>>> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
>>> > Hi!
>>> >
>>> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
>>> > > From: Thor Thayer <[email protected]>
>>> > >
>>> > > Addition of the Altera SDRAM controller bindings and device
>>> > > tree changes to the Altera SoC project.
>>> > >
>>> [snip]
>>> > > +
>>> > > +Required properties:
>>> > > +- compatible : "altr,sdr-ctl", "syscon";
>>> > > + Note that syscon is invoked for this device to support the FPGA
>>> > > + bridge driver, EDAC driver and other devices that share the
>>> > > + registers.
>>> > > +- reg : Should contain 1 register ranges(address and length)
>>> >
>>> > I haven't really thought this through, but why would the FPGA bridge driver
>>> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
>>> > there more?
>>>
>>> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
>>> path. Our SDRAM controller allows FPGA master access to the SDRAM.
>>>
>>
>> Yes. But what you have to do to enable the path is let the FPGA port you use
>> out of reset. And that is it as far as I can see. The rest happens in the
>> bitstream. Or is there more to enable the path?
>> The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
>> please elaborate.
>
> Hi Steffen,
>
> The sdram controller is used by two drivers. That's why we want to
> specify "syscon" here. The other driver is the FPGA bridge driver.
> Its functionality is very separate from what this driver is doing (we
> are not enabling the bridge in this driver; we are enabling the
> monitoring and resetting the interrupt bit of the EDAC). We wanted to
> specify "syscon" her so that we don't have to have to change it for
> the other driver.
But are there actually overlapping registers which are accessed by
both drivers and need the protection of regmap?
Perhaps MFD is more appropriate than syscon?
Rob
On Tue, 2014-04-08 at 13:52 -0500, Rob Herring wrote:
> On Tue, Apr 8, 2014 at 11:02 AM, delicious quinoa
> <[email protected]> wrote:
> > On Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
> > <[email protected]> wrote:
> >> On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
> >>> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> >>> > Hi!
> >>> >
> >>> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
> >>> > > From: Thor Thayer <[email protected]>
> >>> > >
> >>> > > Addition of the Altera SDRAM controller bindings and device
> >>> > > tree changes to the Altera SoC project.
> >>> > >
> >>> [snip]
> >>> > > +
> >>> > > +Required properties:
> >>> > > +- compatible : "altr,sdr-ctl", "syscon";
> >>> > > + Note that syscon is invoked for this device to support the FPGA
> >>> > > + bridge driver, EDAC driver and other devices that share the
> >>> > > + registers.
> >>> > > +- reg : Should contain 1 register ranges(address and length)
> >>> >
> >>> > I haven't really thought this through, but why would the FPGA bridge driver
> >>> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
> >>> > there more?
> >>>
> >>> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
> >>> path. Our SDRAM controller allows FPGA master access to the SDRAM.
> >>>
> >>
> >> Yes. But what you have to do to enable the path is let the FPGA port you use
> >> out of reset. And that is it as far as I can see. The rest happens in the
> >> bitstream. Or is there more to enable the path?
> >> The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
> >> please elaborate.
> >
> > Hi Steffen,
> >
> > The sdram controller is used by two drivers. That's why we want to
> > specify "syscon" here. The other driver is the FPGA bridge driver.
> > Its functionality is very separate from what this driver is doing (we
> > are not enabling the bridge in this driver; we are enabling the
> > monitoring and resetting the interrupt bit of the EDAC). We wanted to
> > specify "syscon" her so that we don't have to have to change it for
> > the other driver.
>
> But are there actually overlapping registers which are accessed by
> both drivers and need the protection of regmap?
>
> Perhaps MFD is more appropriate than syscon?
Hi Rob,
We are accessing bits in the SDRAM Controller's Control register which
has other bits that configure the SDRAM controller. Since this main
control register may be accessed by other drivers (more likely for
reading the current SDRAM configuration setup than for writing), the
syscon still seems like an appropriate use.
Thor
>
> Rob
On Tue, 2014-04-08 at 13:52 -0500, Rob Herring wrote:
> On Tue, Apr 8, 2014 at 11:02 AM, delicious quinoa
> <[email protected]> wrote:
> > On Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
> > <[email protected]> wrote:
> >> On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
> >>> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> >>> > Hi!
> >>> >
> >>> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
> >>> > > From: Thor Thayer <[email protected]>
> >>> > >
> >>> > > Addition of the Altera SDRAM controller bindings and device
> >>> > > tree changes to the Altera SoC project.
> >>> > >
> >>> [snip]
> >>> > > +
> >>> > > +Required properties:
> >>> > > +- compatible : "altr,sdr-ctl", "syscon";
> >>> > > + Note that syscon is invoked for this device to support the FPGA
> >>> > > + bridge driver, EDAC driver and other devices that share the
> >>> > > + registers.
> >>> > > +- reg : Should contain 1 register ranges(address and length)
> >>> >
> >>> > I haven't really thought this through, but why would the FPGA bridge driver
> >>> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
> >>> > there more?
> >>>
> >>> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
> >>> path. Our SDRAM controller allows FPGA master access to the SDRAM.
> >>>
> >>
> >> Yes. But what you have to do to enable the path is let the FPGA port you use
> >> out of reset. And that is it as far as I can see. The rest happens in the
> >> bitstream. Or is there more to enable the path?
> >> The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
> >> please elaborate.
> >
> > Hi Steffen,
> >
> > The sdram controller is used by two drivers. That's why we want to
> > specify "syscon" here. The other driver is the FPGA bridge driver.
> > Its functionality is very separate from what this driver is doing (we
> > are not enabling the bridge in this driver; we are enabling the
> > monitoring and resetting the interrupt bit of the EDAC). We wanted to
> > specify "syscon" her so that we don't have to have to change it for
> > the other driver.
>
> But are there actually overlapping registers which are accessed by
> both drivers and need the protection of regmap?
>
> Perhaps MFD is more appropriate than syscon?
Hi Rob,
We are accessing bits in the SDRAM Controller's Control register which
has other bits that configure the SDRAM controller. Since this main
control register may be accessed by other drivers (more likely for
reading the current SDRAM configuration setup than for writing), the
syscon still seems like an appropriate use.
Thor
>
> Rob
On Tue, 2014-04-08 at 13:52 -0500, Rob Herring wrote:
> On Tue, Apr 8, 2014 at 11:02 AM, delicious quinoa
> <[email protected]> wrote:
> > On Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
> > <[email protected]> wrote:
> >> On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
> >>> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> >>> > Hi!
> >>> >
> >>> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
> >>> > > From: Thor Thayer <[email protected]>
> >>> > >
> >>> > > Addition of the Altera SDRAM controller bindings and device
> >>> > > tree changes to the Altera SoC project.
> >>> > >
> >>> [snip]
> >>> > > +
> >>> > > +Required properties:
> >>> > > +- compatible : "altr,sdr-ctl", "syscon";
> >>> > > + Note that syscon is invoked for this device to support the FPGA
> >>> > > + bridge driver, EDAC driver and other devices that share the
> >>> > > + registers.
> >>> > > +- reg : Should contain 1 register ranges(address and length)
> >>> >
> >>> > I haven't really thought this through, but why would the FPGA bridge driver
> >>> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
> >>> > there more?
> >>>
> >>> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
> >>> path. Our SDRAM controller allows FPGA master access to the SDRAM.
> >>>
> >>
> >> Yes. But what you have to do to enable the path is let the FPGA port you use
> >> out of reset. And that is it as far as I can see. The rest happens in the
> >> bitstream. Or is there more to enable the path?
> >> The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
> >> please elaborate.
> >
> > Hi Steffen,
> >
> > The sdram controller is used by two drivers. That's why we want to
> > specify "syscon" here. The other driver is the FPGA bridge driver.
> > Its functionality is very separate from what this driver is doing (we
> > are not enabling the bridge in this driver; we are enabling the
> > monitoring and resetting the interrupt bit of the EDAC). We wanted to
> > specify "syscon" her so that we don't have to have to change it for
> > the other driver.
>
> But are there actually overlapping registers which are accessed by
> both drivers and need the protection of regmap?
>
> Perhaps MFD is more appropriate than syscon?
Hi Rob,
We are accessing bits in the SDRAM Controller's Configuration register which
has other bits that configure the SDRAM controller. Since this main
configuration register may be accessed by other drivers (more likely for
reading the current SDRAM configuration setup than for writing), the
syscon still seems like an appropriate use.
Thor
>
> Rob
On Tue, Apr 8, 2014 at 1:52 PM, Rob Herring <[email protected]> wrote:
> On Tue, Apr 8, 2014 at 11:02 AM, delicious quinoa
> <[email protected]> wrote:
>> On Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
>> <[email protected]> wrote:
>>> On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
>>>> On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
>>>> > Hi!
>>>> >
>>>> > On Mon, Apr 07, 2014 at 04:54:07PM -0500, [email protected] wrote:
>>>> > > From: Thor Thayer <[email protected]>
>>>> > >
>>>> > > Addition of the Altera SDRAM controller bindings and device
>>>> > > tree changes to the Altera SoC project.
>>>> > >
>>>> [snip]
>>>> > > +
>>>> > > +Required properties:
>>>> > > +- compatible : "altr,sdr-ctl", "syscon";
>>>> > > + Note that syscon is invoked for this device to support the FPGA
>>>> > > + bridge driver, EDAC driver and other devices that share the
>>>> > > + registers.
>>>> > > +- reg : Should contain 1 register ranges(address and length)
>>>> >
>>>> > I haven't really thought this through, but why would the FPGA bridge driver
>>>> > access the sdram controller? For releasing the resets in fpgaportrst ? Or is
>>>> > there more?
>>>>
>>>> Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
>>>> path. Our SDRAM controller allows FPGA master access to the SDRAM.
>>>>
>>>
>>> Yes. But what you have to do to enable the path is let the FPGA port you use
>>> out of reset. And that is it as far as I can see. The rest happens in the
>>> bitstream. Or is there more to enable the path?
>>> The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss something
>>> please elaborate.
>>
>> Hi Steffen,
>>
>> The sdram controller is used by two drivers. That's why we want to
>> specify "syscon" here. The other driver is the FPGA bridge driver.
>> Its functionality is very separate from what this driver is doing (we
>> are not enabling the bridge in this driver; we are enabling the
>> monitoring and resetting the interrupt bit of the EDAC). We wanted to
>> specify "syscon" her so that we don't have to have to change it for
>> the other driver.
>
> But are there actually overlapping registers which are accessed by
> both drivers and need the protection of regmap?
No overlapping registers here. Just various registers that are used
by: edac driver, fpga bridge, low power modes. So no special
protection needed.
>
> Perhaps MFD is more appropriate than syscon?
>
> Rob
A syscon will do fine here. If we did a MFD, all it would be doing
would be providing register access for this range of registers to a
few drivers, so syscon does that without any trouble.
Alan Tull
aka
delicious quinoa