[PATCH AUTOSEL 5.4 1/5] Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
From: Vitaly Kuznetsov vkuznets@redhat.com
[ Upstream commit f0880e2cb7e1f8039a048fdd01ce45ab77247221 ]
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem ... f8000000-fffbffff : PCI Bus 0000:00 f8000000-fbffffff : 0000:00:08.0 f8000000-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe ... fe0000000-fffffffff : PCI Bus 0000:00 fe0000000-fe07fffff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe fe0000000-fe07fffff : 2ba2:00:02.0 fe0000000-fe07fffff : mlx4_core
the interesting part is the 'f8000000' region as it is actually the VM's framebuffer:
$ lspci -v ... 0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, non-prefetchable) [size=64M] ...
hv_vmbus: registering driver hyperv_drm hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version major 3, minor 5 hyperv_drm 0000:00:08.0: vgaarb: deactivate vga console hyperv_drm 0000:00:08.0: BAR 0: can't reserve [mem 0xf8000000-0xfbffffff] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request framebuffer, boot fb still active?
Note: "Cannot request framebuffer" is not a fatal error in hyperv_setup_gen1() as the code assumes there's some other framebuffer device there but we actually have some other PCI device (mlx4 in this case) config space there!
The problem appears to be that vmbus_allocate_mmio() can use dedicated framebuffer region to serve any MMIO request from any device. The semantics one might assume of a parameter named "fb_overlap_ok" aren't implemented because !fb_overlap_ok essentially has no effect. The existing semantics are really "prefer_fb_overlap". This patch implements the expected and needed semantics, which is to not allocate from the frame buffer space when !fb_overlap_ok.
Note, Gen2 VMs are usually unaffected by the issue because framebuffer region is already taken by EFI fb (in case kernel supports it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers load after it. Devices can be brought up in any sequence so let's resolve the issue by always ignoring 'fb_mmio' region for non-FB requests, even if the region is unclaimed.
Reviewed-by: Michael Kelley mikelley@microsoft.com Signed-off-by: Vitaly Kuznetsov vkuznets@redhat.com Link: https://lore.kernel.org/r/20220827130345.1320254-4-vkuznets@redhat.com Signed-off-by: Wei Liu wei.liu@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/hv/vmbus_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 56918274c48c..d4c5efc6e157 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -2075,7 +2075,7 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj, bool fb_overlap_ok) { struct resource *iter, *shadow; - resource_size_t range_min, range_max, start; + resource_size_t range_min, range_max, start, end; const char *dev_n = dev_name(&device_obj->device); int retval;
@@ -2110,6 +2110,14 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj, range_max = iter->end; start = (range_min + align - 1) & ~(align - 1); for (; start + size - 1 <= range_max; start += align) { + end = start + size - 1; + + /* Skip the whole fb_mmio region if not fb_overlap_ok */ + if (!fb_overlap_ok && fb_mmio && + (((start >= fb_mmio->start) && (start <= fb_mmio->end)) || + ((end >= fb_mmio->start) && (end <= fb_mmio->end)))) + continue; + shadow = __request_region(iter, start, size, NULL, IORESOURCE_BUSY); if (!shadow)
From: Linus Walleij linus.walleij@linaro.org
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
Cc: Marc Zyngier maz@kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Acked-by: Marc Zyngier maz@kernel.org Signed-off-by: Bartosz Golaszewski brgl@bgdev.pl Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpio/gpio-ixp4xx.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-ixp4xx.c b/drivers/gpio/gpio-ixp4xx.c index b3b050604e0b..6bd047e2ca46 100644 --- a/drivers/gpio/gpio-ixp4xx.c +++ b/drivers/gpio/gpio-ixp4xx.c @@ -67,6 +67,14 @@ static void ixp4xx_gpio_irq_ack(struct irq_data *d) __raw_writel(BIT(d->hwirq), g->base + IXP4XX_REG_GPIS); }
+static void ixp4xx_gpio_mask_irq(struct irq_data *d) +{ + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + + irq_chip_mask_parent(d); + gpiochip_disable_irq(gc, d->hwirq); +} + static void ixp4xx_gpio_irq_unmask(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); @@ -76,6 +84,7 @@ static void ixp4xx_gpio_irq_unmask(struct irq_data *d) if (!(g->irq_edge & BIT(d->hwirq))) ixp4xx_gpio_irq_ack(d);
+ gpiochip_enable_irq(gc, d->hwirq); irq_chip_unmask_parent(d); }
@@ -153,12 +162,14 @@ static int ixp4xx_gpio_irq_set_type(struct irq_data *d, unsigned int type) return irq_chip_set_type_parent(d, IRQ_TYPE_LEVEL_HIGH); }
-static struct irq_chip ixp4xx_gpio_irqchip = { +static const struct irq_chip ixp4xx_gpio_irqchip = { .name = "IXP4GPIO", .irq_ack = ixp4xx_gpio_irq_ack, - .irq_mask = irq_chip_mask_parent, + .irq_mask = ixp4xx_gpio_mask_irq, .irq_unmask = ixp4xx_gpio_irq_unmask, .irq_set_type = ixp4xx_gpio_irq_set_type, + .flags = IRQCHIP_IMMUTABLE, + GPIOCHIP_IRQ_RESOURCE_HELPERS, };
static int ixp4xx_gpio_child_to_parent_hwirq(struct gpio_chip *gc, @@ -282,7 +293,7 @@ static int ixp4xx_gpio_probe(struct platform_device *pdev) g->gc.owner = THIS_MODULE;
girq = &g->gc.irq; - girq->chip = &ixp4xx_gpio_irqchip; + gpio_irq_chip_set_chip(girq, &ixp4xx_gpio_irqchip); girq->fwnode = g->fwnode; girq->parent_domain = parent; girq->child_to_parent_hwirq = ixp4xx_gpio_child_to_parent_hwirq;
On 2022-09-21 16:54, Sasha Levin wrote:
From: Linus Walleij linus.walleij@linaro.org
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
Cc: Marc Zyngier maz@kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Acked-by: Marc Zyngier maz@kernel.org Signed-off-by: Bartosz Golaszewski brgl@bgdev.pl Signed-off-by: Sasha Levin sashal@kernel.org
Why? The required dependencies are only in 5,19, and are definitely NOT a stable candidate...
This isn't a fix by any stretch of the imagination.
M.
On Wed, Sep 21, 2022 at 6:57 PM Marc Zyngier maz@kernel.org wrote:
On 2022-09-21 16:54, Sasha Levin wrote:
From: Linus Walleij linus.walleij@linaro.org
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
Cc: Marc Zyngier maz@kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Acked-by: Marc Zyngier maz@kernel.org Signed-off-by: Bartosz Golaszewski brgl@bgdev.pl Signed-off-by: Sasha Levin sashal@kernel.org
Why? The required dependencies are only in 5,19, and are definitely NOT a stable candidate...
This isn't a fix by any stretch of the imagination.
Hi Marc,
While I didn't mark it for stable (and it shouldn't go into any branch earlier than 5.19.x), I did send the patches making the irqchips immutable to Linus Torvalds as fixes as they technically do *fix* the warning emitted by gpiolib and make the implementation correct.
I think these patches should still be part of the v5.19.x stable branch.
Bart
Hi Bartosz,
On Wed, 21 Sep 2022 21:04:27 +0100, Bartosz Golaszewski brgl@bgdev.pl wrote:
On Wed, Sep 21, 2022 at 6:57 PM Marc Zyngier maz@kernel.org wrote:
On 2022-09-21 16:54, Sasha Levin wrote:
From: Linus Walleij linus.walleij@linaro.org
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
Cc: Marc Zyngier maz@kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Acked-by: Marc Zyngier maz@kernel.org Signed-off-by: Bartosz Golaszewski brgl@bgdev.pl Signed-off-by: Sasha Levin sashal@kernel.org
Why? The required dependencies are only in 5,19, and are definitely NOT a stable candidate...
This isn't a fix by any stretch of the imagination.
Hi Marc,
While I didn't mark it for stable (and it shouldn't go into any branch earlier than 5.19.x), I did send the patches making the irqchips immutable to Linus Torvalds as fixes as they technically do *fix* the warning emitted by gpiolib and make the implementation correct.
I think these patches should still be part of the v5.19.x stable branch.
5.19, sure. All the dependencies are there, and tightening the driver implementations is a valuable goal.
However, targeting all the other stable releases (5.4, 5.10, 5.15) makes little sense. It won't even compile! Do the dependencies need to be backported? I don't think it is worthwhile, as this is a long series containing multiple related changes spread all over the tree. This would defeat the very purpose of a stable tree.
M.
On Thu, Sep 22, 2022 at 11:17 AM Marc Zyngier maz@kernel.org wrote:
Hi Bartosz,
On Wed, 21 Sep 2022 21:04:27 +0100, Bartosz Golaszewski brgl@bgdev.pl wrote:
On Wed, Sep 21, 2022 at 6:57 PM Marc Zyngier maz@kernel.org wrote:
On 2022-09-21 16:54, Sasha Levin wrote:
From: Linus Walleij linus.walleij@linaro.org
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
Cc: Marc Zyngier maz@kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Acked-by: Marc Zyngier maz@kernel.org Signed-off-by: Bartosz Golaszewski brgl@bgdev.pl Signed-off-by: Sasha Levin sashal@kernel.org
Why? The required dependencies are only in 5,19, and are definitely NOT a stable candidate...
This isn't a fix by any stretch of the imagination.
Hi Marc,
While I didn't mark it for stable (and it shouldn't go into any branch earlier than 5.19.x), I did send the patches making the irqchips immutable to Linus Torvalds as fixes as they technically do *fix* the warning emitted by gpiolib and make the implementation correct.
I think these patches should still be part of the v5.19.x stable branch.
5.19, sure. All the dependencies are there, and tightening the driver implementations is a valuable goal.
However, targeting all the other stable releases (5.4, 5.10, 5.15) makes little sense. It won't even compile! Do the dependencies need to be backported? I don't think it is worthwhile, as this is a long series containing multiple related changes spread all over the tree. This would defeat the very purpose of a stable tree.
That's what I'm saying. All the conversions to immutable irqchips should go to v5.19 but nowhere else.
I thought that by saying "This isn't a fix by any stretch of the imagination." you meant it should go like regular feature patches into the next merge window only.
Sasha: can you drop this from all branches earlier than v5.19?
Thanks, Bartosz
On Wed, Sep 21, 2022 at 10:04:27PM +0200, Bartosz Golaszewski wrote:
On Wed, Sep 21, 2022 at 6:57 PM Marc Zyngier maz@kernel.org wrote:
On 2022-09-21 16:54, Sasha Levin wrote:
From: Linus Walleij linus.walleij@linaro.org
[ Upstream commit 94e9bc73d85aa6ecfe249e985ff57abe0ab35f34 ]
This turns the IXP4xx GPIO irqchip into an immutable irqchip, a bit different from the standard template due to being hierarchical.
Tested on the IXP4xx which uses drivers/ata/pata_ixp4xx_cf.c for a rootfs on compact flash with IRQs from this GPIO block to the CF ATA controller.
Cc: Marc Zyngier maz@kernel.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Acked-by: Marc Zyngier maz@kernel.org Signed-off-by: Bartosz Golaszewski brgl@bgdev.pl Signed-off-by: Sasha Levin sashal@kernel.org
Why? The required dependencies are only in 5,19, and are definitely NOT a stable candidate...
This isn't a fix by any stretch of the imagination.
Hi Marc,
While I didn't mark it for stable (and it shouldn't go into any branch earlier than 5.19.x), I did send the patches making the irqchips immutable to Linus Torvalds as fixes as they technically do *fix* the warning emitted by gpiolib and make the implementation correct.
I think these patches should still be part of the v5.19.x stable branch.
Yes, and as far as I see we are taking those fixes too.
From: Hamza Mahfooz hamza.mahfooz@amd.com
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs struct.
Signed-off-by: Hamza Mahfooz hamza.mahfooz@amd.com Acked-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index b588e0e409e7..d8687868407d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -35,6 +35,7 @@ #include <linux/pci.h> #include <linux/pm_runtime.h> #include <drm/drm_crtc_helper.h> +#include <drm/drm_damage_helper.h> #include <drm/drm_edid.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_fb_helper.h> @@ -495,6 +496,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector, static const struct drm_framebuffer_funcs amdgpu_fb_funcs = { .destroy = drm_gem_fb_destroy, .create_handle = drm_gem_fb_create_handle, + .dirty = drm_atomic_helper_dirtyfb, };
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
On 2022-09-21 17:54, Sasha Levin wrote:
From: Hamza Mahfooz hamza.mahfooz@amd.com
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs struct.
Signed-off-by: Hamza Mahfooz hamza.mahfooz@amd.com Acked-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index b588e0e409e7..d8687868407d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -35,6 +35,7 @@ #include <linux/pci.h> #include <linux/pm_runtime.h> #include <drm/drm_crtc_helper.h> +#include <drm/drm_damage_helper.h> #include <drm/drm_edid.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_fb_helper.h> @@ -495,6 +496,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector, static const struct drm_framebuffer_funcs amdgpu_fb_funcs = { .destroy = drm_gem_fb_destroy, .create_handle = drm_gem_fb_create_handle,
- .dirty = drm_atomic_helper_dirtyfb,
}; uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
This patch has issues, see https://patchwork.freedesktop.org/patch/503749/ .
From: Yao Wang1 Yao.Wang1@amd.com
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value.
[How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths.
Tested-by: Daniel Wheeler daniel.wheeler@amd.com Reviewed-by: Krunoslav Kovac Krunoslav.Kovac@amd.com Reviewed-by: Aric Cyr Aric.Cyr@amd.com Acked-by: Pavle Kotarac Pavle.Kotarac@amd.com Signed-off-by: Yao Wang1 Yao.Wang1@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index e042d8ce05b4..22d105635e33 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1486,6 +1486,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num, struct fixed31_32 lut2; struct fixed31_32 delta_lut; struct fixed31_32 delta_index; + const struct fixed31_32 one = dc_fixpt_from_int(1);
i = 0; /* fixed_pt library has problems handling too small values */ @@ -1514,6 +1515,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, } else hw_x = coordinates_x[i].x;
+ if (dc_fixpt_le(one, hw_x)) + hw_x = one; + norm_x = dc_fixpt_mul(norm_factor, hw_x); index = dc_fixpt_floor(norm_x); if (index < 0 || index > 255)
From: Nathan Huckleberry nhuck@google.com
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of type: enum drm_mode_status (* mode_valid) (struct drm_connector *connector, struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from int to enum drm_mode_status.
Reported-by: Dan Carpenter error27@gmail.com Link: https://github.com/ClangBuiltLinux/linux/issues/1703 Cc: llvm@lists.linux.dev Signed-off-by: Nathan Huckleberry nhuck@google.com Reviewed-by: Nathan Chancellor nathan@kernel.org Signed-off-by: Heiko Stuebner heiko@sntech.de Link: https://patchwork.freedesktop.org/patch/msgid/20220913205555.155149-1-nhuck@... Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c index 8f299d76b69b..67dae1354aa6 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -275,8 +275,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector *connector) return ret; }
-static int cdn_dp_connector_mode_valid(struct drm_connector *connector, - struct drm_display_mode *mode) +static enum drm_mode_status +cdn_dp_connector_mode_valid(struct drm_connector *connector, + struct drm_display_mode *mode) { struct cdn_dp_device *dp = connector_to_dp(connector); struct drm_display_info *display_info = &dp->connector.display_info;
linux-stable-mirror@lists.linaro.org
-
Bartosz Golaszewski -
Marc Zyngier -
Michel Dänzer -
Sasha Levin