gt; return -ENOENT;
> }
>
> -static inline void add_taint_module(struct module *mod, unsigned flag,
> - enum lockdep_ok lockdep_ok)
> +void add_taint_module(struct module *mod, unsigned flag,
> + enum lockdep_ok lockdep_ok)
> {
> add_taint(flag, lockdep_ok);
> set_bit(flag, >taints);
> }
> +EXPORT_SYMBOL_GPL(add_taint_module);
>
> /*
> * A thread that wants to hold a reference to a module only while it
> diff --git a/kernel/panic.c b/kernel/panic.c
> index ec6d7d788ce7..504fb926947e 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -384,6 +384,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
> [ TAINT_LIVEPATCH ] = { 'K', ' ', true },
> [ TAINT_AUX ] = { 'X', ' ', true },
> [ TAINT_RANDSTRUCT ]= { 'T', ' ', true },
> + [ TAINT_FIRMWARE_CRASH ]= { 'Q', ' ', true },
> };
>
> /**
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 06, 2020 at 09:56:16AM +, Angelo Ribeiro wrote:
> From: Daniel Vetter
> Date: Tue, Apr 28, 2020 at 16:28:15
>
> > On Mon, Apr 27, 2020 at 04:00:35PM +0200, Angelo Ribeiro wrote:
> > > Add Synopsys DesignWare IPK specific extensions for Synopsys Design
On Thu, Apr 30, 2020 at 05:33:46PM +0200, Emmanuel Vadot wrote:
> Source file was dual licenced but the header was omitted, fix that.
> Contributors for this file are:
> Daniel Vetter
> Matt Roper
> Maxime Ripard
> Noralf Trønnes
> Thomas Zimmermann
>
> Acked-
On Tue, May 05, 2020 at 07:55:00AM +0200, Michał Orzeł wrote:
>
>
> On 04.05.2020 13:53, Daniel Vetter wrote:
> > On Fri, May 01, 2020 at 05:49:33PM +0200, Michał Orzeł wrote:
> >>
> >>
> >> On 30.04.2020 20:30, Daniel Vetter wrote:
> >>
On Fri, May 01, 2020 at 05:49:33PM +0200, Michał Orzeł wrote:
>
>
> On 30.04.2020 20:30, Daniel Vetter wrote:
> > On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
> >>
> >> On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
> >> wrote:
> >&
On Thu, Apr 30, 2020 at 09:10:07PM +0200, Paul Kocialkowski wrote:
> Hi Daniel,
>
> On Fri 03 Apr 20, 13:04, Daniel Vetter wrote:
> > On Fri, Apr 03, 2020 at 11:36:17AM +0200, Paul Kocialkowski wrote:
> > > Introduces a driver for the LogiCVC display controller, a
ned-off-by: Ira Weiny
I'm assuming this lands through some other tree or a topic branch or whatever.
Acked-by: Daniel Vetter
Cheers, Daniel
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
> in
eset_acquire_ctx ctx;
> > > int ret = -EINVAL;
> > >
> > > if (!drm_property_change_valid_get(prop, prop_value, ))
> > > return -EINVAL;
> > >
> > > - drm_modeset_lock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ct
On Thu, Apr 30, 2020 at 4:54 PM Emmanuel Vadot wrote:
>
> Source file was dual licenced but the header was omitted, fix that.
> Contributors for this file are:
> Daniel Vetter
> Matt Roper
> Maxime Ripard
> Noralf Trønnes
> Thomas Zimmermann
>
> Acked-by: No
On Wed, Apr 29, 2020 at 11:19:07AM +, k...@kl.wtf wrote:
> April 28, 2020 5:14 PM, "Daniel Vetter" wrote:
>
> > On Fri, Apr 24, 2020 at 06:26:15PM +0200, Kenny Levinsen wrote:
> >
> >> Some processes, such as systemd, are only polling for EPOLLERR|EP
On Tue, Apr 28, 2020 at 10:08:04PM +0300, Adrian Ratiu wrote:
> Hi Daniel,
>
> On Tue, 28 Apr 2020, Daniel Vetter wrote:
> > On Wed, Apr 22, 2020 at 04:07:27AM +0300, Laurent Pinchart wrote:
> > > Hi Adrian, On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu
> >
On Thu, Apr 30, 2020 at 09:47:46PM +0800, Xin Ji wrote:
> Hi Daniel,
>
> On Thu, Apr 30, 2020 at 03:38:39PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
>
On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > > O
On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote:
> > > >
> > &g
> > +#define DB9000_MAX_LAYER 1
> > +
> > +/* LCD Controller Control Register 1 */
> > +#define DB9000_CR1 0x000
> > +/* Horizontal Timing Register */
> > +#define DB9000_HTR 0x008
> > +/* Vertical Timing Regist
I.e. roll out better wrappers
first, once that's soaked through the tree, rename the last offenders.
Personally I like nr_cpu_ents and nr_dma_ents, that's about as clear as it
gets.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 27, 2020 at 04:00:35PM +0200, Angelo Ribeiro wrote:
> Add Synopsys DesignWare IPK specific extensions for Synopsys DesignWare
> MIPI DSI Host driver.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
*
> - * Horizontal refresh rate, for debug output in human readable form. Not
> - * used in a functional way.
> - *
> - * This value is in kHz.
> - */
> - int hsync;
> -
> - /**
>* @picture_aspect_ratio:
>*
>* Field for setting the HDMI picture aspect ratio of a mode.
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; break;
> }
> drm_property_change_valid_put(prop, ref);
> - drm_modeset_unlock_all(dev);
> + DRM_MODESET_LOCK_ALL_END(ctx, ret);
>
> return ret;
> }
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t drm_device *dev, struct
> drm_pending_event *e)
> list_del(>pending_link);
> list_add_tail(>link,
> >file_priv->event_list);
> - wake_up_interruptible(>file_priv->event_wait);
> + wake_up_interruptible_poll(>file_priv->event_wait
;event_list);
> - wake_up_interruptible(>file_priv->event_wait);
> + wake_up_interruptible_poll(>file_priv->event_wait,
> + EPOLLIN | EPOLLRDNORM);
> }
> EXPORT_SYMBOL(drm_send_event_locked);
>
> --
> 2.26.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d9b5540de68 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -6,6 +6,7 @@ config DRM_MEDIATEK
> > depends on COMMON_CLK
> > depends on HAVE_ARM_SMCCC
> > depends on OF
> > + depends on COMMON_CLK_MT8173_MMSYS
> > select DRM_GEM_CMA_HELPER
> > select DRM_KMS_HELPER
> > select DRM_MIPI_DSI
> > --
> > 2.17.1
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
c const struct component_ops imx_mipi_dsi_ops = {
> > + .bind = imx_mipi_dsi_bind,
> > + .unbind = imx_mipi_dsi_unbind,
> > +};
> > +
> > +static int imx_mipi_dsi_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > +
On Tue, Apr 21, 2020 at 05:55:38PM +0200, Neil Armstrong wrote:
> On 15/04/2020 19:33, Daniel Vetter wrote:
> > On Wed, Apr 15, 2020 at 02:29:28AM +0300, Eugeniy Paltsev wrote:
> >> The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI
> >> encoders. S
On Thu, Apr 23, 2020 at 11:18:45PM +0200, Lubomir Rintel wrote:
> On Tue, Apr 21, 2020 at 02:54:12PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 24, 2020 at 04:19:31PM +0100, Lubomir Rintel wrote:
> > > This is a driver for video encoder with VGA an
t;
> Right, understand your argument. I'm pondering if it's not just better
> to reject the mode rather than trying a timing that is definitely
> quite different from what the monitor was asking for. No super strong
> opinion, I'll let other people on the list weigh in.
Yeah mode_fixup is
) of privacy-screen on the
> + * panel, if present.
> + */
> + struct drm_property *privacy_screen_property;
> +
> /**
>* @writeback_fb_id_property: Property for writeback connectors, storing
>* the ID of the output framebuffer.
> diff --git a/include/drm/drm_privacy_screen.h
> b/include/drm/drm_privacy_screen.h
> new file mode 100644
> index ..c589bbc47656
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright © 2019 Google Inc.
> + */
> +
> +#ifndef __DRM_PRIVACY_SCREEN_H__
> +#define __DRM_PRIVACY_SCREEN_H__
> +
> +#ifdef CONFIG_ACPI
> +bool drm_privacy_screen_present(struct drm_connector *connector, u8 port);
> +void drm_privacy_screen_set_val(struct drm_connector *connector,
> + enum drm_privacy_screen val);
> +enum drm_privacy_screen drm_privacy_screen_get_val(struct drm_connector
> +*connector);
> +#else
> +static inline bool drm_privacy_screen_present(struct drm_connector
> *connector,
> + u8 port)
> +{
> + return false;
> +}
> +
> +void drm_privacy_screen_set_val(struct drm_connector *connector,
> + enum drm_privacy_screen val)
> +{ }
> +
> +enum drm_privacy_screen drm_privacy_screen_get_val(
> + struct drm_connector *connector)
> +{
> + return DRM_PRIVACY_SCREEN_DISABLED;
> +}
> +#endif /* CONFIG_ACPI */
> +
> +#endif /* __DRM_PRIVACY_SCREEN_H__ */
> --
> 2.23.0.866.gb869b98d4c-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Oct 22, 2019 at 10:53:57PM -0500, Navid Emamdoost wrote:
> On Tue, Oct 22, 2019 at 4:36 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 21, 2019 at 01:52:49PM -0500, Navid Emamdoost wrote:
> > > In the impelementation of v3d_submit_cl_ioctl() there are two memory
On Fri, Oct 18, 2019 at 02:23:52PM +0200, Gerd Hoffmann wrote:
> Be consistent with the rest of the code base.
>
> Signed-off-by: Gerd Hoffmann
Assuming sparse is all still pleased:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
> driv
orted, and still get to support bridges which are more
> > common.
> >
> > As/when improvements are made to the bridge code we can remove the
> > component bits and not lose anything.
>
> There was an idea a while back about using the device links code to
> solve the bridge issue - but at the time the device links code wasn't
> up to the job. I think that's been resolved now, but I haven't been
> able to confirm it. I did propose some patches for bridge at the
> time but they probably need updating.
I think the only patches that existed where for panel, and we only
discussed the bridge case. At least I can only find patches for panel,not
bridge, but might be missing something.
Either way I think device core is fixed now, so would be really great if
someone can give this another stab, and make drm_bridge/panel easier to
use without fireworks on unload.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
her bits above
m+n are cleared to all 0 or all 1. Unit test would be lovely too. Anyway:
Reviewed-by: Daniel Vetter
> + */
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> + uint32_t m, uint32_t n)
> +{
> + u64 mag = (user_in
> Yep, its not a real problem, I get a few like this every cycle.
Yeah totally within expectations when I acked that cleanup patch. We'll
probably have a few more lockdep annotation patches/changes that will
conflict in drm.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88b703527ba70659365d989f29579f1292ebf9c3
>
> (look for csc_drm_to_base)
>
> Would be great to have a common helper which correctly accounts for
> all the variability.
Yeah the sign-bit 31.32 fixed point format is probably the most ludicrous
uapi fumble we've ever done. A shared function, rolled out to drivers, to
switch it to a signed 2 complements integer sounds like a _very_ good
idea.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t;
> > +*/
> > + acrtc->mst_encoder->base.possible_crtcs =
> > + amdgpu_dm_get_encoder_crtc_mask(dm->adev);
>
> Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()?
If we don't have the same hack for i915 mst I think we shouldn't merge
this ... broken userspace is broken.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> On 05/10/2018 09:58, Daniel Vetter wrote:
> > > On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
> > > wrote:
> > > >
> >
> > [...]
> >
> > > > OK, won't this be enough ?
> > > > --- a/include/drm/drm_mode_config.h
> &g
On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> Hi Daniel, Gerd,
>
> On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
> >
> > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > > This patch is an early RFC to judge the direction
rtc_state;
> > > > > struct drm_crtc_commit *commit;
> > > > > int i;
> > > > > @@ -2300,7 +2300,7 @@
> > > > > EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
> > > > > int drm_atomic_helper_prepare_planes(struct drm_device *dev,
> > > > >struct drm_atomic_state *state)
> > > > > {
> > > > > - struct drm_connector *connector;
> > > > > + struct drm_connector __maybe_unused *connector;
> > > > > struct drm_connector_state *new_conn_state;
> > > > > struct drm_plane *plane;
> > > > > struct drm_plane_state *new_plane_state;
> > > > > @@ -2953,9 +2953,9 @@ int drm_atomic_helper_disable_all(struct
> > > > > drm_device *dev,
> > > > > {
> > > > > struct drm_atomic_state *state;
> > > > > struct drm_connector_state *conn_state;
> > > > > - struct drm_connector *conn;
> > > > > + struct drm_connector __maybe_unused *conn;
> > > > > struct drm_plane_state *plane_state;
> > > > > - struct drm_plane *plane;
> > > > > + struct drm_plane __maybe_unused *plane;
> > > > > struct drm_crtc_state *crtc_state;
> > > > > struct drm_crtc *crtc;
> > > > > int ret, i;
> > > > > @@ -3199,11 +3199,11 @@ int
> > > > > drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state
> > > > > *state,
> > > > > {
> > > > > int i, ret;
> > > > > struct drm_plane *plane;
> > > > > - struct drm_plane_state *new_plane_state;
> > > > > + struct drm_plane_state __maybe_unused *new_plane_state;
> > > > > struct drm_connector *connector;
> > > > > - struct drm_connector_state *new_conn_state;
> > > > > + struct drm_connector_state __maybe_unused *new_conn_state;
> > > > > struct drm_crtc *crtc;
> > > > > - struct drm_crtc_state *new_crtc_state;
> > > > > + struct drm_crtc_state __maybe_unused *new_crtc_state;
> > > > >
> > > > > state->acquire_ctx = ctx;
> > > > >
> > > > > --
> > > > > 2.15.0
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-de...@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rm-misc-next-fixes-2019-09-18)
Author: Daniel Vetter
Date: Tue Sep 17 14:09:35 2019 +0200
drm/kms: Duct-tape for mode object lifetime checks
which undoes any side-effect of the patch you're pointing at. I am
rather surprised though that this results in a hard-lookup for you,
did you
>
> Each console has its own iterator. This iterators will need to advance,
> regardless if the message was printed via write() or write_atomic().
>
> John Ogness
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sun, Sep 15, 2019 at 3:48 PM John Ogness wrote:
>
> On 2019-09-13, Daniel Vetter wrote:
> >> 2. A kernel thread will be created for each registered console, each
> >> responsible for being the sole printers to their respective
> >> consoles. With this, cons
/ yellow text or something like that
ofc :-)
Thanks, Daniel
>
> John Ogness
>
> [0]
> https://www.linuxplumbersconf.org/event/4/contributions/290/attachments/276/463/lpc2019_jogness_printk.pdf
> [1] https://lkml.kernel.org/r/20190704103321.10022-1-pmla...@suse.com
> [2] https://lkml.kernel.org/r/87lfvwcssu@linutronix.de
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
he point here is that we want this. We need to be able to move the
buffer between device ptes and system memory ptes, transparently,
behind userspace back, without races. And the fast path (which is "no
pte exists for this vma") must be real fast, so taking mmap_sem and
replacing the vma is no-go.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
ct_unpin,
> .vmap = drm_gem_vram_object_vmap,
> - .vunmap = drm_gem_vram_object_vunmap
> + .vunmap = drm_gem_vram_object_vunmap,
> + .print_info = drm_gem_ttm_print_info,
Yeah definitely link to the new way of doing stuff in the kerneldoc of the
previous patch. For this.
Reviewed-b
to invalidate_range_end. I can't test
that readily since i915 doesn't use it.
- Added might_sleep annotations to also make sure the mm side keeps up
it's side of the contract here around what's allowed and what's not.
Comments, feedback, review as usual very much appreciated.
Cheers, Daniel
Daniel
On Fri, Aug 23, 2019 at 4:06 PM Peter Zijlstra wrote:
> On Fri, Aug 23, 2019 at 03:42:47PM +0200, Daniel Vetter wrote:
> > I'm assuming the lockdep one will land, so not going to resend that.
>
> I was assuming you'd wake the might_lock_nested() along with the i915
> user th
On Fri, Aug 23, 2019 at 2:12 PM Jason Gunthorpe wrote:
>
> On Fri, Aug 23, 2019 at 10:34:01AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 23, 2019 at 1:14 AM Andrew Morton
> > wrote:
> > >
> > > On Tue, 20 Aug 2019 22:24:40 +0200 Daniel V
On Fri, Aug 23, 2019 at 1:14 AM Andrew Morton wrote:
>
> On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
>
> > Hi Peter,
> >
> > Iirc you've been involved at least somewhat in discussing this. -mm folks
> > are a bit undecided whether these new no
On Thu, Aug 22, 2019 at 4:24 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 22, 2019 at 10:42:39AM +0200, Daniel Vetter wrote:
>
> > > RDMA has a mutex:
> > >
> > > ib_umem_notifier_invalidate_range_end
> > > rbt_ib_umem_for_each_in_ran
On Thu, Aug 22, 2019 at 11:06:44AM +0200, Gerd Hoffmann wrote:
> Not needed any more for remove_conflicting_pci_framebuffers calls.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_fb_helper.h | 4 +---
> drivers/gpu/drm/amd/a
On Thu, Aug 22, 2019 at 10:16 AM Jason Gunthorpe wrote:
>
> On Wed, Aug 21, 2019 at 05:41:51PM +0200, Daniel Vetter wrote:
>
> > > Hm, I thought the page table locks we're holding there already prevent any
> > > sleeping, so would be redundant? But reading
On Fri, Aug 16, 2019 at 3:00 AM Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote:
> > > > So if
On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote:
> > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote:
> >
On Thu, Aug 15, 2019 at 5:10 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote:
>
> > You have to wait for the gpu to finnish current processing in
> > invalidate_range_start. Otherwise there's no point to any of this
> >
On Wed, Aug 14, 2019 at 09:00:29PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote:
> > We need to make sure implementations don't cheat and don't have a
> > possible schedule/blocking point deeply burried where review can't
> > c
o many DMA mapping and
> see:
> cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c
> 6 ahci
> 257 e1000e
> 6 ehci-pci
>5891 nouveau
> 24 uhci_hcd
>
> Does nouveau having this high number of DMA mapping is normal ?
Yeah seems perfec
goto err_vblank;
> @@ -269,6 +276,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> long flags)
> goto err_vblank;
> }
>
> + drm_crtc_vblank_off(>pipe.crtc);
Are you sure you need this one here? vblanks should be off after
drm_vblank_init() is called.
Thanks, Daniel
> +
> /*
>* Attach panel only if there is one.
>* If there is no panel attach, it must be a bridge. In this case, we
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
the commit message. I'm confused, did
something go wrong with some rebase here, and this patch should have a
different title/summary?
-Daniel
> + port->mgr->cbs->destroy_connector(port->mgr, port->connector);
>
> drm_dp_port_teardown_pdt(port, port->pdt);
> port->pdt = DP_PEER_DEVICE_NONE;
> --
> 2.21.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Signed-off-by: Lyude Paul
More official unit tests, yay!
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 27 --
> drivers/gpu/drm/selftests/Mak
On Wed, Jul 17, 2019 at 09:42:24PM -0400, Lyude Paul wrote:
> Since we're about to be calling this from multiple places. Also it makes
> things easier to read!
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Signed-off-by: Lyude Paul
Re
pu/drm/Makefile
> index 10f8329a8b71..545c61d6528b 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -37,6 +37,9 @@ drm_vram_helper-y := drm_gem_vram_helper.o \
>drm_vram_mm_helper.o
> obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
>
> +drm_t
On Fri, Aug 2, 2019 at 11:43 AM Daniel Vetter wrote:
>
> On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey wrote:
> >
> > Hi Lowry,
> >
> > On Thu, Aug 01, 2019 at 06:34:08AM +, Lowry Li (Arm Technology China)
> > wrote:
> > > Hi Brian,
> &g
s all anybody would ever need.
In that case I'm suggesting we experiment around a lot first in the
kernel to improve this. The trouble with uapi is it's forever, kernel
driver heuristics can be changed much easier. If you want to have it
easier for experimentation then I think the right uapi is probably
going to be a custom drm_fourcc.h, with one plane containing the
white/black/red values (so 2 bits per pixel), and the 2nd plane
containing all the information for partial update. But that would just
be a patch you're carrying locally for quick development of
heuristics.
For these partial update heuristics I think a good starting point
would be to wire up the damage stuff, and default to full refresh for
full frame updates.
Just throwing this in as an idea.
-Daniel
> > This way, the kernel can change voltages and perform sanity checks (rate
> > limit, temperature, etc.) instead of "blindly" damaging the hardware.
>
> I wouldn't know how to come up with safe boundaries for such checks. The
> vendor's datasheets are not much of a help. They basically say "don't deviate
> from our defaults for too long", but then there's others[1] who totally do
> deviate without a problem. The built-in hardware limits seem to be sensible.
> This patch configures both the b/w high drive voltage and the b/w/r low drive
> voltage to maximums (+/-11.0V) according to an example from the vendor, and
> it's working fine.
>
> Maybe a way to go at this would be to have a set of parameter presets in dt
> along with limits (full refresh at least every x seconds, full refresh at
> least every x partial refreshes, etc.), and allow userspace to select one of
> these presets using a drm property? This way it can still be configured but
> and it doesn't need any ioctls.
>
> - Jan
>
> [0]
> https://github.com/zkarcher/FancyEPD/blob/master/FancyEPD_Demo/FancyEPD.cpp#L900
> [1] https://www.youtube.com/watch?v=MsbiO8EAsGw
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
per.htm
> [2] https://blog.jaseg.net/images/epaper3.jpg
> [3] https://blog.jaseg.net/images/epaper1.jpg
> [4] https://blog.jaseg.net/images/epaper2.jpg
> [5] https://blog.jaseg.net/images/epaper4.jpg
> [6] https://www.youtube.com/watch?v=MsbiO8EAsGw
> [7] https://github.com/zkarcher/FancyEPD
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
m_connector_to_dumb_vga(connector);
>
> + /*
> +* If I2C bus for DDC is not defined, asume that the cable
> +* is always connected.
> +*/
> + if (PTR_ERR(vga->ddc) == -ENODEV)
> + return connector_status_connected;
> +
> /*
> * Even if we have an I2C bus, we can't assume that the cable
> * is disconnected if drm_probe_ddc fails. Some cables don't
>
> --
> Best regards
> Oleksandr Suvorov
>
> Toradex AG
> Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
> 4800 (main line)
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
pos : ypos - rows;
> + if (rows == 0)
> + return ypos;
p->vrows == 0 looks like something that really should be impossible. Is
this really needed to fix your bug?
> + else
> + return ypos < rows ? ypos : ypos % rows;
This part here makes sense,
flcn/gp102-: improve implementation of bind_context() on
SEC2/GSP
drm/nouveau/secboot/gp102-: remove WAR for SEC2 RTOS start bug
Daniel Vetter (5):
drm/komeda: Remove clock ratio property
drm/komeda: remove slave_planes property
drm/komeda: remove img_enhancement property
On Mon, Jul 15, 2019 at 7:57 PM Jason Gunthorpe wrote:
>
> On Mon, Jul 15, 2019 at 07:53:06PM +0200, Daniel Vetter wrote:
>
> > > So, I'll put it on a topic and send you two a note next week to decide
> > > if you want to merge it or not. I'm really unclear how nouveau'
On Mon, Jul 15, 2019 at 5:04 PM Jason Gunthorpe wrote:
>
> On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote:
>
> > > Linus, do you have any advice on how best to handle sharing mm
> > > patches? The hmm.git was mildly painful as it sits between quilt on
return pra->fn(pte, NULL, addr, pra->data);
> > + return pra->fn(pte, addr, pra->data);
> > }
>
> I looked through this and it looks OK to me, thanks
>
> Jason
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Thu, Jul 11, 2019 at 09:27:30AM +, Philippe CORNU wrote:
> Hi Daniel,
>
>
> On 7/10/19 5:27 PM, Daniel Vetter wrote:
> > On Fri, Jul 05, 2019 at 12:41:03PM +, Philippe CORNU wrote:
> >> Hi Olivier,
> >> and many thanks for your patch.
> >&
ffset + 24, 0, 8);
> - crc = crc32_le(crc, vaddr_out + src_offset,
> - sizeof(u32));
> + pixel = get_pixel_from_buffer(x, y, vaddr, composer);
> + bitmap_clear((void *), 0, 8);
> + crc = crc32_le(crc, (void *), sizeof(u32));
> }
> }
>
> --
> 2.21.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Rodrigo Siqueira
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.c| 2 +-
> drivers/gpu/drm/vkms/vkms_drv.h| 4 ++--
> drivers/gpu/drm/vkms/vkms_output.c | 6 +++---
> drivers/gpu/drm/vkms/vkms_plane.c | 4 ++--
> 4 files changed, 8 insertions(+), 8 deleti
On Thu, Jul 4, 2019 at 5:41 PM Brian Starkey wrote:
>
> Hi,
>
> On Thu, Jul 04, 2019 at 11:57:00AM +0100, james qian wang (Arm Technology
> China) wrote:
> > On Wed, Jul 03, 2019 at 12:01:49PM +0200, Daniel Vetter wrote:
> > >
> > > Uh, what exactly ar
On Mon, Jun 24, 2019 at 11:32 AM Brian Starkey wrote:
>
> Hi Daniel,
>
> On Fri, Jun 21, 2019 at 05:27:00PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 21, 2019 at 12:21 PM Raymond Smith
> > wrote:
> > >
> > > Add the DRM_FORMAT_MOD_ARM_16X16_BL
ma/panfrost people since I assume they'll
be using this, too.
Thanks, Daniel
> +
> +/*
> * Allwinner tiled modifier
> *
> * This tiling mode is implemented by the VPU found on all Allwinner
> platforms,
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter wrote:
> >
> > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote:
> > > >
On Wed, Jun 19, 2019 at 10:42 PM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> > > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > >
On Wed, Jun 19, 2019 at 11:04:15AM +0200, Gerd Hoffmann wrote:
> Call reservation_object_* directly instead
> of using ttm_bo_{reserve,unreserve}.
>
> v3: check for EINTR too.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/d
-ERESTARTSYS) {
errno semantics change here, I think you now get EINTR. With that fixed:
Reviewed-by: Daniel Vetter
> struct virtio_gpu_device *qdev =
> @@ -416,7 +416,7 @@ static inline int virtio_gpu_object_reserve(struct
> virtio_gpu_object *bo)
&
On Fri, Jun 14, 2019 at 08:51:11PM +0200, Christian König wrote:
> Am 14.06.19 um 20:24 schrieb Daniel Vetter:
> >
> > On Fri, Jun 14, 2019 at 8:10 PM Christian König
> > wrote:
> > > [SNIP]
> > > WW_MUTEX_LOCK_BEGIN()
> > >
> > >
On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
China) wrote:
> On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 11, 2019 at 11:13:45AM +, Lowry Li (Arm Technology China)
> > wrote:
> > > From: "L
On Thu, Jun 13, 2019 at 09:28:13AM +0100, Liviu Dudau wrote:
> On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
> > China) wrote:
> > > On Tue, Jun 11, 2019 at 02:30:38PM +0
On Thu, Jun 13, 2019 at 02:24:37PM +0100, Liviu Dudau wrote:
> On Thu, Jun 13, 2019 at 11:08:14AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 13, 2019 at 09:28:13AM +0100, Liviu Dudau wrote:
> > > On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> > > >
On Tue, Jun 11, 2019 at 10:08:10PM +0300, Thomas Backlund wrote:
> Den 11-06-2019 kl. 20:40, skrev Greg Kroah-Hartman:
> > On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote:
> > > On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
> > > wrote:
> >
On Tue, Jun 11, 2019 at 8:53 PM Sven Joachim wrote:
>
> On 2019-06-11 19:33 +0200, Daniel Vetter wrote:
>
> > On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
> > wrote:
> >> On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote:
> >> > Co
On Tue, Jun 11, 2019 at 7:40 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
> > wrote:
> > > On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote:
>
pply in 5.1.9.
> >
> > Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested
> > them yet.
>
> They probably are.
>
> Should I just revert this patch in the stable tree, or add some other
> patch (like the one pointed out here, which seems an odd patch for
>
would be a bug in the drm_vblank.c. Or at least it could be,
I think I first need to better understand still what's going on here to
decided that.
I have a bit a hunch this is fallout from our vblank fudging, but I guess
we'll see.
It's definitely clear that things blow up if the vbl
inconsistency
> might catch us out if it is not one of the last cleanup actions).
>
> intel_uc_fini() is a bit of a mixed bag. It looks like it flushes
> runtime state, so preferrably that flush should be moved to the
> _fini_hw so that _fini is pure cleanup. So for the time being, best to
> leave intel_uc_fini() here.
>
> > + mutex_unlock(_priv->drm.struct_mutex);
> > +
> > + i915_gem_drain_freed_objects(dev_priv);
> > +}
> > +
> > +void i915_gem_fini(struct drm_i915_private *dev_priv)
> > +{
> > + mutex_lock(_priv->drm.struct_mutex);
> > i915_gem_contexts_fini(dev_priv);
> > i915_gem_fini_scratch(dev_priv);
> > mutex_unlock(_priv->drm.struct_mutex);
>
> That split looks sensible to me, with the consideration as to whether
> defer intel_engines_cleanup() as well,
> Reviewed-by: Chris Wilson
> -Chris
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
It's dead code, and removing it avoids me having to understand
what it's doing with lock_fb_info.
v2: Also remove sh_mobile_lcdc_must_reconfigure, now unused (Sam).
Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven (v1)
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc
With the sh_mobile notifier removed we can just directly call the
fbcon code here.
v2: Remove now unused local variable.
v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej
add a static inline to the dummy function.
v4: Add missing #include to sh_mob (Sam).
Cc: Sam Ravnborg
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Maarten Lankhorst
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
also don't
really want to find out. So just do the simple conversion to a direct
function call.
v2: static inline for the dummy versions, I forgot.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de
had to deinline the con_is_visible function.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Nicolas Pitre
Cc: Martin Hostettler
Cc: Adam Borowski
Cc: Daniel Vetter
Cc: Mikulas Patocka
---
drivers/tty/vt/vt.c| 16
include/linux/console_struct.h | 5 +
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Rob Clark
---
drivers/video/fbdev/core/fbsysfs.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/video
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting
As part of trying to understand the locking (or lack thereof) in the
fbcon/vt/fbdev maze, annotate everything.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Cc: Nicolas Pitre
---
drivers/video/console
This was formerly used in fbdev drivers (not sure why, predates most
git history), but now it's entirely an fbcon internal thing. Give it a
more specific name.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Kees Cook
NOW
does nothing. This bug exists ever since this code was extracted as a
common helper in 2002, hence I decided against fixing it. Everyone
just better have a fb_check_var to make sure things work correctly.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: &quo
With the recursion broken in the previous patch we can drop the
FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
prevention was it's only job.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: "Michał Mir
901 - 1000 of 6575 matches
Mail list logo
