`amd_get_cores_per_cu'
>
> Reported-by: build test robot
> Signed-off-by: Huang Rui
Acked-by: Borislav Petkov
This can go in now, regardless of the rest.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the lin
te unit with smp_call_function_many(). This behavior can decrease
> IPI numbers.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Huang Rui
> ---
> drivers/hwmon/fam15h_power.c | 65
> +++-
> 1 file changed, 64 insertions(+), 1 deletio
.58 mW (avg = 2.55 mW, interval = 0.01 s)
>(crit = 15.00 W)
>
> ...
>
> The result is current average processor power consumption in 10
> millisecond. The unit of the result is uWatt.
>
> Suggested-by: Guenter Roeck
> Signed-off-by: Huang Ru
On Tue, Mar 29, 2016 at 11:28:48AM +0800, Huang Rui wrote:
> I checked with HW designer, milliseconds is also a reasonable interval
> of acc power. And I cannot set too long here, because several seconds
> will cause the read function to hang for that period of time.
Exactly this justification sho
On Tue, Mar 29, 2016 at 09:31:58AM +0200, Peter Zijlstra wrote:
> This will not in fact work for Intel, nor if I manage to one day
> randomize our CPU numbers on AMD.
Oh, I know why. I have this 64 CPUs box here:
$ grep "core id" /proc/cpuinfo | uniq
core id : 0
core id : 8
core i
From: Borislav Petkov
We need to reenable the topology extensions CPUID leafs on newer models
too, if BIOS has disabled them, as we rely on them to get proper compute
unit topology.
Make the printk a once thing, while at it.
Signed-off-by: Borislav Petkov
Cc: Rui Huang
Cc: Sherry Hurwitz
From: Borislav Petkov
We need to read a bunch of registers on each compute unit and possibly
on the current CPU too. Disable preemption around it.
Signed-off-by: Borislav Petkov
Cc: Rui Huang
Cc: Sherry Hurwitz
Cc: Guenter Roeck
---
drivers/hwmon/fam15h_power.c | 10 ++
1 file
On Wed, Jun 01, 2016 at 06:22:59AM -0700, Guenter Roeck wrote:
> An explanation would be helpful. Is this a bug fix ?
That's a good point - yes, it is necessary. Both smp_processor_id()
*and* smp_call_function_many() need to be called with preemption
disabled.
It did fire the BUG thing in check_p
On Wed, Jun 01, 2016 at 11:15:09AM -0700, Guenter Roeck wrote:
> It would be great if you can add at least part of the BUG message as well
> as a Fixes: tag into the patch description.
How's that:
---
From: Borislav Petkov
Date: Wed, 1 Jun 2016 11:36:13 +0200
Subject: [P
On Thu, Jun 02, 2016 at 09:47:54AM +0200, Thomas Gleixner wrote:
> What's wrong with using:
>
>on_each_cpu_mask()
>
> Which does all that magic for you?
Ha, very nice! Let me try it.
Thanks!
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe
On Thu, Jun 02, 2016 at 09:58:30AM +0200, Borislav Petkov wrote:
> Ha, very nice! Let me try it.
Yap, much better than opencoding on_each_cpu_mask() :-)
---
From: Borislav Petkov
Date: Wed, 1 Jun 2016 11:36:13 +0200
Subject: [PATCH] hwmon: (fam15h_power) Disable preemption when read
On Fri, Jun 03, 2016 at 11:18:36AM -0700, Guenter Roeck wrote:
> I like this version. Applied, though it would be nice to get a
> Tested-by: or Acked-by: from someone at AMD. I'll hold back until
> early next week before sending it to Linus.
If it makes you feel any better: I have the affected har
On Sat, Apr 28, 2018 at 06:54:38PM -0700, Guenter Roeck wrote:
> Add Raven Ridge root bridge and data fabric PCI IDs.
> This is required for amd_pci_dev_to_node_id() and amd_smn_read().
>
> Signed-off-by: Guenter Roeck
> ---
> This patch is a prerequisite for the second patch in the series.
> I'l
On Fri, Nov 02, 2018 at 02:59:25PM -0500, Bjorn Helgaas wrote:
> This isn't my code, and I'm not really objecting to these changes, but
> from where I sit, the fact that you need this sort of vendor-specific
> topology discovery is a little bit ugly and seems like something of a
> maintenance issue
On Fri, Nov 02, 2018 at 06:11:07PM +, Woods, Brian wrote:
> Add support for new processors which have multiple PCI root complexes
> per data fabric/SMN interface.
Please write out abbreviations. I believe it is only you and I who know
what SMN means. :)
> The interfaces per root complex are r
On Fri, Nov 02, 2018 at 06:11:12PM +, Woods, Brian wrote:
> Add support for AMD family 17h model 30h processors for k10temp. Model
> 30h is functionally the same as model 01h processors (as far as k10temp
> is concerned), just the PCI device IDs need to be updated.
>
> Signed-off-by: Brian Wo
On Mon, Nov 05, 2018 at 08:33:34PM +, Woods, Brian wrote:
> I think having them togeter is cleaner. If you aren't finding any
> misc IDs, I highly doubt you'll find any root IDs. There shouldn't
> be much of a difference in how fast the function exits, either way.
> If you want it the other wa
On Mon, Nov 05, 2018 at 03:45:37PM -0600, Bjorn Helgaas wrote:
> amd_nb.c prevents us from achieving that goal. These patches don't
> add new functionality; they merely describe minor topographical
> differences in new hardware. We usually try to do that in a more
> generic way, e.g., via an ACPI
On Mon, Nov 05, 2018 at 11:32:16PM +, Woods, Brian wrote:
> Your understanding is correct. It's more so that the following DF/SMN
> interface gets mapped correctly.
> /*
>* If there are more PCI root devices than data fabric/
>* system management n
On Tue, Nov 06, 2018 at 03:42:56PM -0600, Bjorn Helgaas wrote:
> This isn't some complicated new device where the programming model
> changed on the new CPU. This is a thermometer that was already
> supported. ACPI provides plenty of functionality that could be used
> to support this generically,
On Tue, Nov 06, 2018 at 05:20:41PM -0600, Bjorn Helgaas wrote:
> Or maybe even drivers/acpi/thermal.c, which claims every Thermal Zone
> (ACPI 6.2, sec 11), would be sufficient. I don't know what the
> relationship between hwmon and other thermal stuff, e.g.,
> Documentation/thermal/sysfs-api.txt
On Wed, Nov 07, 2018 at 07:38:56AM -0600, Bjorn Helgaas wrote:
> Firmware supplies ACPI namespace. The namespace contains an abstract
> description of the platform, including devices. Devices are
> identified by PNP IDs, which are analogous to PCI vendor/device IDs,
> except that a device may hav
On Wed, Nov 07, 2018 at 11:10:44AM -0600, Bjorn Helgaas wrote:
> No, the idea was more that that temp monitoring, e.g., k10temp, could
> be independent of amd_nb.
>
> But I can tell this idea isn't going anywhere, so let's just forget
> that I stuck my neck out and let it die on the vine :)
No no
From: Borislav Petkov
... and __ro_after_init. Since the brand string is being read earlier
now, in early_identify_cpu(), get_model_name() needs to read out the
extended CPUID level for the brand string. This is temporary only, until
the full CPUID read out has been added.
Signed-off-by
,7 @@ static const struct pci_device_id k10temp_id_table[] = {
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) },
> + { PCI_VDEVICE(HYGON, PCI_DEVICE_ID_AMD_17H
On Mon, Jul 22, 2019 at 10:59:32AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Jul 2019, Guenter Roeck wrote:
> > > We could merge his patches (if he contacted the x86 crew), make a v2 of
> > > mine (71h -> 70h, add his Signed-off-by?) and merge, or some other option?
> > >
> > Either case, we'll n
On Fri, Sep 06, 2019 at 01:56:56AM +, Isaac Vaughn wrote:
> Add the new Family 17h Model 70h PCI IDs (device 18h functions 0,3,4,6)
> to the kernel, the hwmon module, and the AMD64 EDAC module.
>
> Signed-off-by: Isaac Vaughn
> ---
> arch/x86/kernel/amd_nb.c | 3 +++
> drivers/edac/amd64_e
On Fri, Sep 06, 2019 at 11:57:35AM +, Isaac Vaughn wrote:
> Will do, thanks.
And, when you reply to mails, please press "Reply-to-all" in your mail
client and do not do private mails. There's a reason there's a Cc list.
Readding them.
> I built my patch on both 5.3.0rc7 and master, and have t
On Fri, Sep 06, 2019 at 02:05:35PM +, Isaac Vaughn wrote:
> They seem to have already covered the changes to hwmon and amd_nb, so
> the difference is probably the changes to amd64_edac.
Yeah, then you can send me only those changes against edac-for-next.
The driver won't load on Zen2 before th
On Fri, Sep 06, 2019 at 09:11:40AM -0700, Guenter Roeck wrote:
> 12163cfbfc0f ("hwmon: (k10temp) Add support for AMD family 17h, model 70h
> CPUs")
> af4e1c5eca95 ("x86/amd_nb: Add PCI device IDs for family 17h, model 70h")
Thanks!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/no
30 matches
Mail list logo
