On Mon, Jun 16, 2025 at 12:50:16PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> For the suspend flow PCIe ports that have downstream devices are put into
> the appropriate D3 state when children are not in D0. For the hibernate
> flow, PCIe ports with downstream devices stay in D
On Wed, Jul 09, 2025 at 09:02:17PM -0400, Alex Huang wrote:
> On 2025-07-08 19:07, Bjorn Helgaas wrote:
> > On Thu, Jul 03, 2025 at 12:09:20AM -0400, Alex Huang wrote:
> >> Recently, I dug up a Radeon Pro WX3100 and when booting, got a black screen
> >> with some com
On Thu, Jul 03, 2025 at 12:09:20AM -0400, Alex Huang wrote:
> Hi,
>
> Recently, I dug up a Radeon Pro WX3100 and when booting, got a black screen
> with some complaints of No EDID read and then a `Fatal error during GPU
> init`. With windows booting fine and an MSI Kombustor run turning out just
>
[+cc Kenneth, Alex, Christian, amd-gfx]
On Thu, Jul 03, 2025 at 12:09:20AM -0400, Alex Huang wrote:
> Hi,
>
> Recently, I dug up a Radeon Pro WX3100 and when booting, got a black screen
> with some complaints of No EDID read and then a `Fatal error during GPU
> init`. With windows booting fine an
>From Denis's report at https://bugzilla.kernel.org/show_bug.cgi?id=220110:
> I am having problems with my laptop that has a thunderbolt
> controller to which I connected an AMD 6750XT.
>
> The topology of my system is described in this bug:
> https://gitlab.freedesktop.org/drm/amd/-/issues/4014
On Sun, Nov 03, 2024 at 05:03:32PM +, Thomas Weißschuh wrote:
> Stop abusing the is_bin_visible() callback to calculate the attribute
> size. Instead use the new, dedicated bin_size() one.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Bjorn Helgaas
Thanks for doing this!
>
On Sun, Nov 03, 2024 at 05:03:29PM +, Thomas Weißschuh wrote:
> struct bin_attribute contains a bunch of pointer members, which when
> overwritten by accident or malice can lead to system instability and
> security problems.
> Moving the definitions of struct bin_attribute to read-only memory
>
On Sun, Nov 03, 2024 at 05:03:31PM +, Thomas Weißschuh wrote:
> Several drivers need to dynamically calculate the size of an binary
> attribute. Currently this is done by assigning attr->size from the
> is_bin_visible() callback.
s/an binary/a binary/
> This has drawbacks:
> * It is not docum
gt; throughout the tree at once.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Bjorn Helgaas# drivers/pci
> ---
> drivers/cxl/port.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> drivers/infiniband/hw/qib/qib_sysfs.c |
On Fri, Sep 27, 2024 at 09:57:20AM +, Feng, Kenneth wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
I don't know what I can do with this.
1) The "AMD Official Use Only - AMD Internal Distribution Only" above
suggests to me that I can't act on it. Is there any way you can ge
On Mon, Mar 25, 2024 at 04:04:44PM -0500, Bjorn Helgaas wrote:
> On Mon, Mar 25, 2024 at 09:39:38PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 25, 2024 at 04:09:20PM +0900, Damien Le Moal wrote:
> > > Use the macro PCI_IRQ_INTX instead of the deprecated PCI_IRQ_LEGACY
> &g
On Mon, Mar 25, 2024 at 09:39:38PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 25, 2024 at 04:09:20PM +0900, Damien Le Moal wrote:
> > Use the macro PCI_IRQ_INTX instead of the deprecated PCI_IRQ_LEGACY
> > macro.
>
> Not needed anymore. MFD subsystem has a patch moving this to MSI support.
> But
On Mon, Mar 25, 2024 at 04:09:11PM +0900, Damien Le Moal wrote:
> This patch series removes the use of the depracated PCI_IRQ_LEGACY macro
> and replace it with PCI_IRQ_INTX. No functional change.
>
> Damien Le Moal (28):
> PCI: msi: Use PCI_IRQ_INTX
> PCI: portdrv: Use PCI_IRQ_INTX
> PCI: d
From: Bjorn Helgaas
After 4020c2280233 ("drm/amdgpu: don't runtime suspend if there are
displays attached (v3)"), "ret" is unconditionally set later before being
used, so there's point in initializing it and the associated comment is no
longer meaningful.
Remove t
[+cc Bartosz]
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote:
> Removing an amdgpu device that still has user space references allocated
> to it causes undefined behaviour. So, implement amdgpu_pci_can_remove()
> and disallow devices that still have files allocated to them from bein
On Fri, Nov 03, 2023 at 02:07:49PM -0500, Mario Limonciello wrote:
> Downstream drivers are getting the wrong values from
> pcie_bandwidth_available() which is causing problems for performance
> of eGPUs.
>
> This series overhauls Thunderbolt related device detection and uses
> the changes to chan
On Fri, Aug 25, 2023 at 02:27:09PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> There is no function that can be used to get all PCI(e) devices in a
> system by matching against its the PCI base class code only, while keep
> the sub-class code and the programming interface ignored. Therefo
On Fri, Aug 18, 2023 at 04:12:57PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Ilpo Järvinen
> > Sent: Monday, July 17, 2023 8:05 AM
> > To: linux-...@vger.kernel.org; Bjorn Helgaas ; Lorenzo
> > Pieralisi ; Rob Herring ;
> > Krzy
On Mon, Jul 24, 2023 at 08:47:48PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > "drm/loongson: Add an implement for ..." also solves a problem, but it
> > lacks a commit log, so I don't know what the problem is.
>
> I have already
On Mon, Jul 24, 2023 at 08:16:18PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > > 2) It does not take the PCI Bar may get relocated into consideration.
> > > 3) It is not effective for the PCI device without a dedicated VRAM Bar.
> > > 4)
On Mon, Jul 17, 2023 at 03:04:57PM +0300, Ilpo Järvinen wrote:
> Don't assume that only the driver would be accessing LNKCTL. ASPM
> policy changes can trigger write to LNKCTL outside of driver's control.
> And in the case of upstream bridge, the driver does not even own the
> device it's changing
On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch adds the aperture_contain_firmware_fb() function to do the
> determination. Unfortunately, due to the fact that the apertures list
> will be freed dynamically, the location and size information of th
[+cc linux-pci; I don't apply or ack PCI patches unless they appear there]
On Wed, Jul 12, 2023 at 12:43:04AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The observation behind this is that we should avoid accessing the global
> screen_info directly. Call the aperture_contain_firmware_fb
[+cc linux-pci]
On Wed, Jul 12, 2023 at 12:43:01AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, the default VGA device selection is not perfect. Potential
> problems are:
>
> 1) This function is a no-op on non-x86 architectures.
> 2) It does not take the PCI Bar may get reloca
[+cc linux-pci (please cc in the future since the bulk of this patch
is in drivers/pci/)]
On Wed, Jul 12, 2023 at 12:43:05AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, the strategy of selecting the default boot on a multiple video
> card coexistence system is not perfect. Pot
On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote:
> On 2023/6/30 01:44, Limonciello, Mario wrote:
> > > On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> > > > 4) Right now we're i
On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> A nouveau developer(Lyude) from redhat send me a R-B,
>
> Thanks for the developers of nouveau project.
>
>
> Please allow me add a link[1] here.
>
>
> [1]
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff2585
On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote:
> On 2023/6/9 03:19, Bjorn Helgaas wrote:
> > On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
> > > From: Sui Jingfeng
> > >
> > > The vga_is_firmware_default() function is arch-depend
think it's something like "PCI Code and
ID Assignment, r1.9, sec 1, 1.19".
> Signed-off-by: Shiwu Zhang
> Acked-by: Lijo Lazar
With the above:
Acked-by: Bjorn Helgaas # pci_ids.h
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +
> include/linux/pci_ids.h
On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The vga_is_firmware_default() function is arch-dependent, which doesn't
> sound right. At least, it also works on the Mips and LoongArch platforms.
> Tested with the drm/amdgpu and drm/radeon drivers. However,
Start with verb and capitalize to match ("Deal only with ...")
On Thu, Jun 08, 2023 at 07:43:21PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> vgaarb only deal with the VGA devcie(pdev->class == 0x0300), so replace the
> pci_get_subsys() function with pci_get_class(). Filter the non pci d
Capitalize subject to match ("Tidy ...")
On Thu, Jun 08, 2023 at 07:43:19PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch replaces the leading space with a tab and removes the double
> blank line, no functional change.
Can you move this to the end of the series? The functional
Match the subject line style:
$ git log --oneline drivers/pci/vgaarb.c
f321c35feaee PCI/VGA: Replace full MIT license text with SPDX identifier
d5109fe4d1ec PCI/VGA: Use unsigned format string to print lock counts
4e6c91847a7f PCI/VGA: Log bridge control messages when adding devices
dc59
From: Bjorn Helgaas
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is
native"), the PCI core does this for all devices during enumeration, so the
driver doesn't need to do it itse
[+cc Christian, Xinhui, amd-gfx]
On Fri, Jan 06, 2023 at 01:48:11PM +0800, Baolu Lu wrote:
> On 1/5/23 11:27 PM, Felix Kuehling wrote:
> > Am 2023-01-05 um 09:46 schrieb Deucher, Alexander:
> > > > -Original Message-
> > > > From: Hegde, Vasant
> > > > On 1/5/2023 4:07 PM, Baolu Lu wrote:
[+cc Stefan, linux-pci]
On Wed, Nov 23, 2022 at 09:43:07AM +0800, Guchun Chen wrote:
> Return true early if ASIC is in BACO state already, no need
> to talk to SMU. It can fix the issue that driver was not
> calling BACO exit at all in runtime pm resume, and a timing
> issue leading to a PCI AER e
On Fri, Sep 09, 2022 at 01:11:54PM +0530, Lazar, Lijo wrote:
>
>
> On 9/8/2022 11:27 PM, Bjorn Helgaas wrote:
> > On Thu, Sep 08, 2022 at 04:42:38PM +, Lazar, Lijo wrote:
> > > I am not sure if ASPM settings can be generalized by PCIE core.
> > > Performa
's back, things are likely to break.
> From: Alex Deucher
> On Thu, Sep 8, 2022 at 12:12 PM Bjorn Helgaas wrote:
> > Do you know why the driver configures ASPM itself? If the PCI core is
> > doing something wrong (and I'm sure it is, ASPM support is kind of a
> &g
[+cc Evan, author of 62f8f5c3bfc2 ("drm/amdgpu: enable ASPM support
for PCIE 7.4.0/7.6.0")]
On Thu, Sep 08, 2022 at 08:53:44AM +0530, Lijo Lazar wrote:
> As per PCIE Base Spec r4.0 Section 6.18
> 'Software must not enable LTR in an Endpoint unless the Root Complex
> and all intermediate Switches i
[+cc Greg, no action needed yet, just FYI that stable will want these]
On Thu, Aug 25, 2022 at 02:28:19PM +0530, Lijo Lazar wrote:
> HDP flush is used early in the init sequence as part of memory controller
> block initialization. Hence remapping of HDP registers needed for flush
> needs to happen
On Thu, Aug 25, 2022 at 10:18:28AM +0200, Christian König wrote:
> Am 25.08.22 um 09:54 schrieb Lazar, Lijo:
> > On 8/25/2022 1:04 PM, Christian König wrote:
> > > Am 25.08.22 um 08:40 schrieb Stefan Roese:
> > > > On 24.08.22 16:45, Tom Seewald wrote:
> > > > > On Wed, Aug 24, 2022 at 12:11 AM Laz
[Adding amdgpu folks]
On Wed, Aug 17, 2022 at 11:45:15PM +, bugzilla-dae...@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216373
>
> Bug ID: 216373
>Summary: Uncorrected errors reported for AMD GPU
> Kernel Version: v6.0-rc1
> Regression:
On Fri, Aug 19, 2022 at 12:13:03PM -0500, Bjorn Helgaas wrote:
> On Thu, Aug 18, 2022 at 03:38:12PM -0500, Bjorn Helgaas wrote:
> > [Adding amdgpu folks]
> >
> > On Wed, Aug 17, 2022 at 11:45:15PM +, bugzilla-dae...@kernel.org wrote:
> > > https://bugzilla.ker
On Thu, Aug 18, 2022 at 03:38:12PM -0500, Bjorn Helgaas wrote:
> [Adding amdgpu folks]
>
> On Wed, Aug 17, 2022 at 11:45:15PM +, bugzilla-dae...@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216373
> >
> > Bug ID: 216373
> >
On Fri, Aug 19, 2022 at 02:03:59PM +0530, Lazar, Lijo wrote:
> Or, it could be amdgpu or some other software component -
>
> register mmio base: 0x95E0
> Address 0x95e7f000
>
> 0x95e7f000 indicates access from CPU to a register offset 0x7FE000. This
> doesn't look like a valid register
On Sun, May 8, 2022 at 3:29 PM wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=215958
>
> Bug ID: 215958
>Summary: thunderbolt3 egpu cannot disconnect cleanly
>Product: Drivers
>Version: 2.5
> Kernel Version: 5.17.0-1003-oem #3-Ubuntu SMP
On Mon, Feb 28, 2022 at 03:33:13PM +, Limonciello, Mario wrote:
> [AMD Official Use Only]
>
> >
> > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-
> > facing&
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a dev
On Thu, Feb 24, 2022 at 07:23:49PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> > The `is_thunderbolt` attribute originally had a well defined list of
> > quirks that it existed for, but it has been overloaded with m
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a dev
p.org/drm/amd/-/issues/1760
Link:
https://lore.kernel.org/r/20220222160801.841643-1-alexander.deuc...@amd.com
Signed-off-by: Alex Deucher
Signed-off-by: Bjorn Helgaas
Acked-by: Christian König
Acked-by: Guchun Chen
> ---
> drivers/pci/quirks.c | 14 +-
>
On Mon, Feb 14, 2022 at 12:56:58PM +0200, Mika Westerberg wrote:
> On Mon, Feb 14, 2022 at 09:52:02AM +0100, Lukas Wunner wrote:
> > On Mon, Feb 14, 2022 at 09:34:26AM +0200, Mika Westerberg wrote:
> > > On Fri, Feb 11, 2022 at 03:45:46PM -0600, Bjorn Helgaas wrote:
> > &g
Make the subject specific, not just "appropriately." I think you're
marking something *removable*, so include that.
On Fri, Feb 11, 2022 at 01:32:45PM -0600, Mario Limonciello wrote:
> Discrete USB4 controllers won't have ACPI nodes specifying which
> PCIe or XHCI port they are linked with.
>
>
On Fri, Feb 11, 2022 at 01:32:44PM -0600, Mario Limonciello wrote:
> USB4 class devices are also removable like Intel Thunderbolt devices.
Spec reference, please.
> Drivers of downstream devices use this information to declare functional
> differences in how the drivers perform by knowing that th
On Fri, Feb 11, 2022 at 01:32:43PM -0600, Mario Limonciello wrote:
> The root port used for PCIe tunneling should be marked as removable to
> ensure that the entire chain is marked removable.
>
> This can be done by looking for the device property specified in
> the ACPI tables `usb4-host-interfac
On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote:
> `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
> controller to indicate that D3 is possible. As this is used solely
> for older Apple systems, move it into a quirk that enumerates across
> all Intel TBT co
Update subject to something like:
PCI: pciehp: Quirk broken Command Completed support on Intel Thunderbolt
controllers
On Fri, Feb 11, 2022 at 01:32:40PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` check is currently used to indicate the lack of
> command completed support for a num
> Acked-by: Alex Deucher
> Acked-by: Mika Westerberg
> Signed-off-by: Mario Limonciello
I would change the subject to:
PCI: Add USB4 class definition
because this seems like more of a PCI thing than a Thunderbolt thing,
but either way:
Acked-by: Bjorn Helgaas
> ---
&g
283e3d6d ("USB: add support for dev_groups to
> struct usb_driver")
>
> Signed-off-by: Andrey Grodzovsky
> Suggested-by: Greg Kroah-Hartman
With the subject change above,
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pci-driver.c | 1 +
> include/linux/p
On Thu, Apr 29, 2021 at 12:53:15PM -0400, Andrey Grodzovsky wrote:
> On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
> > On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
> > > This is exact copy of 'USB: add support for dev_groups to
> > > struct
In subject,
s/dmr/drm/
s/Move some/Move/ ("some" consumes space without adding meaning)
Or maybe something like:
drm/amdgpu: Convert driver sysfs attributes to static attributes
On Wed, Apr 28, 2021 at 11:11:49AM -0400, Andrey Grodzovsky wrote:
> This allows to remove explicit creation and d
On Wed, Apr 28, 2021 at 11:11:40AM -0400, Andrey Grodzovsky wrote:
> Until now extracting a card either by physical extraction (e.g. eGPU with
> thunderbolt connection or by emulation through syfs ->
> /sys/bus/pci/devices/device_id/remove)
> would cause random crashes in user apps. The random
In subject:
s/PCI: add support/PCI: Add support/
to match convention ("git log --oneline drivers/pci/pci-driver.c" to
learn this).
On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
> This is exact copy of 'USB: add support for dev_groups to
> struct usb_device_driver' patch by G
On Tue, Mar 16, 2021 at 03:28:51PM -0400, Alex Deucher wrote:
> From: Marcin Bachry
>
> Renoir needs a similar delay.
See
https://lore.kernel.org/linux-pci/20210311125322.GA216@bjorn-Precision-5520/
This is becoming a problem. We shouldn't have to merge a quirk for
every new device. Eith
On Wed, Jan 27, 2021 at 04:44:02PM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 27, 2021 at 4:16 PM Bjorn Helgaas wrote:
> >
> > On Tue, Jan 26, 2021 at 02:23:17PM -0600, Bjorn Helgaas wrote:
> > > From: Bjorn Helgaas
> > >
> > > The double negativ
On Tue, Jan 26, 2021 at 02:23:17PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
> Replace it with "if (ACPI_SUCCESS(status))".
>
> Signed-off-by: Bjorn Helgaas
> ---
>
From: Bjorn Helgaas
The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
Replace it with "if (ACPI_SUCCESS(status))".
Signed-off-by: Bjorn Helgaas
---
This isn't really an ACPI patch, but I'm sending it to you, Rafael, since
it seems easier t
On Tue, Jan 05, 2021 at 02:44:00PM +0100, Christian König wrote:
> Hi Bjorn,
>
> Darren stumbled over an AMD GPU with nonsense in it's resizeable BAR
> capability dword.
>
> This is most likely fixable with a VBIOS update, but we already sold quite a
> bunch of those boards with the problem.
>
On Wed, Sep 02, 2020 at 11:43:41PM +, Grodzovsky, Andrey wrote:
> It's based on v5.9-rc2 but won't apply cleanly since there is a
> significant amount of amd-staging-drm-next patches which this was
> applied on top of.
Is there a git branch published somewhere? It'd be nice to be able to
see
On Wed, Sep 02, 2020 at 02:42:06PM -0400, Andrey Grodzovsky wrote:
> Cache the PCI state on boot and before each case where we might
> loose it.
s/loose/lose/
> v2: Add pci_restore_state while caching the PCI state to avoid
> breaking PCI core logic for stuff like suspend/resume.
>
> v3: Extract
On Wed, Sep 02, 2020 at 02:42:04PM -0400, Andrey Grodzovsky wrote:
> DPC recovery involves ASIC reset just as normal GPU recovery so block
> SW GPU schedulers and wait on all concurrent GPU resets.
> + * Cancel and wait for all TDRs in progress if failing to
> + * set ad
On Wed, Sep 02, 2020 at 02:42:05PM -0400, Andrey Grodzovsky wrote:
> Wait for HW/PSP initiated ASIC reset to complete before
> starting the recovery operations.
>
> v2: Remove typo
>
> Signed-off-by: Andrey Grodzovsky
> Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device
On Wed, Sep 02, 2020 at 02:42:03PM -0400, Andrey Grodzovsky wrote:
> At this point the ASIC is already post reset by the HW/PSP
> so the HW not in proper state to be configured for suspension,
> some blocks might be even gated and so best is to avoid touching it.
>
> v2: Rename in_dpc to more mean
On Wed, Sep 02, 2020 at 02:42:02PM -0400, Andrey Grodzovsky wrote:
> Many PCI bus controllers are able to detect a variety of hardware PCI errors
> on the bus,
> such as parity errors on the data and address buses, A typical action taken
> is to disconnect
> the affected device, halting all I/
On Tue, Jun 02, 2020 at 11:16:17AM +0200, Piotr Stankiewicz wrote:
> The primary objective of this patch series is to change the behaviour
> of pci_alloc_irq_vectors_affinity such that it forwards the MSI-X enable
> error code when appropriate. In the process, though, it was pointed out
> that ther
On Mon, Apr 06, 2020 at 03:42:01PM -0400, Alex Deucher wrote:
> According to the hw architect, pre-ZEN parts support
> p2p writes and ZEN parts support both p2p reads and writes.
>
> Add entries for Zen parts Raven (0x15d0) and Renoir (0x1630).
>
> Cc: Christian König
> Acked-by: Christian König
On Mon, Mar 30, 2020 at 01:54:33PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Bjorn Helgaas
> > Sent: Saturday, March 28, 2020 4:19 PM
> > To: Mikel Rychliski
> > Cc: amd-gfx@lists.freedesktop.org; linux-...@vger.kernel.org;
>
) previously directly accessed an __iomem
> pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
>
> pci_platform_rom() now has no remaining callers, so remove it.
>
> Signed-off-by: Mikel Rychliski
I applied this to pci/resource for v5.7. I would feel better if some
of
On Wed, Mar 04, 2020 at 10:55:37AM +0800, Prike Liang wrote:
> This fix will handle some MP1 FW issue like as mclk dpm table in
> renoir has a reverse dpm clock layout and a zero frequency dpm level
> as following case.
>
> cat pp_dpm_mclk
> 0: 1200Mhz
> 1: 1200Mhz
> 2: 800Mhz
> 3: 0Mhz
>
> Signe
Cosmetics:
s/ioremap/ioremap()/ (also in commit log)
s/phys_to_virt/phys_to_virt()/ (also in commit log)
s/pci_platform_rom/pci_platform_rom()/ (commit log)
s/rom/ROM/
On Mon, Mar 02, 2020 at 10:34:55PM -0500, Mikel Rychliski wrote:
> On some EFI systems, the video BIOS is provided by the EFI fir
On Wed, Jan 15, 2020 at 03:20:18PM -0500, Alex Deucher wrote:
> On Wed, Jan 15, 2020 at 3:17 PM Bjorn Helgaas wrote:
> > On Wed, Jan 15, 2020 at 12:26:32PM -0500, Alex Deucher wrote:
> > > On Wed, Jan 15, 2020 at 12:14 PM Bjorn Helgaas wrote:
> > > > On Tue, Ja
On Wed, Jan 15, 2020 at 12:26:32PM -0500, Alex Deucher wrote:
> On Wed, Jan 15, 2020 at 12:14 PM Bjorn Helgaas wrote:
> > On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjorn Helgaas wrote:
> > > On Tue, Jan 14, 2020 at 03:55:21PM -0500, Alex Deucher wrote:
> > > > W
On Tue, Jan 14, 2020 at 05:41:44PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 14, 2020 at 03:55:21PM -0500, Alex Deucher wrote:
> > We've root caused the issue and clarified the quirk.
> > This also adds a new quirk for a new GPU.
> >
> > Alex Deucher (2):
> &
ca864c493 ("PCI: Mark AMD Stoney Radeon R7 GPU ATS as broken")
See-also: 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken")
Signed-off-by: Alex Deucher
Signed-off-by: Bjorn Helgaas
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 4937a088d
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correc
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Link: https://lore.kernel.org/r/20191112173503.176611-2-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
include/uapi/linux/pci_regs.h | 2
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Link: https://lore.kernel.org/r/20191112173503.176611-4-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd
nfig_word() and pci_write_config_word() calls with
pcie_capability_read_word() and pcie_capability_write_word().
[bhelgaas: fix a couple remaining instances in cik.c]
Link: https://lore.kernel.org/r/20191118003513.10852-1-f...@fredlawl.com
Signed-off-by: Frederick Lawler
Signed-off-by: Bjorn Helgaas
---
driv
From: Bjorn Helgaas
Use pcie_capability_read_word() and similar instead of using
pci_read_config_word() directly. Add #defines to replace some magic
numbers. Fix typos in use of Transmit Margin field.
These are currently on my pci/misc branch for v5.5. Let me know if you see
any issues
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correc
nfig_word() and pci_write_config_word() calls with
pcie_capability_read_word() and pcie_capability_write_word().
Link: https://lore.kernel.org/r/20191118003513.10852-1-f...@fredlawl.com
Signed-off-by: Frederick Lawler
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/drm/radeon/cik.c | 70 +---
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Link: https://lore.kernel.org/r/20191112173503.176611-4-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon
On Mon, Nov 18, 2019 at 12:42:25PM -0500, Alex Deucher wrote:
> On Mon, Nov 18, 2019 at 3:37 AM Frederick Lawler wrote:
> >
> > Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> > added accessors for the PCI Express Capability so that drivers didn't
> > need to be aware of di
On Tue, Nov 12, 2019 at 07:35:53PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Bjorn Helgaas
> > Sent: Tuesday, November 12, 2019 12:35 PM
> > To: Deucher, Alexander ; Koenig, Christian
> > ; Zhou, David(C
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
Since v2:
- Fix a gpu_cfg2 case in amdgpu/si.c that I had missed
- Separate out the functional
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Signed-off-by: Bjorn Helgaas
---
include/uapi/linux/pci_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correc
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++
drivers/gpu/drm/amd/amdgpu/si.c
On Tue, Nov 12, 2019 at 05:45:15PM +0100, Michel Dänzer wrote:
> On 2019-11-11 8:29 p.m., Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > Add definitions for these PCIe Link Control 2 register fields:
> >
> > Enter Compliance
> > Transmit Mar
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
I don't intend the Target Link Speed patch to change anything, so it should
be straightforward to r
1 - 100 of 146 matches
Mail list logo
