Hi,
> buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object
> obj->pages-sgl
> before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel
> console path.
That should be the right place.
> Once display manger is kicked off for example (sudo systemctl start
>
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 111 +++--
include/uapi/drm/amdgpu_drm.h | 9 ++
3 files changed, 100 insertions(+), 28 deletions(-)
diff --git
user mode can query timeline payload.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 53 ++
include/uapi/drm/drm.h | 11 +++
4 files changed, 68
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 99
On 2018年09月18日 16:32, Christian König wrote:
+ for (i = 0; i < args->count_handles; i++) {
+ if (syncobjs[i]->type == DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("timeline syncobj cannot reset!\n");
Why not? I mean that should still work or do I miss anything?
timeline
Hi Christian,
Yes you are correct. My bad.
Do you have any comments on the second patch? I will drop this patch and
rebase the second one.
Regards,
Nayan
On Wed, Sep 19, 2018, 2:09 AM Koenig, Christian
wrote:
> Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
> > Which points to the job
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup
Hook this into amdgpu's atomic check for their connectors so they never
get modesets on no-longer-present MST connectors. We'll also expand on
this later once we add DP MST fallback retraining support.
As well, turns out that the only atomic DRM driver without the
->best_encoder() bug is amdgpu.
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own,
There's two major things this patchset does:
- Add drm_dp_mst_connector_atomic_check() so drivers don't need to use
->best_encoder() to prevent modesets on zombie MST connectors. We'll
use this later for implementing MST fallback retraining as well.
- Fix DPMS on->off changes failing with
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable
https://bugs.freedesktop.org/show_bug.cgi?id=107693
--- Comment #12 from gloriouseggr...@gmail.com ---
We've removed the broken opengl patchset in wine-staging. Seems the problems it
resolved originally have all been resolved in wine already. Should be effective
next release. it was also
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
>
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
+ 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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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.
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
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 ++
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
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 |
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
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
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
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
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
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
$ 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 +++---
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(-)
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(>ring_mirror_list), doesn't it?
Regards,
Christian.
>
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
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
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
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
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
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
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
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 ||
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
> ---
>
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().
> > >
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
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 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
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
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
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 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)
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Michel Dänzer changed:
What|Removed |Added
Attachment #141635|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 #141631|0 |1
is obsolete|
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
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
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=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=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
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
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=edit
Using libunwind
--
You are receiving this mail because:
You are the assignee for the
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:
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
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
>
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,
> 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
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
>
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.
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,
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`
在 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
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
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
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
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
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
>
> 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
>
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
> > >
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
> ---
>
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:
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
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
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'
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Mike Lothian changed:
What|Removed |Added
Attachment #141632|0 |1
is obsolete|
1 - 100 of 117 matches
Mail list logo