Hi Thomas,
On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> > > Remove the unused flags FB
Hi Thomas,
On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit
Hi Thomas,
> > > - if (helper->funcs->fb_dirty) {
> > > - drm_fb_helper_memory_range_to_clip(info, pos, ret,
> > > _area);
> > > - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> > > - drm_rect_width(_area),
> > > -
/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
tly 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
> 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
>
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 struct
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
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:
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,
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,
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
Hi Nirmoy,
On Tue, Jan 17, 2023 at 07:04:16PM +0100, Nirmoy Das wrote:
> Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
> with proper APIs.
Thanks for working on this!
Also thanks for Christian to take care and apply the patches.
Sam
On Tue, Jan 17, 2023 at 06:44:47PM +0100, Nirmoy Das wrote:
> There are no current users of DRM_DEBUG_KMS_RATELIMITED()
> so remove it.
Thanks
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sa
a very nice reduction of bloat! I hope this has a measureable
effect on building times.
I was working on something similar, but that approach only added missing
includes, and did not kill all the unnessesary includes - which I think
is the biggest win here.
All patches are:
Reviewed-by: Sam Ravnbor
_hdmi.c
> index 477cb6985b4d..37dc66332bbd 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -8,8 +8,8 @@
> #include
> #include
>
> -#include
> #include
> +#include
Move one up to maintain sorting.
W
On Mon, Jan 16, 2023 at 02:12:18PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
ivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
Move it one line up to keep the sorting.
With this fixed:
Reviewed-by: Sam Ravnborg
> #include
> #include
&g
een the
header file and the implementation.
I think sparse would also complain that the function is not declared
or something like that.
With this fixed:
Reviewed-by: Sam Ravnborg
> #include
> #include
> #include
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lea
On Wed, Jan 11, 2023 at 02:02:01PM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . No functional
> changes. Include where the driver got the header file via
> .
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> driver
Hi Ville,
On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > Include in source files that need it. Some of DRM's
> > source code gets OF header via drm_crtc_helper.h and ,
> > which can leed to unnecessary
rtc_helper.h any longer.
Are you planning a clean-up of drm_crtc_helper.h later?
With a handful of forward it could losse all includes.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Christian König # amd
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
ix komeda build (kernel test robot)
Whole series are:
Acked-by: Sam Ravnborg
Except for the patches where I added an explicit r-b.
Sam
Hi Javier,
>
> >>>
> >>> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> >>> + ret = drm_drv_enabled();
> >>
> >> 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 mentioned
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
Hi Thomas,
On Wed, Aug 04, 2021 at 08:30:41PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.08.21 um 17:00 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Tue, Aug 03, 2021 at 11:07:01AM +0200, Thomas Zimmermann wrote:
> > > Drop the DRM IRQ midlayer in
he functionality.
>
> v2:
> * drop IRQ_NOTCONNECTED test from atmel-hlcdc (Sam)
> * use devm_request_irq() in atmel-hlcdc (Sam)
> * unify variable names in arm/hlcdc (Sam)
>
> Thomas Zimmermann (14):
The following patches are all:
Acked-by: Sam Ravnborg
&
Hi Thomas,
On Tue, Aug 03, 2021 at 11:07:01AM +0200, Thomas Zimmermann wrote:
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
>
> DRM IRQ callbacks are now being called directly
Hi Thomas,
> >
> > 1) IRQ_NOTCONNECTED
> >
> > We do not have this check in drm_irq today and we should avoid spreading
> > it all over. We are either carrying it forever or we wil lsee patches
> > floating in to drop the check again.
> > The current use in the kernel is minimal:
> >
Hi Thomas,
On Tue, Jul 27, 2021 at 08:27:07PM +0200, Thomas Zimmermann wrote:
> DRM's IRQ helpers are only helpful for old, non-KMS drivers. Move
> the code behind CONFIG_DRM_LEGACY. Convert KMS drivers to Linux
> IRQ interfaces.
>
> DRM provides IRQ helpers for setting up, receiving and
Hi Thomas,
>
> Are you sure, you're testing with the latest drm-misc-next or drm-tip?
> Because using irq_enabled is deprecated and the flag was recently replaced
> by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in VBLANK ioctls").
I was looking at drm-misc-fixes which did not have
Hi Dan,
> >
> > I think I got it - we need to set irq_enabled to true.
> > The documentation says so:
> > "
> > * @irq_enabled:
> > *
> > * Indicates that interrupt handling is enabled, specifically
> > vblank
> > * handling. Drivers which don't use
Hi Dan,
> >>
> >> Just to be sure...
> >> Can you confirm that vbltest is working OK *before* this patch?
> >
> > Yes, can you please verify that it regressed. If so, this would mean
> > that the driver misses vblank interrupts with the patch applied.
>
> Yes, unfortunately the vbltest works
Hi Dan,
thanks for the quick feedback!
On Wed, Jul 28, 2021 at 05:50:34PM +, dan.sned...@microchip.com wrote:
> On 7/28/21 8:44 AM, Sam Ravnborg wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Hi D
Hi Dan,
On Wed, Jul 28, 2021 at 03:11:08PM +, dan.sned...@microchip.com wrote:
> On 7/28/21 7:00 AM, Sam Ravnborg wrote:
> > [You don't often get email from s...@ravnborg.org. Learn why this is
> > important at http://aka.ms/LearnAboutSenderIdentification.]
> >
&
ed behind
> CONFIG_DRM_LEGACY.
>
> All callers have been updated.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_irq.c | 63 ---
You could have pulled it all into drm_legacy_misc.c.
> drivers/gpu/drm/drm_leg
Hi Dan,
I hope you can fine to test this patch from Thomas.
If this works then we can forget about my attempt to do the same.
Hi Thomas,
IRQ_NOTCONNECTED check seems redundant, as mentioned in another patch
already.
With that considered:
Reviewed-by: Sam Ravnborg
We shall wait for testing
gt; + return -ENOTCONN;
The code above is almost redundandt as request_irq has the same check.
The only benefit of this check is that we avoid calling
hdlcd_irq_preinstall().
And IRQ_NOTCONNECTED is only set for PCI devices which this is not.
So I would thing the if () should be dropped here.
Hi Thomas,
On Tue, Jul 27, 2021 at 08:27:07PM +0200, Thomas Zimmermann wrote:
> DRM's IRQ helpers are only helpful for old, non-KMS drivers. Move
> the code behind CONFIG_DRM_LEGACY. Convert KMS drivers to Linux
> IRQ interfaces.
>
> DRM provides IRQ helpers for setting up, receiving and
Hi Alex,
On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Fixes for 5.14. The big change here is unifying the SMU13 code. This was
> new code added in 5.14 to support Yellow Carp, but we've since cleaned it
> up and removed a lot of duplication, so better to
.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.pdev
>
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
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
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
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:
> >
Hi Lee,
> > the *d.h headers are supposed to just be hardware definitions. I'd
> > prefer to keep driver stuff out of them.
>
> That's fine (I did wonder if that were the case).
>
> I need an answer from you and Sam whether I can create new headers.
>
> For me, it is the right thing to do.
On Mon, Nov 09, 2020 at 08:10:13PM +, Lee Jones wrote:
> On Mon, 09 Nov 2020, Sam Ravnborg wrote:
>
> > Hi Alex,
> > On Mon, Nov 09, 2020 at 02:50:35PM -0500, Alex Deucher wrote:
> > > On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
> > > >
>
Hi Alex,
On Mon, Nov 09, 2020 at 02:50:35PM -0500, Alex Deucher wrote:
> On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Function parameter or
> > member 'dev' not described in
Hi Lee,
> >
> > Other public functions in radeon_device.c have their prototype in
> > radeon.h - for example radeon_is_px()
> >
> > Add radeon_device_is_virtual() there so we avoiid this new header.
>
> Oh yes, I remember why this wasn't a suitable solution now:
>
> The macro "radeon_init" in
On Sat, Nov 07, 2020 at 06:41:38PM +, Lee Jones wrote:
> On Sat, 07 Nov 2020, Sam Ravnborg wrote:
>
> > Hi Christian.
> >
> > > I'm not sure if we want to do some of the suggested changes to radeon.
> >
> > All patches for radeon looks goo
Hi Christian.
> I'm not sure if we want to do some of the suggested changes to radeon.
All patches for radeon looks good to me except "drm/radeon/radeon: Move
prototype into shared header".
Acked-by: Sam Ravnborg
from me to have them applied (except the shared header one)
Hi Lee,
On Fri, Nov 06, 2020 at 09:49:47PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Function parameter or
> member 'dev' not described in 'radeon_info_ioctl'
> drivers/gpu/drm/radeon/radeon_kms.c:226:
Hi Lee,
On Fri, Nov 06, 2020 at 09:49:40PM +, Lee Jones wrote:
> Unfortunately, a suitable one didn't already exist.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no previous prototype
> for ‘radeon_device_is_virtual’
Hi Lee and DRM folks.
On Fri, Nov 06, 2020 at 09:49:30PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There are 5000 warnings to work through. It will take
Hi Lee.
On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Thanks for looking into this.
> There are 5000 warnings to work through.
ves the rsp
> code from both, bochs and fbdev.
>
> v5:
> * implement fb_read/fb_write internally (Daniel, Sam)
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
>
> Signed-off-by: Thomas Zi
On Fri, Oct 16, 2020 at 02:19:42PM +0200, Thomas Zimmermann wrote:
> Hi
>
> On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
>
> > Hi Thomas.
> >
> > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > > At least sparc64 requi
nsider it fixed for real now and not just a workaround.
I also tested with:
qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial stdio
and it worked in both cases too.
All the comments above so future-me have an easier time finding how to
reproduce.
Tested-by: Sam Ravnborg
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/dma-buf-map.h |
* move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
I have been offline for a while so have not followed all the threads on
this. So may comments below may well be addressed but I failed to see
it.
If the point about fb_sync is already address
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
Looks good.
Reviewed-by:
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
Cc: amd-gfx@lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_encoders.c| 24 +--
.../gpu
: Patrik Jakobsson
Cc: Paweł Chmiel
Cc: Philippe CORNU
Cc: Rob Clark
Cc: Robert Chiras
Cc: Rodrigo Vivi
Cc: Sam Ravnborg
Cc: Sebastian Reichel
Cc: Thierry Reding
Cc: Tomi Valkeinen
Cc: "Ville Syrjälä"
Cc: Vinay Simha BN
Cc: Wambui Karuga
Cc: Zheng Bin
Sam Ra
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
Cc: amd-gfx@lists.freedesktop.org
Cc: Sam Ravnborg
---
.../gpu/drm/amd/amdgpu/atombios_encoders.c| 19
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
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
Cc: amd-gfx@lists.freedesktop.org
Cc: Sam Ravnborg
---
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 15
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
Cc: amd-gfx@lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_encoders.c| 23 ++-
.../gpu
Ravnborg
Cc: Sebastian Reichel
Cc: Thierry Reding
Cc: Tomi Valkeinen
Cc: "Ville Syrjälä"
Cc: Vinay Simha BN
Cc: Wambui Karuga
Cc: Zheng Bin
Sam Ravnborg (22):
backlight: Silently fail backlight_update_status() if no device
backlight: Add DECLARE_* macro for device re
On Fri, May 08, 2020 at 10:55:42AM +0100, Emil Velikov wrote:
> On Fri, 8 May 2020 at 09:16, Christian König wrote:
> >
> > Am 07.05.20 um 20:03 schrieb Sam Ravnborg:
> > > Hi Emil.
> > >
> > > On Thu, May 07, 2020 at 04:07:52PM +0100, Emi
Hi Emil.
On Thu, May 07, 2020 at 04:07:52PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> The driver does not hold struct_mutex, thus using the locked version of
> the helper is incorrect.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: amd-gfx@lists.freedesktop.org
> Fixes:
On Thu, Mar 26, 2020 at 10:09:58PM +0100, Wolfram Sang wrote:
> We are deprecating calls which return NULL in favor of new variants which
> return an ERR_PTR. Only build tested.
>
>
> Wolfram Sang (6):
> drm/amdgpu: convert to use i2c_new_client_device()
> drm/gma500: convert to use
On Fri, Mar 27, 2020 at 04:45:09PM +0100, Wolfram Sang wrote:
>
> > > > > Move away from the deprecated API.
> > > > >
> > > > > Signed-off-by: Wolfram Sang
> > > >
> > > > patches 1,6, are:
> > > > Acked-by: Alex Deucher
> > > Should we commit all to drm-misc-next?
> >
> > I'm fine to see it
On Fri, Mar 27, 2020 at 10:25:16AM -0400, Alex Deucher wrote:
> On Thu, Mar 26, 2020 at 5:35 PM Wolfram Sang
> wrote:
> >
> > Move away from the deprecated API.
> >
> > Signed-off-by: Wolfram Sang
>
> patches 1,6, are:
> Acked-by: Alex Deucher
Should we commit all to drm-misc-next?
On Thu, Mar 19, 2020 at 03:19:54PM +0100, Sam Ravnborg wrote:
> On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> > Thomas Zimmermann had made a nice patch-set that introduced
> > drm_simple_encoder_init() which is already present in drm-misc-next.
> &g
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functiona
the approach implemented
here smelled like middle-layer.
IMO this is not so, it is just a way to handle cleanup
for the simple cases.
Sam
Sam Ravnborg (3):
drm: drm_encoder_init() => drm_encoder_init_funcs()
drm: drm_simple_encoder_init() => drm_encoder_init()
drm/atmel
to reflect this.
And adjust the name to drm_encoder_init().
Drop include of drm_simple_kms_helper.h in the touched
drivers as it is no logner required.
Signed-off-by: Sam Ravnborg
Cc: Dave Airlie
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: David Airlie
were ignored.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: NXP Linux Team
Cc: Laurent Pinchart
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-media
atmel-hlcdc has no need to extend the functionality of the
encoder, so use drm_encoder_init().
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
---
drivers/gpu/drm
t; #include
> -#include
> #include "amdgpu.h"
> #include "amdgpu_amdkfd.h"
> #include "sdma0/sdma0_4_2_2_offset.h"
Thanks!
All patches are:
Acked-by: Sam Ravnborg
Actual status in drm-misc:
$ git grep drmP | cut -d '/' -f 1 | sort | uniq -c
18
> > - added Acked-by in patch 2
> > - made the ownership of ddc i2c_adapter explicit in all patches,
> > this made the affected patches much simpler
>
> Looks good now.
> Patch 1 and 2 are:
> Reviewed-by: Sam Ravnborg
>
> The remaining patches are:
> Acked-
of patch 1
> - added kernel-doc for drm_connector_init_with_ddc()
> - improved kernel-doc for the ddc field of struct drm_connector
> - added Reviewed-by in patches 17 and 18
> - added Acked-by in patch 2
> - made the ownership of ddc i2c_adapter explicit in all patches,
&g
at the patches before. Sorry
for providing feedback this late.
Sam
On Fri, Jul 26, 2019 at 08:37:59AM +0200, Sam Ravnborg wrote:
> Hi Andrzej.
>
> Patch looks good, but one kernel-doc detail.
>
> On Wed, Jul 24, 2019 at 03:59:23PM +0200, Andrzej Pietrasiewicz wrote:
>
Hi Andrzej.
Patch looks good, but one kernel-doc detail.
On Wed, Jul 24, 2019 at 03:59:23PM +0200, Andrzej Pietrasiewicz wrote:
> Add generic code which creates symbolic links in sysfs, pointing to ddc
> interface used by a particular video output. For example:
>
> ls -l
Hi Andrzej.
On Wed, Jul 24, 2019 at 03:59:24PM +0200, Andrzej Pietrasiewicz wrote:
> Allow passing ddc adapter pointer to the init function. Even if
> drm_connector_init() sometime in the future decides to e.g. memset() all
> connector fields to zeros, the newly added function ensures that at its
Hi Andrej.
On Tue, Jul 23, 2019 at 02:44:50PM +0200, Andrzej Pietrasiewicz wrote:
> Hi Sam,
>
> W dniu 23.07.2019 o 11:05, Sam Ravnborg pisze:
> > Hi Andrzej
> >
> > On Thu, Jul 11, 2019 at 01:26:41PM +0200, Andrzej Pietrasiewicz wrote:
> > > Use the
Hi Andrzej.
On Thu, Jul 11, 2019 at 01:26:44PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/ast/ast_mode.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff
Hi Andrzej.
On Thu, Jul 11, 2019 at 01:26:43PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
Hi Andrzej
On Thu, Jul 11, 2019 at 01:26:41PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Tue, Jun 25, 2019 at 10:42:05PM +0200, Daniel Vetter wrote:
> That way we can ditch our gem_prime_res_obj implementation. Since ttm
> absolutely needs the right reservation object all the boilerplate is
> already there and we just have to wire it up correctly.
>
> Note that gem/prime doesn't
Hi Arnd.
On Mon, Jun 17, 2019 at 02:38:55PM +0200, Arnd Bergmann wrote:
> Some randconfig builds fail to compile the dcn10 code because of
> a missing declaration:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
> function 'dcn10_apply_ctx_for_surface':
>
Hi Daniel.
Minor nitpick..
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 65d599065709..4fd09a9ad67a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -3193,7 +3193,7 @@ static struct drm_driver driver = {
>
1 - 100 of 131 matches
Mail list logo
