chment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/3144cf32/attachment-0001.html>
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/20160803/4a53c8ed/attachment.html>
On Tue, Aug 02, 2016 at 04:09:58PM -0700, Joshua Clayton wrote:
> Greetings Russell,
> I'm publishing an etnaviv yocto layer on github.
> One of the components is libdrm-armada, which we get from
> git://ftp.arm.linux.org.uk/~rmk/libdrm-armada.git
>
> I don't want to put an unwanted extra burden o
On Tue, 2016-08-02 at 13:04 -0400, Sean Paul wrote:
> On Tue, Aug 2, 2016 at 1:02 PM, Sean Paul wrote:
> > On Fri, Jul 29, 2016 at 5:04 AM, Bibby Hsieh
> > wrote:
> >> From: Daniel Kurtz
> >>
> >> The mtk_plane_enable is just called once by mtk_plane_atomic_update.
> >> So, merge mtk_plane_enab
On 6 July 2016 at 20:05, Mario Kleiner wrote:
> For DP sinks which don't expose color depth via EDID, use
> the drm_dp_sink_bpc() helper to derive the bpc of the sink.
>
> This should handle DP native sinks with the "Assume 6 bpc if EDID
> doesn't tell us" as mandated by DP spec. It gives more acc
Hi Linus,
This tree was waiting on some media stuff I hadn't had time to get a
stable branchpoint off, so I just waited until it was all in your tree
first, it's been around a bit on the list and shouldn't affect anything
outside adding the generic API and moving some ARM drivers to using it.
D
On 03.08.2016 01:12, Rob Clark wrote:
Hi,
>> Well, if it already does buffer allocation and mapping (which might
>> also involve copying around phyisical buffers), why not also add
>> copy-between-buffers ?
>
> except "dumb" buffers exist *only* for CPU rendered content, you
> cannot assume that
On 3 August 2016 at 13:33, Enrico Weigelt, metux IT consult
wrote:
> On 03.08.2016 01:12, Rob Clark wrote:
>
> Hi,
>
>>> Well, if it already does buffer allocation and mapping (which might
>>> also involve copying around phyisical buffers), why not also add
>>> copy-between-buffers ?
>>
>> except
t was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/3fe9482a/attachment.html>
On 03.08.2016 05:47, Dave Airlie wrote:
> Because no hw is the same once you go beyond that.
hmm, it doesn't seem to be so extremly different, that we cant
at least abstract some common aspects.
> Video memory size means what? VRAM, GPU accessible system RAM,
> amount of CPU visible VRAM?
Actua
On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
> On 6 July 2016 at 20:05, Mario Kleiner wrote:
> > For DP sinks which don't expose color depth via EDID, use
> > the drm_dp_sink_bpc() helper to derive the bpc of the sink.
> >
> > This should handle DP native sinks with the "Assume 6 b
https://bugzilla.kernel.org/show_bug.cgi?id=151341
Bug ID: 151341
Summary: AMDGPU Hawaii: screen freeze, Xorg blocked in
fence_default_wait
Product: Drivers
Version: 2.5
Kernel Version: 4.7.0
Hardware: x86-64
From: Ville Syrjälä
This series aims to clean up the way we fill out the display_info
structure a bit. Mainly doing a clean separation of the audio and
video related bits.
My aim is getting i915 to respect the HDMI sink TMDS clock limit
(currently we respect only the DP++ dongle limit, and th
From: Ville Syrjälä
Clear out stale audio latency information (potentially from a previous
EDID) before constructing the ELD from the EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/dr
From: Ville Syrjälä
Clear out old max_tmds_clock and dvi_dual information (possibly from a
previous EDID) before parsing the current EDID. Tne current EDID might
not even have these in its HDMI VSDB, which would mean that we'd leave
the old stale values in place.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
We generally store clocks in kHz, so let's do that for the
HDMI max TMDS clock value as well. Less surpising.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
drivers/gpu/drm/drm_edid.c
From: Ville Syrjälä
Instead of parsing parts of the CEA extension block in two places
to determine supported color formats and whatnot, let's just
consolidate it to one function. This also makes it possible to neatly
flatten drm_assign_hdmi_deep_color_info().
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
We have the drm_display_info for storing information about the sink, so
let's move dvi_dual and max_tmds_clock in there.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 4 ++--
drivers/gpu/drm/
From: Ville Syrjälä
It's not a good idea to leave stale cea_rev in the drm_display_info. The
current EDID might not even have a CEA ext block in which case we'd end
up leaving the stale value in place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 1 +
1 file changed, 1 ins
From: Ville Syrjälä
drm_edid_to_eld() is just mean to cook up the ELD for the audio driver,
so having it parse non-audio related stuff seems just wrong, and
potentially could lead to that information not being even filled out
if the function doesn't even get called. Let's move that stuff to the
From: Ville Syrjälä
We already pass the connector to drm_add_display_info() and
drm_assign_hdmi_deep_color_info(), so passing the
connector->display_info also is pointless.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 11 ---
1 file changed, 4 insertions(+), 7 dele
From: Ville Syrjälä
Reduce the eyesore with a local variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.
From: Ville Syrjälä
It's perfectly legal for the sink to support 12bpc only for
some lower resolution modes, while the higher resolution modes
can only be used with 8bpc. So let's take the sink's max TMDS clock
into account before we go and decide that a particular mode can
be used with 12bpc.
On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_fun
On Tue, Aug 02, 2016 at 11:30:21PM -0700, Rodrigo Vivi wrote:
> I was going to remove the legacy get/put versions right now, but
> decided to check if there were any pending patch in mailing lists and
> found this.
>
> What about deleting the functions at all instead of having it internally?
Ther
Op 03-08-16 om 00:37 schreef Lyude:
> 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 th
On Wed, Aug 03, 2016 at 10:06:38AM +0300, Ville Syrjälä wrote:
> On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote:
> > Adds files and directories to debugfs for controlling and reading frame
> > CRCs, per CRTC:
> >
> > dri/0/crtc-0/crc
> > dri/0/crtc-0/crc/control
> > dri/0/crtc-0/cr
On Fri, Jul 22, 2016 at 04:10:45PM +0200, Tomeu Vizoso wrote:
> The core provides now an ABI to userspace for generation of frame CRCs,
> so implement the ->set_crc_source() callback and reuse as much code as
> possible with the previous ABI implementation.
>
> v2:
> - Leave the legacy impleme
[1.162571] Unable to handle kernel NULL pointer dereference at virtual
address 0200
[1.165656] Modules linked in:
[1.165941] CPU: 5 PID: 143 Comm: kworker/5:2 Not tainted 4.4.15 #237
[1.166506] Hardware name: Rockchip RK3399 Evaluation Board v1 (Android) (DT)
[1.167153] Wor
On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote:
> [1.162571] Unable to handle kernel NULL pointer dereference at virtual
> address 0200
> [1.165656] Modules linked in:
> [1.165941] CPU: 5 PID: 143 Comm: kworker/5:2 Not tainted 4.4.15 #237
> [1.166506] Hardware name: R
On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote:
> > [1.162571] Unable to handle kernel NULL pointer dereference at virtual
> > address 0200
> > [1.165656] Modules linked in:
> > [1.165941] CPU: 5 PID: 143 Co
On 2016å¹´08æ03æ¥ 16:46, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote:
>> On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote:
>>> [1.162571] Unable to handle kernel NULL pointer dereference at virtual
>>> address 0200
>>> [1.165656] Modu
On 03.08.2016 02:49, Nicolai Hähnle wrote:
> On 02.08.2016 12:08, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Fixes warnings and miscompilation resulting in crashes with clang.
>
> How annoying. Seems like this would affect most (current and future)
> uses of container_of, and so it woul
Hello Nicolai Hähnle,
The patch 324c614a819a: "drm/amdgpu/gfx7: set
USER_SHADER_ARRAY_CONFIG based on disable_cu parameter" from Jun 17,
2016, leads to the following static checker warning:
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5057 gfx_v7_0_get_cu_info()
error: buffer overflow '
Hi Enrico,
On 2016-08-02 15:21, Enrico Weigelt, metux IT consult wrote:
> I'm currently thinking about adding an hw-accelerated bitblt operation.
> The idea goes like this:
>
> * we add some bitblt ioctl which copies rects between bo's.
>(it also handles memory layouts, pixfmt conversion, etc
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/857de4ed/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/90d00785/attachment.html>
This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
supported for HDMI 2.0 4k modes.
Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
This patch adds drm flag bits for aspect ratio information
Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.
Signed-off-by: Shashank Sharma
---
in
Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
Signed-off-by: Shashank Sharma
---
drivers/video/hdmi.c | 4
include/linux/hdmi.h | 2 ++
2 files changed, 6 insertions(+)
diff -
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or viseversa.
Signed-off-by: Shashank Sharma
---
drivers/gpu
org/archives/dri-devel/attachments/20160803/8d6d8759/attachment.html>
On Wed, Aug 3, 2016 at 4:56 AM, Michel Dänzer wrote:
> On 03.08.2016 02:49, Nicolai Hähnle wrote:
>> On 02.08.2016 12:08, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> Fixes warnings and miscompilation resulting in crashes with clang.
>>
>> How annoying. Seems like this would affect mo
On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Signalling doesn't need to be enabled at sync_file creation, it is only
> required if userspace waiting the fence to signal through poll().
>
> Thus we delay fence_add_callback() until poll is called. It
On Wed, Aug 03, 2016 at 11:24:37AM +0200, Marek Szyprowski wrote:
> Hi Enrico,
>
>
> On 2016-08-02 15:21, Enrico Weigelt, metux IT consult wrote:
> > I'm currently thinking about adding an hw-accelerated bitblt operation.
> > The idea goes like this:
> >
> > * we add some bitblt ioctl which copi
On Wed, Aug 03, 2016 at 04:26:24PM +0530, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
> supported for HDMI 2.0 4k modes.
>
> Adding aspect ratio support
On Wed, Aug 03, 2016 at 04:56:20PM +0800, Mark yao wrote:
> On 2016å¹´08æ03æ¥ 16:46, Daniel Vetter wrote:
> > On Wed, Aug 03, 2016 at 10:43:21AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 03, 2016 at 04:13:45PM +0800, Mark Yao wrote:
> > > > [1.162571] Unable to handle kernel NULL pointer
On 08/03/2016 08:09 AM, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
>> On 6 July 2016 at 20:05, Mario Kleiner wrote:
>>> For DP sinks which don't expose color depth via EDID, use
>>> the drm_dp_sink_bpc() helper to derive the bpc of the sink.
>>>
>>> This sh
Looks reasonable to me, adding a few more AMD people which probably want
to take a look as well.
Patch #3 and #4 are Reviewed-by: Christian König
since they touch the radeon/amdgpu driver.
Patch #1, #2 and #5 - #8 are Acked-by: Christian König
.
Regards,
Christian.
Am 03.08.2016 um 08:33
they are annyoing.
Instructions can be found in the PC Gaming Wiki.
--
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
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/20160803/8bc8ea89/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=151341
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
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
On Wed, Aug 03, 2016 at 09:50:23AM -0400, Lyude wrote:
...
> +int
> +skl_disable_sagv(struct drm_i915_private *dev_priv)
> +{
> + int ret, result;
> +
> + if (IS_BROXTON(dev_priv))
> + return 0;
> + if (!dev_priv->skl_sagv_enabled)
> + return 0;
> +
> + mutex
On Tue, Aug 02, 2016 at 06:37:37PM -0400, Lyude wrote:
> 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 w
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the numbe
Having added an interval-tree to struct drm_mm, we can replace the
auxiliary rb-tree inside the drm_vma_manager with it.
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_vma_manager.c | 43 ---
incl
As we always add this to the drm_mm->hole_stack as our first operation,
we do not need to initialise the list node.
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff
On Tue, Aug 02, 2016 at 06:50:01PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the
> corresponding macro,
> Patch series seems to have 0 changelogs anywhere, but I'm pretty sure I've
> seen this before. > > Please try again and state what changed and why you are
> resubmitting this.
> -Daniel
Hi Daniel,
This is a re-spin of the patch series for aspect ratio support.
The first four patches dint get
Hello Joes,
> I've also seen this before and I am using them in order to pass HDMI
> compliance. Without
> these patches the compliance fails. Still, I've made some changes which I can
> submit. I've
> some comments to you (Shashank):
Thanks for addressing these patches. You are welcome to review
It was really strange to see negative vblank seqs on debug
messages. It is rare to have that big number, but when it
happens it is confusing and misleading.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_irq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/dr
hment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/02e20f22/attachment.sig>
On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma
wrote:
> This patch adds drm flag bits for aspect ratio information
>
> Currently drm flag bits don't have field for mode's picture
> aspect ratio. This field will help the driver to pick mode with
> right aspect ratio, and help in setting right VIC
On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma
wrote:
> Current DRM layer functions dont parse aspect ratio information
s/dont/don't/
> while converting a user mode->kernel mode or viceversa. This
s/viceversa/vice versa/
> causes modeset to pick mode with wrong aspect ratio, eventually
> caui
Hi Chris
On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson
wrote:
> Having added an interval-tree to struct drm_mm, we can replace the
> auxiliary rb-tree inside the drm_vma_manager with it.
>
> Signed-off-by: Chris Wilson
> Cc: David Herrmann
> Cc: dri-devel at lists.freedesktop.org
> ---
Should
On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma
wrote:
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
>
> This patch adds enumeration for the new aspect ratios
> in the existing aspect ratio list.
>
> Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
> ---
>
On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma
wrote:
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
>
> This patch:
> - Adds new DRM flags for to represent these new aspect ratios.
> - Adds new cases to handle these aspect ratios while converting
> from user->kern
Hi Chris
On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson
wrote:
> As we always add this to the drm_mm->hole_stack as our first operation,
> we do not need to initialise the list node.
>
> Signed-off-by: Chris Wilson
> Cc: David Herrmann
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gp
Hey
On Wed, Aug 3, 2016 at 5:04 PM, Chris Wilson
wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookups f
Hi
Some rather random cleanups on drm_file and whatever I found on the way. The
idea here really is to get to a point where we can allocate drm_file from a
kernel context to get in-kernel rendering to work. This would allow allocating
dumb-buffers, dma-bufs, etc. from within the kernel and get fbd
The minor referred to by "DRM_MINOR_LEGACY" is called 'dev->primary' and
gets 'cardX' as name assigned. Lets reduce this magnificent number of
names for the same concept by one and rename DRM_MINOR_LEGACY to
DRM_MINOR_PRIMARY (to match the actual struct-member name).
Furthermore, this is in no way
Each DRM file-context caches the EUID of the process that opened the file.
It is used exclusively for debugging purposes in /proc/dri/ and friends.
Note, however, that "struct file" already caches the credentials of a
process at open-time. So lets just use drm_file->filp->f_cred->euid if
available
The *only* known user of GETCLIENT is libva, which uses it to check
whether its own context is authenticated. It used to iterate all clients,
look for one that matches its own pid and then check its state.
The entire purpose for us to still have a GETCLIENT implementation is to
serve libva. So let
Right now, the vma-manager requires all entries to provide a "struct
file*" as identifier. This is confusing, since there is no inherent
connection to "struct file" in the vma-manager at all, but it is
exclusively used as tag.
Replace its usage with a simple "void *tag" and make sure callers can u
Rather than using "struct file*", use "struct drm_file*" as tag VM tag for
BOs. This will pave the way for "struct drm_file*" without any "struct
file*" back-pointer.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
drivers/gpu/drm/ast/ast_ttm.c | 3 ++
We don't want anyone but legacy DRM1 code to use drm_file.filp. Especially
for in-kernel contexts, this might be set to NULL, so lets make sure
no-one accesses it, ever.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_bufs.c | 7 ---
drivers/gpu/drm/drm_fops.c | 2 +-
include/drm/drmP.
Rather than accessing priv->filp->f_cred, use priv->pid->task->creds. We
want to get rid of "priv->filp", so lets avoid it if possible.
Since we already are in an rcu-read-side, we can use __task_cred() rather
than task_cred_xxx().
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_info.c |
Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs (not that I
am aware of
Oh, nevermind... I saw the places that depends on changes on other
legacy usage like drm_wait_on_vblank... (not trivial on intel_crt)
and other cases...
So better to just go with the static for now.
Feel free to use:
Reviewed-by: Rodrigo Vivi
On Wed, Aug 3, 2016 at 12:22 AM, Daniel Vetter wr
At a higher level, all objects are created with definite size i.e. 0 is
illegal. In forthcoming patches, this assumption is dependent upon in
the drm_mm range manager, i.e. trying to create a drm_mm node with size
0 will have undefined behaviour. Add a couple of WARNs upon creating the
drm_mm node
Am Dienstag, 2. August 2016, 10:16:04 schrieb Yakir Yang:
> Hi Mark & Heiko,
>
> Ping..
devicetree side looks good, so we're waiting on Mark to pick up patch 1.
Heiko
> On 06/15/2016 09:28 PM, Yakir Yang wrote:
> > Using the common hdmi-codec driver to support hdmi audio function.
> >
> >
Hi,
I have changed simpledrm to use drm_simple_kms_helper and now I'm
facing this:
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
d
On Wed, Aug 03, 2016 at 08:04:28PM +0200, David Herrmann wrote:
> Right now, the vma-manager requires all entries to provide a "struct
> file*" as identifier. This is confusing, since there is no inherent
> connection to "struct file" in the vma-manager at all, but it is
> exclusively used as tag.
On Wed, Aug 03, 2016 at 08:04:26PM +0200, David Herrmann wrote:
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 323c238..e9d66f5 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -199,7 +199,6 @@ static int drm_open_helper(struct file *
On Wed, Aug 03, 2016 at 08:04:30PM +0200, David Herrmann wrote:
> Rather than accessing priv->filp->f_cred, use priv->pid->task->creds. We
> want to get rid of "priv->filp", so lets avoid it if possible.
>
> Since we already are in an rcu-read-side, we can use __task_cred() rather
> than task_cred
On Wed, Aug 03, 2016 at 08:04:26PM +0200, David Herrmann wrote:
> @@ -98,13 +99,14 @@ int drm_clients_info(struct seq_file *m, void *data)
>
> rcu_read_lock(); /* locks pid_task()->comm */
> task = pid_task(priv->pid, PIDTYPE_PID);
> + uid = priv->filp ? pr
On Wed, Aug 03, 2016 at 09:53:46AM -0700, Rodrigo Vivi wrote:
> It was really strange to see negative vblank seqs on debug
> messages. It is rare to have that big number, but when it
> happens it is confusing and misleading.
>
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
> ---
>
On Wed, Aug 03, 2016 at 08:04:29PM +0200, David Herrmann wrote:
> Rather than using "struct file*", use "struct drm_file*" as tag VM tag for
> BOs. This will pave the way for "struct drm_file*" without any "struct
> file*" back-pointer.
>
> Signed-off-by: David Herrmann
Ok, the danger of untyped
It's super confusing that new drivers need to be marked with
DRIVER_MODESET when really it means DRIVER_MODERN. Much better to
invert the meaning and rename it to something that's suitably
off-putting.
Since there's over 100 places using DRIVER_MODESET we need to roll out
this change without a fla
Except for nouveau, only legacy drivers need this really. And nouveau
is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special
case.
I've tried to be careful to leave everything related to modeset still
using the DRIVER_MODESET flag. Otherwise it's a direct replacement of
!DRIVER_MODESET
Hi Archit,
On Tuesday 19 Jul 2016 12:06:41 Archit Taneja wrote:
> Hi Dave,
>
> This is an update to the previous drm bridge pull request. The ADV7511
> driver's conversion from slave encoder to bridge meant that its users
> (the rcar-du kms driver) should use the bridge interface too. This pull
>
Den 02.08.2016 15:05, skrev Daniel Vetter:
> On Sat, Jul 30, 2016 at 5:48 PM, Noralf Trønnes
> wrote:
>> Den 29.07.2016 10:23, skrev Daniel Vetter:
>>> Actually adding David.
>>> -Daniel
>>>
>>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
On Thu, Jul 28, 2016 at 04:15:04
The conversion of the rcar-du driver from the I2C slave encoder to the
DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing
the bridge from being handled automatically by the DRM core. Fix it.
Fixes: 1d926114d8f4 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi
encode
On Tue, Aug 02, 2016 at 02:20:33PM -0700, Matt Roper wrote:
> On Tue, Aug 02, 2016 at 02:52:51PM -0400, Lyude wrote:
> > Thanks to Ville for suggesting this as a potential solution to pipe
> > underruns on Skylake.
> >
> > On Skylake all of the registers for configuring planes, including the
> > r
On Wed, Aug 03, 2016 at 02:14:53PM -0700, Matt Roper wrote:
...
>
> I imagine we'll eventually probably want to create a new display vfunc
> to handle platform-specific pipe-level stuff that needs to happen under
> vblank evasion (like the scalers and linetime WM we have today) to keep
> the code
No functional change. Justs finish the migration from
drm_vblank_*(dev, pipe) to drm_crtc_vblank_*(crtc)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/nouveau/nouveau_display.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_
No functional change. Only removing unused legacy functions.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_irq.c | 62 +--
include/drm/drm_irq.h | 2 --
2 files changed, 12 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq
No functional change.
This is the last user of legacy function so we will be able
to clean up drm_irq.c a bit.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_drv.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/
1 - 100 of 127 matches
Mail list logo
