All of lore.kernel.org
 help / color / mirror / Atom feed
From: tthayer@altera.com (Thor Thayer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller
Date: Tue, 8 Apr 2014 09:29:50 -0500	[thread overview]
Message-ID: <1396967390.23349.15.camel@dinh-ubuntu> (raw)
In-Reply-To: <20140408133818.GB16054@pengutronix.de>

On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> Hi!
> 
> On Mon, Apr 07, 2014 at 04:54:07PM -0500, tthayer at altera.com wrote:
> > From: Thor Thayer <tthayer@altera.com>
> > 
> > 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 at c0000000 {
> 		ipcore at 0 {
> 			resets = <&sdr 1>;
> 			reset-names = "foo";
> 			resets = <&rst 96>;
> 			reset-names = "bar";
> 			(...)
> 		};
> 
> 		ipcore at 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 at 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 at ffc25000 {
> > +			compatible = "altr,sdr-ctl", "syscon";
> > +			reg = <0xffc25000 0x1000>;
> > +		};
> > +
> >  		rstmgr at ffd05000 {
> >  			compatible = "altr,rst-mgr";
> >  			reg = <0xffd05000 0x1000>;
> 

WARNING: multiple messages have this Message-ID (diff)
From: Thor Thayer <tthayer-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
To: Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	dougthompson-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller
Date: Tue, 8 Apr 2014 09:29:50 -0500	[thread overview]
Message-ID: <1396967390.23349.15.camel@dinh-ubuntu> (raw)
In-Reply-To: <20140408133818.GB16054-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> Hi!
> 
> On Mon, Apr 07, 2014 at 04:54:07PM -0500, tthayer-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org wrote:
> > From: Thor Thayer <tthayer-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
> > 
> > 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>;
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Thor Thayer <tthayer@altera.com>
To: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: <robherring2@gmail.com>, <dougthompson@xmission.com>,
	<grant.likely@linaro.org>, <pawel.moll@arm.com>,
	<mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>,
	<galak@codeaurora.org>, <rob@landley.net>,
	<linux@arm.linux.org.uk>, <dinguyen@altera.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-doc@vger.kernel.org>
Subject: Re: [PATCH 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller
Date: Tue, 8 Apr 2014 09:29:50 -0500	[thread overview]
Message-ID: <1396967390.23349.15.camel@dinh-ubuntu> (raw)
In-Reply-To: <20140408133818.GB16054@pengutronix.de>

On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
> Hi!
> 
> On Mon, Apr 07, 2014 at 04:54:07PM -0500, tthayer@altera.com wrote:
> > From: Thor Thayer <tthayer@altera.com>
> > 
> > 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>;
> 


  reply	other threads:[~2014-04-08 14:29 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1396907649-20212-1-git-send-email-tthayer@altera.com>
2014-04-07 21:54 ` [PATCH 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller tthayer at altera.com
2014-04-07 21:54   ` tthayer
2014-04-07 21:54   ` tthayer
2014-04-08 10:48   ` Mark Rutland
2014-04-08 10:48     ` Mark Rutland
2014-04-08 13:38   ` Steffen Trumtrar
2014-04-08 13:38     ` Steffen Trumtrar
2014-04-08 13:38     ` Steffen Trumtrar
2014-04-08 14:29     ` Thor Thayer [this message]
2014-04-08 14:29       ` Thor Thayer
2014-04-08 14:29       ` Thor Thayer
2014-04-08 14:33       ` Steffen Trumtrar
2014-04-08 14:33         ` Steffen Trumtrar
2014-04-08 14:33         ` Steffen Trumtrar
2014-04-08 16:02         ` delicious quinoa
2014-04-08 16:02           ` delicious quinoa
2014-04-08 18:52           ` Rob Herring
2014-04-08 18:52             ` Rob Herring
2014-04-11 14:21             ` Thor Thayer
2014-04-11 14:21               ` Thor Thayer
2014-04-11 14:21               ` Thor Thayer
2014-04-11 14:43             ` Thor Thayer
2014-04-11 14:43               ` Thor Thayer
2014-04-11 14:49             ` Thor Thayer
2014-04-11 14:49               ` Thor Thayer
2014-04-11 14:49               ` Thor Thayer
2014-07-10 21:02             ` Alan Tull
2014-07-10 21:02               ` Alan Tull
2014-04-07 21:54 ` [PATCH 2/3] dts: socfpga: Add bindings for Altera SoC SDRAM EDAC tthayer at altera.com
2014-04-07 21:54   ` tthayer
2014-04-07 21:54   ` tthayer
2014-04-08 10:51   ` Mark Rutland
2014-04-08 10:51     ` Mark Rutland
     [not found] ` <1396907649-20212-1-git-send-email-tthayer-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
2014-04-07 21:54   ` [PATCH 3/3] edac: altera: Add SDRAM EDAC support for CycloneV/ArriaV tthayer-EIB2kfCEclfQT0dZR+AlfA
2014-04-07 21:54     ` tthayer
     [not found]     ` <1396907649-20212-4-git-send-email-tthayer-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
2014-04-08 10:08       ` Borislav Petkov
2014-04-08 10:08         ` Borislav Petkov
2014-04-08 13:57         ` Thor Thayer
2014-04-08 13:57           ` Thor Thayer
2014-04-08 15:24           ` Borislav Petkov
     [not found]             ` <20140408152406.GI30077-fF5Pk5pvG8Y@public.gmane.org>
2014-04-08 15:40               ` Mark Rutland
2014-04-08 15:40                 ` Mark Rutland
2014-04-08 16:03                 ` Borislav Petkov
     [not found]                   ` <20140408160351.GK30077-fF5Pk5pvG8Y@public.gmane.org>
2014-04-08 16:10                     ` Mark Rutland
2014-04-08 16:10                       ` Mark Rutland
     [not found]                       ` <20140408161054.GA26210-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2014-04-08 16:22                         ` Borislav Petkov
2014-04-08 16:22                           ` Borislav Petkov
     [not found]                           ` <20140408162213.GL30077-fF5Pk5pvG8Y@public.gmane.org>
2014-04-08 21:15                             ` Thor Thayer
2014-04-08 21:15                               ` Thor Thayer
2014-04-08 10:45       ` Mark Rutland
2014-04-08 10:45         ` Mark Rutland
     [not found]         ` <20140408104525.GA11876-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2014-04-08 12:45           ` Steffen Trumtrar
2014-04-08 12:45             ` Steffen Trumtrar
     [not found]             ` <20140408124541.GA16054-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-04-08 14:00               ` Thor Thayer
2014-04-08 14:00                 ` Thor Thayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1396967390.23349.15.camel@dinh-ubuntu \
    --to=tthayer@altera.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.