On Tue, 07 Mar 2017, Javi Merino wrote:
> On Tue, Mar 07, 2017 at 06:16:51PM +0200, Jani Nikula wrote:
>> On Mon, 06 Mar 2017, Javi Merino wrote:
>> > I found these two minor issues while building an EDID. I'm not sure
>> > whether the second patch (Add O= to support) is upstream material, but
>
On Tue, 07 Mar 2017, Maxime Ripard wrote:
> I just rebased my tree on top of the latest drm-misc tag
> (drm-misc-next-2017-03-06). It should compile, and not have merge
> conflicts anymore.
Conflicts happen. Rebasing should not be the standard operating
procedure for fixing them.
BR,
Jani.
--
On Wed, 08 Mar 2017, Sean Paul wrote:
> On Tue, Mar 07, 2017 at 09:35:11PM +0100, Tomeu Vizoso wrote:
>> Gabriel Krisman reported these warnings when building the documentation:
>>
>> ./drivers/gpu/drm/drm_dp_helper.c:1165: warning: No description found
>> for parameter 'crtc'
>> ./drivers/gpu/d
On Wed, 08 Mar 2017, Jani Nikula wrote:
> On Wed, 08 Mar 2017, Sean Paul wrote:
>> On Tue, Mar 07, 2017 at 09:35:11PM +0100, Tomeu Vizoso wrote:
>>> Gabriel Krisman reported these warnings when building the documentation:
>>>
>>> ./drivers/gpu/drm/drm_dp_helper.c:1165: warning: No description f
On Wed, Mar 08, 2017 at 12:25:59PM +0800, Chen-Yu Tsai wrote:
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> wrote:
> > It seems like what's called a backporch in the datasheet is actually the
> > backporch plus the sync period. Fix that in our driver.
> >
> > Signed-off-by: Maxime Ripard
> >
Hi Julian,
On Tue, Mar 07, 2017 at 09:21:19PM +1100, Julian Calaby wrote:
> Hi Maxime,
>
> On Tue, Mar 7, 2017 at 7:56 PM, Maxime Ripard
> wrote:
> > The video PLLs are used directly by the HDMI controller. Export them so
> > that we can use them in our DT node.
> >
> > Signed-off-by: Maxime Rip
Hi David, Inki,
Thanks for reporting.
On 06.03.2017 11:05, David Binderman wrote:
> Hello there,
>
> linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681]: (warning)
> Result of operator '|' is always true if one operand is non-zero. Did you
> intend to use '&'?
>
> Source code is
>
very old qxl hardware revisions (predating qxl ksm support by a few
years) supported a fixed list of video modes only. The list is still
provided by the virtual hardware, for backward compatibility reasons.
The qxl kms driver never ever looks at it, except for dumping it to
the kernel log at load
Try to read the client monitors config at driver load time, even without
explicit notification. So in case that info was filled before the driver
loaded and we've missed the notifications because of that the settings
will still be used.
With that place we now have to take care to properly handle
Call qxl_add_monitors_config_modes() unconditionally. Do all sanity
checks in that function.
Fix sanity checks. monitors_config is the current monitor
configuration, whereas client_monitors_config is the configuration
requested by the spice client. So when filling the mode list, based on
the sp
When reading the monitor config fails, don't retry forever. If it fails
ten times in a row just give up to avoid the driver hangs. Also add a
small delay after each attempt, so the host has a chance to complete a
partial update.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.
Hi Jani,
On Wed, Mar 08, 2017 at 10:41:37AM +0200, Jani Nikula wrote:
On Wed, 08 Mar 2017, Jani Nikula wrote:
On Wed, 08 Mar 2017, Sean Paul wrote:
On Tue, Mar 07, 2017 at 09:35:11PM +0100, Tomeu Vizoso wrote:
Gabriel Krisman reported these warnings when building the documentation:
./driv
On 03/07/2017 06:35 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 07-03-2017 16:42, Neil Armstrong wrote:
>> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
>> Controller, this patch takes the pixel format from the plat_data if provided.
>>
>> Signed-off-by: Neil Armstrong
On Wed, Mar 08, 2017 at 10:26:54AM +0200, Jani Nikula wrote:
> On Tue, 07 Mar 2017, Maxime Ripard wrote:
> > I just rebased my tree on top of the latest drm-misc tag
> > (drm-misc-next-2017-03-06). It should compile, and not have merge
> > conflicts anymore.
>
> Conflicts happen. Rebasing should
On Wed, Mar 08, 2017 at 08:45:13AM +0100, Gerd Hoffmann wrote:
> On Di, 2017-03-07 at 21:49 +0100, Noralf Trønnes wrote:
> > drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> > automatically, so it's not necessary to call
> > drm_debugfs_remove_files().
> >
> > Cc: airl...@linux.
On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/linux/resource_ext.h:19:0,
> from include/linux/pci.h:32,
>
https://bugs.freedesktop.org/show_bug.cgi?id=100109
Bug ID: 100109
Summary: Graphics Lockup if monitor disconnected and then set
into standby
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Hi Jose,
On 03/07/2017 06:12 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 07-03-2017 16:42, Neil Armstrong wrote:
>> From: Laurent Pinchart
>>
>> In preparation for adding PHY operations to handle RX SENSE and HPD,
>> group all the PHY interrupt setup code in a single location and extract
>> it to
https://bugs.freedesktop.org/show_bug.cgi?id=100109
--- Comment #1 from Kieran Grant ---
I just tried to quickly reproduce the problem using timer delayed xset usage
and turning off monitor and unplugging it... but no oops and no graphics stack
corruption... (Well... at least *that* is good news)
On Tue, Mar 07, 2017 at 09:49:23PM +0100, Noralf Trønnes wrote:
> Remove the .debugfs_cleanup() callback now that all the users are gone.
>
> Signed-off-by: Noralf Trønnes
First 2 patches merged to drm-misc, with Rob's irc ack on the first one.
I'll leave the 3rd for Gerd.
Thanks, Daniel
> ---
On 07.03.2017 10:14, Inki Dae wrote:
>
> 2017년 02월 23일 01:05에 Andrzej Hajda 이(가) 쓴 글:
>> DECON in case of video mode generates interrupt by default at start
>> of vertical back porch. As this interrupt is used to generate VBLANK
>> events more optimal point is start of vertical front porch.
>>
>> S
On Wed, Mar 08, 2017 at 06:01:54AM +0100, Lukas Wunner wrote:
> On Tue, Mar 07, 2017 at 03:30:30PM -0500, Alex Deucher wrote:
> > On Fri, Feb 24, 2017 at 2:19 PM, Lukas Wunner wrote:
> > > An external Thunderbolt GPU can neither drive the laptop's panel nor be
> > > powered off by the platform, so
This adds the the devicetree binding for the Prefetch Resolve Gasket,
as found on i.MX6 QuadPlus.
The PRG is fairly simple in that it only has a configuration register
range and two clocks, one for the AHB slave port and one for the AXI
ports and the functional units.
The PRE connections need to b
This adds support for the i.MX6 QuadPlus PRE units. Currently only
linear prefetch into SRAM is supported, other modes of operation
like the tiled-to-linear conversion will be added later.
Signed-off-by: Lucas Stach
---
v2:
- adopt to changed DT binding
- change name of the lookup functions as su
The i.MX6 QuadPlus IPU needs to PRG unit to gain access to the
data bus. Make sure it is present and available to be used.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-common.c | 11 ++-
drivers/gpu/ipu-v3/ipu-prv.h| 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
di
The Prefetch Resolve Engine is a prefetch and tile resolve engine
which prefetches display data from DRAM to an internal SRAM region.
It has a single clock for configuration register access and the
functional units. A single shared interrupt is used for status and
error signaling.
The only externa
Using non-zero AXI IDs for anything other than the display channels
collides with the PRG AXI snooping, so only do this if there is no
PRG present.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/driv
This adds support for the i.MX6 QUadPlus PRG unit. It glues together the
IPU and the PRE units.
Signed-off-by: Lucas Stach
---
v2: change name of the lookup function as suggested by Philipp
---
drivers/gpu/ipu-v3/Makefile | 2 +-
drivers/gpu/ipu-v3/ipu-prg.c | 418
On i.MX6 QuadPlus the PRG needs to be clocked in order to pass
through the data access requests from the IDMAC. This call is a
no-op for other all other SoCs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx
Document the valid compatible strings for the IPUv3.
On i.MX6 QuadPlus the IPU needs to know which PRG has to be
used for this IPU instance. Add a "fsl,prg" property containing
a phandle pointing to the correct PRG device.
Signed-off-by: Lucas Stach
---
Documentation/devicetree/bindings/display
Allow the planes to use the PRG/PRE units as linear prefetchers when
possible. This improves DRAM efficiency a bit and reduces the chance
for display underflow when the memory subsystem is under load.
This does not yet support scanning out tiled buffers directly, as this
needs more work, but it al
https://bugzilla.kernel.org/show_bug.cgi?id=62541
--- Comment #4 from Jani Nikula (jani.nik...@intel.com) ---
(In reply to Szőgyényi Gábor from comment #3)
> Please try to reproduce this bug with latest kernel image & latest systemd.
Sorry, what's the point? If you're scrubbing the bugs here, ple
https://bugzilla.kernel.org/show_bug.cgi?id=88861
--- Comment #26 from Jani Nikula (jani.nik...@intel.com) ---
*** Bug 194697 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Mi, 2017-03-08 at 10:52 +0100, Daniel Vetter wrote:
> On Wed, Mar 08, 2017 at 08:45:13AM +0100, Gerd Hoffmann wrote:
> > On Di, 2017-03-07 at 21:49 +0100, Noralf Trønnes wrote:
> > > drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> > > automatically, so it's not necessary to c
printks are slow so we should not be doing them from the vblank evade
critical section. These could explain why we sometimes seem to
blow past our 100 usec deadline.
The problem has been there ever since commit bfd16b2a23dc ("drm/i915:
Make updating pipe without modeset atomic.") but it may not ha
On 03/07/2017 06:35 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 07-03-2017 16:42, Neil Armstrong wrote:
>> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
>> Controller, this patch takes the pixel format from the plat_data if provided.
>>
>> Signed-off-by: Neil Armstrong
Den 07.03.2017 23.21, skrev Daniel Vetter:
On Sat, Feb 11, 2017 at 07:48:52PM +0100, Noralf Trønnes wrote:
+const struct file_operations tinydrm_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release= drm_release,
+ .unlocked_ioctl = d
On Wed, Mar 08, 2017 at 11:46:33AM +0100, Peter Wu wrote:
> On Wed, Mar 08, 2017 at 06:01:54AM +0100, Lukas Wunner wrote:
> > On Tue, Mar 07, 2017 at 03:30:30PM -0500, Alex Deucher wrote:
> > > On Fri, Feb 24, 2017 at 2:19 PM, Lukas Wunner wrote:
> > > > An external Thunderbolt GPU can neither dri
Loosely based on commit f0a42bb5423a ("drm/msm: submit support for
in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have
a flags field yet, so we have to extend the structure and trust that
drm_ioctl will clear the flags for us if an older userspace only submits
part of the struct.
The next patch will need the dma_fence to create the sync_file in
etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +++-
drivers/gpu/drm/et
Based on commit 4cd0945901a6 ("drm/msm: submit support for out-fences").
We increment the minor driver version so userspace can detect explicit
fence support.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 27
On Wed, Mar 08, 2017 at 01:00:07PM +0100, Maarten Lankhorst wrote:
> printks are slow so we should not be doing them from the vblank evade
> critical section. These could explain why we sometimes seem to
> blow past our 100 usec deadline.
>
> The problem has been there ever since commit bfd16b2a23
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Re
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashan
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modese
Op 08-03-17 om 14:12 schreef Ville Syrjälä:
> On Wed, Mar 08, 2017 at 01:00:07PM +0100, Maarten Lankhorst wrote:
>> printks are slow so we should not be doing them from the vblank evade
>> critical section. These could explain why we sometimes seem to
>> blow past our 100 usec deadline.
>>
>> The p
Hi all,
So I looked at drmP.h, thought "this is small, should finally be doable to split
it all into sensible pieces and document things".
Yes that joke was on me, only managed to do a few random things and then split
out drm_file related things. Plus clean those up and give the docs a fresh-up.
And remove the semi-kernel-doc stuff, to make sure no one uses this.
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 15 ---
include/drm/drm_auth.h | 17 +
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP
At least radeon, amdgpu and nouveau should be converted. We have
patches for i915 already.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index ce0f1a588e7f..63
An easy one as a drive-by.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_kms_helper_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index 45db36cd3d20..6e35a56a6102 100644
---
Worst case if the hw can't support completion signalling in a
race-free way we want the event to be too late, not too early.
Text adapted from a proposal from Laurent - the other side of how to
make hw work correctly where it's possible is imo already sufficiently
documented.
v2: Review from Laur
Plus a little bit more documentation.
v2: Untangle the missing forward decls to make drm_prime|gem.h
free-standing.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-mm.rst | 3 ++
drivers/gpu/drm/drm_prime.c | 3 +-
include/drm/drmP.h| 32 ++
include/drm/d
I'm torn on whether drm_minor really should be here or somewhere else.
Maybe with more clarity after untangling drmP.h more this is easier to
decide, for now I've put a FIXME comment right next to it. Right now
we need struct drm_minor for the inline drm_file type helpers, and so
it does kinda make
This was originally added by David Herrmann for range checks, but
entirely unused. It confused me, so let's remove it.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 82610178
Just another step in finally making drmP.h obsolete.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 7 +
include/drm/drmP.h| 43 +++---
include/drm/drm_pci.h | 78 +++
3 files changed, 89 insertions(+)
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/ms
There's really not a reason afaics that we can't just clean up
everything at the end, in the terminal postclose hook: Since this is
closing a file descriptor we know no one else can have a reference or
a thread doing something with that drm_file except the close code.
Ordering shouldn't matter, as
Well, mostly drm_file.h, and clean up all related things:
- I didnt' figure out the difference between preclose and postclose.
The existing explanation in drm-internals.rst didn't convince me,
since it's also really outdated - we clean up pending DRM events in
the core nowadays. I put a FIXM
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/rad
We might as well dump the drm_file pointer, that's about as useful
a cookie as the pid. Noticed while typing docs for drm_file and friends.
Since the only consumer of this is the tracepoints I think we can safely
change this - those tracepoints should not be uapi relevant at all. It
all goes back
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm
The core takes care of handling the send_event vs. close() issues, we
can remove that driver code.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 12 +++-
drivers/gpu/drm/msm
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 4 ++--
1 file changed, 2
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu
It's not just file ops, but drm_file stuff in general. This is prep
work to extracting a drm_file.h header in the next patch.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-internals.rst| 4 ++--
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/{drm_fops.c => dr
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exyn
Hi
On Wed, Mar 8, 2017 at 3:12 PM, Daniel Vetter wrote:
> This was originally added by David Herrmann for range checks, but
> entirely unused. It confused me, so let's remove it.
>
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 1 -
> 1 file changed, 1 deletio
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +--
Less code ftw.
This converts all drivers except the tinydrm helper module. That one
needs more work, since it gets the THIS_MODULE reference from
tinydrm.ko instead of the actual driver module like it should.
Probably needs a similar trick like I used here with generating the
entire struct with a
With all drivers converted there's only legacy dri1 drivers using it.
Not going to touch those, instead just hide it like we've done with
other dri1 driver hooks like firstopen.
In all this I didn't find any real reason why we'd needed 2 hooks, and
having symmetry between open and close just appea
This did work for me, including stereo 3D, so that is rather disappointing.
(DVI output of the card -> DVI/HDMI adapter -> HDMI Cable -> HDMI TV input)
Is it that HDMI signaling passing through a DVI connector is dis-allowed
on the whole, or is there something more subtle that I am missing?
Would
Sadly there's only 1 driver which can use it, everyone else is special
for some reason:
- gma500 has a horrible runtime PM ioctl wrapper that probably doesn't
really work but meh.
- i915 needs special compat_ioctl handler because regrets.
- arcgpu needs to fixup the pgprot because (no idea why i
I have easy access to an LG 3D television, though I do not have model
information handy at the moment. This is the only display I have tested on
so far.
I have tested all three modes, and in each case the signal is recognized as
3D (the TV pops up a message to this effect), and the content is dis
Hi Philipp,
2017-03-08 Philipp Zabel :
> Loosely based on commit f0a42bb5423a ("drm/msm: submit support for
> in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have
> a flags field yet, so we have to extend the structure and trust that
> drm_ioctl will clear the flags for us if an
Hi Philipp,
2017-03-08 Philipp Zabel :
> The next patch will need the dma_fence to create the sync_file in
> etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.h| 3 ++-
> drivers/gpu/drm/etnaviv
Hi Philipp,
2017-03-08 Philipp Zabel :
> Based on commit 4cd0945901a6 ("drm/msm: submit support for out-fences").
> We increment the minor driver version so userspace can detect explicit
> fence support.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2
Hi Daniel,
2017-03-08 Daniel Vetter :
> Plus a little bit more documentation.
>
> v2: Untangle the missing forward decls to make drm_prime|gem.h
> free-standing.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-mm.rst | 3 ++
> drivers/gpu/drm/drm_prime.c | 3 +-
> include/
Hi Daniel,
Thank you for the patch.
On Wednesday 08 Mar 2017 15:12:39 Daniel Vetter wrote:
> Worst case if the hw can't support completion signalling in a
> race-free way we want the event to be too late, not too early.
>
> Text adapted from a proposal from Laurent - the other side of how to
> m
2017-03-08 Daniel Vetter :
> And remove the semi-kernel-doc stuff, to make sure no one uses this.
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 15 ---
> include/drm/drm_auth.h | 17 +
> 2 files changed, 17 insertions(+), 15 deletions(-)
Reviewed
Reviewed-by: Christian König for this one and
#19.
Christian.
Am 08.03.2017 um 15:12 schrieb Daniel Vetter:
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Alex Deucher
Cc
VBLANK interrupt should be signalled as soon as scanout ends, front porch
is the best moment.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/
DECON in Exynos5433 has frame counter, it can be used to implement
get_vblank_counter callback.
Signed-off-by: Andrzej Hajda
---
v2:
- reuse decon_get_frame_count function already implemented
in previous patch
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12
drivers/gpu
Hi Inki,
This patchset fixes long standing issue with occassional page faults
or vblank event timeouts on TM2 targets due to delayed vblank handling.
DECON driver should now handle properly all scenarios described in drm
docs [1][2], at least it was my intention.
The patchset also:
- adds frame c
DECON in case of video mode generates interrupt by default at start
of vertical back porch. As this interrupt is used to generate VBLANK
events more optimal point is start of vertical front porch.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
include/vide
CRTC event is currently send with next vblank, or instantly in case crtc
is being disabled. This approach usually works, but in corner cases it can
result in premature event generation. Only device driver is able to verify
if the event can be sent. This patch is a first step in that direction - it
All Exynos CRTC drivers shouldn't fail at referencing vblank events,
alternate path is actually dead code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos
Since crtc index is stored in drm_crtc pipe field became redundant.
The patch beside removing the field simplifies also
exynos_drm_crtc_get_pipe_from_type.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +--
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 3
All Exynos CRTCs are fully configured by .enable callback. The only users
of mode_set_nofb actually did nothing in their callbacks - they immediately
returned because devices were in suspend state - mode_set_nofb is always
called on disabled device.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/d
The field duplicates drm_dev->mode_config.num_crtc.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 --
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 11 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
drivers/gpu/drm/exyn
The patch fixes copy/paste bug introduced during code refactoring.
Reported-by: Dan Carpenter
Fixes: b93c2e8b5d9d ("drm/exynos/decon5433: configure sysreg in case of
hardware trigger")Fixes:
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
1 file changed
Current implementation of event handling assumes that vblank interrupt is
always called at the right time. It is not true, it can be delayed due to
various reasons. As a result different races can happen. The patch fixes
the issue by using hardware frame counter present in DECON to serialize
vblank
All Exynos planes are assigned to exactly one CRTC, it allows to simplify
initialization by moving setting of possible_crtcs to exynos_plane_init.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/
Since possible_crtcs are set by Exynos core helper pipe fields have no
raison d'etre. The only place it was used, as a hack, is
fimd_clear_channels, to avoid calling drm_crtc_handle_vblank, but DRM core
has already other protection mechanism (vblank->enabled), so it could be
safely removed.
Signed
2017-03-08 Daniel Vetter :
> Just another step in finally making drmP.h obsolete.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_pci.c | 7 +
> include/drm/drmP.h| 43 +++---
> include/drm/drm_pci.h | 78
> +
2017-03-08 Daniel Vetter :
> An easy one as a drive-by.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_kms_helper_common.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
> b/drivers/gpu/drm/drm_kms_helper_common
1 - 100 of 155 matches
Mail list logo
