ueue.
Cc: Matt Roper
Cc: Linus Torvalds
Cc: Paul Bolle
Signed-off-by: Daniel Vetter
---
Just to make it really clear: This is 4.1-next material. It's simply
the explanation for why we didn't notice the oops ourselves. The 4.0
oops itself looks like some glue lacking in the load detect co
On Mon, Mar 2, 2015 at 5:53 PM, Linus Torvalds
wrote:
> On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter wrote:
>> And can you please attach a bactrace of the WARN in your patch, just to
>> double-check you blow up at the same spot?
>
> So the dmesg I attached had a backtrace
On Sun, Dec 14, 2014 at 02:07:19AM +0100, Emmanuel Benisty wrote:
> Hi Daniel,
>
> > On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter
> > wrote:
> >> Adding relevant mailing lists.
> >>
> >>
> >> On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Ben
sect", and the offending commit is this one:
>
> [root@kiera linux-git]# git bisect bad
> 83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit
> commit 83f45fc360c8e16a330474860ebda872d1384c8c
> Author: Daniel Vetter
> Date: Wed Aug 6 09:10:18 2014 +020
you could take it, Otherwise we will have to wait everyone's ack
> to get this through drm-next I think.
I'll probably mass-apply the leftovers to drm-misc in 2-3 weeks latest.
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
uot;kick out 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
ing
> Acked-by: Philipp Zabel
> Acked-by: Manfred Schlaegl
> Signed-off-by: Stefan Agner
Since I bikeshedded the old patches that used the display mode stuff to
death, and I think this makes a lot more sense:
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/panel/panel-simple.c |
ting
> driver-specific implementations with the generic one.
>
> Signed-off-by: Alexey Brodkin
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Boris Brezillon
> ---
>
> No changes v5 -> v6.
>
> Changes v4 -> v5:
> * Added missing mutex unlock on a fail
ins of both register_ and 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()
> *
it(info, image);
> + sys_imageblit(info, image);
>
> udl_handle_damage(&ufbdev->ufb, image->dx, image->dy, image->width,
> image->height);
> --
> 2.2.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nfo, 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
qxl_fb_image_init(&qxl_fb_image, qdev, info, NULL);
> + qxl_draw_opaque_fb(&qxl_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 +271,8 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
>
> info->par = qfbdev;
>
> - qxl_framebuffer_init(qdev->ddev, &qfbdev->qfb, &mode_cmd, gobj);
> + qxl_framebuffer_init(qdev->ddev, &qfbdev->qfb, &mode_cmd, gobj,
> + &qxlfb_fb_funcs);
>
> fb = &qfbdev->qfb.base;
>
> @@ -504,7 +393,6 @@ int qxl_fbdev_init(struct qxl_device *qdev)
> qfbdev->qdev = qdev;
> qdev->mode_info.qfbdev = qfbdev;
> spin_lock_init(&qfbdev->delayed_ops_lock);
> - spin_lock_init(&qfbdev->dirty.lock);
> INIT_LIST_HEAD(&qfbdev->delayed_ops);
>
> drm_fb_helper_prepare(qdev->ddev, &qfbdev->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(&qdev->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
info->fbdefio = fbdefio;
> + fb_deferred_io_init(info);
> + if (!fb_defio) /* see commit 677d23b */
> + info->fbops->fb_mmap = udl_fb_mmap;
> }
> -
> - info->
mage 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 as we
xplicitly. But
that's only the case for DRM_AUTH ioctls.
Reviewed-by: Daniel Vetter
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
>
> Signed-off-by: Eric Anh
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 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
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 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 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
ndex > page->index)
> break;
> }
>
> list_add_tail(&page->lru, &cur->lru);
>
> page_already_added:
> mutex_unlock(&fbdefio->lock);
>
> /* come back after delay to process the deferred IO */
> schedule_delayed_work(&info->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(&fbdefio->lock);
> list_for_each_entry(cur, &fbdefio->pagelist, lru) {
> lock_page(cur);
> page_mkclean(cur);
> unlock_page(cur);
> }
>
> /* driver's callback with pagelist */
> fbdefio->deferred_io(info, &fbdefio->pagelist);
> ...
> mutex_unlock(&fbdefio->lock);
> }
>
>
> Noralf.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Apr 21, 2016 at 12:38:49PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clar
} else {
> + mixer->pending_event = event;
> + }
> + spin_unlock_irqrestore(&drm_dev->event_lock, flags);
> + }
> +out:
> + mutex_unlock(&drm_dev->struct_mutex);
> + return ret;
> +}
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
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)
> {
> - return intel_dp_dpcd_read_wake(&intel_dp->aux,
> + return drm_dp_dpcd_read(&intel_dp->aux,
> DP_DEVICE_SERVICE_IRQ_VECTOR,
> sink_irq_vector, 1) == 1;
> }
> @@ -4030,7 +3995,7 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8
> *sink_irq_vector)
> {
> int ret;
>
> - ret = intel_dp_dpcd_read_wake(&intel_dp->aux,
> + ret = drm_dp_dpcd_read(&intel_dp->aux,
>DP_SINK_COUNT_ESI,
>sink_irq_vector, 14);
> if (ret != 14)
> --
> 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 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
orary, 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
wrote:
> On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter wrote:
>>
>> Works all fine here, http, ssh & git protocols all up&running well.
>> Maybe temporary, or just your part of the interwebs fell off?
>
> I
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 Corpo
m_mode.h| 15 +
30 files changed, 524 insertions(+), 286 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > +static int arcpgu_atomic_commit(struct drm_device *dev,
> > > +
On Tue, Mar 15, 2016 at 03:24:46PM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:
> > On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> > >
> > > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vett
ting
> driver-specific implementations with generic one.
>
> Signed-off-by: Alexey Brodkin
> Cc: Daniel Vetter
> Cc: David Airlie
> ---
> drivers/gpu/drm/drm_crtc.c | 44 +++-
> drivers/gpu/drm/drm_drv.c | 3 ++-
> include/d
On Fri, Mar 18, 2016 at 09:58:49PM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Fri, 2016-03-18 at 19:06 +0100, Daniel Vetter wrote:
> > On Fri, Mar 18, 2016 at 01:01:42PM +0300, Alexey Brodkin wrote:
> > >
> > > As a pair to already existing drm_co
>is_mst = true;
> > @@ -4112,7 +4077,7 @@ stop:
> > static bool
> > intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector)
> > {
> > - return intel_dp_dpcd_read_wake(&intel_dp->aux,
> > + return drm_dp_dpcd_read(&intel_dp->aux,
> >DP_DEVICE_SERVICE_IRQ_VECTOR,
> >sink_irq_vector, 1) == 1;
> > }
> > @@ -4122,7 +4087,7 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp,
> > u8 *sink_irq_vector)
> > {
> > int ret;
> >
> > - ret = intel_dp_dpcd_read_wake(&intel_dp->aux,
> > + ret = drm_dp_dpcd_read(&intel_dp->aux,
> > DP_SINK_COUNT_ESI,
> > sink_irq_vector, 14);
> > if (ret != 14)
> > @@ -4383,7 +4348,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> > uint8_t reg;
> >
> > - if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_SINK_COUNT,
> > ®, 1) < 0)
> > return connector_status_unknown;
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> 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
On Fri, Mar 18, 2016 at 08:11:49AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Fri, 2016-03-18 at 09:02 +0100, Daniel Vetter wrote:
> > On Thu, Mar 17, 2016 at 08:27:10PM +, Alexey Brodkin wrote:
> > >
> > > Hi Daniel,
> > >
> > > On
On Sun, Apr 24, 2016 at 11:16:34AM +0100, Emil Velikov wrote:
> On 22 April 2016 at 09:24, Daniel Vetter wrote:
> > 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, 2
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: clip rectangle
> + *
is will break this driver so use the
> sys_{fillrect,copyarea,imageblit} functions directly.
>
> Signed-off-by: Noralf Trønnes
For patches 2&3: Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_fb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(
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 Vette
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
v_cma->fb) {
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index be62bd3..6554b6f 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -4,11 +4,18 @@
> struct drm_fbdev_cma;
> struct drm_gem_cma_obje
On Sun, Apr 24, 2016 at 10:49:01PM +0200, Noralf Trønnes wrote:
> Use the fbdev deferred io support in drm_fb_helper which mirrors the
> one qxl has had.
> This patch has only been compile tested.
>
> Signed-off-by: Noralf Trønnes
Yay for deleting code. Reviewed-by
when in atomic).
>
> This patch has only been compile tested.
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Changes since v1:
> - No need to enable deferred_io by default since drm_fb_helper uses
> a dedicated worker for flushing
Hooray for deleting code. Reviewed
>>>> + * @r: clip rectangle whose width is returned
> > >>>> + *
> > >>>> + * RETURNS:
> > >>>> + * The width of the clip rectangle.
> > >>>> + */
> > >>>> +static inline int drm_clip_rect_width(const struct drm_c
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,
> > drivers/dma-buf/fence.c | 2 +-
> > drivers/dma-buf/sync_file.c | 60 +
> > drivers/gpu/drm/Kconfig | 1 +
> > drivers/gpu/drm/drm_atomic.c | 196
> > +
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: Comments by Daniel Vetter:
erty is easier to
> handle in userspace than the array. Any other idea?
Imo FENCE_FD is perfectly fine. But what's the concern around giving
people the wrong idea with attaching fences to planes? For nonblocking
commits we need to store them somewhere for the worker, drm_plane_stat
fences fds back in
> the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.
>
> struct drm_out_fences {
> __u32 crtc_id;
> __u32 fd;
> };
>
> v2: Comment by Rob Clark:
> - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
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ä :
> > >
> > > > On Mon, Ap
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:
> > > &
working anymore until reboot with 4.1.9 which 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
On Tue, Mar 29, 2016 at 6:16 PM, Andy Lutomirski wrote:
> On Tue, Mar 29, 2016 at 12:49 AM, Andy Lutomirski wrote:
>> On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter
>> wrote:
>>> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski
>>> wrote:
>>>> A
int intel_lid_notify(struct notifier_block *nb,
> unsigned long val,
>* and as part of the cleanup in the hw state restore we also redisable
>* the vga plane.
>*/
> - if (!HAS_PCH_SPLIT(dev)) {
> - drm_modeset_lock_all(dev);
> + if (!HAS_PCH_SPLIT(de
On Tue, Mar 29, 2016 at 05:42:01PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Signed-off-by: Borislav Petkov
> Cc: intel-...@lists.freedesktop.org
Acked-by: Daniel Vetter
> ---
>
> @tip guys, the pat_bsp_init() and pat_ap_init() hunk will conflict wit
t running on top of implicitly synced
ozone/kms.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 1263
> drivers/gpu/drm/rockchip/Kconfig |9 +
> drivers/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
On Fri, Apr 01, 2016 at 05:21:52PM +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 engine being supported at the moment.
>
> Cc: David Brown
> Cc: Brian S
On Fri, Apr 01, 2016 at 05:21:52PM +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 engine being supported at the moment.
>
> Cc: David Brown
> Cc: Brian S
On Tue, Apr 12, 2016 at 06:13:49PM +0100, Liviu Dudau wrote:
> On Tue, Apr 12, 2016 at 05:47:57PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > > +static int malidp_enable_vblank(struct drm_device *drm, unsign
On Tue, Apr 12, 2016 at 06:16:54PM +0100, Liviu Dudau wrote:
> On Tue, Apr 12, 2016 at 05:58:11PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > > Add support for the new family of Display Processors from ARM Ltd.
> >
On Fri, Oct 30, 2015 at 03:20:54PM +0100, Maxime Ripard wrote:
> The Allwinner A10 and subsequent SoCs share the same display pipeline, with
> variations in the number of controllers (1 or 2), or the presence or not of
> some output (HDMI, TV, VGA) or not.
>
> This hardware supports 4 layers and 3
te mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.h
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.h
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.
= false;
> > radeon_connector_free_edid(connector);
> >diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> >b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> >index 171d3e4..579c22c 100644
> >--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> >+++ b
. those
> on marginal power) which send you HPD storms as well. But DP relies on
> 'short HPD' pulses which can be as brief as 2ms. So attempting to
> totally debounce all HPD won't work.
In our experience in i915 DP hpd works perfectly on all machines. At least
we never h
de_end(entry), \
> - 1 : 0; \
> - entry = list_entry((backwards) ? entry->hole_stack.prev :
> entry->hole_stack.next, struct drm_mm_node, hole_stack))
> + __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, 0)
>
> /*
> * Basic range manager supp
sues
> - move the sync framework to drivers/base/dma-buf
>
> Cc: Arve Hjønnevåg
> Cc: Riley Andrews
> Cc: Daniel Vetter
> Cc: Rob Clark
> Cc: Greg Hackmann
> Cc: John Harrison
> Signed-off-by: Gustavo Padovan
This reflects my recollection of various discussion
On Tue, Nov 24, 2015 at 09:51:12AM +0100, Daniel Vetter wrote:
> On Mon, Nov 23, 2015 at 05:41:53PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > - remove sw_sync, it is used only for testing/debugging and should not
> > be upstreamed.
> >
mostly a problem for integrated gpus, since discrete ones usually
require contiguous vram for scanout. I think saying "don't do that" is a
valid option though, i.e. we're assuming that page mappings for a in-use
scanout range never changes on the guest side. That is true for at le
On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote:
> On Monday, June 29, 2015 5:25 PM, Daniel Vetter
> wrote:
>> As long as the display is up and running we should have a fair stab at
>> showing the oops - it's just that no one has seriously bothered with
>> the neces
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote:
> On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
&g
gt;
> Can you mix compilation flag and module param ?
Hm, the point of the kconfig is to not require all the legacy baggage
from fbdev. But I guess a module option could be added later on too.
bochs has it too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
And I
think with Maarten's latest code (for 4.3) we'd just do an unconditional
compute_config (need it for fast pfit updates and fastboot), which means
the bogus values in ->dpll_hw_state aren't a problem any more since we'll
overwrite them again. And t
ount(dev, crtc);
> + pr_info("XXX: last:%u\n", last);
>
> ret = wait_event_timeout(dev->vblank[crtc].queue,
> - last != drm_vblank_count(dev, crtc),
> + last != (l = drm_vblank_count(dev, crtc)),
>
On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang wrote:
> On Tuesday, June 30, 2015 2:37 PM, Daniel Vetter
> wrote:
>> On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote:
>> >
>> > I think testing can be done by injecting a fatal machine check
>> > exception via ei
On Tue, Jun 30, 2015 at 06:07:44PM +0200, Michal Hocko wrote:
> On Tue 30-06-15 16:32:49, Daniel Vetter wrote:
> [...]
> > Looks like the vblank is actually running, just the wakeup somehow doesn't
> > happen in time. What machine is this (lspci -nn)?
>
> 00:0
eferences, no broken links are
> added.
>
> [1] - lists.freedesktop.org/archives/dri-devel/2014-August/065404.html
>
> Signed-off-by: Danilo Cesar Lemes de Paula
> Cc: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Jonathan Corbet
> Cc: Herbert Xu
&
On Tue, Jun 30, 2015 at 10:13:35PM +0200, Michal Hocko wrote:
> On Tue 30-06-15 18:59:29, Daniel Vetter wrote:
> [...]
> > I looked at dmesg, nothing out of the ordinary there. Unfortunately also
> > no hints why the pipe is somehow off when we think it's on. Can you pl
On Wed, Jul 1, 2015 at 9:26 AM, Rui Wang wrote:
> On Tuesday, June 30, 2015 11:24 PM, Daniel Vetter
> wrote:
>> On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang wrote:
>> > But einj does something more than what an IPI can do, it injects hardware
>> > errors which tri
On Wed, Jul 01, 2015 at 05:54:06PM +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2015-06-30 at 18:41 +0300, Jani Nikula wrote:
> > On Tue, 30 Jun 2015, Daniel Vetter wrote:
> > > On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote:
> > >> On Tue, 3
cmd,
> return -EFAULT;
>
> request = compat_alloc_user_space(sizeof(*request));
> - if (!access_ok(VERIFY_WRITE, request, sizeof(*request)) ||
> + if (!request ||
> __put_user(update32.handle, &request->handle) ||
> __put_user(update
gned int cmd,
> > unsigned long x;
> >
> > request = compat_alloc_user_space(sizeof(*request));
> > - if (!access_ok(VERIFY_WRITE, request, sizeof(*request))
> > - || !access_ok(VERIFY_WRITE, argp, sizeof(*argp))
> > + if (!request || !argp
&
ringbuffer.
> *
> * The ringbuffer might not be ready to accept the commands right away
> (maybe it needs to
> --
> 2.6.0.rc0.24.gec371ff
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-
drm_platform_register_drivers(struct platform_driver *const *drv,
> + int count);
> +void drm_platform_unregister_drivers(struct platform_driver *const *drv,
> +int count);
>
> /* returns true if currently okay to sleep *
; reverse of the execution path.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Sudip Mukherjee
Queued for -next, thanks for the patch.
-Daniel
> ---
>
> Sent on 27/07/2015
>
> drivers/gpu/drm/i915/intel_dp.c | 23 ++-
> 1 f
On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote:
> We were not checking the return value of drm_encoder_init() which can
> fail. And if it fails then we will be working with an uninitialized
> encoder.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-of
On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
>
> Cc: Daniel Vetter
> Cc: Jani N
The master control
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control
> interrupt lied (SDE)!
> [ 4057.592685] [drm:gen8_irq_handl
t, Maarten wrote:
> > > > Hey,
> > > >
> > > > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
> > > > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
> > > > > > On Tue, Sep 22, 2015 at 05:13:55PM +0200
vmas);
> - if (dev_priv->objects)
> - kmem_cache_destroy(dev_priv->objects);
> -
> + kmem_cache_destroy(dev_priv->requests);
> + kmem_cache_destroy(dev_priv->vmas);
> + kmem_cache_destroy(dev_priv->objects);
> pci_dev_put(dev_priv->bridge_dev);
&
void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> - if (state->mode_blob)
> - drm_property_unreference_blob(state->mode_blob);
> + drm_property_unreference_blob(sta
On Wed, Nov 11, 2015 at 02:14:12PM -0800, Maxime Ripard wrote:
> Hi Daniel,
>
> Thanks for your review!
Back from vacation, sorry for the delay.
>
> On Fri, Oct 30, 2015 at 03:44:09PM +0100, Daniel Vetter wrote:
> > > +static void sun4i_crtc_disab
gt; goto err_remove_crtc;
> }
> + ipu_crtc_set_primary_plane(ipu_crtc);
>
> /* If this crtc is using the DP, add an overlay plane */
> if (pdata->dp >= 0 && pdata->dma[1] > 0) {
> --
> 2.5.0
>
> ___
>
false;
> yres_specified = true;
> was_digit = false;
> } else
> @@ -1491,4 +1497,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
>
> out:
> return ret;
> -}
> \ No newline at e
t; + struct dma_buf_attachment *attach,
> struct sg_table *sgt);
> +
> void *rockchip_gem_prime_vmap(struct drm_gem_object *obj);
> void rockchip_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
>
> --
&
o that. The DRM core will automatically do that when setting up a
> default configuration, or as a result of userspace setting up the wanted
> configuration. You're also likely only seeing this the first time around
> and subsequent calls will not trigger this anymore because at that
simply made the checking more anal in
commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter
Date: Thu Oct 15 09:36:25 2015 +0200
drm/gem: Check locking in drm_gem_object_unreference
With the above added this is:
Reviewed-by: Daniel Vetter
>
> If we don't do this
1901 - 2000 of 3914 matches
Mail list logo
