Re: [PATCH] drm: Require PCI for selecting VGA_ARB.
On 1/8/19, Paul Menzel wrote: > Dear Maarten, > > > Thank you very much for the quick response. > > On 01/08/19 16:37, Maarten Lankhorst wrote: >> Op 08-01-2019 om 16:07 schreef Paul Menzel: > >>> Building Linux 5.0-rc1 fails with the errors below. Please find the >>> configuration file attached. >>> >>> ``` >>> $ make -j120 >>> […] >>> drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’: >>> drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’ >>> undeclared (first use in this function); did you mean >>> ‘PCI_SUBTRACTIVE_DECODE’? >>> flags |= PCI_VGA_STATE_CHANGE_DECODES; >>> ^~~~ >>> PCI_SUBTRACTIVE_DECODE >>> drivers/gpu/vga/vgaarb.c:286:14: note: each undeclared identifier is >>> reported only once for each function it appears in >>> CC [M] net/netfilter/xt_realm.o >>> CC drivers/hid/hid-cherry.o >>> drivers/gpu/vga/vga_switcheroo.c: In function >>> ‘vga_switcheroo_runtime_suspend’: >>> drivers/gpu/vga/vga_switcheroo.c:1053:2: error: implicit declaration of >>> function ‘pci_bus_set_current_state’; did you mean ‘__set_current_state’? >>> [-Werror=implicit-function-declaration] >>> pci_bus_set_current_state(pdev->bus, PCI_D3cold); >>> ^ >>> __set_current_state >>> drivers/gpu/vga/vgaarb.c:291:13: error: ‘PCI_VGA_STATE_CHANGE_BRIDGE’ >>> undeclared (first use in this function); did you mean >>> ‘PCI_VGA_STATE_CHANGE_DECODES’? >>> flags |= PCI_VGA_STATE_CHANGE_BRIDGE; >>> ^~~ >>> PCI_VGA_STATE_CHANGE_DECODES >>> CC fs/reiserfs/dir.o >>> LD [M] net/tipc/tipc.o >>> drivers/gpu/vga/vga_switcheroo.c: In function >>> ‘vga_switcheroo_runtime_resume’: >>> drivers/gpu/vga/vga_switcheroo.c:1067:2: error: implicit declaration of >>> function ‘pci_wakeup_bus’; did you mean ‘__wake_up_bit’? >>> [-Werror=implicit-function-declaration] >>> pci_wakeup_bus(pdev->bus); >>> ^~ >>> __wake_up_bit >>> drivers/gpu/vga/vgaarb.c:293:3: error: implicit declaration of function >>> ‘pci_set_vga_state’; did you mean ‘pci_set_power_state’? >>> [-Werror=implicit-function-declaration] >>>pci_set_vga_state(conflict->pdev, false, pci_bits, flags); >>>^ >>>pci_set_power_state >>> CC fs/read_write.o >>> CC drivers/hid/hid-chicony.o >>> CC drivers/hid/hid-cypress.o >>> drivers/gpu/vga/vgaarb.c: In function ‘vga_arb_device_init’: >>> drivers/gpu/vga/vgaarb.c:1495:25: error: ‘pci_bus_type’ undeclared (first >>> use in this function); did you mean ‘pci_pcie_type’? >>> bus_register_notifier(_bus_type, _notifier); >>> ^~~~ >>> pci_pcie_type >>> cc1: some warnings being treated as errors >>> make[3]: *** [scripts/Makefile.build:277: drivers/gpu/vga/vgaarb.o] Error >>> 1 >>> make[3]: *** Waiting for unfinished jobs >>> […] >>> ``` > >> WARNING: unmet direct dependencies detected for VGA_ARB >> Depends on [n]: HAS_IOMEM [=y] && PCI [=n] && !S390 >> Selected by [y]: >> - VGA_SWITCHEROO [=y] && HAS_IOMEM [=y] && X86 [=y] && ACPI [=y] >> >> So I guess you need to enable PCI, probably not a common config you're >> using. :) >> >> Especially since you selected EXPERT. > > We have the attached defconfig, which is then integrated using > `make olddefconfig`. > >> Oh well, apply this with git am --scissors? >> -8< >> When configuring the kernel without PCI we can still enable VGA >> switcheroo, >> which is not possible because VGA_ARB cannot be selected. >> >> Remove this by depending on PCI for !S390. >> >> Reported-by: Paul Menzel >> Signed-off-by: Maarten Lankhorst >> --- >> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig >> index b677e5d524e6..ef5671475870 100644 >> --- a/drivers/gpu/vga/Kconfig >> +++ b/drivers/gpu/vga/Kconfig >> @@ -21,6 +21,7 @@ config VGA_SWITCHEROO >> bool "Laptop Hybrid Graphics - GPU switching support" >> depends on X86 >> depends on ACPI >> +depends on (PCI && !S390) # For VGA_ARB >> select VGA_ARB >> help >>Many laptops released in 2008/9/10 have two GPUs with a multiplexer > > Is this an effect of commit eb01d42a (PCI: consolidate PCI config entry in > drivers/pci) as the `default y` is missing now? > See this : https://patchwork.kernel.org/patch/10749209/ This change is about to go in. > > Kind regards, > > Paul > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
Acked-by: Daniel Vetter
---
drivers/gpu/vga/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
index b677e5d524e6..d5f1d8e1c6f8 100644
--- a/drivers/gpu/vga/Kconfig
+++ b/drivers/gpu/vga/Kconfig
@@ -21,6 +21,7 @@ config VGA_SWITCHEROO
bool "Laptop Hybrid Graphics - GPU switching support"
depends on X86
depends on ACPI
+ depends on PCI
select VGA_ARB
help
Many laptops released in 2008/9/10 have two GPUs with a multiplexer
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
Acked-by: Daniel Vetter
---
drivers/gpu/vga/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
index b677e5d524e6..d5f1d8e1c6f8 100644
--- a/drivers/gpu/vga/Kconfig
+++ b/drivers/gpu/vga/Kconfig
@@ -21,6 +21,7 @@ config VGA_SWITCHEROO
bool "Laptop Hybrid Graphics - GPU switching support"
depends on X86
depends on ACPI
+ depends on PCI
select VGA_ARB
help
Many laptops released in 2008/9/10 have two GPUs with a multiplexer
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
Acked-by: Daniel Vetter
---
drivers/gpu/vga/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
index b677e5d524e6..d5f1d8e1c6f8 100644
--- a/drivers/gpu/vga/Kconfig
+++ b/drivers/gpu/vga/Kconfig
@@ -21,6 +21,7 @@ config VGA_SWITCHEROO
bool "Laptop Hybrid Graphics - GPU switching support"
depends on X86
depends on ACPI
+ depends on PCI
select VGA_ARB
help
Many laptops released in 2008/9/10 have two GPUs with a multiplexer
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not been explicitly called out. Signed-off-by: Sinan Kaya Reviewed-by: Lukas Wunner --- drivers/gpu/vga/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig index b677e5d524e6..d5f1d8e1c6f8 100644 --- a/drivers/gpu/vga/Kconfig +++ b/drivers/gpu/vga/Kconfig @@ -21,6 +21,7 @@ config VGA_SWITCHEROO bool "Laptop Hybrid Graphics - GPU switching support" depends on X86 depends on ACPI + depends on PCI select VGA_ARB help Many laptops released in 2008/9/10 have two GPUs with a multiplexer -- 2.19.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
On 12/23/2018 8:15 PM, Lukas Wunner wrote:
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
This series doesn't have a cover letter so it's unclear to me through
which tree it's supposed to go in? Each patch through the individual
subsystem tree or all through the same tree? If the former I guess I
could push this to drm-misc...
Feel free to apply individual patches independently. Let me know which
one you applied so that I can drop them on the next rev.
I've realized only now that this patch fixes fallout of commit
5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
which is part of Rafael's acpi pull for v4.21.
Usually such fixes go through the same tree as the offending commit,
so I'd expect Raphael to pick up the whole series and forward it to
Linus in the second half of the merge window. I'm not sure if that's
how it'll play out though given the holidays.
I'll do follow-up with Rafael. Apologize for not giving the full story.
Trying to get pieces out in the middle of vacation as there was a breakage.
I didn't have time to polish.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote: > > On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote: > > This driver depends on the PCI infrastructure but the dependency has not > > been explicitly called out. > > > > Signed-off-by: Sinan Kaya > > Reviewed-by: Lukas Wunner > > This series doesn't have a cover letter so it's unclear to me through > which tree it's supposed to go in? Each patch through the individual > subsystem tree or all through the same tree? If the former I guess I > could push this to drm-misc... > Feel free to apply individual patches independently. Let me know which one you applied so that I can drop them on the next rev. > Thanks, > > Lukas > > > --- > > drivers/gpu/vga/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig > > index b677e5d524e6..d5f1d8e1c6f8 100644 > > --- a/drivers/gpu/vga/Kconfig > > +++ b/drivers/gpu/vga/Kconfig > > @@ -21,6 +21,7 @@ config VGA_SWITCHEROO > > bool "Laptop Hybrid Graphics - GPU switching support" > > depends on X86 > > depends on ACPI > > + depends on PCI > > select VGA_ARB > > help > > Many laptops released in 2008/9/10 have two GPUs with a multiplexer > > -- > > 2.19.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not been explicitly called out. Signed-off-by: Sinan Kaya Reviewed-by: Lukas Wunner --- drivers/gpu/vga/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig index b677e5d524e6..d5f1d8e1c6f8 100644 --- a/drivers/gpu/vga/Kconfig +++ b/drivers/gpu/vga/Kconfig @@ -21,6 +21,7 @@ config VGA_SWITCHEROO bool "Laptop Hybrid Graphics - GPU switching support" depends on X86 depends on ACPI + depends on PCI select VGA_ARB help Many laptops released in 2008/9/10 have two GPUs with a multiplexer -- 2.19.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not been explicitly called out. Signed-off-by: Sinan Kaya --- drivers/gpu/vga/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig index b677e5d524e6..d5f1d8e1c6f8 100644 --- a/drivers/gpu/vga/Kconfig +++ b/drivers/gpu/vga/Kconfig @@ -21,6 +21,7 @@ config VGA_SWITCHEROO bool "Laptop Hybrid Graphics - GPU switching support" depends on X86 depends on ACPI + depends on PCI select VGA_ARB help Many laptops released in 2008/9/10 have two GPUs with a multiplexer -- 2.19.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 6/25/2018 11:52 AM, ok...@codeaurora.org wrote: >> Note that this is not the only MMIO translation related change made by >> Heyi Guo to the generic PCI host bridge and bus drivers, but given >> that those did not support MMIO translation at all, I take it your >> affected platforms will already have their own changes to accommodate >> this. > > Platform has been doing mmio translation for quite a while. Because all > accesses go through pci io protocol, the rest of the UEFI never needed to be > aware of bar address or do direct access. > > This is the first time I hear of direct access. Maybe, GOP is a special case. > > I started copying your response to the bios vendor. > > They are probably missing that patch. I will pass it along. I was informed that they fixed the issue in BIOS by presenting CPU physical address instead of PCI bus address in FrameBufferBase of the AST GOP UEFI driver. We can drop this patch now. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 6/25/2018 1:29 PM, Ard Biesheuvel wrote: >>> Platform has been doing mmio translation for quite a while. Because all >>> accesses go through pci io protocol, the rest of the UEFI never needed to >>> be aware of bar address or do direct access. >>> >>> This is the first time I hear of direct access. Maybe, GOP is a special >>> case. >>> >>> I started copying your response to the bios vendor. >>> >>> They are probably missing that patch. I will pass it along. >> I was informed that they fixed the issue in BIOS by presenting CPU physical >> address instead of PCI bus address in FrameBufferBase of the AST GOP UEFI >> driver. >> >> We can drop this patch now. >> > Excellent! Thanks for following up with the vendor ... > Sure, appreciate the help. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 6/22/2018 2:01 PM, Ard Biesheuvel wrote: >> Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is >> described as >> >> """ >> Base address of graphics linear frame buffer. Info contains >> information required to allow software to draw directly to the >> frame buffer without using Blt().Offset zero in >> FrameBufferBase represents the upper left pixel of the >> display. >> """ > I just tried AMD Radeon and NVidia graphics cards on a system with > non-1:1 mapped MMIO windows, and in both cases, the GOP protocol > structure is populated correctly, i.e., using the CPU address not the > PCIe address. > > EDK2 only recently gained support for MMIO translation in the host > bridge driver, so I so wonder if this is a platform issue rather than > a driver issue. It may be worth a try to dump the results of > GetBarAttributes() of all PCI I/O protocol instances (either in UEFI > or in the stub), to double check that the correct values are returned. > Thanks for checking out other platforms. I'll mark the issue as a BIOS issue and bounce your feedback to the BIOS provider. Let's hold onto this patch for the moment. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Ard, On 6/22/2018 7:21 AM, Ard Biesheuvel wrote: > Apologies for only bringing this up now, but I think this patch is > wrong after all. > > screen_info.lfb_base is supposed to be a CPU address, and so > translating it like this is wrong. If you end up with a PCI address > here, you have made a mistake in hacking support for PCI outbound > translations into UEFI. Other users such as UEFI itself or GRUB will > treat this as a CPU physical address as well, so the kernel should not > treat it any differently. The behavior I'm seeing is from a UEFI BIOS vendor. I did not write the code for it... I was asked to debug it. I'd like to dive into your statement about UEFI and GRUB using this address as physical addresses. AFAIK, all PCI outbound requests go through PCI IO protocol in UEFI and the translation information is hidden inside the UEFI PCI Host Bridge driver. Drivers are not allowed to access PCI resources directly especially as a memory mapped address. This particular vendor is programming the BAR address into the GOP protocol. Since the host bridge driver is doing a translation, we are hitting this issue. Is there a UEFI spec reference about the definition of this field? Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Bjorn, On 6/19/2018 5:59 PM, Bjorn Helgaas wrote: > On Fri, May 18, 2018 at 10:20:29AM -0400, Sinan Kaya wrote: >> On 5/18/2018 6:42 AM, Robin Murphy wrote: >>> >>> FWIW, now that I've actually gone and looked, it appears you could simplify >>> the whole function quite a bit by getting rid of these and just using the >>> new local resource directly, especially since the only actual use of size >>> is an open-coded resource_contains(). >> >> Posted V2 a minute ago. I did the simplification on a prior patch in order >> not to >> mix the issues. > > I don't see the V2 on linux-pci, but it sounds like Ard would merge this > anyway. So I'll drop this and you can let me know if there's anything you > need from me. > It is planned to go through fbdev tree for 4.19. https://patchwork.kernel.org/patch/10410895/ Feel free to review/ACK. Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Ard, On 5/18/2018 10:17 AM, Sinan Kaya wrote: > A host bridge is allowed to remap BAR addresses using _TRA attribute in > _CRS windows. > > pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] > (bus address [0x0010-0x1fff]) > pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] > > When a VGA device is behind such a host bridge and the resource is > translated efifb driver is trying to do ioremap against bus address > rather than the resource address and is failing to probe. > > efifb: probing for efifb > efifb: cannot reserve video memory at 0x1e00 > efifb: framebuffer at 0x1e00, using 1920k, total 1875k > efifb: mode is 800x600x32, linelength=3200, pages=1 > efifb: scrolling: redraw > efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > Use the host bridge offset information to convert bus address to > resource address in the fixup. > > Signed-off-by: Sinan Kaya > --- I didn't see any messages about these getting picked up for 4.18. Are they queued on your own branch? Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 1/2] efi/fb: Simplify fixup code to prefer struct resource
Get rid of base and size variables in favor of a struct resource.
The conditional for checking window can be replaced with
resource_contains().
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/efifb.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..6daac8d 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -426,17 +426,20 @@ static void record_efifb_bar_resource(struct pci_dev
*dev, int idx, u64 offset)
static void efifb_fixup_resources(struct pci_dev *dev)
{
- u64 base = screen_info.lfb_base;
- u64 size = screen_info.lfb_size;
+ struct resource screen_res = {
+ .start = screen_info.lfb_base,
+ .end = screen_info.lfb_base + screen_info.lfb_size - 1,
+ .flags = IORESOURCE_MEM,
+ };
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
return;
if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
- base |= (u64)screen_info.ext_lfb_base << 32;
+ screen_res.start |= (u64)screen_info.ext_lfb_base << 32;
- if (!base)
+ if (!screen_res.start)
return;
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
@@ -445,8 +448,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!(res->flags & IORESOURCE_MEM))
continue;
- if (res->start <= base && res->end >= base + size - 1) {
- record_efifb_bar_resource(dev, i, base - res->start);
+ if (resource_contains(res, _res)) {
+ u64 win_offset = screen_res.start - res->start;
+
+ record_efifb_bar_resource(dev, i, win_offset);
break;
}
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
(bus address [0x0010-0x1fff])
pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e00
efifb: framebuffer at 0x1e00, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/efifb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 6daac8d..429cc85 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -431,6 +431,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
.end = screen_info.lfb_base + screen_info.lfb_size - 1,
.flags = IORESOURCE_MEM,
};
+ struct pci_bus_region region;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -442,6 +443,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!screen_res.start)
return;
+ region.start = screen_res.start;
+ region.end = screen_res.end;
+ pcibios_bus_to_resource(dev->bus, _res, );
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = >resource[i];
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 5/18/2018 6:42 AM, Robin Murphy wrote: > > FWIW, now that I've actually gone and looked, it appears you could simplify > the whole function quite a bit by getting rid of these and just using the new > local resource directly, especially since the only actual use of size is an > open-coded resource_contains(). Posted V2 a minute ago. I did the simplification on a prior patch in order not to mix the issues. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 5/17/2018 6:17 AM, Robin Murphy wrote: >> + } >> + > > Is this not pretty much just pcibios_bus_to_resource()? > Agreed, let me convert the code to use pcibios_bus_to_resource() API. I wasn't aware of its existence. > Robin. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
(bus address [0x0010-0x1fff])
pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb driver is having difficulty locating the base address from BAR
address when
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e00
efifb: framebuffer at 0x1e00, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/efifb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..ea68d5c 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
+ struct pci_bus_region region;
+ struct resource res;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -439,6 +441,14 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!base)
return;
+ region.start = base;
+ region.end = base + size - 1;
+ res.start = 0;
+ res.flags = IORESOURCE_MEM;
+ pcibios_bus_to_resource(dev->bus, , );
+ if (res.start)
+ base = res.start;
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = >resource[i];
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 5/16/2018 2:31 PM, Timur Tabi wrote: > On 05/16/2018 01:23 PM, Sinan Kaya wrote: >> + win_start = window->res->start - window->offset; > > Can you guarantee that window->res->start is always >= window->offset? > Resource offset is generally 0 when not translating or a positive number that you subtract from the resource start to reach to the translating window. Having a bigger offset than resource start should be considered a BIOS bug. >> + win_size = window->res->end - window->res->start + 1; > > Use resource_size() instead. > I'll fix it. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
(bus address [0x0010-0x1fff])
pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb driver is having difficulty locating the base address from BAR
address when
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e00
efifb: framebuffer at 0x1e00, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/efifb.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..feef02b 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
+ struct pci_host_bridge *bridge;
+ struct resource_entry *window;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -439,6 +441,27 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!base)
return;
+ bridge = pci_find_host_bridge(dev->bus);
+ if (!bridge)
+ return;
+
+ resource_list_for_each_entry(window, >windows) {
+ phys_addr_t win_start;
+ phys_addr_t win_end;
+ size_t win_size;
+
+ if (resource_type(window->res) != IORESOURCE_MEM)
+ continue;
+
+ win_start = window->res->start - window->offset;
+ win_end = window->res->end - window->offset;
+ win_size = window->res->end - window->res->start + 1;
+ if (win_start <= base && win_end >= base + win_size - 1) {
+ base += window->offset;
+ break;
+ }
+ }
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = >resource[i];
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 5/16/2018 2:23 PM, Sinan Kaya wrote:
> + if (win_start <= base && win_end >= base + win_size - 1) {
> + base += window->offset;
> + break;
> + }
I should probably add window->offset!=0 to the if statement in order not to
break non-translating case.
Any other comments?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/prime: Iterate SG DMA addresses separately
On 4/30/2018 9:54 AM, Robin Murphy wrote: > For dma_map_sg(), DMA API implementations are free to merge consecutive > segments into a single DMA mapping if conditions are suitable, thus the > resulting DMA addresses which drm_prime_sg_to_page_addr_arrays() > iterates over may be packed into fewer entries than sgt->nents implies. > > The current implementation does not account for this, meaning that its > callers either have to reject the 0 < count < nents case or risk getting > bogus DMA addresses beyond the first segment. Fortunately this is quite > easy to handle without having to rejig structures to also store the > mapped count, since the total DMA length should still be equal to the > total buffer length. All we need is a second scatterlist cursor to > iterate through the DMA addresses independently of the page addresses. > > Reviewed-by: Christian König <christian.koe...@amd.com> > Signed-off-by: Robin Murphy <robin.mur...@arm.com> > --- Much better Tested-by: Sinan Kaya <ok...@codeauora.org> for the first two patches. (1/3 and 2/3) -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing
On 4/27/2018 11:54 AM, Robin Murphy wrote:
>
>> ubuntu@ubuntu:~/amdgpu$_./vectoradd_hip.exe
>> [ 834.002206] create_process:620
>> [ 837.413021] Unable to handle kernel NULL pointer dereference at virtual
>> address 0018
>
> £5 says that's sg_dma_len(NULL), which implies either that something's gone
> horribly wrong with the scatterlist DMA mapping such that the lengths don't
> match, or much more likely that ttm.dma_address is NULL and I've missed the
> tiny subtlety below. Does that fix matters?
Turned out to be a null pointer problem after sg_next(). The following helped.
+ if (addrs && (dma_len == 0)) {
dma_sg = sg_next(dma_sg);
- dma_len = sg_dma_len(dma_sg);
- addr = sg_dma_address(dma_sg);
+ if (dma_sg) {
+ dma_len = sg_dma_len(dma_sg);
+ addr = sg_dma_address(dma_sg);
+ }
}
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing
On 4/27/2018 11:54 AM, Robin Murphy wrote: >> I'm taking this back. I observed a crash with the HSA applications: > > FWIW, was this working before, or is this somewhere new that we're only > reaching now that pin_userpages can succeed? Yes, HSA application is a different test. Previous DRM library unit test is still passing. It must have some unique characteristic. I'll test your patch and report. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing
On 4/17/2018 5:13 PM, Sinan Kaya wrote: > Tested-by: Sinan Kaya <ok...@codeaurora.org> > > using QDF2400 and XFX Vega64 GPU for the first two patches. > > ./builddir/tests/amdgpu/amdgpu_test -s 1 > > Suite: Basic Tests > Test: Userptr Test ...passed > > Userptr Test fails without this patch. I'm taking this back. I observed a crash with the HSA applications: ubuntu@ubuntu:~/amdgpu$_./vectoradd_hip.exe [ 834.002206] create_process:620 [ 837.413021] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 837.414097] user pgtable: 4k pages, 48-bit VAs, pgd = 8d448000 [ 837.427034] [0018] *pgd=0a424003, *pud=0e0b3003, *pmd= [ 837.427414] Internal error: Oops: 9606 [#1] SMP [ 837.427744] Modules linked in: [ 837.457060] CPU: 3 PID: 2321 Comm: vectoradd_hip.e Not tainted 4.13.0 #5 [ 837.463076] task: 8dfb0d80 task.stack: 8e17c000 [ 837.473795] PC is at drm_prime_sg_to_page_addr_arrays+0xac/0xec [ 837.482877] LR is at drm_prime_sg_to_page_addr_arrays+0xac/0xec [ 837.491910] pc : [] lr : [] pstate: 80400149 [ 837.492022] sp : 8e17f850 [ 837.492115] x29: 8e17f850 x28: 8d586700 [ 837.516635] x27: x26: e10410004000 [ 837.526444] x25: 8cb91880 x24: 0002 [ 837.534974] x23: 8cb91910 x22: 8cb91900 [ 837.535178] x21: 0002 x20: [ 837.535340] x19: 8cb91880 x18: d278 [ 837.560498] x17: bef39240 x16: 081bb868 [ 837.560684] x15: bf6fe000 x14: [ 837.574764] x13: x12: [ 837.51] x11: 0001 x10: 8a449038 [ 837.593181] x9 : x8 : 8cb91980 [ 837.604606] x7 : x6 : 003f [ 837.612801] x5 : 0040 x4 : [ 837.617425] x3 : 0002 x2 : [ 837.625768] x1 : 0002 x0 : [ 838.516100] [] drm_prime_sg_to_page_addr_arrays+0xac/0xec [ 838.516385] [] amdgpu_ttm_tt_populate+0x80/0xe8 [ 838.545137] [] ttm_tt_bind+0x3c/0x7c [ 838.558468] [] ttm_bo_handle_move_mem+0x12c/0x340 [ 838.562518] [] ttm_bo_validate+0x90/0x100 [ 838.572370] [] ttm_bo_init_reserved+0x25c/0x324 [ 838.582103] [] amdgpu_bo_do_create+0x140/0x3e4 [ 838.591609] [] amdgpu_bo_create+0x40/0x15c [ 838.601034] [] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x36c/0x80c [ 838.609631] [] kfd_ioctl_alloc_memory_of_gpu+0xfc/0x180 [ 838.621500] [] kfd_ioctl+0x144/0x1e8 [ 838.632253] [] vfs_ioctl+0x18/0x40 [ 838.641592] [] do_vfs_ioctl+0x5ac/0x6bc [ 838.649349] [] SyS_ioctl+0x5c/0x8c [ 838.649609] [] el0_svc_naked+0x24/0x28 [ 838.649776] Code: 17f1 35d4 aa1903e0 97fab3f6 (b9401814) [ 838.672742] ---[ end trace fb2627bd4d4c9818 ]--- Robin, if you want to debug this; feel free to send me a debug patch. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing
On 4/17/2018 11:58 AM, Robin Murphy wrote: > The amdgpu driver doesn't appear to directly use the scatterlist mapped > by amdgpu_ttm_tt_pin_userptr(), it merely hands it off to > drm_prime_sg_to_page_addr_arrays() to generate the dma_address array > which it actually cares about. Now that the latter can cope with > dma_map_sg() coalescing dma-contiguous segments such that it returns > 0 < count < nents, we can relax the current count == nents check to > only consider genuine failure as other drivers do. > > This avoids a false negative on arm64 systems with an IOMMU. > > Reported-by: Sinan Kaya <ok...@codeaurora.org> > Signed-off-by: Robin Murphy <robin.mur...@arm.com> > --- > > v2: Expand commit message to clarify > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 205da3ff9cd0..f81e96a4242f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -813,7 +813,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) > > r = -ENOMEM; > nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction); > - if (nents != ttm->sg->nents) > + if (nents == 0) > goto release_sg; > > drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, > Tested-by: Sinan Kaya <ok...@codeaurora.org> using QDF2400 and XFX Vega64 GPU for the first two patches. ./builddir/tests/amdgpu/amdgpu_test -s 1 Suite: Basic Tests Test: Userptr Test ...passed Userptr Test fails without this patch. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers
On 4/11/2018 8:03 AM, Robin Murphy wrote:
> On 10/04/18 21:59, Sinan Kaya wrote:
>> Code is expecing to observe the same number of buffers returned from
>> dma_map_sg() function compared to sg_alloc_table_from_pages(). This
>> doesn't hold true universally especially for systems with IOMMU.
>
> So why not fix said code? It's clearly not a real hardware limitation, and
> the map_sg() APIs have potentially returned fewer than nents since forever,
> so there's really no excuse.
Sure, I'll take a better fix if there is one.
>
>> IOMMU driver tries to combine buffers into a single DMA address as much
>> as it can. The right thing is to tell the DMA layer how much combining
>> IOMMU can do.
>
> Disagree; this is a dodgy hack, since you'll now end up passing scatterlists
> into dma_map_sg() which already violate max_seg_size to begin with, and I
> think a conscientious DMA API implementation would be at rights to fail the
> mapping for that reason (I know arm64 happens not to, but that was a
> deliberate design decision to make my life easier at the time).
>
> As a short-term fix, at least do something like what i915 does and constrain
> the table allocation to the desired segment size as well, so things remain
> self-consistent. But still never claim that faking a hardware constraint as a
> workaround for a driver shortcoming is "the right thing to do" ;)
You are asking for something like this from here, right?
https://elixir.bootlin.com/linux/v4.16.1/source/drivers/gpu/drm/i915/i915_gem_dmabuf.c#L58
ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
if (ret)
goto err_free;
src = obj->mm.pages->sgl;
dst = st->sgl;
for (i = 0; i < obj->mm.pages->nents; i++) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
src = sg_next(src);
}
This seems to allocate the scatter gather list and fill it in manually before
passing it
to dma_map_sg(). I'll give it a try.
Just double checking.
>
> Robin.
>
>> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers
Code is expecing to observe the same number of buffers returned from
dma_map_sg() function compared to sg_alloc_table_from_pages(). This
doesn't hold true universally especially for systems with IOMMU.
The hardware actually needs the dma_address on a page by page basis.
Joining multiple consecutive pages into one entry is just additional
overhead which we don't need.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index af1b879..91abe1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1948,6 +1948,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* init the mode config */
drm_mode_config_init(adev->ddev);
+ /* limit scatter-gather buffer size to PAGE_SIZE */
+ dma_set_max_seg_size(adev->dev, PAGE_SIZE);
+
r = amdgpu_device_ip_init(adev);
if (r) {
/* failed in exclusive mode due to timeout */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers
Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially for systems with IOMMU. IOMMU driver tries to combine buffers into a single DMA address as much as it can. The right thing is to tell the DMA layer how much combining IOMMU can do. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index e4bb435..02465cd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -787,6 +787,8 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) enum dma_data_direction direction = write ? DMA_BIDIRECTIONAL : DMA_TO_DEVICE; + dma_set_max_seg_size(adev->dev, PAGE_SIZE); + r = sg_alloc_table_from_pages(ttm->sg, ttm->pages, ttm->num_pages, 0, ttm->num_pages << PAGE_SHIFT, GFP_KERNEL); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers
Code is expecing to observe the same number of buffers returned from
dma_map_sg() function compared to sg_alloc_table_from_pages(). This
doesn't hold true universally especially for systems with IOMMU.
IOMMU driver tries to combine buffers into a single DMA address as much
as it can. The right thing is to tell the DMA layer how much combining
IOMMU can do.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 +
4 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 8e28270..1b031eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -851,7 +851,7 @@ static int gmc_v6_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
dev_warn(adev->dev, "amdgpu: No coherent DMA available.\n");
}
-
+ dma_set_max_seg_size(adev->dev, PAGE_SIZE);
r = gmc_v6_0_init_microcode(adev);
if (r) {
dev_err(adev->dev, "Failed to load mc firmware!\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 86e9d682..0a4b2cc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -999,6 +999,7 @@ static int gmc_v7_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+ dma_set_max_seg_size(adev->dev, PAGE_SIZE);
r = gmc_v7_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 9a813d8..b171529 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1096,6 +1096,7 @@ static int gmc_v8_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+ dma_set_max_seg_size(adev->dev, PAGE_SIZE);
r = gmc_v8_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 3b7e7af..36e658ab 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -855,6 +855,7 @@ static int gmc_v9_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
printk(KERN_WARNING "amdgpu: No coherent DMA available.\n");
}
+ dma_set_max_seg_size(adev->dev, PAGE_SIZE);
r = gmc_v9_0_mc_init(adev);
if (r)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 09/26] drm/nouveau: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:37 AM, 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() function in favor of
> pci_get_domain_bus_and_slot().
>
> Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
> and extract the domain number from
> 1. struct pci_dev
> 2. struct pci_dev through drm_device->pdev
> 3. struct pci_dev through fb->subdev->drm_device->pdev
>
> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
> drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
> drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
> 4 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> index 90075b6..c79160c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> @@ -213,8 +213,10 @@ struct nv_sim_state {
> if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
> (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
> uint32_t type;
> + int domain = pci_domain_nr(dev->pdev->bus);
>
> - pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
> + 0x7c, );
>
> sim_data.memory_type = (type >> 12) & 1;
> sim_data.memory_width = 64;
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> index b985990..0c9bdf0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> @@ -216,12 +216,15 @@
> {
> struct nvkm_pll_vals pllvals;
> int ret;
> + int domain;
> +
> + domain = pci_domain_nr(dev->pdev->bus);
>
> if (plltype == PLL_MEMORY &&
> (dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
> uint32_t mpllP;
> -
> - pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
> + 0x6c, );
> mpllP = (mpllP >> 8) & 0xf;
> if (!mpllP)
> mpllP = 4;
> @@ -232,7 +235,8 @@
> (dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
> uint32_t clock;
>
> - pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
> + 0x4c, );
> return clock / 1000;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 8d4a5be..33b6139 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -524,7 +524,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> }
>
> /* subfunction one is a hdmi audio device? */
> - drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
> + drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> + (unsigned int)pdev->bus->number,
>
> PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
>
> if (!drm->hdmi_device) {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> index 4c07d10..18241c6 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> @@ -28,8 +28,16 @@
> {
> struct pci_dev *bridge;
> u32 mem, mib;
> + int domain = 0;
> + struct pci_dev *pdev = NULL;
>
> - bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
> + if (dev_is_pci(fb->subdev.device->dev))
> + pdev = to_pci_dev(fb->subdev.device->dev);
> +
> + if (pdev)
> + domain = pci_domain_nr(pdev->bus);
> +
> + bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
> if (!bridge) {
> nvkm_error(>subdev, "no bridge device\n");
> return -ENODEV;
>
Any feedback here? I don't have any hardware to test the changes. I just did a
compile test.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:38 AM, 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() function in favor of > pci_get_domain_bus_and_slot(). > > struct riva_par has a pointer to struct pci_dev. Use the pci_dev member > to extract the domain information. > > Change the function signature for CalcStateExt and RivaGetConfig to pass > in struct pci_dev in addition to RIVA_HW_INST so that code inside the > riva_hw.c can also calculate domain number and pass it to > pci_get_domain_bus_and_slot(). > > Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Any feedback here, most of the remaining patches have the ACK except these? -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:37 AM, 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() function in favor of > pci_get_domain_bus_and_slot(). > > Find the domain number from pdev. > > Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Any feedback here ? most of the remaining patches have the ACK except these. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
On 12/19/2017 12:37 AM, 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() function in favor of > pci_get_domain_bus_and_slot(). > > struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev > member to extract the domain information and pass it to > pci_get_domain_bus_and_slot() function. > > Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Any feedback here ? most of the remaining patches have the ACK except these. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Find the domain number from pdev.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/intelfb/intelfbhw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/intelfb/intelfbhw.c
b/drivers/video/fbdev/intelfb/intelfbhw.c
index 83fec57..57aff74 100644
--- a/drivers/video/fbdev/intelfb/intelfbhw.c
+++ b/drivers/video/fbdev/intelfb/intelfbhw.c
@@ -181,7 +181,9 @@ int intelfbhw_get_memory(struct pci_dev *pdev, int
*aperture_size,
return 1;
/* Find the bridge device. It is always 0:0.0 */
- if (!(bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0 {
+ bridge_dev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus), 0,
+PCI_DEVFN(0, 0));
+ if (!bridge_dev) {
ERR_MSG("cannot find bridge device\n");
return 1;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 09/26] drm/nouveau: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from
1. struct pci_dev
2. struct pci_dev through drm_device->pdev
3. struct pci_dev through fb->subdev->drm_device->pdev
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..c79160c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -213,8 +213,10 @@ struct nv_sim_state {
if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
+ int domain = pci_domain_nr(dev->pdev->bus);
- pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, );
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..0c9bdf0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -216,12 +216,15 @@
{
struct nvkm_pll_vals pllvals;
int ret;
+ int domain;
+
+ domain = pci_domain_nr(dev->pdev->bus);
if (plltype == PLL_MEMORY &&
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
-
- pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, );
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +235,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
- pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, );
return clock / 1000;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 8d4a5be..33b6139 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -524,7 +524,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
/* subfunction one is a hdmi audio device? */
- drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 4c07d10..18241c6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -28,8 +28,16 @@
{
struct pci_dev *bridge;
u32 mem, mib;
+ int domain = 0;
+ struct pci_dev *pdev = NULL;
- bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+ if (dev_is_pci(fb->subdev.device->dev))
+ pdev = to_pci_dev(fb->subdev.device->dev);
+
+ if (pdev)
+ domain = pci_domain_nr(pdev->bus);
+
+ bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(>subdev, "no bridge device\n");
return -ENODEV;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
struct riva_par has a pointer to struct pci_dev. Use the pci_dev member
to extract the domain information.
Change the function signature for CalcStateExt and RivaGetConfig to pass
in struct pci_dev in addition to RIVA_HW_INST so that code inside the
riva_hw.c can also calculate domain number and pass it to
pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/riva/fbdev.c | 2 +-
drivers/video/fbdev/riva/nv_driver.c | 7 ---
drivers/video/fbdev/riva/riva_hw.c | 20 +---
drivers/video/fbdev/riva/riva_hw.h | 3 ++-
4 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index 1ea78bb..ff82823 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -780,7 +780,7 @@ static int riva_load_video_mode(struct fb_info *info)
else
newmode.misc_output |= 0x80;
- rc = CalcStateExt(>riva, , bpp, width,
+ rc = CalcStateExt(>riva, , par->pdev, bpp, width,
hDisplaySize, height, dotClock);
if (rc)
goto out;
diff --git a/drivers/video/fbdev/riva/nv_driver.c
b/drivers/video/fbdev/riva/nv_driver.c
index f3694cf..a3d9c66 100644
--- a/drivers/video/fbdev/riva/nv_driver.c
+++ b/drivers/video/fbdev/riva/nv_driver.c
@@ -159,6 +159,7 @@ unsigned long riva_get_memlen(struct riva_par *par)
unsigned int chipset = par->Chipset;
struct pci_dev* dev;
u32 amt;
+ int domain = pci_domain_nr(par->pdev->bus);
switch (chip->Architecture) {
case NV_ARCH_03:
@@ -226,12 +227,12 @@ unsigned long riva_get_memlen(struct riva_par *par)
case NV_ARCH_30:
if(chipset == NV_CHIP_IGEFORCE2) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, );
pci_dev_put(dev);
memlen = (((amt >> 6) & 31) + 1) * 1024;
} else if (chipset == NV_CHIP_0x01F0) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x84, );
pci_dev_put(dev);
memlen = (((amt >> 4) & 127) + 1) * 1024;
@@ -417,6 +418,6 @@ unsigned long riva_get_maxdclk(struct riva_par *par)
}
par->riva.flatPanel = (par->FlatPanel > 0) ? TRUE : FALSE;
- RivaGetConfig(>riva, par->Chipset);
+ RivaGetConfig(>riva, par->pdev, par->Chipset);
}
diff --git a/drivers/video/fbdev/riva/riva_hw.c
b/drivers/video/fbdev/riva/riva_hw.c
index 8bdf37f..0601c13 100644
--- a/drivers/video/fbdev/riva/riva_hw.c
+++ b/drivers/video/fbdev/riva/riva_hw.c
@@ -1108,7 +1108,8 @@ static char nv3_get_param(nv3_fifo_info *res_info,
nv3_sim_state * state, nv3_ar
unsigned pixelDepth,
unsigned *burst,
unsigned *lwm,
-RIVA_HW_INST *chip
+RIVA_HW_INST *chip,
+struct pci_dev *pdev
)
{
nv10_fifo_info fifo_data;
@@ -1116,8 +1117,9 @@ static char nv3_get_param(nv3_fifo_info *res_info,
nv3_sim_state * state, nv3_ar
unsigned int M, N, P, pll, MClk, NVClk;
unsigned int uMClkPostDiv;
struct pci_dev *dev;
+int domain = pci_domain_nr(pdev->bus);
-dev = pci_get_bus_and_slot(0, 3);
+dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0x6C, );
pci_dev_put(dev);
uMClkPostDiv = (uMClkPostDiv >> 8) & 0xf;
@@ -1132,7 +1134,7 @@ static char nv3_get_param(nv3_fifo_info *res_info,
nv3_sim_state * state, nv3_ar
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
-dev = pci_get_bus_and_slot(0, 1);
+dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, _data.memory_type);
pci_dev_put(dev);
sim_data.memory_type= (sim_data.memory_type >> 12) & 1;
@@ -1234,6 +1236,7 @@ static char nv3_get_param(nv3_fifo_info *res_info,
nv3_sim_state * state, nv3_ar
(
RIVA_HW_INST *chip,
RIVA_HW_STATE *state,
+struct pci_dev *pdev,
intbpp,
intwidth,
inthDisplaySize,
@@ -1300,7 +1303,7 @@ static char nv3_get_param(nv3_fifo_info *res_info,
nv3_sim_state * state, nv3_ar
pixelDepth * 8,
&(state->arbitration0),
[PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev
member to extract the domain information and pass it to
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/fbdev/nvidia/nv_hw.c| 11 ++-
drivers/video/fbdev/nvidia/nv_setup.c | 3 ++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_hw.c
b/drivers/video/fbdev/nvidia/nv_hw.c
index 81c80ac..8335da4 100644
--- a/drivers/video/fbdev/nvidia/nv_hw.c
+++ b/drivers/video/fbdev/nvidia/nv_hw.c
@@ -683,10 +683,11 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
nv10_sim_state sim_data;
unsigned int M, N, P, pll, MClk, NVClk, memctrl;
struct pci_dev *dev;
+ int domain = pci_domain_nr(par->pci_dev->bus);
if ((par->Chipset & 0x0FF0) == 0x01A0) {
unsigned int uMClkPostDiv;
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0x6C, );
uMClkPostDiv = (uMClkPostDiv >> 8) & 0xf;
@@ -694,7 +695,7 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
uMClkPostDiv = 4;
MClk = 40 / uMClkPostDiv;
} else {
- dev = pci_get_bus_and_slot(0, 5);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 5);
pci_read_config_dword(dev, 0x4c, );
MClk /= 1000;
}
@@ -707,13 +708,13 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
sim_data.pix_bpp = (char)pixelDepth;
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, _data.memory_type);
pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type >> 12) & 1;
sim_data.memory_width = 64;
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0, );
pci_dev_put(dev);
memctrl >>= 16;
@@ -721,7 +722,7 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
if ((memctrl == 0x1A9) || (memctrl == 0x1AB) || (memctrl == 0x1ED)) {
u32 dimm[3];
- dev = pci_get_bus_and_slot(0, 2);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 2);
pci_read_config_dword(dev, 0x40, [0]);
dimm[0] = (dimm[0] >> 8) & 0x4f;
pci_read_config_dword(dev, 0x44, [1]);
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c
b/drivers/video/fbdev/nvidia/nv_setup.c
index 2f2e162..b17acd2 100644
--- a/drivers/video/fbdev/nvidia/nv_setup.c
+++ b/drivers/video/fbdev/nvidia/nv_setup.c
@@ -264,7 +264,8 @@ static void nv10GetConfig(struct nvidia_par *par)
}
#endif
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(pci_domain_nr(par->pci_dev->bus),
+ 0, 1);
if ((par->Chipset & 0x) == 0x01a0) {
u32 amt;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 21/26] backlight: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain as 0.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Acked-by: Daniel Thompson <daniel.thomp...@linaro.org>
---
drivers/video/backlight/apple_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/apple_bl.c
b/drivers/video/backlight/apple_bl.c
index d843296..6a34ab9 100644
--- a/drivers/video/backlight/apple_bl.c
+++ b/drivers/video/backlight/apple_bl.c
@@ -143,7 +143,7 @@ static int apple_bl_add(struct acpi_device *dev)
struct pci_dev *host;
int intensity;
- host = pci_get_bus_and_slot(0, 0);
+ host = pci_get_domain_bus_and_slot(0, 0, 0);
if (!host) {
pr_err("unable to find PCI host\n");
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
On 12/12/2017 9:04 AM, Joonas Lahtinen wrote: > Hi, > > I sent this individual i915 patch to our CI, and it is passing on all > platforms: > > https://patchwork.freedesktop.org/series/34822/ > > Is it ok if I merge this to drm-tip already? As long as you have this change in your tree, it should be safe. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/include/linux/pci.h?id=7912af5c835bd86f2b0347a480e0f40e2fab30d0 > > Regards, Joonas > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
On 11/28/2017 11:29 AM, Sinan Kaya wrote: > On 11/28/2017 10:30 AM, Ville Syrjälä wrote: >>> + dev_priv->bridge_dev = >>> + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0)); >> Maybe just pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) ? >> >> I guess if we want to be pedantic we could go for: >> >> bus = pci_find_host_bridge(pdev->bus)->bus; >> pci_get_slot(bus, PCI_DEVFN(0, 0)) >> >> but I think the GPU should always be on the root bus, so the simpler >> form should be fine. >> > > All three of these should be correct. > > I'll use pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) as you suggested. > Now that I think about this more, I think my version is a simpler change and does not introduce "new features" by assuming GPU and host to be on the same bus similar to the original code. Original code could have used pci_get_slot() too. Since all of them are correct, mine is slightly more correct; I'd like to keep mine. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH resend V3 24/29] backlight: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain as 0.
Acked-by: Jingoo Han <jingooh...@gmail.com>
Acked-by: Daniel Thompson <daniel.thomp...@linaro.org>
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/video/backlight/apple_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/apple_bl.c
b/drivers/video/backlight/apple_bl.c
index d843296..6a34ab9 100644
--- a/drivers/video/backlight/apple_bl.c
+++ b/drivers/video/backlight/apple_bl.c
@@ -143,7 +143,7 @@ static int apple_bl_add(struct acpi_device *dev)
struct pci_dev *host;
int intensity;
- host = pci_get_bus_and_slot(0, 0);
+ host = pci_get_domain_bus_and_slot(0, 0, 0);
if (!host) {
pr_err("unable to find PCI host\n");
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
On 11/28/2017 10:30 AM, Ville Syrjälä wrote: >> +dev_priv->bridge_dev = >> +pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0)); > Maybe just pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) ? > > I guess if we want to be pedantic we could go for: > > bus = pci_find_host_bridge(pdev->bus)->bus; > pci_get_slot(bus, PCI_DEVFN(0, 0)) > > but I think the GPU should always be on the root bus, so the simpler > form should be fine. > All three of these should be correct. I'll use pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) as you suggested. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 08/29] drm/gma500: deprecate pci_get_bus_and_slot()
+dri-devel@lists.freedesktop.org
On 11/27/2017 11:57 AM, 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() function in favor of
> pci_get_domain_bus_and_slot().
>
> Add domain parameter to CDV_MSG_READ32, CDV_MSG_WRITE32, MRST_MSG_READ32,
> MRST_MSG_WRITE32, MDFLD_MSG_READ32, MDFLD_MSG_WRITE32.
>
> Extract pci_dev from struct drm_device and use pdev to find the domain
> number while calling pci_get_domain_bus_and_slot().
>
> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
> ---
> drivers/gpu/drm/gma500/cdv_device.c | 16 +---
> drivers/gpu/drm/gma500/gma_device.c | 4 +++-
> drivers/gpu/drm/gma500/mid_bios.c | 12 +---
> drivers/gpu/drm/gma500/psb_drv.c| 10 --
> drivers/gpu/drm/gma500/psb_drv.h| 18 ++
> 5 files changed, 39 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_device.c
> b/drivers/gpu/drm/gma500/cdv_device.c
> index 8745971..3a3bf75 100644
> --- a/drivers/gpu/drm/gma500/cdv_device.c
> +++ b/drivers/gpu/drm/gma500/cdv_device.c
> @@ -185,21 +185,22 @@ static int cdv_backlight_init(struct drm_device *dev)
> * for this and the MID devices.
> */
>
> -static inline u32 CDV_MSG_READ32(uint port, uint offset)
> +static inline u32 CDV_MSG_READ32(int domain, uint port, uint offset)
> {
> int mcr = (0x10<<24) | (port << 16) | (offset << 8);
> uint32_t ret_val = 0;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
> pci_write_config_dword(pci_root, 0xD0, mcr);
> pci_read_config_dword(pci_root, 0xD4, _val);
> pci_dev_put(pci_root);
> return ret_val;
> }
>
> -static inline void CDV_MSG_WRITE32(uint port, uint offset, u32 value)
> +static inline void CDV_MSG_WRITE32(int domain, uint port, uint offset,
> +u32 value)
> {
> int mcr = (0x11<<24) | (port << 16) | (offset << 8) | 0xF0;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
> pci_write_config_dword(pci_root, 0xD4, value);
> pci_write_config_dword(pci_root, 0xD0, mcr);
> pci_dev_put(pci_root);
> @@ -216,11 +217,12 @@ static void cdv_init_pm(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> u32 pwr_cnt;
> + int domain = pci_domain_nr(dev->pdev->bus);
> int i;
>
> - dev_priv->apm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
> + dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
> PSB_APMBA) & 0x;
> - dev_priv->ospm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
> + dev_priv->ospm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
> PSB_OSPMBA) & 0x;
>
> /* Power status */
> @@ -251,7 +253,7 @@ static void cdv_errata(struct drm_device *dev)
>* Bonus Launch to work around the issue, by degrading
>* performance.
>*/
> - CDV_MSG_WRITE32(3, 0x30, 0x08027108);
> + CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
> }
>
> /**
> diff --git a/drivers/gpu/drm/gma500/gma_device.c
> b/drivers/gpu/drm/gma500/gma_device.c
> index 4a295f9..a7fb6de 100644
> --- a/drivers/gpu/drm/gma500/gma_device.c
> +++ b/drivers/gpu/drm/gma500/gma_device.c
> @@ -19,7 +19,9 @@
> void gma_get_core_freq(struct drm_device *dev)
> {
> uint32_t clock;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root =
> + pci_get_domain_bus_and_slot(pci_domain_nr(dev->pdev->bus),
> + 0, 0);
> struct drm_psb_private *dev_priv = dev->dev_private;
>
> /*pci_write_config_dword(pci_root, 0xD4, 0x00C32004);*/
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c
> b/drivers/gpu/drm/gma500/mid_bios.c
> index d75ecb3..5c23d4e 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -32,7 +32,9 @@
> static void mid_get_fuse_settings(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root =
> + pci
Re: [PATCH V3 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()
+nouv...@lists.freedesktop.org
On 11/27/2017 11:57 AM, 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() function in favor of
> pci_get_domain_bus_and_slot().
>
> Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
> and extract the domain number from
> 1. struct pci_dev
> 2. struct pci_dev through drm_device->pdev
> 3. struct pci_dev through fb->subdev->drm_device->pdev
>
> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
> drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
> drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
> 4 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> index 90075b6..c79160c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> @@ -213,8 +213,10 @@ struct nv_sim_state {
> if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
> (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
> uint32_t type;
> + int domain = pci_domain_nr(dev->pdev->bus);
>
> - pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
> + 0x7c, );
>
> sim_data.memory_type = (type >> 12) & 1;
> sim_data.memory_width = 64;
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> index b985990..0c9bdf0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> @@ -216,12 +216,15 @@
> {
> struct nvkm_pll_vals pllvals;
> int ret;
> + int domain;
> +
> + domain = pci_domain_nr(dev->pdev->bus);
>
> if (plltype == PLL_MEMORY &&
> (dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
> uint32_t mpllP;
> -
> - pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
> + 0x6c, );
> mpllP = (mpllP >> 8) & 0xf;
> if (!mpllP)
> mpllP = 4;
> @@ -232,7 +235,8 @@
> (dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
> uint32_t clock;
>
> - pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
> + 0x4c, );
> return clock / 1000;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 595630d..0b6c639 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> }
>
> /* subfunction one is a hdmi audio device? */
> - drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
> + drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> + (unsigned int)pdev->bus->number,
>
> PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
>
> if (!drm->hdmi_device) {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> index 3c6a871..8849b71 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> @@ -28,8 +28,16 @@
> {
> struct pci_dev *bridge;
> u32 mem, mib;
> + int domain = 0;
> + struct pci_dev *pdev = NULL;
>
> - bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
> + if (dev_is_pci(fb->subdev.device->dev))
> + pdev = to_pci_dev(fb->subdev.device->dev);
> +
> + if (pdev)
> + domain = pci_domain_nr(pdev->bus);
> +
> + bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
> if (!bridge) {
> nvkm_error(>subdev, "no bridge device\n");
> return -ENODEV;
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
+dri-devel@lists.freedesktop.org
On 11/27/2017 11:57 AM, 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() function in favor of
> pci_get_domain_bus_and_slot().
>
> Extract the domain number from drm_device and pass it into
> pci_get_domain_bus_and_slot() function.
>
> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9f45cfe..5a8cb79 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
>
> static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
> {
> - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
> +
> + dev_priv->bridge_dev =
> + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
> if (!dev_priv->bridge_dev) {
> DRM_ERROR("bridge device not found\n");
> return -1;
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Extract the domain number from drm_device and pass it into
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9f45cfe..5a8cb79 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void
*data,
static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
- dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
+
+ dev_priv->bridge_dev =
+ pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
if (!dev_priv->bridge_dev) {
DRM_ERROR("bridge device not found\n");
return -1;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from
1. struct pci_dev
2. struct pci_dev through drm_device->pdev
3. struct pci_dev through fb->subdev->drm_device->pdev
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..c79160c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -213,8 +213,10 @@ struct nv_sim_state {
if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
+ int domain = pci_domain_nr(dev->pdev->bus);
- pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, );
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..0c9bdf0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -216,12 +216,15 @@
{
struct nvkm_pll_vals pllvals;
int ret;
+ int domain;
+
+ domain = pci_domain_nr(dev->pdev->bus);
if (plltype == PLL_MEMORY &&
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
-
- pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, );
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +235,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
- pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, );
return clock / 1000;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 595630d..0b6c639 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
/* subfunction one is a hdmi audio device? */
- drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 3c6a871..8849b71 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -28,8 +28,16 @@
{
struct pci_dev *bridge;
u32 mem, mib;
+ int domain = 0;
+ struct pci_dev *pdev = NULL;
- bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+ if (dev_is_pci(fb->subdev.device->dev))
+ pdev = to_pci_dev(fb->subdev.device->dev);
+
+ if (pdev)
+ domain = pci_domain_nr(pdev->bus);
+
+ bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(>subdev, "no bridge device\n");
return -ENODEV;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 09/29] drm/i915: deprecate pci_get_bus_and_slot()
On 11/22/2017 5:49 PM, Sinan Kaya wrote:
> static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
> {
> - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus);
I'll convert domain type to int on the next version across the series.
I tried to convert most of the drivers to use pci_domain_nr() per feedback
from Greg KH. I'll hold onto posting a new version until I gather feedback
with the approach I have taken.
I just did a build test with the series.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 09/29] drm/i915: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Extract the domain number from drm_device and pass it into
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9f45cfe..fea2b5e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void
*data,
static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
- dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus);
+
+ dev_priv->bridge_dev =
+ pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
if (!dev_priv->bridge_dev) {
DRM_ERROR("bridge device not found\n");
return -1;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()
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() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from
1. struct pci_dev
2. struct pci_dev through drm_device->pdev
3. struct pci_dev through fb->subdev->drm_device->pdev
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..e7455f7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -213,8 +213,10 @@ struct nv_sim_state {
if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
+ u32 domain = pci_domain_nr(dev->pdev->bus);
- pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, );
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..8806b1b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -216,12 +216,15 @@
{
struct nvkm_pll_vals pllvals;
int ret;
+ u32 domain;
+
+ domain = pci_domain_nr(dev->pdev->bus);
if (plltype == PLL_MEMORY &&
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
-
- pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, );
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +235,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
- pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, );
return clock / 1000;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 595630d..0b6c639 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
/* subfunction one is a hdmi audio device? */
- drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 3c6a871..273a632 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -28,8 +28,16 @@
{
struct pci_dev *bridge;
u32 mem, mib;
+ u32 domain = 0;
+ struct pci_dev *pdev = NULL;
- bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+ if (dev_is_pci(fb->subdev.device->dev))
+ pdev = to_pci_dev(fb->subdev.device->dev);
+
+ if (pdev)
+ domain = pci_domain_nr(pdev->bus);
+
+ bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(>subdev, "no bridge device\n");
return -ENODEV;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/30] drm/nouveau: deprecate pci_get_bus_and_slot()
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.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 3 ++-
drivers/gpu/drm/nouveau/dispnv04/hw.c| 6 --
drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..729d7d0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -214,7 +214,8 @@ struct nv_sim_state {
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
- pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(0, 0, 1),
+ 0x7c, );
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..4b35093 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -221,7 +221,8 @@
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
- pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(0, 0, 3),
+ 0x6c, );
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +233,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
- pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
+ pci_read_config_dword(pci_get_domain_bus_and_slot(0, 0, 5),
+ 0x4c, );
return clock / 1000;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 595630d..0b6c639 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
/* subfunction one is a hdmi audio device? */
- drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 3c6a871..3d2a203 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -29,7 +29,7 @@
struct pci_dev *bridge;
u32 mem, mib;
- bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+ bridge = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(>subdev, "no bridge device\n");
return -ENODEV;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/30] drm/i915: deprecate pci_get_bus_and_slot()
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.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9f45cfe..2ca7603 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -419,7 +419,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
- dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ uint16_t devfn = PCI_DEVFN(0, 0)
+
+ dev_priv->bridge_dev = pci_get_domain_bus_and_slot(0, 0, devfn);
if (!dev_priv->bridge_dev) {
DRM_ERROR("bridge device not found\n");
return -1;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] PCI: create revision file in sysfs
On 11/16/2016 3:58 PM, Bjorn Helgaas wrote: > [+cc Sinan, Lukas] > > Hi Daniel, > > On Mon, Nov 14, 2016 at 07:40:03PM +0100, Daniel Vetter wrote: >> On Fri, Nov 11, 2016 at 02:37:23PM +, Emil Velikov wrote: >>> From: Emil Velikov >>> >>> Currently the revision isn't available via sysfs/libudev thus if one >>> wants to know the value they need to read through the config file. >>> >>> This in itself wakes/powers up the device, causing unwanted delay >>> since it can be quite costly. >>> >>> There are at least two userspace components which could make use the new >>> file libpciaccess and libdrm. The former [used in various places] wakes >>> up _every_ PCI device, which can be observed via glxinfo [when using >>> Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0] >>> can lead to 2-3 second delays while starting firefox, thunderbird or >>> chromium. >>> >>> Expose the revision as a separate file, just like we do for the device, >>> vendor, their subsystem version and class. >>> >>> Cc: Bjorn Helgaas >>> Cc: linux-pci at vger.kernel.org >>> Cc: Greg KH >>> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502 >>> Tested-by: Mauro Santos >>> Reviewed-by: Alex Deucher >>> Signed-off-by: Emil Velikov >> >> Given that waking a gpu can take somewhere between ages and forever, and >> that we read the pci revisions everytime we launch a new gl app I think >> this is the correct approach. Of course we could just patch libdrm and >> everyone to not look at the pci revision, but that just leads to every >> pci-based driver having a driver-private ioctl/getparam thing to expose >> it. Which also doesn't make much sense. > > This re-asserts what has already been said, but doesn't address any of > my questions in the v2 discussion, so I'm still looking to continue > that thread. > > I am curious about this long wakeup issue, though. Are we talking > about a D3cold -> D0 transition? I assume so, since config space is > generally accessible in all power states except D3cold. From the > device's point of view this is basically like a power-on. I think the > gist of PCIe r3.0, sec 6.6.1 is that we need to wait 100ms, e.g., > PCI_PM_D3COLD_WAIT, before doing config accesses. > > We do support Configuration Request Retry Status Software Visibility > (pci_enable_crs()), so a device *can* take longer than 100ms after > power-up to respond to a config read, but I think that only applies to > reads of the Vendor ID. I cc'd Sinan because we do have some issues > with our CRS support, and maybe he can shed some light on this. This applies to all config requests including vendor ID. It is just the vendor ID returns a special code (device id = 0x0001 vendor id =0x) so that CRS aware software can understand the difference between CRS and an actual failure. It is recommended to always read the vendor ID following a reset/power on to understand if the device is sending a CRS. As Bjorn mentioned, we do enable CRS visibility in the kernel but only for the root port in pci_enable_crs function. When CRS visibility is disabled, root port needs to retry the request until a good response is received. CRS polling happens behind the scenes in pci_bus_read_dev_vendor_id function. In order for reads to take longer than 100ms, the CRS must be disabled at a lower level in the bus. I wonder if you have a bridge between your device and the root port. Bridge Configuration Retry Enable needs to be programmed if we want kernel to know about retry responses behind a bridge. "Bridge Configuration Retry Enable â When Set, this bit enables PCI Express to PCI/PCI-X bridges to return Configuration Request Retry Status (CRS) in response to Configuration Requests that target devices below the bridge. Refer to the PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0 for further details. Default value of this bit is 0b." Kernel is currently not setting this. > > I'm not surprised if a GPU takes longer than 100ms to do device- > specific, driver-managed, non-PCI things like detect and wake up > monitors. But I *am* surprised if generic PCI bus-level things like > config reads take longer than that. I also cc'd Lukas because he > knows a lot more about PCI PM than I do. > > Bjorn > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
