efi/fb: Simplify fixup code to prefer struct resource
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().
--- drivers/video/fbdev/efifb.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/video/fbdev/efifb.c +11 -6
@@ -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, &screen_res)) { +u64 win_offset = screen_res.start - res->start; + +record_efifb_bar_resource (dev, i, win_offset);break ; } }
Signature · 1 line
2.7.4
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 0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg 0x10: [mem 0x8011e000000-0x8011effffff]
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 0x1e000000
efifb: framebuffer at 0x1e000000, 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.
--- drivers/video/fbdev/efifb.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/video/fbdev/efifb.c +5 -0
@@ -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, &screen_res, ®ion); +for (i =0 ; i <=PCI_STD_RESOURCE_END ; i++) {struct resource *res = &dev->resource[i];
Signature · 1 line
2.7.4
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Ard,
Quoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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
Quoted 5 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>---
I didn't see any messages about these getting picked up for 4.18.
Are they queued on your own branch?
Sinan
Signature · 3 lines
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 23 lines · Sinan Kaya
Hi Ard,
Quoted 20 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Use the host bridge offset information to convert bus address to resource address in the fixup.
Quoted 7 lines
Quoted 2 lines
Signed-off-by Sinan Kaya <[email protected]>---
I didn't see any messages about these getting picked up for 4.18.
Are they queued on your own branch?
No, you never cc'ed me on them until now.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 27 lines · Ard Biesheuvel
Quoted 26 lines · Sinan Kaya
Hi Ard,
Quoted 22 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>---
Quoted 6 lines
Quoted 4 lines
I didn't see any messages about these getting picked up for 4.18.
Are they queued on your own branch?
No, you never cc'ed me on them until now.
Ouch, I hoped that you would get it via get_maintainer script. Sorry for that.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 35 lines · On 13 June 2018 at 17:17, <[email protected]> wrote:
Quoted 34 lines · Ard Biesheuvel
Quoted 32 lines · Sinan Kaya
Hi Ard,
Quoted 19 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff])
pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Quoted 5 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>---
I didn't see any messages about these getting picked up for 4.18.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Are they queued on your own branch?
No, you never cc'ed me on them until now.
Ouch, I hoped that you would get it via
get_maintainerscript. Sorry for that.
Actually, get_maintainer is right: this should go through the fbdev tree not the EFI tree
Were you going to resend them? If not, I can find them in my archive and ack them, and we will ask Bartlomiej to take them for v4.19
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 42 lines · Ard Biesheuvel
Quoted 41 lines · On 13 June 2018 at 17:17, <[email protected]> wrote:
Quoted 38 lines · Ard Biesheuvel
Quoted 26 lines · Sinan Kaya
Hi Ard,
Quoted 22 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff])
pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Use the host bridge offset information to convert bus address to resource address in the fixup.
Quoted 8 lines
Quoted 2 lines
Signed-off-by Sinan Kaya <[email protected]>---
I didn't see any messages about these getting picked up for 4.18.
Are they queued on your own branch?
No, you never cc'ed me on them until now.
Quoted 8 lines
Quoted 2 lines
Ouch, I hoped that you would get it via
get_maintainerscript. Sorry for that.Actually,
get_maintaineris right: this should go through the fbdev tree not the EFI treeWere you going to resend them? If not, I can find them in my archive and ack them, and we will ask Bartlomiej to take them for v4.19
I prefer ack rather than resend to be honest.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
In reply to Sinan KayaQuoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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
Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>
Bartlomiej, could you please take these via the fbdev tree for v4.19? Peter already gave his ack but Sinan dropped it (presumably because of the split in v2)
Sinan, does this need to go to -stable? I.e., has it ever worked before?
Quoted 35 lines
--- drivers/video/fbdev/efifb.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/video/fbdev/efifb.c +5
-1@@ -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, &screen_res, ®ion); +for (i =0 ; i <=PCI_STD_RESOURCE_END ; i++) {struct resource *res = &dev->resource[i]; --2.7.4
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 23 lines · Ard Biesheuvel
Quoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>
Quoted 8 lines
Reviewed-by Ard Biesheuvel <[email protected]>Bartlomiej, could you please take these via the fbdev tree for v4.19? Peter already gave his ack but Sinan dropped it (presumably because of the split in v2)
Sinan, does this need to go to -stable? I.e., has it ever worked before?
Yes, it needs to go to stable. It never worked before. Issue was found during a graphics bring up with AST driver.
It needs a 32 bit graphics card and a 32 bit translating host bridge to hit the issue.
Quoted 41 lines
Quoted 41 lines
--- drivers/video/fbdev/efifb.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/video/fbdev/efifb.c +1
-0@@ -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)drivers/video/fbdev/efifb.c +4
-1@@ -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, &screen_res, ®ion); +for (i =0 ; i <=PCI_STD_RESOURCE_END ; i++) {struct resource *res = &dev->resource[i]; --2.7.4
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
In reply to Ard BiesheuvelQuoted 18 lines · Ard Biesheuvel
Quoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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
Quoted 8 lines
Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>Reviewed-by Ard Biesheuvel <[email protected]>Bartlomiej, could you please take these via the fbdev tree for v4.19?
Sure, I will queue it after the current merge window.
Quoted 2 lines
Peter already gave his ack but Sinan dropped it (presumably because of the split in v2)
Peter, can I (re)add your ACK to V2 patches?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 26 lines · Bartlomiej Zolnierkiewicz
Quoted 25 lines · Ard Biesheuvel
Quoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>Reviewed-by Ard Biesheuvel <[email protected]>
Quoted 9 lines
Quoted 1 line
Bartlomiej, could you please take these via the fbdev tree for v4.19?
Sure, I will queue it after the current merge window.
Quoted 2 lines
Peter already gave his ack but Sinan dropped it (presumably because of the split in v2)
Peter, can I (re)add your ACK to V2 patches?
Actually, it would be better if we could take this through the EFI tree instead, with your ack. Would you mind?
There are some other efifb changes coming up, some of which depend on core EFI changes, and taking these through different trees is going to be more trouble than it's worth.
https://marc.info/?l=linux-efi&m=152929425329015&w=2 from Hans, and the series
[PATCH v2 0/2] efi: add support for cacheable efifb mappings
that I just cc'ed you on a minute ago.
Thanks.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 32 lines · Ard Biesheuvel
Quoted 30 lines · Bartlomiej Zolnierkiewicz
Quoted 18 lines · Ard Biesheuvel
Quoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Quoted 8 lines
Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>Reviewed-by Ard Biesheuvel <[email protected]>Bartlomiej, could you please take these via the fbdev tree for v4.19?
Sure, I will queue it after the current merge window.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Peter already gave his ack but Sinan dropped it (presumably because of the split in v2)
Peter, can I (re)add your ACK to V2 patches?
Actually, it would be better if we could take this through the EFI tree instead, with your ack. Would you mind?
Fine with me.
Quoted 3 lines
There are some other efifb changes coming up, some of which depend on core EFI changes, and taking these through different trees is going to be more trouble than it's worth.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz
Acked-byRe: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 36 lines · Bartlomiej Zolnierkiewicz
Quoted 35 lines · Ard Biesheuvel
Quoted 33 lines · Bartlomiej Zolnierkiewicz
Quoted 18 lines · Ard Biesheuvel
Quoted 17 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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:0Quoted 8 lines
Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>Reviewed-by Ard Biesheuvel <[email protected]>Bartlomiej, could you please take these via the fbdev tree for v4.19?
Sure, I will queue it after the current merge window.
Quoted 2 lines
Peter already gave his ack but Sinan dropped it (presumably because of the split in v2)
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Peter, can I (re)add your ACK to V2 patches?
Actually, it would be better if we could take this through the EFI tree instead, with your ack. Would you mind?
Fine with me.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
In reply to Sinan KayaMinor subject nit: From the caller's point of view, we must convert a bus address to a resource *always* (the caller has no knowledge of "whether it is translated by the host bridge").
Quoted 2 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.
Also, _TRA/_CRS are ACPI-specific terms and non-ACPI host bridges can also do the same sort of translation. Another trivial nit.
Quoted 14 lines
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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
Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>
Thanks a lot for fixing this!
Quoted 35 lines
--- drivers/video/fbdev/efifb.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/video/fbdev/efifb.c +5
-0@@ -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, &screen_res, ®ion); +for (i =0 ; i <=PCI_STD_RESOURCE_END ; i++) {struct resource *res = &dev->resource[i];Signature · 7 lines
2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 25 lines · Bjorn Helgaas
Minor subject nit: From the caller's point of view, we must convert a bus address to a resource *always* (the caller has no knowledge of "whether it is translated by the host bridge").
Quoted 2 lines · Sinan Kaya
A host bridge is allowed to remap BAR addresses using
_TRAattribute in_CRSwindows.Also, _TRA/_CRS are ACPI-specific terms and non-ACPI host bridges can also do the same sort of translation. Another trivial nit.
Quoted 14 lines
pci_bus0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) pci 0000:02:00.0: reg0x10: [mem 0x8011e000000-0x8011effffff]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 at0x1e000000
efifb: framebuffer at0x1e000000, 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
Quoted 9 lines
Quoted 4 lines
Use the host bridge offset information to convert bus address to resource address in the fixup.
Signed-off-by Sinan Kaya <[email protected]>Reviewed-by Bjorn Helgaas <[email protected]>Thanks a lot for fixing this!
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.
Quoted 40 lines
Quoted 31 lines
--- drivers/video/fbdev/efifb.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/video/fbdev/efifb.c +5
-1@@ -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, &screen_res, ®ion); +for (i =0 ; i <=PCI_STD_RESOURCE_END ; i++) {struct resource *res = &dev->resource[i]; --2.7.4
Quoted 4 lines
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Ard,
Quoted 9 lines · Ard Biesheuvel
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
Signature · 3 lines
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 26 lines · Sinan Kaya
Hi Ard,
Quoted 9 lines · Ard Biesheuvel
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.
Quoted 6 lines
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?
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.
"""
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 37 lines · Ard Biesheuvel
Quoted 26 lines · Sinan Kaya
Hi Ard,
Quoted 9 lines · Ard Biesheuvel
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.
Quoted 6 lines
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?
Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is described as
Quoted 7 lines
"""
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 15 lines · Ard Biesheuvel
Quoted 10 lines
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.
Quoted 6 lines
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.
Signature · 3 lines
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 23 lines · Sinan Kaya
Quoted 15 lines · Ard Biesheuvel
Quoted 10 lines
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.
Quoted 6 lines
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.
Quoted 3 lines
Thanks for checking out other platforms. I'll mark the issue as a BIOS issue and bounce your feedback to the BIOS provider.
I screwed up my testing, unfortunately. Both the public AMD GOP driver I tried, and the Nvidia GT218 under x86 emulation break when using MMIO translation. However, GraphicsOutputDxe in the EDK2 tree gets it right, and uses PciIo->GetBarAttributes() to get the address of the framebuffer region, which will return the CPU address not the PCI address.
Quoted 2 lines
Let's hold onto this patch for the moment.
Yes. I'd like to get this resolved as well, but if the drivers are dereferencing BAR values as CPU addresses, this is unlikely to be the only thing that is broken under outbound translation.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 35 lines · Ard Biesheuvel
Quoted 23 lines · Sinan Kaya
Quoted 15 lines · Ard Biesheuvel
Quoted 10 lines
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.
Quoted 6 lines
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.Quoted 3 lines
Thanks for checking out other platforms. I'll mark the issue as a BIOS issue and bounce your feedback to the BIOS provider.
I screwed up my testing, unfortunately. Both the public AMD GOP driver I tried, and the Nvidia GT218 under x86 emulation break when using MMIO translation. However, GraphicsOutputDxe in the EDK2 tree gets it right, and uses
PciIo->GetBarAttributes()to get the address of the framebuffer region, which will return the CPU address not the PCI address.
Quoted 6 lines
Quoted 2 lines
Let's hold onto this patch for the moment.
Yes. I'd like to get this resolved as well, but if the drivers are dereferencing BAR values as CPU addresses, this is unlikely to be the only thing that is broken under outbound translation.
Note that this was fixed fairly recently in EDK2, so BIOS vendors providing UEFI firmware for ARM platforms with outbound MMIO translation should probably incorporate this EDK2 patch
commit dc080d3b61e570e7a3163fc24afa6f8388d0c0bf
Author: Heyi Guo <[email protected]> Date: Thu Feb 8 11:13:27 2018 +0800
MdeModulePkg/PciBus: return CPU address for GetBarAttributes
According to UEFI spec 2.7, PciIo->GetBarAttributes should return host address (CPU view ddress) rather than device address (PCI view address), and
device address = host address + address translation offset, so we subtract translation from device address before returning.
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 60 lines · Ard Biesheuvel
Quoted 35 lines · Ard Biesheuvel
Quoted 23 lines · Sinan Kaya
Quoted 15 lines · Ard Biesheuvel
Quoted 10 lines
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.
Quoted 6 lines
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.Quoted 3 lines
Thanks for checking out other platforms. I'll mark the issue as a BIOS issue and bounce your feedback to the BIOS provider.
I screwed up my testing, unfortunately. Both the public AMD GOP driver I tried, and the Nvidia GT218 under x86 emulation break when using MMIO translation. However, GraphicsOutputDxe in the EDK2 tree gets it right, and uses
PciIo->GetBarAttributes()to get the address of the framebuffer region, which will return the CPU address not the PCI address.Quoted 6 lines
Quoted 2 lines
Let's hold onto this patch for the moment.
Yes. I'd like to get this resolved as well, but if the drivers are dereferencing BAR values as CPU addresses, this is unlikely to be the only thing that is broken under outbound translation.
Note that this was fixed fairly recently in EDK2, so BIOS vendors providing UEFI firmware for ARM platforms with outbound MMIO translation should probably incorporate this EDK2 patch
commit
dc080d3b61e570e7a3163fc24afa6f8388d0c0bfAuthor: Heyi Guo <[email protected]> Date: Thu Feb 8 11:13:27 2018 +0800MdeModulePkg/PciBus: return CPU address for GetBarAttributes
According to UEFI spec 2.7,
PciIo->GetBarAttributesshould return
host
address (CPU view ddress) rather than device address (PCI view address), and
device address = host address + address translation offset, so we subtract translation from device address before returning.
Quoted 5 lines
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 6 lines · On 6/25/2018 11:52 AM, [email protected] wrote:
Quoted 5 lines
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.
Quoted 7 lines
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.
Signature · 3 lines
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.
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 11 lines · Sinan Kaya
Quoted 10 lines · On 6/25/2018 11:52 AM, [email protected] wrote:
Quoted 5 lines
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.
Quoted 9 lines
Quoted 3 lines
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 ...
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Quoted 6 lines · Ard Biesheuvel
Quoted 6 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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.
Signature · 3 lines
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.
Quoted 5 lines · Sinan Kaya
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 <[email protected]>
Quoted 54 lines
--- drivers/video/fbdev/efifb.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)drivers/video/fbdev/efifb.c +11
-7@@ -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, &screen_res)) { +u64 win_offset = screen_res.start - res->start; + +record_efifb_bar_resource (dev, i, win_offset);break ; } } --2.7.4
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Bartlomiej Zolnierkiewicz
Acked-byQuoted 8 lines · Ard Biesheuvel
Quoted 5 lines · Sinan Kaya
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 <[email protected]>Reviewed-by Ard Biesheuvel <[email protected]>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics