ich hasn't
> happened with 4.4.5 yet ... do you think any of those would be worth
> further investigation? If so, any suggestions as to how to split it all
> into separate issues/how to go about it?
No idea about X stuff, not my expertise ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/gpu/drm/rockchip/Makefile |1 +
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 384 +
> include/drm/bridge/analogix_dp.h | 41 +
> 28 files changed, 4115 insertions(+), 3269 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> create mode 100644
> Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
> bridge/analogix/analogix_dp_reg.h} (62%)
> create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
> create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> create mode 100644 include/drm/bridge/analogix_dp.h
>
> --
> 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
ng on top of implicitly synced
ozone/kms.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 25, 2016 at 08:35:18PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 18:38, skrev Ville Syrjälä:
> >On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> >>>On Mon, Apr 25,
gt; > >>>> + *
> > >>>> + * RETURNS:
> > >>>> + * The width of the clip rectangle.
> > >>>> + */
> > >>>> +static inline int drm_clip_rect_width(const struct drm_clip_rect *r)
> > >>>> +{
> > >>>
l(>lru, >lru);
>
> page_already_added:
> mutex_unlock(>lock);
>
> /* come back after delay to process the deferred IO */
> schedule_delayed_work(>deferred_work, fbdefio->delay);
> return VM_FAULT_LOCKED;
> }
>
> static int fb_deferred_io_set_page_dirty(struct page *page)
> {
> if (!PageDirty(page))
> SetPageDirty(page);
> return 0;
> }
>
> /* workqueue callback */
> static void fb_deferred_io_work(struct work_struct *work)
> {
> ...
> /* here we mkclean the pages, then do all deferred IO */
> mutex_lock(>lock);
> list_for_each_entry(cur, >pagelist, lru) {
> lock_page(cur);
> page_mkclean(cur);
> unlock_page(cur);
> }
>
> /* driver's callback with pagelist */
> fbdefio->deferred_io(info, >pagelist);
> ...
> mutex_unlock(>lock);
> }
>
>
> Noralf.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
linux-foundation.org>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Rob Clark <robdcl...@gmail.com>
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Ack for i915 parts for merging through
On Thu, Apr 21, 2016 at 08:18:48PM +0200, Noralf Trønnes wrote:
>
> Den 21.04.2016 09:28, skrev Daniel Vetter:
> >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
rded the damage and returned, leaving it to the next call to
> push the changes.
That kind of explanation needs to be added to the commit message. I
completely missed that udl doesn't have an async work item for defio
from atomic.
> And in the following code I fixed a null pointer problem a
ret = -EBUSY;
> + } else {
> + mixer->pending_event = event;
> + }
> + spin_unlock_irqrestore(_dev->event_lock, flags);
> + }
> +out:
> + mutex_unlock(_dev->struct_mutex);
> + return ret;
> +}
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
f, 1)) {
> if (buf[0] & DP_MST_CAP) {
> DRM_DEBUG_KMS("Sink is MST capable\n");
> intel_dp->is_mst = true;
> @@ -4020,7 +3985,7 @@ stop:
> static bool
> intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector)
> {
> -
On Fri, Apr 22, 2016 at 04:17:14PM +0200, Noralf Trønnes wrote:
>
> Den 22.04.2016 10:27, skrev Daniel Vetter:
> >On Thu, Apr 21, 2016 at 08:54:45PM +0200, Noralf Trønnes wrote:
> >>Den 20.04.2016 17:25, skrev Noralf Trønnes:
> >>>This adds deferred io support if
, I didn't realize that you're reusing the same worker for both
things. 2 workers indeed make sense, since the mmap one must have a
built-in delay (to coalesce a bunch of writes), whereas the other one
probably should be run right away, after each op.
-Daniel
--
Daniel Vetter
Software Engineer, Intel
git protocols all up well.
Maybe temporary, or just your part of the interwebs fell off?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, Apr 22, 2016 at 7:30 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
>>
>> Works all fine here, http, ssh & git protocols all up well.
>> Maybe temporary, or jus
On Thu, Apr 28, 2016 at 11:36:44AM -0300, Gustavo Padovan wrote:
> 2016-04-27 Daniel Stone <dan...@fooishbar.org>:
>
> > Hi,
> >
> > On 26 April 2016 at 21:48, Greg Hackmann <ghackm...@google.com> wrote:
> > > On 04/26/2016 01:05 PM, Daniel Vetter wro
/udl_drv.h | 2 -
> drivers/gpu/drm/udl/udl_fb.c| 140 +-
> drivers/video/fbdev/core/fb_defio.c | 3 +-
> include/drm/drm_fb_cma_helper.h | 14 +++
> include/drm/drm_fb_helper.h | 15 +++
> include/linux/fb.h | 1 +
> 13 files changed, 372 insertions(+), 328 deletions(-)
>
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;funcs->dirty() by a dedicated worker
> > ensuring that it always runs in process context.
> >
> > Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
> > Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> > ---
>
> Thanks for the series! Unf
On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote:
>
> On 29/04/16 17:55, Daniel Vetter wrote:
>
> >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
> >> That sounds like a very bad idea to me...
> >>
> >> If t
Adding David, forgot that before hitting send.
-Daniel
On Fri, Apr 29, 2016 at 5:36 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote:
>>
>> On 29/04/16 17:55, Daniel Vetter wrote:
>>
>> >> Who's cal
--
>
> Changes since v2:
> - The drm_clip_rect_{width/height} functions are dropped, so open code it
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> still applies.
>
> Changes since v1:
> - Add FIXME about special dirty() callback for fbdev
> - Remove note in commit message about d
include/drm/drm_fb_cma_helper.h | 14 +++
> include/drm/drm_fb_helper.h | 15 +++
> include/linux/fb.h | 1 +
> 13 files changed, 378 insertions(+), 328 deletions(-)
>
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;
> + struct page *page;
> + u32 y1, y2;
> +
> + min = ULONG_MAX;
> + max = 0;
> + list_for_each_entry(page, pagelist, lru) {
> + start = page->index << PAGE_SHIFT;
> + end = start + PAGE_SIZE - 1;
> + min = m
anger in upstream to perfect the internal interfaces
anyway, but let's get this started.
Had some real nitpicks on the docs patch, but that can also be merged
later on imo. Except for that patch, on the series:
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>
> Thanks,
>
&
ile:
> +
> + fd_install(fd, sync_file->file);
> +
> +The sync_file fd now can be sent to userspace.
> +
> +If the creation process fail, or the sync_file needs to be released by any
> +other reason fput(sync_file->file) should be used.
With the above nitpicks fixed:
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> +
> +References:
> +[1] struct sync_file in include/linux/sync_file.h
> +[2] All interfaces mentioned above defined in include/linux/sync_file.h
> --
> 2.5.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 26, 2016 at 12:02:08PM -0300, Gustavo Padovan wrote:
> 2016-04-26 Daniel Vetter <dan...@ffwll.ch>:
>
> > On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> > >
&
On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
> On 04/26/2016 01:05 PM, Daniel Vetter wrote:
> >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, 2
andard struct fence.
>
> That means that no changes needed to any driver besides supporting fences.
>
> fence_collection's fence doesn't belong to any timeline context, so
> fence_is_later() and fence_later() are not meant to be called with
> fence_collections fences.
>
> v2: Comm
ed to store them somewhere for the worker, drm_plane_state
seems like an as good place as any other.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
M_MODE_ATOMIC_OUT_FENCE flag here.
>
> Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> ---
> drivers/gpu/drm/drm_atomic.c | 163
> +-
On Tue, Apr 26, 2016 at 06:24:54PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 11:09, skrev Daniel Vetter:
> >On Sun, Apr 24, 2016 at 10:48:58PM +0200, Noralf Trønnes wrote:
> >>This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
> >>The fbdev f
On Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote:
> > > 2016-04-26 Ville Syrjälä <ville.syrj...@linux.intel.com>:
> > &
On Wed, Apr 27, 2016 at 11:45:31AM +0200, Noralf Trønnes wrote:
>
> Den 26.04.2016 19:19, skrev Daniel Vetter:
> >On Tue, Apr 26, 2016 at 06:24:54PM +0200, Noralf Trønnes wrote:
> >>Den 25.04.2016 11:09, skrev Daniel Vetter:
> >>>On Sun, Apr 24, 2016 at 10:48
when in atomic).
>
> This patch has only been compile tested.
>
> Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
> ---
>
> Changes since v1:
> - No need to enable deferred_io by default since drm_fb_helper uses
> a dedicated worker for flushing
Hoor
n. This will break this driver so use the
> sys_{fillrect,copyarea,imageblit} functions directly.
>
> Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
For patches 2&3: Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/gpu/drm/qxl/qxl_fb.c | 6 +++--
On Sun, Apr 24, 2016 at 11:16:34AM +0100, Emil Velikov wrote:
> On 22 April 2016 at 09:24, Daniel Vetter <dan...@ffwll.ch> wrote:
> > On Thu, Apr 21, 2016 at 08:18:48PM +0200, Noralf Trønnes wrote:
> >>
> >> Den 21.04.2016 09:28, skrev Daniel Vetter:
> >>
pload the entire screen. We've talked about adding a
dirty rectangle to atomic to allow userspace to optimize this, but there
should _never_ be a need to do a dirtyfb call around a modeset. Probably
just a driver bug in your panel drm drivers?
With the above line removed:
Reviewed-by: Daniel Ve
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
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -4,11 +4,18 @@
> struct drm_fbdev_cma;
> struct drm_gem_cma_object;
>
> +struct drm_fb_helper_surface_size;
> +struct drm_framebuffer_funcs;
> +struct drm_fb_helper_funcs;
> struct drm_framebuffer;
> +struct drm_fb_helper;
> struct drm_device;
> struct drm_file;
> struct drm_mode_fb_cmd2;
>
> +struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
> + unsigned int preferred_bpp, unsigned int num_crtc,
> + unsigned int max_conn_count, const struct drm_fb_helper_funcs *funcs);
> struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
> unsigned int preferred_bpp, unsigned int num_crtc,
> unsigned int max_conn_count);
> @@ -16,6 +23,13 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma);
>
> void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma *fbdev_cma);
> +int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
> + struct drm_fb_helper_surface_size *sizes,
> + struct drm_framebuffer_funcs *funcs);
> +
> +void drm_fb_cma_destroy(struct 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(struct drm_device *dev,
> struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t;x1 * 4) + (stride * clips->y1);
> +
> + qxl_fb_image_init(_fb_image, qdev, info, NULL);
> + qxl_draw_opaque_fb(_fb_image, stride);
> +
> + return 0;
> +}
> +
> +static const struct drm_framebuffer_funcs qxlfb_fb_funcs = {
> + .destroy = qxl_user_framebuffer_destroy,
> + .dirty = qxlfb_framebuffer_dirty,
> +};
> +
> static int qxlfb_create(struct qxl_fbdev *qfbdev,
> struct drm_fb_helper_surface_size *sizes)
> {
> @@ -383,7 +275,8 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
>
> info->par = qfbdev;
>
> - qxl_framebuffer_init(qdev->ddev, >qfb, _cmd, gobj);
> + qxl_framebuffer_init(qdev->ddev, >qfb, _cmd, gobj,
> + _fb_funcs);
>
> fb = >qfb.base;
>
> @@ -504,7 +397,6 @@ int qxl_fbdev_init(struct qxl_device *qdev)
> qfbdev->qdev = qdev;
> qdev->mode_info.qfbdev = qfbdev;
> spin_lock_init(>delayed_ops_lock);
> - spin_lock_init(>dirty.lock);
> INIT_LIST_HEAD(>delayed_ops);
>
> drm_fb_helper_prepare(qdev->ddev, >helper,
> diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> index b2977a1..2319800 100644
> --- a/drivers/gpu/drm/qxl/qxl_kms.c
> +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> @@ -261,10 +261,6 @@ static int qxl_device_init(struct qxl_device *qdev,
> qdev->gc_queue = create_singlethread_workqueue("qxl_gc");
> INIT_WORK(>gc_work, qxl_gc_work);
>
> - r = qxl_fb_init(qdev);
> - if (r)
> - return r;
> -
> return 0;
> }
>
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+ */
> +static inline void drm_clip_rect_reset(struct drm_clip_rect *clip)
> +{
> + clip->x1 = 0;
> + clip->x2 = 0;
> + clip->y1 = 0;
> + clip->y2 = 0;
> +}
> +
> +/**
> + * drm_clip_rect_is_empty - Is clip rectangle empty?
> + * @clip
a small helper in each driver (or shared one in cma,
although cma doesn't yet grok reserverations/implicitly attached
fences).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
though ... In the end it's purely a transport question, and
both ABI ideas work out semantically exactly the same in the end. It's
just that at least in my opinion FENCE_FD prop is a lot more
convenient.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Thu, Apr 28, 2016 at 7:55 PM, Gustavo Padovan
<gustavo.pado...@collabora.co.uk> wrote:
> 2016-04-28 Ville Syrjälä <ville.syrj...@linux.intel.com>:
>
>> On Thu, Apr 28, 2016 at 07:43:16PM +0200, Daniel Vetter wrote:
>> > On Thu, Apr 28, 2016 at 6:56 P
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 Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote:
> > > &
-buf/fence-collection.c| 159
> > drivers/dma-buf/fence.c | 2 +-
> > drivers/dma-buf/sync_file.c | 60 +
> > drivers/gpu/drm/Kconfig | 1 +
> > drivers/gpu/drm/drm_atomic.c
On Thu, May 19, 2016 at 04:26:49PM +0100, Liviu Dudau wrote:
> On Mon, Apr 25, 2016 at 03:19:23PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display
, the bochsdrmfb driver needs to adjust
> + * file->f_mapping so it can use ttm_fbdev_mmap().
> + */
> + int (*fb_open_adj_file)(struct fb_info *info, struct file *file);
> };
>
> #ifdef CONFIG_FB_TILEBLITTING
> --
> 2.6.6
>
> ___
> 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
; @@ -67,6 +67,7 @@ static inline struct fence_array *to_fence_array(struct
> fence *fence)
> }
>
> struct fence_array *fence_array_create(int num_fences, struct fence **fences,
> -u64 context, unsigned seqno);
> +u64 context, unsigned seqno,
> +bool signal_on_any);
>
> #endif /* __LINUX_FENCE_ARRAY_H */
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
andard struct fence.
>
> That means that no changes needed to any driver besides supporting fences.
>
> fence_collection's fence doesn't belong to any timeline context, so
> fence_is_later() and fence_later() are not meant to be called with
> fence_collections fences.
>
> v2: Comm
On Mon, May 23, 2016 at 01:29:11PM +0200, Christian König wrote:
> Am 23.05.2016 um 09:41 schrieb Daniel Vetter:
> >On Fri, May 20, 2016 at 11:47:28AM -0300, Gustavo Padovan wrote:
> >>2016-05-20 Christian König <deathsim...@vodafone.de>:
> >>
> &g
On Mon, May 23, 2016 at 03:58:41PM +0200, Christian König wrote:
> Am 23.05.2016 um 15:50 schrieb Daniel Vetter:
> >On Mon, May 23, 2016 at 01:25:22PM +0200, Christian König wrote:
> >>From: Christian König <christian.koe...@amd.com>
> >>
> >>If @sig
__
> 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 belong to any timeline context, so
> > fence_is_later() and fence_later() are not meant to be called with
> > fence_collections fences.
> >
> > v2: Comments by Daniel Vetter:
> > - merge fence_collection_init() and fence_collection_add()
> > - only add callbacks at ->
drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
> > if (hole_start > node->start || hole_end < end)
> > --
> > 2.1.4
>
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
Applied to drm-misc, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 24, 2016 at 10:30:50AM +0200, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 10:28:42AM +0200, Heiko Stuebner wrote:
> > Hi Tomeu,
> >
> > Patch subject: please put the version into the brackets, so [PATCH v5] as
> > it
> > shouldn't be part of the
>
> > drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 25
> > ++--- drivers/gpu/drm/rockchip/rockchip_drm_vop.c |
> > 6 ++
> > 3 files changed, 29 insertions(+), 3 deletions(-)
>
> Heik
> > +#define MALIDP_BGND_COLOR_B0x000
> > > +
> > Something feels very wrong here. Are you sure what all three are zero ?
>
> Default background color. Black is #0.
>
> >
> >
> > > --- /dev/null
> > > +++ b
On Tue, May 24, 2016 at 10:41:30AM +0200, Heiko Stuebner wrote:
> Am Dienstag, 24. Mai 2016, 10:37:49 schrieb Daniel Vetter:
> > On Tue, May 24, 2016 at 10:30:50AM +0200, Daniel Vetter wrote:
> > > On Tue, May 24, 2016 at 10:28:42AM +0200, Heiko Stuebner wrote
ll for the userspace side of gpu drivers, and at least
some driver teams use C++ for the compilers in there.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, May 24, 2016 at 6:28 PM, Max Staudt <msta...@suse.de> wrote:
> Hi Daniel,
>
> Thanks for the feedback! Comments below:
>
>
> On 05/23/2016 03:44 PM, Daniel Vetter wrote:
>> Do we _really_ care about fbdev mmap support so much that we want to add
>> mo
pu driver, an array
> based implementation and a collection like one.
>
> Gustavo would you mind if I take your patches and work a bit on this?
I think the goal is to start landing the atomic fence stuff in 4.8.
Probably simplest if we converge on a first iteration that I can pull into
drm-misc right after 4.7-rc1. Then you can both base your respective work
on top of that branch (it's a stable one, so can even base official
branches on it).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 10, 2016 at 8:59 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
>> if (ret)
>> return ret;
>>
>> /* How to handle !visible, is it even possible? */
>
> if (!visible)
> return -EINVAL;
>
> You can't, so
it(). drm_fbdev_cma_fini() tears it down.
> - * If CONFIG_FB_DEFERRED_IO is enabled and the callback
> - * (struct drm_framebuffer_funcs)->dirty is set, fb_deferred_io
> + * If the _framebuffer_funcs ->dirty callback is set, fb_deferred_io
> * will be set up automatically. dirty() is
+ *
> + * This function is called when the underlying plane state is updated.
> + * This hook is optional.
> + */
> + void (*update)(struct drm_simple_display_pipe *pipe,
> +struct drm_plane_state *plane_state);
> +};
> +
> +/**
> + * struct drm_simple_display_pipe - simple display pipeline
> + * @crtc: CRTC control structure
> + * @plane: Plane control structure
> + * @encoder: Encoder control structure
> + * @connector: Connector control structure
> + * @funcs: Pipeline control functions (optional)
> + *
> + * Simple display pipeline with plane, crtc and encoder collapsed into one
> + * entity.
Maybe add: "It should be initialized by calling
drm_simple_display_pipe_init()". Imo never hurts to have a few too many
cross references ;-)
> + */
> +struct drm_simple_display_pipe {
> + struct drm_crtc crtc;
> + struct drm_plane plane;
> + struct drm_encoder encoder;
> + struct drm_connector *connector;
> +
> + struct drm_simple_display_pipe_funcs *funcs;
> +};
> +
> +int drm_simple_display_pipe_init(struct drm_device *dev,
> + struct drm_simple_display_pipe *pipe,
> + struct drm_simple_display_pipe_funcs *funcs,
> + const uint32_t *formats,
> + unsigned int format_count,
> + struct drm_connector *connector);
> +
> +#endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
> --
> 2.8.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
lper_connector_dpms(struct drm_connector *connector,
>int mode);
> +struct drm_encoder *
> +drm_atomic_helper_best_encoder(struct drm_connector *connector);
>
> /* default implementations for state handling */
> void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
> --
> 2.8.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
encoder->base.id, encoder->name);
> @@ -981,10 +974,12 @@ void drm_atomic_helper_commit_modeset_enables(struct
> drm_device *dev,
>*/
> drm_bridge_pre_enable(encoder->bridge);
>
> - if (funcs->enable)
> - funcs->enable(encoder);
> - else if (funcs->commit)
> - funcs->commit(encoder);
> + if (funcs) {
> + if (funcs->enable)
> + funcs->enable(encoder);
> + else if (funcs->commit)
> + funcs->commit(encoder);
> + }
>
> drm_bridge_enable(encoder->bridge);
> }
> --
> 2.8.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
lay_pipe {
> + struct drm_crtc crtc;
> + struct drm_plane plane;
> + struct drm_encoder encoder;
> + struct drm_connector *connector;
> +
> + struct drm_simple_display_pipe_funcs *funcs;
> +};
Same thing as in the previous patch: Function table pointers should be
c
On Wed, May 11, 2016 at 07:09:10PM +0200, Daniel Vetter wrote:
> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:
> > +/**
> > + * drm_simple_display_pipe_init - Initialize a simple display pipeline
> > + * @dev: DRM device
> > + * @pipe: simple displa
On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
> On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> > On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> > >
c_state = drm_atomic_get_existing_crtc_state(plane_state->state,
> > + >crtc);
> > + if (crtc_state->enable != !!plane_state->crtc)
> > + return -EINVAL; /* plane must match crtc enable state */
> >
le *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_cmd2 *mode_cmd,
> + const struct drm_framebuffer_funcs *funcs);
> struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);
>
> --
> 2.8.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
,
>mode_cmd.height, mode_cmd.pitches[0]);
> --
> 1.8.3.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
On Tue, May 17, 2016 at 02:22:26PM +0200, Noralf Trønnes wrote:
>
>
> Den 17.05.2016 14:12, skrev Ville Syrjälä:
> >On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
> >>Den 17.05.2016 09:59, skrev Daniel Vetter:
> >>>On Tue, May 17, 2016 at 1
On Tue, May 17, 2016 at 3:14 PM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Tue, May 17, 2016 at 03:04:52PM +0200, Daniel Vetter wrote:
>> On Tue, May 17, 2016 at 02:22:26PM +0200, Noralf Trønnes wrote:
>> >
>> >
>> > Den 17.05.2016 14:12,
kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt
Please read this doc in it's entirety, ask on irc if you don't get certain
parts. Then come back an rework your patch.
Super short summary: _All_ the types you've used are absolute no-go in
ioctl structs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
opy->base.crtc)
> + drm_connector_reference(connector);
> +
Please use __drm_atomic_helper_connector_duplicate_state instead of
open-coding it.
Cheers, Daniel
> return >base;
> }
>
> --
> 2.1.4
>
> ___
> 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
eck out how other drivers are using this helper - it is explicitly
for the case where you duplicate the entire struct, and it just
initializes the core part from drm. You can then add your own fixup
code afterwards. It also doesn't matter whether you do kmalloc or
kcalloc or kmemdup - it does a memcpy
e anywhere, you must align
the entire struct to 64bits too, otherwise just align to 32bits.
This is a bit more than what's required, but it's much harder to screw up
that way.
-Daniel
> - each member of the struct must be the same offset for both 32bit and
> 64bit builds. ^^ helps with tha
nally, add a warning if allocating memory for the state information
> fails in tegra_dsi_connector_reset().
>
> Fixes: d2307dea14a4 ("drm/atomic: use connector references (v3)")
>
> Signed-off-by: Jon Hunter <jonath...@nvidia.com>
Reviewed-by: Daniel Vetter <
On Wed, May 18, 2016 at 10:18:52AM +0100, Jon Hunter wrote:
>
> On 17/05/16 18:36, Daniel Vetter wrote:
> > On Tue, May 17, 2016 at 7:29 PM, Jon Hunter <jonath...@nvidia.com> wrote:
> >>>> @@ -764,6 +769,9 @@ tegra_dsi_connector_duplicate_state(struct
; Fixes: d2307dea14a4 ("drm/atomic: use connector references (v3)")
>
> Signed-off-by: Jon Hunter <jonath...@nvidia.com>
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> Acked-by: Thierry Reding <tred...@nvidia.com>
Applied to drm
: Arnd Bergmann <a...@arndb.de>
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: nouv...@lists.freedesktop.org
>
&g
struct radeon_cs_chunk *chunk;
> struct radeon_cs_buckets buckets;
> unsigned i;
> --
> 2.7.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
On Thu, May 12, 2016 at 12:18 PM, Noralf Trønnes <nor...@tronnes.org> wrote:
> Den 12.05.2016 10:11, skrev Daniel Vetter:
>>
>> On Wed, May 11, 2016 at 07:09:10PM +0200, Daniel Vetter wrote:
>>>
>>> On Wed, May 11, 2016 at
i/sti_tvout.c
> > index 2c99016443e5..f983db5a59da 100644
> > --- a/drivers/gpu/drm/sti/sti_tvout.c
> > +++ b/drivers/gpu/drm/sti/sti_tvout.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gpu/drm/sti/sti_vid.c
> > index 5a2c5dc3687b..523ed19f5ac6 100644
> > --- a/drivers/gpu/drm/sti/sti_vid.c
> > +++ b/drivers/gpu/drm/sti/sti_vid.c
> > @@ -3,6 +3,7 @@
> > * Author: Fabien Dessenne <fabien.desse...@st.com> for STMicroelectronics.
> > * License terms: GNU General Public License (GPL), version 2
> > */
> > +#include
> >
> > #include
> >
> > --
> > 2.7.0
> >
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Working Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
xed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> comple
onfig
> > @@ -1,6 +1,6 @@
> > config DRM_FSL_DCU
> > tristate "DRM Support for Freescale DCU"
> > - depends on DRM && OF && ARM
> > + depends on DRM && OF && ARM && COMMON_CLK
> > select BACKLIGHT_CLASS_DEVICE
> > select BACKLIGHT_LCD_SUPPORT
> > select DRM_KMS_HELPER
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ay
pipeline these callbacks shouldn't even be needed at all. Tried just
removing them?
-Daniel
>
> int hdlcd_setup_crtc(struct drm_device *drm)
> --
> 2.8.1.dirty
>
> _______
> 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
b/include/drm/drm_panel_helper.h
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __DRM_PANEL_HELPER_H__
> +#define __DRM_PANEL_HELPER_H__
> +
> +struct drm_device;
> +struct drm_panel;
> +
> +struct drm_connector *drm_panel_connector_create(struct drm_device *dev,
> + struct drm_panel *panel,
> + int connector_type);
> +
> +#endif
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> +};
> +
> +/**
> + * struct drm_simple_display_pipe - simple display pipeline
> + * @crtc: CRTC control structure
> + * @plane: Plane control structure
> + * @encoder: Encoder control structure
> + * @connector: Connector control structure
> + * @funcs: Pipeline control functions (optional)
> + *
> + * Simple display pipeline with plane, crtc and encoder collapsed into one
> + * entity.
> + */
> +struct drm_simple_display_pipe {
> + struct drm_crtc crtc;
> + struct drm_plane plane;
> + struct drm_encoder encoder;
> + struct drm_connector *connector;
> +
> + struct drm_simple_display_pipe_funcs *funcs;
> +};
> +
> +int drm_simple_display_pipe_init(struct drm_device *dev,
> + struct drm_simple_display_pipe *pipe,
> + struct drm_simple_display_pipe_funcs *funcs,
> + const uint32_t *formats,
> + unsigned int format_count,
> + struct drm_connector *connector);
> +
> +#endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, May 06, 2016 at 04:34:08PM +0200, Noralf Trønnes wrote:
>
> Den 06.05.2016 16:15, skrev Thierry Reding:
> >On Fri, May 06, 2016 at 04:08:16PM +0200, Daniel Vetter wrote:
> >>On Fri, May 06, 2016 at 04:03:47PM +0200, Thierry Reding wrote:
> >>>On Thu,
On Fri, May 06, 2016 at 04:01:37PM +0200, Thierry Reding wrote:
> On Fri, May 06, 2016 at 03:39:53PM +0200, Noralf Trønnes wrote:
> >
> > Den 05.05.2016 19:03, skrev Daniel Vetter:
> > > On Thu, May 05, 2016 at 03:24:34PM +0200, Noralf Trønnes wrote:
> > >
pipeline structure. The only thing
variable you have to hook up to that is the drm_connector. And I think for
dead-simple panels avoiding the basic boilerplate in that does indeed make
some sense.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
are flushed using the callback
> >>(struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
> >>ensuring that it always runs in process context.
> >>
> >>Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
> >>Reviewed-by: Daniel
te_flip(struct drm_crtc *crtc, struct
> > drm_file *file)
> > if (!file || (event->base.file_priv == file)) {
> > mdp5_crtc->event = NULL;
> > DBG("%s: send event: %p", mdp5_crtc->name, event);
> > -
ct amdgpu_device
> > *adev,
> >
> > /* wakeup usersapce */
> > if (works->event)
> > - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> > + drm_crtc_send_vblank_event(_crtc->base, works->event);
> >
> > spin_unlock_irqrestore(>ddev->event_lock, flags);
> >
> >
>
> This patch and patch 8 are
>
> Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Both applied to drm-misc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Apr 29, 2016 at 04:57:05PM +0200, Daniel Vetter wrote:
> On Thu, Apr 28, 2016 at 05:18:30PM +0200, Noralf Trønnes wrote:
> > This patchset adds fbdev deferred io support to drm_fb_helper and
> > drm_fb_cma_helper.
> >
> > It channels fbdev mmap and fb_{write,
> > - drm_send_vblank_event(dev, 0, event);
> > + drm_crtc_send_vblank_event(>crtc, event);
> > drm_vblank_put(dev, 0);
> > }
> > spin_unlock_irqrestore(>event_lock, flags);
>
> --
> Regards,
>
> Laure
t;
> >
> > Thanks!
> > Do you prefer me to pick this one to my next pull request?
>
> Yes, please pick it.
I didn't see a confirmation, so smashed it into drm-misc.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
1301 - 1400 of 6575 matches
Mail list logo
