r, 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.
>
> --
> FTTC broadband for 0.8mile line: currently at 9.
> ___
> 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
> ___
> 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
t drm_unique {
> > - size_t unique_len;/**< 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
> ___
> 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 &quo
On Tue, Oct 13, 2015 at 09:24:26AM -0700, Dan Williams wrote:
> On Tue, Oct 13, 2015 at 1:24 AM, Daniel Vetter <dan...@ffwll.ch> 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:
>
space knows something bad happened (should trigger collection
> --
> 2.4.3
>
> ___
> 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 unsubsc
> reverse of the execution path.
>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Signed-off-by: Sudip Mukherjee <su...@vectorindia.org>
Queued for -next, thanks for the patch.
-Daniel
> ---
>
> Sent on 27
On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote:
> We were not checking the return value of drm_encoder_init() which can
> fail. And if it fails then we will be working with an uninitialized
> encoder.
>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> C
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
/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 ++--------
>
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 <daniel.vet...@ffwll.ch>
>
> The following ch
dev->mode_config.tv_hue_property =
> drm_property_create_range(dev, 0, "hue", 0, 100);
> + if (!dev->mode_config.tv_hue_property)
> + goto nomem;
>
> return 0;
> +nomem:
> + return -ENOMEM;
> }
> EXPORT_SYMBOL(drm_
_handler [i915]] *ERROR* The master control
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control
> interrupt lied (SDE)!
> [ 4057.59268
On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> 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 <daniel.vet...@ffwll.ch>
> Signed-off-by: Jani Nikula <jani.n
in V3:
- Test driver on Vybrid board and add compatible string
- Remove unused functions
- set default crtc for encoder
- replace legacy functions with atomic help functions
Adviced by Daniel Vetter
- Set the unique name of the DRM device
- Implement irq handle function for vblank interrupt
djku...@chromium.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: sta...@vger.kernel.org
Applied to topic/drm-fixes to make sure it won't get lost, but I expect
rockchip maintainers to pick this one up.
-Daniel
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67
On Wed, Jul 08, 2015 at 08:40:17AM +0200, Michal Hocko wrote:
I have just tried to boot 4.2-rc1 and cannot seem to reproduce the issue
anymore.
On Tue 07-07-15 10:43:58, Daniel Vetter wrote:
[...]
Can you please
boot with drm.debug=0xf (lots more nois in dmesg with this) and reproduce
On Fri, Jul 10, 2015 at 10:43:11AM +, Wang J.W. wrote:
Hi Daniel,
Thank you very much for your review!
See below...
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Friday, July 10, 2015 4:00 PM
To: Wang Jianwei
that we've recently started cleaning up, looks good. No
detailed review though (for one I lack hw docs).
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Might be good to get some cross-review from some other arm soc drm driver
team, then send a pull request to Dave for 4.3.
Cheers, Daniel
--
Daniel
proper reference for cursor_set"
>
> which calls drm_gem_object_lookup(dev, file_priv...). Previously this wasn't
> a problem because we checked the handle. Move the check early in the function
> can fix the problem.
>
> Signed-off-by: Rui Wang <rui.y.w...@intel.com>
ke the casting Maarten's current hack does, we
probably need a per-encoder ->sanitize hook for this stuff. Better to
retry for 4.5. Can you pls push the revert?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from t
On Tue, Nov 17, 2015 at 06:47:28PM +, John Keeping wrote:
> On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
>
> > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <dan...@ffwll.ch>
> &g
, I simply made the checking more anal in
commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter <daniel.vet...@ffwll.ch>
Date: Thu Oct 15 09:36:25 2015 +0200
drm/gem: Check locking in drm_gem_object_unreference
With the above added this is:
Reviewed-by: Daniel Vetter &l
the typical component code.
Drop no-op hooks for atomic_begin and mode_fixup() now that
they're optional. Drop sentinel in Makefile. Fix minor style
nits I noticed on another reread.
fwiw Acked-by: Daniel Vetter daniel.vet...@ffwll.ch since Eric has done
all the changes I requested
eventually see a dt-enabled
component functions to standardize this even more the overall concept is
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux
On Tue, Aug 25, 2015 at 9:11 PM, Rob Clark robdcl...@gmail.com wrote:
On Tue, Aug 25, 2015 at 3:05 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 19, 2015 at 03:00:04PM -0400, Rob Clark wrote:
On Tue, Apr 7, 2015 at 2:09 PM, Jilai Wang jil...@codeaurora.org wrote:
So one thing that I
...@infradead.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Jonathan Corbet cor...@lwn.net
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Stephan Mueller smuel...@chronox.de
Cc: Michal Marek mma...@suse.cz
Cc: linux-kernel@vger.kernel.org
Cc
://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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
d properly ;-) Hence I'm all for
purging where this leaks out of the drm subsystem.
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/gpu/drm/drm_lock.c | 41 ---
> include/drm/drmP.h |1 -
>
ivers/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,
> - struct drm_framebuffer *fb,
>
. Wrt
session handling that's something which would need to be fixed between
v4l and logind (or whatever).
In general I don't like hand-rolling our own proprietary v4l-open process,
it means that all the existing v4l testdev tooling must be changed, even
when you're root.
-Daniel
--
Daniel Vetter
...@infradead.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Jonathan Corbet cor...@lwn.net
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Stephan Mueller smuel...@chronox.de
Cc: Michal Marek mma...@suse.cz
Cc: linux-kernel@vger.kernel.org
Cc
On Thu, Sep 10, 2015 at 04:07:16PM +0800, Xinliang Liu wrote:
> On 25 August 2015 at 17:36, Daniel Vetter <dan...@ffwll.ch> wrote:
> Hi Daniel,
> Thank you very much for reply. Sorry, I just come back from vacation.
> Very happy that you have a good idea to solve the mess.
> L
orward with the kerneldoc toolchain we have makes sense. Hence I'd
like to see those patches landed before we resolve #1 if possible.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
r might not be ready to accept the commands right away
> (maybe it needs to
> --
> 2.6.0.rc0.24.gec371ff
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel V
On Sun, Sep 13, 2015 at 9:13 PM, Jonathan Corbet <cor...@lwn.net> wrote:
> On Sun, 13 Sep 2015 12:36:07 +0200
> Daniel Vetter <dan...@ffwll.ch> wrote:
>
>> Personally I don't care which kind of text markup we pick and wich
>> converter, as long as the proje
er
> *m);
> +int drm_platform_register_drivers(struct platform_driver *const *drv,
> + int count);
> +void drm_platform_unregister_drivers(struct platform_driver *const *drv,
> +int count);
>
> /*
than the old thing and it's also what you want long-term.
I've also just done a presenation about atomic for drivers:
http://people.freedesktop.org/~danvet/presentations/xdc-2015.pdf
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe fr
start > b->stolen->start)
> > + return 1;
> > + return 0;
> > }
> >
> > static int i915_gem_stolen_list_info(struct seq_file *m, void *data)
> > --
> > 2.1.3
> >
>
> --
> Jani Nikula, Intel Open Source Technology Center
unsigned flags, unsigned color,
> struct drm_clip_rect *clips, unsigned num_clips);
> };
>
> struct tinydrm_panel {
> struct drm_panel panel;
> u32 width;
> u32 height;
> void *dev_private;
>
&g
eginners (when using one
of the latest drivers as a template for what needs to be done).
-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.kern
ev_put(dev_priv->bridge_dev);
> kfree(dev_priv);
>
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corpo
:56AM +, Lankhorst, Maarten wrote:
> > > > Hey,
> > > >
> > > > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
> > > > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
> > > > > > On Tue, Sep 22
> 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.
Bui
find(pdev) != NULL) {
> > --
> > 2.1.3
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open
should
take care of pretty much all the boilerplate for you. They have ready-made
simple gem and dumb framebuffer mmap support, which is all a basic kms
driver needs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: sen
unsigned int count);
> +void platform_unregister_drivers(struct platform_driver * const *drivers,
> +unsigned int count);
> +
> /* early platform driver interface */
> struct early_platform_driver {
> con
On Wed, Sep 23, 2015 at 10:59:51AM +0200, Borislav Petkov wrote:
> On Wed, Sep 23, 2015 at 09:25:23AM +0200, Daniel Vetter wrote:
> > Strange thing is that I've tested this on a radeon over here and I don't
> > see this backtrace ... wut. Below diff should appease the backtrac
on implementing support for
drm_simple_outputs which would collapse the crtc->encoder->connector
chain into 1 entity. Would be trivial to implement and then trivial to
write simple drivers on top of that. And besides that drm already has
piles of reallly simple drivers with just one output and one
en consider drm
"because I don't have a desktop gpu" which is just silly - drm has become
rather flexible. And that's essentially why writing simple drm drivers
still has a bit too much boilerplate, since no one yet bothered to add a
bit of helper support needed.
Thanks, Daniel
--
Daniel Vet
ailing 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 linux-kernel" in
the body of a messag
abuse, e.g. we already use -ENOENT to signal any kind of lookup failure in
ioctls (even if the fd itself is obviously there so not possible that the
fd isn't there).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send
appease the backtraces at
least.
-Daniel
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index d8319dae8358..9f05de73ae97 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1734,9 +1734,11 @@ int rade
5fce5c152ff4528 ]---
> >>
> >> Some intelgfx hardware infos (see attached Xorg.0.log)...
> >>
> >> [27.487] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
> >> Graphics 3000
> >> [27.565] (II) intel(0): SNA initialized with Sandybr
7666342=1=2
> [1] http://marc.info/?l=linux-kernel=144227950327112=2
--
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 majord
On Thu, Sep 24, 2015 at 07:12:27PM +0200, Ondrej Zary wrote:
> On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
> > On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> > > On 2015-09-24 08:46, Thomas Petazzoni wrote:
> > > >Hello,
> &g
ing fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-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
On Thu, Sep 17, 2015 at 05:51:28PM +0800, Xinliang Liu wrote:
> On 17 September 2015 at 04:16, Daniel Vetter <dan...@ffwll.ch> wrote:
>
> > On Wed, Sep 16, 2015 at 04:23:35PM +0100, Daniel Stone wrote:
> > > The biggest issue though, is that this driver should become
* @driver_private: pointer to the bridge driver's internal context
> */
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
gt; > scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
> >
> > [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
> >
> > Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>
> Reviewed-by: Jani Nikula <jani.nik...@intel.com>
Queued for -next, thanks for the
> +}
> +
> +void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
> +{
> + WARN_ONCE(1, "not implemented");
> +}
> +
> +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> +struct vm_area_struct *area)
> +{
> + WARN_
s_one_work+0x1fd/0x670
> > > [] ? process_one_work+0x16c/0x670
> > > [] worker_thread+0x4e/0x450
> > > [] ? process_one_work+0x670/0x670
> > > [] kthread+0x101/0x120
> > > [] ? kthread_create_on_node+0x250/0x250
> > > [] ret_from_fork+0x3f/0x70
> > &g
On Wed, Sep 23, 2015 at 11:18 AM, Ander Conselvan De Oliveira
<conselv...@gmail.com> wrote:
> On Wed, 2015-09-23 at 10:24 +0200, Daniel Vetter wrote:
>> On Tue, Sep 15, 2015 at 04:08:53PM +0300, Ander Conselvan De Oliveira wrote:
>> > On Mon, 2015-09-14 at 16:38 +0300, And
coding
> git bisect skip fe36f55d4d4447679923fc74564786ae423ca4bd
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporat
ntext_idr, per_file_ctx,
> > (void *)(unsigned long)m);
> > }
> > --
> > 1.9.1
> >
> >
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-de...@
kselftest
> > - clean up and ABI check for security issues
> > - move the sync framework to drivers/base/dma-buf
> >
> > Cc: Arve Hjønnevåg <a...@android.com>
> > Cc: Riley Andrews <riandr...@android.com>
> > Cc: Daniel Vetter <daniel.vet...@ffwll.c
> +{
> + return readl(hdlcd->mmio + reg);
> +}
> +
> +int hdlcd_setup_crtc(struct drm_device *dev);
> +void hdlcd_set_scanout(struct hdlcd_drm_private *hdlcd);
> +void hdlcd_crtc_suspend(struct drm_crtc *crtc);
> +void hdlcd_crtc_resume(struct drm_crtc *crtc);
> +
> +#
On Wed, Dec 02, 2015 at 04:24:19PM +0100, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 12:23:00PM +, Liviu Dudau wrote:
> > The HDLCD controller is a display controller that supports resolutions
> > up to 4096x4096 pixels. It is present on various development boards
> >
elpers without passing in a driver callback for the allocate
> step.
>
> Signed-off-by: Eric Anholt <e...@anholt.net>
Yeah there's no other way to make this happen without ridiculous amounts
of boilerplate.
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> --
times, at least with atomic helpers).
Like Thierry said the recommendation is to just shovel that code into
->enable hooks. ->mode_set_nofb is mostly there to support easier
transition for drivers which started with the legacy crtc helpers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel C
ith that, atm rule for igt is to send to
intel-gfx and push after 24h of no complaints. For purely vc4-specific
stuff we should probably create a vc4 subdir.
Wrt tests failing: I sometimes run the entire suite here on a radeon, and
at least in the past that resulted in a perfect 100% skip score. So s
m);
> > if (ret)
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 0b921ae06cd8..995fb96cb740 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1049,6 +1049,7 @@ void drm_dev_ref(struct drm_device *dev);
> >
On Sun, Dec 06, 2015 at 11:16:32AM +0100, Nicolas Iooss wrote:
> On 12/06/2015 10:35 AM, Daniel Vetter wrote:
> >> On 11/18/2015 06:58 PM, Nicolas Iooss wrote:
> >>> drm_dev_set_unique() formats its parameter using kvasprintf() but many
> >>> of its callers d
2.5.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
--
To unsubscribe from this list: se
On Mon, Dec 07, 2015 at 11:53:01AM +0200, Jani Nikula wrote:
> On Mon, 07 Dec 2015, Daniel Vetter <dan...@ffwll.ch> wrote:
> > On Sun, Dec 06, 2015 at 11:16:32AM +0100, Nicolas Iooss wrote:
> >> On 12/06/2015 10:35 AM, Daniel Vetter wrote:
> >> >> On 1
.c
> index 6f1a0a6..31e181d 100644
> --- a/drivers/gpu/drm/i915/dvo_tfp410.c
> +++ b/drivers/gpu/drm/i915/dvo_tfp410.c
> @@ -306,7 +306,7 @@ static void tfp410_destroy(struct intel_dvo_device *dvo)
> }
> }
>
> -struct intel_dvo_dev_ops tfp410_ops = {
>
On Wed, Dec 09, 2015 at 05:09:12PM +0530, Sudip Mukherjee wrote:
> On Thu, Oct 08, 2015 at 04:29:31PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote:
> > > We were not checking the return value of drm_encoder_init() wh
htly which involved skipping the hot_plug hook for now
> and letting the live_status check happen in detect until the hpd handling
> part is finalized (Daniel)
>
> Signed-off-by: Shashank Sharma <shashank.sha...@intel.com>
> Signed-off-by: Sonika Jindal <sonik
anks, Daniel
>
> >> Fixes: 52157a4ca396 ("drm: modes: replace simple_strtoul by kstrtouint")
> >
> > For me the commit id is cc344980c76748e57c9c03100c2a14d36ab00334.
>
> Oups, I took commit id from my local git.
>
> Regards
>
> _____
yres_specified = true;
> was_digit = false;
> } else
> @@ -1496,4 +1490,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
>
> out:
> return ret;
> -}
> +}
> \ No newline at end of file
> --
> 2.
ver_name)(struct fence *fence);
> const char * (*get_timeline_name)(struct fence *fence);
> bool (*enable_signaling)(struct fence *fence);
> + void (*disable_signaling)(struct fence *fence);
> bool (*signaled)(struct fence *fence);
> signed long (*wait
e_object, so this should be a no-op for them.
>
> Signed-off-by: Eric Anholt <e...@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Since vc4 landed already I'll pull this into drm-misc.
-Daniel
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 6 +++---
> d
- hdmi->connector.encoder = encoder;
>
> yep that fixes the warning. From the thread you mention, it looks like that
> assignment should also be removed in the non-atomic case (i.MX)?
>
> Or if it is really necessary there could also wrap it in a conditional to
>
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -168,8 +168,6 @@ static int vc4_drm_bind(struct device *dev)
> vc4->dev = drm;
> drm->dev_private = vc4;
>
> - drm_dev_set_unique(drm, dev_name(dev));
> -
> drm_mode_config_init(drm);
>
On Tue, Dec 15, 2015 at 11:08:01AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 11:00 AM, Gustavo Padovan <gust...@padovan.org> wrote:
> > 2015-12-15 Daniel Vetter <dan...@ffwll.ch>:
> >
> >> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokh
reproduce it
> > on upstream kernel as well?
>
> Unfortunately this board does not run upsrteam just yet, but looking
> at the sync driver and fence code we are pretty much in sync with
> upstream.
Just to check: Is that with a proper hw driver, or using SW_SYNC? The
later wi
> >> and
> >> * a variable list of arguments. Drivers can use this at driver probe
> >> time if
> > You might want to also update the above hunk :-)
>
> Indeed, thanks! I will wait a little bit for other feedbacks, read all
> the comments/documentation
On Mon, Dec 14, 2015 at 07:14:09AM +0100, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2015-12-10, Daniel Vetter wrote:
> > On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote:
> > > On 2015-11-09, Dave Airlie wrote:
> [...]
> > > This p
nt() only reprobes connectors for which hpd is enabled, which
are not all of them. We broke this in
commit 816da85a0990c2b52cfffa77637d1c770d6790e9
Author: Daniel Vetter <daniel.vet...@ffwll.ch>
Date: Tue Oct 23 18:23:33 2012 +
drm: handle HPD and polled connectors separately
whic
way, does DRM improves 2D acceleration support over fbdev?
>
> I don't know enough about 2D acceleration to answer that.
We've tried in-kernel accel of 2d fbdev ops in i915 and realized it's too
much work and pretty pointless. But it's definitely possible to do that,
on top of the provided fbdev em
;
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> mutex_lock(_mutex);
> --
> 2.5.0
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-d
.add_connector = intel_dp_add_mst_connector,
> .register_connector = intel_dp_register_mst_connector,
> .destroy_connector = intel_dp_destroy_mst_connector,
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listin
On Tue, Jan 05, 2016 at 09:05:49PM +0100, Daniel Vetter wrote:
> On Tue, Jan 05, 2016 at 02:53:08PM -0500, Lyude wrote:
> > There's no reason to check for an active encoder when setting up hpd,
> > especially since a disconnected connector isn't going to have an encoder
> &g
(!connector->polled && I915_HAS_HOTPLUG(dev) &&
intel_connector->encoder->hpd_pin > HPD_NONE)
connector->polled = DRM_CONNECTOR_POLL_HPD;
}
That yields even tidier code and gives us a place for a comment. Can you
pls respi
x460
> [Tue Jan 5 15:15:44 2016] ---[ end trace 074b4bd8168aac27 ]---
>
>In attachment all the hardware details. Also you can find compiled kernel
> here:
>http://mail.gelma.net/i915
>
> Thanks a lot for your work,
> Andrea
> __
intel_connector->encoder->hpd_pin > HPD_NONE)
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> }
>
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.o
plain in his MST commit why he's done this.
Dave? I can't come up with a reason, but better to test that. Lyude?
Anyway looks good to me.
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>
> drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
> 1 file changed, 1 insertion(+),
1001 - 1100 of 6575 matches
Mail list logo
