this
in the helpers ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
;
if (!pdata) {
--
1.8.2.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
that drivers need to control
when certain callbacks are called is shared by everyone here afaics.
And I also don't see any issues with Rob's proposal in this regard.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from
found on SoCs which all do non-standard stuff and where we
actually have an established or anticipated need for sharing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung
On Tue, Dec 17, 2013 at 09:12:42AM -0600, Daniel Drake wrote:
On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter dan...@ffwll.ch wrote:
Have a bit of logic in the exynos -detect function to re-try a 2nd
round of edid probing after each hdp interrupt if the first one
returns an -ENXIO. Only
On Wed, Dec 18, 2013 at 10:28:37AM -0600, Daniel Drake wrote:
On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter dan...@ffwll.ch wrote:
I think we can do it simpler. When you get a hpd interrupt you eventually
call drm_helper_hpd_irq_event which will update all the state and poke
connectors
them is to atomically commit them, then the
only thing we need is the atomic ioctl, which can shovel entire groups of
properties over the wire at once.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send
On Mon, Mar 10, 2014 at 09:50:14AM +0530, Rahul Sharma wrote:
On 8 March 2014 06:16, Matt Roper matthew.d.ro...@intel.com wrote:
On Fri, Mar 07, 2014 at 03:50:54PM +0530, Rahul Sharma wrote:
Hi Daniel,
On 7 March 2014 14:06, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Mar 06, 2014
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list
On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Signed-off-by: Thierry Reding tred...@nvidia.com
Reviewed-by: Daniel Vetter
properly.
Signed-off-by: Thierry Reding tred...@nvidia.com
Some bikeshed on the kerneldoc below, with that addressed this is
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 4 ++-
drivers/gpu
a drm_panel with
sufficient isolation between all components.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
yourself for async flips if you want the buffer to
survive a bit. crtc_mode_set has not need for this. I expect that the
refcounting bug is somewhere else, at least from my experience chasing
such issues in i915 ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
On Fri, Sep 12, 2014 at 11:27:41AM +0200, Andrzej Hajda wrote:
On 09/12/2014 10:57 AM, Daniel Vetter wrote:
On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
Hi Andrzej,
On 2014년 09월 09일 22:16, Andrzej Hajda wrote:
Adding reference to framebuffer should be accompanied
;
+
exynos_drm_crtc_plane_mode_set(crtc, overlay);
return 0;
--
1.9.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
this not, but it will not magically fix the refcounting bugs itself.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
interface and relevant codes specific to Exynos
drm.
Inki Dae (2):
drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
drm/exynos: use drm generic mmap interface
Thanks for doing this. Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
-Daniel
drivers/gpu/drm/exynos/exynos_drm_drv.c | 28
the drm
core will take care of your refcounting needs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
plane pointerreference has already been cleared in step
2.
And even if their would be a bug in here, you _certainly_ should not
try to paper over this in your driver, but instead fix up the
refcounting done in the drm core.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
);
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);
--
1.9.1
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord
, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda a.ha...@samsung.com wrote:
On 10/03/2014 10:31 AM, Daniel Vetter wrote:
On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote:
The main intent of this patchset is to allow use of suspend/resume drm
driver
callbacks in KMS drivers
drm_vblank_get() after drm_vblank_off()
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Yeah, you should always call vblank_on again when you (re)enable a crtc,
whether this is through a set_config call or through dpms. This is
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Sorry that we didn't catch
);
--
1.7.9.5
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
all the various struct device_node in drm_foo.h.
Should be all fairly simple to pull off with cocci.
Thierry?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul seanp...@chromium.org wrote:
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge
On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar ajayn...@gmail.com wrote:
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul seanp...@chromium.org wrote:
On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter dan...@ffwll.ch wrote:
So don't ask why but I
On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar ajayn...@gmail.com wrote:
On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar ajayn...@gmail.com wrote:
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM
On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul seanp...@chromium.org wrote:
@@ -660,8 +662,11
On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul seanp...@chromium.org wrote:
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge
On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote:
On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote:
On Tue, Oct 28, 2014
On Wed, Oct 29, 2014 at 10:14:37AM +0100, Thierry Reding wrote:
On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
That makes the entire thing a bit non-trivial, which is why I think it
would be better as some generic helper. Which then gets embedded or
instantiated for specific
On Thu, Oct 30, 2014 at 10:09:28AM +, Russell King - ARM Linux wrote:
On Thu, Oct 30, 2014 at 11:01:02AM +0100, Andrzej Hajda wrote:
On 10/29/2014 10:14 AM, Thierry Reding wrote:
On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
I think we nee try_get_module for the code
On Wed, Oct 29, 2014 at 10:16:49AM +0100, Thierry Reding wrote:
On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
On Mon, Oct 27, 2014 at 8:58 PM
On Wed, Oct 29, 2014 at 10:09:04AM +0100, Andrzej Hajda wrote:
On 10/29/2014 08:58 AM, Daniel Vetter wrote:
On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote:
On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote:
On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding
On Mon, Nov 03, 2014 at 09:06:04AM +0100, Thierry Reding wrote:
On Fri, Oct 31, 2014 at 04:59:40PM +0100, Daniel Vetter wrote:
On Wed, Oct 29, 2014 at 10:16:49AM +0100, Thierry Reding wrote:
On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
On Tue, Oct 28, 2014 at 03:29:47PM
;
- ret = drm_vblank_get(dev, crtc);
- if (WARN(ret, vblank not available on crtc %i, ret=%i\n, crtc, ret))
+ if (WARN_ON(pipe = dev-num_crtcs))
This addition should be in the previous patch. I didn't spot anything else
but it's a bit a tedious patch. But makes sense.
-Daniel
--
Daniel
On Tue, Dec 16, 2014 at 05:53:34PM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
These legacy functions all operate on the struct drm_device * and an
index to the CRTC that they should access. This is bad because it
requires keeping track of a global data structures to
On Tue, Dec 16, 2014 at 06:59:28PM +0100, Daniel Vetter wrote:
On Tue, Dec 16, 2014 at 05:53:34PM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
These legacy functions all operate on the struct drm_device * and an
index to the CRTC that they should access
...@nvidia.com
With the comment in patch 9 addressed patches 1-11 are
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_irq.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b34900a8e172
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send
and still resulting in the
lowest possible latency (since the kernel we just commit the flips for
which all the buffers are ready and not stall).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line
thing gone we can indeed rip
out exynos_plane_dpms and exynos_plane-enabled and just directly call
manager-ops-win_enable/disble. And then rip out the win_enable since
it's unused.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
);
ret = PTR_ERR(ctx-crtc);
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
to keep this little bit
of temporary fixup code around.
I've had the same in my exynos branch, we have the same now in i915 (well
it looks a bit different since we dont use all the helpers but roll some
things ourselves).
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Thanks
r-b but good enough for an
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Aside: If you think something doesn't need to be done please explain what
you mean or at least ask about what you don't understand in a patch. As-is
your review is pretty much unactionable.
Cheers, Daniel
Thanks
reading exynos code and these
patches here before we can implement atomic.
Personally I'd have delayered even more aggressively before going into the
atomic stuff. But in the end I guess Padovan wants to be able to ship
exynos atomic preferrably sooner than later.
Cheers, Daniel
--
Daniel Vetter
On Thu, Feb 05, 2015 at 12:48:07PM +, Daniel Stone wrote:
Hi,
On 5 February 2015 at 12:26, Rob Clark robdcl...@gmail.com wrote:
On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter dan...@ffwll.ch wrote:
Yeah I noticed the zpos fun when hacking around too. Exynos should
probably switch
On Thu, Feb 05, 2015 at 10:05:43AM +0900, Joonyoung Shim wrote:
Hi Daniel,
On 02/04/2015 11:16 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:42:57PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado
On Thu, Feb 05, 2015 at 11:37:13AM +0900, Joonyoung Shim wrote:
Hi Daniel,
On 02/04/2015 11:28 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado
to
be moved out of the if block again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Thu, Feb 05, 2015 at 11:48:18AM +0900, Joonyoung Shim wrote:
Hi Daniel,
On 02/04/2015 11:30 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:49:25PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado
.
And similar to piglit I think it makes more sense to have that outside of
any userspace components we ship to users, i.e. not in libdrm.
But I really can't justify doing this work to my dear employer ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
;
const struct exynos_drm_crtc_ops*ops;
--
2.1.0
___
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
://vger.kernel.org/majordomo-info.html
___
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
at updating.
Really if that's all you have to comment and no substantial technical
concerns or questions then just can such a bikeshed mail.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung
not locked up, you simply won't see any dmesg output after that.
Use Archit's Kconfig support in drm-misc to disable fbdev emulation
and try again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line
);
}
if (drm_core_check_feature(dev, DRIVER_RENDER)) {
--
2.1.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
On Tue, Nov 17, 2015 at 03:19:35PM +0100, Andrzej Hajda wrote:
> Hi Daniel,
>
> On 11/17/2015 11:06 AM, Daniel Vetter wrote:
> > On Thu, Nov 12, 2015 at 02:49:29PM +0100, Thierry Reding wrote:
> >> On Thu, Nov 12, 2015 at 11:11:20AM -0200, Gustavo Padovan wrote:
>
this is a bug in exynos atomic_check code. Drivers _must_ check state
irrespective of state->active - if they forgoe any checking when active =
false then legacy DPMS On might spuriuosly fail, which will upset
userspace. There shouldn't be any exceptions to this rule.
Cheers, Daniel
--
Daniel Ve
= exynos_drm_lastclose,
--
2.1.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> > +#define DEFAULT_WIN0
> > +#define CURSOR_WIN 1
>
> You fixed overlay number for cursor with 1. However, Display controllers
> of Exynos SoC have fixed overlay priority like this,
>
> win 4 > win 3 > win 2 > win 1 > win 0 so if we fix the overlay number
> for cursor and we use another overlay - which has a higher layer than
> cursor - to display caption or UI then the we couldn't see the cursor on
> screen without additional work such as color key or alpha channel.
>
> So before that, you need to check how many overlays can be used
> according to Exynos SoC versions, and which way is better - one is for
> top layer to be fixed for cursor, other is for one given layer to be
> fixed by user-space for cursor.
I think cursor should by default be the top layer (if the hw can do it).
Otherwise it will be really confusing to compositors I fear.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ int exynos_plane_init(struct drm_device *dev,
> exynos_plane->index = index;
> exynos_plane->config = config;
>
> - if (config->type == DRM_PLANE_TYPE_OVERLAY)
> - exynos_plane_attach_zpos_property(_plane->base,
> -
On Wed, Dec 16, 2015 at 02:54:04PM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-12-16 14:28, Daniel Vetter wrote:
> >On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
> >>This patch adds all infrastructure to make zpos plane property
> &g
_space (see
> > drm_atomic.c:destroy_vblank_event), as well as calling
>
> Reasonable to me. Seems other DRM drivers don't increment event_space.
>
> > event->base.destroy (see drm_fops.c:drm_read) underneath event_lock,
> > yes.
>
> In addition, only event objects
65 matches
Mail list logo
