.fb_pan_display = intel_fbdev_pan_display,
> > - .fb_blank = intel_fbdev_blank,
> > + .fb_dirty = intel_fbdev_dirty,
> > + .fb_pan_display = drm_fb_helper_pan_display,
> > + .fb_blank = drm_fb_helper_blank,
> > .fb_setcmap = drm_fb_helper_setcmap,
> > .fb_debug_enter = drm_fb_helper_debug_enter,
> > .fb_debug_leave = drm_fb_helper_debug_leave,
> > --
> > 2.1.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/c9b2ec23/attachment-0001.html>
its &= ~frontbuffer_bits;
> > @@ -233,6 +250,7 @@ void intel_frontbuffer_flip(struct drm_device *dev,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >
> > mutex_lock(&dev_priv->fb_tracking.lock);
> > + dev_priv->fb_tracking.fb_dirty = false;
> > /* Remove stale busy bits due to the old buffer. */
> > dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;
> > mutex_unlock(&dev_priv->fb_tracking.lock);
> > --
> > 2.1.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/efc0c16d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=64891
Tommaso Falchi Delitala changed:
What|Removed |Added
CC||volalto86 at gmail.com
--- Comm
>crtc->dev);
> }
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Michal Hocko
SUSE Labs
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/gzip
Size: 25781 bytes
Desc:
On Fri, Jun 26, 2015 at 12:08:57PM -0300, Danilo Cesar Lemes de Paula wrote:
> Functions, Structs and Parameters definitions on kernel documentation
> are pure cosmetic, it only highlights the element.
>
> To ease the navigation in the documentation we should use inside
> those tags so readers ca
On Tue, Jun 30, 2015 at 06:07:44PM +0200, Michal Hocko wrote:
> On Tue 30-06-15 16:32:49, Daniel Vetter wrote:
> [...]
> > Looks like the vblank is actually running, just the wakeup somehow doesn't
> > happen in time. What machine is this (lspci -nn)?
>
> 00:00.0 Host bridge [0600]: Intel Corporat
On 26.06.2015 19:31, Christian König wrote:
> From: Christian König
>
> We only should do so when the BO_VA was actually mapped.
> Otherwise we get a nice error message on the next CS.
>
> v2: It actually doesn't matter if it was invalidated or not,
> if it was mapped we need to clear the
On Tue, 30 Jun 2015, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote:
>> On Tue, 30 Jun 2015, Ander Conselvan de Oliveira
>> wrote:
>> > Similarly to what is done for SKL, clear the dpll_hw_state of the pipe
>> > config in hsw_dp_set_ddi_pll_sel(), since it mai
ip
Size: 28850 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/df50cfa1/attachment-0001.bin>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/f0f4f95c/attachment-0001.html>
On Tue, 30 Jun 2015, Ander Conselvan de Oliveira wrote:
> Similarly to what is done for SKL, clear the dpll_hw_state of the pipe
> config in hsw_dp_set_ddi_pll_sel(), since it main contain stale values.
> That can happen if a crtc that was previously driving an HDMI connector
> switches to a DP co
On Tue, Jun 30, 2015 at 01:57:07PM +0200, Michal Hocko wrote:
> Hi,
> I am getting the following warning when I switch to the text console
> from X. I do not know when this has started because I have noticed
> that only now (in 4.1 kernel). I can try some older kernels if this is
> useful.
>
> I h
On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote:
> On Tue, 30 Jun 2015, Ander Conselvan de Oliveira at intel.com> wrote:
> > Similarly to what is done for SKL, clear the dpll_hw_state of the pipe
> > config in hsw_dp_set_ddi_pll_sel(), since it main contain stale values.
> > That can h
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/f69e2e4f/attachment.html>
Hi Jyri,
Thank you for the patch.
On Tuesday 30 June 2015 13:30:55 Jyri Sarha wrote:
> There is nothing special about tilcdc HW when the video memory is
> concerned. Just using the standard drm helpers for implementation is
> enough.
>
> Signed-off-by: Jyri Sarha
This looks simple, I like it :
Similarly to what is done for SKL, clear the dpll_hw_state of the pipe
config in hsw_dp_set_ddi_pll_sel(), since it main contain stale values.
That can happen if a crtc that was previously driving an HDMI connector
switches to a DP connector. In that case, the wrpll field was left with
its old valu
On Mon, 29 Jun 2015, Daniel Vetter wrote:
> On Mon, Jun 29, 2015 at 05:50:09PM +0300, Jani Nikula wrote:
>> On Mon, 29 Jun 2015, Ander Conselvan De Oliveira
>> wrote:
>> > On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
>> >> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote:
>> >> >
A new parameter was recently added to the i915 GEM contexts.
Add its define to i915_drm.h.
Signed-off-by: David Weinehall
---
include/drm/i915_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1cb117..a658d1cc367a 100644
--- a/i
Add helper functions to set/get GEM context parameters.
Signed-off-by: David Weinehall
---
intel/intel_bufmgr.h | 4
intel/intel_bufmgr_gem.c | 57
2 files changed, 61 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr
This patch contains a few minor updates related to
I915 GEM context.
David Weinehall (2):
intel: Add get/set context parameter helpers
Add the I915_CONTEXT_PARAM_NO_ZEROMAP parameter
include/drm/i915_drm.h | 1 +
intel/intel_bufmgr.h | 4
intel/intel_bufmgr_gem.c | 57 ++
Hi Dave.
Some fixes and some new features. I'd like you can pull them.
The following changes since commit c5fd936e992dd2829167d2adc63e151675ca6898:
drm/nouveau: Pause between setting gpu to D3hot and cutting the power
(2015-06-26 10:26:37 +1000)
are available in the git repository at:
Hi,
On 06/30/2015 02:01 PM, Benjamin Gaignard wrote:
> Hi,
>
> I think that what have been done by Rob with module_param is also a good idea:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934
>
> Can
Hi,
I am getting the following warning when I switch to the text console
from X. I do not know when this has started because I have noticed
that only now (in 4.1 kernel). I can try some older kernels if this is
useful.
I have tried to instrument drm_wait_one_vblank and dump drm_vblank_count
before
On Tue, Jun 30, 2015 at 03:24:51PM +0300, David Weinehall wrote:
> This patch contains a few minor updates related to
> I915 GEM context.
As a kernel API, this is absolutely awful. Can we please correct it before
it is released?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
There is nothing special about tilcdc HW when the video memory is
concerned. Just using the standard drm helpers for implementation is
enough.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drive
Hi,
On 06/30/2015 12:40 PM, Daniel Vetter wrote:
> Any updates on this or too much distractions? I really think doing
> this would be awesome for the drm subsystem, instead of reinventing
> this wheel for each driver.
I'd started on this again. I've got more free time now than before, so I
shoul
Call __drm_atomic_helper_plane_destroy_state() in the plane reset
handler instead of open-coding it. This will avoid changes to the driver
if plane state later gets more fields that need to be reset.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_plane.c | 3 +--
1 file changed
nal issues.
If you find some then please reopen this bug report.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/22
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150630/0dcccb1e/attachment.html>
On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard
wrote:
> I think that what have been done by Rob with module_param is also a good idea:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934
>
> Can yo
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list
We can have devices where the data bus is MIPI DSI, but the control bus
is something else (i2c, spi etc). A typical example is i2c controlled
encoder bridge chips.
Such devices too require passing DSI specific parameters (number of data
lanes, DSI mode flags, color format etc) to their DSI host. F
We are currently restricted when it comes to supporting DSI on devices
that have a non-DSI control bus. For example, DSI encoder chips are
available in the market that are configured via i2c. Configuring their
registers via DSI bus is either optional or not available at all.
These devices still ne
Hi,
I think that what have been done by Rob with module_param is also a good idea:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934
Can you mix compilation flag and module param ?
Benjamin
2015-06-3
On Tue, Jun 30, 2015 at 09:36:49AM +0200, Hans Verkuil wrote:
> On 06/29/15 21:25, Dmitry Torokhov wrote:
> > On Mon, Jun 29, 2015 at 12:14:49PM +0200, Hans Verkuil wrote:
> >> From: Kamil Debski
> >>
> >> Add HDMI CEC specific keycodes to the keycodes definition.
> >>
> >> Signed-off-by: Kamil De
On 06/29/15 21:25, Dmitry Torokhov wrote:
> On Mon, Jun 29, 2015 at 12:14:49PM +0200, Hans Verkuil wrote:
>> From: Kamil Debski
>>
>> Add HDMI CEC specific keycodes to the keycodes definition.
>>
>> Signed-off-by: Kamil Debski
>> Signed-off-by: Hans Verkuil
>
> Could you please describe the int
On Mon, Jun 29, 2015 at 01:44:46PM -0700, Rodrigo Vivi wrote:
> Now that we have fb user dirty invalidating frontbuffer and we have
> the new fbdev dirty callback let's merge them.
>
> So it doesn't matter if fbcon throught fbdev or splash screen throught
> drm_ioctl_dirtyfb, in any case we will h
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote:
> On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
>> Hi,
On Mon, Jun 29, 2015 at 01:44:44PM -0700, Rodrigo Vivi wrote:
> There are cases we need to mark dirty/damaged areas, specially with
> operations that touches frontbuffer directly. To cover these cases
> this patch introduces the optional fb_dirty operation.
>
> Signed-off-by: Rodrigo Vivi
The pr
On Mon, Jun 29, 2015 at 01:44:43PM -0700, Rodrigo Vivi wrote:
> This patch introduces a frontbuffer invalidation on dirty fb
> user callback.
>
> It is mainly used for DIRTYFB drm ioctl, but can be extended
> for fbdev use on following patch.
>
> This patch itself already solves the biggest PSR k
Hello Hans,
Thanks for the comments and good to know that V4L2 already has something
similar. It would be great to have something to compare / discus with :)
Yes, I agree that we can share a color library which can use any interface
underneath. Once we have some framework level stability, I wou
41 matches
Mail list logo
