On Tue, Aug 08, 2017 at 02:25:10PM +0100, Will Deacon wrote:
> On Fri, Jul 28, 2017 at 04:12:33PM -0700, Greg KH wrote:
> > On Thu, Jul 27, 2017 at 03:15:15PM +0200, Borislav Petkov wrote:
> > > On Thu, Jul 27, 2017 at 11:08:56AM +0200, Jan Glauber wrote:
> > > > OK. As fixing the firmware will tak
On Fri, Jul 28, 2017 at 04:12:33PM -0700, Greg KH wrote:
> On Thu, Jul 27, 2017 at 03:15:15PM +0200, Borislav Petkov wrote:
> > On Thu, Jul 27, 2017 at 11:08:56AM +0200, Jan Glauber wrote:
> > > OK. As fixing the firmware will take quite some time I'll go for the
> > > memory
> > > controller driv
On 27/07/17 10:08, Jan Glauber wrote:
On Thu, Jul 27, 2017 at 07:11:57AM +0200, Borislav Petkov wrote:
On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
Also, if a given configuration disables CONFIG_EDAC there is some hackery
needed to get the perf portion of the driver included.
On Thu, Jul 27, 2017 at 03:15:15PM +0200, Borislav Petkov wrote:
> On Thu, Jul 27, 2017 at 11:08:56AM +0200, Jan Glauber wrote:
> > OK. As fixing the firmware will take quite some time I'll go for the memory
> > controller driver that starts EDAC / PMU depending on their CONFIG_.
> >
> > What woul
On Thu, Jul 27, 2017 at 06:11:30PM -0700, Greg KH wrote:
> Oh well, fix it in the kernel, that's what it's there for :)
Duude, don't put crazy ideas in people's heads!
:-)))
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
On Thu, Jul 27, 2017 at 10:29:53AM -0700, David Daney wrote:
> On 07/26/2017 07:29 PM, Greg KH wrote:
> > On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
> > > On 07/26/2017 01:08 PM, Greg KH wrote:
> > > > On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote:
> > > > > On 07/26
On 07/26/2017 07:29 PM, Greg KH wrote:
On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
On 07/26/2017 01:08 PM, Greg KH wrote:
On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote:
On 07/26/2017 10:33 AM, Greg KH wrote:
On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Pet
On Thu, Jul 27, 2017 at 11:08:56AM +0200, Jan Glauber wrote:
> OK. As fixing the firmware will take quite some time I'll go for the memory
> controller driver that starts EDAC / PMU depending on their CONFIG_.
>
> What would be the proper location for the multiplexer?
> drivers/soc/cavium or drive
On Thu, Jul 27, 2017 at 07:11:57AM +0200, Borislav Petkov wrote:
> On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
> > Also, if a given configuration disables CONFIG_EDAC there is some hackery
> > needed to get the perf portion of the driver included.
>
> Yes, and we don't do performa
On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
> Also, if a given configuration disables CONFIG_EDAC there is some hackery
> needed to get the perf portion of the driver included.
Yes, and we don't do performance counters in EDAC.
So you could add a small memory controller driver wh
On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
> On 07/26/2017 01:08 PM, Greg KH wrote:
> > On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote:
> > > On 07/26/2017 10:33 AM, Greg KH wrote:
> > > > On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote:
> > > > > On W
On 07/26/2017 01:08 PM, Greg KH wrote:
On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote:
On 07/26/2017 10:33 AM, Greg KH wrote:
On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote:
On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote:
On Wed, Jul 26, 2017 at 05:55:48
On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote:
> On 07/26/2017 10:33 AM, Greg KH wrote:
> > On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote:
> > > On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote:
> > > > On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov
On 07/26/2017 10:33 AM, Greg KH wrote:
On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote:
On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote:
On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov wrote:
On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote:
The PM
On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote:
> On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote:
> > On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov wrote:
> > > On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote:
> > > > The PMU/EDAC devices are all PC
On Wed, Jul 26, 2017 at 05:25:15PM +0100, Jonathan Cameron wrote:
> On Wed, 26 Jul 2017 17:46:23 +0200
> Jan Glauber wrote:
>
> > On Wed, Jul 26, 2017 at 04:17:11PM +0100, Suzuki K Poulose wrote:
> > > How about adding a soc specific (wrapper) driver for the memory
> > > controller, which
> > >
On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote:
> On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov wrote:
> > On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote:
> > > The PMU/EDAC devices are all PCI devices do I need the 'struct pci_dev *'.
> > > I'm not aware of other
On Wed, 26 Jul 2017 17:46:23 +0200
Jan Glauber wrote:
> On Wed, Jul 26, 2017 at 04:17:11PM +0100, Suzuki K Poulose wrote:
> > How about adding a soc specific (wrapper) driver for the memory controller,
> > which
> > could use the PCI id and trigger EDAC and PMU drivers (based on what is
> > sele
On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov wrote:
> On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote:
> > The PMU/EDAC devices are all PCI devices do I need the 'struct pci_dev *'.
> > I'm not aware of other ways to access these devices. Please enlighten
> > me if I'm miss
On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote:
> The PMU/EDAC devices are all PCI devices do I need the 'struct pci_dev *'.
> I'm not aware of other ways to access these devices. Please enlighten
> me if I'm missing something.
Me enlighten you on Cavium hardware?! You're funny.
So I
On Wed, Jul 26, 2017 at 04:17:11PM +0100, Suzuki K Poulose wrote:
> How about adding a soc specific (wrapper) driver for the memory controller,
> which
> could use the PCI id and trigger EDAC and PMU drivers (based on what is
> selected by configs) ?
Sounds good to me. Is there a driver that alr
On Wed, Jul 26, 2017 at 05:35:02PM +0200, Borislav Petkov wrote:
> On Wed, Jul 26, 2017 at 05:13:14PM +0200, Jan Glauber wrote:
> > I'm also looking for CPU implementor (MIDR), I could check for the model
> > too but I still need to detect devices based on PCI IDs as the model
> > check is not suff
On Wed, Jul 26, 2017 at 05:13:14PM +0200, Jan Glauber wrote:
> I'm also looking for CPU implementor (MIDR), I could check for the model
> too but I still need to detect devices based on PCI IDs as the model
> check is not sufficient here (only multi-socket ThunderX has OCX TLK
> devices).
So what
On Wed, Jul 26, 2017 at 04:17:11PM +0100, Suzuki K Poulose wrote:
> How about adding a soc specific (wrapper) driver for the memory controller,
> which
> could use the PCI id and trigger EDAC and PMU drivers (based on what is
> selected by configs) ?
That was the last idea on my list if nothing
On 26/07/17 16:13, Jan Glauber wrote:
On Wed, Jul 26, 2017 at 04:55:22PM +0200, Borislav Petkov wrote:
On Wed, Jul 26, 2017 at 03:35:25PM +0100, Suzuki K Poulose wrote:
So the Cavium EDACs, which appear as PCI devices have a PMU attached to it.
Cavium EDACs?
So let me set something straight
On Wed, Jul 26, 2017 at 04:55:22PM +0200, Borislav Petkov wrote:
> On Wed, Jul 26, 2017 at 03:35:25PM +0100, Suzuki K Poulose wrote:
> > So the Cavium EDACs, which appear as PCI devices have a PMU attached to it.
>
> Cavium EDACs?
>
> So let me set something straight first: An EDAC driver simply
On Wed, Jul 26, 2017 at 03:35:25PM +0100, Suzuki K Poulose wrote:
> So the Cavium EDACs, which appear as PCI devices have a PMU attached to it.
Cavium EDACs?
So let me set something straight first: An EDAC driver simply talks to
some RAS IP block and reports errors. It shouldn't have anything to
+To: Boris
Hi Boris,
On 26/07/17 14:10, Jan Glauber wrote:
On Wed, Jul 26, 2017 at 01:47:35PM +0100, Suzuki K Poulose wrote:
On 26/07/17 12:19, Jan Glauber wrote:
On Tue, Jul 25, 2017 at 04:39:18PM +0100, Suzuki K Poulose wrote:
On 25/07/17 16:04, Jan Glauber wrote:
Add support for the PMU
On Wed, Jul 26, 2017 at 01:47:35PM +0100, Suzuki K Poulose wrote:
> On 26/07/17 12:19, Jan Glauber wrote:
> >On Tue, Jul 25, 2017 at 04:39:18PM +0100, Suzuki K Poulose wrote:
> >>On 25/07/17 16:04, Jan Glauber wrote:
> >>>Add support for the PMU counters on Cavium SOC memory controllers.
> >>>
> >>
On 26/07/17 12:19, Jan Glauber wrote:
On Tue, Jul 25, 2017 at 04:39:18PM +0100, Suzuki K Poulose wrote:
On 25/07/17 16:04, Jan Glauber wrote:
Add support for the PMU counters on Cavium SOC memory controllers.
This patch also adds generic functions to allow supporting more
devices with PMU coun
On Tue, Jul 25, 2017 at 04:39:18PM +0100, Suzuki K Poulose wrote:
> On 25/07/17 16:04, Jan Glauber wrote:
> >Add support for the PMU counters on Cavium SOC memory controllers.
> >
> >This patch also adds generic functions to allow supporting more
> >devices with PMU counters.
> >
> >Properties of t
On Tue, 25 Jul 2017 17:04:20 +0200
Jan Glauber wrote:
> Add support for the PMU counters on Cavium SOC memory controllers.
>
> This patch also adds generic functions to allow supporting more
> devices with PMU counters.
>
> Properties of the LMC PMU counters:
> - not stoppable
> - fixed purpose
On 25/07/17 16:04, Jan Glauber wrote:
Add support for the PMU counters on Cavium SOC memory controllers.
This patch also adds generic functions to allow supporting more
devices with PMU counters.
Properties of the LMC PMU counters:
- not stoppable
- fixed purpose
- read-only
- one PCI device pe
Add support for the PMU counters on Cavium SOC memory controllers.
This patch also adds generic functions to allow supporting more
devices with PMU counters.
Properties of the LMC PMU counters:
- not stoppable
- fixed purpose
- read-only
- one PCI device per memory controller
Signed-off-by: Jan
34 matches
Mail list logo