Am 20.12.21 um 22:51 schrieb Andrey Grodzovsky:
On 2021-12-20 2:16 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq
Am 20.12.21 um 20:22 schrieb Andrey Grodzovsky:
On 2021-12-20 2:17 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Restrict jobs resubmission to suspend case
only since schedulers not initialised yet on
probe.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu
20.12.2021 19:55, Dmitry Osipenko пишет:
> 20.12.2021 19:12, Dmitry Osipenko пишет:
>> 20.12.2021 18:27, Thierry Reding пишет:
>>> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi,
>
> th
On Sat, 4 Dec 2021 17:37:03 +0300, Dmitry Osipenko wrote:
> This series revives Tegra20 S/PDIF driver which was upstreamed long time
> ago, but never was used. It also turns Tegra DRM HDMI driver into HDMI
> audio CODEC provider. Finally, HDMI audio is enabled in device-trees.
> For now the audio i
Fix function name in handlers.c kernel-doc comment
to remove some warnings found by running scripts/kernel-doc,
which is caused by using 'make W=1'.
drivers/gpu/drm/i915/gvt/handlers.c:3812: warning: expecting prototype
for intel_t_default_mmio_write(). Prototype was for
intel_vgpu_default_mmio_wri
On Mon, Dec 20, 2021 at 8:51 AM Thierry Reding wrote:
>
> From: Thierry Reding
>
> In order to validate multiple "if" conditionals, they must be part of an
> "allOf:" list, otherwise they will cause a failure in parsing the schema
> because of the duplicated "if" property.
>
> Fixes: d7df3948eb49
From: Evan Quan
[ Upstream commit 17c65d6fca844ee72a651944d8ce721e9040bf70 ]
Pair the operations did in GMC ->hw_init and ->hw_fini. That
can help to maintain correct cached state for GMC and avoid
unintention gate operation dropping due to wrong cached state.
BugLink: https://gitlab.freedeskto
From: Nicholas Kazlauskas
[ Upstream commit 791255ca9fbe38042cfd55df5deb116dc11fef18 ]
[Why]
If the firmware wasn't reset by PSP or HW and is currently running
then the firmware will hang or perform underfined behavior when we
modify its firmware state underneath it.
[How]
Reset DMCUB before se
From: Evan Quan
[ Upstream commit 17c65d6fca844ee72a651944d8ce721e9040bf70 ]
Pair the operations did in GMC ->hw_init and ->hw_fini. That
can help to maintain correct cached state for GMC and avoid
unintention gate operation dropping due to wrong cached state.
BugLink: https://gitlab.freedeskto
From: Nicholas Kazlauskas
[ Upstream commit 791255ca9fbe38042cfd55df5deb116dc11fef18 ]
[Why]
If the firmware wasn't reset by PSP or HW and is currently running
then the firmware will hang or perform underfined behavior when we
modify its firmware state underneath it.
[How]
Reset DMCUB before se
On Mon, Dec 20, 2021 at 04:52:19PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a known (but exceedingly unlikely) race condition where the
> asynchronous frequency management code could reduce the GT clock while
> a GuC reload is in progress (during a full GT reset)
From: John Harrison
If the GuC fails to load, it is useful to know what firmware file /
version was attempted. So move the version info report to before the
load attempt rather than only after a successful load.
If the GuC does fail to load, then make the error messages visible
rather than being
From: John Harrison
Update to the latest GuC release.
The latest GuC firmware introduces a number of interface changes:
GuC may return NO_RESPONSE_RETRY message for requests sent over CTB.
Add support for this reply and try resending the request again as a
new CTB message.
A KLV (key-length-va
From: John Harrison
There is a known (but exceedingly unlikely) race condition where the
asynchronous frequency management code could reduce the GT clock while
a GuC reload is in progress (during a full GT reset). A fix is in
progress but there are complex locking issues to be resolved. In the
me
From: John Harrison
Update to the latest GuC version. This includes a suite of interface
changes and new features with corresponding i915 side changes.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Temporarily bump the GuC load timeout
drm/i915/guc: Update to GuC version
On Fri, 17 Dec 2021 at 03:25, Bjorn Andersson
wrote:
>
> The sc8180x has 2 DP and 1 eDP controllers, add support for these to the
> DP driver.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
> ---
>
> Changes since v5:
> - Dropped DPU hw catalog change from the patch
> - Rebas
On Mon 20 Dec 15:53 PST 2021, Dmitry Baryshkov wrote:
> On Fri, 17 Dec 2021 at 03:19, Bjorn Andersson
> wrote:
> >
> > dpu_kms_debugfs_init() is invoked for each minor being registered. Most
> > of the files created are unrelated to the minor, so there's no reason to
> > present them per minor.
>
On Mon, 20 Dec 2021 at 21:42, David Heidelberg wrote:
>
> Driver and dts has been already adjusted and bus moved out of dpu, let's
> update also dt-bindings.
>
> Fixes warnings as:
> arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: mdss
> @ae0: clock-names: ['iface', 'core'] is too shor
On Fri, 17 Dec 2021 at 03:19, Bjorn Andersson
wrote:
>
> dpu_kms_debugfs_init() is invoked for each minor being registered. Most
> of the files created are unrelated to the minor, so there's no reason to
> present them per minor.
> The exception to this is the DisplayPort code, which ends up invok
On 12/16/2021 3:30 PM, Vinay Belgaumkar wrote:
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.
SLPC will rest
next-20211220]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sascha-Hauer/drm-rockchip-RK356x-VO
Allow a privacy screen provider to stash its private data pointer in the
drm_privacy_screen, and update the drm_privacy_screen_register() call to
accept that. Also introduce a *_get_drvdata() so that it can retrieved
back when needed.
This also touches the IBM Thinkpad platform driver, the only us
On 2021-12-20 2:20 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Use reset domain wq also for non TDR gpu recovery trigers
such as sysfs and RAS. We must serialize all possible
GPU recoveries to gurantee no concurrency there.
For TDR call the original recovery fu
On 2021-12-20 2:16 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the
On 12/16/2021 4:26 PM, Bjorn Andersson wrote:
The sc8180x has 2 DP and 1 eDP controllers, add support for these to the
DP driver.
Signed-off-by: Bjorn Andersson
Reviewed-by: Abhinav Kumar
---
Changes since v5:
- Dropped DPU hw catalog change from the patch
- Rebased the patch
drivers/
On 12/16/2021 4:20 PM, Bjorn Andersson wrote:
dpu_kms_debugfs_init() is invoked for each minor being registered. Most
of the files created are unrelated to the minor, so there's no reason to
present them per minor.
The exception to this is the DisplayPort code, which ends up invoking
dp_debug_
On 2021-12-20 2:17 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Restrict jobs resubmission to suspend case
only since schedulers not initialised yet on
probe.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
1 file chan
Tested-by: Dan Moulding
Thanks!
-- Dan
On 2021-12-20 12:06 p.m., Liu, Shaoyun wrote:
[AMD Official Use Only]
Hi , Andrey
I actually has some concerns about this change .
1. on SRIOV configuration , the reset notify coming from host , and driver
already trigger a work queue to handle the reset (check
xgpu_*_mailbox_flr_work) ,
https://bugzilla.kernel.org/show_bug.cgi?id=215223
--- Comment #6 from reznov90...@gmail.com ---
Switching off and then switching on monitor helps.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, Dec 20, 2021 at 03:16:55PM +0100, Nicolas Frattaroli wrote:
> On Montag, 20. Dezember 2021 12:06:30 CET Sascha Hauer wrote:
> > From: Andy Yan
> >
> > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> > It replaces the VOP unit found in the older Rockchip SoCs.
> >
Driver and dts has been already adjusted and bus moved out of dpu, let's
update also dt-bindings.
Fixes warnings as:
arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: mdss
@ae0: clock-names: ['iface', 'core'] is too short
From schema:
Documentation/devicetree/bindings/display/ms
On 12/20/2021 07:00, Tvrtko Ursulin wrote:
On 17/12/2021 16:22, Matthew Brost wrote:
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the GuC firmware in the similar way it is
done
by
On 12/20/2021 4:29 AM, Daniel Vetter wrote:
On Fri, Dec 10, 2021 at 07:58:50AM +0100, Christian König wrote:
Am 09.12.21 um 19:28 schrieb Felix Kuehling:
Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
That still won't work.
But I think we could do this change for the amdgpu mmap callb
On Mon, Dec 20, 2021 at 03:00:53PM +, Tvrtko Ursulin wrote:
>
> On 17/12/2021 16:22, Matthew Brost wrote:
> > On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
> > >
> > > On 14/12/2021 15:07, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Log engine resets
On Mon, Dec 20, 2021 at 10:18:38AM +0100, Daniel Vetter wrote:
> On Thu, Dec 02, 2021 at 10:51:12AM +0100, Claudio Suarez wrote:
> > The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log
> > calls in drm core, files drm_a*.c") fails when the drm_device
> > cannot be found in the parameter plane_
On Thu, Dec 16, 2021 at 4:38 PM Javier Martinez Canillas
wrote:
>
> According to disable Documentation/admin-guide/kernel-parameters.txt, this
> parameter can be used to disable kernel modesetting.
>
> DRM drivers will not perform display-mode changes or accelerated rendering
> and only the system
[AMD Official Use Only]
Hi , Andrey
I actually has some concerns about this change .
1. on SRIOV configuration , the reset notify coming from host , and driver
already trigger a work queue to handle the reset (check
xgpu_*_mailbox_flr_work) , is it a good idea to trigger another work queue
20.12.2021 19:12, Dmitry Osipenko пишет:
> 20.12.2021 18:27, Thierry Reding пишет:
>> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>>> 20.12.2021 13:48, Thierry Reding пишет:
From: Thierry Reding
Hi,
this is an alternative proposal to fix panel support
On Montag, 20. Dezember 2021 15:16:55 CET Nicolas Frattaroli wrote:
> On Montag, 20. Dezember 2021 12:06:30 CET Sascha Hauer wrote:
> > From: Andy Yan
> >
> > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> > It replaces the VOP unit found in the older Rockchip SoCs.
> >
Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.
The factory installed Android has a hardcoded modeline in its kernel,
causing it to not suffer from this BIOS bug;
and the Android boot-splash
20.12.2021 18:27, Thierry Reding пишет:
> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>> 20.12.2021 13:48, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> Hi,
>>>
>>> this is an alternative proposal to fix panel support on Venice 2 and
>>> Nyan. Dmitry had proposed a di
On Mon, 2021-12-20 at 14:54 +, Kieran Bingham wrote:
> Hi Antonio,
>
> Quoting Antonio Borneo (2021-12-18 18:28:04)
> > Commit 680532c50bca ("drm: adv7511: Add support for
> > i2c_new_secondary_device") allows a device tree node to override
> > the default addresses of the secondary i2c device
On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 13:48, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > Hi,
> >
> > this is an alternative proposal to fix panel support on Venice 2 and
> > Nyan. Dmitry had proposed a different solution that involved reverting
On 20-12-2021 14:55, Kevin Tang wrote:
> Dear Maarten,
> I see it from the cgit.freedesktop.org, our sprd drivers seems has
> been merged into drm-misc.
>
> Now, what shall we do next?
>
> BR,
> Best wishes
>
> Kevin Tang 于2021年12月7日周二 22:27写道:
You should apply for commit rights to drm-misc, so y
On 17/12/2021 16:22, Matthew Brost wrote:
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the GuC firmware in the similar way it is done
by the execlists backend.
This way we have not
Hi Antonio,
Quoting Antonio Borneo (2021-12-18 18:28:04)
> Commit 680532c50bca ("drm: adv7511: Add support for
> i2c_new_secondary_device") allows a device tree node to override
> the default addresses of the secondary i2c devices. This is useful
> for solving address conflicts on the i2c bus.
>
20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi,
>
> this is an alternative proposal to fix panel support on Venice 2 and
> Nyan. Dmitry had proposed a different solution that involved reverting
> the I2C/DDC registration order and would complicate things by breaking
> the
On 12/10/2021 10:58 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits
On Mon, 20 Dec 2021 12:06:15 +0100, Sascha Hauer wrote:
> None of the upstream device tree files has a "unwedge" pinctrl
> specified. Make it optional.
>
> Signed-off-by: Sascha Hauer
> ---
> .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
> 1 file changed, 1 insertion(+)
On Mon, 20 Dec 2021 12:06:19 +0100, Sascha Hauer wrote:
> The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
> The binding differs slightly from the existing VOP binding, so add a new
> binding file for it.
>
> Signed-off-by: Sascha Hauer
> ---
> .../display/rockchip/rockchi
On Mon, 20 Dec 2021 12:06:17 +0100, Sascha Hauer wrote:
> Signed-off-by: Sascha Hauer
> ---
> .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 +++
> 1 file changed, 11 insertions(+)
>
Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consid
On Mon, 20 Dec 2021 12:06:16 +0100, Sascha Hauer wrote:
> "vpll" is a misnomer. A clock input to a device should be named after
> the usage in the device, not after the clock that drives it. On the
> rk3568 the same clock is driven by the HPLL.
> To fix that, this patch renames the vpll clock to re
On Montag, 20. Dezember 2021 12:06:30 CET Sascha Hauer wrote:
> From: Andy Yan
>
> The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> It replaces the VOP unit found in the older Rockchip SoCs.
>
> This driver has been derived from the downstream Rockchip Kernel and
> heavily
documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
a7904a538933c525096ca2ccde1e60d0ee62c08e
c
Dear Maarten,
I see it from the cgit.freedesktop.org, our sprd drivers seems has
been merged into drm-misc.
Now, what shall we do next?
BR,
Best wishes
Kevin Tang 于2021年12月7日周二 22:27写道:
>
> ChangeList:
> RFC v1:
> 1. only upstream modeset and atomic at first commit.
> 2. remove some unused cod
e' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
a7904a538933c525096ca2ccde1e60
e' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
a7904a538933c525096ca2ccde1e60
From: Thierry Reding
In order to validate multiple "if" conditionals, they must be part of an
"allOf:" list, otherwise they will cause a failure in parsing the schema
because of the duplicated "if" property.
Fixes: d7df3948eb49 ("dt-bindings: display: bridge: lvds-codec: Document pixel
data sam
On Montag, 20. Dezember 2021 12:06:08 CET Sascha Hauer wrote:
>
> Third round of patches and last one for this year. I hopefully integrated
> all review feedback. Additionally the driver is now fully converted to
> regmap, so no struct vop_reg necessary anymore.
>
> Sascha
>
> Changes since v2:
On 2021-12-18 07:45, Lu Baolu wrote:
The suported page sizes of an iommu_domain are saved in the pgsize_bitmap
field. Retrieve the value from the right place.
Fixes: 58fd9375c2c534 ("drm/nouveau/platform: probe IOMMU if present")
...except domain->pgsize_bitmap was introduced more than a year
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dts
From: Benjamin Gaignard
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Link:
https://lore.kernel.org/r/20210707120323.401785-2-benjam
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
Signed-off-by: Sascha Hauer
---
.../bindings/display
The binding specifies the clock order to "cec", "grf", "vpll". Reorder
the clocks accordingly.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip-vop2.yaml | 146 ++
1 file changed, 146 insert
Add a device node to drm_encoder which corresponds with the port node
in the DT description of the encoder. This allows drivers to find the
of_graph link between a crtc and an encoder.
Signed-off-by: Sascha Hauer
---
include/drm/drm_encoder.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a
With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/Kconfig| 8
drivers/gpu/drm/rockchip/Makefile | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
3 f
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 ++
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 ++
arc
On the rk3568 we have this (simplified) situation:
.. .-..-.
-| hpll |--.--| /n ||dclk_vop0|-
`´ | `-´`-´
| .-..-.
`--| /m ||dclk_vop1|-
| `-´`-´
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped str
From: Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 48 +++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/roc
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 +++--
1
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
Third round of patches and last one for this year. I hopefully integrated
all review feedback. Additionally the driver is now fully converted to
regmap, so no struct vop_reg necessary anymore.
Sascha
Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI dri
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml| 10
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.y
The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 delet
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 18 ++
The pixel clocks dclk_vop[012] can be clocked from hpll, vpll, gpll or
cpll. gpll and cpll also drive many other clocks, so changing the
dclk_vop[012] clocks could change these other clocks as well. Drop
CLK_SET_RATE_PARENT to fix that. With this change the VOP2 driver can
only adjust the pixel clo
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 +++
1 file changed, 48 insertions(+)
diff
The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
1 file changed,
From: Johannes Berg
Even if it's probably not really useful, it can get selected
by e.g. randconfig builds, and then failing to compile is an
annoyance. Unfortunately, it's hard to fix in Kconfig, since
DRM_TTM is selected by many things that don't really depend
on any specific architecture, and
From: Thierry Reding
Move the eDP panel on Venice 2 and Nyan boards into the corresponding
AUX bus device tree node. This allows us to avoid a nasty circular
dependency that would otherwise be created between the DPAUX and panel
nodes via the DDC/I2C phandle.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
The DPAUX hardware block exposes an DP AUX interface that provides
access to an AUX bus and the devices on that bus. Use the DP AUX bus
infrastructure that was recently introduced to probe devices on this
bus from DT.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra
From: Thierry Reding
Hi,
this is an alternative proposal to fix panel support on Venice 2 and
Nyan. Dmitry had proposed a different solution that involved reverting
the I2C/DDC registration order and would complicate things by breaking
the encapsulation of the driver by introducing a global (tho
On Mon, Dec 20, 2021 at 10:25 AM Geert Uytterhoeven
wrote:
> JFYI, when comparing v5.16-rc6[1] to v5.16-rc5[3], the summaries are:
> - build errors: +1/-5
+ /kisskb/src/drivers/gpu/drm/ttm/ttm_module.c: error: 'struct
cpuinfo_um' has no member named 'x86': => 71:24
um-x86_64/um-allyesconfig
On Mon, Dec 20, 2021 at 08:25:05AM +0100, Christian König wrote:
> Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
> > This patchset is based on earlier work by Boris[1] that allowed to have an
> > ordered workqueue at the driver level that will be used by the different
> > schedulers to queue thei
On Tue, Dec 14, 2021 at 11:02:02AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, Dec 14, 2021 at 06:08:37PM +0800, Jiasheng Jiang wrote:
> > The return value of kzalloc() needs to be checked.
> > To avoid use of null pointer '&state->base' in case of the
> > failure of alloc.
> >
> > Fixes: 99665
On Tue, Dec 07, 2021 at 09:46:47PM +0100, Thomas Hellström wrote:
>
> On 12/7/21 19:08, Daniel Vetter wrote:
> > Once more an entire week behind on mails, but this looked interesting
> > enough.
> >
> > On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
> > > On Fri, 2021-12-03 at
On Fri, Dec 10, 2021 at 09:26:56AM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote:
> > Am 10.12.21 um 13:42 schrieb Jason Gunthorpe:
> > > On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote:
> > > > Hi Jason,
> > > > Thank you for replying.
On Fri, Dec 10, 2021 at 07:58:50AM +0100, Christian König wrote:
> Am 09.12.21 um 19:28 schrieb Felix Kuehling:
> > Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
> > > That still won't work.
> > >
> > > But I think we could do this change for the amdgpu mmap callback only.
> > If graphics u
On Thu, Dec 02, 2021 at 10:51:12AM +0100, Claudio Suarez wrote:
> The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log
> calls in drm core, files drm_a*.c") fails when the drm_device
> cannot be found in the parameter plane_state->crtc.
> Fix it using plane_state->plane.
>
> Reported-by: kerne
syzbot has found a reproducer for the following issue on:
HEAD commit:3f667b5d4053 Merge tag 'tty-5.16-rc6' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=174324a3b0
kernel config: https://syzkaller.appspot.com/x/.config?x=fa55609
syzbot has bisected this issue to:
commit 45d9c8dde4cd8589f9180309ec60f0da2ce486e4
Author: Daniel Vetter
Date: Thu Aug 12 13:14:12 2021 +
drm/vgem: use shmem helpers
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=147953cbb0
start commit: 3f667b5d4053 Merge tag 'tty
It needs call dma_buf_put() to put dmabuf in case of getting
fd failed.
Signed-off-by: Xianting Tian
---
drivers/dma-buf/udmabuf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c57a609db..d77f96995 100644
--- a
Hi Jiasheng,
On Mon, Dec 20, 2021 at 9:19 AM Jiasheng Jiang wrote:
> The return value of platform_get_resource() needs to be checked.
> To avoid use of error pointer in case that there is no suitable resource.
Thanks for your patch!
> Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbd
Hi Jagan,
On Sun, Dec 19, 2021 at 10:10:10PM +0530, Jagan Teki wrote:
> Hi Sam,
>
> On Thu, Nov 11, 2021 at 3:11 PM Jagan Teki wrote:
> >
> > AM-1280800N3TZQW-T00H panel support 8 bpc not 6 bpc as per
> > recent testing in i.MX8MM platform.
> >
> > Fix it.
> >
> > Fixes: bca684e69c4c ("drm/panel
1 - 100 of 102 matches
Mail list logo