On 20 June 2016 at 22:17, Daniel Vetter wrote:
> On Sat, Jun 18, 2016 at 12:46:38AM +0100, Emil Velikov wrote:
>> On 17 June 2016 at 08:33, Daniel Vetter wrote:
>> > @@ -64,16 +73,6 @@ int drm_getmagic(struct drm_device *dev, void *data,
>> > struct drm_file *file_priv)
>> > return ret <
On Sat, Jun 18, 2016 at 12:46:38AM +0100, Emil Velikov wrote:
> On 17 June 2016 at 08:33, Daniel Vetter wrote:
> > @@ -64,16 +73,6 @@ int drm_getmagic(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
> > return ret < 0 ? ret : 0;
> > }
> >
> > -/**
> > - * drm_authmagi
On Sat, Jun 18, 2016 at 12:47:21AM +0100, Emil Velikov wrote:
> On 18 June 2016 at 00:00, Emil Velikov wrote:
>
> >> @@ -134,24 +152,21 @@ static int drm_new_set_master(struct drm_device
> >> *dev, struct drm_file *fpriv)
> >>
> >> /* take another reference for the copy in the local file
Hi Dave,
The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:
Merge tag 'topic/drm-misc-2016-06-15' of git://anongit.freedesktop.org/drm-
intel into drm-next (2016-06-16 05:49:32 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.git drm
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/73f560e1/attachment.html>
org/archives/dri-devel/attachments/20160620/095335af/attachment.html>
On Fri, Jun 17, 2016 at 08:53:11AM +0100, Chris Wilson wrote:
> On Fri, Jun 17, 2016 at 09:33:25AM +0200, Daniel Vetter wrote:
> > - Group declarations for separate files (drm_bridge.c, drm_edid.c)
> > - Move declarations only used within drm.ko to drm_crtc_internal.h
> > - drm_property_type_valid
On Mon, Jun 20, 2016 at 05:42:46PM +0100, Matthew Auld wrote:
> The drm_pending_event can be freed by drm_send_event_locked, as a
> result we should call trace_drm_vblank_event_delivered before this
> to avoid hitting a user-after-free error when accessing the pid member:
>
> [ 378.438497] BUG: K
Em Sex, 2016-06-10 Ã s 08:44 +0200, Stefan Richter escreveu:
> On Jun 09 Zanoni, Paulo R wrote:
> >
> > Em Qui, 2016-06-09 Ã s 11:58 -0400, Lyude escreveu:
> > >
> > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
> > >
> > > This was kind of a difficult bug to track down. If you're
Enable the standard GEM dma-buf interface provided by the DRM core, but
only for exporting the VGEM object. This allows passing around the VGEM
objects created from the dumb interface and using them as sources
elsewhere. Creating a VGEM object for a foriegn handle is not supported.
v2: With additi
On Mon, Jun 20, 2016 at 09:04:32PM +0100, Chris Wilson wrote:
Eek, appologies. This was meant to git-send-email -v3 but mangled into
-3 instead.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
---
drivers/gpu/drm/i915/i915_debugfs.c| 162 +---
drivers/gpu/drm/i915/i915_drv.h| 84 ++---
drivers/gpu/drm/i915/i915_gem.c| 144 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +-
drivers/gpu/drm/i915/i915_gem_request.c| 287
If a driver does not have a parent, or never sets the unique name for
itself, then we may proceed to chase a NULL dereference through
debugfs/.../name.
Testcase: igt/vgem_basic/debugfs
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 21 ++---
1 fil
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 49e7ff9840bd..c3f177231f6a 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem
gt;
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/9348a018/attachment-0001.html>
If a driver does not have a parent, or never sets the unique name for
itself, then we may proceed to chase a NULL dereference through
debugfs/.../name.
Testcase: igt/vgem_basic/debugfs
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 21 ++---
1 fil
ted to Steam titles
--
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/20160620/4e11efc1/attachment-0001.html>
On 6/20/2016 6:34 PM, Rob Herring wrote:
> On Thu, Jun 16, 2016 at 05:06:46PM +0530, Archit Taneja wrote:
>> The MSM8916 SoC contains a MDP5 based display block, and one DSI output.
>> Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children
>> sub-blocks. Establish the link between
7.0-1
--
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/20160620/eddc6b50/attachment.html>
On Mon, Jun 20, 2016 at 04:30:36PM +0100, Chris Wilson wrote:
> On Mon, Jun 20, 2016 at 05:22:55PM +0200, Benjamin Gaignard wrote:
> > Like what has been done for connectors add callbacks on encoder,
> > crtc and plane to let driver do actions after drm device registration.
> >
> > Correspondingly
Hi Benjamin,
On 20 June 2016 at 16:22, Benjamin Gaignard
wrote:
> +
> + drm_dev_set_unique(ddev, dev_name(dev));
> +
Daniel Vetter has a series in flight [1] which should make this
obsolete (wrong actually).
There were a couple of minor issues, but I'd expect it to be complete
some time th
xt attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/77b38ced/attachment.sig>
already.
On Tegra124 and earlier the HDMI output is driven by a separate IP block
that's not at all related to SOR, and I haven't found any evidence that
it would be in the SOR power partition either.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/259513f5/attachment.sig>
; > { .compatible = "nvidia,tegra124-dpaux", .data =
> > &tegra124_dpaux_soc },
> > { },
> > };
>
> OK. I wonder if we should call it 'has_safe_clock' because this clock
> does not exist for tegra124 AFAICT. #bikeshed ;-)
has_safe_clock is fine with me, too.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/eb942b43/attachment.sig>
On 20 June 2016 at 15:31, Daniel Vetter wrote:
> On Sun, Jun 19, 2016 at 02:31:31PM +0200, Mathias Krause wrote:
>> [...]
>> With no users left, we can remove dma_buf_debugfs_create_file().
>>
>> While at it, simplify the error handling in dma_buf_init_debugfs()
>> slightly.
>>
>> Signed-off-by: M
-
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/20160620/be41d398/attachment.html>
The gpu documentation has now been converted to reStructuredText files
under Documentation/gpu. Remove the obsolete DocBook template. Also
remove it from MAINTAINERS.
Good riddance.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/Makefile |2 +-
Documentation/DocBook/gpu.tmpl | 3528 --
Pandoc really did a bad job of converting the big KMS properties table
to RST. Instead, put the properties into a separate plain text CSV file,
and include it in the RST file. The generated output isn't very pretty,
but at least the information is there, and it's stored in a format
that's easier to
While splitting the document up, the headings "shifted" from what pandoc
generated. Use the following order for headings for consistency:
==
Document title
==
First
=
Second
--
Third
~
Leave the lower level headings as they are; I think those are less
import
We'll want to keep an eye on what's going on in these files.
Signed-off-by: Jani Nikula
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb88f724e07c..ce9c23dd02c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3857,6 +3857,7 @@ F:driv
Make the gpu documentation easier to manage by splitting to separate
files. Again, this is just the split, no real edits.
Signed-off-by: Jani Nikula
---
Documentation/gpu/drm-internals.rst | 1998 +++
Documentation/gpu/drm-userland-interfaces.rst | 91 +
Documentation
This is the first step towards converting the DocBook gpu.tmpl to Sphinx
and reStructuredText, the new kernel documentation tool and markup.
Use Jon's "cheesy conversion script" in Documentation/sphinx/tmplcvt to
do the rough conversion. Do the manual edits in follow-up patches. Add a
new Document
Hi all, this series converts the DocBook gpu.tmpl to reStructuredText,
now that we have Sphinx support merged to docs-next and drm-next.
I haven't really touched the content, this is just a fairly mechanical
conversion and split up of the document. I'm sure there are small issues
here and there, b
The drm_pending_event can be freed by drm_send_event_locked, as a
result we should call trace_drm_vblank_event_delivered before this
to avoid hitting a user-after-free error when accessing the pid member:
[ 378.438497] BUG: KASAN: use-after-free in send_vblank_event+0xf0/0x310 [drm]
at addr
for one or the other. So I guess at least
> >> gallium and mali are doing the same thing. No idea if that is the
> >> same thing that i965 does.
> >
> > Hi,
> >
> > Quentin did some tests for me, and the results are... not what I would
> > have expected:
> > https://phabricator.freedesktop.org/T7475#88454
> >
> > RadeonSI works like Intel, but Nouveau does the opposite. I think the
> > Nouveau way is correct by the spec, which makes everyone else (intel,
> > radeonsi, weston-simple-dmabuf-v4l) get it wrong. Unfortunately, two
> > wrongs make a right, so when weston-simple-dmabuf-v4l hardcodes Y_INVERT
> > as set, it'll come out the right way on intel and radeon.
>
> oh, wow.. that seems quite odd that two different gallium drivers have
> different results, since I'd have expected this to be completely
> handled by mesa/st.. now I'm somewhat curious.
Hi,
after a head-scratching session on #dri-devel and a little bit on
#wayland too, I'm ready to punt that off as a bad test.
It is quite possible the machine running nouveau had a webcam that
really produces upside-down images. weston-simple-dmabuf-v4l does not
understand that. Apparently mpv OTOH does. How, maybe there is an
answer in V4L2 API, but I haven't looked it up yet.
If we look at the Vivid tests, the results are consistent and expected.
All intel, nouveau and radeon work the same way.
> > And it is wrong for weston-simple-dmabuf-v4l to set Y_INVERT, that I
> > believe is clear. It is only there because of the "oops, it's
> > upside-down" syndrome, AFAIK.
> >
> >> > After all, using GL with windows and FBOs and stuff you very often find
> >> > yourself upside down, and I suspect people have got the habit of just
> >> > flipping it if it does not look right the first time. See e.g. the
> >> > row-order of data going into glTexImage2D...
> >> >
> >> > If the answer is "oops, well, dmabuf import is semantically y-flipping
> >> > when it should not, but we cannot fix it because that would break
> >> > everyone", I would be happy with that. I just want confirmation before
> >> > flipping the flip flag. :-)
> >
> > So many bugs that accidentally counter each other...
Seems like we can conclude this by saying that a dmabuf imported via
EGL as a GL texture will have the origin at top-left, instead of what
the GL spec says.
Thanks,
pq
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/62207ab8/attachment.sig>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/6da0/attachment-0001.html>
Use drm_dev_alloc() and drm_dev_register() instead of .load()
To simplify init sequence only create fbdev when requested
in output_poll_changed().
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 140 +
drivers/gpu/drm/sti/sti_drv.h |
Make sti driver use register callback to move debugfs
initialization out of sub-components creation.
This will allow to convert driver .load() to
drm_dev_alloc() and drm_dev_register().
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_compositor.c | 20
drivers/g
Like what has been done for connectors add callbacks on encoder,
crtc and plane to let driver do actions after drm device registration.
Correspondingly, add callbacks called before unregister drm device.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_drv.c | 42 +++
late_register() and early_unregister() callbacks have been introduced
for connectors, let do the same for encoders, crcts and planes.
Like for the previously introduced functions they are called
right after drm device registration and before unregistration.
Those new callbacks allow to defer actio
On Sat, Jun 18, 2016 at 4:55 PM, Nicolas Iooss
wrote:
> amdgpu_cgs_acpi_eval_object() returned the value of variable "result"
> without initializing it first.
>
> This bug has been found by compiling the kernel with clang. The
> compiler complained:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
On Sat, Jun 18, 2016 at 4:38 AM, Dan Carpenter
wrote:
> ! has higher precedence than bitwise & so we need to add parenthesis
> for this to work as intended.
>
> Fixes: 048765ad5af7 ('amdgpu: fix asic initialization for virtualized
> environments (v2)')
> Signed-off-by: Dan Carpenter
Applied.
As a forewarning: I have confirmed the CRT hpd loops Vsyrjala has mentioned, and
they are triggered by this patch. I'm working on a patch for this atm.
On Mon, 2016-06-20 at 16:57 -0400, Lyude wrote:
> Unfortunately, there's two situations where we lose hpd right now:
> - Runtime suspend
> - When
Unfortunately, there's two situations where we lose hpd right now:
- Runtime suspend
- When we've shut off all of the power wells on Valleyview/Cherryview
While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get the
Hi CK,
Thanks for your comments.
On Mon, 2016-06-13 at 13:56 +0800, CK Hu wrote:
> Hi, YT:
>
> Some comments inline.
>
> On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote:
> > This patch add support for the Mediatek MT2701 DISP subsystem.
> > There is only one OVL engine in MT2701.
> >
> > Sign
Hi CK,
On Mon, 2016-06-13 at 14:43 +0800, CK Hu wrote:
> Hi, YT:
>
> One comment inline.
>
> On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote:
> > We need to acquire mutex before using the resources,
> > and need to release it after finished.
> > So we don't need to write registers in the blanki
On Mon, Jun 20, 2016 at 05:22:57PM +0200, Benjamin Gaignard wrote:
> static int sti_bind(struct device *dev)
> {
> - return drm_platform_init(&sti_driver, to_platform_device(dev));
> + struct drm_device *ddev;
> + int ret;
> +
> + ddev = drm_dev_alloc(&sti_driver, dev);
> + if
Hi Ilia,
Thanks for your answer.
On 16-06-2016 13:39, Ilia Mirkin wrote:
> On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu
> wrote:
>> Hi Daniel,
>>
>> Sorry to bother you again. I promise this is the last time :)
>>
>> On 15-06-2016 11:15, Daniel Vetter wrote:
>>> On Wed, Jun 15, 2016 at 11:48 AM,
On Mon, Jun 20, 2016 at 05:22:55PM +0200, Benjamin Gaignard wrote:
> Like what has been done for connectors add callbacks on encoder,
> crtc and plane to let driver do actions after drm device registration.
>
> Correspondingly, add callbacks called before unregister drm device.
>
> Signed-off-by:
On Fri, Jun 17, 2016 at 06:04:11PM -0400, Lyude wrote:
> Forgot to mention, Ville: if you could get me an example of how to get
> vlv into an infinite loop with these patches I'd appreciate that. I
> haven't been able to reproduce this at all with the Valleyview machine
> I've got here.
Whether it
Hi Dave,
This pull request contains 2 patches adding support for the sii902x
bridge.
Regards,
Boris
The following changes since commit a0877f52035280370707bdefeddc6faa6478b892:
Merge tag 'topic/drm-misc-2016-06-15' of
git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16 05:49:3
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/5a51eb30/attachment-0001.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/868f22e2/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/5c7c5429/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/2d9c444d/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/209ba5da/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/fe71f9f8/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/b5ad2084/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/eb1ba05b/attachment-0001.html>
> gallium and mali are doing the same thing. No idea if that is the
> same thing that i965 does.
Hi,
Quentin did some tests for me, and the results are... not what I would
have expected:
https://phabricator.freedesktop.org/T7475#88454
RadeonSI works like Intel, but Nouveau does the opposite. I think the
Nouveau way is correct by the spec, which makes everyone else (intel,
radeonsi, weston-simple-dmabuf-v4l) get it wrong. Unfortunately, two
wrongs make a right, so when weston-simple-dmabuf-v4l hardcodes Y_INVERT
as set, it'll come out the right way on intel and radeon.
And it is wrong for weston-simple-dmabuf-v4l to set Y_INVERT, that I
believe is clear. It is only there because of the "oops, it's
upside-down" syndrome, AFAIK.
> > After all, using GL with windows and FBOs and stuff you very often find
> > yourself upside down, and I suspect people have got the habit of just
> > flipping it if it does not look right the first time. See e.g. the
> > row-order of data going into glTexImage2D...
> >
> > If the answer is "oops, well, dmabuf import is semantically y-flipping
> > when it should not, but we cannot fix it because that would break
> > everyone", I would be happy with that. I just want confirmation before
> > flipping the flip flag. :-)
So many bugs that accidentally counter each other...
Thanks,
pq
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/4765adc5/attachment.sig>
On Sun, Jun 19, 2016 at 02:31:31PM +0200, Mathias Krause wrote:
> There is only a single user of dma_buf_debugfs_create_file() and that
> one got the function pointer cast wrong. With that one fixed, there is
> no need to have a wrapper for debugfs_create_file(), just call it
> directly.
>
> With
On Sun, Jun 19, 2016 at 02:31:29PM +0200, Mathias Krause wrote:
> The callback function dma_buf_describe() returns an int not void so the
> function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
> also fail when acquiring the mutex gets interrupted so always returning
> 0 in dma_b
On 17 June 2016 at 08:33, Daniel Vetter wrote:
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -522,7 +522,6 @@ static struct drm_driver kms_driver = {
> .preclose = amdgpu_driver_preclose_kms,
> .postclose = amdgpu_driver_postc
On Mon, Jun 20, 2016 at 01:55:57PM +0800, Ying Liu wrote:
> On Mon, Jun 13, 2016 at 10:01 PM, Daniel Vetter wrote:
> > On Mon, Jun 13, 2016 at 05:26:28PM +0800, Ying Liu wrote:
> >> On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote:
> >> > On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wro
ANX7688 is a transmitter to support DisplayPort over USB-C for
smartphone and tablets.
This binding only describes the HDMI to DP component of the chip.
Signed-off-by: Nicolas Boichat
---
.../devicetree/bindings/video/bridge/anx7688.txt | 32 ++
1 file changed, 32 insertio
ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.
The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the
On Fri, Jun 17, 2016 at 05:58:24PM -0400, Lyude wrote:
> Unfortunately, there's two situations where we lose hpd right now:
> - Runtime suspend
> - When we've shut off all of the power wells on Valleyview/Cherryview
>
> While it would be nice if this didn't cause issues, this has the
> ability to
On Mon, Jun 20, 2016 at 12:42:55PM +0100, Chris Wilson wrote:
> On Fri, Jun 17, 2016 at 09:33:27AM +0200, Daniel Vetter wrote:
> > With the previous patch this is now redudant, the core always
> > sets a reasonable dev->unique string.
> >
> > Cc: Sean Paul
> > Signed-off-by: Daniel Vetter
>
> W
(please keep me on Cc, I'm not subscribed to the list)
Hello,
while trying to use the NUC DN2820FYK [1], screen goes black as soon
i915 is loaded. The NUC is connected by HDMI to a 1920x1080 display.
Works normally while on the BIOS (upgraded to the latest one just in
case today) and while on grub
The 100c08 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)
So move the dma_m
Am Freitag, den 17.06.2016, 09:33 +0200 schrieb Daniel Vetter:
> Since
>
> commit e112e593b215c394c0303dbf0534db0928e87967
> Author: Nicolas Iooss
> Date: Fri Dec 11 11:20:28 2015 +0100
>
> drm: use dev_name as default unique name in drm_dev_alloc()
>
> we're using a reasonable default wh
Am Freitag, den 17.06.2016, 12:13 +0200 schrieb Lucas Stach:
> Make sure to leave a clean panel state behind and allow to
> properly attach to the panel again on a rebind.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/imx/imx-ldb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --
Am Freitag, den 17.06.2016, 12:13 +0200 schrieb Lucas Stach:
> Instead let drm_mode_config_cleanup() do the work when taking down
> the master device. This requires all cleanup functions to be
> properly hooked up to the mode object .destroy callback.
>
> Signed-off-by: Lucas Stach
> ---
> drive
Hi Dave,
please consider merging this tag, which contains the v16 MT8173 HDMI
patches I sent on 2016-05-26, rebased onto v4.7-rc2, with two warnings
fixed.
regards
Philipp
The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
a
On Mon, Jun 13, 2016 at 10:01 PM, Daniel Vetter wrote:
> On Mon, Jun 13, 2016 at 05:26:28PM +0800, Ying Liu wrote:
>> On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote:
>> > On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
>> >> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
>> >> wr
Quoting Maxime Ripard (2016-05-16 05:47:02)
> In the current multiplier base clock implementation, if the
> CLK_SET_RATE_PARENT flag isn't set, the code will not make sure that the
> multiplier computed remains within the boundaries of our clock.
>
> This means that if the clock we want to reach i
2016-06-20 Joe Perches :
> On Mon, 2016-06-20 at 12:53 -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Fix paths in the comments.
>
> Why is it useful to have the path or filename embedded
> in the file at
> all?
I just kept it as is. Thinking about this now I don't see
this as
Quoting Maxime Ripard (2016-06-20 01:54:58)
> On Fri, Jun 17, 2016 at 04:05:33PM -0700, Michael Turquette wrote:
> > Quoting Maxime Ripard (2016-05-16 05:47:01)
> > > A fixed factor clock, if it needs to change its rate, by definition do not
> > > have any choice but to modify its parent rate.
> >
From: Gustavo Padovan
Sync Framework was de-staged to drivers/dma-buf/, so remove it entries
in the TODO file.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/TODO | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
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
Fix paths in the comments.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync_debug.c | 2 +-
drivers/staging/android/sync_debug.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/a
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/{trace/sync.h
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
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
---
drivers/staging/android/sw_sync.c| 16
dri
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 3 patches are clean up and improvements and the rest is preparation
to de-stage and then finally the actual de-st
2016-06-17 12:42 GMT+02:00 Lucas Stach :
> The GPU init path now reports any errors which might occur more accurately
> than what is possible with the generic "something failed" message.
>
> Remove the generic reporting, so we don't log an error into dmesg anymore
> if any of the GPU cores are igno
2016-06-17 12:42 GMT+02:00 Lucas Stach :
> Print error messages that mention the exact cause of the failure on
> all paths which may fail the GPU init.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 --
> 1 file changed,
On Fri, Jun 17, 2016 at 09:33:27AM +0200, Daniel Vetter wrote:
> With the previous patch this is now redudant, the core always
> sets a reasonable dev->unique string.
>
> Cc: Sean Paul
> Signed-off-by: Daniel Vetter
Will this fix:
[ 4442.886507]
===
So far, we were missing to send the vblank event when disabling the CRTC,
making us never report the last vblank event.
This was causing a time out on the page flip, which should be solved now.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 8
1 file changed, 8 i
The sun4i display engine doesn't have any vblank counter. Use the proper
helper for that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
On 17/06/16 17:45, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Fri, Jun 17, 2016 at 05:30:54PM +0100, Mark Rutland wrote:
>> On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote:
>>> The I2C driver core for boards using device-tree assumes any subnode of
>>> an I2C adapter
From: Guodong Xu
Add select HISI_KIRIN_DW_DSI to Kconfig.
The DRM driver depends on dsi sub-driver.
Signed-off-by: Zoltan Kuscsik
---
drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
b/drivers/gpu/drm/hisilicon
.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/e572dabb/attachment.html>
On 17/06/16 17:37, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Fri, Jun 17, 2016 at 01:03:44PM +0100, Jon Hunter wrote:
>> The DPAUX pins are shared with an internal I2C controller. To allow
>> these pins to be muxed to the I2C controller, register a pinctrl device
>> for the DP
Hi,
On 17 June 2016 at 16:25, Chris Wilson wrote:
> Up to now, the recommendation was for drivers to call drm_dev_register()
> followed by drm_connector_register_all(). Now that
> drm_connector_register() is safe against multiple invocations, we can
> move drm_connector_register_all() to drm_dev_
https://bugzilla.kernel.org/show_bug.cgi?id=120591
--- Comment #7 from Dmitrii Tcvetkov ---
Thank you for advice, I've sent the patch, mail awaits moderation.
--
You are receiving this mail because:
You are watching the assignee of the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/a42735c2/attachment.html>
Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.
Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git
And video mode setting is from dsi-panel-jdi-d
Provide a small convenience wrapper that set/get the
display brightness value
Cc: John Stultz
Cc: Sumit Semwal
Cc: Archit Taneja
Cc: Rob Clark
Cc: Jani Nikula
Cc: Thierry Reding
Signed-off-by: Vinay Simha BN
---
v1:
*tested in nexus7 2nd gen.
v2:
* implemented jani review comments
-fu
1 - 100 of 133 matches
Mail list logo
