Hi Giulio,
On Thu, 15 Feb 2018 at 17:54, Giulio Benetti
wrote:
>
> Differently from other Lcd signals, HSYNC and VSYNC signals
> result inverted if their bits are cleared to 0.
>
> Invert their settings of IO_POL register.
>
> Signed-off-by: Giulio Benetti
> ---
> drivers/gpu/drm/sun4i/sun4i_tc
_dpu_crtc_vblank_enable_no_lock releases crtc_lock as
its needed for power handle operations. This opens up a
window where in a thread running dpu_crtc_disable and a thread
running dpu_crtc_vblank can race in using dpu_crtc->enabled.
dpu_crtc_disable will change the state, where as dpu_crtc_vblank
https://bugs.freedesktop.org/show_bug.cgi?id=108100
--- Comment #8 from Jure Repinc ---
Created attachment 142738
--> https://bugs.freedesktop.org/attachment.cgi?id=142738&action=edit
Xorg.0.log
Xorg.0.log from Linux kernel 4.19.4
--
You are receiving this mail because:
You are the assignee
Add the display nodes containing information about the panel,
DSI configuration and board specific pin configuration to the
SDM845 MTP device tree file.
This patch depends on the following:
https://patchwork.freedesktop.org/series/51909/
Changes in v4:
- patch introduced in the series
On Thu, 2018-12-06 at 10:40 +0800, Zhang, Jerry(Junwei) wrote:
> On 12/6/18 12:56 AM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > The following cases are possible for pr_debug():
> >
> > 1. CONFIG_DYNAMIC_DEBUG disabled
> > a) DEBUG not defined: pr_debug() translates to no_printk(..
On 12/6/18 12:56 AM, Michel Dänzer wrote:
From: Michel Dänzer
All the output is related, so it should all be printed the same way.
Some of it was using pr_debug, but some of it appeared in dmesg by
default. The caller should handle failure, so there's no need to spam
dmesg with potentially quit
On 12/6/18 12:56 AM, Michel Dänzer wrote:
From: Michel Dänzer
The following cases are possible for pr_debug():
1. CONFIG_DYNAMIC_DEBUG disabled
a) DEBUG not defined: pr_debug() translates to no_printk(...), i.e.
it never generates any output.
b) DEBUG defined: pr_debug() transla
~~~
Caused by commit
0b258ed1a219 ("drm: revert "expand replace_fence to support timeline point
v2"")
interacting with commit
1584f16ca96e ("drm/v3d: Add support for submitting jobs to the TFU")
I have used the drm-misc tree from next-20181205 for today.
--
C
From: Jérôme Glisse
The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
C
On Wed, 2018-12-05 at 12:30 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-12-05 at 10:48 -0800, José Roberto de Souza wrote:
> > The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this
> > warning when generating kernel documentation.
> >
> > ./include/drm/drm_dp_helper.h:1374: warning:
On 2018-12-05 6:04 p.m., Jerome Glisse wrote:
> On Wed, Dec 05, 2018 at 09:42:45PM +, Kuehling, Felix wrote:
>> The amdgpu part looks good to me.
>>
>> A minor nit-pick in mmu_notifier.c (inline).
>>
>> Either way, the series is Acked-by: Felix Kuehling
>>
>> On 2018-12-05 12:36 a.m., jgli...@
On Wed, Dec 05, 2018 at 09:42:45PM +, Kuehling, Felix wrote:
> The amdgpu part looks good to me.
>
> A minor nit-pick in mmu_notifier.c (inline).
>
> Either way, the series is Acked-by: Felix Kuehling
>
> On 2018-12-05 12:36 a.m., jgli...@redhat.com wrote:
> > From: Jérôme Glisse
> >
> > T
Applied. thanks!
Alex
On Wed, Dec 5, 2018 at 2:02 PM Lyude Paul wrote:
>
> Reviewed-by: Lyude Paul
>
> Thanks!
>
> On Wed, 2018-12-05 at 15:43 +0800, Wen Yang wrote:
> > kfree(NULL) is safe, so removes NULL check before freeing the mem.
> > This patch also fix the ifnullfree.cocci warnings.
> >
On 11/30/18 6:43 AM, Yangtao Li wrote:
seq_file.h does not need to be included,so remove it.
Acked-by: Laura Abbott
Signed-off-by: Yangtao Li
---
drivers/staging/android/ion/ion.c | 1 -
drivers/staging/android/ion/ion_system_heap.c | 1 -
2 files changed, 2 deletions(-)
d
The amdgpu part looks good to me.
A minor nit-pick in mmu_notifier.c (inline).
Either way, the series is Acked-by: Felix Kuehling
On 2018-12-05 12:36 a.m., jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> To avoid having to change many callback definition everytime we want
> to add a parame
On Wed, Dec 05, 2018 at 10:03:09PM +0100, Hans de Goede wrote:
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
>
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to
Add support for PMIC mipi sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans d
Hi All,
This series is the result of me debugging and fixing the LCD panel not
lighting up on some CHT devices when they are booted with an external
monitor connected and the GOP only initializes the external monitor,
leaving the LCD uninitialized.
This is caused by the lack of support for execut
https://bugs.freedesktop.org/show_bug.cgi?id=108956
--- Comment #1 from Alex Deucher ---
Please attach your dmesg output and xorg log if using X.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-d
On Wed, Dec 5, 2018 at 2:44 PM Christian König
wrote:
>
> I missed one case during the recent revert of the replace_fence
> interface change.
>
> Fixes: 0b258ed1a219 drm: revert "expand replace_fence to support timeline
> point v2"
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> --
On Wed, 2018-12-05 at 10:48 -0800, José Roberto de Souza wrote:
> The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this
> warning when generating kernel documentation.
>
> ./include/drm/drm_dp_helper.h:1374: warning: Incorrect use of kernel-
> doc format: * @DP_DPCD_QUIRK_NO_PSR
Hi Dave,
drm-misc fixes for this week. Big item is the lease uevent change. It seems like
there's a high degree of confidence that existing userspaces will be happy with
any uevent, so it should be a non-issue. Nevertheless, it hasn't soaked for very
long, so something to keep an eye on.
drm-misc
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.
For instances using of_node_cmp, this has the side effect of now using
case sensitive comparisons. This should not matter for any FDT based
system which omap is.
Cc
https://bugs.freedesktop.org/show_bug.cgi?id=108956
Bug ID: 108956
Summary: After 11 seconds, 3 second video freeze
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sever
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.
For instances using of_node_cmp, this has the side effect of now using
case sensitive comparisons. This should not matter for any FDT based
system which this is.
Cc
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.
For instances using of_node_cmp, this has the side effect of now using
case sensitive comparisons. This should not matter for any FDT based
system which this is.
Cc
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #11 from magiblot ---
(In reply to Pekka Paalanen from comment #10)
If all you need is a tester, I'm up for anything.
Is there any simple way (e.g. using a PKGBUILD file) to compile weston with
undefined HAVE_GBM_MODIFIERS?
Thanks
I missed one case during the recent revert of the replace_fence
interface change.
Fixes: 0b258ed1a219 drm: revert "expand replace_fence to support timeline point
v2"
Signed-off-by: Christian König
---
drivers/gpu/drm/v3d/v3d_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Hi Dave,
I'm guest-robclarking for msm for this PR. I've been tracking a bunch of display
stuff for dpu and it am able to take a bit off Rob's plate by collecting the
fixes that have trickled in over the past while.
We've got a bunch of dpu-specific fixes since rc1, but I've deferred most of
them
Hi Dave,
Fixes for 4.20:
- Fix banding regression on 6 bpc panels
- Vega20 fix for six 4k displays
- Fix LRU handling in ttm_buffer_object_transfer
- Use proper MC firmware for newer polaris variants
- Vega20 powerplay fixes
- VCN suspend/resume fix for PCO
- Misc other fixes
The following change
Reviewed-by: Lyude Paul
Thanks!
On Wed, 2018-12-05 at 15:43 +0800, Wen Yang wrote:
> kfree(NULL) is safe, so removes NULL check before freeing the mem.
> This patch also fix the ifnullfree.cocci warnings.
>
> Signed-off-by: Wen Yang
> CC: Alex Deucher
> CC: christian.koe...@amd.com
> CC: "Dav
This reverts commit 7f3ef5dedb146e3d5063b6845781ad1bb59b92b5.
It causes new warnings [1] on shutdown when running the Google Kevin or
Scarlet (RK3399) boards under Chrome OS. Presumably our usage of DRM is
different than what Marc and Heiko test.
We're looking at a different approach (e.g., [2])
On Wed, Dec 05, 2018 at 03:11:03PM +0100, Heiko Stuebner wrote:
> Can you maybe give "drm/rockchip: shutdown drm subsystem on shutdown" [2]
> a try? When the underlying issue of rebooting surfaced we had 2 competing
> solutions, so we at least don't reopen the issue, that people have problems
> re
Hi,
On Wed, Dec 05, 2018 at 02:28:48PM +, Marc Zyngier wrote:
> On 05/12/2018 14:11, Heiko Stübner wrote:
> > Am Mittwoch, 5. Dezember 2018, 04:01:34 CET schrieb Brian Norris:
> >> On Sun, Aug 05, 2018 at 01:48:07PM +0100, Marc Zyngier wrote:
> >>> Leaving the DRM driver enabled on reboot or k
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #24 from Jan Burgmeier ---
I tested with a shorter DP cable but the error still occurs. I don't think it
is a cable/hardware problem as the same hardware with kernel parameter dc=0
works just fine.
I tried a Ubuntu 18.04 live stick
From: Michel Dänzer
The following cases are possible for pr_debug():
1. CONFIG_DYNAMIC_DEBUG disabled
a) DEBUG not defined: pr_debug() translates to no_printk(...), i.e.
it never generates any output.
b) DEBUG defined: pr_debug() translates to printk(KERN_DEBUG ...),
i.e. it ge
From: Michel Dänzer
All the output is related, so it should all be printed the same way.
Some of it was using pr_debug, but some of it appeared in dmesg by
default. The caller should handle failure, so there's no need to spam
dmesg with potentially quite a lot of output by default.
Signed-off-by
On Wed 05-12-18 11:40:52, Jerome Glisse wrote:
> On Wed, Dec 05, 2018 at 05:35:20PM +0100, Jan Kara wrote:
> > On Wed 05-12-18 00:36:26, jgli...@redhat.com wrote:
> > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> > > index 5119ff846769..5f6665ae3ee2 100644
> > > --- a/mm/mmu_notifier.c
> >
On Wed 05-12-18 00:36:27, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> To avoid having to change many call sites everytime we want to add a
> parameter use a structure to group all parameters for the mmu_notifier
> invalidate_range_start/end cakks. No functional changes with this
> patch.
Commit 3e407417b192 ("drm/vc4: Fix X/Y positioning of planes using
T_TILES modifier") fixed the problem with T_TILES format, but left
things in a non-working state for SAND formats. Address that now.
Signed-off-by: Boris Brezillon
---
Hi Eric,
So, I finally spent time debugging my SANDXXX patter
Add support for X/Y reflection when the plane is using linear or T-tiled
formats. X/Y reflection hasn't been tested on SAND formats, so we reject
them until proper testing/debugging has been done.
Signed-off-by: Boris Brezillon
---
Eric, I dropped your Reviewed-by as this version also contains su
On Wed, Dec 05, 2018 at 05:35:20PM +0100, Jan Kara wrote:
> On Wed 05-12-18 00:36:26, jgli...@redhat.com wrote:
> > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> > index 5119ff846769..5f6665ae3ee2 100644
> > --- a/mm/mmu_notifier.c
> > +++ b/mm/mmu_notifier.c
> > @@ -178,14 +178,20 @@ int __
On Wed 05-12-18 00:36:26, jgli...@redhat.com wrote:
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 5119ff846769..5f6665ae3ee2 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -178,14 +178,20 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
>
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++-
drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c | 10 +--
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 4 +-
drivers/
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +++
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 --
drivers/
From: Sean Paul
mdp5 only exposes one custom property, and it's zpos.
Fortunately, we have a standard zpos property now, we can remove
the hand-rolled property code entirely from mdp5 and rely on core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
drivers/gp
From: Sean Paul
It's always 0, and not exposed via property, so remove it and all
affected code.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 1 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 --
dr
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 3 ---
drivers/gpu/drm/msm/dsi/dsi.c| 2 --
d
On Wed 05-12-18 10:53:57, Jerome Glisse wrote:
> On Wed, Dec 05, 2018 at 12:04:16PM +0100, Jan Kara wrote:
> > Hi Jerome!
> >
> > On Mon 03-12-18 15:18:16, jgli...@redhat.com wrote:
> > > From: Jérôme Glisse
> > >
> > > To avoid having to change many call sites everytime we want to add a
> > > p
From: Sean Paul
Just call drm_plane_create_rotation_property() directly
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/
From: Sean Paul
It's always 0xFF, so remove it and any code that relies on it being
!= 0xFF.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 27 ++
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 1 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 -
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/dsi/dsi.c | 1 -
drivers/gpu/drm/msm/edp/edp.c | 1 -
drivers/gpu/drm/msm/hdmi/hdmi.c | 1 -
drivers/gpu/drm/msm/msm_drv.h | 3 ---
4
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 16
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |
In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pending work if not
scheduled.
Signed-off-by: Jay
On Wed, 2018-12-05 at 04:35 -0500, Sasha Levin wrote:
> From: "Y.C. Chen"
[]
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
[]
> @@ -973,9 +973,21 @@ static int get_clock(void *i2c_priv)
> {
> struct ast_i2c_chan *i2c = i2c_priv;
> struct ast_private *a
On Wed, Dec 05, 2018 at 12:04:16PM +0100, Jan Kara wrote:
> Hi Jerome!
>
> On Mon 03-12-18 15:18:16, jgli...@redhat.com wrote:
> > From: Jérôme Glisse
> >
> > To avoid having to change many call sites everytime we want to add a
> > parameter use a structure to group all parameters for the mmu_no
On Wed, Dec 05, 2018 at 09:36:54AM +0100, Paul Kocialkowski wrote:
> This introduces stride and offset configuration for the VPU tiling mode.
> Stride is calculated differently than it is for linear formats and an
> offset is calculated, for which new register definitions are introduced.
>
> Signe
On Wed, Dec 05, 2018 at 09:36:47AM +0100, Paul Kocialkowski wrote:
> Both the backend and the frontend need the BT.601 CSC coefficients for
> YUV to RGB conversion. Since the backend has a dependency on the
> frontend (and not the other way round), move the coefficients there
> so that both can acc
On Wed, Dec 05, 2018 at 09:36:46AM +0100, Paul Kocialkowski wrote:
> Since all the RGB input formats have the same value for the DATA_FMT
> field of the INPUT_FMT register, we can group them when the format is
> known to be RGB. Here, we assume that a non-YUV format is RGB, because
> the hardware d
On Wed, Dec 05, 2018 at 09:36:48AM +0100, Paul Kocialkowski wrote:
> In prevision of adding support for YUV formats, set the YUV to RGB
> colorspace conversion coefficients if required and don't bypass the
> CSC engine when converting.
>
> The BT601 coefficients from the A33 BSP are copied over fr
On Wed, Dec 05, 2018 at 09:36:45AM +0100, Paul Kocialkowski wrote:
> The helper returning the input mode needs to know the number of planes
> for the provided format. Passing the fourcc requires iterating through
> the format info list in order to return the number of planes.
>
> Pass the DRM form
https://bugs.freedesktop.org/show_bug.cgi?id=108940
--- Comment #5 from fin4...@hotmail.com ---
Manjaro Linux is for Nvidia gpus. For Amd gpus, it has too old kernel and Mesa.
Use Debian sid Xfce with a latest custom kernel from kernel.org or
https://cgit.freedesktop.org/~agd5f/linux and the Oibaf
On Wed, Dec 05, 2018 at 08:40:34AM +0100, Andrzej Hajda wrote:
> On 04.12.2018 20:02, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> >> On 03.12.2018 22:48, Ville Syrjälä wrote:
> >>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> Qu
Mhm, looks like DC calling TTM here without going through the pin function?
Anyway, I'm going to revert the patch for now. Looks like I really need
to test this with eviction turned on.
Christian.
Am 05.12.18 um 15:58 schrieb Michel Dänzer:
On 2018-12-05 9:38 a.m., Christian König wrote:
Ma
The field is only used in a safety check during device
connection/disconnection, where the src field can be easily used
instead. Remove it and use src.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c| 6 ++
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
2 files chang
The TV encoder supports both PAL and NTSC modes, but when queried for
the list of modes it supports, only the currently selected mode is
reported. Fix it and report the two modes unconditionally.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 25 +++-
Now that the .get_modes() operations takes a drm_connector and fills it
with modes, it becomes easy to fill display information in the same
operation without requiring a separate .get_size() opearation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 14 +++-
The DPI and SDI encoders store the full videomode upon mode set, to only
use the value of the pixel clock when enabling the encoder. This wastes
memory. Store the pixel clock value only.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 9 -
drivers/gpu/drm/omapdrm/
Replace internal usage of struct videomode with struct drm_display_mode
in order to avoid converting needlessly between the data structures.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 82 ++
1 file changed, 38 insertions(+), 44 deletions(
The omap_dss_device .check_timings() and .set_timings() operations
operate on struct videomode, while the DRM API operates on struct
drm_display_mode. This forces conversion from to videomode in the
callers. While that's not a problem per se, it creates a difference with
the drm_bridge API.
Replac
omap_dss_device operations expose fixed video timings through a
.get_timings() operation that return a single timing for the device. To
prepare for the move to drm_bridge, modify the API to instead add DRM
modes directly to the connector.
As this puts more burden on display devices, we also create
The DISPC timings checks relate to the CRTC, but they're performed in
the encoder and connector .atomic_check() and .mode_valid() operations.
Move them to the CRTC .mode_valid() operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c | 6 --
drivers/gpu/drm/om
Now that the direction of OF graph walk has been reversed, there's no
need to lookup devices by port as we have no sink device connected
through multiple sink ports. Simplify OF lookup of the DSS devices to
look them up by node only.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/ds
For HDMI pipelines, when the output gets disconnected the device
handling CEC needs to be notified. Instead of guessing which device that
would be (and sometimes getting it wrong), notify all devices in the
pipeline.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c |
The omapdrm driver initialization procedure starts by connecting all
available pipelines, gathering related information (such as output and
display DSS devices, and DT aliases), sorting them by alias, and finally
creates all the DRM/KMS objects.
When using DRM bridges instead of DSS devices, we wi
Instead of manually iterating over the dss devices in the pipeline to
find the first one that implements the .get_modes() operation, add a new
operation flag for .get_modes() and use the omap_connector_find_device()
helper function to locate the right dss device.
Signed-off-by: Laurent Pinchart
-
The source pointer will be removed to the omap_dss_device structure.
Store it internally in the DSI panel driver data.
Signed-off-by: Laurent Pinchart
---
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 55 ++-
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drive
The field is only used to check whether the device is connected, and we
can do so by checking the dss field instead. Remove the src field.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c| 14 +-
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
2 files changed,
Display pipelines based on drm_bridge are handled from the bridge
closest to the CRTC. To move to that model we thus need to transition
away from walking pipelines in the other direction, and from accessing
the device at the end of the pipeline when possible.
Remove most accesses to the display de
The DT bindings for the OMAP DSS allow assigning numerical IDs to
display outputs through display entries in the alias node. The driver
uses this information to sort pipelines according to the order specified
in DT, making it possible for a system to give a priority order to
outputs.
Retrieval of
Instead of rolling out custom suspend/resume implementations based on
state information stored in the driver's data structures, use the atomic
suspend/resume helpers that rely on a DRM atomic state object.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 --
drivers
Hello,
This patch series finishes the large omapdrm refactoring started in v4.17 to
transition from the omapdrm-specific encoder and panel drivers to drm_bridge
and drm_panel. While more changes will follow, the next patch series will
focus on the usage of the first drm_bridge driver (for the tftp
The encoder .atomic_check() and connector .mode_valid() operations both
walk through the dss devices in the pipeline to validate the mode.
Factor out the common code in a new omap_drm_connector_mode_fixup()
function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.c |
All .enable() and .disable() handlers for panels and connectors share
common code that validates and updates the device's state. Move it to
common locations in the omap_encoder_enable() and omap_encoder_disable()
handlers.
The enabled check in the .disable() handler is left untouched, it will
be a
The kobj field from struct omap_dss_device is not used. Remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 1f698a95a94a..d3b
The internal encoders return an error from their .enable() handler when
their are not connected to a dss manager. As the flag used is set and
cleared in the connect and disconnect handlers, this effectively checks
whether the omap_dss_device is connected.
The .enable() handler is called from code
The mode setting handler of the VENC stores the video mode internally,
to then convert it to a configuration when programming the hardware. The
stored mode is otherwise unused. Cache the configuration directly
instead.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 68 +
The display isn't used by the encoder implementation, don't pass it to
the initialization function and store it internally needlessly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/omapdrm/omap_encoder.c | 5 +
drivers/gpu/drm/omapdrm/omap
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 handle components from source to sink.
Reconcile the omapdrm and omapdss drivers
All the internal encoders share common init and cleanup code. Factor it
out to separate functions.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 17 +++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 17 +++--
drivers/gpu/drm/omapdrm/dss/hdmi4.c
The venc_device structure wss_data field is set to 0 and never otherwise
modified, remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/d
The displays (connectors, panels and encoders) return an error from
their .enable() handler when the dss device is not connected. They also
disconnect the dss device explicitly from their .remove() handler if it
is still connected.
Those safety checks are not needed:
- The .enable() handler is ca
The displays (connectors, panels and encoders) bail out from their
.enable() and .disable() handlers if the dss device is already enabled
or disabled. Those safety checks are not needed when the functions are
called through the omapdss_device_ops, as the .enable() and .disable()
handlers are called
The omap_connector_attached_encoder() doesn't exist anymore, remove its
declaration from omap_connector.h.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_connector.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.h
b/drivers/gpu/drm
On 2018-12-05 9:38 a.m., Christian König wrote:
> Make sure we reserve at least one slot for pipelined BO moves
> during BO creation.
>
> Fixes: 5786b66c9e3b drm/ttm: drop the extra reservation for pipelined BO
> moves
>
> Signed-off-by: Christian König
Unfortunately, I still hit a hang with pi
On Wed, Dec 5, 2018 at 2:42 PM Anton Ivanov
wrote:
> On 30/11/2018 03:14, Luis Chamberlain wrote:
> > On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote:
> > Then for the UML stuff, I think if we *really* accept that UML will
> > always be a viable option we should probably consider n
On Wed, Dec 05, 2018 at 09:46:40AM +0100, Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> >>> On 03.12.2018 22:38, Ville Syrj
Quoting Kuehling, Felix (2018-12-03 22:55:16)
>
> On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> > Quoting Ho, Kenny (2018-11-27 17:41:17)
> >> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
> >> wrote:
> >>> I think a more abstract property "% of GPU (processing power)" might
> >>> be a mor
1 - 100 of 208 matches
Mail list logo