On Mon, 10 Feb 2020 19:01:06 +
Emil Velikov wrote:
> Thanks for having a look Daniel.
>
> On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> >
> > On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > This commit reworks the permission handli
The driver currently uses runtime PM to perform some of the module
initialization and cleanup. This has three problems:
1) There is no Kconfig dependency on CONFIG_PM, so if runtime PM is
disabled, the driver will not work at all, since the module will
never be initialized.
2) The driver do
On Mon, Feb 10, 2020 at 10:53:10AM +0100, Gerd Hoffmann wrote:
> Move final cleanups from cirrus_pci_remove() to the new callback.
> Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
>
> Set pointers to NULL after iounmap() and check them before using
> them to make sure we don't touch
Currently, the DSI host blocks binding the display pipeline until the
panel is available. This unnecessarily prevents other display outpus
from working, and adds logspam to dmesg when the panel driver is built
as a module (the component master is unsuccessfully brought up several
times during boot)
This member is never used, so remove it.
Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
Signed-off-by: Samuel Holland
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 -
2 files changed, 5 deletions(-)
diff --git a
The continued use of an ERR_PTR to signify "no panel" outside of
sun6i_dsi_attach is confusing because it is a double negative. Because
the connector always reports itself as connected, there is also the
possibility of sending an ERR_PTR to drm_panel_get_modes(), which would
crash.
Solve both of t
Hi,
On Tue, Feb 11, 2020 at 01:28:58AM -0600, Samuel Holland wrote:
> The driver currently uses runtime PM to perform some of the module
> initialization and cleanup. This has three problems:
>
> 1) There is no Kconfig dependency on CONFIG_PM, so if runtime PM is
>disabled, the driver will not
On Mon, Feb 10, 2020 at 11:08:19AM +0100, Gerd Hoffmann wrote:
> Split virtio_gpu_deinit(), move the drm shutdown and release to
> virtio_gpu_release(). Also free vbufs in case we can't queue them.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> driver
On Mon, Feb 10, 2020 at 04:35:42PM +0100, Emmanuel Vadot wrote:
> Hello all,
>
> We had a discussion a while back with Noralf where he said that he wouldn't
> mind dual licence his work under GPL-2 and MIT.
> Those files are a problem with BSDs as we cannot include them.
> For drm_client.c the mai
On Tue, Feb 11, 2020 at 06:28:47AM +0100, Thomas Zimmermann wrote:
> Hi
>
> I'm surprised that prepare_fb is called with fb == NULL. But, OK
Yeah we don't filter that ... maybe an oversight? I'm not sure whether
there's any driver that needs to do something special for when the plane
is disabled
On Mon, Feb 10, 2020 at 12:16 PM Geert Uytterhoeven
wrote:
> On Sun, Jan 12, 2020 at 6:15 PM Geert Uytterhoeven
> wrote:
> > Replace the call to the custom non-existing function by a standard
> > BUILD_BUG() invocation.
> >
> > Suggested-by: Masahiro Yamada
> > Signed-off-by: Geert Uytterhoeven
Hi Ville,
On 10/02/2020 18:03, Ville Syrjälä wrote:
The usual approach we follow in i915 for things that affect more
than one plane is is to collect that state into the crtc state.
That way we get to remember it for the planes that are not part
of the current commit.
And when we have state tha
On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
> A recent commit in clang added -Wtautological-compare to -Wall, which is
> enabled for i915 so we see the following warning:
>
> ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning:
> result of comparison of constant 57646075230342
Call bochs_unload via drm_driver.release to make sure we release stuff
when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
touching hardware after device removal. Tidy up here and there.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 6 +++---
drivers/gpu/
Move final cleanups from cirrus_pci_remove() to the new callback.
Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
Use drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus.c | 43
On 13/01/2020 14:01, Tomi Valkeinen wrote:
On 12/12/2019 22:35, Laurent Pinchart wrote:
Hi Tomi,
On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote:
On 11/12/2019 18:53, Tony Lindgren wrote:
* Laurent Pinchart [191202 13:05]:
Hi Tomi,
Thank you for the patch.
On Thu, Nov 14, 2
Split virtio_gpu_deinit(), move the drm shutdown and release to
virtio_gpu_release(). Drop vqs_ready variable, instead use
drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal. Tidy up here and there.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> This is a eDP function and it will always returns true for non-eDP
> ports.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/
On 2/11/20 9:49 AM, Geert Uytterhoeven wrote:
> On Mon, Feb 10, 2020 at 12:16 PM Geert Uytterhoeven
> wrote:
>> On Sun, Jan 12, 2020 at 6:15 PM Geert Uytterhoeven
>> wrote:
>>> Replace the call to the custom non-existing function by a standard
>>> BUILD_BUG() invocation.
>>>
>>> Suggested-by:
[AMD Official Use Only - Internal Distribution Only]
For patch 1/2/3/5/6
Reviewed-by: xinhui pan
From: Christian König
Sent: Monday, February 10, 2020 11:09:01 PM
To: Pan, Xinhui ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
Subject: Cleanu
Hi Tomi,
On Tue, Feb 11, 2020 at 12:01:31PM +0200, Tomi Valkeinen wrote:
> On 13/01/2020 14:01, Tomi Valkeinen wrote:
> > On 12/12/2019 22:35, Laurent Pinchart wrote:
> >> On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote:
> >>> On 11/12/2019 18:53, Tony Lindgren wrote:
> * Laure
On Tue, Feb 11, 2020 at 01:08:12PM +0200, Tomi Valkeinen wrote:
> On 11/02/2020 13:07, Laurent Pinchart wrote:
>
> >> Hopefully soon (in five years? =) we can say that omapdrm supports all
> >> the boards, and we can deprecate omapfb.
> >
> > I'd love to send a patch to remove omapfb, but I'll le
On Tue, Feb 11, 2020 at 10:55:29AM +0100, Gerd Hoffmann wrote:
> Call bochs_unload via drm_driver.release to make sure we release stuff
> when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
> touching hardware after device removal. Tidy up here and there.
>
> Signed-off-by: Gerd H
On Tue, Feb 11, 2020 at 11:06:53AM +, Pan, Xinhui wrote:
> [AMD Official Use Only - Internal Distribution Only]
Uh might want to fix your email setup.
-Daniel
>
> For patch 1/2/3/5/6
> Reviewed-by: xinhui pan
>
> From: Christian König
> Sent: Monday, Februa
On Mon, Feb 10, 2020 at 10:47:36AM +0100, Thomas Zimmermann wrote:
> Hi,
>
> I smoke-tested the patchset by running X11, Weston and fbdev emulation
> on ast and udl. No apparent problems found, so
>
> Tested-by: Thomas Zimmermann
Merged patches 2-5 (first one needs to wait for amdgpu/radeon pat
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> TGL timeouts when disabling MST transcoder and fifo underruns over
> MST
> transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> mode) during the disable sequence.
>
> Although BSpec disable sequence don't require thi
On 11/02/2020 13:07, Laurent Pinchart wrote:
Hopefully soon (in five years? =) we can say that omapdrm supports all
the boards, and we can deprecate omapfb.
I'd love to send a patch to remove omapfb, but I'll let you do the
honours :-)
Not before we add DSI support to omapdrm...
Tomi
--
T
On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen wrote:
>
> On Mon, 10 Feb 2020 19:01:06 +
> Emil Velikov wrote:
>
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > > > From
On Mon, 10 Feb 2020 at 21:54, Daniel Vetter wrote:
>
> On Mon, Feb 10, 2020 at 8:01 PM Emil Velikov wrote:
> >
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > > > From: Em
On Mon, 10 Feb 2020 at 08:10, Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.02.20 um 17:41 schrieb Daniel Vetter:
> > On Fri, Feb 07, 2020 at 03:16:02PM +0100, Thomas Zimmermann wrote:
> >> Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
> >> the set function, drm_helper_connector_d
On Thursday, 2020-02-06 17:46:36 +, Li, Juston wrote:
> On Wed, 2020-02-05 at 23:27 +, Eric Engestrom wrote:
> > On Wednesday, 2020-02-05 23:10:21 +, Li, Juston wrote:
> > > On Wed, 2020-02-05 at 22:25 +, Eric Engestrom wrote:
> > > > On Friday, 2020-01-31 13:41:09 -0800, Juston Li
Add compatible to panel-simple for Rocktech Displays Limited
RK101II01D-CT 10.1" TFT 1280x800 Pixels with LVDS interface, LED
Backlight, and capacitive touch panel ("goodix,gt928" compatible).
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1
Add support for Rocktech RK101II01D-CT panel to panel-simple and add
yaml binding for it.
Changes since v2:
- No separate binding document, just add new compatible to panel-simple.yaml
Changes since first fersion:
- Move to yaml binding
Jyri Sarha (2):
dt-bindings: panel-simple: Add rocktech,r
Add support for Rocktech RK101II01D-CT, 10.1" 1280x800 TFT with LVDS
interface, LED backlight and integrated Goodix GT928 capacitive touch
panel.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32
Drop the virtio_gpu_{disable,enable}_notify(). Add a new
virtio_gpu_notify() call instead, which must be called whenever
the driver wants make sure the host is notified needed.
Drop notification from command submission. Add virtio_gpu_notify()
calls everywhere instead. This results in more batc
Hi,
> @@ -541,6 +539,7 @@ void virtio_gpu_cmd_unref_resource(struct
> virtio_gpu_device *vgdev,
> cmd_p->resource_id = cpu_to_le32(resource_id);
>
> virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
> + virtio_gpu_commit_ctrl(vgdev);
> }
Well, I was more thinking about adding that
On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> Hi Ville,
>
> On 10/02/2020 18:03, Ville Syrjälä wrote:
>
> > The usual approach we follow in i915 for things that affect more
> > than one plane is is to collect that state into the crtc state.
> > That way we get to remember it f
[SNIP]
+ /*
+* Make NO_EVICT bos immediately available to
+* shrinkers, now that they are queued for
+* destruction.
+*/
+ if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT) {
+ bo->mem.pl
This patch reworks the whole delayed deletion of BOs which aren't idle.
Instead of having two counters for the BO structure we resurrect the BO
when we find that a deleted BO is not idle yet.
This has many advantages, especially that we don't need to
increment/decrement the BOs reference counter
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> @@ -1364,11 +1372,15 @@ int intel_hdmi_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> static int intel_hdmi_hdcp_read_bksv(struct intel_digital_port
> *intel_dig_port,
>u8 *bksv)
> {
> + stru
Add missing virtio_gpu_array_lock_resv() call.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index ac42c84d2d7f..d1c3f5fbfee4 100644
---
Gerd Hoffmann (2):
drm/virtio: fix virtio_gpu_execbuffer_ioctl locking
drm/virtio: fix virtio_gpu_cursor_plane_update().
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
2 files changed, 11 insertions(+), 10 deletions(-)
--
Lockdep says we can't call vmemdup() while having objects reserved
because it needs the mmap semaphore. So reorder the calls reserve
the objects later.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletio
Call bochs_unload via drm_driver.release to make sure we release stuff
when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
touching hardware after device removal. Tidy up here and there.
v4: add changelog.
v3: use drm_dev_*().
v2: move hardware deinit to pci_remove().
Signed-off-
Move final cleanups from cirrus_pci_remove() to the new callback.
Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
Use drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal.
v4: add changelog.
v3: use drm_dev*.
v2: stop touching hardware after pci_remove().
Sig
Split virtio_gpu_deinit(), move the drm shutdown and release to
virtio_gpu_release(). Drop vqs_ready variable, instead use
drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal. Tidy up here and there.
v4: add changelog.
v3: use drm_dev_*().
Signed-off-by: Gerd Hoffmann
-
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> @@ -5990,11 +6040,13 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
> u8 *bksv)
> {
> + struct intel_
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> Conversion of instances of the printk based drm logging macros to the
> struct drm_device based logging macros in i915/display/intel_dp_mst.c.
> This also involves extracting the drm_i915_private device pointer from
> various intel types to use in the ma
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> Conversion of the printk based drm logging macros to the struct
> drm_device based logging macros in display/intel_dp_aux_backlight.c.
> This also involves extracting the drm_i915_private device pointer from
> various intel types to use in the macros.
>
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> This patchset continues the conversion of the printk based drm logging
> macros in drm/i915 to use the struct drm_device based logging macros.
> This series was done both using coccinelle and manually.
Thank you for the patches! I pushed all the patches
Reviewed-by: xinhui pan
> 2020年2月11日 21:43，Christian König 写道：
>
> This patch reworks the whole delayed deletion of BOs which aren't idle.
>
> Instead of having two counters for the BO structure we resurrect the BO
> when we find that a deleted BO is not idle yet.
>
> This has many advantages
On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
>
> v2: move that to ttm_bo_individualize_resv
>
> Signed-off-by: Christian König
> ---
> d
On Tue, Feb 11, 2020 at 02:52:18PM +0100, Gerd Hoffmann wrote:
> Call bochs_unload via drm_driver.release to make sure we release stuff
> when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
> touching hardware after device removal. Tidy up here and there.
>
> v4: add changelog.
>
On Tue, Feb 11, 2020 at 02:55:22PM +0100, Gerd Hoffmann wrote:
> Move final cleanups from cirrus_pci_remove() to the new callback.
> Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
>
> Use drm_dev_{enter,exit,unplug} to avoid touching hardware after
> device removal.
>
> v4: add cha
On Tue, Feb 11, 2020 at 02:58:04PM +0100, Gerd Hoffmann wrote:
> Split virtio_gpu_deinit(), move the drm shutdown and release to
> virtio_gpu_release(). Drop vqs_ready variable, instead use
> drm_dev_{enter,exit,unplug} to avoid touching hardware after
> device removal. Tidy up here and there.
>
There is no real reason to require drivers to set and use
dev->dev_private. Indeed, the current recommendation, as documented in
drm_device.h, is to embed struct drm_device in the per-device struct
instead of using dev_private.
Remove the requirement for dev_private to have been set to indicate
dr
Hello Ramalingam C,
The patch 6498bf5800a3: "drm: revocation check at drm subsystem" from
May 7, 2019, leads to the following static checker warning:
drivers/gpu/drm/drm_hdcp.c:195 drm_hdcp_parse_hdcp2_srm()
warn: mask and shift to zero
drivers/gpu/drm/drm_hdcp.c
190
> 2020年2月11日 22:14，Daniel Vetter 写道：
>
> On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
>> When non-imported BOs are resurrected for delayed delete we replace
>> the dma_resv object to allow for easy reclaiming of the resources.
>>
>> v2: move that to ttm_bo_individualize_res
On Tue, Feb 11, 2020 at 04:47:53PM +0200, Jani Nikula wrote:
> There is no real reason to require drivers to set and use
> dev->dev_private. Indeed, the current recommendation, as documented in
> drm_device.h, is to embed struct drm_device in the per-device struct
> instead of using dev_private.
>
Am 11.02.20 um 15:14 schrieb Daniel Vetter:
On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that to ttm_bo_individualize_resv
Signed-
Am 11.02.20 um 16:02 schrieb Pan, Xinhui:
2020年2月11日 22:14，Daniel Vetter 写道：
On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that
On Tue, Feb 11, 2020 at 4:23 PM Christian König
wrote:
>
> Am 11.02.20 um 16:02 schrieb Pan, Xinhui:
> >
> >> 2020年2月11日 22:14，Daniel Vetter 写道：
> >>
> >> On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
> >>> When non-imported BOs are resurrected for delayed delete we replace
> >
On Fri, Jan 31, 2020 at 12:00 AM Akhil P Oommen wrote:
>
> On 1/24/2020 11:56 PM, Jordan Crouse wrote:
> > On Fri, Jan 24, 2020 at 05:50:11PM +0530, Akhil P Oommen wrote:
> >> Highest bank bit configuration is different for a618 gpu. Update
> >> it with the correct configuration which is the reset
On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> > Hi Ville,
> >
> > On 10/02/2020 18:03, Ville Syrjälä wrote:
> >
> > > The usual approach we follow in i915 for things that affect more
> > > than one plane is is to
On Tue, Feb 11, 2020 at 04:40:21PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> > > Hi Ville,
> > >
> > > On 10/02/2020 18:03, Ville Syrjälä wrote:
> > >
> > > > The usual approac
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that to ttm_bo_individualize_resv
v3: add a comment to explain what's going on
Signed-off-by: Christian König
Reviewed-by: xinhui pan
---
drivers/gpu/
On Tue, Feb 11, 2020 at 11:46:26AM +, Emil Velikov wrote:
> On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen wrote:
> >
> > On Mon, 10 Feb 2020 19:01:06 +
> > Emil Velikov wrote:
> >
> > > Thanks for having a look Daniel.
> > >
> > > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > > >
On Mon, Feb 10, 2020 at 9:58 PM wrote:
>
> On 2020-02-07 19:40, Jeffrey Hugo wrote:
> > On Fri, Feb 7, 2020 at 5:38 AM wrote:
> >>
> >> On 2020-02-06 20:29, Jeffrey Hugo wrote:
> >> > On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P
> >> > wrote:
> >> >>
> >> >> For a given byte clock, if VCO recal
On Tue, Feb 11, 2020 at 04:43:26PM +0100, Christian König wrote:
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
>
> v2: move that to ttm_bo_individualize_resv
> v3: add a comment to explain what's going on
Hi Jyri
On Tue, Feb 11, 2020 at 02:17:16PM +0200, Jyri Sarha wrote:
> Add support for Rocktech RK101II01D-CT panel to panel-simple and add
> yaml binding for it.
>
> Changes since v2:
> - No separate binding document, just add new compatible to panel-simple.yaml
>
> Changes since first fersion:
The patch
drm/mediatek: support HDMI jack status reporting
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) a
The patch
ASoC: mediatek: mt8173-rt5650: support HDMI jack reporting
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 2
The patch
drm/mediatek: exit earlier if failed to register audio driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the nex
On 2/10/20 4:50 PM, Luben Tuikov wrote:
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I didn't find this objection in my mail actually
I suggested to instead use a _list_ to store
Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.
This behavior is not accurate; actually, we need to return
the actual CRC value when co
Ping?
Alex
On Fri, Feb 7, 2020 at 4:17 PM Alex Deucher wrote:
>
> Split into init and register functions to avoid a segfault
> in some configs when the load/unload callbacks are removed.
>
> v2:
> - add back accidently dropped has_aux setting
> - set dev in late_register
>
> v3:
> - fix dp cec o
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
v2: Adjust the FIXME (Daniel)
Cc: Philipp Zabel
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/imx/im
From: Ville Syrjälä
Another respin of the possible_clones/crtcs fixing.
Changes based on v2 review:
- introduce drm_mode_config_validate()
- WARN for possible_clones!=0 when the encoder
itself isn't in the mask
- update the documentation to match the code
Other changes:
- sligth refactoring o
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Acked-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2 i
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
v2: Move to drm_mode_config_validate() (Daniel)
Make the docs say we WARN when this is wrong (Daniel)
Extract full_crtc_mask()
Cc: Thomas Zimmermann
Cc: Daniel Vetter
S
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about effecti
From: Ville Syrjälä
Let's simplify life of driver by allowing them to leave
encoder->possible_crtcs unset if they have no restrictions
in crtc<->encoder linkage. We'll just populate possible_crtcs
with the full crtc mask when registering the encoder so that
userspace doesn't have to deal with dri
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into drm_encoder_i
On Mon, Feb 10, 2020 at 10:38 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
> In function dcn10_post_unlock_program_front_end:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2623:29:
> warning: variable stream_status set but
On 11/02/2020 18:05, Tony Lindgren wrote:
* Merlijn Wajer [200211 12:54]:
Hi,
On 11/02/2020 12:08, Tomi Valkeinen wrote:
On 11/02/2020 13:07, Laurent Pinchart wrote:
Hopefully soon (in five years? =) we can say that omapdrm supports all
the boards, and we can deprecate omapfb.
I'd love to
On Tue, 11 Feb 2020, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 04:47:53PM +0200, Jani Nikula wrote:
>> There is no real reason to require drivers to set and use
>> dev->dev_private. Indeed, the current recommendation, as documented in
>> drm_device.h, is to embed struct drm_device in the per-
On Tue, Feb 11, 2020 at 06:22:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll fi
On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Many drivers are populating encoder->possible_clones wrong. Let's
> persuade them to get it right by adding some loud WARNs.
>
> We'll cross check the bits between any two encoders. So either
> both encoders
On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> v2: Move to drm_mode_config_validate() (Daniel)
> Make the docs say we WARN when this is wrong (Dani
On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's simplify life of driver by allowing them to leave
> encoder->possible_crtcs unset if they have no restrictions
> in crtc<->encoder linkage. We'll just populate possible_crtcs
> with the full crtc mask w
On Tue, Feb 11, 2020 at 06:02:33PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Many drivers are populating encoder->possible_clones wrong. Let's
> > persuade them to get it right by adding some loud WARNs.
> >
> > W
On Tue, Feb 11, 2020 at 06:05:45PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's simplify life of driver by allowing them to leave
> > encoder->possible_crtcs unset if they have no restrictions
> > in crtc<->enco
On 2/10/20 3:35 PM, Ben Skeggs wrote:
On Tue, 11 Feb 2020 at 09:17, James Jones wrote:
On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
I've sent out a v4 version of the format modifier patches wh
On 11/02/2020 18:27, Tony Lindgren wrote:
We are still missing DSI command mode support, and moving it to the common DRM
model.
Nope, DSI command mode support has been working just fine for
a while now :) And Sebastian has a WIP git tree of the common DRM
Indeed... It had been going on for
Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.
So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that we
The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can
According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls dep
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but
a) delta: Adds DRM_IOCTL_MODE_GETFB2
b) Generated using make headers_install
c) Taken from drm-next-misc:
commit 3ff4c24bdb1f494c217c80348f9db4896043ed81
Author: Lyude Paul
Date: Fri Jan 17 17:47:48 2020 -0500
drm/dp_mst: Fix indenting in drm_dp_mst_topolog
1 - 100 of 120 matches
Mail list logo
