On Wed, May 4, 2016 at 3:43 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> I'd really like to converge on the markup question, so that we can start
> using all the cool stuff with impunity in gpu documentations.
Aside: If we decide this now I could send in a pull request for the
rst/s
nx. Everyone pretty much agrees that
this would be a second step, and the first step would be to simply
integrate more advanced markup into the existing toolchain.
- which flavour of markup has the best support for more advanced use-cases
like those in the media docbook. It sounds like sphinx won that
competition.
I'd really like to converge on the markup question, so that we can start
using all the cool stuff with impunity in gpu documentations.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ng <thierry.red...@gmail.com>
> Acked-by: Philipp Zabel <p.za...@pengutronix.de>
> Acked-by: Manfred Schlaegl <manfred.schla...@gmx.at>
> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> Signed-off-by: Stefan Agner <ste...@agner.ch>
In case this wasn't clear: T
On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff wi
p and will make sure that the fbdev emulation
> will
> * not miss any hotplug events.
> *
> --
> 2.5.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d, save_enabled, dev->mode_config.num_connector);
> + memcpy(enabled, save_enabled, fb_helper->connector_count);
> kfree(save_enabled);
> return false;
> }
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 4, 2016 at 5:02 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
>> On Wed, 4 May 2016 16:18:27 +0200
>> Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>>
>> > > I'd really like t
fb_helper->connector_count *
> sizeof(struct drm_fb_helper_crtc *));
> }
> }
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; Agree.
>
> >
> > PS:
> > I am mentioning the following just in case that it has any
> > relationship
> > with the FBC related kernel freezes. Maybe it doesn't... There is
> > another recent regression on this PC, but I have not yet figured out
> > whether it was introduced by any particular kernel version. The
> > regression is: When switching from X11 to text console by
> > [Ctrl][Alt][Fx]
> > or by shutting down sddm, I often only get a blank screen. I suspect
> > that this regression was introduced when I replaced kdm by sddm, but
> > I am not sure about that.
>
> Maybe there is some relationship, since this operation involves a mode
> change. You can also try checking dmesg to see if there are underruns
> right when you do the change.
>
>
> If you don't want to keep carrying a manual revert, you can just boot
> with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> it would be good to know in case you still somehow see the machine
> hangs even with FBC disabled.
>
> Thanks,
> Paulo
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
encoder_funcs = encoder->helper_private;
> - encoder_funcs->commit(encoder);
> + if (encoder_funcs->commit)
> + encoder_funcs->commit(encoder);
>
> drm_bridge_enable(encoder->bridge);
> }
> @@ -771,12 +793,15 @@ static void drm_helper_encoder_dpms(struct drm_encoder
> *encoder, int mode)
> struct drm_bridge *bridge = encoder->bridge;
> const struct drm_encoder_helper_funcs *encoder_funcs;
>
> + encoder_funcs = encoder->helper_private;
> + if (!encoder_funcs)
> + return;
> +
> if (mode == DRM_MODE_DPMS_ON)
> drm_bridge_pre_enable(bridge);
> else
> drm_bridge_disable(bridge);
>
> - encoder_funcs = encoder->helper_private;
> if (encoder_funcs->dpms)
> encoder_funcs->dpms(encoder, mode);
>
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_framebuffer *fb);
> int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
> struct drm_file *file_priv, unsigned int *handle);
>
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb
t; END
> Timed out: CRC reading
> Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)
This one failed in both runs. Can you please retest with just that using
# kms_frontbuffer_tracking --run-subtest fbc-1p-primscrn-spr-indfb-fullscreen
Also please boot with drm.debug=0xe and grab the full dmesg of just that
single subtest. There's definitely something going wrong here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, May 06, 2016 at 03:01:37PM +0200, Noralf Trønnes wrote:
>
> Den 05.05.2016 18:27, skrev Daniel Vetter:
> >On Thu, May 05, 2016 at 03:24:31PM +0200, Noralf Trønnes wrote:
> >>Add drm_fb_cma_create_with_funcs() for drivers that need to set the
> >>
On Mon, May 09, 2016 at 09:19:22PM +0200, Noralf Trønnes wrote:
>
> Den 05.05.2016 18:23, skrev Daniel Vetter:
> >On Thu, May 05, 2016 at 03:24:32PM +0200, Noralf Trønnes wrote:
> >>Make drm_encoder_helper_funcs and it's functions optional to avoid
> >>having dummy
On Mon, May 09, 2016 at 08:37:39PM +0200, Noralf Trønnes wrote:
>
> Den 09.05.2016 16:46, skrev Daniel Vetter:
> >On Thu, May 05, 2016 at 03:24:33PM +0200, Noralf Trønnes wrote:
> >>Provides helper functions for drivers that have a simple display
> >>pip
d up
> and gave Sphinx a try, I was up and running with reasonable PDF and
> HTML output in a day and a half.
>
> Honestly, in the end I think we could make either tool do what is
> needed of it. However, my impression after trying to do a document
> that needs to have nice publishable out
scaling mode”
> - ENUM
> - { "None", "Full", "Center", "Full aspect" }
> - Connector
> - TBD
> -
> -
> + Optional
> "aspect ratio"
> ENUM
> { "None", "4:3", "16:9" }
> Connector
> - DRM property to set aspect ratio from user space app.
> - This enum is made generic to allow addition of custom aspect
> - ratios.
> + TDB
>
>
> “dirty”
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ofc before we return 0; we want these checks always done. And catch all
these things so that drivers never fall over this pitfall.
Noticed while discussing tilcdc atomic patches, since tilcdc could
probably use drm_simple_display_pipe too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
KMS is
fully agnostic to how/what your underlying buffer objects even are.
You could have allocations in some sepcial secure memory that only the
gpu could even read/write, as another example.
Maybe we need to make this part in the overview docs better?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
o itself, boom. From
that pov it's an unsafe api, and hence something to avoid.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Apr 15, 2016 at 11:59:00AM -0700, Gustavo Padovan wrote:
> 2016-04-15 Daniel Vetter <dan...@ffwll.ch>:
> > On Thu, Apr 14, 2016 at 06:29:38PM -0700, Gustavo Padovan wrote:
> > > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> > &
On Fri, Apr 15, 2016 at 11:29:34AM -0700, Gustavo Padovan wrote:
> 2016-04-15 Daniel Vetter <dan...@ffwll.ch>:
>
> > On Fri, Apr 15, 2016 at 11:03 AM, Christian König
> > <christian.koe...@amd.com> wrote:
> > > Might be that how amdgpu uses the fence cont
driver-specific implementations with the generic one.
>
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
&g
ut firmware fb driver" out of fbdev, since we'd need it
to have a simple drm driver for e.g. uefi.
But I definitely don't want a legacy horror show like fbdev to
automagically take care of device mappings for drivers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
and I think this makes a lot more sense:
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 ++
> include/drm/drm_crtc.h | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-sim
Fastest way to get stuff like this in, and if driver maintainers don't
pipe up by then ... their problem imo ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d unregister_all()
> * Updated commit messages (mostly spellos and grammar issues)
>
> Changes v1 -> v2:
> * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> * Use drm_for_each_connector() instead of list_for_each_entry()
> * Updated kerneldoc for drm_dev_registe
lit(info, image);
> + sys_imageblit(info, image);
>
> udl_handle_damage(>ufb, image->dx, image->dy, image->width,
> image->height);
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
> extern void fb_deferred_io_init(struct fb_info *info);
> extern void fb_deferred_io_open(struct fb_info *info,
> struct inode *inode,
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n = NULL;
> + image->cmap.blue = NULL;
> + image->cmap.transp = NULL;
> + image->data = qfbdev->shadow + (clips->x1 * 4) + (stride * clips->y1);
> +
> + qxl_fb_image_init(_fb_image, qdev, info, NULL);
> + qxl_draw_opaque_fb(_fb_image, stride);
> +
>
; + info->fbops->fb_mmap = udl_fb_mmap;
> }
> -
> - info->fbdefio = fbdefio;
> - fb_deferred_io_init(info);
> }
>
> pr_notice("open /dev/fb%d user=%d fb_info=%p count=%d\n",
> @@ -379,9 +252,9 @@ static struct fb_ops udlfb_ops = {
> .owner = THIS_MODULE,
> .fb_check_var = drm_fb_helper_check_var,
> .fb_set_par = drm_fb_helper_set_par,
> - .fb_fillrect = udl_fb_fillrect,
> - .fb_copyarea = udl_fb_copyarea,
> - .fb_imageblit = udl_fb_imageblit,
> + .fb_fillrect = drm_fb_helper_sys_fillrect,
> + .fb_copyarea = drm_fb_helper_sys_copyarea,
> + .fb_imageblit = drm_fb_helper_sys_imageblit,
> .fb_pan_display = drm_fb_helper_pan_display,
> .fb_blank = drm_fb_helper_blank,
> .fb_setcmap = drm_fb_helper_setcmap,
> @@ -458,7 +331,6 @@ udl_framebuffer_init(struct drm_device *dev,
> {
> int ret;
>
> - spin_lock_init(>dirty_lock);
> ufb->obj = obj;
> drm_helper_mode_fill_fb_struct(>base, mode_cmd);
> ret = drm_framebuffer_init(dev, >base, _funcs);
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
m code: drm_ioctl.c, drm_mm.c, drm_memory.c,
> ...
> *This is the category used by the DRM_DEBUG() macro.
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> };
>
> @@ -103,4 +104,13 @@ void sync_file_put(struct sync_file *sync_file);
> */
> void sync_file_install(struct sync_file *sync_file, int fd);
>
> +/**
> + * sync_file_fences_get - get the fence related to the fd
> + * @fd: file descriptor to look for
pted - we can't proceed with the atomic update in that case, but
need to bail out. And userspace needs to restart the ioctl.
Also, needs a testcase I think.
-Daniel
> fence_put(plane->state->fence);
> plane->state->fence = NULL;
> }
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ULL if the fence is not a fence_collection,
> + * or the fence_collection otherwise.
> + */
> +static inline struct fence_collection * to_fence_collection(struct fence
> *fence)
> +{
Kerneldoc claims it, but you don't check that the fence is indeed a
fence_collection. That's usually done by comparing the ops pointer.
> + return container_of(fence, struct fence_collection, base);
> +}
> +
> +struct fence_collection *fence_collection_init(int num_fences);
> +void fence_collection_add(struct fence_collection *collection,
> + struct fence *fence);
> +void fence_collection_put(struct fence_collection *collection);
> +
> +#endif /* __LINUX_FENCE_COLLECTION_H */
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> index 2b17698..02170dd 100644
> --- a/include/linux/fence.h
> +++ b/include/linux/fence.h
> @@ -30,6 +30,8 @@
> #include
> #include
>
> +#define FENCE_NO_CONTEXT 0
> +
> struct fence;
> struct fence_ops;
> struct fence_cb;
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ate_object(dev, DRM_MODE_PROP_ATOMIC,
> "CRTC_ID", DRM_MODE_OBJECT_CRTC);
> if (!prop)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8cb377c..5ba3cda 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2122,6 +2122,7 @@ struct drm_mode_config {
> struct drm_property *prop_crtc_w;
> struct drm_property *prop_crtc_h;
> struct drm_property *prop_fb_id;
> + struct drm_property *prop_fence_fd;
> struct drm_property *prop_crtc_id;
> struct drm_property *prop_active;
> struct drm_property *prop_mode_id;
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> "CRTC_ID", DRM_MODE_OBJECT_CRTC);
> if (!prop)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8cb377c..5ba3cda 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2122,6 +2122,7 @@ struct drm_mode_config {
> struct drm_property *prop_crtc_w;
> struct drm_property *prop_crtc_h;
> struct drm_property *prop_fb_id;
> + struct drm_property *prop_fence_fd;
> struct drm_property *prop_crtc_id;
> struct drm_property *prop_active;
> struct drm_property *prop_mode_id;
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
.g. exynos uses drm_event for rendering ...).
-Daniel
> +
> send_vblank_event(dev, e, seq, );
> }
> EXPORT_SYMBOL(drm_send_vblank_event);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 3c8422c..8f83c2a 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -282,6 +282,7 @@ struct drm_ioctl_desc {
> /* Event queued up for userspace to read */
> struct drm_pending_event {
> struct drm_event *event;
> + struct fence *fence;
> struct list_head link;
> struct list_head pending_link;
> struct drm_file *file_priv;
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nc_timeline *timeline;
> + unsigned long fence_seqno;
>
> /*
>* For legacy crtc IOCTLs so that atomic drivers can get at the locking
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 39905cc..4cdcd22 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -592,6 +592,11 @@ struct drm_mode_destroy_dumb {
> DRM_MODE_ATOMIC_ALLOW_MODESET |\
> DRM_MODE_ATOMIC_OUT_FENCE)
>
> +struct drm_out_fences {
> + __u32 crtc_id;
> + __u32 fd;
> +};
> +
> struct drm_mode_atomic {
> __u32 flags;
> __u32 count_objs;
> @@ -601,6 +606,8 @@ struct drm_mode_atomic {
> __u64 prop_values_ptr;
> __u64 reserved;
> __u64 user_data;
> + __u64 count_out_fences;
> + __u64 out_fences_ptr;
> };
>
> /**
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
fence where the
timeline never matches with any other timeline (since it's a
combiation).
And yeah I think fence_collection should probably compress down the
fences to 1 per timeline. But then that's just an implementation
detail we can fix later on.
-Daniel
--
Daniel Vetter
Software Engineer, Intel
On Wed, Apr 20, 2016 at 08:33:17PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 19:44, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 05:25:26PM +0200, Noralf Trønnes wrote:
> >>Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
> >>When th
On Wed, Apr 20, 2016 at 09:04:38PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 19:47, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
> >>Use the fbdev deferred io support in drm_fb_helper.
> >>The (struct fb_ops *)-&g
On Thu, Apr 21, 2016 at 09:41:34AM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 09:04:38PM +0200, Noralf Trønnes wrote:
> >
> > Den 20.04.2016 19:47, skrev Daniel Vetter:
> > >On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
> > >&
On Wed, Apr 20, 2016 at 08:15:30PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 19:42, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 05:25:23PM +0200, Noralf Trønnes wrote:
> >>Now that drm_fb_helper gets deferred io support, the
> >>drm_fb_helper_sys_{fillrect
xplicitly. But
that's only the case for DRM_AUTH ioctls.
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Aside: I wonder whether we should go through all the drivers and replace
DRM_AUTH | DRM_RENDER_ALLOW with 0? It looks a bit like drm ioctl flags
are cargo culted ...
-Daniel
>
> Signe
On Wed, Apr 20, 2016 at 11:27:27PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > > Reason I ask is since I noticed a while ago a lot of drivers
>
On Thu, Apr 21, 2016 at 09:49:39AM +0200, Daniel Vetter wrote:
> On Thu, Apr 21, 2016 at 09:41:34AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 20, 2016 at 09:04:38PM +0200, Noralf Trønnes wrote:
> > >
> > > Den 20.04.2016 19:47, skrev Daniel Vetter:
> > >
On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote:
> > > &
On Wed, Apr 27, 2016 at 09:49:49PM +0200, Noralf Trønnes wrote:
>
> Den 27.04.2016 21:24, skrev Daniel Vetter:
> >On Wed, Apr 27, 2016 at 08:16:29PM +0200, Noralf Trønnes wrote:
> >>This patchset adds fbdev deferred io support to drm_fb_helper and
> >>drm_fb_cma_help
On Wed, Apr 27, 2016 at 09:24:52PM +0200, Noralf Trønnes wrote:
>
> Den 27.04.2016 21:20, skrev Daniel Vetter:
> >On Wed, Apr 27, 2016 at 08:16:32PM +0200, Noralf Trønnes wrote:
> >>This adds deferred io support to drm_fb_helper.
> >>The fbdev framebuffer changes
const struct drm_display_mode *modes, unsigned int num_modes,
> int connector_type);
Yeah, this makes more sense to me, but then we're kinda reinventing
something like simple-panel.c with this. Otoh right now with
smple_display_pipe it's not possible to wire up the panel callbacks
_atomic_helper_page_flip,
> -#endif
> + .page_flip = virtio_gpu_page_flip,
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>> > > Signed-off-by: Dave Airlie <airl...@redhat.com>
>> > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
&g
; >
> > Yes, thanks, that "fixed" it. So atomic commits not working properly
> > on IVB?
>
> Not yet it seems. Something seems to be off in the timing, but has so
> far eluded capture.
Fyi we reverted this for now to fix things up:
commit 527b6abe5fd2d24fba69e9564a2d608e1796ca8d
Author: Chris Wilson <ch...@chris-wilson.co.uk>
Date: Fri Jun 24 13:44:03 2016 +0100
Revert "drm/i915: Use atomic commits for legacy page_flips"
Kudos to Chris for handling this in my absence.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d keep
working for everyone. Only exception is if there's a driver which calls
drm_dev_register too early (before all connectors are probed), which would
be a bug anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nout engines which you need to dynamically
allocate.
> On 2016年07月26日 17:51, Mark yao wrote:
> > On 2016年07月26日 16:26, Daniel Vetter wrote:
> > > On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
> > > > >What is share plane:
> > > > >Plane har
;crtc.port = of_get_next_parent(ep);
> >
> > ret = component_bind_all(dev, drm);
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
"pclk");
> > if (IS_ERR(hwdev->pclk))
> >
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; *plane,
> + struct drm_plane *parent,
> + unsigned long possible_crtcs,
> + const struct drm_plane_funcs *funcs,
> + const uint32_t *formats,
> + unsigned int format_count,
> + enum drm_plane_type type);
> extern void drm_plane_cleanup(struct drm_plane *plane);
>
> /**
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 452675f..01979a4 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -677,6 +677,13 @@ struct drm_get_cap {
> */
> #define DRM_CLIENT_CAP_ATOMIC3
>
> +/**
> + * DRM_CLIENT_CAP_SHARE_PLANES
> + *
> + * If set to 1, the DRM core will expose share planes to userspace.
> + */
> +#define DRM_CLIENT_CAP_SHARE_PLANES 4
> +
> /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
> struct drm_set_client_cap {
> __u64 capability;
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ry?
psr or fbc are the likely culprits. More likely fbc if the underruns
correlate with the flicker (but note that by default we only report
them once per modest, needs to be reset with a dpms or
suspend/resume). Driver should even pick up the new module option
settings at runtime (but again you need to force a modeset, just
suspend/resume quickly), so fast to test.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
> This adds a compile-time check in the driver to ensure we only
> attempt to call that function if either CONFIG_FB=y or
> both subsystems are configured as loadable modules.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: 0b6320dfdfea ("drm/virtio: m
p_unbind(struct device *dev)
> drm_kms_helper_poll_fini(drm);
> malidp_se_irq_fini(drm);
> malidp_de_irq_fini(drm);
> + drm->irq_enabled = false;
> drm_vblank_cleanup(drm);
> component_unbind_all(dev, drm);
> of_node_put(malidp->crtc.port);
> --
> 2.9.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
.
> But, I will keep Cc to you for this patch-set.
Archit Tajena is the maintainer of last resort for anything related to
drm_bridge.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
oblems(does it create any issue?).
>
> Can you reconsider or propose a concrete solution that is not more complex
> than our entire driver?
>
> Thanks a lot!
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
if (funcs->cleanup_fb)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index d1559cd..08b2033 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1531,6 +1531,7 @@ struct drm_plane {
> uint32_t *format_types;
> unsigned int form
e_param_named_unsafe(edp_vswing, i915.edp_vswing, int, 0400);
> > +module_param_named_unsafe(edp_vswing, i915.edp_vswing, int, S_IRUSR);
> > MODULE_PARM_DESC(edp_vswing,
> > "Ignore/Override vswing pre-emph table selection from VBT "
> > "(0=use value from vbt [default], 1=low power swing(200mV),"
> > "2=default swing(400mV))");
> >
> > -module_param_named_unsafe(enable_guc_submission,
> > i915.enable_guc_submission, bool, 0400);
> > +module_param_named_unsafe(enable_guc_submission,
> > i915.enable_guc_submission, bool, S_IRUSR);
> > MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
> > (default:false)");
> >
> > -module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
> > +module_param_named(guc_log_level, i915.guc_log_level, int, S_IRUSR);
> > MODULE_PARM_DESC(guc_log_level,
> > "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
> >
> > -module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
> > +module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, S_IRUSR
> > | S_IWUSR);
> > MODULE_PARM_DESC(enable_dp_mst,
> > "Enable multi-stream transport (MST) for new DisplayPort sinks.
> > (default: true)");
> > -module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> > uint, 0400);
> > +module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> > uint, S_IRUSR);
> > MODULE_PARM_DESC(inject_load_failure,
> > "Force an error after a number of failure check points (0:disabled
> > (default), N:force failure at the Nth failure check point)");
> > --
> > 2.9.2
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; -extern void drm_vblank_put(struct drm_device *dev, unsigned int pipe);
> > extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
> > extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
> > extern void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
> > --
> > 2.5.5
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
RNEL);
> + if (!fbdev)
> + return -ENOMEM;
> +
> + private->fbdev = fbdev;
> + helper = >fbdev_helper;
>
> drm_fb_helper_prepare(dev, helper, _drm_fb_helper_funcs);
>
> @@ -175,7 +181,9 @@ void rockchip_drm_fbdev_fini(struct drm_device *dev)
> struct rockchip_drm_private *private = dev->dev_private;
> struct drm_fb_helper *helper;
>
> - helper = >fbdev_helper;
> + if (!private || private->fbdev)
> + return;
> + helper = >fbdev->fbdev_helper;
>
> drm_fb_helper_unregister_fbi(helper);
> drm_fb_helper_release_fbi(helper);
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_debugfs_remove_files(info_list, 1, minor);
> }
> }
> +
> +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
> + size_t *values_cnt)
> +{
> + struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> + enum intel_display_power_domain power_domain;
> + enum intel_pipe_crc_source source;
> + int ret;
> +
> + if (display_crc_ctl_parse_source(source_name, ) < 0) {
> + DRM_DEBUG_DRIVER("unknown source %s\n", source_name);
> + return -EINVAL;
> + }
> +
> + power_domain = POWER_DOMAIN_PIPE(crtc->index);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain)) {
> + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n");
> + return -EIO;
> + }
> +
> + ret = do_set_crc_source(crtc->dev, crtc->index, source);
> +
> + intel_display_power_put(dev_priv, power_domain);
> +
> + *values_cnt = 5;
> +
> + return ret;
> +}
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
arguments, as
> > +* provided from the configured source. Drivers should accept a "auto"
> > +* source name that will select a default source for this CRTC.
> > +*
> > +* This callback is optional if the driver does not support any CRC
> > +* generation functionality.
> > +*
> > +* RETURNS:
> > +*
> > +* 0 on success or a negative error code on failure.
> > +*/
> > + int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
> > + size_t *values_cnt);
> > };
> >
> > /**
> > @@ -844,6 +869,22 @@ struct drm_crtc {
> > * context.
> > */
> > struct drm_modeset_acquire_ctx *acquire_ctx;
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > + /**
> > +* @debugfs_entry:
> > +*
> > +* Debugfs directory for this CRTC.
> > +*/
> > + struct dentry *debugfs_entry;
> > +
> > + /**
> > +* @crc:
> > +*
> > +* Configuration settings of CRC capture.
> > +*/
> > + struct drm_crtc_crc crc;
> > +#endif
> > };
> >
> > /**
> > diff --git a/include/drm/drm_debugfs_crc.h b/include/drm/drm_debugfs_crc.h
> > new file mode 100644
> > index ..a341fc9becad
> > --- /dev/null
> > +++ b/include/drm/drm_debugfs_crc.h
> > @@ -0,0 +1,74 @@
> > +/*
> > + * Copyright © 2016 Collabora Ltd.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +#ifndef __DRM_DEBUGFS_CRC_H__
> > +#define __DRM_DEBUGFS_CRC_H__
> > +
> > +/**
> > + * struct drm_crtc_crc_entry - entry describing a frame's content
> > + * @frame: number of the frame this CRC is about
> > + * @crc: array of values that characterize the frame
> > + */
> > +struct drm_crtc_crc_entry {
> > + bool has_frame_counter;
> > + uint32_t frame;
> > + uint32_t crcs[0];
> > +};
> > +
> > +#define DRM_MAX_CRC_NR 10
> > +#define DRM_CRC_ENTRIES_NR 128
> > +/**
> > + * struct drm_crtc_crc - data supporting CRC capture on a given CRTC
> > + * @lock: protects the fields in this struct
> > + * @source: name of the currently configured source of CRCs
> > + * @opened: whether userspace has opened the data file for reading
> > + * @entries: array of entries, with size of %DRM_CRTC_CRC_ENTRIES_NR
> > + * @head: head of circular queue
> > + * @tail: tail of circular queue
> > + * @wq: workqueue used to synchronize reading and writing
> > + */
> > +struct drm_crtc_crc {
> > + spinlock_t lock;
> > + const char *source;
> > + bool opened;
> > + struct drm_crtc_crc_entry *entries;
> > + int head, tail;
> > + size_t values_cnt;
> > + wait_queue_head_t wq;
> > +};
> > +
> > +#if defined(CONFIG_DEBUG_FS)
> > +int drm_debugfs_crtc_crc_add(struct drm_crtc *crtc);
> > +int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame,
> > + uint32_t frame, uint32_t *crcs);
> > +#else
> > +static inline int drm_debugfs_crtc_crc_add(struct drm_crtc *crtc)
> > +{
> > + return 0;
> > +}
> > +static inline int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
> > has_frame,
> > +uint32_t frame, uint32_t *crcs)
> > +{
> > + return -EINVAL;
> > +}
> > +#endif /* defined(CONFIG_DEBUG_FS) */
> > +
> > +#endif /* __DRM_DEBUGFS_CRC_H__ */
> > --
> > 2.5.5
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 03, 2016 at 04:56:20PM +0800, Mark yao wrote:
> On 2016年08月03日 16:46, Daniel Vetter wrote:
> > On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote:
> > > > [1.162571] Unable
h it isn't
> here), so revert it.
>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Signed-off-by: Johannes Berg <johannes.b...@intel.com>
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
And ack-by: me for merging through whatever tree this makes sense for.
-Daniel
lanes(drm, state, false);
> drm_atomic_helper_commit_modeset_enables(drm, state);
> + drm_atomic_helper_commit_planes(drm, state, true);
> +
> drm_atomic_helper_wait_for_vblanks(drm, state);
> +
> drm_atomic_helper_cleanup_planes(drm, state);
> drm_atomic_state_free(state);
> }
> --
> 1.7.9.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Aug 04, 2016 at 12:35:59PM +0200, Enric Balletbo Serra wrote:
> 2016-07-12 12:13 GMT+02:00 Daniel Vetter <dan...@ffwll.ch>:
> > On Wed, Jun 29, 2016 at 6:31 AM, Daniel Kurtz <djku...@chromium.org> wrote:
> >> On Fri, Jun 17, 2016 at 3:14 AM, Emil Vel
> [1.172215] [] worker_thread+0x24c/0x374
> [1.172217] [] kthread+0xdc/0xe4
> [1.17] [] ret_from_fork+0x10/0x40
>
> Signed-off-by: Mark Yao <mark@rock-chips.com>
> ---
> Change in v1:
> Advised by Daniel Vetter
> only do the struct->pointer convers
>pitches[0] * cmd->height;
> + if (!bpp ||
> + bpp > 4 ||
> + cmd->pitches[0] < bpp * fb->base.width ||
> + cmd->pitches[0] > 0xU ||
> + size + fb->base.offsets[0] < size ||
> + size + fb->base.offsets[0] > fb->obj->base.size) {
> + err = ERR_PTR(-EINVAL);
> + goto err_free;
> + }
> +
> + ret = drm_framebuffer_init(ddev, >base, _fb_ops);
> + if (ret < 0) {
> + err = ERR_PTR(ret);
> + goto err_free;
> + }
> +
> + DRM_DEBUG_KMS("[FB:%d] pixel_format: %s\n", fb->base.base.id,
> + drm_get_format_name(fb->base.pixel_format));
> +
> + return >base;
> +
> +err_free:
> + kfree(fb);
> +err_unref:
> + drm_gem_object_unreference_unlocked(gobj);
> +
> + return err;
> +}
> +
> +static const struct drm_mode_config_funcs sdrm_mode_config_ops = {
> + .fb_create = sdrm_fb_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +int sdrm_drm_modeset_init(struct sdrm_device *sdrm)
> +{
> + struct drm_connector *conn = >conn;
> + struct drm_device *ddev = sdrm->ddev;
> + int ret;
> +
> + drm_mode_config_init(ddev);
> + ddev->mode_config.min_width = 1;
> + ddev->mode_config.min_height = 1;
> + ddev->mode_config.max_width = 8192;
> + ddev->mode_config.max_height = 8192;
> + ddev->mode_config.preferred_depth = sdrm->fb_bpp;
> + ddev->mode_config.funcs = _mode_config_ops;
> +
> + drm_connector_helper_add(conn, _conn_hfuncs);
> + ret = drm_connector_init(ddev, conn, _conn_ops,
> + DRM_MODE_CONNECTOR_VIRTUAL);
> + if (ret)
> + goto err_cleanup;
> +
> + ret = drm_mode_create_dirty_info_property(ddev);
> + if (ret)
> + goto err_cleanup;
> +
> + drm_object_attach_property(>base,
> +ddev->mode_config.dirty_info_property,
> +DRM_MODE_DIRTY_ON);
> +
> + ret = drm_simple_display_pipe_init(ddev, >pipe, _pipe_funcs,
> +sdrm_formats,
> +ARRAY_SIZE(sdrm_formats), conn);
> + if (ret)
> + goto err_cleanup;
> +
> + drm_mode_config_reset(ddev);
> +
> + return 0;
> +
> +err_cleanup:
> + drm_mode_config_cleanup(ddev);
> +
> + return ret;
> +}
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
arm-kernel/2014-August/279071.html
simpledrm isn't a real driver, but only meant to be used to drive the
firmware framebuffer in early boot until a real driver takes over. It's a
replacement really for all the various uefi/vesa/whatever fbdev drivers.
Full reliance on the firmware very much intended.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
++
> 10 files changed, 1477 insertions(+)
> create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
> create mode 100644 drivers/gpu/drm/simpledrm/Makefile
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
> create mode 100644 drivers/gpu/drm/simpledr
xtracting dma-buf stuff (dma_buf, fence, reservation and all
that) is ok though, it is a fairly stand-alone topic.
-Daniel
>
> > Does that make sense?
> >
> I do hope that my proposal above finds some merit with everyone.
>
> > Thanks,
> >
> > jon
>
> BR,
> Sumit.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
a4 ("fence: dma-buf cross-device synchronization (v18)")
>
> Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
On patches 1&2 Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> include/linux/fence.h | 2 +-
> 1 file changed, 1 insertion(+
fig.mutex);
> [4.255291]
> *** DEADLOCK ***
>
> And i915 related kconfigs are here:
>
> CONFIG_DRM_I915=m
> CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y
> CONFIG_DRM_I915_USERPTR=y
> CONFIG_DRM_I915_GVT=y
> # CONFIG_DRM_I915_WERROR is not set
> # CO
; + if (fbdev->fb_helper.fbdev->state != FBINFO_STATE_RUNNING)
> + sdrm_fbdev_set_suspend(fbdev->fb_helper.fbdev, 0);
> +}
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> b/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> index 00e50d9..92ddc116 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_kms.c
> @@ -24,6 +24,13 @@ static const uint32_t sdrm_formats[] = {
> DRM_FORMAT_XRGB,
> };
>
> +void sdrm_lastclose(struct drm_device *ddev)
> +{
> + struct sdrm_device *sdrm = ddev->dev_private;
> +
> + sdrm_fbdev_restore_mode(sdrm);
> +}
> +
> static int sdrm_conn_get_modes(struct drm_connector *conn)
> {
> struct sdrm_device *sdrm = conn->dev->dev_private;
> @@ -91,8 +98,9 @@ void sdrm_display_pipe_update(struct
> drm_simple_display_pipe *pipe,
> struct sdrm_device *sdrm = pipe_to_sdrm(pipe);
>
> sdrm_crtc_send_vblank_event(>crtc);
> + sdrm_fbdev_display_pipe_update(sdrm, fb);
>
> - if (fb) {
> + if (fb && fb->funcs->dirty) {
> pipe->plane.fb = fb;
> sdrm_dirty_all_locked(sdrm);
> }
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sun, Aug 14, 2016 at 06:52:04PM +0200, Noralf Trønnes wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit
, ret);
> +
> drm_connector_register(connector);
> drm_mode_connector_attach_encoder(connector, encoder);
>
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; + !fb_helper->dev || fb_helper->fbdev != info)
> + return NOTIFY_DONE;
> +
> + sdrm = fb_helper->dev->dev_private;
> +
> + if (sdrm && sdrm->fbdev)
> + platform_device_del(sdrm->ddev->platformdev);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block sdrm_fbdev_event_notifier = {
> + .notifier_call = sdrm_fbdev_event_notify,
> +};
> +
> +void sdrm_fbdev_kickout_init(void)
> +{
> + fb_register_client(_fbdev_event_notifier);
> +}
> +
> +void sdrm_fbdev_kickout_exit(void)
> +{
> + fb_unregister_client(_fbdev_event_notifier);
> +}
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
m/simpledrm/simpledrm.h
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c
>
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > > > > + drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > > > > + MTK_LUT_SIZE);
> > > >
> > > > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > > > drm_helper_crtc_enable_color_mgmt with:
> > > >
> > > > drm_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > > >true, MTK_LUT_SIZE);
> > >
> > > BTW that looks wrong (already in the original). AFAICS the patch just
> > > handled the gamma_lut, not the degamma_lut, so telling you have both
> > > is not right.
> >
> > Thanks, so should that be
> >drm_crtc_enable_color_mgmt(_crtc->base, 0, false,
> > MTK_LUT_SIZE);
> > instead, since we only handle gamma?
>
> Hmm. Yeah, that looks correct since you didn't seem to have "ctm" either.
Yup, that's how this is meant to be used.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; > mtk_plane_atomic_update
> > drm/mediatek: plane: Use FB's format's cpp to compute x offset
>
> These two don't apply. Could you please rebase them onto
> git.pengutronix.de/git/pza/linux.git mediatek-drm/next
Note that I think most of them are already in drm-misc, and that branch is
non-rebasing.
-Daniel
>
> regards
> Philipp
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ver load, and
simply proceed if it's not there. Adding a sysfs interface (which is
abi) seems way too much overkill for this imo. If you want to upgrade
the firmware you can then just drop it into the right directory, with
no further interaction needed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
are getting fixed).
I think a good plan would be:
1. Move this tracking into drm panel helpers, ditch it from all drivers.
2. Add WARN_ON for multiple enables/disables, but only for DRIVER_ATOMIC.
Makes sure we can remove this boilerplate, makes sure that atomic drivers
are consistent, leaves existing drivers unharmed.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ockchip_drm_vop.c
> > @@ -34,6 +34,7 @@
> > #include "rockchip_drm_drv.h"
> > #include "rockchip_drm_gem.h"
> > #include "rockchip_drm_fb.h"
> > +#include "rockchip_drm_psr.h"
> > #include "rockchip_drm_vop.h"
> >
> > #define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \
> > @@ -121,6 +122,9 @@ struct vop {
> > /* protected by dev->event_lock */
> > struct drm_pending_vblank_event *event;
> >
> > + bool psr_enabled;
> > + struct delayed_work psr_work;
> > +
> > struct completion line_flag_completion;
> >
> > const struct vop_data *data;
> > @@ -911,6 +915,16 @@ static const struct drm_plane_funcs vop_plane_funcs = {
> > .atomic_destroy_state = vop_atomic_plane_destroy_state,
> > };
> >
> > +static void vop_psr_work(struct work_struct *work)
> > +{
> > + struct vop *vop = container_of(work, typeof(*vop), psr_work.work);
> > +
> > + if (vop->psr_enabled)
> > + rockchip_drm_psr_enable(>crtc);
> > + else
> > + rockchip_drm_psr_disable(>crtc);
> > +}
> > +
> > static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
> > {
> > struct vop *vop = to_vop(crtc);
> > @@ -925,6 +939,9 @@ static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
> >
> > spin_unlock_irqrestore(>irq_lock, flags);
> >
> > + vop->psr_enabled = false;
> > + schedule_delayed_work(>psr_work, msecs_to_jiffies(10));
> > +
> > return 0;
> > }
> >
> > @@ -941,6 +958,9 @@ static void vop_crtc_disable_vblank(struct drm_crtc
> > *crtc)
> > VOP_INTR_SET_TYPE(vop, enable, FS_INTR, 0);
> >
> > spin_unlock_irqrestore(>irq_lock, flags);
> > +
> > + vop->psr_enabled = true;
> > + schedule_delayed_work(>psr_work, msecs_to_jiffies(10));
> > }
> >
> > static void vop_crtc_wait_for_update(struct drm_crtc *crtc)
> > @@ -1582,6 +1602,10 @@ static int vop_bind(struct device *dev, struct
> > device *master, void *data)
> > return ret;
> >
> > pm_runtime_enable(>dev);
> > +
> > + vop->psr_enabled = false;
> > + INIT_DELAYED_WORK(>psr_work, vop_psr_work);
> > +
> > return 0;
> > }
> >
> > --
> > 1.9.1
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
last reference
holder any more? What if there's a 2nd sync_file that now stops working
because the callbacks went poof? Some other driver that registered
callbacks?
Generally mixing refcounting with explicit teardown is really tricky,
fragile and tends to not work. This smells fishy.
Why exactly do we have
On Mon, Jul 04, 2016 at 11:27:38AM +0200, Andrea Merello wrote:
> On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> > On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote:
> >> This driver supports the VGA/LCD core available f
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/include/linux/kref.h b/include/linux/kref.h
> >>>> index 484604d..83d1f94 100644
> >>>> --- a/include/linux/kref.h
> >>>> +++ b/include/linux/kref.h
> >>>> @@ -166,6 +166,6 @@ static inline int kref_put_mutex(struct kref *kref,
> >>>> */
> >>>> static inline int __must_check kref_get_unless_zero(struct kref *kref)
> >>>> {
> >>>> - return atomic_add_unless(>refcount, 1, 0);
> >>>> + return atomic_inc_not_zero(>refcount);
> >>>> }
> >>>> #endif /* _KREF_H_ */
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> > are no pending tasks while disconnecting the driver.
> >
> > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com>
>
> Acked-by: Tejun Heo <t...@kernel.org>
Applied to drm-misc, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
uld be squashed together when
> applying.
For all the drm driver patches:
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Should I pull these in through drm-misc, or do you prefer to merge them
through a special topic branch (with everything else) instead on your own?
-Daniel
>
>
s *ops,
> spinlock_t *lock, u64 context, unsigned seqno);
>
> +struct fence **fence_get_fences(struct fence *fence);
> void fence_release(struct kref *kref);
> void fence_teardown(struct fence *fence);
> void fence_free(struct fence *fence);
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
split up into 3 patches? At least it's good practice to
split up the drm core helper functions into it's own patch, instead of
hiding it behind something with the drm/imx prefix - no one will spot it
that way.
> Ping?!
If imx maintainers keep being asleep at the helm I can merge this through
g
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
scripts/kernel-doc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 27757c21551a..e067cfb59321 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2969,7 +2969,7 @
gt;ttm);
> + ttm_tt_destroy(bo->ttm);
> atomic_dec(>glob->bo_count);
> if (bo->resv == >ttm_resv)
> reservation_object_fini(>ttm_resv);
> --
> 2.9.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
1401 - 1500 of 6575 matches
Mail list logo
