linux-kernel - Re: [PATCHv5 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 May 2014 16:44:47 +0200
From:	Steffen Trumtrar <s.trumtrar@...gutronix.de>
To:	Alan Tull <delicious.quinoa@...il.com>
Cc:	Thor Thayer <tthayer.linux@...il.com>,
	Thor Thayer <tthayer@...era.com>,
	Rob Herring <robherring2@...il.com>, pawel.moll@....com,
	Mark Rutland <mark.rutland@....com>,
	ijc+devicetree@...lion.org.uk, Kumar Gala <galak@...eaurora.org>,
	Rob Landley <rob@...dley.net>, linux@....linux.org.uk,
	Dinh Nguyen <dinguyen@...era.com>, dougthompson@...ssion.com,
	Grant Likely <grant.likely@...aro.org>,
	Borislav Petkov <bp@...en8.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-edac@...r.kernel.org,
	Alan Tull <atull@...era.com>
Subject: Re: [PATCHv5 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM
 controller

Hi!

On Tue, May 20, 2014 at 09:31:06AM -0500, Alan Tull wrote:
> On Mon, May 19, 2014 at 2:37 PM, Thor Thayer <tthayer.linux@...il.com> wrote:
> 
> >>> >> 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..8f8746b
> >>> >> --- /dev/null
> >>> >> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> >>> >> @@ -0,0 +1,11 @@
> >>> >> +Altera SOCFPGA SDRAM Controller
> >>> >> +
> >>> >> +Required properties:
> >>> >> +- compatible : "altr,sdr-ctl";
> >>> >> +- reg : Should contain 1 register ranges(address and length)
> >>> >> +
> >>> >> +Example:
> >>> >> +     sdrctl@...25000 {
> >>> >> +             compatible = "altr,sdr-ctl";
> >>> >> +             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@...25000 {
> >>> >> +                     compatible = "altr,sdr-ctl", "syscon";
> >>> >                                                    ^^^^^^^^^^
> >>> >
> >>> > Get rid of that, too, please.
> >>>
> >>> Hi Steffan,
> >>>
> >>> I believe I need to keep the "syscon". The same register (ctrlcfg)
> >>> that has the ECC enable bitfield also includes the DRAM configuration
> >>> bitfields that other drivers will want to access (specifically the
> >>> FPGA bridge needs this information). Since this register will be
> >>> shared between drivers,  syscon seems like the best solution.
> >>>
> >>
> >> Hm, from looking at the documentation of the ctrlcfg I can't really
> >> understand which bits you would need for the FPGA brigde and why.
> 
> Hi Steffen,
> 
> Offset 0x80 in the sdr-ctl is the "fpgaportrst" register.  14 bits
> wide, defaults to 0.  When appropriate bits set to 1 in that reg, it
> allows an FPGA port to come out of reset (enables that port).  Has no
> other effect on SDRAM configuration.
> 
> >> That all sounds like stuff you would want to set for the specific
> >> RAM you are dealing with on a specific board.
> >> What bridge are you talking about? The SDRAM bridge?
> 
> Yes, the port allows the FPGA a direct path to the SDRAM.  This one
> register the only register in the sdr that the bridge driver needs.
> 

So, what I suggested down ...

> >>
> >> I can see the problem with the ECC enable, though.
> >>
> >> Regards,
> >> Steffen
> >>
> >
> >>> >                 sdrctl@...25000 {
> >>> >                         compatible = "altr,sdr-ctl";
> >>> >                         reg = <0xffc25000 0x1000>;
> >>> >                         ranges;
> >>> >
> >>> >                         edac@...2502c {
> >>> >                                 compatible = "altr,sdram-edac";
> >>> >                                 reg = <0xffc2502c 0x50>;
> >>> >                                 interrupts = <0 39 4>;
> >>> >                         };
> >>> >                 };
> >>> >
> >>> > Then we can later add:
> >>> >
> >>> >                         sdr-ports: ports@...2507c {
> >>> >                                 #reset-cells = <1>;
> >>> >                                 compatible = "altr,sdr-ports";
> >>> >                                 reg = <0xffc2507c 0x10>;
> >>> >                                 clocks = <&ddr_dqs_clk>;
> >>> >                                 ...
> >>> >                         };
>

... here should work. No?! Just a simple driver that registers with the
reset-framework. I would add 0x7c to that driver and than that driver could
"configure" the port and let it out of reset.

I have done the same thing for the other 3 bridges, but am not finished yet.
Especially the GPV-stuff needs to at least be able to be added later if not now.

Regard,
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 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/