https://bugs.freedesktop.org/show_bug.cgi?id=106892
--- Comment #1 from Simon ---
Ok seems the radeon driver has problems with my monitor at 1440x900@75Hz,
because if I reduce that to 1440x900@60Hz it seems to work stable, though my
Intel iGPU never had problems with 75Hz..
--
You are
On 12 June 2018 at 02:27, Rodrigo Vivi wrote:
> Hi Dave,
>
> This is the first round targeting 4.19.
>
Does this tree feed into linux-next already?
Since we shouldn't have new stuff for linux-next feeding into it until
after rc1.
I won't be pulling this until after rc1 anyways.
Dave.
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Alexandru-Cosmin Gheorghe
>Sent: Monday, June 11, 2018 3:47 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com;
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #15 from Alexander Mezin (mezin.alexan...@gmail.com) ---
No, it doesn't change anything, system freezes on resume.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
On Wed, Jun 06, 2018 at 12:36:49PM +0300, Laurent Pinchart wrote:
> The drm_encoder implementation requires access to the omap_dss_device
> corresponding to the display, which is passed to its initialization
> function and stored internally. Clean up of the HDMI mode and infoframe
> handling
Hi,
On Wed, Jun 06, 2018 at 12:36:50PM +0300, Laurent Pinchart wrote:
> The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
> operations are called recursively from the display device back to the
> HDMI encoder. This isn't required, as all components other than the HDMI
> encoder
https://bugs.freedesktop.org/show_bug.cgi?id=106446
--- Comment #7 from Mike Bendel ---
Adding amdgpu.dpm=1 did not fix it, unfortunately. Noticed no change on my
WX7100. Thanks for the suggestion though.
--
You are receiving this mail because:
You are the assignee for the
Hi,
On Wed, Jun 06, 2018 at 12:36:48PM +0300, Laurent Pinchart wrote:
> The CRTC mode set implementation needs to access the omap_dss_device for
> the pipeline display. To do so, it iterates over all pipelines to find
> the one that contains an encoder corresponding to the CRTC, and request
> the
Hi,
On Wed, Jun 06, 2018 at 12:36:33PM +0300, Laurent Pinchart wrote:
> Various functions that need to differentiate between omap_dss_device
> instances corresponding to displays and to internal encoders use the
> omap_dss_device.driver field, which is only set for display instances.
> This gets
Hi,
On Wed, Jun 06, 2018 at 12:36:47PM +0300, Laurent Pinchart wrote:
> Instead of calling the EDID read operation (.read_edid()) recursively
> from the display device back to the first device that provides EDID read
> support, iterate over the devices manually in the DRM connector code.
> This
Hi,
On Wed, Jun 06, 2018 at 12:36:46PM +0300, Laurent Pinchart wrote:
> On HDMI outputs, CEC support requires notification of HPD signal
> deassertion. The HPD signal can be handled by various omap_dss_device
> instances in the pipeline, and all of them forward HPD events to the
> OMAP4 internal
Hi,
On Wed, Jun 06, 2018 at 12:36:45PM +0300, Laurent Pinchart wrote:
> The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable
> and disable hot-plug detection at omapdrm probe and remove time. This is
> required to avoid reporting hot-plug detection events before the DRM
>
Hi,
On Wed, Jun 06, 2018 at 12:36:44PM +0300, Laurent Pinchart wrote:
> The HPD-related omap_dss_device operations are now only called when the
> device supports HPD. There's no need to duplicate that check in the
> omap_dss_device drivers. The .register_hpd_cb() operation can as a
> result be
Hi,
On Wed, Jun 06, 2018 at 12:36:43PM +0300, Laurent Pinchart wrote:
> Instead of calling the hot-plug detection callback registration
> operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively
> from the display device back to the first device that provides hot plug
> detection
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://bugs.freedesktop.org/show_bug.cgi?id=104520
--- Comment #22 from Alif Wahid ---
Created attachment 140127
--> https://bugs.freedesktop.org/attachment.cgi?id=140127=edit
Log dump from /sys/class/drm/card0/error after GPU hang (as printed in dmesg
output).
I see this error
Remove hand rolled msm property caching to handle DPU
custom properties. This change also cleans up all its
dependencies to cache and restore respective drm
states.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile | 1 -
remove unwanted dpu uapi headers exposing custom
payload layouts for custom properties
changs in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Cleanup residual connector property enumerations.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
Enable drm core zpos normalization for planes.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
Submitting a series of patches to further clean up DPU driver by stripping
down a list of custom properties supporting proprietary features. It
removes the property installers/handlers and cleans up relevant files of
of some of the advanced features. This series is based on the patch[1]
Replace custom plane zpos property with drm core zpos
property. CRTC relies on the normalized zpos values
to configure blend stages of each plane.
changes in v2:
- Move out unrelated changes in plane init (Sean Paul)
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
Hi,
On Mon, Jun 11, 2018 at 08:11:09PM +0300, Laurent Pinchart wrote:
> Hi Sebastian,
>
> On Monday, 11 June 2018 02:52:44 EEST Sebastian Reichel wrote:
> > On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote:
> > > Similarly to for_each_dss_display(), the for_each_dss_output()
Hi,
On Mon, Jun 11, 2018 at 08:16:24PM +0300, Laurent Pinchart wrote:
> Hi Sebastian,
>
> On Monday, 11 June 2018 02:48:45 EEST Sebastian Reichel wrote:
> > On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote:
> > > The dss_mgr_connect() and dss_mgr_disconnect() functions take two
>
https://bugs.freedesktop.org/show_bug.cgi?id=106892
Bug ID: 106892
Summary: GPU hang with radeon glx driver
Product: Mesa
Version: 18.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
From: Ville Syrjälä
Use the '[PROP:id:name]' format I introduced for the core in the driver
debug messages as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic.c | 6 --
drivers/gpu/drm/i915/intel_atomic_plane.c | 6 --
2 files changed, 8 insertions(+), 4
From: Ville Syrjälä
Print out the modeline when we reject a bad user mode. Avoids having to
guess why it was rejected.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 20 +---
drivers/gpu/drm/drm_crtc.c | 4 +++-
From: Ville Syrjälä
Print the id/name of the object we're dealing with. Makes it easier to
figure out what's going on. Also toss in a few extra debug prints that
might be useful.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 88 ++--
1
https://bugs.freedesktop.org/show_bug.cgi?id=106871
--- Comment #2 from Erik ---
Thank a lot!, i will forward the bug.
(Still interesting how you can figure this out from my logging.)
--
You are receiving this mail because:
You are the assignee for the
On Mon, Jun 11, 2018 at 12:07 AM Christoph Hellwig wrote:
>
> For now I'd say revert this commit for 4.17/4.18-rc and I'll look into
> addressing these issues properly.
Ok, reverted in my tree, and marked for stable (for 4.17). Thanks,
Linus
Hi Sebastian,
On Monday, 11 June 2018 14:59:13 EEST Sebastian Reichel wrote:
> On Sat, May 26, 2018 at 08:25:09PM +0300, Laurent Pinchart wrote:
> > The omapdrm and omapdss drivers are architectured based on display
> > pipelines made of multiple components handled from sink (display) to
> >
Add a helper function to parse the clock names and set up
the bulk data so we can take advantage of the bulk clock
functions instead of rolling our own. This is added
as a helper function so the upcoming a6xx GMU code can
also take advantage of it.
Signed-off-by: Jordan Crouse
---
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +
2 files changed, 2166
Now that the IOMMU is the master of it's own power we don't need to bring
up the GPU to do IOMMU operations. This is good because bringing up a6xx
requires the GMU so calling pm_runtime_get_sync() too early in the process
gets us into some nasty circular dependency situations.
Signed-off-by:
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the
Failure to load firwmare is the primary reason to fail adreno_load_gpu().
Try to load it first before going into the hardware initialization code and
unwinding it. This is important for a6xx because the GMU gets loaded from
the runtime power code and it is more costly to fail in that path because
This is an initial version of support for the Adreno a6xx GPU family starting
with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845
code that would be needed to actually bring up a device and it is also in
advance of any user side support for the a6xx GPU so this is mainly
The expected return value from ion_map_kernel is an ERR_PTR. The error
path for a vmalloc failure currently just returns NULL, triggering
a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR.
Reported-by: syzbot+55b1d9f811650de94...@syzkaller.appspotmail.com
Signed-off-by:
On Mon, Jun 04, 2018 at 11:13:53AM -0700, Sinclair Yeh wrote:
> On Wed, May 30, 2018 at 11:08:57PM +0300, Ville Syrjälä wrote:
> > On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Instead of plane->fb (which we're going to deprecate for atomic
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #9 from Henrik Holst ---
Just tried that and the black box around the sight vanished but the water
effect is still there for me, this is on 18.0.1 however so perhaps 18.1.x works
differently there. Wouldn't be surprised either if
Hi Sebastian,
On Monday, 11 June 2018 02:48:45 EEST Sebastian Reichel wrote:
> On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote:
> > The dss_mgr_connect() and dss_mgr_disconnect() functions take two
> > omap_dss_device pointers as parameters, which are always set to the same
> >
https://bugs.freedesktop.org/show_bug.cgi?id=106872
--- Comment #1 from Michel Dänzer ---
Please attach the dmesg output from the affected system, preferably captured
while or after the problem occurs.
(In reply to Bas Nieuwenhuizen from comment #0)
> e.g. the last report we had kernel reported
Hi Sebastian,
On Monday, 11 June 2018 02:52:44 EEST Sebastian Reichel wrote:
> On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote:
> > Similarly to for_each_dss_display(), the for_each_dss_output() macro
> > iterates over all the DSS connected outputs.
> >
> > Signed-off-by:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
> On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
> > On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
> > > > > > > > > > @@ -325,6 +401,14 @@ static int map_grant_pages(struct
> > > > > > > > > > grant_map
> > > > > > > > > > *map)
> > > >
On Thu, Jun 07, 2018 at 03:13:23PM +0300, Laurent Pinchart wrote:
> Hi Ville,
>
> On Thursday, 7 June 2018 15:03:12 EEST Ville Syrjälä wrote:
> > On Wed, Jun 06, 2018 at 12:08:12PM +0300, Laurent Pinchart wrote:
> > > The drm_connector_helper_funcs .mode_valid() operation should not modify
> > >
From: Colin Ian King
The check for level being less than zero always false because flags
is currently unsigned and can never be negative. Fix this by making
flags a s32.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Signed-off-by: Colin Ian King
---
V2: Make flags
On 11/06/18 17:25, Ville Syrjälä wrote:
> On Mon, Jun 11, 2018 at 05:00:37PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> The check for level being less than zero is redundant as level
>> is an unsigned u32 and hence will never be less than zero.
>> Remove this redundant check.
>>
>>
https://bugzilla.kernel.org/show_bug.cgi?id=199619
--- Comment #8 from Giorgio (giorgio.colacc...@gmail.com) ---
Hi Elmar,
I don’t know if it may be of help, anyway I have a similar problem: the point
is that my problem does not seem related to graphic drivers. My OS is
Slackware64 14.2, kernel
https://bugzilla.kernel.org/show_bug.cgi?id=199619
Giorgio (giorgio.colacc...@gmail.com) changed:
What|Removed |Added
CC|
Hi Dave,
This is the first round targeting 4.19.
Here goes drm-intel-next-2018-06-06:
- Ice Lake's display enabling patches (Jose, Mahesh, Dhinakaran, Paulo, Manasi,
Anusha, Arkadiusz)
- Ice Lake's workarounds (Oscar and Yunwei)
- Ice Lake interrupt registers fixes (Oscar)
- Context switch
On Mon, Jun 11, 2018 at 05:00:37PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The check for level being less than zero is redundant as level
> is an unsigned u32 and hence will never be less than zero.
> Remove this redundant check.
>
> Detected by CoverityScan, CID#1468363 ("Macro
Hi,
On Wed, Jun 06, 2018 at 12:36:41PM +0300, Laurent Pinchart wrote:
> When an omap_dss_device operation can be implemented in multiple places
> in a chain of devices, it is important to find out which device to
> address to perfom the operation. This is currently done by calling the
> operation
Hi,
On Wed, Jun 06, 2018 at 12:36:42PM +0300, Laurent Pinchart wrote:
> Instead of calling the .detect() operation recursively from the display
> device back to the first device that provides hot plug detection
> support, iterate over the devices manually in the DRM connector
> .detect()
From: Colin Ian King
The check for level being less than zero is redundant as level
is an unsigned u32 and hence will never be less than zero.
Remove this redundant check.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Signed-off-by: Colin Ian King
---
Hi,
On Wed, Jun 06, 2018 at 12:36:40PM +0300, Laurent Pinchart wrote:
> omap_dss_device instances have two ops structures, omap_dss_driver and
> omap_dss_device_ops. The former is used for devices at the end of the
> pipeline (a.k.a. display devices), and the latter for intermediate
> devices.
>
On Wed, Jun 06, 2018 at 05:39:42PM +0200, Enric Balletbo i Serra wrote:
> Trivial fix to spelling mistake in tilcdc.txt devicetree documentation.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +-
> 1 file changed, 1
On Fri, Jun 08, 2018 at 11:56:04AM +0530, Sharat Masetty wrote:
> This series re-factors the devfreq code a bit in preparation for the upcoming
> A6x related devfreq changes. The code applies cleanly on 4.17 and has been
> verified on DB820C.
>
> V2: Addressed code review comments from Jordan
Hi,
On Wed, Jun 06, 2018 at 12:36:39PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> As the descriptor API handles the active-low flag internally we need to
> invert the polarity of
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #14 from Christian König (christian.koe...@amd.com) ---
Created attachment 276471
--> https://bugzilla.kernel.org/attachment.cgi?id=276471=edit
Testing patch
Please test if this patch helps as well.
It limits the work done during
Hi,
On Wed, Jun 06, 2018 at 12:36:38PM +0300, Laurent Pinchart wrote:
> The driver doesn't use GPIOs and thus doesn't need to include the
> linux/gpio.h header.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Wed, Jun 06, 2018 at 12:36:37PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Wed, Jun 06, 2018 at 12:36:36PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> The reset GPIO is mandatory, so drop conditional tests through the
> driver. The qvga GPIO is
Hi,
On Wed, Jun 06, 2018 at 12:36:35PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> As the descriptor API handles the active-low flag internally we need to
> invert the polarity of
Hi,
On Wed, Jun 06, 2018 at 12:36:34PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Wed, Jun 06, 2018 at 12:36:32PM +0300, Laurent Pinchart wrote:
> The omapdrm driver checks at suspend and resume time whether the
> displays it operates on have their driver operations set. This check is
> unneeded, as all display drivers set the driver operations field at
> probe time and
Hi,
On Wed, Jun 06, 2018 at 12:36:31PM +0300, Laurent Pinchart wrote:
> The .get_mirror() and .set_mirror() omap_dss_driver operations are
> implemented by the panel-tpo-td043mtea1 driver but are never used.
> Remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian
Hi,
On Wed, Jun 06, 2018 at 12:36:30PM +0300, Laurent Pinchart wrote:
> The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate()
> omap_dss_driver operations are not used. Remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi Andrzej et all,
just so we don't discuss in a theoretic way much longer I've just
sent a RFC with my current state of work for the dw-mipi-dsi dual-dsi
support - aka the old "let code speak" ;-)
I've found a somewhat nice way to get from one dsi-controller node
to the node of the other
From a specified output port of one dsi controller this function allows to
iterate over the list of registered dsi controllers trying to find a second
instance connected to the same display, like it is used in dual-dsi setups.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/drm_mipi_dsi.c |
Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
As described in the general dual-dsi devicetree binding, the panel should
define two input ports and point each of them to one of the used dsi-
controllers, as well as declare one of them as clock-master.
This is used to
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using
devm-helpers. So this is happening on each try of master bringup possibly
slowing down things a lot.
Drivers using the component framework may instead want call dw_mipi_dsi_probe
separately in their probe function setup
When the panel-driver is build as a module it currently fails hard as the
panel cannot be probed directly:
dw_mipi_dsi_bind()
__dw_mipi_dsi_probe()
creates dsi bus
creates panel device
triggers panel module load
panel not probed (module not loaded or panel probe slow)
The Rockchip DSI driver was separate till now, not using the common
bridge driver that was introduced a bit later. So this series migrates
over to use that common bridge driver and then also adds support for
dual-dsi to both the bridge and Rockchip glue code.
The bridge-migration itself is v8
From: Nickey Yang
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
setup. This will require additional implementation-specific
code to look up the slave instance and do specific setup.
Also will probably need code in the specific crtcs as dual-dsi
does not equal two separate dsi
From: Nickey Yang
This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
Reviewed-by: Brian Norris
Signed-off-by: Heiko
From: Nickey Yang
Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge and remove the old separate one.
changes:
v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind()
Right now the host is only unregistered when the driver is used via the
bridge api and not via the component api, leading to the host staying
registered in cases like probe deferral.
So move the host unregister to the general remove function, so that it
gets cleaned up in all cases.
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
https://bugs.freedesktop.org/show_bug.cgi?id=105145
--- Comment #12 from Christian König ---
(In reply to k.philipp from comment #11)
> Is the interlaced format necessary in the first place?
Unfortunately yes it is.
The pixel shader used for de-interlacing needs to have access to the
https://bugs.freedesktop.org/show_bug.cgi?id=105145
--- Comment #11 from k.phil...@gmail.com ---
Hi again,
> The PR got merged.
I do have a patch ready (it's just a few lines anyway), but vaapi has not seen
a release yet so it is unclear which API version it should depend on. Also we
have
Add calls to pm_runtime_force_{suspend,resume} as SYSTEM_SLEEP_PM_OPS for
all drivers for the real Exynos DRM hardware modules. This ensures that
the resources will be released for the system PM suspend/resume cycle.
Exynos DRM core already takes care of suspending the whole display pipeline
Dear all,
This patchset performs a significant cleanup of Exynos DRM suspend/resume
code. A side effect of this cleanup is working system suspend/resume on
Exynos5433 SoCs, where there are more dependencies between hardware
device drivers, clock controllers and power domains than in case of the
The virtual Exynos DRM device has no runtime PM enabled, so checking
for its runtime suspended state is useless.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
In the current code, exynos_drm_suspend() function is called after all
real devices (CRTCs, Encoders, etc) are suspended, because Exynos DRM
virtual platform device is created as last device in the system (as
a part of DRM registration). None of the devices for real hardware
modules has its own
Hi Ville,
I finally found some time to dig deeper into when a CEC device should be
registered.
Since it's been a long while since we discussed this let me just recap the
situation
and then propose three solutions:
CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers.
Hi,
On Sat, May 26, 2018 at 08:25:18PM +0300, Laurent Pinchart wrote:
> The dss_mgr .connect() and .disconnect() are implemented as no-op in
> omapdrm. The operations are unneeded, remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Sat, May 26, 2018 at 08:25:17PM +0300, Laurent Pinchart wrote:
> The omap_dss_device.dispc_channel_connect field is used by DSS outputs
> to fail the .enable() operation if they're not connected. Set the field
> directly from the (dis)connect handlers of the DSS outputs instead of
> going
Hi,
On Sat, May 26, 2018 at 08:25:14PM +0300, Laurent Pinchart wrote:
> The omap_crtcs global array is used to store pointers to omap_crtc
> indexed by DISPC channel number, in order to look them up in the dss_mgr
> operations. Store the information in the omap_drm_private structure in
> the form
Hi,
On Sat, May 26, 2018 at 08:25:15PM +0300, Laurent Pinchart wrote:
> The omap_crtc_output global array is used to look up the DSS output
> device by channel. We can replace that by accessing the output device
> from the pipeline if we store the pipeline pointer in the omap_crtc
> structure.
>
Hi,
On Sat, May 26, 2018 at 08:25:16PM +0300, Laurent Pinchart wrote:
> The CRTC connect handler checks whether the DSS output supports the
> DISPC channel assigned to it. As the channel is assigned to the output
> by the output driver a failure there could only result from a driver
> bug. All
Hi,
On Sat, May 26, 2018 at 08:25:13PM +0300, Laurent Pinchart wrote:
> Replace the dss display device pointer by a pipe pointer that will allow
> the omap_crtc_init() function to access both the display and the DSS
> output. As a result we can remove the omapdss_device_get_dispc_channel()
>
Hi,
On Sat, May 26, 2018 at 08:25:12PM +0300, Laurent Pinchart wrote:
> To simplify the pipeline disconnection handling merge the
> omapdss_device_disconnect() and omapdss_output_unset_device() functions.
> The device state check is now called for every device in the pipeline,
> extending this
Hi,
On Sat, May 26, 2018 at 08:25:11PM +0300, Laurent Pinchart wrote:
> The display type is validated when the display is connected to the DSS
> output. We already have all the information we need for validation when
> initializing the outputs. Move validation to output initialization to
>
Hi,
On Sat, May 26, 2018 at 08:25:10PM +0300, Laurent Pinchart wrote:
> When a DSS output is (dis)connected the omapdss_output_(un)set_device()
> function performs a sanity check to ensure that the output isn't already
> (dis)connected. The check is unnecessary as those situations should
> never
Hi,
On Sat, May 26, 2018 at 08:25:09PM +0300, Laurent Pinchart wrote:
> The omapdrm and omapdss drivers are architectured based on display
> pipelines made of multiple components handled from sink (display) to
> source (DSS output). This is incompatible with the DRM bridge and panel
> APIs that
On Mon, 11 Jun 2018, John Sledge wrote:
> Thanks for the help. I was able to manage your advice on the
> drm_dp_aux_chardev. Though I still need to learn more about the DRM vs
> kernel process flow. Like for example, upon changing/adding
> DRM_DP_AUX_CHARDEV in kernel .config, How did
Hi,
On Sat, May 26, 2018 at 08:25:08PM +0300, Laurent Pinchart wrote:
> Create an omap_drm_pipeline structure to model display pipelines, made
> of a CRTC, an encoder, a connector and a DSS display device. This allows
> grouping related parameters together instead of storing them in
> independent
https://bugs.freedesktop.org/show_bug.cgi?id=106418
--- Comment #4 from Michel Dänzer ---
(In reply to Christian König from comment #3)
> Good to know, David and I actually already fixed one cause for this. So I
> assumed that this should do it, but that obviously isn't the case.
FWIW, I hit it
https://bugs.freedesktop.org/show_bug.cgi?id=106418
--- Comment #3 from Christian König ---
(In reply to Michel Dänzer from comment #2)
> Christian, could this be related to commit a35f2f34b5b4 "dma-buf: make
> returning the exclusive fence optional", or do you have other ideas? I'm now
>
1 - 100 of 127 matches
Mail list logo