On Tue, Feb 11, 2020 at 11:25 PM Andrew Lunn wrote:
> On Tue, Feb 11, 2020 at 10:41:20PM +0100, H. Nikolaus Schaller wrote:
> > This is needed to give the MIPS Ingenic CI20 board a stable MAC address
> > which can be optionally provided by vendor U-Boot.
> >
> > For get_mac_addr() we use an adapte
Hi, Tzung-Bi:
On Thu, 2020-02-06 at 11:17 +0800, Tzung-Bi Shih wrote:
> 1.
> Provides a callback (i.e. mtk_hdmi_audio_hook_plugged_cb) to hdmi-codec.
> When ASoC machine driver calls hdmi_codec_set_jack_detect(), the
> callback will be invoked to save plugged_cb and codec_dev parameters.
>
> +---
Not all drivers need to be compiled into the kernel.
Support building and loading of kernel modules.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/configs/ci20_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
in
This is needed to give the MIPS Ingenic CI20 board a stable MAC address
which can be optionally provided by vendor U-Boot.
For get_mac_addr() we use an adapted copy of from ksz884x.c which
has very similar functionality.
Signed-off-by: H. Nikolaus Schaller
---
drivers/net/ethernet/davicom/dm900
Interrupts should not be specified by interrupt line but by
gpio parent and reference.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/ci20.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/inge
> Am 12.02.2020 um 09:07 schrieb Geert Uytterhoeven :
>
> On Tue, Feb 11, 2020 at 11:25 PM Andrew Lunn wrote:
>> On Tue, Feb 11, 2020 at 10:41:20PM +0100, H. Nikolaus Schaller wrote:
>>> This is needed to give the MIPS Ingenic CI20 board a stable MAC address
>>> which can be optionally provided
This is a 3.3V regulator.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/ci20.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index e02a19db7ef1..e1364f941c7d 100644
--- a/arch/mips/boot/dts/
Hi Maxime,
On 2/11/20 2:26 AM, Maxime Ripard wrote:
> 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,
The PMU on the CI20 board is an ACT8600 using the ACT8865 driver.
Since it is not compiled, the PMU and the CI20 board is running in
power-on reset state of the PMU.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/configs/ci20_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/
Document the bindings used for the Cadence MHDP DPI/DP bridge in
yaml format.
Signed-off-by: Yuti Amonkar
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/cdns,mhdp.yaml| 125 ++
1 file changed, 125 insertions(+)
create mode 100644
Documentation/devicetree/bindings
* 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 send a patch
The CI20 board has a gpio based IR receiver.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/configs/ci20_defconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 74e5775b8a05..0458ea4d54e8 100644
--- a/arch/mi
On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
> 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_execbuf
The constants from irq.h and gpio.h can be used in the
jz4780.dtsi and derived DTS like ci20.dts.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/inge
This patch series adds new DRM driver for Cadence Display Port.
The Cadence Display Port is also referred as MHDP (Mobile High
Definition Link, High-Definition Multimedia Interface Display
Port) Cadence Display Port complies with VESA DisplayPort (DP)
and embedded Display Port (eDP) standards. This
* Tomi Valkeinen [200211 16:14]:
> 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
Maxime, thanks for your comments. I'll update the patch, but meanwhile,
I have some remarks/questions, see below.
On Tue, Feb 11, 2020 at 08:20:04AM +0100, Maxime Ripard wrote:
> > + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
> > + SUN4I_TCON0_LVDS_ANA1_UPDATE
This patch set provides several improvements for the CI20 board:
* suppress warnings from i2c if device is not responding
* make ingenic-drm found through DT
* allow davicom dm9000 ethernet controller to use MAC address provided by U-Boot
* fix #include in jz4780.dtsi
* configure for loadable kern
The SW1 button is hooked up to send input events.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/configs/ci20_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 0458ea4d54e8..0db0088bbc1c 100644
--- a/arch/mi
Add MODULE_DEVICE_TABLE so that the driver can load by
matching the device tree if compiled as module.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/inge
Add j721e wrapper for mhdp, which sets up the clock and data muxes.
Signed-off-by: Yuti Amonkar
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/bridge/Kconfig | 12
drivers/gpu/drm/bridge/Makefile | 3 +
drivers/gpu/drm/bridge/cdns-mhdp-core.c | 14 +
drivers/gpu/drm
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 send a patch to remove omapfb, but I'll let you do the
>> honou
On Tue, Feb 11, 2020 at 8:44 AM Rob Clark 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
I am getting a kernel build error at version 5.6-rc1:
drivers/gpu/drm/drm_edid.c: In function 'cea_mode_alternate_timings':
drivers/gpu/drm/drm_edid.c:3275:2: error: call to '__compiletime_assert_3282'
declared with attribute error: BUILD_BUG_ON failed: cea_mode_for_vic(8)->vtotal
!= 262 || cea_
This suppresses "simple" error reasons
ABRT_7B_ADDR_NOACK
ABRT_10ADDR1_NOACK
ABRT_10ADDR2_NOACK
from flooding the console log when running i2cdetect on
addresses without a responding slave.
Additionally, reading the JZ4780_I2C_TAR in this situation
seems to harm the contr
On 2/11/20 12:48 PM, Frank Rowand wrote:
> I am getting a kernel build error at version 5.6-rc1:
>
> drivers/gpu/drm/drm_edid.c: In function 'cea_mode_alternate_timings':
> drivers/gpu/drm/drm_edid.c:3275:2: error: call to '__compiletime_assert_3282'
> declared with attribute error: BUILD_BUG_ON
This patch adds new DRM driver for Cadence MHDP DPTX IP used on J721e SoC.
MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and
embedded Display Port (eDP) standards. It integrates uCPU running the
embedded Firmware(FW) interfaced over APB interface.
Basically, it takes a DPI
On Tue, Feb 11, 2020 at 5:28 PM Rob Clark wrote:
>
> On Tue, Feb 11, 2020 at 7:59 AM Jeffrey Hugo wrote:
> >
> > On Tue, Feb 11, 2020 at 8:44 AM Rob Clark wrote:
> > >
> > > On Mon, Feb 10, 2020 at 9:58 PM wrote:
> > > >
> > > > On 2020-02-07 19:40, Jeffrey Hugo wrote:
> > > > > On Fri, Feb 7,
There is a ACT8600 on the CI20 board and the bindings of the
ACT8865 driver have changed without updating the CI20 device
tree. Therefore the PMU can not be probed successfully and
is running in power-on reset state.
Fix DT to match the latest act8865-regulator bindings.
Signed-off-by: H. Nikolau
Adding dsi controller and phy entries for idp dt.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Added dsi controller and dsi phy entries for idp dts
Changes in v2:
- Adding dependency patchwork series
- Removing suspend configuration
- Adding blank before cu
On Tue, 11 Feb 2020 22:41:24 +0100
"H. Nikolaus Schaller" wrote:
> There is a ACT8600 on the CI20 board and the bindings of the
> ACT8865 driver have changed without updating the CI20 device
> tree. Therefore the PMU can not be probed successfully and
> is running in power-on reset state.
>
> Fi
From: Alex Smith
The infrared sensor on the CI20 board is connected to a GPIO and can
be operated by using the gpio-ir-recv driver. Add a DT node for the
sensor to allow that driver to be used.
Signed-off-by: Alex Smith
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/ci20.d
DTS has been augmented to add some gpio-leds. We need the leds-gpio driver
and enable the triggers.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/configs/ci20_defconfig | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci2
The SW1 button can be used as a simple one-button keyboard
and is connected to PD17.
Note: SW1 has a second meaning to change the boot sequence
when pressed while powering on.
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/ci20.dts | 12
1 file changed, 12 inser
+Viresh Kumar +Stephen Boyd for clock advice.
On Fri, Feb 7, 2020 at 1:27 PM Nicolas Boichat wrote:
>
> The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
> devfreq, and provides OPP table with 2 sets of voltages.
>
> TODO: This is incomplete as we'll need add support for setting
> a
On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
>> 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:
On Tue, Feb 11, 2020 at 07:13:31PM +0200, Ville Syrjälä wrote:
> 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'
On Tue, Feb 11, 2020 at 07:14:51PM +0200, Ville Syrjälä wrote:
> 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
> > > en
On Wed, Feb 12, 2020 at 10:07:55AM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 07:14:51PM +0200, Ville Syrjälä wrote:
> > 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ä
> > >
On Tue, Feb 11, 2020 at 03:19:56PM +0100, Daniel Vetter wrote:
> 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 af
Combined HDCP patches together. Few for DRM SRM handling and few
more for hdcp2.2 compliance fix at I915.
Ramalingam C (5):
drm/hdcp: optimizing the srm handling
drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITS
drm/i915: terminate reauth at stream management failure
drm/i915: dont retry stream
On Tue, Feb 11, 2020 at 03:27:11PM +0100, Daniel Vetter wrote:
> 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 avoi
Need to extract the 2 most significant bits from a byte for constructing
the revoked KSV count of the SRM.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d512089b873f
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with functiona
As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.
v2:
seq_num_m++ is extended for steam management failures too.[Anshuman]
v3:
use drm_dbg_kms instead
When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.
So we are terminating the stream management retry, on roll over of the
seq_num_m.
v2:
using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
Signed-off-by: Ramalingam C
---
drivers/gpu/
Converts remaining instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros
manually.
This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion
to struct drm_device based logging macros.")
Signed-off-by: Ramalingam C
cc: Jani
The printout for txabrt is way too talkative. Reduce it to the minimum,
the rest can be gained by I2C core debugging and datasheet information.
Also, make it a debug printout, it won't help the regular user.
Reported-by: H. Nikolaus Schaller
Signed-off-by: Wolfram Sang
---
Sorry, normally I do
In order to use GCE function, we need add some information
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16
1 file changed, 16 insertions(+)
diff
On Wed, 12 Feb 2020, Ramalingam C wrote:
> Converts remaining instances of the printk based logging macros in
> i915/display/intel_hdcp.c with the struct drm_device based macros
> manually.
>
> This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion
> to struct drm_device based log
According mtk hardware design, stream_done0 and stream_done1 are
generated by mutex, so we move gce event property to mutex device mode.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/medi
On 2020-02-12 at 12:01:08 +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2020, Ramalingam C wrote:
> > Converts remaining instances of the printk based logging macros in
> > i915/display/intel_hdcp.c with the struct drm_device based macros
> > manually.
> >
> > This is continuation of commit 65833c463
Combined HDCP patches together. Few for DRM SRM handling and few
more for hdcp2.2 compliance fix at I915.
v2:
minor changes in i915 related 3 patches.
Ramalingam C (5):
drm/hdcp: optimizing the srm handling
drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITS
drm/i915: terminate reauth at stream m
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with functiona
As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.
v2:
seq_num_m++ is extended for steam management failures too.[Anshuman]
v3:
use drm_dbg_kms instead
Need to extract the 2 most significant bits from a byte for constructing
the revoked KSV count of the SRM.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d512089b873f
When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.
So we are terminating the stream management retry, on roll over of the
seq_num_m.
v2:
using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v3:
dev_priv is used as i915 [JaniN]
Signed-
Converts remaining instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros
manually.
This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion
to struct drm_device based logging macros.")
v2:
i915_dev_priv is used instead o
On 07/02/2020 06:26, Nicolas Boichat wrote:
> It is useful to know which component cannot be powered on.
>
> Signed-off-by: Nicolas Boichat
> Reviewed-by: Steven Price
> Reviewed-by: Alyssa Rosenzweig
Reviewed-by: Matthias Brugger
> ---
>
> Was useful when trying to probe Bifrost GPU, to
Hi, Bibby:
On Wed, 2020-02-12 at 17:55 +0800, Bibby Hsieh wrote:
> According mtk hardware design, stream_done0 and stream_done1 are
> generated by mutex, so we move gce event property to mutex device mode.
>
Reviewed-by: CK Hu
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk
On Wed, 2020-02-12 at 17:55 +0800, Bibby Hsieh wrote:
> In order to use GCE function, we need add some information
> into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
>
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Yongqiang Niu
> ---
> arch/arm64/boot/dts/mediatek/mt818
Hi,
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -270,7 +270,9 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
> drm_file *file)
> return id;
> }
>
> +
> vfpriv->ctx_id = id;
checkpatch warning here:
-:
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
On Wed, 12 Feb 2020, Ramalingam C wrote:
> Converts remaining instances of the printk based logging macros in
> i915/display/intel_hdcp.c with the struct drm_device based macros
> manually.
>
> This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion
> to struct drm_device based log
On 2020-02-12 at 13:31:45 +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2020, Ramalingam C wrote:
> > Converts remaining instances of the printk based logging macros in
> > i915/display/intel_hdcp.c with the struct drm_device based macros
> > manually.
> >
> > This is continuation of commit 65833c463
Am 12.02.20 um 07:23 schrieb Pan, Xinhui:
2020年2月11日 23:43，Christian König 写道：
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
The copy_to_user() function returns the number of bytes remaining to be
copied, but we want to return a negative error code to the user.
Fixes: 030d5b97a54b ("drm/amdgpu: use amdgpu_device_vram_access in
amdgpu_ttm_vram_read")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_t
Am 12.02.20 um 13:07 schrieb Dan Carpenter:
The copy_to_user() function returns the number of bytes remaining to be
copied, but we want to return a negative error code to the user.
Fixes: 030d5b97a54b ("drm/amdgpu: use amdgpu_device_vram_access in
amdgpu_ttm_vram_read")
Signed-off-by: Dan Carpe
The hardcoded '12' means the number of elements in the
adv7511_csc_ycbcr_to_rgb[] array, so use the ARRAY_SIZE() macro
to let the code less error prone.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 16
1 file changed, 8 insertions(+), 8 deletio
On 11/02/2020 17:41, Daniel Vetter wrote:
> 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
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was scr
On 12/02/2020 15:59, Jyri Sarha wrote:
> The old implementation of placing planes on the CRTC while configuring
> the planes was naive and relied on the order in which the planes were
> configured, enabled, and disabled. The situation where a plane's zpos
> was changed on the fly was completely bro
On Wed, Feb 12, 2020 at 04:08:11PM +0200, Jyri Sarha wrote:
> On 12/02/2020 15:59, Jyri Sarha wrote:
> > The old implementation of placing planes on the CRTC while configuring
> > the planes was naive and relied on the order in which the planes were
> > configured, enabled, and disabled. The situat
Hi,
> > Sorry, normally I don't do counter patches. Yet, this time I realized
> > that it would be faster to actually do what I envisioned than to
> > describe it in words. I hope you don't feel offended.
>
> No problem. I had thought a little about that myself, but did not
> dare to solve more t
Hi Maxime,
On Fri, Jan 17, 2020 at 07:51:00PM +0100, Maxime Ripard wrote:
> On Fri, Jan 17, 2020 at 04:34:27PM +0100, Stephan Gerhold wrote:
> > At the moment, video mode parameters like video=540x960,reflect_x,
> > (without rotation set) are not taken into account when applying the
> > mode in dr
On 2/11/20 7:53 PM, Luben Tuikov wrote:
On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
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 Novembe
On 2020-02-12 6:07 p.m., Nathan Chancellor wrote:
> On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
>> On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
>>> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
> A r
On Wed, Feb 12, 2020 at 7:12 AM Christian König
wrote:
>
> Am 12.02.20 um 13:07 schrieb Dan Carpenter:
> > The copy_to_user() function returns the number of bytes remaining to be
> > copied, but we want to return a negative error code to the user.
> >
> > Fixes: 030d5b97a54b ("drm/amdgpu: use amdg
The fixes look reasonable.
Reviewed-by: Chia-I Wu
On Tue, Feb 11, 2020 at 5:50 AM Gerd Hoffmann wrote:
>
>
>
> 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 ++
On Wed, Feb 12, 2020 at 2:49 AM Nicolas Boichat wrote:
>
> +Viresh Kumar +Stephen Boyd for clock advice.
>
> On Fri, Feb 7, 2020 at 1:27 PM Nicolas Boichat wrote:
> >
> > The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
> > devfreq, and provides OPP table with 2 sets of voltages.
>
On 12/02/2020 16:33, Ville Syrjälä wrote:
> On Wed, Feb 12, 2020 at 04:08:11PM +0200, Jyri Sarha wrote:
>> On 12/02/2020 15:59, Jyri Sarha wrote:
>>> The old implementation of placing planes on the CRTC while configuring
>>> the planes was naive and relied on the order in which the planes were
>>>
On Wed, Feb 12, 2020 at 3:13 AM Gerd Hoffmann wrote:
>
> 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_
On Tue, Feb 11, 2020 at 3:56 PM Gurchetan Singh
wrote:
>
> We currently do it when open the DRM fd, let's delay it. First step,
> remove the hyercall from initialization.
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
> drivers/gpu/drm/virtio/virtgpu_i
On Tue, Feb 11, 2020 at 3:56 PM Gurchetan Singh
wrote:
>
> We only want create a new virglrenderer context after the first
> 3D ioctl.
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +
> drivers/gpu/drm/vi
On Wed, Feb 12, 2020 at 12:53 PM Christian König
wrote:
>
> Am 12.02.20 um 07:23 schrieb Pan, Xinhui:
> >
> >> 2020年2月11日 23:43，Christian König 写道：
> >>
> >> When non-imported BOs are resurrected for delayed delete we replace
> >> the dma_resv object to allow for easy reclaiming of the resources.
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
From: Tomeu Vizoso
If the exception type isn't a translation fault, don't try to map and
instead go straight to a terminal fault.
Otherwise, we can get flooded by kernel warnings and further faults.
Signed-off-by: Tomeu Vizoso
Signed-off-by: Rob Herring
---
I rewrote this some simplifying the
Hi!
> > > It would be good to get LED backlight to work in clean way for 5.6
> > > kernel.
> ...
> > > [If you have an idea what else is needed, it would be welcome; it
> > > works for me in development tree but not in tree I'd like to
> > > upstream.]
> > >
> > > Lee, would you be willing to tak
On Wed, Feb 12, 2020 at 7:01 PM Jyri Sarha wrote:
>
> On 12/02/2020 16:33, Ville Syrjälä wrote:
> > On Wed, Feb 12, 2020 at 04:08:11PM +0200, Jyri Sarha wrote:
> >> On 12/02/2020 15:59, Jyri Sarha wrote:
> >>> The old implementation of placing planes on the CRTC while configuring
> >>> the planes
On Thu, Feb 6, 2020 at 8:13 AM Boris Brezillon
wrote:
>
> We need to use the AS attached to the opened FD when dumping counters.
>
> Reported-by: Antonio Caggiano
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc:
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/
On Mon, Feb 3, 2020 at 9:33 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
> drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
> variable 'bo' set but not used [-Wunused-but-set-variab
Hi Dave, Daniel,
Fixes for 5.6.
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.6-2020-02-12
for you to fetch chang
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
Currently, nouveau doesn't actually bother to try probing whether or not
it can actually handle interlaced modes over DisplayPort. As a result,
on volta and later we'll end up trying to set an interlaced mode even
when it's not supported and cause the front end for the display engine
to hang.
So,
Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.
Thi
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul
Cc
This just limits the BPC for MST connectors to a maximum of 8 from
nv50_mstc_get_modes(), instead of doing so during
nv50_msto_atomic_check(). This doesn't introduce any functional changes
yet (other then userspace now lying about the max bpc, but we can't
support that yet anyway so meh). But, we'l
Andrzej / Neil,
On Mon, Feb 3, 2020 at 4:21 PM Doug Anderson wrote:
>
> Andrzej / Neil,
>
> On Mon, Feb 3, 2020 at 3:37 PM Bjorn Andersson
> wrote:
> >
> > On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> >
> > > The current bridge driver always forced us to use 24 bits per pixel
> > > ov
While certain modeset operations on gv100+ need us to temporarily
disable the LUT, we make the mistake of sometimes neglecting to
reprogram the LUT after such modesets. In particular, moving a head from
one encoder to another seems to trigger this quite often. GV100+ is very
picky about having a LU
Besides x, y position, width and height,
fb also need updating in async update.
Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic
update")
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
1 - 100 of 112 matches
Mail list logo
