On 2017年09月08日 14:12, Mark yao wrote:
On 2017年09月08日 13:04, Heiko Stuebner wrote:
Am Freitag, 8. September 2017, 09:23:09 CEST schrieb Mark yao:
On 2017年09月07日 20:09, Heiko Stübner wrote:
Hi Mark,
Am Donnerstag, 7. September 2017, 18:16:29 CEST schrieb Mark yao:
Looks good for me, so:
Review
On Fri, Sep 08, 2017 at 09:46:02AM +0700, Nhan Nguyen wrote:
> commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.
>
> I've found that by just turning the chip on and off via the
> POWER_DOWN register, I end up getting i2c_transfer errors on
> HiKey.
>
> Investigating further, it turns out
On Fri, Sep 08, 2017 at 02:49:52PM +0800, Chen-Yu Tsai wrote:
> On Fri, Sep 8, 2017 at 2:42 PM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Fri, Sep 08, 2017 at 12:15:45PM +0800, Chen-Yu Tsai wrote:
> >> When binding the TCON, we were checking the reset control status and
> >> asserting reset if it
The TCONs on A31/A31s can select either backend as its input. As there
is no configurable mux in the backend or DRC to redirect their output,
or for the DRC to select an input, the connections are presumably from
the each DRC to each TCON, with the TCON having two input ports, like
the following di
The encoder drivers use drm_of_find_possible_crtcs to get upstream
crtcs from the device tree using of_graph. For the results to be
correct, encoders must be probed/bound after _all_ crtcs have been
created. The existing code uses a depth first recursive traversal
of the of_graph, which means the e
The TCON has a mux to select the source of the data to display.
This mux includes selecting the display backends. On the A31,
which has two display pipelines, this mux can let the TCON
select either backend as its data source. Although the muxing
can be changed on the fly, DRM needs to be able to g
Now that sun4i_tcon_find_engine_traverse() usage is restricted to the
single input case, we can remove the for_each_available_child_of_node
loop.
While at it, consolidate all the of_node_put calls into a common exit
path.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 51 +
The device tree binding for sun4i-drm says:
For all connections between components up to the TCONs in the display
pipeline, when there are multiple components of the same type at the
same depth, the local endpoint ID must be the same as the remote
component's index. For example, if
Hi everyone,
Previously I added support for two display pipelines for the sun4i-drm
driver. At the time we did not have support for downstream encoders to
actually test the second pipeline, nor having both pipelines active at
the same time.
With HDMI encoder support now merged and support for it
The patch b317fa3ba11a ("drm/sun4i: tcon: Find matching display backend
by device node matching") assumed a one-to-one mapping between TCONs
and backends. This turned out wrong, as we found muxing controls in the
TCON of the A31, and undocumented usage of the backend output selector
of the A20.
Ma
When the second display pipeline device nodes for the A31/A31s were
added, it was not known that the TCONs could (through either DRCs)
select either backend as their input. Thus in the endpoints connecting
these components together, the endpoint IDs were set to 0, while in
fact they should have bee
If we want to have vblank on both pipelines at the same time, we need
to call drm_vblank_init with num_crtcs = 2.
Instead, since the crtc init calls correctly set mode_config.num_crtc,
we can move the drm_vblank_init call to after the crtc init code is
called, which is the component bind part. The
commit 6d5104c5a6b56385426e15047050584794bb6254 upstream.
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.
Thus this patch re
commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
HiKey.
Investigating further, it turns out that some of the register
state in hardware is getting lost, as the device
commit 518cb7057a59b9441336d2e88a396d52b6ab0cce upstream.
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.
Digging deeper, I found this was due to the fact that
IRQs were disab
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #12 from Christian König ---
To repeat my question: Does patch "drm/amdgpu: fix moved list handling in the
VM" fix the issue?
Do you guys have this in your kernel branch yet? If not that lockup is
expected.
--
You are receiving th
Hi Mauro,
thanks for your comments. Much appreciated!
> There are also a couple of things here that Sphinx would complain.
> So, it could be worth to rename it to *.rst, while you're writing
> it, and see what:
> make htmldocs
> will complain and how it will look in html.
OK, I'll check th
When binding the TCON, we were checking the reset control status and
asserting reset if it wasn't in reset. The check failed to account for
the reset control API returning error codes if the status callback was
not implemented.
Since we want the TCON to be reset in all cases, use reset_control_res
Op 07-09-17 om 11:49 schreef Daniel Vetter:
> On Mon, Sep 04, 2017 at 12:48:33PM +0200, Maarten Lankhorst wrote:
>> The next commit removes the wait for flip_done in in
>> drm_atomic_helper_commit_cleanup_done, but we need it for the tests
>> to pass. Instead of using complicated vblank tracking wh
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #11 from Peter ---
Well, no problem, just please give me a reliable way to get this info. Listing
the X.org.log, I'm a bit confused.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #13 from Arek Ruśniak ---
Christian sorry, I thought that was clear.
Yes, I updated ASAP so it contains:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.12&id=8bd2cc0ab44b00346cc41f3ac828cbf992f6bc61
Doesn't help f
https://bugs.freedesktop.org/show_bug.cgi?id=102543
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=102543
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Maxime,
On 07/18/17 18:29, Maxime Ripard wrote:
> Hi,
>
> On Tue, Jul 11, 2017 at 11:06:52PM +0200, Hans Verkuil wrote:
>> On 11/07/17 22:39, Maxime Ripard wrote:
>>> On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
From: Hans Verkuil
This patch series adds CEC sup
https://bugs.freedesktop.org/show_bug.cgi?id=99349
--- Comment #19 from Emil Velikov ---
Note that the series adds an extra optimisation pass. As such it's not suitable
for stable. You'll have to use mesa from git until 17.3 is out.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #14 from Christian König ---
(In reply to Arek Ruśniak from comment #13)
> Christian sorry, I thought that was clear.
No problem, that just means that this is the same issue I'm still hunting for.
--
You are receiving this mail b
https://bugzilla.kernel.org/show_bug.cgi?id=192271
fthhi...@emlhub.com changed:
What|Removed |Added
CC||fthhi...@emlhub.com
--- Comment #6
https://bugs.freedesktop.org/show_bug.cgi?id=102543
--- Comment #7 from Chris Wilson ---
(In reply to Martin Peres from comment #6)
> Thanks Chris! I will close this bug.
>
> What about https://bugs.freedesktop.org/show_bug.cgi?id=102249 though? Could
> the patch you sent fix this too?
It's not
On 08/09/17 07:02, Hoegeun Kwon wrote:
> Exynos 5250 and 5420 have different hardware rotation limits. However,
> currently it uses only one compatible - "exynos5-gsc". Since we have
> to distinguish between these two, we add different compatible.
>
> Signed-off-by: Hoegeun Kwon
> ---
> arch/arm
Hi All,
Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot (transparently) rotate in hardware, so we
need to rotate things in software / let user space deal with this.
The fbcon code has a set of DMI based quirks to automatically detect
such tablet
For now this is always set to DRM_MODE_PANEL_ORIENTATION_UNKNOWN
unless there is a dmi based quirk overriding the value.
In the future we should probably provide an initial value based on
the VBT (at least for some panel types).
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_panel.
Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot (transparently) rotate in hardware, so we
need to rotate things in software / let user space deal with this.
The fbcon code has a set of DMI based quirks to automatically detect
such tablet LCD panel
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).
This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to commu
On 08/09/17 07:02, Hoegeun Kwon wrote:
> The gscaler has hardware rotation limits that need to be hardcoded
> into driver. Distinguish them and add them to the property list.
>
> The hardware rotation limits are related to the cropped source size.
> When swap occurs, use rot_max size instead of cr
On Fri, Sep 08, 2017 at 01:54:41PM +0200, Hans de Goede wrote:
> Hi All,
>
> Some x86 clamshell design devices use portrait tablet LCD panels and a
> display engine which cannot (transparently) rotate in hardware, so we
> need to rotate things in software / let user space deal with this.
>
> The
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #15 from Christian König ---
Created attachment 134082
--> https://bugs.freedesktop.org/attachment.cgi?id=134082&action=edit
Possible fix
Please try the attached kernel patch.
--
You are receiving this mail because:
You are the
On Fri, Sep 08, 2017 at 06:22:02PM +0700, Nhan Ngoc. Nguyen wrote:
> This patch is ported from linux stable 4.9, commit
> 3587c856675c45809010c2cee5b21096f6e8e938.
No, commit 3587c856675c45809010c2cee5b21096f6e8e938 showed up in
4.11-rc1:
$ git describe --contains 3587c856675c45809010c2ce
This adds all the main control registers to the debugfs
register file. This was helpful for my debugging so it will
likely help others as well.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- No changes.
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Coll
This replaces the custom connector in the PL111 with the
panel bridge helper.
This works nicely for all standard panels, but since there
are several PL11x-based systems that will need to use the dumb
VGA connector bridge we use drm_of_find_panel_or_bridge()
and make some headroom for dealing with
The header file contains prototypes for two nonexisting
functions. Get rid of them.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- No changes.
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Collect Eric's ACK.
---
drivers/gpu/drm/pl111/pl111_drm.h | 4 -
We detect and enable the use of the PL110 variant, an earlier
incarnation of PL111. The only real difference is that the
control and interrupt enable registers have swapped place.
The Versatile AB and Versatile PB have a variant inbetween
PL110 and PL111, it is PL110 but they have already swapped t
The old codebase has a delay between enabling and powering up the
PL11x.
According to the manual for PL110, ARM DDI 0161E page 1-5 and
the PL111 manual ARM DDI 0293C page 1-6, the power sequence should
be such that once Vdd is stable (which we assume it is at boot)
LCDEN is enabled first and then
The silcon and components around the PL111 may require some
variants to perform special set-up of the display. Add two
callbacks to manage this.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- No changes.
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Reb
The ARM reference designs in the Versatile family: Integrator,
Versatile and RealView can make use of the new DRM driver as well.
We just need to create a bit of platform-specific code for them
that we isolate to its own file.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v
https://bugs.freedesktop.org/show_bug.cgi?id=102616
Chris Wilson changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=102616
--- Comment #4 from Chris Wilson ---
*** Bug 102620 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Chris,
2017-09-07 Chris Wilson :
> Quoting Gustavo Padovan (2017-09-07 20:02:46)
> > From: Dominik Behr
> >
> > To avoid hanging userspace components that might have been waiting on the
> > active fences of the destroyed timeline we need to signal with error all
> > remaining fences on such
Quoting Gustavo Padovan (2017-09-08 14:03:00)
> Hi Chris,
>
> 2017-09-07 Chris Wilson :
>
> > Quoting Gustavo Padovan (2017-09-07 20:02:46)
> > > From: Dominik Behr
> > >
> > > To avoid hanging userspace components that might have been waiting on the
> > > active fences of the destroyed timelin
From: Colin Ian King
The current error handling on devm_kzalloc failures performs a non-null
check on connector. Thss check is redundant because connector is null
at that failure point. With this check removed, we may as well make
the failure path into a trivial -ENOMEM return to clean up the er
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: Maarten Lankhorst
commit 813a7e1604eaad1c2792d37d402e1b48b8d0eb3f upstream.
Make it more clear that post commit return ret is really return 0,
and add a missing drm_atomic_helper_cleanup_plan
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Maarten Lankhorst
commit 813a7e1604eaad1c2792d37d402e1b48b8d0eb3f upstream.
Make it more clear that post commit return ret is really return 0,
and add a missing drm_atomic_helper_cleanup_plan
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 6d5104c5a6b56385426e15047050584794bb6254 upstream.
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent notice
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 518cb7057a59b9441336d2e88a396d52b6ab0cce upstream.
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't h
https://bugs.freedesktop.org/show_bug.cgi?id=102625
Bug ID: 102625
Summary: Game Crashlands crashes on startup
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: norm
Hi,
On Fri, Sep 08, 2017 at 03:50:09PM +0800, Chen-Yu Tsai wrote:
> When the second display pipeline device nodes for the A31/A31s were
> added, it was not known that the TCONs could (through either DRCs)
> select either backend as their input. Thus in the endpoints connecting
> these components t
Hello,
The v2 incorporates the feedback on v1 [1] and rebases the series to master.
We no longer force 32bpp, fix incorrect error handling during plane
initialization, and drom some irrelevant patches.
[1] https://lists.freedesktop.org/archives/dri-devel/2017-August/150703.html
Dominik Behr (1):
From: Varad Gautam
allow reading the drm file from userspace.
Signed-off-by: Varad Gautam
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 69c4e352dd78..452059780ddc 1006
From: Zach Reizner
There is no reliable way of detecting actual VRAM size, which is
important in the case of cirrus because cursor data is always stored in
the last 16K of VRAM. Because qemu effectivaly hardcodes 4MB but reports
32MB, we hardcode 4MB in the cirrus driver to ensure the cursor work
From: Dominik Behr
initialize start and size fields in fb info
so user space drivers like fbdev can map the memory
cherry-pick from 3.14 to 3.18 kernel to let VMtest pass
dmesg now shows proper size and fb start
initially reviewed for chromiumos at:
https://chromium-review.googlesource.com/167
From: Zach Reizner
This patch implements PRIME export, but not import for cirrus.
initially reviewed at:
https://chromium-review.googlesource.com/229688
https://chromium-review.googlesource.com/339057
Signed-off-by: Zach Reizner
Signed-off-by: Stphane Marchesin
Signed-off-by: Varad Gautam
--
From: Varad Gautam
drm_helper_disable_unused_functions should not be called by atomic drivers,
so disable it for later patches.
Signed-off-by: Varad Gautam
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/d
From: Varad Gautam
cirrus exposes one legacy primary plane tied to the crtc. convert this to
use the universal planes interface in preparation for atomic.
v2: avoid early plane cleanup to fix faulty error handling. (krisman)
Signed-off-by: Varad Gautam
Reviewed-by: Gabriel Krisman Bertazi
---
From: Varad Gautam
add a cirrus_bo_unpin call, and move bo_{reserve,unreserve} operations
to bo_{pin,unpin} to ensure correct pinning/unpinning and simplify the call
sequence.
Signed-off-by: Varad Gautam
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 1 +
drivers/gpu/drm/cirrus/cirrus_mode.c | 14
From: Varad Gautam
split the driver to fit into atomic semantics, and switch to using
the atomic transition layer helpers for legacy modesetting.
Signed-off-by: Varad Gautam
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 1 +
drivers/gpu/drm/cirrus/cirrus_main.c | 3 +
drivers/gpu/drm/cirrus/c
From: Varad Gautam
move from transition helpers to actual atomic handlers.
Signed-off-by: Varad Gautam
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gp
From: Varad Gautam
This enables cursor plane on cirrus. It only supports ARGB 8-bit cursors
from userspace, and downconverts them to 1-bit black and white with
masking, which is all cirrus hardware can support. Only cursors with
size 32x32 or 64x64 will work.
initial non-atomic version:
Reviewed
From: Varad Gautam
the hardware does not provide interrupts on vblank, so we just send a fake
vblank event on atomic_flush.
Signed-off-by: Varad Gautam
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/cirrus/cirrus
From: Varad Gautam
allow userspace to use atomic ioctls.
we now pass the following tests when running with cirrus.bpp=32:
igt/kms_atomic_transition:
plane-all-transition
plane-use-after-nonblocking-unbind
plane-all-modeset-transition
plane-toggle-modeset-transition
1x-modeset
On Fri, Sep 8, 2017 at 9:29 PM, Maxime Ripard
wrote:
> Hi,
>
> On Fri, Sep 08, 2017 at 03:50:09PM +0800, Chen-Yu Tsai wrote:
>> When the second display pipeline device nodes for the A31/A31s were
>> added, it was not known that the TCONs could (through either DRCs)
>> select either backend as thei
On Friday, 2017-09-08 14:17:04 +0100, Colin King wrote:
> From: Colin Ian King
>
> The current error handling on devm_kzalloc failures performs a non-null
> check on connector. Thss check is redundant because connector is null
> at that failure point. With this check removed, we may as well make
https://bugs.freedesktop.org/show_bug.cgi?id=102625
ratatosk.yggdra...@googlemail.com changed:
What|Removed |Added
Attachment #134084|0 |1
is obsolete
Hi Colin,
On 8 September 2017 at 14:17, Colin King wrote:
> From: Colin Ian King
>
> The current error handling on devm_kzalloc failures performs a non-null
> check on connector. Thss check is redundant because connector is null
> at that failure point. With this check removed, we may as well m
https://bugs.freedesktop.org/show_bug.cgi?id=102625
--- Comment #2 from ratatosk.yggdra...@googlemail.com ---
Apologies, please ignore the previous gdb output. The error printed there was
transient which was gone after a reboot. I have updated the attached gdb output
which should be more helpful n
From: Colin Ian King
The current error handling when devm_kzalloc fails performs a
non-null check on connector which is redundant because connector
is null at that failure point. Once this is removed, make the
failure path into a trivial -ENOMEM return to clean up the
error handling. Also remove
From: Colin Ian King
The call to kfd_device_by_id can potentially return null, so check that
dev is null and return with -EINVAL to avoid a null pointer dereference.
Detected by CoverityScan CID#1454629 ("Dereference null return value")
Fixes: 5d71dbc3a588 ("drm/amdkfd: Implement image tiling m
https://bugs.freedesktop.org/show_bug.cgi?id=102625
--- Comment #3 from Samuel Pitoiset ---
I bet if you launch the game with R600_DEBUG="ps,vs,tcs,tes,cs,gs" it will
work.
It's similar to the "Peace, Death!" issue because they both use the same
engine.
--
You are receiving this mail because:
Now that we have the DRM_DEV_* variants, we should use them.
Signed-off-by: Sean Paul
---
Documentation/gpu/todo.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 22af55d06ab8..e3b622094bf4 100644
--- a/Documentatio
Add forward declarations in cdn-dp-reg.h to cdn_dp_device and audio_info
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
index c4bbb4a83319..84
On Fri, Sep 08, 2017 at 05:00:16PM +0800, Chen-Yu Tsai wrote:
> When binding the TCON, we were checking the reset control status and
> asserting reset if it wasn't in reset. The check failed to account for
> the reset control API returning error codes if the status callback was
> not implemented.
>
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #20 from har...@gmx.de ---
@Thomas,
i get freezes in windowed mode with activated vsync too (tried with latest
git).
--
You are receiving this mail because:
You are the assignee for the bug._
If struct fb_ops is defined in a library like cma, fb_open() takes a
ref on the library instead of the driver module. Use
fb_ops.fb_open/fb_release to ensure that the driver module is pinned.
Add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
DRM_FB_HELPER_DEFAULT_OPS().
Signed-off-by:
Make struct drm_fbdev_cma public so we don't have to make more wrappers
to call the drm_fb_helper fbdev wrappers.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 5 -
include/drm/drm_fb_cma_helper.h | 11 +++
2 files changed, 7 inser
This adds device unplug support to drm_fb_helper, drm_fb_cma_helper
(fbdev) and tinydrm.
There are several changes in this version:
I've used Daniel's idea of protecting drm_device.unplugged with srcu to
provide race free drm_dev_unplug().
The fbdev helper unplug patch has become very small with
Keep track of fbdev users and only restore fbdev in
drm_fb_helper_restore_fbdev_mode_unlocked() when in use. This avoids
fbdev being restored in drm_driver.last_close when nothing uses it.
Additionally fbdev is turned off when the last user is closing.
fbcon is a user in this context.
Signed-off-b
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
driver
Support using drm_fb_helper_unregister_fbi() in driver.remove prior to
calling drm_fbdev_cma_fini() in drm_driver.release.
Also make drm_fbdev_cma_fini() NULL tolerant.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
1 file changed, 7 ins
Might as well embed drm_device since tinydrm_device (embeds pipe struct
and fbdev pointer) needs to stick around after driver-device unbind to
handle open fd's after device removal.
tinydrm_release() will be expanded in a later patch.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
Changes
Support device unplugging to make tinydrm suitable for USB devices.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 84 +
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 26 -
2 files changed, 72 insertions(+), 38 deletions(-)
di
Hi,
On 08-09-17 14:05, Daniel Vetter wrote:
On Fri, Sep 08, 2017 at 01:54:41PM +0200, Hans de Goede wrote:
Hi All,
Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot (transparently) rotate in hardware, so we
need to rotate things in software / le
No need to put out a driver registered message since drm_dev_register()
does that now. SPI speed is an important metric when dealing with
display problems, so retain that info.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 14 +-
drivers/gp
Support device unplug by taking a ref on drm_device during probe, drop
it in fbops.destroy = drm_fb_helper_fb_destroy().
Use drm_dev_is_unplugged() to block futile operations.
drm_fb_helper_unregister_fbi() can now be called on device removal and
drm_fb_helper_fini() in drm_driver.release.
It tur
It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 55 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 10 +++
Protect device resource by adding drm_dev_enter() and drm_dev_exit().
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 11 ---
drivers/gpu/drm/tinydrm/mipi-dbi.c | 18 +-
drivers/gpu/drm/tinydrm/repaper.c | 30
fbdev is in maintenance only, except that it's still used by drm
through the drm fbdev emulation, to be able to use fbcon. And people
might want to sometimes extend fbcon to enable new features for drm
drivers, e.g. Hans' panel orientation work.
The problem is that when those patches only touch fb
On Fri, Sep 8, 2017 at 11:35 AM, Daniel Vetter wrote:
> fbdev is in maintenance only, except that it's still used by drm
> through the drm fbdev emulation, to be able to use fbcon. And people
> might want to sometimes extend fbcon to enable new features for drm
> drivers, e.g. Hans' panel orientat
On Fri, Sep 08, 2017 at 10:32:07AM -0400, Sean Paul wrote:
> Now that we have the DRM_DEV_* variants, we should use them.
>
> Signed-off-by: Sean Paul
I think that's fairly ideal fodder for outreachy, assume we make sure the
driver maintainer is ok with the resulting torrent of patches first :-)
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #16 from Arek Ruśniak ---
Patch fixes issue.
I've tried both staging-4.12 and staging-drm-next branches.
Thanks Christian
PS. It will be nice if Vedran could confirmed this for Vega before we close.
--
You are receiving this mail
On Fri, Sep 8, 2017 at 11:44 AM, Daniel Vetter wrote:
> On Fri, Sep 08, 2017 at 10:32:07AM -0400, Sean Paul wrote:
>> Now that we have the DRM_DEV_* variants, we should use them.
>>
>> Signed-off-by: Sean Paul
>
> I think that's fairly ideal fodder for outreachy, assume we make sure the
> driver
https://bugs.freedesktop.org/show_bug.cgi?id=99710
--- Comment #10 from Sandeep ---
I tried the 4.11.0 kernel since I suspected that the buggy change might also be
present in the point releases, but that also caused a hang whenplaying Left 4
Dead 2. Will try older kernels and see if they work cor
What's the difference between HandleToFD and ExportSyncFile?
Thanks,
Marek
On Sat, Jun 17, 2017 at 3:06 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> These ioctls are now in drm next so add the first set of libdrm APIs.
>
> Signed-off-by: Dave Airlie
> ---
> include/drm/drm.h | 26 ++
1 - 100 of 130 matches
Mail list logo
