On Tue, Mar 28, 2017 at 09:17:25AM +0300, Shashank Sharma wrote:
> This patch adds description about 'scdc' variable in drm_hdmi_info
> structure, to fix this warning during doc-build.
>
> "drm_connector.h:140: warning: No description found for parameter 'scdc'"
>
> V2: Rebase
> V3: Added extra *
On Tue, Mar 28, 2017 at 08:23:53AM +0200, Daniel Vetter wrote:
> On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:
> > On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> > > This is just prep work to get an acquire ctx into every place where we
> > > call ->update_pla
On Mon, Mar 27, 2017 at 06:48:24PM +0200, Lukas Wunner wrote:
> I've been contributing to vga_switcheroo for the past two years and by
> now am fairly familiar with it, so danvet suggested that I add myself
> as reviewer.
>
> While at it, add missing file pattern for vga_switcheroo.h + vgaarb.h
>
On Mon, Mar 27, 2017 at 08:13:17PM -0400, Harry Wentland wrote:
> On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> > No need to grab both plane and crtc locks at the same time, we can do
> > them one after the other. If userspace races it'll get what it
> > deserves either way.
>
On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:
> On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> > This is just prep work to get an acquire ctx into every place where we
> > call ->update_plane or ->disable_plane.
> >
> > v2: Keep the hidden acquire_ctx pointer
Here you go, https://patchwork.freedesktop.org/patch/146746/
Had to remove extra line in start, from V4.
Confirmed with a make DOCBOOKS="" htmldocs, no more error for scdc.
Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
On Mon, Mar 27, 2017 at 02:47:08PM +0100, Jose Abreu wrote:
> Hi Daniel,
>
>
> On 23-03-2017 11:00, Daniel Vetter wrote:
> > On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote:
> >> Hi Daniel,
> >>
> >>
> >> On 23-03-2017 07:22, Daniel Vetter wrote:
> >>> On Wed, Mar 22, 2017 at 05:35:57P
This patch adds description about 'scdc' variable in drm_hdmi_info
structure, to fix this warning during doc-build.
"drm_connector.h:140: warning: No description found for parameter 'scdc'"
V2: Rebase
V3: Added extra *
V4: Removed merged conflict
V5: Removed extra line at start of structure (Dani
On Sun, Mar 26, 2017 at 08:39:51AM +, Sharma, Shashank wrote:
> Thanks, V5 will do the trick for sure :-)
Hm, where is v5?
-Daniel
>
> Regards
> Shashank
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Saturday, March 25,
On 03/24/17 11:40, Tomi Valkeinen wrote:
> DRA7 errata i886 (FPDLink PLL Unlocks With Certain SoC PLL M/N Values)
> says that FPDLink is sensitive to jitter on the vout clock, and that low
> PLL M and N values result in more jitter than high M and N values.
>
> This patch implements a workaround f
https://bugs.freedesktop.org/show_bug.cgi?id=100426
Bug ID: 100426
Summary: Trine 3 takes long time to load
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=100375
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |DRM/other
--- Comment #3 from Michel Dä
https://bugs.freedesktop.org/show_bug.cgi?id=100375
--- Comment #2 from Edward O'Callaghan ---
(In reply to Michel Dänzer from comment #1)
> set_root doesn't look directly related to amdgpu or drm, so this could be
> memory corruption. KASAN might give more information.
>
> Does this only happen
https://bugs.freedesktop.org/show_bug.cgi?id=100375
--- Comment #1 from Michel Dänzer ---
set_root doesn't look directly related to amdgpu or drm, so this could be
memory corruption. KASAN might give more information.
Does this only happen when forcing an invalid EDID?
--
You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=100392
--- Comment #2 from Michel Dänzer ---
Please attach the dmesg output from when the problem occurs.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=100392
Michel Dänzer changed:
What|Removed |Added
Attachment #130456|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=100395
--- Comment #1 from Michel Dänzer ---
So this doesn't happen with amdgpu.dc=0?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=100424
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Vulkan/radeon
Versio
https://bugs.freedesktop.org/show_bug.cgi?id=100400
--- Comment #7 from Michel Dänzer ---
valgrind might give more information.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=100400
Michel Dänzer changed:
What|Removed |Added
Attachment #130461|application/octet-stream|text/plain
mime type|
Hi Alastair,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.11-rc4 next-20170327]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Alastair-Bridgewater/Enable-HDMI
* drm_mode_set_crtcinfo() does compensation for interlace and
doublescan timing effects already, so do it first and use the
compensated figures instead of the constant "vscan / ilace" terms
that we had before.
* Also prefer using the mode->crtc_* fields generally instead of
the non-crtc_-prefi
Now that we have mechanism by which to pass mode-dependent HDMI
InfoFrames to the low-level hardware driver, it is incumbent upon
us to do so.
Signed-off-by: Alastair Bridgewater
---
drivers/gpu/drm/nouveau/nv50_display.c | 30 +-
1 file changed, 29 insertions(+), 1 d
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic") InfoFrame.
Also don't enable any AVI or Vendor InfoFrame
On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
wrote:
> From: Samu Onkalo
>
> The user may request to the driver (vb2) to skip the cache maintenance
> operations in case the buffer does not need cache synchronisation, e.g. in
> cases where the buffer is passed between hardware blocks without i
HDMI InfoFrames are passed to NVKM as bags of bytes, but the
hardware needs them to be packed into words. Rather than having
four (or more) copies of the packing logic introduce a single copy
now, in a central place.
We currently need these for AVI and Vendor InfoFrames, but we may
also expect to
Enable stereoscopic output for HDMI and DisplayPort connectors on
NV50+ (G80+) hardware. We do not enable stereoscopy on older
hardware in case there is some older board that still has HDMI
output but for which we have no logic for setting the Vendor
InfoFrame.
With this, I get an obvious 3D outp
On Mon, 2017-03-27 at 10:35 +0200, Maarten Lankhorst wrote:
> Op 27-03-17 om 10:31 schreef Daniel Vetter:
> > On Mon, Mar 27, 2017 at 10:28:42AM +0200, Maarten Lankhorst wrote:
> >> Op 27-03-17 om 08:38 schreef Daniel Vetter:
> >>> On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any InfoFrame that is not p
The nouveau driver, in the Linux 3.7 days, used to try and set the
AVI InfoFrame based on the selected display mode. These days, it
uses a fixed set of InfoFrames. Start to correct that, by
providing a mechanism whereby InfoFrame data may be passed to the
NVKM functions that do the actual configu
On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
wrote:
> From: Sakari Ailus
>
> The cache synchronisation may be a time consuming operation and thus not
> best performed in an interrupt which is a typical context for
> vb2_buffer_done() calls. This may consume up to tens of ms on some
> machine
* Frame-packing modes add an extra vtotal raster lines to each
frame above and beyond what the basic mode description calls for.
Account for this during scaler configuration (possibly a bit of a
hack), during CRTC configuration (clearly not a hack), and when
checking that a mode is vaild for a gi
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any AVI or Vendor InfoFrame
HDMI 3D mode support, round two. Revisions include no longer dealing
with audio InfoFrames, passing infoframe data to NVKM as bags of bytes
rather than as data pre-packed for the hardware, more-normal return
value checking for drm_hdmi_*_infoframe_from_display_mode() results,
Frame-Packing mode su
On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
wrote:
> From: Sakari Ailus
>
> The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
> dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
> by USERPTR.
>
> Unify the two, leaving dma_sgt.
I think this pat
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any InfoFrame that is not p
Patches 2-5, 9-12, 14-19: Reviewed-by: Harry Wentland
Patches 1,13: Questions in response to those patches
Patches 6-8: Acked-by: Harry Wentland
Looks like a nice cleanup.
Harry
On Wednesday, March 22, 2017 10:50:39 PM EDT Daniel Vetter wrote:
> Hi all,
>
> This is something I kinda had on
On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> No need to grab both plane and crtc locks at the same time, we can do
> them one after the other. If userspace races it'll get what it
> deserves either way.
>
> This removes another user of drm_modeset_lock_crtc. There's only one
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: ba92d1fc68425bbff454195c1a7bf07ec9b650d0
commit: 0e14c5d6baef9140a24d83f5cf53bb59a1952e87 [198/266] drm/amdgpu: add NGG
parameters
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian
https://bugs.freedesktop.org/show_bug.cgi?id=100400
--- Comment #6 from Samuel Pitoiset ---
Thanks for this very nice report. :)
I can reproduce the issue with mesa/LLVM from today.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=98924
--- Comment #3 from Jeroen Bollen ---
I can confirm this bug also.
Hardware:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Opal
XT [Radeon R7 M265] (rev 81)
Subsystem: Hewlett-Packard Company Device 814f
https://bugs.freedesktop.org/show_bug.cgi?id=100390
--- Comment #7 from Samuel Pitoiset ---
Okay, the game uses ARB_texture_buffer_object which is only exposed with a core
profile for some reasons. I'm able to run the game with some hacky changes but
it fails to render correctly at some point.
U
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: ba92d1fc68425bbff454195c1a7bf07ec9b650d0
commit: 8ddf606557a311b7a4b4b5ad0578e52d2e7d5728 [211/266] drm/amdgpu: add
vega10 interrupt handler
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0
https://bugs.freedesktop.org/show_bug.cgi?id=100398
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #2 from
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: ba92d1fc68425bbff454195c1a7bf07ec9b650d0
commit: 7b6a92ae5cf029e021246cb79c8613b19e4554d4 [208/266] drm/amdgpu: Add GMC
9.0 support (v2)
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3)
Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to
keep from triggering the hardware addressing bug between of the tile
binner of the tile alloc memory (where the top 4 bits come from the
tile state data array's address).
To work around that and allow more memory to be reserved f
https://bugs.freedesktop.org/show_bug.cgi?id=100390
--- Comment #6 from Samuel Pitoiset ---
The game requests a 4.1 compatibility profile which is unsupported by Mesa and
it crashes because it doesn't check the return value of
glXCreateContextAttribsARB.
I'm investigating in order to know if it'
On 03/26/2017 09:05 PM, Ayaka wrote:
從我的 iPad 傳送
Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
從我的 iPad 傳送
Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
從我的 iPad 傳送
Ville Syrjälä 於
https://bugs.freedesktop.org/show_bug.cgi?id=100424
--- Comment #1 from Darren Salt ---
I'm aware (via IRC) that 4.11-rc3 should be fine. However, as I'm using
amd-staging-4.9 for its HDMI audio support, this isn't an option.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=100424
Bug ID: 100424
Summary: X hang (in kernel) after some event in Serious Sam
Fusion using radv. 4.9/and-staging-4.9
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
Most of the display servers today use a single surface to represent the
entire desktop even if it's stretched across multiple screens.
For vmwgfx with STDU, the maximum surface size is limited to the
maximum texture size on the host. On a 2D VM, this limits our
ability to support configurations w
The scanout surface size is the smaller of max texture size and
max STDU size.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +++
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 16 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |
From: Thomas Hellstrom
Provide and document a reference implementation.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 254 ---
drivers/gpu/drm/vmwgfx/vmwgf
From: Øyvind A. Holm
This reverts commit 2d8e60e8b074 ("drm/vmwgfx: Replace numeric
parameter like 0444 with macro")
The commit belongs to the series of 1285 patches sent to LKML on
2016-08-02, it changes the representation of file permissions from the
octal value "0600" to "S_IRUSR | S_IWUSR".
From: Thomas Hellstrom
The callbacks we need to provide to many resources are very similar, so
provide a simple resource type with a number of helpers for these
callbacks.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/Makefile | 3 +-
d
From: Thomas Hellstrom
Instead of providing an ioctl for each handle type, provide a single
handle_close ioctl, and reuse the UNREF_DMABUF ioctl.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
include/uapi/drm/vmwgfx_drm.h | 24
1 file changed, 24 inser
vmw_ldu_crtc_helper_commit() is not called if
drm_atomic_crtc_needs_modeset() decides nothing related to CRTC timing has
changed.
So a better place for this code is in vmw_ldu_primary_plane_atomic_update()
since we will need to update ld->fb every time the FB is updated.
Signed-off-by: Sinclair Y
These are a collection of patches currently queued for vmwgfx-next
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Pinning fbdev's FB at the start of VRAM prevents X from pinning
its FB. Since for ldu, the fb would be pinned anyway during a
mode set, just skip pinning it in fbdev.
This is not the best solution, but since ldu is not used much
anymore, it seems like a reasonable workaround.
Signed-off-by: Sinc
We can no longer make the assumption that vmw_stdu_update_st() will
be called when there's a valid display surface attached. So
instead of using display_srf for width and height, make a record of
these paremeters when the screen target is first defined.
Signed-off-by: Sinclair Yeh
Reviewed-by: T
https://bugs.freedesktop.org/show_bug.cgi?id=100398
--- Comment #1 from Alex Deucher ---
Is this still an issue with the latest drm-next-4.12-wip branch? I just a
squashed in a fix for this.
--
You are receiving this mail because:
You are the assignee for the bug.__
Switch over to internal atomic API. This completes the atomic
internal atomic switch for all the Display Units.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 103 ++---
drivers/gpu/drm/vmwgfx/vm
Switch over to using internal atomic API for mode set.
This removes the legacy set_config API, replacing it with
drm_atomic_helper_set_config(). The DRM helper will use various
vmwgfx-specific atomic functions to set a mode.
DRIVER_ATOMIC capability flag is not yet set, so the user mode
will sti
Since the link between connector and encoder is always fixed in our case,
just return the one encoder.
These helpers won't be called until we flip on the atomic support
flag or set drm_crtc_funcs->set_config to using the atomic
helper.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
-
This connects the main state object check and commit function.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/drivers/gp
1. When unsetting a mode, num_connector should be set to zero
2. The pixel_format field needs to be initialized as newer DRM internal
functions checks this field
3. Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can
change current mode
Signed-off-by: Sinclair Yeh
Reviewed-
Atomic mode set requires us to refactor existing vmw_stdu_crtc_set_config
code into sections that check the validity of the new mode, and sections
that actually program the hardware state.
vmw_du_crtc_atomic_check() takes CRTC-related checking code. In a later
patch, vmw_du_primary_plane_atomic_c
Refactor previous FB and cursor plane update code into their
atomic counterparts: check, update, prepare, cleanup, and disable.
These helpers won't be called until we flip on the atomic support
flag or set drm_crtc_funcs->set_config to using the atomic
helper.
v2:
* Removed unnecessary pinning of
Add plane state handling functions.
We have to keep track of a few plane states so we cannot use the
DRM helper for this.
Created vmw_plane_state along with functions to reset, duplicate,
and destroty it.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmw
Add connector handling functions. Start tracking is_implicity in
the connector state. Eventually, this field should be tracked
exclusively in a connector state.
Now that plane and connector states have been created, we can also
activate the code that use CRTC state.
Signed-off-by: Sinclair Yeh
This series enables atomic mode set on vmwgfx. Developed in
collaboration with Thomas Hellstrom and the VMWare Graphics
Team.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Create and Add CRTC state. We currently do not track any properties
or custom states so we can technically use the DRM helpers. Creating
this code just to make potential future additions easier.
Most of the new code will be compiled but not enabled until
plane/connector state handling code is al
Universal support is prerequisite for atomic mode set.
Explicitly create planes for the cursor and the primary FB. With
a functional cursor plane, the DRM will no longer use the legacy
cursor_set2 and cursor_move entry points.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
Reviewe
On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> This is just prep work to get an acquire ctx into every place where we
> call ->update_plane or ->disable_plane.
>
> v2: Keep the hidden acquire_ctx pointers valid while transitioning.
>
> Signed-off-by: Daniel Vetter
> ---
> d
On Mon, 27 Mar 2017, Jani Nikula wrote:
> On Sat, 25 Mar 2017, Shashank Sharma wrote:
>> This patch adds description about 'scdc' variable in drm_hdmi_info
>> structure, to fix this warning during doc-build.
>>
>> "drm_connector.h:140: warning: No description found for parameter 'scdc'"
>
> Did y
On Sat, 25 Mar 2017, Shashank Sharma wrote:
> This patch adds description about 'scdc' variable in drm_hdmi_info
> structure, to fix this warning during doc-build.
>
> "drm_connector.h:140: warning: No description found for parameter 'scdc'"
Did you actually run 'make htmldocs' with this? The ope
Hi Maxime,
As promised, here is the patch adding the interrupt line for the display
backend to the sun5i shared dtsi, and another one adding it to the device
tree bindings.
The display backend has an undocumented (in the user manual) interrupt
that, according to vendor code, is raised when the cu
On 03/27/2017 05:29 PM, Tetsuo Handa wrote:
> Thomas Hellstrom wrote:
>> So to summarize. Yes, the drm callers can be fixed up, but IMO requiring
>> vfree() to be non-atomic is IMO not a good idea if avoidable.
>
> I agree.
>
> I don't know about drm code. But I can find AppArmor code doing
> k
Hello there,
linux-4.11-rc4/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c:1319]: (style) Redundant
condition: If 'EXPR == 0', the comparison 'EXPR != 1' is always true.
Source code is
if ((HDCP_STATE_INACTIVE != hdcp_ctrl->hdcp_state) ||
(HDCP_STATE_NO_AKSV == hdcp_ctrl->hdcp_state)) {
Sugg
The display backend on sun5i shares the same interrupt line as the
display frontend. Add it.
Signed-off-by: Chen-Yu Tsai
---
This won't directly apply to old releases. We may want to backport
them though?
---
arch/arm/boot/dts/sun5i.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
2017-03-24 16:58 GMT+01:00 Rob Herring :
> On Mon, Mar 20, 2017 at 02:32:22PM +0100, Richard Genoud wrote:
>> This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
>> LCD panel, which can be supported by the simple panel driver.
>>
>> Signed-off-by: Richard Genoud
>> ---
>>
>> Cha
On Mon, Mar 27, 2017 at 04:26:02PM +0300, Andrey Ryabinin wrote:
> [+CC drm folks, see the following threads:
>
> http://lkml.kernel.org/r/201703232349.bgb95898.qhlvffomtfo...@i-love.sakura.ne.jp
>
> http://lkml.kernel.org/r/1490352808-7187-1-git-send-email-penguin-ker...@i-love.sakur
> On Tue, Mar 21, 2017 at 5:00 PM, Stephen Rothwell
wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_gem_shrinker.c
>
> between commit:
>
> 3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths
(shrinker)")
>
> from the d
Hi Daniel,
On 23-03-2017 11:00, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote:
>> Hi Daniel,
>>
>>
>> On 23-03-2017 07:22, Daniel Vetter wrote:
>>> On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
We can't expect userspace to have full support f
This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
LCD panel, which can be supported by the simple panel driver.
Acked-by: Rob Herring
Signed-off-by: Richard Genoud
---
Changes since v2:
Remove status, reg and unit-addresses from example
Changes since v1:
Add power-supply p
Thomas Hellstrom wrote:
> So to summarize. Yes, the drm callers can be fixed up, but IMO requiring
> vfree() to be non-atomic is IMO not a good idea if avoidable.
I agree.
I don't know about drm code. But I can find AppArmor code doing
kvfree() from dfa_free() from aa_dfa_free_kref() from kref_pu
The display backend has an interrupt line. Add it to the device tree
binding.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
b/Docum
從我的 iPad 傳送
> Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
>
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>>
>> 從我的 iPad 傳送
>>
Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
從我的 iPad 傳送
>> V
I've been contributing to vga_switcheroo for the past two years and by
now am fairly familiar with it, so danvet suggested that I add myself
as reviewer.
While at it, add missing file pattern for vga_switcheroo.h + vgaarb.h
to the DRM and DRM-MISC sections such that get_maintainer.pl returns
dri-d
On Wed, Mar 22, 2017 at 10:50:46PM +0100, Daniel Vetter wrote:
> Yes the help text is unhelpful, but atomic drivers should never use
> this. Just grab the lock without context or anything.
>
> Also an aside: Checking ->active like this doesn't protect against
> nonblocking commits, this is rather
https://bugs.freedesktop.org/show_bug.cgi?id=98629
Brian Paul changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On 26/01/17 14:37, Martin Peres wrote:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending co
On 03/27/2017 03:26 PM, Andrey Ryabinin wrote:
> [+CC drm folks, see the following threads:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_201703232349.BGB95898.QHLVFFOMtFOOJS-40I-2Dlove.SAKURA.ne.jp&d=DwIC-g&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMC
Previously, when a surface was opened using a legacy (non prime) handle,
it was verified to have been created by a client in the same master realm.
Relax this so that opening is also allowed recursively if the client
already has the surface open.
This works around a regression in svga mesa where o
A malicious caller could otherwise hand over handles to other objects
causing all sorts of interesting problems.
Testing done: Ran a Fedora 25 desktop using both Xorg and
gnome-shell/Wayland.
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence
On Fri, Mar 24, 2017 at 11:42:53AM +0100, Philipp Zabel wrote:
> On Fri, 2017-03-24 at 10:24 +, Martyn Welch wrote:
> [...]
> > > Could you move to v4.9 or v4.10 and check if the four patches in
> > > https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.9-ipu-dp-plane-fix
> > > or
> > > https:/
Hi Laurent,
On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart
wrote:
> The property is used by the driver but is missing from the DT bindings.
> Document it.
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt
Also unify/merge with the existing stuff.
I was a bit torn where to put this, but in the end I decided to put
all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
have a bit a split with the other uapi related stuff used internally,
like drm_file.[hc], but I think overall this makes
Hi Geert,
On Thursday 23 Mar 2017 16:10:56 Geert Uytterhoeven wrote:
> On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
> >
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >
> > +int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
>
The property is used by the driver but is missing from the DT bindings.
Document it.
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bin
1 - 100 of 114 matches
Mail list logo
