* [PATCH 08/14] fbdev/omap2: Include <linux/export.h>
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
In-Reply-To: <20250610105948.384540-1-tzimmermann@suse.de>
Fix the compile-time warnings
drivers/video/fbdev/omap2/omapfb/dss/apply.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/core.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/display.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/dss_features.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/manager.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/output.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/overlay.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/dss/venc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/omap2/omapfb/vrfb.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/omap2/omapfb/dss/apply.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/core.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/display.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/dss_features.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/manager.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/output.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/overlay.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 1 +
drivers/video/fbdev/omap2/omapfb/vrfb.c | 1 +
11 files changed, 11 insertions(+)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/apply.c b/drivers/video/fbdev/omap2/omapfb/dss/apply.c
index acca991c7540..39947e569a54 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/apply.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/apply.c
@@ -6,6 +6,7 @@
#define DSS_SUBSYS_NAME "APPLY"
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/slab.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/core.c b/drivers/video/fbdev/omap2/omapfb/dss/core.c
index 55b640f2f245..02ea41f6c8f4 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/export.h>
#include <linux/platform_device.h>
#include <linux/seq_file.h>
#include <linux/debugfs.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
index cc2ad787d493..7831c6a2eedb 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
@@ -6,6 +6,7 @@
#define DSS_SUBSYS_NAME "APPLY"
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/slab.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/display.c b/drivers/video/fbdev/omap2/omapfb/dss/display.c
index f91db94c9905..16543425bd84 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/display.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/display.c
@@ -11,6 +11,7 @@
#define DSS_SUBSYS_NAME "DISPLAY"
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/jiffies.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index 7c636db79882..f90a8eff7259 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -6,6 +6,7 @@
#include <linux/device.h>
#include <linux/err.h>
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_graph.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
index 62c2d48d9e09..38be57ba8c28 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
@@ -6,6 +6,7 @@
* Author: Archit Taneja <archit@ti.com>
*/
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/manager.c b/drivers/video/fbdev/omap2/omapfb/dss/manager.c
index 2c2da35345d0..c59e5689d6cc 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/manager.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/manager.c
@@ -11,6 +11,7 @@
#define DSS_SUBSYS_NAME "MANAGER"
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/module.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/output.c b/drivers/video/fbdev/omap2/omapfb/dss/output.c
index 4e2992a0ce50..48cbfb75443f 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/output.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/output.c
@@ -4,6 +4,7 @@
* Author: Archit Taneja <archit@ti.com>
*/
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/overlay.c b/drivers/video/fbdev/omap2/omapfb/dss/overlay.c
index 8c8e627da13d..bbbdc233ee61 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/overlay.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/overlay.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/err.h>
+#include <linux/export.h>
#include <linux/sysfs.h>
#include <linux/platform_device.h>
#include <linux/delay.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
index f99dda9e55a5..ed283029ad95 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
@@ -14,6 +14,7 @@
#include <linux/module.h>
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/export.h>
#include <linux/io.h>
#include <linux/mutex.h>
#include <linux/completion.h>
diff --git a/drivers/video/fbdev/omap2/omapfb/vrfb.c b/drivers/video/fbdev/omap2/omapfb/vrfb.c
index 568e6e1eca62..675482cde519 100644
--- a/drivers/video/fbdev/omap2/omapfb/vrfb.c
+++ b/drivers/video/fbdev/omap2/omapfb/vrfb.c
@@ -9,6 +9,7 @@
/*#define DEBUG*/
#include <linux/err.h>
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/ioport.h>
--
2.49.0
^ permalink raw reply related
* [PATCH 05/14] fbdev/matroxfb: Remove trailing whitespaces
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
In-Reply-To: <20250610105948.384540-1-tzimmermann@suse.de>
Fix coding style.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/matrox/g450_pll.c | 24 ++++----
drivers/video/fbdev/matrox/matroxfb_DAC1064.c | 46 +++++++-------
drivers/video/fbdev/matrox/matroxfb_g450.c | 60 +++++++++----------
drivers/video/fbdev/matrox/matroxfb_misc.c | 20 +++----
4 files changed, 75 insertions(+), 75 deletions(-)
diff --git a/drivers/video/fbdev/matrox/g450_pll.c b/drivers/video/fbdev/matrox/g450_pll.c
index ff8e321a22ce..96996efc9288 100644
--- a/drivers/video/fbdev/matrox/g450_pll.c
+++ b/drivers/video/fbdev/matrox/g450_pll.c
@@ -258,13 +258,13 @@ static inline unsigned int g450_findworkingpll(struct matrox_fb_info *minfo,
unsigned int found = 0;
unsigned int idx;
unsigned int mnpfound = mnparray[0];
-
+
for (idx = 0; idx < mnpcount; idx++) {
unsigned int sarray[3];
unsigned int *sptr;
{
unsigned int mnp;
-
+
sptr = sarray;
mnp = mnparray[idx];
if (mnp & 0x38) {
@@ -277,7 +277,7 @@ static inline unsigned int g450_findworkingpll(struct matrox_fb_info *minfo,
}
while (sptr >= sarray) {
unsigned int mnp = *sptr--;
-
+
if (g450_testpll(minfo, mnp - 0x0300, pll) &&
g450_testpll(minfo, mnp + 0x0300, pll) &&
g450_testpll(minfo, mnp - 0x0200, pll) &&
@@ -310,12 +310,12 @@ static int g450_checkcache(struct matrox_fb_info *minfo,
struct matrox_pll_cache *ci, unsigned int mnp_key)
{
unsigned int i;
-
+
mnp_key &= G450_MNP_FREQBITS;
for (i = 0; i < ci->valid; i++) {
if (ci->data[i].mnp_key == mnp_key) {
unsigned int mnp;
-
+
mnp = ci->data[i].mnp_value;
if (i) {
memmove(ci->data + 1, ci->data, i * sizeof(*ci->data));
@@ -343,7 +343,7 @@ static int __g450_setclk(struct matrox_fb_info *minfo, unsigned int fout,
{
u_int8_t tmp, xpwrctrl;
unsigned long flags;
-
+
matroxfb_DAC_lock_irqsave(flags);
xpwrctrl = matroxfb_DAC_in(minfo, M1064_XPWRCTRL);
@@ -375,7 +375,7 @@ static int __g450_setclk(struct matrox_fb_info *minfo, unsigned int fout,
}
{
u_int8_t misc;
-
+
misc = mga_inb(M_MISC_REG_READ) & ~0x0C;
switch (pll) {
case M_PIXEL_PLL_A:
@@ -409,13 +409,13 @@ static int __g450_setclk(struct matrox_fb_info *minfo, unsigned int fout,
u_int8_t tmp;
unsigned int mnp;
unsigned long flags;
-
+
matroxfb_DAC_lock_irqsave(flags);
tmp = matroxfb_DAC_in(minfo, M1064_XPWRCTRL);
if (!(tmp & 2)) {
matroxfb_DAC_out(minfo, M1064_XPWRCTRL, tmp | 2);
}
-
+
mnp = matroxfb_DAC_in(minfo, M1064_XPIXPLLCM) << 16;
mnp |= matroxfb_DAC_in(minfo, M1064_XPIXPLLCN) << 8;
matroxfb_DAC_unlock_irqrestore(flags);
@@ -441,7 +441,7 @@ static int __g450_setclk(struct matrox_fb_info *minfo, unsigned int fout,
delta = pll_freq_delta(fout, g450_vco2f(mnp, vco));
for (idx = mnpcount; idx > 0; idx--) {
/* == is important; due to nextpll algorithm we get
- sorted equally good frequencies from lower VCO
+ sorted equally good frequencies from lower VCO
frequency to higher - with <= lowest wins, while
with < highest one wins */
if (delta <= deltaarray[idx-1]) {
@@ -472,7 +472,7 @@ static int __g450_setclk(struct matrox_fb_info *minfo, unsigned int fout,
{
unsigned long flags;
unsigned int mnp;
-
+
matroxfb_DAC_lock_irqsave(flags);
mnp = g450_checkcache(minfo, ci, mnparray[0]);
if (mnp != NO_MORE_MNP) {
@@ -495,7 +495,7 @@ int matroxfb_g450_setclk(struct matrox_fb_info *minfo, unsigned int fout,
unsigned int pll)
{
unsigned int* arr;
-
+
arr = kmalloc(sizeof(*arr) * MNP_TABLE_SIZE * 2, GFP_KERNEL);
if (arr) {
int r;
diff --git a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
index 398b7035f5a9..99bdcb52ef4b 100644
--- a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
+++ b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
@@ -43,11 +43,11 @@ static void DAC1064_calcclock(const struct matrox_fb_info *minfo,
unsigned int p;
DBG(__func__)
-
+
/* only for devices older than G450 */
fvco = PLL_calcclock(minfo, freq, fmax, in, feed, &p);
-
+
p = (1 << p) - 1;
if (fvco <= 100000)
;
@@ -169,7 +169,7 @@ static void g450_set_plls(struct matrox_fb_info *minfo)
struct matrox_hw_state *hw = &minfo->hw;
int pixelmnp;
int videomnp;
-
+
c2_ctl = hw->crtc2.ctl & ~0x4007; /* Clear PLL + enable for CRTC2 */
c2_ctl |= 0x0001; /* Enable CRTC2 */
hw->DACreg[POS1064_XPWRCTRL] &= ~0x02; /* Stop VIDEO PLL */
@@ -192,7 +192,7 @@ static void g450_set_plls(struct matrox_fb_info *minfo)
}
c2_ctl |= 0x0006; /* Use video PLL */
hw->DACreg[POS1064_XPWRCTRL] |= 0x02;
-
+
outDAC1064(minfo, M1064_XPWRCTRL, hw->DACreg[POS1064_XPWRCTRL]);
matroxfb_g450_setpll_cond(minfo, videomnp, M_VIDEO_PLL);
}
@@ -200,7 +200,7 @@ static void g450_set_plls(struct matrox_fb_info *minfo)
hw->DACreg[POS1064_XPIXCLKCTRL] &= ~M1064_XPIXCLKCTRL_PLL_UP;
if (pixelmnp >= 0) {
hw->DACreg[POS1064_XPIXCLKCTRL] |= M1064_XPIXCLKCTRL_PLL_UP;
-
+
outDAC1064(minfo, M1064_XPIXCLKCTRL, hw->DACreg[POS1064_XPIXCLKCTRL]);
matroxfb_g450_setpll_cond(minfo, pixelmnp, M_PIXEL_PLL_C);
}
@@ -303,9 +303,9 @@ void DAC1064_global_init(struct matrox_fb_info *minfo)
poweroff TMDS. But if we boot with DFP connected,
TMDS generated clocks are used instead of ALL pixclocks
available... If someone knows which register
- handles it, please reveal this secret to me... */
+ handles it, please reveal this secret to me... */
hw->DACreg[POS1064_XPWRCTRL] &= ~0x04; /* Poweroff TMDS */
-#endif
+#endif
break;
}
/* Now set timming related variables... */
@@ -728,14 +728,14 @@ static void g450_mclk_init(struct matrox_fb_info *minfo)
} else {
unsigned long flags;
unsigned int pwr;
-
+
matroxfb_DAC_lock_irqsave(flags);
pwr = inDAC1064(minfo, M1064_XPWRCTRL) & ~0x02;
outDAC1064(minfo, M1064_XPWRCTRL, pwr);
matroxfb_DAC_unlock_irqrestore(flags);
}
matroxfb_g450_setclk(minfo, minfo->values.pll.system, M_SYSTEM_PLL);
-
+
/* switch clocks to their real PLL source(s) */
pci_write_config_dword(minfo->pcidev, PCI_OPTION_REG, minfo->hw.MXoptionReg | 4);
pci_write_config_dword(minfo->pcidev, PCI_OPTION3_REG, minfo->values.reg.opt3);
@@ -748,15 +748,15 @@ static void g450_memory_init(struct matrox_fb_info *minfo)
/* disable memory refresh */
minfo->hw.MXoptionReg &= ~0x001F8000;
pci_write_config_dword(minfo->pcidev, PCI_OPTION_REG, minfo->hw.MXoptionReg);
-
+
/* set memory interface parameters */
minfo->hw.MXoptionReg &= ~0x00207E00;
minfo->hw.MXoptionReg |= 0x00207E00 & minfo->values.reg.opt;
pci_write_config_dword(minfo->pcidev, PCI_OPTION_REG, minfo->hw.MXoptionReg);
pci_write_config_dword(minfo->pcidev, PCI_OPTION2_REG, minfo->values.reg.opt2);
-
+
mga_outl(M_CTLWTST, minfo->values.reg.mctlwtst);
-
+
/* first set up memory interface with disabled memory interface clocks */
pci_write_config_dword(minfo->pcidev, PCI_MEMMISC_REG, minfo->values.reg.memmisc & ~0x80000000U);
mga_outl(M_MEMRDBK, minfo->values.reg.memrdbk);
@@ -765,25 +765,25 @@ static void g450_memory_init(struct matrox_fb_info *minfo)
pci_write_config_dword(minfo->pcidev, PCI_MEMMISC_REG, minfo->values.reg.memmisc | 0x80000000U);
udelay(200);
-
+
if (minfo->values.memory.ddr && (!minfo->values.memory.emrswen || !minfo->values.memory.dll)) {
mga_outl(M_MEMRDBK, minfo->values.reg.memrdbk & ~0x1000);
}
mga_outl(M_MACCESS, minfo->values.reg.maccess | 0x8000);
-
+
udelay(200);
-
+
minfo->hw.MXoptionReg |= 0x001F8000 & minfo->values.reg.opt;
pci_write_config_dword(minfo->pcidev, PCI_OPTION_REG, minfo->hw.MXoptionReg);
-
+
/* value is written to memory chips only if old != new */
mga_outl(M_PLNWT, 0);
mga_outl(M_PLNWT, ~0);
-
+
if (minfo->values.reg.mctlwtst != minfo->values.reg.mctlwtst_core) {
mga_outl(M_CTLWTST, minfo->values.reg.mctlwtst_core);
}
-
+
}
static void g450_preinit(struct matrox_fb_info *minfo)
@@ -791,7 +791,7 @@ static void g450_preinit(struct matrox_fb_info *minfo)
u_int32_t c2ctl;
u_int8_t curctl;
u_int8_t c1ctl;
-
+
/* minfo->hw.MXoptionReg = minfo->values.reg.opt; */
minfo->hw.MXoptionReg &= 0xC0000100;
minfo->hw.MXoptionReg |= 0x00000020;
@@ -805,7 +805,7 @@ static void g450_preinit(struct matrox_fb_info *minfo)
pci_write_config_dword(minfo->pcidev, PCI_OPTION_REG, minfo->hw.MXoptionReg);
/* Init system clocks */
-
+
/* stop crtc2 */
c2ctl = mga_inl(M_C2CTL);
mga_outl(M_C2CTL, c2ctl & ~1);
@@ -818,20 +818,20 @@ static void g450_preinit(struct matrox_fb_info *minfo)
g450_mclk_init(minfo);
g450_memory_init(minfo);
-
+
/* set legacy VGA clock sources for DOSEmu or VMware... */
matroxfb_g450_setclk(minfo, 25175, M_PIXEL_PLL_A);
matroxfb_g450_setclk(minfo, 28322, M_PIXEL_PLL_B);
/* restore crtc1 */
mga_setr(M_SEQ_INDEX, 1, c1ctl);
-
+
/* restore cursor */
outDAC1064(minfo, M1064_XCURCTRL, curctl);
/* restore crtc2 */
mga_outl(M_C2CTL, c2ctl);
-
+
return;
}
diff --git a/drivers/video/fbdev/matrox/matroxfb_g450.c b/drivers/video/fbdev/matrox/matroxfb_g450.c
index df3309fd14f3..86fe757d7761 100644
--- a/drivers/video/fbdev/matrox/matroxfb_g450.c
+++ b/drivers/video/fbdev/matrox/matroxfb_g450.c
@@ -32,29 +32,29 @@ struct mctl {
#define WLMAX 0x3FF
static const struct mctl g450_controls[] =
-{ { { V4L2_CID_BRIGHTNESS, V4L2_CTRL_TYPE_INTEGER,
+{ { { V4L2_CID_BRIGHTNESS, V4L2_CTRL_TYPE_INTEGER,
"brightness",
- 0, WLMAX-BLMIN, 1, 370-BLMIN,
+ 0, WLMAX-BLMIN, 1, 370-BLMIN,
0,
}, offsetof(struct matrox_fb_info, altout.tvo_params.brightness) },
- { { V4L2_CID_CONTRAST, V4L2_CTRL_TYPE_INTEGER,
+ { { V4L2_CID_CONTRAST, V4L2_CTRL_TYPE_INTEGER,
"contrast",
- 0, 1023, 1, 127,
+ 0, 1023, 1, 127,
0,
}, offsetof(struct matrox_fb_info, altout.tvo_params.contrast) },
{ { V4L2_CID_SATURATION, V4L2_CTRL_TYPE_INTEGER,
"saturation",
- 0, 255, 1, 165,
+ 0, 255, 1, 165,
0,
}, offsetof(struct matrox_fb_info, altout.tvo_params.saturation) },
{ { V4L2_CID_HUE, V4L2_CTRL_TYPE_INTEGER,
"hue",
- 0, 255, 1, 0,
+ 0, 255, 1, 0,
0,
}, offsetof(struct matrox_fb_info, altout.tvo_params.hue) },
{ { MATROXFB_CID_TESTOUT, V4L2_CTRL_TYPE_BOOLEAN,
"test output",
- 0, 1, 1, 0,
+ 0, 1, 1, 0,
0,
}, offsetof(struct matrox_fb_info, altout.tvo_params.testout) },
};
@@ -89,7 +89,7 @@ static inline int *get_ctrl_ptr(struct matrox_fb_info *minfo, unsigned int idx)
static void tvo_fill_defaults(struct matrox_fb_info *minfo)
{
unsigned int i;
-
+
for (i = 0; i < G450CTRLS; i++) {
*get_ctrl_ptr(minfo, i) = g450_controls[i].desc.default_value;
}
@@ -99,7 +99,7 @@ static int cve2_get_reg(struct matrox_fb_info *minfo, int reg)
{
unsigned long flags;
int val;
-
+
matroxfb_DAC_lock_irqsave(flags);
matroxfb_DAC_out(minfo, 0x87, reg);
val = matroxfb_DAC_in(minfo, 0x88);
@@ -141,16 +141,16 @@ static void g450_compute_bwlevel(const struct matrox_fb_info *minfo, int *bl,
static int g450_query_ctrl(void* md, struct v4l2_queryctrl *p) {
int i;
-
+
i = get_ctrl_id(p->id);
if (i >= 0) {
*p = g450_controls[i].desc;
return 0;
}
if (i == -ENOENT) {
- static const struct v4l2_queryctrl disctrl =
+ static const struct v4l2_queryctrl disctrl =
{ .flags = V4L2_CTRL_FLAG_DISABLED };
-
+
i = p->id;
*p = disctrl;
p->id = i;
@@ -163,7 +163,7 @@ static int g450_query_ctrl(void* md, struct v4l2_queryctrl *p) {
static int g450_set_ctrl(void* md, struct v4l2_control *p) {
int i;
struct matrox_fb_info *minfo = md;
-
+
i = get_ctrl_id(p->id);
if (i < 0) return -EINVAL;
@@ -209,7 +209,7 @@ static int g450_set_ctrl(void* md, struct v4l2_control *p) {
}
break;
}
-
+
return 0;
}
@@ -217,7 +217,7 @@ static int g450_set_ctrl(void* md, struct v4l2_control *p) {
static int g450_get_ctrl(void* md, struct v4l2_control *p) {
int i;
struct matrox_fb_info *minfo = md;
-
+
i = get_ctrl_id(p->id);
if (i < 0) return -EINVAL;
p->value = *get_ctrl_ptr(minfo, i);
@@ -247,22 +247,22 @@ static void computeRegs(struct matrox_fb_info *minfo, struct mavenregs *r,
unsigned long long piic;
int mnp;
int over;
-
+
r->regs[0x80] = 0x03; /* | 0x40 for SCART */
hvis = ((mt->HDisplay << 1) + 3) & ~3;
-
+
if (hvis >= 2048) {
hvis = 2044;
}
-
+
piic = 1000000000ULL * hvis;
do_div(piic, outd->h_vis);
dprintk(KERN_DEBUG "Want %u kHz pixclock\n", (unsigned int)piic);
-
+
mnp = matroxfb_g450_setclk(minfo, piic, M_VIDEO_PLL);
-
+
mt->mnp = mnp;
mt->pixclock = g450_mnp2f(minfo, mnp);
@@ -275,7 +275,7 @@ static void computeRegs(struct matrox_fb_info *minfo, struct mavenregs *r,
piic = outd->chromasc;
do_div(piic, mt->pixclock);
chromasc = piic;
-
+
dprintk(KERN_DEBUG "Chroma is %08X\n", chromasc);
r->regs[0] = piic >> 24;
@@ -287,7 +287,7 @@ static void computeRegs(struct matrox_fb_info *minfo, struct mavenregs *r,
hsl = (((outd->h_sync + pixclock) / pixclock)) & ~1;
hlen = hvis + hfp + hsl + hbp;
over = hlen & 0x0F;
-
+
dprintk(KERN_DEBUG "WL: vis=%u, hf=%u, hs=%u, hb=%u, total=%u\n", hvis, hfp, hsl, hbp, hlen);
if (over) {
@@ -310,14 +310,14 @@ static void computeRegs(struct matrox_fb_info *minfo, struct mavenregs *r,
r->regs[0x2C] = hfp;
r->regs[0x31] = hvis / 8;
r->regs[0x32] = hvis & 7;
-
+
dprintk(KERN_DEBUG "PG: vis=%04X, hf=%02X, hs=%02X, hb=%02X, total=%04X\n", hvis, hfp, hsl, hbp, hlen);
r->regs[0x84] = 1; /* x sync point */
r->regs[0x85] = 0;
hvis = hvis >> 1;
hlen = hlen >> 1;
-
+
dprintk(KERN_DEBUG "hlen=%u hvis=%u\n", hlen, hvis);
mt->interlaced = 1;
@@ -332,13 +332,13 @@ static void computeRegs(struct matrox_fb_info *minfo, struct mavenregs *r,
unsigned int vtotal;
unsigned int vsyncend;
unsigned int vdisplay;
-
+
vtotal = mt->VTotal;
vsyncend = mt->VSyncEnd;
vdisplay = mt->VDisplay;
if (vtotal < outd->v_total) {
unsigned int yovr = outd->v_total - vtotal;
-
+
vsyncend += yovr >> 1;
} else if (vtotal > outd->v_total) {
vdisplay = outd->v_total - 4;
@@ -350,7 +350,7 @@ static void computeRegs(struct matrox_fb_info *minfo, struct mavenregs *r,
r->regs[0x33] = upper - 1; /* upper blanking */
r->regs[0x82] = upper; /* y sync point */
r->regs[0x83] = upper >> 8;
-
+
mt->VDisplay = vdisplay;
mt->VSyncStart = outd->v_total - 2;
mt->VSyncEnd = outd->v_total;
@@ -509,9 +509,9 @@ static void cve2_init_TV(struct matrox_fb_info *minfo,
LR(0x80);
LR(0x82); LR(0x83);
LR(0x84); LR(0x85);
-
+
cve2_set_reg(minfo, 0x3E, 0x01);
-
+
for (i = 0; i < 0x3E; i++) {
LR(i);
}
@@ -558,7 +558,7 @@ static int matroxfb_g450_compute(void* md, struct my_timming* mt) {
static int matroxfb_g450_program(void* md) {
struct matrox_fb_info *minfo = md;
-
+
if (minfo->outputs[1].mode != MATROXFB_OUTPUT_MODE_MONITOR) {
cve2_init_TV(minfo, &minfo->hw.maven);
}
diff --git a/drivers/video/fbdev/matrox/matroxfb_misc.c b/drivers/video/fbdev/matrox/matroxfb_misc.c
index 8f159a2ad8d0..3fe99214c116 100644
--- a/drivers/video/fbdev/matrox/matroxfb_misc.c
+++ b/drivers/video/fbdev/matrox/matroxfb_misc.c
@@ -390,7 +390,7 @@ void matroxfb_vgaHWrestore(struct matrox_fb_info *minfo)
static void get_pins(unsigned char __iomem* pins, struct matrox_bios* bd) {
unsigned int b0 = readb(pins);
-
+
if (b0 == 0x2E && readb(pins+1) == 0x41) {
unsigned int pins_len = readb(pins+2);
unsigned int i;
@@ -426,7 +426,7 @@ static void get_pins(unsigned char __iomem* pins, struct matrox_bios* bd) {
static void get_bios_version(unsigned char __iomem * vbios, struct matrox_bios* bd) {
unsigned int pcir_offset;
-
+
pcir_offset = readb(vbios + 24) | (readb(vbios + 25) << 8);
if (pcir_offset >= 26 && pcir_offset < 0xFFE0 &&
readb(vbios + pcir_offset ) == 'P' &&
@@ -451,7 +451,7 @@ static void get_bios_version(unsigned char __iomem * vbios, struct matrox_bios*
static void get_bios_output(unsigned char __iomem* vbios, struct matrox_bios* bd) {
unsigned char b;
-
+
b = readb(vbios + 0x7FF1);
if (b == 0xFF) {
b = 0;
@@ -461,7 +461,7 @@ static void get_bios_output(unsigned char __iomem* vbios, struct matrox_bios* bd
static void get_bios_tvout(unsigned char __iomem* vbios, struct matrox_bios* bd) {
unsigned int i;
-
+
/* Check for 'IBM .*(V....TVO' string - it means TVO BIOS */
bd->output.tvout = 0;
if (readb(vbios + 0x1D) != 'I' ||
@@ -472,7 +472,7 @@ static void get_bios_tvout(unsigned char __iomem* vbios, struct matrox_bios* bd)
}
for (i = 0x2D; i < 0x2D + 128; i++) {
unsigned char b = readb(vbios + i);
-
+
if (b == '(' && readb(vbios + i + 1) == 'V') {
if (readb(vbios + i + 6) == 'T' &&
readb(vbios + i + 7) == 'V' &&
@@ -488,7 +488,7 @@ static void get_bios_tvout(unsigned char __iomem* vbios, struct matrox_bios* bd)
static void parse_bios(unsigned char __iomem* vbios, struct matrox_bios* bd) {
unsigned int pins_offset;
-
+
if (readb(vbios) != 0x55 || readb(vbios + 1) != 0xAA) {
return;
}
@@ -648,9 +648,9 @@ static int parse_pins5(struct matrox_fb_info *minfo,
const struct matrox_bios *bd)
{
unsigned int mult;
-
+
mult = bd->pins[4]?8000:6000;
-
+
minfo->limits.pixel.vcomax = (bd->pins[ 38] == 0xFF) ? 600000 : bd->pins[ 38] * mult;
minfo->limits.system.vcomax = (bd->pins[ 36] == 0xFF) ? minfo->limits.pixel.vcomax : bd->pins[ 36] * mult;
minfo->limits.video.vcomax = (bd->pins[ 37] == 0xFF) ? minfo->limits.system.vcomax : bd->pins[ 37] * mult;
@@ -770,7 +770,7 @@ void matroxfb_read_pins(struct matrox_fb_info *minfo)
u32 biosbase;
u32 fbbase;
struct pci_dev *pdev = minfo->pcidev;
-
+
memset(&minfo->bios, 0, sizeof(minfo->bios));
pci_read_config_dword(pdev, PCI_OPTION_REG, &opt);
pci_write_config_dword(pdev, PCI_OPTION_REG, opt | PCI_OPTION_ENABLE_ROM);
@@ -790,7 +790,7 @@ void matroxfb_read_pins(struct matrox_fb_info *minfo)
} else {
unsigned int ven = readb(b+0x64+0) | (readb(b+0x64+1) << 8);
unsigned int dev = readb(b+0x64+2) | (readb(b+0x64+3) << 8);
-
+
if (ven != pdev->vendor || dev != pdev->device) {
printk(KERN_INFO "matroxfb: Legacy BIOS is for %04X:%04X, while this device is %04X:%04X\n",
ven, dev, pdev->vendor, pdev->device);
--
2.49.0
^ permalink raw reply related
* [PATCH 03/14] fbdev/c2p: Include <linux/export.h>
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
In-Reply-To: <20250610105948.384540-1-tzimmermann@suse.de>
Fix the compile-time warnings
drivers/video/fbdev/c2p_iplan2.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/c2p_planar.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/c2p_iplan2.c | 1 +
drivers/video/fbdev/c2p_planar.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/c2p_iplan2.c b/drivers/video/fbdev/c2p_iplan2.c
index cfd2361f24b1..ee4b315d3f40 100644
--- a/drivers/video/fbdev/c2p_iplan2.c
+++ b/drivers/video/fbdev/c2p_iplan2.c
@@ -8,6 +8,7 @@
* for more details.
*/
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/string.h>
diff --git a/drivers/video/fbdev/c2p_planar.c b/drivers/video/fbdev/c2p_planar.c
index 819c82a98ac0..236aad5137ef 100644
--- a/drivers/video/fbdev/c2p_planar.c
+++ b/drivers/video/fbdev/c2p_planar.c
@@ -8,6 +8,7 @@
* for more details.
*/
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/string.h>
--
2.49.0
^ permalink raw reply related
* [PATCH 04/14] fbdev/cyber2000fb: Unexport symbols
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
In-Reply-To: <20250610105948.384540-1-tzimmermann@suse.de>
Fix the compile-time warning
drivers/video/fbdev/cyber2000fb.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
The affected symbols are not used outside of their module.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/cyber2000fb.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c b/drivers/video/fbdev/cyber2000fb.c
index 986760b90465..fcc565b2d98c 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -1089,7 +1089,6 @@ void cyber2000fb_enable_extregs(struct cfb_info *cfb)
cyber2000_grphw(EXT_FUNC_CTL, old, cfb);
}
}
-EXPORT_SYMBOL(cyber2000fb_enable_extregs);
/*
* Disable access to the extended registers
@@ -1109,7 +1108,6 @@ void cyber2000fb_disable_extregs(struct cfb_info *cfb)
else
cfb->func_use_count -= 1;
}
-EXPORT_SYMBOL(cyber2000fb_disable_extregs);
/*
* Attach a capture/tv driver to the core CyberX0X0 driver.
@@ -1135,7 +1133,6 @@ int cyber2000fb_attach(struct cyberpro_info *info, int idx)
return int_cfb_info != NULL;
}
-EXPORT_SYMBOL(cyber2000fb_attach);
/*
* Detach a capture/tv driver from the core CyberX0X0 driver.
@@ -1143,7 +1140,6 @@ EXPORT_SYMBOL(cyber2000fb_attach);
void cyber2000fb_detach(int idx)
{
}
-EXPORT_SYMBOL(cyber2000fb_detach);
#ifdef CONFIG_FB_CYBER2000_DDC
--
2.49.0
^ permalink raw reply related
* [PATCH 01/14] fbdev: Remove trailing whitespaces
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
In-Reply-To: <20250610105948.384540-1-tzimmermann@suse.de>
Fix coding style.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/macmodes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/macmodes.c b/drivers/video/fbdev/macmodes.c
index d6be3c67d3df..cd689161f561 100644
--- a/drivers/video/fbdev/macmodes.c
+++ b/drivers/video/fbdev/macmodes.c
@@ -236,7 +236,7 @@ int mac_vmode_to_var(int vmode, int cmode, struct fb_var_screeninfo *var)
case CMODE_8:
var->bits_per_pixel = 8;
var->red.offset = 0;
- var->red.length = 8;
+ var->red.length = 8;
var->green.offset = 0;
var->green.length = 8;
var->blue.offset = 0;
--
2.49.0
^ permalink raw reply related
* [PATCH 02/14] fbdev: Include <linux/export.h>
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
In-Reply-To: <20250610105948.384540-1-tzimmermann@suse.de>
Fix the compile-time warnings
drivers/video/fbdev/core/cfbcopyarea.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/cfbfillrect.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/cfbimgblt.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fb_ddc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fb_defio.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fb_io_fops.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fb_sys_fops.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fbcmap.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fbcon.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/fbmon.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/modedb.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/svgalib.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/syscopyarea.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/sysfillrect.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/core/sysimgblt.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/macmodes.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/sbuslib.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
drivers/video/fbdev/wmt_ge_rops.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/cfbcopyarea.c | 2 ++
drivers/video/fbdev/core/cfbfillrect.c | 2 ++
drivers/video/fbdev/core/cfbimgblt.c | 2 ++
drivers/video/fbdev/core/fb_ddc.c | 1 +
drivers/video/fbdev/core/fb_defio.c | 1 +
drivers/video/fbdev/core/fb_io_fops.c | 1 +
drivers/video/fbdev/core/fb_sys_fops.c | 2 ++
drivers/video/fbdev/core/fbcmap.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
drivers/video/fbdev/core/fbmon.c | 2 ++
drivers/video/fbdev/core/modedb.c | 1 +
drivers/video/fbdev/core/svgalib.c | 1 +
drivers/video/fbdev/core/syscopyarea.c | 2 ++
drivers/video/fbdev/core/sysfillrect.c | 2 ++
drivers/video/fbdev/core/sysimgblt.c | 2 ++
drivers/video/fbdev/macmodes.c | 1 +
drivers/video/fbdev/sbuslib.c | 1 +
drivers/video/fbdev/wmt_ge_rops.c | 1 +
18 files changed, 26 insertions(+)
diff --git a/drivers/video/fbdev/core/cfbcopyarea.c b/drivers/video/fbdev/core/cfbcopyarea.c
index 23fbf3a8df7c..ce2e6807be60 100644
--- a/drivers/video/fbdev/core/cfbcopyarea.c
+++ b/drivers/video/fbdev/core/cfbcopyarea.c
@@ -2,6 +2,8 @@
/*
* Copyright (C) 2025 Zsolt Kajtar (soci@c64.rulez.org)
*/
+
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/fbdev/core/cfbfillrect.c b/drivers/video/fbdev/core/cfbfillrect.c
index 615de89256d5..bd2fbbda10c6 100644
--- a/drivers/video/fbdev/core/cfbfillrect.c
+++ b/drivers/video/fbdev/core/cfbfillrect.c
@@ -2,6 +2,8 @@
/*
* Copyright (C) 2025 Zsolt Kajtar (soci@c64.rulez.org)
*/
+
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
index bcec4e32c0e7..e116cd1d8a39 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -2,6 +2,8 @@
/*
* Copyright (C) 2025 Zsolt Kajtar (soci@c64.rulez.org)
*/
+
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/fbdev/core/fb_ddc.c b/drivers/video/fbdev/core/fb_ddc.c
index e25143219862..824796361367 100644
--- a/drivers/video/fbdev/core/fb_ddc.c
+++ b/drivers/video/fbdev/core/fb_ddc.c
@@ -10,6 +10,7 @@
#include <linux/delay.h>
#include <linux/device.h>
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/i2c-algo-bit.h>
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index 4fc93f253e06..8df2e51e3390 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
+#include <linux/export.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/vmalloc.h>
diff --git a/drivers/video/fbdev/core/fb_io_fops.c b/drivers/video/fbdev/core/fb_io_fops.c
index 3408ff1b2b7a..6ab60fcd0050 100644
--- a/drivers/video/fbdev/core/fb_io_fops.c
+++ b/drivers/video/fbdev/core/fb_io_fops.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
+#include <linux/export.h>
#include <linux/fb.h>
#include <linux/module.h>
#include <linux/uaccess.h>
diff --git a/drivers/video/fbdev/core/fb_sys_fops.c b/drivers/video/fbdev/core/fb_sys_fops.c
index a9aa6519a5b3..be96b3b3942e 100644
--- a/drivers/video/fbdev/core/fb_sys_fops.c
+++ b/drivers/video/fbdev/core/fb_sys_fops.c
@@ -9,6 +9,8 @@
* for more details.
*
*/
+
+#include <linux/export.h>
#include <linux/fb.h>
#include <linux/module.h>
#include <linux/uaccess.h>
diff --git a/drivers/video/fbdev/core/fbcmap.c b/drivers/video/fbdev/core/fbcmap.c
index ff09e57f3c38..9cc3e87da14b 100644
--- a/drivers/video/fbdev/core/fbcmap.c
+++ b/drivers/video/fbdev/core/fbcmap.c
@@ -11,6 +11,7 @@
* more details.
*/
+#include <linux/export.h>
#include <linux/string.h>
#include <linux/module.h>
#include <linux/fb.h>
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2df48037688d..25684f5d6523 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -56,6 +56,7 @@
* more details.
*/
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/types.h>
#include <linux/fs.h>
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 0a26399dbc89..023caaea682e 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -26,6 +26,8 @@
* for more details.
*
*/
+
+#include <linux/export.h>
#include <linux/fb.h>
#include <linux/module.h>
#include <linux/pci.h>
diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
index 7196b055f2bd..53a610948c4a 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -11,6 +11,7 @@
* more details.
*/
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/fb.h>
diff --git a/drivers/video/fbdev/core/svgalib.c b/drivers/video/fbdev/core/svgalib.c
index 821b89a0a645..d6053af749f6 100644
--- a/drivers/video/fbdev/core/svgalib.c
+++ b/drivers/video/fbdev/core/svgalib.c
@@ -10,6 +10,7 @@
* Some parts are based on David Boucher's viafb (http://davesdomain.org.uk/viafb/)
*/
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/string.h>
diff --git a/drivers/video/fbdev/core/syscopyarea.c b/drivers/video/fbdev/core/syscopyarea.c
index b634e2d21208..773569bce67c 100644
--- a/drivers/video/fbdev/core/syscopyarea.c
+++ b/drivers/video/fbdev/core/syscopyarea.c
@@ -2,6 +2,8 @@
/*
* Copyright (C) 2025 Zsolt Kajtar (soci@c64.rulez.org)
*/
+
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/fbdev/core/sysfillrect.c b/drivers/video/fbdev/core/sysfillrect.c
index 372ca6a324c2..12eea3e424bb 100644
--- a/drivers/video/fbdev/core/sysfillrect.c
+++ b/drivers/video/fbdev/core/sysfillrect.c
@@ -2,6 +2,8 @@
/*
* Copyright (C) 2025 Zsolt Kajtar (soci@c64.rulez.org)
*/
+
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index c756cc658b7d..0a5bfd8ad095 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -2,6 +2,8 @@
/*
* Copyright (C) 2025 Zsolt Kajtar (soci@c64.rulez.org)
*/
+
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/fbdev/macmodes.c b/drivers/video/fbdev/macmodes.c
index cd689161f561..b16a9d9bef98 100644
--- a/drivers/video/fbdev/macmodes.c
+++ b/drivers/video/fbdev/macmodes.c
@@ -16,6 +16,7 @@
*/
#include <linux/errno.h>
+#include <linux/export.h>
#include <linux/fb.h>
#include <linux/string.h>
#include <linux/module.h>
diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
index 4c79654bda30..dd2002d0810f 100644
--- a/drivers/video/fbdev/sbuslib.c
+++ b/drivers/video/fbdev/sbuslib.c
@@ -5,6 +5,7 @@
*/
#include <linux/compat.h>
+#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/string.h>
diff --git a/drivers/video/fbdev/wmt_ge_rops.c b/drivers/video/fbdev/wmt_ge_rops.c
index 92fbb3f3a0d3..2bd26bfb2b46 100644
--- a/drivers/video/fbdev/wmt_ge_rops.c
+++ b/drivers/video/fbdev/wmt_ge_rops.c
@@ -7,6 +7,7 @@
* Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
*/
+#include <linux/export.h>
#include <linux/module.h>
#include <linux/fb.h>
#include <linux/io.h>
--
2.49.0
^ permalink raw reply related
* [PATCH 00/14] fbdev: Fix warnings related to including <linux/export.h>
From: Thomas Zimmermann @ 2025-06-10 10:56 UTC (permalink / raw)
To: deller, soci, simona, jayalk, linux, FlorianSchandinat, alchark,
krzk
Cc: linux-fbdev, dri-devel, linux-arm-kernel, linux-omap,
Thomas Zimmermann
Some source files in fbdev do not include <linux/export.h> properly;
others do when they don't have to. The build scripts warn about these
cases.
Clean up to fix the related warnings. While at it, also fix trailing
whitespaces in the affected files.
Thomas Zimmermann (14):
fbdev: Remove trailing whitespaces
fbdev: Include <linux/export.h>
fbdev/c2p: Include <linux/export.h>
fbdev/cyber2000fb: Unexport symbols
fbdev/matroxfb: Remove trailing whitespaces
fbdev/matroxfb: Include <linux/export.h>
fbdev/omap: Include <linux/export.h>
fbdev/omap2: Include <linux/export.h>
fbdev/omap2: Do not include <linux/export.h>
fbdev/mb862xx: Do not include <linux/export.h>
fbdev/pxafb: Unexport symbol
fbdev/sisfb: Unexport symbols
fbdev/viafb: Include <linux/export.h>
fbdev/viafb: Do not include <linux/export.h>
drivers/video/fbdev/c2p_iplan2.c | 1 +
drivers/video/fbdev/c2p_planar.c | 1 +
drivers/video/fbdev/core/cfbcopyarea.c | 2 +
drivers/video/fbdev/core/cfbfillrect.c | 2 +
drivers/video/fbdev/core/cfbimgblt.c | 2 +
drivers/video/fbdev/core/fb_ddc.c | 1 +
drivers/video/fbdev/core/fb_defio.c | 1 +
drivers/video/fbdev/core/fb_io_fops.c | 1 +
drivers/video/fbdev/core/fb_sys_fops.c | 2 +
drivers/video/fbdev/core/fbcmap.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
drivers/video/fbdev/core/fbmon.c | 2 +
drivers/video/fbdev/core/modedb.c | 1 +
drivers/video/fbdev/core/svgalib.c | 1 +
drivers/video/fbdev/core/syscopyarea.c | 2 +
drivers/video/fbdev/core/sysfillrect.c | 2 +
drivers/video/fbdev/core/sysimgblt.c | 2 +
drivers/video/fbdev/cyber2000fb.c | 4 --
drivers/video/fbdev/macmodes.c | 3 +-
drivers/video/fbdev/matrox/g450_pll.c | 26 ++++----
drivers/video/fbdev/matrox/matroxfb_DAC1064.c | 47 +++++++-------
drivers/video/fbdev/matrox/matroxfb_Ti3026.c | 1 +
drivers/video/fbdev/matrox/matroxfb_accel.c | 2 +
drivers/video/fbdev/matrox/matroxfb_base.c | 1 +
drivers/video/fbdev/matrox/matroxfb_g450.c | 62 ++++++++++---------
drivers/video/fbdev/matrox/matroxfb_misc.c | 21 ++++---
drivers/video/fbdev/mb862xx/mb862xx-i2c.c | 1 -
drivers/video/fbdev/omap/lcd_dma.c | 1 +
drivers/video/fbdev/omap/lcdc.c | 2 +
drivers/video/fbdev/omap/omapfb_main.c | 2 +
drivers/video/fbdev/omap2/omapfb/dss/apply.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/core.c | 1 +
.../fbdev/omap2/omapfb/dss/dispc-compat.c | 1 +
.../video/fbdev/omap2/omapfb/dss/display.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/dpi.c | 1 -
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 1 +
.../fbdev/omap2/omapfb/dss/dss_features.c | 1 +
.../video/fbdev/omap2/omapfb/dss/manager.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/output.c | 1 +
.../video/fbdev/omap2/omapfb/dss/overlay.c | 1 +
drivers/video/fbdev/omap2/omapfb/dss/sdi.c | 1 -
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 1 +
.../video/fbdev/omap2/omapfb/omapfb-ioctl.c | 1 -
drivers/video/fbdev/omap2/omapfb/vrfb.c | 1 +
drivers/video/fbdev/pxafb.c | 1 -
drivers/video/fbdev/sbuslib.c | 1 +
drivers/video/fbdev/sis/sis_main.c | 9 ---
drivers/video/fbdev/via/via-core.c | 1 +
drivers/video/fbdev/via/via-gpio.c | 1 -
drivers/video/fbdev/via/via_i2c.c | 1 +
drivers/video/fbdev/wmt_ge_rops.c | 1 +
51 files changed, 132 insertions(+), 95 deletions(-)
--
2.49.0
^ permalink raw reply
* Re: [PATCH] fbtft: reduce stack usage
From: Andy Shevchenko @ 2025-06-10 10:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Greg Kroah-Hartman, Riyan Dhiman,
Thomas Zimmermann, Paolo Perego, Lorenzo Stoakes, Matthew Wilcox,
Jeff Johnson, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <088dc0a1-fc54-478c-b253-4ed5dd6d6bae@app.fastmail.com>
On Tue, Jun 10, 2025 at 12:35:14PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 10, 2025, at 12:26, Andy Shevchenko wrote:
> > On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
...
> >> +static noinline_for_stack void fbtft_write_register_64(struct fbtft_par *par,
> >> + int i, int buf[64])
> >
> > Perhaps int i, int buf[64] should be u32?
>
> Right, I can send an updated patch, or this could be fixed up when applying
> the patch
Greg doesn't do that (or won't do anyway), so either a followup or a v2.
...
> > Wondering if we may reuse this in other cases (by providing the additional
> > length parameter). But it may be done later on.
>
> I tried this and that quickly became a mess. It is probably a good
> idea to rework the code to completely avoid the varargs function
> pointer and instead take an array here, but this is not something
> I could easily do myself as that takes more time and needs better
> testing.
Right and this driver in any case in a frozen position, so it might never
happen, though.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] fbtft: reduce stack usage
From: Arnd Bergmann @ 2025-06-10 10:35 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Greg Kroah-Hartman, Riyan Dhiman, Thomas Zimmermann, Paolo Perego,
Lorenzo Stoakes, Matthew Wilcox, Jeff Johnson, dri-devel,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <aEgIX221QIt5k0zY@smile.fi.intel.com>
On Tue, Jun 10, 2025, at 12:26, Andy Shevchenko wrote:
> On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
>> Move the varargs handling into a separate noinline function so each
>> individual function stays below the limit. A better approach might be to
>> replace the varargs function with one that takes an array of arguments,
>> but that would be a much larger rework of the other callers.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> ...
Thanks
>> +static noinline_for_stack void fbtft_write_register_64(struct fbtft_par *par,
>> + int i, int buf[64])
>
> Perhaps int i, int buf[64] should be u32?
Right, I can send an updated patch, or this could be fixed up when applying
the patch
>> +{
>> + par->fbtftops.write_register(par, i,
>> + buf[0], buf[1], buf[2], buf[3],
>> + buf[4], buf[5], buf[6], buf[7],
>> + buf[8], buf[9], buf[10], buf[11],
>> + buf[12], buf[13], buf[14], buf[15],
>> + buf[16], buf[17], buf[18], buf[19],
>> + buf[20], buf[21], buf[22], buf[23],
>> + buf[24], buf[25], buf[26], buf[27],
>> + buf[28], buf[29], buf[30], buf[31],
>> + buf[32], buf[33], buf[34], buf[35],
>> + buf[36], buf[37], buf[38], buf[39],
>> + buf[40], buf[41], buf[42], buf[43],
>> + buf[44], buf[45], buf[46], buf[47],
>> + buf[48], buf[49], buf[50], buf[51],
>> + buf[52], buf[53], buf[54], buf[55],
>> + buf[56], buf[57], buf[58], buf[59],
>> + buf[60], buf[61], buf[62], buf[63]);
>> +}
>
> Wondering if we may reuse this in other cases (by providing the additional
> length parameter). But it may be done later on.
I tried this and that quickly became a mess. It is probably a good
idea to rework the code to completely avoid the varargs function
pointer and instead take an array here, but this is not something
I could easily do myself as that takes more time and needs better
testing.
Arnd
^ permalink raw reply
* Re: [PATCH] fbtft: reduce stack usage
From: Andy Shevchenko @ 2025-06-10 10:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Arnd Bergmann, Riyan Dhiman,
Thomas Zimmermann, Paolo Perego, Lorenzo Stoakes,
Matthew Wilcox (Oracle), Jeff Johnson, dri-devel, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <20250610092445.2640575-1-arnd@kernel.org>
On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The use of vararg function pointers combined with a huge number of
> arguments causes some configurations to exceed the stack size warning
> limit:
>
> drivers/staging/fbtft/fbtft-core.c:863:12: error: stack frame size (1512) exceeds limit (1280) in 'fbtft_init_display_from_property' [-Werror,-Wframe-larger-than]
>
> drivers/staging/fbtft/fb_ssd1331.c:131:30: error: stack frame size (1392) exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
> ^
> drivers/staging/fbtft/fb_ssd1351.c:120:30: error: stack frame size (1392) exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
>
> Move the varargs handling into a separate noinline function so each
> individual function stays below the limit. A better approach might be to
> replace the varargs function with one that takes an array of arguments,
> but that would be a much larger rework of the other callers.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
...
> +static noinline_for_stack void fbtft_write_register_64(struct fbtft_par *par,
> + int i, int buf[64])
Perhaps int i, int buf[64] should be u32?
> +{
> + par->fbtftops.write_register(par, i,
> + buf[0], buf[1], buf[2], buf[3],
> + buf[4], buf[5], buf[6], buf[7],
> + buf[8], buf[9], buf[10], buf[11],
> + buf[12], buf[13], buf[14], buf[15],
> + buf[16], buf[17], buf[18], buf[19],
> + buf[20], buf[21], buf[22], buf[23],
> + buf[24], buf[25], buf[26], buf[27],
> + buf[28], buf[29], buf[30], buf[31],
> + buf[32], buf[33], buf[34], buf[35],
> + buf[36], buf[37], buf[38], buf[39],
> + buf[40], buf[41], buf[42], buf[43],
> + buf[44], buf[45], buf[46], buf[47],
> + buf[48], buf[49], buf[50], buf[51],
> + buf[52], buf[53], buf[54], buf[55],
> + buf[56], buf[57], buf[58], buf[59],
> + buf[60], buf[61], buf[62], buf[63]);
> +}
Wondering if we may reuse this in other cases (by providing the additional
length parameter). But it may be done later on.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] fbtft: reduce stack usage
From: Arnd Bergmann @ 2025-06-10 9:24 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman
Cc: Arnd Bergmann, Riyan Dhiman, Thomas Zimmermann, Paolo Perego,
Lorenzo Stoakes, Matthew Wilcox (Oracle), Jeff Johnson, dri-devel,
linux-fbdev, linux-staging, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The use of vararg function pointers combined with a huge number of
arguments causes some configurations to exceed the stack size warning
limit:
drivers/staging/fbtft/fbtft-core.c:863:12: error: stack frame size (1512) exceeds limit (1280) in 'fbtft_init_display_from_property' [-Werror,-Wframe-larger-than]
drivers/staging/fbtft/fb_ssd1331.c:131:30: error: stack frame size (1392) exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
^
drivers/staging/fbtft/fb_ssd1351.c:120:30: error: stack frame size (1392) exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
Move the varargs handling into a separate noinline function so each
individual function stays below the limit. A better approach might be to
replace the varargs function with one that takes an array of arguments,
but that would be a much larger rework of the other callers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/fbtft/fb_ssd1331.c | 36 ++++++++++++------
drivers/staging/fbtft/fb_ssd1351.c | 42 ++++++++++++---------
drivers/staging/fbtft/fbtft-core.c | 59 +++++++++++++-----------------
3 files changed, 73 insertions(+), 64 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/staging/fbtft/fb_ssd1331.c
index 06b7056d6c71..f43ee3249175 100644
--- a/drivers/staging/fbtft/fb_ssd1331.c
+++ b/drivers/staging/fbtft/fb_ssd1331.c
@@ -107,6 +107,28 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
va_end(args);
}
+static noinline_for_stack void write_gamma_reg(struct fbtft_par *par,
+ u32 gamma[63])
+{
+ write_reg(par, 0xB8,
+ gamma[0], gamma[1], gamma[2], gamma[3],
+ gamma[4], gamma[5], gamma[6], gamma[7],
+ gamma[8], gamma[9], gamma[10], gamma[11],
+ gamma[12], gamma[13], gamma[14], gamma[15],
+ gamma[16], gamma[17], gamma[18], gamma[19],
+ gamma[20], gamma[21], gamma[22], gamma[23],
+ gamma[24], gamma[25], gamma[26], gamma[27],
+ gamma[28], gamma[29], gamma[30], gamma[31],
+ gamma[32], gamma[33], gamma[34], gamma[35],
+ gamma[36], gamma[37], gamma[38], gamma[39],
+ gamma[40], gamma[41], gamma[42], gamma[43],
+ gamma[44], gamma[45], gamma[46], gamma[47],
+ gamma[48], gamma[49], gamma[50], gamma[51],
+ gamma[52], gamma[53], gamma[54], gamma[55],
+ gamma[56], gamma[57], gamma[58], gamma[59],
+ gamma[60], gamma[61], gamma[62]);
+}
+
/*
* Grayscale Lookup Table
* GS1 - GS63
@@ -130,7 +152,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
*/
static int set_gamma(struct fbtft_par *par, u32 *curves)
{
- unsigned long tmp[GAMMA_NUM * GAMMA_LEN];
+ u32 tmp[GAMMA_NUM * GAMMA_LEN];
int i, acc = 0;
for (i = 0; i < 63; i++) {
@@ -150,17 +172,7 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
}
}
- write_reg(par, 0xB8,
- tmp[0], tmp[1], tmp[2], tmp[3], tmp[4], tmp[5], tmp[6],
- tmp[7], tmp[8], tmp[9], tmp[10], tmp[11], tmp[12], tmp[13],
- tmp[14], tmp[15], tmp[16], tmp[17], tmp[18], tmp[19], tmp[20],
- tmp[21], tmp[22], tmp[23], tmp[24], tmp[25], tmp[26], tmp[27],
- tmp[28], tmp[29], tmp[30], tmp[31], tmp[32], tmp[33], tmp[34],
- tmp[35], tmp[36], tmp[37], tmp[38], tmp[39], tmp[40], tmp[41],
- tmp[42], tmp[43], tmp[44], tmp[45], tmp[46], tmp[47], tmp[48],
- tmp[49], tmp[50], tmp[51], tmp[52], tmp[53], tmp[54], tmp[55],
- tmp[56], tmp[57], tmp[58], tmp[59], tmp[60], tmp[61],
- tmp[62]);
+ write_gamma_reg(par, tmp);
return 0;
}
diff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/staging/fbtft/fb_ssd1351.c
index 6736b09b2f45..eb8bee6993c3 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -96,6 +96,28 @@ static int set_var(struct fbtft_par *par)
return 0;
}
+static noinline_for_stack void write_gamma_reg(struct fbtft_par *par,
+ u32 gamma[63])
+{
+ write_reg(par, 0xB8,
+ gamma[0], gamma[1], gamma[2], gamma[3],
+ gamma[4], gamma[5], gamma[6], gamma[7],
+ gamma[8], gamma[9], gamma[10], gamma[11],
+ gamma[12], gamma[13], gamma[14], gamma[15],
+ gamma[16], gamma[17], gamma[18], gamma[19],
+ gamma[20], gamma[21], gamma[22], gamma[23],
+ gamma[24], gamma[25], gamma[26], gamma[27],
+ gamma[28], gamma[29], gamma[30], gamma[31],
+ gamma[32], gamma[33], gamma[34], gamma[35],
+ gamma[36], gamma[37], gamma[38], gamma[39],
+ gamma[40], gamma[41], gamma[42], gamma[43],
+ gamma[44], gamma[45], gamma[46], gamma[47],
+ gamma[48], gamma[49], gamma[50], gamma[51],
+ gamma[52], gamma[53], gamma[54], gamma[55],
+ gamma[56], gamma[57], gamma[58], gamma[59],
+ gamma[60], gamma[61], gamma[62]);
+}
+
/*
* Grayscale Lookup Table
* GS1 - GS63
@@ -119,7 +141,7 @@ static int set_var(struct fbtft_par *par)
*/
static int set_gamma(struct fbtft_par *par, u32 *curves)
{
- unsigned long tmp[GAMMA_NUM * GAMMA_LEN];
+ u32 tmp[GAMMA_NUM * GAMMA_LEN];
int i, acc = 0;
for (i = 0; i < 63; i++) {
@@ -139,23 +161,7 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
}
}
- write_reg(par, 0xB8,
- tmp[0], tmp[1], tmp[2], tmp[3],
- tmp[4], tmp[5], tmp[6], tmp[7],
- tmp[8], tmp[9], tmp[10], tmp[11],
- tmp[12], tmp[13], tmp[14], tmp[15],
- tmp[16], tmp[17], tmp[18], tmp[19],
- tmp[20], tmp[21], tmp[22], tmp[23],
- tmp[24], tmp[25], tmp[26], tmp[27],
- tmp[28], tmp[29], tmp[30], tmp[31],
- tmp[32], tmp[33], tmp[34], tmp[35],
- tmp[36], tmp[37], tmp[38], tmp[39],
- tmp[40], tmp[41], tmp[42], tmp[43],
- tmp[44], tmp[45], tmp[46], tmp[47],
- tmp[48], tmp[49], tmp[50], tmp[51],
- tmp[52], tmp[53], tmp[54], tmp[55],
- tmp[56], tmp[57], tmp[58], tmp[59],
- tmp[60], tmp[61], tmp[62]);
+ write_gamma_reg(par, tmp);
return 0;
}
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index da9c64152a60..86c77f996f5b 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -833,6 +833,28 @@ int fbtft_unregister_framebuffer(struct fb_info *fb_info)
}
EXPORT_SYMBOL(fbtft_unregister_framebuffer);
+static noinline_for_stack void fbtft_write_register_64(struct fbtft_par *par,
+ int i, int buf[64])
+{
+ par->fbtftops.write_register(par, i,
+ buf[0], buf[1], buf[2], buf[3],
+ buf[4], buf[5], buf[6], buf[7],
+ buf[8], buf[9], buf[10], buf[11],
+ buf[12], buf[13], buf[14], buf[15],
+ buf[16], buf[17], buf[18], buf[19],
+ buf[20], buf[21], buf[22], buf[23],
+ buf[24], buf[25], buf[26], buf[27],
+ buf[28], buf[29], buf[30], buf[31],
+ buf[32], buf[33], buf[34], buf[35],
+ buf[36], buf[37], buf[38], buf[39],
+ buf[40], buf[41], buf[42], buf[43],
+ buf[44], buf[45], buf[46], buf[47],
+ buf[48], buf[49], buf[50], buf[51],
+ buf[52], buf[53], buf[54], buf[55],
+ buf[56], buf[57], buf[58], buf[59],
+ buf[60], buf[61], buf[62], buf[63]);
+}
+
/**
* fbtft_init_display_from_property() - Device Tree init_display() function
* @par: Driver data
@@ -887,23 +909,8 @@ static int fbtft_init_display_from_property(struct fbtft_par *par)
fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
"buf[%d] = %02X\n", j, buf[j]);
- par->fbtftops.write_register(par, i,
- buf[0], buf[1], buf[2], buf[3],
- buf[4], buf[5], buf[6], buf[7],
- buf[8], buf[9], buf[10], buf[11],
- buf[12], buf[13], buf[14], buf[15],
- buf[16], buf[17], buf[18], buf[19],
- buf[20], buf[21], buf[22], buf[23],
- buf[24], buf[25], buf[26], buf[27],
- buf[28], buf[29], buf[30], buf[31],
- buf[32], buf[33], buf[34], buf[35],
- buf[36], buf[37], buf[38], buf[39],
- buf[40], buf[41], buf[42], buf[43],
- buf[44], buf[45], buf[46], buf[47],
- buf[48], buf[49], buf[50], buf[51],
- buf[52], buf[53], buf[54], buf[55],
- buf[56], buf[57], buf[58], buf[59],
- buf[60], buf[61], buf[62], buf[63]);
+ fbtft_write_register_64(par, i, buf);
+
} else if (val & FBTFT_OF_INIT_DELAY) {
fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
"init: msleep(%u)\n", val & 0xFFFF);
@@ -996,23 +1003,7 @@ int fbtft_init_display(struct fbtft_par *par)
}
buf[j++] = par->init_sequence[i++];
}
- par->fbtftops.write_register(par, j,
- buf[0], buf[1], buf[2], buf[3],
- buf[4], buf[5], buf[6], buf[7],
- buf[8], buf[9], buf[10], buf[11],
- buf[12], buf[13], buf[14], buf[15],
- buf[16], buf[17], buf[18], buf[19],
- buf[20], buf[21], buf[22], buf[23],
- buf[24], buf[25], buf[26], buf[27],
- buf[28], buf[29], buf[30], buf[31],
- buf[32], buf[33], buf[34], buf[35],
- buf[36], buf[37], buf[38], buf[39],
- buf[40], buf[41], buf[42], buf[43],
- buf[44], buf[45], buf[46], buf[47],
- buf[48], buf[49], buf[50], buf[51],
- buf[52], buf[53], buf[54], buf[55],
- buf[56], buf[57], buf[58], buf[59],
- buf[60], buf[61], buf[62], buf[63]);
+ fbtft_write_register_64(par, j, buf);
break;
case -2:
i++;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] fbdev: pm3fb: Fix potential divide by zero
From: Geert Uytterhoeven @ 2025-06-10 7:42 UTC (permalink / raw)
To: Alex Guo; +Cc: deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250607194959.2457473-1-alexguo1023@gmail.com>
Hi Alex,
On Sat, 7 Jun 2025 at 22:14, Alex Guo <alexguo1023@gmail.com> wrote:
> variable var->pixclock can be set by user. In case it equals to
> zero, divide by zero would occur in pm3fb_check_var. Similar
> crashes have happened in other fbdev drivers. There is no check
> and modification on var->pixclock along the call chain to
> pm3fb_check_var. So we fix this by checking whether 'pixclock'
> is zero.
>
> Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
> Error out if 'pixclock' equals zero")
>
> Signed-off-by: Alex Guo <alexguo1023@gmail.com>
Thanks for your patch, which is now commit 59d1fc7b3e1ae9d4
("fbdev: pm3fb: fix potential divide by zero") in fbdev/for-next.
> --- a/drivers/video/fbdev/pm3fb.c
> +++ b/drivers/video/fbdev/pm3fb.c
> @@ -998,6 +998,9 @@ static int pm3fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
> return -EINVAL;
> }
>
> + if (!var->pixclock)
> + return -EINVAL;
While this fixes the crash, this is correct behavior for an fbdev driver.
When a value is invalid, it should be rounded up to a valid value instead,
if possible.
> +
> if (PICOS2KHZ(var->pixclock) > PM3_MAX_PIXCLOCK) {
> DPRINTK("pixclock too high (%ldKHz)\n",
> PICOS2KHZ(var->pixclock));
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fbdev: pm3fb: Fix potential divide by zero
From: Helge Deller @ 2025-06-08 13:12 UTC (permalink / raw)
To: Alex Guo; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250607194959.2457473-1-alexguo1023@gmail.com>
On 6/7/25 21:49, Alex Guo wrote:
> variable var->pixclock can be set by user. In case it equals to
> zero, divide by zero would occur in pm3fb_check_var. Similar
> crashes have happened in other fbdev drivers. There is no check
> and modification on var->pixclock along the call chain to
> pm3fb_check_var. So we fix this by checking whether 'pixclock'
> is zero.
>
> Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
> Error out if 'pixclock' equals zero")
>
> Signed-off-by: Alex Guo <alexguo1023@gmail.com>
> ---
> drivers/video/fbdev/pm3fb.c | 3 +++
> 1 file changed, 3 insertions(+)
applied.
Thanks!
Helge
^ permalink raw reply
* [PATCH] fbdev: pm3fb: Fix potential divide by zero
From: Alex Guo @ 2025-06-07 19:49 UTC (permalink / raw)
To: deller; +Cc: linux-fbdev, dri-devel, linux-kernel, Alex Guo
variable var->pixclock can be set by user. In case it equals to
zero, divide by zero would occur in pm3fb_check_var. Similar
crashes have happened in other fbdev drivers. There is no check
and modification on var->pixclock along the call chain to
pm3fb_check_var. So we fix this by checking whether 'pixclock'
is zero.
Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
Error out if 'pixclock' equals zero")
Signed-off-by: Alex Guo <alexguo1023@gmail.com>
---
drivers/video/fbdev/pm3fb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/pm3fb.c b/drivers/video/fbdev/pm3fb.c
index 6e55e42514d6..d9b3f1937ce6 100644
--- a/drivers/video/fbdev/pm3fb.c
+++ b/drivers/video/fbdev/pm3fb.c
@@ -998,6 +998,9 @@ static int pm3fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
return -EINVAL;
}
+ if (!var->pixclock)
+ return -EINVAL;
+
if (PICOS2KHZ(var->pixclock) > PM3_MAX_PIXCLOCK) {
DPRINTK("pixclock too high (%ldKHz)\n",
PICOS2KHZ(var->pixclock));
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] nvidiafb: fix build on 32-bit ARCH=um
From: Helge Deller @ 2025-06-06 19:24 UTC (permalink / raw)
To: Johannes Berg, linux-kernel, linux-fbdev
Cc: dri-devel, Antonino Daplas, Johannes Berg, Arnd Bergmann
In-Reply-To: <20250606090218.15826-2-johannes@sipsolutions.net>
On 6/6/25 11:02, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Now that ARCH=um no longer has IO port accesses, this driver
> can no longer build as-is. Make the IO port calls not just
> conditional on i386 but also !UML.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> drivers/video/fbdev/nvidia/nv_local.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* [PATCH] nvidiafb: fix build on 32-bit ARCH=um
From: Johannes Berg @ 2025-06-06 9:02 UTC (permalink / raw)
To: linux-kernel, linux-fbdev
Cc: dri-devel, Antonino Daplas, Helge Deller, Johannes Berg,
Arnd Bergmann
From: Johannes Berg <johannes.berg@intel.com>
Now that ARCH=um no longer has IO port accesses, this driver
can no longer build as-is. Make the IO port calls not just
conditional on i386 but also !UML.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/video/fbdev/nvidia/nv_local.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/nvidia/nv_local.h b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508daa417..93aff35305a9 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -80,7 +80,7 @@
(par)->dmaFree -= ((size) + 1); \
}
-#if defined(__i386__)
+#if defined(__i386__) && !defined(CONFIG_UML)
#define _NV_FENCE() outb(0, 0x3D0);
#else
#define _NV_FENCE() mb();
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Thomas Zimmermann @ 2025-06-06 7:05 UTC (permalink / raw)
To: Michael Kelley, Simona Vetter
Cc: David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
hch@lst.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <SN6PR02MB4157F630284939E084486AFED46FA@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi
Am 05.06.25 um 19:38 schrieb Michael Kelley:
[...]
>> I try to address the problem with the patches at
>>
>> https://lore.kernel.org/dri-devel/20250605152637.98493-1-tzimmermann@suse.de/
>>
>> Testing and feedback is much appreciated.
>>
> Nice!
>
> I ran the same test case with your patches, and everything works well. The
> hyperv_drm numbers are now pretty much the same as the hyperv_fb
> numbers for both elapsed time and system CPU time -- within a few percent.
> For hyperv_drm, there's no longer a gap in the elapsed time and system
> CPU time. No errors due to the guest-to-host ring buffer being full. Total
> messages to Hyper-V for hyperv_drm are now a few hundred instead of 3M.
Sounds great. Credit also goes to the vkms devs, which already have the
software vblank in their driver.
This might need better support for cases where display updates take
exceptionally long, but I can see this being merged as a DRM feature.
> The hyperv_drm message count is still a little higher than for hyperv_fb,
> presumably because the simulated vblank rate in hyperv_drm is higher than
> the 20 Hz rate used by hyperv_fb deferred I/O. But the overall numbers are
> small enough that the difference is in the noise. Question: what is the default
> value for the simulated vblank rate? Just curious ...
As with a hardware interrupt, the vblank rate comes from the programmed
display mode, so most likely 60 Hz. The difference in the update
frequency could explain the remaining differences to hyperv_fb.
Best regards
Thomas
>
> Michael
--
--
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
* RE: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Michael Kelley @ 2025-06-05 17:38 UTC (permalink / raw)
To: Thomas Zimmermann, Simona Vetter
Cc: David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
hch@lst.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <154aa365-0e27-458c-b801-62fd1cbfa169@suse.de>
From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Thursday, June 5, 2025 8:36 AM
>
> Hi
>
> Am 04.06.25 um 23:43 schrieb Michael Kelley:
> [...]
> > Nonetheless, there's an underlying issue. A main cause of the difference
> > is the number of messages to Hyper-V to update dirty regions. With
> > hyperv_fb using deferred I/O, the messages are limited 20/second, so
> > the total number of messages to Hyper-V is about 480. But hyperv_drm
> > appears to send 3 messages to Hyper-V for each line of output, or a total of
> > about 3,000,000 messages (~90K/second). That's a lot of additional load
> > on the Hyper-V host, and it adds the 10 seconds of additional elapsed
> > time seen in the guest. There also this ugly output in dmesg because the
> > ring buffer for sending messages to the Hyper-V host gets full -- Hyper-V
> > doesn't always keep up, at least not on my local laptop where I'm
> > testing:
> >
> > [12574.327615] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12574.327684] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12574.327760] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12574.327841] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12597.016128] hyperv_sendpacket: 6211 callbacks suppressed
> > [12597.016133] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12597.016172] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12597.016220] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> > [12597.016267] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm]
> *ERROR* Unable to send packet via vmbus; error -11
> >
> > hyperv_drm could be fixed to not output the ugly messages, but there's
> > still the underlying issue of overrunning the ring buffer, and excessively
> > hammering on the host. If we could get hyperv_drm doing deferred I/O, I
> > would feel much better about going full-on with deprecating hyperv_fb.
>
> I try to address the problem with the patches at
>
> https://lore.kernel.org/dri-devel/20250605152637.98493-1-tzimmermann@suse.de/
>
> Testing and feedback is much appreciated.
>
Nice!
I ran the same test case with your patches, and everything works well. The
hyperv_drm numbers are now pretty much the same as the hyperv_fb
numbers for both elapsed time and system CPU time -- within a few percent.
For hyperv_drm, there's no longer a gap in the elapsed time and system
CPU time. No errors due to the guest-to-host ring buffer being full. Total
messages to Hyper-V for hyperv_drm are now a few hundred instead of 3M.
The hyperv_drm message count is still a little higher than for hyperv_fb,
presumably because the simulated vblank rate in hyperv_drm is higher than
the 20 Hz rate used by hyperv_fb deferred I/O. But the overall numbers are
small enough that the difference is in the noise. Question: what is the default
value for the simulated vblank rate? Just curious ...
Michael
^ permalink raw reply
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Thomas Zimmermann @ 2025-06-05 15:35 UTC (permalink / raw)
To: Michael Kelley, Simona Vetter
Cc: David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
hch@lst.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi
Am 04.06.25 um 23:43 schrieb Michael Kelley:
[...]
> Nonetheless, there's an underlying issue. A main cause of the difference
> is the number of messages to Hyper-V to update dirty regions. With
> hyperv_fb using deferred I/O, the messages are limited 20/second, so
> the total number of messages to Hyper-V is about 480. But hyperv_drm
> appears to send 3 messages to Hyper-V for each line of output, or a total of
> about 3,000,000 messages (~90K/second). That's a lot of additional load
> on the Hyper-V host, and it adds the 10 seconds of additional elapsed
> time seen in the guest. There also this ugly output in dmesg because the
> ring buffer for sending messages to the Hyper-V host gets full -- Hyper-V
> doesn't always keep up, at least not on my local laptop where I'm
> testing:
>
> [12574.327615] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12574.327684] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12574.327760] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12574.327841] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016128] hyperv_sendpacket: 6211 callbacks suppressed
> [12597.016133] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016172] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016220] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016267] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
>
> hyperv_drm could be fixed to not output the ugly messages, but there's
> still the underlying issue of overrunning the ring buffer, and excessively
> hammering on the host. If we could get hyperv_drm doing deferred I/O, I
> would feel much better about going full-on with deprecating hyperv_fb.
I try to address the problem with the patches at
https://lore.kernel.org/dri-devel/20250605152637.98493-1-tzimmermann@suse.de/
Testing and feedback is much appreciated.
Best regards
Thomas
>
> Michael
>
--
--
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
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: David Hildenbrand @ 2025-06-05 8:10 UTC (permalink / raw)
To: Michael Kelley, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org
Cc: weh@microsoft.com, tzimmermann@suse.de, hch@lst.de,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-mm@kvack.org
In-Reply-To: <SN6PR02MB41574078A6785C3E2E1A6391D46CA@SN6PR02MB4157.namprd02.prod.outlook.com>
On 04.06.25 23:58, Michael Kelley wrote:
> From: Michael Kelley <mhklinux@outlook.com> Sent: Tuesday, June 3, 2025 10:25 AM
>>
>> From: David Hildenbrand <david@redhat.com> Sent: Tuesday, June 3, 2025 12:55 AM
>>>
>>> On 03.06.25 03:49, Michael Kelley wrote:
>>>> From: David Hildenbrand <david@redhat.com> Sent: Monday, June 2, 2025 2:48 AM
>>>>>
>
> [snip]
>
>>>>>> @@ -182,20 +221,34 @@ 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 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.
>>>>>> + * The PTE must be marked writable before the defio deferred work runs
>>>>>> + * again and potentially marks the PTE write-protected. If the order
>>>>>> + * should be switched, the PTE would become writable without defio
>>>>>> + * tracking the page, leaving the page forever ignored by defio.
>>>>>> + *
>>>>>> + * For vmalloc() framebuffers, the associated struct page is locked
>>>>>> + * before releasing the defio lock. mm will later mark the PTE writaable
>>>>>> + * and release the struct page lock. The struct page lock prevents
>>>>>> + * the page from being prematurely being marked write-protected.
>>>>>> + *
>>>>>> + * For FBINFO_KMEMFB framebuffers, mm assumes there is no struct page,
>>>>>> + * so the PTE must be marked writable while the defio lock is held.
>>>>>> */
>>>>>> - lock_page(pageref->page);
>>>>>> + if (info->flags & FBINFO_KMEMFB) {
>>>>>> + unsigned long pfn = page_to_pfn(pageref->page);
>>>>>> +
>>>>>> + ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address,
>>>>>> + __pfn_to_pfn_t(pfn, PFN_SPECIAL));
>>>>>
>>>>> Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a
>>>>> horrible hack.
>>>>>
>>>>> In another thread, you mention that you use PFN_SPECIAL to bypass the
>>>>> check in vm_mixed_ok(), so VM_MIXEDMAP is likely not set?
>>>>
>>>> The VMA has VM_PFNMAP set, not VM_MIXEDMAP. It seemed like
>>>> VM_MIXEDMAP is somewhat of a superset of VM_PFNMAP, but maybe that's
>>>> a wrong impression.
>>>
>>> VM_PFNMAP: nothing is refcounted except anon pages
>>>
>>> VM_MIXEDMAP: anything with a "struct page" (pfn_valid()) is refcounted
>>>
>>> pte_special() is a way for GUP-fast to distinguish these refcounted (can
>>> GUP) from non-refcounted (camnnot GUP) pages mapped by PTEs without any
>>> locks or the VMA being available.
>>>
>>> Setting pte_special() in VM_MIXEDMAP on ptes that have a "struct page"
>>> (pfn_valid()) is likely very bogus.
>>
>> OK, good to know.
>>
>>>
>>>> vm_mixed_ok() does a thorough job of validating the
>>>> use of __vm_insert_mixed(), and since what I did was allowed, I thought
>>>> perhaps it was OK. Your feedback has set me straight, and that's what I
>>>> needed. :-)
>>>
>>> What exactly are you trying to achieve? :)
>>>
>>> If it's mapping a page with a "struct page" and *not* refcounting it,
>>> then vmf_insert_pfn() is the current way to achieve that in a VM_PFNMAP
>>> mapping. It will set pte_special() automatically for you.
>>>
>>
>> Yes, that's what I'm using to initially create the special PTE in the
>> .fault callback.
>>
>>>>
>>>> But the whole approach is moot with Alistair Popple's patch set that
>>>> eliminates pfn_t. Is there an existing mm API that will do mkwrite on a
>>>> special PTE in a VM_PFNMAP VMA? I didn't see one, but maybe I missed
>>>> it. If there's not one, I'll take a crack at adding it in the next version of my
>>>> patch set.
>>>
>>> I assume you'd want vmf_insert_pfn_mkwrite(), correct? Probably
>>> vmf_insert_pfn_prot() can be used by adding PAGE_WRITE to pgprot. (maybe
>>> :) )
>>
>> Ok, I'll look at that more closely. The sequence is that the special
>> PTE gets created with vmf_insert_pfn(). Then when the page is first
>> written to, the .pfn_mkwrite callback is invoked by mm. The question
>> is the best way for that callback to mark the existing PTE as writable.
>>
>
> FWIW, vmf_insert_pfn_prot() won't work. It calls insert_pfn() with
> the "mkwrite" parameter set to 'false', in which case insert_pfn()
> does nothing if the PTE already exists.
Ah, you are worried about the "already exists but is R/O case".
>
> So I would need to create a new API that does appropriate validation
> for a VM_PFNMAP VMA, and then calls insert_pfn() with the "mkwrite"
> parameter set to 'true'.
IMHO, nothing would speak against vmf_insert_pfn_mkwrite().
Much better than using that "mixed" ... beauty of a function.
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Thomas Zimmermann @ 2025-06-05 7:55 UTC (permalink / raw)
To: Michael Kelley, Simona Vetter
Cc: David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
hch@lst.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi
Am 04.06.25 um 23:43 schrieb Michael Kelley:
> From: Simona Vetter <simona.vetter@ffwll.ch> Sent: Wednesday, June 4, 2025 7:46 AM
>> On Wed, Jun 04, 2025 at 10:12:45AM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 03.06.25 um 19:50 schrieb Michael Kelley:
>>>> From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Monday, June 2, 2025 11:25 PM
>>>>> Hi
>>>>>
>>>>> Am 03.06.25 um 03:49 schrieb Michael Kelley:
>>>>> [...]
>>>>> What is the motivation behind this work? The driver or fbdev as a whole
>>>>> does not have much of a future anyway.
>>>>>
>>>>> I'd like to suggest removing hyperv_fb entirely in favor of hypervdrm?
>>>>>
>>>> Yes, I think that's the longer term direction. A couple months ago I had an
>>>> email conversation with Saurabh Sengar from the Microsoft Linux team where
>>>> he raised this idea. I think the Microsoft folks will need to drive the deprecation
>>>> process, as they need to coordinate with the distro vendors who publish
>>>> images for running on local Hyper-V and in the Azure cloud. And my
>>>> understanding is that the Linux kernel process would want the driver to
>>>> be available but marked "deprecated" for a year or so before it actually
>>>> goes away.
>>> We (DRM upstream) recently considered moving some fbdev drivers to
>>> drivers/staging or marking them with !DRM if a DRM driver is available.
>>> Hyverv_fb would be a candidate.
>>>
>>> At least at SUSE, we ship hypervdrm instead of hyperv_fb. This works well on
>>> the various generations of the hyperv system. Much of our userspace would
>>> not be able to use hyperv_fb anyway.
> Good to know. Red Hat has made the switch as well. The Ubuntu images
> in Azure have both hyperv_fb and hyperv_drm. I don't know what other
> distros have done.
>
>> Yeah investing into fbdev drivers, especially when some mm surgery seems
>> needed, does not sound like a good idea to me overall.
>>
>>>> I do have some concerns about the maturity of the hyperv_drm driver
>>>> "around the edges". For example, somebody just recently submitted a
>>>> patch to flush output on panic. I have less familiarity hyperv_drm vs.
>>>> hyperv_fb, so some of my concern is probably due to that. We might
>>>> need to do review of hyperv_drm and see if there's anything else to
>>>> deal with before hyperv_fb goes away.
>>> The panic output is a feature that we recently added to the kernel. It
>>> allows a DRM driver to display a final error message in the case of a kernel
>>> panic (think of blue screens on Windows). Drivers require a minimum of
>>> support to make it work. That's what the hypervdrm patches were about.
>> I'm also happy to help with any other issues and shortfalls of drm vs
>> fbdev. There are some, but I thought it was mostly around some of the low
>> bit color formats that really old devices want, and not anything that
>> hyperv would need.
> You've set me up perfectly to raise an issue. :-) I'm still relatively new
> to the hyperv_drm driver and DRM in general, compared with hyperv_fb.
> One capability in fbdev is deferred I/O, which is what this entire patch
> series is about. The hyperv_drm driver doesn't currently use anything
> similar to deferred I/O like hyperv_fb. I don't know if that's because
> hyperv_drm doesn't make use of what DRM has to offer, or if DRM doesn't
> have a deferred I/O framework like fbdev. Do you know what the situation
> is? Or could you point me to an example of doing deferred I/O with DRM
> that hyperv_drm should be following?
Fbdev deferred I/O is a workaround for the fact that fbdev does not
require a flush operation on its I/O buffers. Writing to an mmaped
buffer is expected to go to hardware immediately. On devices where this
is not the case, deferred I/O tracks written pages and writes them back
to hardware at intervals.
For DRM, there's the MODE_DIRTYFB ioctl [1] that all userspace has to
call after writing to mmap'ed buffers. So regular DRM doesn't need
deferred I/O as userspace triggers writeback explicitly.
[1]
https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_ioctl.c#L686
>
> I ran a quick performance test comparing hyperv_drm with hyperv_fb.
> The test does "cat" of a big text file in the Hyper-V graphics console. The
> file has 1024 * 1024 lines, each with 64 characters, so total file size is
> 64 MiB.
>
> With hyperv_fb the test completes in 24 seconds elapsed time, with
> 24 seconds of system CPU time. With hyperv_drm, it takes 34 seconds
> elapsed time, but with about the same 24 seconds of system CPU time.
> Overall this difference isn't huge, and probably isn't that noticeable
> when doing human-scale work (i.e., 'dmesg' outputting several
> hundred lines in 0.19 seconds vs. my test doing 1M lines) on the Hyper-V
> graphics console. To me, the console doesn't feel slow with hyperv_drm
> compared to hyperv_fb, which is good.
DRM consoles are technically an fbdev device that operates on a DRM
device. Both, DRM and fbdev, have some differences that can make this
problematic. I'm not surprised that there are issues.
>
> Nonetheless, there's an underlying issue. A main cause of the difference
> is the number of messages to Hyper-V to update dirty regions. With
> hyperv_fb using deferred I/O, the messages are limited 20/second, so
> the total number of messages to Hyper-V is about 480. But hyperv_drm
> appears to send 3 messages to Hyper-V for each line of output, or a total of
> about 3,000,000 messages (~90K/second). That's a lot of additional load
> on the Hyper-V host, and it adds the 10 seconds of additional elapsed
> time seen in the guest. There also this ugly output in dmesg because the
> ring buffer for sending messages to the Hyper-V host gets full -- Hyper-V
> doesn't always keep up, at least not on my local laptop where I'm
> testing:
>
> [12574.327615] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12574.327684] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12574.327760] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12574.327841] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016128] hyperv_sendpacket: 6211 callbacks suppressed
> [12597.016133] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016172] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016220] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
> [12597.016267] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
>
> hyperv_drm could be fixed to not output the ugly messages, but there's
> still the underlying issue of overrunning the ring buffer, and excessively
> hammering on the host. If we could get hyperv_drm doing deferred I/O, I
> would feel much better about going full-on with deprecating hyperv_fb.
Thanks for debugging this. A number of things are playing into this.
- DRM performs display output along vblank IRQs. For example, if the
display runs with 60 Hz there should be no more than 60 display updates
per second. From what I can tell, there's no IRQ support in hypervdrm
(or HyperV in general?). Without IRQ support, drivers output to hardware
ASAP, which can result in large numbers of buffer updates per second.
I've heard about this problem in other context [2] and you're likely
seeing a similar issue.
- DRM's console also needs better support for vblank interrupts. It
currently sends out updates ASAP as well.
Both points are not much of a problem on most desktop and server
systems, but can be an be an issue with virtualization.
[2] https://bugzilla.suse.com/show_bug.cgi?id=1189174
Best regards
Thomas
>
> Michael
>
--
--
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
* RE: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Michael Kelley @ 2025-06-04 21:58 UTC (permalink / raw)
To: Michael Kelley, David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org
Cc: weh@microsoft.com, tzimmermann@suse.de, hch@lst.de,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-mm@kvack.org
In-Reply-To: <SN6PR02MB4157A3F9E646C060553E5D90D46DA@SN6PR02MB4157.namprd02.prod.outlook.com>
From: Michael Kelley <mhklinux@outlook.com> Sent: Tuesday, June 3, 2025 10:25 AM
>
> From: David Hildenbrand <david@redhat.com> Sent: Tuesday, June 3, 2025 12:55 AM
> >
> > On 03.06.25 03:49, Michael Kelley wrote:
> > > From: David Hildenbrand <david@redhat.com> Sent: Monday, June 2, 2025 2:48 AM
> > >>
[snip]
> > >>> @@ -182,20 +221,34 @@ 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 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.
> > >>> + * The PTE must be marked writable before the defio deferred work runs
> > >>> + * again and potentially marks the PTE write-protected. If the order
> > >>> + * should be switched, the PTE would become writable without defio
> > >>> + * tracking the page, leaving the page forever ignored by defio.
> > >>> + *
> > >>> + * For vmalloc() framebuffers, the associated struct page is locked
> > >>> + * before releasing the defio lock. mm will later mark the PTE writaable
> > >>> + * and release the struct page lock. The struct page lock prevents
> > >>> + * the page from being prematurely being marked write-protected.
> > >>> + *
> > >>> + * For FBINFO_KMEMFB framebuffers, mm assumes there is no struct page,
> > >>> + * so the PTE must be marked writable while the defio lock is held.
> > >>> */
> > >>> - lock_page(pageref->page);
> > >>> + if (info->flags & FBINFO_KMEMFB) {
> > >>> + unsigned long pfn = page_to_pfn(pageref->page);
> > >>> +
> > >>> + ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address,
> > >>> + __pfn_to_pfn_t(pfn, PFN_SPECIAL));
> > >>
> > >> Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a
> > >> horrible hack.
> > >>
> > >> In another thread, you mention that you use PFN_SPECIAL to bypass the
> > >> check in vm_mixed_ok(), so VM_MIXEDMAP is likely not set?
> > >
> > > The VMA has VM_PFNMAP set, not VM_MIXEDMAP. It seemed like
> > > VM_MIXEDMAP is somewhat of a superset of VM_PFNMAP, but maybe that's
> > > a wrong impression.
> >
> > VM_PFNMAP: nothing is refcounted except anon pages
> >
> > VM_MIXEDMAP: anything with a "struct page" (pfn_valid()) is refcounted
> >
> > pte_special() is a way for GUP-fast to distinguish these refcounted (can
> > GUP) from non-refcounted (camnnot GUP) pages mapped by PTEs without any
> > locks or the VMA being available.
> >
> > Setting pte_special() in VM_MIXEDMAP on ptes that have a "struct page"
> > (pfn_valid()) is likely very bogus.
>
> OK, good to know.
>
> >
> > > vm_mixed_ok() does a thorough job of validating the
> > > use of __vm_insert_mixed(), and since what I did was allowed, I thought
> > > perhaps it was OK. Your feedback has set me straight, and that's what I
> > > needed. :-)
> >
> > What exactly are you trying to achieve? :)
> >
> > If it's mapping a page with a "struct page" and *not* refcounting it,
> > then vmf_insert_pfn() is the current way to achieve that in a VM_PFNMAP
> > mapping. It will set pte_special() automatically for you.
> >
>
> Yes, that's what I'm using to initially create the special PTE in the
> .fault callback.
>
> > >
> > > But the whole approach is moot with Alistair Popple's patch set that
> > > eliminates pfn_t. Is there an existing mm API that will do mkwrite on a
> > > special PTE in a VM_PFNMAP VMA? I didn't see one, but maybe I missed
> > > it. If there's not one, I'll take a crack at adding it in the next version of my
> > > patch set.
> >
> > I assume you'd want vmf_insert_pfn_mkwrite(), correct? Probably
> > vmf_insert_pfn_prot() can be used by adding PAGE_WRITE to pgprot. (maybe
> > :) )
>
> Ok, I'll look at that more closely. The sequence is that the special
> PTE gets created with vmf_insert_pfn(). Then when the page is first
> written to, the .pfn_mkwrite callback is invoked by mm. The question
> is the best way for that callback to mark the existing PTE as writable.
>
FWIW, vmf_insert_pfn_prot() won't work. It calls insert_pfn() with
the "mkwrite" parameter set to 'false', in which case insert_pfn()
does nothing if the PTE already exists.
So I would need to create a new API that does appropriate validation
for a VM_PFNMAP VMA, and then calls insert_pfn() with the "mkwrite"
parameter set to 'true'.
Michael
^ permalink raw reply
* RE: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Michael Kelley @ 2025-06-04 21:43 UTC (permalink / raw)
To: Simona Vetter, Thomas Zimmermann
Cc: David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
hch@lst.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <aEBcCjMWZJgbsRas@phenom.ffwll.local>
From: Simona Vetter <simona.vetter@ffwll.ch> Sent: Wednesday, June 4, 2025 7:46 AM
>
> On Wed, Jun 04, 2025 at 10:12:45AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 03.06.25 um 19:50 schrieb Michael Kelley:
> > > From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Monday, June 2, 2025 11:25 PM
> > > > Hi
> > > >
> > > > Am 03.06.25 um 03:49 schrieb Michael Kelley:
> > > > [...]
> > > > What is the motivation behind this work? The driver or fbdev as a whole
> > > > does not have much of a future anyway.
> > > >
> > > > I'd like to suggest removing hyperv_fb entirely in favor of hypervdrm?
> > > >
> > > Yes, I think that's the longer term direction. A couple months ago I had an
> > > email conversation with Saurabh Sengar from the Microsoft Linux team where
> > > he raised this idea. I think the Microsoft folks will need to drive the deprecation
> > > process, as they need to coordinate with the distro vendors who publish
> > > images for running on local Hyper-V and in the Azure cloud. And my
> > > understanding is that the Linux kernel process would want the driver to
> > > be available but marked "deprecated" for a year or so before it actually
> > > goes away.
> >
> > We (DRM upstream) recently considered moving some fbdev drivers to
> > drivers/staging or marking them with !DRM if a DRM driver is available.
> > Hyverv_fb would be a candidate.
> >
> > At least at SUSE, we ship hypervdrm instead of hyperv_fb. This works well on
> > the various generations of the hyperv system. Much of our userspace would
> > not be able to use hyperv_fb anyway.
Good to know. Red Hat has made the switch as well. The Ubuntu images
in Azure have both hyperv_fb and hyperv_drm. I don't know what other
distros have done.
>
> Yeah investing into fbdev drivers, especially when some mm surgery seems
> needed, does not sound like a good idea to me overall.
>
> > > I do have some concerns about the maturity of the hyperv_drm driver
> > > "around the edges". For example, somebody just recently submitted a
> > > patch to flush output on panic. I have less familiarity hyperv_drm vs.
> > > hyperv_fb, so some of my concern is probably due to that. We might
> > > need to do review of hyperv_drm and see if there's anything else to
> > > deal with before hyperv_fb goes away.
> >
> > The panic output is a feature that we recently added to the kernel. It
> > allows a DRM driver to display a final error message in the case of a kernel
> > panic (think of blue screens on Windows). Drivers require a minimum of
> > support to make it work. That's what the hypervdrm patches were about.
>
> I'm also happy to help with any other issues and shortfalls of drm vs
> fbdev. There are some, but I thought it was mostly around some of the low
> bit color formats that really old devices want, and not anything that
> hyperv would need.
You've set me up perfectly to raise an issue. :-) I'm still relatively new
to the hyperv_drm driver and DRM in general, compared with hyperv_fb.
One capability in fbdev is deferred I/O, which is what this entire patch
series is about. The hyperv_drm driver doesn't currently use anything
similar to deferred I/O like hyperv_fb. I don't know if that's because
hyperv_drm doesn't make use of what DRM has to offer, or if DRM doesn't
have a deferred I/O framework like fbdev. Do you know what the situation
is? Or could you point me to an example of doing deferred I/O with DRM
that hyperv_drm should be following?
I ran a quick performance test comparing hyperv_drm with hyperv_fb.
The test does "cat" of a big text file in the Hyper-V graphics console. The
file has 1024 * 1024 lines, each with 64 characters, so total file size is
64 MiB.
With hyperv_fb the test completes in 24 seconds elapsed time, with
24 seconds of system CPU time. With hyperv_drm, it takes 34 seconds
elapsed time, but with about the same 24 seconds of system CPU time.
Overall this difference isn't huge, and probably isn't that noticeable
when doing human-scale work (i.e., 'dmesg' outputting several
hundred lines in 0.19 seconds vs. my test doing 1M lines) on the Hyper-V
graphics console. To me, the console doesn't feel slow with hyperv_drm
compared to hyperv_fb, which is good.
Nonetheless, there's an underlying issue. A main cause of the difference
is the number of messages to Hyper-V to update dirty regions. With
hyperv_fb using deferred I/O, the messages are limited 20/second, so
the total number of messages to Hyper-V is about 480. But hyperv_drm
appears to send 3 messages to Hyper-V for each line of output, or a total of
about 3,000,000 messages (~90K/second). That's a lot of additional load
on the Hyper-V host, and it adds the 10 seconds of additional elapsed
time seen in the guest. There also this ugly output in dmesg because the
ring buffer for sending messages to the Hyper-V host gets full -- Hyper-V
doesn't always keep up, at least not on my local laptop where I'm
testing:
[12574.327615] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12574.327684] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12574.327760] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12574.327841] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12597.016128] hyperv_sendpacket: 6211 callbacks suppressed
[12597.016133] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12597.016172] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12597.016220] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
[12597.016267] hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] *ERROR* Unable to send packet via vmbus; error -11
hyperv_drm could be fixed to not output the ugly messages, but there's
still the underlying issue of overrunning the ring buffer, and excessively
hammering on the host. If we could get hyperv_drm doing deferred I/O, I
would feel much better about going full-on with deprecating hyperv_fb.
Michael
^ permalink raw reply
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Simona Vetter @ 2025-06-04 14:45 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Michael Kelley, David Hildenbrand, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
hch@lst.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <9a93813c-4d7c-45ef-b5a2-0ad37e7a078a@suse.de>
On Wed, Jun 04, 2025 at 10:12:45AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.06.25 um 19:50 schrieb Michael Kelley:
> > From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Monday, June 2, 2025 11:25 PM
> > > Hi
> > >
> > > Am 03.06.25 um 03:49 schrieb Michael Kelley:
> > > [...]
> > > > > Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a
> > > > > horrible hack.
> > > > >
> > > > > In another thread, you mention that you use PFN_SPECIAL to bypass the
> > > > > check in vm_mixed_ok(), so VM_MIXEDMAP is likely not set?
> > > > The VMA has VM_PFNMAP set, not VM_MIXEDMAP. It seemed like
> > > > VM_MIXEDMAP is somewhat of a superset of VM_PFNMAP, but maybe that's
> > > > a wrong impression. vm_mixed_ok() does a thorough job of validating the
> > > > use of __vm_insert_mixed(), and since what I did was allowed, I thought
> > > > perhaps it was OK. Your feedback has set me straight, and that's what I
> > > > needed. :-)
> > > >
> > > > But the whole approach is moot with Alistair Popple's patch set that
> > > > eliminates pfn_t. Is there an existing mm API that will do mkwrite on a
> > > > special PTE in a VM_PFNMAP VMA? I didn't see one, but maybe I missed
> > > > it. If there's not one, I'll take a crack at adding it in the next version of my
> > > > patch set.
> > > What is the motivation behind this work? The driver or fbdev as a whole
> > > does not have much of a future anyway.
> > >
> > > I'd like to suggest removing hyperv_fb entirely in favor of hypervdrm?
> > >
> > Yes, I think that's the longer term direction. A couple months ago I had an
> > email conversation with Saurabh Sengar from the Microsoft Linux team where
> > he raised this idea. I think the Microsoft folks will need to drive the deprecation
> > process, as they need to coordinate with the distro vendors who publish
> > images for running on local Hyper-V and in the Azure cloud. And my
> > understanding is that the Linux kernel process would want the driver to
> > be available but marked "deprecated" for a year or so before it actually
> > goes away.
>
> We (DRM upstream) recently considered moving some fbdev drivers to
> drivers/staging or marking them with !DRM if a DRM driver is available.
> Hyverv_fb would be a candidate.
>
> At least at SUSE, we ship hypervdrm instead of hyperv_fb. This works well on
> the various generations of the hyperv system. Much of our userspace would
> not be able to use hyperv_fb anyway.
Yeah investing into fbdev drivers, especially when some mm surgery seems
needed, does not sound like a good idea to me overall.
> > I do have some concerns about the maturity of the hyperv_drm driver
> > "around the edges". For example, somebody just recently submitted a
> > patch to flush output on panic. I have less familiarity hyperv_drm vs.
> > hyperv_fb, so some of my concern is probably due to that. We might
> > need to do review of hyperv_drm and see if there's anything else to
> > deal with before hyperv_fb goes away.
>
> The panic output is a feature that we recently added to the kernel. It
> allows a DRM driver to display a final error message in the case of a kernel
> panic (think of blue screens on Windows). Drivers require a minimum of
> support to make it work. That's what the hypervdrm patches were about.
I'm also happy to help with any other issues and shortfalls of drm vs
fbdev. There are some, but I thought it was mostly around some of the low
bit color formats that really old devices want, and not anything that
hyperv would need.
Cheers, Sima
>
> Best regards
> Thomas
>
> >
> > This all got started when I was looking at a problem with hyperv_fb,
> > and I found several other related problems, some of which also existed
> > in hyperv_drm. You've seen several small'ish fixes from me and Saurabh
> > as a result, and this issue with mmap()'ing /dev/fb0 is the last one of that
> > set. This fix is definitely a bit bigger, but it's the right fix. On the flip side,
> > if we really get on a path to deprecate hyperv_fb, there are hack fixes for
> > the mmap problem that are smaller and contained to hyperv_fb. I would
> > be OK with a hack fix in that case.
> >
> > Michael
>
> --
> --
> 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)
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] sysfb: Fix screen_info type check for VGA
From: Javier Martinez Canillas @ 2025-06-04 11:15 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: dri-devel, linux-fbdev, Thomas Zimmermann, Alex Deucher,
Tzung-Bi Shih, Helge Deller, Uwe Kleine-König, Zsolt Kajtar,
stable
In-Reply-To: <20250603154838.401882-1-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the helper screen_info_video_type() to get the framebuffer
> type from struct screen_info. Handle supported values in sorted
> switch statement.
>
> Reading orig_video_isVGA is unreliable. On most systems it is a
> VIDEO_TYPE_ constant. On some systems with VGA it is simply set
> to 1 to signal the presence of a VGA output. See vga_probe() for
> an example. Retrieving the screen_info type with the helper
> screen_info_video_type() detects these cases and returns the
> appropriate VIDEO_TYPE_ constant. For VGA, sysfb creates a device
> named "vga-framebuffer".
>
> The sysfb code has been taken from vga16fb, where it likely didn't
> work correctly either. With this bugfix applied, vga16fb loads for
> compatible vga-framebuffer devices.
>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ 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