Boris Brezillon writes:
> cirrus_modeset_init() is initializing/registering the emulated fbdev
> and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> !funcs->best_encoder is valid"), DRM internals can access/test some of
> the fields in mode_config->funcs as part of the fbdev
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/b8ed0e84/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/c7343a61/attachment.html>
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/d070d311/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/4b751b0d/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160808/90770831/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/00f79f6f/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/b71f2526/attachment-0001.html>
|RESOLVED
--- Comment #4 from JohnDoe ---
Fixed with 4.8rc1
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
27;t need those (or the workaround from my tree referenced in comment
1) now that the d3cold support has gone upstream via the pci tree.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160808/009c2ab5/attachment.html>
On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> 2016-08-07 Pavel Machek :
>
> > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > > Hi,
> > > >
> > > > Do you think there is time to get this in for 4.8?
> > >
>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/adcadcd4/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/16709819/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/dd1f5c82/attachment.html>
se before reporting) I'll attach them to the bug though
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/d1ea75d9/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/ccdbc239/attachment.html>
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/bfe36ff0/attachment.html>
On Fri, Aug 05, 2016 at 07:50:06PM -0600, Shuah Khan wrote:
> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
+ Archit
Tomeu,
Thanks for the update :-)
But you have missed three tiny align problems, please see my inline
notes, wish you could fix them. After that this patch looks good to me, so:
Reviewed-by: Yakir Yang
I guess this patch should go through Archit's drm_bridge tree, so I
added him in
Shouldn't be possible since everyone kzallocs this, but better safe
than sorry. Random drive-by-idea really.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
inde
From: Gustavo Padovan
SW_SYNC allows to run tests on the sync_file framework via debugfs on
/sync/sw_sync
Opening and closing the file triggers creation and release of a sync
timeline. To create fences on this timeline the SW_SYNC_IOC_CREATE_FENCE
ioctl should be used. To increment the timeline
From: Gustavo Padovan
This interface is hidden from kernel headers and it is intended for use
only for testing. So testers would have to add the ioctl information
internally. This is to prevent misuse of this feature.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c | 31 ++
From: Gustavo Padovan
remove file paths in the comments and add short description about each
file.
v2: remove file paths instead of just change them.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c| 2 +-
drivers/staging/android/sync_debug.c | 2 +-
drivers/staging/an
From: Gustavo Padovan
The common behaviour for trace headers is to have them in the same folder
they are used, instead of creating a special trace/ directory.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c| 2 +-
drivers/staging/android/sync_trace.h | 32
From: Gustavo Padovan
Closing the timeline without waiting all fences to signal is not
a critical failure, it is just bad usage from userspace so avoid
calling WARN_ON in this case.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 d
From: Gustavo Padovan
SW_SYNC should never be used by other pieces of the kernel apart from
sync_debug as it is only a Sync File Validation Framework, so hide any
info to avoid confuse this with a standard kernel internal API.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.
From: Gustavo Padovan
Hi Greg,
This is the last step in the Sync Framwork de-stage task. It de-stage
the SW_SYNC validation framework and the sync_debug info debugfs file.
The first 2 patches are clean up and improvements and the rest is preparation
to de-stage and then finally the actual de-st
- Original Message -
> From: "Linus Torvalds"
> To: "Eric W. Biederman" , "Boris Brezillon"
> , "Daniel
> Vetter"
> Cc: "Linux Kernel Mailing List" , "Dave
> Airlie" , "David Airlie"
> , "DRI"
> Sent: Tuesday, 9 August, 2016 7:19:23 AM
> Subject: Re: Linux 4.8-rc1 Cirrus QEMU crashes
Fix unsupported GEM memory type error message to include the memory type
information.
Signed-off-by: Shuah Khan
---
Changes since v1:
-- Comment changed to read clearly
drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/d
On Mon, Aug 8, 2016 at 1:23 PM, Maarten Lankhorst
wrote:
> There are two paths into intel_cleanup_plane_fb, the normal completion
> path and the failure path.
>
> In the failure case, intel_cleanup_plane_fb is called before
> drm_atomic_helper_swap_state, so any wait_req reference made in
> intel_
Hi,
On 05-08-2016 09:13, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
Hi Russell,
So, I didn't use fr
Hi,
On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote:
>On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
>> Hi Russell,
>>
>> On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
>> >
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
2016-08-08 Maarten Lankhorst :
> Op 20-06-16 om 17:53 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > When creating a sync_pt the name received wasn't used anywhere.
> > Now we add it to the sync info debug output to make it easier to indetify
> > the userspace name of that sync pt.
>
2016-07-24 Pavel Machek :
> On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> > 2016-08-07 Pavel Machek :
> >
> > > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > > > Hi,
> > > > >
> > > > > Do you think the
Reviewed-by: Rodrigo Vivi
On Mon, 2016-08-08 at 18:24 +0200, Daniel Vetter wrote:
> Shouldn't be possible since everyone kzallocs this, but better safe
> than sorry. Random drive-by-idea really.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> Â drivers/gpu/drm/drm_irq.c | 1 +
> Â 1
From: Michel Dänzer
These flags allow userspace to explicitly specify the target vertical
blank period when a flip should take effect.
v2:
* Add new struct drm_mode_crtc_page_flip_target instead of modifying
struct drm_mode_crtc_page_flip, to make sure all existing userspace
code keeps comp
From: Michel Dänzer
Mostly the same as the existing page_flip hook, but takes an additional
parameter specifying the target vertical blank period when the flip
should take effect.
v2:
* Add curly braces around else statement corresponding to an if block
with curly braces (Alex Deucher)
* Call
2016-08-07 Pavel Machek :
> On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > Hi,
> > >
> > > Do you think there is time to get this in for 4.8?
> >
> > No, it was too late on my end, due to travel and vacation, sorry
On 04.08.2016 16:42, Ville Syrjälä wrote:
> On Thu, Aug 04, 2016 at 12:39:41PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> These flags allow userspace to explicitly specify the target vertical
>> blank period when a flip should take effect.
>
> I like the idea. Atomic could use t
Read DisplayPort branch device info from through debugfs
interface.
v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v4: move DP branch device info to function 'intel_dp_branch_device_info()'
v5: initial step to m
DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.
v2: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v3: Fill bpc for connector's display info in separate
drm_dp_helper function
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
v2: DPCD read outs and c
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.
v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 27 +++
in
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.
v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 27 +++
d
Prep work for DP branch device handling
This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards
- DP to VGA
- DP to DVI
- DP to HDMI
- DP++ dual mode
- Wireless WiGig
DPCD register d
On 04.08.2016 19:56, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 12:39:41PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> @@ -543,15 +549,25 @@ struct drm_color_lut {
>> * 'as soon as possible', meaning that it not delay waiting for vblank.
>> * This may cause tearing on the sc
Hi,
Currently I am working on some HDMI 2.0 features using the DRM
infrastructure. I am mainly working in parsing the newly
introduced EDID blocks such as HDMI Forum Vendor Specific Data
Block, YCBCR 420 Video Data Block and YCBCR Capability Map Data
Block. The new blocks require some changes in t
Den 06.08.2016 00:38, skrev Paul Gortmaker:
> On Fri, Aug 5, 2016 at 11:44 AM, Noralf Trønnes
> wrote:
>> Create a simple fbdev device during SimpleDRM setup so legacy user-space
>> and fbcon can use it.
>>
>> Original work by David Herrmann.
>>
>> Cc: dh.herrmann at gmail.com
>> Signed-off-by:
On 08/08/2016 10:56 AM, Krzysztof Kozlowski wrote:
> On Fri, Aug 05, 2016 at 07:50:06PM -0600, Shuah Khan wrote:
>> Fix unsupported GEM memory type error message to include the memory type
>> information.
>>
>> Signed-off-by: Shuah Khan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
>>
From: Douglas Anderson
When fixing up the clock in vop_crtc_mode_fixup() we're not doing it
quite correctly. Specifically if we've got the true clock 26667 Hz,
we'll perform this calculation:
26667 / 1000 => 26
Later when we try to set the clock we'll do clk_set_rate(26 *
100
Hi Ville,
Two fixes inline...
On Wed, Jul 27, 2016 at 1:34 AM, wrote:
>
> From: Ville Syrjälä
>
> Add a version of drm_plane_helper_check_update() which takes a plane
> state instead of having the caller pass in everything.
>
> And to reduce code duplication, let's reimplement
> drm_plane_hel
https://bugzilla.kernel.org/show_bug.cgi?id=100871
--- Comment #10 from Charles R. Anderson ---
Problem still exists in Linux 4.6.4 in Fedora 24
(kernel-4.6.4-301.fc24.x86_64).
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 08/06/16 01:19, Russell King - ARM Linux wrote:
>> > It'll pick up that as the DT device to hang things off which I'd expect
>> > to be the desired outcome given that this is a very similar situation to
>> > the MFD situation. I've not been following the full thread so there is
>> > probably co
Instead of just preparing the panel on bind, actually prepare/unprepare
during modeset/disable. The panel must be prepared in order to read hpd
status and edid, so we need to keep state around the prepares in order
to ensure we don't accidentally turn the panel off at the wrong time.
Signed-off-by
On Mon, Aug 8, 2016 at 12:27 PM, Vivi, Rodrigo
wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Mon, 2016-08-08 at 18:24 +0200, Daniel Vetter wrote:
>> Shouldn't be possible since everyone kzallocs this, but better safe
>> than sorry. Random drive-by-idea really.
>>
>> Cc: Rodrigo Vivi
>> Signed-off-b
On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman
wrote:
>
> Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
>
> I am just about to head out the door on vacation until the end of the
> month so hopefully I am tossing out enough information to the right
> people.
>
> I have
dri-devel/attachments/20160808/285d5b57/attachment.html>
On Mon, 8 Aug 2016, Daniel Vetter wrote:
> On Sun, Aug 07, 2016 at 06:41:11PM -0500, Scot Doyle wrote:
> > Hi all,
> >
> > I'm interested in discussing ways compositors could cooperate
> > without CONFIG_VT/VT_VACTIVATE/VT_SETMODE.
> >
> > Daniel wrote up a nice article "VT Switching with Atomic
On Fri, Aug 5, 2016 at 8:30 PM, Lyude wrote:
> While I was investigating an unrelated bug on the radeon driver, I noticed
> that
> it's become rather difficult to actually read through dmesg with drm.debug
> turned on, on account of the huge number of messages we end up printing from
> failed DP
There are two paths into intel_cleanup_plane_fb, the normal completion
path and the failure path.
In the failure case, intel_cleanup_plane_fb is called before
drm_atomic_helper_swap_state, so any wait_req reference made in
intel_prepare_plane_fb will be in old_intel_state->wait_req.
In the normal
On 8 August 2016 at 12:43, Yakir Yang wrote:
> + Archit
>
> Tomeu,
>
> Thanks for the update :-)
>
> But you have missed three tiny align problems, please see my inline notes,
> wish you could fix them. After that this patch looks good to me, so:
>
> Reviewed-by: Yakir Yang
Hi Yakir,
thanks fo
Both the fence and event alloc are safe to be done without holding the GPU
lock, as they either don't need any locking (fences) or are protected by
their own lock (events).
This solves a bad locking interaction between the submit path and the
recover worker. If userspace manages to exhaust all ava
On 04.08.2016 20:01, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 12:47:38PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 04, 2016 at 12:39:36PM +0900, Michel Dänzer wrote:
>>>
>>> @@ -5434,6 +5435,18 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>>> if (!crtc)
>>> return
On 04.08.2016 19:12, Daniel Stone wrote:
> On 4 August 2016 at 11:01, Michel Dänzer wrote:
>> On 04.08.2016 18:51, Daniel Stone wrote:
>>> On 4 August 2016 at 04:39, Michel Dänzer wrote:
Patch 6 extends the ioctl with new flags, which allow userspace to
explicitly specify the target v
On 05.08.2016 00:13, Alex Deucher wrote:
> On Wed, Aug 3, 2016 at 11:39 PM, Michel Dänzer wrote:
>>
>> @@ -5434,6 +5435,18 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>> if (!crtc)
>> return -ENOENT;
>>
>> + if (crtc->funcs->page_flip_target) {
>> +
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +--
drivers/gpu/drm/ttm/ttm_bo.c| 3
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c| 3 +--
drivers/gpu/drm/ttm/ttm_bo_util.c |
From: Michel Dänzer
I noticed that these parameters are unused.
These patches apply on top of 34b58355ad1d ("drm/ttm: Wait for a BO to
become idle before unbinding it from GTT"), which is being merged to 4.8
via Alex's tree.
Michel Dänzer (2):
drm/ttm: Remove unused parameter evict from ttm
esktop.org/archives/dri-devel/attachments/20160808/ef670b46/attachment.html>
On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
> Hello there,
>
> Recent versions of gcc say this:
>
> include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
> requires 37 bits to represent, but âintâ only has 32 bits
> [-Wshift-overflow=]
>
> Source code is
>
Op 20-06-16 om 17:53 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> When creating a sync_pt the name received wasn't used anywhere.
> Now we add it to the sync info debug output to make it easier to indetify
> the userspace name of that sync pt.
>
> Signed-off-by: Gustavo Padovan
> ---
> d
On Sat, 06 Aug 2016, Rodrigo Vivi wrote:
> This patch is blocking PSR on panels that we know that our hardware support.
And it also fixes a regression on Linus' laptop, and it's been merged
upstream...
BR,
Jani.
>
> I wonder if:
> 1. This restrictions was for older platforms and spec is out dat
On Mon, Aug 8, 2016 at 5:08 AM, Christian König
wrote:
> Am 08.08.2016 um 05:28 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer
>
>
> Reviewed-by: Christian König
Applied. thanks!
Alex
>
>>
>> I noticed that these parameters are unused.
>>
>> These patches apply on top of 34b58355ad1d
On 6 August 2016 at 19:04, Daniel Stone wrote:
> Hi Tomeu,
>
> On 22 July 2016 at 15:10, Tomeu Vizoso wrote:
>> +/**
>> + * DOC: CRC ABI
>> + *
>> + * DRM device drivers can provide to userspace CRC information of each
>> frame as
>> + * it reached a given hardware component (a "source").
>> + *
Am 08.08.2016 um 05:28 schrieb Michel Dänzer:
> From: Michel Dänzer
Reviewed-by: Christian König
>
> I noticed that these parameters are unused.
>
> These patches apply on top of 34b58355ad1d ("drm/ttm: Wait for a BO to
> become idle before unbinding it from GTT"), which is being merged to 4
On Sat, Aug 06, 2016 at 10:26:09PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Hm, I can't see v1 anywhere, but I think it'd be better. You can't store
> > any transient state related to the current update in struct drm_plane. In
> > this case the cleanup_buffers from a previous upd
From: Ville Syrjälä
Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.
And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/d6389a0e/attachment-0001.html>
On Mon, Aug 08, 2016 at 03:29:24PM +0800, Daniel Kurtz wrote:
> Hi Ville,
>
> Two fixes inline...
>
> On Wed, Jul 27, 2016 at 1:34 AM, wrote:
> >
> > From: Ville Syrjälä
> >
> > Add a version of drm_plane_helper_check_update() which takes a plane
> > state instead of having the caller pass in
On Fri, Aug 05, 2016 at 03:10:51PM -0700, Rodrigo Vivi wrote:
> This patch is blocking PSR on panels that we know that our hardware support.
How do we know that?
> I wonder if:
> 1. This restrictions was for older platforms and spec is out dated
> 2. Or Spec is not documenting the restriction pro
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_
On Sun, Aug 07, 2016 at 06:41:11PM -0500, Scot Doyle wrote:
> Hi all,
>
> I'm interested in discussing ways compositors could cooperate
> without CONFIG_VT/VT_VACTIVATE/VT_SETMODE.
>
> Daniel wrote up a nice article "VT Switching with Atomic Modeset" [1]
> inviting discussion on dri-devel (about
Hello there,
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
requires 37 bits to represent, but âintâ only has 32 bits
[-Wshift-overflow=]
Source code is
#define INTEL_BSM_MASK (0x << 20)
Maybe something like
#define INTEL_BSM_MA
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/59a9e70c/attachment.html>
On Mon, Aug 08, 2016 at 12:54:45PM +0900, Michel Dänzer wrote:
> On 04.08.2016 20:01, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 12:47:38PM +0200, Daniel Vetter wrote:
> >> On Thu, Aug 04, 2016 at 12:39:36PM +0900, Michel Dänzer wrote:
> >>>
> >>> @@ -5434,6 +5435,18 @@ int drm_mode_page_fl
On Fri, Aug 05, 2016 at 02:49:44PM -0700, Rodrigo Vivi wrote:
> On Thu, Aug 4, 2016 at 1:26 AM, Daniel Vetter wrote:
> > On Wed, Aug 03, 2016 at 02:33:39PM -0700, Rodrigo Vivi wrote:
> >> DC state reset the frame counter that is a read-only register.
> >>
> >> So, besides blocking DC state on vbla
Op 06-08-16 om 02:07 schreef Lyude:
> From: Matt Roper
>
> When we write watermark values to the hardware, those values are stored
> in dev_priv->wm.skl_hw. However with recent watermark changes, the
> results structure we're copying from only contains valid watermark and
> DDB values for the pip
xt mode setting operation, which is likely to be days
away.
--
-keith
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/4af545e3/attachment-0001.sig>
.
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160808/5837fef5/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=118701
Stuart Foster changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|CODE_FIX
https://bugzilla.kernel.org/show_bug.cgi?id=151341
--- Comment #6 from yshuiv7 at gmail.com ---
Created attachment 227901
--> https://bugzilla.kernel.org/attachment.cgi?id=227901&action=edit
Kernel Oops when resetting the GPU
--
You are receiving this mail because:
You are watching the assigne
https://bugzilla.kernel.org/show_bug.cgi?id=151341
--- Comment #5 from yshuiv7 at gmail.com ---
I tried to reset the gpu by using /sys/kernel/debug/dri/0/amdgpu_gpu_reset, and
the result is a NULL pointer dereference in the kernel.
dmesg attached
--
You are receiving this mail because:
You are
96 matches
Mail list logo
