All of lore.kernel.org
 help / color / mirror / Atom feed
From: dinguyen@opensource.altera.com (Dinh Nguyen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support
Date: Fri, 7 Nov 2014 10:31:20 -0600	[thread overview]
Message-ID: <545CF3D8.1020500@opensource.altera.com> (raw)
In-Reply-To: <20141106163134.GF4318@pd.tnic>

Hi Boris,

On 11/06/2014 10:31 AM, Borislav Petkov wrote:
> Hi Thor,
> 
> On Tue, Nov 04, 2014 at 04:57:44PM -0600, Thor Thayer wrote:
>> We want to at least separate L2/OCRAM ECC from the SDRAM ECC because
>> 1) the SDRAM preparation can take almost 2 seconds on boot and some
>> customers need a faster boot time.
>> 2) the SDRAM has an ECC initialization dependency on the preloader which is
>> outside the kernel. It is desirable to be able to turn the SDRAM on & off
>> separately.
> 
> Well, now that I asked and you gave valid reasons for the split,
> you should keep them split the way they are. But please do add that
> explanation to the commit message so that it is clear to people why
> there is a split.
> 
>> You bring up a good point about the L2 and OCRAM being combined though.
>>
>> If we do want granular control, maybe I should use a submenu? Or isn't that
>> desirable either?
> 
> Well, what do you think would be easier/faster for a user configuring? A
> separate menu where you have to do a couple of key presses just to enter
> it or simply a subtree in Kconfig with all the options together. I think
> the "depends" gives you that already...
> 
> Ok, once you've worked in the suggested changes, you're good to go,
> at least for the EDAC bits. Let me know how you want to handle this,
> whether I should pick up the whole thing or I should ack the EDAC parts.
> This patchset should go together, in any case, and so I don't care
> whoever picks it up.
> 

If it's okay, can you please pick up this series, once everything is
cleaned up? I just checked to make sure that there aren't any merge
conflicts in the DTS files in this series against DTS patches that I
have queue up for 3.19, and there aren't.

Thanks,
Dinh

WARNING: multiple messages have this Message-ID (diff)
From: Dinh Nguyen <dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
To: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	Thor Thayer
	<tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Cc: dougthompson-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
	m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+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,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	tthayer.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCHv3 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support
Date: Fri, 7 Nov 2014 10:31:20 -0600	[thread overview]
Message-ID: <545CF3D8.1020500@opensource.altera.com> (raw)
In-Reply-To: <20141106163134.GF4318-fF5Pk5pvG8Y@public.gmane.org>

Hi Boris,

On 11/06/2014 10:31 AM, Borislav Petkov wrote:
> Hi Thor,
> 
> On Tue, Nov 04, 2014 at 04:57:44PM -0600, Thor Thayer wrote:
>> We want to at least separate L2/OCRAM ECC from the SDRAM ECC because
>> 1) the SDRAM preparation can take almost 2 seconds on boot and some
>> customers need a faster boot time.
>> 2) the SDRAM has an ECC initialization dependency on the preloader which is
>> outside the kernel. It is desirable to be able to turn the SDRAM on & off
>> separately.
> 
> Well, now that I asked and you gave valid reasons for the split,
> you should keep them split the way they are. But please do add that
> explanation to the commit message so that it is clear to people why
> there is a split.
> 
>> You bring up a good point about the L2 and OCRAM being combined though.
>>
>> If we do want granular control, maybe I should use a submenu? Or isn't that
>> desirable either?
> 
> Well, what do you think would be easier/faster for a user configuring? A
> separate menu where you have to do a couple of key presses just to enter
> it or simply a subtree in Kconfig with all the options together. I think
> the "depends" gives you that already...
> 
> Ok, once you've worked in the suggested changes, you're good to go,
> at least for the EDAC bits. Let me know how you want to handle this,
> whether I should pick up the whole thing or I should ack the EDAC parts.
> This patchset should go together, in any case, and so I don't care
> whoever picks it up.
> 

If it's okay, can you please pick up this series, once everything is
cleaned up? I just checked to make sure that there aren't any merge
conflicts in the DTS files in this series against DTS patches that I
have queue up for 3.19, and there aren't.

Thanks,
Dinh

--
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: Dinh Nguyen <dinguyen@opensource.altera.com>
To: Borislav Petkov <bp@alien8.de>,
	Thor Thayer <tthayer@opensource.altera.com>
Cc: <dougthompson@xmission.com>, <m.chehab@samsung.com>,
	<robh+dt@kernel.org>, <pawel.moll@arm.com>,
	<mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>,
	<galak@codeaurora.org>, <linux@arm.linux.org.uk>,
	<grant.likely@linaro.org>, <devicetree@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-edac@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <tthayer.linux@gmail.com>
Subject: Re: [PATCHv3 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support
Date: Fri, 7 Nov 2014 10:31:20 -0600	[thread overview]
Message-ID: <545CF3D8.1020500@opensource.altera.com> (raw)
In-Reply-To: <20141106163134.GF4318@pd.tnic>

Hi Boris,

On 11/06/2014 10:31 AM, Borislav Petkov wrote:
> Hi Thor,
> 
> On Tue, Nov 04, 2014 at 04:57:44PM -0600, Thor Thayer wrote:
>> We want to at least separate L2/OCRAM ECC from the SDRAM ECC because
>> 1) the SDRAM preparation can take almost 2 seconds on boot and some
>> customers need a faster boot time.
>> 2) the SDRAM has an ECC initialization dependency on the preloader which is
>> outside the kernel. It is desirable to be able to turn the SDRAM on & off
>> separately.
> 
> Well, now that I asked and you gave valid reasons for the split,
> you should keep them split the way they are. But please do add that
> explanation to the commit message so that it is clear to people why
> there is a split.
> 
>> You bring up a good point about the L2 and OCRAM being combined though.
>>
>> If we do want granular control, maybe I should use a submenu? Or isn't that
>> desirable either?
> 
> Well, what do you think would be easier/faster for a user configuring? A
> separate menu where you have to do a couple of key presses just to enter
> it or simply a subtree in Kconfig with all the options together. I think
> the "depends" gives you that already...
> 
> Ok, once you've worked in the suggested changes, you're good to go,
> at least for the EDAC bits. Let me know how you want to handle this,
> whether I should pick up the whole thing or I should ack the EDAC parts.
> This patchset should go together, in any case, and so I don't care
> whoever picks it up.
> 

If it's okay, can you please pick up this series, once everything is
cleaned up? I just checked to make sure that there aren't any merge
conflicts in the DTS files in this series against DTS patches that I
have queue up for 3.19, and there aren't.

Thanks,
Dinh


  reply	other threads:[~2014-11-07 16:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30 15:32 [PATCHv3 0/5] Add Altera peripheral memories to EDAC framework tthayer at opensource.altera.com
2014-10-30 15:32 ` tthayer
2014-10-30 15:32 ` tthayer
2014-10-30 15:32 ` [PATCHv3 1/5] arm: socfpga: Enable L2 Cache ECC on startup tthayer at opensource.altera.com
2014-10-30 15:32   ` tthayer
2014-10-30 15:32   ` tthayer
2014-10-30 15:32 ` [PATCHv3 2/5] arm: socfpga: Enable OCRAM " tthayer at opensource.altera.com
2014-10-30 15:32   ` tthayer
2014-10-30 15:32   ` tthayer
2014-10-30 15:32 ` [PATCHv3 3/5] edac: altera: Remove SDRAM module compile tthayer at opensource.altera.com
2014-10-30 15:32   ` tthayer
2014-10-30 15:32   ` tthayer
2014-10-30 15:32 ` [PATCHv3 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support tthayer at opensource.altera.com
2014-10-30 15:32   ` tthayer
2014-10-30 15:32   ` tthayer
2014-11-04 15:12   ` Borislav Petkov
2014-11-04 15:12     ` Borislav Petkov
2014-11-04 22:57     ` Thor Thayer
2014-11-04 22:57       ` Thor Thayer
2014-11-04 22:57       ` Thor Thayer
2014-11-06 16:31       ` Borislav Petkov
2014-11-06 16:31         ` Borislav Petkov
2014-11-07 16:31         ` Dinh Nguyen [this message]
2014-11-07 16:31           ` Dinh Nguyen
2014-11-07 16:31           ` Dinh Nguyen
2014-11-07 16:51           ` Borislav Petkov
2014-11-07 16:51             ` Borislav Petkov
2014-11-07 16:51             ` Borislav Petkov
2014-10-30 15:32 ` [PATCHv3 5/5] arm: dts: Add Altera L2 Cache and OCRAM EDAC tthayer at opensource.altera.com
2014-10-30 15:32   ` tthayer
2014-10-30 15:32   ` tthayer

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=545CF3D8.1020500@opensource.altera.com \
    --to=dinguyen@opensource.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.