contain objects which
>are actually leasable (connectors, crtcs and planes)
> * Drop the patch which changes permissions on get resources
>ioctls
A bit lacking time to do an in-depth review, but all my major concerns
seem to be addressed. On the series.
Acked-by: Daniel Vetter
T
>waiting_seqno = f1->seqno;
> > -
> > - ),
> > -
> > - TP_printk("driver=%s timeline=%s context=%u seqno=%u " \
> > - "waits on driver=%s timeline=%s context=%u seqno=%u",
> > - __get_str(driver), __get_str(timeline), __entry->context,
>
+414,9 @@ tinydrm_dbg_spi_print(struct spi_device *spi, struct
> spi_transfer *tr,
> void _tinydrm_dbg_spi_message(struct spi_device *spi, struct spi_message *m)
> {
> struct spi_transfer *tmp;
> - struct list_head *pos;
> int i = 0;
>
> - list_for_each(pos, &
able3) / sizeof(hz_init_t));
> + setup_hazard_table(init_table1, table1, ARRAY_SIZE(init_table1));
> + setup_hazard_table(init_table2, table2, ARRAY_SIZE(init_table2));
> + setup_hazard_table(init_table3, table3, ARRAY_SIZE(init_table3));
> }
> --
> 2.14.2
>
>
or->format_supported_num = 0;
> - for (i = 0 ; i < TV_FORMAT_NUM; i++)
> + for (i = 0 ; i < ARRAY_SIZE(tv_format_names); i++)
> if (format_map & (1 << i))
>
> psb_intel_sdvo_connector->tv_format_supported[psb_intel_sdvo_connector->format_supported_num++]
> = i;
>
> --
> 2.14.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
on upstream kernel, it could only be called by dump_create, and the
>> drm_mode_create_dumb_ioctl already did the size check.
>>
>> will resent this patch, and rewrite the commit message, thanx.
>
> That suggests that this patch isn't needed at all.
Yes, not needed for
gt;mode_valid() and crtc->mode_valid() so that we can
> make sure that the mode will be accepted in every components.
>
> Signed-off-by: Jose Abreu
> Reviewed-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> Cc: Carlos Palminha
> Cc: Ville Syrjälä
> Cc: Daniel V
On Thu, May 25, 2017 at 03:19:13PM +0100, Jose Abreu wrote:
> Add a new helper to call crtc->mode_valid, connector->mode_valid
> and encoder->mode_valid callbacks.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jose Abreu
> Reviewed-by: Daniel Vetter
> Re
> > [ 44.003597] Console: switching to colour frame buffer device 128x48
> > [ 54.240707] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
> > [CRTC:58:crtc-3] flip_done timed out
> > [ 64.480706] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
&
On Tue, Oct 31, 2017 at 08:08:14AM -0700, Kees Cook wrote:
> On Tue, Oct 31, 2017 at 3:18 AM, Daniel Vetter wrote:
> > On Mon, Oct 30, 2017 at 03:05:29PM -0700, Kees Cook wrote:
> >> On Mon, Oct 30, 2017 at 3:08 AM, Daniel Vetter wrote:
> >> > On Tue, Oct 24, 2017
t; >
> > I happened to notice that this was in next-20171102, but missing in
> > next-20171103. Did it get removed, or am I misunderstanding something?
>
> I don't know. It's in drm-misc-next, though, so it'll flow upstream
> without my intervention.
I'll
ply the H3/5
> > part of this patchset?
>
> This came a bit late, we're too close from the merge window
> now. Please resend them after -rc1 is out.
Just dropping here that drm-misc is open all the time, making for a much
better process for contributors :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_dev_unref(dev);
> + drm_dev_put(dev);
> }
>
> static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nsigned long)dev_priv;
> - lid_timer->function = psb_lid_timer_func;
> lid_timer->expires = jiffies + PSB_LID_DELAY;
>
> add_timer(lid_timer);
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
>
;
> --
> 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
"magic" stuff going on in the background, which then sometimes doesn't
work and we end up implementing hacks in drivers to paper over it.
Slightly more details: The gpu can also get access to the pmic, through
its own register window, except the synchronization at the hw/fw level is
screwed up and doesn't work, breaking the illusion that the gpu is a
prefectly isolated pci device. In reality, at the SoC level, it's anything
but. But because those deps aren't clearly expressed (people hoped it
would work with the magic, which was all added to make running Windows on
top of this possible), so it all looks like horrible hacks instead of the
much cleaner design arm-soc platforms have with DT describing all these
deps much more explicitly.
Aside: There's a lot more mmio windows of other devices and special
backdoors to other stuff in the gpu "pci" mmio bar than just this. Mostly
they work as designed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Oct 30, 2017 at 03:05:29PM -0700, Kees Cook wrote:
> On Mon, Oct 30, 2017 at 3:08 AM, Daniel Vetter wrote:
> > On Tue, Oct 24, 2017 at 08:16:09AM -0700, Kees Cook wrote:
> >> In preparation for unconditionally passing the struct timer_list pointer to
> >> all
/gpu/drm/drm_modeset_lock.c
> @@ -93,7 +93,7 @@ void drm_modeset_lock_all(struct drm_device *dev)
> struct drm_modeset_acquire_ctx *ctx;
> int ret;
>
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL | __GFP_NOFAIL);
> if (WARN_ON(!ctx))
> return;
>
> Then it will turn up on somebody'ss too-small-to-fail fix list.
lgtm. Can you pls submit this as a patch withs sob and everything?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t;
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the
rly ;-) Hence I'm all for
purging where this leaks out of the drm subsystem.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_lock.c | 41 ---
> include/drm/drmP.h |1 -
> include/linux/sched.h |7 +-
> kernel/signal.c
On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> > 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
> >
On Tue, Oct 13, 2015 at 11:16:48AM +0300, Jani Nikula wrote:
> There's plenty of drm/i915 related hardware and software documentation,
> and firmware downloads for the latest platforms.
>
> Cc: Daniel Vetter
> Signed-off-by: Jani Nikula
Queued for -next, thanks fo
On Tue, Oct 13, 2015 at 09:24:26AM -0700, Dan Williams wrote:
> On Tue, Oct 13, 2015 at 1:24 AM, Daniel Vetter wrote:
> > On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
> >> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> >> > On Fri, Oc
dc 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -264,7 +264,6 @@ static int mdp5_plane_prepare_fb(struct drm_plane *plane,
> }
>
> static void mdp5_plane_cleanup_fb(struct drm_plane *plane,
> - struc
___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe l
/**< Length of unique */
> > + __kernel_size_t unique_len; /**< Length of unique */
> As the file is used by other platforms than Linux this change will
> break them. Can you add a typedef similar to how __u8 and friends are
> handled at the top of the file.
This
__
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe l
__
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe l
goto nomem;
>
> dev->mode_config.tv_saturation_property =
> drm_property_create_range(dev, 0, "saturation", 0, 100);
> + if (!dev->mode_config.tv_saturation_property)
> + goto nomem;
>
> dev->mode_config
On Wed, Oct 21, 2015 at 10:53:31AM +0100, Eric Anholt wrote:
> Dave suggested it was time to just send a pull request on the driver, so
> here goes:
Given I suggested the same:
Acked-by: Daniel Vetter
>
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70
bf8a6afd15551)
Dave already applied it.
-Daniel
>
> Thanks
> Emil
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
5740
>
> Reviewed-by: Emil Velikov
Same deal, already merged.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
> >
&g
tform wanting to use the component
> helper, and they want to call this function? You prevent them doing so
> by moving this into here, because they're then forced down to 32-bit DMA.
> Please, get rid of it, and leave this crappiness in the respective
> drivers.
>
> --
>
On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
>
> > > The warning on boot seems to be gone as of rc3, but I can now trigger
> this pretty easily..
> >
> > http://patchwo
/gpu/drm/armada/armada_drv.c | 68 +++---
> drivers/gpu/drm/drm_of.c| 88
> +
> drivers/gpu/drm/imx/imx-drm-core.c | 55 ++
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 81 ++--
ince it wants struct
drm_rect but atomic states don't give you that.
-Daniel
> +
> if (crtc_x < 0) {
> offset += drm_format_plane_cpp(fb->pixel_format, 0) * -crtc_x;
> crtc_w += crtc_x;
> --
> 2.6.1
>
> _______
ned!
> ERROR: "drm_agp_acquire_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_free_ioctl" [drivers/gpu/drm/drm.ko] undefined!
>
> Not quite sure which commit caused this, but I have used the drm-misc
> tree from next-20150930 for today.
_
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-
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
> > +#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
e use of them.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> ---
>
> Changes v2->v3:
> - Try to document the callbacks
m_{crtc/encoder/connector}_mode_valid()
> drm: Introduce drm_bridge_mode_valid()
> drm: Use new mode_valid() helpers in connector probe helper
> drm: Use mode_valid() in atomic modeset
> drm: arc: Use crtc->mode_valid() callback
>
> Cc: Carlos Palminha
> Cc: Alexey
p;output->connector);
> > - goto err_encoder_cleanup;
> > - }
> > -
> > - output->panel = panel;
> > + bridge = drm_panel_bridge_add(panel,
> > DRM_MODE_CONNECTOR_Unknown);
> > + if (IS_ERR(bridge))
> > + return PTR_ERR(bridge);
>
> It would even be simpler if panels were directly registering
> themselves to the bridge infrastructure so that they can be found with
> drm_of_find_bridge() and we don't have to explicitly create this
> bride->panel wrapper, but I remember that Thierry was not a big fan of
> this idea.
>
> Also, I keep thinking that we're abusing objects. A bridge is supposed
> to convert a pixel stream in a given format/encoding into a different
> format/encoding. Here, there's no conversion taking place in this
> panel_bridge, it's just a way to expose the panel as a generic element
> that can be easily connected to many display controller drivers.
> To be perfectly clear, I really like this idea of providing a generic
> wrapper, I'm just unsure exposing this wrapper as a bridge is such a
> good idea, unless we clarify the meaning/goal of a 'drm_bridge' object.
>
> The more I look at it, the more I think the drm_bridge is turning into a
> generic element that is taking a stream of pixel in a specific format
> and either consuming it of transforming it before forwarding it to the
> next element in the chain.
>
> Regards,
>
> Boris
> ___
> 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
to extend out the HFP so that the refresh rate matches.
>
> Signed-off-by: Eric Anholt
Yeah, this is what mode_fixup is for (or the fancier atomic_check, but no
benefit with using that one here).
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/vc4/vc4_dsi.c | 112
> ++
On Fri, May 12, 2017 at 11:24:12AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 10 May 2017 10:03:37 Daniel Vetter wrote:
> > On Tue, May 09, 2017 at 06:00:08PM +0100, Jose Abreu wrote:
> > > This adds a new callback to crtc, encoder and bridge helpe
> way
> the other validation functions validate a mode against other parameters, but
> it's your patch :-)
Call it drm_connector_validate_mode, because the first argument is
generally the object we operate on :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, May 12, 2017 at 02:01:49PM +0300, Laurent Pinchart wrote:
> Hi Archit,
>
> On Friday 12 May 2017 16:20:07 Archit Taneja wrote:
> > On 05/12/2017 03:08 PM, Laurent Pinchart wrote:
> > > On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote:
> > >> On W
On Fri, May 12, 2017 at 12:53:56PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 10 May 2017 19:55:56 Daniel Vetter wrote:
> > On Wed, May 10, 2017 at 09:38:00PM +0530, Archit Taneja wrote:
> > > On 5/9/2017 10:30 PM, Jose Abreu wrote:
> > > &g
: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
Btw for justifying your patch series a bit more, would be real sweet to
roll ->mode_valid out to more drivers. I see two easy cases:
bri
f at least a valid encoderXbridgeXcrtc combination is found which
> > accepts the mode then the function returns MODE_OK.
> >
> > Signed-off-by: Jose Abreu
> > Cc: Carlos Palminha
> > Cc: Alexey Brodkin
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> &
On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard
wrote:
> On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
>> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
>> > > On T
ioctl = amdgpu_kms_compat_ioctl,
> #endif
> + .oom_file_badness = drm_oom_badness,
Would be neat if we could roll this out for all gem drivers (once it's no
longer an RFC ofc).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
one, depending upon how the
buffers or DRM fd have been shared).
Would it be ok to hang onto potentially arbitrary mmget references
essentially forever? If that's ok I think we can do your process based
account (minus a few minor inaccuracies for shared stuff perhaps, but no
one cares about that).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
also be good to resubmit them so i915 CI can run
the tests (now that the code has landed).
On the patch itself, minus lack of testcases:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_auth.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/
.preferred = 1,
in add_detailed_modes. Please fix that one up too for consistency, then
I'll merge your patch.
Cheers, Daniel
> }
> }
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...
On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
> On 2018-01-30 10:31 AM, Daniel Vetter wrote:
> > On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote:
> >> Am 24.01.2018 um 12:50 schrieb Michal Hocko:
> >>> On Wed 24-01-18 12:23:10, Miche
l, so less important).
> > >
> > > Sean
> > >
> > > >
> > > > Signed-off-by: Gustavo A. R. Silva
> > > > ---
> > > > Changes in v2:
> > > > - Use true for boolean value in add_detailed_mode as suggeste
; the one to fail.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index a9ae6dd2d593..38
On Tue, Jan 30, 2018 at 11:55:01AM -0800, Keith Packard wrote:
> Daniel Vetter writes:
>
> > On Thu, Jan 18, 2018 at 05:51:59PM -0800, Keith Packard wrote:
> >> Don't let a lessee control what the current DRM master is set to;
> >> that's the job of the &q
mit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t *best_clock)
> {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
> int err = target;
>
> memset(best_clock, 0, sizeof(*best_clock));
> --
> 2.9.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 Wed, Jan 17, 2018 at 10:20:24AM +0100, Maxime Ripard wrote:
> On Thu, Jan 11, 2018 at 08:34:58PM +0200, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote:
> > > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Rip
fbdev power states for backlights (those really only can
be either off or on).
Cleanup motivated by Meghana's questions about all this.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Meghana Madhyastha
Signed-off-by: Daniel Vetter
---
include/linux/backlight.h | 3 ---
1 file chang
Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.
Stop that by allocating a tiny driver private data structure instead.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Signed-off-by: Daniel Vetter
---
drivers/video/backlight
erall.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Signed-off-by: Daniel Vetter
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7691e1025708..6534517f53b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2546,6 +2546,7 @@ BACKLIGHT CLASS/SUBS
Now that the 3 drivers using this are cleaned up we can also remove
this final bit of confusion of leaking driver internals into the
backlight power interface.
The backlight power interface itself is still a massive mess.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Signed-off-by: Daniel
Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.
Luckily we have already a drvdata structure, so fixing this is really
easy.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Thomas Petazzoni
Signed-off-by: Daniel Vetter
Nothing in the entire tree ever sets this, which means this is dead
code. Remove it.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Signed-off-by: Daniel Vetter
---
drivers/video/backlight/generic_bl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/video/backlight
On Wed, Jan 17, 2018 at 3:36 PM, Arnd Bergmann wrote:
> On Wed, Jan 17, 2018 at 9:27 AM, Daniel Vetter wrote:
>> On Tue, Jan 16, 2018 at 03:57:10PM +0100, Arnd Bergmann wrote:
>>> The two functions pass a partially initialized structure back to the
>>> caller after a
On Wed, Jan 17, 2018 at 04:44:00PM +, Daniel Thompson wrote:
> On 17/01/18 14:01, Daniel Vetter wrote:
> > Nothing in the entire tree ever sets this, which means this is dead
> > code. Remove it.
> >
> > Cc: Lee Jones
> > Cc: Daniel Thompson
> > Cc
On Wed, Jan 17, 2018 at 8:44 PM, Arnd Bergmann wrote:
> On Wed, Jan 17, 2018 at 3:55 PM, Daniel Vetter wrote:
>> On Wed, Jan 17, 2018 at 3:36 PM, Arnd Bergmann wrote:
>>> On Wed, Jan 17, 2018 at 9:27 AM, Daniel Vetter wrote:
>>>> On Tue, Jan 16, 2018 at 03:57:1
OWN;
>> + bd->props.state |= BL_CORE_FBBLANK;
>> +
>> + return backlight_update_status(bd);
>> +}
>> +
>> extern struct backlight_device *backlight_device_register(const char
>> *name,
>> struct device *dev, void *devdata, const struct backlight_ops
>> *ops,
>> const struct backlight_properties *props);
>>
> ___
> 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
Thanks a lot for your comments.
On Wed, Jan 17, 2018 at 04:47:41PM +, Daniel Thompson wrote:
> On 17/01/18 14:01, Daniel Vetter wrote:
> > Leaking driver internal tracking into the already massively confusing
> > backlight power tracking is really confusing.
> >
> >
ctor, edid != NULL);
>
> --
> 2.15.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
_force_bit(i2c, false);
> + }
>
> intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
>
> --
> 2.15.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
src_y;
> uint32_t src_h, src_w;
>
> + /* Plane opacity */
> + u8 alpha;
> +
> /* Plane rotation */
> unsigned int rotation;
>
> @@ -481,6 +485,7 @@ enum drm_plane_type {
> * @funcs: helper functions
> * @properties: property tracking for this plane
> * @type: type of plane (overlay, primary, cursor)
> + * @alpha_property: alpha property for this plane
> * @zpos_property: zpos property for this plane
> * @rotation_property: rotation property for this plane
> * @helper_private: mid-layer private data
> @@ -546,6 +551,7 @@ struct drm_plane {
>*/
> struct drm_plane_state *state;
>
> + struct drm_property *alpha_property;
> struct drm_property *zpos_property;
> struct drm_property *rotation_property;
> };
> --
> git-series 0.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 Tue, Jan 09, 2018 at 11:56:24AM +0100, Maxime Ripard wrote:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Eric Anholt
> Signed-off-by: Maxime Ripard
On patches 1-5:
Reviewed-by: Daniel Vetter
On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > Some drivers duplicate the logic to create a property to store a per
On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:23 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
> > > Implement k
On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:32 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
> > > Implement GEM
gt; index 09076a625637..9ae53b73c9d2 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
> > * &drm_modeset_lock is required to duplicate and update this object's
> > state.
> > */
> > struct drm_private_obj {
> > + /**
> > +* @lock: Modeset lock to protect the state object.
> > +*/
> > + struct drm_modeset_lock lock;
> > +
> > /**
> > * @state: Current atomic state for this driver private object.
> > */
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_modeset_lock is required to duplicate and update this object's state.
> */
> struct drm_private_obj {
> + /**
> + * @lock: Modeset lock to protect the state object.
> + */
> + struct drm_modeset_lock lock;
> +
> /**
>* @state: Current atomic state for this dri
acking of what is assigned to which plane/crtc is in global
> > state, so it fits nicely in the current locking model. For i915, I'm
> > not quite sure what is the global state you are concerned about, so it
> > is a bit hard to talk about the best solution in the abstract. Maybe
> > the better option is to teach modeset-lock how to be a rwlock instead?
>
> The thing I'm thinking is the core display clock (cdclk) frequency which
> we need to consult whenever computing plane states and whatnot. We don't
> want a modeset on one crtc to block a plane update on another crtc
> unless we actually have to bump the cdclk (which would generally require
> all crtcs to undergo a full modeset). Seems like a generally useful
> pattern to me.
The usual way to fix that is to have read-only copies of the state in the
plane or crtc states. And for writing (or if the requirement changes) you
have to lock all the objects. Essentially what Rob's doing for his
plane/crtc assignment stuff.
What we do in i915 is kinda not what I've been recommending to everyone
else, because it is a rather tricky and complicated way to get things
done. Sure there's a tradeoff between duplicating data and complicated
locking schemes, but I think for the kms case having to explicitly type
code that reflects the depencies in computation (instead of having that
embedded implicitly in the locking scheme) is a feature, not a bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Mar 06, 2018 at 08:29:20AM +0100, Daniel Vetter wrote:
> On Wed, Feb 21, 2018 at 04:19:40PM +0100, Maarten Lankhorst wrote:
> > Hey,
> >
> > Op 21-02-18 om 15:37 schreef Rob Clark:
> > > Follow the same pattern of locking as with other state objects. This
&
On Mon, Mar 05, 2018 at 11:30:35AM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:25 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:42AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
> > > H
return -EINVAL;
> > > > > file_priv->atomic = req->value;
> > > > > file_priv->universal_planes = req->value;
> > > > > break;
> > > > > --
> > > > > 2.16.2
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-de...@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel OTC
> > >
> > > --
> > >
> > > | I would like to |
> > > | fix the world, |
> > > | but they're not |
> > > | giving me the |
> > > \ source code! /
> > > ---
> > > ¯\_(ツ)_/¯
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ector_modes,
> so it will only pick my single hardcoded mode from
> drm_connector_helper_funcs.get_modes
> callback (connector_get_modes).
No, you still need your mode_valid check. Userspace can ignore your mode
list and give you something totally different. But it needs to be moved to
the drm_simple_display_pipe_funcs vtable.
> > You need to use one of the other mode_valid callbacks instead,
> > drm_simple_display_pipe_funcs has the one you should use.
> >
> Not sure I understand why do I need to provide a callback here?
> For simple KMS the drm_simple_kms_crtc_mode_valid callback is used,
> which always returns MODE_OK if there is no .mode_valid set for the pipe.
> As per my understanding drm_simple_kms_crtc_mode_valid is only called for
> modes, which were collected by drm_helper_probe_single_connector_modes,
> so I assume each time .validate_mode is called it can only have my hardcoded
> mode to validate?
Please read the kerneldoc again, userspace can give you modes that are not
coming from drm_helper_probe_single_connector_modes. If the kerneldoc
isn't clear, then please submit a patch to make it clearer.
> > > +
> > > +static int display_check(struct drm_simple_display_pipe *pipe,
> > > + struct drm_plane_state *plane_state,
> > > + struct drm_crtc_state *crtc_state)
> > > +{
> > > + struct xen_drm_front_drm_pipeline *pipeline =
> > > + to_xen_drm_pipeline(pipe);
> > > +
> > > + return pipeline->conn_connected ? 0 : -EINVAL;
> > As mentioned, this -EINVAL here needs to go. Since you already have a
> > mode_valid callback you can (should) drop this one here entirely.
> Not sure how mode_valid is relevant to this code [1]: This function is
> called
> in the check phase of an atomic update, specifically when the underlying
> plane is checked. But, anyways: the reason for this callback and it
> returning
> -EINVAL is primarialy for a dumb user-space which cannot handle hotplug
> events.
Fix your userspace. Again, you can't invent new uapi like this which ends
up being inconsistent with other existing userspace.
> But, as you mentioned before, it will make most compositors die, so I will
> remove this
Yup, sounds good.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
patch.
-Daniel
>
> > > if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> > > break;
> > > }
> > > --
> > > 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
________
> 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, Mar 27, 2018 at 11:34 AM, Oleksandr Andrushchenko
wrote:
> Hi, Daniel!
>
>
> On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote:
>>
>> On 03/26/2018 11:18 AM, Daniel Vetter wrote:
>>>
>>> On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr And
On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
>> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
>> > malidp_pm_suspend_late checks if the runtime status is not suspended
>&
5/367
Reviewed-by: Daniel Vetter
Aside, and kinda why I noticed this patch to begin with: You have drm-misc
commit rights, but you seem to not use that. And with 18 patches in the
4.17 cycle you're the top contributor who's not pushing his own patches.
What's the hold-up? Tools
> 5 files changed, 206 insertions(+), 174 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_hdmi.c
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailma
On Fri, Apr 13, 2018 at 4:46 PM, Thomas Huth wrote:
> On 13.04.2018 16:32, Daniel Vetter wrote:
>> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
>>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>>> all the code that is enabled by
en propose a Xen helper library for sharing big
> > > buffers,
> > > so common code of the above drivers can use the same code w/o code
> > > duplication)
> > I think it is possible to use your functions for memory sharing part in
> > hyper_dmabuf's backend (this 'backend' means the layer that does page
> > sharing
> > and inter-vm communication with xen-specific way.), so why don't we work on
> > "Xen helper library for sharing big buffers" first while we continue our
> > discussion on the common API layer that can cover any dmabuf sharing cases.
> >
> Well, I would love we reuse the code that I have, but I also
> understand that it was limited by my use-cases. So, I do not
> insist we have to ;)
> If we start designing and discussing hyper-dmabuf protocol we of course
> can work on this helper library in parallel.
Imo code reuse is overrated. Adding new uapi is what freaks me out here
:-)
If we end up with duplicated implementations, even in upstream, meh, not
great, but also ok. New uapi, and in a similar way, new hypervisor api
like the dma-buf forwarding that hyperdmabuf does is the kind of thing
that will lock us in for 10+ years (if we make a mistake).
> > > Thank you,
> > > Oleksandr
> > >
> > > P.S. All, is it a good idea to move this out of udmabuf thread into a
> > > dedicated one?
> > Either way is fine with me.
> So, if you can start designing the protocol we may have a dedicated mail
> thread for that. I will try to help with the protocol as much as I can
Please don't start with the protocol. Instead start with the concrete
use-cases, and then figure out why exactly you need new uapi. Once we have
that answered, we can start thinking about fleshing out the details.
Cheers, Daniel
>
> > > > > > cheers,
> > > > > >Gerd
> > > > > >
> > > > > Thank you,
> > > > > Oleksandr
> > > > >
> > > > > P.S. Sorry for making your original mail thread to discuss things much
> > > > > broader than your RFC...
> > > > >
> > > [1] https://github.com/xen-troops/displ_be
> > > [2]
> > > https://elixir.bootlin.com/linux/v4.16-rc7/source/include/xen/interface/io/displif.h#L484
> > > [3]
> > > https://elixir.bootlin.com/linux/v4.16-rc7/source/include/xen/interface/io/sndif.h
> > >
> [1]
> https://elixir.bootlin.com/linux/v4.16-rc7/source/include/xen/interface/io/displif.h
> [2]
> https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg00685.html
> ___
> 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 Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
> Hi Daniel,
>
> On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wr
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
---
drivers/input/mouse/psmouse-base.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/psm
On Tue, Mar 20, 2018 at 01:58:01PM +0200, Oleksandr Andrushchenko wrote:
> On 03/19/2018 05:28 PM, Daniel Vetter wrote:
> > There should be no difference between immediate removal and delayed
> > removal of the drm_device from the xenbus pov. The lifetimes of the
> > front
because depot_save_stack can call free_pages (to drop it's
preallocation), which can call debug_check_no_obj_freed, which will
recurse into the db->lock spinlocks.
Cc: Philippe Ombredanne
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Kate Stewart
Cc: Daniel Vetter
Cc: Waiman Long
501 - 600 of 3914 matches
Mail list logo
