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: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: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: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
>-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;
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.
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
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
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.
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
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: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: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
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
> >
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
https://bugzilla.kernel.org/show_bug.cgi?id=199619
Giorgio (giorgio.colacc...@gmail.com) changed:
What|Removed |Added
CC|
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
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.
>>
>>
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 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
> > >
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)
> > > >
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:
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
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
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:
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
> >
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
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
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
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
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:
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
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
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 +++-
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()
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
---
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
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
---
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/
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]
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 -
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
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
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
>
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:
On Fri, 08 Jun 2018, Hans Verkuil wrote:
> On 08/06/18 10:17, Neil Armstrong wrote:
> > On 08/06/2018 09:53, Hans Verkuil wrote:
> >> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> >>> Hi All,
> >>>
> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> >>> through it's
Hi Linus,
I looked at Rob's msm tree, he kept it small due to being late, and it
was in -next for a while before he was ill, so I think it should be
fine. Otherwise this contains a set of i915 fixes and a v3d build fix,
and vc4 leak fix.
Thanks,
Dave.
drm-next-2018-06-11:
msm next, i915, vc4,
I think the prime issue is that dma_direct_alloc respects the dma
mask. Which we don't need if actually using the iommu. This would
be mostly harmless exept for the the SEV bit high in the address that
makes the checks fail.
For now I'd say revert this commit for 4.17/4.18-rc and I'll look into
2018-06-08 8:52 GMT+02:00 Christian König :
> Am 08.06.2018 um 08:02 schrieb Christoph Hellwig:
>>
>> On Thu, Jun 07, 2018 at 02:32:46PM +0200, Gabriel C wrote:
>>>
>>> Ok done.. bisect points to:
>>
>> What is the failure mode you are seeing? Can't find anything in the
>> mail unfortunately.
>
>
Hi,
thank you for reviewing our patches. I sent "v2".
Regards,
Roman.
On Fri, Jun 8, 2018 at 9:24 AM Bartlomiej Zolnierkiewicz
wrote:
>
>
> [ + linux-fbdev ML ]
>
> On Thursday, May 31, 2018 03:02:52 PM r...@google.com wrote:
> > From: Christoffer Dall
> >
> > User space Android code
Hello,
syzbot found the following crash on:
HEAD commit:a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1480e36f80
kernel config: https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca
From: Roman Kiryanov
Address issues pointed by checkpatch.pl
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Updated the commit message to include "video: fbdev:" and added a
description.
drivers/video/fbdev/goldfishfb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
---
Changes in v7: None
Changes in v6: None
Changes in
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)
From: Christoffer Dall
User space Android code identifies pixclock == 0 as a sign for emulation
and will set the frame rate to 60 fps when reading this value, which is
the desired outcome.
Signed-off-by: Christoffer Dall
Signed-off-by: Peter Maydell
Signed-off-by: Roman Kiryanov
---
Changes
From: Yu Ning
Add an ACPI id to make goldfish framebuffer to support ACPI enumeration.
Signed-off-by: Yu Ning
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Removed references to commits outside of kernel.org.
- Updated the commit description.
drivers/video/fbdev/goldfishfb.c | 8
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Gustavo Padovan
Hi,
On Wed, Feb 28, 2018 at 01:25:58PM +0200, Tomi Valkeinen wrote:
> If we have no crtcs/connectors, fbdev init goes fine, but
> omap_fbdev_create() is never called. This means that omap_fbdev->bo is
> NULL and omap_fbdev_free() crashes.
>
> Add a check to omap_fbdev_free() to handle the NULL
Hi,
On Sat, May 26, 2018 at 08:24:22PM +0300, Laurent Pinchart wrote:
> From: Peter Ujfalusi
>
> As ordering of the dss_devices based on DT aliases is now implemented in
> omap_drm.c, there is no need to do the ordering in dss/display.c
> anymore.
>
> At the same time remove the alias member
On Fri, Jun 8, 2018 at 11:47 AM, Tomi Valkeinen wrote:
> Hi,
>
> On 22/05/18 21:13, Souptick Joarder wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are
https://bugs.freedesktop.org/show_bug.cgi?id=106879
Bug ID: 106879
Summary: Ugly bug present in kernels 4.14, 4.15, 4.16, 4.17
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106877
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
QA
https://bugzilla.kernel.org/show_bug.cgi?id=198713
Nicholas Johnson (nicholas.john...@outlook.com.au) changed:
What|Removed |Added
CC|
Hi Lee,
On 11/06/2018 08:03, Lee Jones wrote:
> On Fri, 08 Jun 2018, Hans Verkuil wrote:
>> On 08/06/18 10:17, Neil Armstrong wrote:
>>> On 08/06/2018 09:53, Hans Verkuil wrote:
On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Hi All,
>
> The new Google "Fizz" Intel-based ChromeOS
https://bugs.freedesktop.org/show_bug.cgi?id=106877
Samuel Pitoiset changed:
What|Removed |Added
Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon
QA
https://bugs.freedesktop.org/show_bug.cgi?id=106870
--- Comment #1 from Michel Dänzer ---
The attached dmesg looks like bug 106418.
Other than that, per https://bugs.freedesktop.org/show_bug.cgi?id=105251#c9 ,
try the latest microcode files from
https://bugs.freedesktop.org/show_bug.cgi?id=106418
Michel Dänzer changed:
What|Removed |Added
CC||ckoenig.leichtzumerken@gmai
https://bugs.freedesktop.org/show_bug.cgi?id=106871
Michel Dänzer changed:
What|Removed |Added
Attachment #140110|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=106871
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Uma,
Any progress on userspace for this?
I was thinking on working on using this in drm_hwcomposer.
Thank you,
Alex Gheorghe
On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote:
> This patch series adds properties for plane color features. It adds
> properties for degamma used to
On 11/06/18 10:56, Neil Armstrong wrote:
> Hi Lee,
>
> On 11/06/2018 08:03, Lee Jones wrote:
>> On Fri, 08 Jun 2018, Hans Verkuil wrote:
>>> On 08/06/18 10:17, Neil Armstrong wrote:
On 08/06/2018 09:53, Hans Verkuil wrote:
> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>> Hi All,
Hi Jani,
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 DRM_DP_AUX_CHARDEV was being invoke here? From
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
>
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
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
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: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
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: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: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: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: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: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 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.
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
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
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
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
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
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)
1 - 100 of 127 matches
Mail list logo
