Re: [RESEND v3 2/2] drm: Add CONFIG_DRM_WERROR

nd on COMPILE_TEST > > Reviewed-by: Hamza Mahfooz # v1 > Signed-off-by: Jani Nikula > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [PATCH 2/2] drm: Warn when freeing a framebuffer that's still on a list

Ville Syrjala writes: > From: Ville Syrjälä > > Sprinkle some extra WARNs around so that we might catch > premature framebuffer destruction more readily. > > Signed-off-by: Ville Syrjälä > --- Acked-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canill

Re: [PATCH 1/2] drm: Don't unref the same fb many times by mistake due to deadlock handling

ramebuffer list. Fortunately I was able to convince it to oops > instead, and from there it was easier to track down the culprit. > > Cc: sta...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- Acked-by: Javier Martinez Canillas > drivers/gpu/drm/drm_plane.c | 1 + > 1 fil

Re: [PATCH] drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m

ge managers" > default n > - depends on DRM=y > + depends on DRM > depends on STACKTRACE_SUPPORT > select STACKDEPOT > help > -- Acked-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [RFC] drm: enable W=1 warnings by default across the subsystem

r kernel configs. It's a fair point though that probably the only option is to enable it unconditionally. Acked-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [RFC] drm: enable W=1 warnings by default across the subsystem

using W=1 or > CONFIG_DRM_EXTRA_CHECKS introducing warnings, and people using them > fixing the warnings... > > I really do think making it unconditional is the only way. > Fair enough. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [RFC] drm: enable W=1 warnings by default across the subsystem

l Makefiles, depending on the >> case. > > I'm all for it, but yeah, we need some easy way to opt-in/opt-out. Some > drivers are pretty much unmaintained now and are likely to never fix > those warnings. > Maybe add a Kconfig symbol for it instead of making unconditional? Some

Re: [Intel-gfx] [PATCH v5 2/7] drm/client: Do not acquire module reference

p DRM clients can now be unloaded. > > Signed-off-by: Thomas Zimmermann > --- The change makes sense to me. Acked-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2] drm: Spelling s/sempahore/semaphore/

Geert Uytterhoeven writes: > Fix misspellings of "semaphore". > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Hamza Mahfooz > --- > v2: > - Add Reviewed-by. > --- Pushed to drm-misc (drm-misc-next). Thanks! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

local variable. > Maybe all the other people with strong opinions are dead if this was > "discussed to death" before? :-) > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ | -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace

gp, sizeof(var))) > return -EFAULT; > + /* only for kernel-internal use */ > + var.activate &= ~FB_ACTIVATE_KD_TEXT; > console_lock(); I don't have a better idea on how to fix this and as you said the whole struct fb_var_

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

__ prefix in their name. So maybe I am the one who was confused on the meaning of it. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

at [1]. > > Signed-off-by: Thomas Zimmermann > Link: > https://patchwork.kernel.org/project/dri-devel/patch/20230404201842.567344-1-daniel.vet...@ffwll.ch/ > # 1 > --- Looks good to me and I agree that it makes the code easier to understand. Reviewed-by: Javier Martine

Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var

Daniel Vetter writes: > On Wed, Apr 05, 2023 at 07:42:08PM +0200, Javier Martinez Canillas wrote: [...] >> >> Ah, your patch adds it after that indeed. Please ignore my comment then. >> > >> > So rb: you? >> > >> >> Yes, I alread

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

Daniel Vetter writes: > On Wed, 5 Apr 2023 at 18:54, Javier Martinez Canillas > wrote: >> >> Daniel Vetter writes: [...] >> >> Yeah, agreed that if vga_remove_vgacon() isn't enough and another helper >> is needed then starts to get a little silly. Maybe

Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var

Daniel Vetter writes: > On Wed, Apr 05, 2023 at 06:27:17PM +0200, Javier Martinez Canillas wrote: >> Daniel Vetter writes: [...] >> > >> > The __fill_var is after this. I'm honestly not sure what the exact >> >> Ah, your patch adds it after that indeed

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

al issues. There is no point on blocking all your series just for this IMO. Then latter if Thomas has strong opinions can send a follow-up patch for the gma500 driver and the aperture helpers. > -Daniel > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var

ight not have a big > enough buffer anymore and things fail (but shouldn't). > > Not sure how to fix that tbh. Would this be a problem in practice? -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 8/8] fbdev: Simplify fb_is_primary_device for x86

an fb is primary"). That patch doesn't explain why we still > fall back to the shadow rom check. > > Signed-off-by: Daniel Vetter > Cc: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Javier Martinez Canillas > Cc: Thomas Zimmermann > Cc: Thomas Gleixne

Re: [Intel-gfx] [PATCH 7/8] video/aperture: Only remove sysfb on the default vga pci device

38d8 ("fbdev: Disable sysfb device registration when removing > conflicting FBs") > Tested-by: Aaron Plattner > Reviewed-by: Javier Martinez Canillas > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 > Signed-off-by: Daniel Vetter > Cc: Aaron Pla

Re: [Intel-gfx] [PATCH 6/8] video/aperture: Drop primary argument

1 vm, not for gen2) there is one leftover user in an actual driver > left to touch. > > Signed-off-by: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Javier Martinez Canillas > Cc: Helge Deller > Cc: linux-fb...@vger.kernel.org > Cc: Maarten Lankhorst > Cc: Maxime Ripard

Re: [Intel-gfx] [PATCH 5/8] video/aperture: Move vga handling to pci function

> > - Also it's a bit funny if we have one part of the vga removal in the > pci function, and the other in the generic one. > > v2: Rebase. > > Signed-off-by: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Javier Martinez Canillas > Cc: Helge Deller > Cc:

Re: [Intel-gfx] [PATCH 4/8] video/aperture: Only kick vgacon when the pdev is decoding vga

> > v2: Flip the check around to make it clear it's a special case for > kicking out the vgacon driver only (Thomas) > > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303 > Signed-off-by: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Javier Martinez Canillas

Re: [Intel-gfx] [PATCH 3/8] drm/aperture: Remove primary argument

s primary == false and we can remove > it now. > > v2: > - Reorder to avoid compile fail (Thomas) > - Include gma500, which retained it's called to the non-pci version. > > Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 2/8] video/aperture: use generic code to figure out the vga default device

only used to select the right fbdev driver for fbcon, and not for > the fw handover dance which the aperture helpers handle. At least > for x86 we might want to look into unifying them, but that's a > separate thing. > > v2: Extend commit message trying to summarize various

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

e must kick fbdev drivers before vgacon, >* otherwise the vga fbdev driver falls over. >*/ > ret = vga_remove_vgacon(pdev); > if (ret) > return ret; > > return 0; > } > If this is enough I agree that is much more easier code to understand. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var

n -EINVAL; > + > + /* We neither support grayscale nor FOURCC (also stored in here). */ > + if (var->grayscale > 0) > + return -EINVAL; > + > + if (var->nonstd) > + return -EINVAL; > > /* >* Workaround for SDL 1.2, which is known to be setting all pixel format > @@ -1612,11 +1647,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo > *var, > drm_fb_helper_fill_pixel_fmt(var, format); > } > Other than what I mentioned, the patch makes sense to me. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()

: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > --- Makes sense to drop this. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var

help distros to figure out if something has to be cherry-picked by them. So I believe that would be useful to have it. The patch looks good to me. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH] drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini()

Thomas Zimmermann writes: > Hi > > Am 21.02.23 um 11:27 schrieb Javier Martinez Canillas: >> Thomas Zimmermann writes: >> >>> Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the >>> calling fbdev implementation. Avoids a possible

Re: [Intel-gfx] [PATCH] drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini()

be Fixes: 032116bbe152 ("drm/fbdev-generic: Minimize client unregistering") instead? Because commit 4825797c36da just added a wrapper function for mutex_destroy(_helper->lock), but it was commit 032116bbe152 that made drm_fbdev_cleanup() to call that helper function. > Cc: Thomas

Re: [Intel-gfx] [PATCH v2 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'

> > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 09/10] drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy()

On 1/24/23 14:40, Thomas Zimmermann wrote: > The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls > drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the > caller. No functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH v2 08/10] drm/fbdev-generic: Minimize client unregistering

. > > v2: > * remove test for (fbi != NULL) in drm_fbdev_cleanup() (Sam) > > Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 07/10] drm/fbdev-generic: Minimize hotplug error handling

On 1/24/23 14:40, Thomas Zimmermann wrote: > Call drm_fb_helper_init() in the generic-fbdev hotplug helper drm_fb_helper_fini() > to revert the effects of drm_fb_helper_init(). No full cleanup > is required. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH v2 06/10] drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function

fbdev code has to be adapted. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 05/10] drm/fb-helper: Remove preferred_bpp parameter from fbdev internals

e in the fb-helper instance. > > No functional changes. > > Signed-off-by: Thomas Zimmermann > --- That's much better indeed. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup

per_generic_funcs); > Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()

to remove this stub if you limit the scope of the helper. No strong opinion though. So if you prefer to keep it as is, feel free to add: Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 02/10] drm/client: Add hotplug_failed flag

b_helper, which prevents us from initializing these pointers > early after allocation. > > The change also harmonizes behavior among DRM clients. Additional DRM > clients will now handle failed hotplugging like fbdev does. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by:

Re: [Intel-gfx] [PATCH v2 01/10] drm/client: Test for connectors before sending hotplug event

> --- Reviewed-by: Javier Martinez Canillas but I've a question below. > drivers/gpu/drm/drm_client.c| 5 + > drivers/gpu/drm/drm_fbdev_generic.c | 5 - > 2 files changed, 5 insertions(+), 5 deletions(-) [...] > --- a/drivers/gpu/drm/drm_fbdev_generic.c > +++ b/dr

Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device

so is carrying a workaround just for the Nvidia proprietary driver since all other drivers provide a emulated fbdev device. So getting this finally fixed will be indeed highly appreciated. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device

a69aa38d8 tag here too ? > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 > Signed-off-by: Daniel Vetter > Cc: Aaron Plattner > Cc: Javier Martinez Canillas > Cc: Thomas Zimmermann > Cc: Helge Deller > Cc: Sam Ravnborg > Cc: Alex Deucher > Cc: # v5.1

Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device

Since is just a single function call, I would just duplicate like $subject does to be honest. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v3] drm: Only select I2C_ALGOBIT for drivers that actually need it

On 12/19/22 09:49, Javier Martinez Canillas wrote: > Hello Uwe, > > On 12/19/22 09:36, Uwe Kleine-König wrote: >> While working on a drm driver that doesn't need the i2c algobit stuff I >> noticed that DRM selects this code even though only 8 drivers actually use >&g

Re: [Intel-gfx] [PATCH 18/18] drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE

ned-off-by: Thomas Zimmermann > --- > drivers/video/fbdev/core/fbmem.c | 33 -- > drivers/video/fbdev/core/fbsysfs.c | 1 - > include/linux/fb.h | 22 > 3 files changed, 56 deletions(-) Nice patch! Reviewed-by: Ja

Re: [Intel-gfx] [PATCH 17/18] fbdev/vga16fb: Do not use struct fb_info.apertures

ned-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 16/18] fbdev/vesafb: Do not use struct fb_info.apertures

ned-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 15/18] fbdev/vesafb: Remove trailing whitespaces

On 12/19/22 17:05, Thomas Zimmermann wrote: > Fix coding style. No functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 14/18] fbdev/simplefb: Do not use struct fb_info.apertures

ned-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 13/18] fbdev/offb: Do not use struct fb_info.apertures

ned-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 12/18] fbdev/offb: Allocate struct offb_par with framebuffer_alloc()

On 12/19/22 17:05, Thomas Zimmermann wrote: > Move the palette array into struct offb_par and allocate both via > framebuffer_alloc(), as intended by fbdev. No functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best r

Re: [Intel-gfx] [PATCH 11/18] fbdev/efifb: Do not use struct fb_info.apertures

ned-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 10/18] fbdev/efifb: Add struct efifb_par for driver data

On 12/19/22 17:05, Thomas Zimmermann wrote: > The efifb_par structure holds the palette for efifb. It will also > be useful for storing the device's aperture range. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Ma

Re: [Intel-gfx] [PATCH 09/18] vfio-mdev/mdpy-fb: Do not set struct fb_info.apertures

goto err_unmap; > - } > - info->apertures->ranges[0].base = info->fix.smem_start; > - info->apertures->ranges[0].size = info->fix.smem_len; > - > info->fbops = _fb_ops; > info->flags = FBINFO_DEFAULT; > info->pseudo

Re: [Intel-gfx] [PATCH 08/18] fbdev/hyperv-fb: Do not set struct fb_info.apertures

y: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 07/18] fbdev/clps711x-fb: Do not set struct fb_info.apertures

y: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 06/18] drm/fb-helper: Do not allocate unused apertures structure

On 12/19/22 17:05, Thomas Zimmermann wrote: > The apertures field in struct fb_info is not used by DRM drivers. Do > not allocate it. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 05/18] drm/radeon: Do not set struct fb_info.apertures

On 12/19/22 17:05, Thomas Zimmermann wrote: > Generic fbdev drivers use the apertures field in struct fb_info to > control ownership of the framebuffer memory and graphics device. Do > not set the values in radeon. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH 04/18] drm/i915: Do not set struct fb_info.apertures

On 12/19/22 17:05, Thomas Zimmermann wrote: > Generic fbdev drivers use the apertures field in struct fb_info to > control ownership of the framebuffer memory and graphics device. Do > not set the values in i915. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH 03/18] drm/gma500: Do not set struct fb_info.apertures

On 12/19/22 17:05, Thomas Zimmermann wrote: > Generic fbdev drivers use the apertures field in struct fb_info to > control ownership of the framebuffer memory and graphics device. Do > not set the values in gma500. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH 02/18] Revert "fbcon: don't lose the console font across generic->chip driver switch"

emd/systemd/tree/src/vconsole/90-vconsole.rules.in?h=v222 > # 3 > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH 01/18] fbcon: Remove trailing whitespaces

On 12/19/22 17:04, Thomas Zimmermann wrote: > Fix coding style. No functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v3] drm: Only select I2C_ALGOBIT for drivers that actually need it

next cleanup patch. Still prepare this already by also selecting I2C for > the individual drivers. > > Signed-off-by: Uwe Kleine-König > --- Thanks for sending a v3 of this. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v3 23/23] drm/fb-helper: Clarify use of last_close and output_poll_changed

-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v3 20/23] drm/fb-helper: Set flag in struct drm_fb_helper for leaking physical addresses

_fb_helper.c. No functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 17/21] drm/fb-helper: Perform all fbdev I/O with the same implementation

; > It could happen that some userspace program hits to error, but still > relies on the output and position being updated. IIRC I even added > validation of this behavior to the IGT fbdev tests. I agree that this > is somewhat bogus behavior, but changing it would change long-standing > userspace semantics. > Thanks for the explanation, feel free then to also add to this patch: Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 21/21] drm/fb-helper: Remove unnecessary include statements

On 10/24/22 13:19, Thomas Zimmermann wrote: > Remove include statements for where it is not > required (i.e., most of them). In a few places include other header > files that are required by the source code. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH v2 20/21] drm/fb-helper: Move generic fbdev emulation into separate source file

omas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 19/21] drm/fb-helper: Always initialize generic fbdev emulation

t; will initialize after hotplugging the connector. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 18/21] drm/fb_helper: Minimize damage-helper overhead

an fb_dirty callback. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas But I've a trivial comment below: > drivers/gpu/drm/drm_fb_helper.c | 90 ++--- > 1 file changed, 60 insertions(+), 30 deletions(-) >

Re: [Intel-gfx] [PATCH v2 17/21] drm/fb-helper: Perform all fbdev I/O with the same implementation

.] > +static ssize_t fb_write_screen_base(struct fb_info *info, const char __user > *buf, size_t count, > + loff_t pos) > +{ > + char __iomem *dst = info->screen_base + pos; > + size_t alloc_size = min_t(size_t, count, PAGE_SIZE); > + ssize_t ret = 0; > + int err = 0; Same here. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 16/21] drm/fb-helper: Call fb_sync in I/O functions

same in DRM implementations will allow us to use > them throughout DRM drivers. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 15/21] drm/fb-helper: Disconnect damage worker from update logic

helper, > damage_work); This line is an unrelated code style change. But I guess it's OK. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 14/21] drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use _info postfix

On 10/24/22 13:19, Thomas Zimmermann wrote: > Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info() > as part of unifying the naming within fbdev helpers. Adapt drivers. No > functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier

Re: [Intel-gfx] [PATCH v2 13/21] drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info postfix

On 10/24/22 13:19, Thomas Zimmermann wrote: > Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as > part of unifying the naming within fbdev helpers. Adapt drivers. No > functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez C

Re: [Intel-gfx] [PATCH v2 12/21] drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper

; > Signed-off-by: Thomas Zimmermann > --- Agreed. I got confused by this naming in the past. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 11/21] drm/fb-helper: Cleanup include statements in header file

On 10/24/22 13:19, Thomas Zimmermann wrote: > Only include what we have to. > > Signed-off-by: Thomas Zimmermann > --- Nice cleanup. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 10/21] drm/tve200: Include

On 10/24/22 13:19, Thomas Zimmermann wrote: > Include for of_match_ptr(). > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 09/21] drm/panel-ili9341: Include

On 10/24/22 13:19, Thomas Zimmermann wrote: > Include for devm_of_find_backlight(). > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 08/21] drm/rockchip: Don't set struct drm_driver.output_poll_changed

otplug_event() and > drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. > > v2: > * fix commit description (Christian) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 07/21] drm/logicvc: Don't set struct drm_driver.output_poll_changed

otplug_event() and > drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. > > v2: > * fix commit description (Christian) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 06/21] drm/ingenic: Don't set struct drm_driver.output_poll_changed

otplug_event() and > drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. > > v2: > * fix commit description (Christian, Sergey) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 05/21] drm/imx/dcss: Don't set struct drm_driver.output_poll_changed

otplug_event() and > drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. > > v2: > * fix commit description (Christian) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 04/21] drm/amdgpu: Don't set struct drm_driver.output_poll_changed

otplug_event() and > drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. > > v2: > * fix commit description (Christian) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 04/21] drm/amdgpu: Don't set struct drm_driver.output_poll_changed

otplug_event() and > drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. > > v2: > * fix commit description (Christian) > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Do you think that the fbdev helpers kernel

Re: [Intel-gfx] [PATCH v2 03/21] drm/vboxvideo: Don't set struct drm_driver.lastclose

_dev_restore() in drm_lastclose(). > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 02/21] drm/mcde: Don't set struct drm_driver.lastclose

rm_lastclose(). > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 01/21] drm/komeda: Don't set struct drm_driver.lastclose

rm_lastclose(). > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

eader files. > > IMHO the current convention (if any) is far from optimal and we should > consider breaking it. > Yes, I agree with that. But probably we should be explicit about the wrapper export symbols to access static functions pattern in the KUnit docs so other subsystems could do the same and it becomes a convention ? > Best regards > Thomas > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

line_mode(connector) > } > EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit) > #endif > > The wrapper's declaration can be located in the kunit test file. > But that's also not nice since we are artificially exposing these only to allow the static functions to be called from unit tests. And would be a different approach than the one used by all other subsystems... -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

ml.org/lkml/2022/6/10/316 -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat

Re: [Intel-gfx] [PATCH] fbdev: efifb: Fix a use-after-free due early fb_info cleanup

Hello Lucas, On 5/7/22 18:20, Lucas De Marchi wrote: > On Fri, May 06, 2022 at 03:22:25PM +0200, Javier Martinez Canillas wrote: >> Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather >> than .remove") attempted to fix a use-after-free error due driv

[Intel-gfx] [PATCH] fbdev: efifb: Fix a use-after-free due early fb_info cleanup

free since the fb_info was still used after the free. This should fix for good by freeing the fb_info at the end of the handler. Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove") Reported-by: Ville Syrjälä Reported-by: Andrzej Hajda Signed-off-by: Javi

Re: [Intel-gfx] [PATCH] fbcon: Fix delayed takeover locking

On 4/13/22 11:21, Daniel Vetter wrote: > On Wed, Apr 13, 2022 at 11:16:08AM +0200, Javier Martinez Canillas wrote: >> Hello Daniel, >> >> On 4/13/22 10:21, Daniel Vetter wrote: >>> I messed up the delayed takover path in the locking conversion in >>>

Re: [Intel-gfx] [PATCH] fbcon: Fix delayed takeover locking

d without the console_lock being held. The changes themselves look good to me. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat

Re: [Intel-gfx] [PATCH 02/15] dma-buf: specify usage while adding fences to dma_resv obj v7

On 4/7/22 15:13, Christian König wrote: > Am 07.04.22 um 15:08 schrieb Javier Martinez Canillas: >> Hello Christian, >> >> On 4/7/22 10:59, Christian König wrote: >>> Instead of distingting between shared and exclusive fences specify >>> the fence usage

Re: [Intel-gfx] [PATCH 02/15] dma-buf: specify usage while adding fences to dma_resv obj v7

for the vc4 DRM driver. I've this patch locally which seems to work but I don't know enough about the fence API to know if is correct. If you think is the proper fix then I can post it as a patch. >From 3e96db4827ef69b38927476659cbb4469a0246e6 Mon Sep 17 00:00:00 2001 From: Javier Martinez Cani

Re: [Intel-gfx] [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

On 4/5/22 12:34, Daniel Vetter wrote: > On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas > wrote: [snip] >> >> I believe the correct fix would be for the fbdev core to keep a list of >> the apertures struct that are passed to remove_conflicting_framebuffers(), >&

Re: [Intel-gfx] [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

On 4/5/22 11:24, Daniel Vetter wrote: > On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas [snip] >> >> This is how I think that work, please let me know if you see something >> wrong in my logic: >> >> 1) A PCI device of OF device is registered for the

  1   2   >