Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Hi, Matthias: On Thu, 2020-03-26 at 16:45 +0100, Matthias Brugger wrote: > > On 26/03/2020 15:51, CK Hu wrote: > > Hi, Matthias: > > > > On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote: > >> Hi CK, > >> > >> On 26/03/2020 00:05, CK Hu wrote: > >>> Hi, Matthias: > >>> > >>> On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote: > > On 11/03/2020 17:53, Enric Balletbo i Serra wrote: > > Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions > > to > > replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path(). > > Those functions will allow DRM driver and others to control the data > > path routing. > > > > Signed-off-by: Enric Balletbo i Serra > > Reviewed-by: Matthias Brugger > > Reviewed-by: CK Hu > > Acked-by: CK Hu > > This patch does not apply against v5.6-rc1. > Please rebase as this is a quite big patch and it won't be easy to do > that by hand. > >>> > >>> I think this patch depends on [1] which has been acked by me and I have > >>> not picked it. The simple way is that you pick [1] first and then pick > >>> this series. > >>> > >>> [1] > >>> https://patchwork.kernel.org/patch/11406227/ > >>> > >> > >> You would need to provide a stable tag for me that I can merge into my > >> tree. You > >> can also try to merge my for-next [1] which has the newest version from > >> Enric. > >> If you see any merge conflict, then we have to do something about it :) > >> > >> Regards, > >> Matthias > >> > >> [1] > >> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next > >> > > > > You have applied this series, so I would not apply other patches which > > would conflict with this series. After this series land on main stream > > (wish it happen in this merge window), I would rebase other patch on > > main stream. > > > > I haven't (yet) send the pull request. If you want to bring in your patches in > v5.7 as well we can find a solution to that. Shall I provide you with a stable > branch which you can merge? This way you can add all your patches in the pull > request as well and we don't have to wait for v5.8 to get things into > mainline. > > Let me know and I'll provide you with a stable branch. > Other drm patches is not in a hurry, for now I don't need a stable branch. If I need one, I would tell you, thanks. Regards, CK > Regards, > Matthias > > > Regards, > > CK > > > >>> Regards, > >>> CK > >>> > > Regards, > Matthias > > > --- > > > > Changes in v12: None > > Changes in v10: > > - Select CONFIG_MTK_MMSYS (CK) > > - Pass device pointer of mmsys device instead of config regs (CK) > > > > Changes in v9: > > - Introduced a new patch to move routing control into mmsys driver. > > - Removed the patch to use regmap as is not needed anymore. > > > > Changes in v8: None > > Changes in v7: None > > > > drivers/gpu/drm/mediatek/Kconfig| 1 + > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +- > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 -- > > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 - > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- > > drivers/soc/mediatek/mtk-mmsys.c| 279 > > include/linux/soc/mediatek/mtk-mmsys.h | 20 ++ > > 8 files changed, 316 insertions(+), 282 deletions(-) > > create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h > > > > diff --git a/drivers/gpu/drm/mediatek/Kconfig > > b/drivers/gpu/drm/mediatek/Kconfig > > index fa5ffc4fe823..c420f5a3d33b 100644 > > --- a/drivers/gpu/drm/mediatek/Kconfig > > +++ b/drivers/gpu/drm/mediatek/Kconfig > > @@ -11,6 +11,7 @@ config DRM_MEDIATEK > > select DRM_MIPI_DSI > > select DRM_PANEL > > select MEMORY > > + select MTK_MMSYS > > select MTK_SMI > > select VIDEOMODE_HELPERS > > help > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > > index 0e05683d7b53..579a5a5d4472 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > > @@ -6,6 +6,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -28,7 +29,7 @@ > > * @enabled: records whether crtc_enable succeeded > > * @planes: array of 4 drm_plane structures, one for each overlay plane > > * @pending_planes: whether any plane has pending changes to be applied > > - * @config_regs: memory mapped mmsys configuration register space > > + * @mmsys_dev: pointer to the mmsys device for configuration registers > > * @mutex: handle to one of the ten
[PATCH AUTOSEL 4.4 2/4] drm/bochs: downgrade pci_request_region failure from error to warning
From: Gerd Hoffmann
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Link:
http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kra...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index a39b0343c197d..401c218567af9 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -97,10 +97,8 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
- DRM_ERROR("Cannot request framebuffer\n");
- return -EBUSY;
- }
+ if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+ DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size);
if (bochs->fb_map == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 03/10] drm/bochs: downgrade pci_request_region failure from error to warning
From: Gerd Hoffmann
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Link:
http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kra...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index a39b0343c197d..401c218567af9 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -97,10 +97,8 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
- DRM_ERROR("Cannot request framebuffer\n");
- return -EBUSY;
- }
+ if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+ DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size);
if (bochs->fb_map == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 2/7] drm/bochs: downgrade pci_request_region failure from error to warning
From: Gerd Hoffmann
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Link:
http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kra...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index a39b0343c197d..401c218567af9 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -97,10 +97,8 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
- DRM_ERROR("Cannot request framebuffer\n");
- return -EBUSY;
- }
+ if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+ DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size);
if (bochs->fb_map == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 05/19] drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
From: Mario Kleiner
[ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ]
This fixes a problem found on the MacBookPro 2017 Retina panel:
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.
This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux <= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -> No modes for the laptop panel -> failure
to set any mode -> Panel goes dark.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.
Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.
Signed-off-by: Mario Kleiner
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 0ab890c927ec7..6dd2334dd5e60 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2879,6 +2879,17 @@ static bool retrieve_link_cap(struct dc_link *link)
sink_id.ieee_device_id,
sizeof(sink_id.ieee_device_id));
+ /* Quirk Apple MBP 2017 15" Retina panel: Wrong DP_MAX_LINK_RATE */
+ {
+ uint8_t str_mbp_2017[] = { 101, 68, 21, 101, 98, 97 };
+
+ if ((link->dpcd_caps.sink_dev_id == 0x0010fa) &&
+ !memcmp(link->dpcd_caps.sink_dev_id_str, str_mbp_2017,
+ sizeof(str_mbp_2017))) {
+ link->reported_link_cap.link_rate = 0x0c;
+ }
+ }
+
core_link_read_dpcd(
link,
DP_SINK_HW_REVISION_START,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 09/15] drm/amdgpu: fix typo for vcn1 idle check
From: James Zhu
[ Upstream commit acfc62dc68770aa665cc606891f6df7d6d1e52c0 ]
fix typo for vcn1 idle check
Signed-off-by: James Zhu
Reviewed-by: Leo Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 4f8f3bb218320..a54f8943ffa34 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -857,7 +857,7 @@ static int vcn_v1_0_set_clockgating_state(void *handle,
if (enable) {
/* wait for STATUS to clear */
- if (vcn_v1_0_is_idle(handle))
+ if (!vcn_v1_0_is_idle(handle))
return -EBUSY;
vcn_v1_0_enable_clock_gating(adev);
} else {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 05/15] drm/bochs: downgrade pci_request_region failure from error to warning
From: Gerd Hoffmann
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Link:
http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kra...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index a39b0343c197d..401c218567af9 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -97,10 +97,8 @@ int bochs_hw_init(struct drm_device *dev, uint32_t flags)
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
- DRM_ERROR("Cannot request framebuffer\n");
- return -EBUSY;
- }
+ if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+ DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size);
if (bochs->fb_map == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 15/15] drm/lease: fix WARNING in idr_destroy
From: Qiujun Huang
[ Upstream commit b216a8e7908cd750550c0480cf7d2b3a37f06954 ]
drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.
drm_master_put
->drm_master_destroy
->idr_destroy
So we needn't call idr_destroy again.
Reported-and-tested-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjag...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_lease.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 086f2adc541b0..19e9935c2e436 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -545,10 +545,12 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
}
DRM_DEBUG_LEASE("Creating lease\n");
+ /* lessee will take the ownership of leases */
lessee = drm_lease_create(lessor, );
if (IS_ERR(lessee)) {
ret = PTR_ERR(lessee);
+ idr_destroy();
goto out_leases;
}
@@ -583,7 +585,6 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
out_leases:
put_unused_fd(fd);
- idr_destroy();
DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 17/28] drm/amdgpu: fix typo for vcn1 idle check
From: James Zhu
[ Upstream commit acfc62dc68770aa665cc606891f6df7d6d1e52c0 ]
fix typo for vcn1 idle check
Signed-off-by: James Zhu
Reviewed-by: Leo Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index b4f84a820a448..654912402a851 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -1374,7 +1374,7 @@ static int vcn_v1_0_set_clockgating_state(void *handle,
if (enable) {
/* wait for STATUS to clear */
- if (vcn_v1_0_is_idle(handle))
+ if (!vcn_v1_0_is_idle(handle))
return -EBUSY;
vcn_v1_0_enable_clock_gating(adev);
} else {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 19/19] drm/lease: fix WARNING in idr_destroy
From: Qiujun Huang
[ Upstream commit b216a8e7908cd750550c0480cf7d2b3a37f06954 ]
drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.
drm_master_put
->drm_master_destroy
->idr_destroy
So we needn't call idr_destroy again.
Reported-and-tested-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjag...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_lease.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481cafdde280..825abe38201ac 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -542,10 +542,12 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
}
DRM_DEBUG_LEASE("Creating lease\n");
+ /* lessee will take the ownership of leases */
lessee = drm_lease_create(lessor, );
if (IS_ERR(lessee)) {
ret = PTR_ERR(lessee);
+ idr_destroy();
goto out_leases;
}
@@ -580,7 +582,6 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
out_leases:
put_unused_fd(fd);
- idr_destroy();
DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 04/15] drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
From: Mario Kleiner
[ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ]
This fixes a problem found on the MacBookPro 2017 Retina panel:
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.
This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux <= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -> No modes for the laptop panel -> failure
to set any mode -> Panel goes dark.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.
Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.
Signed-off-by: Mario Kleiner
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 122249da03ab7..a4928854a3de5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2440,6 +2440,17 @@ static bool retrieve_link_cap(struct dc_link *link)
sink_id.ieee_device_id,
sizeof(sink_id.ieee_device_id));
+ /* Quirk Apple MBP 2017 15" Retina panel: Wrong DP_MAX_LINK_RATE */
+ {
+ uint8_t str_mbp_2017[] = { 101, 68, 21, 101, 98, 97 };
+
+ if ((link->dpcd_caps.sink_dev_id == 0x0010fa) &&
+ !memcmp(link->dpcd_caps.sink_dev_id_str, str_mbp_2017,
+ sizeof(str_mbp_2017))) {
+ link->reported_link_cap.link_rate = 0x0c;
+ }
+ }
+
core_link_read_dpcd(
link,
DP_SINK_HW_REVISION_START,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 01/15] drm/bridge: dw-hdmi: fix AVI frame colorimetry
From: Jernej Skrabec
[ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ]
CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.
Acked-by: Laurent Pinchart
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
encodings")
Signed-off-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +--
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 2a0a1654d3ce5..6930452a712a8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1364,28 +1364,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
struct drm_display_mode *mode)
frame.colorspace = HDMI_COLORSPACE_RGB;
/* Set up colorimetry */
- switch (hdmi->hdmi_data.enc_out_encoding) {
- case V4L2_YCBCR_ENC_601:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
+ if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
+ switch (hdmi->hdmi_data.enc_out_encoding) {
+ case V4L2_YCBCR_ENC_601:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV601)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV709)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
+ break;
+ default: /* Carries no data */
frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ }
+ } else {
+ frame.colorimetry = HDMI_COLORIMETRY_NONE;
frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
- case V4L2_YCBCR_ENC_709:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
- frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
- break;
- default: /* Carries no data */
- frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
}
frame.scan_mode = HDMI_SCAN_MODE_NONE;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 06/19] drm/bochs: downgrade pci_request_region failure from error to warning
From: Gerd Hoffmann
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Link:
http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kra...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index e567bdfa2ab8e..bb1391784caf0 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -156,10 +156,8 @@ int bochs_hw_init(struct drm_device *dev)
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
- DRM_ERROR("Cannot request framebuffer\n");
- return -EBUSY;
- }
+ if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+ DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size);
if (bochs->fb_map == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 01/19] drm/bridge: dw-hdmi: fix AVI frame colorimetry
From: Jernej Skrabec
[ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ]
CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.
Acked-by: Laurent Pinchart
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
encodings")
Signed-off-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +--
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 1326f2c734bf8..41bf4aaff21c4 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1576,28 +1576,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
struct drm_display_mode *mode)
frame.colorspace = HDMI_COLORSPACE_RGB;
/* Set up colorimetry */
- switch (hdmi->hdmi_data.enc_out_encoding) {
- case V4L2_YCBCR_ENC_601:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
+ if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
+ switch (hdmi->hdmi_data.enc_out_encoding) {
+ case V4L2_YCBCR_ENC_601:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV601)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV709)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
+ break;
+ default: /* Carries no data */
frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ }
+ } else {
+ frame.colorimetry = HDMI_COLORIMETRY_NONE;
frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
- case V4L2_YCBCR_ENC_709:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
- frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
- break;
- default: /* Carries no data */
- frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
}
frame.scan_mode = HDMI_SCAN_MODE_NONE;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 01/10] drm/bridge: dw-hdmi: fix AVI frame colorimetry
From: Jernej Skrabec
[ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ]
CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.
Acked-by: Laurent Pinchart
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
encodings")
Signed-off-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +--
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index cc1094f901255..96cf64d0ee824 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1348,28 +1348,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
struct drm_display_mode *mode)
frame.colorspace = HDMI_COLORSPACE_RGB;
/* Set up colorimetry */
- switch (hdmi->hdmi_data.enc_out_encoding) {
- case V4L2_YCBCR_ENC_601:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
+ if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
+ switch (hdmi->hdmi_data.enc_out_encoding) {
+ case V4L2_YCBCR_ENC_601:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV601)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV709)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
+ break;
+ default: /* Carries no data */
frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ }
+ } else {
+ frame.colorimetry = HDMI_COLORIMETRY_NONE;
frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
- case V4L2_YCBCR_ENC_709:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
- frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
- break;
- default: /* Carries no data */
- frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
}
frame.scan_mode = HDMI_SCAN_MODE_NONE;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 10/19] drm/amdgpu: fix typo for vcn1 idle check
From: James Zhu
[ Upstream commit acfc62dc68770aa665cc606891f6df7d6d1e52c0 ]
fix typo for vcn1 idle check
Signed-off-by: James Zhu
Reviewed-by: Leo Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 93b3500e522b8..4f0f0de832937 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -1375,7 +1375,7 @@ static int vcn_v1_0_set_clockgating_state(void *handle,
if (enable) {
/* wait for STATUS to clear */
- if (vcn_v1_0_is_idle(handle))
+ if (!vcn_v1_0_is_idle(handle))
return -EBUSY;
vcn_v1_0_enable_clock_gating(adev);
} else {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 28/28] drm/lease: fix WARNING in idr_destroy
From: Qiujun Huang
[ Upstream commit b216a8e7908cd750550c0480cf7d2b3a37f06954 ]
drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.
drm_master_put
->drm_master_destroy
->idr_destroy
So we needn't call idr_destroy again.
Reported-and-tested-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjag...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_lease.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index b481cafdde280..825abe38201ac 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -542,10 +542,12 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
}
DRM_DEBUG_LEASE("Creating lease\n");
+ /* lessee will take the ownership of leases */
lessee = drm_lease_create(lessor, );
if (IS_ERR(lessee)) {
ret = PTR_ERR(lessee);
+ idr_destroy();
goto out_leases;
}
@@ -580,7 +582,6 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
out_leases:
put_unused_fd(fd);
- idr_destroy();
DRM_DEBUG_LEASE("drm_mode_create_lease_ioctl failed: %d\n", ret);
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 09/28] drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
From: Mario Kleiner
[ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ]
This fixes a problem found on the MacBookPro 2017 Retina panel:
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.
This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux <= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -> No modes for the laptop panel -> failure
to set any mode -> Panel goes dark.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.
Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.
Signed-off-by: Mario Kleiner
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 504055fc70e89..6f2b3ec17e7f0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2909,6 +2909,17 @@ static bool retrieve_link_cap(struct dc_link *link)
sink_id.ieee_device_id,
sizeof(sink_id.ieee_device_id));
+ /* Quirk Apple MBP 2017 15" Retina panel: Wrong DP_MAX_LINK_RATE */
+ {
+ uint8_t str_mbp_2017[] = { 101, 68, 21, 101, 98, 97 };
+
+ if ((link->dpcd_caps.sink_dev_id == 0x0010fa) &&
+ !memcmp(link->dpcd_caps.sink_dev_id_str, str_mbp_2017,
+ sizeof(str_mbp_2017))) {
+ link->reported_link_cap.link_rate = 0x0c;
+ }
+ }
+
core_link_read_dpcd(
link,
DP_SINK_HW_REVISION_START,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 08/28] drm/amdgpu: add fbdev suspend/resume on gpu reset
From: Evan Quan [ Upstream commit 063e768ebd27d3ec0d6908b7f8ea9b0a732b9949 ] This can fix the baco reset failure seen on Navi10. And this should be a low risk fix as the same sequence is already used for system suspend/resume. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 332b9c24a2cd0..9a8a1c6ca3210 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3854,6 +3854,8 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info *hive, if (r) goto out; + amdgpu_fbdev_set_suspend(tmp_adev, 0); + /* must succeed. */ amdgpu_ras_resume(tmp_adev); @@ -4023,6 +4025,8 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev, */ amdgpu_unregister_gpu_instance(tmp_adev); + amdgpu_fbdev_set_suspend(adev, 1); + /* disable ras on ALL IPs */ if (!in_ras_intr && amdgpu_device_ip_need_full_reset(tmp_adev)) amdgpu_ras_suspend(tmp_adev); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 10/28] drm/bochs: downgrade pci_request_region failure from error to warning
From: Gerd Hoffmann
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Link:
http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kra...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index e567bdfa2ab8e..bb1391784caf0 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -156,10 +156,8 @@ int bochs_hw_init(struct drm_device *dev)
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
- DRM_ERROR("Cannot request framebuffer\n");
- return -EBUSY;
- }
+ if (pci_request_region(pdev, 0, "bochs-drm") != 0)
+ DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size);
if (bochs->fb_map == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 02/28] drm/bridge: dw-hdmi: fix AVI frame colorimetry
From: Jernej Skrabec
[ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ]
CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.
Acked-by: Laurent Pinchart
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
encodings")
Signed-off-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skra...@siol.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +--
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 67fca439bbfb4..24965e53d351b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1624,28 +1624,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
struct drm_display_mode *mode)
frame.colorspace = HDMI_COLORSPACE_RGB;
/* Set up colorimetry */
- switch (hdmi->hdmi_data.enc_out_encoding) {
- case V4L2_YCBCR_ENC_601:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
+ if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
+ switch (hdmi->hdmi_data.enc_out_encoding) {
+ case V4L2_YCBCR_ENC_601:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV601)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ if (hdmi->hdmi_data.enc_in_encoding ==
V4L2_YCBCR_ENC_XV709)
+ frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ else
+ frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
+ break;
+ default: /* Carries no data */
frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
+ frame.extended_colorimetry =
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
+ break;
+ }
+ } else {
+ frame.colorimetry = HDMI_COLORIMETRY_NONE;
frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
- case V4L2_YCBCR_ENC_709:
- if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709)
- frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
- else
- frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
- break;
- default: /* Carries no data */
- frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
- frame.extended_colorimetry =
- HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
- break;
+ HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
}
frame.scan_mode = HDMI_SCAN_MODE_NONE;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
On Thu, 26 Mar 2020, Nathan Chancellor wrote: > This is the only warning on an x86_64 defconfig build. Apologies if we > are being too persistent or nagging but we need guidance from the i915 > maintainers on which solution they would prefer so it can be picked up. > I understand you all are busy and I appreciate the work you all do but > I do not want this to fall between the cracks because it is annoying to > constantly see this warning. Apologies for the delay. As I replied first thing in this thread, this works for me. Thanks for the patch, pushed to drm-intel-next-queued. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #3 from Cyrax (ev...@hotmail.com) --- GCC is "gcc (Arch Linux 9.3.0-1) 9.3.0" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'
On Wed, 25 Mar 2020 16:05:41 -0600 Rob Herring wrote: > Setting 'additionalProperties: false' is frequently omitted, but is > important in order to check that there aren't extra undocumented > properties in a binding. > > Ideally, we'd just add this automatically and make this the default, but > there's some cases where it doesn't work. For example, if a common > schema is referenced, then properties in the common schema aren't part > of what's considered for 'additionalProperties'. Also, sometimes there > are bus specific properties such as 'spi-max-frequency' that go into > bus child nodes, but aren't defined in the child node's schema. > > So let's stick with the json-schema defined default and add > 'additionalProperties: false' where needed. This will be a continual > review comment and game of wack-a-mole. > > Signed-off-by: Rob Herring Acked-by: Jonathan Cameron for IIO ones. Thanks. > --- > .../devicetree/bindings/arm/altera/socfpga-clk-manager.yaml| 2 ++ > .../bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml | 2 ++ > Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 2 ++ > Documentation/devicetree/bindings/arm/renesas,prr.yaml | 2 ++ > .../devicetree/bindings/arm/samsung/exynos-chipid.yaml | 2 ++ > Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 ++ > .../bindings/arm/samsung/samsung-secure-firmware.yaml | 2 ++ > .../devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++ > Documentation/devicetree/bindings/clock/fsl,plldig.yaml| 2 ++ > Documentation/devicetree/bindings/clock/imx8mn-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/imx8mp-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/milbeaut-clock.yaml| 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,msm8998-gpucc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-videocc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-videocc.yaml | 2 ++ > .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 2 ++ > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml| 2 ++ > Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++ > Documentation/devicetree/bindings/eeprom/at24.yaml | 2 ++ > .../firmware/intel,ixp4xx-network-processing-engine.yaml | 3 +++ > .../devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml | 2 ++ > .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++ > Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml| 2 ++ > .../devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 2 ++ > .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml| 2 ++ > .../devicetree/bindings/iio/chemical/plantower,pms7003.yaml| 2 ++ > .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 ++ > Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml| 2 ++ > Documentation/devicetree/bindings/iio/light/adux1020.yaml | 2 ++ > Documentation/devicetree/bindings/iio/light/bh1750.yaml
Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'
On Wed, 2020-03-25 at 16:05 -0600, Rob Herring wrote: > Setting 'additionalProperties: false' is frequently omitted, but is > important in order to check that there aren't extra undocumented > properties in a binding. > > Ideally, we'd just add this automatically and make this the default, but > there's some cases where it doesn't work. For example, if a common > schema is referenced, then properties in the common schema aren't part > of what's considered for 'additionalProperties'. Also, sometimes there > are bus specific properties such as 'spi-max-frequency' that go into > bus child nodes, but aren't defined in the child node's schema. > > So let's stick with the json-schema defined default and add > 'additionalProperties: false' where needed. This will be a continual > review comment and game of wack-a-mole. For Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml .../devicetree/bindings/iio/temperature/adi,ltc2983.yaml Documentation/devicetree/bindings/sound/adi,adau7118.yaml [also, if i missed any, also for any other ADI or LTC bindings] Acked-by: Alexandru Ardelean > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/altera/socfpga-clk-manager.yaml| 2 ++ > .../bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml | 2 ++ > Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 2 ++ > Documentation/devicetree/bindings/arm/renesas,prr.yaml | 2 ++ > .../devicetree/bindings/arm/samsung/exynos-chipid.yaml | 2 ++ > Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 ++ > .../bindings/arm/samsung/samsung-secure-firmware.yaml | 2 ++ > .../devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++ > Documentation/devicetree/bindings/clock/fsl,plldig.yaml| 2 ++ > Documentation/devicetree/bindings/clock/imx8mn-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/imx8mp-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/milbeaut-clock.yaml| 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,msm8998-gpucc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-videocc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-videocc.yaml | 2 ++ > .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 2 ++ > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml| 2 ++ > Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++ > Documentation/devicetree/bindings/eeprom/at24.yaml | 2 ++ > .../firmware/intel,ixp4xx-network-processing-engine.yaml | 3 +++ > .../devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml | 2 ++ > .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++ > Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml| 2 ++ >
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
On 26/03/2020 15:51, CK Hu wrote:
> Hi, Matthias:
>
> On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote:
>> Hi CK,
>>
>> On 26/03/2020 00:05, CK Hu wrote:
>>> Hi, Matthias:
>>>
>>> On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote:
On 11/03/2020 17:53, Enric Balletbo i Serra wrote:
> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
> Those functions will allow DRM driver and others to control the data
> path routing.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Matthias Brugger
> Reviewed-by: CK Hu
> Acked-by: CK Hu
This patch does not apply against v5.6-rc1.
Please rebase as this is a quite big patch and it won't be easy to do that
by hand.
>>>
>>> I think this patch depends on [1] which has been acked by me and I have
>>> not picked it. The simple way is that you pick [1] first and then pick
>>> this series.
>>>
>>> [1]
>>> https://patchwork.kernel.org/patch/11406227/
>>>
>>
>> You would need to provide a stable tag for me that I can merge into my tree.
>> You
>> can also try to merge my for-next [1] which has the newest version from
>> Enric.
>> If you see any merge conflict, then we have to do something about it :)
>>
>> Regards,
>> Matthias
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>>
>
> You have applied this series, so I would not apply other patches which
> would conflict with this series. After this series land on main stream
> (wish it happen in this merge window), I would rebase other patch on
> main stream.
>
I haven't (yet) send the pull request. If you want to bring in your patches in
v5.7 as well we can find a solution to that. Shall I provide you with a stable
branch which you can merge? This way you can add all your patches in the pull
request as well and we don't have to wait for v5.8 to get things into mainline.
Let me know and I'll provide you with a stable branch.
Regards,
Matthias
> Regards,
> CK
>
>>> Regards,
>>> CK
>>>
Regards,
Matthias
> ---
>
> Changes in v12: None
> Changes in v10:
> - Select CONFIG_MTK_MMSYS (CK)
> - Pass device pointer of mmsys device instead of config regs (CK)
>
> Changes in v9:
> - Introduced a new patch to move routing control into mmsys driver.
> - Removed the patch to use regmap as is not needed anymore.
>
> Changes in v8: None
> Changes in v7: None
>
> drivers/gpu/drm/mediatek/Kconfig| 1 +
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> drivers/soc/mediatek/mtk-mmsys.c| 279
> include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
> 8 files changed, 316 insertions(+), 282 deletions(-)
> create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
>
> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> b/drivers/gpu/drm/mediatek/Kconfig
> index fa5ffc4fe823..c420f5a3d33b 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -11,6 +11,7 @@ config DRM_MEDIATEK
> select DRM_MIPI_DSI
> select DRM_PANEL
> select MEMORY
> + select MTK_MMSYS
> select MTK_SMI
> select VIDEOMODE_HELPERS
> help
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0e05683d7b53..579a5a5d4472 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -28,7 +29,7 @@
> * @enabled: records whether crtc_enable succeeded
> * @planes: array of 4 drm_plane structures, one for each overlay plane
> * @pending_planes: whether any plane has pending changes to be applied
> - * @config_regs: memory mapped mmsys configuration register space
> + * @mmsys_dev: pointer to the mmsys device for configuration registers
> * @mutex: handle to one of the ten disp_mutex streams
> * @ddp_comp_nr: number of components in ddp_comp
> * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this
> crtc
> @@ -50,7 +51,7 @@ struct mtk_drm_crtc {
> u32 cmdq_event;
> #endif
>
> - void __iomem*config_regs;
> + struct device *mmsys_dev;
> struct mtk_disp_mutex *mutex;
> unsigned intddp_comp_nr;
> struct mtk_ddp_comp
[PATCH 0/6] gpu: convert to use new I2C API
We are deprecating calls which return NULL in favor of new variants which return an ERR_PTR. Only build tested. Wolfram Sang (6): drm/amdgpu: convert to use i2c_new_client_device() drm/gma500: convert to use i2c_new_client_device() drm/i2c/sil164: convert to use i2c_new_client_device() drm/i2c/tda998x: convert to use i2c_new_client_device() drm/nouveau/therm: convert to use i2c_new_client_device() drm/radeon: convert to use i2c_new_client_device() drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 2 +- drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 8 drivers/gpu/drm/i2c/sil164_drv.c | 7 +-- drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++-- drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++-- drivers/gpu/drm/radeon/radeon_combios.c| 4 ++-- 7 files changed, 19 insertions(+), 16 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/radeon: convert to use i2c_new_client_device()
Move away from the deprecated API.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++--
drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 848ef68d9086..5d2591725189 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2111,7 +2111,7 @@ static int radeon_atombios_parse_power_table_1_3(struct
radeon_device *rdev)
ucOverdriveThermalController];
info.addr =
power_info->info.ucOverdriveControllerAddress >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter, );
+ i2c_new_client_device(>pm.i2c_bus->adapter,
);
}
}
num_modes = power_info->info.ucNumOfPowerModeEntries;
@@ -2351,7 +2351,7 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
const char *name =
pp_lib_thermal_controller_names[controller->ucType];
info.addr = controller->ucI2cAddress >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
} else {
DRM_INFO("Unknown thermal controller type %d at 0x%02x
%s fan control\n",
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index c3e49c973812..d3c04df7e75d 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2704,7 +2704,7 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
const char *name =
thermal_controller_names[thermal_controller];
info.addr = i2c_addr >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
}
} else {
@@ -2721,7 +2721,7 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
const char *name = "f75375";
info.addr = 0x28;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
DRM_INFO("Possible %s thermal controller at
0x%02x\n",
name, info.addr);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/nouveau/therm: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
index 03b355dabab3..abf3eda683f0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
@@ -36,8 +36,8 @@ probe_monitoring_device(struct nvkm_i2c_bus *bus,
request_module("%s%s", I2C_MODULE_PREFIX, info->type);
- client = i2c_new_device(>i2c, info);
- if (!client)
+ client = i2c_new_client_device(>i2c, info);
+ if (IS_ERR(client))
return false;
if (!client->dev.driver ||
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #2 from Cyrax (ev...@hotmail.com) --- Created attachment 288079 --> https://bugzilla.kernel.org/attachment.cgi?id=288079=edit dmesg output -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/i2c/sil164: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index a839f78a4c8a..741886b54419 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -393,7 +393,7 @@ sil164_detect_slave(struct i2c_client *client)
return NULL;
}
- return i2c_new_device(adap, );
+ return i2c_new_client_device(adap, );
}
static int
@@ -402,6 +402,7 @@ sil164_encoder_init(struct i2c_client *client,
struct drm_encoder_slave *encoder)
{
struct sil164_priv *priv;
+ struct i2c_client *slave_client;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -410,7 +411,9 @@ sil164_encoder_init(struct i2c_client *client,
encoder->slave_priv = priv;
encoder->slave_funcs = _encoder_funcs;
- priv->duallink_slave = sil164_detect_slave(client);
+ slave_client = sil164_detect_slave(client);
+ if (!IS_ERR(slave_client))
+ priv->duallink_slave = slave_client;
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes
Hi Daniel, Dave, Here's the first drm-misc-next-fixes PR for 5.7. Thanks! Maxime drm-misc-next-fixes-2020-03-26: Two main topics in that first drm-misc-next-fixes PR, first a revert of the data-mapping property in the DT that turned out to be non-optimal (but hasn't reached a stable release yet), and an improvement of a Kconfig help text. The following changes since commit 6afe6929964bca6847986d0507a555a041f07753: drm: Mark up racy check of drm_gem_object.handle_count (2020-03-16 10:31:35 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-03-26 for you to fetch changes up to d021d751c14752a0266865700f6f212fab40a18c: drm/panel-simple: drop use of data-mapping property (2020-03-25 21:59:22 +0100) Two main topics in that first drm-misc-next-fixes PR, first a revert of the data-mapping property in the DT that turned out to be non-optimal (but hasn't reached a stable release yet), and an improvement of a Kconfig help text. Geert Uytterhoeven (1): dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text Sam Ravnborg (2): dt-bindings: display: drop data-mapping from panel-dpi drm/panel-simple: drop use of data-mapping property .../devicetree/bindings/display/panel/panel-dpi.yaml | 10 -- drivers/dma-buf/Kconfig | 11 ++- drivers/gpu/drm/panel/panel-simple.c | 11 --- 3 files changed, 6 insertions(+), 26 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/amdgpu: convert to use i2c_new_client_device()
Move away from the deprecated API.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
index ba1bb95a3cf9..0e8018c9aa8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
@@ -856,7 +856,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device
*adev)
const char *name =
pp_lib_thermal_controller_names[controller->ucType];
info.addr = controller->ucI2cAddress >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
} else {
DRM_INFO("Unknown thermal controller type %d at 0x%02x
%s fan control\n",
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] video: convert to use new I2C API
We are deprecating calls which return NULL in favor of new variants which return an ERR_PTR. Only build tested. Wolfram Sang (1): video: backlight: tosa_lcd: convert to use i2c_new_client_device() drivers/video/backlight/tosa_lcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/i2c/tda998x: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index c3332209f27a..d9a548d0273c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1949,9 +1949,9 @@ static int tda998x_create(struct device *dev)
cec_info.platform_data = >cec_glue;
cec_info.irq = client->irq;
- priv->cec = i2c_new_device(client->adapter, _info);
- if (!priv->cec) {
- ret = -ENODEV;
+ priv->cec = i2c_new_client_device(client->adapter, _info);
+ if (IS_ERR(priv->cec)) {
+ ret = PTR_ERR(priv->cec);
goto fail;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix HDMI mode validation
On Thu, Mar 26, 2020 at 01:20:01PM +0100, Nicolas Saenz Julienne wrote:
> Current mode validation impedes setting up some video modes which should
> be supported otherwise. Namely 1920x1200@60Hz.
>
> Fix this by lowering the minimum HDMI state machine clock to pixel clock
> ratio allowed.
>
> Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> Reported-by: Stefan Wahren
> Suggested-by: Dave Stevenson
> Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false'
On Wed, 2020-03-25 at 16:05 -0600, Rob Herring wrote: > Numerous schemas are missing 'additionalProperties: false' statements which > ensures a binding doesn't have any extra undocumented properties or child > nodes. Fixing this reveals various missing properties, so let's fix all > those occurrences. > For 'bindings/iio/adc/adi,ad7192.yaml' Acked-by: Alexandru Ardelean > Cc: Stephen Boyd > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Masahiro Yamada > Cc: Jonathan Cameron > Cc: Hartmut Knaack > Cc: Lars-Peter Clausen > Cc: Peter Meerwald-Stadler > Cc: Neil Armstrong > Cc: Mauro Carvalho Chehab > Cc: Kevin Hilman > Cc: Lee Jones > Cc: "David S. Miller" > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Guillaume La Roque > Cc: Zhang Rui > Cc: Daniel Lezcano > Cc: Thomas Gleixner > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-amlo...@lists.infradead.org > Cc: net...@vger.kernel.org > Cc: linux...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/clock/fsl,plldig.yaml | 3 +++ > .../gpio/socionext,uniphier-gpio.yaml | 2 ++ > .../bindings/gpu/arm,mali-bifrost.yaml| 6 ++--- > .../bindings/gpu/arm,mali-midgard.yaml| 3 +++ > .../bindings/iio/adc/adi,ad7192.yaml | 1 - > .../bindings/iio/pressure/bmp085.yaml | 3 +++ > .../media/amlogic,meson-gx-ao-cec.yaml| 9 +--- > .../bindings/mfd/rohm,bd71828-pmic.yaml | 3 +++ > .../bindings/net/ti,cpsw-switch.yaml | 23 --- > .../regulator/max77650-regulator.yaml | 2 +- > .../bindings/thermal/amlogic,thermal.yaml | 2 ++ > .../bindings/timer/arm,arch_timer_mmio.yaml | 2 ++ > 12 files changed, 43 insertions(+), 16 deletions(-) > > diff --git a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > index c8350030b374..d1c040228cf7 100644 > --- a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > +++ b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > @@ -21,6 +21,9 @@ properties: >reg: > maxItems: 1 > > + clocks: > +maxItems: 1 > + >'#clock-cells': > const: 0 > > diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier- > gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier- > gpio.yaml > index 580a39e09d39..c58ff9a94f45 100644 > --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml > +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml > @@ -41,6 +41,8 @@ properties: > minimum: 0 > maximum: 512 > > + gpio-ranges: true > + >gpio-ranges-group-names: > $ref: /schemas/types.yaml#/definitions/string-array > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > index e8b99adcb1bd..05fd9a404ff7 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > @@ -43,6 +43,9 @@ properties: > >operating-points-v2: true > > + resets: > +maxItems: 2 > + > required: >- compatible >- reg > @@ -57,9 +60,6 @@ allOf: >contains: > const: amlogic,meson-g12a-mali > then: > - properties: > -resets: > - minItems: 2 >required: > - resets > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > index 8d966f3ff3db..6819cde050df 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > @@ -75,6 +75,9 @@ properties: > >mali-supply: true > > + power-domains: > +maxItems: 1 > + >resets: > minItems: 1 > maxItems: 2 > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > index 84d25bd39488..d0913034b1d8 100644 > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > @@ -106,7 +106,6 @@ examples: > spi-cpha; > clocks = <_mclk>; > clock-names = "mclk"; > -#interrupt-cells = <2>; > interrupts = <25 0x2>; > interrupt-parent = <>; > dvdd-supply = <>; > diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > index 519137e5c170..5d4aec0e0d24 100644 > --- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > +++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > @@ -25,6 +25,9 @@ properties: >-
Re: [PATCH 3/4] dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false'
On Wed, 25 Mar 2020 16:05:40 -0600 Rob Herring wrote: > Numerous schemas are missing 'additionalProperties: false' statements which > ensures a binding doesn't have any extra undocumented properties or child > nodes. Fixing this reveals various missing properties, so let's fix all > those occurrences. > > Cc: Stephen Boyd > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Masahiro Yamada > Cc: Jonathan Cameron > Cc: Hartmut Knaack > Cc: Lars-Peter Clausen > Cc: Peter Meerwald-Stadler > Cc: Neil Armstrong > Cc: Mauro Carvalho Chehab > Cc: Kevin Hilman > Cc: Lee Jones > Cc: "David S. Miller" > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Guillaume La Roque > Cc: Zhang Rui > Cc: Daniel Lezcano > Cc: Thomas Gleixner > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-amlo...@lists.infradead.org > Cc: net...@vger.kernel.org > Cc: linux...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: Jonathan Cameron #for-iio > --- > .../devicetree/bindings/clock/fsl,plldig.yaml | 3 +++ > .../gpio/socionext,uniphier-gpio.yaml | 2 ++ > .../bindings/gpu/arm,mali-bifrost.yaml| 6 ++--- > .../bindings/gpu/arm,mali-midgard.yaml| 3 +++ > .../bindings/iio/adc/adi,ad7192.yaml | 1 - > .../bindings/iio/pressure/bmp085.yaml | 3 +++ > .../media/amlogic,meson-gx-ao-cec.yaml| 9 +--- > .../bindings/mfd/rohm,bd71828-pmic.yaml | 3 +++ > .../bindings/net/ti,cpsw-switch.yaml | 23 --- > .../regulator/max77650-regulator.yaml | 2 +- > .../bindings/thermal/amlogic,thermal.yaml | 2 ++ > .../bindings/timer/arm,arch_timer_mmio.yaml | 2 ++ > 12 files changed, 43 insertions(+), 16 deletions(-) > > diff --git a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > index c8350030b374..d1c040228cf7 100644 > --- a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > +++ b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml > @@ -21,6 +21,9 @@ properties: >reg: > maxItems: 1 > > + clocks: > +maxItems: 1 > + >'#clock-cells': > const: 0 > > diff --git > a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml > b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml > index 580a39e09d39..c58ff9a94f45 100644 > --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml > +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml > @@ -41,6 +41,8 @@ properties: > minimum: 0 > maximum: 512 > > + gpio-ranges: true > + >gpio-ranges-group-names: > $ref: /schemas/types.yaml#/definitions/string-array > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > index e8b99adcb1bd..05fd9a404ff7 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > @@ -43,6 +43,9 @@ properties: > >operating-points-v2: true > > + resets: > +maxItems: 2 > + > required: >- compatible >- reg > @@ -57,9 +60,6 @@ allOf: >contains: > const: amlogic,meson-g12a-mali > then: > - properties: > -resets: > - minItems: 2 >required: > - resets > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > index 8d966f3ff3db..6819cde050df 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml > @@ -75,6 +75,9 @@ properties: > >mali-supply: true > > + power-domains: > +maxItems: 1 > + >resets: > minItems: 1 > maxItems: 2 > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > index 84d25bd39488..d0913034b1d8 100644 > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml > @@ -106,7 +106,6 @@ examples: > spi-cpha; > clocks = <_mclk>; > clock-names = "mclk"; > -#interrupt-cells = <2>; > interrupts = <25 0x2>; > interrupt-parent = <>; > dvdd-supply = <>; > diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > index 519137e5c170..5d4aec0e0d24 100644 > --- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > +++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml > @@ -25,6 +25,9 @@ properties: >- bosch,bmp280 >- bosch,bme280
Re: [PATCH 1/4] dt-bindings: iio/accel: Drop duplicate adi, adxl345/6 from trivial-devices.yaml
On Thu, 26 Mar 2020 07:57:31 + "Ardelean, Alexandru" wrote: > On Wed, 2020-03-25 at 16:05 -0600, Rob Herring wrote: > > [External] > > > > The 'adi,adxl345' definition is a duplicate as there's a full binding in: > > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > > > The trivial-devices binding doesn't capture that 'adi,adxl346' has a > > fallback compatible 'adi,adxl345', so let's add it to adi,adxl345.yaml. > > > > Acked-by: Alexandru Ardelean Acked-by: Jonathan Cameron > > > Cc: Michael Hennerich > > Cc: Jonathan Cameron > > Cc: Hartmut Knaack > > Cc: Lars-Peter Clausen > > Cc: Peter Meerwald-Stadler > > Cc: linux-...@vger.kernel.org > > Signed-off-by: Rob Herring > > --- > > .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 10 +++--- > > Documentation/devicetree/bindings/trivial-devices.yaml | 4 > > 2 files changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > index c602b6fe1c0c..d124eba1ce54 100644 > > --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > @@ -17,9 +17,13 @@ description: | > > > > properties: > >compatible: > > -enum: > > - - adi,adxl345 > > - - adi,adxl375 > > +oneOf: > > + - items: > > + - const: adi,adxl346 > > + - const: adi,adxl345 > > + - enum: > > + - adi,adxl345 > > + - adi,adxl375 > > > >reg: > > maxItems: 1 > > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml > > b/Documentation/devicetree/bindings/trivial-devices.yaml > > index 978de7d37c66..51d1f6e43c02 100644 > > --- a/Documentation/devicetree/bindings/trivial-devices.yaml > > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > > @@ -42,10 +42,6 @@ properties: > >- adi,adt7476 > > # +/-1C TDM Extended Temp Range I.C > >- adi,adt7490 > > -# Three-Axis Digital Accelerometer > > - - adi,adxl345 > > -# Three-Axis Digital Accelerometer (backward-compatibility > > value > > "adi,adxl345" must be listed too) > > - - adi,adxl346 > > # AMS iAQ-Core VOC Sensor > >- ams,iaq-core > > # i2c serial eeprom (24cxx) > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/gma500: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
index 9e8224456ea2..71574063c63e 100644
--- a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
+++ b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
@@ -747,11 +747,11 @@ static int cmi_lcd_hack_create_device(void)
return -EINVAL;
}
- client = i2c_new_device(adapter, );
- if (!client) {
- pr_err("%s: i2c_new_device() failed\n", __func__);
+ client = i2c_new_client_device(adapter, );
+ if (IS_ERR(client)) {
+ pr_err("%s: creating I2C device failed\n", __func__);
i2c_put_adapter(adapter);
- return -EINVAL;
+ return PTR_ERR(client);
}
return 0;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] video: backlight: tosa_lcd: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index e8ab583e5098..113116d3585c 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -107,7 +107,7 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
/* TG LCD GVSS */
tosa_tg_send(spi, TG_PINICTL, 0x0);
- if (!data->i2c) {
+ if (IS_ERR_OR_NULL(data->i2c)) {
/*
* after the pannel is powered up the first time,
* we can access the i2c bus so probe for the DAC
@@ -119,7 +119,7 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
.addr = DAC_BASE,
.platform_data = data->spi,
};
- data->i2c = i2c_new_device(adap, );
+ data->i2c = i2c_new_client_device(adap, );
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Fix HDMI mode validation
Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.
Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.
Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
Reported-by: Stefan Wahren
Suggested-by: Dave Stevenson
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index cea18dc15f77..340719238753 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -681,11 +681,23 @@ static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
- /* HSM clock must be 108% of the pixel clock. Additionally,
-* the AXI clock needs to be at least 25% of pixel clock, but
-* HSM ends up being the limiting factor.
+ /*
+* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
+* be faster than pixel clock, infinitesimally faster, tested in
+* simulation. Otherwise, exact value is unimportant for HDMI
+* operation." This conflicts with bcm2835's vc4 documentation, which
+* states HSM's clock has to be at least 108% of the pixel clock.
+*
+* Real life tests reveal that vc4's firmware statement holds up, and
+* users are able to use pixel clocks closer to HSM's, namely for
+* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
+* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
+* 162MHz.
+*
+* Additionally, the AXI clock needs to be at least 25% of
+* pixel clock, but HSM ends up being the limiting factor.
*/
- if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+ if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
return MODE_CLOCK_HIGH;
return MODE_OK;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
On Mon, Mar 16, 2020 at 02:41:23PM -0700, Nick Desaulniers wrote: > On Fri, Feb 14, 2020 at 7:36 AM Michel Dänzer wrote: > > > > On 2020-02-14 12:49 p.m., Jani Nikula wrote: > > > On Fri, 14 Feb 2020, Chris Wilson wrote: > > >> Quoting Jani Nikula (2020-02-14 06:36:15) > > >>> On Thu, 13 Feb 2020, Nathan Chancellor wrote: > > A recent commit in clang added -Wtautological-compare to -Wall, which > > is > > enabled for i915 after -Wtautological-compare is disabled for the rest > > of the kernel so we see the following warning on x86_64: > > > > ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning: > > result of comparison of constant 576460752303423487 with expression of > > type 'unsigned int' is always false > > [-Wtautological-constant-out-of-range-compare] > > if (unlikely(remain > N_RELOC(ULONG_MAX))) > > ^ > > ../include/linux/compiler.h:78:42: note: expanded from macro > > 'unlikely' > > # define unlikely(x)__builtin_expect(!!(x), 0) > > ^ > > 1 warning generated. > > > > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not > > account for the case where this file is built for 32-bit x86, where > > ULONG_MAX == UINT_MAX and this check is still relevant. > > > > Cast remain to unsigned long, which keeps the generated code the same > > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and > > the warning is silenced so we can catch more potential issues in the > > future. > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/778 > > Suggested-by: Michel Dänzer > > Signed-off-by: Nathan Chancellor > > >>> > > >>> Works for me as a workaround, > > >> > > >> But the whole point was that the compiler could see that it was > > >> impossible and not emit the code. Doesn't this break that? > > > > > > It seems that goal and the warning are fundamentally incompatible. > > > > Not really: > > > > if (sizeof(remain) >= sizeof(unsigned long) && > > unlikely(remain > N_RELOC(ULONG_MAX))) > > return -EINVAL; > > > > In contrast to the cast, this doesn't generate any machine code on 64-bit: > > > > https://godbolt.org/z/GmUE4S > > > > but still generates the same code on 32-bit: > > > > https://godbolt.org/z/hAoz8L > > Exactly. > > This check is only a tautology when `sizeof(long) == sizeof(int)` (ie. > ILP32 platforms, like 32b x86), notice how BOTH GCC AND Clang generate > exactly the same code: https://godbolt.org/z/6ShrDM > > Both compilers eliminate the check when `-m32` is not set, and > generate the exact same check otherwise. How about: > ``` > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > index d3f4f28e9468..25b9d3f3ad57 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > @@ -1415,8 +1415,10 @@ static int eb_relocate_vma(struct > i915_execbuffer *eb, struct eb_vma *ev) > > urelocs = u64_to_user_ptr(entry->relocs_ptr); > remain = entry->relocation_count; > +#ifndef CONFIG_64BIT > if (unlikely(remain > N_RELOC(ULONG_MAX))) > return -EINVAL; > +#endif > > /* > * We must check that the entire relocation array is safe > ``` > > We now have 4 proposed solutions: > 1. > https://lore.kernel.org/lkml/20191123195321.41305-1-natechancel...@gmail.com/ > 2. > https://lore.kernel.org/lkml/20200211050808.29463-1-natechancel...@gmail.com/ > 3. > https://lore.kernel.org/lkml/20200214054706.33870-1-natechancel...@gmail.com/ > 4. my diff above > Let's please come to a resolution on this. This is the only warning on an x86_64 defconfig build. Apologies if we are being too persistent or nagging but we need guidance from the i915 maintainers on which solution they would prefer so it can be picked up. I understand you all are busy and I appreciate the work you all do but I do not want this to fall between the cracks because it is annoying to constantly see this warning. Cheers, Nathan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Hi CK,
On 26/03/2020 00:05, CK Hu wrote:
> Hi, Matthias:
>
> On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote:
>>
>> On 11/03/2020 17:53, Enric Balletbo i Serra wrote:
>>> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
>>> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
>>> Those functions will allow DRM driver and others to control the data
>>> path routing.
>>>
>>> Signed-off-by: Enric Balletbo i Serra
>>> Reviewed-by: Matthias Brugger
>>> Reviewed-by: CK Hu
>>> Acked-by: CK Hu
>>
>> This patch does not apply against v5.6-rc1.
>> Please rebase as this is a quite big patch and it won't be easy to do that
>> by hand.
>
> I think this patch depends on [1] which has been acked by me and I have
> not picked it. The simple way is that you pick [1] first and then pick
> this series.
>
> [1]
> https://patchwork.kernel.org/patch/11406227/
>
You would need to provide a stable tag for me that I can merge into my tree. You
can also try to merge my for-next [1] which has the newest version from Enric.
If you see any merge conflict, then we have to do something about it :)
Regards,
Matthias
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
> Regards,
> CK
>
>>
>> Regards,
>> Matthias
>>
>>> ---
>>>
>>> Changes in v12: None
>>> Changes in v10:
>>> - Select CONFIG_MTK_MMSYS (CK)
>>> - Pass device pointer of mmsys device instead of config regs (CK)
>>>
>>> Changes in v9:
>>> - Introduced a new patch to move routing control into mmsys driver.
>>> - Removed the patch to use regmap as is not needed anymore.
>>>
>>> Changes in v8: None
>>> Changes in v7: None
>>>
>>> drivers/gpu/drm/mediatek/Kconfig| 1 +
>>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
>>> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
>>> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
>>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
>>> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
>>> drivers/soc/mediatek/mtk-mmsys.c| 279
>>> include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
>>> 8 files changed, 316 insertions(+), 282 deletions(-)
>>> create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/Kconfig
>>> b/drivers/gpu/drm/mediatek/Kconfig
>>> index fa5ffc4fe823..c420f5a3d33b 100644
>>> --- a/drivers/gpu/drm/mediatek/Kconfig
>>> +++ b/drivers/gpu/drm/mediatek/Kconfig
>>> @@ -11,6 +11,7 @@ config DRM_MEDIATEK
>>> select DRM_MIPI_DSI
>>> select DRM_PANEL
>>> select MEMORY
>>> + select MTK_MMSYS
>>> select MTK_SMI
>>> select VIDEOMODE_HELPERS
>>> help
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> index 0e05683d7b53..579a5a5d4472 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> @@ -6,6 +6,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -28,7 +29,7 @@
>>> * @enabled: records whether crtc_enable succeeded
>>> * @planes: array of 4 drm_plane structures, one for each overlay plane
>>> * @pending_planes: whether any plane has pending changes to be applied
>>> - * @config_regs: memory mapped mmsys configuration register space
>>> + * @mmsys_dev: pointer to the mmsys device for configuration registers
>>> * @mutex: handle to one of the ten disp_mutex streams
>>> * @ddp_comp_nr: number of components in ddp_comp
>>> * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this
>>> crtc
>>> @@ -50,7 +51,7 @@ struct mtk_drm_crtc {
>>> u32 cmdq_event;
>>> #endif
>>>
>>> - void __iomem*config_regs;
>>> + struct device *mmsys_dev;
>>> struct mtk_disp_mutex *mutex;
>>> unsigned intddp_comp_nr;
>>> struct mtk_ddp_comp **ddp_comp;
>>> @@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
>>> *mtk_crtc)
>>> }
>>>
>>> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
>>> - mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
>>> -mtk_crtc->ddp_comp[i]->id,
>>> -mtk_crtc->ddp_comp[i + 1]->id);
>>> + mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
>>> + mtk_crtc->ddp_comp[i]->id,
>>> + mtk_crtc->ddp_comp[i + 1]->id);
>>> mtk_disp_mutex_add_comp(mtk_crtc->mutex,
>>> mtk_crtc->ddp_comp[i]->id);
>>> }
>>> @@ -355,9 +356,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
>>> *mtk_crtc)
>>>mtk_crtc->ddp_comp[i]->id);
>>> mtk_disp_mutex_disable(mtk_crtc->mutex);
>>> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1;
Re: [PATCH] drm/vc4: Fix HDMI mode validation
On Thu, 2020-03-26 at 18:19 +0100, Stefan Wahren wrote:
> Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
> > Current mode validation impedes setting up some video modes which should
> > be supported otherwise. Namely 1920x1200@60Hz.
> >
> > Fix this by lowering the minimum HDMI state machine clock to pixel clock
> > ratio allowed.
> >
> > Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> > Reported-by: Stefan Wahren
> > Suggested-by: Dave Stevenson
> > Signed-off-by: Nicolas Saenz Julienne
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 20
> > 1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index cea18dc15f77..340719238753 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -681,11 +681,23 @@ static enum drm_mode_status
> > vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
> > const struct drm_display_mode *mode)
> > {
> > - /* HSM clock must be 108% of the pixel clock. Additionally,
> > -* the AXI clock needs to be at least 25% of pixel clock, but
> > -* HSM ends up being the limiting factor.
> > + /*
> > +* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> > +* be faster than pixel clock, infinitesimally faster, tested in
> > +* simulation. Otherwise, exact value is unimportant for HDMI
> > +* operation." This conflicts with bcm2835's vc4 documentation, which
> > +* states HSM's clock has to be at least 108% of the pixel clock.
> > +*
> > +* Real life tests reveal that vc4's firmware statement holds up, and
> > +* users are able to use pixel clocks closer to HSM's, namely for
> > +* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> > +* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
>
> s/RPi0-3/bcm2835/ ?
Well as Dave Stevenson stated on the previous thread[1], it's the firmware that
sets up the HSM limitation. IIUC technically both HSM and pixel clocks could be
increased. Hence this being more of a RPi limitation than the chip itself.
"Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I
don't anticipate there being any issue with varying it. It looks like
there was the expectation of it being variable in the past, but
someone has refactored it and either accidentally or deliberately
given up on the idea."
Regards,
Nicolas
[1] https://www.spinics.net/lists/arm-kernel/msg794591.html
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: iio/accel: Drop duplicate adi, adxl345/6 from trivial-devices.yaml
On Wed, 2020-03-25 at 16:05 -0600, Rob Herring wrote: > [External] > > The 'adi,adxl345' definition is a duplicate as there's a full binding in: > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > The trivial-devices binding doesn't capture that 'adi,adxl346' has a > fallback compatible 'adi,adxl345', so let's add it to adi,adxl345.yaml. > Acked-by: Alexandru Ardelean > Cc: Michael Hennerich > Cc: Jonathan Cameron > Cc: Hartmut Knaack > Cc: Lars-Peter Clausen > Cc: Peter Meerwald-Stadler > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 10 +++--- > Documentation/devicetree/bindings/trivial-devices.yaml | 4 > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > index c602b6fe1c0c..d124eba1ce54 100644 > --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > @@ -17,9 +17,13 @@ description: | > > properties: >compatible: > -enum: > - - adi,adxl345 > - - adi,adxl375 > +oneOf: > + - items: > + - const: adi,adxl346 > + - const: adi,adxl345 > + - enum: > + - adi,adxl345 > + - adi,adxl375 > >reg: > maxItems: 1 > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml > b/Documentation/devicetree/bindings/trivial-devices.yaml > index 978de7d37c66..51d1f6e43c02 100644 > --- a/Documentation/devicetree/bindings/trivial-devices.yaml > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > @@ -42,10 +42,6 @@ properties: >- adi,adt7476 > # +/-1C TDM Extended Temp Range I.C >- adi,adt7490 > -# Three-Axis Digital Accelerometer > - - adi,adxl345 > -# Three-Axis Digital Accelerometer (backward-compatibility value > "adi,adxl345" must be listed too) > - - adi,adxl346 > # AMS iAQ-Core VOC Sensor >- ams,iaq-core > # i2c serial eeprom (24cxx) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 hmm 0/9] Small hmm_range_fault() cleanups
On 3/23/20 6:14 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This is v2 of the first simple series with a few additional patches of little adjustments. This needs an additional patch to the hmm tester: diff --git a/tools/testing/selftests/vm/hmm-tests.c b/tools/testing/selftests/vm/hmm-tests.c index 033a12c7ab5b6d..da15471a2bbf9a 100644 --- a/tools/testing/selftests/vm/hmm-tests.c +++ b/tools/testing/selftests/vm/hmm-tests.c @@ -1274,7 +1274,7 @@ TEST_F(hmm2, snapshot) /* Check what the device saw. */ m = buffer->mirror; ASSERT_EQ(m[0], HMM_DMIRROR_PROT_ERROR); - ASSERT_EQ(m[1], HMM_DMIRROR_PROT_NONE); + ASSERT_EQ(m[1], HMM_DMIRROR_PROT_ERROR); ASSERT_EQ(m[2], HMM_DMIRROR_PROT_ZERO | HMM_DMIRROR_PROT_READ); ASSERT_EQ(m[3], HMM_DMIRROR_PROT_READ); ASSERT_EQ(m[4], HMM_DMIRROR_PROT_WRITE); v2 changes: - Simplify and rename the flags, rework hmm_vma_walk_test in patch 2 (CH) - Adjust more comments in patch 3 (CH, Ralph) - Put the ugly boolean logic into a function in patch 3 (CH) - Update commit message of patch 4 (CH) - Adjust formatting in patch 5 (CH) Patches 6, 7, 8 are new v1: https://lore.kernel.org/r/20200320164905.21722-1-...@ziepe.ca Jason Gunthorpe (9): mm/hmm: remove pgmap checking for devmap pages mm/hmm: return the fault type from hmm_pte_need_fault() mm/hmm: remove unused code and tidy comments mm/hmm: remove HMM_FAULT_SNAPSHOT mm/hmm: remove the CONFIG_TRANSPARENT_HUGEPAGE #ifdef mm/hmm: use device_private_entry_to_pfn() mm/hmm: do not unconditionally set pfns when returning EBUSY mm/hmm: do not set pfns when returning an error code mm/hmm: return error for non-vma snapshots Documentation/vm/hmm.rst| 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +- include/linux/hmm.h | 109 + mm/hmm.c| 312 ++-- 5 files changed, 133 insertions(+), 304 deletions(-) I was able to recompile Karol Herbst's mesa tree and Jerome's SVM tests to test this with nouveau so for the series you can add, Tested-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
On Fri, Mar 27, 2020 at 5:46 AM Jason A. Donenfeld wrote: > > On Thu, Mar 26, 2020 at 2:44 PM Masahiro Yamada wrote: > > I collected more Reviewed-by and Acked-by, > > then pushed this series to > > > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > > kbuild-asinstr > > But not the version of the penultimate patch that Nick ack'd Dropped Nick's Reviewed-by. -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
Hi all, On Thu, Mar 26, 2020 at 6:22 PM Ingo Molnar wrote: > > > * Jason A. Donenfeld wrote: > > > Very little has changed from last time, and this whole series still > > looks good to me. I think I already ack'd most packages, but in case > > it helps: > > > > Reviewed-by: Jason A. Donenfeld > > Acked-by: Ingo Molnar > > > Since this touches a lot of stuff, it might be best to get it in as > > early as possible during the merge window, as I imagine new code being > > added is going to want to be touching those makefiles too. > > I'd argue the opposite: please merge this later in the merge window, to > not disrupt the vast body of other stuff that has already been lined up > and has been tested, and to give time for these new bits to get tested > some more. I agree. > Also, please get it into -next ASAP, today would be ideal for test > coverage ... I collected more Reviewed-by and Acked-by, then pushed this series to git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git kbuild-asinstr It will show up in -next soon. -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your full dmesg output. What version of gcc are you using? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] New: [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 Bug ID: 206987 Summary: [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration Product: Drivers Version: 2.5 Kernel Version: 5.5.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ev...@hotmail.com Regression: No Whole system crashes with this error message : simd exception: [#1] PREEMPT SMP NOPTI Only giving a REISUB treatment works. And cause is amdgpu driver. --- Mar 26 20:47:13 shodan kernel: simd exception: [#1] PREEMPT SMP NOPTI Mar 26 20:47:13 shodan kernel: CPU: 7 PID: 1344 Comm: Xorg Tainted: GW OE 5.5.11-arch1-1 #1 Mar 26 20:47:13 shodan kernel: Hardware name: Micro-Star International Co., Ltd. MS-7B78/X470 GAMING PRO CARBON (MS-7B78), BIOS 2.80 03/06/2019 Mar 26 20:47:13 shodan kernel: RIP: 0010:mode_support_and_system_configuration+0x30a3/0x4d90 [amdgpu] Mar 26 20:47:13 shodan kernel: Code: 00 0f 28 c3 e8 7e c9 ff ff f3 41 0f 11 87 40 19 00 00 e9 12 fd ff ff 41 83 be a8 00 00 00 06 75 93 f3 41 0f 10 86 40 1b 00 00 41 0f 5e 86 f8 17 00 00 e8 4f c9 ff ff 41 8b 87 80 04 00 00 f3 Mar 26 20:47:13 shodan kernel: RSP: 0018:b216c1f3b978 EFLAGS: 00010246 Mar 26 20:47:13 shodan kernel: RAX: 0006 RBX: 9c120bbfadc4 RCX: 0004 Mar 26 20:47:13 shodan kernel: RDX: 0001 RSI: RDI: 9c120bbfb008 Mar 26 20:47:13 shodan kernel: RBP: 9c120bbfadc4 R08: 9c120bbfc164 R09: 0120 Mar 26 20:47:13 shodan kernel: R10: 9c120bbfaee4 R11: 9c120bbf0248 R12: 9c120bbfc63c Mar 26 20:47:13 shodan kernel: R13: R14: 9c120bbfaf5c R15: 9c120bbfadc4 Mar 26 20:47:13 shodan kernel: FS: 7f1c9f336dc0() GS:9c19009c() knlGS: Mar 26 20:47:13 shodan kernel: CS: 0010 DS: ES: CR0: 80050033 Mar 26 20:47:13 shodan kernel: CR2: 1f82bfec7fe0 CR3: 0007cbe4a000 CR4: 003406e0 Mar 26 20:47:13 shodan kernel: Call Trace: Mar 26 20:47:13 shodan kernel: dcn_validate_bandwidth+0xfe5/0x1f20 [amdgpu] Mar 26 20:47:13 shodan kernel: dc_validate_global_state+0x28a/0x310 [amdgpu] Mar 26 20:47:13 shodan kernel: amdgpu_dm_atomic_check+0x5d8/0x870 [amdgpu] Mar 26 20:47:13 shodan kernel: drm_atomic_check_only+0x578/0x800 [drm] Mar 26 20:47:13 shodan kernel: ? dm_crtc_duplicate_state+0x6b/0x1f0 [amdgpu] Mar 26 20:47:13 shodan kernel: drm_atomic_commit+0x13/0x50 [drm] Mar 26 20:47:13 shodan kernel: drm_atomic_helper_legacy_gamma_set+0x123/0x180 [drm_kms_helper] Mar 26 20:47:13 shodan kernel: drm_mode_gamma_set_ioctl+0x171/0x220 [drm] Mar 26 20:47:13 shodan kernel: ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm] Mar 26 20:47:13 shodan kernel: drm_ioctl_kernel+0xb2/0x100 [drm] Mar 26 20:47:13 shodan kernel: drm_ioctl+0x209/0x360 [drm] Mar 26 20:47:13 shodan kernel: ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm] Mar 26 20:47:13 shodan kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Mar 26 20:47:13 shodan kernel: do_vfs_ioctl+0x4b7/0x730 Mar 26 20:47:13 shodan kernel: ksys_ioctl+0x5e/0x90 Mar 26 20:47:13 shodan kernel: __x64_sys_ioctl+0x16/0x20 Mar 26 20:47:13 shodan kernel: do_syscall_64+0x4e/0x150 Mar 26 20:47:13 shodan kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 26 20:47:13 shodan kernel: RIP: 0033:0x7f1ca01892eb Mar 26 20:47:13 shodan kernel: Code: 0f 1e fa 48 8b 05 a5 8b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 75 8b 0c 00 f7 d8 64 89 01 48 Mar 26 20:47:13 shodan kernel: RSP: 002b:7ffc60ff5648 EFLAGS: 0206 ORIG_RAX: 0010 Mar 26 20:47:13 shodan kernel: RAX: ffda RBX: 0001 RCX: 7f1ca01892eb Mar 26 20:47:13 shodan kernel: RDX: 7ffc60ff5700 RSI: c02064a5 RDI: 000a Mar 26 20:47:13 shodan kernel: RBP: 7ffc60ff5680 R08: 562bb635c080 R09: 562bb635c280 Mar 26 20:47:13 shodan kernel: R10: 562bb635be80 R11: 0206 R12: 0100 Mar 26 20:47:13 shodan kernel: R13: 562bb6ab4f70 R14: 562bb635b9c0 R15: 0100 Mar 26 20:47:13 shodan kernel: Modules linked in: snd_seq_dummy snd_seq bluetooth ecdh_generic rfkill ecc veth fuse iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tun ip6table_mangle xt_MASQUERADE iptable_nat nf_nat xt_connmark iptable_mangle xt_helper xt_NFLOG xt_limit xt_conntrack xt_tcpudp nf_conntrack_ftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_irc nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) pktcdvd nfnetlink_log nfnetlink ip6table_filter nct6775 ip6_tables hwmon_vid
Re: [PATCH v8 2/3] dt-bindings: Add binding for IT6505.
On Mon, Mar 23, 2020 at 01:21:53PM +0800, allen wrote:
> Add a DT binding documentation for IT6505.
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Allen Chen
> Signed-off-by: Pi-Hsun Shih
> ---
> cros-ec does not have an associated driver that uses the standard Linux USB-C
> driver class.
> extcon is used to model the Type-C connector.(crbug.com/982932)
That's nice, but doesn't matter for upstream. And sounds like a driver
problem, not a binding issue.
> ---
> .../bindings/display/bridge/ite,it6505.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> new file mode 100644
> index ..13feeef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ite,it6505.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ITE it6505 Device Tree Bindings
> +
> +maintainers:
> + - Allen Chen
> +
> +description: |
> + The IT6505 is a high-performance DisplayPort 1.1a transmitter,
> + fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications.
> + The IT6505 supports color depth of up to 36 bits (12 bits/color)
> + and ensures robust transmission of high-quality uncompressed video
> + content, along with uncompressed and compressed digital audio content.
> +
> + Aside from the various video output formats supported, the IT6505
> + also encodes and transmits up to 8 channels of I2S digital audio,
> + with sampling rate up to 192kHz and sample size up to 24 bits.
> + In addition, an S/PDIF input port takes in compressed audio of up to
> + 192kHz frame rate.
> +
> + Each IT6505 chip comes preprogrammed with an unique HDCP key,
> + in compliance with the HDCP 1.3 standard so as to provide secure
> + transmission of high-definition content. Users of the IT6505 need not
> + purchase any HDCP keys or ROMs.
> +
> +properties:
> + compatible:
> +const: ite,it6505
> +
> + ovdd-supply:
> +maxItems: 1
> +description: I/O voltage
> +
> + pwr18-supply:
> +maxItems: 1
> +description: core voltage
> +
> + interrupts:
> +maxItems: 1
> +description: interrupt specifier of INT pin
> +
> + reset-gpios:
> +maxItems: 1
> +description: gpio specifier of RESET pin
> +
> + extcon:
Think I said this already, but don't use extcon and define an output
port to a DP or USB connector.
> +maxItems: 1
> +description: extcon specifier for the Power Delivery
> +
> + port:
> +type: object
> +description: A port node pointing to DPI host port node
> +
> +required:
> + - compatible
> + - ovdd-supply
> + - pwr18-supply
> + - interrupts
> + - reset-gpios
> + - extcon
> +
> +examples:
> + - |
> +#include
> +
> +i2c3 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +dp-bridge@5c {
> +compatible = "ite,it6505";
> +interrupts = <152 IRQ_TYPE_EDGE_FALLING 152 0>;
> +reg = <0x5c>;
> +pinctrl-names = "default";
> +pinctrl-0 = <_pins>;
> +ovdd-supply = <_vsim1_reg>;
> +pwr18-supply = <_pp18_reg>;
> +reset-gpios = < 179 1>;
> +extcon = <_extcon>;
> +
> +port {
> +it6505_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/2] dt-bindings: display: add visionox rm69299 panel variant
On Mon, Mar 23, 2020 at 10:33:15AM +0530, Harigovindan P wrote:
> Add bindings for visionox rm69299 panel.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v2:
> - Removed unwanted properties from description.
> - Creating source files without execute permissions(Rob Herring).
> Changes in v3:
> - Changing txt file into yaml
> Changes in v4:
> - Updating license identifier.
> - Moving yaml file inside panel directory.
> - Removing pinctrl entries.
> - Adding documentation for reset-gpios.
> Changes in v5:
> - No changes. Updated 2/2 Patch.
> Changes in v6:
> - Removing patternProperties.
> - Added " |" after description.
> - Setting port and reset-gpios to true.
> - Removing @ae94000 for dsi node.
> Changes in v7:
> - Added reg property.
> Changes in v8:
> - Rearranged additionalProperties.
> - Dropping improper reg property.
> Changes in v9:
> - Adding additionalProperties at the same level as
> 'properties'
> - Adding properties for "ports" which includes:
> -> #address-cells
> -> #size-cells
> -> port@0
>
> .../display/panel/visionox,rm69299.yaml | 82 +++
> 1 file changed, 82 insertions(+)
> create mode 100755
> Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
Wrong file mode.
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> new file mode 100755
> index ..2dd4d9471fa8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Visionox model RM69299 Panels Device Tree Bindings.
> +
> +maintainers:
> + - Harigovindan P
> +
> +description: |
> + This binding is for display panels using a Visionox RM692999 panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: visionox,rm69299-1080p-display
> +
> + reg:
> +maxItems: 1
> +
> + vdda-supply:
> +description: |
> + Phandle of the regulator that provides the vdda supply voltage.
> +
> + vdd3p3-supply:
> +description: |
> + Phandle of the regulator that provides the vdd3p3 supply voltage.
> +
> + ports:
> +type: object
> +description: |
> + A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
As I said before, fix the example. You don't need 'ports' nor a unit
address as there is only 1 port.
All you need instead of 'ports' is 'port: true' because
panel-common.yaml defines it.
And 'port' should be required.
> +type: object
> +description: |
> + Input endpoints of the controller.
> +
> + reset-gpios: true
> +
> + additionalProperties: false
You are defining a property called 'additionalProperties'. Remove the
indentation.
> +
> +required:
> + - compatible
> + - vdda-supply
> + - vdd3p3-supply
> + - reset-gpios
> +
> +examples:
> + - |
> +panel {
> +compatible = "visionox,rm69299-1080p-display";
> +
> +vdda-supply = <_pp1800_l8c>;
> +vdd3p3-supply = <_pp2800_l18a>;
> +
> +reset-gpios = <_gpio 3 0>;
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +panel0_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +...
> +
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: Add TODO for making drm_fb_helper_alloc_fbi fill apertures
On Thu, Mar 26, 2020 at 4:10 PM Hans de Goede wrote:
>
> Currently drivers using drm_fbdev_generic_setup() end up with a single
> empty aperture in their fb_info struct.
>
> Not having the proper info in the apertures list causes
> register_framebuffer to not remove conflicting framebuffers,
> which some drivers currently workaround by manually calling
> drm_fb_helper_remove_conflicting_pci_framebuffers().
>
> Add a TODO as a reminder that we need to fix this.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/drm_fb_helper.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4c7cbce7bae7..16b8dc38d022 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -526,6 +526,14 @@ struct fb_info *drm_fb_helper_alloc_fbi(struct
> drm_fb_helper *fb_helper)
> if (ret)
> goto err_release;
>
> + /*
> +* TODO: We really should be smarter here and alloc an apperture
> +* for each IORESOURCE_MEM resource helper->dev->dev has and also
> +* init the ranges of the appertures based on the resources.
> +* Note some drivers currently count on there being only 1 empty
> +* aperture and fill this themselves, these will need to be dealt
> +* with somehow when fixing this.
> +*/
Ah yes this is a bit more involved than first apperances suggest - we
might want to have a dedicated solution for the generic_setup helper
only, so we don't break all the other drivers using this function
directly.
Reviewed-by: Daniel Vetter
> info->apertures = alloc_apertures(1);
> if (!info->apertures) {
> ret = -ENOMEM;
> --
> 2.26.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix HDMI mode validation
Am 26.03.20 um 18:36 schrieb Nicolas Saenz Julienne:
> On Thu, 2020-03-26 at 18:19 +0100, Stefan Wahren wrote:
>> Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
>>> Current mode validation impedes setting up some video modes which should
>>> be supported otherwise. Namely 1920x1200@60Hz.
>>>
>>> Fix this by lowering the minimum HDMI state machine clock to pixel clock
>>> ratio allowed.
>>>
>>> Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
>>> Reported-by: Stefan Wahren
>>> Suggested-by: Dave Stevenson
>>> Signed-off-by: Nicolas Saenz Julienne
>>> ---
>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 20
>>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> index cea18dc15f77..340719238753 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> @@ -681,11 +681,23 @@ static enum drm_mode_status
>>> vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
>>> const struct drm_display_mode *mode)
>>> {
>>> - /* HSM clock must be 108% of the pixel clock. Additionally,
>>> -* the AXI clock needs to be at least 25% of pixel clock, but
>>> -* HSM ends up being the limiting factor.
>>> + /*
>>> +* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
>>> +* be faster than pixel clock, infinitesimally faster, tested in
>>> +* simulation. Otherwise, exact value is unimportant for HDMI
>>> +* operation." This conflicts with bcm2835's vc4 documentation, which
>>> +* states HSM's clock has to be at least 108% of the pixel clock.
>>> +*
>>> +* Real life tests reveal that vc4's firmware statement holds up, and
>>> +* users are able to use pixel clocks closer to HSM's, namely for
>>> +* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
>>> +* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
>> s/RPi0-3/bcm2835/ ?
> Well as Dave Stevenson stated on the previous thread[1], it's the firmware
> that
> sets up the HSM limitation. IIUC technically both HSM and pixel clocks could
> be
> increased. Hence this being more of a RPi limitation than the chip itself.
>
> "Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I
> don't anticipate there being any issue with varying it. It looks like
> there was the expectation of it being variable in the past, but
> someone has refactored it and either accidentally or deliberately
> given up on the idea."
Okay thanks for the explanation again
So i'm fine this patch
>
> Regards,
> Nicolas
>
> [1] https://www.spinics.net/lists/arm-kernel/msg794591.html
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix HDMI mode validation
Am 26.03.20 um 18:19 schrieb Stefan Wahren:
> Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
>> Current mode validation impedes setting up some video modes which should
>> be supported otherwise. Namely 1920x1200@60Hz.
>>
>> Fix this by lowering the minimum HDMI state machine clock to pixel clock
>> ratio allowed.
>>
>> Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
>> Reported-by: Stefan Wahren
>> Suggested-by: Dave Stevenson
>> Signed-off-by: Nicolas Saenz Julienne
>> ---
>> drivers/gpu/drm/vc4/vc4_hdmi.c | 20
>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index cea18dc15f77..340719238753 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -681,11 +681,23 @@ static enum drm_mode_status
>> vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
>> const struct drm_display_mode *mode)
>> {
>> -/* HSM clock must be 108% of the pixel clock. Additionally,
>> - * the AXI clock needs to be at least 25% of pixel clock, but
>> - * HSM ends up being the limiting factor.
>> +/*
>> + * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
>> + * be faster than pixel clock, infinitesimally faster, tested in
>> + * simulation. Otherwise, exact value is unimportant for HDMI
>> + * operation." This conflicts with bcm2835's vc4 documentation, which
>> + * states HSM's clock has to be at least 108% of the pixel clock.
>> + *
>> + * Real life tests reveal that vc4's firmware statement holds up, and
>> + * users are able to use pixel clocks closer to HSM's, namely for
>> + * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
>> + * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> s/RPi0-3/bcm2835/ ?
>
> Beside this nit:
>
> Tested-by: Stefan Wahren
>
> Thanks
Sorry typo in the mail address:
stefan.wah...@i2se.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix HDMI mode validation
Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
> Current mode validation impedes setting up some video modes which should
> be supported otherwise. Namely 1920x1200@60Hz.
>
> Fix this by lowering the minimum HDMI state machine clock to pixel clock
> ratio allowed.
>
> Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> Reported-by: Stefan Wahren
> Suggested-by: Dave Stevenson
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index cea18dc15f77..340719238753 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -681,11 +681,23 @@ static enum drm_mode_status
> vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
> const struct drm_display_mode *mode)
> {
> - /* HSM clock must be 108% of the pixel clock. Additionally,
> - * the AXI clock needs to be at least 25% of pixel clock, but
> - * HSM ends up being the limiting factor.
> + /*
> + * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> + * be faster than pixel clock, infinitesimally faster, tested in
> + * simulation. Otherwise, exact value is unimportant for HDMI
> + * operation." This conflicts with bcm2835's vc4 documentation, which
> + * states HSM's clock has to be at least 108% of the pixel clock.
> + *
> + * Real life tests reveal that vc4's firmware statement holds up, and
> + * users are able to use pixel clocks closer to HSM's, namely for
> + * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> + * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
s/RPi0-3/bcm2835/ ?
Beside this nit:
Tested-by: Stefan Wahren
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 14/16] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
On Thu, 2020-03-05 at 15:12 -0500, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Signed-off-by: Sean Paul
>
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> #v4
>
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 117 ++
> include/drm/drm_dp_helper.h | 3 +
> include/drm/drm_dp_mst_helper.h | 44 ++
> 3 files changed, 164 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 6c62ad8f44142..5bba5aac86f31 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -418,6 +419,22 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> memcpy([idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
> idx += req->u.i2c_write.num_bytes;
> break;
> + case DP_QUERY_STREAM_ENC_STATUS: {
> + const struct drm_dp_query_stream_enc_status *msg;
> +
> + msg = >u.enc_status;
> + buf[idx] = msg->stream_id;
> + idx++;
> + memcpy([idx], msg->client_id, sizeof(msg->client_id));
> + idx += sizeof(msg->client_id);
> + buf[idx] = 0;
> + buf[idx] |= msg->stream_event & GENMASK(1, 0);
> + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> + buf[idx] |= (msg->stream_behavior & GENMASK(1, 0)) << 3;
> + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> + idx++;
> + }
> + break;
> }
> raw->cur_len = idx;
> }
> @@ -930,6 +947,34 @@ static bool
> drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
> return true;
> }
>
> +static bool
> +drm_dp_sideband_parse_query_stream_enc_status(
> + struct drm_dp_sideband_msg_rx *raw,
> + struct drm_dp_sideband_msg_reply_body *repmsg)
> +{
> + struct drm_dp_query_stream_enc_status_ack_reply *reply;
> +
> + reply = >u.enc_status;
> +
> + reply->stream_id = raw->msg[3];
> +
> + reply->reply_signed = raw->msg[2] & BIT(0);
> +
> + reply->hdcp_1x_device_present = raw->msg[2] & BIT(3);
> + reply->hdcp_2x_device_present = raw->msg[2] & BIT(4);
> +
> + reply->query_capable_device_present = raw->msg[2] & BIT(5);
> + reply->legacy_device_present = raw->msg[2] & BIT(6);
> + reply->unauthorizable_device_present = raw->msg[2] & BIT(7);
> +
> + reply->auth_completed = !!(raw->msg[1] & BIT(3));
> + reply->encryption_enabled = !!(raw->msg[1] & BIT(4));
> + reply->repeater_present = !!(raw->msg[1] & BIT(5));
> + reply->state = (raw->msg[1] & GENMASK(7, 6)) >> 6;
> +
> + return true;
> +}
I don't mind terribly either way, but since you're already using the
BIT/GENMASK() macros have you considered GET_BITFIELD()?
> +
> static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_reply_body
> *msg)
> {
> @@ -964,6 +1009,8 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
> return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
> case DP_CLEAR_PAYLOAD_ID_TABLE:
> return true; /* since there's nothing to parse */
> + case DP_QUERY_STREAM_ENC_STATUS:
> + return drm_dp_sideband_parse_query_stream_enc_status(raw,
> msg);
> default:
> DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> @@ -1115,6 +1162,25 @@ static void build_power_updown_phy(struct
> drm_dp_sideband_msg_tx *msg,
> msg->path_msg = true;
> }
>
> +static int
> +build_query_stream_enc_status(struct drm_dp_sideband_msg_tx *msg, u8
> stream_id,
> + u8 *q_id)
> +{
> + struct drm_dp_sideband_msg_req_body req;
> +
> + req.req_type = DP_QUERY_STREAM_ENC_STATUS;
> + req.u.enc_status.stream_id = stream_id;
> + memcpy(req.u.enc_status.client_id, q_id,
> +sizeof(req.u.enc_status.client_id));
> + req.u.enc_status.stream_event = 0;
> + req.u.enc_status.valid_stream_event = false;
> + req.u.enc_status.stream_behavior = 0;
> + req.u.enc_status.valid_stream_behavior = false;
> +
> + drm_dp_encode_sideband_req(, msg);
> + return 0;
> +}
> +
> static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr
> *mgr,
> struct drm_dp_vcpi *vcpi)
> {
> @@ -3151,6 +3217,57 @@ int drm_dp_send_power_updown_phy(struct
> drm_dp_mst_topology_mgr *mgr,
> }
>
Re: [PATCH][next] drm/vmwgfx: fix spelling mistake "Cound" -> "Could"
Am 26.03.20 um 11:19 schrieb Colin King:
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_ERROR error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 367d5b87ee6a..2e61a4ecd8ef 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3037,7 +3037,7 @@ static int vmw_cmd_dx_bind_streamoutput(struct
> vmw_private *dev_priv,
> res = vmw_dx_streamoutput_lookup(vmw_context_res_man(ctx_node->ctx),
>cmd->body.soid);
> if (IS_ERR(res)) {
> - DRM_ERROR("Cound not find streamoutput to bind.\n");
> + DRM_ERROR("Could not find streamoutput to bind.\n");
> return PTR_ERR(res);
> }
>
>
Reviewed-by: Roland Scheidegger
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, radeon, scheduler drm-next-5.7
Hi Dave, Daniel, Fixes for 5.7. The following changes since commit cb7adfd6ad12a11902ebe374bec7fd4efa2cec1c: Merge tag 'mediatek-drm-next-5.7' of https://github.com/ckhu-mediatek/linux.git-tags into drm-next (2020-03-20 13:08:38 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.7-2020-03-26 for you to fetch changes up to e862b08b4650be6d5196c191baceff3c43dfddef: drm/amdgpu: don't try to reserve training bo for sriov (v2) (2020-03-25 17:04:35 -0400) amd-drm-next-5.7-2020-03-26: amdgpu: - Remove a dpm quirk that is not necessary - Fix handling of AC/DC mode in newer SMU firmwares on navi - SR-IOV fixes - RAS fixes scheduler: - Fix a race condition radeon: - Remove a dpm quirk that is not necessary Alex Deucher (6): drm/amdgpu/smu11: add a helper to set the power source drm/amdgpu/swSMU: use the smu11 power source helper for navi1x drm/amdgpu/swSMU: set AC/DC mode based on the current system state (v2) drm/amdgpu/swSMU: handle DC controlled by GPIO for navi1x drm/amdgpu/swSMU: handle manual AC/DC notifications drm/amdgpu/smu11: add support for SMU AC/DC interrupts Dennis Li (1): drm/amdgpu: fix the coverage issue to clear ArcVPGRs Evan Quan (2): drm/amd/swSMU: add callback to set AC/DC power source (v2) drm/amdgpu/swSMU: correct the bootup power source for Navi1X (v2) John Clements (1): drm/amdgpu: protect RAS sysfs during GPU reset Mario Kleiner (1): drm/amd/display: Fix pageflip event race condition for DCN. Monk Liu (1): drm/amdgpu: don't try to reserve training bo for sriov (v2) Yassine Oudjana (1): drm/[radeon|amdgpu]: Remove HAINAN board from max_sclk override check Yintian Tao (1): drm/scheduler: fix rare NULL ptr race Zhigang Luo (1): Revert "drm/amdgpu: add CAP fw loading" shaoyunl (1): drm/amdgpu/sriov : Don't resume RLCG for SRIOV guest drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 12 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 3 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 -- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 5 +++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 1 - drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 24 -- drivers/gpu/drm/amd/amdgpu/si_dpm.c | 1 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +-- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 38 +++ drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h| 3 ++ drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 3 ++ drivers/gpu/drm/amd/powerplay/navi10_ppt.c| 8 - drivers/gpu/drm/amd/powerplay/smu_internal.h | 3 ++ drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 31 ++ drivers/gpu/drm/radeon/si_dpm.c | 1 - drivers/gpu/drm/scheduler/sched_main.c| 2 ++ 21 files changed, 138 insertions(+), 49 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
On Thu, Mar 26, 2020 at 08:45:59PM +0530, Bharadiya,Pankaj wrote:
> On Tue, Mar 24, 2020 at 06:46:10PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj
> > wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
> > > > Sent: 23 March 2020 20:18
> > > > To: Laxminarayan Bharadiya, Pankaj
> > > >
> > > > Cc: Lattannavar, Sameer ;
> > > > jani.nik...@linux.intel.com; dan...@ffwll.ch;
> > > > intel-...@lists.freedesktop.org;
> > > > dri-devel@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> > > > ; Vivi, Rodrigo
> > > > ;
> > > > David Airlie ; Chris Wilson
> > > > ;
> > > > Maarten Lankhorst ; Souza, Jose
> > > > ; Deak, Imre ; Shankar, Uma
> > > >
> > > > Subject: Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane
> > > > and CRTC
> > > >
> > > > On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> > > > > GEN >= 10 hardware supports the programmable scaler filter.
> > > > >
> > > > > Attach scaling filter property for CRTC and plane for GEN >= 10
> > > > > hardwares and program scaler filter based on the selected filter type.
> > > > >
> > > > > changes since v1:
> > > > > * None
> > > > > Changes since RFC:
> > > > > * Enable properties for GEN >= 10 platforms (Ville)
> > > > > * Do not round off the crtc co-ordinate (Danial Stone, Ville)
> > > > > * Add new functions to handle scaling filter setup (Ville)
> > > > > * Remove coefficient set 0 hardcoding.
> > > > >
> > > > > Signed-off-by: Shashank Sharma
> > > > > Signed-off-by: Ankit Nautiyal
> > > > > Signed-off-by: Pankaj Bharadiya
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 32
> > > > > ++-- drivers/gpu/drm/i915/display/intel_sprite.c |
> > > > > 31 ++-
> > > > > 2 files changed, 60 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index 791dd908aa89..4b3387ee332e 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -6309,6 +6309,25 @@ void
> > > > skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private
> > > > *dev_priv,
> > > > > }
> > > > > }
> > > > >
> > > > > +static u32
> > > > > +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum
> > > > > pipe
> > > > pipe,
> > > > > + int id, int set, enum drm_crtc_scaling_filter
> > > > > filter) {
> > > > > + u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
> > > > > +
> > > > > + if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > > > > + skl_scaler_setup_nearest_neighbor_filter(dev_priv,
> > > > > pipe, id,
> > > > > + set);
> > > > > + scaler_filter_ctl = PS_FILTER_PROGRAMMED |
> > > > > + PS_UV_VERT_FILTER_SELECT(set) |
> > > > > + PS_UV_HORZ_FILTER_SELECT(set) |
> > > > > + PS_Y_VERT_FILTER_SELECT(set) |
> > > > > + PS_Y_HORZ_FILTER_SELECT(set);
> > > > > +
> > > > > + }
> > > > > + return scaler_filter_ctl;
> > > >
> > > > This function does too many things.
> > >
> > > I was thinking to have a common function which configures the filter and
> > > also
> > > provides the register bits (ps_ctrl) to select a desired filter so that
> > > we need
> > > not have extra condition to figure out filter select register bits where
> > > this
> > > function is being called.
> > > How about renaming this function to some better name like
> > > skl_scaler_set_and_get_filter_select() or something else?
> > > Or shall I breakdown this function into multiple functions?
> >
> > I'd just inline the PS_CTRL stuff into the current function.
>
> I am yet to verify this, but would like to get your early comments.
> How about something like this? -
>
> +inline u32 skl_scaler_get_filter_select(enum drm_scaling_filter filter, int
> set)
> +{
> + u32 filter_select = PS_FILTER_MEDIUM;
Pointless variable.
if (whatever)
return A;
else
return B;
> +
> + if (filter == DRM_SCALING_FILTER_NEAREST_NEIGHBOR) {
> + filter_select = PS_FILTER_PROGRAMMED |
> + PS_UV_VERT_FILTER_SELECT(set) |
> + PS_UV_HORZ_FILTER_SELECT(set) |
> + PS_Y_VERT_FILTER_SELECT(set) |
> + PS_Y_HORZ_FILTER_SELECT(set);
> + }
> +
> + return filter_select;
> +}
> +
> +void skl_scaler_setup_filter(struct drm_i915_private *dev_priv, enum pipe
> pipe,
> +int id, int set, enum drm_scaling_filter filter)
> +{
> + switch(filter) {
> + case DRM_SCALING_FILTER_DEFAULT:
> + break;
> +
Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
On Tue, Mar 24, 2020 at 06:46:10PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj
> wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: 23 March 2020 20:18
> > > To: Laxminarayan Bharadiya, Pankaj
> > >
> > > Cc: Lattannavar, Sameer ;
> > > jani.nik...@linux.intel.com; dan...@ffwll.ch;
> > > intel-...@lists.freedesktop.org;
> > > dri-devel@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> > > ; Vivi, Rodrigo ;
> > > David Airlie ; Chris Wilson ;
> > > Maarten Lankhorst ; Souza, Jose
> > > ; Deak, Imre ; Shankar, Uma
> > >
> > > Subject: Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and
> > > CRTC
> > >
> > > On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> > > > GEN >= 10 hardware supports the programmable scaler filter.
> > > >
> > > > Attach scaling filter property for CRTC and plane for GEN >= 10
> > > > hardwares and program scaler filter based on the selected filter type.
> > > >
> > > > changes since v1:
> > > > * None
> > > > Changes since RFC:
> > > > * Enable properties for GEN >= 10 platforms (Ville)
> > > > * Do not round off the crtc co-ordinate (Danial Stone, Ville)
> > > > * Add new functions to handle scaling filter setup (Ville)
> > > > * Remove coefficient set 0 hardcoding.
> > > >
> > > > Signed-off-by: Shashank Sharma
> > > > Signed-off-by: Ankit Nautiyal
> > > > Signed-off-by: Pankaj Bharadiya
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 32
> > > > ++-- drivers/gpu/drm/i915/display/intel_sprite.c |
> > > > 31 ++-
> > > > 2 files changed, 60 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 791dd908aa89..4b3387ee332e 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -6309,6 +6309,25 @@ void
> > > skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private
> > > *dev_priv,
> > > > }
> > > > }
> > > >
> > > > +static u32
> > > > +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum
> > > > pipe
> > > pipe,
> > > > + int id, int set, enum drm_crtc_scaling_filter
> > > > filter) {
> > > > + u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
> > > > +
> > > > + if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > > > + skl_scaler_setup_nearest_neighbor_filter(dev_priv,
> > > > pipe, id,
> > > > +set);
> > > > + scaler_filter_ctl = PS_FILTER_PROGRAMMED |
> > > > + PS_UV_VERT_FILTER_SELECT(set) |
> > > > + PS_UV_HORZ_FILTER_SELECT(set) |
> > > > + PS_Y_VERT_FILTER_SELECT(set) |
> > > > + PS_Y_HORZ_FILTER_SELECT(set);
> > > > +
> > > > + }
> > > > + return scaler_filter_ctl;
> > >
> > > This function does too many things.
> >
> > I was thinking to have a common function which configures the filter and
> > also
> > provides the register bits (ps_ctrl) to select a desired filter so that we
> > need
> > not have extra condition to figure out filter select register bits where
> > this
> > function is being called.
> > How about renaming this function to some better name like
> > skl_scaler_set_and_get_filter_select() or something else?
> > Or shall I breakdown this function into multiple functions?
>
> I'd just inline the PS_CTRL stuff into the current function.
I am yet to verify this, but would like to get your early comments.
How about something like this? -
+inline u32 skl_scaler_get_filter_select(enum drm_scaling_filter filter, int
set)
+{
+ u32 filter_select = PS_FILTER_MEDIUM;
+
+ if (filter == DRM_SCALING_FILTER_NEAREST_NEIGHBOR) {
+ filter_select = PS_FILTER_PROGRAMMED |
+ PS_UV_VERT_FILTER_SELECT(set) |
+ PS_UV_HORZ_FILTER_SELECT(set) |
+ PS_Y_VERT_FILTER_SELECT(set) |
+ PS_Y_HORZ_FILTER_SELECT(set);
+ }
+
+ return filter_select;
+}
+
+void skl_scaler_setup_filter(struct drm_i915_private *dev_priv, enum pipe pipe,
+int id, int set, enum drm_scaling_filter filter)
+{
+ switch(filter) {
+ case DRM_SCALING_FILTER_DEFAULT:
+ break;
+ case DRM_SCALING_FILTER_NEAREST_NEIGHBOR:
+ cnl_program_nearest_filter_coefs(dev_priv, pipe, id, set);
+ break;
+ default:
+ default:
+ MISSING_CASE(filter);
+ }
+}
+
static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
Re: [PATCH 00/51] drm_device managed resources, v5
On Mon, Mar 23, 2020 at 03:48:59PM +0100, Daniel Vetter wrote: > Hi all, > > Another round, another set of polish all over. intel-gfx-ci was happy last > time around (after I fixed a fumble), so really just review and comments > needed now. There's still a few patches at the beginning holding the > entire thing up and preventing merging of the driver patches which have > acks/r-b already. > > Thanks, Daniel Ok got them all, applied them all. Thanks a lot to everyone for providing review, feedback and testing on these. Thanks, Daniel > > Daniel Vetter (51): > mm/sl[uo]b: export __kmalloc_track(_node)_caller > drm/i915: Don't clear drvdata in ->release > drm: add managed resources tied to drm_device > drm: Set final_kfree in drm_dev_alloc > drm/mipi_dbi: Use drmm_add_final_kfree in all drivers > drm/udl: Use drmm_add_final_kfree > drm/qxl: Use drmm_add_final_kfree > drm/i915: Use drmm_add_final_kfree > drm/cirrus: Use drmm_add_final_kfree > drm/v3d: Use drmm_add_final_kfree > drm/tidss: Use drmm_add_final_kfree > drm/mcde: Use drmm_add_final_kfree > drm/vgem: Use drmm_add_final_kfree > drm/vkms: Use drmm_add_final_kfree > drm/repaper: Use drmm_add_final_kfree > drm/ingenic: Use drmm_add_final_kfree > drm/gm12u320: Use drmm_add_final_kfree > drm/: Use drmm_add_final_kfree > drm: Cleanups after drmm_add_final_kfree rollout > drm: Handle dev->unique with drmm_ > drm: Use drmm_ for drm_dev_init cleanup > drm: manage drm_minor cleanup with drmm_ > drm: Manage drm_gem_init with drmm_ > drm: Manage drm_vblank_cleanup with drmm_ > drm: Garbage collect drm_dev_fini > drm: Manage drm_mode_config_init with drmm_ > drm/bochs: Remove leftover drm_atomic_helper_shutdown > drm/bochs: Drop explicit drm_mode_config_cleanup > drm/cirrus: Drop explicit drm_mode_config_cleanup call > drm/cirrus: Fully embrace devm_ > drm/ingenic: Drop explicit drm_mode_config_cleanup call > drm/mcde: Drop explicit drm_mode_config_cleanup call > drm/mcde: More devm_drm_dev_init > drm/meson: Drop explicit drm_mode_config_cleanup call > drm/pl111: Drop explicit drm_mode_config_cleanup call > drm/rcar-du: Drop explicit drm_mode_config_cleanup call > drm/rockchip: Drop explicit drm_mode_config_cleanup call > drm/stm: Drop explicit drm_mode_config_cleanup call > drm/shmob: Drop explicit drm_mode_config_cleanup call > drm/mtk: Drop explicit drm_mode_config_cleanup call > drm/tidss: Drop explicit drm_mode_config_cleanup call > drm/gm12u320: More drmm_ > drm/gm12u320: Use devm_drm_dev_init > drm/gm12u320: Use helpers for shutdown/suspend/resume > drm/gm12u320: Simplify upload work > drm/repaper: Drop explicit drm_mode_config_cleanup call > drm/mipi-dbi: Move drm_mode_config_init into mipi library > drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call > drm/udl: Drop explicit drm_mode_config_cleanup call > drm/udl: drop drm_driver.release hook > drm: Add docs for managed resources > > Documentation/gpu/drm-internals.rst | 12 + > Documentation/gpu/drm-kms.rst | 2 +- > drivers/gpu/drm/Makefile | 3 +- > .../gpu/drm/arm/display/komeda/komeda_kms.c | 2 + > drivers/gpu/drm/armada/armada_drv.c | 2 + > drivers/gpu/drm/bochs/bochs.h | 1 - > drivers/gpu/drm/bochs/bochs_drv.c | 6 +- > drivers/gpu/drm/bochs/bochs_kms.c | 15 +- > drivers/gpu/drm/cirrus/cirrus.c | 74 ++--- > drivers/gpu/drm/drm_drv.c | 215 ++ > drivers/gpu/drm/drm_gem.c | 21 +- > drivers/gpu/drm/drm_internal.h| 5 +- > drivers/gpu/drm/drm_managed.c | 276 ++ > drivers/gpu/drm/drm_mipi_dbi.c| 24 +- > drivers/gpu/drm/drm_mode_config.c | 23 +- > drivers/gpu/drm/drm_vblank.c | 31 +- > drivers/gpu/drm/i915/i915_drv.c | 22 +- > drivers/gpu/drm/i915/i915_drv.h | 3 + > .../gpu/drm/i915/selftests/mock_gem_device.c | 32 +- > drivers/gpu/drm/ingenic/ingenic-drm.c | 17 +- > drivers/gpu/drm/mcde/mcde_drv.c | 35 +-- > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 9 +- > drivers/gpu/drm/meson/meson_drv.c | 5 +- > drivers/gpu/drm/pl111/pl111_drv.c | 12 +- > drivers/gpu/drm/qxl/qxl_drv.c | 2 - > drivers/gpu/drm/qxl/qxl_kms.c | 2 + > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 14 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 - > drivers/gpu/drm/shmobile/shmob_drm_kms.c | 6 +- > drivers/gpu/drm/stm/drv.c | 10 +- > drivers/gpu/drm/tidss/tidss_drv.c | 10 +- > drivers/gpu/drm/tidss/tidss_kms.c | 19 +- >
[PATCH] drm/fb-helper: Add TODO for making drm_fb_helper_alloc_fbi fill apertures
Currently drivers using drm_fbdev_generic_setup() end up with a single
empty aperture in their fb_info struct.
Not having the proper info in the apertures list causes
register_framebuffer to not remove conflicting framebuffers,
which some drivers currently workaround by manually calling
drm_fb_helper_remove_conflicting_pci_framebuffers().
Add a TODO as a reminder that we need to fix this.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_fb_helper.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4c7cbce7bae7..16b8dc38d022 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -526,6 +526,14 @@ struct fb_info *drm_fb_helper_alloc_fbi(struct
drm_fb_helper *fb_helper)
if (ret)
goto err_release;
+ /*
+* TODO: We really should be smarter here and alloc an apperture
+* for each IORESOURCE_MEM resource helper->dev->dev has and also
+* init the ranges of the appertures based on the resources.
+* Note some drivers currently count on there being only 1 empty
+* aperture and fill this themselves, these will need to be dealt
+* with somehow when fixing this.
+*/
info->apertures = alloc_apertures(1);
if (!info->apertures) {
ret = -ENOMEM;
--
2.26.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
Hi,
On 3/26/20 3:47 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 3:40 PM Hans de Goede wrote:
Hi,
On 3/26/20 2:39 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 2:18 PM Hans de Goede wrote:
Hi,
On 3/26/20 12:29 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
The vboxvideo driver is missing a call to remove conflicting framebuffers.
Surprisingly, when using legacy BIOS booting this does not really cause
any issues. But when using UEFI to boot the VM then plymouth will draw
on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
/dev/fb1 as fbdev emulation).
VirtualBox will actual display the output of both devices (I guess it is
showing whatever was drawn last), this causes weird artifacts because of
pitch issues in the efifb when the VM window is not sized at 1024x768
(the window will resize to its last size once the vboxvideo driver loads,
changing the pitch).
Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
call fixes this.
Cc: sta...@vger.kernel.org
Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 8512d970a09f..261255085918 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret)
goto err_mode_fini;
+ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
"vboxvideodrmfb");
+if (ret)
+goto err_irq_fini;
To avoid transient issues this should be done as early as possible,
definitely before the drm driver starts to touch the "hw".>
Ok will fix and then push this to drm-misc-next-fixes, thank you.
With that
Reviewed-by: Daniel Vetter
I do wonder though why the automatic removal of conflicting framebuffers
doesn't work, fbdev should already do that from register_framebuffer(),
which is called somewhere in drm_fbdev_generic_setup (after a few layers).
Did you check why the two framebuffers don't conflict, and why the uefi
one doesn't get thrown out?
I did not check, I was not aware that this check was already happening
in register_framebuffer(). So I just checked and the reason why this
is not working is because the fbdev emulation done by drm_fbdev_generic_setup
does not fill in fb_info.apertures->ranges[0] .
So fb_info.apertures->ranges[0].base is left as 0 which does not match
with the registered efifb's aperture.
We could try to fix this, but that is not entirely trivial, we would
need to pass the pci_dev pointer down into drm_fb_helper_alloc_fbi()
then and then like remove_conflicting_pci_framebuffers() does add
apertures for all IORESOURCE_MEM PCI bars, but that would conflict
with drivers which do rely on drm_fb_helper_alloc_fbi() currently
allocating one empty aperture and then actually fill that itself...
You don't need the pci device, because resources are attached to the
struct device directly. So you could just go through all
IORESOURCE_MEM ranges, and add them. And the struct device we always
have through drm_device->dev. This idea just crossed my mind since you
brought up IORESOURCE_MEM, might be good to try that out instead of
having to litter all drivers with explicit removal calls. The explicit
removal is really only for races (vga hw tends to blow up if 2 drivers
touch it, stuff like that), or when there's resources conflicts. Can
you try to look into that?
Interesting idea, but I'm afraid that my plate is quite full with a lot of
more urgent things atm, so I really do not have time for this, sorry.
Hm can you capture this idea in a todo then instead? I don't really
like the idea of everyone having to add bogus
remove_conflicting_framebuffer calls just because the generic fbdev
helper falls short of expectations. Kinda not happy to land the
vboxvideo patch since it's just a hack to work around a helper bug.
Sure I can add a TODO for this. Note part of the problem is that some
drivers already manually set up the single aperture currently allocated
by drm_fb_helper_alloc_fbi() and the question is if we can just drop
that code when we switch to automatically adding apertures without
this having bad side effects.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v6 00/17] add drm support for MT8183
Hi, Yongqiang: In [1], Matthias has applied below series to fix mmsys driver probe problem. Please base on that series to resend your patches. soc / drm: mediatek: Fix mediatek-drm device probingsoc / drm: mediatek: Move routing control to mmsys device clk / soc: mediatek: Move mt8173 MMSYS to platform driver dt-bindings: mediatek: Update mmsys binding to reflect it is a system controllerdrm/mediatek: Omit warning on probe defers [1] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next Regards, CK On Fri, 2020-01-03 at 11:12 +0800, Yongqiang Niu wrote: > This series are based on 5.5-rc1 and provid 17 patch > to support mediatek SOC MT8183 > > Change since v5 > - fix reviewed issue in v5 > base https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 > > Change since v4 > - fix reviewed issue in v4 > > Change since v3 > - fix reviewed issue in v3 > - fix type error in v3 > - fix conflict with iommu patch > > Change since v2 > - fix reviewed issue in v2 > - add mutex node into dts file > > Changes since v1: > - fix reviewed issue in v1 > - add dts for mt8183 display nodes > - adjust display clock control flow in patch 22 > - add vmap support for mediatek drm in patch 23 > - fix page offset issue for mmap function in patch 24 > - enable allow_fb_modifiers for mediatek drm in patch 25 > > Yongqiang Niu (17): > dt-bindings: mediatek: add rdma_fifo_size description for mt8183 > display > arm64: dts: add display nodes for mt8183 > drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in > drm/mediatek: make sout select function format same with select input > drm/mediatek: add mmsys private data for ddp path config > drm/mediatek: add private data for rdma1 to dpi0 connection > drm/mediatek: add private data for rdma1 to dsi0 connection > drm/mediatek: move rdma sout from mtk_ddp_mout_en into > mtk_ddp_sout_sel > drm/mediatek: add connection from OVL0 to OVL_2L0 > drm/mediatek: add connection from RDMA0 to COLOR0 > drm/mediatek: add connection from RDMA1 to DSI0 > drm/mediatek: add connection from OVL_2L0 to RDMA0 > drm/mediatek: add connection from OVL_2L1 to RDMA1 > drm/mediatek: add connection from DITHER0 to DSI0 > drm/mediatek: add connection from RDMA0 to DSI0 > drm/mediatek: add fifo_size into rdma private data > drm/mediatek: add support for mediatek SOC MT8183 > > .../bindings/display/mediatek/mediatek,disp.txt| 13 + > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 98 +++ > drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 18 ++ > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 25 +- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 4 + > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 288 > - > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 + > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 49 > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 + > 9 files changed, 435 insertions(+), 70 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Hi, Matthias:
On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote:
> Hi CK,
>
> On 26/03/2020 00:05, CK Hu wrote:
> > Hi, Matthias:
> >
> > On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote:
> >>
> >> On 11/03/2020 17:53, Enric Balletbo i Serra wrote:
> >>> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
> >>> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
> >>> Those functions will allow DRM driver and others to control the data
> >>> path routing.
> >>>
> >>> Signed-off-by: Enric Balletbo i Serra
> >>> Reviewed-by: Matthias Brugger
> >>> Reviewed-by: CK Hu
> >>> Acked-by: CK Hu
> >>
> >> This patch does not apply against v5.6-rc1.
> >> Please rebase as this is a quite big patch and it won't be easy to do that
> >> by hand.
> >
> > I think this patch depends on [1] which has been acked by me and I have
> > not picked it. The simple way is that you pick [1] first and then pick
> > this series.
> >
> > [1]
> > https://patchwork.kernel.org/patch/11406227/
> >
>
> You would need to provide a stable tag for me that I can merge into my tree.
> You
> can also try to merge my for-next [1] which has the newest version from Enric.
> If you see any merge conflict, then we have to do something about it :)
>
> Regards,
> Matthias
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>
You have applied this series, so I would not apply other patches which
would conflict with this series. After this series land on main stream
(wish it happen in this merge window), I would rebase other patch on
main stream.
Regards,
CK
> > Regards,
> > CK
> >
> >>
> >> Regards,
> >> Matthias
> >>
> >>> ---
> >>>
> >>> Changes in v12: None
> >>> Changes in v10:
> >>> - Select CONFIG_MTK_MMSYS (CK)
> >>> - Pass device pointer of mmsys device instead of config regs (CK)
> >>>
> >>> Changes in v9:
> >>> - Introduced a new patch to move routing control into mmsys driver.
> >>> - Removed the patch to use regmap as is not needed anymore.
> >>>
> >>> Changes in v8: None
> >>> Changes in v7: None
> >>>
> >>> drivers/gpu/drm/mediatek/Kconfig| 1 +
> >>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
> >>> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
> >>> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
> >>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
> >>> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> >>> drivers/soc/mediatek/mtk-mmsys.c| 279
> >>> include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
> >>> 8 files changed, 316 insertions(+), 282 deletions(-)
> >>> create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
> >>>
> >>> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> >>> b/drivers/gpu/drm/mediatek/Kconfig
> >>> index fa5ffc4fe823..c420f5a3d33b 100644
> >>> --- a/drivers/gpu/drm/mediatek/Kconfig
> >>> +++ b/drivers/gpu/drm/mediatek/Kconfig
> >>> @@ -11,6 +11,7 @@ config DRM_MEDIATEK
> >>> select DRM_MIPI_DSI
> >>> select DRM_PANEL
> >>> select MEMORY
> >>> + select MTK_MMSYS
> >>> select MTK_SMI
> >>> select VIDEOMODE_HELPERS
> >>> help
> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> index 0e05683d7b53..579a5a5d4472 100644
> >>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> @@ -6,6 +6,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> #include
> >>> #include
> >>> @@ -28,7 +29,7 @@
> >>> * @enabled: records whether crtc_enable succeeded
> >>> * @planes: array of 4 drm_plane structures, one for each overlay plane
> >>> * @pending_planes: whether any plane has pending changes to be applied
> >>> - * @config_regs: memory mapped mmsys configuration register space
> >>> + * @mmsys_dev: pointer to the mmsys device for configuration registers
> >>> * @mutex: handle to one of the ten disp_mutex streams
> >>> * @ddp_comp_nr: number of components in ddp_comp
> >>> * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this
> >>> crtc
> >>> @@ -50,7 +51,7 @@ struct mtk_drm_crtc {
> >>> u32 cmdq_event;
> >>> #endif
> >>>
> >>> - void __iomem*config_regs;
> >>> + struct device *mmsys_dev;
> >>> struct mtk_disp_mutex *mutex;
> >>> unsigned intddp_comp_nr;
> >>> struct mtk_ddp_comp **ddp_comp;
> >>> @@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> >>> *mtk_crtc)
> >>> }
> >>>
> >>> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> >>> - mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
> >>> - mtk_crtc->ddp_comp[i]->id,
> >>> - mtk_crtc->ddp_comp[i + 1]->id);
> >>> + mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
>
Re: [PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
On Thu, Mar 26, 2020 at 3:40 PM Hans de Goede wrote:
>
> Hi,
>
> On 3/26/20 2:39 PM, Daniel Vetter wrote:
> > On Thu, Mar 26, 2020 at 2:18 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 3/26/20 12:29 PM, Daniel Vetter wrote:
> >>> On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
> The vboxvideo driver is missing a call to remove conflicting
> framebuffers.
>
> Surprisingly, when using legacy BIOS booting this does not really cause
> any issues. But when using UEFI to boot the VM then plymouth will draw
> on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
> /dev/fb1 as fbdev emulation).
>
> VirtualBox will actual display the output of both devices (I guess it is
> showing whatever was drawn last), this causes weird artifacts because of
> pitch issues in the efifb when the VM window is not sized at 1024x768
> (the window will resize to its last size once the vboxvideo driver loads,
> changing the pitch).
>
> Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
> call fixes this.
>
> Cc: sta...@vger.kernel.org
> Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> index 8512d970a09f..261255085918 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> if (ret)
> goto err_mode_fini;
>
> +ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
> "vboxvideodrmfb");
> +if (ret)
> +goto err_irq_fini;
> >>>
> >>> To avoid transient issues this should be done as early as possible,
> >>> definitely before the drm driver starts to touch the "hw".>
> >>
> >> Ok will fix and then push this to drm-misc-next-fixes, thank you.
> >>
> >>> With that
> >>>
> >>> Reviewed-by: Daniel Vetter
> >>>
> >>> I do wonder though why the automatic removal of conflicting framebuffers
> >>> doesn't work, fbdev should already do that from register_framebuffer(),
> >>> which is called somewhere in drm_fbdev_generic_setup (after a few layers).
> >>>
> >>> Did you check why the two framebuffers don't conflict, and why the uefi
> >>> one doesn't get thrown out?
> >>
> >> I did not check, I was not aware that this check was already happening
> >> in register_framebuffer(). So I just checked and the reason why this
> >> is not working is because the fbdev emulation done by
> >> drm_fbdev_generic_setup
> >> does not fill in fb_info.apertures->ranges[0] .
> >>
> >> So fb_info.apertures->ranges[0].base is left as 0 which does not match
> >> with the registered efifb's aperture.
> >>
> >> We could try to fix this, but that is not entirely trivial, we would
> >> need to pass the pci_dev pointer down into drm_fb_helper_alloc_fbi()
> >> then and then like remove_conflicting_pci_framebuffers() does add
> >> apertures for all IORESOURCE_MEM PCI bars, but that would conflict
> >> with drivers which do rely on drm_fb_helper_alloc_fbi() currently
> >> allocating one empty aperture and then actually fill that itself...
> >
> > You don't need the pci device, because resources are attached to the
> > struct device directly. So you could just go through all
> > IORESOURCE_MEM ranges, and add them. And the struct device we always
> > have through drm_device->dev. This idea just crossed my mind since you
> > brought up IORESOURCE_MEM, might be good to try that out instead of
> > having to litter all drivers with explicit removal calls. The explicit
> > removal is really only for races (vga hw tends to blow up if 2 drivers
> > touch it, stuff like that), or when there's resources conflicts. Can
> > you try to look into that?
>
> Interesting idea, but I'm afraid that my plate is quite full with a lot of
> more urgent things atm, so I really do not have time for this, sorry.
Hm can you capture this idea in a todo then instead? I don't really
like the idea of everyone having to add bogus
remove_conflicting_framebuffer calls just because the generic fbdev
helper falls short of expectations. Kinda not happy to land the
vboxvideo patch since it's just a hack to work around a helper bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] gpu scheduler 5.6 fixes
Hi Dave, Daniel, Just one small fix for the scheduler. The following changes since commit 16fbf79b0f83bc752cee8589279f1ebfe57b3b6e: Linux 5.6-rc7 (2020-03-22 18:31:56 -0700) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.6-2020-03-26 for you to fetch changes up to 3c0fdf3302cb4f186c871684eac5c407a107e480: drm/scheduler: fix rare NULL ptr race (2020-03-26 10:22:36 -0400) amd-drm-fixes-5.6-2020-03-26: Scheduler: - Fix a race condition that could result in a segfault Yintian Tao (1): drm/scheduler: fix rare NULL ptr race drivers/gpu/drm/scheduler/sched_main.c | 2 ++ 1 file changed, 2 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
Hi,
On 3/26/20 2:39 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 2:18 PM Hans de Goede wrote:
Hi,
On 3/26/20 12:29 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
The vboxvideo driver is missing a call to remove conflicting framebuffers.
Surprisingly, when using legacy BIOS booting this does not really cause
any issues. But when using UEFI to boot the VM then plymouth will draw
on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
/dev/fb1 as fbdev emulation).
VirtualBox will actual display the output of both devices (I guess it is
showing whatever was drawn last), this causes weird artifacts because of
pitch issues in the efifb when the VM window is not sized at 1024x768
(the window will resize to its last size once the vboxvideo driver loads,
changing the pitch).
Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
call fixes this.
Cc: sta...@vger.kernel.org
Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 8512d970a09f..261255085918 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret)
goto err_mode_fini;
+ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
"vboxvideodrmfb");
+if (ret)
+goto err_irq_fini;
To avoid transient issues this should be done as early as possible,
definitely before the drm driver starts to touch the "hw".>
Ok will fix and then push this to drm-misc-next-fixes, thank you.
With that
Reviewed-by: Daniel Vetter
I do wonder though why the automatic removal of conflicting framebuffers
doesn't work, fbdev should already do that from register_framebuffer(),
which is called somewhere in drm_fbdev_generic_setup (after a few layers).
Did you check why the two framebuffers don't conflict, and why the uefi
one doesn't get thrown out?
I did not check, I was not aware that this check was already happening
in register_framebuffer(). So I just checked and the reason why this
is not working is because the fbdev emulation done by drm_fbdev_generic_setup
does not fill in fb_info.apertures->ranges[0] .
So fb_info.apertures->ranges[0].base is left as 0 which does not match
with the registered efifb's aperture.
We could try to fix this, but that is not entirely trivial, we would
need to pass the pci_dev pointer down into drm_fb_helper_alloc_fbi()
then and then like remove_conflicting_pci_framebuffers() does add
apertures for all IORESOURCE_MEM PCI bars, but that would conflict
with drivers which do rely on drm_fb_helper_alloc_fbi() currently
allocating one empty aperture and then actually fill that itself...
You don't need the pci device, because resources are attached to the
struct device directly. So you could just go through all
IORESOURCE_MEM ranges, and add them. And the struct device we always
have through drm_device->dev. This idea just crossed my mind since you
brought up IORESOURCE_MEM, might be good to try that out instead of
having to litter all drivers with explicit removal calls. The explicit
removal is really only for races (vga hw tends to blow up if 2 drivers
touch it, stuff like that), or when there's resources conflicts. Can
you try to look into that?
Interesting idea, but I'm afraid that my plate is quite full with a lot of
more urgent things atm, so I really do not have time for this, sorry.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
drm-misc-fixes-2020-03-26: drm-misc-fixes for v5.6: - SG fixes for prime, radeon and amdgpu. The following changes since commit b216a8e7908cd750550c0480cf7d2b3a37f06954: drm/lease: fix WARNING in idr_destroy (2020-03-18 14:42:18 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-03-26 for you to fetch changes up to 47f7826c520ecd92ffbffe59ecaa2fe61e42ec70: drm/radeon: fix scatter-gather mapping with user pages (2020-03-25 12:10:55 -0400) drm-misc-fixes for v5.6: - SG fixes for prime, radeon and amdgpu. Shane Francis (3): drm/prime: use dma length macro when mapping sg drm/amdgpu: fix scatter-gather mapping with user pages drm/radeon: fix scatter-gather mapping with user pages drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/drm_prime.c | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/51] mm/sl[uo]b: export __kmalloc_track(_node)_caller
On Mon, Mar 23, 2020 at 03:49:00PM +0100, Daniel Vetter wrote:
> slab does this already, and I want to use this in a memory allocation
> tracker in drm for stuff that's tied to the lifetime of a drm_device,
> not the underlying struct device. Kinda like devres, but for drm.
>
> Acked-by: Andrew Morton
> Signed-off-by: Daniel Vetter
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Cc: Andrew Morton
> Cc: linux...@kvack.org
> --
> I plan to merge this through drm-misc-next (with Andrew's ack) once
> the remainder of the drm series is in shape.
Ok I pulled this in now, but it's going to miss the 5.7 merge window, so
queued for 5.8. Should show up in linux-next right after -rc1.
-Daniel
> -Daniel
> ---
> mm/slob.c | 2 ++
> mm/slub.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/mm/slob.c b/mm/slob.c
> index fa53e9f73893..ac2aecfbc7a8 100644
> --- a/mm/slob.c
> +++ b/mm/slob.c
> @@ -524,6 +524,7 @@ void *__kmalloc_track_caller(size_t size, gfp_t gfp,
> unsigned long caller)
> {
> return __do_kmalloc_node(size, gfp, NUMA_NO_NODE, caller);
> }
> +EXPORT_SYMBOL(__kmalloc_track_caller);
>
> #ifdef CONFIG_NUMA
> void *__kmalloc_node_track_caller(size_t size, gfp_t gfp,
> @@ -531,6 +532,7 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfp,
> {
> return __do_kmalloc_node(size, gfp, node, caller);
> }
> +EXPORT_SYMBOL(__kmalloc_node_track_caller);
> #endif
>
> void kfree(const void *block)
> diff --git a/mm/slub.c b/mm/slub.c
> index 2988dae3f692..a937de5182cc 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4377,6 +4377,7 @@ void *__kmalloc_track_caller(size_t size, gfp_t
> gfpflags, unsigned long caller)
>
> return ret;
> }
> +EXPORT_SYMBOL(__kmalloc_track_caller);
>
> #ifdef CONFIG_NUMA
> void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
> @@ -4407,6 +4408,7 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t
> gfpflags,
>
> return ret;
> }
> +EXPORT_SYMBOL(__kmalloc_node_track_caller);
> #endif
>
> #ifdef CONFIG_SYSFS
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
On Thu, Mar 26, 2020 at 2:18 PM Hans de Goede wrote:
>
> Hi,
>
> On 3/26/20 12:29 PM, Daniel Vetter wrote:
> > On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
> >> The vboxvideo driver is missing a call to remove conflicting framebuffers.
> >>
> >> Surprisingly, when using legacy BIOS booting this does not really cause
> >> any issues. But when using UEFI to boot the VM then plymouth will draw
> >> on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
> >> /dev/fb1 as fbdev emulation).
> >>
> >> VirtualBox will actual display the output of both devices (I guess it is
> >> showing whatever was drawn last), this causes weird artifacts because of
> >> pitch issues in the efifb when the VM window is not sized at 1024x768
> >> (the window will resize to its last size once the vboxvideo driver loads,
> >> changing the pitch).
> >>
> >> Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
> >> call fixes this.
> >>
> >> Cc: sta...@vger.kernel.org
> >> Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> >> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> >> index 8512d970a09f..261255085918 100644
> >> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> >> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> >> @@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> >> struct pci_device_id *ent)
> >> if (ret)
> >> goto err_mode_fini;
> >>
> >> +ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
> >> "vboxvideodrmfb");
> >> +if (ret)
> >> +goto err_irq_fini;
> >
> > To avoid transient issues this should be done as early as possible,
> > definitely before the drm driver starts to touch the "hw".>
>
> Ok will fix and then push this to drm-misc-next-fixes, thank you.
>
> > With that
> >
> > Reviewed-by: Daniel Vetter
> >
> > I do wonder though why the automatic removal of conflicting framebuffers
> > doesn't work, fbdev should already do that from register_framebuffer(),
> > which is called somewhere in drm_fbdev_generic_setup (after a few layers).
> >
> > Did you check why the two framebuffers don't conflict, and why the uefi
> > one doesn't get thrown out?
>
> I did not check, I was not aware that this check was already happening
> in register_framebuffer(). So I just checked and the reason why this
> is not working is because the fbdev emulation done by drm_fbdev_generic_setup
> does not fill in fb_info.apertures->ranges[0] .
>
> So fb_info.apertures->ranges[0].base is left as 0 which does not match
> with the registered efifb's aperture.
>
> We could try to fix this, but that is not entirely trivial, we would
> need to pass the pci_dev pointer down into drm_fb_helper_alloc_fbi()
> then and then like remove_conflicting_pci_framebuffers() does add
> apertures for all IORESOURCE_MEM PCI bars, but that would conflict
> with drivers which do rely on drm_fb_helper_alloc_fbi() currently
> allocating one empty aperture and then actually fill that itself...
You don't need the pci device, because resources are attached to the
struct device directly. So you could just go through all
IORESOURCE_MEM ranges, and add them. And the struct device we always
have through drm_device->dev. This idea just crossed my mind since you
brought up IORESOURCE_MEM, might be good to try that out instead of
having to litter all drivers with explicit removal calls. The explicit
removal is really only for races (vga hw tends to blow up if 2 drivers
touch it, stuff like that), or when there's resources conflicts. Can
you try to look into that?
This generic solution will still not be enough for shmem/cma based
drivers on SoC, but at least it should take care of anything that puts
the framebuffer into some kind of bar or stolen memory region. What
drivers do explicitly for those is just put in the framebuffer base
address. But iirc fbdev core does that already unconditionally.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/51] drm/i915: Use drmm_add_final_kfree
On Thu, Mar 26, 2020 at 2:11 PM Jani Nikula wrote: > > On Mon, 23 Mar 2020, Daniel Vetter wrote: > > With this we can drop the final kfree from the release function. > > > > The mock device in the selftests needed it's pci_device split > > up from the drm_device. In the future we could simplify this again > > by allocating the pci_device as a managed allocation too. > > > > v2: I overlooked that i915_driver_destroy is also called in the > > unwind code of the error path. There we need a drm_dev_put. > > Similar for the mock object. > > > > Now the problem with that is that the drm_driver->release callbacks > > for both the real driver and the mock one assume everything has been > > set up. Hence going through that path for a partially set up driver > > will result in issues. Quickest fix is to disable the ->release() hook > > until the driver is fully initialized, and keep the onion unwinding. > > Long term would be cleanest to move everything over to drmm_ release > > actions, but that's a lot of work for a big driver like i915. Plus > > more core work needed first anyway. > > > > v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch > > over to start using drm_dev_put() to clean up even on the error path. > > Aside I think the current error path is leaking the allocation. > > > > v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/ > > > > Signed-off-by: Daniel Vetter > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: Rodrigo Vivi > > Cc: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Matthew Auld > > Cc: Andi Shyti > > Cc: Mika Kuoppala > > Cc: Daniele Ceraolo Spurio > > Cc: Daniel Vetter > > Cc: Abdiel Janulgue > > Cc: intel-...@lists.freedesktop.org > > Okay, I didn't find any holes in this, and while I wish I had more > confidence I checked all the corner cases, this is > > Reviewed-by: Jani Nikula > > A couple of notes below, don't have to do anything about them. (Maybe > better *not* to do anything about them, to move this forward. ;) > > > --- > > drivers/gpu/drm/i915/i915_drv.c | 10 ++- > > drivers/gpu/drm/i915/i915_drv.h | 3 ++ > > .../gpu/drm/i915/selftests/mock_gem_device.c | 30 ++- > > 3 files changed, 35 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index 4792051e9e2e..481313536b5a 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -43,6 +43,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include "display/intel_acpi.h" > > @@ -890,6 +891,8 @@ i915_driver_create(struct pci_dev *pdev, const struct > > pci_device_id *ent) > > return ERR_PTR(err); > > } > > > > + drmm_add_final_kfree(>drm, i915); > > + > > i915->drm.pdev = pdev; > > pci_set_drvdata(pdev, i915); > > > > @@ -908,7 +911,6 @@ static void i915_driver_destroy(struct drm_i915_private > > *i915) > > struct pci_dev *pdev = i915->drm.pdev; > > > > drm_dev_fini(>drm); > > - kfree(i915); > > } > > > > /** > > @@ -992,6 +994,8 @@ int i915_driver_probe(struct pci_dev *pdev, const > > struct pci_device_id *ent) > > > > i915_welcome_messages(i915); > > > > + i915->do_release = true; > > + > > This whole ->do_release thing is obviously a bummer. I did wonder if we > could set driver->release to NULL initially, and set it to the proper > thing here. It would make drm_dev_put() handle drm_dev_fini() internally > too. > > Less obvious? I don't know. Yeah it's not pretty, but I figured I'll go with obvious ugly than too clever for my own ugly. The trouble is that i915 is the only big driver bothers to correctly unwind everything in ->release, hence it's the one driver that really suffers through the valley of ugly here. All the others are more or less just terminally broken wrt lifetimes, so only get better. Or so simple (like the drivers I already fully clean up with this series) that I can get through the valley of ugly in one small series of 50 patches for all of them. > > return 0; > > > > out_cleanup_irq: > > @@ -1012,6 +1016,7 @@ int i915_driver_probe(struct pci_dev *pdev, const > > struct pci_device_id *ent) > > out_fini: > > i915_probe_error(i915, "Device initialization failed (%d)\n", ret); > > i915_driver_destroy(i915); > > + drm_dev_put(>drm); > > Also wondered about throwing i915_driver_destroy away, and inlining the > drm_dev_fini()... > > > return ret; > > } > > > > @@ -1051,6 +1056,9 @@ static void i915_driver_release(struct drm_device > > *dev) > > struct drm_i915_private *dev_priv = to_i915(dev); > > struct intel_runtime_pm *rpm = _priv->runtime_pm; > > > > + if (!dev_priv->do_release) > > ...or, calling drm_dev_fini() in this branch, avoiding the need to call > it elsewhere. > > *shrug* > > All of it can be done afterwards, if deemed useful. drm_dev_fini()
Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'
Le mer. 25 mars 2020 à 23:06, Rob Herring a écrit : > > Setting 'additionalProperties: false' is frequently omitted, but is > important in order to check that there aren't extra undocumented > properties in a binding. > > Ideally, we'd just add this automatically and make this the default, but > there's some cases where it doesn't work. For example, if a common > schema is referenced, then properties in the common schema aren't part > of what's considered for 'additionalProperties'. Also, sometimes there > are bus specific properties such as 'spi-max-frequency' that go into > bus child nodes, but aren't defined in the child node's schema. > > So let's stick with the json-schema defined default and add > 'additionalProperties: false' where needed. This will be a continual > review comment and game of wack-a-mole. for stm32 bindings: Reviewed-by Benjamin Gaignard > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/altera/socfpga-clk-manager.yaml| 2 ++ > .../bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml | 2 ++ > Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 2 ++ > Documentation/devicetree/bindings/arm/renesas,prr.yaml | 2 ++ > .../devicetree/bindings/arm/samsung/exynos-chipid.yaml | 2 ++ > Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 ++ > .../bindings/arm/samsung/samsung-secure-firmware.yaml | 2 ++ > .../devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++ > Documentation/devicetree/bindings/clock/fsl,plldig.yaml| 2 ++ > Documentation/devicetree/bindings/clock/imx8mn-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/imx8mp-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/milbeaut-clock.yaml| 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,msm8998-gpucc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-videocc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-videocc.yaml | 2 ++ > .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 2 ++ > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml| 2 ++ > Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++ > Documentation/devicetree/bindings/eeprom/at24.yaml | 2 ++ > .../firmware/intel,ixp4xx-network-processing-engine.yaml | 3 +++ > .../devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml | 2 ++ > .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++ > Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml| 2 ++ > .../devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 2 ++ > .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml| 2 ++ > .../devicetree/bindings/iio/chemical/plantower,pms7003.yaml| 2 ++ > .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 ++ > Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml| 2 ++ > Documentation/devicetree/bindings/iio/light/adux1020.yaml | 2 ++ > Documentation/devicetree/bindings/iio/light/bh1750.yaml
Re: [PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
Hi,
On 3/26/20 12:29 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
The vboxvideo driver is missing a call to remove conflicting framebuffers.
Surprisingly, when using legacy BIOS booting this does not really cause
any issues. But when using UEFI to boot the VM then plymouth will draw
on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
/dev/fb1 as fbdev emulation).
VirtualBox will actual display the output of both devices (I guess it is
showing whatever was drawn last), this causes weird artifacts because of
pitch issues in the efifb when the VM window is not sized at 1024x768
(the window will resize to its last size once the vboxvideo driver loads,
changing the pitch).
Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
call fixes this.
Cc: sta...@vger.kernel.org
Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 8512d970a09f..261255085918 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret)
goto err_mode_fini;
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "vboxvideodrmfb");
+ if (ret)
+ goto err_irq_fini;
To avoid transient issues this should be done as early as possible,
definitely before the drm driver starts to touch the "hw".>
Ok will fix and then push this to drm-misc-next-fixes, thank you.
With that
Reviewed-by: Daniel Vetter
I do wonder though why the automatic removal of conflicting framebuffers
doesn't work, fbdev should already do that from register_framebuffer(),
which is called somewhere in drm_fbdev_generic_setup (after a few layers).
Did you check why the two framebuffers don't conflict, and why the uefi
one doesn't get thrown out?
I did not check, I was not aware that this check was already happening
in register_framebuffer(). So I just checked and the reason why this
is not working is because the fbdev emulation done by drm_fbdev_generic_setup
does not fill in fb_info.apertures->ranges[0] .
So fb_info.apertures->ranges[0].base is left as 0 which does not match
with the registered efifb's aperture.
We could try to fix this, but that is not entirely trivial, we would
need to pass the pci_dev pointer down into drm_fb_helper_alloc_fbi()
then and then like remove_conflicting_pci_framebuffers() does add
apertures for all IORESOURCE_MEM PCI bars, but that would conflict
with drivers which do rely on drm_fb_helper_alloc_fbi() currently
allocating one empty aperture and then actually fill that itself...
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 02/51] drm/i915: Don't clear drvdata in ->release
On Wed, 25 Mar 2020, Jani Nikula wrote: > On Mon, 23 Mar 2020, Daniel Vetter wrote: >> For two reasons: >> >> - The driver core clears this already for us after we're unloaded in >> __device_release_driver(). >> >> - It's way too late, the drm_device ->release callback might massively >> outlive the underlying physical device, since a drm_device can't be > > *can be*? > >> kept alive by open drm_file or well really anything else userspace >> is still hanging onto. So if we clear this ourselves, we should >> clear it in the pci ->remove callback, not in the drm_device >> ->relase callback. > > ->release > > Reviewed-by: Jani Nikula Oops, drivers/gpu/drm/i915/i915_drv.c: In function ‘i915_driver_destroy’: drivers/gpu/drm/i915/i915_drv.c:911:18: error: unused variable ‘pdev’ [-Werror=unused-variable] struct pci_dev *pdev = i915->drm.pdev; ^~~~ > >> >> Looking at git history this was fixed in the driver core with >> >> commit 0998d0631001288a5974afc0b2a5f568bcdecb4d >> Author: Hans de Goede >> Date: Wed May 23 00:09:34 2012 +0200 >> >> device-core: Ensure drvdata = NULL when no driver is bound >> >> v2: Cite the core fix in the commit message (Chris). >> >> Cc: Greg Kroah-Hartman >> Cc: Chris Wilson >> Signed-off-by: Daniel Vetter >> --- >> drivers/gpu/drm/i915/i915_drv.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c >> b/drivers/gpu/drm/i915/i915_drv.c >> index 48ba37e35bea..4792051e9e2e 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.c >> +++ b/drivers/gpu/drm/i915/i915_drv.c >> @@ -909,9 +909,6 @@ static void i915_driver_destroy(struct drm_i915_private >> *i915) >> >> drm_dev_fini(>drm); >> kfree(i915); >> - >> -/* And make sure we never chase our dangling pointer from pci_dev */ >> -pci_set_drvdata(pdev, NULL); >> } >> >> /** -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/51] drm/i915: Use drmm_add_final_kfree
On Mon, 23 Mar 2020, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> The mock device in the selftests needed it's pci_device split
> up from the drm_device. In the future we could simplify this again
> by allocating the pci_device as a managed allocation too.
>
> v2: I overlooked that i915_driver_destroy is also called in the
> unwind code of the error path. There we need a drm_dev_put.
> Similar for the mock object.
>
> Now the problem with that is that the drm_driver->release callbacks
> for both the real driver and the mock one assume everything has been
> set up. Hence going through that path for a partially set up driver
> will result in issues. Quickest fix is to disable the ->release() hook
> until the driver is fully initialized, and keep the onion unwinding.
> Long term would be cleanest to move everything over to drmm_ release
> actions, but that's a lot of work for a big driver like i915. Plus
> more core work needed first anyway.
>
> v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch
> over to start using drm_dev_put() to clean up even on the error path.
> Aside I think the current error path is leaking the allocation.
>
> v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/
>
> Signed-off-by: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Matthew Auld
> Cc: Andi Shyti
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
> Cc: Daniel Vetter
> Cc: Abdiel Janulgue
> Cc: intel-...@lists.freedesktop.org
Okay, I didn't find any holes in this, and while I wish I had more
confidence I checked all the corner cases, this is
Reviewed-by: Jani Nikula
A couple of notes below, don't have to do anything about them. (Maybe
better *not* to do anything about them, to move this forward. ;)
> ---
> drivers/gpu/drm/i915/i915_drv.c | 10 ++-
> drivers/gpu/drm/i915/i915_drv.h | 3 ++
> .../gpu/drm/i915/selftests/mock_gem_device.c | 30 ++-
> 3 files changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4792051e9e2e..481313536b5a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "display/intel_acpi.h"
> @@ -890,6 +891,8 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return ERR_PTR(err);
> }
>
> + drmm_add_final_kfree(>drm, i915);
> +
> i915->drm.pdev = pdev;
> pci_set_drvdata(pdev, i915);
>
> @@ -908,7 +911,6 @@ static void i915_driver_destroy(struct drm_i915_private
> *i915)
> struct pci_dev *pdev = i915->drm.pdev;
>
> drm_dev_fini(>drm);
> - kfree(i915);
> }
>
> /**
> @@ -992,6 +994,8 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>
> i915_welcome_messages(i915);
>
> + i915->do_release = true;
> +
This whole ->do_release thing is obviously a bummer. I did wonder if we
could set driver->release to NULL initially, and set it to the proper
thing here. It would make drm_dev_put() handle drm_dev_fini() internally
too.
Less obvious? I don't know.
> return 0;
>
> out_cleanup_irq:
> @@ -1012,6 +1016,7 @@ int i915_driver_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> out_fini:
> i915_probe_error(i915, "Device initialization failed (%d)\n", ret);
> i915_driver_destroy(i915);
> + drm_dev_put(>drm);
Also wondered about throwing i915_driver_destroy away, and inlining the
drm_dev_fini()...
> return ret;
> }
>
> @@ -1051,6 +1056,9 @@ static void i915_driver_release(struct drm_device *dev)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_runtime_pm *rpm = _priv->runtime_pm;
>
> + if (!dev_priv->do_release)
...or, calling drm_dev_fini() in this branch, avoiding the need to call
it elsewhere.
*shrug*
All of it can be done afterwards, if deemed useful.
> + return;
> +
> disable_rpm_wakeref_asserts(rpm);
>
> i915_gem_driver_release(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a7ea1d855359..7ae652723ed7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -821,6 +821,9 @@ struct i915_selftest_stash {
> struct drm_i915_private {
> struct drm_device drm;
>
> + /* FIXME: Device release actions should all be moved to drmm_ */
> + bool do_release;
> +
> const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
> struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
> struct intel_driver_caps caps;
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
>
Re: [PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
> The vboxvideo driver is missing a call to remove conflicting framebuffers.
>
> Surprisingly, when using legacy BIOS booting this does not really cause
> any issues. But when using UEFI to boot the VM then plymouth will draw
> on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
> /dev/fb1 as fbdev emulation).
>
> VirtualBox will actual display the output of both devices (I guess it is
> showing whatever was drawn last), this causes weird artifacts because of
> pitch issues in the efifb when the VM window is not sized at 1024x768
> (the window will resize to its last size once the vboxvideo driver loads,
> changing the pitch).
>
> Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
> call fixes this.
>
> Cc: sta...@vger.kernel.org
> Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> index 8512d970a09f..261255085918 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> if (ret)
> goto err_mode_fini;
>
> + ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
> "vboxvideodrmfb");
> + if (ret)
> + goto err_irq_fini;
To avoid transient issues this should be done as early as possible,
definitely before the drm driver starts to touch the "hw". With that
Reviewed-by: Daniel Vetter
I do wonder though why the automatic removal of conflicting framebuffers
doesn't work, fbdev should already do that from register_framebuffer(),
which is called somewhere in drm_fbdev_generic_setup (after a few layers).
Did you check why the two framebuffers don't conflict, and why the uefi
one doesn't get thrown out?
-Daniel
> +
> ret = drm_fbdev_generic_setup(>ddev, 32);
> if (ret)
> goto err_irq_fini;
> --
> 2.26.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/vmwgfx: fix spelling mistake "Cound" -> "Could"
From: Colin Ian King
There is a spelling mistake in a DRM_ERROR error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 367d5b87ee6a..2e61a4ecd8ef 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3037,7 +3037,7 @@ static int vmw_cmd_dx_bind_streamoutput(struct
vmw_private *dev_priv,
res = vmw_dx_streamoutput_lookup(vmw_context_res_man(ctx_node->ctx),
cmd->body.soid);
if (IS_ERR(res)) {
- DRM_ERROR("Cound not find streamoutput to bind.\n");
+ DRM_ERROR("Could not find streamoutput to bind.\n");
return PTR_ERR(res);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Variable Refresh Rate & flickering screens
On Wednesday, March 25, 2020 7:53 PM, Manasi Navare wrote: > But I am still figuring out how the panel indicates this restriction that we > need to program > in the HW registers. > > Harry/SImon, do you know of any such panels that have these restrictions and > if they > indicate this limitation or the maxshift through EDID or DPCD? As far as I've understood, there is no such information exposed by the connector. This is the main annoying thing with this slew rate: it seems like we can only guess what slew rate to pick. Hence Martin's proposal to add some properties to allow user-space to tune this (with sane default values that work on most screens). Another idea is to have a hwdb of "bad VRR screens", and only apply a slew rate to these screens. Not sure what the best would be yet. Having a lot of VRR screens to test with could help getting a better understanding. I think AMD has a certification program for FreeSync, maybe they have a flickering requirement? (Something like "screen must not flicker if rate increases or decreases by XXX Hz each vblank"?) Simon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
On Wed, 25 Mar 2020 17:18:15 +0100 Neil Armstrong wrote: > Hi, > > On 25/03/2020 14:49, Pekka Paalanen wrote: > > On Wed, 25 Mar 2020 11:24:15 +0100 > > Neil Armstrong wrote: > > > >> Hi, > >> > >> On 25/03/2020 10:04, Simon Ser wrote: > >>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong > >>> wrote: > >>> > Amlogic uses a proprietary lossless image compression protocol and format > for their hardware video codec accelerators, either video decoders or > video input encoders. > > This introduces the Scatter Memory layout, means the header contains > IOMMU > references to the compressed frames content to optimize memory access > and layout. > > In this mode, only the header memory address is needed, thus the content > memory organization is tied to the current producer execution and cannot > be saved/dumped neither transferrable between Amlogic SoCs supporting > this > modifier. > >>> > >>> I don't think this is suitable for modifiers. User-space relies on > >>> being able to copy a buffer from one machine to another over the > >>> network. It would be pretty annoying for user-space to have a blacklist > >>> of modifiers that don't work this way. > >>> > >>> Example of such user-space: > >>> https://gitlab.freedesktop.org/mstoeckl/waypipe/ > >>> > >> > >> I really understand your point, but this is one of the use-cases we need > >> solve. > >> This is why I split the fourcc patch and added an explicit comment. > >> > >> Please point me a way to display such buffer, the HW exists, works like > >> that and > >> it's a fact and can't change. > >> > >> It will be the same for secure zero-copy buffers we can't map from > >> userspace, but > >> only the HW decoder can read/write and HW display can read. > > > > The comparison to secure buffers is a good one. > > > > Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier > > meaningfully mmappable to CPU always / sometimes / never / > > varies-and-cannot-know? > > mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, > absolutely never. > > So yeah, these should not be mmappable since not meaningful. Ok. So we have a modifier that means there is no point in even trying to mmap the buffer. Not being able to mmap automatically makes things like waypipe not be able to work on the buffer, so the buffer cannot be replicated over a network, hence there is no compatibility issue. However, it still leaves the problem that, since waypipe is "just" a message relay that does not participate in the protocol really, the two end points might still negotiate to use a modifier that waypipe cannot handle. Secure buffers have the same problem: by definition, one must not be able to replicate the buffer elsewhere. To me it seems there needs to be a way to identify buffers that cannot be mmapped. mmap() failing is obvious, but in waypipe's case it is too late - the end points have already negotiated the formats and modifiers and they cannot handle failures afterwards. > > > > Maybe this type should be handled similar to secure buffers, with the > > exception that they are not actually secured but only mostly > > inaccessible. Then again, I haven't looked at any of the secure buffer > > proposals. > > Actually, the Amlogic platforms offers secure video path using these exact > modifiers, AFAIK it doesn't support the NV12 dual-write output in secure. > > AFAIK last submission is from AMD, and it doesn't talk at all about > mmapability > of the secure BOs. To me, a secure buffer concept automatically implies that there cannot be CPU access to it. The CPU is not trusted, right? Not even the kernel. I would assume secure implies no mmap. So I wonder, how does the secure buffers proposal manage userspace like waypipe? Or, is the secure buffer proposal allowing mmap, but the content is indecipherable? Maybe they shouldn't allow mmap? I think much of the criticism against this modifier should also be presented to a secure buffers proposal and see how that turns out. If they have the same problem, maybe you could use their solution? Thanks, pq pgpa3w4_QFMqi.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
* Jason A. Donenfeld wrote: > Very little has changed from last time, and this whole series still > looks good to me. I think I already ack'd most packages, but in case > it helps: > > Reviewed-by: Jason A. Donenfeld Acked-by: Ingo Molnar > Since this touches a lot of stuff, it might be best to get it in as > early as possible during the merge window, as I imagine new code being > added is going to want to be touching those makefiles too. I'd argue the opposite: please merge this later in the merge window, to not disrupt the vast body of other stuff that has already been lined up and has been tested, and to give time for these new bits to get tested some more. Also, please get it into -next ASAP, today would be ideal for test coverage ... Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
* Masahiro Yamada wrote:
> > LGTM. I've got these four from Jason A. Donenfeld queued up in
> > tip:WIP.x86/asm:
> >
> > bd5b1283e41c: ("crypto: Curve25519 - do not pollute dispatcher based on
> > assembler")
> > 829f32d78588: ("crypto: X86 - rework configuration, based on Kconfig")
> > 95ef9f80ed63: ("x86/build: Probe assembler from Kconfig instead of Kbuild")
> > 1651e700664b: ("x86: Fix bitops.h warning with a moved cast")
> >
> > I suppose these might interact (maybe even conflict), and are topically
> > related.
> >
> > Would you like to pull these into the kbuild tree? You can find them in:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/asm
> >
> > Thanks,
> >
> > Ingo
>
>
> I did not know that these had already landed in tip tree.
>
> They are immature version.
> (In fact CONFIG_AS_CFI and AS_ADX are false-negative
> if GCC that defaults to 32-bit is used.)
>
> Can you simply discard the WIP.x86/asm branch,
> and only reapply
> 1651e700664b: ("x86: Fix bitops.h warning with a moved cast")
>
> ?
Sure, done!
In case you need any x86 maintainer acks for your series:
Acked-by: Ingo Molnar
Thanks,
Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false'
On 25/03/2020 23:05, Rob Herring wrote: > Numerous schemas are missing 'additionalProperties: false' statements which > ensures a binding doesn't have any extra undocumented properties or child > nodes. Fixing this reveals various missing properties, so let's fix all > those occurrences. > > Cc: Stephen Boyd > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Masahiro Yamada > Cc: Jonathan Cameron > Cc: Hartmut Knaack > Cc: Lars-Peter Clausen > Cc: Peter Meerwald-Stadler > Cc: Neil Armstrong > Cc: Mauro Carvalho Chehab > Cc: Kevin Hilman > Cc: Lee Jones > Cc: "David S. Miller" > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Guillaume La Roque > Cc: Zhang Rui > Cc: Daniel Lezcano > Cc: Thomas Gleixner > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-amlo...@lists.infradead.org > Cc: net...@vger.kernel.org > Cc: linux...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/clock/fsl,plldig.yaml | 3 +++ > .../gpio/socionext,uniphier-gpio.yaml | 2 ++ > .../bindings/gpu/arm,mali-bifrost.yaml| 6 ++--- > .../bindings/gpu/arm,mali-midgard.yaml| 3 +++ > .../bindings/iio/adc/adi,ad7192.yaml | 1 - > .../bindings/iio/pressure/bmp085.yaml | 3 +++ > .../media/amlogic,meson-gx-ao-cec.yaml| 9 +--- > .../bindings/mfd/rohm,bd71828-pmic.yaml | 3 +++ > .../bindings/net/ti,cpsw-switch.yaml | 23 --- > .../regulator/max77650-regulator.yaml | 2 +- > .../bindings/thermal/amlogic,thermal.yaml | 2 ++ > .../bindings/timer/arm,arch_timer_mmio.yaml | 2 ++ > 12 files changed, 43 insertions(+), 16 deletions(-) > For: .../bindings/gpu/arm,mali-bifrost.yaml| 6 ++--- .../bindings/gpu/arm,mali-midgard.yaml| 3 +++ .../media/amlogic,meson-gx-ao-cec.yaml| 9 +--- .../bindings/thermal/amlogic,thermal.yaml | 2 ++ Reviewed-by: Neil Armstrong ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'
On 25/03/2020 23:05, Rob Herring wrote: > Setting 'additionalProperties: false' is frequently omitted, but is > important in order to check that there aren't extra undocumented > properties in a binding. > > Ideally, we'd just add this automatically and make this the default, but > there's some cases where it doesn't work. For example, if a common > schema is referenced, then properties in the common schema aren't part > of what's considered for 'additionalProperties'. Also, sometimes there > are bus specific properties such as 'spi-max-frequency' that go into > bus child nodes, but aren't defined in the child node's schema. > > So let's stick with the json-schema defined default and add > 'additionalProperties: false' where needed. This will be a continual > review comment and game of wack-a-mole. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/altera/socfpga-clk-manager.yaml| 2 ++ > .../bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml | 2 ++ > Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 2 ++ > Documentation/devicetree/bindings/arm/renesas,prr.yaml | 2 ++ > .../devicetree/bindings/arm/samsung/exynos-chipid.yaml | 2 ++ > Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 ++ > .../bindings/arm/samsung/samsung-secure-firmware.yaml | 2 ++ > .../devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++ > Documentation/devicetree/bindings/clock/fsl,plldig.yaml| 2 ++ > Documentation/devicetree/bindings/clock/imx8mn-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/imx8mp-clock.yaml | 2 ++ > Documentation/devicetree/bindings/clock/milbeaut-clock.yaml| 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,msm8998-gpucc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sc7180-videocc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-dispcc.yaml | 2 ++ > Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++ > .../devicetree/bindings/clock/qcom,sdm845-videocc.yaml | 2 ++ > .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 2 ++ > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml| 2 ++ > Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++ > Documentation/devicetree/bindings/eeprom/at24.yaml | 2 ++ > .../firmware/intel,ixp4xx-network-processing-engine.yaml | 3 +++ > .../devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml | 2 ++ > .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml| 2 ++ > Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++ > Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++ > Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++ > Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 ++ > Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml| 2 ++ > .../devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 2 ++ > .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml| 2 ++ > .../devicetree/bindings/iio/chemical/plantower,pms7003.yaml| 2 ++ > .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 ++ > Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml| 2 ++ > Documentation/devicetree/bindings/iio/light/adux1020.yaml | 2 ++ > Documentation/devicetree/bindings/iio/light/bh1750.yaml| 2 ++ >
Re: [PATCH v2 09/16] drm/i915: remove always-defined CONFIG_AS_MOVNTDQA
On Thu, 26 Mar 2020, Masahiro Yamada wrote:
> CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
> Use SSE4.1 movntdqa to accelerate reads from WC memory").
>
> We raise the minimal supported binutils version from time to time.
> The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum
> required binutils version to 2.21").
>
> I confirmed the code in $(call as-instr,...) can be assembled by the
> binutils 2.21 assembler and also by LLVM integrated assembler.
>
> Remove CONFIG_AS_MOVNTDQA, which is always defined.
>
> Signed-off-by: Masahiro Yamada
> Reviewed-by: Nick Desaulniers
Ack for merging this via whichever tree you see fit; please let me know
if you want me to pick this up via drm-intel.
BR,
Jani.
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/i915/Makefile | 3 ---
> drivers/gpu/drm/i915/i915_memcpy.c | 5 -
> 2 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index a1f2411aa21b..e559e53fc634 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -28,9 +28,6 @@ subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
> CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
> CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
>
> -subdir-ccflags-y += \
> - $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)
> -
> subdir-ccflags-y += -I$(srctree)/$(src)
>
> # Please keep these build lists sorted!
> diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
> b/drivers/gpu/drm/i915/i915_memcpy.c
> index fdd550405fd3..7b3b83bd5ab8 100644
> --- a/drivers/gpu/drm/i915/i915_memcpy.c
> +++ b/drivers/gpu/drm/i915/i915_memcpy.c
> @@ -35,7 +35,6 @@
>
> static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
>
> -#ifdef CONFIG_AS_MOVNTDQA
> static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
> {
> kernel_fpu_begin();
> @@ -93,10 +92,6 @@ static void __memcpy_ntdqu(void *dst, const void *src,
> unsigned long len)
>
> kernel_fpu_end();
> }
> -#else
> -static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len) {}
> -static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len) {}
> -#endif
>
> /**
> * i915_memcpy_from_wc: perform an accelerated *aligned* read from WC
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/9] fs: Constify vma argument to vma_is_dax
On Tue, Mar 24, 2020 at 09:11:15PM +0100, Thomas Hellström (VMware) wrote: > From: "Thomas Hellstrom (VMware)" > > The function is used by upcoming vma_is_special_huge() with which we want > to use a const vma argument. Since for vma_is_dax() the vma argument is > only dereferenced for reading, constify it. > > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Matthew Wilcox (Oracle)" > Cc: "Kirill A. Shutemov" > Cc: Ralph Campbell > Cc: "Jérôme Glisse" > Cc: "Christian König" > Cc: Dan Williams > Signed-off-by: Thomas Hellstrom (VMware) > Reviewed-by: Roland Scheidegger > Acked-by: Christian König Acked-by: Matthew Wilcox (Oracle) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v12 0/5] arm/arm64: mediatek: Fix mt8173 mmsys device probing
[Patches rebased on top of a clean 5.6-rc1 branch] Dear all, These patches are intended to solve an old standing issue on some Mediatek devices (mt8173, mt2701 and mt2712 are affected by this issue). Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver gets probed, which in effect breaks graphics on those devices. The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display and MDP (Media Data Path) subsystem. On this series the clk driver is not a pure clock controller but a system controller that can provide access to the shared registers between the different drivers that need it (mediatek-drm and mediatek-mdp). Hence the MMSYS clk driver was moved to drivers/soc/mediatek and is the entry point (parent) which will trigger the probe of the corresponding mediatek-drm driver. **IMPORTANT** This series only fixes the issue on mt8173 to make it simple and as is the only platform I can test. Similar changes should be applied for mt2701 and mt2712 to have display working. These patches apply on top of linux-next. For reference, here are the links to the old discussions: * v11: https://patchwork.kernel.org/project/linux-mediatek/list/?series=249871 * v10: https://patchwork.kernel.org/project/linux-mediatek/list/?series=248505 * v9: https://patchwork.kernel.org/project/linux-clk/list/?series=247591 * v8: https://patchwork.kernel.org/project/linux-mediatek/list/?series=244891 * v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217 * v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 * v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063 * v4: * https://patchwork.kernel.org/patch/10530871/ * https://patchwork.kernel.org/patch/10530883/ * https://patchwork.kernel.org/patch/10530885/ * https://patchwork.kernel.org/patch/10530911/ * https://patchwork.kernel.org/patch/10530913/ * v3: * https://patchwork.kernel.org/patch/10367857/ * https://patchwork.kernel.org/patch/10367861/ * https://patchwork.kernel.org/patch/10367877/ * https://patchwork.kernel.org/patch/10367875/ * https://patchwork.kernel.org/patch/10367885/ * https://patchwork.kernel.org/patch/10367883/ * https://patchwork.kernel.org/patch/10367889/ * https://patchwork.kernel.org/patch/10367907/ * https://patchwork.kernel.org/patch/10367909/ * https://patchwork.kernel.org/patch/10367905/ * v2: No relevant discussion, see v3 * v1: * https://patchwork.kernel.org/patch/10016497/ * https://patchwork.kernel.org/patch/10016499/ * https://patchwork.kernel.org/patch/10016505/ * https://patchwork.kernel.org/patch/10016507/ Best regards, Enric Changes in v12: - Leave the clocks part in drivers/clk (clk-mt8173-mm) - Instantiate the clock driver from the mtk-mmsys driver. - Add default config option to not break anything. - Removed the Reviewed-by CK tag as changed the organization. Changes in v10: - Update the binding documentation for the mmsys system controller. - Renamed to be generic mtk-mmsys - Add driver data support to be able to support diferent SoCs - Select CONFIG_MTK_MMSYS (CK) - Pass device pointer of mmsys device instead of config regs (CK) - Match driver data to get display routing. Changes in v9: - Move mmsys to drivers/soc/mediatek (CK) - Introduced a new patch to move routing control into mmsys driver. - Removed the patch to use regmap as is not needed anymore. - Do not move the display routing from the drm driver (CK) Changes in v8: - Be a builtin_platform_driver like other mediatek mmsys drivers. - New patch introduced in this series. Changes in v7: - Free clk_data->clks as well - Get rid of private data structure Enric Balletbo i Serra (3): dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller soc / drm: mediatek: Move routing control to mmsys device soc / drm: mediatek: Fix mediatek-drm device probing Matthias Brugger (2): drm/mediatek: Omit warning on probe defers clk / soc: mediatek: Move mt8173 MMSYS to platform driver .../bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- drivers/clk/mediatek/Kconfig | 7 + drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt8173-mm.c | 146 drivers/clk/mediatek/clk-mt8173.c | 104 -- drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 259 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 7 -
[RESEND PATCH v12 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
From: Matthias Brugger
There is no strong reason for this to use CLK_OF_DECLARE instead of
being a platform driver. Plus, MMSYS provides clocks but also a shared
register space for the mediatek-drm and the mediatek-mdp
driver. So move the MMSYS clocks to a new platform driver and also
create a new MMSYS platform driver in drivers/soc/mediatek that
instantiates the clock driver.
Signed-off-by: Matthias Brugger
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
---
Changes in v12:
- Leave the clocks part in drivers/clk (clk-mt8173-mm)
- Instantiate the clock driver from the mtk-mmsys driver.
- Add default config option to not break anything.
- Removed the Reviewed-by CK tag as changed the organization.
Changes in v10:
- Renamed to be generic mtk-mmsys
- Add driver data support to be able to support diferent SoCs
Changes in v9:
- Move mmsys to drivers/soc/mediatek (CK)
Changes in v8:
- Be a builtin_platform_driver like other mediatek mmsys drivers.
Changes in v7:
- Free clk_data->clks as well
- Get rid of private data structure
drivers/clk/mediatek/Kconfig | 7 ++
drivers/clk/mediatek/Makefile| 1 +
drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++
drivers/clk/mediatek/clk-mt8173.c| 104 ---
drivers/soc/mediatek/Kconfig | 8 ++
drivers/soc/mediatek/Makefile| 1 +
drivers/soc/mediatek/mtk-mmsys.c | 50 +
7 files changed, 213 insertions(+), 104 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c
create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index ea3c70d1307e..9e28db8125cd 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -274,6 +274,13 @@ config COMMON_CLK_MT8173
---help---
This driver supports MediaTek MT8173 clocks.
+config COMMON_CLK_MT8173_MMSYS
+ bool "Clock driver for MediaTek MT8173 mmsys"
+ depends on COMMON_CLK_MT8173
+ default COMMON_CLK_MT8173
+ help
+ This driver supports MediaTek MT8173 mmsys clocks.
+
config COMMON_CLK_MT8183
bool "Clock driver for MediaTek MT8183"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8cdb76a5cd71..bb0536942075 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_COMMON_CLK_MT7629_ETHSYS) += clk-mt7629-eth.o
obj-$(CONFIG_COMMON_CLK_MT7629_HIFSYS) += clk-mt7629-hif.o
obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
+obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
obj-$(CONFIG_COMMON_CLK_MT8183) += clk-mt8183.o
obj-$(CONFIG_COMMON_CLK_MT8183_AUDIOSYS) += clk-mt8183-audio.o
obj-$(CONFIG_COMMON_CLK_MT8183_CAMSYS) += clk-mt8183-cam.o
diff --git a/drivers/clk/mediatek/clk-mt8173-mm.c
b/drivers/clk/mediatek/clk-mt8173-mm.c
new file mode 100644
index ..36fa20be77b6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8173-mm.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ */
+
+#include
+#include
+#include
+
+#include "clk-gate.h"
+#include "clk-mtk.h"
+
+#include
+
+static const struct mtk_gate_regs mm0_cg_regs = {
+ .set_ofs = 0x0104,
+ .clr_ofs = 0x0108,
+ .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs = {
+ .set_ofs = 0x0114,
+ .clr_ofs = 0x0118,
+ .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = _cg_regs, \
+ .shift = _shift,\
+ .ops = _clk_gate_ops_setclr,\
+ }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = _cg_regs, \
+ .shift = _shift,\
+ .ops = _clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate mt8173_mm_clks[] = {
+ /* MM0 */
+ GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+ GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+ GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+ GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+ GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+
[RESEND PATCH v12 1/5] drm/mediatek: Omit warning on probe defers
From: Matthias Brugger
It can happen that the mmsys clock drivers aren't probed before the
platform driver gets invoked. The platform driver used to print a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Reviewed-by: CK Hu
Signed-off-by: Enric Balletbo i Serra
---
Changes in v12: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 -
drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c| 8 ++--
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +++-
7 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 6fb0d6983a4a..3ae9c810845b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -119,7 +119,10 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
_disp_color_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 891d80c73e04..28651bc579bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -386,7 +386,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
_disp_ovl_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0cb848d64206..e04319fedf46 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -294,7 +294,10 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
_disp_rdma_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 01fa8b8d763d..1b219edef541 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -701,21 +701,27 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dpi->engine_clk)) {
ret = PTR_ERR(dpi->engine_clk);
- dev_err(dev, "Failed to get engine clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get engine clock: %d\n", ret);
+
return ret;
}
dpi->pixel_clk = devm_clk_get(dev, "pixel");
if (IS_ERR(dpi->pixel_clk)) {
ret = PTR_ERR(dpi->pixel_clk);
- dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+
return ret;
}
dpi->tvd_clk = devm_clk_get(dev, "pll");
if (IS_ERR(dpi->tvd_clk)) {
ret = PTR_ERR(dpi->tvd_clk);
- dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 13035c906035..b885f60f474c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -628,7 +628,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
if (!ddp->data->no_clk) {
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
+ if
[RESEND PATCH v12 2/5] dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller
The mmsys system controller is not only a pure clock controller, so
update the binding documentation to reflect that apart from providing
clocks, it also provides routing and miscellaneous control registers.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
Reviewed-by: CK Hu
---
Changes in v12: None
Changes in v10:
- Update the binding documentation for the mmsys system controller.
Changes in v9: None
Changes in v8: None
Changes in v7: None
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 301eefbe1618..8d6a9d98e7a6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -1,7 +1,8 @@
Mediatek mmsys controller
-The Mediatek mmsys controller provides various clocks to the system.
+The Mediatek mmsys system controller provides clock control, routing control,
+and miscellaneous control in mmsys partition.
Required Properties:
@@ -15,13 +16,13 @@ Required Properties:
- "mediatek,mt8183-mmsys", "syscon"
- #clock-cells: Must be 1
-The mmsys controller uses the common clk binding from
+For the clock control, the mmsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
-mmsys: clock-controller@1400 {
+mmsys: syscon@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
#clock-cells = <1>;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
On 2020-03-25 21:20, Doug Anderson wrote:
Hi,
On Wed, Mar 25, 2020 at 8:40 AM Rob Clark wrote:
On Tue, Mar 24, 2020 at 7:35 AM Doug Anderson
wrote:
>
> Hi,
>
> On Sun, Mar 22, 2020 at 11:14 PM Kalyan Thota wrote:
> >
> > "The PM core always increments the runtime usage counter
> > before calling the ->suspend() callback and decrements it
> > after calling the ->resume() callback"
> >
> > DPU and DSI are managed as runtime devices. When
> > suspend is triggered, PM core adds a refcount on all the
> > devices and calls device suspend, since usage count is
> > already incremented, runtime suspend was not getting called
> > and it kept the clocks on which resulted in target not
> > entering into XO shutdown.
> >
> > Add changes to manage runtime devices during pm sleep.
> >
> > Changes in v1:
> > - Remove unnecessary checks in the function
> > _dpu_kms_disable_dpu (Rob Clark).
>
> I'm wondering what happened with my feedback on v1, AKA:
>
>
https://lore.kernel.org/r/CAD=FV=VxzEV40g+ieuEN+7o=34+wm8mho8o7t5za1yosx7s...@mail.gmail.com
>
> Maybe you didn't see it? ...or if you or Rob think I'm way off base
> (always possible) then please tell me so.
>
-- I didn't notice your comments earlier. Apologies !!
At least w/ the current patch, disable_dpu should not be called for
screen-off (although I'd hope if all the screens are off the device
would suspend).
OK, that's good.
-- Rob has answered it, with current change disable_dpu will only be
called during pm_suspend.
But I won't claim to be a pm expert.. so not really
sure if this is the best approach or not. I don't think our
arrangement of sub-devices under a parent is completely abnormal, so
it does feel like there should be a simpler solution..
I think the other arguments about asymmetry are still valid and I've
fixed bugs around this type of thing in the past. For instance, see
commit f7ccbed656f7 ("drm/rockchip: Suspend DP late").
* What happens if suspend is aborted partway through (by getting a
wakeup even as you're suspending, for instance)? In such a case some
of the normal suspend calls will be called but "suspend_late" won't be
called. Does that mess up your counting?
-- I understand this concern, i'll explore a bit more on how to handle
"failed to suspend","early awake"
cases (to restore the usage_count) since suspend_late wont be called.
*From your description, it sure seems like this part of the
runtime_pm.rst doc is relevant to you:
Did I misunderstand and this isn't what you want? Looking a bit
further, maybe the right thing is to use the "SMART_SUSPEND" flag?
-- if you notice in the device_prepare
(https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1913)
there is a pm_runtime_get_noresume at L1931, which will increment the
usagecount before triggering client prepare call, hence implementing
prepare wont fetch us much.
This appears to be more for the cases when device is runtime suspended
and suspend followed later
"one example usecase that i can think of, is screen timeout after that
suspend is triggered"
currently the problem i am looking at is that
PM Core does +1 in device prepare
DPU driver does -1 in suspend
DPU driver does +1 in suspend late ( look for right place )
PM core does -1 in device complete
i'll get back after exploring a bit.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: sram: qcom: Clean-up 'ranges' and child node names
On Wed, Mar 25, 2020 at 04:05:39PM -0600, Rob Herring wrote:
> The regex for child nodes doesn't match the example. This wasn't flagged
> with 'additionalProperties: false' missing. The child node schema was also
> incorrect with 'ranges' property as it applies to child nodes and should
> be moved up to the parent node.
>
> Fixes: 957fd69d396b ("dt-bindings: soc: qcom: add On Chip MEMory (OCMEM)
> bindings")
> Cc: Brian Masney
> Cc: Bjorn Andersson
> Cc: linux-arm-...@vger.kernel.org
> Signed-off-by: Rob Herring
Reviewed-by: Brian Masney
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
On 11/03/2020 17:53, Enric Balletbo i Serra wrote:
> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
> Those functions will allow DRM driver and others to control the data
> path routing.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Matthias Brugger
> Reviewed-by: CK Hu
> Acked-by: CK Hu
This patch does not apply against v5.6-rc1.
Please rebase as this is a quite big patch and it won't be easy to do that by
hand.
Regards,
Matthias
> ---
>
> Changes in v12: None
> Changes in v10:
> - Select CONFIG_MTK_MMSYS (CK)
> - Pass device pointer of mmsys device instead of config regs (CK)
>
> Changes in v9:
> - Introduced a new patch to move routing control into mmsys driver.
> - Removed the patch to use regmap as is not needed anymore.
>
> Changes in v8: None
> Changes in v7: None
>
> drivers/gpu/drm/mediatek/Kconfig| 1 +
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> drivers/soc/mediatek/mtk-mmsys.c| 279
> include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
> 8 files changed, 316 insertions(+), 282 deletions(-)
> create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
>
> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> b/drivers/gpu/drm/mediatek/Kconfig
> index fa5ffc4fe823..c420f5a3d33b 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -11,6 +11,7 @@ config DRM_MEDIATEK
> select DRM_MIPI_DSI
> select DRM_PANEL
> select MEMORY
> + select MTK_MMSYS
> select MTK_SMI
> select VIDEOMODE_HELPERS
> help
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0e05683d7b53..579a5a5d4472 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -28,7 +29,7 @@
> * @enabled: records whether crtc_enable succeeded
> * @planes: array of 4 drm_plane structures, one for each overlay plane
> * @pending_planes: whether any plane has pending changes to be applied
> - * @config_regs: memory mapped mmsys configuration register space
> + * @mmsys_dev: pointer to the mmsys device for configuration registers
> * @mutex: handle to one of the ten disp_mutex streams
> * @ddp_comp_nr: number of components in ddp_comp
> * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
> @@ -50,7 +51,7 @@ struct mtk_drm_crtc {
> u32 cmdq_event;
> #endif
>
> - void __iomem*config_regs;
> + struct device *mmsys_dev;
> struct mtk_disp_mutex *mutex;
> unsigned intddp_comp_nr;
> struct mtk_ddp_comp **ddp_comp;
> @@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> }
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> - mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
> - mtk_crtc->ddp_comp[i]->id,
> - mtk_crtc->ddp_comp[i + 1]->id);
> + mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
> + mtk_crtc->ddp_comp[i]->id,
> + mtk_crtc->ddp_comp[i + 1]->id);
> mtk_disp_mutex_add_comp(mtk_crtc->mutex,
> mtk_crtc->ddp_comp[i]->id);
> }
> @@ -355,9 +356,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> mtk_crtc->ddp_comp[i]->id);
> mtk_disp_mutex_disable(mtk_crtc->mutex);
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> - mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> - mtk_crtc->ddp_comp[i]->id,
> - mtk_crtc->ddp_comp[i + 1]->id);
> + mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
> + mtk_crtc->ddp_comp[i]->id,
> + mtk_crtc->ddp_comp[i + 1]->id);
> mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
> mtk_crtc->ddp_comp[i]->id);
> }
> @@ -761,7 +762,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> if (!mtk_crtc)
> return -ENOMEM;
>
> - mtk_crtc->config_regs = priv->config_regs;
> + mtk_crtc->mmsys_dev = priv->mmsys_dev;
> mtk_crtc->ddp_comp_nr = path_len;
> mtk_crtc->ddp_comp =
[RESEND PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
Those functions will allow DRM driver and others to control the data
path routing.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
Reviewed-by: CK Hu
Acked-by: CK Hu
---
Changes in v12: None
Changes in v10:
- Select CONFIG_MTK_MMSYS (CK)
- Pass device pointer of mmsys device instead of config regs (CK)
Changes in v9:
- Introduced a new patch to move routing control into mmsys driver.
- Removed the patch to use regmap as is not needed anymore.
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/Kconfig| 1 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/soc/mediatek/mtk-mmsys.c| 279
include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
8 files changed, 316 insertions(+), 282 deletions(-)
create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index fa5ffc4fe823..c420f5a3d33b 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -11,6 +11,7 @@ config DRM_MEDIATEK
select DRM_MIPI_DSI
select DRM_PANEL
select MEMORY
+ select MTK_MMSYS
select MTK_SMI
select VIDEOMODE_HELPERS
help
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0dfcd1787e65..615a54e60fe2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,7 @@
* @enabled: records whether crtc_enable succeeded
* @planes: array of 4 drm_plane structures, one for each overlay plane
* @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @mmsys_dev: pointer to the mmsys device for configuration registers
* @mutex: handle to one of the ten disp_mutex streams
* @ddp_comp_nr: number of components in ddp_comp
* @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -50,7 +51,7 @@ struct mtk_drm_crtc {
u32 cmdq_event;
#endif
- void __iomem*config_regs;
+ struct device *mmsys_dev;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -300,9 +301,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
DRM_DEBUG_DRIVER("mediatek_ddp_ddp_path_setup\n");
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
-mtk_crtc->ddp_comp[i]->id,
-mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
+ mtk_crtc->ddp_comp[i]->id,
+ mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_add_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -360,9 +361,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_crtc->ddp_comp[i]->id);
mtk_disp_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
- mtk_crtc->ddp_comp[i]->id,
- mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
+mtk_crtc->ddp_comp[i]->id,
+mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -755,7 +756,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->config_regs = priv->config_regs;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->ddp_comp_nr = path_len;
mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
sizeof(*mtk_crtc->ddp_comp),
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b885f60f474c..014c1bbe1df2 100644
---
[RESEND PATCH v12 5/5] soc / drm: mediatek: Fix mediatek-drm device probing
In the actual implementation the same compatible string
"mediatek,-mmsys" is used to bind the clock drivers
(drivers/soc/mediatek) as well as to the gpu driver
(drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends with the problem
that the only probed driver is the clock driver and there is no display
at all.
In any case having the same compatible string for two drivers is not
correct and should be fixed. To fix this, and maintain backward
compatibility, we can consider that the mmsys driver is the top-level
entry point for the multimedia subsystem, so is not a pure clock
controller but a system controller, and the drm driver is instantiated
by that MMSYS driver.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
Acked-by: CK Hu
---
Changes in v12: None
Changes in v10:
- Match driver data to get display routing.
Changes in v9:
- Do not move the display routing from the drm driver (CK)
Changes in v8:
- New patch introduced in this series.
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 31 --
drivers/soc/mediatek/mtk-mmsys.c | 6 +
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f2f07098265d..e2bb0d19ef99 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -422,9 +422,21 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static const struct of_device_id mtk_drm_of_ids[] = {
+ { .compatible = "mediatek,mt2701-mmsys",
+ .data = _mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = _mmsys_driver_data},
+ { .compatible = "mediatek,mt8173-mmsys",
+ .data = _mmsys_driver_data},
+ { }
+};
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *phandle = dev->parent->of_node;
+ const struct of_device_id *of_id;
struct mtk_drm_private *private;
struct device_node *node;
struct component_match *match = NULL;
@@ -442,8 +454,14 @@ static int mtk_drm_probe(struct platform_device *pdev)
return -ENODEV;
}
+ of_id = of_match_node(mtk_drm_of_ids, phandle);
+ if (!of_id)
+ return -ENODEV;
+
+ private->data = of_id->data;
+
/* Iterate over sibling DISP function blocks */
- for_each_child_of_node(dev->of_node->parent, node) {
+ for_each_child_of_node(phandle->parent, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -577,22 +595,11 @@ static int mtk_drm_sys_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
mtk_drm_sys_resume);
-static const struct of_device_id mtk_drm_of_ids[] = {
- { .compatible = "mediatek,mt2701-mmsys",
- .data = _mmsys_driver_data},
- { .compatible = "mediatek,mt2712-mmsys",
- .data = _mmsys_driver_data},
- { .compatible = "mediatek,mt8173-mmsys",
- .data = _mmsys_driver_data},
- { }
-};
-
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
.remove = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
- .of_match_table = mtk_drm_of_ids,
.pm = _drm_pm_ops,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 4b286b525cd3..32a92ec447c5 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -285,6 +285,7 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
const struct mtk_mmsys_driver_data *data;
struct device *dev = >dev;
struct platform_device *clks;
+ struct platform_device *drm;
void __iomem *config_regs;
struct resource *mem;
int ret;
@@ -307,6 +308,11 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
if (IS_ERR(clks))
return PTR_ERR(clks);
+ drm = platform_device_register_data(>dev, "mediatek-drm",
+ PLATFORM_DEVID_AUTO, NULL, 0);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/9] fs: Constify vma argument to vma_is_dax
> From: "Thomas Hellstrom (VMware)"
>
> The function is used by upcoming vma_is_special_huge() with which we want
> to use a const vma argument. Since for vma_is_dax() the vma argument is
> only dereferenced for reading, constify it.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Matthew Wilcox (Oracle)"
> Cc: "Kirill A. Shutemov"
> Cc: Ralph Campbell
> Cc: "Jérôme Glisse"
> Cc: "Christian König"
> Cc: Dan Williams
> Signed-off-by: Thomas Hellstrom (VMware)
> Reviewed-by: Roland Scheidegger
> Acked-by: Christian König
> ---
> include/linux/fs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3cd4fe6b845e..2b38ce5b73ad 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3391,7 +3391,7 @@ static inline bool io_is_direct(struct file *filp)
> return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
> }
>
> -static inline bool vma_is_dax(struct vm_area_struct *vma)
> +static inline bool vma_is_dax(const struct vm_area_struct *vma)
> {
> return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
> }
> --
Acked-by: Pankaj Gupta
> 2.21.1
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/16] drm/i915: remove always-defined CONFIG_AS_MOVNTDQA
CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
Use SSE4.1 movntdqa to accelerate reads from WC memory").
We raise the minimal supported binutils version from time to time.
The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum
required binutils version to 2.21").
I confirmed the code in $(call as-instr,...) can be assembled by the
binutils 2.21 assembler and also by LLVM integrated assembler.
Remove CONFIG_AS_MOVNTDQA, which is always defined.
Signed-off-by: Masahiro Yamada
Reviewed-by: Nick Desaulniers
---
Changes in v2: None
drivers/gpu/drm/i915/Makefile | 3 ---
drivers/gpu/drm/i915/i915_memcpy.c | 5 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a1f2411aa21b..e559e53fc634 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,9 +28,6 @@ subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
-subdir-ccflags-y += \
- $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)
-
subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
b/drivers/gpu/drm/i915/i915_memcpy.c
index fdd550405fd3..7b3b83bd5ab8 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -35,7 +35,6 @@
static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
-#ifdef CONFIG_AS_MOVNTDQA
static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
{
kernel_fpu_begin();
@@ -93,10 +92,6 @@ static void __memcpy_ntdqu(void *dst, const void *src,
unsigned long len)
kernel_fpu_end();
}
-#else
-static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len) {}
-static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len) {}
-#endif
/**
* i915_memcpy_from_wc: perform an accelerated *aligned* read from WC
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
This series of cleanups was prompted by Linus:
https://lkml.org/lkml/2020/3/12/726
First, this series drop always-on CONFIG_AS_* options.
Some of those options were introduced in old days.
For example, the check for CONFIG_AS_CFI dates back to 2006.
We raise the minimal tool versions from time to time.
Currently, we require binutils 2.21
(and we even plan to bump it to 2.23).
After cleaning away the old checks,
as-instr calls are moved to Kconfig from Makefiles,
then more Kconfig / Makefile code is cleaned up.
I folded all relevanet patches into this series,
as suggested by Jason A. Donenfeld.
The update for v2 is quite small.
I just swapped the patch order of patch 8 and 11
instead of moving comments around files,
which was addressed by Nick Desaulniers.
Borislav Petkov (1):
Documentation/changes: Raise minimum supported binutils version to
2.23
Jason A. Donenfeld (4):
x86: probe assembler capabilities via kconfig instead of makefile
crypto: x86 - rework configuration based on Kconfig
crypto: curve25519 - do not pollute dispatcher based on assembler
x86: update AS_* macros to binutils >=2.23, supporting ADX and AVX2
Masahiro Yamada (11):
lib/raid6/test: fix build on distros whose /bin/sh is not bash
x86: remove unneeded defined(__ASSEMBLY__) check from asm/dwarf2.h
x86: remove always-defined CONFIG_AS_CFI
x86: remove unneeded (CONFIG_AS_)CFI_SIGNAL_FRAME
x86: remove always-defined CONFIG_AS_CFI_SECTIONS
x86: remove always-defined CONFIG_AS_SSSE3
x86: remove always-defined CONFIG_AS_AVX
x86: replace arch macros from compiler with CONFIG_X86_{32,64}
drm/i915: remove always-defined CONFIG_AS_MOVNTDQA
x86: add comments about the binutils version to support code in
as-instr
crypto: x86 - clean up poly1305-x86_64-cryptogams.S by 'make clean'
Documentation/process/changes.rst | 4 +-
arch/x86/Kconfig | 2 +
arch/x86/Kconfig.assembler| 17 ++
arch/x86/Makefile | 22 ---
arch/x86/crypto/Makefile | 162 +++---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 6 -
arch/x86/crypto/aesni-intel_glue.c| 21 +--
arch/x86/crypto/blake2s-core.S| 2 -
arch/x86/crypto/chacha_glue.c | 6 +-
arch/x86/crypto/poly1305-x86_64-cryptogams.pl | 16 --
arch/x86/crypto/poly1305_glue.c | 11 +-
arch/x86/crypto/sha1_ssse3_asm.S | 4 -
arch/x86/crypto/sha1_ssse3_glue.c | 13 --
arch/x86/crypto/sha256-avx-asm.S | 3 -
arch/x86/crypto/sha256-avx2-asm.S | 3 -
arch/x86/crypto/sha256_ssse3_glue.c | 12 --
arch/x86/crypto/sha512-avx-asm.S | 2 -
arch/x86/crypto/sha512-avx2-asm.S | 3 -
arch/x86/crypto/sha512_ssse3_glue.c | 10 --
arch/x86/include/asm/dwarf2.h | 44 -
arch/x86/include/asm/xor_avx.h| 9 -
drivers/gpu/drm/i915/Makefile | 3 -
drivers/gpu/drm/i915/i915_memcpy.c| 5 -
include/crypto/curve25519.h | 6 +-
kernel/signal.c | 2 +-
lib/raid6/algos.c | 12 +-
lib/raid6/avx2.c | 4 -
lib/raid6/recov_avx2.c| 6 -
lib/raid6/recov_ssse3.c | 6 -
lib/raid6/test/Makefile | 9 +-
30 files changed, 101 insertions(+), 324 deletions(-)
create mode 100644 arch/x86/Kconfig.assembler
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
