- Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
Date: Mon, 21 Jun 2021 02:50:09 +
From: bugzilla-dae...@bugzilla.kernel.org
To: bj...@helgaas.com
Subject: [Bug 213519] New: WARNING on system reboot in:
drivers/gpu/drm/i915/intel_runtime_pm.c:635
intel_runtime_pm
[+cc Joel (reporter)]
On Mon, Jun 21, 2021 at 04:50:14PM -0500, Bjorn Helgaas wrote:
> - Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
>
> Date: Mon, 21 Jun 2021 02:50:09 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: bj...@helgaas.com
> Subject
s is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > Acked-by: Mark Brown
> > Acked-by: Bjorn Helgaas
> > Acked-by: Srivatsa S. Bhat (VMware)
>
> So I can't apply this one
[+cc Christian, author of pci_resize_resource(), Sergei, author of
rebalancing patches]
Hi Lucas,
On Fri, Jun 17, 2022 at 11:44:41AM -0700, Lucas De Marchi wrote:
> Cc'ing intel-pci, lkml, Bjorn
>
> On Fri, Jun 17, 2022 at 11:32:37AM +0300, Jani Nikula wrote:
> > On Thu, 16 Jun 2022, priyanka.da
On Fri, Dec 17, 2021 at 10:13:13PM -0800, Lucas De Marchi wrote:
> When using QFLAG_APPLY_ONCE we make sure the quirk is applied only once.
Maybe "called" only once, since you're about to add a distinction
between "called" and "applied"?
I'm not really sure the concept of QFLAG_APPLY_ONCE, QFLAG_
lderlake-P.
>
> Since there are just a few quirks using the QFLAG_APPLY_ONCE logic and
> that is even the only flag, just use a static local variable in the
> quirk function itself. This allows to mark the quirk as applied only
> when it really is. As pointed out by Bjorn Helgaas, this is
On Wed, Jan 05, 2022 at 04:36:54PM -0800, Lucas De Marchi wrote:
> Remove extra parenthesis and wrap lines so it's easier to read what are
> the conditions being checked. The call to the hook also had an extra
> indentation: remove here to conform to coding style.
It's nice when your subject lines
On Thu, Jan 06, 2022 at 02:30:47PM -0800, Lucas De Marchi wrote:
> On Thu, Jan 06, 2022 at 03:58:50PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 05, 2022 at 04:36:53PM -0800, Lucas De Marchi wrote:
> > > When using QFLAG_APPLY_ONCE we make sure the quirk is called only once.
&g
s applied/
> So replace the uses of QFLAG_APPLY_ONCE with static local variables in
> the few quirks that use this logic and remove all the flags logic.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Bjorn Helgaas
> ---
>
> v3: Keep in this patch only the
On Fri, Jan 07, 2022 at 01:05:16PM -0800, Lucas De Marchi wrote:
> early_pci_scan_bus() does a depth-first traversal, possibly calling
> the quirk functions for each device based on vendor, device and class
> from early_qrk table. intel_graphics_quirks() however uses PCI_ANY_ID
> and does additiona
On Mon, Jan 10, 2022 at 12:11:36PM -0500, Rodrigo Vivi wrote:
> On Fri, Jan 07, 2022 at 08:57:32PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 07, 2022 at 01:05:16PM -0800, Lucas De Marchi wrote:
> > > early_pci_scan_bus() does a depth-first traversal, possibly calling
> &g
ace the uses of QFLAG_APPLY_ONCE with static local variables in
> the few quirks that use this logic and remove all the flags logic.
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: Bjorn Helgaas
Only occurred to me now, but another, less intrusive approach would be
to just r
On Wed, Jan 12, 2022 at 04:21:28PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 12, 2022 at 06:08:05PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 12, 2022 at 03:30:43PM -0800, Lucas De Marchi wrote:
> > > The flags are only used to mark a quirk to be called once and nothing
>
On Tue, Jan 18, 2022 at 06:26:48PM +0100, Borislav Petkov wrote:
> On Tue, Jan 18, 2022 at 08:36:56AM -0800, Lucas De Marchi wrote:
> > I had the impression the subject/title should be imperative, with it
> > more relaxed in the body. It seems we have one more difference among
> > subsystems and I
On Tue, Jan 18, 2022 at 07:37:29PM +0100, Borislav Petkov wrote:
> On Tue, Jan 18, 2022 at 11:58:53AM -0600, Bjorn Helgaas wrote:
> > I don't really care much one way or the other. I think the simplest
> > approach is to remove QFLAG_APPLY_ONCE from intel_graphics_quirks()
>
On Wed, Jan 19, 2022 at 12:30:04PM -0800, Lucas De Marchi wrote:
> On Tue, Jan 18, 2022 at 02:01:45PM -0600, Bjorn Helgaas wrote:
> > Haha :) I was hoping not to touch it myself because I think this
> > whole stolen memory thing is kind of nasty. It's not clear to me why
&
On Fri, Mar 11, 2022 at 12:06:38PM +0200, Jani Nikula wrote:
> early-quirks.c is the only user of drm/i915_drm.h that also needs
> drm/i915_pciids.h. Include the masses of PCI ID macros only where
> needed.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: x...@ke
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
tags/pci-v5.17-fixes-1
for you to fetch changes up to 9c494ca4d3a535
On Fri, Apr 10, 2020 at 05:56:13PM +0200, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki"
>
> Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
> matches its purpose more closely.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysock
On Sun, Aug 02, 2020 at 08:46:48PM +0200, Borislav Petkov wrote:
> On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> > Because the value ~0 has a meaning to some drivers and only
>
> No, ~0 means that the PCI read failed. For *every* PCI device I know.
Wait, I'm not convinced ye
Hi Sinan,
On Mon, Nov 27, 2017 at 11:57:37AM -0500, Sinan Kaya wrote:
> Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot()
> in order to remove domain 0 assumptions in the kernel.
>
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI devi
in
> Cc: Jarkko Sakkinen
> Cc: Jani Nikula
> Cc: Ben Skeggs
> Cc: Benjamin Tissoires
> Cc: Joerg Roedel
> Cc: Adrian Hunter
> Cc: Yisen Zhuang
> Cc: Bjorn Helgaas
> Cc: Zhang Rui
> Cc: Felipe Balbi
> Cc: Mathias Nyman
> Cc: Heikki Krogerus
> Cc
[+cc Intel DRM maintainers, etc]
On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> which are known to break.
Do you have a reference for this? Any public bug reports, bugzilla,
Intel spec reference or errata? "Which
On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> > > whi
On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> > > On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > > > On Wed, Sep 26, 2018
On Thu, Oct 11, 2018 at 03:11:01PM +0800, Bin Meng wrote:
> On Wed, Oct 10, 2018 at 1:02 AM Bjorn Helgaas wrote:
> > On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> > > On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > > > On Thu, Sep 27, 2018
On Mon, Jul 09, 2018 at 10:36:48AM +0200, Daniel Vetter wrote:
> Avoids the inverted condition compared to the open-coded version.
>
> Signed-off-by: Daniel Vetter
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
I assume you'll merge this
a few extra register defines from i915_reg.h, decouple the
> two by defining the required registers locally in quirks.c. This was
> already done for a few other igpu related registers.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Sign
> - use pr_debug(), pr_err() instead of the corresponding printk() (Rafael)
The version history is very useful during development but not after
merging, so I prefer it to go after the "---" marker so it doesn't get
included in the permanent changelog.
> Reported-by: Daniel Vet
age flags a breakage during the
> > driver's automated testing which parses dmesg and picks up the error.
> >
> > Reported-by: Daniel Vetter
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> > CC: Bjorn Helgaas
> > CC: Rafael J. Wysocki
kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource
---
Bjorn Helgaas (12):
PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
PCI: Don't assign or reassign immutable resources
PCI: Don't enable/disable ROM BAR if we're using a RAM shadow
IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set,
don't bother trying to assign or reassign the resource.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/setup-res.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/
If we're using a RAM shadow copy instead of the ROM BAR, we don't need to
touch the ROM BAR enable bit.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
ind
ed by pdev_sort_resources(), which already ignores
IORESOURCE_PCI_FIXED resources.
Link:
http://lkml.kernel.org/r/ca+55afyvmftbb0oz_yx8+eqoejnzgtcsysj9quhepdz9bhd...@mail.gmail.com
Signed-off-by: Bjorn Helgaas
---
arch/ia64/pci/fixup.c |3 ++-
arch/x86/pci/fixup.c |3 ++-
2 files chang
om the ROM BAR.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/pci/fixup.c | 22 --
arch/x86/pci/fixup.c | 22 --
drivers/pci/rom.c | 11 ---
include/linux/ioport.h |2 +-
4 files changed, 33 insertions(+), 24 deletions(-)
diff --git
Use a temporary struct resource pointer to avoid needless repetition of
"dev->resource[idx]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 10 +
arch/ia64/sn/kernel/io_init.c | 39 --
that ioremaps the copy.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 18 +++---
arch/ia64/sn/kernel/io_init.c | 17 +
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c
b/arch/ia
Remove unnecessary indentation in pci_map_rom(). This is logically part of
the previous patch; I split it out to make the critical changes in that
patch more obvious. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 37
.
Note that this makes it obvious that (a) we're putting a virtual address in
a struct resource, and (b) we're passing a virtual address to ioremap()
below in the PCI_ROM_RESOURCE case. These are both pre-existing problems
that I'll resolve next.
Signed-off-by: Bjorn Helgaas
---
arch
The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused.
Remove them and code that depends on them.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/remove.c |1 -
drivers/pci/rom.c | 31 +--
include/linux/ioport.h |2 --
3 files changed, 1
Use a temporary struct resource pointer to avoid needless repetition of
"pdev->resource[PCI_ROM_RESOURCE]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
_map_rom() will
ioremap() it as needed.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
index b66b1eb..c015ca1 100644
--- a/arch
The value of pdev->rom_attr is the definitive indicator of the fact that
we're created a sysfs attribute. Check that rather than rom_size, which is
only used incidentally when deciding whether to create a sysfs attribute.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-sysfs.
On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> The purpose of this series is to:
>
> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
> messages reported by Linus [1], Andy [2], and others.
>
> - Move arch-specific shadow
On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> >> The purpose of this series is to:
> >>
> >> - Fix the "BA
On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> The purpose of this series is to:
> ...
> - Move arch-specific shadow ROM location knowledge, e.g.,
> 0xC-0xD, from PCI core to arch code.
> ...
> Bjorn Helgaas (12):
> PCI: Mark shad
On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() functi
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 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 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
On Fri, Jun 09, 2023 at 03:09:26PM -0700, David E. Box wrote:
> Hi Bjorn,
>
> On Thu, 2023-06-08 at 15:52 -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2023 at 02:33:23PM -0700, David E. Box wrote:
> > > In commit f492edb40b54 ("PCI: vmd: Add quirk to configure PCIe
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 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
[+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
[+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; 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
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
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
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
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
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,
On Tue, Apr 11, 2023 at 02:33:23PM -0700, David E. Box wrote:
> In commit f492edb40b54 ("PCI: vmd: Add quirk to configure PCIe ASPM and
> LTR") the VMD driver calls pci_enabled_link_state as a callback from
> pci_bus_walk. Both will acquire the pci_bus_sem lock leading to a lockdep
> warning. Inste
ed-by: Takashi Iwai # sound/
> Reviewed-by: Jacek Lawrynowicz #
> drivers/accel/ivpu/
> Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/
> Reviewed-by: Rodrigo Vivi
Acked-by: Bjorn Helgaas # drivers/pci/
> -EXPORT_SYMBOL_GPL(pm_runtime_get_if_active);
> +EXPORT_SYMBOL_GPL(pm_ru
sound/
> Reviewed-by: Jacek Lawrynowicz #
> drivers/accel/ivpu/
> Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/
> Reviewed-by: Rodrigo Vivi
Acked-by: Bjorn Helgaas # drivers/pci/
- Previous PM history uses "PM: " in the subject lines (not "pm: ").
- I don
On Tue, Jan 23, 2024 at 08:44:04PM +, Sakari Ailus wrote:
> On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> ...
> > - I don't know whether it's feasible, but it would be nice if the
> > intel_pm_runtime_pm.c rework could be done in one shot
Hi David,
On Tue, Mar 21, 2023 at 04:38:49PM -0700, David E. Box wrote:
> The VMD driver calls pci_enabled_link_state as a callback from
> pci_bus_walk. Both will acquire the pci_bus_sem lock leading to a lockdep
> warning. Add an argument to pci_enable_link_state to set whether the lock
> should
On Wed, Mar 22, 2023 at 03:45:01PM -0500, Bjorn Helgaas wrote:
> Hi David,
>
> On Tue, Mar 21, 2023 at 04:38:49PM -0700, David E. Box wrote:
> > The VMD driver calls pci_enabled_link_state as a callback from
> > pci_bus_walk. Both will acquire the pci_bus_sem lock leading to
n RPL-P
> >
> > arch/x86/kernel/early-quirks.c| 19 +++---
>
> Bjorn, ack for merging this via drm-intel-next?
Sorry, I had ignored this because I didn't think it affected any PCI
stuff. This is fine with me:
Acked-by: Bjorn Helgaas
But since you asked :)
loses:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14834/bat-apl-1/boot0.txt
> Cc: Dave Jiang
> Cc: Bjorn Helgaas
> Signed-off-by: Dan Williams
> ---
> drivers/pci/probe.c | 7 ---
> include/linux/pci.h | 1 -
> 2 files changed, 4 insertions(+), 4 deletions(-)
tion()")
> Reported-by: Jani Saarinen
> Closes:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14834/bat-apl-1/boot0.txt
> Cc: Dave Jiang
> Cc: Bjorn Helgaas
> Signed-off-by: Dan Williams
Applied with Alison's reviewed-by and Jani's tested-by to for-linus
fo
f/0x170
>
> Switch to a shared static key for all instances.
>
> Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()")
> Reported-by: Jani Saarinen
> Closes:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14834/bat-apl-1/boot0.txt
> Cc: Dav
h_string(ecrc_policy_str, ARRAY_SIZE(ecrc_policy_str), str);
> + i = match_string(ecrc_policy_str, str);
> if (i < 0)
> return;
>
Acked-by: Bjorn Helgaas# drivers/pci/
> +++ b/mm/vmpressure.c
> @@ -388,7 +388,7 @@ int vmpressure_register_event(str
[+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> After a CPU upgrade while keeping the same mainboard,
> we faced "spurious interrupt" problems again.
>
> It turned out that the new CPU also featured a
> new GPU with a differen
On Fri, Apr 25, 2014 at 11:35:21AM -0600, Bjorn Helgaas wrote:
> [+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
>
> On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> > After a CPU upgrade while keeping the same mainboard,
> > we faced "spurious
On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
>> PCI resource allocation is undergoing some changes at the moment, it's
>> definitely a bug if the Flush Page isn't getting allocated. I'm looking
>> forward to hopefully getting pci_bus
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> Can you open a kernel.org bugzilla report and attach complete dmesg
>> logs of the working and broken kernels to it? There might be more
>> useful resource-rela
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> I wouldn't start bisecting yet, but if you're in the mood, this
>> commit: 96702be56037 "Merge branch 'pci/resource' into next" looks
>&g
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> Can you open a kernel.org bugzilla report and attach complete dmesg
>> logs of the working and broken kernels to it? There might be more
>> useful resource-rela
On Fri, Mar 07, 2014 at 06:16:49PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> > > This might end up not being relevant. And this is surely documented
> > > somewhere, b
On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle wrote:
> On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas wrote:
>> It seems quite possible that I broke pci_bus_alloc_resource(), which could
>> cause an allocation failure like this.
>>
>> If you have a chance to try it, h
On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas wrote:
> It seems quite possible that I broke pci_bus_alloc_resource(), which could
> cause an allocation failure like this.
>
> If you have a chance to try it, here's a debug patch against v3.14-rc5. It
> should apply cleanly
[+cc linux-pci]
On Sat, Mar 08, 2014 at 03:44:37PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]:
> > I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
> > legal); let me know if otherwise.
>
> $ grep CONFIG_PHYS_ADDR
[+cc Rafael]
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]:
>> Thanks. Can you try the patch below? I think it should fix the problem.
>>
>>
>> PCI: Don't check resource_size() in pci_bus_alloc_reso
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle wrote:
> On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
>> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
>> > A bit of doubt is caused by two new boot time messages:
>> > pnp 00:00: unknown resource type 10
ula
> Acked-by: Bjorn Helgaas
> Signed-off-by: Yijing Wang
> ---
> v4->v5: Add some detailed debug info for acpi_evaluate_object()
> failure suggested by Bjorn.
> v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> v2->v3: Fix compile error point
se.c |9 +
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 23 +--
> drivers/pci/pci-label.c|9 ++---
For the drivers/pci/pci-label.c part,
Acked-by: Bjorn Helgaas
> + status = acpi_evaluate_object(handle, &q
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki wrote:
> On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
>> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki
>> wrote:
>> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> >
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki wrote:
> On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
>> > Since acpi_evaluate_object() returns acpi_status and not plain int,
>> > ACPI_F
On Tue, Apr 21, 2015 at 11:07 AM, Linus Torvalds
wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog
[+cc Matthew]
On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 :00:02.0: BAR 6: [??? 0x00
On Fri, Aug 08, 2014 at 03:54:04PM +0200, Thomas Jarosch wrote:
> New Intel G3258 CPU, new MSI board, same problem:
> The GPU interrupt fired like crazy on monitor unplug.
>
> lspci output:
> 00:02.0 VGA compatible controller: Intel Corporation Device 0402 (rev 06)
> Subsystem: Micro-Star
chines. Apart from that we'll just let the normal
> pci pm code take care of everything for us.
>
> Cc: Bjorn Helgaas
> Cc: "Rafael J. Wysocki"
> Cc: Rodrigo Vivi
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Ville
On Wed, Sep 25, 2024 at 05:45:24PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the driver doesn't call pci_save_state() driver/pci will
> normally save+power manage the device from the _noirq() pm
> hooks.
drivers/pci. Or maybe just mention the PM hook names specifically.
> We can
On Thu, Sep 26, 2024 at 07:03:16PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2024 at 02:28:42PM -0500, Bjorn Helgaas wrote:
> > On Wed, Sep 25, 2024 at 05:45:21PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > On some older laptops i91
+++++------
> drivers/pci/pci-driver.c | 16 +++-
> 2 files changed, 94 insertions(+), 43 deletions(-)
> Cc: Bjorn Helgaas
> Cc: "Rafael J. Wysocki"
> Cc: Rodrigo Vivi
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-
: probe with driver e1000e failed with
> error -12
> `
> After bisecting the tree, the following patch [3] seems to be the first "bad"
> commit
>
> ````````
96 matches
Mail list logo
