On Fri, Jul 18, 2025 at 01:34:13PM -0300, Luiz Otavio Mello wrote:
> Includes the missing file drm_device.h, which was unintentionally
> omitted in v1.
>
> i915 is the only remaining user of struct_mutex lock.
>
> Move it from drm_device to drm_i915_private so it is only used within
> the i915 dr
RM_FBDEV_DMA_DRIVER_OPS macro (Sam)
> v2:
> - use drm_client_setup_with_fourcc()
>
> Signed-off-by: Thomas Zimmermann
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Claudiu Beznea
Acked-by: Sam Ravnborg
t;
> v2:
> - use drm_client_setup_with_fourcc()
>
> Signed-off-by: Thomas Zimmermann
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Claudiu Beznea
Hi Thomas.
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 +++-
> 1 file chan
Hi Thomas,
> > > - if (helper->funcs->fb_dirty) {
> > > - drm_fb_helper_memory_range_to_clip(info, pos, ret,
> > > &damage_area);
> > > - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> > > - drm_rect_width(&damage_area),
> > > -
drivers/gpu/drm/drm_fb_helper.c| 107 -
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/display/intel_fbdev.c | 14 +--
> include/drm/drm_fb_helper.h| 39
> 5 files changed, 9 insertions(+), 155 deletions(-)
Nice diffstat!
Assuming there is a good explanation on the dirty check:
Reviewed-by: Sam Ravnborg
bdev-generic and i915 need them. Both will be updated to implement
> damage handling by themselves and the exported functions will be removed.
>
> v4:
> * update interfaces
>
> Signed-off-by: Thomas Zimmermann
Assuming there is a good answer why there is no dirty ch
I/O helpers
> drm/tegra: Use regular fbdev I/O helpers
These are all:
Acked-by: Sam Ravnborg
Hi Thomas,
On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Use an fbdev generator macro for
> deferred I/O to create the fbdev callbacks. i915 was the only
> caller of the DRM helpers, so r
pers directly within each DRM fbdev emulation,
> we can eventually remove DRM's wrapper functions entirely.
>
> v4:
> * use initializer macros for struct fb_ops
> v2:
> * use FB_IO_HELPERS option
>
> Signed-off-by: Thomas Zimmermann
> Cc: Russell King
Acked-by: Sam Ravnborg
so maybe it is just me.
And everything looks consistent, so OK.
With the white space issues fixed:
Reviewed-by: Sam Ravnborg
lify
> fbdev's driver configs.
>
> v3:
> * fix select statement (Jingfeng)
>
> Signed-off-by: Thomas Zimmermann
I like these, thanks.
Reviewed-by: Sam Ravnborg
Hi Thomas,
On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Armada does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly
Hi Thomas,
On Mon, May 15, 2023 at 11:40:24AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Exynos does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly
Hi Thomas,
> >
> > Nice cleanup.
> >
> > From one of the patches:
> >
> > > +config DRM_ARMADA_FBDEV_EMULATION
> > > + bool
> > > + depends on DRM_ARMADA
> > > + select FB_CFB_COPYAREA
> > > + select FB_CFB_FILLRECT
> > > + select FB_CFB_IMAGEBLIT
> >
> > This seems like a
Hi Thomas,
On Fri, May 12, 2023 at 10:41:41AM +0200, Thomas Zimmermann wrote:
> DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
> and fb_sys_() helpers. The DRM functions don't provide any additional
> functionality for most DRM drivers. So remove them and call the fbdev
> I
Hi Thomas,
On Tue, Mar 28, 2023 at 01:14:20PM +0200, Thomas Zimmermann wrote:
> Initialize i915's fbdev client by giving an instance of struct
> drm_client_funcsi to drm_client_init(). Also clean up with
An extra i had sneaked in here
Sam
On Fri, Jan 27, 2023 at 03:21:30PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 25.01.23 um 22:03 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> > > Initialize the fb-helper structure immed
On Fri, Jan 27, 2023 at 03:13:50PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 25.01.23 um 21:52 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> > > Test for connectors in the client code and
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> Test for connectors in the client code and remove a similar test
> from the generic fbdev emulation. Do nothing if the test fails.
> Not having connectors indicates a driver bug.
>
> Signed-off-by: Thomas Zimmermann
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> Initialize the fb-helper structure immediately after its allocation
> in drm_fbdev_generic_setup(). That will make it easier to fill it with
> driver-specific values, such as the preferred BPP.
>
> Signed-off-by: Thom
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:
> Signal failed hotplugging with a flag in struct drm_client_dev. If set,
> the client helpers will not further try to set up the fbdev display.
>
> This used to be signalled with a combination of cleared pointers in
>
Hi Thomas,
a quick drive-by comment.
On Mon, Jan 23, 2023 at 11:05:59AM +0100, Thomas Zimmermann wrote:
> The generic fbdev emulation names variables of type struct fb_info
> both 'fbi' and 'info'. The latter seems to be more common in fbdev
> code, so name fbi accordingly.
>
> Also replace the
off-by: Nirmoy Das
Thanks for adding this.
The patch as-is is:
Reviewed-by: Sam Ravnborg
It would have been nice to start adding kernel-doc to the
non-deprecated logging functions. But as everyone else is missing this,
it is OK that we miss it here.
A couple of nice follow-up patches would be
acs do currently depend on drm_framebuffer.h without
> actually including it directly. All of those need to be fixed
> up.
>
> v2: Fix up msm some more
> v2: Deal with ingenic and shmobile as well
>
> Signed-off-by: Ville Syrjälä
Acked-by: Sam Ravnborg
> ---
> drivers
ideo/vbox_mode.c
> index 4017b0a621fc..52eaa10712ec 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
ditto
> #include
> #include
> #include
With the above fixed:
Acked-by: Sam Ravnborg
the rest I trust the robots.
So with the reported builderrros fixed and my alphabetic order comment
addressed, then the full series are:
Acked-by: Sam Ravnborg
Sam
> Quite a few placs do currently depend on drm_blend.h without
> actually including it directly. All of those need to be fixed
> up.
>
> Signed-off-by: Ville Syrjälä
With the commit message fixed:
Acked-by: Sam Ravnborg
n dev, oldmode;
> identifier newmode;
> @@
> - newmode = drm_mode_create(dev);
> + newmode = drm_mode_duplicate(dev, oldmode);
> ...
> - drm_mode_copy(newmode, oldmode);
>
> Signed-off-by: Ville Syrjälä
> Cc: Thierry Reding
> Cc: Sam Ravnborg
Looks good,
Acked-by: Sam Ravnborg
ton
> Cc: Greg Kroah-Hartman
> Cc: linux-stag...@lists.linux.dev
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Helge Deller
> Cc: Matthew Wilcox
> Cc: Sam Ravnborg
> Cc: Tetsuo Handa
> Cc: Zhen Lei
> Cc: Alex Deucher
> Cc: Xiyu Yang
> Cc: linux-
Hi Daniel,
On Tue, Feb 08, 2022 at 03:03:28PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > > Accessing the one in fbmem.c witho
On Tue, Feb 08, 2022 at 02:58:21PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > > There's a bunch of confusions going on her
On Tue, Feb 08, 2022 at 02:53:59PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > > No idea why con2fb_acquire_newinfo() initializes much less than
> > >
Hi Daniel,
On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > There's two minor behaviou
Hi Daniel,
On Tue, Feb 08, 2022 at 02:46:33PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > > It was only used by fbcon, and that now switched to its own,
Hi Daniel,
On Tue, Feb 08, 2022 at 02:42:25PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > &
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> Accessing the one in fbmem.c without taking the right locks is a bad
> idea. Instead maintain our own private copy, which is fully protected
> by console_lock() (like everything else in fbcon.c). That copy is
> serialized
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> There's a bunch of confusions going on here:
> - The deferred fbcon setup notifier should only be cleaned up from
> fb_console_exit(), to be symmetric with fb_console_init()
> - We also need to make sure we don't race wi
on_open also allocating the fbcon_ops structure.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Tetsuo Handa
> Cc: Greg Kroah-Hartman
> Cc: Du Cheng
> Cc: Claudio Suarez
Thanks, like I wrote earlier this makes sense.
Acked-by: Sam Ravnborg
>
> With this the do_fb_ioctl() handler is the only code in fbmem.c still
> calling console_lock().
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Thomas Zimmermann
> Cc: Du Cheng
> Cc: Claudio Suarez
> Cc: Greg Kroah-Hartman
> Cc: Tetsuo Handa
&
as explicit that the
deferred_takeover falg is moved to the worker function to reset it as
late as possible.
With the commit log updated:
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/core/fbcon.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
n't be worse than what we had from a "can you trigger
> races?" pov, but it's at least clearer.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Claudio Suarez
> Cc: Tetsuo Handa
> Cc: Thomas Zimmermann
> Cc: Greg Kroah-Hartman
> Cc:
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> No idea why con2fb_acquire_newinfo() initializes much less than
> fbcon_startup(), but so be it. From a quick look most of the
> un-initialized stuff should be fairly harmless, but who knows.
>
> Signed-off-by: Daniel Vetter
> Cc: D
Hi Daniel,
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would dr
On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> It was only used by fbcon, and that now switched to its own,
> private work.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: linux-fb...@vger.kernel.org
I would merge this with the patch that drops the usage
> ---
> inc
On Mon, Jan 31, 2022 at 10:05:40PM +0100, Daniel Vetter wrote:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Tetsuo Handa
> Cc: Greg Kroah-Hartman
> Cc: Du Cheng
> Cc: Thomas Zimmermann
> Cc: Claudi
; bigger fish to fry.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: Daniel Vetter
> Cc: Qing Wang
> Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
otential for use-after free mixups.
>
> First step is to encapsulate the lookup.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: Tetsuo Handa
> Cc: Du Cheng
> Cc: Claudio Suarez
> Cc: Thomas Zimmermann
Acked-by: Sam Ravnborg
On Mon, Jan 31, 2022 at 10:05:43PM +0100, Daniel Vetter wrote:
> It doesn't ever fail anymore.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Thomas Zimmermann
> Cc: Greg Kroah-Hartman
> Cc: Claudio Suarez
> Cc: Du Cheng
> Cc: Tetsuo Handa
Acked-by: Sam Ravnborg
if (newinfo && newinfo->fbops->fb_set_par) {
> - ret = newinfo->fbops->fb_set_par(newinfo);
> + fbcon_del_cursor_work(oldinfo);
> + kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_data);
> + kfree(ops->cur
g in this patch.
Also, the comment is wrong as info_idx is set in several places.
Like set_con2fb_map(), fbcon_remap_all(), and more.
Though it is not set by fb_console_init - so partly OK.
With the comment adjustment dropped.
Acked-by: Sam Ravnborg
at least the code deletion looked OK, I failed
t otherwise git log says I'm
> the one who's stuck with this.
>
> 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
Du Cheng
> Cc: Tetsuo Handa
> Cc: Claudio Suarez
> Cc: Greg Kroah-Hartman
Acked-by: Sam Ravnborg
Hi Javier,
>
> >>>
> >>> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> >>> + ret = drm_drv_enabled(&driver);
> >>
> >> You pass the local driver variable here - which looks wrong as this is
> >> not the same as the driver variable declared in another file.
> >
>
> Yes, Jani ment
Hi Javier,
On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
> Some DRM drivers check the vgacon_text_force() function return value as an
> indication on whether they should be allowed to be enabled or not.
>
> This function returns true if the nomodeset kernel command lin
Hi Daniel,
On Thu, Aug 12, 2021 at 03:14:12PM +0200, Daniel Vetter wrote:
> Aside from deleting lots of code the real motivation here is to switch
> the mmap over to VM_PFNMAP, to be more consistent with what real gpu
> drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
> work, a
t;fbdev)
> /* drm_fbdev_fb_destroy() takes care of cleanup */
> drm_fb_helper_unregister_fbi(fb_helper);
I could not find any better spot to clear deferred_setup - so I think
this is OK.
With the two spellign issues fixed:
Acked-by: Sam Ravnborg
No r-b as I an not too fluent in these code paths and all the locking.
Sam
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
on top to make sure we don't have
> strange combinations of hooks: cleanup_fb without prepare_fb doesn't
> make sense, and since simpler drivers are all new they better be GEM
> based drivers.
>
> v2: Warn and bail when it's _not_ a GEM driver (Noralf)
>
> v3
_uid to the right place too
> (Sam)
>
> Acked-by: Christian König
> Cc: Sam Ravnborg
> Reviewed-by: Alex Deucher
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: Alex Deucher
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc
prepare_fb hook set,
drm_gem_plane_helper_prepare_fb() is called automatically to
implement this.
"
But anyway is fine and with the typo fixed:
Acked-by: Sam Ravnborg
Sam
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Daniel,
On Tue, Jun 22, 2021 at 06:55:08PM +0200, Daniel Vetter wrote:
> It's tedious to review this all the time, and my audit showed that
> arcpgu actually forgot to set this.
>
> Make this the default and stop worrying.
>
> Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
>
Hi Daniel,
On Tue, Jun 22, 2021 at 06:55:03PM +0200, Daniel Vetter wrote:
> There's a bunch of atomic drivers who don't do this quite correctly,
> luckily most of them aren't in wide use or people would have noticed
> the tearing.
>
> By making this the default we avoid the constant audit pain an
Hi Daniel,
On Tue, Jun 22, 2021 at 06:54:57PM +0200, Daniel Vetter wrote:
> Oversight from
>
> commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> Author: Christian König
> Date: Mon May 10 16:14:09 2021 +0200
this is what we uses Fixes: ... for.
It looks wrong to hide it in the description.
The attachment_uid member of @sysfs_entry is protected by dma_resv lock
> * and is incremented on each attach.
belongs to the paragraph describing sysfs_entry and should be moved too.
Or maybe reworded and then document all fields in dma_buf_sysfs_entry?
With this fixed:
Acked-by: Sam Ravnborg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ce.pdev
> drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
All above are:
Acked-by: Sam Ravnborg
> drm/nouveau: Remove references to struct drm_device.pdev
I lost my confidence in my reading of this code.
> drm/i915: Remove references to struct drm_device.pde
Hi Thomas,
On Tue, Nov 24, 2020 at 12:38:24PM +0100, Thomas Zimmermann wrote:
> We have DRM drivers based on USB, SPI and platform devices. All of them
> are fine with storing their device reference in struct drm_device.dev.
> PCI devices should be no exception. Therefore struct drm_device.pdev is
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:18PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Ben Skeggs
Suggestion to an alternative implmentation below.
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:14PM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert gma500 to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Patrik Jakobsson
This patch includes several whitespace chang
Hi James.
> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6q
ing turned up the following:
- The example in drm_drv needs to be updated
- legacy drivers, that are obviously not converted - but worth to
mention above
- arc is not converted and it is not legacy
Maybe you have it covered in your big arc conversion patch?
With the above fixed:
Acked-by: Sam R
s Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Daniel Vetter
Some of the conditionals does not help the readability :-(
But they are better than exposing legacy stuff to non-legacy drivers.
And it is a suprising fews that are required.
So legacy seems to be fact
dev->driver = (struct drm_driver *) driver;
checkpatch will tell you to drop space after closing ')'
With this super important fix the patch is:
Reviewed-by: Sam Ravnborg
> +#else
> dev->driver = driver;
> +#endif
>
> INIT_LIST_HEAD(&dev->mana
ndeed dma-buf is the only relevant user in drm then
I am totally fine with the current naming.
One alternative named that popped up in my head: struct sys_io_map {}
But again, if this is kept in dma-buf then I am fine with the current
naming.
In other words, if you continue to th
Hi Thomas.
Sorry for chiming in late here, have been offline for a while.
On Fri, Sep 25, 2020 at 01:55:57PM +0200, Thomas Zimmermann wrote:
> Dma-buf provides vmap() and vunmap() for retriving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
>
Hi Daniel.
On Fri, Sep 04, 2020 at 03:42:44PM +0200, Daniel Vetter wrote:
> On Fri, Apr 24, 2020 at 6:46 PM Sam Ravnborg wrote:
> >
> > Hi Daniel.
> >
> > On Wed, Apr 15, 2020 at 09:40:15AM +0200, Daniel Vetter wrote:
> > > Upcasting using a container_o
Hi Anitha.
Feedback on kmb_dsi.
The main feedback can be found after the kmb_dsi_init function.
The highligt of the feedback is that, in my opinion, the
best would be to use the drm_bridge abstraction for the kmb_dsi.
Maybe because I am biased - and this is just overhead.
But it just looks simple
LCD controller->mipi DSI-> ADV bridge
>
> Only 1080p resolution and single plane is supported at this time.
>
> v2: moved extern to .h, removed license text
> use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.
>
> v3: Squashed all 59 commits to one
Hi Thomas.
On Thu, Aug 13, 2020 at 10:36:44AM +0200, Thomas Zimmermann wrote:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by sev
Hi Anitha.
On Mon, Aug 03, 2020 at 09:02:24PM +, Chrisanthus, Anitha wrote:
> Hi Sam,
> I installed codespell, but the dictionary.txt in
> usr/share/codespell/dictionary.txt
> seems to be different from yours. Mine is version 1.8. Where can I get the
> dictionary.txt
> that you are using?
I
LCD controller->mipi DSI-> ADV bridge
>
> Only 1080p resolution and single plane is supported at this time.
>
> v2: moved extern to .h, removed license text
> use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.
>
> v3: Squashed all 59 commits to one
Hi Anitha.
A few extra details.
> diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
> new file mode 100644
> index 000..570d46e
> --- /dev/null
> +++ b/drivers/gpu/drm/kmb/kmb_crtc.c
> @@ -0,0 +1,219 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyrig
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote:
> Hi Anitha
>
> On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> > This is a new DRM driver for Intel's KeemBay SOC.
> > The SoC couples an ARM Cortex A53 CPU with an Intel
> > Movidius VPU.
> >
> > This driver is
Hi Anitha.
On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC.
ns
> everywhere.
>
> v2:
> - Also delete the workqueue (Sam)
> - drop the @commit kerneldoc, I missed that one.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
>
Hi,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
> Hi,
>
> On 7/9/20 4:14 PM, Sam Ravnborg wrote:
> > Hi Hans.
> >
> > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> > > Hi All,
> > >
> > > Here is v4 of
Hi Hans.
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v4 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.
Why is it that i
fmann
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 20
> 1 file changed, 20 deletions(-)
Very nice catch:
Reviewed-by: Sam Ravnborg
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/dri
s
> everywhere.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: linux-arm-ker...@lists.infradead.org
Looks good, nice to see all this code deleted!
This more or less mat
Hi Anitha.
On Tue, Jun 30, 2020 at 02:27:12PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
...
Nice and informative intro - thanks.
The patchset looks more like a dump of current state an
ermann
> Cc: David Airlie
> Cc: Daniel Vetter
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_irq.c | 2 +-
> drivers/gpu/drm/drm_vblank.c| 14 +++---
> 3 files changed, 9 insertions(+), 9 deletions
Hi Ville.
On Thu, May 14, 2020 at 09:40:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make it easier to figure out what caused a particular debug
> message let's print out aux->name.
>
> v2: Convert drm_dp_send_real_edid_checksum() too
>
> C
On Tue, Apr 28, 2020 at 04:12:21PM +0200, Daniel Vetter wrote:
> On Fri, Apr 24, 2020 at 08:10:02PM +0200, Sam Ravnborg wrote:
> > On Wed, Apr 15, 2020 at 09:40:31AM +0200, Daniel Vetter wrote:
> > > Since aspeed doesn't use devm_kzalloc anymore we can use the managed
&g
On Tue, Apr 28, 2020 at 04:00:11PM +0200, Daniel Vetter wrote:
> On Fri, Apr 24, 2020 at 05:09:11PM +0200, Sam Ravnborg wrote:
> > Hi Daniel
> >
> > On Wed, Apr 15, 2020 at 09:40:01AM +0200, Daniel Vetter wrote:
> > > Also need to remove the drm_dev_put from the remo
mit_tail()
So it seems you are right.
>
> Signed-off-by: Daniel Vetter
> Cc: Alexey Brodkin
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpg
er
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
&g
On Wed, Apr 15, 2020 at 09:40:33AM +0200, Daniel Vetter wrote:
> This is only needed for hotpluggable connectors set up after
> drm_dev_register().
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
bs.org
> Cc: linux-arm-ker...@lists.infradead.org
Hmm, the helper function makes no sense, maybe embed it?
One Q below. Whith Q addressed:
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
&g
ast, which is faster anyway.
>
> Signed-off-by: Daniel Vetter
> Cc: Joel Stanley
> Cc: Andrew Jeffery
> Cc: linux-asp...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 ++
>
On Wed, Apr 15, 2020 at 09:40:29AM +0200, Daniel Vetter wrote:
> No longer used since the conversion to generic fbdev.
>
> Signed-off-by: Daniel Vetter
> Cc: Joel Stanley
> Cc: Andrew Jeffery
> Cc: linux-asp...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
A
On Wed, Apr 15, 2020 at 09:40:27AM +0200, Daniel Vetter wrote:
> That way we can get rid of this final piece of init code, and use the
> simple pipe helpers as intended.
>
> Signed-off-by: Daniel Vetter
> Cc: Alexey Brodkin
One nit below, with this addressed:
Acked-b
On Wed, Apr 15, 2020 at 09:40:26AM +0200, Daniel Vetter wrote:
> At less than 500 lines total feels like the right thing to do.
>
> Also noticed that the simple wrapper around drm_connector_cleanup can
> be dropped.
>
> Signed-off-by: Daniel Vetter
Acked-by: Sam Ravnborg
&g
1 - 100 of 347 matches
Mail list logo
