From: bp@alien8.de (Borislav Petkov)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] edac: add support for ARM PL310 L2 cache parity
Date: Wed, 9 Apr 2014 17:19:32 +0200 [thread overview]
Message-ID: <20140409151932.GK6529@pd.tnic> (raw)
In-Reply-To: <CAL_Jsq+gszc+R_BrLtHKEBGYd=3T+sE1d+-HoF9aYZt6C2k5-g@mail.gmail.com>
On Wed, Apr 09, 2014 at 08:18:28AM -0500, Rob Herring wrote:
> I don't think so, the PL310 is present on lots of ARM chips besides
> Xilinx. I don't know how many support parity as that is optional. In
> fact the highbank_l2_edac.c is for the PL310 as well, but the
> registers it uses is all custom logic added for ECC and there is no
> part of the PL310 h/w used by the driver.
Oh ok, so highbank_l2 and PL310 could theoretically be merged together
in one compilation unit, even if they don't really share code at all...
> If there is lots duplication, then that's a sign the framework needs
> to handle more of the boilerplate pieces. There could be a "simple"
> driver/library for devices which are no more than some registers, an
> interrupt handler and static information about the type of EDAC
> device.
Yeah, it's not that - I'm just getting worried that I'm receiving an
EDAC driver for each piece of silicon out there and would like to still
keep drivers/edac/ sane and be able to control that wild growth.
I'm just thinking out loud here, bear with me pls:
Frankly, having a single compilation unit contain similar silicon
functionality could be a good way to put a hold on the growth but the
disadvantage of this is fatter drivers. Which wouldn't matter all too
much but after a certain level of fat, they might need splitting.
And the highbank version is nothing but the big probe routine and a
small irq handler.
And the PL310 is similar but also with a poller.
I guess, if they don't share functionality at all, putting them together
might not be worth it. Hohummm.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Rob Herring <robherring2@gmail.com>
Cc: Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@xilinx.com>,
Doug Thompson <dougthompson@xmission.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-edac@vger.kernel.org,
Michal Simek <michal.simek@xilinx.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>, Rob Landley <rob@landley.net>,
kpc528@gmail.com, kalluripunnaiahchoudary@gmail.com,
punnaia@xilinx.com
Subject: Re: [RFC PATCH] edac: add support for ARM PL310 L2 cache parity
Date: Wed, 9 Apr 2014 17:19:32 +0200 [thread overview]
Message-ID: <20140409151932.GK6529@pd.tnic> (raw)
In-Reply-To: <CAL_Jsq+gszc+R_BrLtHKEBGYd=3T+sE1d+-HoF9aYZt6C2k5-g@mail.gmail.com>
On Wed, Apr 09, 2014 at 08:18:28AM -0500, Rob Herring wrote:
> I don't think so, the PL310 is present on lots of ARM chips besides
> Xilinx. I don't know how many support parity as that is optional. In
> fact the highbank_l2_edac.c is for the PL310 as well, but the
> registers it uses is all custom logic added for ECC and there is no
> part of the PL310 h/w used by the driver.
Oh ok, so highbank_l2 and PL310 could theoretically be merged together
in one compilation unit, even if they don't really share code at all...
> If there is lots duplication, then that's a sign the framework needs
> to handle more of the boilerplate pieces. There could be a "simple"
> driver/library for devices which are no more than some registers, an
> interrupt handler and static information about the type of EDAC
> device.
Yeah, it's not that - I'm just getting worried that I'm receiving an
EDAC driver for each piece of silicon out there and would like to still
keep drivers/edac/ sane and be able to control that wild growth.
I'm just thinking out loud here, bear with me pls:
Frankly, having a single compilation unit contain similar silicon
functionality could be a good way to put a hold on the growth but the
disadvantage of this is fatter drivers. Which wouldn't matter all too
much but after a certain level of fat, they might need splitting.
And the highbank version is nothing but the big probe routine and a
small irq handler.
And the PL310 is similar but also with a poller.
I guess, if they don't share functionality at all, putting them together
might not be worth it. Hohummm.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-04-09 15:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1393770760-32550-1-git-send-email-punnaia@xilinx.com>
2014-03-02 14:32 ` [RFC PATCH] edac: add support for ARM PL310 L2 cache parity Punnaiah Choudary Kalluri
2014-03-02 14:32 ` Punnaiah Choudary Kalluri
2014-03-02 14:32 ` Punnaiah Choudary Kalluri
2014-04-03 15:02 ` Michal Simek
2014-04-03 15:02 ` Michal Simek
2014-04-03 15:24 ` Borislav Petkov
2014-04-03 15:24 ` Borislav Petkov
2014-04-03 15:25 ` Michal Simek
2014-04-03 15:25 ` Michal Simek
2014-04-09 11:32 ` Borislav Petkov
2014-04-09 11:32 ` Borislav Petkov
2014-04-09 13:18 ` Rob Herring
2014-04-09 13:18 ` Rob Herring
2014-04-09 13:18 ` Rob Herring
2014-04-09 15:19 ` Borislav Petkov [this message]
2014-04-09 15:19 ` Borislav Petkov
2014-04-09 17:29 ` Punnaiah Choudary
2014-04-09 17:29 ` Punnaiah Choudary
2014-04-09 17:47 ` Borislav Petkov
2014-04-09 17:47 ` Borislav Petkov
2014-04-09 17:47 ` Borislav Petkov
2014-04-10 6:12 ` Michal Simek
2014-04-10 6:12 ` Michal Simek
2014-04-10 9:02 ` Borislav Petkov
2014-04-10 9:02 ` Borislav Petkov
2014-04-10 10:09 ` Michal Simek
2014-04-10 10:09 ` Michal Simek
2014-04-10 10:09 ` Michal Simek
2014-04-11 13:14 ` Borislav Petkov
2014-04-11 13:14 ` Borislav Petkov
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=20140409151932.GK6529@pd.tnic \
--to=bp@alien8.de \
--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.