[PATCH AUTOSEL 5.14 15/40] drm/amdkfd: fix svm_migrate_fini warning
From: Philip Yang
[ Upstream commit 197ae17722e989942b36e33e044787877f158574 ]
Device manager releases device-specific resources when a driver
disconnects from a device, devm_memunmap_pages and
devm_release_mem_region calls in svm_migrate_fini are redundant.
It causes below warning trace after patch "drm/amdgpu: Split
amdgpu_device_fini into early and late", so remove function
svm_migrate_fini.
BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718
WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795
devm_release_action+0x51/0x60
Call Trace:
? memunmap_pages+0x360/0x360
svm_migrate_fini+0x2d/0x60 [amdgpu]
kgd2kfd_device_exit+0x23/0xa0 [amdgpu]
amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu]
amdgpu_device_fini_sw+0x45/0x290 [amdgpu]
amdgpu_driver_release_kms+0x12/0x30 [amdgpu]
drm_dev_release+0x20/0x40 [drm]
release_nodes+0x196/0x1e0
device_release_driver_internal+0x104/0x1d0
driver_detach+0x47/0x90
bus_remove_driver+0x7a/0xd0
pci_unregister_driver+0x3d/0x90
amdgpu_exit+0x11/0x20 [amdgpu]
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 -
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 13 -
drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 5 -
3 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 9e52948d4992..0e5ebb384164 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -910,7 +910,6 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
void kgd2kfd_device_exit(struct kfd_dev *kfd)
{
if (kfd->init_complete) {
- svm_migrate_fini((struct amdgpu_device *)kfd->kgd);
device_queue_manager_uninit(kfd->dqm);
kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 165e0ebb619d..4a16e3c257b9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -891,6 +891,10 @@ int svm_migrate_init(struct amdgpu_device *adev)
pgmap->ops = _migrate_pgmap_ops;
pgmap->owner = SVM_ADEV_PGMAP_OWNER(adev);
pgmap->flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
+
+ /* Device manager releases device-specific resources, memory region and
+* pgmap when driver disconnects from device.
+*/
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
@@ -911,12 +915,3 @@ int svm_migrate_init(struct amdgpu_device *adev)
return 0;
}
-
-void svm_migrate_fini(struct amdgpu_device *adev)
-{
- struct dev_pagemap *pgmap = >kfd.dev->pgmap;
-
- devm_memunmap_pages(adev->dev, pgmap);
- devm_release_mem_region(adev->dev, pgmap->range.start,
- pgmap->range.end - pgmap->range.start + 1);
-}
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.h
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.h
index 0de76b5d4973..2f5b3394c9ed 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.h
@@ -47,7 +47,6 @@ unsigned long
svm_migrate_addr_to_pfn(struct amdgpu_device *adev, unsigned long addr);
int svm_migrate_init(struct amdgpu_device *adev);
-void svm_migrate_fini(struct amdgpu_device *adev);
#else
@@ -55,10 +54,6 @@ static inline int svm_migrate_init(struct amdgpu_device
*adev)
{
return 0;
}
-static inline void svm_migrate_fini(struct amdgpu_device *adev)
-{
- /* empty */
-}
#endif /* IS_ENABLED(CONFIG_HSA_AMD_SVM) */
--
2.33.0
[PATCH AUTOSEL 5.14 14/40] drm/amdkfd: handle svm migrate init error
From: Philip Yang
[ Upstream commit 7d6687200a939176847090bbde5cb79a82792a2f ]
If svm migration init failed to create pgmap for device memory, set
pgmap type to 0 to disable device SVM support capability.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index dab290a4d19d..165e0ebb619d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -894,6 +894,9 @@ int svm_migrate_init(struct amdgpu_device *adev)
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
+
+ /* Disable SVM support capability */
+ pgmap->type = 0;
devm_release_mem_region(adev->dev, res->start,
res->end - res->start + 1);
return PTR_ERR(r);
--
2.33.0
Re: [PATCH v2 3/3] drm/rockchip: dsi: Disable PLL clock on bind error
On Tue, Sep 28, 2021 at 2:00 AM Brian Norris wrote:
>
> Fix some error handling here noticed in review of other changes.
>
> Reported-by: Chen-Yu Tsai
> Signed-off-by: Brian Norris
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi
bridge driver")
Otherwise,
Reviewed-by: Chen-Yu Tsai
Additionally, I would move patch 2 and this patch before the first patch,
as these two fix a commit introduced in v5.0, while the first patch fixes
something introduced in v5.14. This would make automatic backporting cleaner.
> ---
>
> Changes in v2:
> - New
>
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index fa4080176719..0ed13d81fe60 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -943,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> ret = clk_prepare_enable(dsi->grf_clk);
> if (ret) {
> DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n",
> ret);
> - goto out_pm_runtime;
> + goto out_pll_clk;
> }
>
> dw_mipi_dsi_rockchip_config(dsi);
> @@ -955,17 +955,19 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
> - goto out_pm_runtime;
> + goto out_pll_clk;
> }
>
> ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
> - goto out_pm_runtime;
> + goto out_pll_clk;
> }
>
> return 0;
>
> +out_pll_clk:
> + clk_disable_unprepare(dsi->pllref_clk);
> out_pm_runtime:
> pm_runtime_put(dsi->dev);
> if (dsi->slave)
> --
> 2.33.0.685.g46640cef36-goog
>
Re: [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema
On Mon, 27 Sep 2021 18:44:21 +0200, H. Nikolaus Schaller wrote: > From: Sam Ravnborg > > Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. > Based on .txt binding from Zubair Lutfullah Kakakhel > > Signed-off-by: Sam Ravnborg > Signed-off-by: H. Nikolaus Schaller > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > --- > .../bindings/display/ingenic-jz4780-hdmi.yaml | 85 +++ > 1 file changed, 85 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml:45:16: [error] syntax error: mapping values are not allowed here (syntax) dtschema/dtc warnings/errors: make[1]: *** Deleting file 'Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.example.dts' Traceback (most recent call last): File "/usr/local/bin/dt-extract-example", line 45, in binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 434, in load return constructor.get_single_data() File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 120, in get_single_data node = self.composer.get_single_node() File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node File "_ruamel_yaml.pyx", line 889, in _ruamel_yaml.CParser._compose_mapping_node File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node File "_ruamel_yaml.pyx", line 891, in _ruamel_yaml.CParser._compose_mapping_node File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this context in "", line 45, column 16 make[1]: *** [Documentation/devicetree/bindings/Makefile:20: Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml: mapping values are not allowed in this context in "", line 45, column 16 /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml: ignoring, error parsing file warning: no schema found in file: ./Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml make: *** [Makefile:1441: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1533471 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [Freedreno] [PATCH] drm/msm/dsi: do not install irq handler before power up the host
On 28/09/2021 04:33, abhin...@codeaurora.org wrote:
On 2021-09-27 18:29, Dmitry Baryshkov wrote:
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
>>> On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader.
If this
> state generates an IRQ, it might hang the system by holding the
> interrupt line before the driver sets up the DSI host to the
known
> state.
>
> Move the request/free_irq calls into
msm_dsi_host_power_on/_off calls,
> so that we can be sure that the interrupt is delivered when
the host is
> in the known state.
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector
support")
> Signed-off-by: Dmitry Baryshkov
This is a valid change and we have seen interrupt storms in
downstream
happening
when like you said the bootloader leaves the DSI host in unknown
state.
Just one question below.
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e269df285136..cd842347a6b1 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1951,15 +1951,6 @@ int msm_dsi_host_modeset_init(struct
> mipi_dsi_host *host,
> return ret;
> }
>
> - ret = devm_request_irq(>dev, msm_host->irq,
> - dsi_host_irq, IRQF_TRIGGER_HIGH |
IRQF_ONESHOT,
> - "dsi_isr", msm_host);
> - if (ret < 0) {
> - DRM_DEV_ERROR(>dev, "failed to request
IRQ%u: %d\n",
> - msm_host->irq, ret);
> - return ret;
> - }
> -
> msm_host->dev = dev;
> ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
> if (ret) {
> @@ -2413,6 +2404,16 @@ int msm_dsi_host_power_on(struct
mipi_dsi_host
> *host,
> if (msm_host->disp_en_gpio)
> gpiod_set_value(msm_host->disp_en_gpio, 1);
>
> + ret = devm_request_irq(_host->pdev->dev,
msm_host->irq,
> + dsi_host_irq, IRQF_TRIGGER_HIGH |
IRQF_ONESHOT,
> + "dsi_isr", msm_host);
> + if (ret < 0) {
> + DRM_DEV_ERROR(_host->pdev->dev, "failed to
request IRQ%u: %d\n",
> + msm_host->irq, ret);
> + return ret;
> + }
> +
> +
Do you want to move this to msm_dsi_host_enable()?
So without the controller being enabled it is still in unknown
state?
>>>
>>> msm_dsi_host_power_on() reconfigures the host registers, so the
state
>>> is known at the end of the power_on().
>>>
Also do you want to do this after dsi0 and dsi1 are
initialized to
account for
dual dsi cases?
>>>
>>> I don't think this should matter. The host won't generate 'extra'
>>> interrupts in such case, will it?
>>>
>> We have seen cases where misconfiguration has caused interrupts to
>> storm only
>> on one DSI in some cases. So yes, I would prefer this is done after
>> both are
>> configured.
>
> I've checked. The power_on is called from
dsi_mgr_bridge_pre_enable()
> when both DSI hosts should be bound.
DSI being bound is enough? I thought the issue we are trying to
address
is that
we need to have called msm_dsi_host_power_on() for both the hosts so
that both are
put in the known state before requesting the irq.
OR in other words move the irq_enable() to below location.
341 static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
342 {
364 ret = msm_dsi_host_power_on(host, _shared_timings[id],
is_bonded_dsi, msm_dsi->phy);
365 if (ret) {
366 pr_err("%s: power on host %d failed, %d\n",
__func__, id, ret);
367 goto host_on_fail;
368 }
369
370 if (is_bonded_dsi && msm_dsi1) {
371 ret = msm_dsi_host_power_on(msm_dsi1->host,
372 _shared_timings[DSI_1],
is_bonded_dsi, msm_dsi1->phy);
373 if (ret) {
374 pr_err("%s: power on host1 failed, %d\n",
375 __func__,
ret);
376 goto host1_on_fail;
377 }
378 }
< move the irq enable here >
**
Ah, I see your point. What about moving to msm_dsi_host_enable() then?
Yes, I had suggested this a
Re: [Freedreno] [PATCH] drm/msm/dsi: do not install irq handler before power up the host
On 2021-09-27 18:29, Dmitry Baryshkov wrote:
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
>>> On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader. If this
> state generates an IRQ, it might hang the system by holding the
> interrupt line before the driver sets up the DSI host to the known
> state.
>
> Move the request/free_irq calls into msm_dsi_host_power_on/_off calls,
> so that we can be sure that the interrupt is delivered when the host is
> in the known state.
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
> Signed-off-by: Dmitry Baryshkov
This is a valid change and we have seen interrupt storms in
downstream
happening
when like you said the bootloader leaves the DSI host in unknown
state.
Just one question below.
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e269df285136..cd842347a6b1 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1951,15 +1951,6 @@ int msm_dsi_host_modeset_init(struct
> mipi_dsi_host *host,
> return ret;
> }
>
> - ret = devm_request_irq(>dev, msm_host->irq,
> - dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> - "dsi_isr", msm_host);
> - if (ret < 0) {
> - DRM_DEV_ERROR(>dev, "failed to request IRQ%u: %d\n",
> - msm_host->irq, ret);
> - return ret;
> - }
> -
> msm_host->dev = dev;
> ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
> if (ret) {
> @@ -2413,6 +2404,16 @@ int msm_dsi_host_power_on(struct mipi_dsi_host
> *host,
> if (msm_host->disp_en_gpio)
> gpiod_set_value(msm_host->disp_en_gpio, 1);
>
> + ret = devm_request_irq(_host->pdev->dev, msm_host->irq,
> + dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + "dsi_isr", msm_host);
> + if (ret < 0) {
> + DRM_DEV_ERROR(_host->pdev->dev, "failed to request IRQ%u:
%d\n",
> + msm_host->irq, ret);
> + return ret;
> + }
> +
> +
Do you want to move this to msm_dsi_host_enable()?
So without the controller being enabled it is still in unknown
state?
>>>
>>> msm_dsi_host_power_on() reconfigures the host registers, so the state
>>> is known at the end of the power_on().
>>>
Also do you want to do this after dsi0 and dsi1 are initialized to
account for
dual dsi cases?
>>>
>>> I don't think this should matter. The host won't generate 'extra'
>>> interrupts in such case, will it?
>>>
>> We have seen cases where misconfiguration has caused interrupts to
>> storm only
>> on one DSI in some cases. So yes, I would prefer this is done after
>> both are
>> configured.
>
> I've checked. The power_on is called from dsi_mgr_bridge_pre_enable()
> when both DSI hosts should be bound.
DSI being bound is enough? I thought the issue we are trying to
address
is that
we need to have called msm_dsi_host_power_on() for both the hosts so
that both are
put in the known state before requesting the irq.
OR in other words move the irq_enable() to below location.
341 static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
342 {
364 ret = msm_dsi_host_power_on(host, _shared_timings[id],
is_bonded_dsi, msm_dsi->phy);
365 if (ret) {
366 pr_err("%s: power on host %d failed, %d\n",
__func__, id, ret);
367 goto host_on_fail;
368 }
369
370 if (is_bonded_dsi && msm_dsi1) {
371 ret = msm_dsi_host_power_on(msm_dsi1->host,
372 _shared_timings[DSI_1],
is_bonded_dsi, msm_dsi1->phy);
373 if (ret) {
374 pr_err("%s: power on host1 failed, %d\n",
375 __func__,
ret);
376 goto host1_on_fail;
377 }
378 }
< move the irq enable here >
**
Ah, I see your point. What about moving to msm_dsi_host_enable()
then?
Yes, I had suggested this a few replies ago. But only at the dsi_msgr
we know if DSI1 is also done.
So
Re: [Freedreno] [PATCH] drm/msm/dsi: do not install irq handler before power up the host
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
>>> On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader. If
this
> state generates an IRQ, it might hang the system by holding the
> interrupt line before the driver sets up the DSI host to the
known
> state.
>
> Move the request/free_irq calls into
msm_dsi_host_power_on/_off calls,
> so that we can be sure that the interrupt is delivered when
the host is
> in the known state.
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector
support")
> Signed-off-by: Dmitry Baryshkov
This is a valid change and we have seen interrupt storms in
downstream
happening
when like you said the bootloader leaves the DSI host in unknown
state.
Just one question below.
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e269df285136..cd842347a6b1 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1951,15 +1951,6 @@ int msm_dsi_host_modeset_init(struct
> mipi_dsi_host *host,
> return ret;
> }
>
> - ret = devm_request_irq(>dev, msm_host->irq,
> - dsi_host_irq, IRQF_TRIGGER_HIGH |
IRQF_ONESHOT,
> - "dsi_isr", msm_host);
> - if (ret < 0) {
> - DRM_DEV_ERROR(>dev, "failed to request
IRQ%u: %d\n",
> - msm_host->irq, ret);
> - return ret;
> - }
> -
> msm_host->dev = dev;
> ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
> if (ret) {
> @@ -2413,6 +2404,16 @@ int msm_dsi_host_power_on(struct
mipi_dsi_host
> *host,
> if (msm_host->disp_en_gpio)
> gpiod_set_value(msm_host->disp_en_gpio, 1);
>
> + ret = devm_request_irq(_host->pdev->dev, msm_host->irq,
> + dsi_host_irq, IRQF_TRIGGER_HIGH |
IRQF_ONESHOT,
> + "dsi_isr", msm_host);
> + if (ret < 0) {
> + DRM_DEV_ERROR(_host->pdev->dev, "failed to
request IRQ%u: %d\n",
> + msm_host->irq, ret);
> + return ret;
> + }
> +
> +
Do you want to move this to msm_dsi_host_enable()?
So without the controller being enabled it is still in unknown
state?
>>>
>>> msm_dsi_host_power_on() reconfigures the host registers, so the
state
>>> is known at the end of the power_on().
>>>
Also do you want to do this after dsi0 and dsi1 are initialized to
account for
dual dsi cases?
>>>
>>> I don't think this should matter. The host won't generate 'extra'
>>> interrupts in such case, will it?
>>>
>> We have seen cases where misconfiguration has caused interrupts to
>> storm only
>> on one DSI in some cases. So yes, I would prefer this is done after
>> both are
>> configured.
>
> I've checked. The power_on is called from dsi_mgr_bridge_pre_enable()
> when both DSI hosts should be bound.
DSI being bound is enough? I thought the issue we are trying to address
is that
we need to have called msm_dsi_host_power_on() for both the hosts so
that both are
put in the known state before requesting the irq.
OR in other words move the irq_enable() to below location.
341 static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
342 {
364 ret = msm_dsi_host_power_on(host, _shared_timings[id],
is_bonded_dsi, msm_dsi->phy);
365 if (ret) {
366 pr_err("%s: power on host %d failed, %d\n", __func__,
id, ret);
367 goto host_on_fail;
368 }
369
370 if (is_bonded_dsi && msm_dsi1) {
371 ret = msm_dsi_host_power_on(msm_dsi1->host,
372 _shared_timings[DSI_1],
is_bonded_dsi, msm_dsi1->phy);
373 if (ret) {
374 pr_err("%s: power on host1 failed, %d\n",
375 __func__, ret);
376 goto host1_on_fail;
377 }
378 }
< move the irq enable here >
**
Ah, I see your point. What about moving to msm_dsi_host_enable() then?
Yes, I had suggested this a few replies ago. But only at the dsi_msgr we
know if DSI1 is also done.
So you can do it right after it
Re: [Freedreno] [PATCH] drm/msm/dsi: do not install irq handler before power up the host
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
>>> On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader. If this
> state generates an IRQ, it might hang the system by holding the
> interrupt line before the driver sets up the DSI host to the known
> state.
>
> Move the request/free_irq calls into msm_dsi_host_power_on/_off calls,
> so that we can be sure that the interrupt is delivered when the host is
> in the known state.
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
> Signed-off-by: Dmitry Baryshkov
This is a valid change and we have seen interrupt storms in
downstream
happening
when like you said the bootloader leaves the DSI host in unknown
state.
Just one question below.
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e269df285136..cd842347a6b1 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1951,15 +1951,6 @@ int msm_dsi_host_modeset_init(struct
> mipi_dsi_host *host,
> return ret;
> }
>
> - ret = devm_request_irq(>dev, msm_host->irq,
> - dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> - "dsi_isr", msm_host);
> - if (ret < 0) {
> - DRM_DEV_ERROR(>dev, "failed to request IRQ%u: %d\n",
> - msm_host->irq, ret);
> - return ret;
> - }
> -
> msm_host->dev = dev;
> ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
> if (ret) {
> @@ -2413,6 +2404,16 @@ int msm_dsi_host_power_on(struct mipi_dsi_host
> *host,
> if (msm_host->disp_en_gpio)
> gpiod_set_value(msm_host->disp_en_gpio, 1);
>
> + ret = devm_request_irq(_host->pdev->dev, msm_host->irq,
> + dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + "dsi_isr", msm_host);
> + if (ret < 0) {
> + DRM_DEV_ERROR(_host->pdev->dev, "failed to request IRQ%u:
%d\n",
> + msm_host->irq, ret);
> + return ret;
> + }
> +
> +
Do you want to move this to msm_dsi_host_enable()?
So without the controller being enabled it is still in unknown
state?
>>>
>>> msm_dsi_host_power_on() reconfigures the host registers, so the state
>>> is known at the end of the power_on().
>>>
Also do you want to do this after dsi0 and dsi1 are initialized to
account for
dual dsi cases?
>>>
>>> I don't think this should matter. The host won't generate 'extra'
>>> interrupts in such case, will it?
>>>
>> We have seen cases where misconfiguration has caused interrupts to
>> storm only
>> on one DSI in some cases. So yes, I would prefer this is done after
>> both are
>> configured.
>
> I've checked. The power_on is called from dsi_mgr_bridge_pre_enable()
> when both DSI hosts should be bound.
DSI being bound is enough? I thought the issue we are trying to
address
is that
we need to have called msm_dsi_host_power_on() for both the hosts so
that both are
put in the known state before requesting the irq.
OR in other words move the irq_enable() to below location.
341 static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
342 {
364 ret = msm_dsi_host_power_on(host, _shared_timings[id],
is_bonded_dsi, msm_dsi->phy);
365 if (ret) {
366 pr_err("%s: power on host %d failed, %d\n", __func__,
id, ret);
367 goto host_on_fail;
368 }
369
370 if (is_bonded_dsi && msm_dsi1) {
371 ret = msm_dsi_host_power_on(msm_dsi1->host,
372 _shared_timings[DSI_1],
is_bonded_dsi, msm_dsi1->phy);
373 if (ret) {
374 pr_err("%s: power on host1 failed, %d\n",
375 __func__,
ret);
376 goto host1_on_fail;
377 }
378 }
< move the irq enable here >
**
Ah, I see your point. What about moving to msm_dsi_host_enable() then?
Yes, I had suggested this a few replies ago. But only at the dsi_msgr we
know if DSI1 is also done.
So you can do it right after it in below location?
427 if (is_dual_dsi && msm_dsi1) {
428
Re: [PATCH v3.1] dt-bindings: display: renesas,du: Provide bindings for r8a779a0
On Mon, Sep 27, 2021 at 03:57:34PM -0500, Rob Herring wrote: > On Thu, 23 Sep 2021 14:01:38 +0100, Kieran Bingham wrote: > > From: Kieran Bingham > > > > Extend the Renesas DU display bindings to support the r8a779a0 V3U. > > > > Reviewed-by: Laurent Pinchart > > Reviewed-by: Geert Uytterhoeven > > Signed-off-by: Kieran Bingham > > > > --- > > v2: > > - Collected Laurent's tag > > - Remove clock-names requirement > > - Specify only a single clock > > > > v3: > > - Use clocknames: 'du.0' instead of 'du' to remain consistent > > > > v3.1: > > - Require clock-names > > - Collect Geert's tag > > > > .../bindings/display/renesas,du.yaml | 51 +++ > > 1 file changed, 51 insertions(+) > > Reviewed-by: Rob Herring Thank you Rob, that was the missing piece for a pull request :-) -- Regards, Laurent Pinchart
Re: [Freedreno] [PATCH] drm/msm/dsi: do not install irq handler before power up the host
On Tue, 28 Sept 2021 at 03:22, wrote:
>
> On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> > On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
> >> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
> >>> Hi,
> >>>
> >>> On Tue, 21 Sept 2021 at 20:01, wrote:
>
> On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> > The DSI host might be left in some state by the bootloader. If this
> > state generates an IRQ, it might hang the system by holding the
> > interrupt line before the driver sets up the DSI host to the known
> > state.
> >
> > Move the request/free_irq calls into msm_dsi_host_power_on/_off calls,
> > so that we can be sure that the interrupt is delivered when the host is
> > in the known state.
> >
> > Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
> > Signed-off-by: Dmitry Baryshkov
>
> This is a valid change and we have seen interrupt storms in
> downstream
> happening
> when like you said the bootloader leaves the DSI host in unknown
> state.
> Just one question below.
>
> > ---
> > drivers/gpu/drm/msm/dsi/dsi_host.c | 21 -
> > 1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > index e269df285136..cd842347a6b1 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -1951,15 +1951,6 @@ int msm_dsi_host_modeset_init(struct
> > mipi_dsi_host *host,
> > return ret;
> > }
> >
> > - ret = devm_request_irq(>dev, msm_host->irq,
> > - dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> > - "dsi_isr", msm_host);
> > - if (ret < 0) {
> > - DRM_DEV_ERROR(>dev, "failed to request IRQ%u:
> > %d\n",
> > - msm_host->irq, ret);
> > - return ret;
> > - }
> > -
> > msm_host->dev = dev;
> > ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
> > if (ret) {
> > @@ -2413,6 +2404,16 @@ int msm_dsi_host_power_on(struct mipi_dsi_host
> > *host,
> > if (msm_host->disp_en_gpio)
> > gpiod_set_value(msm_host->disp_en_gpio, 1);
> >
> > + ret = devm_request_irq(_host->pdev->dev, msm_host->irq,
> > + dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> > + "dsi_isr", msm_host);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(_host->pdev->dev, "failed to request
> > IRQ%u: %d\n",
> > + msm_host->irq, ret);
> > + return ret;
> > + }
> > +
> > +
>
> Do you want to move this to msm_dsi_host_enable()?
> So without the controller being enabled it is still in unknown
> state?
> >>>
> >>> msm_dsi_host_power_on() reconfigures the host registers, so the state
> >>> is known at the end of the power_on().
> >>>
> Also do you want to do this after dsi0 and dsi1 are initialized to
> account for
> dual dsi cases?
> >>>
> >>> I don't think this should matter. The host won't generate 'extra'
> >>> interrupts in such case, will it?
> >>>
> >> We have seen cases where misconfiguration has caused interrupts to
> >> storm only
> >> on one DSI in some cases. So yes, I would prefer this is done after
> >> both are
> >> configured.
> >
> > I've checked. The power_on is called from dsi_mgr_bridge_pre_enable()
> > when both DSI hosts should be bound.
>
> DSI being bound is enough? I thought the issue we are trying to address
> is that
> we need to have called msm_dsi_host_power_on() for both the hosts so
> that both are
> put in the known state before requesting the irq.
>
> OR in other words move the irq_enable() to below location.
>
> 341 static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
> 342 {
>
> 364 ret = msm_dsi_host_power_on(host, _shared_timings[id],
> is_bonded_dsi, msm_dsi->phy);
> 365 if (ret) {
> 366 pr_err("%s: power on host %d failed, %d\n", __func__, id,
> ret);
> 367 goto host_on_fail;
> 368 }
> 369
> 370 if (is_bonded_dsi && msm_dsi1) {
> 371 ret = msm_dsi_host_power_on(msm_dsi1->host,
> 372 _shared_timings[DSI_1], is_bonded_dsi,
> msm_dsi1->phy);
> 373 if (ret) {
> 374 pr_err("%s: power on host1 failed, %d\n",
> 375 __func__, ret);
> 376 goto host1_on_fail;
> 377 }
> 378 }
>
> < move the irq enable here >
> **
Ah, I see your point. What about moving to msm_dsi_host_enable()
Re: [Freedreno] [PATCH] drm/msm/dsi: do not install irq handler before power up the host
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
On 2021-09-21 10:47, Dmitry Baryshkov wrote:
Hi,
On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader. If this
> state generates an IRQ, it might hang the system by holding the
> interrupt line before the driver sets up the DSI host to the known
> state.
>
> Move the request/free_irq calls into msm_dsi_host_power_on/_off calls,
> so that we can be sure that the interrupt is delivered when the host is
> in the known state.
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
> Signed-off-by: Dmitry Baryshkov
This is a valid change and we have seen interrupt storms in
downstream
happening
when like you said the bootloader leaves the DSI host in unknown
state.
Just one question below.
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e269df285136..cd842347a6b1 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1951,15 +1951,6 @@ int msm_dsi_host_modeset_init(struct
> mipi_dsi_host *host,
> return ret;
> }
>
> - ret = devm_request_irq(>dev, msm_host->irq,
> - dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> - "dsi_isr", msm_host);
> - if (ret < 0) {
> - DRM_DEV_ERROR(>dev, "failed to request IRQ%u: %d\n",
> - msm_host->irq, ret);
> - return ret;
> - }
> -
> msm_host->dev = dev;
> ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
> if (ret) {
> @@ -2413,6 +2404,16 @@ int msm_dsi_host_power_on(struct mipi_dsi_host
> *host,
> if (msm_host->disp_en_gpio)
> gpiod_set_value(msm_host->disp_en_gpio, 1);
>
> + ret = devm_request_irq(_host->pdev->dev, msm_host->irq,
> + dsi_host_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + "dsi_isr", msm_host);
> + if (ret < 0) {
> + DRM_DEV_ERROR(_host->pdev->dev, "failed to request IRQ%u:
%d\n",
> + msm_host->irq, ret);
> + return ret;
> + }
> +
> +
Do you want to move this to msm_dsi_host_enable()?
So without the controller being enabled it is still in unknown
state?
msm_dsi_host_power_on() reconfigures the host registers, so the state
is known at the end of the power_on().
Also do you want to do this after dsi0 and dsi1 are initialized to
account for
dual dsi cases?
I don't think this should matter. The host won't generate 'extra'
interrupts in such case, will it?
We have seen cases where misconfiguration has caused interrupts to
storm only
on one DSI in some cases. So yes, I would prefer this is done after
both are
configured.
I've checked. The power_on is called from dsi_mgr_bridge_pre_enable()
when both DSI hosts should be bound.
DSI being bound is enough? I thought the issue we are trying to address
is that
we need to have called msm_dsi_host_power_on() for both the hosts so
that both are
put in the known state before requesting the irq.
OR in other words move the irq_enable() to below location.
341 static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
342 {
364 ret = msm_dsi_host_power_on(host, _shared_timings[id],
is_bonded_dsi, msm_dsi->phy);
365 if (ret) {
366 pr_err("%s: power on host %d failed, %d\n", __func__, id, ret);
367 goto host_on_fail;
368 }
369
370 if (is_bonded_dsi && msm_dsi1) {
371 ret = msm_dsi_host_power_on(msm_dsi1->host,
372 _shared_timings[DSI_1], is_bonded_dsi,
msm_dsi1->phy);
373 if (ret) {
374 pr_err("%s: power on host1 failed, %d\n",
375 __func__, ret);
376 goto host1_on_fail;
377 }
378 }
< move the irq enable here >
**
> msm_host->power_on = true;
> mutex_unlock(_host->dev_mutex);
>
> @@ -2439,6 +2440,8 @@ int msm_dsi_host_power_off(struct mipi_dsi_host
> *host)
> goto unlock_ret;
> }
>
> + devm_free_irq(_host->pdev->dev, msm_host->irq, msm_host);
> +
> dsi_ctrl_config(msm_host, false, NULL, NULL);
>
> if (msm_host->disp_en_gpio)
Re: [PATCH] drm/edid: Fix drm_edid_encode_panel_id() kerneldoc warning
Hi,
On Mon, Sep 27, 2021 at 7:41 AM Douglas Anderson wrote:
>
> Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and
> not 0, 2, 3) we were getting a kernel doc warning that looked like
> this:
>
> include/drm/drm_edid.h:530: warning:
> Function parameter or member 'vend_chr_1' not described in
> 'drm_edid_encode_panel_id'
> include/drm/drm_edid.h:530: warning:
> Excess function parameter 'vend_chr_3' description in
> 'drm_edid_encode_panel_id'
>
> Fix it.
>
> Fixes: 7d1be0a09fa6 ("drm/edid: Fix EDID quirk compile error on older
> compilers")
> Reported-by: Stephen Rothwell
> Signed-off-by: Douglas Anderson
> ---
>
> include/drm/drm_edid.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Pushed with Randy's Ack to drm-misc-next:
116e5947d7bf drm/edid: Fix drm_edid_encode_panel_id() kerneldoc warning
[PATCH 2/2] drm/msm/devfreq: Add 1ms delay before clamping freq
From: Rob Clark
Add a short delay before clamping to idle frequency on active->idle
transition. It takes ~0.5ms to increase the freq again on the next
idle->active transition, so this helps avoid extra freq transitions
on workloads that bounce between CPU and GPU.
Signed-off-by: Rob Clark
---
Note that this sort of re-introduces the theoretical race solved
by [1].. but that should not be a problem with something along the
lines of [2].
[1] https://patchwork.freedesktop.org/patch/455910/?series=95111=1
[2] https://patchwork.freedesktop.org/patch/455928/?series=95119=1
drivers/gpu/drm/msm/msm_gpu.h | 7 +
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 38 +--
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 32a859307e81..2fcb6c195865 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -120,6 +120,13 @@ struct msm_gpu_devfreq {
* it is inactive.
*/
unsigned long idle_freq;
+
+ /**
+* idle_work:
+*
+* Used to delay clamping to idle freq on active->idle transition.
+*/
+ struct msm_hrtimer_work idle_work;
};
struct msm_gpu {
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index 15b64f35c0f6..36e1930ee26d 100644
--- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
+++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
@@ -96,8 +96,12 @@ static struct devfreq_dev_profile msm_devfreq_profile = {
.get_cur_freq = msm_devfreq_get_cur_freq,
};
+static void msm_devfreq_idle_work(struct kthread_work *work);
+
void msm_devfreq_init(struct msm_gpu *gpu)
{
+ struct msm_gpu_devfreq *df = >devfreq;
+
/* We need target support to do devfreq */
if (!gpu->funcs->gpu_busy)
return;
@@ -113,25 +117,27 @@ void msm_devfreq_init(struct msm_gpu *gpu)
msm_devfreq_profile.freq_table = NULL;
msm_devfreq_profile.max_state = 0;
- gpu->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
+ df->devfreq = devm_devfreq_add_device(>pdev->dev,
_devfreq_profile, DEVFREQ_GOV_SIMPLE_ONDEMAND,
NULL);
- if (IS_ERR(gpu->devfreq.devfreq)) {
+ if (IS_ERR(df->devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
- gpu->devfreq.devfreq = NULL;
+ df->devfreq = NULL;
return;
}
- devfreq_suspend_device(gpu->devfreq.devfreq);
+ devfreq_suspend_device(df->devfreq);
- gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
- gpu->devfreq.devfreq);
+ gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
df->devfreq);
if (IS_ERR(gpu->cooling)) {
DRM_DEV_ERROR(>pdev->dev,
"Couldn't register GPU cooling device\n");
gpu->cooling = NULL;
}
+
+ msm_hrtimer_work_init(>idle_work, gpu->worker,
msm_devfreq_idle_work,
+ CLOCK_MONOTONIC, HRTIMER_MODE_REL);
}
void msm_devfreq_cleanup(struct msm_gpu *gpu)
@@ -179,6 +185,11 @@ void msm_devfreq_active(struct msm_gpu *gpu)
unsigned int idle_time;
unsigned long target_freq = df->idle_freq;
+ /*
+* Cancel any pending transition to idle frequency:
+*/
+ hrtimer_cancel(>idle_work.timer);
+
/*
* Hold devfreq lock to synchronize with get_dev_status()/
* target() callbacks
@@ -209,9 +220,12 @@ void msm_devfreq_active(struct msm_gpu *gpu)
mutex_unlock(>devfreq->lock);
}
-void msm_devfreq_idle(struct msm_gpu *gpu)
+
+static void msm_devfreq_idle_work(struct kthread_work *work)
{
- struct msm_gpu_devfreq *df = >devfreq;
+ struct msm_gpu_devfreq *df = container_of(work,
+ struct msm_gpu_devfreq, idle_work.work);
+ struct msm_gpu *gpu = container_of(df, struct msm_gpu, devfreq);
unsigned long idle_freq, target_freq = 0;
/*
@@ -229,3 +243,11 @@ void msm_devfreq_idle(struct msm_gpu *gpu)
mutex_unlock(>devfreq->lock);
}
+
+void msm_devfreq_idle(struct msm_gpu *gpu)
+{
+ struct msm_gpu_devfreq *df = >devfreq;
+
+ msm_hrtimer_queue_work(>idle_work, ms_to_ktime(1),
+ HRTIMER_MODE_ABS);
+}
--
2.31.1
[PATCH 1/2] drm/msm: Add hrtimer + kthread_work helper
From: Rob Clark
Before open-coding this a 2nd time, add a helper.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 21 ++---
drivers/gpu/drm/msm/msm_drv.c| 29 +
drivers/gpu/drm/msm/msm_drv.h| 22 ++
drivers/gpu/drm/msm/msm_kms.h| 3 +--
4 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index fab09e7c6efc..27c9ae563f2f 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -116,20 +116,10 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
int crtc_idx)
trace_msm_atomic_async_commit_finish(crtc_mask);
}
-static enum hrtimer_restart msm_atomic_pending_timer(struct hrtimer *t)
-{
- struct msm_pending_timer *timer = container_of(t,
- struct msm_pending_timer, timer);
-
- kthread_queue_work(timer->worker, >work);
-
- return HRTIMER_NORESTART;
-}
-
static void msm_atomic_pending_work(struct kthread_work *work)
{
struct msm_pending_timer *timer = container_of(work,
- struct msm_pending_timer, work);
+ struct msm_pending_timer, work.work);
msm_atomic_async_commit(timer->kms, timer->crtc_idx);
}
@@ -139,8 +129,6 @@ int msm_atomic_init_pending_timer(struct msm_pending_timer
*timer,
{
timer->kms = kms;
timer->crtc_idx = crtc_idx;
- hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
- timer->timer.function = msm_atomic_pending_timer;
timer->worker = kthread_create_worker(0, "atomic-worker-%d", crtc_idx);
if (IS_ERR(timer->worker)) {
@@ -149,7 +137,10 @@ int msm_atomic_init_pending_timer(struct msm_pending_timer
*timer,
return ret;
}
sched_set_fifo(timer->worker->task);
- kthread_init_work(>work, msm_atomic_pending_work);
+
+ msm_hrtimer_work_init(>work, timer->worker,
+ msm_atomic_pending_work,
+ CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
return 0;
}
@@ -258,7 +249,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
vsync_time = kms->funcs->vsync_time(kms, async_crtc);
wakeup_time = ktime_sub(vsync_time, ms_to_ktime(1));
- hrtimer_start(>timer, wakeup_time,
+ msm_hrtimer_queue_work(>work, wakeup_time,
HRTIMER_MODE_ABS);
}
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 938765ad7109..624078b3adf2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -200,6 +200,35 @@ void msm_rmw(void __iomem *addr, u32 mask, u32 or)
msm_writel(val | or, addr);
}
+static enum hrtimer_restart msm_hrtimer_worktimer(struct hrtimer *t)
+{
+ struct msm_hrtimer_work *work = container_of(t,
+ struct msm_hrtimer_work, timer);
+
+ kthread_queue_work(work->worker, >work);
+
+ return HRTIMER_NORESTART;
+}
+
+void msm_hrtimer_queue_work(struct msm_hrtimer_work *work,
+ ktime_t wakeup_time,
+ enum hrtimer_mode mode)
+{
+ hrtimer_start(>timer, wakeup_time, mode);
+}
+
+void msm_hrtimer_work_init(struct msm_hrtimer_work *work,
+ struct kthread_worker *worker,
+ kthread_work_func_t fn,
+ clockid_t clock_id,
+ enum hrtimer_mode mode)
+{
+ hrtimer_init(>timer, clock_id, mode);
+ work->timer.function = msm_hrtimer_worktimer;
+ work->worker = worker;
+ kthread_init_work(>work, fn);
+}
+
static irqreturn_t msm_irq(int irq, void *arg)
{
struct drm_device *dev = arg;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 8b005d1ac899..de062450add4 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -488,6 +488,28 @@ void msm_writel(u32 data, void __iomem *addr);
u32 msm_readl(const void __iomem *addr);
void msm_rmw(void __iomem *addr, u32 mask, u32 or);
+/**
+ * struct msm_hrtimer_work - a helper to combine an hrtimer with kthread_work
+ *
+ * @timer: hrtimer to control when the kthread work is triggered
+ * @work: the kthread work
+ * @worker: the kthread worker the work will be scheduled on
+ */
+struct msm_hrtimer_work {
+ struct hrtimer timer;
+ struct kthread_work work;
+ struct kthread_worker *worker;
+};
+
+void msm_hrtimer_queue_work(struct msm_hrtimer_work *work,
+ ktime_t wakeup_time,
+ enum hrtimer_mode mode);
+void msm_hrtimer_work_init(struct msm_hrtimer_work *work,
+ struct kthread_worker *worker,
+
Re: [PATCH v2 1/3] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
On Mon, Sep 27, 2021 at 10:59:42AM -0700, Brian Norris wrote:
> In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
Hmm, sorry to reply to my own patch so quickly, but after a bit more
testing I'm finding we still have yet another problem here -- that
suspend/resume does not work. For suspend/resume,
drm_mode_config_helper_{suspend,resume}() are expecting to only do
teardown/setup via disable()/enable() -- there is no re-bind() (which
makes sense). But the DSI hardware state may be lost, so the resume-time
enable() may find the panel initialization timing out yet again.
Possible solutions:
(1) I can add PM suspend()/resume() operations just to call
dw_mipi_dsi_rockchip_config().
(2) Switch back to using mode_set() for HW configuration, like the
downstream/BSP driver does (and the initial versions Rockchip and
later Heiko were working on did the same), since that's always
called at the right time before both panel and encoder enable().
That also happens to be where some other DSI drivers [1] do similar
init.
Have we been avoiding (2) just because that doesn't really match the
intended purpose of the callback? I can't find any cleaner callback for
this at the moment, and I'd rather not try to introduce entirely new drm
helper callbacks just for this particularly-unfriendly sequence.
I have a patch written for option (1), and may send a v3 soon to include
that as well (because that's also a regression from the same commit).
Brian
[1] e.g., drivers/gpu/drm/bridge/nwl-dsi.c
Re: [PATCH 1/3] drm/bridge: Add a function to abstract away panels
On Mon, Sep 27, 2021 at 09:43:44PM +0200, Maxime Ripard wrote:
> On Thu, Sep 23, 2021 at 03:29:37AM +0300, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > Thank you for the patch.
> >
> > I know this has already been merged, but I have a question.
> >
> > On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
> > > Display drivers so far need to have a lot of boilerplate to first
> > > retrieve either the panel or bridge that they are connected to using
> > > drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
> > > functions or create a drm panel bridge through drm_panel_bridge_add.
> > >
> > > In order to reduce the boilerplate and hopefully create a path of least
> > > resistance towards using the DRM panel bridge layer, let's create the
> > > function devm_drm_of_get_next to reduce that boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/drm_bridge.c | 42
> > > drivers/gpu/drm/drm_of.c | 3 +++
> > > include/drm/drm_bridge.h | 2 ++
> > > 3 files changed, 43 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index a8ed66751c2d..10ddca4638b0 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -28,6 +28,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #include "drm_crtc_internal.h"
> > > @@ -51,10 +52,8 @@
> > > *
> > > * Display drivers are responsible for linking encoders with the first
> > > bridge
> > > * in the chains. This is done by acquiring the appropriate bridge with
> > > - * of_drm_find_bridge() or drm_of_find_panel_or_bridge(), or creating it
> > > for a
> > > - * panel with drm_panel_bridge_add_typed() (or the managed version
> > > - * devm_drm_panel_bridge_add_typed()). Once acquired, the bridge shall be
> > > - * attached to the encoder with a call to drm_bridge_attach().
> > > + * devm_drm_of_get_bridge(). Once acquired, the bridge shall be attached
> > > to the
> > > + * encoder with a call to drm_bridge_attach().
> > > *
> > > * Bridges are responsible for linking themselves with the next bridge
> > > in the
> > > * chain, if any. This is done the same way as for encoders, with the
> > > call to
> > > @@ -1233,6 +1232,41 @@ struct drm_bridge *of_drm_find_bridge(struct
> > > device_node *np)
> > > return NULL;
> > > }
> > > EXPORT_SYMBOL(of_drm_find_bridge);
> > > +
> > > +/**
> > > + * devm_drm_of_get_bridge - Return next bridge in the chain
> > > + * @dev: device to tie the bridge lifetime to
> > > + * @np: device tree node containing encoder output ports
> > > + * @port: port in the device tree node
> > > + * @endpoint: endpoint in the device tree node
> > > + *
> > > + * Given a DT node's port and endpoint number, finds the connected node
> > > + * and returns the associated bridge if any, or creates and returns a
> > > + * drm panel bridge instance if a panel is connected.
> > > + *
> > > + * Returns a pointer to the bridge if successful, or an error pointer
> > > + * otherwise.
> > > + */
> > > +struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
> > > + struct device_node *np,
> > > + unsigned int port,
> > > + unsigned int endpoint)
> > > +{
> > > + struct drm_bridge *bridge;
> > > + struct drm_panel *panel;
> > > + int ret;
> > > +
> > > + ret = drm_of_find_panel_or_bridge(np, port, endpoint,
> > > + , );
> > > + if (ret)
> > > + return ERR_PTR(ret);
> > > +
> > > + if (panel)
> > > + bridge = devm_drm_panel_bridge_add(dev, panel);
> > > +
> > > + return bridge;
> >
> > I really like the idea, I've wanted to do something like this for a long
> > time. I however wonder if this is the best approach, or if we could get
> > the panel core to register the bridge itself. The part that bothers me
> > here is the assymetry in the lifetime of the bridges, the returned
> > pointer is either looked up or allocated.
> >
> > Bridge lifetime is such a mess that it may not make a big difference,
> > but eventually we'll have to address that problem globally.
>
> We can't have Rust soon enough :)
:-) Jokes aside, Rust or C, this would need a design overhaul as a first
step.
> Does it really matter though? I thought the bridges couldn't be unloaded
> from a DRM device anyway, so for all practical purposes this will be
> removed at around the same time: when the whole DRM device is going to
> be teared down?
Try to unbind a bridge device from its driver in sysfs, and it won't be
pretty.
--
Regards,
Laurent Pinchart
[pull] amdgpu, amdkfd, radeon drm-next-5.16
Hi Dave, Daniel, New stuff for 5.16. The following changes since commit 8f0284f190e6a0aa09015090568c03f18288231a: Merge tag 'amd-drm-next-5.15-2021-08-27' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-08-30 09:06:03 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.16-2021-09-27 for you to fetch changes up to 2485e2753ec896b169526e3ef7988589d1c458f5: drm/amdgpu: make soc15_common_ip_funcs static (2021-09-23 16:35:27 -0400) amd-drm-next-5.16-2021-09-27: amdgpu: - RAS improvements - BACO fixes - Yellow Carp updates - Misc code cleanups - Initial DP 2.0 support - VCN priority handling - Cyan Skillfish updates - Rework IB handling for multimedia engine tests - Backlight fixes - DCN 3.1 power saving improvements - Runtime PM fixes - Modifier support for DCC image stores for gfx 10.3 - Hotplug fixes - Clean up stack related warnings in display code - DP alt mode fixes - Display rework for better handling FP code - Debugfs fixes amdkfd: - SVM fixes - DMA map fixes radeon: - AGP fix Aaron Liu (1): drm/amd/display: setup system context for APUs Alex Deucher (4): drm/amdgpu: add some additional RDNA2 PCI IDs drm/amdgpu/display: add a proper license to dc_link_dp.c MAINTAINERS: fix up entry for AMD Powerplay drm/amdgpu: make soc15_common_ip_funcs static Alex Sierra (1): drm/amdkfd: drop process ref count when xnack disable Alvin Lee (1): drm/amd/display: Update swizzle mode enums Andrey Grodzovsky (4): drm/amd/display: Fix crash on device remove/driver unload drm/amdgpu: Fix crash on device remove/driver unload drm/amdgpu: Fix MMIO access page fault drm/amdgpu: Fix resume failures when device is gone Angus Wang (1): drm/amd/display: cleanup idents after a revert Anson Jacob (5): drm/amd/display: Fix memory leak reported by coverity drm/amd/display: dc_assert_fp_enabled assert only if FPU is not enabled drm/amd/display: Fix false BAD_FREE warning from Coverity drm/amd/display: Fix multiple memory leaks reported by coverity drm/amd/display: Revert "Directly retrain link from debugfs" Anthony Koo (5): drm/amd/display: [FW Promotion] Release 0.0.80 drm/amd/display: [FW Promotion] Release 0.0.81 drm/amd/display: [FW Promotion] Release 0.0.82 drm/amd/display: [FW Promotion] Release 0.0.83 drm/amd/display: [FW Promotion] Release 0.0.84 Aric Cyr (5): drm/amd/display: 3.2.150 drm/amd/display: 3.2.151 drm/amd/display: 3.2.152 drm/amd/display: 3.2.153 drm/amd/display: 3.2.154 Arnd Bergmann (1): drm/amd/display: fix empty debug macros Aurabindo Pillai (2): drm/amd/display: Add emulated sink support for updating FS drm/amd/display: Add flag to detect dpms force off during HPD Candice Li (7): drm/amd/amdgpu: consolidate PSP TA unload function drm/amd/amdgpu: add mpio to ras block drm/amdgpu: Create common PSP TA load function drm/amdgpu: Unify PSP TA context drm/amdgpu: Conform ASD header/loading to generic TA systems drm/amdgpu: Update PSP TA unload function drm/amdgpu: Remove all code paths under the EAGAIN path in RAS late init Christian König (2): drm/amdgpu: fix use after free during BO move drm/amdgpu: remove unused amdgpu_bo_validate Colin Ian King (7): drm/amdgpu/swsmu: fix spelling mistake "minimun" -> "minimum" drm/amd/display: fix spelling mistake "alidation" -> "validation" drm/amd/display: Fix unused initialization of pointer sink drm/amdgpu: clean up inconsistent indenting drm/amdgpu: sdma: clean up identation drm/radeon/ci_dpm: Remove redundant initialization of variables hi_sidd, lo_sidd drm/radeon: make array encoded_lanes static Dale Zhao (1): drm/amd/display: Refine condition of cursor visibility for pipe-split Eric Yang (1): drm/amd/display: Add periodic detection when zstate is enabled Ernst Sjöstrand (1): drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10 Evan Quan (2): drm/amdgpu: reenable BACO support for 699F:C7 polaris12 SKU drm/amd/pm: fix runpm hang when amdgpu loaded prior to sound driver Fangzhi Zuo (6): drm/amd/display: Add DP 2.0 Audio Package Generator drm/amd/display: Add DP 2.0 HPO Stream Encoder drm/amd/display: Add DP 2.0 HPO Link Encoder drm/amd/display: Add DP 2.0 DCCG drm/amd/display: Add DP 2.0 BIOS and DMUB Support drm/amd/display: Add DP 2.0 SST DC Support Felix Kuehling (1): drm/amdkfd: make needs_pcie_atomics FW-version dependent Guchun Chen (2): drm/amdgpu: stop scheduler when calling hw_fini (v2) drm/amdgpu: move amdgpu_virt_release_full_gpu to fini_early stage Guo, Bing (1):
Re: [PATCH] drm/msm/submit: fix overflow check on 64-bit architectures
Quoting Arnd Bergmann (2021-09-27 04:36:23)
> From: Arnd Bergmann
>
> The overflow check does causes a warning from clang-14 when 'sz' is a type
> that is smaller than size_t:
>
> drivers/gpu/drm/msm/msm_gem_submit.c:217:10: error: result of comparison of
> constant 18446744073709551615 with expression of type 'unsigned int' is
> always false [-Werror,-Wtautological-constant-out-of-range-compare]
> if (sz == SIZE_MAX) {
>
> Change the type accordingly.
>
> Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking
> bos")
> Signed-off-by: Arnd Bergmann
> ---
Reviewed-by: Stephen Boyd
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
Hi Yunfei, > This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1] > and > "Mediatek MT8192 clock support"[2]. > > 1: Multi hardware decode is based on stateless decoder, MT8183 is the first > time > to add stateless decoder. Otherwise it will cause conflict. This patch will be > accepted in 5.15[1]. Just a few basic questions. What kind of "conflict" are you expecting here? Are you referring to kernel "5.15" here? Probably not. If yes, then that sounds strange to me considering our current kernel uprev plans and current kernel used for MT8183. > 2: The definition of decoder clocks are in mt8192-clk.h, this patch already > in clk tree[2]. > > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826 This link seems to be no longer available. > [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next=f35f1a23e0e12e3173e9e9dedbc150d139027189
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
Hi Ezequiel, Thank you for reviewing these series from Yunfei! This series is one of the main obstacles for us at the moment for MTK so please continue to help & support reviewing this series. > > According to google's suggestion, it's better not to use v4l2 async > > also. > > Hum? I haven't seen such objection on the mailing list. Maybe coming from Tzung-Bi? Yunfei, please let us know. Steve
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
> > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826 > This link seems to be no longer available. It is probably because the default state is "Action Required", and this series was accepted recently afterwards. I can see the series with the below link. https://patchwork.linuxtv.org/project/linux-media/list/?series=5826=* Sorry for the confusion. Steve
Re: [PATCH v3.1] dt-bindings: display: renesas,du: Provide bindings for r8a779a0
On Thu, 23 Sep 2021 14:01:38 +0100, Kieran Bingham wrote: > From: Kieran Bingham > > Extend the Renesas DU display bindings to support the r8a779a0 V3U. > > Reviewed-by: Laurent Pinchart > Reviewed-by: Geert Uytterhoeven > Signed-off-by: Kieran Bingham > > --- > v2: > - Collected Laurent's tag > - Remove clock-names requirement > - Specify only a single clock > > v3: > - Use clocknames: 'du.0' instead of 'du' to remain consistent > > v3.1: > - Require clock-names > - Collect Geert's tag > > .../bindings/display/renesas,du.yaml | 51 +++ > 1 file changed, 51 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
On Mon, Sep 27, 2021 at 10:42 PM Bjorn Andersson wrote: > On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote: > > On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson > > wrote: > > > > An easier option might be to find a way to build QCOM_SCM without > > RESET_CONTROLLER for compile testing purposes. I don't know > > what would break from that. > > > > Afaict the reset API is properly stubbed and RESET_CONTROLLER is a bool, > so I think we can simply drop the "select" and the kernel will still > compile fine in all combinations. > > When it comes to runtime, we currently select RESET_CONTROLLER from the > Qualcomm common clocks. If that is dropped (why would it...) it seems > possible to build a custom kernel for msm8916 that we can boot and miss > the stubbed out "mss restart" reset line from the SCM. > > > So, let's just drop the select RESET_CONTROLLER from SCM for now. Ok, I've made that change locally, giving it more time on the randconfig build box now. Arnd
Re: [PATCH v2 7/9] vfio/ccw: Remove private->mdev
On Mon, 2021-09-27 at 09:32 -0300, Jason Gunthorpe wrote: > On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote: > > On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote: > > > Having a mdev pointer floating about in addition to a struct > > > vfio_device > > > is confusing. It is only used for three things: > > > > > > - Getting the mdev 'struct device *' - this is the same as > > > private->vdev.dev > > > > > > - Printing the uuid of the mdev in logging. The uuid is also the > > > dev_name > > > of the mdev so this is the same string as > > > dev_name(private->vdev.dev) > > > > > > - A weird attempt to fence the vfio_ccw_sch_io_todo() work. This > > > work > > > is > > > only queued during states IDLE/PROCESSING/PENDING and flushed > > > when > > > entering CLOSED. Thus the work already cannot run when the mdev > > > is > > > NULL. > > > Remove it. > > > > > > Signed-off-by: Jason Gunthorpe > > > drivers/s390/cio/vfio_ccw_drv.c | 6 ++-- > > > drivers/s390/cio/vfio_ccw_fsm.c | 48 + > > > > > > drivers/s390/cio/vfio_ccw_ops.c | 16 -- > > > drivers/s390/cio/vfio_ccw_private.h | 2 -- > > > include/linux/mdev.h| 4 --- > > > 5 files changed, 30 insertions(+), 46 deletions(-) > > > > I like this patch. Unfortunately it depends on the removal of a > > hunk in > > patch 4, which sets the FSM state to different values based on > > whether > > private->mdev is NULL or not, so can't go on its own. Need to spend > > more time thinking about that patch. > > The FSM patch is important, really what is happening is the FSM logic > takes on the roles that was being split all over the place with other > logic, like this mdev stuff. To make that work we need a FSM that > makes sense.. No argument from me about that. My point is that I could consume this patch easier than the FSM patch, and need to get back to that one. Eric > > Jason
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote: > On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson > wrote: > > On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote: > > > From: Arnd Bergmann > > > > > > - To avoid a circular dependency chain involving RESET_CONTROLLER > > >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in > > >the latter one to 'select'. > > > > Can you please help me understand why this is part of the same patch? > > This can be done as a preparatory patch if we decide to do it this way, > for the review it seemed better to spell out that this is required. > > I still hope that we can avoid adding another 'select RESET_CONTROLLER' > if someone can figure out what to do instead. > Okay, thanks. > The problem here is that QCOM_SCM selects RESET_CONTROLLER, > and turning that into 'depends on' would in turn mean that any driver that > wants to select QCOM_SCM would have to have the same RESET_CONTROLLER > dependency. > Right, and that will just be another thing we'll get wrong across the tree. > An easier option might be to find a way to build QCOM_SCM without > RESET_CONTROLLER for compile testing purposes. I don't know > what would break from that. > Afaict the reset API is properly stubbed and RESET_CONTROLLER is a bool, so I think we can simply drop the "select" and the kernel will still compile fine in all combinations. When it comes to runtime, we currently select RESET_CONTROLLER from the Qualcomm common clocks. If that is dropped (why would it...) it seems possible to build a custom kernel for msm8916 that we can boot and miss the stubbed out "mss restart" reset line from the SCM. So, let's just drop the select RESET_CONTROLLER from SCM for now. Regards, Bjorn
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson wrote: > On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > - To avoid a circular dependency chain involving RESET_CONTROLLER > >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in > >the latter one to 'select'. > > Can you please help me understand why this is part of the same patch? This can be done as a preparatory patch if we decide to do it this way, for the review it seemed better to spell out that this is required. I still hope that we can avoid adding another 'select RESET_CONTROLLER' if someone can figure out what to do instead. The problem here is that QCOM_SCM selects RESET_CONTROLLER, and turning that into 'depends on' would in turn mean that any driver that wants to select QCOM_SCM would have to have the same RESET_CONTROLLER dependency. An easier option might be to find a way to build QCOM_SCM without RESET_CONTROLLER for compile testing purposes. I don't know what would break from that. Arnd
[PATCH 3/3] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.
So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9b1ac02b0263..1e20c607408c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -456,11 +456,17 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
}
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will
always use the VESA
+* interface. This means that there's quite a number of panels out
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise
support for both
+* interfaces, the VESA backlight interface will stop working once
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to
detect Intel's
+* backlight interface at all. This means that the only sensible way
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
*/
if (try_intel_interface &&
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
controls\n");
--
2.31.1
[PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.
Note that for the DRM helpers for this, we change some behavior by starting
to hide all backlights that require PWM controls by default, and require
that the driver pass our new DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM flag to
drm_edp_backlight_supported(). The primary reason for doing this is that
panels requiring PWM in addition to DPCD controls will require additional
implementation on the driver's side, as there's no way for us to handle
PWM controls from the helpers in a driver-independent way.
Note however that we still don't enable using this by default when it's not
needed, primarily because I haven't yet had a chance to confirm if it's
safe to do this on the one machine in Intel's CI that had an issue with
this: samus-fi-bdw. I have done basic testing of this on other machines
though, by manually patching i915 to force it into PWM-only mode on some of
my laptops.
Signed-off-by: Lyude Paul
Cc: Rajeev Nandan
Cc: Doug Anderson
Cc: Satadru Pramanik
---
drivers/gpu/drm/drm_dp_helper.c | 102 ++
.../drm/i915/display/intel_dp_aux_backlight.c | 51 ++---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +-
include/drm/drm_dp_helper.h | 46
4 files changed, 146 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..a1cf849fc6ed 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3163,7 +3163,10 @@ EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
* @level: The brightness level to set
*
* Sets the brightness level of an eDP panel's backlight. Note that the
panel's backlight must
- * already have been enabled by the driver by calling
drm_edp_backlight_enable().
+ * already have been enabled by the driver by calling
drm_edp_backlight_enable(). Note that if the
+ * panel in question requires the PWM pin be used to control brightness levels
(e.g.
+ * _edp_backlight_info.aux_set is %false), then this function becomes a
no-op and it is up to
+ * the driver to handle adjusting the brightness levels.
*
* Returns: %0 on success, negative error code on failure
*/
@@ -3173,6 +3176,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux,
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
+ /* The panel uses PWM for controlling brightness levels */
+ if (!bl->aux_set)
+ return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3234,11 +3241,8 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
* restoring any important backlight state such as the given backlight level,
the brightness byte
* count, backlight frequency, etc.
*
- * Note that certain panels, while supporting brightness level controls over
DPCD, may not support
- * having their backlights enabled via the standard
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
- * _edp_backlight_info.aux_enable will be set to %false, this function
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must
perform the required
- * implementation specific step for enabling the backlight after calling this
function.
+ * Drivers supporting %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM are expected to enable
the panel backlight
+ * and/or program the panel's brightness level after calling this function.
*
* Returns: %0 on success, negative error code on failure.
*/
@@ -3246,7 +3250,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
const u16 level)
{
int ret;
- u8 dpcd_buf, new_dpcd_buf;
+ u8 dpcd_buf, new_dpcd_buf, new_mode;
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
_buf);
if (ret != 1) {
@@ -3256,10 +3260,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
}
new_dpcd_buf = dpcd_buf;
+ if (bl->aux_set)
+ new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ else
+ new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
- if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+ if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ new_dpcd_buf |= new_mode;
if (bl->pwmgen_bit_count) {
[PATCH 1/3] drm/i915: Add support for panels with VESA backlights with PWM enable/disable
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.
For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
enable/disable")
Cc: # v5.12+
---
.../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 569d17b4d00f..594fdc7453ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+ if (!panel->backlight.edp.vesa.info.aux_enable)
+ panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
+
panel->backlight.pwm_level_max);
+
drm_edp_backlight_enable(_dp->aux,
>backlight.edp.vesa.info, level);
}
@@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
drm_edp_backlight_disable(_dp->aux,
>backlight.edp.vesa.info);
+
+ if (!panel->backlight.edp.vesa.info.aux_enable)
+ panel->backlight.pwm_funcs->disable(old_conn_state,
+
intel_backlight_invert_pwm_level(connector, 0));
}
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
*connector, enum pipe pipe)
@@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
intel_connector *connector,
if (ret < 0)
return ret;
+ if (!panel->backlight.edp.vesa.info.aux_enable) {
+ ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+ if (ret < 0) {
+ drm_err(>drm,
+ "Failed to setup PWM backlight controls for eDP
backlight: %d\n",
+ ret);
+ return ret;
+ }
+ }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- /* TODO: We currently only support AUX only backlight configurations,
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time,
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
- if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
- drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+ if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
}
--
2.31.1
[PATCH 0/3] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
When I originally moved all of the VESA backlight code in i915 into DRM helpers, one of the things I didn't have the hardware or time for testing was machines that used a combination of PWM and DPCD in order to control their backlights. This has since then caused some breakages and resulted in us disabling DPCD backlight support on such machines. This works fine, unless you have a machine that actually needs this functionality for backlight controls to work at all. Additionally, we will need to support PWM for when we start adding support for VESA's product (as in the product of multiplication) control mode for better brightness ranges. So - let's finally finish up implementing basic support for these types of backlights to solve these problems in our DP helpers, along with implementing support for this in i915. And since digging into this issue solved the last questions we really had about probing backlights in i915 for the most part, let's update some of the comments around that as well! Lyude Paul (3): drm/i915: Add support for panels with VESA backlights with PWM enable/disable drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs() drivers/gpu/drm/drm_dp_helper.c | 102 ++ .../drm/i915/display/intel_dp_aux_backlight.c | 81 ++ drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +- include/drm/drm_dp_helper.h | 46 4 files changed, 170 insertions(+), 61 deletions(-) -- 2.31.1
Re: [PATCH v2 1/3] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
On Mon, Sep 27, 2021 at 12:18 PM Tom Hebb wrote: > Reviewed-by: Thomas Hebb Thanks! > Thank you for catching this, and sorry that my original fix broke things. > There had actually been a report of this breakage from my patch, but I > missed that email until it had already been merged and then didn't have > time to follow up on it. Totally my bad. No worries. It was a 1 step forward, 1 step backward kind of a thing anyway -- things were broken in many cases before your patch too (with very similar-looking symptoms) -- so the net result is still good, having both issues fixed. I'm not sure how that ideally should have been handled [1], but it's totally fair to not have time to follow up on everything. At the worst, we could have reverted things; but again, I'm pretty sure things were broken just as well without your fix, just with a different root cause. Regards, Brian [1] Don't accept (or, revert?) your bugfix until what may or may not have been a regression is fixed? I'm not sure.
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote: > From: Arnd Bergmann > > Now that SCM can be a loadable module, we have to add another > dependency to avoid link failures when ipa or adreno-gpu are > built-in: > > aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': > ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available' > > ld.lld: error: undefined symbol: qcom_scm_is_available > >>> referenced by adreno_gpu.c > >>> gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in > >>> archive drivers/built-in.a > > This can happen when CONFIG_ARCH_QCOM is disabled and we don't select > QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd > use a similar dependency here to what we have for QCOM_RPROC_COMMON, > but that causes dependency loops from other things selecting QCOM_SCM. > > This appears to be an endless problem, so try something different this > time: > > - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' >but that is simply selected by all of its users > > - All the stubs in include/linux/qcom_scm.h can go away > > - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to >allow compile-testing QCOM_SCM on all architectures. > > - To avoid a circular dependency chain involving RESET_CONTROLLER >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in >the latter one to 'select'. Can you please help me understand why this is part of the same patch? > > The last bit is rather annoying, as drivers should generally never > 'select' another subsystem, and about half the users of the reset > controller interface do this anyway. > > Nevertheless, this version seems to pass all my randconfig tests > and is more robust than any of the prior versions. > > Comments? > I like it! It's less confusing than the current scheme, so should be easier to get right. And I like the fact that we don't need the stubs anymore. @John, could you please have a look at this as well, wrt GKI. Regards, Bjorn > Signed-off-by: Arnd Bergmann > --- > drivers/firmware/Kconfig| 4 +- > drivers/gpu/drm/msm/Kconfig | 4 +- > drivers/iommu/Kconfig | 2 +- > drivers/media/platform/Kconfig | 2 +- > drivers/mmc/host/Kconfig| 2 +- > drivers/net/ipa/Kconfig | 1 + > drivers/net/wireless/ath/ath10k/Kconfig | 2 +- > drivers/pinctrl/qcom/Kconfig| 3 +- > drivers/pinctrl/sunxi/Kconfig | 6 +-- > include/linux/arm-smccc.h | 10 > include/linux/qcom_scm.h| 71 - > 11 files changed, 23 insertions(+), 84 deletions(-) > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > index 220a58cf0a44..f7dd82ef0b9c 100644 > --- a/drivers/firmware/Kconfig > +++ b/drivers/firmware/Kconfig > @@ -203,9 +203,7 @@ config INTEL_STRATIX10_RSU > Say Y here if you want Intel RSU support. > > config QCOM_SCM > - tristate "Qcom SCM driver" > - depends on ARM || ARM64 > - depends on HAVE_ARM_SMCCC > + tristate > select RESET_CONTROLLER > > config QCOM_SCM_DOWNLOAD_MODE_DEFAULT > diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig > index e9c6af78b1d7..3ddf739a6f9b 100644 > --- a/drivers/gpu/drm/msm/Kconfig > +++ b/drivers/gpu/drm/msm/Kconfig > @@ -17,7 +17,7 @@ config DRM_MSM > select DRM_SCHED > select SHMEM > select TMPFS > - select QCOM_SCM if ARCH_QCOM > + select QCOM_SCM > select WANT_DEV_COREDUMP > select SND_SOC_HDMI_CODEC if SND_SOC > select SYNC_FILE > @@ -55,7 +55,7 @@ config DRM_MSM_GPU_SUDO > > config DRM_MSM_HDMI_HDCP > bool "Enable HDMI HDCP support in MSM DRM driver" > - depends on DRM_MSM && QCOM_SCM > + depends on DRM_MSM > default y > help > Choose this option to enable HDCP state machine > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 124c41adeca1..989c83acbfee 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -308,7 +308,7 @@ config APPLE_DART > config ARM_SMMU > tristate "ARM Ltd. System MMU (SMMU) Support" > depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y > + select QCOM_SCM > select IOMMU_API > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU if ARM > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 157c924686e4..80321e03809a 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -565,7 +565,7 @@ config VIDEO_QCOM_VENUS > depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM > depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST > select QCOM_MDT_LOADER if ARCH_QCOM > - select QCOM_SCM if ARCH_QCOM > + select QCOM_SCM >
Re: [PATCH 1/3] drm/bridge: Add a function to abstract away panels
On Thu, Sep 23, 2021 at 03:29:37AM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> I know this has already been merged, but I have a question.
>
> On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
> > Display drivers so far need to have a lot of boilerplate to first
> > retrieve either the panel or bridge that they are connected to using
> > drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
> > functions or create a drm panel bridge through drm_panel_bridge_add.
> >
> > In order to reduce the boilerplate and hopefully create a path of least
> > resistance towards using the DRM panel bridge layer, let's create the
> > function devm_drm_of_get_next to reduce that boilerplate.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/drm_bridge.c | 42
> > drivers/gpu/drm/drm_of.c | 3 +++
> > include/drm/drm_bridge.h | 2 ++
> > 3 files changed, 43 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index a8ed66751c2d..10ddca4638b0 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "drm_crtc_internal.h"
> > @@ -51,10 +52,8 @@
> > *
> > * Display drivers are responsible for linking encoders with the first
> > bridge
> > * in the chains. This is done by acquiring the appropriate bridge with
> > - * of_drm_find_bridge() or drm_of_find_panel_or_bridge(), or creating it
> > for a
> > - * panel with drm_panel_bridge_add_typed() (or the managed version
> > - * devm_drm_panel_bridge_add_typed()). Once acquired, the bridge shall be
> > - * attached to the encoder with a call to drm_bridge_attach().
> > + * devm_drm_of_get_bridge(). Once acquired, the bridge shall be attached
> > to the
> > + * encoder with a call to drm_bridge_attach().
> > *
> > * Bridges are responsible for linking themselves with the next bridge in
> > the
> > * chain, if any. This is done the same way as for encoders, with the call
> > to
> > @@ -1233,6 +1232,41 @@ struct drm_bridge *of_drm_find_bridge(struct
> > device_node *np)
> > return NULL;
> > }
> > EXPORT_SYMBOL(of_drm_find_bridge);
> > +
> > +/**
> > + * devm_drm_of_get_bridge - Return next bridge in the chain
> > + * @dev: device to tie the bridge lifetime to
> > + * @np: device tree node containing encoder output ports
> > + * @port: port in the device tree node
> > + * @endpoint: endpoint in the device tree node
> > + *
> > + * Given a DT node's port and endpoint number, finds the connected node
> > + * and returns the associated bridge if any, or creates and returns a
> > + * drm panel bridge instance if a panel is connected.
> > + *
> > + * Returns a pointer to the bridge if successful, or an error pointer
> > + * otherwise.
> > + */
> > +struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
> > + struct device_node *np,
> > + unsigned int port,
> > + unsigned int endpoint)
> > +{
> > + struct drm_bridge *bridge;
> > + struct drm_panel *panel;
> > + int ret;
> > +
> > + ret = drm_of_find_panel_or_bridge(np, port, endpoint,
> > + , );
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + if (panel)
> > + bridge = devm_drm_panel_bridge_add(dev, panel);
> > +
> > + return bridge;
>
> I really like the idea, I've wanted to do something like this for a long
> time. I however wonder if this is the best approach, or if we could get
> the panel core to register the bridge itself. The part that bothers me
> here is the assymetry in the lifetime of the bridges, the returned
> pointer is either looked up or allocated.
>
> Bridge lifetime is such a mess that it may not make a big difference,
> but eventually we'll have to address that problem globally.
We can't have Rust soon enough :)
Does it really matter though? I thought the bridges couldn't be unloaded
from a DRM device anyway, so for all practical purposes this will be
removed at around the same time: when the whole DRM device is going to
be teared down?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH] gpu: amd: replace open-coded offsetof() with builtin
Applied. Thanks! Alex On Mon, Sep 27, 2021 at 8:21 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > The two AMD drivers have their own custom offsetof() implementation > that now triggers a warning with recent versions of clang: > > drivers/gpu/drm/radeon/radeon_atombios.c:133:14: error: performing pointer > subtraction with a null pointer has undefined behavior > [-Werror,-Wnull-pointer-subtraction] > > Change all the instances to use the normal offsetof() provided > by the kernel that does not have this problem. > > Signed-off-by: Arnd Bergmann > --- > drivers/gpu/drm/amd/display/dc/bios/command_table2.c | 4 +--- > drivers/gpu/drm/amd/include/atombios.h| 2 +- > drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h | 4 ++-- > drivers/gpu/drm/radeon/atombios.h | 2 +- > 4 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c > b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c > index f1f672a997d7..4f37be727332 100644 > --- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c > +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c > @@ -44,9 +44,7 @@ > bp->base.ctx->logger > > #define GET_INDEX_INTO_MASTER_TABLE(MasterOrData, FieldName)\ > - (((char *)(&((\ > - struct atom_master_list_of_##MasterOrData##_functions_v2_1 > *)0)\ > - ->FieldName)-(char *)0)/sizeof(uint16_t)) > + (offsetof(struct atom_master_list_of_##MasterOrData##_functions_v2_1, > FieldName) / sizeof(uint16_t)) > > #define EXEC_BIOS_CMD_TABLE(fname, params)\ > (amdgpu_atom_execute_table(((struct amdgpu_device > *)bp->base.ctx->driver_context)->mode_info.atom_context, \ > diff --git a/drivers/gpu/drm/amd/include/atombios.h > b/drivers/gpu/drm/amd/include/atombios.h > index 6a505d1b82a5..da895d1f3b4f 100644 > --- a/drivers/gpu/drm/amd/include/atombios.h > +++ b/drivers/gpu/drm/amd/include/atombios.h > @@ -7148,7 +7148,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 > #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) > (((static_cast(TABLE_HEADER_OFFSET))->ucTableFormatRevision > )&0x3F) > #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) > (((static_cast(TABLE_HEADER_OFFSET))->ucTableContentRevision)&0x3F) > #else // not __cplusplus > -#define GetIndexIntoMasterTable(MasterOrData, FieldName) > (((char*)(&((ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES*)0)->FieldName)-(char*)0)/sizeof(USHORT)) > +#define GetIndexIntoMasterTable(MasterOrData, FieldName) > (offsetof(ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES, FieldName) / > sizeof(USHORT)) > > #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) > ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableFormatRevision)&0x3F) > #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) > ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableContentRevision)&0x3F) > diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h > b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h > index b7e2651b570b..2fc1733bcdcf 100644 > --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h > +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h > @@ -29,9 +29,9 @@ > typedef enum atom_smu9_syspll0_clock_id BIOS_CLKID; > > #define GetIndexIntoMasterCmdTable(FieldName) \ > - (((char*)(&((struct > atom_master_list_of_command_functions_v2_1*)0)->FieldName)-(char*)0)/sizeof(uint16_t)) > + (offsetof(struct atom_master_list_of_command_functions_v2_1, > FieldName) / sizeof(uint16_t)) > #define GetIndexIntoMasterDataTable(FieldName) \ > - (((char*)(&((struct > atom_master_list_of_data_tables_v2_1*)0)->FieldName)-(char*)0)/sizeof(uint16_t)) > + (offsetof(struct atom_master_list_of_data_tables_v2_1, FieldName) / > sizeof(uint16_t)) > > #define PP_ATOMFWCTRL_MAX_VOLTAGE_ENTRIES 32 > > diff --git a/drivers/gpu/drm/radeon/atombios.h > b/drivers/gpu/drm/radeon/atombios.h > index 83e8b8547f9b..bd5dc09e860f 100644 > --- a/drivers/gpu/drm/radeon/atombios.h > +++ b/drivers/gpu/drm/radeon/atombios.h > @@ -5983,7 +5983,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 > #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) > (((static_cast(TABLE_HEADER_OFFSET))->ucTableFormatRevision > )&0x3F) > #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) > (((static_cast(TABLE_HEADER_OFFSET))->ucTableContentRevision)&0x3F) > #else // not __cplusplus > -#defineGetIndexIntoMasterTable(MasterOrData, FieldName) > (((char*)(&((ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES*)0)->FieldName)-(char*)0)/sizeof(USHORT)) > +#defineGetIndexIntoMasterTable(MasterOrData, FieldName) > (offsetof(ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES, > FieldName)/sizeof(USHORT)) > > #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) >
Re: [PATCH] drm/amdkfd: fix resource_size.cocci warnings
Applied. Thanks! Alex On Sun, Sep 26, 2021 at 3:10 PM Amos Jianjun Kong wrote: > > On Sun, Sep 26, 2021 at 3:17 PM Yang Li wrote: >> >> Use resource_size function on resource object >> instead of explicit computation. >> >> Clean up coccicheck warning: >> ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:905:10-13: ERROR: Missing >> resource_size with res >> >> Reported-by: Abaci Robot >> Signed-off-by: Yang Li >> --- >> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c >> b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c >> index 4a16e3c..f53e17a 100644 >> --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c >> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c >> @@ -901,8 +901,7 @@ int svm_migrate_init(struct amdgpu_device *adev) >> >> /* Disable SVM support capability */ >> pgmap->type = 0; >> - devm_release_mem_region(adev->dev, res->start, >> - res->end - res->start + 1); >> + devm_release_mem_region(adev->dev, res->start, >> resource_size(res)); > > > Looks good. > Reviewed-by: Amos Kong > > >> >> return PTR_ERR(r); >> } >> >> -- >> 1.8.3.1 >>
[PATCH v3] drm/dp: Add Additional DP2 Headers
Include FEC, DSC, Link Training related headers. Change since v2 - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT Signed-off-by: Fangzhi Zuo --- This patch is based on top of the other DP2.0 work in "drm/dp: add LTTPR DP 2.0 DPCD addresses" --- include/drm/drm_dp_helper.h | 20 1 file changed, 20 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1d5b3dbb6e56..a1df35aa6e68 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -453,6 +453,7 @@ struct drm_panel; # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) # define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3) +#define DP_FEC_CAPABILITY_10x091 /* 2.0 */ /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */ #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */ @@ -537,6 +538,9 @@ struct drm_panel; #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1 0x0a1 #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2 +/* DFP Capability Extension */ +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3 /* 2.0 */ + /* Link Configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ @@ -688,6 +692,7 @@ struct drm_panel; #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ # define DP_DECOMPRESSION_EN(1 << 0) +#define DP_DSC_CONFIGURATION 0x161 /* DP 2.0 */ #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE BIT(0) @@ -743,6 +748,7 @@ struct drm_panel; # define DP_RECEIVE_PORT_0_STATUS (1 << 0) # define DP_RECEIVE_PORT_1_STATUS (1 << 1) # define DP_STREAM_REGENERATION_STATUS (1 << 2) /* 2.0 */ +# define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3) /* 2.0 */ #define DP_ADJUST_REQUEST_LANE0_1 0x206 #define DP_ADJUST_REQUEST_LANE2_3 0x207 @@ -865,6 +871,8 @@ struct drm_panel; # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4 # define DP_PHY_TEST_PATTERN_CP2520 0x5 +#define DP_PHY_SQUARE_PATTERN 0x249 + #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 @@ -1109,6 +1117,18 @@ struct drm_panel; #define DP_128B132B_TRAINING_AUX_RD_INTERVAL 0x2216 /* 2.0 */ # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230 +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256 0x2250 + +/* DSC Extended Capability Branch Total DSC Resources */ +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT 0x2260 /* 2.0 */ +# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5) +# define DP_DSC_DECODER_COUNT_SHIFT5 +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270 /* 2.0 */ +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0) +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1) +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1 + /* Protocol Converter Extension */ /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ #define DP_CEC_TUNNELING_CAPABILITY0x3000 -- 2.25.1
Re: [PATCH] drm/amdgpu: fix warning for overflow check
Applied. Thanks!
On Mon, Sep 27, 2021 at 9:07 AM Christian König
wrote:
>
> Am 27.09.21 um 14:58 schrieb Arnd Bergmann:
> > From: Arnd Bergmann
> >
> > The overflow check in amdgpu_bo_list_create() causes a warning with
> > clang-14 on 64-bit architectures, since the limit can never be
> > exceeded.
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of
> > comparison of constant 256204778801521549 with expression of type 'unsigned
> > int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> > if (num_entries > (SIZE_MAX - sizeof(struct amdgpu_bo_list))
> > ~~~ ^ ~~
> >
> > The check remains useful for 32-bit architectures, so just avoid the
> > warning by using size_t as the type for the count.
> >
> > Fixes: 920990cb080a ("drm/amdgpu: allocate the bo_list array after the
> > list")
> > Signed-off-by: Arnd Bergmann
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> > index 15c45b2a3983..714178f1b6c6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> > @@ -61,7 +61,7 @@ static void amdgpu_bo_list_free(struct kref *ref)
> >
> > int amdgpu_bo_list_create(struct amdgpu_device *adev, struct drm_file
> > *filp,
> > struct drm_amdgpu_bo_list_entry *info,
> > - unsigned num_entries, struct amdgpu_bo_list
> > **result)
> > + size_t num_entries, struct amdgpu_bo_list **result)
> > {
> > unsigned last_entry = 0, first_userptr = num_entries;
> > struct amdgpu_bo_list_entry *array;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
> > index c905a4cfc173..044b41f0bfd9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
> > @@ -61,7 +61,7 @@ int amdgpu_bo_create_list_entry_array(struct
> > drm_amdgpu_bo_list_in *in,
> > int amdgpu_bo_list_create(struct amdgpu_device *adev,
> >struct drm_file *filp,
> >struct drm_amdgpu_bo_list_entry *info,
> > - unsigned num_entries,
> > + size_t num_entries,
> >struct amdgpu_bo_list **list);
> >
> > static inline struct amdgpu_bo_list_entry *
>
Re: [PATCH v2 1/3] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
Reviewed-by: Thomas Hebb
Thank you for catching this, and sorry that my original fix broke things.
There had actually been a report of this breakage from my patch, but I
missed that email until it had already been merged and then didn't have
time to follow up on it. Totally my bad.
[Resending because my last reply was HTML.]
On Mon, Sep 27, 2021 at 11:00 AM Brian Norris wrote:
>
> In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
>
> Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
> built either as modules or built-in.
>
> Side notes: it seems one is more likely to see this problem when the
> panel driver is built into the kernel. I've also seen this problem
> bisect down to commits that simply changed Kconfig dependencies, because
> it changed the order in which driver init functions were compiled into
> the kernel, and therefore the ordering and timing of built-in device
> probe.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Link:
> https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
> Reported-by:
> Cc:
> Signed-off-by: Brian Norris
> Tested-by: Nícolas F. R. A. Prado
> ---
>
> Changes in v2:
> - Clean up pm-runtime state in error cases.
> - Correct git hash for Fixes.
>
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 ++-
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index a2262bee5aa4..45676b23c019 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -773,10 +773,6 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> if (mux < 0)
> return;
>
> - pm_runtime_get_sync(dsi->dev);
> - if (dsi->slave)
> - pm_runtime_get_sync(dsi->slave->dev);
> -
> /*
> * For the RK3399, the clk of grf must be enabled before writing grf
> * register. And for RK3288 or other soc, this grf_clk must be NULL,
> @@ -795,20 +791,10 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> clk_disable_unprepare(dsi->grf_clk);
> }
>
> -static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
> -{
> - struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
> -
> - if (dsi->slave)
> - pm_runtime_put(dsi->slave->dev);
> - pm_runtime_put(dsi->dev);
> -}
> -
> static const struct drm_encoder_helper_funcs
> dw_mipi_dsi_encoder_helper_funcs = {
> .atomic_check = dw_mipi_dsi_encoder_atomic_check,
> .enable = dw_mipi_dsi_encoder_enable,
> - .disable = dw_mipi_dsi_encoder_disable,
> };
>
> static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
> @@ -938,10 +924,14 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> put_device(second);
> }
>
> + pm_runtime_get_sync(dsi->dev);
> + if (dsi->slave)
> + pm_runtime_get_sync(dsi->slave->dev);
> +
> ret = clk_prepare_enable(dsi->pllref_clk);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to enable pllref_clk: %d\n", ret);
> - return ret;
> + goto out_pm_runtime;
> }
>
> /*
> @@ -953,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> ret = clk_prepare_enable(dsi->grf_clk);
> if (ret) {
> DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n",
> ret);
> - return ret;
> + goto out_pm_runtime;
> }
>
> dw_mipi_dsi_rockchip_config(dsi);
> @@ -965,16 +955,23 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
> - return ret;
> + goto out_pm_runtime;
> }
>
> ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
>
Re: [PATCH v2 1/3] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
Reviewed-by: Thomas Hebb
Thank you for catching this, and sorry that my original fix broke things.
There had actually been a report of this breakage from my patch, but I
missed that email until it had already been merged and then didn't have
time to follow up on it. Totally my bad.
On Mon, Sep 27, 2021 at 11:00 AM Brian Norris
wrote:
> In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
>
> Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
> built either as modules or built-in.
>
> Side notes: it seems one is more likely to see this problem when the
> panel driver is built into the kernel. I've also seen this problem
> bisect down to commits that simply changed Kconfig dependencies, because
> it changed the order in which driver init functions were compiled into
> the kernel, and therefore the ordering and timing of built-in device
> probe.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC
> mux to bind()")
> Link:
> https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
> Reported-by
> :
>
> Cc:
> Signed-off-by: Brian Norris
> Tested-by: Nícolas F. R. A. Prado
> ---
>
> Changes in v2:
> - Clean up pm-runtime state in error cases.
> - Correct git hash for Fixes.
>
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 ++-
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index a2262bee5aa4..45676b23c019 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -773,10 +773,6 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> if (mux < 0)
> return;
>
> - pm_runtime_get_sync(dsi->dev);
> - if (dsi->slave)
> - pm_runtime_get_sync(dsi->slave->dev);
> -
> /*
> * For the RK3399, the clk of grf must be enabled before writing
> grf
> * register. And for RK3288 or other soc, this grf_clk must be
> NULL,
> @@ -795,20 +791,10 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> clk_disable_unprepare(dsi->grf_clk);
> }
>
> -static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
> -{
> - struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
> -
> - if (dsi->slave)
> - pm_runtime_put(dsi->slave->dev);
> - pm_runtime_put(dsi->dev);
> -}
> -
> static const struct drm_encoder_helper_funcs
> dw_mipi_dsi_encoder_helper_funcs = {
> .atomic_check = dw_mipi_dsi_encoder_atomic_check,
> .enable = dw_mipi_dsi_encoder_enable,
> - .disable = dw_mipi_dsi_encoder_disable,
> };
>
> static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip
> *dsi,
> @@ -938,10 +924,14 @@ static int dw_mipi_dsi_rockchip_bind(struct device
> *dev,
> put_device(second);
> }
>
> + pm_runtime_get_sync(dsi->dev);
> + if (dsi->slave)
> + pm_runtime_get_sync(dsi->slave->dev);
> +
> ret = clk_prepare_enable(dsi->pllref_clk);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to enable pllref_clk: %d\n",
> ret);
> - return ret;
> + goto out_pm_runtime;
> }
>
> /*
> @@ -953,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device
> *dev,
> ret = clk_prepare_enable(dsi->grf_clk);
> if (ret) {
> DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n",
> ret);
> - return ret;
> + goto out_pm_runtime;
> }
>
> dw_mipi_dsi_rockchip_config(dsi);
> @@ -965,16 +955,23 @@ static int dw_mipi_dsi_rockchip_bind(struct device
> *dev,
> ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
> - return ret;
> + goto out_pm_runtime;
> }
>
> ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
> if
Re: [PATCH 1/2] drm/rockchip: dsi: hold pm-runtime across bind/unbind
On Mon, Sep 27, 2021 at 12:10 AM Chen-Yu Tsai wrote:
> On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote:
> > We should match the runtime PM to the lifetime of the bind()/unbind()
> > cycle.
>
> I'm not too familiar with MIPI DSI, but it seems that the subsystem expects
> the DSI link to be always available, and in LPM if power saving is required?
> If so then this change matches that expectation, though we might lose some
> power savings compared to the previous non-conforming behavior.
Yeah, I was a little torn on whether we should care about any possible
lost power savings here, because now we stay runtime-enabled even if
the display is not enable()d. But I'm not aware of a good hook for
handling this kind of a sequence, and I'm not convinced there is much
savings by disabling the power domain in that case.
> > Fixes: 59eb7193bef2 ("drm/rockchip: dsi: move all lane config except LCDC
> > mux to bind()")
>
> This hash is from some stable branch. The mainline one is:
>
> 43c2de1002d2 drm/rockchip: dsi: move all lane config except LCDC mux to bind()
Oops, good catch. I've been doing too much debugging/development on
5.10.y stable. Fixed in v2.
> The bind function is missing an error cleanup path. We might end up with
> unbalanced runtime PM references. (And also possibly an enabled pllref clk.)
> This is a pre-existing issue though. The code changes here look correct.
In v2, I've performed cleanup for the runtime PM state in this patch,
and added an additional patch to fix the other existing issues you
noted. Thanks.
Brian
Re: [PATCH] drm/bridge/lontium-lt9611uxc: fix provided connector suport
On 09/07/2021 02:03, Dmitry Baryshkov wrote:
- set DRM_CONNECTOR_POLL_HPD as the connector will generate hotplug
events on its own
- do not call drm_kms_helper_hotplug_event() unless mode_config.funcs
pointer is not NULL to remove possible kernel oops.
Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ
handler")
Signed-off-by: Dmitry Baryshkov
---
Gracious ping for review. It would be really nice to get this patch into
5.16
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 3cac16db970f..010657ea7af7 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -167,9 +167,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work)
struct lt9611uxc *lt9611uxc = container_of(work, struct lt9611uxc,
work);
bool connected;
- if (lt9611uxc->connector.dev)
- drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
- else {
+ if (lt9611uxc->connector.dev) {
+ if (lt9611uxc->connector.dev->mode_config.funcs)
+ drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
+ } else {
mutex_lock(>ocm_lock);
connected = lt9611uxc->hdmi_connected;
@@ -339,6 +340,8 @@ static int lt9611uxc_connector_init(struct drm_bridge
*bridge, struct lt9611uxc
return -ENODEV;
}
+ lt9611uxc->connector.polled = DRM_CONNECTOR_POLL_HPD;
+
drm_connector_helper_add(>connector,
_bridge_connector_helper_funcs);
ret = drm_connector_init(bridge->dev, >connector,
--
With best wishes
Dmitry
[PATCH v2 3/3] drm/rockchip: dsi: Disable PLL clock on bind error
Fix some error handling here noticed in review of other changes.
Reported-by: Chen-Yu Tsai
Signed-off-by: Brian Norris
---
Changes in v2:
- New
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index fa4080176719..0ed13d81fe60 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -943,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = clk_prepare_enable(dsi->grf_clk);
if (ret) {
DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
- goto out_pm_runtime;
+ goto out_pll_clk;
}
dw_mipi_dsi_rockchip_config(dsi);
@@ -955,17 +955,19 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
- goto out_pm_runtime;
+ goto out_pll_clk;
}
ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
- goto out_pm_runtime;
+ goto out_pll_clk;
}
return 0;
+out_pll_clk:
+ clk_disable_unprepare(dsi->pllref_clk);
out_pm_runtime:
pm_runtime_put(dsi->dev);
if (dsi->slave)
--
2.33.0.685.g46640cef36-goog
[PATCH v2 2/3] drm/rockchip: dsi: Fix unbalanced clock on probe error
Our probe() function never enabled this clock, so we shouldn't disable
it if we fail to probe the bridge.
Noted by inspection.
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
driver")
Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
---
(no changes since v1)
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 45676b23c019..fa4080176719 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1398,14 +1398,10 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
if (ret != -EPROBE_DEFER)
DRM_DEV_ERROR(dev,
"Failed to probe dw_mipi_dsi: %d\n", ret);
- goto err_clkdisable;
+ return ret;
}
return 0;
-
-err_clkdisable:
- clk_disable_unprepare(dsi->pllref_clk);
- return ret;
}
static int dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
--
2.33.0.685.g46640cef36-goog
[PATCH v2 1/3] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
didn't move the runtime PM management. Therefore, depending on initial
boot state, runtime-PM workqueue delays, and other timing factors, we
may disable our power domain in between the hardware configuration
(bind()) and when we enable the display. This can cause us to lose
hardware state and fail to configure our display. For example:
dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
panel-innolux-p079zca ff96.mipi.0: failed to write command 0
or:
dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
We should match the runtime PM to the lifetime of the bind()/unbind()
cycle.
Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
built either as modules or built-in.
Side notes: it seems one is more likely to see this problem when the
panel driver is built into the kernel. I've also seen this problem
bisect down to commits that simply changed Kconfig dependencies, because
it changed the order in which driver init functions were compiled into
the kernel, and therefore the ordering and timing of built-in device
probe.
Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
to bind()")
Link:
https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
Reported-by:
Cc:
Signed-off-by: Brian Norris
Tested-by: Nícolas F. R. A. Prado
---
Changes in v2:
- Clean up pm-runtime state in error cases.
- Correct git hash for Fixes.
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 ++-
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index a2262bee5aa4..45676b23c019 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -773,10 +773,6 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
if (mux < 0)
return;
- pm_runtime_get_sync(dsi->dev);
- if (dsi->slave)
- pm_runtime_get_sync(dsi->slave->dev);
-
/*
* For the RK3399, the clk of grf must be enabled before writing grf
* register. And for RK3288 or other soc, this grf_clk must be NULL,
@@ -795,20 +791,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
clk_disable_unprepare(dsi->grf_clk);
}
-static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
-{
- struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
-
- if (dsi->slave)
- pm_runtime_put(dsi->slave->dev);
- pm_runtime_put(dsi->dev);
-}
-
static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
.enable = dw_mipi_dsi_encoder_enable,
- .disable = dw_mipi_dsi_encoder_disable,
};
static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
@@ -938,10 +924,14 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
put_device(second);
}
+ pm_runtime_get_sync(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_get_sync(dsi->slave->dev);
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to enable pllref_clk: %d\n", ret);
- return ret;
+ goto out_pm_runtime;
}
/*
@@ -953,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = clk_prepare_enable(dsi->grf_clk);
if (ret) {
DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
- return ret;
+ goto out_pm_runtime;
}
dw_mipi_dsi_rockchip_config(dsi);
@@ -965,16 +955,23 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
- return ret;
+ goto out_pm_runtime;
}
ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
- return ret;
+ goto out_pm_runtime;
}
return 0;
+
+out_pm_runtime:
+ pm_runtime_put(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_put(dsi->slave->dev);
+
+ return ret;
}
static void dw_mipi_dsi_rockchip_unbind(struct device *dev,
@@ -989,6 +986,10 @@ static void dw_mipi_dsi_rockchip_unbind(struct device *dev,
dw_mipi_dsi_unbind(dsi->dmd);
clk_disable_unprepare(dsi->pllref_clk);
+
+ pm_runtime_put(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_put(dsi->slave->dev);
}
static const
[PATCH v2 0/3] Fix Rockchip MIPI DSI display init timeouts
The Rockchip DSI driver has had a number of bugs over time and has
usually only worked by chance. A number of users have noticed that
things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
lane config except LCDC mux to bind()"), although it was fixing several
real issues of its own that had been present forever in the upstream
driver (but notably, not in the downstream/BSP driver).
Patch 1 is the most important fix here. See its description for more
info.
While I'm at it, fix a few error handling and cleanup issues too.
Changes in v2:
- Clean up pm-runtime state in error cases.
- Correct git hash for Fixes.
Brian Norris (3):
drm/rockchip: dsi: Hold pm-runtime across bind/unbind
drm/rockchip: dsi: Fix unbalanced clock on probe error
drm/rockchip: dsi: Disable PLL clock on bind error
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
--
2.33.0.685.g46640cef36-goog
[RFC] drm/msm/a6xx: Serialize GMU communication
From: Rob Clark
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
---
Are we allowed to use c99/gnu99 yet?
drivers/gpu/drm/msm/Makefile | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 9 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 50 ---
4 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 904535eda0c4..57283bbad3f0 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -I $(srctree)/$(src)
+ccflags-y := -I $(srctree)/$(src) -std=gnu99
ccflags-y += -I $(srctree)/$(src)/disp/dpu1
ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
ccflags-$(CONFIG_DRM_MSM_DP) += -I $(srctree)/$(src)/dp
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index a7c58018959f..8b73f70766a4 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -296,6 +296,8 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
u32 val;
int request, ack;
+ WARN_ON_ONCE(!mutex_is_locked(>lock));
+
if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits))
return -EINVAL;
@@ -337,6 +339,8 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
{
int bit;
+ WARN_ON_ONCE(!mutex_is_locked(>lock));
+
if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits))
return;
@@ -1482,6 +1486,8 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (!pdev)
return -ENODEV;
+ mutex_init(>lock);
+
gmu->dev = >dev;
of_dma_configure(gmu->dev, node, true);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 3c74f64e3126..f05a00c0afd0 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -44,6 +44,9 @@ struct a6xx_gmu_bo {
struct a6xx_gmu {
struct device *dev;
+ /* For serializing communication with the GMU: */
+ struct mutex lock;
+
struct msm_gem_address_space *aspace;
void * __iomem mmio;
@@ -88,6 +91,12 @@ struct a6xx_gmu {
bool legacy; /* a618 or a630 */
};
+/* Helper macro for serializing GMU access: */
+#define with_gmu_lock(gmu) \
+ for (bool done = ({ mutex_lock(&(gmu)->lock); false; }); \
+ !done; \
+ done = ({ mutex_unlock(&(gmu)->lock); true; }))
+
static inline u32 gmu_read(struct a6xx_gmu *gmu, u32 offset)
{
return msm_readl(gmu->mmio + (offset << 2));
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index f6a4dbef796b..5e1ae3df42ba 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -881,7 +881,7 @@ static int a6xx_zap_shader_init(struct msm_gpu *gpu)
A6XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS | \
A6XX_RBBM_INT_0_MASK_UCHE_TRAP_INTR)
-static int a6xx_hw_init(struct msm_gpu *gpu)
+static int hw_init(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
@@ -1135,6 +1135,19 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
return ret;
}
+static int a6xx_hw_init(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ int ret;
+
+ with_gmu_lock(_gpu->gmu) {
+ ret = hw_init(gpu);
+ }
+
+ return ret;
+}
+
static void a6xx_dump(struct msm_gpu *gpu)
{
DRM_DEV_INFO(>pdev->dev, "status: %08x\n",
@@ -1509,7 +1522,9 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
trace_msm_gpu_resume(0);
- ret = a6xx_gmu_resume(a6xx_gpu);
+ with_gmu_lock(_gpu->gmu) {
+ ret = a6xx_gmu_resume(a6xx_gpu);
+ }
if (ret)
return ret;
@@ -1532,7 +1547,9 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
msm_devfreq_suspend(gpu);
- ret = a6xx_gmu_stop(a6xx_gpu);
+ with_gmu_lock(_gpu->gmu) {
+ ret = a6xx_gmu_stop(a6xx_gpu);
+ }
if (ret)
return ret;
@@ -1547,18 +1564,17 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- static DEFINE_MUTEX(perfcounter_oob);
- mutex_lock(_oob);
+ with_gmu_lock(_gpu->gmu) {
+ /* Force the GPU power on so we can read this register */
+
Re: [PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780
> Am 27.09.2021 um 19:08 schrieb Maxime Ripard :
>
> On Mon, Sep 27, 2021 at 06:44:24PM +0200, H. Nikolaus Schaller wrote:
>> From: Paul Boddie
>>
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and configuration
>> modifications.
>>
>> +regulator = devm_regulator_get_optional(>dev, "hdmi-5v");
>> +
>> +if (IS_ERR(regulator)) {
>> +ret = PTR_ERR(regulator);
>> +
>> +DRM_DEV_ERROR(>dev, "failed to get hpd regulator: %s
>> (%d)\n",
>> + "hdmi-5v", ret);
>> +return ret;
>> +}
>
> This doesn't match your binding
or the binding not what we wanted to have...
BR and thanks,
Nikolaus
Re: [PATCH v4 05/10] drm/bridge: synopsis: Fix to properly handle HPD
> Am 27.09.2021 um 19:00 schrieb Maxime Ripard :
>
> Hi,
>
> On Mon, Sep 27, 2021 at 06:44:23PM +0200, H. Nikolaus Schaller wrote:
>> It appears that dw-hdmi plugin detection is not properly
>> propagated unless we call drm_kms_helper_hotplug_event().
>>
>> Maybe drm_bridge_hpd_notify should have been setup to
>> call this.
>>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index f082e14320e1..edea04f80576 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -3018,6 +3018,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> if (hdmi->bridge.dev) {
>> drm_helper_hpd_irq_event(hdmi->bridge.dev);
>> drm_bridge_hpd_notify(>bridge, status);
>> +
>> +drm_kms_helper_hotplug_event(hdmi->bridge.dev);
>
> drm_kms_helper_hotplug_event is already called from drm_helper_hpd_irq_event
Ah, now I see. It should be called but is not for some unkown
condition (poll disabled? changed = false?).
It may also be a leftover from the attempt to make it work with
the builtin dw-hdmi connector.
Will check for v5.
BR and thanks,
Nikolaus
Re: [PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780
On Mon, Sep 27, 2021 at 06:44:24PM +0200, H. Nikolaus Schaller wrote:
> From: Paul Boddie
>
> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
> HDMI support. This requires a new driver, plus device tree and configuration
> modifications.
>
> Signed-off-by: Paul Boddie
> Signed-off-by: Ezequiel Garcia
> Signed-off-by: H. Nikolaus Schaller
> ---
> drivers/gpu/drm/ingenic/Kconfig | 9 ++
> drivers/gpu/drm/ingenic/Makefile | 1 +
> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 142 ++
> 3 files changed, 152 insertions(+)
> create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>
> diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
> index 3b57f8be007c..4c7d311fbeff 100644
> --- a/drivers/gpu/drm/ingenic/Kconfig
> +++ b/drivers/gpu/drm/ingenic/Kconfig
> @@ -25,4 +25,13 @@ config DRM_INGENIC_IPU
>
> The Image Processing Unit (IPU) will appear as a second primary plane.
>
> +config DRM_INGENIC_DW_HDMI
> + bool "Ingenic specific support for Synopsys DW HDMI"
> + depends on MACH_JZ4780
> + select DRM_DW_HDMI
> + help
> + Choose this option to enable Synopsys DesignWare HDMI based driver.
> + If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
> + select this option..
> +
> endif
> diff --git a/drivers/gpu/drm/ingenic/Makefile
> b/drivers/gpu/drm/ingenic/Makefile
> index d313326bdddb..3db9888a6c04 100644
> --- a/drivers/gpu/drm/ingenic/Makefile
> +++ b/drivers/gpu/drm/ingenic/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
> ingenic-drm-y = ingenic-drm-drv.o
> ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
> +ingenic-drm-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
> diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
> b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
> new file mode 100644
> index ..dd9c94ae842e
> --- /dev/null
> +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
> @@ -0,0 +1,142 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019, 2020 Paul Boddie
> + *
> + * Derived from dw_hdmi-imx.c with i.MX portions removed.
> + * Probe and remove operations derived from rcar_dw_hdmi.c.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
> + { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
> } } },
> + { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
> } } },
> + { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
> } } },
> + { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
> } } },
> + { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
> } } }
> +};
> +
> +static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
> + /*pixelclk bpp8bpp10 bpp12 */
> + { 5400, { 0x091c, 0x091c, 0x06dc } },
> + { 5840, { 0x091c, 0x06dc, 0x06dc } },
> + { 7200, { 0x06dc, 0x06dc, 0x091c } },
> + { 7425, { 0x06dc, 0x0b5c, 0x091c } },
> + { 11880, { 0x091c, 0x091c, 0x06dc } },
> + { 21600, { 0x06dc, 0x0b5c, 0x091c } },
> + { ~0UL, { 0x, 0x, 0x } },
> +};
> +
> +/*
> + * Resistance term 133Ohm Cfg
> + * PREEMP config 0.00
> + * TX/CK level 10
> + */
> +static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
> + /*pixelclk symbol term vlev */
> + { 21600, 0x800d, 0x0005, 0x01ad},
> + { ~0UL, 0x, 0x, 0x}
> +};
> +
> +static enum drm_mode_status
> +ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> +const struct drm_display_info *info,
> +const struct drm_display_mode *mode)
> +{
> + if (mode->clock < 13500)
> + return MODE_CLOCK_LOW;
> + /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
> + if (mode->clock > 216000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> +static bool
> +ingenic_dw_hdmi_mode_fixup(struct drm_bridge *bridge,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode)
> +{
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> +
> + return true;
> +}
> +
> +static const struct drm_bridge_timings ingenic_dw_hdmi_timings = {
> + .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
> +};
> +
> +static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
> + .mpll_cfg = ingenic_mpll_cfg,
> + .cur_ctr= ingenic_cur_ctr,
> + .phy_config = ingenic_phy_config,
> + .mode_valid = ingenic_dw_hdmi_mode_valid,
> +
Re: [PATCH v4 03/10] dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema
Hi, On Mon, Sep 27, 2021 at 06:44:21PM +0200, H. Nikolaus Schaller wrote: > From: Sam Ravnborg > > Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. > Based on .txt binding from Zubair Lutfullah Kakakhel > > Signed-off-by: Sam Ravnborg > Signed-off-by: H. Nikolaus Schaller > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > --- > .../bindings/display/ingenic-jz4780-hdmi.yaml | 85 +++ > 1 file changed, 85 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml > > diff --git > a/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml > b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml > new file mode 100644 > index ..5e60cdac4f63 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml > @@ -0,0 +1,85 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/ingenic-jz4780-hdmi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Bindings for Ingenic JZ4780 HDMI Transmitter > + > +maintainers: > + - H. Nikolaus Schaller > + > +description: | > + The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI > 1.4 > + TX controller IP with accompanying PHY IP. > + > +allOf: > + - $ref: panel/panel-common.yaml# Is it a panel though? > +properties: > + compatible: > +items: > + - const: ingenic,jz4780-dw-hdmi This can just be a const, there's no need for the items > + > + reg: > +maxItems: 1 > +description: the address & size of the LCD controller registers There's no need for that description, it's obvious enough > + reg-io-width: > +const: 4 If it's fixed, why do you need it in the first place? > + interrupts: > +maxItems: 1 > +description: Specifies the interrupt provided by parent There's no need for that description, it's obvious enough > + clocks: > +maxItems: 2 > +description: Clock specifiers for isrf and iahb clocks This can be defined as clocks: items: - description: isrf - description: iahb A better description about what these clocks are would be nice as well > + clock-names: > +items: > + - const: isfr Is it isfr or isrf? > + - const: iahb > + > + hdmi-regulator: true > +description: Optional regulator to provide +5V at the connector regulators need to be suffixed by -supply You also can just provide the description, you don't need the true there > + ddc-i2c-bus: true ditto > +description: An I2C interface if the internal DDC I2C driver is not to > be used > + ports: true If there's a single port, you don't need ports You should also include /schemas/graph.yaml#/$defs/port-base Maxime signature.asc Description: PGP signature
Re: [PATCH v4 05/10] drm/bridge: synopsis: Fix to properly handle HPD
Hi,
On Mon, Sep 27, 2021 at 06:44:23PM +0200, H. Nikolaus Schaller wrote:
> It appears that dw-hdmi plugin detection is not properly
> propagated unless we call drm_kms_helper_hotplug_event().
>
> Maybe drm_bridge_hpd_notify should have been setup to
> call this.
>
> Signed-off-by: H. Nikolaus Schaller
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index f082e14320e1..edea04f80576 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -3018,6 +3018,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> if (hdmi->bridge.dev) {
> drm_helper_hpd_irq_event(hdmi->bridge.dev);
> drm_bridge_hpd_notify(>bridge, status);
> +
> + drm_kms_helper_hotplug_event(hdmi->bridge.dev);
drm_kms_helper_hotplug_event is already called from drm_helper_hpd_irq_event
Maxime
signature.asc
Description: PGP signature
[PATCH v4 06/10] drm/ingenic: Add dw-hdmi driver for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
HDMI support. This requires a new driver, plus device tree and configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 142 ++
3 files changed, 152 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 3b57f8be007c..4c7d311fbeff 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -25,4 +25,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ bool "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option..
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddb..3db9888a6c04 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+ingenic-drm-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index ..dd9c94ae842e
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static bool
+ingenic_dw_hdmi_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+ adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+
+ return true;
+}
+
+static const struct drm_bridge_timings ingenic_dw_hdmi_timings = {
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .mode_fixup = ingenic_dw_hdmi_mode_fixup,
+ .timings= _dw_hdmi_timings,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel
[PATCH v4 04/10] drm/bridge: synopsis: Add mode_fixup and bridge timings support
From: Paul Boddie
The platform-specific configuration structure is augmented with
mode_fixup and timings members so that specialisations of the
Synopsys driver can introduce mode flags and bus flags.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +++
include/drm/bridge/dw_hdmi.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f08d0fded61f..f082e14320e1 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2767,6 +2767,11 @@ static int dw_hdmi_bridge_atomic_check(struct drm_bridge
*bridge,
bridge_state->input_bus_cfg.format,
bridge_state->output_bus_cfg.format);
+ if (hdmi->plat_data->mode_fixup)
+ if (!hdmi->plat_data->mode_fixup(bridge, _state->mode,
+_state->adjusted_mode))
+ return -EINVAL;
+
return 0;
}
@@ -3416,6 +3421,8 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
*pdev,
#ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
#endif
+ if (plat_data->timings)
+ hdmi->bridge.timings = plat_data->timings;
memset(, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3..743038200044 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -8,6 +8,7 @@
#include
+struct drm_bridge;
struct drm_display_info;
struct drm_display_mode;
struct drm_encoder;
@@ -142,6 +143,10 @@ struct dw_hdmi_plat_data {
enum drm_mode_status (*mode_valid)(struct dw_hdmi *hdmi, void *data,
const struct drm_display_info *info,
const struct drm_display_mode *mode);
+ bool (*mode_fixup)(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode);
+ const struct drm_bridge_timings *timings;
/* Vendor PHY support */
const struct dw_hdmi_phy_ops *phy_ops;
--
2.31.1
[PATCH v4 07/10] MIPS: DTS: jz4780: Account for Synopsys HDMI driver and LCD controllers
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
HDMI support. This requires a new driver, plus device tree and configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 45 ++
1 file changed, 45 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 9e34f433b9b5..4cbc6a4db6cd 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -424,6 +424,51 @@ i2c4: i2c@10054000 {
status = "disabled";
};
+ hdmi: hdmi@1018 {
+ compatible = "ingenic,jz4780-dw-hdmi";
+ reg = <0x1018 0x8000>;
+ reg-io-width = <4>;
+
+ clocks = < JZ4780_CLK_HDMI>, < JZ4780_CLK_AHB0>;
+ clock-names = "isfr" , "iahb";
+
+ assigned-clocks = < JZ4780_CLK_HDMI>;
+ assigned-clock-rates = <2700>;
+
+ interrupt-parent = <>;
+ interrupts = <3>;
+
+ /* ddc-i2c-bus = <>; */
+
+ status = "disabled";
+ };
+
+ lcdc0: lcdc0@1305 {
+ compatible = "ingenic,jz4780-lcd";
+ reg = <0x1305 0x1800>;
+
+ clocks = < JZ4780_CLK_TVE>, < JZ4780_CLK_LCD0PIXCLK>;
+ clock-names = "lcd", "lcd_pclk";
+
+ interrupt-parent = <>;
+ interrupts = <31>;
+
+ status = "disabled";
+ };
+
+ lcdc1: lcdc1@130a {
+ compatible = "ingenic,jz4780-lcd";
+ reg = <0x130a 0x1800>;
+
+ clocks = < JZ4780_CLK_TVE>, < JZ4780_CLK_LCD1PIXCLK>;
+ clock-names = "lcd", "lcd_pclk";
+
+ interrupt-parent = <>;
+ interrupts = <31>;
+
+ status = "disabled";
+ };
+
nemc: nemc@1341 {
compatible = "ingenic,jz4780-nemc", "simple-mfd";
reg = <0x1341 0x1>;
--
2.31.1
[PATCH v4 09/10] MIPS: defconfig: CI20: configure for DRM_DW_HDMI_JZ4780
Enable CONFIG options as modules. Signed-off-by: Ezequiel Garcia Signed-off-by: H. Nikolaus Schaller --- arch/mips/configs/ci20_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig index ab7ebb066834..9c9c649d385b 100644 --- a/arch/mips/configs/ci20_defconfig +++ b/arch/mips/configs/ci20_defconfig @@ -98,7 +98,13 @@ CONFIG_RC_DEVICES=y CONFIG_IR_GPIO_CIR=m CONFIG_IR_GPIO_TX=m CONFIG_MEDIA_SUPPORT=m +CONFIG_DRM=m +CONFIG_DRM_INGENIC=m +CONFIG_DRM_INGENIC_DW_HDMI=y +CONFIG_DRM_DISPLAY_CONNECTOR=m # CONFIG_VGA_CONSOLE is not set +CONFIG_FB=y +CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_HID is not set CONFIG_USB=y CONFIG_USB_STORAGE=y -- 2.31.1
[PATCH v4 00/10] MIPS: JZ4780 and CI20 HDMI
- fix setting output_port = 1 (issue found by p...@crapouillou.net) - ci20.dts: convert to use hdmi-connector (by h...@goldelico.com) - add a hdmi-regulator to control +5V power (by h...@goldelico.com) - added a fix to dw-hdmi to call drm_kms_helper_hotplug_event on plugin event detection (by h...@goldelico.com) - always allocate extended descriptor but initialize only for jz4780 (by h...@goldelico.com) - updated to work on top of "[PATCH v3 0/6] drm/ingenic: Various improvements v3" (by p...@crapouillou.net) - rebased to v5.13-rc3 PATCH V3 2021-08-08 07:10:50: This series adds HDMI support for JZ4780 and CI20 board (and fixes one IPU related issue in registration error path) - [patch 1/8] switched from mode_fixup to atomic_check (suggested by robert.f...@linaro.org) - the call to the dw-hdmi specialization is still called mode_fixup - [patch 3/8] diverse fixes for ingenic-drm-drv (suggested by p...@crapouillou.net) - factor out some non-HDMI features of the jz4780 into a separate patch - multiple fixes around max height - do not change regmap config but a copy on stack - define some constants - factor out fixing of drm_init error path for IPU into separate patch - use FIELD_PREP() - [patch 8/8] conversion to component framework dropped (suggested by laurent.pinch...@ideasonboard.com and p...@crapouillou.net) PATCH V2 2021-08-05 16:08:05: This series adds HDMI support for JZ4780 and CI20 board V2: - code and commit messages revisited for checkpatch warnings - rebased on v5.14-rc4 - include (failed, hence RFC 8/8) attempt to convert to component framework (was suggested by Paul Cercueil a while ago) H. Nikolaus Schaller (2): drm/bridge: synopsis: Fix to properly handle HPD MIPS: defconfig: CI20: configure for DRM_DW_HDMI_JZ4780 Paul Boddie (7): drm/ingenic: Fix drm_init error path if IPU was registered drm/ingenic: Add support for JZ4780 and HDMI output drm/bridge: synopsis: Add mode_fixup and bridge timings support drm/ingenic: Add dw-hdmi driver for jz4780 MIPS: DTS: jz4780: Account for Synopsys HDMI driver and LCD controllers MIPS: DTS: CI20: Add DT nodes for HDMI setup drm/ingenic: add some jz4780 specific features Sam Ravnborg (1): dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema .../bindings/display/ingenic-jz4780-hdmi.yaml | 85 +++ arch/mips/boot/dts/ingenic/ci20.dts | 67 + arch/mips/boot/dts/ingenic/jz4780.dtsi| 45 ++ arch/mips/configs/ci20_defconfig | 6 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 ++ drivers/gpu/drm/ingenic/Kconfig | 9 ++ drivers/gpu/drm/ingenic/Makefile | 1 + drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 135 - drivers/gpu/drm/ingenic/ingenic-drm.h | 42 ++ drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 142 ++ include/drm/bridge/dw_hdmi.h | 5 + 11 files changed, 540 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c -- 2.31.1
[PATCH v4 10/10] drm/ingenic: add some jz4780 specific features
From: Paul Boddie
The jz4780 has some features which need initialization
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index e2df4b085905..605549b316b5 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -66,6 +66,10 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
bool map_noncoherent;
+ bool has_alpha;
+ bool has_pcfg;
+ bool has_recover;
+ bool has_rgbc;
bool use_extended_hwdesc;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
@@ -732,6 +736,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->has_recover)
+ cfg |= JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN;
+
/* set use of the 8-word descriptor and OSD foreground usage. */
if (priv->soc_info->use_extended_hwdesc)
cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
@@ -1321,6 +1328,25 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
if (soc_info->has_osd)
regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ if (soc_info->has_alpha)
+ regmap_set_bits(priv->map, JZ_REG_LCD_OSDC,
JZ_LCD_OSDC_ALPHAEN);
+
+ /* Magic values from the vendor kernel for the priority thresholds. */
+ if (soc_info->has_pcfg)
+ regmap_write(priv->map, JZ_REG_LCD_PCFG,
+JZ_LCD_PCFG_PRI_MODE |
+JZ_LCD_PCFG_HP_BST_16 |
+(511 << JZ_LCD_PCFG_THRESHOLD2_OFFSET) |
+(400 << JZ_LCD_PCFG_THRESHOLD1_OFFSET) |
+(256 << JZ_LCD_PCFG_THRESHOLD0_OFFSET));
+
+ /* RGB output control may be superfluous. */
+ if (soc_info->has_rgbc)
+ regmap_write(priv->map, JZ_REG_LCD_RGBC,
+JZ_LCD_RGBC_RGB_FORMAT_ENABLE |
+JZ_LCD_RGBC_ODD_RGB |
+JZ_LCD_RGBC_EVEN_RGB);
+
mutex_init(>clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1484,6 +1510,9 @@ static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
.has_osd = false,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4740_formats,
@@ -1496,6 +1525,9 @@ static const struct jz_soc_info jz4725b_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4725b_formats_f1,
@@ -1509,6 +1541,9 @@ static const struct jz_soc_info jz4770_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = true,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 1280,
.max_height = 720,
.formats_f1 = jz4770_formats_f1,
@@ -1521,6 +1556,10 @@ static const struct jz_soc_info jz4770_soc_info = {
static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
+ .has_alpha = true,
+ .has_pcfg = true,
+ .has_recover = true,
+ .has_rgbc = true,
.use_extended_hwdesc = true,
.max_width = 4096,
.max_height = 2048,
--
2.31.1
[PATCH v4 08/10] MIPS: DTS: CI20: Add DT nodes for HDMI setup
From: Paul Boddie
We need to hook up
* HDMI connector
* HDMI power regulator
* DDC pinmux
* HDMI and LCDC endpoint connections
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/ci20.dts | 67 +
1 file changed, 67 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index a688809beebc..4776be35b14d 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -78,6 +78,18 @@ eth0_power: fixedregulator@0 {
enable-active-high;
};
+ hdmi_out: connector {
+ compatible = "hdmi-connector";
+ label = "HDMI OUT";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <_hdmi_out>;
+ };
+ };
+ };
+
ir: ir {
compatible = "gpio-ir-receiver";
gpios = < 3 GPIO_ACTIVE_LOW>;
@@ -102,6 +114,17 @@ otg_power: fixedregulator@2 {
gpio = < 14 GPIO_ACTIVE_LOW>;
enable-active-high;
};
+
+ hdmi_power: fixedregulator@3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "hdmi_power";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+
+ gpio = < 25 GPIO_ACTIVE_LOW>;
+ enable-active-high;
+ };
};
{
@@ -506,6 +529,12 @@ pins_i2c4: i2c4 {
bias-disable;
};
+ pins_hdmi_ddc: hdmi_ddc {
+ function = "hdmi-ddc";
+ groups = "hdmi-ddc";
+ bias-disable;
+ };
+
pins_nemc: nemc {
function = "nemc";
groups = "nemc-data", "nemc-cle-ale", "nemc-rd-we",
"nemc-frd-fwe";
@@ -536,3 +565,41 @@ pins_mmc1: mmc1 {
bias-disable;
};
};
+
+ {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_hdmi_ddc>;
+
+ hdmi-5v-supply = <_power>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dw_hdmi_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dw_hdmi_out: endpoint {
+ remote-endpoint = <_con>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ port {
+ lcd_out: endpoint {
+ remote-endpoint = <_hdmi_in>;
+ };
+ };
+};
--
2.31.1
[PATCH v4 05/10] drm/bridge: synopsis: Fix to properly handle HPD
It appears that dw-hdmi plugin detection is not properly
propagated unless we call drm_kms_helper_hotplug_event().
Maybe drm_bridge_hpd_notify should have been setup to
call this.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f082e14320e1..edea04f80576 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3018,6 +3018,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (hdmi->bridge.dev) {
drm_helper_hpd_irq_event(hdmi->bridge.dev);
drm_bridge_hpd_notify(>bridge, status);
+
+ drm_kms_helper_hotplug_event(hdmi->bridge.dev);
}
}
--
2.31.1
[PATCH v4 03/10] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../bindings/display/ingenic-jz4780-hdmi.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
diff --git a/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
new file mode 100644
index ..5e60cdac4f63
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic-jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - H. Nikolaus Schaller
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: ingenic,jz4780-dw-hdmi
+
+ reg:
+maxItems: 1
+description: the address & size of the LCD controller registers
+
+ reg-io-width:
+const: 4
+
+ interrupts:
+maxItems: 1
+description: Specifies the interrupt provided by parent
+
+ clocks:
+maxItems: 2
+description: Clock specifiers for isrf and iahb clocks
+
+ clock-names:
+items:
+ - const: isfr
+ - const: iahb
+
+ hdmi-regulator: true
+description: Optional regulator to provide +5V at the connector
+ ddc-i2c-bus: true
+description: An I2C interface if the internal DDC I2C driver is not to be
used
+ ports: true
+
+required:
+- compatible
+- clocks
+- clock-names
+- ports
+- reg-io-width
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-dw-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <>;
+interrupt-parent = <>;
+interrupts = <3>;
+clocks = < JZ4780_CLK_HDMI>, < JZ4780_CLK_AHB0>;
+clock-names = "isfr", "iahb";
+
+ports {
+hdmi_in: port {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in_lcd: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_out_hdmi>;
+};
+};
+};
+};
+
+...
--
2.31.1
[PATCH v4 01/10] drm/ingenic: Fix drm_init error path if IPU was registered
From: Paul Boddie If ingenic drm driver can not be registered, the IPU driver won't be deregistered. Code structure is chosen in preparation to add hdmi unregistration in error case following the same pattern by a later patch. Signed-off-by: Paul Boddie Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 35b61657d9f6..f73522bdacaa 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -1498,7 +1498,16 @@ static int ingenic_drm_init(void) return err; } - return platform_driver_register(_drm_driver); + err = platform_driver_register(_drm_driver); + if (err) + goto err_ipu_unreg; + + return 0; + +err_ipu_unreg: + if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) + platform_driver_unregister(ingenic_ipu_driver_ptr); + return err; } module_init(ingenic_drm_init); -- 2.31.1
[PATCH v4 02/10] drm/ingenic: Add support for JZ4780 and HDMI output
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 85 +--
drivers/gpu/drm/ingenic/ingenic-drm.h | 42 +++
2 files changed, 122 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index f73522bdacaa..e2df4b085905 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -6,6 +6,7 @@
#include "ingenic-drm.h"
+#include
#include
#include
#include
@@ -49,6 +50,11 @@ struct ingenic_dma_hwdesc {
u32 addr;
u32 id;
u32 cmd;
+ /* extended hw descriptor for jz4780 */
+ u32 offsize;
+ u32 pagewidth;
+ u32 cpos;
+ u32 dessize;
} __aligned(16);
struct ingenic_dma_hwdescs {
@@ -60,9 +66,11 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
bool map_noncoherent;
+ bool use_extended_hwdesc;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
+ unsigned int max_reg;
};
struct ingenic_drm_private_state {
@@ -168,12 +176,11 @@ static bool ingenic_drm_writeable_reg(struct device *dev,
unsigned int reg)
}
}
-static const struct regmap_config ingenic_drm_regmap_config = {
+static struct regmap_config ingenic_drm_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
- .max_register = JZ_REG_LCD_SIZE1,
.writeable_reg = ingenic_drm_writeable_reg,
};
@@ -663,6 +670,37 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
hwdesc->cmd = JZ_LCD_CMD_EOF_IRQ | (width * height * cpp / 4);
hwdesc->next = dma_hwdesc_addr(priv, next_id);
+ if (priv->soc_info->use_extended_hwdesc) {
+ hwdesc->cmd |= JZ_LCD_CMD_FRM_ENABLE;
+
+ /* Extended 8-byte descriptor */
+ hwdesc->cpos = 0;
+ hwdesc->offsize = 0;
+ hwdesc->pagewidth = 0;
+
+ switch (newstate->fb->format->format) {
+ case DRM_FORMAT_XRGB1555:
+ hwdesc->cpos |= JZ_LCD_CPOS_RGB555;
+ fallthrough;
+ case DRM_FORMAT_RGB565:
+ hwdesc->cpos |= JZ_LCD_CPOS_BPP_15_16;
+ break;
+ case DRM_FORMAT_XRGB:
+ hwdesc->cpos |= JZ_LCD_CPOS_BPP_18_24;
+ break;
+ }
+ hwdesc->cpos |= JZ_LCD_CPOS_PREMULTIPLY_LCD |
+ (JZ_LCD_CPOS_COEFFICIENT_1_ALPHA1 <<
+JZ_LCD_CPOS_COEFFICIENT_OFFSET);
+
+ hwdesc->dessize =
+ (0xff << JZ_LCD_DESSIZE_ALPHA_OFFSET) |
+ FIELD_PREP(JZ_LCD_DESSIZE_HEIGHT_MASK <<
+ JZ_LCD_DESSIZE_HEIGHT_OFFSET, height
- 1) |
+ FIELD_PREP(JZ_LCD_DESSIZE_WIDTH_MASK <<
+ JZ_LCD_DESSIZE_WIDTH_OFFSET, width -
1);
+ }
+
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
fourcc = newstate->fb->format->format;
@@ -694,6 +732,10 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ /* set use of the 8-word descriptor and OSD foreground usage. */
+ if (priv->soc_info->use_extended_hwdesc)
+ cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
+
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= JZ_LCD_CFG_HSYNC_ACTIVE_LOW;
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
@@ -1010,6 +1052,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
struct drm_encoder *encoder;
struct ingenic_drm_bridge *ib;
struct drm_device *drm;
+ struct regmap_config regmap_config;
void __iomem *base;
long parent_rate;
unsigned int i, clone_mask = 0;
@@ -1063,8 +1106,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
return PTR_ERR(base);
}
+ regmap_config = ingenic_drm_regmap_config;
+ regmap_config.max_register = soc_info->max_reg;
priv->map = devm_regmap_init_mmio(dev, base,
-
Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency
On Mon, Sep 27, 2021 at 04:28:02PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
>
> aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function
> `drm_fb_helper_alloc_fbi':
> (.text+0x10cc): undefined reference to `framebuffer_alloc'
>
> Tighten the dependency so it is only allowed in the case that DRM can
> link against FB.
>
> Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
> Link: https://lore.kernel.org/all/20210721152211.2706171-1-a...@kernel.org/
> Signed-off-by: Arnd Bergmann
Thanks for fixing this!
Reviewed-by: Kees Cook
--
Kees Cook
Re: [PATCH] drm/edid: Fix drm_edid_encode_panel_id() kerneldoc warning
On 9/27/21 7:41 AM, Douglas Anderson wrote:
Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and
not 0, 2, 3) we were getting a kernel doc warning that looked like
this:
include/drm/drm_edid.h:530: warning:
Function parameter or member 'vend_chr_1' not described in
'drm_edid_encode_panel_id'
include/drm/drm_edid.h:530: warning:
Excess function parameter 'vend_chr_3' description in
'drm_edid_encode_panel_id'
Fix it.
Fixes: 7d1be0a09fa6 ("drm/edid: Fix EDID quirk compile error on older
compilers")
Reported-by: Stephen Rothwell
Signed-off-by: Douglas Anderson
Acked-by: Randy Dunlap
Thanks.
---
include/drm/drm_edid.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 4d17cd04fff7..18f6c700f6d0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -511,8 +511,8 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
/**
* drm_edid_encode_panel_id - Encode an ID for matching against
drm_edid_get_panel_id()
* @vend_chr_0: First character of the vendor string.
- * @vend_chr_2: Second character of the vendor string.
- * @vend_chr_3: Third character of the vendor string.
+ * @vend_chr_1: Second character of the vendor string.
+ * @vend_chr_2: Third character of the vendor string.
* @product_id: The 16-bit product ID.
*
* This is a macro so that it can be calculated at compile time and used
--
~Randy
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Paul, > Am 25.09.2021 um 21:39 schrieb Paul Cercueil : > > > > Le sam., sept. 25 2021 at 21:26:42 +0200, H. Nikolaus Schaller > a écrit : >> Hi Paul, >>> Am 25.09.2021 um 21:08 schrieb Paul Cercueil : >>> Hi Paul & Nikolaus, >>> If you spent some time debugging the issue >> we did ... > > By saying that you didn't debug, We did - but sometimes you don't see the wood for the trees. > (null) means you're printing a NULL pointer. So I could see that > hdmi->next_bridge was NULL. I remember we did find this, but did not understand that it should be initialized by dw-hdmi. And because we though that dw-hdmi has it its own connector, it is ok that way. > The place that sets it is dw_hdmi_parse_dt, which will return early with code > 0, before next_bridge is set, if plat_data->output_port == 0, which was your > case. Well, we were still at 5.14 when we did these initial attempts to use hdmi-connector with synopsys. Back then, there was no dw_hdmi_parse_dt and no output_port. IAW: we did not even have a chance to make it work on top of 5.14 the hdmi-connector way. And were sucessful. I just noticed this when trying to backport the last puzzle piece... Well, it is always difficult to hit a moving target. > Since your hdmi-connector is wired at port #1, then .output_port should be 1 > as well. Anyways it works now for 5.14.8 (our internal test) and 5.15-rc3. And v4 of the jz4780 hdmi stuff will follow. BR and thanks, Nikolaus
Re: [Intel-gfx] [PATCH v5 01/13] drm/ttm: stop calling tt_swapin in vm_access
On Mon, 27 Sept 2021 at 12:47, Christian König wrote:
>
> Any objections that I just push patches 1-7 to drm-misc-next?
Please go ahead Christian. Thanks.
>
> Christian.
>
> Am 27.09.21 um 13:41 schrieb Matthew Auld:
> > In commit:
> >
> > commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
> > Author: Felix Kuehling
> > Date: Thu Jul 13 17:01:16 2017 -0400
> >
> > drm/ttm: Implement vm_operations_struct.access v2
> >
> > we added the vm_access hook, where we also directly call tt_swapin for
> > some reason. If something is swapped-out then the ttm_tt must also be
> > unpopulated, and since access_kmap should also call tt_populate, if
> > needed, then swapping-in will already be handled there.
> >
> > If anything, calling tt_swapin directly here would likely always fail
> > since the tt->pages won't yet be populated, or worse since the tt->pages
> > array is never actually cleared in unpopulate this might lead to a nasty
> > uaf.
> >
> > Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Christian König
> > Reviewed-by: Thomas Hellström
> > Reviewed-by: Christian König
> > ---
> > drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > index f56be5bc0861..5b9b7fd01a69 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > @@ -519,11 +519,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma,
> > unsigned long addr,
> >
> > switch (bo->resource->mem_type) {
> > case TTM_PL_SYSTEM:
> > - if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
> > - ret = ttm_tt_swapin(bo->ttm);
> > - if (unlikely(ret != 0))
> > - return ret;
> > - }
> > fallthrough;
> > case TTM_PL_TT:
> > ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
>
[PATCH] drm/scdc: Document hotplug gotchas
There's some interactions between the SCDC setup and the disconnection / reconnection of displays. Let's document it and a solution. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_scdc_helper.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/drm_scdc_helper.c b/drivers/gpu/drm/drm_scdc_helper.c index 48a382464d54..12e09fe8c8df 100644 --- a/drivers/gpu/drm/drm_scdc_helper.c +++ b/drivers/gpu/drm/drm_scdc_helper.c @@ -34,6 +34,19 @@ * HDMI 2.0 specification. It is a point-to-point protocol that allows the * HDMI source and HDMI sink to exchange data. The same I2C interface that * is used to access EDID serves as the transport mechanism for SCDC. + * + * Note: The SCDC status is going to be lost when the display is + * disconnected. This can happen physically when the user disconnects + * the cable, but also when a display is switched on (such as waking up + * a TV). + * + * This is further complicated by the fact that, upon a disconnection / + * reconnection, KMS won't change the mode on its own. This means that + * one can't just rely on setting the SCDC status on enable, but also + * has to track the connector status changes using interrupts and + * restore the SCDC status. The typical place to restore that state is + * in drm_encoder_helper_funcs.detect() or + * drm_connector_helper_funcs.detect_ctx(). */ #define SCDC_I2C_SLAVE_ADDRESS 0x54 -- 2.31.1
[PATCH][next] nvidiafb: Use strscpy() to prevent buffer overflow.
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.
CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
source argument is a parameter of the current function.
89strcpy(chan->adapter.name, name);
Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c
b/drivers/video/fbdev/nvidia/nv_i2c.c
index d7994a173245..0b48965a6420 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan,
const char *name,
{
int rc;
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name, sizeof(chan->adapter.name));
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = >algo;
--
2.33.0
[PATCH v2] drm/dp: Add Additional DP2 Headers
Include FEC, DSC, Link Training related headers. Signed-off-by: Fangzhi Zuo --- This patch is based on top of the other DP2.0 work in "drm/dp: add LTTPR DP 2.0 DPCD addresses" --- include/drm/drm_dp_helper.h | 20 1 file changed, 20 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1d5b3dbb6e56..f1fd9889f190 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -453,6 +453,7 @@ struct drm_panel; # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) # define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3) +#define DP_FEC_CAPABILITY_10x091 /* 2.0 */ /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */ #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */ @@ -537,6 +538,9 @@ struct drm_panel; #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1 0x0a1 #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2 +/* DFP Capability Extension */ +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3 /* 2.0 */ + /* Link Configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ @@ -688,6 +692,7 @@ struct drm_panel; #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ # define DP_DECOMPRESSION_EN(1 << 0) +#define DP_DSC_CONFIGURATION 0x161 /* DP 2.0 */ #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE BIT(0) @@ -743,6 +748,7 @@ struct drm_panel; # define DP_RECEIVE_PORT_0_STATUS (1 << 0) # define DP_RECEIVE_PORT_1_STATUS (1 << 1) # define DP_STREAM_REGENERATION_STATUS (1 << 2) /* 2.0 */ +# define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3) /* 2.0 */ #define DP_ADJUST_REQUEST_LANE0_1 0x206 #define DP_ADJUST_REQUEST_LANE2_3 0x207 @@ -865,6 +871,8 @@ struct drm_panel; # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4 # define DP_PHY_TEST_PATTERN_CP2520 0x5 +#define DP_PHY_SQUARE_PATTERN 0x249 + #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 @@ -1109,6 +1117,18 @@ struct drm_panel; #define DP_128B132B_TRAINING_AUX_RD_INTERVAL 0x2216 /* 2.0 */ # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230 +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256 0x2250 + +/* DSC Extended Capability Branch Total DSC Resources */ +#define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260 /* 2.0 */ +# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5) +# define DP_DSC_DECODER_COUNT_SHIFT5 +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270 /* 2.0 */ +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0) +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1) +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1 + /* Protocol Converter Extension */ /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ #define DP_CEC_TUNNELING_CAPABILITY0x3000 -- 2.25.1
[PATCH] drm/msm: Switch ordering of runpm put vs devfreq_idle
From: Rob Clark
I've seen a few crashes like:
Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun
nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6 ip6t_REJECT
ip6t_ipv6header vhost_vsock vhost vmw_vsock_virtio_transport_common vsock
rfcomm algif_hash algif_skcipher af_alg uinput veth xt_cgroup xt_MASQUERADE
venus_enc venus_dec videobuf2_dma_contig qcom_spmi_adc5 qcom_spmi_adc_tm5
hci_uart qcom_vadc_common cros_ec_typec qcom_spmi_temp_alarm typec btqca
snd_soc_rt5682_i2c snd_soc_rt5682 snd_soc_sc7180 bluetooth snd_soc_qcom_common
snd_soc_rl6231 ecdh_generic ecc venus_core v4l2_mem2mem snd_soc_lpass_sc7180
snd_soc_lpass_hdmi snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_max98357a
ip6table_nat fuse iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors
cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf cros_ec_sensorhub
lzo_rle ath10k_snoc lzo_compress ath10k_core ath zram mac80211 cfg80211
ax88179_178a usbnet mii uvcvideo videobuf2_vmalloc joydev
CPU: 3 PID: 212 Comm: A618-worker Tainted: G W 5.4.139-16300-g88d8e1285982
#1
Hardware name: Google Pompom (rev1) with LTE (DT)
pstate: 60c9 (nZCv daif +PAN +UAO)
pc : a6xx_gmu_set_oob+0x114/0x200
lr : a6xx_gmu_set_oob+0x10c/0x200
sp : ffc011b7bc20
x29: ffc011b7bc20 x28: ffdad27c5000
x27: 0001 x26: ffdad1521044
x25: ffbef7498338 x24: 0018
x23: 0002 x22: 00014648
x21: 033732fe638b x20: 8000
x19: ffbef7433bc8 x18: 4000
x17: 00243508d982 x16: b67e
x15: 90d4 x14: 0024
x13: 0024 x12: 00017521
x11: 0b48 x10: 00326a48
x9 : 1a130d33f6371600 x8 : ffc011e54648
x7 : 614948e5003c x6 : ffbe3cd17e60
x5 : 0040 x4 : 0004
x3 : x2 : ffbef7488000
x1 : ffbef7488000 x0 :
Call trace:
a6xx_gmu_set_oob+0x114/0x200
a6xx_gmu_set_freq+0xe0/0x1fc
msm_devfreq_target+0x80/0x13c
msm_devfreq_idle+0x54/0x94
retire_submit+0x170/0x254
retire_submits+0xa4/0xdc
retire_worker+0x1c/0x28
kthread_worker_fn+0xf4/0x1bc
kthread+0x140/0x158
ret_from_fork+0x10/0x18
Code: 52800c81 9415bbe5 f9400a68 8b160108 (b9400108)
---[ end trace 16b871df2482cd61 ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x1ac140 from 0xffc01000
PHYS_OFFSET: 0xffc28000
CPU features: 0x88102e,2a80aa38
Memory Limit: none
Which smells a lot like touching hw after power collapse. I'm not
*entirely* sure how it could have taken 66ms (the autosuspend delay)
before we get to a6xx_gmu_set_oob(), but to be safe we should move
the pm_runtime_put_autosuspend() after msm_devfreq_idle().
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d1a16642ecd5..2b2bbe7499e6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -667,9 +667,6 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
msm_submit_retire(submit);
- pm_runtime_mark_last_busy(>pdev->dev);
- pm_runtime_put_autosuspend(>pdev->dev);
-
spin_lock_irqsave(>submit_lock, flags);
list_del(>node);
spin_unlock_irqrestore(>submit_lock, flags);
@@ -683,6 +680,9 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
mutex_unlock(>active_lock);
msm_gem_submit_put(submit);
+
+ pm_runtime_mark_last_busy(>pdev->dev);
+ pm_runtime_put_autosuspend(>pdev->dev);
}
static void retire_submits(struct msm_gpu *gpu)
--
2.31.1
[PATCH] [RFC] qcom_scm: hide Kconfig symbol
From: Arnd Bergmann Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available' ld.lld: error: undefined symbol: qcom_scm_is_available >>> referenced by adreno_gpu.c >>> gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in >>> archive drivers/built-in.a This can happen when CONFIG_ARCH_QCOM is disabled and we don't select QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd use a similar dependency here to what we have for QCOM_RPROC_COMMON, but that causes dependency loops from other things selecting QCOM_SCM. This appears to be an endless problem, so try something different this time: - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' but that is simply selected by all of its users - All the stubs in include/linux/qcom_scm.h can go away - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to allow compile-testing QCOM_SCM on all architectures. - To avoid a circular dependency chain involving RESET_CONTROLLER and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in the latter one to 'select'. The last bit is rather annoying, as drivers should generally never 'select' another subsystem, and about half the users of the reset controller interface do this anyway. Nevertheless, this version seems to pass all my randconfig tests and is more robust than any of the prior versions. Comments? Signed-off-by: Arnd Bergmann --- drivers/firmware/Kconfig| 4 +- drivers/gpu/drm/msm/Kconfig | 4 +- drivers/iommu/Kconfig | 2 +- drivers/media/platform/Kconfig | 2 +- drivers/mmc/host/Kconfig| 2 +- drivers/net/ipa/Kconfig | 1 + drivers/net/wireless/ath/ath10k/Kconfig | 2 +- drivers/pinctrl/qcom/Kconfig| 3 +- drivers/pinctrl/sunxi/Kconfig | 6 +-- include/linux/arm-smccc.h | 10 include/linux/qcom_scm.h| 71 - 11 files changed, 23 insertions(+), 84 deletions(-) diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 220a58cf0a44..f7dd82ef0b9c 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -203,9 +203,7 @@ config INTEL_STRATIX10_RSU Say Y here if you want Intel RSU support. config QCOM_SCM - tristate "Qcom SCM driver" - depends on ARM || ARM64 - depends on HAVE_ARM_SMCCC + tristate select RESET_CONTROLLER config QCOM_SCM_DOWNLOAD_MODE_DEFAULT diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index e9c6af78b1d7..3ddf739a6f9b 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -17,7 +17,7 @@ config DRM_MSM select DRM_SCHED select SHMEM select TMPFS - select QCOM_SCM if ARCH_QCOM + select QCOM_SCM select WANT_DEV_COREDUMP select SND_SOC_HDMI_CODEC if SND_SOC select SYNC_FILE @@ -55,7 +55,7 @@ config DRM_MSM_GPU_SUDO config DRM_MSM_HDMI_HDCP bool "Enable HDMI HDCP support in MSM DRM driver" - depends on DRM_MSM && QCOM_SCM + depends on DRM_MSM default y help Choose this option to enable HDCP state machine diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 124c41adeca1..989c83acbfee 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -308,7 +308,7 @@ config APPLE_DART config ARM_SMMU tristate "ARM Ltd. System MMU (SMMU) Support" depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y + select QCOM_SCM select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU if ARM diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 157c924686e4..80321e03809a 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -565,7 +565,7 @@ config VIDEO_QCOM_VENUS depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST select QCOM_MDT_LOADER if ARCH_QCOM - select QCOM_SCM if ARCH_QCOM + select QCOM_SCM select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV help diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 71313961cc54..95b3511b0560 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -547,7 +547,7 @@ config MMC_SDHCI_MSM depends on MMC_SDHCI_PLTFM select MMC_SDHCI_IO_ACCESSORS select MMC_CQHCI - select QCOM_SCM if MMC_CRYPTO && ARCH_QCOM + select QCOM_SCM if MMC_CRYPTO help This selects the Secure Digital
Re: [PATCH] drm/msm: Fix crash on dev file close
On Sun, Sep 26, 2021 at 12:36 PM Dmitry Baryshkov
wrote:
>
> On Sun, 26 Sept 2021 at 22:01, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > If the device file was opened prior to fw being available (such as from
> > initrd before rootfs is mounted, when the initrd does not contain GPU
> > fw), that would cause a later crash when the dev file is closed due to
> > unitialized submitqueues list:
>
> Reviewed-by: Dmitry Baryshkov
>
> I've sent a close version of this patch a day or so ago, but yours is
> better, as I did not touch rwlock init.
Thanks, sorry I did not see your patch earlier
BR,
-R
> >
> >CPU: 4 PID: 263 Comm: plymouthd Tainted: GW
> > 5.15.0-rc2-next-20210924 #2
> >Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN33WW(V2.06) 06/ 4/2019
> >pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> >pc : msm_submitqueue_close+0x30/0x190 [msm]
> >lr : msm_postclose+0x54/0xf0 [msm]
> >sp : 80001074bb80
> >x29: 80001074bb80 x28: 03ad80c4db80 x27: 03ad80dc5ab0
> >x26: x25: 03ad80dc5af8 x24: 03ad81e90800
> >x23: x22: 03ad81e90800 x21: 03ad8b35e788
> >x20: 03ad81e90878 x19: x18:
> >x17: x16: da15f14f7940 x15:
> >x14: x13: 0001 x12: 0040
> >x11: x10: x9 : da15cd18ff88
> >x8 : 03ad80c4db80 x7 : 0228 x6 :
> >x5 : 1793a4e807e636bd x4 : 03ad80c4db80 x3 : 03ad81e90878
> >x2 : x1 : 03ad80c4db80 x0 :
> >Call trace:
> > msm_submitqueue_close+0x30/0x190 [msm]
> > msm_postclose+0x54/0xf0 [msm]
> > drm_file_free.part.0+0x1cc/0x2e0 [drm]
> > drm_close_helper.isra.0+0x74/0x84 [drm]
> > drm_release+0x78/0x120 [drm]
> > __fput+0x78/0x23c
> > fput+0x1c/0x30
> > task_work_run+0xcc/0x22c
> > do_exit+0x304/0x9f4
> > do_group_exit+0x44/0xb0
> > __wake_up_parent+0x0/0x3c
> > invoke_syscall+0x50/0x120
> > el0_svc_common.constprop.0+0x4c/0xf4
> > do_el0_svc+0x30/0x9c
> > el0_svc+0x20/0x60
> > el0t_64_sync_handler+0xe8/0xf0
> > el0t_64_sync+0x1a0/0x1a4
> >Code: aa0003f5 a90153f3 f8408eb3 aa1303e0 (f85e8674)
> >---[ end trace 39b2fa37509a2be2 ]---
> >Fixing recursive fault but reboot is needed!
> >
> > Fixes: 86c2a0f000c1 drm/msm: ("Small submitqueue creation cleanup")
> > Reported-by: Steev Klimaszewski
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 3 +++
> > drivers/gpu/drm/msm/msm_submitqueue.c | 4
> > 2 files changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index f350de754f84..938765ad7109 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -689,6 +689,9 @@ static int context_init(struct drm_device *dev, struct
> > drm_file *file)
> > if (!ctx)
> > return -ENOMEM;
> >
> > + INIT_LIST_HEAD(>submitqueues);
> > + rwlock_init(>queuelock);
> > +
> > kref_init(>ref);
> > msm_submitqueue_init(dev, ctx);
> >
> > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > index 32a55d81b58b..7ce0771b5582 100644
> > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > @@ -140,10 +140,6 @@ int msm_submitqueue_init(struct drm_device *drm,
> > struct msm_file_private *ctx)
> > */
> > default_prio = DIV_ROUND_UP(max_priority, 2);
> >
> > - INIT_LIST_HEAD(>submitqueues);
> > -
> > - rwlock_init(>queuelock);
> > -
> > return msm_submitqueue_create(drm, ctx, default_prio, 0, NULL);
> > }
> >
> > --
> > 2.31.1
> >
>
>
> --
> With best wishes
> Dmitry
[PATCH] drm/i915/ttm: Rework object initialization slightly
We may end up in i915_ttm_bo_destroy() in an error path before the
object is fully initialized. In that case it's not correct to call
__i915_gem_free_object(), because that function
a) Assumes the gem object refcount is 0, which it isn't.
b) frees the placements which are owned by the caller until the
init_object() region ops returns successfully. Fix this by providing
a lightweight cleanup function i915_gem_object_fini() which is also
called by __i915_gem_free_object().
While doing this, also make sure we call dma_resv_fini() as part of
ordinary object destruction and not from the RCU callback that frees
the object. This will help track down bugs where the object is incorrectly
locked from an RCU lookup.
Finally, make sure the object isn't put on the region list until it's
either locked or fully initialized in order to block list processing of
partially initialized objects.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 18 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 32 +-
3 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6fb9afb65034..244e555f9bba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -89,6 +89,20 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
mutex_init(>mm.get_dma_page.lock);
}
+/**
+ * i915_gem_object_fini - Clean up a GEM object initialization
+ * @obj: The gem object cleanup
+ *
+ * This function cleans up gem object fields that are set up by
+ * drm_gem_private_object_init() and i915_gem_object_init().
+ */
+void i915_gem_object_fini(struct drm_i915_gem_object *obj)
+{
+ mutex_destroy(>mm.get_page.lock);
+ mutex_destroy(>mm.get_dma_page.lock);
+ dma_resv_fini(>base._resv);
+}
+
/**
* Mark up the object's coherency levels for a given cache_level
* @obj: #drm_i915_gem_object
@@ -174,7 +188,6 @@ void __i915_gem_free_object_rcu(struct rcu_head *head)
container_of(head, typeof(*obj), rcu);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
- dma_resv_fini(>base._resv);
i915_gem_object_free(obj);
GEM_BUG_ON(!atomic_read(>mm.free_count));
@@ -223,7 +236,6 @@ void __i915_gem_free_object(struct drm_i915_gem_object *obj)
obj_link))) {
GEM_BUG_ON(vma->obj != obj);
spin_unlock(>vma.lock);
-
__i915_vma_put(vma);
spin_lock(>vma.lock);
@@ -253,6 +265,8 @@ void __i915_gem_free_object(struct drm_i915_gem_object *obj)
if (obj->shares_resv_from)
i915_vm_resv_put(obj->shares_resv_from);
+
+ i915_gem_object_fini(obj);
}
static void __i915_gem_free_objects(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3043fcbd31bd..4f1af3b487d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -58,6 +58,9 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key,
unsigned alloc_flags);
+
+void i915_gem_object_fini(struct drm_i915_gem_object *obj);
+
struct drm_i915_gem_object *
i915_gem_object_create_shmem(struct drm_i915_private *i915,
resource_size_t size);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index b94497989995..fbe143f34e85 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -813,12 +813,9 @@ static void i915_ttm_adjust_lru(struct drm_i915_gem_object
*obj)
*/
static void i915_ttm_delayed_free(struct drm_i915_gem_object *obj)
{
- if (obj->ttm.created) {
- ttm_bo_put(i915_gem_to_ttm(obj));
- } else {
- __i915_gem_free_object(obj);
- call_rcu(>rcu, __i915_gem_free_object_rcu);
- }
+ GEM_BUG_ON(!obj->ttm.created);
+
+ ttm_bo_put(i915_gem_to_ttm(obj));
}
static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
@@ -898,16 +895,19 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- i915_ttm_backup_free(obj);
-
- /* This releases all gem object bindings to the backend. */
- __i915_gem_free_object(obj);
-
i915_gem_object_release_memory_region(obj);
mutex_destroy(>ttm.get_io_page.lock);
- if (obj->ttm.created)
+ if (obj->ttm.created) {
+ i915_ttm_backup_free(obj);
+
+ /* This releases all gem
Re: [PATCH] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
On Mon, Sep 27, 2021 at 7:15 AM Sumit Semwal wrote:
>
> Hello Greg,
>
> Thanks for the patch!
>
> On Sat, 25 Sept 2021 at 19:17, Greg Kroah-Hartman
> wrote:
>>
>> In order to better track where in the kernel the dma-buf code is used,
>> put the symbols in the namespace DMA_BUF and modify all users of the
>> symbols to properly import the namespace to not break the build at the
>> same time.
>>
>> Now the output of modinfo shows the use of these symbols, making it
>> easier to watch for users over time:
>>
>> $ modinfo drivers/misc/fastrpc.ko | grep import
>> import_ns: DMA_BUF
>>
>> Cc: Sumit Semwal
>> Cc: "Christian König"
>> Cc: Alex Deucher
>> Cc: "Pan, Xinhui"
>> Cc: David Airlie
>> Cc: Daniel Vetter
>> Cc: Maarten Lankhorst
>> Cc: Maxime Ripard
>> Cc: Thomas Zimmermann
>> Cc: Mauro Carvalho Chehab
>> Cc: Arnd Bergmann
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: Greg Kroah-Hartman
>
>
> With the addition of the 2 misses found by Arnd, please feel free to add my
> Acked-by: Sumit Semwal
Same here.
Acked-by: Alex Deucher
>>
>> ---
>>
>> The topic of dma-buf came up in the Maintainer's summit yesterday, and
>> one comment was to put the symbols in their own module namespace, to
>> make it easier to notice and track who was using them. This patch does
>> so, and finds some "interesting" users of the api already in the tree.
>>
>> Only test-built on x86 allmodconfig, don't know what other arches will
>> pick up, will let 0-day run on it for a bit...
>>
>> Comments?
>>
>>
>>
>>
>> drivers/dma-buf/dma-buf.c | 34 +--
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++
>> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 ++
>> drivers/gpu/drm/drm_prime.c | 3 ++
>> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 3 ++
>> drivers/gpu/drm/tegra/gem.c | 3 ++
>> drivers/gpu/drm/vmwgfx/ttm_object.c | 3 ++
>> drivers/infiniband/core/umem_dmabuf.c | 3 ++
>> .../media/common/videobuf2/videobuf2-core.c | 1 +
>> .../common/videobuf2/videobuf2-dma-contig.c | 1 +
>> .../media/common/videobuf2/videobuf2-dma-sg.c | 1 +
>> .../common/videobuf2/videobuf2-vmalloc.c | 1 +
>> drivers/misc/fastrpc.c| 1 +
>> .../staging/media/tegra-vde/dmabuf-cache.c| 3 ++
>> drivers/tee/tee_shm.c | 3 ++
>> drivers/virtio/virtio_dma_buf.c | 1 +
>> drivers/xen/gntdev-dmabuf.c | 3 ++
>> samples/vfio-mdev/mbochs.c| 1 +
>> 20 files changed, 60 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 63d32261b63f..6c2b5ea828a6 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -610,7 +610,7 @@ struct dma_buf *dma_buf_export(const struct
>> dma_buf_export_info *exp_info)
>> module_put(exp_info->owner);
>> return ERR_PTR(ret);
>> }
>> -EXPORT_SYMBOL_GPL(dma_buf_export);
>> +EXPORT_SYMBOL_NS_GPL(dma_buf_export, DMA_BUF);
>>
>> /**
>> * dma_buf_fd - returns a file descriptor for the given struct dma_buf
>> @@ -634,7 +634,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags)
>>
>> return fd;
>> }
>> -EXPORT_SYMBOL_GPL(dma_buf_fd);
>> +EXPORT_SYMBOL_NS_GPL(dma_buf_fd, DMA_BUF);
>>
>> /**
>> * dma_buf_get - returns the struct dma_buf related to an fd
>> @@ -660,7 +660,7 @@ struct dma_buf *dma_buf_get(int fd)
>>
>> return file->private_data;
>> }
>> -EXPORT_SYMBOL_GPL(dma_buf_get);
>> +EXPORT_SYMBOL_NS_GPL(dma_buf_get, DMA_BUF);
>>
>> /**
>> * dma_buf_put - decreases refcount of the buffer
>> @@ -679,7 +679,7 @@ void dma_buf_put(struct dma_buf *dmabuf)
>>
>> fput(dmabuf->file);
>> }
>> -EXPORT_SYMBOL_GPL(dma_buf_put);
>> +EXPORT_SYMBOL_NS_GPL(dma_buf_put, DMA_BUF);
>>
>> static void mangle_sg_table(struct sg_table *sg_table)
>> {
>> @@ -810,7 +810,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
>> device *dev,
>> dma_buf_detach(dmabuf, attach);
>> return ERR_PTR(ret);
>> }
>> -EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
>> +EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
>>
>> /**
>> * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
>> @@ -825,7 +825,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
>> *dmabuf,
>> {
>> return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
>> }
>> -EXPORT_SYMBOL_GPL(dma_buf_attach);
>> +EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
>>
>> static void __unmap_dma_buf(struct dma_buf_attachment *attach,
>> struct sg_table *sg_table,
>> @@ -871,7 +871,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
>> dma_buf_attachment *attach)
>>
>> kfree(attach);
>> }
>>
Re: [PATCH 1/2] drm/rockchip: dsi: hold pm-runtime across bind/unbind
On Fri, Sep 24, 2021 at 04:23:45PM -0700, Brian Norris wrote:
> In commit 59eb7193bef2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
>
> Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
> built either as modules or built-in.
>
> Side notes: it seems one is more likely to see this problem when the
> panel driver is built into the kernel. I've also seen this problem
> bisect down to commits that simply changed Kconfig dependencies, because
> it changed the order in which driver init functions were compiled into
> the kernel, and therefore the ordering and timing of built-in device
> probe.
>
> Fixes: 59eb7193bef2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Link:
> https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
> Reported-by:
> Cc:
> Signed-off-by: Brian Norris
> ---
This fixes the display enablement issue in Acer Chrometab 10 (RK3399
Gru-Scarlet) indeed.
Tested-by: Nícolas F. R. A. Prado
Thanks,
Nícolas
Re: linux-next: build warning after merge of the drm-misc tree
Hi,
On Sun, Sep 26, 2021 at 10:44 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> include/drm/drm_edid.h:530: warning: Function parameter or member
> 'vend_chr_1' not described in 'drm_edid_encode_panel_id'
> include/drm/drm_edid.h:530: warning: Excess function parameter 'vend_chr_3'
> description in 'drm_edid_encode_panel_id'
>
>
> Introduced by commit
>
> 7d1be0a09fa6 ("drm/edid: Fix EDID quirk compile error on older compilers")
Thanks for the report! Fix posted.
https://lore.kernel.org/r/20210927074104.1.Ibf22f2a0b75287a5d636c0570c11498648bf61c6@changeid
[PATCH] drm/edid: Fix drm_edid_encode_panel_id() kerneldoc warning
Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and
not 0, 2, 3) we were getting a kernel doc warning that looked like
this:
include/drm/drm_edid.h:530: warning:
Function parameter or member 'vend_chr_1' not described in
'drm_edid_encode_panel_id'
include/drm/drm_edid.h:530: warning:
Excess function parameter 'vend_chr_3' description in
'drm_edid_encode_panel_id'
Fix it.
Fixes: 7d1be0a09fa6 ("drm/edid: Fix EDID quirk compile error on older
compilers")
Reported-by: Stephen Rothwell
Signed-off-by: Douglas Anderson
---
include/drm/drm_edid.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 4d17cd04fff7..18f6c700f6d0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -511,8 +511,8 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
/**
* drm_edid_encode_panel_id - Encode an ID for matching against
drm_edid_get_panel_id()
* @vend_chr_0: First character of the vendor string.
- * @vend_chr_2: Second character of the vendor string.
- * @vend_chr_3: Third character of the vendor string.
+ * @vend_chr_1: Second character of the vendor string.
+ * @vend_chr_2: Third character of the vendor string.
* @product_id: The 16-bit product ID.
*
* This is a macro so that it can be calculated at compile time and used
--
2.33.0.685.g46640cef36-goog
Re: [PATCH v3 8/9] dma-buf/sync_file: Add SET_DEADLINE ioctl
On Mon, Sep 27, 2021 at 1:42 AM Pekka Paalanen wrote:
>
> On Fri, 3 Sep 2021 11:47:59 -0700
> Rob Clark wrote:
>
> > From: Rob Clark
> >
> > The initial purpose is for igt tests, but this would also be useful for
> > compositors that wait until close to vblank deadline to make decisions
> > about which frame to show.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/dma-buf/sync_file.c| 19 +++
> > include/uapi/linux/sync_file.h | 20
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > index 394e6e1e9686..f295772d5169 100644
> > --- a/drivers/dma-buf/sync_file.c
> > +++ b/drivers/dma-buf/sync_file.c
> > @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct
> > sync_file *sync_file,
> > return ret;
> > }
> >
> > +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file,
> > + unsigned long arg)
> > +{
> > + struct sync_set_deadline ts;
> > +
> > + if (copy_from_user(, (void __user *)arg, sizeof(ts)))
> > + return -EFAULT;
> > +
> > + if (ts.pad)
> > + return -EINVAL;
> > +
> > + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec,
> > ts.tv_nsec));
> > +
> > + return 0;
> > +}
> > +
> > static long sync_file_ioctl(struct file *file, unsigned int cmd,
> > unsigned long arg)
> > {
> > @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned
> > int cmd,
> > case SYNC_IOC_FILE_INFO:
> > return sync_file_ioctl_fence_info(sync_file, arg);
> >
> > + case SYNC_IOC_SET_DEADLINE:
> > + return sync_file_ioctl_set_deadline(sync_file, arg);
> > +
> > default:
> > return -ENOTTY;
> > }
> > diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
> > index ee2dcfb3d660..f67d4ffe7566 100644
> > --- a/include/uapi/linux/sync_file.h
> > +++ b/include/uapi/linux/sync_file.h
> > @@ -67,6 +67,18 @@ struct sync_file_info {
> > __u64 sync_fence_info;
> > };
> >
> > +/**
> > + * struct sync_set_deadline - set a deadline on a fence
> > + * @tv_sec: seconds elapsed since epoch
> > + * @tv_nsec: nanoseconds elapsed since the time given by the tv_sec
> > + * @pad: must be zero
>
> Hi Rob,
>
> I think you need to specify which clock this timestamp must be in.
>
> Which epoch? Sounds a bit like CLOCK_REALTIME to me which would not
> make sense.
It should be monotonic.. same clock as is used for vblank timestamps,
which I assume that would be the most straightforward thing for
compositors to use
BR,
-R
> Also I cannot guess how a compositor should be using this, so
> explaining the expected usage would be really good, with reasons for
> why should userspace bother.
>
>
> Thanks,
> pq
>
> > + */
> > +struct sync_set_deadline {
> > + __s64 tv_sec;
> > + __s32 tv_nsec;
> > + __u32 pad;
> > +};
> > +
> > #define SYNC_IOC_MAGIC '>'
> >
> > /**
> > @@ -95,4 +107,12 @@ struct sync_file_info {
> > */
> > #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct
> > sync_file_info)
> >
> > +
> > +/**
> > + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence
> > + *
> > + * Allows userspace to set a deadline on a fence, see
> > dma_fence_set_deadline()
> > + */
> > +#define SYNC_IOC_SET_DEADLINE_IOW(SYNC_IOC_MAGIC, 5, struct
> > sync_set_deadline)
> > +
> > #endif /* _UAPI_LINUX_SYNC_H */
>
[PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency
From: Arnd Bergmann
With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function
`drm_fb_helper_alloc_fbi':
(.text+0x10cc): undefined reference to `framebuffer_alloc'
Tighten the dependency so it is only allowed in the case that DRM can
link against FB.
Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Link: https://lore.kernel.org/all/20210721152211.2706171-1-a...@kernel.org/
Signed-off-by: Arnd Bergmann
---
I posted this in July, the patch is still required and should work
on its own.
---
drivers/gpu/drm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cea777ae7fb9..9199f53861ca 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -103,7 +103,7 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
- depends on FB
+ depends on FB=y || FB=DRM
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
--
2.29.2
[PATCH] [RESEND] drm/rcar: stop using 'imply' for dependencies
From: Arnd Bergmann The meaning of the 'imply' keyword has changed recently, and neither the old meaning (select the symbol if its dependencies are met) nor the new meaning (enable it by default, but let the user set any other setting) is what we want here. Work around this by adding two more Kconfig options that lead to the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS are enabled, that portion of the driver becomes usable, and no configuration results in a link error. This avoids a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin': rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable' arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init': Link: https://lore.kernel.org/all/2020041713.675905-5-a...@arndb.de/ Signed-off-by: Arnd Bergmann --- This was last posted as part of a longer series to rework the DRM dependencies in a more logical way. The rest of the series is still open, but this one is needed as a bug fix regardless of the rest. --- drivers/gpu/drm/rcar-du/Kconfig | 25 - 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index b47e74421e34..3e588ddba245 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -4,8 +4,6 @@ config DRM_RCAR_DU depends on DRM && OF depends on ARM || ARM64 depends on ARCH_RENESAS || COMPILE_TEST - imply DRM_RCAR_CMM - imply DRM_RCAR_LVDS select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER @@ -14,13 +12,17 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. -config DRM_RCAR_CMM - tristate "R-Car DU Color Management Module (CMM) Support" - depends on DRM && OF +config DRM_RCAR_USE_CMM + bool "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU + default DRM_RCAR_DU help Enable support for R-Car Color Management Module (CMM). +config DRM_RCAR_CMM + def_tristate DRM_RCAR_DU + depends on DRM_RCAR_USE_CMM + config DRM_RCAR_DW_HDMI tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support" depends on DRM && OF @@ -28,15 +30,20 @@ config DRM_RCAR_DW_HDMI help Enable support for R-Car Gen3 or RZ/G2 internal HDMI encoder. +config DRM_RCAR_USE_LVDS + bool "R-Car DU LVDS Encoder Support" + depends on DRM_BRIDGE && OF + default DRM_RCAR_DU + help + Enable support for the R-Car Display Unit embedded LVDS encoders. + config DRM_RCAR_LVDS - tristate "R-Car DU LVDS Encoder Support" - depends on DRM && DRM_BRIDGE && OF + def_tristate DRM_RCAR_DU + depends on DRM_RCAR_USE_LVDS select DRM_KMS_HELPER select DRM_PANEL select OF_FLATTREE select OF_OVERLAY - help - Enable support for the R-Car Display Unit embedded LVDS encoders. config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM -- 2.29.2
Re: [PATCH] backlight: hx8357: Add SPI device ID table
On Mon, Sep 27, 2021 at 02:24:17PM +0100, Daniel Thompson wrote: > In that case what is the point of including unconsumed driver data? Most > DT centric drivers that included this for modalias reasons leave it > NULL. It's mainly there because it's generated fairly mechanically from the OF ID table - there's no great reason for it to be there while all instantiation is done via DT. signature.asc Description: PGP signature
Re: [PATCH] backlight: hx8357: Add SPI device ID table
On Mon, Sep 27, 2021 at 12:47:27PM +0100, Mark Brown wrote: > On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote: > > > Based on this I had expected to find spi_get_device_id() and a ->driver_data > > somewhere in this patch. > > > Where will this .driver_data be consumed? > > It will never be consumed unless someone writes a board file - the > runtime match will still happen based on the DT compatible, this is only > there for the modalias. Ok... so I'm not going mad. In that case what is the point of including unconsumed driver data? Most DT centric drivers that included this for modalias reasons leave it NULL. I reviewed quite a few drivers this morning and I haven't seen a single one that includes unreachable driver data in this manner. Unless there's a good reason I'd prefer backlight to follow the prior art! Daniel.
Re: [PATCH] drm/amdgpu: fix warning for overflow check
Am 27.09.21 um 14:58 schrieb Arnd Bergmann:
From: Arnd Bergmann
The overflow check in amdgpu_bo_list_create() causes a warning with
clang-14 on 64-bit architectures, since the limit can never be
exceeded.
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison
of constant 256204778801521549 with expression of type 'unsigned int' is always
false [-Werror,-Wtautological-constant-out-of-range-compare]
if (num_entries > (SIZE_MAX - sizeof(struct amdgpu_bo_list))
~~~ ^ ~~
The check remains useful for 32-bit architectures, so just avoid the
warning by using size_t as the type for the count.
Fixes: 920990cb080a ("drm/amdgpu: allocate the bo_list array after the list")
Signed-off-by: Arnd Bergmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 15c45b2a3983..714178f1b6c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -61,7 +61,7 @@ static void amdgpu_bo_list_free(struct kref *ref)
int amdgpu_bo_list_create(struct amdgpu_device *adev, struct drm_file *filp,
struct drm_amdgpu_bo_list_entry *info,
- unsigned num_entries, struct amdgpu_bo_list **result)
+ size_t num_entries, struct amdgpu_bo_list **result)
{
unsigned last_entry = 0, first_userptr = num_entries;
struct amdgpu_bo_list_entry *array;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
index c905a4cfc173..044b41f0bfd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
@@ -61,7 +61,7 @@ int amdgpu_bo_create_list_entry_array(struct
drm_amdgpu_bo_list_in *in,
int amdgpu_bo_list_create(struct amdgpu_device *adev,
struct drm_file *filp,
struct drm_amdgpu_bo_list_entry *info,
-unsigned num_entries,
+size_t num_entries,
struct amdgpu_bo_list **list);
static inline struct amdgpu_bo_list_entry *
[PATCH] drm/amdgpu: fix warning for overflow check
From: Arnd Bergmann
The overflow check in amdgpu_bo_list_create() causes a warning with
clang-14 on 64-bit architectures, since the limit can never be
exceeded.
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison
of constant 256204778801521549 with expression of type 'unsigned int' is always
false [-Werror,-Wtautological-constant-out-of-range-compare]
if (num_entries > (SIZE_MAX - sizeof(struct amdgpu_bo_list))
~~~ ^ ~~
The check remains useful for 32-bit architectures, so just avoid the
warning by using size_t as the type for the count.
Fixes: 920990cb080a ("drm/amdgpu: allocate the bo_list array after the list")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 15c45b2a3983..714178f1b6c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -61,7 +61,7 @@ static void amdgpu_bo_list_free(struct kref *ref)
int amdgpu_bo_list_create(struct amdgpu_device *adev, struct drm_file *filp,
struct drm_amdgpu_bo_list_entry *info,
- unsigned num_entries, struct amdgpu_bo_list **result)
+ size_t num_entries, struct amdgpu_bo_list **result)
{
unsigned last_entry = 0, first_userptr = num_entries;
struct amdgpu_bo_list_entry *array;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
index c905a4cfc173..044b41f0bfd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h
@@ -61,7 +61,7 @@ int amdgpu_bo_create_list_entry_array(struct
drm_amdgpu_bo_list_in *in,
int amdgpu_bo_list_create(struct amdgpu_device *adev,
struct drm_file *filp,
struct drm_amdgpu_bo_list_entry *info,
-unsigned num_entries,
+size_t num_entries,
struct amdgpu_bo_list **list);
static inline struct amdgpu_bo_list_entry *
--
2.29.2
Re: [PATCH v2 7/9] vfio/ccw: Remove private->mdev
On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote: > On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote: > > Having a mdev pointer floating about in addition to a struct > > vfio_device > > is confusing. It is only used for three things: > > > > - Getting the mdev 'struct device *' - this is the same as > > private->vdev.dev > > > > - Printing the uuid of the mdev in logging. The uuid is also the > > dev_name > > of the mdev so this is the same string as > > dev_name(private->vdev.dev) > > > > - A weird attempt to fence the vfio_ccw_sch_io_todo() work. This work > > is > > only queued during states IDLE/PROCESSING/PENDING and flushed when > > entering CLOSED. Thus the work already cannot run when the mdev is > > NULL. > > Remove it. > > > > Signed-off-by: Jason Gunthorpe > > drivers/s390/cio/vfio_ccw_drv.c | 6 ++-- > > drivers/s390/cio/vfio_ccw_fsm.c | 48 + > > drivers/s390/cio/vfio_ccw_ops.c | 16 -- > > drivers/s390/cio/vfio_ccw_private.h | 2 -- > > include/linux/mdev.h| 4 --- > > 5 files changed, 30 insertions(+), 46 deletions(-) > > I like this patch. Unfortunately it depends on the removal of a hunk in > patch 4, which sets the FSM state to different values based on whether > private->mdev is NULL or not, so can't go on its own. Need to spend > more time thinking about that patch. The FSM patch is important, really what is happening is the FSM logic takes on the roles that was being split all over the place with other logic, like this mdev stuff. To make that work we need a FSM that makes sense.. Jason
Re: [PATCH] drm/amdgpu: fix clang out-of-range warning
In general that change looks good. But what configuration is that?
Background is that it doesn't make much sense to compile the amdgpu
driver on systems where resource_size_t is only 32bit.
Christian.
Am 27.09.21 um 14:19 schrieb Arnd Bergmann:
From: Arnd Bergmann
clang-14 points out that comparing an 'unsigned int' against a large
64-bit constantn is pointless:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1206:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned
int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
res->start > 0x1ull)
Rephrase the comparison using the upper_32_bits() macro, which should
keep it legible while avoiding the warning.
Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR
resize")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ab3794c42d36..741a55031ca1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1203,7 +1203,7 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
pci_bus_for_each_resource(root, res, i) {
if (res && res->flags & (IORESOURCE_MEM | IORESOURCE_MEM_64) &&
- res->start > 0x1ull)
+ upper_32_bits(res->start) != 0)
break;
}
[PATCH] gpu: amd: replace open-coded offsetof() with builtin
From: Arnd Bergmann The two AMD drivers have their own custom offsetof() implementation that now triggers a warning with recent versions of clang: drivers/gpu/drm/radeon/radeon_atombios.c:133:14: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] Change all the instances to use the normal offsetof() provided by the kernel that does not have this problem. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/amd/display/dc/bios/command_table2.c | 4 +--- drivers/gpu/drm/amd/include/atombios.h| 2 +- drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h | 4 ++-- drivers/gpu/drm/radeon/atombios.h | 2 +- 4 files changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c index f1f672a997d7..4f37be727332 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c @@ -44,9 +44,7 @@ bp->base.ctx->logger #define GET_INDEX_INTO_MASTER_TABLE(MasterOrData, FieldName)\ - (((char *)(&((\ - struct atom_master_list_of_##MasterOrData##_functions_v2_1 *)0)\ - ->FieldName)-(char *)0)/sizeof(uint16_t)) + (offsetof(struct atom_master_list_of_##MasterOrData##_functions_v2_1, FieldName) / sizeof(uint16_t)) #define EXEC_BIOS_CMD_TABLE(fname, params)\ (amdgpu_atom_execute_table(((struct amdgpu_device *)bp->base.ctx->driver_context)->mode_info.atom_context, \ diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h index 6a505d1b82a5..da895d1f3b4f 100644 --- a/drivers/gpu/drm/amd/include/atombios.h +++ b/drivers/gpu/drm/amd/include/atombios.h @@ -7148,7 +7148,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableFormatRevision )&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableContentRevision)&0x3F) #else // not __cplusplus -#define GetIndexIntoMasterTable(MasterOrData, FieldName) (((char*)(&((ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES*)0)->FieldName)-(char*)0)/sizeof(USHORT)) +#define GetIndexIntoMasterTable(MasterOrData, FieldName) (offsetof(ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES, FieldName) / sizeof(USHORT)) #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableFormatRevision)&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableContentRevision)&0x3F) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h index b7e2651b570b..2fc1733bcdcf 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomfwctrl.h @@ -29,9 +29,9 @@ typedef enum atom_smu9_syspll0_clock_id BIOS_CLKID; #define GetIndexIntoMasterCmdTable(FieldName) \ - (((char*)(&((struct atom_master_list_of_command_functions_v2_1*)0)->FieldName)-(char*)0)/sizeof(uint16_t)) + (offsetof(struct atom_master_list_of_command_functions_v2_1, FieldName) / sizeof(uint16_t)) #define GetIndexIntoMasterDataTable(FieldName) \ - (((char*)(&((struct atom_master_list_of_data_tables_v2_1*)0)->FieldName)-(char*)0)/sizeof(uint16_t)) + (offsetof(struct atom_master_list_of_data_tables_v2_1, FieldName) / sizeof(uint16_t)) #define PP_ATOMFWCTRL_MAX_VOLTAGE_ENTRIES 32 diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h index 83e8b8547f9b..bd5dc09e860f 100644 --- a/drivers/gpu/drm/radeon/atombios.h +++ b/drivers/gpu/drm/radeon/atombios.h @@ -5983,7 +5983,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableFormatRevision )&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) (((static_cast(TABLE_HEADER_OFFSET))->ucTableContentRevision)&0x3F) #else // not __cplusplus -#defineGetIndexIntoMasterTable(MasterOrData, FieldName) (((char*)(&((ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES*)0)->FieldName)-(char*)0)/sizeof(USHORT)) +#defineGetIndexIntoMasterTable(MasterOrData, FieldName) (offsetof(ATOM_MASTER_LIST_OF_##MasterOrData##_TABLES, FieldName)/sizeof(USHORT)) #define GET_COMMAND_TABLE_COMMANDSET_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableFormatRevision)&0x3F) #define GET_COMMAND_TABLE_PARAMETER_REVISION(TABLE_HEADER_OFFSET) ATOM_COMMON_TABLE_HEADER*)TABLE_HEADER_OFFSET)->ucTableContentRevision)&0x3F) -- 2.29.2
[PATCH] drm/amdgpu: fix clang out-of-range warning
From: Arnd Bergmann
clang-14 points out that comparing an 'unsigned int' against a large
64-bit constantn is pointless:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1206:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned
int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
res->start > 0x1ull)
Rephrase the comparison using the upper_32_bits() macro, which should
keep it legible while avoiding the warning.
Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR
resize")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ab3794c42d36..741a55031ca1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1203,7 +1203,7 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
pci_bus_for_each_resource(root, res, i) {
if (res && res->flags & (IORESOURCE_MEM | IORESOURCE_MEM_64) &&
- res->start > 0x1ull)
+ upper_32_bits(res->start) != 0)
break;
}
--
2.29.2
Re: [PATCH v2 3/9] vfio/ccw: Convert to use vfio_register_group_dev()
On Fri, Sep 24, 2021 at 04:37:43PM -0400, Eric Farman wrote:
> > @@ -528,6 +534,7 @@ static int __init vfio_ccw_sch_init(void)
> >
> > static void __exit vfio_ccw_sch_exit(void)
> > {
> > + mdev_unregister_driver(_ccw_mdev_driver);
>
> Wouldn't it be better to mirror the unwind-init case, such that the
> above goes...
>
> > css_driver_unregister(_ccw_sch_driver);
> > isc_unregister(VFIO_CCW_ISC);
>
> ...here?
Yes, I switched it
Thanks,
Jason
Re: [PATCH] backlight: hx8357: Add SPI device ID table
On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote: > Based on this I had expected to find spi_get_device_id() and a ->driver_data > somewhere in this patch. > Where will this .driver_data be consumed? It will never be consumed unless someone writes a board file - the runtime match will still happen based on the DT compatible, this is only there for the modalias. signature.asc Description: PGP signature
Re: [PATCH v5 01/13] drm/ttm: stop calling tt_swapin in vm_access
Any objections that I just push patches 1-7 to drm-misc-next?
Christian.
Am 27.09.21 um 13:41 schrieb Matthew Auld:
In commit:
commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
Author: Felix Kuehling
Date: Thu Jul 13 17:01:16 2017 -0400
drm/ttm: Implement vm_operations_struct.access v2
we added the vm_access hook, where we also directly call tt_swapin for
some reason. If something is swapped-out then the ttm_tt must also be
unpopulated, and since access_kmap should also call tt_populate, if
needed, then swapping-in will already be handled there.
If anything, calling tt_swapin directly here would likely always fail
since the tt->pages won't yet be populated, or worse since the tt->pages
array is never actually cleared in unpopulate this might lead to a nasty
uaf.
Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Reviewed-by: Thomas Hellström
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..5b9b7fd01a69 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -519,11 +519,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
switch (bo->resource->mem_type) {
case TTM_PL_SYSTEM:
- if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
- ret = ttm_tt_swapin(bo->ttm);
- if (unlikely(ret != 0))
- return ret;
- }
fallthrough;
case TTM_PL_TT:
ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
Re: [PATCH] drm/i915/audio: Use BIOS provided value for RKL HDA link
On Mon, 06 Sep 2021, Kai Vehmanen wrote:
> Hi,
>
> On Mon, 6 Sep 2021, Kai-Heng Feng wrote:
>
>> Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in
>> driver") makes HDMI audio on Lenovo P350 disappear.
>>
>> So in addition to TGL, extend the logic to RKL to use BIOS provided
>> value to fix the regression.
>
> thanks Kai-Heng! We were not aware of commercial RKL systems following the
> old BIOS guidance, but given you just hit one, then this definitely is
> needed:
>
> Reviewed-by: Kai Vehmanen
This had fallen between the cracks, pushed now. Thanks for the patch and
review.
BR,
Jani.
>
> Br, Kai
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH v5 13/13] drm/i915/ttm: enable shmem tt backend
Turn on the shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 46d57541c0b2..4ae630fbc5cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1093,6 +1093,7 @@ static u64 i915_ttm_mmap_offset(struct
drm_i915_gem_object *obj)
static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
.name = "i915_gem_object_ttm",
+ .flags = I915_GEM_OBJECT_IS_SHRINKABLE,
.get_pages = i915_ttm_get_pages,
.put_pages = i915_ttm_put_pages,
--
2.26.3
[PATCH v5 11/13] drm/i915/ttm: make evicted shmem pages visible to the shrinker
We currently just evict lmem objects to system memory when under memory
pressure, and in the next patch we want to use the shmem backend even
for this case. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets migrated back to lmem when touched again.
For all cases we can just adjust the i915 shrinker LRU each time we also
adjust the TTM LRU. The two cases we care about are:
1) When something is moved by TTM, including when initially populating
an object. Importantly this covers the case where TTM moves something from
lmem <-> smem, outside of the normal get_pages() interface, which
should still ensure the shmem pages underneath are reclaimable.
2) When calling into i915_gem_object_unlock(). The unlock should
ensure the object is removed from the shinker LRU, if it was indeed
swapped out, or just purged, when the shrinker drops the object lock.
We can optimise this(if needed) by tracking if the object is already
visible to the shrinker(protected by the object lock), so we don't touch
the shrinker LRU more than needed.
v2(Thomas)
- Handle managing the shrinker LRU in adjust_lru, where it is always
safe to touch the object.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 29 +++-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 28 +++
3 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1c9a1d8d3434..640dfbf1f01e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -523,6 +523,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object *obj);
void i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj);
+void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj);
void i915_gem_object_make_purgeable(struct drm_i915_gem_object *obj);
static inline bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 0440696f786a..4b6b2bb6f180 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -487,13 +487,12 @@ void i915_gem_object_make_unshrinkable(struct
drm_i915_gem_object *obj)
spin_unlock_irqrestore(>mm.obj_lock, flags);
}
-static void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj,
- struct list_head *head)
+static void ___i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj,
+ struct list_head *head)
{
struct drm_i915_private *i915 = obj_to_i915(obj);
unsigned long flags;
- GEM_BUG_ON(!i915_gem_object_has_pages(obj));
if (!i915_gem_object_is_shrinkable(obj))
return;
@@ -512,6 +511,21 @@ static void __i915_gem_object_make_shrinkable(struct
drm_i915_gem_object *obj,
spin_unlock_irqrestore(>mm.obj_lock, flags);
}
+/**
+ * __i915_gem_object_make_shrinkable - Move the object to the tail of the
+ * shrinkable list. Objects on this list might be swapped out. Used with
+ * WILLNEED objects.
+ * @obj: The GEM object.
+ *
+ * DO NOT USE. This is intended to be called on very special objects that don't
+ * yet have mm.pages, but are guaranteed to have potentially reclaimable pages
+ * underneath.
+ */
+void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj)
+{
+ ___i915_gem_object_make_shrinkable(obj,
+ _to_i915(obj)->mm.shrink_list);
+}
/**
* i915_gem_object_make_shrinkable - Move the object to the tail of the
@@ -523,8 +537,8 @@ static void __i915_gem_object_make_shrinkable(struct
drm_i915_gem_object *obj,
*/
void i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj)
{
- __i915_gem_object_make_shrinkable(obj,
- _to_i915(obj)->mm.shrink_list);
+ GEM_BUG_ON(!i915_gem_object_has_pages(obj));
+ __i915_gem_object_make_shrinkable(obj);
}
/**
@@ -538,6 +552,7 @@ void i915_gem_object_make_shrinkable(struct
drm_i915_gem_object *obj)
*/
void i915_gem_object_make_purgeable(struct drm_i915_gem_object *obj)
{
- __i915_gem_object_make_shrinkable(obj,
- _to_i915(obj)->mm.purge_list);
+ GEM_BUG_ON(!i915_gem_object_has_pages(obj));
+ ___i915_gem_object_make_shrinkable(obj,
+ _to_i915(obj)->mm.purge_list);
}
diff --git
[PATCH v5 10/13] drm/i915: try to simplify make_{un}shrinkable
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself is no longer shrinkable(transitioning from purgeable <->
shrinkable doesn't seem to be a thing), for example in the ppGTT
insertion paths we should now be careful not to needlessly call
make_unshrinkable multiple times. Outside of that there is some fallout
in intel_context which relies on nesting calls to shrink_pin.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 9
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 16 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 52 +--
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 -
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 -
drivers/gpu/drm/i915/gt/intel_context.c | 9 +---
7 files changed, 41 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6fb9afb65034..e8265a432fcb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -305,15 +305,6 @@ static void i915_gem_free_object(struct drm_gem_object
*gem_obj)
*/
atomic_inc(>mm.free_count);
- /*
-* This serializes freeing with the shrinker. Since the free
-* is delayed, first by RCU then by the workqueue, we want the
-* shrinker to be able to free pages of unreferenced objects,
-* or else we may oom whilst there are plenty of deferred
-* freed objects.
-*/
- i915_gem_object_make_unshrinkable(obj);
-
/*
* Since we require blocking on struct_mutex to unbind the freed
* object from the GPU before releasing resources back to the
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index f0fb17be2f7a..e4f8a6774da8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -461,7 +461,6 @@ struct drm_i915_gem_object {
* instead go through the pin/unpin interfaces.
*/
atomic_t pages_pin_count;
- atomic_t shrink_pin;
/**
* Priority list of potential placements for this object.
@@ -522,7 +521,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_dma_page;
/**
-* Element within i915->mm.unbound_list or i915->mm.bound_list,
+* Element within i915->mm.shrink_list or i915->mm.purge_list,
* locked by i915->mm.obj_lock.
*/
struct list_head link;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8eb1c3a6fc9c..f0df1394d7f6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -64,28 +64,16 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
GEM_BUG_ON(i915_gem_object_has_tiling_quirk(obj));
i915_gem_object_set_tiling_quirk(obj);
GEM_BUG_ON(!list_empty(>mm.link));
- atomic_inc(>mm.shrink_pin);
shrinkable = false;
}
if (shrinkable) {
- struct list_head *list;
- unsigned long flags;
-
assert_object_held(obj);
- spin_lock_irqsave(>mm.obj_lock, flags);
-
- i915->mm.shrink_count++;
- i915->mm.shrink_memory += obj->base.size;
if (obj->mm.madv != I915_MADV_WILLNEED)
- list = >mm.purge_list;
+ i915_gem_object_make_purgeable(obj);
else
- list = >mm.shrink_list;
- list_add_tail(>mm.link, list);
-
- atomic_set(>mm.shrink_pin, 0);
- spin_unlock_irqrestore(>mm.obj_lock, flags);
+ i915_gem_object_make_shrinkable(obj);
}
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index cc80bd23d323..0440696f786a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -460,23 +460,26 @@ void i915_gem_shrinker_taints_mutex(struct
drm_i915_private *i915,
#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
+/**
+ * i915_gem_object_make_unshrinkable - Hide the object from the shrinker. By
+ * default all object types that support shrinking(see IS_SHRINKABLE), will
also
+ * make the object visible to the shrinker after allocating
[PATCH v5 12/13] drm/i915/ttm: use cached system pages when evicting lmem
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 194e5f1deda8..46d57541c0b2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -134,11 +134,11 @@ static enum ttm_caching
i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
{
/*
-* Objects only allowed in system get cached cpu-mappings.
-* Other objects get WC mapping for now. Even if in system.
+* Objects only allowed in system get cached cpu-mappings, or when
+* evicting lmem-only buffers to system for swapping. Other objects get
+* WC mapping for now. Even if in system.
*/
- if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
- obj->mm.n_placements <= 1)
+ if (obj->mm.n_placements <= 1)
return ttm_cached;
return ttm_write_combined;
--
2.26.3
[PATCH v5 07/13] drm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse to fault (prime-) imported pages
we introduced the restriction that imported pages should not be directly
mappable through TTM(this also extends to userptr). In the next patch we
want to introduce a shmem_tt backend, which should follow all the
existing rules with TTM_PAGE_FLAG_EXTERNAL, since it will need to handle
swapping itself, but with the above mapping restriction lifted.
v2(Christian):
- Don't OR together EXTERNAL and EXTERNAL_MAPPABLE in the definition
of EXTERNAL_MAPPABLE, just leave it the caller to handle this
correctly, otherwise we might encounter subtle issues.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_tt.c| 3 +++
include/drm/ttm/ttm_tt.h| 19 ---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 950f4f132802..33680c94127c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -163,8 +163,10 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
* (if at all) by redirecting mmap to the exporter.
*/
if (bo->ttm && (bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL)) {
- dma_resv_unlock(bo->base.resv);
- return VM_FAULT_SIGBUS;
+ if (!(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE)) {
+ dma_resv_unlock(bo->base.resv);
+ return VM_FAULT_SIGBUS;
+ }
}
return 0;
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 86f31fde6e35..7e83c00a3f48 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -84,6 +84,9 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
if (unlikely(bo->ttm == NULL))
return -ENOMEM;
+ WARN_ON(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE &&
+ !(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL));
+
return 0;
}
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 86d74069be3e..f20832139815 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -67,13 +67,26 @@ struct ttm_tt {
* Note that enum ttm_bo_type.ttm_bo_type_sg objects will always enable
* this flag.
*
+* TTM_TT_FLAG_EXTERNAL_MAPPABLE: Same behaviour as
+* TTM_TT_FLAG_EXTERNAL, but with the reduced restriction that it is
+* still valid to use TTM to map the pages directly. This is useful when
+* implementing a ttm_tt backend which still allocates driver owned
+* pages underneath(say with shmem).
+*
+* Note that since this also implies TTM_TT_FLAG_EXTERNAL, the usage
+* here should always be:
+*
+* page_flags = TTM_TT_FLAG_EXTERNAL |
+*TTM_TT_FLAG_EXTERNAL_MAPPABLE;
+*
* TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is
* set by TTM after ttm_tt_populate() has successfully returned, and is
* then unset when TTM calls ttm_tt_unpopulate().
*/
-#define TTM_TT_FLAG_SWAPPED(1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL (1 << 2)
+#define TTM_TT_FLAG_SWAPPED(1 << 0)
+#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
+#define TTM_TT_FLAG_EXTERNAL (1 << 2)
+#define TTM_TT_FLAG_EXTERNAL_MAPPABLE (1 << 3)
#define TTM_TT_FLAG_PRIV_POPULATED (1 << 31)
uint32_t page_flags;
--
2.26.3
[PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to check if the object is even still shrinkable; in between us
dropping the shrinker LRU lock and acquiring the object lock it could for
example have been moved. Also we need to differentiate between
"lazy" shrinking and the immediate writeback mode. Also later we need to
handle objects which don't even have mm.pages, so bundling this into
put_pages() would require somehow handling that edge case, hence
just letting the ttm backend handle everything in try_to_writeback
doesn't seem too bad.
v3(Thomas):
- Likely a bad idea to touch the object from the unpopulate hook,
since it's not possible to hold a reference, without also creating
circular dependency, so likely this is too fragile. For now just
ensure we at least mark the pages as dirty/accessed when called from the
shrinker on WILLNEED objects.
- s/try_to_writeback/shrinker_release_pages, since this can do more
than just writeback.
- Get rid of do_backup boolean and just set the SWAPPED flag prior to
calling unpopulate.
- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, since
these just get skipped anyway. We can try to come up with something
better later.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 240 --
5 files changed, 245 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3043fcbd31bd..1c9a1d8d3434 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -601,6 +601,14 @@ int i915_gem_object_wait_migration(struct
drm_i915_gem_object *obj,
bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
enum intel_memory_type type);
+struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region *mr,
+ struct address_space *mapping,
+ unsigned int max_segment);
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup);
+void __shmem_writeback(size_t size, struct address_space *mapping);
+
#ifdef CONFIG_MMU_NOTIFIER
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index fa2ba9e2a4d0..f0fb17be2f7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -56,6 +56,8 @@ struct drm_i915_gem_object_ops {
struct sg_table *pages);
void (*truncate)(struct drm_i915_gem_object *obj);
void (*writeback)(struct drm_i915_gem_object *obj);
+ int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
+ bool should_writeback);
int (*pread)(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_pread *arg);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 36b711ae9e28..19e55cc29a15 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -25,8 +25,8 @@ static void check_release_pagevec(struct pagevec *pvec)
cond_resched();
}
-static void shmem_free_st(struct sg_table *st, struct address_space *mapping,
- bool dirty, bool backup)
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup)
{
struct sgt_iter sgt_iter;
struct pagevec pvec;
@@ -52,10 +52,10 @@ static void shmem_free_st(struct sg_table *st, struct
address_space *mapping,
kfree(st);
}
-static struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
- size_t size, struct intel_memory_region
*mr,
- struct address_space *mapping,
- unsigned int max_segment)
+struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region *mr,
+ struct address_space *mapping,
+
[PATCH v5 08/13] drm/i915/gem: Break out some shmem backend utils
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute the page sizes using
the dma segments rather than using the physical page address segments.
v2(Reported-by: kernel test robot )
- Make sure we initialise the mapping on the error path in
shmem_get_pages()
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 181 +-
1 file changed, 106 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 11f072193f3b..36b711ae9e28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -25,46 +25,61 @@ static void check_release_pagevec(struct pagevec *pvec)
cond_resched();
}
-static int shmem_get_pages(struct drm_i915_gem_object *obj)
+static void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup)
{
- struct drm_i915_private *i915 = to_i915(obj->base.dev);
- struct intel_memory_region *mem = obj->mm.region;
- const unsigned long page_count = obj->base.size / PAGE_SIZE;
+ struct sgt_iter sgt_iter;
+ struct pagevec pvec;
+ struct page *page;
+
+ mapping_clear_unevictable(mapping);
+
+ pagevec_init();
+ for_each_sgt_page(page, sgt_iter, st) {
+ if (dirty)
+ set_page_dirty(page);
+
+ if (backup)
+ mark_page_accessed(page);
+
+ if (!pagevec_add(, page))
+ check_release_pagevec();
+ }
+ if (pagevec_count())
+ check_release_pagevec();
+
+ sg_free_table(st);
+ kfree(st);
+}
+
+static struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region
*mr,
+ struct address_space *mapping,
+ unsigned int max_segment)
+{
+ const unsigned long page_count = size / PAGE_SIZE;
unsigned long i;
- struct address_space *mapping;
struct sg_table *st;
struct scatterlist *sg;
- struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
- unsigned int max_segment = i915_sg_segment_size();
- unsigned int sg_page_sizes;
gfp_t noreclaim;
int ret;
- /*
-* Assert that the object is not currently in any GPU domain. As it
-* wasn't in the GTT, there shouldn't be any way it could have been in
-* a GPU cache
-*/
- GEM_BUG_ON(obj->read_domains & I915_GEM_GPU_DOMAINS);
- GEM_BUG_ON(obj->write_domain & I915_GEM_GPU_DOMAINS);
-
/*
* If there's no chance of allocating enough pages for the whole
* object, bail early.
*/
- if (obj->base.size > resource_size(>region))
- return -ENOMEM;
+ if (size > resource_size(>region))
+ return ERR_PTR(-ENOMEM);
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
-rebuild_st:
if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
kfree(st);
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
}
/*
@@ -73,14 +88,12 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
*
* Fail silently without starting the shrinker
*/
- mapping = obj->base.filp->f_mapping;
mapping_set_unevictable(mapping);
noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
sg = st->sgl;
st->nents = 0;
- sg_page_sizes = 0;
for (i = 0; i < page_count; i++) {
const unsigned int shrink[] = {
I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
@@ -135,10 +148,9 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (!i ||
sg->length >= max_segment ||
page_to_pfn(page) != last_pfn + 1) {
- if (i) {
- sg_page_sizes |= sg->length;
+ if (i)
sg = sg_next(sg);
- }
+
st->nents++;
sg_set_page(sg, page, PAGE_SIZE, 0);
} else {
@@ -149,14 +161,65 @@ static int shmem_get_pages(struct drm_i915_gem_object
*obj)
/* Check
[PATCH v5 04/13] drm/ttm: remove TTM_PAGE_FLAG_NO_RETRY
No longer used it seems. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Christian König Reviewed-by: Christian König --- include/drm/ttm/ttm_tt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index 89b15d673b22..842ce756213c 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -41,7 +41,6 @@ struct ttm_operation_ctx; #define TTM_PAGE_FLAG_SWAPPED (1 << 4) #define TTM_PAGE_FLAG_ZERO_ALLOC (1 << 6) #define TTM_PAGE_FLAG_SG (1 << 8) -#define TTM_PAGE_FLAG_NO_RETRY (1 << 9) #define TTM_PAGE_FLAG_PRIV_POPULATED (1 << 31) -- 2.26.3
