https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #16 from Mike Lothian ---
Weird it was only showing i915 resumes no amdgpu ones - even though dmesg
clearly shows the card powering up
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #2 from SET ---
Created attachment 141623
--> https://bugs.freedesktop.org/attachment.cgi?id=141623&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #3 from SET ---
Created attachment 141624
--> https://bugs.freedesktop.org/attachment.cgi?id=141624&action=edit
dmesg after reboot
--
You are receiving this mail because:
You are the assignee for the bug._
Am 17.09.2018 um 11:33 schrieb zhoucm1:
[SNIP]
+static struct dma_fence *
+drm_syncobj_point_get(struct drm_syncobj *syncobj, u64 point, u64
flags)
+{
+ struct dma_fence *fence;
+ int ret = 0;
+
+ if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
+ ret = wait_event_timeou
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #4 from SET ---
Created attachment 141625
--> https://bugs.freedesktop.org/attachment.cgi?id=141625&action=edit
kernel log during problems
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #5 from SET ---
Please see attachments.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.f
Quoting José Roberto de Souza (2018-09-17 22:22:44)
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> Cc: Chris Wilson
> Signed-o
On Tue, Sep 18, 2018 at 04:20:18PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> vgem seems to oops on the intel CI due to the vgem debugfs init
> hitting this path now.
>
> Check if we have mode_config funcs before checking one.
>
> Signed-off-by: Dave Airlie
I thought Dave would apply,
https://bugs.freedesktop.org/show_bug.cgi?id=107891
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #17 from Mike Lothian ---
Created attachment 141631
--> https://bugs.freedesktop.org/attachment.cgi?id=141631&action=edit
pref report --header
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #18 from Mike Lothian ---
Created attachment 141632
--> https://bugs.freedesktop.org/attachment.cgi?id=141632&action=edit
Perf data
So the --header didn't show anything, however the raw data does seem to do
something amdgpu releat
https://bugs.freedesktop.org/show_bug.cgi?id=107950
Michel Dänzer changed:
What|Removed |Added
Attachment #141623|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=107950
Michel Dänzer changed:
What|Removed |Added
Attachment #141625|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=107693
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #6 from Michel Dänzer ---
Does updating xf86-video-ati to 18.1.0 or using EXA instead of glamor help by
any chance? Your system is affected by bug 105381.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Mike Lothian changed:
What|Removed |Added
Attachment #141632|0 |1
is obsolete|
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The E3 (r8a77990) supports two LVDS channels. Extend the binding to
> support them.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Jacopo Mondi
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
display will show an initial corrupt frame.
Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
activating the CRTC.
Signed-off-by: Leonard Crestez
Test
Christophe Leroy writes:
> The 'access' parameter of hash_preload() is either 0 or _PAGE_EXEC.
> Among the two versions of hash_preload(), only the PPC64 one is
> doing something with this 'access' parameter.
>
> In order to remove the use of _PAGE_EXEC outside platform code,
> 'access' parameter
On Mon, 2018-09-17 at 15:16 -0400, Sean Paul wrote:
> On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote:
> > Adding lcdif nodes to a power domain currently doesn't work, it results
> > in black/corrupted screens or hangs. While the driver does enable
> > runtime pm it does not deal co
On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> On Monday, 17 September 2018 10:50:55 EEST Simon Horman wrote:
> > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > > conn
On Fri, Sep 14, 2018 at 12:10:42PM +0300, Laurent Pinchart wrote:
> From: Takeshi Kihara
>
> Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> tree.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> Tested-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/
Adding lcdif nodes to a power domain currently results in
black/corrupted screens or hangs because power is not correctly enabled
when required.
Ensure power is on when display is active by adding
pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez
Reviewed-by: S
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> On the D3 and E3 SoCs, the LVDS encoder can derive its internal pixel
> clock from an externally supplied clock, either through the EXTAL pin or
> through one of the DU_DOTCLKINx pins. Add corresponding clocks to the DT
> bind
On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> supporting VSP and FCP.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
> -
Hi Inki,
On Tue, Sep 11, 2018 at 2:06 PM Souptick Joarder wrote:
>
> On Thu, Aug 2, 2018 at 9:12 PM Souptick Joarder wrote:
> >
> > convert drm_atomic_helper_suspend/resume() to use
> > drm_mode_config_helper_suspend/resume().
> >
> > exynos_drm_fbdev_suspend/resume can be removed
> > as drm_mode
Adding lcdif nodes to a power domain currently doesn't work, it results
in black/corrupted screens or hangs. While the driver does enable
runtime pm it does not deal correctly with the block being unpowered.
---
All patches in this series have review tags from a while ago and I
tested them again
On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> > supporting VSP and FCP
The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
immediately reenabled in mxsfb_enable_controller.
Avoid this by moving the handling of axi clk one level up to
mxsfb_crtc_enable. Do the same for mxsfb_crtc_disable for symmetry.
This shouldn't have any functional effect.
Si
The lcdif block is only powered on when display is active so plane
updates when not enabled are not valid. Writing to an unpowered IP block
is mostly ignored but can trigger bus errors on some chips.
Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
and having the drm core e
Since power to the lcdif block can be lost on suspend implement
PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
the current mode.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
1 file changed, 2
On Fri, Apr 13, 2018 at 9:59 AM Huang Rui wrote:
> On Thu, Apr 12, 2018 at 09:33:33PM +0200, Mathieu Malaterre wrote:
> > In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
> > 255 is done. Since it is always false, change the signature of this
> > function to use an `int` ins
在 2018-09-17一的 16:54 +0200，Maxime Ripard写道：
> On Mon, Sep 10, 2018 at 04:32:30PM +0200, Jernej Škrabec wrote:
> > Dne ponedeljek, 10. september 2018 ob 16:23:54 CEST je Maxime
> > Ripard
> > napisal(a):
> > > On Fri, Sep 07, 2018 at 03:22:34PM +0800, Icenowy Zheng wrote:
> > > > The R40 HDMI PHY s
Thank you for your patch!
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> in the other R-Car Gen3 family members:
>
> - The LVDS PLL architecture is more complex and requires computing PLL
> parame
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> Document the E3 (r8a77990) SoC in the R-Car DU bindings.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Jacopo Mondi
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
> 1 file changed, 2 insertio
Thank you for your patch!
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The THC63LVD1024 is restricted to a pixel clock frequency in the range
> of 8 to 135 MHz. Implement the bridge .mode_valid() operation
> accordingly.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-b
On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture,
After schedule() returns 0, we must do one last check of COND to
determine the reason for the wakeup with 0 jiffies remaining before
reporting the timeout -- otherwise we may lose the signal due to
scheduler delays.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106690
Signed-off-by: Chr
Both the .enable_signaling and .release of the null syncobj fence
can be replaced by the default callbacks for a small reduction in code
size.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #20 from Mike Lothian ---
Created attachment 141635
--> https://bugs.freedesktop.org/attachment.cgi?id=141635&action=edit
Using libunwind
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #7 from SET ---
With EXA, sddm login screen does not show up.
xf86-video-ati 18.1.0 is in testing branch at Arch repositories. Will test when
it'll be available as stable.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=101877
--- Comment #5 from Alexandre Pereira ---
I have a similar problem.
I have a Rx 580 with 2 exactly equal monitors. On windows, there is no issue
and memory clock is always at 300mhz, except when gaming.
When on linux, If using graphical displa
https://bugs.freedesktop.org/show_bug.cgi?id=107953
--- Comment #2 from Nicholas Kazlauskas ---
Thanks for the report. This had a Vega specific fix in mind but I guess it
extends to Polaris as well.
I would imagine the first patch from this thread should fix your issue (ie. the
one that's *not*
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Bug ID: 107978
Summary: [amdgpu] Switching to tty fails with DisplayPort
monitor going to sleep (REG_WAIT timeout /
dce110_stream_encoder_dp_blank)
Product: DRI
https://bugs.freedesktop.org/show_bug.cgi?id=107946
--- Comment #3 from Nicholas Kazlauskas ---
Please post an Xorg log along with what distro/desktop environment you're
using. It may also help if you can post another 4.19 dmesg log with drm.debug=6
in your bootline.
--
You are receiving this m
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #13 from Andrey Arapov (andrey.ara...@nixaid.com) ---
Could you please try reverting this commit
https://github.com/torvalds/linux/commit/e03fd3f300f6184c1264186a4c815e93bf658abb
, rebuilding your kernel and let us know if it fixes you
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Michel Dänzer changed:
What|Removed |Added
Attachment #141631|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Michel Dänzer changed:
What|Removed |Added
Attachment #141633|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Michel Dänzer changed:
What|Removed |Added
Attachment #141635|0 |1
is obsolete|
On Wed, Aug 01, 2018 at 01:37:05AM +0530, Souptick Joarder wrote:
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> With this conversion, tegra_drm_fb_suspend() and
> tegra_drm_fb_resume() wil not be used anymore.
> Both of these functions can be re
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #14 from Claude Heiland-Allen (cla...@mathr.co.uk) ---
I checked out linux v4.19-rc4 from git, then reverted that commit - no change,
display goes blank about 5 seconds into boot.
I noticed something else in the dmesg (it was there in
On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote:
> Hi, Greg
>
> Can you pick up the patch?
Nope:
$ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c
Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX)
David Airlie (maintainer:DRM DRIVERS)
dri-devel@lists.freedesktop.or
On Mon, Aug 27, 2018 at 9:18 AM, Shawn Guo wrote:
> On Fri, Aug 17, 2018 at 10:24:06AM +0800, zhong jiang wrote:
>> for_each_available_child_of_node will get and put the node properly,
>> the following of_node_put will lead to the double put. So just
>> remove it.
>>
>> Signed-off-by: zhong jiang
On Tue, Sep 18, 2018 at 5:02 PM, Greg KH wrote:
> On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote:
>> Hi, Greg
>>
>> Can you pick up the patch?
>
> Nope:
> $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c
> Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX)
> David Ai
Signed-off-by: Eric Engestrom
---
include/drm/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/README b/include/drm/README
index 521630db8b4c52749188..ea2320cc9e7728a9c08b 100644
--- a/include/drm/README
+++ b/include/drm/README
@@ -71,7 +71,7 @@ Note: One sh
On Tue, Sep 18, 2018 at 04:24:37PM +0100, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
Reviewed-by: Sean Paul
> ---
> include/drm/README | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/README b/include/drm/README
> index 521630db8b4c52749188..ea23
Got it.
-depends on EXTCON=y || (EXTCON=m && DRM_ROCKCHIP=m)
+depends on DRM_ROCKCHIP=m
+select EXTCON
Damian
-Original Message-
From: Heiko Stuebner
Sent: Thursday, September 13, 2018 14:32
To: Damian Kos
Cc: David Airlie ; Rob Herring ; Mark
Rutland ; Archit Taneja ; Andrzej
Hajda
On 2018/9/18 23:02, Greg KH wrote:
> On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote:
>> Hi, Greg
>>
>> Can you pick up the patch?
> Nope:
> $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c
> Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX)
> David Airlie (maintain
On Mon, Sep 10, 2018 at 12:16 PM Souptick Joarder wrote:
>
> On Mon, Aug 6, 2018 at 11:42 AM Souptick Joarder wrote:
> >
> > On Wed, Aug 1, 2018 at 1:37 AM, Souptick Joarder
> > wrote:
> > > convert drm_atomic_helper_suspend/resume() to use
> > > drm_mode_config_helper_suspend/resume().
> > >
>
Hi, Greg
Can you pick up the patch?
Thanks,
zhong jiang
On 2018/8/17 10:24, zhong jiang wrote:
> for_each_available_child_of_node will get and put the node properly,
> the following of_node_put will lead to the double put. So just
> remove it.
>
> Signed-off-by: zhong jiang
> ---
> drivers/
On Sun, Sep 16, 2018 at 01:45:23PM +0530, Uma Shankar wrote:
> This is how a typical display color hardware pipeline looks like:
> +---+
> |RAM|
> | +--++-++-+ |
> | | FB 1 || FB
Hi,
On Sun, Sep 16, 2018 at 01:45:25PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instan
Which points to the job running on the hardware. This is
useful when we need to access the currently executing job
from the scheduler.
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +++--
include/drm/gpu_scheduler.h| 2 ++
2 files changed,
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 16 +---
include/drm/gpu_scheduler.h
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
On Mon, Sep 17, 2018 at 09:52:08PM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added client capabilities for ASPECT_RATIO and WRI
Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
> Which points to the job running on the hardware. This is
> useful when we need to access the currently executing job
> from the scheduler.
That should be identical to
list_first_entry_or_null(&sched->ring_mirror_list), doesn't it?
Regards,
Christi
All the other vendors use the format
DRM_FORMAT_MOD_{SAMSUNG,QCOM,VIVANTE,NVIDIA,BROADCOM,ARM}_* for their
modifiers, except Intel.
Suggested-by: Gerd Hoffmann
Signed-off-by: Eric Engestrom
---
include/uapi/drm/drm_fourcc.h | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
$ sed -i s/I915_FORMAT_MOD_/DRM_FORMAT_MOD_INTEL_/g $(git grep -l
I915_FORMAT_MOD_)
$ git checkout include/uapi/drm/drm_fourcc.h
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 12 +-
drivers/gpu/drm/i915/intel_display.c | 128 +++---
drivers/
Registering the connector explicitly right after creation is not necessary
for modesetting drivers, because drm_dev_register already takes care of
this on the core side, by calling drm_modeset_register_all.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 1 -
1 file chan
Let's expose the primary plane initialization inside the vboxvideo driver
in preparation for universal planes and atomic.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 78 +--
1 file changed, 74 insertions(+), 4 deletions(-)
diff --git a/driver
Move the setup of drm modesetting config from vbox_driver_load() to
vbox_mode_init().
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_main.c | 45 ---
drivers/staging/vboxvideo/vbox_mode.c | 62 ---
2 files changed, 57 insertions(+), 50 del
Allow specifying where to pin the framebuffer bo, so that this helper can
be used from the cursor code too.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/dr
Hi Greg,
Here is a series of various cleanups and other prep. work for moving
the vboxvideo driver over to atomic modesetting so that it can be moved
out of staging.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list
This is the recommended way to create the drm_device structure,
according to DRM documentation.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 110 +++---
drivers/staging/vboxvideo/vbox_drv.h | 17 ++--
drivers/staging/vboxvideo/vbox_fb.c | 19 +
Fold the driver_load / unload functions into the probe / remove functions
now that we are no longer using the deprecated drm_get_pci_dev() mechanism.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 71 +--
drivers/staging/vboxvideo/vbox_drv.h |
vbox_pm_resume() is the only caller of vbox_drm_resume(), so squash the
2 functions into 1.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.
Add vbox_bo_k[un]map helper functions instead of having code directly
poking struct vbox_bo internals.
While touch neighboring code anyways also fix a return -PTR_ERR(info),
which should be return PTR_ERR(info).
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 2 ++
driv
Move pin / unpin of fb out of vbox_crtc_set_base_and_mode() so that it can
be used to implement the atomic_update drm_plane_helper_func for the primary
plane.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 5 +++
drivers/staging/vboxvideo/vbox_mode.c | 52 +
The fbdev compat fb gets pinned into VRAM at creation and then gets pinned
a second time when set as scanout buffer and unpinned when replaced, this
means its pin count never becomes less then 1, so it is always at the same
address and there is no need for the vbox_fbdev_set_base() call.
Signed-of
We always need to reserve the bo around a pin / unpin, so move the
reservation there.
This allows removing the vbox_fb_[un]pin helpers.
Note this means that we now no longer hold the bo reserved while
k[un]mapping it in vbox_fb.c this is fine as it is not necessary
to hold it reserved for this.
When vbox_set_up_input_mapping() gets called the first crtc might be
disable and not have a fb at all, triggering a NUL ptr deref at:
vbox->input_mapping_width = CRTC_FB(crtci)->width;
Instead of using the fb from the crtc with id 0, just use the fb from
the first crtc wit
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
v3: adding comments about the feature requirement about capabilities
Cc: Chris Wilson
Signed
On 09/12/2018 02:25 AM, Gerd Hoffmann wrote:
> Hi,
>
>> I attempted to fix it in the ttm layer and here is the discussion
>> https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/
>>
>> The ttm maintainer Christian is suggesting to map and set ttm->pages as
>> decrypted
>>
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
>
> > Acked-by: Darren Hart (VMware)
> >
> > As for a longer term solution, would it be possible to init fops in such
> > a way that the compat_ioctl call defaults to generic_
On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> v3: addin
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
On 14.09.2018 02:23, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thankk you for the patch.
>
> On Wednesday, 12 September 2018 21:32:15 EEST Stefan Agner wrote:
>> The DRM bus flags conveys additional information on pixel data on
>> the bus. All currently available bus flags might be of interest for
On Tue, Sep 18, 2018 at 11:11:15AM -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the con
On Tue, Sep 18, 2018 at 11:11:14AM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The
Thanks Imre for your review comments. Please find the comments below:
On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > On Icelake, a separate power well PG2 is created for
> > VDSC engine used for eDP/MIPI DSI. This pat
On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> Thanks Imre for your review comments. Please find the comments below:
>
> On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > On Icelake, a separate powe
On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > Thanks Imre for your review comments. Please find the comments below:
> >
> > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > On Tue, Sep 11, 2018 at
On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > Thanks Imre for your review comments. Please find the comments below:
> > >
> > > On Fri, Sep 14,
+ Harry, Leo
This would definitely be useful. We ran into a lot of issues when we
enabled >8 bpc support.
On Tue, Sep 18, 2018 at 2:10 PM Radhakrishna Sripada
wrote:
>
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to dr
On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > Thanks Imre for your review
On Sat, Sep 8, 2018 at 6:53 AM Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->outp
1 - 100 of 119 matches
Mail list logo
