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_
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:
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 the comment
[+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
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
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.
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 telli
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.
> > >
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
[+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
[+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
[+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.
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 in the
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]
>
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
g 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 | 3 +++
>
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
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
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
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 itsel
[+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
[+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
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.
> > > Perfo
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
> > mess), I'd
[+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
[+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
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
[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
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-
> > facin
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
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
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 +-
> 1 file
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:
>
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
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
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
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
> 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 usb_d
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
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
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.
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 to just app
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:
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
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
> ---
>
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
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
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
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
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;
>
viously 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 the
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
>
>
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
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:
> > > &g
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):
> >
: 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 4937a088d7d8..fbeb9f73ef28 10
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
onfig_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
---
drivers/g
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
onfig_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
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
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 review
From: Bjorn Helgaas
Add definitions for these PCIe Link Control 2 register fields:
Enter Compliance
Transmit Margin
and use them in amdgpu and radeon.
NOTE: This is a functional change because "7 << 9" was apparently a typo.
That mask included the high order bit of
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2
definitions. No functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 8
drivers/gpu/drm/amd/amdgpu/si.c | 8
drivers
On Thu, Nov 7, 2019 at 4:30 PM Ilia Mirkin wrote:
>
> On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote:
> > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> > index 29d6e93fd15e..03446be8a7be 100644
> > --- a/include/uapi/linux/pci_regs.
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2
definitions. No functional change intended.
---
drivers/gpu/drm/amd/amdgpu/cik.c | 8
drivers/gpu/drm/amd/amdgpu/si.c | 8
drivers/gpu/drm/radeon/cik.c | 8
drivers/gpu/drm
From: Bjorn Helgaas
Add definitions for these PCIe Link Control 2 register fields:
Enter Compliance
Transmit Margin
and use them in amdgpu and radeon.
NOTE: This is a functional change because "7 << 9" looks like it might be a
typo. That mask includes the high order
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 haven't signed off on these because the first one actually changes the
bits involved because
On Wed, Jul 17, 2019 at 9:08 PM 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 differences between v1 and v2 of the PCI
> Express Capability.
>
>
On Wed, Jul 17, 2019 at 9:08 PM 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 differences between v1 and v2 of the PCI
> Express Capability.
>
>
On Wed, Apr 24, 2019 at 09:10:21PM +0200, Heiner Kallweit wrote:
> In several places in the kernel we find PCI_DEVID used like this:
> PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper
> for it.
>
> v2:
> - apply the change to all affected places in the kernel
>
> Heiner Kallweit
On Tue, Nov 27, 2018 at 11:49:43AM -0500, Mikulas Patocka wrote:
> On Mon, 26 Nov 2018, Bjorn Helgaas wrote:
> > On Mon, Nov 19, 2018 at 06:47:04PM -0600, Bjorn Helgaas wrote:
> > > On Tue, Oct 30, 2018 at 12:36:08PM -0400, Mikulas Patocka wrote:
> > > > The
1 - 100 of 129 matches
Mail list logo
