* [PATCH v4 1/9] dt-bindings: iio: dac: adi-axi-adc: add ad7606 variant
From: Angelo Dureghello @ 2025-02-10 16:10 UTC (permalink / raw)
To: Michael Hennerich, Lars-Peter Clausen, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandru Ardelean, David Lechner
Cc: Jonathan Cameron, linux-fbdev, linux-iio, devicetree,
linux-kernel, Guillaume Stols, Angelo Dureghello
In-Reply-To: <20250210-wip-bl-ad7606_add_backend_sw_mode-v4-0-160df18b1da7@baylibre.com>
From: Guillaume Stols <gstols@baylibre.com>
A new compatible is added to reflect the specialized version of the HDL.
We use the parallel interface to write the ADC's registers, and
accessing this interface requires to use ADI_AXI_REG_CONFIG_RD,
ADI_AXI_REG_CONFIG_WR and ADI_AXI_REG_CONFIG_CTRL in a custom fashion.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Guillaume Stols <gstols@baylibre.com>
Co-developed-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
.../devicetree/bindings/iio/adc/adi,axi-adc.yaml | 70 +++++++++++++++++++++-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
index e1f450b80db2..4fa82dcf6fc9 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
@@ -17,13 +17,23 @@ description: |
interface for the actual ADC, while this IP core will interface
to the data-lines of the ADC and handle the streaming of data into
memory via DMA.
+ In some cases, the AXI ADC interface is used to perform specialized
+ operation to a particular ADC, e.g access the physical bus through
+ specific registers to write ADC registers.
+ In this case, we use a different compatible which indicates the target
+ IP core's name.
+ The following IP is currently supported:
+ - AXI AD7606x: specialized version of the IP core for all the chips from
+ the ad7606 family.
https://wiki.analog.com/resources/fpga/docs/axi_adc_ip
+ http://analogdevicesinc.github.io/hdl/library/axi_ad7606x/index.html
properties:
compatible:
enum:
- adi,axi-adc-10.0.a
+ - adi,axi-ad7606x
reg:
maxItems: 1
@@ -47,17 +57,48 @@ properties:
'#io-backend-cells':
const: 0
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^adc@[0-9a-f]+$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+ additionalProperties: true
+ required:
+ - compatible
+ - reg
+
required:
- compatible
- dmas
- reg
- clocks
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: adi,axi-ad7606x
+ then:
+ properties:
+ '#address-cells': false
+ '#size-cells': false
+ patternProperties:
+ "^adc@[0-9a-f]+$": false
+
additionalProperties: false
examples:
- |
- axi-adc@44a00000 {
+ adc@44a00000 {
compatible = "adi,axi-adc-10.0.a";
reg = <0x44a00000 0x10000>;
dmas = <&rx_dma 0>;
@@ -65,4 +106,31 @@ examples:
clocks = <&axi_clk>;
#io-backend-cells = <0>;
};
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ parallel_bus_controller@44a00000 {
+ compatible = "adi,axi-ad7606x";
+ reg = <0x44a00000 0x10000>;
+ dmas = <&rx_dma 0>;
+ dma-names = "rx";
+ clocks = <&ext_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7606b";
+ reg = <0>;
+ pwms = <&axi_pwm_gen 0 0>;
+ pwm-names = "convst1";
+ avcc-supply = <&adc_vref>;
+ vdrive-supply = <&vdd_supply>;
+ reset-gpios = <&gpio0 91 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;
+ adi,range-gpios = <&gpio0 89 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio0 88 GPIO_ACTIVE_HIGH
+ &gpio0 87 GPIO_ACTIVE_HIGH
+ &gpio0 86 GPIO_ACTIVE_HIGH>;
+ io-backends = <¶llel_bus_controller>;
+ };
+ };
...
--
2.47.0
^ permalink raw reply related
* [PATCH v4 0/9] add support for Software mode on AD7606's iio backend driver
From: Angelo Dureghello @ 2025-02-10 16:10 UTC (permalink / raw)
To: Michael Hennerich, Lars-Peter Clausen, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandru Ardelean, David Lechner
Cc: Jonathan Cameron, linux-fbdev, linux-iio, devicetree,
linux-kernel, Guillaume Stols, Angelo Dureghello
The previous series added iio_backend mode, but the configuration for this
mode was only possible through GPIOs (Hardware mode). Here, we add support
for configuring the chip using its registers (Software mode).
The bus access is based on Angelo's ad3552 implementation, that is we have
a particular compatible for the backend (here axi-adc) version supporting
the ad7606's register writing, and the ad7606 is defined as a child node
of the backend in the devicetree. Small changes are added to make the code
a bit more straightforward to understand, and more compact.
Signed-off-by: Guillaume Stols <gstols@baylibre.com>
Co-developed-by: Angelo Dureghello <adureghello@baylibre.com>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v4:
- some spaces / tabs fixes,
- fix child nodes creation as done for dac,
- change usleep_range into flseep,
- use just a u32 as a value in bus access functions,
- protect bus access from concurrent access,
- Link to v3: https://lore.kernel.org/r/20250129-wip-bl-ad7606_add_backend_sw_mode-v3-0-c3aec77c0ab7@baylibre.com
Changes in v3:
- add some fixes found while testing,
- general commit meessages fixes,
- codying style fixes,
- dt-bindings: add some properties as requirted,
- use iio_device_claim_direct_mode (and release),
- rename bus read/write functions with "bus" as done for ad3552r.
Changes in v2:
- Improved descriptions.
- dt-bindings: improved descriptions, added exemple and additional
property for the custom IP.
- Reworked some macro commits to avoid changing order and associated
diff artifacts.
- Various cleanups and formatting fixes.
- Link to v1: https://lore.kernel.org/r/20241121-ad7606_add_iio_backend_software_mode-v1-0-8a693a5e3fa9@baylibre.com
---
Angelo Dureghello (3):
iio: adc: adi-axi-adc: add struct axi_adc_info
iio: adc: adi-axi-adc: add platform children support
iio: adc: ad7606: protect register access
Guillaume Stols (6):
dt-bindings: iio: dac: adi-axi-adc: add ad7606 variant
iio: adc: ad7606: move the software mode configuration
iio: adc: ad7606: move software functions into common file
iio: adc: adi-axi-adc: add support for AD7606 register writing
iio: adc: ad7606: change channel macros parameters
iio: adc: ad7606: add support for writing registers when using backend
.../devicetree/bindings/iio/adc/adi,axi-adc.yaml | 70 +++++++-
drivers/iio/adc/ad7606.c | 159 +++++++++++++++++--
drivers/iio/adc/ad7606.h | 103 ++++++++----
drivers/iio/adc/ad7606_bus_iface.h | 16 ++
drivers/iio/adc/ad7606_par.c | 52 +++++-
drivers/iio/adc/ad7606_spi.c | 137 +---------------
drivers/iio/adc/adi-axi-adc.c | 176 +++++++++++++++++++--
7 files changed, 516 insertions(+), 197 deletions(-)
---
base-commit: 4692f10bec7459a0baa95bdfa66a4ea740ec9e0a
change-id: 20250129-wip-bl-ad7606_add_backend_sw_mode-dd22a50663f3
Best regards,
--
Angelo Dureghello <adureghello@baylibre.com>
^ permalink raw reply
* Re: hyper_bf soft lockup on Azure Gen2 VM when taking kdump or executing kexec
From: thomas.tai @ 2025-02-10 15:08 UTC (permalink / raw)
To: Michael Kelley, mhkelley58@gmail.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, drawat.floss@gmail.com,
javierm@redhat.com, Helge Deller, daniel@ffwll.ch,
airlied@gmail.com, tzimmermann@suse.de
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB41572155B6D139C499814EB7D4F12@SN6PR02MB4157.namprd02.prod.outlook.com>
<snip>
>> Then the question is why the efifb driver doesn't work in the kdump
>> kernel. Actually, it *does* work in many cases. I built the 6.13.0 kernel
>> on the Oracle Linux 9.4 system, and transferred the kernel image binary
>> and module binaries to an Ubuntu 20.04 VM in Azure. In that VM, the
>> efifb driver is loaded as part of the kdump kernel, and it doesn't cause
>> any problems. But there's an interesting difference. In the Oracle Linux
>> 9.4 VM, the efifb driver finds the framebuffer at 0x40000000, while on
>> the Ubuntu 20.04 VM, it finds the framebuffer at 0x40900000. This
>> difference is due to differences in how the screen_info variable gets
>> setup in the two VMs.
>>
>> When the normal kernel starts in a freshly booted VM, Hyper-V provides
>> the EFI framebuffer at 0x40000000, and it works. But after the Hyper-V
>> FB driver or Hyper-V DRM driver has initialized, Linux has picked a
>> different MMIO address range and told Hyper-V to use the new
>> address range (which often starts at 0x40900000). A kexec does *not*
>> reset Hyper-V's transition to the new range, so when the efifb driver
>> tries to use the framebuffer at 0x40000000, the accesses trap to
>> Hyper-V and probably fail or timeout (I'm not sure of the details). After
>> the guest does some number of these bad references, Hyper-V considers
>> itself to be under attack from an ill-behaving guest, and throttles the
>> guest so that it doesn't run for a few seconds. The throttling repeats,
>> and results in extremely slow running in the kdump kernel.
>>
>> Somehow in the Ubuntu 20.04 VM, the location of the frame buffer
>> as stored in screen_info.lfb_base gets updated to be 0x40900000. I
>> haven't fully debugged how that happens. But with that update, the
>> efifb driver is using the updated framebuffer address and it works. On
>> the Oracle Linux 9.4 system, that update doesn't appear to happen,
>> and the problem occurs.
>>
>> This in an interim update on the problem. I'm still investigating how
>> screen_info.lfb_base is set in the kdump kernel, and why it is different
>> in the Ubuntu 20.04 VM vs. in the Oracle Linux 9.4 VM. Once that is
>> well understood, we can contemplate how to fix the problem. Undoing
>> the revert that is commit 2bebc3cd4870 doesn't seem like the solution
>> since the original code there was reported to cause many other issues.
>> The solution focus will likely be on how to ensure the kdump kernel gets
>> the correct framebuffer address so the efifb driver works, since the
>> framebuffer address changing is a quirk of Hyper-V behavior.
>>
>> If anyone else has insight into what's going on here, please chime in.
>> What I've learned so far is still somewhat tentative.
>>
> Here's what is happening. On Ubuntu 20.04, the kdump image is
> loaded into crash memory using the kexec command. Ubuntu 20.04
> has kexec from the kexec-tools package version 2.0.18-1ubuntu1.1,
> and per the kexec man page, it defaults to using the older kexec_load()
> system call. When using kexec_load(), the contents to be loaded into
> crash memory is constructed in user space by the kexec command.
> The kexec command gets the "screen_info" settings, including the
> physical address of the frame buffer, via the FBIOGET_FSCREENINFO
> ioctl against /dev/fb0. The Hyper-V FB or DRM driver registers itself
> with the fbdev subsystem so that it is /dev/fb0, and the ioctl returns
> the updated framebuffer address. So the efifb driver loads and runs
> correctly.
>
> On Oracle Linux 9.4, the kdump image is also loaded with the
> kexec command, but from kexec-tools package version
> kexec-tools-2.0.28-1.0.10.el9_5.x86_64, which is slightly later than
> the version on Ubuntu 20.04. This newer kexec defaults to using the
> newer kexec_file_load() system call. This system call gets the
> framebuffer address from the screen_info variable in the kernel, which
> has not been updated to reflect the new framebuffer address. Hence
> in the kdump kernel, the efifb driver uses the old framebuffer address,
> and hence the problem.
>
> To further complicate matters, the kexec on Oracle Linux 9.4 seems to
> have a bug when the -c option forces the use of kexec_load() instead
> of kexec_file_load(). As an experiment, I modified the kdumpctl shell
> script to add the "-c" option to kexec, but in that case the value "0x0"
> is passed as the framebuffer address, which is wrong. Furthermore,
> the " screen_info.orig_video_isVGA" value (which I mentioned earlier
> in connection with commit 2bebc3cd4870) is also set to 0, so the
> kdump kernel no longer thinks it has an EFI framebuffer. Hence the
> efifb driver isn't loaded, and the kdump works, though for the wrong
> reasons. If kexec 2.0.18 from Ubuntu is copied onto the Oracle Linux 9.4
> VM, then kdump works as expected, with the efifb driver being loaded
> and using the correct framebuffer address. So something is going wrong
> with kexec 2.0.28 in how it sets up the screen_info when the -c option
> is used. I'll leave the debugging of the kexec bug to someone else.
Hi Michael,
Do you think we need to handle Azure Gen2 VM differently in the kexec?
Or should we change the kexec_file_load() system call to
retrieve the correct framebuffer address?
Thank you,
Thomas
> I'm still thinking about alternatives to fix this mess. Please chime
> in if you have suggestions.
>
> Michael
^ permalink raw reply
* Re: [PATCH 1/1] fbdev: hyperv_fb: iounmap() the correct memory when removing a device
From: Saurabh Singh Sengar @ 2025-02-10 14:58 UTC (permalink / raw)
To: Michael Kelley
Cc: haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
deller@gmx.de, weh@microsoft.com, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB4157B0F36D7B99A5BF01471CD4F22@SN6PR02MB4157.namprd02.prod.outlook.com>
On Mon, Feb 10, 2025 at 02:28:35PM +0000, Michael Kelley wrote:
> From: Saurabh Singh Sengar <ssengar@linux.microsoft.com> Sent: Monday, February 10, 2025 4:41 AM
> >
> > On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelley58@gmail.com wrote:
> > > From: Michael Kelley <mhklinux@outlook.com>
> > >
> > > When a Hyper-V framebuffer device is removed, or the driver is unbound
> > > from a device, any allocated and/or mapped memory must be released. In
> > > particular, MMIO address space that was mapped to the framebuffer must
> > > be unmapped. Current code unmaps the wrong address, resulting in an
> > > error like:
> > >
> > > [ 4093.980597] iounmap: bad address 00000000c936c05c
> > >
> > > followed by a stack dump.
> > >
> > > Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> > > Hyper-V frame buffer driver") changed the kind of address stored in
> > > info->screen_base, and the iounmap() call in hvfb_putmem() was not
> > > updated accordingly.
> > >
> > > Fix this by updating hvfb_putmem() to unmap the correct address.
> > >
> > > Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
> > > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> > > ---
> > > drivers/video/fbdev/hyperv_fb.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> > > index 7fdb5edd7e2e..363e4ccfcdb7 100644
> > > --- a/drivers/video/fbdev/hyperv_fb.c
> > > +++ b/drivers/video/fbdev/hyperv_fb.c
> > > @@ -1080,7 +1080,7 @@ static void hvfb_putmem(struct hv_device *hdev, struct fb_info *info)
> > >
> > > if (par->need_docopy) {
> > > vfree(par->dio_vp);
> > > - iounmap(info->screen_base);
> > > + iounmap(par->mmio_vp);
> > > vmbus_free_mmio(par->mem->start, screen_fb_size);
> > > } else {
> > > hvfb_release_phymem(hdev, info->fix.smem_start,
> > > --
> > > 2.25.1
> > >
> >
> > Thanks for fixing this:
> > Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> >
> >
> > While we are at it, I want to mention that I also observed below WARN
> > while removing the hyperv_fb, but that needs a separate fix.
> >
> >
> > [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40
> > < snip >
> > [ 44.111289] Call Trace:
> > [ 44.111290] <TASK>
> > [ 44.111291] ? show_regs+0x6c/0x80
> > [ 44.111295] ? __warn+0x8d/0x150
> > [ 44.111298] ? framebuffer_release+0x2c/0x40
> > [ 44.111300] ? report_bug+0x182/0x1b0
> > [ 44.111303] ? handle_bug+0x6e/0xb0
> > [ 44.111306] ? exc_invalid_op+0x18/0x80
> > [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20
> > [ 44.111311] ? framebuffer_release+0x2c/0x40
> > [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb]
> > [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus]
> > [ 44.111323] device_remove+0x40/0x80
> > [ 44.111325] device_release_driver_internal+0x20b/0x270
> > [ 44.111327] ? bus_find_device+0xb3/0xf0
> >
>
> Thanks for pointing this out. Interestingly, I'm not seeing this WARN
> in my experiments. What base kernel are you testing with? Are you
> testing on a local VM or in Azure? What exactly are you doing
> to create the problem? I've been doing unbind of the driver,
> but maybe you are doing something different.
>
> FWIW, there is yet another issue where after doing two unbind/bind
> cycles of the hyperv_fb driver, there's an error about freeing a
> non-existent resource. I know what that problem is, and it's in
> vmbus_drv.c. I'll be submitting a patch for that as soon as I figure out
> a clean fix.
>
> Michael
This is on local Hyper-V. Kernel: 6.14.0-rc1-next-20250205+
I run below command to reproduce the above error:
echo "5620e0c7-8062-4dce-aeb7-520c7ef76171" > /sys/bus/vmbus/devices/5620e0c7-8062-4dce-aeb7-520c7ef76171/driver/unbind
When hvfb_remove is called I can see the refcount for framebuffer is 2 when ,
I expect it to be 1. After unregistering this framebuffer there is still 1 refcount
remains, which is the reason for this WARN at the time of framebuffer_release.
I wonder who is registering/using this extra framebuffer. Its not hyperv_drm or
hyperv_fb IIUC.
- Saurabh
^ permalink raw reply
* RE: [PATCH 1/1] fbdev: hyperv_fb: iounmap() the correct memory when removing a device
From: Michael Kelley @ 2025-02-10 14:28 UTC (permalink / raw)
To: Saurabh Singh Sengar
Cc: haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
deller@gmx.de, weh@microsoft.com, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org
In-Reply-To: <20250210124043.GA17819@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
From: Saurabh Singh Sengar <ssengar@linux.microsoft.com> Sent: Monday, February 10, 2025 4:41 AM
>
> On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelley58@gmail.com wrote:
> > From: Michael Kelley <mhklinux@outlook.com>
> >
> > When a Hyper-V framebuffer device is removed, or the driver is unbound
> > from a device, any allocated and/or mapped memory must be released. In
> > particular, MMIO address space that was mapped to the framebuffer must
> > be unmapped. Current code unmaps the wrong address, resulting in an
> > error like:
> >
> > [ 4093.980597] iounmap: bad address 00000000c936c05c
> >
> > followed by a stack dump.
> >
> > Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> > Hyper-V frame buffer driver") changed the kind of address stored in
> > info->screen_base, and the iounmap() call in hvfb_putmem() was not
> > updated accordingly.
> >
> > Fix this by updating hvfb_putmem() to unmap the correct address.
> >
> > Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
> > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> > ---
> > drivers/video/fbdev/hyperv_fb.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> > index 7fdb5edd7e2e..363e4ccfcdb7 100644
> > --- a/drivers/video/fbdev/hyperv_fb.c
> > +++ b/drivers/video/fbdev/hyperv_fb.c
> > @@ -1080,7 +1080,7 @@ static void hvfb_putmem(struct hv_device *hdev, struct fb_info *info)
> >
> > if (par->need_docopy) {
> > vfree(par->dio_vp);
> > - iounmap(info->screen_base);
> > + iounmap(par->mmio_vp);
> > vmbus_free_mmio(par->mem->start, screen_fb_size);
> > } else {
> > hvfb_release_phymem(hdev, info->fix.smem_start,
> > --
> > 2.25.1
> >
>
> Thanks for fixing this:
> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
>
>
> While we are at it, I want to mention that I also observed below WARN
> while removing the hyperv_fb, but that needs a separate fix.
>
>
> [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40
> < snip >
> [ 44.111289] Call Trace:
> [ 44.111290] <TASK>
> [ 44.111291] ? show_regs+0x6c/0x80
> [ 44.111295] ? __warn+0x8d/0x150
> [ 44.111298] ? framebuffer_release+0x2c/0x40
> [ 44.111300] ? report_bug+0x182/0x1b0
> [ 44.111303] ? handle_bug+0x6e/0xb0
> [ 44.111306] ? exc_invalid_op+0x18/0x80
> [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20
> [ 44.111311] ? framebuffer_release+0x2c/0x40
> [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb]
> [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus]
> [ 44.111323] device_remove+0x40/0x80
> [ 44.111325] device_release_driver_internal+0x20b/0x270
> [ 44.111327] ? bus_find_device+0xb3/0xf0
>
Thanks for pointing this out. Interestingly, I'm not seeing this WARN
in my experiments. What base kernel are you testing with? Are you
testing on a local VM or in Azure? What exactly are you doing
to create the problem? I've been doing unbind of the driver,
but maybe you are doing something different.
FWIW, there is yet another issue where after doing two unbind/bind
cycles of the hyperv_fb driver, there's an error about freeing a
non-existent resource. I know what that problem is, and it's in
vmbus_drv.c. I'll be submitting a patch for that as soon as I figure out
a clean fix.
Michael
^ permalink raw reply
* Re: [PATCH 1/1] fbdev: hyperv_fb: iounmap() the correct memory when removing a device
From: Saurabh Singh Sengar @ 2025-02-10 12:40 UTC (permalink / raw)
To: mhklinux
Cc: haiyangz, wei.liu, decui, deller, weh, dri-devel, linux-fbdev,
linux-kernel, linux-hyperv
In-Reply-To: <20250209235252.2987-1-mhklinux@outlook.com>
On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> When a Hyper-V framebuffer device is removed, or the driver is unbound
> from a device, any allocated and/or mapped memory must be released. In
> particular, MMIO address space that was mapped to the framebuffer must
> be unmapped. Current code unmaps the wrong address, resulting in an
> error like:
>
> [ 4093.980597] iounmap: bad address 00000000c936c05c
>
> followed by a stack dump.
>
> Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> Hyper-V frame buffer driver") changed the kind of address stored in
> info->screen_base, and the iounmap() call in hvfb_putmem() was not
> updated accordingly.
>
> Fix this by updating hvfb_putmem() to unmap the correct address.
>
> Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> ---
> drivers/video/fbdev/hyperv_fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 7fdb5edd7e2e..363e4ccfcdb7 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -1080,7 +1080,7 @@ static void hvfb_putmem(struct hv_device *hdev, struct fb_info *info)
>
> if (par->need_docopy) {
> vfree(par->dio_vp);
> - iounmap(info->screen_base);
> + iounmap(par->mmio_vp);
> vmbus_free_mmio(par->mem->start, screen_fb_size);
> } else {
> hvfb_release_phymem(hdev, info->fix.smem_start,
> --
> 2.25.1
>
Thanks for fixing this:
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
While we are at it, I want to mention that I also observed below WARN
while removing the hyperv_fb, but that needs a separate fix.
[ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40
< snip >
[ 44.111289] Call Trace:
[ 44.111290] <TASK>
[ 44.111291] ? show_regs+0x6c/0x80
[ 44.111295] ? __warn+0x8d/0x150
[ 44.111298] ? framebuffer_release+0x2c/0x40
[ 44.111300] ? report_bug+0x182/0x1b0
[ 44.111303] ? handle_bug+0x6e/0xb0
[ 44.111306] ? exc_invalid_op+0x18/0x80
[ 44.111308] ? asm_exc_invalid_op+0x1b/0x20
[ 44.111311] ? framebuffer_release+0x2c/0x40
[ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb]
[ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus]
[ 44.111323] device_remove+0x40/0x80
[ 44.111325] device_release_driver_internal+0x20b/0x270
[ 44.111327] ? bus_find_device+0xb3/0xf0
- Saurabh
^ permalink raw reply
* Re: [PATCH RESEND 00/13] fbdev: core: Deduplicate cfb/sys drawing fbops
From: Thomas Zimmermann @ 2025-02-10 9:24 UTC (permalink / raw)
To: Kajtár Zsolt, linux-fbdev, dri-devel
In-Reply-To: <8c0aa1f0-27f8-befa-2b27-76e9faf7fc6d@c64.rulez.org>
Hi
Am 08.02.25 um 01:51 schrieb Kajtár Zsolt:
> Hello Thomas!
>
>> No it's not. Major code abstractions behind preprocessor tokens are
>> terrible to maintain.
> Hmm, don't get me wrong but I'm not sure if the changes were really
> checked in detail. At first sight it might look like I'm adding tons of
> new macro ridden code in those header files replacing cleaner code.
>
> While actually that's just how the I/O version currently is, copied and
> white space cleaned (as it was requested) plus comment style matched
> with sys.
>
> The only new thing which hides the mentioned abstraction a little more
> is FB_MEM, which replaced __iomem. But that's a tradeoff to be able to
> use the same source for system as well.
>
> Or the concern is that now system memory specific code might get mixed
> in there by mistake?
>
> It was not planned as the final version, the current maintainer asked
> for addressing some pre-existing quality issues with further patches but
> otherwise accepted the taken approach.
>
>> It's also technically not possible to switch between system and I/O
>> memory at will. These are very different things.
> Yes, there are architectures where these two don't mix at all, I'm aware
> of that. I need that on x86 only (for old hw), and there it seems
> doable. Depending on the resolution either the aperture or the defio
> memory is mapped. If the framebuffer is not remapped after a mode change
> that's an application bug. Otherwise it's harmless as both are always
> there and don't change.
>
> I'd better like to find out problems sooner than later, so if you or
> anyone else could share any concerns that'd be really helpful!
First of all, commit 779121e9f175 ("fbdev: Support for byte-reversed
framebuffer formats") isn't super complicated AFAICT. I can be
implemented in the sys_ helpers as well. It seems like you initially did
that.
About the series at hand: generating code by macro expansion is good for
simple cases. I've done that in several places within fbdev myself, such
as [1]. But if the generated code requires Turing-completeness, it
becomes much harder to see through the macros and understand what is
going on. This makes code undiscoverable; and discoverability is a
requirement for maintenance.
[1] https://elixir.bootlin.com/linux/v6.13.1/source/include/linux/fb.h#L700
Then there's type-safety and type-casting. The current series defeats it
by casting various pointers to whatever the macros define. For example,
looking at the copyarea patches, they use screen_base [2] from struct
fb_info. The thing is, using screen_base is wrong for sys_copyarea().
The function should use 'screen_buffer' instead. It works because both
fields share the same bits of a union. Using screen_base is a bug in the
current implementation that should be fixed, while this patch series
would set it in stone.
[2]
https://elixir.bootlin.com/linux/v6.13.1/source/drivers/video/fbdev/core/syscopyarea.c#L340
Next, if you look through the commit history, you'll find that there are
several commits with performance improvements. Memory access in the sys
variants is not guaranteed to be 32-bit aligned by default. The compiler
has to assume unaligned access, which results in slower code. Hence,
some manual intervention has to be done. It's too easy to accidentally
mess this up by using nontransparent macros for access.
If you want to do meaningful work here, please do actual refactoring
instead of throwing unrelated code together. First of all, never use
macros, but functions. You can supply callback functions to access the
framebuffer. Each callback should know whether it operates on
screen_base or screen_buffer.
But using callbacks for individual reads and writes can have runtime
overhead. It's better to operate on complete scanlines. The current
helpers are already organized that way. Again, from the copyarea helper:
sys_copyarea()
{
// first prepare
// then go through the scanlines
while (height) {
do_something_for_the_current_scanline().
}
}
The inner helper do_something_...() has to be written for various cfb
and sys cases and can be given as function pointer to a generic helper.
Best regards
Thomas
>
>> If you want that pixel-reversing feature in sys_ helpers, please
>> implement it there.
> Actually that's what I did first. Then did it once more by adapting the
> I/O version as that gave me more confidence that it'll work exactly the
> same and there's less room for error.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* [PATCH 1/1] fbdev: hyperv_fb: iounmap() the correct memory when removing a device
From: mhkelley58 @ 2025-02-09 23:52 UTC (permalink / raw)
To: haiyangz, wei.liu, decui, deller, weh
Cc: dri-devel, linux-fbdev, linux-kernel, linux-hyperv
From: Michael Kelley <mhklinux@outlook.com>
When a Hyper-V framebuffer device is removed, or the driver is unbound
from a device, any allocated and/or mapped memory must be released. In
particular, MMIO address space that was mapped to the framebuffer must
be unmapped. Current code unmaps the wrong address, resulting in an
error like:
[ 4093.980597] iounmap: bad address 00000000c936c05c
followed by a stack dump.
Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
Hyper-V frame buffer driver") changed the kind of address stored in
info->screen_base, and the iounmap() call in hvfb_putmem() was not
updated accordingly.
Fix this by updating hvfb_putmem() to unmap the correct address.
Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
drivers/video/fbdev/hyperv_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 7fdb5edd7e2e..363e4ccfcdb7 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1080,7 +1080,7 @@ static void hvfb_putmem(struct hv_device *hdev, struct fb_info *info)
if (par->need_docopy) {
vfree(par->dio_vp);
- iounmap(info->screen_base);
+ iounmap(par->mmio_vp);
vmbus_free_mmio(par->mem->start, screen_fb_size);
} else {
hvfb_release_phymem(hdev, info->fix.smem_start,
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 RESEND 0/3] Apple DWI backlight driver
From: Neal Gompa @ 2025-02-09 11:22 UTC (permalink / raw)
To: Nick Chan
Cc: Hector Martin, Sven Peter, Alyssa Rosenzweig, Lee Jones,
Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, asahi,
linux-arm-kernel, dri-devel, linux-leds, devicetree, linux-kernel,
linux-fbdev, Janne Grunau
In-Reply-To: <20250203115156.28174-1-towinchenmi@gmail.com>
On Mon, Feb 3, 2025 at 6:52 AM Nick Chan <towinchenmi@gmail.com> wrote:
>
> Apple SoCs come with a 2-wire interface named DWI. On some iPhones, iPads
> and iPod touches the backlight controller is connected via this interface.
> This series adds a backlight driver for backlight controllers connected
> this way.
>
> Changes since v4:
> - Change type to BACKLIGHT_PLATFORM since the driver does not directly
> interface with the backlight controller. The actual backlight controller
> can be directly controlled via i2c and is not the same on all hardware
> that supports the dwi interface.
> - Rename file to apple_dwi_bl.c to better match config option.
> - Rename driver to apple-dwi-bl to better match config option
> - Indicate that the backlight scales linearly
>
> v4: https://lore.kernel.org/asahi/20241211113512.19009-1-towinchenmi@gmail.com/T
>
> Changes since v3:
> - $ref to common.yaml in bindings
> - (and then additionalProperties is changed to unevaluatedProperties)
> - Use hex everywhere in bindings example
> - Use sizeof(*dwi_bl) instead of the type of the struct when doing
> devm_kzalloc()
> - Use devm_platform_get_and_ioremap_resource() in driver
> - Fix sorting in drivers/video/backlight/Makefile
> - In drivers/video/backlight/Kconfig, move config to right after
> BACKLIGHT_APPLE
> - Explain this driver being completely different from apple_bl
>
> v3: https://lore.kernel.org/asahi/20241209075908.140014-1-towinchenmi@gmail.com/T
>
> Changes since v2:
> - Add missing includes in driver
> - Fix file path in MAINTAINERS
>
> v2: https://lore.kernel.org/asahi/20241207130433.30351-1-towinchenmi@gmail.com/T
>
> Changes since v1:
> - Fixed dt-bindings $id.
> - Make power-domains an optional property in dt-bindings.
> - Added missing error checking after devm_ioremap_resource() in
> dwi_bl_probe().
>
> v1: https://lore.kernel.org/asahi/20241206172735.4310-1-towinchenmi@gmail.com/T
>
> Nick Chan
>
> ---
> Nick Chan (3):
> dt-bindings: leds: backlight: apple,dwi-bl: Add Apple DWI backlight
> backlight: apple_dwi_bl: Add Apple DWI backlight driver
> MAINTAINERS: Add entries for Apple DWI backlight controller
>
> .../bindings/leds/backlight/apple,dwi-bl.yaml | 57 ++++++++
> MAINTAINERS | 2 +
> drivers/video/backlight/Kconfig | 12 ++
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/apple_dwi_bl.c | 123 ++++++++++++++++++
> 5 files changed, 195 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml
> create mode 100644 drivers/video/backlight/apple_dwi_bl.c
>
>
> base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
> --
> 2.48.1
>
>
This series looks good to me.
Reviewed-by: Neal Gompa <neal@gompa.dev>
--
真実はいつも一つ！/ Always, there's only one truth!
^ permalink raw reply
* Re: [PATCH v3 3/3] fb_defio: do not use deprecated page->mapping, index fields
From: Lorenzo Stoakes @ 2025-02-09 6:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaya Kumar, Simona Vetter, Helge Deller, linux-fbdev, dri-devel,
linux-kernel, linux-mm, Matthew Wilcox, David Hildenbrand,
Kajtar Zsolt, Maira Canal, Simona Vetter, Thomas Zimmermann
In-Reply-To: <81171ab16c14e3df28f6de9d14982cee528d8519.1739029358.git.lorenzo.stoakes@oracle.com>
Andrew - apologies for this, I managed to miss some unusued variable warnings in
this nommu workaround, once you take the v3 could you apply this trivial
fix-patch on top to resolve that?
I tested this locally to confirm it resolves the problem. Thanks!
----8<----
From f428a950a5a932c0e4404a89f2a34b0683728016 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Sun, 9 Feb 2025 06:29:25 +0000
Subject: [PATCH] mm: fixup unused variable warnings
Unfortunately fb_defio being enabled by nommu devices seems enormously
ingrained in the kernel to the point that it's not feasible to address that
in this series, so we use an ifdef to workaround.
However this workaround unfortunately missed some unused variables -
correct this.
This has been tested locally with W=1 and confirmed to resolve the issue.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
drivers/video/fbdev/core/fb_defio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index acf7bc7ac45f..4fc93f253e06 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -265,15 +265,15 @@ static void fb_deferred_io_work(struct work_struct *work)
/* here we wrprotect the page's mappings, then do all deferred IO. */
mutex_lock(&fbdefio->lock);
+#ifdef CONFIG_MMU
list_for_each_entry(pageref, &fbdefio->pagereflist, list) {
struct page *page = pageref->page;
pgoff_t pgoff = pageref->offset >> PAGE_SHIFT;
-#ifdef CONFIG_MMU
mapping_wrprotect_range(fbdefio->mapping, pgoff,
page_to_pfn(page), 1);
-#endif
}
+#endif
/* driver's callback with pagereflist */
fbdefio->deferred_io(info, &fbdefio->pagereflist);
--
2.48.1
^ permalink raw reply related
* Re: The business loan-
From: David Song @ 2025-02-08 22:05 UTC (permalink / raw)
To: linux-fbdev
Hello,
My name is David Song, at AA4 FS, we are a consultancy and
brokerage Firm specializing in Growth Financial Loan and joint
partnership venture. We specialize in investments in all Private
and public sectors in a broad range of areas within our Financial
Investment Services.
We are experts in financial and operational management, due
diligence and capital planning in all markets and industries. Our
Investors wish to invest in any viable Project presented by your
Management after reviews on your Business Project Presentation
Plan.
We look forward to your Swift response. We also offer commission
to consultants and brokers for any partnership referrals.
Regards,
David Song
Senior Broker
AA4 Financial Services
13 Wonersh Way, Cheam,
Sutton, Surrey, SM2 7LX
Email: dsong@aa4financialservice.com
^ permalink raw reply
* [PATCH v3 1/3] mm: refactor rmap_walk_file() to separate out traversal logic
From: Lorenzo Stoakes @ 2025-02-08 15:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaya Kumar, Simona Vetter, Helge Deller, linux-fbdev, dri-devel,
linux-kernel, linux-mm, Matthew Wilcox, David Hildenbrand,
Kajtar Zsolt, Maira Canal, Simona Vetter, Thomas Zimmermann
In-Reply-To: <cover.1739029358.git.lorenzo.stoakes@oracle.com>
In order to permit the traversal of the reverse mapping at a specified
mapping and offset rather than those specified by an input folio, we need
to separate out the portion of the rmap file logic which deals with this
traversal from those parts of the logic which interact with the folio.
This patch achieves this by adding a new static __rmap_walk_file() function
which rmap_walk_file() invokes.
This function permits the ability to pass NULL folio, on the assumption
that the caller has provided for this correctly in the callbacks specified
in the rmap_walk_control object.
Though it provides for this, and adds debug asserts to ensure that, should
a folio be specified, these are equal to the mapping and offset specified
in the folio, there should be no functional change as a result of this
patch.
The reason for adding this is to enable for future changes to permit users
to be able to traverse mappings of userland-mapped kernel memory,
write-protecting those mappings to enable page_mkwrite() or pfn_mkwrite()
fault handlers to be retriggered on subsequent dirty.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
mm/rmap.c | 79 +++++++++++++++++++++++++++++++++++++------------------
1 file changed, 53 insertions(+), 26 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 7825707929d8..52f98f6ccb56 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2751,35 +2751,37 @@ static void rmap_walk_anon(struct folio *folio,
anon_vma_unlock_read(anon_vma);
}
-/*
- * rmap_walk_file - do something to file page using the object-based rmap method
- * @folio: the folio to be handled
- * @rwc: control variable according to each walk type
- * @locked: caller holds relevant rmap lock
+/**
+ * __rmap_walk_file() - Traverse the reverse mapping for a file-backed mapping
+ * of a page mapped within a specified page cache object at a specified offset.
*
- * Find all the mappings of a folio using the mapping pointer and the vma chains
- * contained in the address_space struct it points to.
+ * @folio: Either the folio whose mappings to traverse, or if NULL,
+ * the callbacks specified in @rwc will be configured such
+ * as to be able to look up mappings correctly.
+ * @mapping: The page cache object whose mapping VMAs we intend to
+ * traverse. If @folio is non-NULL, this should be equal to
+ * folio_mapping(folio).
+ * @pgoff_start: The offset within @mapping of the page which we are
+ * looking up. If @folio is non-NULL, this should be equal
+ * to folio_pgoff(folio).
+ * @nr_pages: The number of pages mapped by the mapping. If @folio is
+ * non-NULL, this should be equal to folio_nr_pages(folio).
+ * @rwc: The reverse mapping walk control object describing how
+ * the traversal should proceed.
+ * @locked: Is the @mapping already locked? If not, we acquire the
+ * lock.
*/
-static void rmap_walk_file(struct folio *folio,
- struct rmap_walk_control *rwc, bool locked)
+static void __rmap_walk_file(struct folio *folio, struct address_space *mapping,
+ pgoff_t pgoff_start, unsigned long nr_pages,
+ struct rmap_walk_control *rwc, bool locked)
{
- struct address_space *mapping = folio_mapping(folio);
- pgoff_t pgoff_start, pgoff_end;
+ pgoff_t pgoff_end = pgoff_start + nr_pages - 1;
struct vm_area_struct *vma;
- /*
- * The page lock not only makes sure that page->mapping cannot
- * suddenly be NULLified by truncation, it makes sure that the
- * structure at mapping cannot be freed and reused yet,
- * so we can safely take mapping->i_mmap_rwsem.
- */
- VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
-
- if (!mapping)
- return;
+ VM_WARN_ON_FOLIO(folio && mapping != folio_mapping(folio), folio);
+ VM_WARN_ON_FOLIO(folio && pgoff_start != folio_pgoff(folio), folio);
+ VM_WARN_ON_FOLIO(folio && nr_pages != folio_nr_pages(folio), folio);
- pgoff_start = folio_pgoff(folio);
- pgoff_end = pgoff_start + folio_nr_pages(folio) - 1;
if (!locked) {
if (i_mmap_trylock_read(mapping))
goto lookup;
@@ -2794,8 +2796,7 @@ static void rmap_walk_file(struct folio *folio,
lookup:
vma_interval_tree_foreach(vma, &mapping->i_mmap,
pgoff_start, pgoff_end) {
- unsigned long address = vma_address(vma, pgoff_start,
- folio_nr_pages(folio));
+ unsigned long address = vma_address(vma, pgoff_start, nr_pages);
VM_BUG_ON_VMA(address == -EFAULT, vma);
cond_resched();
@@ -2808,12 +2809,38 @@ static void rmap_walk_file(struct folio *folio,
if (rwc->done && rwc->done(folio))
goto done;
}
-
done:
if (!locked)
i_mmap_unlock_read(mapping);
}
+/*
+ * rmap_walk_file - do something to file page using the object-based rmap method
+ * @folio: the folio to be handled
+ * @rwc: control variable according to each walk type
+ * @locked: caller holds relevant rmap lock
+ *
+ * Find all the mappings of a folio using the mapping pointer and the vma chains
+ * contained in the address_space struct it points to.
+ */
+static void rmap_walk_file(struct folio *folio,
+ struct rmap_walk_control *rwc, bool locked)
+{
+ /*
+ * The folio lock not only makes sure that folio->mapping cannot
+ * suddenly be NULLified by truncation, it makes sure that the structure
+ * at mapping cannot be freed and reused yet, so we can safely take
+ * mapping->i_mmap_rwsem.
+ */
+ VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
+
+ if (!folio->mapping)
+ return;
+
+ __rmap_walk_file(folio, folio->mapping, folio->index,
+ folio_nr_pages(folio), rwc, locked);
+}
+
void rmap_walk(struct folio *folio, struct rmap_walk_control *rwc)
{
if (unlikely(folio_test_ksm(folio)))
--
2.48.1
^ permalink raw reply related
* [PATCH v3 2/3] mm: provide mapping_wrprotect_range() function
From: Lorenzo Stoakes @ 2025-02-08 15:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaya Kumar, Simona Vetter, Helge Deller, linux-fbdev, dri-devel,
linux-kernel, linux-mm, Matthew Wilcox, David Hildenbrand,
Kajtar Zsolt, Maira Canal, Simona Vetter, Thomas Zimmermann
In-Reply-To: <cover.1739029358.git.lorenzo.stoakes@oracle.com>
in the fb_defio video driver, page dirty state is used to determine when
frame buffer pages have been changed, allowing for batched, deferred I/O to
be performed for efficiency.
This implementation had only one means of doing so effectively - the use of
the folio_mkclean() function.
However, this use of the function is inappropriate, as the fb_defio
implementation allocates kernel memory to back the framebuffer, and then is
forced to specified page->index, mapping fields in order to permit the
folio_mkclean() rmap traversal to proceed correctly.
It is not correct to specify these fields on kernel-allocated memory, and
moreover since these are not folios, page->index, mapping are deprecated
fields, soon to be removed.
We therefore need to provide a means by which we can correctly traverse the
reverse mapping and write-protect mappings for a page backing an
address_space page cache object at a given offset.
This patch provides this - mapping_wrprotect_range() - which allows for
this operation to be performed for a specified address_space, offset, PFN
and size, without requiring a folio nor, of course, an inappropriate use of
page->index, mapping.
With this provided, we can subsequently adjust the fb_defio implementation
to make use of this function and avoid incorrect invocation of
folio_mkclean() and more importantly, incorrect manipulation of
page->index and mapping fields.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
include/linux/rmap.h | 3 ++
mm/rmap.c | 74 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 77 insertions(+)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 4509a43fe59f..e28622ee4648 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -754,6 +754,9 @@ unsigned long page_address_in_vma(const struct folio *folio,
*/
int folio_mkclean(struct folio *);
+int mapping_wrprotect_range(struct address_space *mapping, pgoff_t pgoff,
+ unsigned long pfn, unsigned long nr_pages);
+
int pfn_mkclean_range(unsigned long pfn, unsigned long nr_pages, pgoff_t pgoff,
struct vm_area_struct *vma);
diff --git a/mm/rmap.c b/mm/rmap.c
index 52f98f6ccb56..66cc318925bc 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1129,6 +1129,80 @@ int folio_mkclean(struct folio *folio)
}
EXPORT_SYMBOL_GPL(folio_mkclean);
+struct wrprotect_file_state {
+ int cleaned;
+ pgoff_t pgoff;
+ unsigned long pfn;
+ unsigned long nr_pages;
+};
+
+static bool mapping_wrprotect_range_one(struct folio *folio,
+ struct vm_area_struct *vma, unsigned long address, void *arg)
+{
+ struct wrprotect_file_state *state = (struct wrprotect_file_state *)arg;
+ struct page_vma_mapped_walk pvmw = {
+ .pfn = state->pfn,
+ .nr_pages = state->nr_pages,
+ .pgoff = state->pgoff,
+ .vma = vma,
+ .address = address,
+ .flags = PVMW_SYNC,
+ };
+
+ state->cleaned += page_vma_mkclean_one(&pvmw);
+
+ return true;
+}
+
+static void __rmap_walk_file(struct folio *folio, struct address_space *mapping,
+ pgoff_t pgoff_start, unsigned long nr_pages,
+ struct rmap_walk_control *rwc, bool locked);
+
+/**
+ * mapping_wrprotect_range() - Write-protect all mappings in a specified range.
+ *
+ * @mapping: The mapping whose reverse mapping should be traversed.
+ * @pgoff: The page offset at which @pfn is mapped within @mapping.
+ * @pfn: The PFN of the page mapped in @mapping at @pgoff.
+ * @nr_pages: The number of physically contiguous base pages spanned.
+ *
+ * Traverses the reverse mapping, finding all VMAs which contain a shared
+ * mapping of the pages in the specified range in @mapping, and write-protects
+ * them (that is, updates the page tables to mark the mappings read-only such
+ * that a write protection fault arises when the mappings are written to).
+ *
+ * The @pfn value need not refer to a folio, but rather can reference a kernel
+ * allocation which is mapped into userland. We therefore do not require that
+ * the page maps to a folio with a valid mapping or index field, rather the
+ * caller specifies these in @mapping and @pgoff.
+ *
+ * Return: the number of write-protected PTEs, or an error.
+ */
+int mapping_wrprotect_range(struct address_space *mapping, pgoff_t pgoff,
+ unsigned long pfn, unsigned long nr_pages)
+{
+ struct wrprotect_file_state state = {
+ .cleaned = 0,
+ .pgoff = pgoff,
+ .pfn = pfn,
+ .nr_pages = nr_pages,
+ };
+ struct rmap_walk_control rwc = {
+ .arg = (void *)&state,
+ .rmap_one = mapping_wrprotect_range_one,
+ .invalid_vma = invalid_mkclean_vma,
+ };
+
+ if (!mapping)
+ return 0;
+
+ __rmap_walk_file(/* folio = */NULL, mapping, pgoff, nr_pages, &rwc,
+ /* locked = */false);
+
+ return state.cleaned;
+}
+EXPORT_SYMBOL_GPL(mapping_wrprotect_range);
+
/**
* pfn_mkclean_range - Cleans the PTEs (including PMDs) mapped with range of
* [@pfn, @pfn + @nr_pages) at the specific offset (@pgoff)
--
2.48.1
^ permalink raw reply related
* [PATCH v3 3/3] fb_defio: do not use deprecated page->mapping, index fields
From: Lorenzo Stoakes @ 2025-02-08 15:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaya Kumar, Simona Vetter, Helge Deller, linux-fbdev, dri-devel,
linux-kernel, linux-mm, Matthew Wilcox, David Hildenbrand,
Kajtar Zsolt, Maira Canal, Simona Vetter, Thomas Zimmermann
In-Reply-To: <cover.1739029358.git.lorenzo.stoakes@oracle.com>
With the introduction of mapping_wrprotect_range() there is no need to use
folio_mkclean() in order to write-protect mappings of frame buffer pages,
and therefore no need to inappropriately set kernel-allocated page->index,
mapping fields to permit this operation.
Instead, store the pointer to the page cache object for the mapped driver
in the fb_deferred_io object, and use the already stored page offset from
the pageref object to look up mappings in order to write-protect them.
This is justified, as for the page objects to store a mapping pointer at
the point of assignment of pages, they must all reference the same
underlying address_space object. Since the life time of the pagerefs is
also the lifetime of the fb_deferred_io object, storing the pointer here
makes sense.
This eliminates the need for all of the logic around setting and
maintaining page->index,mapping which we remove.
This eliminates the use of folio_mkclean() entirely but otherwise should
have no functional change.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Tested-by: Kajtar Zsolt <soci@c64.rulez.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fb_defio.c | 43 ++++++++++-------------------
include/linux/fb.h | 1 +
2 files changed, 16 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index 65363df8e81b..acf7bc7ac45f 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -69,14 +69,6 @@ static struct fb_deferred_io_pageref *fb_deferred_io_pageref_lookup(struct fb_in
return pageref;
}
-static void fb_deferred_io_pageref_clear(struct fb_deferred_io_pageref *pageref)
-{
- struct page *page = pageref->page;
-
- if (page)
- page->mapping = NULL;
-}
-
static struct fb_deferred_io_pageref *fb_deferred_io_pageref_get(struct fb_info *info,
unsigned long offset,
struct page *page)
@@ -140,13 +132,10 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
if (!page)
return VM_FAULT_SIGBUS;
- if (vmf->vma->vm_file)
- page->mapping = vmf->vma->vm_file->f_mapping;
- else
- printk(KERN_ERR "no mapping available\n");
+ if (!vmf->vma->vm_file)
+ fb_err(info, "no mapping available\n");
- BUG_ON(!page->mapping);
- page->index = vmf->pgoff; /* for folio_mkclean() */
+ BUG_ON(!info->fbdefio->mapping);
vmf->page = page;
return 0;
@@ -194,9 +183,9 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
/*
* We want the page to remain locked from ->page_mkwrite until
- * the PTE is marked dirty to avoid folio_mkclean() being called
- * before the PTE is updated, which would leave the page ignored
- * by defio.
+ * the PTE is marked dirty to avoid mapping_wrprotect_range()
+ * being called before the PTE is updated, which would leave
+ * the page ignored by defio.
* Do this by locking the page here and informing the caller
* about it with VM_FAULT_LOCKED.
*/
@@ -274,14 +263,16 @@ static void fb_deferred_io_work(struct work_struct *work)
struct fb_deferred_io_pageref *pageref, *next;
struct fb_deferred_io *fbdefio = info->fbdefio;
- /* here we mkclean the pages, then do all deferred IO */
+ /* here we wrprotect the page's mappings, then do all deferred IO. */
mutex_lock(&fbdefio->lock);
list_for_each_entry(pageref, &fbdefio->pagereflist, list) {
- struct folio *folio = page_folio(pageref->page);
+ struct page *page = pageref->page;
+ pgoff_t pgoff = pageref->offset >> PAGE_SHIFT;
- folio_lock(folio);
- folio_mkclean(folio);
- folio_unlock(folio);
+#ifdef CONFIG_MMU
+ mapping_wrprotect_range(fbdefio->mapping, pgoff,
+ page_to_pfn(page), 1);
+#endif
}
/* driver's callback with pagereflist */
@@ -337,6 +328,7 @@ void fb_deferred_io_open(struct fb_info *info,
{
struct fb_deferred_io *fbdefio = info->fbdefio;
+ fbdefio->mapping = file->f_mapping;
file->f_mapping->a_ops = &fb_deferred_io_aops;
fbdefio->open_count++;
}
@@ -344,13 +336,7 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_open);
static void fb_deferred_io_lastclose(struct fb_info *info)
{
- unsigned long i;
-
flush_delayed_work(&info->deferred_work);
-
- /* clear out the mapping that we setup */
- for (i = 0; i < info->npagerefs; ++i)
- fb_deferred_io_pageref_clear(&info->pagerefs[i]);
}
void fb_deferred_io_release(struct fb_info *info)
@@ -370,5 +356,6 @@ void fb_deferred_io_cleanup(struct fb_info *info)
kvfree(info->pagerefs);
mutex_destroy(&fbdefio->lock);
+ fbdefio->mapping = NULL;
}
EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5ba187e08cf7..cd653862ab99 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -225,6 +225,7 @@ struct fb_deferred_io {
int open_count; /* number of opened files; protected by fb_info lock */
struct mutex lock; /* mutex that protects the pageref list */
struct list_head pagereflist; /* list of pagerefs for touched pages */
+ struct address_space *mapping; /* page cache object for fb device */
/* callback */
struct page *(*get_page)(struct fb_info *info, unsigned long offset);
void (*deferred_io)(struct fb_info *info, struct list_head *pagelist);
--
2.48.1
^ permalink raw reply related
* [PATCH v3 0/3] expose mapping wrprotect, fix fb_defio use
From: Lorenzo Stoakes @ 2025-02-08 15:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaya Kumar, Simona Vetter, Helge Deller, linux-fbdev, dri-devel,
linux-kernel, linux-mm, Matthew Wilcox, David Hildenbrand,
Kajtar Zsolt, Maira Canal, Simona Vetter, Thomas Zimmermann
Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel pages are mapped read-only and
write-protect faults used to batch up I/O operations.
Each time the deferred work is done, folio_mkclean() is used to mark the
framebuffer page as having had I/O performed on it. However doing so
requires the kernel page (perhaps allocated via vmalloc()) to have its
page->mapping, index fields set so the rmap can find everything that maps
it in order to write-protect.
This is problematic as firstly, these fields should not be set for
kernel-allocated memory, and secondly these are not folios (it's not user
memory) and page->index, mapping fields are now deprecated and soon to be
removed.
The removal of these fields is imminent, rendering this series more urgent
than it might first appear.
The implementers cannot be blamed for having used this however, as there is
simply no other way of performing this operation correctly.
This series fixes this - we provide the mapping_wrprotect_range() function
to allow the reverse mapping to be used to look up mappings from the page
cache object (i.e. its address_space pointer) at a specific offset.
The fb_defio logic already stores this offset, and can simply be expanded
to keep track of the page cache object, so the change then becomes
straight-forward.
This series should have no functional change.
v3:
* Fix fb_err() usage.
* Do not add missing CONFIG_MMU dependency on CONFIG_FB_DEFERRED_IO -
unfortunately this is simply not practical in this series, as this option is
selected by other options and this propagates quite significantly, and it is
not obvious that a dependency on CONFIG_MMU has been correctly tested/assured
to be valid in all instances.
Instead, simply use #ifdef CONFIG_MMU to avoid calling
mapping_wrprotect_range() for nommu, which is equivalent behaviour to before
this change.
Ideally somebody will work through the fb/drm code and ensure anything that
requires deferred I/O explicitly depends on CONFIG_MMU, or is ok with the
deferred work being a no-op.
v2:
* Make CONFIG_FB_DEFERRED_IO depend on CONFIG_MMU (as it strictly relies upon
it) to fix randconfig builds.
* Replace mapping_wrprotect_page() with mapping_wrprotect_range() accepting a
PFN, as per Simona. While it is not suited for use with DMA addresses (as
pointed out by hch), it is still worth doing so to make the function more
flexible.
* Also update the mapping_wrprotect_range() signature to be more logical -
with the pfn argument appearing before nr_pages.
* Use fb_err() for error output as per Thomas.
https://lore.kernel.org/all/cover.1738855154.git.lorenzo.stoakes@oracle.com/
non-RFC:
* Kajtar kindly smoke-tested the defio side of this change and confirmed
that it appears to work correctly. I am therefore stripping the RFC and
putting forward as a non-RFC series.
https://lore.kernel.org/all/cover.1738347308.git.lorenzo.stoakes@oracle.com/
RFC v2:
* Updated Jaya Kumar's email on cc - the MAINTAINERS section is apparently
incorrect.
* Corrected rmap_walk_file() comment to refer to folios as per Matthew.
* Reference folio->mapping rather than folio_mapping(folio) in
rmap_walk_file() as per Matthew.
* Reference folio->index rather than folio_pgoff(folio) in rmap_walk_file()
as per Matthew.
* Renamed rmap_wrprotect_file_page() to mapping_wrprotect_page() as per
Matthew.
* Fixed kerneldoc and moved to implementation as per Matthew.
* Updated mapping_wrprotect_page() to take a struct page pointer as per
David.
* Removed folio lock when invoking mapping_wrprotect_page() in
fb_deferred_io_work() as per Matthew.
* Removed compound_nr() in fb_deferred_io_work() as per Matthew.
RFC v1:
https://lore.kernel.org/all/1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoakes@oracle.com/
Lorenzo Stoakes (3):
mm: refactor rmap_walk_file() to separate out traversal logic
mm: provide mapping_wrprotect_range() function
fb_defio: do not use deprecated page->mapping, index fields
drivers/video/fbdev/core/fb_defio.c | 43 +++-----
include/linux/fb.h | 1 +
include/linux/rmap.h | 3 +
mm/rmap.c | 153 +++++++++++++++++++++++-----
4 files changed, 146 insertions(+), 54 deletions(-)
--
2.48.1
^ permalink raw reply
* [PATCH] fbdev: fsl-diu-fb: add missing device_remove_file()
From: oushixiong1025 @ 2025-02-08 10:23 UTC (permalink / raw)
To: Timur Tabi
Cc: Helge Deller, linux-fbdev, dri-devel, linux-kernel, Shixiong Ou
From: Shixiong Ou <oushixiong@kylinos.cn>
Call device_remove_file() when driver remove.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
---
drivers/video/fbdev/fsl-diu-fb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 5ac8201c3533..8c91af9a9156 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -1807,6 +1807,7 @@ static int fsl_diu_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "could not create sysfs file %s\n",
data->dev_attr.attr.name);
+ goto error;
}
dev_set_drvdata(&pdev->dev, data);
@@ -1827,6 +1828,9 @@ static void fsl_diu_remove(struct platform_device *pdev)
int i;
data = dev_get_drvdata(&pdev->dev);
+
+ device_remove_file(&pdev->dev, &data->dev_attr);
+
disable_lcdc(&data->fsl_diu_info[0]);
free_irq(data->irq, data->diu_reg);
--
2.17.1
^ permalink raw reply related
* [PATCH v2] fbdev: lcdcfb: add missing device_remove_file()
From: oushixiong1025 @ 2025-02-08 9:29 UTC (permalink / raw)
To: Helge Deller
Cc: Thomas Zimmermann, Laurent Pinchart, Lee Jones,
Uwe Kleine-König, Arnd Bergmann, linux-fbdev, dri-devel,
linux-kernel, Shixiong Ou
From: Shixiong Ou <oushixiong@kylinos.cn>
1. The device_remove_file() need to be called when driver is removing.
2. The device_remove_file() need to be called if the call to
device_create_file() fails.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
---
v1->v2:
add missing 'return error'.
call device_remove_file() in sh_mobile_lcdc_overlay_fb_unregister().
drivers/video/fbdev/sh_mobile_lcdcfb.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 4715dcb59811..c52661d5491a 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1504,10 +1504,14 @@ static void
sh_mobile_lcdc_overlay_fb_unregister(struct sh_mobile_lcdc_overlay *ovl)
{
struct fb_info *info = ovl->info;
+ unsigned int i;
if (info == NULL || info->dev == NULL)
return;
+ for (i = 0; i < ARRAY_SIZE(overlay_sysfs_attrs); ++i)
+ device_remove_file(info->dev, &overlay_sysfs_attrs[i]);
+
unregister_framebuffer(ovl->info);
}
@@ -1516,7 +1520,7 @@ sh_mobile_lcdc_overlay_fb_register(struct sh_mobile_lcdc_overlay *ovl)
{
struct sh_mobile_lcdc_priv *lcdc = ovl->channel->lcdc;
struct fb_info *info = ovl->info;
- unsigned int i;
+ unsigned int i, error = 0;
int ret;
if (info == NULL)
@@ -1531,9 +1535,15 @@ sh_mobile_lcdc_overlay_fb_register(struct sh_mobile_lcdc_overlay *ovl)
info->var.yres, info->var.bits_per_pixel);
for (i = 0; i < ARRAY_SIZE(overlay_sysfs_attrs); ++i) {
- ret = device_create_file(info->dev, &overlay_sysfs_attrs[i]);
- if (ret < 0)
- return ret;
+ error = device_create_file(info->dev, &overlay_sysfs_attrs[i]);
+ if (error)
+ break;
+ }
+
+ if (error) {
+ while (--i >= 0)
+ device_remove_file(info->dev, &overlay_sysfs_attrs[i]);
+ return error;
}
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH] fbdev: lcdcfb: add missing device_remove_file()
From: oushixiong1025 @ 2025-02-08 9:04 UTC (permalink / raw)
To: Helge Deller
Cc: Thomas Zimmermann, Laurent Pinchart, Lee Jones,
Uwe Kleine-König, Arnd Bergmann, linux-fbdev, dri-devel,
linux-kernel, Shixiong Ou
From: Shixiong Ou <oushixiong@kylinos.cn>
1. The device_remove_file() need to be called when driver is removing.
2. The device_remove_file() need to be called if the call to
device_create_file() fails.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 4715dcb59811..b56ab1df7369 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1516,7 +1516,7 @@ sh_mobile_lcdc_overlay_fb_register(struct sh_mobile_lcdc_overlay *ovl)
{
struct sh_mobile_lcdc_priv *lcdc = ovl->channel->lcdc;
struct fb_info *info = ovl->info;
- unsigned int i;
+ unsigned int i, error = 0;
int ret;
if (info == NULL)
@@ -1531,9 +1531,14 @@ sh_mobile_lcdc_overlay_fb_register(struct sh_mobile_lcdc_overlay *ovl)
info->var.yres, info->var.bits_per_pixel);
for (i = 0; i < ARRAY_SIZE(overlay_sysfs_attrs); ++i) {
- ret = device_create_file(info->dev, &overlay_sysfs_attrs[i]);
- if (ret < 0)
- return ret;
+ error = device_create_file(info->dev, &overlay_sysfs_attrs[i]);
+ if (error)
+ break;
+ }
+
+ if (error) {
+ while (--i >= 0)
+ device_remove_file(info->dev, &overlay_sysfs_attrs[i]);
}
return 0;
@@ -1543,10 +1548,14 @@ static void
sh_mobile_lcdc_overlay_fb_cleanup(struct sh_mobile_lcdc_overlay *ovl)
{
struct fb_info *info = ovl->info;
+ unsigned int i;
if (info == NULL || info->device == NULL)
return;
+ for (i = 0; i < ARRAY_SIZE(overlay_sysfs_attrs); ++i)
+ device_remove_file(info->dev, &overlay_sysfs_attrs[i]);
+
framebuffer_release(info);
}
--
2.25.1
^ permalink raw reply related
* Re: The business loan-
From: David Song @ 2025-02-08 4:43 UTC (permalink / raw)
To: linux-fbdev
Hello,
My name is David Song, at AA4 FS, we are a consultancy and
brokerage Firm specializing in Growth Financial Loan and joint
partnership venture. We specialize in investments in all Private
and public sectors in a broad range of areas within our Financial
Investment Services.
We are experts in financial and operational management, due
diligence and capital planning in all markets and industries. Our
Investors wish to invest in any viable Project presented by your
Management after reviews on your Business Project Presentation
Plan.
We look forward to your Swift response. We also offer commission
to consultants and brokers for any partnership referrals.
Regards,
David Song
Senior Broker
AA4 Financial Services
13 Wonersh Way, Cheam,
Sutton, Surrey, SM2 7LX
Email: dsong@aa4financialservice.com
^ permalink raw reply
* Re: [PATCH RESEND 00/13] fbdev: core: Deduplicate cfb/sys drawing fbops
From: Kajtár Zsolt @ 2025-02-08 0:51 UTC (permalink / raw)
To: Thomas Zimmermann, linux-fbdev, dri-devel
In-Reply-To: <c4db73a2-12a7-41f4-a175-332c44f51bc4@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1879 bytes --]
Hello Thomas!
> No it's not. Major code abstractions behind preprocessor tokens are
> terrible to maintain.
Hmm, don't get me wrong but I'm not sure if the changes were really
checked in detail. At first sight it might look like I'm adding tons of
new macro ridden code in those header files replacing cleaner code.
While actually that's just how the I/O version currently is, copied and
white space cleaned (as it was requested) plus comment style matched
with sys.
The only new thing which hides the mentioned abstraction a little more
is FB_MEM, which replaced __iomem. But that's a tradeoff to be able to
use the same source for system as well.
Or the concern is that now system memory specific code might get mixed
in there by mistake?
It was not planned as the final version, the current maintainer asked
for addressing some pre-existing quality issues with further patches but
otherwise accepted the taken approach.
> It's also technically not possible to switch between system and I/O
> memory at will. These are very different things.
Yes, there are architectures where these two don't mix at all, I'm aware
of that. I need that on x86 only (for old hw), and there it seems
doable. Depending on the resolution either the aperture or the defio
memory is mapped. If the framebuffer is not remapped after a mode change
that's an application bug. Otherwise it's harmless as both are always
there and don't change.
I'd better like to find out problems sooner than later, so if you or
anyone else could share any concerns that'd be really helpful!
> If you want that pixel-reversing feature in sys_ helpers, please
> implement it there.
Actually that's what I did first. Then did it once more by adapting the
I/O version as that gave me more confidence that it'll work exactly the
same and there's less room for error.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply
* RE: hyper_bf soft lockup on Azure Gen2 VM when taking kdump or executing kexec
From: Michael Kelley @ 2025-02-07 18:35 UTC (permalink / raw)
To: Saurabh Singh Sengar, Thomas Tai, mhkelley58@gmail.com,
Haiyang Zhang, wei.liu@kernel.org, Dexuan Cui,
drawat.floss@gmail.com, javierm@redhat.com, Helge Deller,
daniel@ffwll.ch, airlied@gmail.com, tzimmermann@suse.de
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
In-Reply-To: <TYZP153MB079619B42859CAD4CAEB8771BEF12@TYZP153MB0796.APCP153.PROD.OUTLOOK.COM>
From: Saurabh Singh Sengar <ssengar@microsoft.com> Sent: Friday, February 7, 2025 6:06 AM
>
> Thanks Michael, for the analysis.
>
> I have tried the kdump steps on Oracle 9.4, 6.13.0 kernel as well. Although I couldn't see
> the soft lockup issue I see some other VMBus failures. But I agree the bootup is
> extremely slow, which should be due to same reason.
Yes, I would also think it is the same underlying reason.
>
> My system is having newer UEFI version, wondering if the latest UEFI version
> (UEFI Release v4.1 08/23/2024) causing this difference in behaviour.
I've seen both the original behavior that Thomas Tai reported, as well as
the extremely slow behavior. In my experiments, it seems to depend on
the Azure V size being used, though I didn't fully investigate. Originally I
was using a DS5_v2 VM (which is what Thomas was using) and saw the
same "soft lockup" as Thomas. Then I moved to a D8ds_v5 VM, which
is somewhat cheaper, and was seeing the very slow behavior.
See my separate email from this morning with a full explanation of the
root cause.
Michael
>
> Relevant part of the logs:
> ---------------------------------------------------------
> echo 1 > /proc/sys/kernel/sysrq
> echo c > /proc/sysrq-trigger
> [ 982.948352] sysrq: Trigger a crash
> [ 982.949553] Kernel panic - not syncing: sysrq triggered crash
> [ 982.951515] CPU: 31 UID: 0 PID: 6938 Comm: bash Kdump: loaded Not tainted
> 6.13.0 #1
> [ 982.954115] Hardware name: Microsoft Corporation Virtual Machine/Virtual
> Machine, BIOS Hyper-V UEFI Release v4.1 08/23/2024
> [ 982.957641] Call Trace:
> [ 982.958508] <TASK>
> [ 982.959251] panic+0x37e/0x3b0
> [ 982.960373] ? _printk+0x64/0x90
> [ 982.961452] sysrq_handle_crash+0x1a/0x20
> [ 982.962840] __handle_sysrq+0x9b/0x190
> [ 982.964145] write_sysrq_trigger+0x5f/0x80
> [ 982.965578] proc_reg_write+0x59/0xb0
> [ 982.966905] vfs_write+0x111/0x470
> [ 982.968004] ? __count_memcg_events+0xbf/0x150
> [ 982.969432] ? count_memcg_events.constprop.0+0x26/0x50
> [ 982.971190] ksys_write+0x6e/0xf0
> [ 982.972307] do_syscall_64+0x62/0x180
> [ 982.973438] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 982.975102] RIP: 0033:0x7f3d570fdbd7
> [ 982.976421] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa
> 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3
> 48 83 ec 28 48 89 54 24 18 48 89 74 24
> [ 982.982893] RSP: 002b:00007fff6d613c48 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000001
> [ 982.985424] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f3d570fdbd7
> [ 982.987613] RDX: 0000000000000002 RSI: 000056362a928470 RDI:
> 0000000000000001
> [ 982.989774] RBP: 000056362a928470 R08: 0000000000000000 R09:
> 00007f3d571b0d40
> [ 982.992109] R10: 00007f3d571b0c40 R11: 0000000000000246 R12:
> 0000000000000002
> [ 982.994321] R13: 00007f3d571fa780 R14: 0000000000000002 R15:
> 00007f3d571f59e0
> [ 982.996461] </TASK>
> [ 982.998317] Kernel Offset: 0x10c00000 from 0xffffffff81000000 (relocation range:
> 0xffffffff80000000-0xffffffffbfffffff)
> [ 0.000000] Linux version 6.13.0 (lisatest@lisa--505-e0-n0) (gcc (GCC) 11.5.0
> 20240719 (Red Hat 11.5.0-2.0.1), GNU ld version 2.35.2-54.0.1.el9) #1 SMP
> PREEMPT_DYNAMIC Thu Feb 6 10:05:27 UTC 2025
> [ 0.000000] Command line: elfcorehdr=0xd000000
> BOOT_IMAGE=(hd0,gpt1)/vmlinuz-6.13.0 ro console=tty0 console=ttyS0,115200n8
> rd.lvm.vg=rootvg irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off
> numa=off udev.children-max=2 panic=10 acpi_no_memhotplug
> transparent_hugepage=never nokaslr hest_disable novmcoredd cma=0 hugetlb_cma=0
> iommu=off disable_cpu_apicid=0
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff]
> reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable
> [ 0.000000] BIOS-e820: [mem 0x00000000000c0000-0x00000000000fffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000000d0e00b0-0x000000002cffffff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000003eead000-0x000000003eeb3fff]
> reserved
> [ 0.000000] BIOS-e820: [mem 0x000000003ff41000-0x000000003ffc8fff] reserved
> [ 0.000000] BIOS-e820: [mem 0x000000003ffc9000-0x000000003fffafff] ACPI data
> [ 0.000000] BIOS-e820: [mem 0x000000003fffb000-0x000000003fffefff] ACPI NVS
> [ 0.000000] random: crng init done
>
> <snip>
>
> [ 0.928063] Console: switching to colour frame buffer device 128x48
> [ 13.391297] fb0: EFI VGA frame buffer device
>
> <snip>
>
> [ 590.199511] hv_netvsc 7c1e527c-2980-7c1e-527c-29807c1e527c (unnamed
> net_device) (uninitialized): VF slot 1 added
> [ 595.120270] Console: switching to colour dummy device 80x25
> [ 605.203700] hyperv_fb: Time out on waiting vram location ack
> [ 605.206161] iounmap: bad address 0000000005f4dac5
> [ 605.207740] CPU: 0 UID: 0 PID: 30 Comm: kworker/u4:2 Not tainted 6.13.0 #1
> [ 605.209984] Hardware name: Microsoft Corporation Virtual Machine/Virtual
> Machine, BIOS Hyper-V UEFI Release v4.1 08/23/2024
> [ 605.213869] Workqueue: async async_run_entry_fn
> [ 605.215601] Call Trace:
> [ 605.216382] <TASK>
> [ 605.217123] dump_stack_lvl+0x66/0x90
> [ 605.218184] hvfb_putmem+0x32/0x110 [hyperv_fb]
> [ 605.219646] hvfb_probe+0x27f/0x360 [hyperv_fb]
> [ 605.221120] vmbus_probe+0x3d/0xa0 [hv_vmbus]
> [ 605.222623] really_probe+0xd9/0x390
> [ 605.223779] __driver_probe_device+0x78/0x160
> [ 605.225213] driver_probe_device+0x1e/0xa0
> [ 605.226591] __driver_attach_async_helper+0x5e/0xe0
> [ 605.228166] async_run_entry_fn+0x34/0x130
> [ 605.229681] process_one_work+0x187/0x3b0
> [ 605.231075] worker_thread+0x24e/0x360
> [ 605.232376] ? __pfx_worker_thread+0x10/0x10
> [ 605.233758] kthread+0xd3/0x100
> [ 605.234805] ? __pfx_kthread+0x10/0x10
> [ 605.236053] ret_from_fork+0x34/0x50
> [ 605.237251] ? __pfx_kthread+0x10/0x10
> [ 605.238519] ret_from_fork_asm+0x1a/0x30
> [ 605.239833] </TASK>
> [ 605.240855] hv_vmbus: probe failed for device 5620e0c7-8062-4dce-aeb7-
> 520c7ef76171 (-110)
> [ 605.243404] hyperv_fb 5620e0c7-8062-4dce-aeb7-520c7ef76171: probe with
> driver hyperv_fb failed with error -110
> [ 605.254672] hv_vmbus: registering driver hv_pci
>
>
>
>
> - Saurabh
>
> > -----Original Message-----
> > From: Michael Kelley <mhklinux@outlook.com>
> > Sent: 07 February 2025 02:30
> > To: Michael Kelley <mhklinux@outlook.com>; Thomas Tai
> > <thomas.tai@oracle.com>; mhkelley58@gmail.com; Haiyang Zhang
> > <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui
> > <decui@microsoft.com>; drawat.floss@gmail.com; javierm@redhat.com;
> > Helge Deller <deller@gmx.de>; daniel@ffwll.ch; airlied@gmail.com;
> > tzimmermann@suse.de
> > Cc: dri-devel@lists.freedesktop.org; linux-fbdev@vger.kernel.org; linux-
> > kernel@vger.kernel.org; linux-hyperv@vger.kernel.org
> > Subject: [EXTERNAL] RE: hyper_bf soft lockup on Azure Gen2 VM when taking
> > kdump or executing kexec
> >
> > From: Michael Kelley <mhklinux@outlook.com>
> > >
> > > From: Thomas Tai <thomas.tai@oracle.com> Sent: Thursday, January 30,
> > > 2025 12:44 PM
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Kelley <mhklinux@outlook.com> Sent: Thursday,
> > > > > January 30, 2025 3:20 PM
> > > > >
> > > > > From: Thomas Tai <thomas.tai@oracle.com> Sent: Thursday, January
> > > > > 30,
> > > > > 2025 10:50 AM
> > > > > >
> > > > > > Sorry for the typo in the subject title. It should have been
> > > > > > 'hyperv_fb soft lockup on Azure Gen2 VM when taking kdump or
> > executing kexec'
> > > > > >
> > > > > > Thomas
> > > > > >
> > > > > > >
> > > > > > > Hi Michael,
> > > > > > >
> > > > > > > We see an issue with the mainline kernel on the Azure Gen 2 VM
> > > > > > > when trying to induce a kernel panic with sysrq commands. The
> > > > > > > VM would hang with soft lockup. A similar issue happens when
> > executing kexec on the VM.
> > > > > > > This issue is seen only with Gen2 VMs(with UEFI boot). Gen1
> > > > > > > VMs with bios boot are fine.
> > > > > > >
> > > > > > > git bisect identifies the issue is cased by the commit
> > > > > > > 20ee2ae8c5899
> > > > > > > ("fbdev/hyperv_fb: Fix logic error for Gen2 VMs in hvfb_getmem()" ).
> > > > > > > However, reverting the commit would cause the frame buffer not
> > > > > > > to work on the Gen2 VM.
> > > > > > >
> > > > > > > Do you have any hints on what caused this issue?
> > > > > > >
> > > > > > > To reproduce the issue with kdump:
> > > > > > > - Install mainline kernel on an Azure Gen 2 VM and trigger a
> > > > > > > kdump
> > > > > > > - echo 1 > /proc/sys/kernel/sysrq
> > > > > > > - echo c > /proc/sysrq-trigger
> > > > > > >
> > > > > > > To reproduce the issue with executing kexec:
> > > > > > > - Install mainline kernel on Azure Gen 2 VM and use kexec
> > > > > > > - sudo kexec -l /boot/vmlinuz --initrd=/boot/initramfs.img
> > > > > > > --command- line="$( cat /proc/cmdline )"
> > > > > > > - sudo kexec -e
> > > > > > >
> > > > > > > Thank you,
> > > > > > > Thomas
> > > > >
> > > > > I will take a look, but it might be early next week before I can do so.
> > > > >
> > > >
> > > > Thank you, Michael for your help!
> > > >
> > > > > It looks like your soft lockup log below is from the kdump kernel
> > > > > (or the newly kexec'ed kernel). Can you confirm? Also, this looks like a
> > subset of the full log.
> > > >
> > > > Yes, the soft lockup log below is from the kdump kernel.
> > > >
> > > > > Do you have the full serial console log that you could email to
> > > > > me? Seeing everything might be helpful. Of course, I'll try to
> > > > > repro the problem myself as well.
> > > >
> > > > I have attached the complete bootup and kdump kernel log.
> > > >
> > > > File: bootup_and_kdump.log
> > > > Line 1 ... 984 (bootup log)
> > > > Line 990 (kdump kernel booting up)
> > > > Line 1351 (soft lockup)
> > > >
> > > > Thank you,
> > > > Thomas
> > > >
> > >
> > > I have reproduced the problem in an Azure VM running Oracle Linux
> > > 9.4 with the 6.13.0 kernel. Interestingly, the problem does not occur
> > > in a VM running on a locally installed Hyper-V with Ubuntu 20.04 and
> > > the 6.13.0 kernel. There are several differences in the two
> > > environments: the version of Hyper-V, the VM configuration, the Linux
> > > distro, and the .config file used to build the 6.13.0 kernel. I'll try
> > > to figure out what make the difference, and then the root cause.
> > >
> >
> > This has been a real bear to investigate. :-( The key observation is that with
> > older kernel versions, the efifb driver does *not* try to load when running in
> > the kdump kernel, and everything works.
> > In newer kernels, the efifb driver *does* try to load, and it appears to hang.
> > (Actually, it is causing the VM to run very slowly. More on that in a minute.)
> >
> > I've bisected the kernel again, compensating for the fact that commit
> > 20ee2ae8c5899 is needed to make the Hyper-V frame buffer work. With that
> > compensation, the actual problematic commit is 2bebc3cd4870 (Revert
> > "firmware/sysfb: Clear screen_info state after consuming it").
> > Doing the revert causes screen_info.orig_video_isVGA to retain its value of
> > 0x70 (VIDEO_TYPE_EFI), which the kdump kernel picks up, causing it to load
> > the efifb driver.
> >
> > Then the question is why the efifb driver doesn't work in the kdump kernel.
> > Actually, it *does* work in many cases. I built the 6.13.0 kernel on the Oracle
> > Linux 9.4 system, and transferred the kernel image binary and module
> > binaries to an Ubuntu 20.04 VM in Azure. In that VM, the efifb driver is
> > loaded as part of the kdump kernel, and it doesn't cause any problems. But
> > there's an interesting difference. In the Oracle Linux
> > 9.4 VM, the efifb driver finds the framebuffer at 0x40000000, while on the
> > Ubuntu 20.04 VM, it finds the framebuffer at 0x40900000. This difference is
> > due to differences in how the screen_info variable gets setup in the two VMs.
> >
> > When the normal kernel starts in a freshly booted VM, Hyper-V provides the
> > EFI framebuffer at 0x40000000, and it works. But after the Hyper-V FB driver
> > or Hyper-V DRM driver has initialized, Linux has picked a different MMIO
> > address range and told Hyper-V to use the new address range (which often
> > starts at 0x40900000). A kexec does *not* reset Hyper-V's transition to the
> > new range, so when the efifb driver tries to use the framebuffer at
> > 0x40000000, the accesses trap to Hyper-V and probably fail or timeout (I'm
> > not sure of the details). After the guest does some number of these bad
> > references, Hyper-V considers itself to be under attack from an ill-behaving
> > guest, and throttles the guest so that it doesn't run for a few seconds. The
> > throttling repeats, and results in extremely slow running in the kdump kernel.
> >
> > Somehow in the Ubuntu 20.04 VM, the location of the frame buffer as stored
> > in screen_info.lfb_base gets updated to be 0x40900000. I haven't fully
> > debugged how that happens. But with that update, the efifb driver is using
> > the updated framebuffer address and it works. On the Oracle Linux 9.4
> > system, that update doesn't appear to happen, and the problem occurs.
> >
> > This in an interim update on the problem. I'm still investigating how
> > screen_info.lfb_base is set in the kdump kernel, and why it is different in the
> > Ubuntu 20.04 VM vs. in the Oracle Linux 9.4 VM. Once that is well
> > understood, we can contemplate how to fix the problem. Undoing the revert
> > that is commit 2bebc3cd4870 doesn't seem like the solution since the original
> > code there was reported to cause many other issues.
> > The solution focus will likely be on how to ensure the kdump kernel gets the
> > correct framebuffer address so the efifb driver works, since the framebuffer
> > address changing is a quirk of Hyper-V behavior.
> >
> > If anyone else has insight into what's going on here, please chime in.
> > What I've learned so far is still somewhat tentative.
> >
> > Michael
^ permalink raw reply
* RE: hyper_bf soft lockup on Azure Gen2 VM when taking kdump or executing kexec
From: Michael Kelley @ 2025-02-07 18:28 UTC (permalink / raw)
To: Michael Kelley, Thomas Tai, mhkelley58@gmail.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
drawat.floss@gmail.com, javierm@redhat.com, Helge Deller,
daniel@ffwll.ch, airlied@gmail.com, tzimmermann@suse.de
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB41578AC54B7C0B7386B8ED00D4F62@SN6PR02MB4157.namprd02.prod.outlook.com>
From: Michael Kelley <mhklinux@outlook.com> Sent: Thursday, February 6, 2025 1:00 PM
>
> From: Michael Kelley <mhklinux@outlook.com>
> >
> > From: Thomas Tai <thomas.tai@oracle.com> Sent: Thursday, January 30, 2025 12:44 PM
> > >
> > > > -----Original Message-----
> > > > From: Michael Kelley <mhklinux@outlook.com> Sent: Thursday, January 30, 2025 3:20 PM
> > > >
> > > > From: Thomas Tai <thomas.tai@oracle.com> Sent: Thursday, January 30,
> > > > 2025 10:50 AM
> > > > >
> > > > > Sorry for the typo in the subject title. It should have been 'hyperv_fb soft lockup on
> > > > > Azure Gen2 VM when taking kdump or executing kexec'
> > > > >
> > > > > Thomas
> > > > >
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > We see an issue with the mainline kernel on the Azure Gen 2 VM when
> > > > > > trying to induce a kernel panic with sysrq commands. The VM would hang
> > > > > > with soft lockup. A similar issue happens when executing kexec on the VM.
> > > > > > This issue is seen only with Gen2 VMs(with UEFI boot). Gen1 VMs with bios
> > > > > > boot are fine.
> > > > > >
> > > > > > git bisect identifies the issue is cased by the commit 20ee2ae8c5899
> > > > > > ("fbdev/hyperv_fb: Fix logic error for Gen2 VMs in hvfb_getmem()" ).
> > > > > > However, reverting the commit would cause the frame buffer not to work
> > > > > > on the Gen2 VM.
> > > > > >
> > > > > > Do you have any hints on what caused this issue?
> > > > > >
> > > > > > To reproduce the issue with kdump:
> > > > > > - Install mainline kernel on an Azure Gen 2 VM and trigger a kdump
> > > > > > - echo 1 > /proc/sys/kernel/sysrq
> > > > > > - echo c > /proc/sysrq-trigger
> > > > > >
> > > > > > To reproduce the issue with executing kexec:
> > > > > > - Install mainline kernel on Azure Gen 2 VM and use kexec
> > > > > > - sudo kexec -l /boot/vmlinuz --initrd=/boot/initramfs.img --command-
> > > > > > line="$( cat /proc/cmdline )"
> > > > > > - sudo kexec -e
> > > > > >
> > > > > > Thank you,
> > > > > > Thomas
> > > >
> > > > I will take a look, but it might be early next week before I can do so.
> > > >
> > >
> > > Thank you, Michael for your help!
> > >
> > > > It looks like your soft lockup log below is from the kdump kernel (or the newly
> > > > kexec'ed kernel). Can you confirm? Also, this looks like a subset of the full log.
> > >
> > > Yes, the soft lockup log below is from the kdump kernel.
> > >
> > > > Do you have the full serial console log that you could email to me? Seeing
> > > > everything might be helpful. Of course, I'll try to repro the problem myself
> > > > as well.
> > >
> > > I have attached the complete bootup and kdump kernel log.
> > >
> > > File: bootup_and_kdump.log
> > > Line 1 ... 984 (bootup log)
> > > Line 990 (kdump kernel booting up)
> > > Line 1351 (soft lockup)
> > >
> > > Thank you,
> > > Thomas
> > >
> >
> > I have reproduced the problem in an Azure VM running Oracle Linux
> > 9.4 with the 6.13.0 kernel. Interestingly, the problem does not occur
> > in a VM running on a locally installed Hyper-V with Ubuntu 20.04 and
> > the 6.13.0 kernel. There are several differences in the two
> > environments: the version of Hyper-V, the VM configuration, the Linux
> > distro, and the .config file used to build the 6.13.0 kernel. I'll try to
> > figure out what make the difference, and then the root cause.
> >
>
> This has been a real bear to investigate. :-( The key observation
> is that with older kernel versions, the efifb driver does *not* try
> to load when running in the kdump kernel, and everything works.
> In newer kernels, the efifb driver *does* try to load, and it appears
> to hang. (Actually, it is causing the VM to run very slowly. More on
> that in a minute.)
>
> I've bisected the kernel again, compensating for the fact that commit
> 20ee2ae8c5899 is needed to make the Hyper-V frame buffer work. With
> that compensation, the actual problematic commit is 2bebc3cd4870
> (Revert "firmware/sysfb: Clear screen_info state after consuming it").
> Doing the revert causes screen_info.orig_video_isVGA to retain its value
> of 0x70 (VIDEO_TYPE_EFI), which the kdump kernel picks up, causing it
> to load the efifb driver.
>
> Then the question is why the efifb driver doesn't work in the kdump
> kernel. Actually, it *does* work in many cases. I built the 6.13.0 kernel
> on the Oracle Linux 9.4 system, and transferred the kernel image binary
> and module binaries to an Ubuntu 20.04 VM in Azure. In that VM, the
> efifb driver is loaded as part of the kdump kernel, and it doesn't cause
> any problems. But there's an interesting difference. In the Oracle Linux
> 9.4 VM, the efifb driver finds the framebuffer at 0x40000000, while on
> the Ubuntu 20.04 VM, it finds the framebuffer at 0x40900000. This
> difference is due to differences in how the screen_info variable gets
> setup in the two VMs.
>
> When the normal kernel starts in a freshly booted VM, Hyper-V provides
> the EFI framebuffer at 0x40000000, and it works. But after the Hyper-V
> FB driver or Hyper-V DRM driver has initialized, Linux has picked a
> different MMIO address range and told Hyper-V to use the new
> address range (which often starts at 0x40900000). A kexec does *not*
> reset Hyper-V's transition to the new range, so when the efifb driver
> tries to use the framebuffer at 0x40000000, the accesses trap to
> Hyper-V and probably fail or timeout (I'm not sure of the details). After
> the guest does some number of these bad references, Hyper-V considers
> itself to be under attack from an ill-behaving guest, and throttles the
> guest so that it doesn't run for a few seconds. The throttling repeats,
> and results in extremely slow running in the kdump kernel.
>
> Somehow in the Ubuntu 20.04 VM, the location of the frame buffer
> as stored in screen_info.lfb_base gets updated to be 0x40900000. I
> haven't fully debugged how that happens. But with that update, the
> efifb driver is using the updated framebuffer address and it works. On
> the Oracle Linux 9.4 system, that update doesn't appear to happen,
> and the problem occurs.
>
> This in an interim update on the problem. I'm still investigating how
> screen_info.lfb_base is set in the kdump kernel, and why it is different
> in the Ubuntu 20.04 VM vs. in the Oracle Linux 9.4 VM. Once that is
> well understood, we can contemplate how to fix the problem. Undoing
> the revert that is commit 2bebc3cd4870 doesn't seem like the solution
> since the original code there was reported to cause many other issues.
> The solution focus will likely be on how to ensure the kdump kernel gets
> the correct framebuffer address so the efifb driver works, since the
> framebuffer address changing is a quirk of Hyper-V behavior.
>
> If anyone else has insight into what's going on here, please chime in.
> What I've learned so far is still somewhat tentative.
>
Here's what is happening. On Ubuntu 20.04, the kdump image is
loaded into crash memory using the kexec command. Ubuntu 20.04
has kexec from the kexec-tools package version 2.0.18-1ubuntu1.1,
and per the kexec man page, it defaults to using the older kexec_load()
system call. When using kexec_load(), the contents to be loaded into
crash memory is constructed in user space by the kexec command.
The kexec command gets the "screen_info" settings, including the
physical address of the frame buffer, via the FBIOGET_FSCREENINFO
ioctl against /dev/fb0. The Hyper-V FB or DRM driver registers itself
with the fbdev subsystem so that it is /dev/fb0, and the ioctl returns
the updated framebuffer address. So the efifb driver loads and runs
correctly.
On Oracle Linux 9.4, the kdump image is also loaded with the
kexec command, but from kexec-tools package version
kexec-tools-2.0.28-1.0.10.el9_5.x86_64, which is slightly later than
the version on Ubuntu 20.04. This newer kexec defaults to using the
newer kexec_file_load() system call. This system call gets the
framebuffer address from the screen_info variable in the kernel, which
has not been updated to reflect the new framebuffer address. Hence
in the kdump kernel, the efifb driver uses the old framebuffer address,
and hence the problem.
To further complicate matters, the kexec on Oracle Linux 9.4 seems to
have a bug when the -c option forces the use of kexec_load() instead
of kexec_file_load(). As an experiment, I modified the kdumpctl shell
script to add the "-c" option to kexec, but in that case the value "0x0"
is passed as the framebuffer address, which is wrong. Furthermore,
the " screen_info.orig_video_isVGA" value (which I mentioned earlier
in connection with commit 2bebc3cd4870) is also set to 0, so the
kdump kernel no longer thinks it has an EFI framebuffer. Hence the
efifb driver isn't loaded, and the kdump works, though for the wrong
reasons. If kexec 2.0.18 from Ubuntu is copied onto the Oracle Linux 9.4
VM, then kdump works as expected, with the efifb driver being loaded
and using the correct framebuffer address. So something is going wrong
with kexec 2.0.28 in how it sets up the screen_info when the -c option
is used. I'll leave the debugging of the kexec bug to someone else.
I'm still thinking about alternatives to fix this mess. Please chime
in if you have suggestions.
Michael
^ permalink raw reply
* RE: hyper_bf soft lockup on Azure Gen2 VM when taking kdump or executing kexec
From: Saurabh Singh Sengar @ 2025-02-07 14:06 UTC (permalink / raw)
To: Michael Kelley, Thomas Tai, mhkelley58@gmail.com, Haiyang Zhang,
wei.liu@kernel.org, Dexuan Cui, drawat.floss@gmail.com,
javierm@redhat.com, Helge Deller, daniel@ffwll.ch,
airlied@gmail.com, tzimmermann@suse.de
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB41578AC54B7C0B7386B8ED00D4F62@SN6PR02MB4157.namprd02.prod.outlook.com>
Thanks Michael, for the analysis.
I have tried the kdump steps on Oracle 9.4, 6.13.0 kernel as well. Although I couldn't see
the soft lockup issue I see some other VMBus failures. But I agree the bootup is extremely
slow, which should be due to same reason.
My system is having newer UEFI version, wondering if the latest UEFI version
(UEFI Release v4.1 08/23/2024) causing this difference in behaviour.
Relevant part of the logs:
---------------------------------------------------------
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
[ 982.948352] sysrq: Trigger a crash
[ 982.949553] Kernel panic - not syncing: sysrq triggered crash
[ 982.951515] CPU: 31 UID: 0 PID: 6938 Comm: bash Kdump: loaded Not tainted 6.13.0 #1
[ 982.954115] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 08/23/2024
[ 982.957641] Call Trace:
[ 982.958508] <TASK>
[ 982.959251] panic+0x37e/0x3b0
[ 982.960373] ? _printk+0x64/0x90
[ 982.961452] sysrq_handle_crash+0x1a/0x20
[ 982.962840] __handle_sysrq+0x9b/0x190
[ 982.964145] write_sysrq_trigger+0x5f/0x80
[ 982.965578] proc_reg_write+0x59/0xb0
[ 982.966905] vfs_write+0x111/0x470
[ 982.968004] ? __count_memcg_events+0xbf/0x150
[ 982.969432] ? count_memcg_events.constprop.0+0x26/0x50
[ 982.971190] ksys_write+0x6e/0xf0
[ 982.972307] do_syscall_64+0x62/0x180
[ 982.973438] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 982.975102] RIP: 0033:0x7f3d570fdbd7
[ 982.976421] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[ 982.982893] RSP: 002b:00007fff6d613c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 982.985424] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f3d570fdbd7
[ 982.987613] RDX: 0000000000000002 RSI: 000056362a928470 RDI: 0000000000000001
[ 982.989774] RBP: 000056362a928470 R08: 0000000000000000 R09: 00007f3d571b0d40
[ 982.992109] R10: 00007f3d571b0c40 R11: 0000000000000246 R12: 0000000000000002
[ 982.994321] R13: 00007f3d571fa780 R14: 0000000000000002 R15: 00007f3d571f59e0
[ 982.996461] </TASK>
[ 982.998317] Kernel Offset: 0x10c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 0.000000] Linux version 6.13.0 (lisatest@lisa--505-e0-n0) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-2.0.1), GNU ld version 2.35.2-54.0.1.el9) #1 SMP PREEMPT_DYNAMIC Thu Feb 6 10:05:27 UTC 2025
[ 0.000000] Command line: elfcorehdr=0xd000000 BOOT_IMAGE=(hd0,gpt1)/vmlinuz-6.13.0 ro console=tty0 console=ttyS0,115200n8 rd.lvm.vg=rootvg irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 acpi_no_memhotplug transparent_hugepage=never nokaslr hest_disable novmcoredd cma=0 hugetlb_cma=0 iommu=off disable_cpu_apicid=0
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000000c0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000000d0e00b0-0x000000002cffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000003eead000-0x000000003eeb3fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000003ff41000-0x000000003ffc8fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000003ffc9000-0x000000003fffafff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x000000003fffb000-0x000000003fffefff] ACPI NVS
[ 0.000000] random: crng init done
<snip>
[ 0.928063] Console: switching to colour frame buffer device 128x48
[ 13.391297] fb0: EFI VGA frame buffer device
<snip>
[ 590.199511] hv_netvsc 7c1e527c-2980-7c1e-527c-29807c1e527c (unnamed net_device) (uninitialized): VF slot 1 added
[ 595.120270] Console: switching to colour dummy device 80x25
[ 605.203700] hyperv_fb: Time out on waiting vram location ack
[ 605.206161] iounmap: bad address 0000000005f4dac5
[ 605.207740] CPU: 0 UID: 0 PID: 30 Comm: kworker/u4:2 Not tainted 6.13.0 #1
[ 605.209984] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 08/23/2024
[ 605.213869] Workqueue: async async_run_entry_fn
[ 605.215601] Call Trace:
[ 605.216382] <TASK>
[ 605.217123] dump_stack_lvl+0x66/0x90
[ 605.218184] hvfb_putmem+0x32/0x110 [hyperv_fb]
[ 605.219646] hvfb_probe+0x27f/0x360 [hyperv_fb]
[ 605.221120] vmbus_probe+0x3d/0xa0 [hv_vmbus]
[ 605.222623] really_probe+0xd9/0x390
[ 605.223779] __driver_probe_device+0x78/0x160
[ 605.225213] driver_probe_device+0x1e/0xa0
[ 605.226591] __driver_attach_async_helper+0x5e/0xe0
[ 605.228166] async_run_entry_fn+0x34/0x130
[ 605.229681] process_one_work+0x187/0x3b0
[ 605.231075] worker_thread+0x24e/0x360
[ 605.232376] ? __pfx_worker_thread+0x10/0x10
[ 605.233758] kthread+0xd3/0x100
[ 605.234805] ? __pfx_kthread+0x10/0x10
[ 605.236053] ret_from_fork+0x34/0x50
[ 605.237251] ? __pfx_kthread+0x10/0x10
[ 605.238519] ret_from_fork_asm+0x1a/0x30
[ 605.239833] </TASK>
[ 605.240855] hv_vmbus: probe failed for device 5620e0c7-8062-4dce-aeb7-520c7ef76171 (-110)
[ 605.243404] hyperv_fb 5620e0c7-8062-4dce-aeb7-520c7ef76171: probe with driver hyperv_fb failed with error -110
[ 605.254672] hv_vmbus: registering driver hv_pci
- Saurabh
> -----Original Message-----
> From: Michael Kelley <mhklinux@outlook.com>
> Sent: 07 February 2025 02:30
> To: Michael Kelley <mhklinux@outlook.com>; Thomas Tai
> <thomas.tai@oracle.com>; mhkelley58@gmail.com; Haiyang Zhang
> <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui
> <decui@microsoft.com>; drawat.floss@gmail.com; javierm@redhat.com;
> Helge Deller <deller@gmx.de>; daniel@ffwll.ch; airlied@gmail.com;
> tzimmermann@suse.de
> Cc: dri-devel@lists.freedesktop.org; linux-fbdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-hyperv@vger.kernel.org
> Subject: [EXTERNAL] RE: hyper_bf soft lockup on Azure Gen2 VM when taking
> kdump or executing kexec
>
> From: Michael Kelley <mhklinux@outlook.com>
> >
> > From: Thomas Tai <thomas.tai@oracle.com> Sent: Thursday, January 30,
> > 2025 12:44 PM
> > >
> > > > -----Original Message-----
> > > > From: Michael Kelley <mhklinux@outlook.com> Sent: Thursday,
> > > > January 30, 2025 3:20 PM
> > > >
> > > > From: Thomas Tai <thomas.tai@oracle.com> Sent: Thursday, January
> > > > 30,
> > > > 2025 10:50 AM
> > > > >
> > > > > Sorry for the typo in the subject title. It should have been
> > > > > 'hyperv_fb soft lockup on Azure Gen2 VM when taking kdump or
> executing kexec'
> > > > >
> > > > > Thomas
> > > > >
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > We see an issue with the mainline kernel on the Azure Gen 2 VM
> > > > > > when trying to induce a kernel panic with sysrq commands. The
> > > > > > VM would hang with soft lockup. A similar issue happens when
> executing kexec on the VM.
> > > > > > This issue is seen only with Gen2 VMs(with UEFI boot). Gen1
> > > > > > VMs with bios boot are fine.
> > > > > >
> > > > > > git bisect identifies the issue is cased by the commit
> > > > > > 20ee2ae8c5899
> > > > > > ("fbdev/hyperv_fb: Fix logic error for Gen2 VMs in hvfb_getmem()" ).
> > > > > > However, reverting the commit would cause the frame buffer not
> > > > > > to work on the Gen2 VM.
> > > > > >
> > > > > > Do you have any hints on what caused this issue?
> > > > > >
> > > > > > To reproduce the issue with kdump:
> > > > > > - Install mainline kernel on an Azure Gen 2 VM and trigger a
> > > > > > kdump
> > > > > > - echo 1 > /proc/sys/kernel/sysrq
> > > > > > - echo c > /proc/sysrq-trigger
> > > > > >
> > > > > > To reproduce the issue with executing kexec:
> > > > > > - Install mainline kernel on Azure Gen 2 VM and use kexec
> > > > > > - sudo kexec -l /boot/vmlinuz --initrd=/boot/initramfs.img
> > > > > > --command- line="$( cat /proc/cmdline )"
> > > > > > - sudo kexec -e
> > > > > >
> > > > > > Thank you,
> > > > > > Thomas
> > > >
> > > > I will take a look, but it might be early next week before I can do so.
> > > >
> > >
> > > Thank you, Michael for your help!
> > >
> > > > It looks like your soft lockup log below is from the kdump kernel
> > > > (or the newly kexec'ed kernel). Can you confirm? Also, this looks like a
> subset of the full log.
> > >
> > > Yes, the soft lockup log below is from the kdump kernel.
> > >
> > > > Do you have the full serial console log that you could email to
> > > > me? Seeing everything might be helpful. Of course, I'll try to
> > > > repro the problem myself as well.
> > >
> > > I have attached the complete bootup and kdump kernel log.
> > >
> > > File: bootup_and_kdump.log
> > > Line 1 ... 984 (bootup log)
> > > Line 990 (kdump kernel booting up)
> > > Line 1351 (soft lockup)
> > >
> > > Thank you,
> > > Thomas
> > >
> >
> > I have reproduced the problem in an Azure VM running Oracle Linux
> > 9.4 with the 6.13.0 kernel. Interestingly, the problem does not occur
> > in a VM running on a locally installed Hyper-V with Ubuntu 20.04 and
> > the 6.13.0 kernel. There are several differences in the two
> > environments: the version of Hyper-V, the VM configuration, the Linux
> > distro, and the .config file used to build the 6.13.0 kernel. I'll try
> > to figure out what make the difference, and then the root cause.
> >
>
> This has been a real bear to investigate. :-( The key observation is that with
> older kernel versions, the efifb driver does *not* try to load when running in
> the kdump kernel, and everything works.
> In newer kernels, the efifb driver *does* try to load, and it appears to hang.
> (Actually, it is causing the VM to run very slowly. More on that in a minute.)
>
> I've bisected the kernel again, compensating for the fact that commit
> 20ee2ae8c5899 is needed to make the Hyper-V frame buffer work. With that
> compensation, the actual problematic commit is 2bebc3cd4870 (Revert
> "firmware/sysfb: Clear screen_info state after consuming it").
> Doing the revert causes screen_info.orig_video_isVGA to retain its value of
> 0x70 (VIDEO_TYPE_EFI), which the kdump kernel picks up, causing it to load
> the efifb driver.
>
> Then the question is why the efifb driver doesn't work in the kdump kernel.
> Actually, it *does* work in many cases. I built the 6.13.0 kernel on the Oracle
> Linux 9.4 system, and transferred the kernel image binary and module
> binaries to an Ubuntu 20.04 VM in Azure. In that VM, the efifb driver is
> loaded as part of the kdump kernel, and it doesn't cause any problems. But
> there's an interesting difference. In the Oracle Linux
> 9.4 VM, the efifb driver finds the framebuffer at 0x40000000, while on the
> Ubuntu 20.04 VM, it finds the framebuffer at 0x40900000. This difference is
> due to differences in how the screen_info variable gets setup in the two VMs.
>
> When the normal kernel starts in a freshly booted VM, Hyper-V provides the
> EFI framebuffer at 0x40000000, and it works. But after the Hyper-V FB driver
> or Hyper-V DRM driver has initialized, Linux has picked a different MMIO
> address range and told Hyper-V to use the new address range (which often
> starts at 0x40900000). A kexec does *not* reset Hyper-V's transition to the
> new range, so when the efifb driver tries to use the framebuffer at
> 0x40000000, the accesses trap to Hyper-V and probably fail or timeout (I'm
> not sure of the details). After the guest does some number of these bad
> references, Hyper-V considers itself to be under attack from an ill-behaving
> guest, and throttles the guest so that it doesn't run for a few seconds. The
> throttling repeats, and results in extremely slow running in the kdump kernel.
>
> Somehow in the Ubuntu 20.04 VM, the location of the frame buffer as stored
> in screen_info.lfb_base gets updated to be 0x40900000. I haven't fully
> debugged how that happens. But with that update, the efifb driver is using
> the updated framebuffer address and it works. On the Oracle Linux 9.4
> system, that update doesn't appear to happen, and the problem occurs.
>
> This in an interim update on the problem. I'm still investigating how
> screen_info.lfb_base is set in the kdump kernel, and why it is different in the
> Ubuntu 20.04 VM vs. in the Oracle Linux 9.4 VM. Once that is well
> understood, we can contemplate how to fix the problem. Undoing the revert
> that is commit 2bebc3cd4870 doesn't seem like the solution since the original
> code there was reported to cause many other issues.
> The solution focus will likely be on how to ensure the kdump kernel gets the
> correct framebuffer address so the efifb driver works, since the framebuffer
> address changing is a quirk of Hyper-V behavior.
>
> If anyone else has insight into what's going on here, please chime in.
> What I've learned so far is still somewhat tentative.
>
> Michael
^ permalink raw reply
* Re: [PATCH] backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()
From: Herve Codina @ 2025-02-07 13:30 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Tony Lindgren, Pavel Machek, Tomi Valkeinen, Jean-Jacques Hiblot
Cc: Daniel Thompson, dri-devel, linux-fbdev, linux-kernel,
Luca Ceresoli, Thomas Petazzoni, stable
In-Reply-To: <20250122091914.309533-1-herve.codina@bootlin.com>
Hi Lee, Daniel, Jingoo,
On Wed, 22 Jan 2025 10:19:14 +0100
Herve Codina <herve.codina@bootlin.com> wrote:
> Lockdep detects the following issue on led-backlight removal:
> [ 142.315935] ------------[ cut here ]------------
> [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80
> ...
> [ 142.500725] Call trace:
> [ 142.503176] led_sysfs_enable+0x54/0x80 (P)
> [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl]
> [ 142.511742] platform_remove+0x30/0x58
> [ 142.515501] device_remove+0x54/0x90
> ...
>
> Indeed, led_sysfs_enable() has to be called with the led_access
> lock held.
>
> Hold the lock when calling led_sysfs_disable().
>
> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
I didn't receive any feedback.
v6.14-rc1 has been released since the patch was sent but the patch applies on
top of v6.14-rc1 without any issue.
Of course if really needed, I can resend the patch. Just tell me.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH RESEND 00/13] fbdev: core: Deduplicate cfb/sys drawing fbops
From: Thomas Zimmermann @ 2025-02-07 8:12 UTC (permalink / raw)
To: Zsolt Kajtar, linux-fbdev, dri-devel
In-Reply-To: <20250207041818.4031-1-soci@c64.rulez.org>
Hi
Am 07.02.25 um 05:18 schrieb Zsolt Kajtar:
> In 68648ed1f58d98b8e8d994022e5e25331fbfe42a the drawing routines were
> duplicated to have separate I/O and system memory versions.
>
> Later the pixel reversing in 779121e9f17525769c04a00475fd85600c8c04eb
> was only added to the I/O version and not to system.
>
> That's unfortunate as reversing is not something only applicable for
> I/O memory and I happen to need both I/O and system version now.
>
> One option is to bring the system version up to date, but from the
> maintenance perspective it's better to not have two versions in the
> first place.
No it's not. Major code abstractions behind preprocessor tokens are
terrible to maintain. It's also technically not possible to switch
between system and I/O memory at will. These are very different things.
If you want that pixel-reversing feature in sys_ helpers, please
implement it there.
Sorry, but NAK on this series.
Best regards
Thomas
>
> The drawing routines (based on the cfb version) were moved to header
> files. These are now included in both cfb and sys modules. The memory
> access and other minor differences were handled with a few macros.
>
> The last patch adds a separate config option for the system version.
>
> Zsolt Kajtar (13):
> fbdev: core: Copy cfbcopyarea to fb_copyarea
> fbdev: core: Make fb_copyarea generic
> fbdev: core: Use generic copyarea for as cfb_copyarea
> fbdev: core: Use generic copyarea for as sys_copyarea
> fbdev: core: Copy cfbfillrect to fb_fillrect
> fbdev: core: Make fb_fillrect generic
> fbdev: core: Use generic fillrect for as cfb_fillrect
> fbdev: core: Use generic fillrect for as sys_fillrect
> fbdev: core: Copy cfbimgblt to fb_imageblit
> fbdev: core: Make fb_imageblit generic
> fbdev: core: Use generic imageblit for as cfb_imageblit
> fbdev: core: Use generic imageblit for as sys_imageblit
> fbdev: core: Split CFB and SYS pixel reversing configuration
>
> drivers/video/fbdev/core/Kconfig | 10 +-
> drivers/video/fbdev/core/cfbcopyarea.c | 427 +-----------------------
> drivers/video/fbdev/core/cfbfillrect.c | 363 +-------------------
> drivers/video/fbdev/core/cfbimgblt.c | 358 +-------------------
> drivers/video/fbdev/core/fb_copyarea.h | 421 +++++++++++++++++++++++
> drivers/video/fbdev/core/fb_draw.h | 6 +-
> drivers/video/fbdev/core/fb_fillrect.h | 359 ++++++++++++++++++++
> drivers/video/fbdev/core/fb_imageblit.h | 356 ++++++++++++++++++++
> drivers/video/fbdev/core/syscopyarea.c | 358 +-------------------
> drivers/video/fbdev/core/sysfillrect.c | 315 +----------------
> drivers/video/fbdev/core/sysimgblt.c | 326 +-----------------
> 11 files changed, 1208 insertions(+), 2091 deletions(-)
> create mode 100644 drivers/video/fbdev/core/fb_copyarea.h
> create mode 100644 drivers/video/fbdev/core/fb_fillrect.h
> create mode 100644 drivers/video/fbdev/core/fb_imageblit.h
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox