>
> So we leak all dynamically created objects? There's no
> kfree(intel_connector) here and we cannot add it because
> drm_mode_object_find() is not ref-counted. So we keep the connector in
> the mode_group and wait until the final drm_mode_config_cleanup()? But
> drm_connector_cleanup() already r
Thank you for advice.
I will send a fixed patch soon.
> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Tuesday, May 13, 2014 5:45 PM
> To: gioh.kim
> Cc: Sumit Semwal; Randy Dunlap; linux-media at vger.kernel.org; dri-devel at
> lists.freedesktop.or
Update some descriptions for API arguments and descriptions.
Signed-off-by: Gioh Kim
---
Documentation/dma-buf-sharing.txt | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 505e711..aa
https://bugzilla.kernel.org/show_bug.cgi?id=67681
Aaron Lu changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
Assignee|aaron.lu at intel.
https://bugzilla.kernel.org/show_bug.cgi?id=74551
--- Comment #5 from maxis11 ---
(In reply to Alex Deucher from comment #4)
> (In reply to maxis11 from comment #3)
> >
> > system steel freezes during boot (using kernel 3.15-rc5 from git).
>
> Are you specifying a runpm setting or just a boot w
s.freedesktop.org/archives/dri-devel/attachments/20140514/35e93d0a/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/e60e883a/attachment.html>
Hi
On Wed, May 14, 2014 at 2:03 AM, Dave Airlie wrote:
> Since any objects you get with find are only valid under mode_config.mutex,
> yes some drivers mess this up, but they should be fixed.
Didn't know that we have such a rule. Then it's fine, of course. The
page-flip code is what worried me,
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked
This configuration could be used in MIPI DSI command mode also.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
This patch adds DT bindings for command mode display timing.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../bindings/video/cmdmode-display-timing.txt | 64
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree
To support MIPI DSI command mode interface, the panel should generates
Tearing Effect synchronization signal between MCU and FB to display
video images.
And the display controller should trigger to transfer video image at
this signal.
So the panel receives the TE IRQ, then calls this handler chains
This patch adds relevant to exynos5420 compatible for exynos5420 SoC support.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/video/exynos_dsim.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/de
This patch adds relevant to exynos5 compatible for exynos5 SoCs.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/arm/samsung/sysreg.txt |1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/sy
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-
This patch adds sysreg property to fimd device node which is required
to use I80 interface.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 570 +
Hi,
This series is for the Exynos DRM driver to support MIPI DSI command mode
display and based on exynos-drm-next branch.
The previous patches,
RFC: http://www.spinics.net/lists/dri-devel/msg58898.html
Patches 1 and 2 fix trivial bugs.
Patches 3 and 4 introduce command mode and command mode di
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
ind
This patch is based on videomode and display_timing relevant codes.
To support command mode panel, it does not need to guide its timing
information to the display controller like video mode panel,
but it requires signal timings to transfer video data.
So this patch adds cmdmode struct, cmdmode_disp
This patch adds helper functions to convert cmdmode
to drm_display_mode
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_modes.c | 59 +++
include/drm/drm_modes.h | 12 +
2 files changed, 71 i
To support MIPI DSI command mode interface, FIMD should do followings:
- Sets LCD block configuration for I80 interface.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Implements trigger feature which transfers image date if there is
page flip request, and implements T
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45
1 file changed
In case of using MIPI command mode interface panel,
the relevant registers should be set.
So this patch adds relevant DT bindings.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/video/samsung-fimd.txt |2 ++
1 file changed, 2 insertio
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/bo
This patch adds mipi-phy node for MIPI-DSI device.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
in
To support command mode interface, the DSI host calls this handler
to notify the panel tearing effect synchronization signal to the
CRTC device manager to trigger to transfer video image.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_d
https://bugzilla.kernel.org/show_bug.cgi?id=67681
--- Comment #26 from 3fdd1e5d at opayq.com ---
Well not according to what I'm reading and understanding here, this is suppose
to be I thought from asus wmi?
CONFIG_ASUS_NB_WMI:
This is a driver for newer Asus notebooks. It adds extra features
lik
https://bugzilla.kernel.org/show_bug.cgi?id=67681
--- Comment #27 from 3fdd1e5d at opayq.com ---
I thought I mentioned this before, but Nvidia uses a driver for Windows to
control this, it doesn't come from Nvidia.
You can actually see that the F keys have an Asus ROG logo themed popup display
i
https://bugzilla.kernel.org/show_bug.cgi?id=67681
--- Comment #28 from 3fdd1e5d at opayq.com ---
E TYPO before;
I thought I mentioned this before, but "ASUS" uses a driver for windows...
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 05.05.2014 18:27, Michel D?nzer wrote:
> On 02.05.2014 22:29, Christian K?nig wrote:
>> Am 02.05.2014 09:25, schrieb Michel D?nzer:
>>>
>>> and asynchronous flips (not synchronized to vertical blank).
>> Actually that's one of the things I've implement in 3.15 by using the
>> pflip interrupt. Al
On Wed, May 14, 2014 at 08:05:11AM +0200, David Herrmann wrote:
> Hi
>
> On Wed, May 14, 2014 at 2:03 AM, Dave Airlie wrote:
> > Since any objects you get with find are only valid under mode_config.mutex,
> > yes some drivers mess this up, but they should be fixed.
>
> Didn't know that we have s
On Tue, 13 May 2014, Chris Wilson wrote:
> i915.ko has a custom fbdev initialisation routine that aims to preserve
> the current mode set by the BIOS, unless overruled by the user. The
> user's wishes are determined by what, if any, mode is specified on the
> command line (via the video= parameter
https://bugzilla.kernel.org/show_bug.cgi?id=76131
Bug ID: 76131
Summary: Regression: Wake up after suspend broken with Radeon
R7 260x (BONAIRE, radeonsi)
Product: Drivers
Version: 2.5
Kernel Version: 3.15.0-rc5+ (commit
https://bugzilla.kernel.org/show_bug.cgi?id=76131
Felix Homann changed:
What|Removed |Added
CC||linuxaudio at showlabor.de
Regress
On Wed, May 14, 2014 at 11:31:47AM +0300, Jani Nikula wrote:
> On Tue, 13 May 2014, Chris Wilson wrote:
> > i915.ko has a custom fbdev initialisation routine that aims to preserve
> > the current mode set by the BIOS, unless overruled by the user. The
> > user's wishes are determined by what, if a
https://bugzilla.kernel.org/show_bug.cgi?id=76131
Christian K?nig changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=76131
--- Comment #2 from Felix Homann ---
The proposed patch https://bugzilla.kernel.org/attachment.cgi?id=135881 doesn't
fix the issue on my machine.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=76131
--- Comment #3 from Christian K?nig ---
Then please bisect what commit broke it for you.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Am 13.05.2014 21:47, schrieb Marek Ol??k:
> For the patch:
>
> Reviewed-by: Marek Ol??k
>
> It would be clearer if alt_domain was renamed to allowed_domains.
Yeah, already had the same idea. Going to rename "domain" to
"prefered_domains" and "alt_domain" to "allowed_domains" for 3.16.
Thanks,
C
https://bugzilla.kernel.org/show_bug.cgi?id=76131
--- Comment #4 from Felix Homann ---
I'll do (*). But bisecting will not be that easy as the R7 260x is mostly
broken on 3.14.x anyway, see
https://bugzilla.redhat.com/show_bug.cgi?id=1094153 and the corresponding
report on freedesktop.org. The bi
https://bugzilla.kernel.org/show_bug.cgi?id=76131
--- Comment #5 from Felix Homann ---
OK, 3.14.x kernels will resume fine if I suspend before the screen freezes.
--
You are receiving this mail because:
You are watching the assignee of the bug.
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/31ca8d1c/attachment.html>
lds/linux.git/commit/?id=277babc374f6ecab6af182554f5d9f35a7768755
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/f6
Crap, any chance you can narrow it down a bit more?
I've just tried a piglit quick test on my Bonaire and it seems to work
perfectly fine.
What hw do you test on?
Regards,
Christian.
Am 13.05.2014 23:21, schrieb Marek Ol??k:
> Hi Christian,
>
> Even though some regressions are fixed by these p
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/a5d3d309/attachment.html>
Hi all -
This series stores connector/encoder names in the relevant structs to
make the name getters thread safe.
What say you, is the wasted memory too high a price to pay for the
thread safety and implementation simplicity of this approach? I think
making drm_get_connector_name and drm_get_enco
This makes drm_get_connector_name() thread safe.
Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3 at
DC1-MBX-01.ptsecurity.ru
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c | 36
include/drm/drm_crtc.h | 2 ++
2 files chan
This makes drm_get_encoder_name() thread safe.
Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3 at
DC1-MBX-01\
.ptsecurity.ru
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c | 31 +--
include/drm/drm_crtc.h | 2 ++
2 files changed,
On Wed, May 14, 2014 at 04:58:18PM +0300, Jani Nikula wrote:
> Hi all -
>
> This series stores connector/encoder names in the relevant structs to
> make the name getters thread safe.
>
> What say you, is the wasted memory too high a price to pay for the
> thread safety and implementation simplici
The EDT ETM0700G0DH6 is a 7" 800x480 panel, which can be
supported by the simple panel driver.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu
filtering state setup
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/11dff6c2/attachment-0001.html>
On Tue, May 13, 2014 at 11:31:07PM +0200, Thierry Reding wrote:
> A different solution, which seems to be fairly common for DRM drivers
> for SoCs, is to instantiate a dummy device so that the DRM driver can
> bind to it. This can happen in two forms: add the dummy device directly
> in device tree
On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
> > On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Some drivers, such as graphics drivers in the DRM subsyst
ddenly be any more convinced by this
solution than by your prior proposal? I didn't say outright no to what
you proposed earlier. What I said was that I didn't like it and that I
thought we could come up with a better solution. Part of getting to a
better solution is trying to understand the problems involved. You don't
solve a problem by simply moving code into a different driver.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/6d0ed490/attachment.sig>
This series depends on the previously posted reservation api patches.
2 of them are not yet in for-next-fences branch of
git://git.linaro.org/people/sumit.semwal/linux-3.x.git
The missing patches are still in my vmwgfx_wip branch at
git://people.freedesktop.org/~mlankhorst/linux
All ttm drivers a
It seems some drivers really want this as a parameter,
like vmwgfx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c |2 +-
drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
drivers/gpu/drm/radeon/radeon_vm.c
This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.
This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c |1
drivers
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst
---
driv
This will ensure we always hold the required lock when calling those functions.
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 17 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouve
This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/tt
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++---
drivers/gpu/drm/nouveau/nouveau_display.c |6 --
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/core/event.c |4
drivers/gpu/drm/nouveau/nouveau_bo.c |6
drivers/gpu/drm/nouveau/nouveau_display.c |4
drivers/gpu/drm/nouveau/nouveau_fence.c | 434 -
d
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h| 15 +--
drivers/gpu/drm/radeon/radeon_device.c |1
drivers/gpu/drm/radeon/radeon_fence.c | 189 +---
3 files changed, 153 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm
Final driver! \o/
This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/Makefile |2
drivers/gpu/drm/qxl/qxl_cmd.c |5 -
drivers/gpu/drm/qxl/qxl_debugfs.c |
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 ++---
drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 -
4 files changed, 200 inser
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +---
drivers/gpu/drm/nouveau/nouveau_fence.h |2
drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++-
drivers/gpu/drm/qxl/qxl_debugfs.c|6 +
drivers/gpu/drm/qxl/qxl_drv
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d09650c1d720..7ba883843668 100644
--- a/drivers/gpu/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 20a1a866ceeb..79e950df3018 100644
--- a
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 76 +++---
1 file changed, 13 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31c4a6dd722d..6fe1f4bf37ed 100644
--- a/drivers/gp
access to
host1x via the parent device.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/2c2e9e59/attachment.sig>
> + /* did fence get signaled after we enabled the sw irq? */
> + if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
> fence->seq) {
> + radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring);
> + return false;
> + }
> +
> + fence->fence_wake.f
need to have an "atomic" color manager
property since there will be a mechanism to atomically apply any number
of properties.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/e728469c/attachment.sig>
On Wed, 14 May 2014, Chris Wilson wrote:
> On Wed, May 14, 2014 at 04:58:18PM +0300, Jani Nikula wrote:
>> Hi all -
>>
>> This series stores connector/encoder names in the relevant structs to
>> make the name getters thread safe.
>>
>> What say you, is the wasted memory too high a price to pay f
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/89ca5175/attachment.html>
On Wed, May 14, 2014 at 04:37:19PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
> > > On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
> > > > From: Thierry Reding
On Mon, May 5, 2014 at 11:19 AM, Daniel Vetter
wrote:
> Hi Dave,
>
> Update pull request with drm core patches. Mostly some polish for the
> primary plane stuff and a pile of patches all over from Thierry. Has
> survived a few days in drm-intel-nightly without causing ill.
>
> I've frobbed my scr
r pattern?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/2cd86462/attachment-0001.sig>
Hi all,
This is Ville's vblank rework series, slightly pimped. I've added kerneldoc,
some polish and also some additional nasty igt testcases for these crtc on/off
vs vblank issues. Seems all to hold together nicely.
Now one thing I wanted to do is roll this out across all drm drivers, but that
l
From: Peter Hurley
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/driv
From: Ville Syrj?l?
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
From: Ville Syrj?l?
If there's a blocking vblank wait in progress while the vblank interrupt
gets disabled, the current code will just let the vblank wait time out.
Instead make it return immediately when vblank interrupts get disabled.
Signed-off-by: Ville Syrj?l?
Signed-off-by: Daniel Vetter
From: Ville Syrj?l?
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during
Originally these functions have been for user modesetting drivers to
ensure vblank processing doesn't fall over completely around modeset
changes. This has been carried over ever since then.
Now that Ville cleaned our vblank handling with an explicit
drm_vblank_off/on braket when disabling/enablin
Leftover from the old days of ums and should be used any longer. Since
commit 29935554b384b1b3a7377d6f0b03b21d18a61683
Author: Laurent Pinchart
Date: Wed May 30 00:58:09 2012 +0200
drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
it is a complete no-Op for kms drivers.
Cc: Laurent Pin
- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
comments explaining when drm_vblank_pre|post_modesets shouldn't be
used.
- General polish and OCD.
Signed-off-by: Daniel Vetter
---
Docum
We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c| 81
d
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
This essentially undoes
commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
Author: Paulo Zanoni
Date: Tue Jul 23
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms
If we want to use this functionality in generic helpers to make
sure that all drivers have somewhat sane vblank handling across
modesets/dpms, we need to make it work for all drivers. But some
don't support interrupts and hence also not vblank waits.
Just return early on such drivers.
Note that w
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
This essentially undoes
commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
Author: Paulo Zanoni
Date: Tue Jul 23
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms
If we want to use this functionality in generic helpers to make
sure that all drivers have somewhat sane vblank handling across
modesets/dpms, we need to make it work for all drivers. But some
don't support interrupts and hence also not vblank waits.
Just return early on such drivers.
Note that w
It literally took us years in i915 to track down all the vblank
bogosity, which means that userspace has now code to deal with random
crap like stuck vblank waits, needless counter wraps and other
hilarity.
To make sure that all drivers are at least somewhat sane enforce
minimal standards in the c
On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> From: Ville Syrj?l?
>
> drm_vblank_off() will turn off vblank interrupts, but as long as the
> refcount is elevated drm_vblank_get() will not re-enable them. This
> is a problem is someone is holding a vblank reference while a modes
On Wed, 2014-05-14 at 20:51 +0200, Daniel Vetter wrote:
> We don't have hardware based disable bits on gmch platforms, so need
> to block spurious underrun reports in software. Which means that we
> _must_ start out with fifo underrun reporting disabled everywhere.
>
> This is in big contrast to i
Hi Rahul, Tomasz,
On 14.05.2014 21:17, Rahul Sharma wrote:
> From: Tomasz Stanislawski
>
> Add exynos-simple-phy driver to support a single register
> PHY interfaces present on Exynos4 SoC.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Rahul Sharma
>
> ---
> .../devicetree/binding
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to autodetect devices when
1 - 100 of 115 matches
Mail list logo
