Re: [PATCH v4 6/6] fbdev/viafb: Make I2C terminology more inclusive
On 7/11/24 07:27, Easwar Hariharan wrote: I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Acked-by: Thomas Zimmermann Signed-off-by: Easwar Hariharan --- drivers/video/fbdev/via/chip.h| 8 drivers/video/fbdev/via/dvi.c | 24 drivers/video/fbdev/via/lcd.c | 6 +++--- drivers/video/fbdev/via/via_aux.h | 2 +- drivers/video/fbdev/via/via_i2c.c | 12 ++-- drivers/video/fbdev/via/vt1636.c | 6 +++--- 6 files changed, 29 insertions(+), 29 deletions(-) This patch was applied to the fbdev git tree. Thanks! Helge
Re: [PATCH v4 5/6] fbdev/smscufx: Make I2C terminology more inclusive
On 7/11/24 07:27, Easwar Hariharan wrote: I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Acked-by: Thomas Zimmermann Signed-off-by: Easwar Hariharan --- drivers/video/fbdev/smscufx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) applied this patch to fbdev git tree. Thanks! Helge
Re: [Intel-gfx] [PATCH v3 RESEND 00/20] remove I2C_CLASS_DDC support
On 11/19/23 21:51, Heiner Kallweit wrote: On 19.11.2023 21:48, Heiner Kallweit wrote: On 19.11.2023 21:28, Helge Deller wrote: On 11/19/23 12:28, Heiner Kallweit wrote: After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Preferably this series should be applied via the i2c tree. The fbdev changes look at least ok so far, so: Acked-by: Helge Deller #fbdev I think this refers to patch 5 of the series. Could you please reply to patch 5 instead of the cover letter with your acked-by so that patchwork gets it right? Thanks! Sorry, just looked at where you are in To, not Cc. So your ack includes patches 6, 9, 10, 13? Yes. Helge v2: - change tag in commit subject of patch 03 - add ack tags v3: - fix a compile error in patch 5 Signed-off-by: Heiner Kallweit --- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 1 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - drivers/gpu/drm/ast/ast_i2c.c | 1 - drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 - drivers/gpu/drm/display/drm_dp_helper.c | 1 - drivers/gpu/drm/display/drm_dp_mst_topology.c | 1 - drivers/gpu/drm/gma500/cdv_intel_dp.c | 1 - drivers/gpu/drm/gma500/intel_gmbus.c | 1 - drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c | 1 - drivers/gpu/drm/gma500/psb_intel_sdvo.c | 1 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 1 - drivers/gpu/drm/i915/display/intel_gmbus.c | 1 - drivers/gpu/drm/i915/display/intel_sdvo.c | 1 - drivers/gpu/drm/loongson/lsdc_i2c.c | 1 - drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 1 - drivers/gpu/drm/mgag200/mgag200_i2c.c | 1 - drivers/gpu/drm/msm/hdmi/hdmi_i2c.c | 1 - drivers/gpu/drm/radeon/radeon_i2c.c | 1 - drivers/gpu/drm/rockchip/inno_hdmi.c | 1 - drivers/gpu/drm/rockchip/rk3066_hdmi.c | 1 - drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 1 - drivers/video/fbdev/core/fb_ddc.c | 1 - drivers/video/fbdev/cyber2000fb.c | 1 - drivers/video/fbdev/i740fb.c | 1 - drivers/video/fbdev/intelfb/intelfb_i2c.c | 15 +-- drivers/video/fbdev/matrox/i2c-matroxfb.c | 12 drivers/video/fbdev/s3fb.c | 1 - drivers/video/fbdev/tdfxfb.c | 1 - drivers/video/fbdev/tridentfb.c | 1 - drivers/video/fbdev/via/via_i2c.c | 1 - include/linux/i2c.h | 1 - 31 files changed, 9 insertions(+), 47 deletions(-)
Re: [Intel-gfx] [PATCH v3 RESEND 00/20] remove I2C_CLASS_DDC support
On 11/19/23 12:28, Heiner Kallweit wrote: After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Preferably this series should be applied via the i2c tree. The fbdev changes look at least ok so far, so: Acked-by: Helge Deller#fbdev v2: - change tag in commit subject of patch 03 - add ack tags v3: - fix a compile error in patch 5 Signed-off-by: Heiner Kallweit --- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c |1 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |1 - drivers/gpu/drm/ast/ast_i2c.c |1 - drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |1 - drivers/gpu/drm/display/drm_dp_helper.c |1 - drivers/gpu/drm/display/drm_dp_mst_topology.c |1 - drivers/gpu/drm/gma500/cdv_intel_dp.c |1 - drivers/gpu/drm/gma500/intel_gmbus.c |1 - drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c|1 - drivers/gpu/drm/gma500/psb_intel_sdvo.c |1 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c |1 - drivers/gpu/drm/i915/display/intel_gmbus.c|1 - drivers/gpu/drm/i915/display/intel_sdvo.c |1 - drivers/gpu/drm/loongson/lsdc_i2c.c |1 - drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c |1 - drivers/gpu/drm/mgag200/mgag200_i2c.c |1 - drivers/gpu/drm/msm/hdmi/hdmi_i2c.c |1 - drivers/gpu/drm/radeon/radeon_i2c.c |1 - drivers/gpu/drm/rockchip/inno_hdmi.c |1 - drivers/gpu/drm/rockchip/rk3066_hdmi.c|1 - drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c|1 - drivers/video/fbdev/core/fb_ddc.c |1 - drivers/video/fbdev/cyber2000fb.c |1 - drivers/video/fbdev/i740fb.c |1 - drivers/video/fbdev/intelfb/intelfb_i2c.c | 15 +-- drivers/video/fbdev/matrox/i2c-matroxfb.c | 12 drivers/video/fbdev/s3fb.c|1 - drivers/video/fbdev/tdfxfb.c |1 - drivers/video/fbdev/tridentfb.c |1 - drivers/video/fbdev/via/via_i2c.c |1 - include/linux/i2c.h |1 - 31 files changed, 9 insertions(+), 47 deletions(-)
Re: [Intel-gfx] [linux-next:master] BUILD REGRESSION e1f6a8eaf1c271a0158114a03e3605f4fba059ad
On 7/5/23 18:07, kernel test robot wrote: tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: e1f6a8eaf1c271a0158114a03e3605f4fba059ad Add linux-next specific files for 20230705 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/20230613.hher4zoo-...@intel.com https://lore.kernel.org/oe-kbuild-all/202306260401.qzlyqpv2-...@intel.com https://lore.kernel.org/oe-kbuild-all/202306291857.nyjjywqk-...@intel.com https://lore.kernel.org/oe-kbuild-all/202306301756.x8dgyynl-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/parisc/kernel/pdt.c:67:6: warning: no previous prototype for 'arch_report_meminfo' [-Wmissing-prototypes] The arch/parisc/* warnings have been fixed a few days ago in for-next, and the patches will most likely be merged upstream today... Helge
Re: [Intel-gfx] linux-next: manual merge of the fbdev tree with the drm-misc tree
On 1/16/23 01:54, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
include/linux/fb.h
between commit:
5b6373de4351 ("drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE")
from the drm-misc tree and commit:
72ac3535c2c5 ("fbdev: fb.h: Replace 0-length array with flexible array")
from the fbdev tree.
I've dropped the offending patch from the fbdev git tree, so it should
be resolved now.
Thanks!
Helge
Re: [Intel-gfx] [PATCH] drm/fb-helper: Remove helpers to change frame buffer config
On 6/29/22 12:56, Geert Uytterhoeven wrote:
> The DRM fbdev emulation layer does not support pushing back
> changes to fb_var_screeninfo to KMS.
>
> However, drm_fb_helper still implements the fb_ops.fb_check_var() and
> fb_ops.fb_set_par() callbacks, but the former fails to validate various
> parameters passed from userspace. Hence unsanitized and possible
> invaled values are passed up through the fbdev, fbcon, and console
> stack, which has become an endless source of security issues reported
> against fbdev.
>
> Fix this by not populating the fb_ops.fb_check_var() and
> fb_ops.fb_set_par() callbacks, as there is no point in providing them if
> the frame buffer config cannot be changed anyway. This makes the fbdev
> core aware that making changes to the frame buffer config is not
> supported, so it will always return the current config.
>
> Signed-off-by: Geert Uytterhoeven
It's unfortunate that DRM currently isn't able to switch resolutions
at runtime.
With that in mind I agree with Geert that it's probably better to
disable (or drop) that code until DRM can cope with fbdev's
interface to switch resolutions.
Furthermore, with the upcoming patches to fbcon (which prevents crashes on
invalid userspace input), you will face a kernel WARNING if you call fbset
to switch screen resolutions with DRM drivers.
So, from my side (although I'd prefer a better fix for DRM):
Acked-by: Helge Deller
Helge
> ---
> The only remaining DRM driver that implements fb_ops.fb_check_var() is
> also broken, as it fails to validate various parameters passed from
> userspace. So vmw_fb_check_var() should either be fixed, or removed.
> ---
> drivers/gpu/drm/drm_fb_helper.c| 180 ++---
> drivers/gpu/drm/i915/display/intel_fbdev.c | 15 --
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 -
> include/drm/drm_fb_helper.h| 16 --
> 4 files changed, 13 insertions(+), 200 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 2d4cee6a10e7..1041a11c410d7967 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -228,9 +228,18 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> }
> EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>
> -static int
> -__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper,
> - bool force)
> +/**
> + * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> + * @fb_helper: driver-allocated fbdev helper, can be NULL
> + *
> + * This should be called from driver's drm _driver.lastclose callback
> + * when implementing an fbcon on top of kms using this helper. This ensures
> that
> + * the user isn't greeted with a black screen when e.g. X dies.
> + *
> + * RETURNS:
> + * Zero if everything went ok, negative error code otherwise.
> + */
> +int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
> *fb_helper)
> {
> bool do_delayed;
> int ret;
> @@ -242,16 +251,7 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper,
> return 0;
>
> mutex_lock(_helper->lock);
> - if (force) {
> - /*
> - * Yes this is the _locked version which expects the master lock
> - * to be held. But for forced restores we're intentionally
> - * racing here, see drm_fb_helper_set_par().
> - */
> - ret = drm_client_modeset_commit_locked(_helper->client);
> - } else {
> - ret = drm_client_modeset_commit(_helper->client);
> - }
> + ret = drm_client_modeset_commit(_helper->client);
>
> do_delayed = fb_helper->delayed_hotplug;
> if (do_delayed)
> @@ -263,22 +263,6 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper,
>
> return ret;
> }
> -
> -/**
> - * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> - * @fb_helper: driver-allocated fbdev helper, can be NULL
> - *
> - * This should be called from driver's drm _driver.lastclose callback
> - * when implementing an fbcon on top of kms using this helper. This ensures
> that
> - * the user isn't greeted with a black screen when e.g. X dies.
> - *
> - * RETURNS:
> - * Zero if everything went ok, negative error code otherwise.
> - */
> -int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
> *fb_helper)
> -{
> - return __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper, false);
> -}
> EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
>
> #ifdef CONFIG_MAGIC_SYSRQ
> @@ -1254,25 +
Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On 2/1/22 14:45, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 12:01 PM Helge Deller wrote:
>> On 2/1/22 11:36, Daniel Vetter wrote:
>>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller wrote:
>>>>
>>>> On 1/31/22 22:05, Daniel Vetter wrote:
>>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>>>> option.
>>>>
>>>> you have two trivial copy-n-paste errors in this patch which still prevent
>>>> the
>>>> console acceleration.
>>>
>>> Duh :-(
>>>
>>> But before we dig into details I think the big picture would be
>>> better. I honestly don't like the #ifdef pile here that much.
>>
>> Me neither.
>> The ifdefs give a better separation, but prevents that the compiler
>> checks the various paths when building.
>>
>>> I wonder whether your approach, also with GETVX/YRES adjusted
>>> somehow, wouldn't look cleaner?
>> I think so.
>> You wouldn't even need to touch GETVX/YRES because the compiler
>> will optimize/reduce it from
>>
>> #define GETVYRES(s,i) ({ \
>> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
>> (i)->var.yres : (i)->var.yres_virtual; })
>>
>> to just become:
>>
>> #define GETVYRES(s,i) ((i)->var.yres)
>
> Yeah, but you need to roll out your helper to all the callsites. But
> since you #ifdef out info->scrollmode we should catch them all I
> guess.
Right. That was the only reason why I ifdef'ed it out.
Technically we don't need that ifdef.
>>> Like I said in the cover letter I got mostly distracted with fbcon
>>> locking last week, not really with this one here at all, so maybe
>>> going with your 4 (or 2 if we squash them like I did here) patches is
>>> neater?
>>
>> The benefit of my patch series was, that it could be easily backported first,
>> and then cleaned up afterwards. Even a small additional backport patch to
>> disable
>> the fbcon acceleration for DRM in the old releases would be easy.
>> But I'm not insisting on backporting the patches, if we find good way
>> forward.
>>
>> So, either with the 4 (or 2) patches would be OK for me (or even your
>> approach).
>
> The idea behind the squash was that it's then impossible to backport
> without the Kconfig,
Yes, my proposal was to simply revert the 2 patches and immediatly send
the Kconfig patch to disable it again.
> and so we'll only enable this code when people
> intentionally want it. Maybe I'm too paranoid?
I think you are too paranoid :-)
If all patches incl. the Kconfig patch are backported then people shouldn't
do it wrong.
> Anyway, you feel like finishing off your approach? Or should I send
> out v2 of this with the issues fixed you spotted? Like I said either
> is fine with me.
Ok, then let me try to finish my approach until tomorrow, and then you
check if you can and want to add your locking and other patches on top of it.
In the end I leave the decision which approach to take to you.
Ok?
Helge
Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On 2/1/22 11:36, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller wrote:
>>
>> On 1/31/22 22:05, Daniel Vetter wrote:
>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>> option.
>>
>> you have two trivial copy-n-paste errors in this patch which still prevent
>> the
>> console acceleration.
>
> Duh :-(
>
> But before we dig into details I think the big picture would be
> better. I honestly don't like the #ifdef pile here that much.
Me neither.
The ifdefs give a better separation, but prevents that the compiler
checks the various paths when building.
> I wonder whether your approach, also with GETVX/YRES adjusted
> somehow, wouldn't look cleaner?
I think so.
You wouldn't even need to touch GETVX/YRES because the compiler
will optimize/reduce it from
#define GETVYRES(s,i) ({ \
(s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
(i)->var.yres : (i)->var.yres_virtual; })
to just become:
#define GETVYRES(s,i) ((i)->var.yres)
> Like I said in the cover letter I got mostly distracted with fbcon
> locking last week, not really with this one here at all, so maybe
> going with your 4 (or 2 if we squash them like I did here) patches is
> neater?
The benefit of my patch series was, that it could be easily backported first,
and then cleaned up afterwards. Even a small additional backport patch to
disable
the fbcon acceleration for DRM in the old releases would be easy.
But I'm not insisting on backporting the patches, if we find good way forward.
So, either with the 4 (or 2) patches would be OK for me (or even your approach).
Helge
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On 1/31/22 22:05, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. Yes, agreed. Acked-by: Helge Deller Since the code is used by drm and existing fbdev drivers, please just make sure to not break fbdev... Thanks! Helge > > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Linus Torvalds > Cc: Linux Fbdev development list > Cc: Pavel Machek > Cc: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Javier Martinez Canillas > Cc: DRI Development > Cc: Linux Kernel Mailing List > Cc: Claudio Suarez > Cc: Tomi Valkeinen > Cc: Geert Uytterhoeven > Cc: Thomas Zimmermann > Cc: Daniel Vetter > Cc: Sven Schnelle > Cc: Gerd Hoffmann > Signed-off-by: Daniel Vetter > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ea3e6c914384..49809eaa3096 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7573,6 +7573,12 @@ S: Maintained > W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > +FRAMEBUFFER CORE > +M: Daniel Vetter > +F: drivers/video/fbdev/core/ > +S: Odd Fixes > +T: git git://anongit.freedesktop.org/drm/drm-misc > + > FRAMEBUFFER LAYER > M: Helge Deller > L: linux-fb...@vger.kernel.org >
Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.
you have two trivial copy-n-paste errors in this patch which still prevent the
console acceleration.
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 2ff90061c7f3..39dc18a5de86 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> - /*
> - * No more hw acceleration for fbcon.
> - *
> - * FIXME: Garbage collect all the now dead code after sufficient time
> - * has passed.
> - */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
should be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> + !(info->flags & FBINFO_HWACCEL_DISABLED))
> + p->scrollmode = SCROLL_MOVE;
> + else /* default to something safe */
> + p->scrollmode = SCROLL_REDRAW;
> +#else
> p->scrollmode = SCROLL_REDRAW;
> +#endif
>
> /*
>* ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> + int cap = info->flags;
> + u16 t = 0;
> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> + info->fix.xpanstep);
> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> + divides(ypan, vc->vc_font.height) && vyres > yres;
> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> + divides(ywrap, vc->vc_font.height) &&
> + divides(vc->vc_font.height, vyres) &&
> + divides(vc->vc_font.height, yres);
> + int reading_fast = cap & FBINFO_READS_FAST;
> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
>
> p->vrows = vyres/fh;
> if (yres > (fh * (vc->vc_rows + 1)))
> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> if ((yres % fh) && (vyres % fh < yres % fh))
> p->vrows--;
> +
> + if (good_wrap || good_pan) {
> + if (reading_fast || fast_copyarea)
> + p->scrollmode = good_wrap ?
> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> + else
> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> + SCROLL_PAN_REDRAW;
> + } else {
> + if (reading_fast || (fast_copyarea && !fast_imageblit))
> + p->scrollmode = SCROLL_MOVE;
> + else
> + p->scrollmode = SCROLL_REDRAW;
> + }
> +
> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
same here... it needs to be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + p->scrollmode = SCROLL_REDRAW;
> +#endif
> }
>
> #define PITCH(w) (((w) + 7) >> 3)
>
still reviewing the other patches...
Helge
Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On 2/1/22 11:16, Helge Deller wrote:
> On 1/31/22 22:05, Daniel Vetter wrote:
>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>> option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
>
>> diff --git a/drivers/video/fbdev/core/fbcon.c
>> b/drivers/video/fbdev/core/fbcon.c
>> index 2ff90061c7f3..39dc18a5de86 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>> ops->graphics = 0;
>>
>> -/*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> +if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
>> +!(info->flags & FBINFO_HWACCEL_DISABLED))
>> +p->scrollmode = SCROLL_MOVE;
>> +else /* default to something safe */
>> +p->scrollmode = SCROLL_REDRAW;
>> +#else
>> p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>
>> /*
>> * ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>> {
>> struct fbcon_ops *ops = info->fbcon_par;
>> int fh = vc->vc_font.height;
>> +int cap = info->flags;
>> +u16 t = 0;
>> +int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> + info->fix.xpanstep);
>> +int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> +int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> +divides(ypan, vc->vc_font.height) && vyres > yres;
>> +int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> +divides(ywrap, vc->vc_font.height) &&
>> +divides(vc->vc_font.height, vyres) &&
>> +divides(vc->vc_font.height, yres);
>> +int reading_fast = cap & FBINFO_READS_FAST;
>> +int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> +!(cap & FBINFO_HWACCEL_DISABLED);
>> +int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> +!(cap & FBINFO_HWACCEL_DISABLED);
>>
>> p->vrows = vyres/fh;
>> if (yres > (fh * (vc->vc_rows + 1)))
>> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> if ((yres % fh) && (vyres % fh < yres % fh))
>> p->vrows--;
>> +
>> +if (good_wrap || good_pan) {
>> +if (reading_fast || fast_copyarea)
>> +p->scrollmode = good_wrap ?
>> +SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> +else
>> +p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> +SCROLL_PAN_REDRAW;
>> +} else {
>> +if (reading_fast || (fast_copyarea && !fast_imageblit))
>> +p->scrollmode = SCROLL_MOVE;
>> +else
>> +p->scrollmode = SCROLL_REDRAW;
>> +}
>> +
>> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
actually:
#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> +p->scrollmode = SCROLL_REDRAW;
>> +#endif
>> }
>>
>> #define PITCH(w) (((w) + 7) >> 3)
>>
>
> still reviewing the other patches...
>
> Helge
>
Re: [Intel-gfx] [PATCH v4 7/9] parisc/perf: open access for CAP_SYS_PERFMON privileged process
On 18.12.19 10:29, Alexey Budankov wrote: > > Open access to monitoring for CAP_SYS_PERFMON privileged processes. > For backward compatibility reasons access to the monitoring remains open > for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure > monitoring is discouraged with respect to CAP_SYS_PERFMON capability. > > Signed-off-by: Alexey Budankov Acked-by: Helge Deller > --- > arch/parisc/kernel/perf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/parisc/kernel/perf.c b/arch/parisc/kernel/perf.c > index 676683641d00..c4208d027794 100644 > --- a/arch/parisc/kernel/perf.c > +++ b/arch/parisc/kernel/perf.c > @@ -300,7 +300,7 @@ static ssize_t perf_write(struct file *file, const char > __user *buf, > else > return -EFAULT; > > - if (!capable(CAP_SYS_ADMIN)) > + if (!perfmon_capable()) > return -EACCES; > > if (count != sizeof(uint32_t)) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/14] i915: Use %pS printk format for direct addresses
Use the %pS printk format for printing symbols from direct addresses.
This is important for the ia64, ppc64 and parisc64 architectures, while on
other architectures there is no difference between %pS and %pF.
Fix it for consistency across the kernel.
Signed-off-by: Helge Deller <del...@gmx.de>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: David Airlie <airl...@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 4e00e5c..29c62d4 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -64,7 +64,7 @@ static unsigned long wait_timeout(void)
static noinline void missed_breadcrumb(struct intel_engine_cs *engine)
{
- DRM_DEBUG_DRIVER("%s missed breadcrumb at %pF, irq posted? %s, current
seqno=%x, last=%x\n",
+ DRM_DEBUG_DRIVER("%s missed breadcrumb at %pS, irq posted? %s, current
seqno=%x, last=%x\n",
engine->name, __builtin_return_address(0),
yesno(test_bit(ENGINE_IRQ_BREADCRUMB,
>irq_posted)),
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
