: Rodrigo Siqueira
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.c| 2 +-
> drivers/gpu/drm/vkms/vkms_drv.h| 4 ++--
> drivers/gpu/drm/vkms/vkms_output.c | 6 +++---
> drivers/gpu/drm/vkms/vkms_plane.c | 4 ++--
> 4 files changed, 8 insertions(+), 8 d
ignores Alpha channel */
> - memset(vaddr_out + src_offset + 24, 0, 8);
> - crc = crc32_le(crc, vaddr_out + src_offset,
> - sizeof(u32));
> + pixel = get_pixel_from_buffer(x, y, vaddr, composer);
> + bitmap_clear((void *)&pixel, 0, 8);
> + crc = crc32_le(crc, (void *)&pixel, sizeof(u32));
> }
> }
>
> --
> 2.21.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 11, 2019 at 09:27:30AM +, Philippe CORNU wrote:
> Hi Daniel,
>
>
> On 7/10/19 5:27 PM, Daniel Vetter wrote:
> > On Fri, Jul 05, 2019 at 12:41:03PM +, Philippe CORNU wrote:
> >> Hi Olivier,
> >> and many thanks for your patch.
> >&
d out by lockdep immediately.
> >
> > Additional to that I'm pretty sure that this used to work correctly
> > sometimes in the past, so I'm either hitting a rare corner case or
> > this broke just recently.
> >
> > Anyway can somebody take a look? I can try to provide a test case if
> > required.
> >
> > Thanks in advance,
> > Christian.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, May 21, 2019 at 12:56:30PM +0200, Maarten Lankhorst wrote:
> Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> > Create a new wrapper function for this, feels like there's some
> > refactoring room here between the two modes.
> >
> > Signed-off-by: Daniel V
Ingo Molnar
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Masahiro Yamada
Cc: Wei Wang
Cc: Andy Shevchenko
Cc: Thomas Gleixner
Cc: Jann Horn
Cc: Feng Tang
Cc: Kees Cook
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote:
> On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_s
On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
>
> On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> >
But we'll make it pink w/ yellow text or something like that
ofc :-)
Thanks, Daniel
>
> John Ogness
>
> [0]
> https://www.linuxplumbersconf.org/event/4/contributions/290/attachments/276/463/lpc2019_jogness_printk.pdf
> [1] https://lkml.kernel.org/r/20190704103321.10022-1-pmla...@suse.com
> [2] https://lkml.kernel.org/r/87lfvwcssu@linutronix.de
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sun, Sep 15, 2019 at 3:48 PM John Ogness wrote:
>
> On 2019-09-13, Daniel Vetter wrote:
> >> 2. A kernel thread will be created for each registered console, each
> >> responsible for being the sole printers to their respective
> >> consoles. With this, cons
> On 05/10/2018 09:58, Daniel Vetter wrote:
> > > On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
> > > wrote:
> > > >
> >
> > [...]
> >
> > > > OK, won't this be enough ?
> > > > --- a/include/drm/drm_mode_config.h
&g
o sour.
>
> > +*/
> > + acrtc->mst_encoder->base.possible_crtcs =
> > + amdgpu_dm_get_encoder_crtc_mask(dm->adev);
>
> Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()?
If we don't have the same hack for i915 mst I think we shouldn't merge
this ... broken userspace is broken.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88b703527ba70659365d989f29579f1292ebf9c3
>
> (look for csc_drm_to_base)
>
> Would be great to have a common helper which correctly accounts for
> all the variability.
Yeah the sign-bit 31.32 fixed point format is probably the most ludicrous
uapi fumble we've ever done. A shared function, rolled out to drivers, to
switch it to a signed 2 complements integer sounds like a _very_ good
idea.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> Yep, its not a real problem, I get a few like this every cycle.
Yeah totally within expectations when I acked that cleanup patch. We'll
probably have a few more lockdep annotation patches/changes that will
conflict in drm.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d_crtc_state, *new_crtc_state;
> > > > > struct drm_crtc_commit *commit;
> > > > > int i;
> > > > > @@ -2300,7 +2300,7 @@
> > > > > EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
> > > > > int drm_atomic_helper_prepare_planes(struct drm_device *dev,
> > > > >struct drm_atomic_state *state)
> > > > > {
> > > > > - struct drm_connector *connector;
> > > > > + struct drm_connector __maybe_unused *connector;
> > > > > struct drm_connector_state *new_conn_state;
> > > > > struct drm_plane *plane;
> > > > > struct drm_plane_state *new_plane_state;
> > > > > @@ -2953,9 +2953,9 @@ int drm_atomic_helper_disable_all(struct
> > > > > drm_device *dev,
> > > > > {
> > > > > struct drm_atomic_state *state;
> > > > > struct drm_connector_state *conn_state;
> > > > > - struct drm_connector *conn;
> > > > > + struct drm_connector __maybe_unused *conn;
> > > > > struct drm_plane_state *plane_state;
> > > > > - struct drm_plane *plane;
> > > > > + struct drm_plane __maybe_unused *plane;
> > > > > struct drm_crtc_state *crtc_state;
> > > > > struct drm_crtc *crtc;
> > > > > int ret, i;
> > > > > @@ -3199,11 +3199,11 @@ int
> > > > > drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state
> > > > > *state,
> > > > > {
> > > > > int i, ret;
> > > > > struct drm_plane *plane;
> > > > > - struct drm_plane_state *new_plane_state;
> > > > > + struct drm_plane_state __maybe_unused *new_plane_state;
> > > > > struct drm_connector *connector;
> > > > > - struct drm_connector_state *new_conn_state;
> > > > > + struct drm_connector_state __maybe_unused *new_conn_state;
> > > > > struct drm_crtc *crtc;
> > > > > - struct drm_crtc_state *new_crtc_state;
> > > > > + struct drm_crtc_state __maybe_unused *new_crtc_state;
> > > > >
> > > > > state->acquire_ctx = ctx;
> > > > >
> > > > > --
> > > > > 2.15.0
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-de...@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> Hi Daniel, Gerd,
>
> On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
> >
> > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > > This patch is an early RFC to judge the direction
gt;
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Signed-off-by: Lyude Paul
More official unit tests, yay!
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 27 --
> drivers/gpu/drm/selftest
port->mgr->cbs->destroy_connector(port->mgr, port->connector);
> + if (port->connector)
And this here I can't connect with the commit message. I'm confused, did
something go wrong with some rebase here, and this patch should have a
different title/summary?
-Daniel
> + port->mgr->cbs->destroy_connector(port->mgr, port->connector);
>
> drm_dp_port_teardown_pdt(port, port->pdt);
> port->pdt = DP_PEER_DEVICE_NONE;
> --
> 2.21.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt;dev, "Failed to initialise vblank\n");
> goto err_vblank;
> @@ -269,6 +276,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> long flags)
> goto err_vblank;
> }
>
> + drm_crtc_vblank_off(&mxsfb->pipe.crt
ny DMA mapping and
> see:
> cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c
> 6 ahci
> 257 e1000e
> 6 ehci-pci
>5891 nouveau
> 24 uhci_hcd
>
> Does nouveau having this high number of DMA mapping is normal ?
Yeah se
On Wed, Aug 14, 2019 at 09:00:29PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote:
> > We need to make sure implementations don't cheat and don't have a
> > possible schedule/blocking point deeply burried where review can
On Thu, Aug 15, 2019 at 5:10 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote:
>
> > You have to wait for the gpu to finnish current processing in
> > invalidate_range_start. Otherwise there's no point to any of this
>
On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote:
> > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote:
> > >
> > +#define __DRM_CKEY_CONV(ckey64, comp_name, nbits) \
> > + DIV_ROUND_UP((u16)((ckey64) >> __drm_ckey_ ## comp_name ## _shift), \
> > +1 << (16 - (nbits)))
>
> As the divisor is a power of two, could we use masking instead of a division
> ?
> Or do you expect the compiler to optimize it properly ?
>
> > +#define __DRM_CKEY_CLAMP(value, nbits) \
> > + min_t(u16, (value), (1 << (nbits)) - 1)
>
> Would the following be simpler to read and a bit more efficient as it avoids
> the division ?
>
> static inline u16 __drm_colorkey_extract_component(u64 ckey64,
>unsigned int shift,
>unsigned int nbits)
> {
> u16 mask = (1 << (16 - nbits)) - 1;
>
> return ((u16)(ckey >> shift) + mask) >> (16 - nbits);
> }
>
> #define drm_colorkey_extract_component(ckey64, comp_name, nbits) \
> __drm_colorkey_extract_component(ckey64, __drm_ckey_ ## comp_name ##
> _shift, nbits)
>
> > #endif
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> 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
Nobody's using cirrus because they care
> about color fidelity and it'll use less CPU to update. There's
> precedent here, mgag200 defaults to 16bpp on sufficiently memory-
> impaired devices.
Yeah nouveau does the same fallback to 16bpp if there's not enough vram.
Avoids the inverted condition compared to the open coded version.
Signed-off-by: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
---
include/linux/cpufreq.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux
other places.
Motivated by a discussion with Andy and Yisheng, who want to add
another for_each_macro which would benefit from for_each_if() instead
of hand-rolling it.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: Andrew Morton
Cc: Kees
On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
> wrote:
>
> > To avoid compilers complainig about ambigious else blocks when putting
> > an if condition into a for_each macro one needs to invert the
> >
connector.c | 4 +--
> include/drm/drm_crtc_helper.h | 7 +++--
> include/drm/drm_fb_helper.h | 5
> 6 files changed, 67 insertions(+), 7 deletions(-)
>
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
eram.h| 95
>> 15 files changed, 1 insertion(+), 993 deletions(-)
>> delete mode 100644 drivers/video/fbdev/sh_mobile_meram.c
>> delete mode 100644 include/video/sh_mobile_meram.h
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
dp_bridge.c | 1 +
> > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> > drivers/gpu/drm/rcar-du/rcar_lvds.c| 2 +-
> > drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> > drivers/gpu/drm/sti/sti_hda.c | 1 +
> > drivers/gpu/drm/sti/sti_hdmi.c | 1 +
> > include/drm/drm_bridge.h | 8
> > 27 files changed, 51 insertions(+), 33 deletions(-)
>
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> 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 (previous && (!previous->dev || previous->encoder != encoder))
> return -EINVAL;
>
> --
> 2.11.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
stent bridge supplier.
>
> Signed-off-by: Peter Rosin
Minus the ->owner bikeshed I brought up in the previous patch I agree with
this approach as the best way to move forward for now.
Acked-by: Daniel Vetter
One small suggestion below, for merging I'd say pls get Jyri's
review/t
x620/0x620
? _kthread_create_on_node+0x30/0x30
ret_from_fork+0x3a/0x50
Signed-off-by: Daniel Vetter
Cc: Dmitry Torokhov
Cc: Benjamin Tissoires
Cc: Daniel Vetter
Cc: Arvind Yadav
Cc: Stephen Lyons
Cc: linux-in...@vger.kernel.org
---
drivers/input/mouse/psmouse-base.c | 2 ++
1 file changed,
; */
> > > #define DRM_CLIENT_CAP_ATOMIC3
> > >
> > > +/**
> > > + * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
> > > + *
> > > + * If set to 1, the DRM core will expose special connectors to be used
> > > for
> > > + * writing back to memory the scene setup in the commit. Depends on
> > > client
> > > + * also supporting DRM_CLIENT_CAP_ATOMIC
> > > + */
> > > +#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS 4
> > > +
> > > /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
> > > struct drm_set_client_cap {
> > > __u64 capability;
> >
> > ~Maarten
> >
>
> --
>
> | 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
On Wed, May 23, 2018 at 03:05:35PM +0530, Souptick Joarder wrote:
> On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
> > On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
> >> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> >> > Hi S
+ u8 buf[MAX_ARG_LEN*2 + 2], status;
> > + struct i2c_msg msgs[MAX_ARG_LEN + 3];
> > int i, ret;
> >
> > + if (args_len > MAX_ARG_LEN) {
> > + DRM_ERROR("Need to increase arg length\n");
> > + return false;
> > + }
> > +
> > psb_intel_sdvo_debug_write(psb_intel_sdvo, cmd, args, args_len);
> >
> > for (i = 0; i < args_len; i++) {
> > --
> > 2.14.3
> >
>
>
>
> --
> Kees Cook
> Pixel Security
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n't add anything further to my git tree
> for tda998x development, as that would change what was sent to David
> back in April.
>
> The alternative would be for drm-misc to take it - I don't think it
> will conflict with anything I've already asked David to take, so t
gt;>
> >> @@ -114,17 +113,7 @@ int udl_gem_fault(struct vm_fault *vmf)
> >> return VM_FAULT_SIGBUS;
> >>
> >> page = obj->pages[page_offset];
> >> - ret = vm_insert_page(vma, vmf->address, page);
> >> - switch (ret) {
> >> - case -EAGAIN:
> >> - case 0:
> >> - case -ERESTARTSYS:
> >> - return VM_FAULT_NOPAGE;
> >> - case -ENOMEM:
> >> - return VM_FAULT_OOM;
> >> - default:
> >> - return VM_FAULT_SIGBUS;
> >> - }
> >> + return vmf_insert_page(vma, vmf->address, page);
> >> }
> >>
> >> int udl_gem_get_pages(struct udl_gem_object *obj)
> >> --
> >> 1.9.1
> >>
> >
> > Any comment on this patch ?
>
> If no comment, we would like to get this patch in queue
> for 4.18.
4.18 is done already, queued up for 4.19 in drm-misc-next.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
It's a debug hack flag useful to work around driver bugs. That's not a
good idea for a new driver. Especially for a new drm driver.
Aside: the fbdev support should probably be converted over to the new
generic fbdev support.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Han
Although given the lack of progress since 2010, maybe time to ditch it
from staging outright?
Signed-off-by: Daniel Vetter
Cc: Arnaud Patard
Cc: Daniel Vetter
---
drivers/staging/xgifb/TODO | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/xgifb/TODO b/drivers/staging
gt; > switch (link_bw) {
> > default:
> > WARN(1, "unknown DP link BW code %x, using 162000\n", link_bw);
> > + /* fall through */
> > case DP_LINK_BW_1_62:
> > return 162000;
> > case DP_LINK_BW_2_7:
> > @@ -552,6 +554,7 @@ int drm_dp_downstream_max_bpc(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE],
> > case DP_DS_16BPC:
> > return 16;
> > }
> > + /* fall through */
> > default:
> > return 0;
> > }
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
o->height, bo->format,
> - bo->gem_handles, bo->pitches, bo->offsets, &bo->fb_id,
> 0);
> + ret = drmModeAddFB2WithModifiers(drm_->fd(), bo->width, bo->height,
> + bo->format, bo->gem_handles, bo->pitches,
> + bo->offsets, modifiers, &bo->fb_id,
> + modifiers[0] ? DRM_MODE_FB_MODIFIERS : 0);
> +
>if (ret) {
> ALOGE("could not create drm fb %d", ret);
> return ret;
> --
> 2.7.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
rong way and
> introduced a local unnecessary ->enabled crtc state.
>
> This commit reverts the crctc _begin() and _enable() changes and simply
> adds drm_atomic_helper_commit_tail_rpm as helper.
>
> Reported-by: Tony McKahan
> Suggested-by: Daniel Vetter
> Fix
hat case just send out a pull for drm-next and include the merge
resolution in the pull request so Dave/I can double-check we did it right.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> > It's a debug hack flag useful to work around driver bugs. That's not a
> > good idea for a new driver. Especially for a new drm driver.
On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > MALI_GRA
On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > >
> > > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > >
On Tue, Jan 15, 2019 at 1:23 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 10:51:02AM +, Liviu Dudau wrote:
> > > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > >
On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
&g
outright?
Signed-off-by: Daniel Vetter
Cc: Arnaud Patard
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
---
drivers/staging/xgifb/TODO | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/xgifb/TODO b/drivers/staging/xgifb/TODO
index 7eb99140a399..a1e25957bf1b 100644
--- a/drivers
On Tue, Jan 15, 2019 at 4:32 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 15, 2019 at 04:15:49PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> >
or i915 we use all kinds of combinations,
e.g. cpu mmap ptes as cached w/ coherent device transactions, or
cached+clflush on the cpu side, and non-coherent device transactions (the
no-snoop thing), or wc mode in the cpu ptes and non-coherent device
transactions-
Plus some debug mode so we catch
ruct
> > intel_encoder *encoder,
> > */
> > if (IS_TV(intel_sdvo_connector)) {
> > if (!intel_sdvo_set_output_timings_from_mode(intel_sdvo, mode))
> > - return false;
> > + return -EINVAL;
> >
> > (void) intel_sdvo_get_preferred_input_mode(intel_sdvo,
> >intel_sdvo_connector,
> > @@ -1144,7 +1144,7 @@ static bool intel_sdvo_compute_config(struct
> > intel_encoder *encoder,
> > } else if (IS_LVDS(intel_sdvo_connector)) {
> > if (!intel_sdvo_set_output_timings_from_mode(intel_sdvo,
> >
> > intel_sdvo_connector->base.panel.fixed_mode))
> > - return false;
> > + return -EINVAL;
> >
> > (void) intel_sdvo_get_preferred_input_mode(intel_sdvo,
> >intel_sdvo_connector,
> > @@ -1153,7 +1153,7 @@ static bool intel_sdvo_compute_config(struct
> > intel_encoder *encoder,
> > }
> >
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > - return false;
> > + return -EINVAL;
> >
> > /*
> > * Make the CRTC code factor in the SDVO pixel multiplier. The
> > @@ -1193,7 +1193,7 @@ static bool intel_sdvo_compute_config(struct
> > intel_encoder *encoder,
> > if (intel_sdvo_connector->is_hdmi)
> > adjusted_mode->picture_aspect_ratio =
> > conn_state->picture_aspect_ratio;
> >
> > - return true;
> > + return 0;
> > }
> >
> > #define UPDATE_PROPERTY(input, NAME) \
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index d7a414ce2774..bd5536f0ec92 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -869,7 +869,7 @@ intel_tv_get_config(struct intel_encoder *encoder,
> > pipe_config->base.adjusted_mode.crtc_clock = pipe_config->port_clock;
> > }
> >
> > -static bool
> > +static int
> > intel_tv_compute_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config,
> > struct drm_connector_state *conn_state)
> > @@ -879,10 +879,10 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> > &pipe_config->base.adjusted_mode;
> >
> > if (!tv_mode)
> > - return false;
> > + return -EINVAL;
> >
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > - return false;
> > + return -EINVAL;
> >
> > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > adjusted_mode->crtc_clock = tv_mode->clock;
> > @@ -897,7 +897,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> > * or whether userspace is doing something stupid.
> > */
> >
> > - return true;
> > + return 0;
> > }
> >
> > static void
> > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> > index d116fead8514..c247ce74b71a 100644
> > --- a/drivers/gpu/drm/i915/vlv_dsi.c
> > +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> > @@ -256,9 +256,9 @@ static void band_gap_reset(struct drm_i915_private
> > *dev_priv)
> > mutex_unlock(&dev_priv->sb_lock);
> > }
> >
> > -static bool intel_dsi_compute_config(struct intel_encoder *encoder,
> > -struct intel_crtc_state *pipe_config,
> > -struct drm_connector_state *conn_state)
> > +static int intel_dsi_compute_config(struct intel_encoder *encoder,
> > + struct intel_crtc_state *pipe_config,
> > + struct drm_connector_state *conn_state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> > @@ -284,7 +284,7 @@ static bool intel_dsi_compute_config(struct
> > intel_encoder *encoder,
> > }
> >
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > - return false;
> > + return -EINVAL;
> >
> > /* DSI uses short packets for sync events, so clear mode flags for DSI
> > */
> > adjusted_mode->flags = 0;
> > @@ -302,16 +302,16 @@ static bool intel_dsi_compute_config(struct
> > intel_encoder *encoder,
> >
> > ret = bxt_dsi_pll_compute(encoder, pipe_config);
> > if (ret)
> > - return false;
> > + return -EINVAL;
> > } else {
> > ret = vlv_dsi_pll_compute(encoder, pipe_config);
> > if (ret)
> > - return false;
> > + return -EINVAL;
> > }
> >
> > pipe_config->clock_set = true;
> >
> > - return true;
> > + return 0;
> > }
> >
> > static bool glk_dsi_enable_io(struct intel_encoder *encoder)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> It's a debug hack flag useful to work around driver bugs. That's not a
> good idea for a new driver. Especially for a new drm driver.
>
> Aside: the fbdev support should probably be converted over to the new
&
t > qdev->vram_size) {
> > > - DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
> > > - return -EINVAL;
> > > - }
>
> ... that check moved into the new function.
>
> cheers,
> Gerd
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
k: internal irq_work function
> */
> struct dma_fence_array {
> struct dma_fence base;
> --
> 2.20.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 Wed, Nov 21, 2018 at 10:31 AM Daniel Vetter wrote:
>
> On Tue, Nov 13, 2018 at 12:52:14AM -0500, Sasha Levin wrote:
> > From: "Lee, Shawn C"
> >
> > [ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
> >
> > BOE panel (ID: 0x0771) that
panel
> > +
> > +Required properties:
> > +- compatible: should be "innolux,ee101ia-01d"
> > +
> > +This binding is compatible with the lvds-panel binding, which is specified
> > +in panel-lvds.txt in this directory.
>
>
>
>
> ___
> 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
se the new
> state->suspend_or_resume hook to fixup the atomic VCPI helpers so they
> merely save and restore the VCPI allocations for such states instead of
> performing error checking on them. This fixes the warnings during
> suspend/resume when a topology is removed from the
4.178687] WARNING: CPU: 2 PID: 1894 at
> drivers/gpu/drm/i915/intel_display.c:12292
> intel_atomic_commit_tail+0xd5e/0xdd0 [i915]
> [ 1894.178692] ---[ end trace 0df08c0b9a67376e ]---
>
> So, fix this by using the new drm_atomic_state.suspend_or_resume hook in
> order to for
t; [ 962.311162] page dumped because: kasan: bad access detected
>
> So, bail early if drm_dp_mst_deallocate_vcpi() is called on a port with
> no VCPI allocation. Additionally, clean up the surrounding kerneldoc
> while we're at it since the port is assumed to be kept a
On Mon, Feb 4, 2019 at 7:49 PM Sam Ravnborg wrote:
>
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:13AM +0100, Daniel Vetter wrote:
> > The compiler already clears this for us.
> >
> > More important, someone might look what this is actually used for,
> > an
| 13 +-
> > 17 files changed, 894 insertions(+), 789 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
> > delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> > create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> > create mode 100644 drivers/phy/cadence/cdns-dphy.c
> >
> > base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c
> >
> ___
> 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_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> +};
I'd include the lower-res formats too here, without those you limit
userspace that looks at this stuff to only these formats. Not that this is
really important for cirrus ... So 24bits would include 16, and 32 would
in
we could teach ttm to not have it's own vma node
...
Anyway, lgtm.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/boch
and would
> not be a burden for the fbdev maintainers, and I can grarantee that I will
> not add any other new features to this driver.
Awesome, and I think as a gradual plan this makes tons of sense.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 05, 2019 at 11:47:58AM +0100, Rafael J. Wysocki wrote:
> w/compOn Thu, Jan 31, 2019 at 3:46 PM Daniel Vetter
> wrote:
> >
> > Someone owes me a beer ...
> >
> > While typing these I think doing an s/component_master/aggregate/
> > would be useful:
an initial draft of these docs.
v2: Review from Rafael:
- git add Documenation/driver-api/component.rst
- lots of polish to the wording + spelling fixes.
Cc: "C, Ramalingam"
Cc: Greg Kroah-Hartman
Cc: Russell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo
On Tue, Feb 05, 2019 at 04:49:02PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 05, 2019 at 05:21:07PM +0100, Daniel Vetter wrote:
> > Someone owes me a beer ...
>
> I find that deeply offensive - it is clearly directed at me personally
> as author of th
org
> Signed-off-by: Rodrigo Siqueira
> ---
> Changes in V2:
> - Add "Cc: sta...@vger.kernel.org" tag
Since cc: stable please apply this patch to drm-misc-fixes, not
drm-misc-next like usual.
Acked-by: Daniel Vetter
>
> drivers/gpu/drm/vkms/vkms_cr
On Mon, Feb 04, 2019 at 07:54:16PM +0100, Sam Ravnborg wrote:
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
> > Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
> > for.
> Can you improve the gammar a lit
ell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo Vivi
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 17
Documentation/driver-api/device_link.rst | 3 +
Documentation/driver-api/index.rst | 1 +
d
ssues:
> -
> -- plain-flip-fb-recreate
> -- plain-flip-ts-check
> -- flip-vs-blocking-wf-vblank
> -- plain-flip-fb-recreate-interruptible
> -- flip-vs-wf_vblank-interruptible
Patch applied to drm-misc-next, thanks for your patch.
-Daniel
> -
> Runtime Configuration
> -
ir ID, including support to add/remove modes.
> -
> - Make ->funcs and ->helper_private vtables optional. There's a bunch of
> empty
>function tables in drivers, but before we can remove them we need to make
> sure
> that all the users in helpers and dri
-misc trees at least.
--------
Daniel Vetter (3):
component: Add documentation
components: multiple components for a device
i915/snd_hdac: I915 subcomponent for the snd_hdac
Documentation/driver-api/component.rst | 17 +++
On Mon, Feb 11, 2019 at 7:25 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> > Hi all,
> >
> > Here's the typed component topic branch.
> >
> > drm-intel maintainers: Please pull,
On Mon, Feb 11, 2019 at 7:57 PM Takashi Iwai wrote:
>
> On Mon, 11 Feb 2019 19:25:12 +0100,
> Sam Ravnborg wrote:
> >
> > Hi Daniel.
> >
> > On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > He
ng Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * Authors:
> + * Walter Goossens
> + * Thomas Chou
> + * Chris Rauer
> + * Ong, Hean-Loong
> + *
> + */
> +#ifndef _INTEL_VIP_DRV_H
> +#define _INTEL_VIP_DRV_
On Tue, Feb 12, 2019 at 9:08 AM Ong, Hean Loong
wrote:
> On Tue, 2019-02-12 at 08:46 +0100, Daniel Vetter wrote:
> > On Tue, Feb 12, 2019 at 10:36:23AM +0800, Hean-Loong, Ong via dri-
> > devel wrote:
> > > From: Ong, Hean Loong
> > >
> > > Driver for I
desktop.org/drm/msm.git
> S: Maintained
> F: drivers/gpu/drm/msm/
> F: include/uapi/drm/msm_drm.h
> --
> A
> 2.20.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 Wed, Feb 13, 2019 at 4:43 PM Rob Clark via dri-devel
wrote:
>
> On Wed, Feb 13, 2019 at 10:28 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 13, 2019 at 10:10:44AM -0500, Rob Clark via dri-devel wrote:
> > > We've moved the tree to a shared gitlab tree, so t
On Wed, Feb 13, 2019 at 11:23:07AM -0500, Sean Paul wrote:
> On Wed, Feb 13, 2019 at 05:04:59PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 13, 2019 at 4:43 PM Rob Clark via dri-devel
> > wrote:
> > >
> > > On Wed, Feb 13, 2019 at 10:28 AM Daniel Vetter wrot
t; is the easy part, the hard part is the compiler.
> > >
> > > So if we want any kind of freedom to play with the UAPI, enhance
> > > it or change it in anyway we must be free to build program for the
> > > device ourself.
> > >
> > > I believe tha
; Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
Merge the previous 5 patches from this series, but this now goes boom on
vbox in staging. Needs another prep patch I think.
-Daniel
> ---
> drivers/gpu/drm/drm_damage_helper.c | 1 +
>
dd forward of drm_gem_object to drm_framebuffer.h (Noralf)
> - Drop "drm: move DRM_IF_VERSION to drm_internal.h" as it is applied to
> drm-misc
> - Drop "drm: make drm_file.h self contained" as Jan made a similar patch that
> was appleid to drm-misc
> - Rebased on
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst| 5 +
driver
On Thu, Feb 07, 2019 at 03:26:13PM -0800, Eric Anholt wrote:
> We always decrement at GEM free, so make sure we increment at GEM
> creation for dma-bufs.
Indeed. Reviewed-by: Daniel Vetter
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/v3d/v3d_bo.c | 6 ++
&g
ned-off-by: Daniel Vetter (v1 code)
Signed-off-by: Ramalingam C (v1 commit message)
Cc: Ramalingam C
Cc: Greg Kroah-Hartman
Cc: Russell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo Vivi
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/base/componen
Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).
Author: Daniel Vetter
Date: Mon Jan 28 17:08:20 2019 +0530
components: mult
ael J. Wysocki
Cc: "C, Ramalingam"
Cc: Greg Kroah-Hartman
Cc: Russell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo Vivi
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 17
Documentation/drive
drmP.h from drm_modeset_helper.h")
>
> I have used the drm-misc tree from next-20190207 for today.
Yup.
Sam, can you pls take a look at what komeda needs? you need to
manually merge together drm-misc-next and drm-next first I think.
Dave, Maxime, Liviu: Heads up, drm-misc-next + drm-next will colide.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
r merging. You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
There isn't a "below" afaics
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ddc5 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -57,8 +57,7 @@
> #include
> #include
> #include
> -
> -#include
> +#include
> #include
> #include
>
> --
> MST
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 8, 2019 at 10:26 AM Stephen Rothwell wrote:
>
> Hi Daniel,
>
> On Fri, 8 Feb 2019 09:53:33 +0100 Daniel Vetter wrote:
> >
> > There isn't a "below" afaics
>
> Oops :-( However the merge diff is not very enlightening in this case
On Fri, Feb 08, 2019 at 10:28:49AM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote:
> > Component framework is extended to support multiple components for
> > a struct device. These will be matched with different masters b
On Fri, Feb 08, 2019 at 12:51:23PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 08, 2019 at 12:27:56AM +0100, Daniel Vetter wrote:
> > While typing these I think doing an s/component_master/aggregate/
> > would be useful:
> > - it's shorter :-)
> > - I think
On Fri, Feb 8, 2019 at 4:23 PM Daniel Vetter wrote:
>
> On Fri, Feb 08, 2019 at 10:28:49AM +, Russell King - ARM Linux admin
> wrote:
> > On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote:
> > > Component framework is extended to support multiple compo
On Fri, Feb 8, 2019 at 4:29 PM Daniel Vetter wrote:
>
> On Fri, Feb 08, 2019 at 12:51:23PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 08, 2019 at 12:27:56AM +0100, Daniel Vetter wrote:
> > > While typing these I think doing an s/component_master/aggregate/
> >> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> >> subsampled Cr:Cb plane 16 bits per channel */
> >> +
> >
> > looks good to me.
> > Reviewed by:- Ayan Kumar Halder
> >
> &
1801 - 1900 of 3914 matches
Mail list logo
