[PATCH v2 4/9] drm/msm/a6xx: add A640/A650 to gpulist
Add Adreno 640 and 650 GPU info to the gpulist.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10 +
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index cb3a6e597d76..1156f72532a4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -189,6 +189,30 @@ static const struct adreno_info gpulist[] = {
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a6xx_gpu_init,
.zapfw = "a630_zap.mdt",
+ }, {
+ .rev = ADRENO_REV(6, 4, 0, ANY_ID),
+ .revn = 640,
+ .name = "A640",
+ .fw = {
+ [ADRENO_FW_SQE] = "a630_sqe.fw",
+ [ADRENO_FW_GMU] = "a640_gmu.bin",
+ },
+ .gmem = SZ_1M,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .init = a6xx_gpu_init,
+ .zapfw = "a640_zap.mdt",
+ }, {
+ .rev = ADRENO_REV(6, 5, 0, ANY_ID),
+ .revn = 650,
+ .name = "A650",
+ .fw = {
+ [ADRENO_FW_SQE] = "a650_sqe.fw",
+ [ADRENO_FW_GMU] = "a650_gmu.bin",
+ },
+ .gmem = SZ_1M + SZ_128K,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .init = a6xx_gpu_init,
+ .zapfw = "a650_zap.mdt",
},
};
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 1d5c43c22269..a7647eaacc7a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -197,7 +197,7 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
uint64_t *value)
*value = adreno_gpu->gmem;
return 0;
case MSM_PARAM_GMEM_BASE:
- *value = 0x10;
+ *value = !adreno_is_a650(adreno_gpu) ? 0x10 : 0;
return 0;
case MSM_PARAM_CHIP_ID:
*value = adreno_gpu->rev.patchid |
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 9ff4e550e7bd..88ae1b2813ef 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -237,6 +237,16 @@ static inline int adreno_is_a630(struct adreno_gpu *gpu)
return gpu->revn == 630;
}
+static inline int adreno_is_a640(struct adreno_gpu *gpu)
+{
+ return gpu->revn == 640;
+}
+
+static inline int adreno_is_a650(struct adreno_gpu *gpu)
+{
+ return gpu->revn == 650;
+}
+
int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value);
const struct firmware *adreno_request_fw(struct adreno_gpu *adreno_gpu,
const char *fwname);
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for the device tree bindings for the same. Signed-off-by: Krishna Manikandan Changes in v2: - Changed dpu to DPU (Sam Ravnborg) - Fixed indentation issues (Sam Ravnborg) - Added empty line between different properties (Sam Ravnborg) - Replaced reference txt files with their corresponding yaml files (Sam Ravnborg) - Modified the file to use "|" only when it is necessary (Sam Ravnborg) Changes in v3: - Corrected the license used (Rob Herring) - Added maxItems for properties (Rob Herring) - Dropped generic descriptions (Rob Herring) - Added ranges property (Rob Herring) - Corrected the indendation (Rob Herring) - Added additionalProperties (Rob Herring) - Split dsi file into two, one for dsi controller and another one for dsi phy per target (Rob Herring) - Corrected description for pinctrl-names (Rob Herring) - Corrected the examples used in yaml file (Rob Herring) - Delete dsi.txt and dpu.txt (Rob Herring) --- .../bindings/display/msm/dpu-sc7180.yaml | 250 + .../bindings/display/msm/dpu-sdm845.yaml | 229 +++ .../devicetree/bindings/display/msm/dpu.txt| 141 .../display/msm/dsi-controller-sc7180.yaml | 123 ++ .../display/msm/dsi-controller-sdm845.yaml | 120 ++ .../bindings/display/msm/dsi-controller.yaml | 163 ++ .../bindings/display/msm/dsi-phy-sc7180.yaml | 75 +++ .../bindings/display/msm/dsi-phy-sdm845.yaml | 76 +++ .../devicetree/bindings/display/msm/dsi-phy.yaml | 87 +++ .../devicetree/bindings/display/msm/dsi.txt| 246 10 files changed, 1123 insertions(+), 387 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy.yaml delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml new file mode 100644 index 000..c230647 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml @@ -0,0 +1,250 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Description of Qualcomm Display DPU dt properties. + +maintainers: + - Krishna Manikandan + +description: | + Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SC7180 target. + +properties: + "mdss": +type: object +description: | + Node containing MDSS that encapsulated sub-blocks like DPU, DSI and DP + interfaces. + +properties: + compatible: + items: + - const: qcom,sc7180-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + description: | + Device clock names in the same order as mentioned in clocks property. + The required clocks are mentioned below. + items: + - const: iface + - const: ahb + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + iommus: + maxItems: 1 + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + ranges: true + + interconnects: + description: | + Interconnect path specifier for MDSS according to + Documentation/devicetree/bindings/interconnect/interconnect.txt. + Should be 2 paths corresponding to 2 AXI ports. + maxItems: 1 + + interconnect-names: + description: | + MDSS will have 2 port names to differentiate between the + 2 interconnect paths defined with interconnect specifie
Re:Re: [PATCH V3] amdgpu:optimization-- reduce no need mutex_lock area
Sure, this seems to be a lot more professional than my previous modification.
My original intention is to make the code easier to read, and I learned a lot
from
submitting these patches. Thank you very much for all your guidance!
Regards,
Bernard
发件人：Felix Kuehling
发送日期：2020-04-22 10:27:16
收件人：1587181464-114215-1-git-send-email-bern...@vivo.com,Alex Deucher
,"Christian König" ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
抄送人：opensource.ker...@vivo.com,Bernard Zhao
主题：Re: [PATCH V3] amdgpu:optimization-- reduce no need mutex_lock area
Thanks again for the patch. I'm going
to apply this with some minor fixes. The headline should start
with "drm/amdgpu:". I'll also change the wording of the headline
and commit message:
drm/amdgpu: shrink critical section
in amdgpu_amdkfd_gpuvm_free_memory_of_gpu
Reduce the mem->lock`s protected
code area, no need to protect pr_debug.
This also simplifies error handling.
There is one more cosmetic change I'm
going to make, see inline. I'll apply your patch with those
updates if you're OK with that.
On 2020-04-21 2:48, Bernard Zhao wrote:
Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Link for V1:
*https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1226588%2F&data=02%7C01%7CFelix.Kuehling%40amd.com%7Cc715f5d02aae40846b8f08d7e5c001fd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230485152789682&sdata=4UdZiWMAbW8eR1BS2%2F6qMvs5K6cHWy5c8I32ReQ4uz0%3D&reserved=0
Link for V2:
*https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1227907%2F&data=02%7C01%7CFelix.Kuehling%40amd.com%7Cc715f5d02aae40846b8f08d7e5c001fd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230485152799673&sdata=Wt%2Bk7k4MtSX4zIDgmLEOB6ZKzfuqAd6GJZ3Creqf1aY%3D&reserved=0
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 327317c54f7c..f03d9843d723 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1285,21 +1285,21 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct bo_vm_reservation_context ctx;
struct ttm_validate_buffer *bo_list_entry;
int ret;
+ unsigned int mapped_to_gpu_memory;
I'll move this before the "int ret;" line. It makes the code more
readable if long declarations come before short ones.
Regards,
Felix
mutex_lock(&mem->lock);
+ mapped_to_gpu_memory = mem->mapped_to_gpu_memory;
+ mutex_unlock(&mem->lock);
+ /* lock is not needed after this, since mem is unused and will
+* be freed anyway
+*/
- if (mem->mapped_to_gpu_memory > 0) {
+ if (mapped_to_gpu_memory > 0) {
pr_debug("BO VA 0x%llx size 0x%lx is still mapped.\n",
mem->va, bo_size);
- mutex_unlock(&mem->lock);
return -EBUSY;
}
- mutex_unlock(&mem->lock);
- /* lock is not needed after this, since mem is unused and will
-* be freed anyway
-*/
-
/* No more MMU notifiers */
amdgpu_mn_unregister(mem->bo);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 1/5] mm/hmm: make CONFIG_DEVICE_PRIVATE into a select
From: Jason Gunthorpe There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if they don't want the overhead. Signed-off-by: Jason Gunthorpe --- arch/powerpc/Kconfig| 2 +- drivers/gpu/drm/nouveau/Kconfig | 2 +- mm/Kconfig | 7 +-- 3 files changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 924c541a926008..8de52aefdc74cc 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -455,7 +455,7 @@ config PPC_TRANSACTIONAL_MEM config PPC_UV bool "Ultravisor support" depends on KVM_BOOK3S_HV_POSSIBLE - depends on DEVICE_PRIVATE + select DEVICE_PRIVATE default n help This option paravirtualizes the kernel to run in POWER platforms that diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index d6e4ae1ef7053a..af5793f3e7c2cf 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -86,10 +86,10 @@ config DRM_NOUVEAU_BACKLIGHT config DRM_NOUVEAU_SVM bool "(EXPERIMENTAL) Enable SVM (Shared Virtual Memory) support" - depends on DEVICE_PRIVATE depends on DRM_NOUVEAU depends on MMU depends on STAGING + select DEVICE_PRIVATE select HMM_MIRROR select MMU_NOTIFIER default n diff --git a/mm/Kconfig b/mm/Kconfig index c1acc34c1c358c..7ca36bf5f5058e 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -805,15 +805,10 @@ config HMM_MIRROR depends on MMU config DEVICE_PRIVATE - bool "Unaddressable device memory (GPU memory, ...)" + bool depends on ZONE_DEVICE select DEV_PAGEMAP_OPS - help - Allows creation of struct pages to represent unaddressable device - memory; i.e., memory that is only accessible from the device (or - group of devices). You likely also want to select HMM_MIRROR. - config FRAME_VECTOR bool -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/xen-front: Add support for Xen PV display frontend
On Tue, 21 Apr 2020, Dan Carpenter wrote:
> Hi Kernel Janitors,
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the following static
> checker warning:
>
> drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> warn: passing zero to 'ERR_CAST'
>
> drivers/gpu/drm/xen/xen_drm_front_gem.c
>133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device
> *dev,
>134 size_t size)
>135 {
>136 struct xen_gem_object *xen_obj;
>137
>138 xen_obj = gem_create(dev, size);
>139 if (IS_ERR_OR_NULL(xen_obj))
>140 return ERR_CAST(xen_obj);
Are the other occurrences of this also a possible problem? There are a
few others outside of xen.
julia
>
> This warning is old and it's actually the result of a bug I had in my
> devel version of Smatch yesterday. xen_obj can't really be NULL, but
> if it were then the caller would return success which would probably
> create some issues.
>
> When a function returns both error pointers and NULL then NULL is a
> special case of success. Like say you have: "p = start_feature();".
> If there is an allocation failure, then the code should return -ENOMEM
> and the whole thing should fail. But if the feature is optional and
> the user has disabled it in the config then we return NULL and the
> caller has to be able to accept that. There are a lot of these
> IS_ERR_OR_NULL() checks in the xen driver...
>
> The one here is clearly buggy because returning NULL would lead to a
> run time failure. All these IS_ERR_OR_NULL() should be checked and
> probably changed to just IS_ERR().
>
> This sort of change is probably change is probably easiest if you build
> the Smatch DB and you can check if Smatch thinks the functions return
> NULL.
>
> ~/smatch/smatch_data/db/smdb.py return_states gem_create | grep INTERNAL
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 58 | (-4095)-(-1) |
>INTERNAL | -1 | | struct xen_gem_object*(*)(struct
> drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 62 |
> 4065035897849303040 | INTERNAL | -1 | | struct
> xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 66 |
> 4065035897849303040 | INTERNAL | -1 | | struct
> xen_gem_object*(*)(struct drm_device*, ulong) |
> drivers/gpu/drm/xen/xen_drm_front_gem.c | gem_create | 68 | 0,(-4095)-(-1) |
> INTERNAL | -1 | | struct xen_gem_object*(*)(struct
> drm_device*, ulong) |
>
> Smatch thinks that gem_create() sometimes returns NULL or error pointers
> but that's because of a bug in the unreleased version of Smatch and
> because gem_create() uses IS_ERR_OR_NULL().
>
>141
>142 return &xen_obj->base;
>143 }
>
> regards,
> dan carpenter
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/9] drm/msm/a6xx: update pdc/rscc GMU registers for A640/A650
Update the gmu_pdc registers for A640 and A650.
Some of the RSCC registers on A650 are in a separate region.
Note this also changes the address of these registers:
RSCC_TCS1_DRV0_STATUS
RSCC_TCS2_DRV0_STATUS
RSCC_TCS3_DRV0_STATUS
Based on the values in msm-4.14 and msm-4.19 kernels.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 90 ++-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 38 +-
3 files changed, 85 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 4aef5fe985d6..60ed5360fd8a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -421,7 +421,7 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
return ret;
}
- ret = gmu_poll_timeout(gmu, REG_A6XX_RSCC_SEQ_BUSY_DRV0, val,
+ ret = gmu_poll_timeout_rscc(gmu, REG_A6XX_RSCC_SEQ_BUSY_DRV0, val,
!val, 100, 1);
if (ret) {
@@ -447,7 +447,7 @@ static void a6xx_rpmh_stop(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1);
- ret = gmu_poll_timeout(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0,
+ ret = gmu_poll_timeout_rscc(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0,
val, val & (1 << 16), 100, 1);
if (ret)
DRM_DEV_ERROR(gmu->dev, "Unable to power off the GPU RSC\n");
@@ -470,32 +470,48 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
struct platform_device *pdev = to_platform_device(gmu->dev);
void __iomem *pdcptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc");
void __iomem *seqptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc_seq");
+ uint32_t pdc_address_offset;
if (!pdcptr || !seqptr)
goto err;
+ if (adreno_is_a618(adreno_gpu) || adreno_is_a640(adreno_gpu))
+ pdc_address_offset = 0x30090;
+ else if (adreno_is_a650(adreno_gpu))
+ pdc_address_offset = 0x300a0;
+ else
+ pdc_address_offset = 0x30080;
+
/* Disable SDE clock gating */
- gmu_write(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0, BIT(24));
+ gmu_write_rscc(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0, BIT(24));
/* Setup RSC PDC handshake for sleep and wakeup */
- gmu_write(gmu, REG_A6XX_RSCC_PDC_SLAVE_ID_DRV0, 1);
- gmu_write(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_DATA, 0);
- gmu_write(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_ADDR, 0);
- gmu_write(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_DATA + 2, 0);
- gmu_write(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_ADDR + 2, 0);
- gmu_write(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_DATA + 4, 0x8000);
- gmu_write(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_ADDR + 4, 0);
- gmu_write(gmu, REG_A6XX_RSCC_OVERRIDE_START_ADDR, 0);
- gmu_write(gmu, REG_A6XX_RSCC_PDC_SEQ_START_ADDR, 0x4520);
- gmu_write(gmu, REG_A6XX_RSCC_PDC_MATCH_VALUE_LO, 0x4510);
- gmu_write(gmu, REG_A6XX_RSCC_PDC_MATCH_VALUE_HI, 0x4514);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_PDC_SLAVE_ID_DRV0, 1);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_DATA, 0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_ADDR, 0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_DATA + 2, 0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_ADDR + 2, 0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_DATA + 4, 0x8000);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_HIDDEN_TCS_CMD0_ADDR + 4, 0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_OVERRIDE_START_ADDR, 0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_PDC_SEQ_START_ADDR, 0x4520);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_PDC_MATCH_VALUE_LO, 0x4510);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_PDC_MATCH_VALUE_HI, 0x4514);
/* Load RSC sequencer uCode for sleep and wakeup */
- gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0, 0xa7a506a0);
- gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 1, 0xa1e6a6e7);
- gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 2, 0xa2e081e1);
- gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 3, 0xe9a982e2);
- gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 4, 0x0020e8a8);
+ if (adreno_is_a650(adreno_gpu)) {
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0, 0xeaaae5a0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 1,
0xe1a1ebab);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 2,
0xa2e0a581);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 3,
0xecac82e2);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 4,
0x0020edad);
+ } else {
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0, 0xa7a506a0);
+ gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 1,
0xa1e6a6e7);
+ gmu_write_rscc(gmu, REG_A6XX_
[PATCH] amdgpu: fixes memleak issue when init failed
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 82a3299e53c0..4c5fb153e6b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
ttm_mem_type_manager *man,
ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file mem_info_vram_total\n");
- return ret;
+ goto VRAM_TOTAL_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vis_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_total\n");
- return ret;
+ goto VIS_VRAM_TOTA_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file mem_info_vram_used\n");
- return ret;
+ goto VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_used\n");
- return ret;
+ goto VIS_VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_vendor);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_vendor\n");
- return ret;
+ goto VRAM_VERDOR_FAIL;
}
return 0;
+
+VRAM_VERDOR_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
+VIS_VRAM_USED_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_used);
+RVAM_USED_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_total);
+VIS_VRAM_TOTA_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_total);
+VRAM_TOTAL_FAIL:
+ kfree(mgr);
+ man->priv = NULL;
+
+ return ret;
}
/**
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/9] drm/msm/a6xx: HFI v2 for A640 and A650
Add HFI v2 code paths required by Adreno 640 and 650 GPUs.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 66 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 117 --
drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 50 ++-
5 files changed, 222 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index c9fd0470a321..b22a69e2f4b0 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -129,8 +129,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
if (ret)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
- gmu->freq = gmu->gpu_freqs[index];
-
/*
* Eventually we will want to scale the path vote with the frequency but
* for now leave it at max so that the performance is nominal.
@@ -154,7 +152,12 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long
freq)
gmu->current_perf_index = perf_index;
- __a6xx_gmu_set_freq(gmu, perf_index);
+ if (gmu->legacy)
+ __a6xx_gmu_set_freq(gmu, perf_index);
+ else
+ a6xx_hfi_set_freq(gmu, perf_index);
+
+ gmu->freq = gmu->gpu_freqs[perf_index];
}
unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
@@ -234,8 +237,13 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
switch (state) {
case GMU_OOB_GPU_SET:
- request = GMU_OOB_GPU_SET_REQUEST;
- ack = GMU_OOB_GPU_SET_ACK;
+ if (gmu->legacy) {
+ request = GMU_OOB_GPU_SET_REQUEST;
+ ack = GMU_OOB_GPU_SET_ACK;
+ } else {
+ request = GMU_OOB_GPU_SET_REQUEST_NEW;
+ ack = GMU_OOB_GPU_SET_ACK_NEW;
+ }
name = "GPU_SET";
break;
case GMU_OOB_BOOT_SLUMBER:
@@ -274,6 +282,13 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
/* Clear a pending OOB state in the GMU */
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
{
+ if (!gmu->legacy) {
+ WARN_ON(state != GMU_OOB_GPU_SET);
+ gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+ 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
+ return;
+ }
+
switch (state) {
case GMU_OOB_GPU_SET:
gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
@@ -296,6 +311,9 @@ static int a6xx_sptprac_enable(struct a6xx_gmu *gmu)
int ret;
u32 val;
+ if (!gmu->legacy)
+ return 0;
+
gmu_write(gmu, REG_A6XX_GMU_GX_SPTPRAC_POWER_CONTROL, 0x778000);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS, val,
@@ -315,6 +333,9 @@ static void a6xx_sptprac_disable(struct a6xx_gmu *gmu)
u32 val;
int ret;
+ if (!gmu->legacy)
+ return;
+
/* Make sure retention is on */
gmu_rmw(gmu, REG_A6XX_GPU_CC_GX_GDSCR, 0, (1 << 11));
@@ -358,6 +379,11 @@ static int a6xx_gmu_notify_slumber(struct a6xx_gmu *gmu)
if (gmu->idle_level < GMU_IDLE_STATE_SPTP)
a6xx_sptprac_disable(gmu);
+ if (!gmu->legacy) {
+ ret = a6xx_hfi_send_prep_slumber(gmu);
+ goto out;
+ }
+
/* Tell the GMU to get ready to slumber */
gmu_write(gmu, REG_A6XX_GMU_BOOT_SLUMBER_OPTION, 1);
@@ -373,6 +399,7 @@ static int a6xx_gmu_notify_slumber(struct a6xx_gmu *gmu)
}
}
+out:
/* Put fence into allow mode */
gmu_write(gmu, REG_A6XX_GMU_AO_AHB_FENCE_CTRL, 0);
return ret;
@@ -642,9 +669,11 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu,
unsigned int state)
if (ret)
return ret;
- ret = a6xx_gmu_gfx_rail_on(gmu);
- if (ret)
- return ret;
+ if (gmu->legacy) {
+ ret = a6xx_gmu_gfx_rail_on(gmu);
+ if (ret)
+ return ret;
+ }
/* Enable SPTP_PC if the CPU is responsible for it */
if (gmu->idle_level < GMU_IDLE_STATE_SPTP) {
@@ -763,7 +792,10 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
enable_irq(gmu->hfi_irq);
/* Set the GPU to the current freq */
- __a6xx_gmu_set_freq(gmu, gmu->current_perf_index);
+ if (gmu->legacy)
+ __a6xx_gmu_set_freq(gmu, gmu->current_perf_index);
+ else
+ a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
/*
* "enable" the GX power domain which won't actually do anything but it
@@ -1262,6 +1294,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
int a6xx_gmu_init(struct a6xx_gpu *a6xx_g
Re: [PATCH 4/9] drm/msm/a6xx: HFI v2 for A640 and A650
On 4/21/20 12:30 PM, Jordan Crouse wrote:
On Mon, Apr 20, 2020 at 10:03:08AM -0400, Jonathan Marek wrote:
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 68 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 117 --
drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 50 ++-
5 files changed, 224 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index c6ecb3189ec5..dc2d69837110 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -126,8 +126,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
if (ret)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
- gmu->freq = gmu->gpu_freqs[index];
-
/*
* Eventually we will want to scale the path vote with the frequency but
* for now leave it at max so that the performance is nominal.
@@ -151,7 +149,12 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long
freq)
gmu->current_perf_index = perf_index;
- __a6xx_gmu_set_freq(gmu, perf_index);
+ if (gmu->legacy)
+ __a6xx_gmu_set_freq(gmu, perf_index);
+ else
+ a6xx_hfi_set_freq(gmu, perf_index);
Welcome to the first great GMU schism. There are going to be a lot of these if()
statements and my guess is that it won't get any cleaner in the future.
The best option in my opinion would be to make two separate GMU implementations
and select the probe either from the gpu list or the compatible string and use
function pointers for the functions that are called from a6xx_gpu.c and
a6xx_gpu_state.c.
We _could_ make the gmu->legacy thing work but if someday there is a another
schism we would be sad that we didn't do the ground work now.
We could also do the same for HFI, but I think there is a bit less of a delta
there and there isn't a harm in having a _v1 function or two laying around.
I don't think it makes sense to have two separate GMU implementations at
this point, most of the code is still sharable. There's "only" 10 of
these gmu->legacy if()s in the final version, and they are very small if()s.
+
+ gmu->freq = gmu->gpu_freqs[perf_index];
}
unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
@@ -231,19 +234,26 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
switch (state) {
case GMU_OOB_GPU_SET:
- request = GMU_OOB_GPU_SET_REQUEST;
- ack = GMU_OOB_GPU_SET_ACK;
+ if (gmu->legacy) {
+ request = GMU_OOB_GPU_SET_REQUEST;
+ ack = GMU_OOB_GPU_SET_ACK;
+ } else {
+ request = GMU_OOB_GPU_SET_REQUEST_NEW;
+ ack = GMU_OOB_GPU_SET_ACK_NEW;
+ }
name = "GPU_SET";
break;
case GMU_OOB_BOOT_SLUMBER:
request = GMU_OOB_BOOT_SLUMBER_REQUEST;
ack = GMU_OOB_BOOT_SLUMBER_ACK;
name = "BOOT_SLUMBER";
+ WARN_ON(!gmu->legacy);
This is unlikely to be the case - these should only be called from within the
GMU code and we should be able to control it.
These are called from a6xx_gpu.c too, not just from within a6xx_gmu.c.
IMO the warnings might be useful to catch errors in the future, but they
not absolutely necessary either.
break;
case GMU_OOB_DCVS_SET:
request = GMU_OOB_DCVS_REQUEST;
ack = GMU_OOB_DCVS_ACK;
name = "GPU_DCVS";
+ WARN_ON(!gmu->legacy);
Same.
break;
default:
return -EINVAL;
@@ -271,6 +281,13 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
/* Clear a pending OOB state in the GMU */
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
{
+ if (!gmu->legacy) {
+ WARN_ON(state != GMU_OOB_GPU_SET);
+ gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+ 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
+ return;
+ }
A good example of the usefulness of per-implementation functions.
I wouldn't say its a great example, the function is effectively the
same, just with a different shift value. It was just simple enough that
it felt better to do it this way.
+
switch (state) {
case GMU_OOB_GPU_SET:
gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
@@ -293,6 +310,9 @@ static int a6xx_sptprac_enable(struct a6xx_gmu *gmu)
int ret;
u32 val;
+ if (!gmu->legacy)
+ return 0;
+
gmu_write(gmu, REG_A6XX_GMU_GX_SPTPRAC_POWER_CONTROL, 0x778000);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_SPTPR
[PATCH v2 1/9] drm/msm: add msm_gem_get_and_pin_iova_range
This function allows pinning iova to a specific page range (for a6xx GMU).
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.h | 6 +-
drivers/gpu/drm/msm/msm_gem.c | 28 +---
drivers/gpu/drm/msm/msm_gem_vma.c | 6 --
3 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 194d900a460e..966fd9068c94 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -236,7 +236,8 @@ int msm_crtc_enable_vblank(struct drm_crtc *crtc);
void msm_crtc_disable_vblank(struct drm_crtc *crtc);
int msm_gem_init_vma(struct msm_gem_address_space *aspace,
- struct msm_gem_vma *vma, int npages);
+ struct msm_gem_vma *vma, int npages,
+ u64 range_start, u64 range_end);
void msm_gem_purge_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma);
void msm_gem_unmap_vma(struct msm_gem_address_space *aspace,
@@ -276,6 +277,9 @@ vm_fault_t msm_gem_fault(struct vm_fault *vmf);
uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
int msm_gem_get_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
+int msm_gem_get_and_pin_iova_range(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace, uint64_t *iova,
+ u64 range_start, u64 range_end);
int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
uint64_t msm_gem_iova(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5a6a79fbc9d6..d8f56a34c117 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -389,7 +389,8 @@ put_iova(struct drm_gem_object *obj)
}
static int msm_gem_get_iova_locked(struct drm_gem_object *obj,
- struct msm_gem_address_space *aspace, uint64_t *iova)
+ struct msm_gem_address_space *aspace, uint64_t *iova,
+ u64 range_start, u64 range_end)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma;
@@ -404,7 +405,8 @@ static int msm_gem_get_iova_locked(struct drm_gem_object
*obj,
if (IS_ERR(vma))
return PTR_ERR(vma);
- ret = msm_gem_init_vma(aspace, vma, obj->size >> PAGE_SHIFT);
+ ret = msm_gem_init_vma(aspace, vma, obj->size >> PAGE_SHIFT,
+ range_start, range_end);
if (ret) {
del_vma(vma);
return ret;
@@ -443,9 +445,13 @@ static int msm_gem_pin_iova(struct drm_gem_object *obj,
msm_obj->sgt, obj->size >> PAGE_SHIFT);
}
-/* get iova and pin it. Should have a matching put */
-int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
- struct msm_gem_address_space *aspace, uint64_t *iova)
+/*
+ * get iova and pin it. Should have a matching put
+ * limits iova to specified range (in pages)
+ */
+int msm_gem_get_and_pin_iova_range(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace, uint64_t *iova,
+ u64 range_start, u64 range_end)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
u64 local;
@@ -453,7 +459,8 @@ int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
mutex_lock(&msm_obj->lock);
- ret = msm_gem_get_iova_locked(obj, aspace, &local);
+ ret = msm_gem_get_iova_locked(obj, aspace, &local,
+ range_start, range_end);
if (!ret)
ret = msm_gem_pin_iova(obj, aspace);
@@ -465,6 +472,13 @@ int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
return ret;
}
+/* get iova and pin it. Should have a matching put */
+int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace, uint64_t *iova)
+{
+ return msm_gem_get_and_pin_iova_range(obj, aspace, iova, 0, U64_MAX);
+}
+
/*
* Get an iova but don't pin it. Doesn't need a put because iovas are currently
* valid for the life of the object
@@ -476,7 +490,7 @@ int msm_gem_get_iova(struct drm_gem_object *obj,
int ret;
mutex_lock(&msm_obj->lock);
- ret = msm_gem_get_iova_locked(obj, aspace, iova);
+ ret = msm_gem_get_iova_locked(obj, aspace, iova, 0, U64_MAX);
mutex_unlock(&msm_obj->lock);
return ret;
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 1af5354bcd46..407b7ab82818 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -103,7 +103,8 @@ void msm_gem_close_vma(struct msm_gem_address_space *aspace,
/* Initialize a new vma and allocate an iova for it */
int msm_gem_init_vma(struct msm_gem_address_space *aspace,
- struct msm_gem_vma *vma, int n
[PATCH -next] drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpy
Fixes coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity
for kmemdup
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity
for kmemdup
Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure
boot"")
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
index aecce2d..667fa01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
@@ -100,25 +100,21 @@ nvkm_acr_hsfw_load_image(struct nvkm_acr *acr, const char
*name, int ver,
hsfw->data_size = lhdr->data_size;
hsfw->sig.prod.size = fwhdr->sig_prod_size;
- hsfw->sig.prod.data = kmalloc(hsfw->sig.prod.size, GFP_KERNEL);
+ hsfw->sig.prod.data = kmemdup(fw->data + fwhdr->sig_prod_offset + sig,
+ hsfw->sig.prod.size, GFP_KERNEL);
if (!hsfw->sig.prod.data) {
ret = -ENOMEM;
goto done;
}
- memcpy(hsfw->sig.prod.data, fw->data + fwhdr->sig_prod_offset + sig,
- hsfw->sig.prod.size);
-
hsfw->sig.dbg.size = fwhdr->sig_dbg_size;
- hsfw->sig.dbg.data = kmalloc(hsfw->sig.dbg.size, GFP_KERNEL);
+ hsfw->sig.dbg.data = kmemdup(fw->data + fwhdr->sig_dbg_offset + sig,
+hsfw->sig.dbg.size, GFP_KERNEL);
if (!hsfw->sig.dbg.data) {
ret = -ENOMEM;
goto done;
}
- memcpy(hsfw->sig.dbg.data, fw->data + fwhdr->sig_dbg_offset + sig,
- hsfw->sig.dbg.size);
-
hsfw->sig.patch_loc = loc;
done:
nvkm_firmware_put(fw);
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] drm/msm/a6xx: update a6xx_hw_init for A640 and A650
Adreno 640 and 650 GPUs need some registers set differently.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 14 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 ++-
2 files changed, 61 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index ed78fee2a262..47840b73cdda 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -1047,6 +1047,8 @@ enum a6xx_tex_type {
#define REG_A6XX_CP_MISC_CNTL 0x0840
+#define REG_A6XX_CP_APRIV_CNTL 0x0844
+
#define REG_A6XX_CP_ROQ_THRESHOLDS_1 0x08c1
#define REG_A6XX_CP_ROQ_THRESHOLDS_2 0x08c2
@@ -1764,6 +1766,8 @@ static inline uint32_t
A6XX_CP_PROTECT_REG_MASK_LEN(uint32_t val)
#define REG_A6XX_RBBM_VBIF_CLIENT_QOS_CNTL 0x0010
+#define REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL 0x0011
+
#define REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL 0x001f
#define REG_A6XX_RBBM_INT_CLEAR_CMD0x0037
@@ -2418,6 +2422,16 @@ static inline uint32_t
A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
#define REG_A6XX_TPL1_NC_MODE_CNTL 0xb604
+#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_0 0xb608
+
+#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_1 0xb609
+
+#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_2 0xb60a
+
+#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_3 0xb60b
+
+#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_4 0xb60c
+
#define REG_A6XX_TPL1_PERFCTR_TP_SEL_0 0xb610
#define REG_A6XX_TPL1_PERFCTR_TP_SEL_1 0xb611
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index a860d4970e10..e1eb34fa3a99 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -414,7 +414,17 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
a6xx_set_hwcg(gpu, true);
/* VBIF/GBIF start*/
- gpu_write(gpu, REG_A6XX_RBBM_VBIF_CLIENT_QOS_CNTL, 0x3);
+ if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu)) {
+ gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE0, 0x00071620);
+ gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE1, 0x00071620);
+ gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE2, 0x00071620);
+ gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE3, 0x00071620);
+ gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE3, 0x00071620);
+ gpu_write(gpu, REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL, 0x3);
+ } else {
+ gpu_write(gpu, REG_A6XX_RBBM_VBIF_CLIENT_QOS_CNTL, 0x3);
+ }
+
if (adreno_is_a630(adreno_gpu))
gpu_write(gpu, REG_A6XX_VBIF_GATE_OFF_WRREQ_EN, 0x0009);
@@ -429,25 +439,35 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A6XX_UCHE_WRITE_THRU_BASE_LO, 0xf000);
gpu_write(gpu, REG_A6XX_UCHE_WRITE_THRU_BASE_HI, 0x0001);
- /* Set the GMEM VA range [0x10:0x10 + gpu->gmem - 1] */
- gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MIN_LO,
- REG_A6XX_UCHE_GMEM_RANGE_MIN_HI, 0x0010);
+ if (!adreno_is_a650(adreno_gpu)) {
+ /* Set the GMEM VA range [0x10:0x10 + gpu->gmem - 1] */
+ gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MIN_LO,
+ REG_A6XX_UCHE_GMEM_RANGE_MIN_HI, 0x0010);
- gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MAX_LO,
- REG_A6XX_UCHE_GMEM_RANGE_MAX_HI,
- 0x0010 + adreno_gpu->gmem - 1);
+ gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MAX_LO,
+ REG_A6XX_UCHE_GMEM_RANGE_MAX_HI,
+ 0x0010 + adreno_gpu->gmem - 1);
+ }
gpu_write(gpu, REG_A6XX_UCHE_FILTER_CNTL, 0x804);
gpu_write(gpu, REG_A6XX_UCHE_CACHE_WAYS, 0x4);
- gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_2, 0x01c0);
+ if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu))
+ gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_2, 0x02000140);
+ else
+ gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_2, 0x01c0);
gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_1, 0x8040362c);
/* Setting the mem pool size */
gpu_write(gpu, REG_A6XX_CP_MEM_POOL_SIZE, 128);
/* Setting the primFifo thresholds default values */
- gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, (0x300 << 11));
+ if (adreno_is_a650(adreno_gpu))
+ gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x0030);
+ else if (adreno_is_a640(adreno_gpu))
+ gpu_write(gpu, REG_A6XX_PC_
Re: [PATCH V2] drm/amdgpu: Remove an unnecessary condition check in reserve_bo_and_cond_vms()
> There is no need to if check again, Thanks for this information. * Should the function name be mentioned in this commit message? * Would you like to adjust the patch subject another bit? > maybe we could merge into the above else branch. I suggest to reconsider this wording. Are you still unsure about the next changes? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=ae83d0b416db002fe95601e7f97f64b59514d936#n151 How do you think about to add the tag “Fixes”? It can be nicer if all patch reviewers (including me) will be explicitly specified as recipients for such messages, can't it? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] amdgpu: remove unnecessary condition check
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the best way to merge unnecessary if/else check branch
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226587/
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 20 +--
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..acb612c53b9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -660,15 +660,15 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else {
- pr_err("Failed to reserve buffers in ttm\n");
+ if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
+ return ret;
}
- return ret;
+ ctx->reserved = true;
+ return 0;
}
/**
@@ -733,17 +733,15 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else
- pr_err("Failed to reserve buffers in ttm.\n");
-
if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
+ return ret;
}
- return ret;
+ ctx->reserved = true;
+ return 0;
}
/**
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 4/5] mm/hmm: remove HMM_PFN_SPECIAL
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_svm.c | 1 -
include/linux/hmm.h | 8
mm/hmm.c| 2 +-
4 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index bff8e64701a547..449083f9f8a2bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -775,7 +775,6 @@ static const uint64_t hmm_range_flags[HMM_PFN_FLAG_MAX] = {
static const uint64_t hmm_range_values[HMM_PFN_VALUE_MAX] = {
0xfffeUL, /* HMM_PFN_ERROR */
0, /* HMM_PFN_NONE */
- 0xfffcUL /* HMM_PFN_SPECIAL */
};
/**
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index c68e9317cf0740..cf0d9bd61bebf9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -379,7 +379,6 @@ static const u64
nouveau_svm_pfn_values[HMM_PFN_VALUE_MAX] = {
[HMM_PFN_ERROR ] = ~NVIF_VMM_PFNMAP_V0_V,
[HMM_PFN_NONE ] = NVIF_VMM_PFNMAP_V0_NONE,
- [HMM_PFN_SPECIAL] = ~NVIF_VMM_PFNMAP_V0_V,
};
/* Issue fault replay for GPU to retry accesses that faulted previously. */
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 0df27dd03d53d7..81c302c884c0e3 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -44,10 +44,6 @@ enum hmm_pfn_flag_e {
* Flags:
* HMM_PFN_ERROR: corresponding CPU page table entry points to poisoned memory
* HMM_PFN_NONE: corresponding CPU page table entry is pte_none()
- * HMM_PFN_SPECIAL: corresponding CPU page table entry is special; i.e., the
- * result of vmf_insert_pfn() or vm_insert_page(). Therefore, it should
not
- * be mirrored by a device, because the entry will never have
HMM_PFN_VALID
- * set and the pfn value is undefined.
*
* Driver provides values for none entry, error entry, and special entry.
* Driver can alias (i.e., use same value) error and special, but
@@ -56,12 +52,10 @@ enum hmm_pfn_flag_e {
* HMM pfn value returned by hmm_vma_get_pfns() or hmm_vma_fault() will be:
* hmm_range.values[HMM_PFN_ERROR] if CPU page table entry is poisonous,
* hmm_range.values[HMM_PFN_NONE] if there is no CPU page table entry,
- * hmm_range.values[HMM_PFN_SPECIAL] if CPU page table entry is a special one
*/
enum hmm_pfn_value_e {
HMM_PFN_ERROR,
HMM_PFN_NONE,
- HMM_PFN_SPECIAL,
HMM_PFN_VALUE_MAX
};
@@ -110,8 +104,6 @@ static inline struct page *hmm_device_entry_to_page(const
struct hmm_range *rang
return NULL;
if (entry == range->values[HMM_PFN_ERROR])
return NULL;
- if (entry == range->values[HMM_PFN_SPECIAL])
- return NULL;
if (!(entry & range->flags[HMM_PFN_VALID]))
return NULL;
return pfn_to_page(entry >> range->pfn_shift);
diff --git a/mm/hmm.c b/mm/hmm.c
index 4c7c396655b528..2693393dc14b30 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -301,7 +301,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
pte_unmap(ptep);
return -EFAULT;
}
- *pfn = range->values[HMM_PFN_SPECIAL];
+ *pfn = range->values[HMM_PFN_ERROR];
return 0;
}
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [V3] amdgpu: remove unnecessary condition check
> But i have to say there are so many code not follow the kernel code-style in > amdgpu module. > And also the ./scripts/checkpatch.pl did not throw any warning or error. Will such information become more interesting for further evolution in the affected software areas? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/9] drm/msm: add internal MSM_BO_MAP_PRIV flag
This flag sets IOMMU_PRIV, which is required for some a6xx GMU objects.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 3 +++
drivers/gpu/drm/msm/msm_gem.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index d8f56a34c117..6277fde13df9 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -428,6 +428,9 @@ static int msm_gem_pin_iova(struct drm_gem_object *obj,
if (!(msm_obj->flags & MSM_BO_GPU_READONLY))
prot |= IOMMU_WRITE;
+ if (msm_obj->flags & MSM_BO_MAP_PRIV)
+ prot |= IOMMU_PRIV;
+
WARN_ON(!mutex_is_locked(&msm_obj->lock));
if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 30584eaf8cc8..972490b14ba5 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -13,6 +13,7 @@
/* Additional internal-use only BO flags: */
#define MSM_BO_STOLEN0x1000/* try to use stolen/splash memory
*/
+#define MSM_BO_MAP_PRIV 0x2000/* use IOMMU_PRIV when mapping */
struct msm_gem_address_space {
const char *name;
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Don't reserve minors for control nodes
From: Michał Winiarski
Control nodes are no longer with us.
While we still need to preserve render nodes numbering, there's no need
to reserve the range formerly used for control. Let's repurpose it to be
used by primary and remove control remains from the code entirely.
References: 0d49f303e8a7 ("drm: remove all control node code")
References: c9ac371d4b59 ("drm: Fix render node numbering regression from
control node removal.")
Signed-off-by: Michał Winiarski
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Marcin Bernatowicz
Cc: Sean Paul
---
drivers/gpu/drm/drm_drv.c | 4 ++--
include/drm/drm_file.h| 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c15c9b4540e1..366a760bbc29 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -124,8 +124,8 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
spin_lock_irqsave(&drm_minor_lock, flags);
r = idr_alloc(&drm_minors_idr,
NULL,
- 64 * type,
- 64 * (type + 1),
+ 128 * type,
+ 128 * (type + 1),
GFP_NOWAIT);
spin_unlock_irqrestore(&drm_minor_lock, flags);
idr_preload_end();
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 716990bace10..45e6dae69293 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -54,7 +54,6 @@ struct file;
*/
enum drm_minor_type {
DRM_MINOR_PRIMARY,
- DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
};
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] drm/msm/a6xx: A640/A650 GMU firmware path
Newer GPUs have different GMU firmware path.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 135 +++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 11 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 6 +
3 files changed, 136 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index b22a69e2f4b0..4aef5fe985d6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -571,6 +571,8 @@ static void a6xx_gmu_power_config(struct a6xx_gmu *gmu)
{
/* Disable GMU WB/RB buffer */
gmu_write(gmu, REG_A6XX_GMU_SYS_BUS_CONFIG, 0x1);
+ gmu_write(gmu, REG_A6XX_GMU_ICACHE_CONFIG, 0x1);
+ gmu_write(gmu, REG_A6XX_GMU_DCACHE_CONFIG, 0x1);
gmu_write(gmu, REG_A6XX_GMU_PWR_COL_INTER_FRAME_CTRL, 0x9c40400);
@@ -600,14 +602,91 @@ static void a6xx_gmu_power_config(struct a6xx_gmu *gmu)
A6XX_GMU_RPMH_CTRL_GFX_VOTE_ENABLE);
}
+static int in_range(u32 addr, u32 start, u32 size)
+{
+ return addr >= start && addr < start + size;
+}
+
+static int a6xx_gmu_fw_load(struct a6xx_gmu *gmu)
+{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ const struct firmware *fw_image = adreno_gpu->fw[ADRENO_FW_GMU];
+ const struct block_header {
+ u32 addr;
+ u32 size;
+ u32 type;
+ u32 value;
+ u32 data[];
+ } *blk;
+ struct a6xx_gmu_bo *mem;
+ u32 reg;
+
+ u32 itcm_base = 0x;
+ u32 dtcm_base = 0x0004;
+
+ if (adreno_is_a650(adreno_gpu))
+ dtcm_base = 0x10004000;
+
+ if (gmu->legacy) {
+ /* Sanity check the size of the firmware that was loaded */
+ if (fw_image->size > 0x8000) {
+ DRM_DEV_ERROR(gmu->dev,
+ "GMU firmware is bigger than the available
region\n");
+ return -EINVAL;
+ }
+
+ gmu_write_bulk(gmu, REG_A6XX_GMU_CM3_ITCM_START,
+ (u32*) fw_image->data, fw_image->size >> 2);
+ return 0;
+ }
+
+
+ for (blk = (const struct block_header *) fw_image->data;
+(const u8*) blk < fw_image->data + fw_image->size;
+blk = (const struct block_header *) &blk->data[blk->size >> 2]) {
+ if (blk->size == 0)
+ continue;
+
+ reg = 0;
+ mem = NULL;
+
+ if (in_range(blk->addr, itcm_base, SZ_16K))
+ reg = REG_A6XX_GMU_CM3_ITCM_START + ((blk->addr -
itcm_base) >> 2);
+ else if (in_range(blk->addr, dtcm_base, SZ_16K))
+ reg = REG_A6XX_GMU_CM3_DTCM_START + ((blk->addr -
dtcm_base) >> 2);
+ else if (in_range(blk->addr, gmu->icache.iova,
gmu->icache.size))
+ mem = &gmu->icache;
+ else if (in_range(blk->addr, gmu->dcache.iova,
gmu->dcache.size))
+ mem = &gmu->dcache;
+ else if (in_range(blk->addr, gmu->dummy.iova, gmu->dummy.size))
+ mem = &gmu->dummy;
+ else {
+ DRM_DEV_ERROR(gmu->dev,
+ "failed to match fw block (addr=%.8x size=%d
data[0]=%.8x)\n",
+ blk->addr, blk->size, blk->data[0]);
+ }
+
+ if (reg)
+ gmu_write_bulk(gmu, reg, blk->data, blk->size >> 2);
+
+ if (mem)
+ memcpy(mem->virt + blk->addr - mem->iova, blk->data,
blk->size);
+ }
+
+ return 0;
+}
+
static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned int state)
{
static bool rpmh_init;
struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
- int i, ret;
+ int ret;
u32 chipid;
- u32 *image;
+
+ if (adreno_is_a650(adreno_gpu))
+ gmu_write(gmu, REG_A6XX_GPU_GMU_CX_GMU_CX_FAL_INTF, 1);
if (state == GMU_WARM_BOOT) {
ret = a6xx_rpmh_start(gmu);
@@ -618,13 +697,6 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu,
unsigned int state)
"GMU firmware is not loaded\n"))
return -ENOENT;
- /* Sanity check the size of the firmware that was loaded */
- if (adreno_gpu->fw[ADRENO_FW_GMU]->size > 0x8000) {
- DRM_DEV_ERROR(gmu->dev,
- "GMU firmware is bigger than the available
region\n");
- return -EINVAL;
- }
-
/* Turn on register retention */
gmu_write(gmu, REG_A6XX_GM
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
* Tony Lindgren [200421 10:39]: > See for example the standard 8250 uart for am335x with: > > $ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi > > The 8250 device configuration is described in the standard 8250 > dts binding, and the am335x module in the ti-sysc binding. > The are separate devices :) Just to clarify why it's like that, see for example arch/arm/boot/dts/am33xx.dtsi, and target-module@4740 in that file for the musb controller. There's a single ti-sysc interconnect target module, but it has multiple devices. There are two musb controler instances, two phy instances and a cppi41 dma instance within a single module. With sgx, I belive there is only the sgx IP within the ti-sysc interconnect target module. They are still seprate devices with their own control registers. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:Re: [PATCH] amdgpu: fixes memleak issue when init failed
发件人："Christian König"
发送日期：2020-04-21 22:53:47
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter
,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
主题：Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20 um
15:39 schrieb 赵军奎:
>> 发件人："Christian König"
>> 发送日期：2020-04-21 21:02:27
>> 收件人："赵军奎"
>> 抄送人：Alex Deucher ,"David (ChunMing) Zhou"
>> ,David Airlie ,Daniel Vetter
>> ,Tom St Denis ,Ori Messinger
>> ,Sam Ravnborg
>> ,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
>> 主题：Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20 um
>> 14:09 schrieb 赵军奎:
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher
,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter
,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am
21.04.20 um 13:17 schrieb Bernard Zhao:
>> VRAM manager and DRM MM when init failed, there is no operaction
>> to free kzalloc memory & remove device file.
>> This will lead to memleak & cause stability issue.
> NAK, failure to create sysfs nodes are not critical.
>
> Christian.
>
OK, get it.
By the way, should i modify this patch to just handle in
error branch, or that it is also unnecessary?
>>> What you can do is to drop the "return ret" if anything with the sysfs
>>> nodes goes wrong and instead print the error code.
>> Emmm, for this part, i am not sure, my modify first print the error, secone
>> release not free memory,
>> and last return error, make everything clear to the system.
>> I think it`s the same with what you mentioned, is there something that I
>> misunderstood?
>
>Yes, maybe an example makes it more clear what to do here. Currently we
>print and error and return when something with the sysfs files goes wrong:
>
>if (ret) {
> DRM_ERROR("Failed to create device file mem_info_vram_total\n");
> return ret;
>}
>
>But what we should do instead is just to print an error and continue and
>in the end return success status:
>
>if (ret)
> DRM_ERROR("Failed to create device file mem_info_vram_total
>(%d)\n", r);
>
>...
>return 0;
>
>Regards,
>Christian.
>
Emmm, i am still confused about two points:
1 Does that mean there is no failed case in this function?
2 There is no need to free the kzmalloc space(no possibility of memory leak )?
Regards,
Bernard
>>
>>> It's really annoying that loading, unloading and loading the driver
>>> again sometimes fails because we have a bug in the sysfs files cleanup.
>>>
>>> We certainly should fix those bugs as well, but they are just not
>>> critical for correct driver functionality.
>>>
>>> Regards,
>>> Christian.
>>
Regards,
Bernard
>> Signed-off-by: Bernard Zhao
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
>>
>> 1 file changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> index 82a3299e53c0..4c5fb153e6b4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> @@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
>> ttm_mem_type_manager *man,
>> ret = device_create_file(adev->dev,
>> &dev_attr_mem_info_vram_total);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vram_total\n");
>> -return ret;
>> +goto VRAM_TOTAL_FAIL;
>> }
>> ret = device_create_file(adev->dev,
>> &dev_attr_mem_info_vis_vram_total);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vis_vram_total\n");
>> -return ret;
>> +goto VIS_VRAM_TOTA_FAIL;
>> }
>> ret = device_create_file(adev->dev,
>> &dev_attr_mem_info_vram_used);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vram_used\n");
>> -return ret;
>> +goto VRAM_USED_FAIL;
>> }
>> ret = device_create_file(adev->dev,
>> &dev_attr_mem_info_vis_vram_used);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vis_vram_used\n");
>> -return ret;
>> +goto VIS_VRAM_USED_FAIL;
>>
[PATCH v1] drm/bochs: fix an issue of ioremap() leak
It forgot to call bochs_hw_fini() to release related resources when
bochs_pci_probe() fail. eg: io virtual address get by ioremap().
Fixes: 81da8c3b8d3df6 ("drm/bochs: add drm_driver.release callback.")
CC: Andy Shevchenko
Signed-off-by: Dejin Zheng
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index addb0568c1af..210a60135c8a 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -138,6 +138,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return ret;
err_unload:
+ bochs_hw_fini(dev);
bochs_unload(dev);
err_free_dev:
drm_dev_put(dev);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
* H. Nikolaus Schaller [200421 17:31]: > > Am 21.04.2020 um 16:15 schrieb Tony Lindgren : > > Note that on omaps there are actually SoC module specific registers. > > Ah, I see. This is of course a difference that the TI glue logic has > its own registers in the same address range as the sgx and this can't > be easily handled by a common sgx driver. > > This indeed seems to be unique with omap. > > > And there can be multiple devices within a single target module on > > omaps. So the extra dts node and device is justified there. > > > > For other SoCs, the SGX clocks are probably best handled directly > > in pvr-drv.c PM runtime functions unless a custom hardware wrapper > > with SoC specific registers exists. > > That is why we need to evaluate what the better strategy is. > > So we have > a) omap which has a custom wrapper around the sgx > b) others without, i.e. an empty (or pass-through) wrapper > > Which one do we make the "standard" and which one the "exception"? > What are good reasons for either one? The wrapper is already handled by the ti-sysc binding, the sgx binding should be standard with optional clocks. See for example the standard 8250 uart for am335x with: $ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi The 8250 device configuration is described in the standard 8250 dts binding, and the am335x module in the ti-sysc binding. The are separate devices :) So for the sgx binding, you can just leave out TI specific module wrapper completely from the example. > It also allows to handle different number of clocks (A31 seems to > need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings > or making big lists of conditionals. This variance would be handled > outside the sgx core bindings and driver. Well if other SoCs implement genpd domains etc, that's then again part of a separate binding and not part of the sgx binding. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 3/5] drm/amdgpu: remove dead code after hmm_range_fault()
From: Jason Gunthorpe
Since amdgpu does not use the snapshot mode of hmm_range_fault() a
successful return already proves that all entries in the pfns are
HMM_PFN_VALID, there is no need to check the return result of
hmm_device_entry_to_page().
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index efc1329a019127..bff8e64701a547 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -862,17 +862,13 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
struct page **pages)
goto out_free_pfns;
}
- for (i = 0; i < ttm->num_pages; i++) {
- /* FIXME: The pages cannot be touched outside the notifier_lock
*/
+ /*
+* Due to default_flags, all pages are HMM_PFN_VALID or
+* hmm_range_fault() fails. FIXME: The pages cannot be touched outside
+* the notifier_lock, and mmu_interval_read_retry() must be done first.
+*/
+ for (i = 0; i < ttm->num_pages; i++)
pages[i] = hmm_device_entry_to_page(range, range->pfns[i]);
- if (unlikely(!pages[i])) {
- pr_err("Page fault failed for pfn[%lu] = 0x%llx\n",
- i, range->pfns[i]);
- r = -ENOMEM;
-
- goto out_free_pfns;
- }
- }
gtt->range = range;
mmput(mm);
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: amd/display: fix Kconfig help text
From: Randy Dunlap
Fix help text: indent one tab + 2 spaces; end a sentence with a
period; and collapse short lines of text to one line.
Fixes: 23c61b4599c4 ("drm/amd: Fix Kconfig indentation")
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Randy Dunlap
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Krzysztof Kozlowski
---
drivers/gpu/drm/amd/display/Kconfig |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- linux-next-20200421.orig/drivers/gpu/drm/amd/display/Kconfig
+++ linux-next-20200421/drivers/gpu/drm/amd/display/Kconfig
@@ -21,16 +21,12 @@ config DRM_AMD_DC_HDCP
bool "Enable HDCP support in DC"
depends on DRM_AMD_DC
help
-Choose this option
-if you want to support
-HDCP authentication
+ Choose this option if you want to support HDCP authentication.
config DEBUG_KERNEL_DC
bool "Enable kgdb break in DC"
depends on DRM_AMD_DC
help
- Choose this option
- if you want to hit
- kdgb_break in assert.
+ Choose this option if you want to hit kdgb_break in assert.
endmenu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 00/11] Convert PWM period and duty cycle to u64
[REQUEST] Would it be possible for the patches that have already received Acked-by's in this series to be accepted and applied to the tree? I lost an Acked-by (in intel-panel.c) because it had a merge conflict with a new change that came in after I rebased to tip. I wasn't sure earlier about accepting single patches as opposed to the entire series en masse, but this event has got me thinking. [COVER LETTER] Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds. Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors. This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors. Changes from v12: - Rebased to tip of for-next - Collected Acked-by for sun4i - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as a result Changes from v11: - Rebased to tip of for-next. - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4] - Squished stm32-lp.c change with final patch in series - sun4i: Used nsecs_to_jiffies() - imx27: Added overflow handling logic - clps711x: Corrected the if condition for skipping the division - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero Changes from v10: - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received so far that had gotten missed in v9. No other changes. Changes from v9: - Gathered the received "Reviewed-by: " tag - Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments. - clps711x: Addressed review comments. Changes from v8: - Gathered all received "Acked-by: " and "Reviewed-by: " tags - Dropped patch to clk-pwm.c for reasons mentiond in [2] - Expanded audience of unreviewed patches Changes from v7: - Changed commit messages of all patches to be brief and to the point. - Added explanation of change in cover letter. - Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core. Changes from v6: - Split out the driver changes out into separate patches, one patch per file for ease of reviewing. Changes from v5: - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned in https://www.spinics.net/lists/linux-pwm/msg11541.html Changes from v4: - Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise. - Re-examined the patch and made the following corrections: * intel_panel.c: DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case). * pwm-sti.c: do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible). Changes from v3: - Rebased to current tip of for-next. Changes from v2: - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c Changes from v1: - Fixed compilation errors seen when compiling for different archs. v1: - Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual. [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/ [2] https://lore.kernel.org/lkml/20200312190859.ga19...@codeaurora.org/ [3] https://www.spinics.net/lists/linux-pwm/msg11906.html [4] https://www.spinics.net/lists/linux-pwm/msg11986.html To: Arnd Bergmann To: David Laight To: Jani Nikula Cc: Alexander Shiyan Cc: Alexandre Torgue Cc: Allison Randal Cc: Arnd Bergmann Cc: Atish Patra Cc: Bartlomiej Zolnierkiewicz Cc: Chen-Yu Tsai Cc: Chris Wilson Cc: Dan Carpenter Cc: Daniel Thompson Cc: Daniel Vetter Cc: David Airlie Cc: David Collins Cc: dri-devel@lists.freedesktop.org Cc: Fabio Estevam Cc: Fabrice Gasnier Cc: Guenter Roeck Cc: intel-...@lists.freedesktop.org Cc: Jean Delvare Cc: Jingoo Han Cc: Joe Perches Cc: Joonas Lahtinen Cc: Kamil Debski Cc: Kate Stewart Cc: Lee Jones Cc: Liam Girdwood Cc: linux-...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: linux-hw...@vge
Re: [PATCH v4] drm/i915: Synchronize active and retire callbacks
On Tue, Apr 21, 2020 at 09:51:37AM +0300, Joonas Lahtinen wrote: > Quoting Sultan Alsawaf (2020-04-20 19:15:14) > > On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote: > > > So it seems that the patch got pulled into v5.6 and has been backported > > > to v5.5 but not v5.4. > > > > You're right, that's my mistake. > > Did applying the patch to v5.4 fix the issue at hand? Of course the patch doesn't apply as-is because the code's been shuffled around, but yes. The crashes are gone with that patch, and I don't have the motivation to check if that patch is actually correct, so hurray, problem solved. I'm not going to send the backport myself because I'll probably be ignored, so you can go ahead and do that. Sultan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 2/5] mm/hmm: make hmm_range_fault return 0 or -1
From: Jason Gunthorpe
hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault() for anything other than error.
More importantly last must be set before returning -EBUSY as it is used to
prevent reading an output pfn as an input flags when the loop restarts.
For clarity and simplicity make hmm_range_fault() return 0 or -ERRNO. Only
set last when returning -EBUSY.
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_svm.c | 6 +++---
include/linux/hmm.h | 2 +-
mm/hmm.c| 25 +
5 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 4e3e9362afeb10..9924f2caa0184c 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -161,7 +161,7 @@ device must complete the update before the driver callback
returns.
When the device driver wants to populate a range of virtual addresses, it can
use::
- long hmm_range_fault(struct hmm_range *range);
+ int hmm_range_fault(struct hmm_range *range);
It will trigger a page fault on missing or read-only entries if write access is
requested (see below). Page faults use the generic mm page fault code path just
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6309ff72bd7876..efc1329a019127 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -852,12 +852,12 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
struct page **pages)
down_read(&mm->mmap_sem);
r = hmm_range_fault(range);
up_read(&mm->mmap_sem);
- if (unlikely(r <= 0)) {
+ if (unlikely(r)) {
/*
* FIXME: This timeout should encompass the retry from
* mmu_interval_read_retry() as well.
*/
- if ((r == 0 || r == -EBUSY) && !time_after(jiffies, timeout))
+ if ((r == -EBUSY) && !time_after(jiffies, timeout))
goto retry;
goto out_free_pfns;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 645fedd77e21b4..c68e9317cf0740 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -536,7 +536,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
.pfn_shift = NVIF_VMM_PFNMAP_V0_ADDR_SHIFT,
};
struct mm_struct *mm = notifier->notifier.mm;
- long ret;
+ int ret;
while (true) {
if (time_after(jiffies, timeout))
@@ -548,8 +548,8 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
down_read(&mm->mmap_sem);
ret = hmm_range_fault(&range);
up_read(&mm->mmap_sem);
- if (ret <= 0) {
- if (ret == 0 || ret == -EBUSY)
+ if (ret) {
+ if (ret == -EBUSY)
continue;
return ret;
}
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 7475051100c782..0df27dd03d53d7 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -120,7 +120,7 @@ static inline struct page *hmm_device_entry_to_page(const
struct hmm_range *rang
/*
* Please see Documentation/vm/hmm.rst for how to use the range API.
*/
-long hmm_range_fault(struct hmm_range *range);
+int hmm_range_fault(struct hmm_range *range);
/*
* HMM_RANGE_DEFAULT_TIMEOUT - default timeout (ms) when waiting for a range
diff --git a/mm/hmm.c b/mm/hmm.c
index 280585833adfc1..4c7c396655b528 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -174,7 +174,6 @@ static int hmm_vma_walk_hole(unsigned long addr, unsigned
long end,
}
if (required_fault)
return hmm_vma_fault(addr, end, required_fault, walk);
- hmm_vma_walk->last = addr;
return hmm_pfns_fill(addr, end, range, HMM_PFN_NONE);
}
@@ -207,7 +206,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
unsigned long addr,
pfn = pmd_pfn(pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
for (i = 0; addr < end; addr += PAGE_SIZE, i++, pfn++)
pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
- hmm_vma_walk->last = end;
return 0;
}
#else /* CONFIG_TRANSPARENT_HUGEPAGE */
@@ -386,13 +384,10 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, pfns);
if (r) {
/* hmm_vma_handle_pte() did pte_unmap() */
- hmm_vma_walk->last = addr;
[PATCH hmm 0/5] Adjust hmm_range_fault() API
From: Jason Gunthorpe
The API is a bit complicated for the uses we actually have, and
disucssions for simplifying have come up a number of times.
This small series removes the customizable pfn format and simplifies the
return code of hmm_range_fault()
All the drivers are adjusted to process in the simplified format.
I would appreciated tested-by's for the two drivers, thanks!
This passes the hmm tester with the following diff:
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index d75e18f2ffd245..a2442efa038c41 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -47,23 +47,8 @@ struct dmirror_bounce {
unsigned long cpages;
};
-#define DPT_SHIFT PAGE_SHIFT
-#define DPT_VALID (1UL << 0)
-#define DPT_WRITE (1UL << 1)
-
#define DPT_XA_TAG_WRITE 3UL
-static const uint64_t dmirror_hmm_flags[HMM_PFN_FLAG_MAX] = {
- [HMM_PFN_VALID] = DPT_VALID,
- [HMM_PFN_WRITE] = DPT_WRITE,
-};
-
-static const uint64_t dmirror_hmm_values[HMM_PFN_VALUE_MAX] = {
- [HMM_PFN_NONE]= 0,
- [HMM_PFN_ERROR] = 0x10,
- [HMM_PFN_SPECIAL] = 0x10,
-};
-
/*
* Data structure to track address ranges and register for mmu interval
* notifier updates.
@@ -175,7 +160,7 @@ static inline struct dmirror_device
*dmirror_page_to_device(struct page *page)
static int dmirror_do_fault(struct dmirror *dmirror, struct hmm_range *range)
{
- uint64_t *pfns = range->pfns;
+ unsigned long *pfns = range->hmm_pfns;
unsigned long pfn;
for (pfn = (range->start >> PAGE_SHIFT);
@@ -188,15 +173,16 @@ static int dmirror_do_fault(struct dmirror *dmirror,
struct hmm_range *range)
* Since we asked for hmm_range_fault() to populate pages,
* it shouldn't return an error entry on success.
*/
- WARN_ON(*pfns == range->values[HMM_PFN_ERROR]);
+ WARN_ON(*pfns & HMM_PFN_ERROR);
+ WARN_ON(!(*pfns & HMM_PFN_VALID));
- page = hmm_device_entry_to_page(range, *pfns);
+ page = hmm_pfn_to_page(*pfns);
WARN_ON(!page);
entry = page;
- if (*pfns & range->flags[HMM_PFN_WRITE])
+ if (*pfns & HMM_PFN_WRITE)
entry = xa_tag_pointer(entry, DPT_XA_TAG_WRITE);
- else if (range->default_flags & range->flags[HMM_PFN_WRITE])
+ else if (WARN_ON(range->default_flags & HMM_PFN_WRITE))
return -EFAULT;
entry = xa_store(&dmirror->pt, pfn, entry, GFP_ATOMIC);
if (xa_is_err(entry))
@@ -260,8 +246,6 @@ static int dmirror_range_fault(struct dmirror *dmirror,
int ret;
while (true) {
- long count;
-
if (time_after(jiffies, timeout)) {
ret = -EBUSY;
goto out;
@@ -269,12 +253,11 @@ static int dmirror_range_fault(struct dmirror *dmirror,
range->notifier_seq = mmu_interval_read_begin(range->notifier);
down_read(&mm->mmap_sem);
- count = hmm_range_fault(range);
+ ret = hmm_range_fault(range);
up_read(&mm->mmap_sem);
- if (count <= 0) {
- if (count == 0 || count == -EBUSY)
+ if (ret) {
+ if (ret == -EBUSY)
continue;
- ret = count;
goto out;
}
@@ -299,16 +282,13 @@ static int dmirror_fault(struct dmirror *dmirror,
unsigned long start,
{
struct mm_struct *mm = dmirror->notifier.mm;
unsigned long addr;
- uint64_t pfns[64];
+ unsigned long pfns[64];
struct hmm_range range = {
.notifier = &dmirror->notifier,
- .pfns = pfns,
- .flags = dmirror_hmm_flags,
- .values = dmirror_hmm_values,
- .pfn_shift = DPT_SHIFT,
+ .hmm_pfns = pfns,
.pfn_flags_mask = 0,
- .default_flags = dmirror_hmm_flags[HMM_PFN_VALID] |
- (write ? dmirror_hmm_flags[HMM_PFN_WRITE] : 0),
+ .default_flags =
+ HMM_PFN_REQ_FAULT | (write ? HMM_PFN_REQ_WRITE : 0),
.dev_private_owner = dmirror->mdevice,
};
int ret = 0;
@@ -754,19 +734,20 @@ static int dmirror_migrate(struct dmirror *dmirror,
}
static void dmirror_mkentry(struct dmirror *dmirror, struct hmm_range *range,
- unsigned char *perm, uint64_t entry)
+ unsigned char *perm, unsigned long entry)
{
struct page *page;
- if (entry == range->values[HMM_PFN_ERROR]) {
+ if (entry & HMM_PFN_ERROR) {
*perm = HMM_DMIRROR_PROT_ERROR;
return;
}
- page = hmm_device_entry_to_page(range, entry);
- if (!page) {
+ if (!
[PATCH v2 8/9] drm/msm/a6xx: enable GMU log
This is required for a650 to work.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 4
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 60ed5360fd8a..f24e436daafe 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -201,6 +201,12 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
u32 val;
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
+
+ /* Set the log wptr index
+* note: downstream saves the value in poweroff and restores it here
+*/
+ gmu_write(gmu, REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_RESP, 0);
+
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 0);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_CM3_FW_INIT_RESULT, val,
@@ -740,6 +746,9 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned
int state)
gmu_write(gmu, REG_A6XX_GMU_HFI_SFR_ADDR, chipid);
+ gmu_write(gmu, REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_MSG,
+ gmu->log.iova | (gmu->log.size / SZ_4K - 1));
+
/* Set up the lowest idle level on the GMU */
a6xx_gmu_power_config(gmu);
@@ -1046,6 +1055,7 @@ static void a6xx_gmu_memory_free(struct a6xx_gmu *gmu)
msm_gem_kernel_put(gmu->icache.obj, gmu->aspace, false);
msm_gem_kernel_put(gmu->dcache.obj, gmu->aspace, false);
msm_gem_kernel_put(gmu->dummy.obj, gmu->aspace, false);
+ msm_gem_kernel_put(gmu->log.obj, gmu->aspace, false);
gmu->aspace->mmu->funcs->detach(gmu->aspace->mmu);
msm_gem_address_space_put(gmu->aspace);
@@ -1450,6 +1460,11 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (ret)
goto err_memory;
+ /* Allocate memory for the GMU log region */
+ ret = a6xx_gmu_memory_alloc(gmu, &gmu->log, SZ_4K, 0);
+ if (ret)
+ goto err_memory;
+
/* Map the GMU registers */
gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
if (IS_ERR(gmu->mmio)) {
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index aed02b2b7659..be65720f32cf 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -61,6 +61,7 @@ struct a6xx_gmu {
struct a6xx_gmu_bo icache;
struct a6xx_gmu_bo dcache;
struct a6xx_gmu_bo dummy;
+ struct a6xx_gmu_bo log;
int nr_clocks;
struct clk_bulk_data *clocks;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
index b4357ea550ec..176ae94d9fe6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
@@ -205,6 +205,10 @@ static inline uint32_t A6XX_GMU_GPU_NAP_CTRL_SID(uint32_t
val)
#define REG_A6XX_GPU_GMU_CX_GMU_CX_FAL_INTF0x50f0
+#define REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_MSG 0x5100
+
+#define REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_RESP
0x5101
+
#define REG_A6XX_GMU_BOOT_KMD_LM_HANDSHAKE 0x51f0
#define REG_A6XX_GMU_LLM_GLM_SLEEP_CTRL
0x5157
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [V3] amdgpu: remove unnecessary condition check
>> But i have to say there are so many code not follow the kernel code-style in >> amdgpu module. >> And also the ./scripts/checkpatch.pl did not throw any warning or error. > > That is unfortunately true, yes. But we try to push new code through the > usual code review and improve things as we go. > > On the other hand patches just to fix the coding style are usually seen as an > unnecessary interruption and just a waste of time. Would you become interested in adjusting deviations from known programming guidelines in an automatic way with the help of corresponding advanced development tools? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [V3] amdgpu: remove unnecessary condition check
>>> There is no need to if check again, maybe we could merge >>> into the above else branch. I find also this commit message still improvable (besides the mentioned implementation details around coding style concerns). How will corresponding review comments be taken better into account? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
> Am 21.04.2020 um 16:15 schrieb Tony Lindgren : > > * Maxime Ripard [200421 11:22]: >> On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote: >>> I had a look on genpd and I'm not really sure if that fits. >>> >>> It is basically some bit that verify that the clocks should be enabled or >>> disabled. >> >> No, it can do much more than that. It's a framework to control the SoCs power >> domains, so clocks might be a part of it, but most of the time it's going to >> be >> about powering up a particular device. > > Note that on omaps there are actually SoC module specific registers. Ah, I see. This is of course a difference that the TI glue logic has its own registers in the same address range as the sgx and this can't be easily handled by a common sgx driver. This indeed seems to be unique with omap. > And there can be multiple devices within a single target module on > omaps. So the extra dts node and device is justified there. > > For other SoCs, the SGX clocks are probably best handled directly > in pvr-drv.c PM runtime functions unless a custom hardware wrapper > with SoC specific registers exists. That is why we need to evaluate what the better strategy is. So we have a) omap which has a custom wrapper around the sgx b) others without, i.e. an empty (or pass-through) wrapper Which one do we make the "standard" and which one the "exception"? What are good reasons for either one? I am currently in strong favour of a) being standard because it makes the pvr-drv.c simpler and really generic (independent of wrapping into any SoC). This will likely avoid problems if we find more SoC with yet another scheme how the SGX clocks are wrapped. It also allows to handle different number of clocks (A31 seems to need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings or making big lists of conditionals. This variance would be handled outside the sgx core bindings and driver. So instead of an img+omap.yaml and an img+a81.yaml and an img+a31.yaml etc. we have a single img,pvrsgx.yaml and individual wrappers (the omap one already exists as bindings/bus/ti-sysc.txt). The only drawback is that we need this "pass-through" wrapper in DTS and driver code to handle clocks, power etc. The second best solution in my view is to make b) the standard and allow the clock(s) to be optional to cover the omap case. And conditionals are added to properly describe the variance of how the sgx is wrapped/integrated. IMHO this is a decision which can not be easily revised later. It is an architectural decision. So we should base it on strategic goals. > > > Regards, > > Tony > BR and thanks for clarification, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Hi, On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote: > On 20.04.20 09:38, Maxime Ripard wrote: > > Hi, > > > > On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote: > > > > > I'm a bit skeptical on that one since it doesn't even list the > > > > > interrupts connected to the GPU that the binding mandates. > > > > > > > > I think he left it out for a future update. > > > > But best he comments himself. > > > > > > I'm currently working on those bindings. They are now 90% done, but they > > > are > > > not finished till now. Currently there is some mainline support missing to > > > add the full binding. The A83T and also the A31/A31s have a GPU Power Off > > > Gating Register in the R_PRCM module, that is not supported right now in > > > Mainline. The Register need to be written when the GPU is powered on and > > > off. > > > > > > @Maxime: I totally agree on your point that a demo needs to be provided > > > before the related DTS patches should be provided. That's the reason why I > > > added the gpu placeholder patches. > > > Do you have an idea how a driver for the R_PRCM stuff can look like? I'm > > > not > > > that experienced with the clock driver framework. > > > > It looks like a power-domain to me, so you'd rather plug that into the genpd > > framework. > > I had a look on genpd and I'm not really sure if that fits. > > It is basically some bit that verify that the clocks should be enabled or > disabled. No, it can do much more than that. It's a framework to control the SoCs power domains, so clocks might be a part of it, but most of the time it's going to be about powering up a particular device. > I think this is better placed somewhere in the clocking framework. > I see there more similarities to the gating stuff. > Do you think it is suitable to implement it like the clock gating? I'm really not sure what makes you think that this should be modelled as a clock? > > > The big question is right now how to proceed with the A83T and A31s > > > patches. > > > I see there three options, which one do you prefer?: > > > > > > 1. Provide now placeholder patches and send new patches, if everything is > > > clear and other things are mainlined > > > 2. Provide now patches as complete as possible and provide later patches > > > to > > > complete them when the R_PRCM things are mainlined > > > 3. Leave them out, till the related work is mainlined and the bindings are > > > final. > > > > Like I said, the DT *has* to be backward-compatible, so for any DT patch > > that > > you are asking to be merged, you should be prepared to support it > > indefinitely > > and be able to run from it, and you won't be able to change the bindings > > later > > on. > > I agree on your points. But is this also suitable to drivers that are > currently off tree and might be merged in one or two years? This is what we done for the Mali. The devicetree binding was first done for the out-of-tree driver, and then lima/panfrost reused it. The key thing here is to have enough confidence about how the hardware works so that you can accurately describe it. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
On 4/16/20 6:22 PM, Chun-Kuang Hu wrote: > Hi, Matthias: > > Matthias Brugger 於 2020年3月26日 週四 下午11:45寫道： >> >> >> >> On 26/03/2020 15:51, CK Hu wrote: >>> Hi, Matthias: >>> >>> On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote: Hi CK, On 26/03/2020 00:05, CK Hu wrote: > Hi, Matthias: > > On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote: >> >> On 11/03/2020 17:53, Enric Balletbo i Serra wrote: >>> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions >>> to >>> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path(). >>> Those functions will allow DRM driver and others to control the data >>> path routing. >>> >>> Signed-off-by: Enric Balletbo i Serra >>> Reviewed-by: Matthias Brugger >>> Reviewed-by: CK Hu >>> Acked-by: CK Hu >> >> This patch does not apply against v5.6-rc1. >> Please rebase as this is a quite big patch and it won't be easy to do >> that by hand. > > I think this patch depends on [1] which has been acked by me and I have > not picked it. The simple way is that you pick [1] first and then pick > this series. > > [1] > https://patchwork.kernel.org/patch/11406227/ > You would need to provide a stable tag for me that I can merge into my tree. You can also try to merge my for-next [1] which has the newest version from Enric. If you see any merge conflict, then we have to do something about it :) Regards, Matthias [1] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next >>> >>> You have applied this series, so I would not apply other patches which >>> would conflict with this series. After this series land on main stream >>> (wish it happen in this merge window), I would rebase other patch on >>> main stream. >>> >> >> I haven't (yet) send the pull request. If you want to bring in your patches >> in >> v5.7 as well we can find a solution to that. Shall I provide you with a >> stable >> branch which you can merge? This way you can add all your patches in the pull >> request as well and we don't have to wait for v5.8 to get things into >> mainline. >> >> Let me know and I'll provide you with a stable branch. > > This series is in linux-next but does not in main stream. So would you > please provide a stable branch so I could pull this series? > Please find the pull request below: The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/ tags/v5.7-next-drm-stable for you to fetch changes up to 667c769246b01c53ad0925d603d2a2531abd3ef2: soc / drm: mediatek: Fix mediatek-drm device probing (2020-04-13 13:01:16 +0200) Enric Balletbo i Serra (3): dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller soc / drm: mediatek: Move routing control to mmsys device soc / drm: mediatek: Fix mediatek-drm device probing Matthias Brugger (2): drm/mediatek: Omit warning on probe defers clk / soc: mediatek: Move mt8173 MMSYS to platform driver Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt | 7 +-- drivers/clk/mediatek/Kconfig | 7 +++ drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++ drivers/clk/mediatek/clk-mt8173.c | 104 -- drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 ++- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 ++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 ++- drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 259 + drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 7 --- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 45 ++- drivers/gpu/drm/mediatek/mtk_drm_drv.h| 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c| 8 +++- drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +- drivers/soc/mediatek/Kconfig | 8 drivers/soc/medi
[PATCH V3] amdgpu: remove unnecessary condition check
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226587/
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..5424bd921a7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -660,13 +660,12 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else {
- pr_err("Failed to reserve buffers in ttm\n");
+ if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
- }
+ } else
+ ctx->reserved = true;
return ret;
}
@@ -733,15 +732,12 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else
- pr_err("Failed to reserve buffers in ttm.\n");
-
if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
- }
+ } else
+ ctx->reserved = true;
return ret;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/xen-front: Add support for Xen PV display frontend
On Tue, 21 Apr 2020, Dan Carpenter wrote:
> On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Apr 2020, Dan Carpenter wrote:
> >
> > > Hi Kernel Janitors,
> > >
> > > Here is another idea that someone could work on, fixing the
> > > IS_ERR_OR_NULL() checks in the xen driver.
> > >
> > > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> > > display frontend" from Apr 3, 2018, leads to the following static
> > > checker warning:
> > >
> > > drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> > > warn: passing zero to 'ERR_CAST'
> > >
> > > drivers/gpu/drm/xen/xen_drm_front_gem.c
> > >133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device
> > > *dev,
> > >134 size_t size)
> > >135 {
> > >136 struct xen_gem_object *xen_obj;
> > >137
> > >138 xen_obj = gem_create(dev, size);
> > >139 if (IS_ERR_OR_NULL(xen_obj))
> > >140 return ERR_CAST(xen_obj);
> >
> > Are the other occurrences of this also a possible problem? There are a
> > few others outside of xen.
>
> We sometimes check a parameter for IS_ERR_OR_NULL().
>
> void free_function(struct something *p)
> {
> if (IS_ERR_OR_NULL(p))
> return;
> }
>
> That's fine, absolutely harmless and not a bug. But if we are checking
> a return value like this then probably most of the time it's invalid
> code. Normally it's again like this code where we're dealing with an
> impossible thing because the return is never NULL. The common bugs are
> that it returns NULL to a caller which only expects error pointers or it
> returns success instead of failure. But sometimes returning success can
> be valid:
>
> obj = get_feature(dev);
> if (IS_ERR_OR_NULL(obj))
> return PTR_ERR(obj);
>
> It deliberately returns success because the rest of the function is
> useless when we don't have the feature.
The other cases are also with ERR_CAST:
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c in create_udp_flow
fs/overlayfs/namei.c in ovl_index_upper
sound/soc/qcom/qdsp6/q6adm.c in q6adm_open
drivers/clk/clk.c in clk_hw_create_clk
julia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4] amdgpu: reduce no need mutex_lock area
Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Changes since V3:
*lock protect the if check, there is some possibility of multi-threaded
racing modify.
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226588/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 327317c54f7c..549bdb429883 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1289,9 +1289,9 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
mutex_lock(&mem->lock);
if (mem->mapped_to_gpu_memory > 0) {
+ mutex_unlock(&mem->lock);
pr_debug("BO VA 0x%llx size 0x%lx is still mapped.\n",
mem->va, bo_size);
- mutex_unlock(&mem->lock);
return -EBUSY;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm/amdgpu: cleanup coding style in amdkfd a bit
Make the code a bit more readable by using a common
error handling pattern.
With that done the patch is Reviewed-by: Christian König
.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the best way to merge unnecessary if/else check branch
Changes since V4:
*Improve the subject line and commit message
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226587/
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 20 +--
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..acb612c53b9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -660,15 +660,15 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else {
- pr_err("Failed to reserve buffers in ttm\n");
+ if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
+ return ret;
}
- return ret;
+ ctx->reserved = true;
+ return 0;
}
/**
@@ -733,17 +733,15 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else
- pr_err("Failed to reserve buffers in ttm.\n");
-
if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
+ return ret;
}
- return ret;
+ ctx->reserved = true;
+ return 0;
}
/**
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:Re: [PATCH] amdgpu: fixes memleak issue when init failed
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher
,"David (ChunMing) Zhou" ,David
Airlie ,Daniel Vetter ,Tom St Denis
,Ori Messinger ,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20
um 13:17 schrieb Bernard Zhao:
>> VRAM manager and DRM MM when init failed, there is no operaction
>> to free kzalloc memory & remove device file.
>> This will lead to memleak & cause stability issue.
>
>NAK, failure to create sysfs nodes are not critical.
>
>Christian.
>
OK, get it.
By the way, should i modify this patch to just handle in error
branch, or that it is also unnecessary?
Regards,
Bernard
>>
>> Signed-off-by: Bernard Zhao
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
>> 1 file changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> index 82a3299e53c0..4c5fb153e6b4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> @@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
>> ttm_mem_type_manager *man,
>> ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_total);
>> if (ret) {
>> DRM_ERROR("Failed to create device file mem_info_vram_total\n");
>> -return ret;
>> +goto VRAM_TOTAL_FAIL;
>> }
>> ret = device_create_file(adev->dev, &dev_attr_mem_info_vis_vram_total);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vis_vram_total\n");
>> -return ret;
>> +goto VIS_VRAM_TOTA_FAIL;
>> }
>> ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_used);
>> if (ret) {
>> DRM_ERROR("Failed to create device file mem_info_vram_used\n");
>> -return ret;
>> +goto VRAM_USED_FAIL;
>> }
>> ret = device_create_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vis_vram_used\n");
>> -return ret;
>> +goto VIS_VRAM_USED_FAIL;
>> }
>> ret = device_create_file(adev->dev, &dev_attr_mem_info_vram_vendor);
>> if (ret) {
>> DRM_ERROR("Failed to create device file
>> mem_info_vram_vendor\n");
>> -return ret;
>> +goto VRAM_VERDOR_FAIL;
>> }
>>
>> return 0;
>> +
>> +VRAM_VERDOR_FAIL:
>> +device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
>> +VIS_VRAM_USED_FAIL:
>> +device_remove_file(adev->dev, &dev_attr_mem_info_vram_used);
>> +RVAM_USED_FAIL:
>> +device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_total);
>> +VIS_VRAM_TOTA_FAIL:
>> +device_remove_file(adev->dev, &dev_attr_mem_info_vram_total);
>> +VRAM_TOTAL_FAIL:
>> +kfree(mgr);
>> +man->priv = NULL;
>> +
>> +return ret;
>> }
>>
>> /**
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/9] drm/msm/a6xx: use msm_gem for GMU memory objects
This gives more fine-grained control over how memory is allocated over the
DMA api. In particular, it allows using an address range or pinning to
a fixed address.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 115 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 9 +-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 6 +-
3 files changed, 88 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index c4e71abbdd53..c9fd0470a321 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -2,14 +2,16 @@
/* Copyright (c) 2017-2019 The Linux Foundation. All rights reserved. */
#include
-#include
#include
#include
#include
#include
+#include
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
+#include "msm_gem.h"
+#include "msm_mmu.h"
static void a6xx_gmu_fault(struct a6xx_gmu *gmu)
{
@@ -620,7 +622,7 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned
int state)
gmu_write(gmu, REG_A6XX_GMU_CM3_BOOT_CONFIG, 0x02);
/* Write the iova of the HFI table */
- gmu_write(gmu, REG_A6XX_GMU_HFI_QTBL_ADDR, gmu->hfi->iova);
+ gmu_write(gmu, REG_A6XX_GMU_HFI_QTBL_ADDR, gmu->hfi.iova);
gmu_write(gmu, REG_A6XX_GMU_HFI_QTBL_INFO, 1);
gmu_write(gmu, REG_A6XX_GMU_AHB_FENCE_RANGE_0,
@@ -919,34 +921,77 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
return 0;
}
-static void a6xx_gmu_memory_free(struct a6xx_gmu *gmu, struct a6xx_gmu_bo *bo)
+static void a6xx_gmu_memory_free(struct a6xx_gmu *gmu)
{
- if (IS_ERR_OR_NULL(bo))
- return;
+ msm_gem_kernel_put(gmu->hfi.obj, gmu->aspace, false);
+ msm_gem_kernel_put(gmu->debug.obj, gmu->aspace, false);
+
+ gmu->aspace->mmu->funcs->detach(gmu->aspace->mmu);
+ msm_gem_address_space_put(gmu->aspace);
+}
+
+static int a6xx_gmu_memory_alloc(struct a6xx_gmu *gmu, struct a6xx_gmu_bo *bo,
+ size_t size, u64 iova)
+{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct drm_device *dev = a6xx_gpu->base.base.dev;
+ uint32_t flags = MSM_BO_WC;
+ u64 range_start, range_end;
+ int ret;
+
+ size = PAGE_ALIGN(size);
+ if (!iova) {
+ /* no fixed address - use GMU's uncached range */
+ range_start = 0x6000;
+ range_end = 0x8000;
+ } else {
+ /* range for fixed address */
+ range_start = iova;
+ range_end = iova + size;
+ }
+
+ bo->obj = msm_gem_new(dev, size, flags);
+ if (IS_ERR(bo->obj))
+ return PTR_ERR(bo->obj);
- dma_free_wc(gmu->dev, bo->size, bo->virt, bo->iova);
- kfree(bo);
+ ret = msm_gem_get_and_pin_iova_range(bo->obj, gmu->aspace, &bo->iova,
+ range_start >> PAGE_SHIFT, range_end >> PAGE_SHIFT);
+ if (ret) {
+ drm_gem_object_put(bo->obj);
+ return ret;
+ }
+
+ bo->virt = msm_gem_get_vaddr(bo->obj);
+ bo->size = size;
+
+ return 0;
}
-static struct a6xx_gmu_bo *a6xx_gmu_memory_alloc(struct a6xx_gmu *gmu,
- size_t size)
+static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
{
- struct a6xx_gmu_bo *bo;
+ struct iommu_domain *domain;
+ int ret;
- bo = kzalloc(sizeof(*bo), GFP_KERNEL);
- if (!bo)
- return ERR_PTR(-ENOMEM);
+ domain = iommu_domain_alloc(&platform_bus_type);
+ if (!domain)
+ return -ENODEV;
- bo->size = PAGE_ALIGN(size);
+ domain->geometry.aperture_start = 0x;
+ domain->geometry.aperture_end = 0x7fff;
- bo->virt = dma_alloc_wc(gmu->dev, bo->size, &bo->iova, GFP_KERNEL);
+ gmu->aspace = msm_gem_address_space_create(gmu->dev, domain, "gmu");
+ if (IS_ERR(gmu->aspace)) {
+ iommu_domain_free(domain);
+ return PTR_ERR(gmu->aspace);
+ }
- if (!bo->virt) {
- kfree(bo);
- return ERR_PTR(-ENOMEM);
+ ret = gmu->aspace->mmu->funcs->attach(gmu->aspace->mmu);
+ if (ret) {
+ msm_gem_address_space_put(gmu->aspace);
+ return ret;
}
- return bo;
+ return 0;
}
/* Return the 'arc-level' for the given frequency */
@@ -1204,7 +1249,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
iounmap(gmu->mmio);
gmu->mmio = NULL;
- a6xx_gmu_memory_free(gmu, gmu->hfi);
+ a6xx_gmu_memory_free(gmu);
free_irq(gmu->gmu_irq, gmu);
free_irq(gmu->hfi_irq, gmu);
@@ -1226,15 +1271,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->dev = &pdev->dev;
- /* Pass force_dma false to require the DT to set the dma region */
- ret = of_dma_configure(gmu->dev, node, false);
-
Re:Re: [PATCH] amdgpu: fixes memleak issue when init failed
发件人："Christian König"
发送日期：2020-04-21 21:02:27
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter
,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
主题：Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am 21.04.20 um
14:09 schrieb 赵军奎:
>> From: "Christian König"
>> Date: 2020-04-21 19:22:49
>> To: Bernard Zhao ,Alex Deucher
>> ,"David (ChunMing) Zhou"
>> ,David Airlie ,Daniel Vetter
>> ,Tom St Denis ,Ori Messinger
>> ,Sam Ravnborg
>> ,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
>> Cc: opensource.ker...@vivo.com
>> Subject: Re: [PATCH] amdgpu: fixes memleak issue when init failed>Am
>> 21.04.20 um 13:17 schrieb Bernard Zhao:
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
>>> NAK, failure to create sysfs nodes are not critical.
>>>
>>> Christian.
>>>
>> OK, get it.
>> By the way, should i modify this patch to just handle in error
>> branch, or that it is also unnecessary?
>
>What you can do is to drop the "return ret" if anything with the sysfs
>nodes goes wrong and instead print the error code.
Emmm, for this part, i am not sure, my modify first print the error, secone
release not free memory,
and last return error, make everything clear to the system.
I think it`s the same with what you mentioned, is there something that I
misunderstood?
>
>It's really annoying that loading, unloading and loading the driver
>again sometimes fails because we have a bug in the sysfs files cleanup.
>
>We certainly should fix those bugs as well, but they are just not
>critical for correct driver functionality.
>
>Regards,
>Christian.
>>
>> Regards,
>> Bernard
>>
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 82a3299e53c0..4c5fb153e6b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -175,30 +175,44 @@ static int amdgpu_vram_mgr_init(struct
ttm_mem_type_manager *man,
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_total\n");
- return ret;
+ goto VRAM_TOTAL_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vis_vram_total);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_total\n");
- return ret;
+ goto VIS_VRAM_TOTA_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_used\n");
- return ret;
+ goto VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vis_vram_used);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vis_vram_used\n");
- return ret;
+ goto VIS_VRAM_USED_FAIL;
}
ret = device_create_file(adev->dev,
&dev_attr_mem_info_vram_vendor);
if (ret) {
DRM_ERROR("Failed to create device file
mem_info_vram_vendor\n");
- return ret;
+ goto VRAM_VERDOR_FAIL;
}
return 0;
+
+VRAM_VERDOR_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_used);
+VIS_VRAM_USED_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_used);
+RVAM_USED_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vis_vram_total);
+VIS_VRAM_TOTA_FAIL:
+ device_remove_file(adev->dev, &dev_attr_mem_info_vram_total);
+VRAM_TOTAL_FAIL:
+ kfree(mgr);
+ man->priv = NULL;
+
+ return ret;
}
/**
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_range_fault() provides CPU addresses which must be DMA mapped.
Perhaps there is some special HW that does not need DMA mapping, but we
don't have any examples of this, and the theoretical performance win of
avoiding an extra scan over the pfns array doesn't seem worth the
complexity. Plus pfns needs to be scanned anyhow to sort out any
DEVICE_PRIVATE pages.
This version replaces the uint64_t with an usigned long containing a pfn
and fix flags. On input flags is filled with the HMM_PFN_REQ_* values, on
successful output it is filled with HMM_PFN_* values, describing the state
of the pages.
amdgpu is simple to convert, it doesn't use snapshot and doesn't use
per-page flags.
nouveau uses only 16 hmm_pte entries at most (ie fits in a few cache
lines), and it sweeps over its pfns array a couple of times anyhow.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
---
Documentation/vm/hmm.rst| 26 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 35 ++
drivers/gpu/drm/nouveau/nouveau_dmem.c | 60 +++--
drivers/gpu/drm/nouveau/nouveau_dmem.h | 4 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 52
include/linux/hmm.h | 99 ++-
mm/hmm.c| 160 +++-
7 files changed, 204 insertions(+), 232 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 9924f2caa0184c..73a9b8c858e5d9 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -185,9 +185,6 @@ The usage pattern is::
range.start = ...;
range.end = ...;
range.pfns = ...;
- range.flags = ...;
- range.values = ...;
- range.pfn_shift = ...;
if (!mmget_not_zero(interval_sub->notifier.mm))
return -EFAULT;
@@ -229,15 +226,10 @@ The hmm_range struct has 2 fields, default_flags and
pfn_flags_mask, that specif
fault or snapshot policy for the whole range instead of having to set them
for each entry in the pfns array.
-For instance, if the device flags for range.flags are::
+For instance if the device driver wants pages for a range with at least read
+permission, it sets::
-range.flags[HMM_PFN_VALID] = (1 << 63);
-range.flags[HMM_PFN_WRITE] = (1 << 62);
-
-and the device driver wants pages for a range with at least read permission,
-it sets::
-
-range->default_flags = (1 << 63);
+range->default_flags = HMM_PFN_REQ_VALID;
range->pfn_flags_mask = 0;
and calls hmm_range_fault() as described above. This will fill fault all pages
@@ -246,18 +238,18 @@ in the range with at least read permission.
Now let's say the driver wants to do the same except for one page in the range
for
which it wants to have write permission. Now driver set::
-range->default_flags = (1 << 63);
-range->pfn_flags_mask = (1 << 62);
-range->pfns[index_of_write] = (1 << 62);
+range->default_flags = HMM_PFN_REQ_VALID;
+range->pfn_flags_mask = HMM_PFN_REQ_WRITE;
+range->pfns[index_of_write] = HMM_PFN_REQ_WRITE;
With this, HMM will fault in all pages with at least read (i.e., valid) and
for the
address == range->start + (index_of_write << PAGE_SHIFT) it will fault with
write permission i.e., if the CPU pte does not have write permission set then
HMM
will call handle_mm_fault().
-Note that HMM will populate the pfns array with write permission for any page
-that is mapped with CPU write permission no matter what values are set
-in default_flags or pfn_flags_mask.
+After hmm_range_fault completes the flag bits are set to the current state of
+the page tables, ie HMM_PFN_VALID | HMM_PFN_WRITE will be set if the page is
+writable.
Represent and manage device memory from core kernel point of view
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 449083f9f8a2bf..bcfa8c26647d5e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -766,17 +766,6 @@ struct amdgpu_ttm_tt {
};
#ifdef CONFIG_DRM_AMDGPU_USERPTR
-/* flags used by HMM internal, not related to CPU/GPU PTE flags */
-static const uint64_t hmm_range_flags[HMM_PFN_FLAG_MAX] = {
- (1 << 0), /* HMM_PFN_VALID */
- (1 << 1), /* HMM_PFN_WRITE */
-};
-
-static const uint64_t hmm_range_values[HMM_PFN_VALUE_MAX] = {
- 0xfffeUL, /* HMM_PFN_ERROR */
- 0, /* HMM_PFN_NONE */
-};
-
/**
* amdgpu_ttm_tt_get_user_pages - get device accessible pages that back user
* memory and start HMM tracking CPU page table update
@@ -815,18 +804,15 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
struct page **pages)
goto out;
}
range->notifier = &bo->notif
[add Markus.Elfring in mail list ]Re:Re: [PATCH V4] amdgpu: reduce no need mutex_lock area
From: "Christian König"
Date: 2020-04-21 15:41:27
To: 1587181464-114215-1-git-send-email-bern...@vivo.com,Felix Kuehling
,Alex Deucher ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com,Bernard Zhao
Subject: Re: [PATCH V4] amdgpu: reduce no need mutex_lock area>Am 21.04.20 um
09:36 schrieb Bernard Zhao:
>> Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
>> and no need to protect pr_debug.
>
>Well that change looks rather superfluous to me.
>
>This is for freeing memory which by definition can only be done once and
>so the should be exactly zero contention on the lock except in a case of
>an error.
>
>Regards,
>Christian.
>
>>
>> Signed-off-by: Bernard Zhao
>>
>> Changes since V1:
>> *commit message improve
>>
>> Changes since V2:
>> *move comment along with the mutex_unlock
>>
>> Changes since V3:
>> *lock protect the if check, there is some possibility of multi-threaded
>> racing modify.
>>
>> Link for V1:
>> *https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1226588%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C9f2b2080f4174c421e4f08d7e5c6b899%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230513976133424&sdata=6wezM%2F%2FjM5uuLblJejS9XFlE9DjWQ5zSt5PsqrfvCVo%3D&reserved=0
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 327317c54f7c..549bdb429883 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -1289,9 +1289,9 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
>> mutex_lock(&mem->lock);
>>
>> if (mem->mapped_to_gpu_memory > 0) {
>> +mutex_unlock(&mem->lock);
>> pr_debug("BO VA 0x%llx size 0x%lx is still mapped.\n",
>> mem->va, bo_size);
>> -mutex_unlock(&mem->lock);
>> return -EBUSY;
>> }
>>
>
add Markus.Elfring in mail list
Regards,
Bernard
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: Guru Das Srinagesh Reviewed-by: Daniel Thompson --- drivers/video/backlight/pwm_bl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index 82b8d75..464baad 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -606,7 +606,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->scale = data->max_brightness; } - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, + pb->scale)); props.type = BACKLIGHT_RAW; props.max_brightness = data->max_brightness; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 01/11] drm/i915: Use 64-bit division macro
Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend. To: Jani Nikula Cc: Joonas Lahtinen Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: "Ville Syrjälä" Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Guru Das Srinagesh --- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index 276f438..81547a0 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, return retval; } - level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100, + level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100, CRC_PMIC_PWM_PERIOD_NS); panel->backlight.level = intel_panel_compute_brightness(connector, level); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3] amdgpu:optimization-- reduce no need mutex_lock area
Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226588/
Link for V2:
*https://lore.kernel.org/patchwork/patch/1227907/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 327317c54f7c..f03d9843d723 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1285,21 +1285,21 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct bo_vm_reservation_context ctx;
struct ttm_validate_buffer *bo_list_entry;
int ret;
+ unsigned int mapped_to_gpu_memory;
mutex_lock(&mem->lock);
+ mapped_to_gpu_memory = mem->mapped_to_gpu_memory;
+ mutex_unlock(&mem->lock);
+ /* lock is not needed after this, since mem is unused and will
+* be freed anyway
+*/
- if (mem->mapped_to_gpu_memory > 0) {
+ if (mapped_to_gpu_memory > 0) {
pr_debug("BO VA 0x%llx size 0x%lx is still mapped.\n",
mem->va, bo_size);
- mutex_unlock(&mem->lock);
return -EBUSY;
}
- mutex_unlock(&mem->lock);
- /* lock is not needed after this, since mem is unused and will
-* be freed anyway
-*/
-
/* No more MMU notifiers */
amdgpu_mn_unregister(mem->bo);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/arm: cleanup coding style in arm a bit
For the code logic, an alarm is thrown after failure, but the code continues to run and returns successfully, so to the caller the if check and return branch will never run. The change is to make the code a bit more readable. Signed-off-by: Bernard Zhao --- drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index af67fefed38d..32bda13250f5 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -160,9 +160,7 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc) hdlcd_write(hdlcd, HDLCD_REG_H_SYNC, vm.hsync_len - 1); hdlcd_write(hdlcd, HDLCD_REG_POLARITIES, polarities); - err = hdlcd_set_pxl_fmt(crtc); - if (err) - return; + hdlcd_set_pxl_fmt(crtc); clk_set_rate(hdlcd->clk, m->crtc_clock * 1000); } -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] powerpc: Replace _ALIGN_DOWN() by ALIGN_DOWN()
Hi! On Tue, Apr 21, 2020 at 01:04:05AM +, Joel Stanley wrote: > On Mon, 20 Apr 2020 at 18:38, Christophe Leroy > wrote: > > _ALIGN_DOWN() is specific to powerpc > > ALIGN_DOWN() is generic and does the same > > > > Replace _ALIGN_DOWN() by ALIGN_DOWN() > > This one is a bit less obvious. It becomes (leaving the typeof's alone > for clarity): > > -((addr)&(~((typeof(addr))(size)-1))) > +addr) - ((size) - 1)) + ((typeof(addr))(size) - 1)) & > ~((typeof(addr))(size)-1)) > > Which I assume the compiler will sort out? [ This is line-wrapped, something in your mailer? Took me a bit to figure out the - and + are diff -u things :-) ] In the common case where size is a constant integer power of two, the compiler will have no problem with this. But why do so complicated? Why are the casts there, btw? Segher ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] fs: extract simple_pin/release_fs to separate files
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig index 39eec9031487..a62795079d9c 100644 --- a/drivers/misc/cxl/Kconfig +++ b/drivers/misc/cxl/Kconfig @@ -19,6 +19,7 @@ config CXL select CXL_BASE select CXL_AFU_DRIVER_OPS select CXL_LIB + select SIMPLEFS default m help Select this option to enable driver support for IBM Coherent diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c index b493de962153..0b8f8de7475a 100644 --- a/drivers/misc/cxl/api.c +++ b/drivers/misc/cxl/api.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig index 2d2266c1439e..ddd9245fff3d 100644 --- a/drivers/misc/ocxl/Kconfig +++ b/drivers/misc/ocxl/Kconfig @@ -12,6 +12,7 @@ config OCXL depends on PPC_POWERNV && PCI && EEH select OCXL_BASE select HOTPLUG_PCI_POWERNV + select SIMPLEFS It's not clear to me the Kconfig updated is needed for the ocxl driver. I think it's only needed for the cxl driver. Fred ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Return more error codes in amdgpu_connector_set_property()
> The "if(!encoder)" branch return the same value 0 of the success > branch, maybe return -EINVAL is more better. I suggest to improve the commit message. * Are you still unsure about the next changes? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=ae83d0b416db002fe95601e7f97f64b59514d936#n151 * Would you like to adjust the patch subject another bit? * How do you think about to add the tag “Fixes” because of adjustments for the exception handling? It can be nicer if all patch reviewers (including me) will be explicitly specified as recipients for such messages, can't it? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Hi, On 21.04.20 13:21, Maxime Ripard wrote: Hi, On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote: On 20.04.20 09:38, Maxime Ripard wrote: Hi, On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote: I'm a bit skeptical on that one since it doesn't even list the interrupts connected to the GPU that the binding mandates. I think he left it out for a future update. But best he comments himself. I'm currently working on those bindings. They are now 90% done, but they are not finished till now. Currently there is some mainline support missing to add the full binding. The A83T and also the A31/A31s have a GPU Power Off Gating Register in the R_PRCM module, that is not supported right now in Mainline. The Register need to be written when the GPU is powered on and off. @Maxime: I totally agree on your point that a demo needs to be provided before the related DTS patches should be provided. That's the reason why I added the gpu placeholder patches. Do you have an idea how a driver for the R_PRCM stuff can look like? I'm not that experienced with the clock driver framework. It looks like a power-domain to me, so you'd rather plug that into the genpd framework. I had a look on genpd and I'm not really sure if that fits. It is basically some bit that verify that the clocks should be enabled or disabled. No, it can do much more than that. It's a framework to control the SoCs power domains, so clocks might be a part of it, but most of the time it's going to be about powering up a particular device. So I think I've found now the right piece of documentation and a driver that implements something similar [1]. So I will write a similar driver like linked above that only sets the right bits for A83T and A31/A31s. Do you think this is the right approach? I think this is better placed somewhere in the clocking framework. I see there more similarities to the gating stuff. Do you think it is suitable to implement it like the clock gating? I'm really not sure what makes you think that this should be modelled as a clock? Looks like I looked in the wrong place and got some information that are not suitable for this. The big question is right now how to proceed with the A83T and A31s patches. I see there three options, which one do you prefer?: 1. Provide now placeholder patches and send new patches, if everything is clear and other things are mainlined 2. Provide now patches as complete as possible and provide later patches to complete them when the R_PRCM things are mainlined 3. Leave them out, till the related work is mainlined and the bindings are final. Like I said, the DT *has* to be backward-compatible, so for any DT patch that you are asking to be merged, you should be prepared to support it indefinitely and be able to run from it, and you won't be able to change the bindings later on. I agree on your points. But is this also suitable to drivers that are currently off tree and might be merged in one or two years? This is what we done for the Mali. The devicetree binding was first done for the out-of-tree driver, and then lima/panfrost reused it. The key thing here is to have enough confidence about how the hardware works so that you can accurately describe it. Ok thanks! So I will resend my patches when the work got a more mature state and we know enough about the Hardware. Cheers, Philipp [1]: https://elixir.bootlin.com/linux/latest/source/drivers/soc/amlogic/meson-gx-pwrc-vpu.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
* Maxime Ripard [200421 11:22]: > On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote: > > I had a look on genpd and I'm not really sure if that fits. > > > > It is basically some bit that verify that the clocks should be enabled or > > disabled. > > No, it can do much more than that. It's a framework to control the SoCs power > domains, so clocks might be a part of it, but most of the time it's going to > be > about powering up a particular device. Note that on omaps there are actually SoC module specific registers. And there can be multiple devices within a single target module on omaps. So the extra dts node and device is justified there. For other SoCs, the SGX clocks are probably best handled directly in pvr-drv.c PM runtime functions unless a custom hardware wrapper with SoC specific registers exists. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Fix ref->mutex deadlock in i915_active_wait()
On Tue, Apr 21, 2020 at 09:38:09AM -0700, Sultan Alsawaf wrote: > Why hasn't this bug got any attention: > https://gitlab.freedesktop.org/drm/intel/issues/1412 > > That seems like a showstopper. Indeed, pretty shocking. It's worth mentioning that the reporter of said bug, after significant time had elapsed, removed i915 from the kernel entirely and now daily drives the NVIDIA binary blob. Having to fall back to closed source blobs indicates a pretty awful state of affairs. It might otherwise be hard to imagine how that could be preferable, but this situation indicates how. Joonas - More generally, it seems what's happening now is that i915 driver stability and quality is reaching a real low point. Back when i915 was the only stable driver in town, the ivory tower attitude of the maintainers seemed quasi-justifiable. The drivers kept being awesome, so when they kicked the can back at users or gave them the cold shoulder on reports, there was never much of an issue, since things always got fixed in fairly short order. This is no longer the case. Bugs are piling up. Users are unhappy. So it's only natural that some users will just wind up fixing it themselves, especially with responses from Intel like "not guilty!" in response to i915 bug reports. And these users who try to fix these bugs will do so without access to your proprietary debuggers, top-secret data sheets, and NDA'd hardware engineers down the hall, and thus you'll always be able to accuse them of something or another about "due-diligence", since nobody is better suited than you to find and fix these issues in the best way possible. But it hasn't been happening in a satisfactory way from your end, and users need their laptops to actually work, and so things will gradually get fixed (hopefully, anyhow) through other means. Even on the stable front, if fixes to bugs are intermingled into massive refactoring patches, and your team isn't taking charge to separate them out and send them to stable@, then backporting to stable kernels is going to result in a lot of custom work from other people. In other words, you can shun your users' bug reports and fellow developers and get away with that while your driver quality remains tip-top, but if you let things fall, as they have as of late, then expect your ivory tower to be shaken a bit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] of_device: removed #include that caused a recursion in included headers
> -Original Message- > From: Rob Herring > Sent: Monday, 20 April 2020 23:37 > > On Mon, Apr 13, 2020 at 04:35:53PM +0300, Hadar Gat wrote: > > Both of_platform.h and of_device.h were included each other. > > In of_device.h, removed unneeded #include to of_platform.h and added > > include to of_platform.h in the files that needs it. > > Guess we forgot about that temporary comment! > > Both of these headers have a lot of things we don't want 'normal' > drivers calling. The most common thing needed from of_device.h is > of_match_device/of_device_get_match_data. A good number are only for > ibmebus. Maybe the header should be split or the former just moved to of.h. > > For of_platform.h, it seems we have a bunch of unneeded includes: > > $ git grep 'of_platform\.h' drivers/ | wc > 5601120 36049 > $ git grep -E 'of_(platform_(pop|def)|find_device)' drivers/ | wc > 2481215 20630 > > Would nice to drop those (or switch to of_device.h?) too. > > Be sure to build on Sparc. It's the oddball. Hi Rob and thanks for your inputs. Unfortunately I cannot continue to work on this patch at the moment since it is not as small as I expected and I have limited resources for that. So anyone can take it and continue from here. Thanks, Hadar > > Signed-off-by: Hadar Gat > > --- > > drivers/base/platform.c | 1 + > > drivers/bus/vexpress-config.c | 1 + > > drivers/dma/at_hdmac.c| 1 + > > drivers/dma/stm32-dmamux.c| 1 + > > drivers/dma/ti/dma-crossbar.c | 1 + > > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 + > > drivers/gpu/drm/msm/hdmi/hdmi.c | 1 + > > drivers/gpu/drm/msm/msm_drv.c | 1 + > > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 + > > drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + > > drivers/iio/adc/stm32-adc-core.c | 1 + > > drivers/iio/adc/stm32-dfsdm-adc.c | 1 + > > drivers/iio/adc/stm32-dfsdm-core.c| 1 + > > drivers/iommu/tegra-smmu.c| 1 + > > drivers/memory/atmel-ebi.c| 1 + > > drivers/mfd/palmas.c | 1 + > > drivers/mfd/ssbi.c| 1 + > > drivers/mtd/nand/raw/omap2.c | 1 + > > drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 + > > drivers/net/ethernet/ti/cpsw.c| 1 + > > drivers/phy/tegra/xusb.c | 1 + > > drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 + > > drivers/soc/samsung/exynos-pmu.c | 1 + > > drivers/soc/sunxi/sunxi_sram.c| 1 + > > include/linux/of_device.h | 2 -- > > lib/genalloc.c| 1 + > > 26 files changed, 25 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[add Markus.Elfring in mail list]Re:[PATCH v2] amdgpu: fixes error branch not return errno issue
From: Bernard Zhao Date: 2020-04-21 10:07:50 To: Alex Deucher ,"Christian König" ,"David (ChunMing) Zhou" ,David Airlie ,Daniel Vetter ,Lyude Paul ,Sam Ravnborg ,Bernard Zhao ,"José Roberto de Souza" ,Andrzej Pietrasiewicz ,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org Cc: opensource.ker...@vivo.com Subject: [PATCH v2] amdgpu: fixes error branch not return errno issue>The "if(!encoder)" branch return the same value 0 of the success >branch, maybe return -EINVAL is more better. > >Signed-off-by: Bernard Zhao > >--- >Changes since V1: >* commit message improve >--- > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c >b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c >index f355d9a..1f8c6b4 100644 >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c >@@ -474,12 +474,12 @@ static int amdgpu_connector_set_property(struct >drm_connector *connector, > /* need to find digital encoder on connector */ > encoder = amdgpu_connector_find_encoder(connector, > DRM_MODE_ENCODER_TMDS); > if (!encoder) >- return 0; >+ return -EINVAL; > > amdgpu_encoder = to_amdgpu_encoder(encoder); > > if (!amdgpu_encoder->enc_priv) >- return 0; >+ return -EINVAL; > > dig = amdgpu_encoder->enc_priv; > new_coherent_mode = val ? true : false; >@@ -494,7 +494,7 @@ static int amdgpu_connector_set_property(struct >drm_connector *connector, > /* need to find digital encoder on connector */ > encoder = amdgpu_connector_find_encoder(connector, > DRM_MODE_ENCODER_TMDS); > if (!encoder) >- return 0; >+ return -EINVAL; > > amdgpu_encoder = to_amdgpu_encoder(encoder); > >@@ -509,7 +509,7 @@ static int amdgpu_connector_set_property(struct >drm_connector *connector, > /* need to find digital encoder on connector */ > encoder = amdgpu_connector_find_encoder(connector, > DRM_MODE_ENCODER_TMDS); > if (!encoder) >- return 0; >+ return -EINVAL; > > amdgpu_encoder = to_amdgpu_encoder(encoder); > >@@ -523,7 +523,7 @@ static int amdgpu_connector_set_property(struct >drm_connector *connector, > /* need to find digital encoder on connector */ > encoder = amdgpu_connector_find_encoder(connector, > DRM_MODE_ENCODER_TMDS); > if (!encoder) >- return 0; >+ return -EINVAL; > > amdgpu_encoder = to_amdgpu_encoder(encoder); > >@@ -537,7 +537,7 @@ static int amdgpu_connector_set_property(struct >drm_connector *connector, > /* need to find digital encoder on connector */ > encoder = amdgpu_connector_find_encoder(connector, > DRM_MODE_ENCODER_TMDS); > if (!encoder) >- return 0; >+ return -EINVAL; > > amdgpu_encoder = to_amdgpu_encoder(encoder); > >@@ -551,7 +551,7 @@ static int amdgpu_connector_set_property(struct >drm_connector *connector, > /* need to find digital encoder on connector */ > encoder = amdgpu_connector_find_encoder(connector, > DRM_MODE_ENCODER_TMDS); > if (!encoder) >- return 0; >+ return -EINVAL; > > amdgpu_encoder = to_amdgpu_encoder(encoder); > >-- >2.7.4 > add Markus.Elfring in mail list Regards, Bernard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Hi, On 20.04.20 09:38, Maxime Ripard wrote: Hi, On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote: I'm a bit skeptical on that one since it doesn't even list the interrupts connected to the GPU that the binding mandates. I think he left it out for a future update. But best he comments himself. I'm currently working on those bindings. They are now 90% done, but they are not finished till now. Currently there is some mainline support missing to add the full binding. The A83T and also the A31/A31s have a GPU Power Off Gating Register in the R_PRCM module, that is not supported right now in Mainline. The Register need to be written when the GPU is powered on and off. @Maxime: I totally agree on your point that a demo needs to be provided before the related DTS patches should be provided. That's the reason why I added the gpu placeholder patches. Do you have an idea how a driver for the R_PRCM stuff can look like? I'm not that experienced with the clock driver framework. It looks like a power-domain to me, so you'd rather plug that into the genpd framework. I had a look on genpd and I'm not really sure if that fits. It is basically some bit that verify that the clocks should be enabled or disabled. I think this is better placed somewhere in the clocking framework. I see there more similarities to the gating stuff. Do you think it is suitable to implement it like the clock gating? The big question is right now how to proceed with the A83T and A31s patches. I see there three options, which one do you prefer?: 1. Provide now placeholder patches and send new patches, if everything is clear and other things are mainlined 2. Provide now patches as complete as possible and provide later patches to complete them when the R_PRCM things are mainlined 3. Leave them out, till the related work is mainlined and the bindings are final. Like I said, the DT *has* to be backward-compatible, so for any DT patch that you are asking to be merged, you should be prepared to support it indefinitely and be able to run from it, and you won't be able to change the bindings later on. I agree on your points. But is this also suitable to drivers that are currently off tree and might be merged in one or two years? Since this GPU IP core is very flexible and the SOC manufactures can configure it on their needs, I think the binding will extend in the future. For example the SGX544 GPU is available in different configurations: there is a SGX544 core and SGX544MPx core. The x stands for the count of the USSE (Universal Scalable Shader Engine) cores. For example the GPU in the A83T is a MP1 and the A31/A31s a MP2. Mali is in the same situation and it didn't cause much trouble. Good to know. In addition to that some of the GPU's have also a 2D engine. In the same memory region, running from the same interrupts, or is it a completely separate IP that happens to be sold by the same vendor? What I know till now this is part of the PowerVR IP and not separated. So it should use the same memory region, clocks and interrupts. Cheers Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:Re: [PATCH V3] amdgpu: remove unnecessary condition check
From: "Christian König"
Date: 2020-04-21 16:06:03
To: 1587180037-113840-1-git-send-email-bern...@vivo.com,Felix Kuehling
,Alex Deucher ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com,Bernard Zhao
Subject: Re: [PATCH V3] amdgpu: remove unnecessary condition check>Am 21.04.20
um 10:03 schrieb Bernard Zhao:
>> There is no need to if check again, maybe we could merge
>> into the above else branch.
>>
>> Signed-off-by: Bernard Zhao
>>
>> Changes since V1:
>> *commit message improve
>> *code style refactoring
>>
>> Changes since V2:
>> *code style adjust
>>
>> Link for V1:
>> *https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1226587%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C0b8fffafb715474289b208d7e5ca7f6c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230530201280350&sdata=Sewv5ESX%2B0B4DbFbE03uM5sifrEcmJllC8pt7J42I7M%3D&reserved=0
>> ---
>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 18 +++---
>> 1 file changed, 7 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 9dff792c9290..5424bd921a7b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -660,13 +660,12 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
>>
>> ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
>> false, &ctx->duplicates);
>> -if (!ret)
>> -ctx->reserved = true;
>> -else {
>> -pr_err("Failed to reserve buffers in ttm\n");
>> +if (ret) {
>> +pr_err("Failed to reserve buffers in ttm.\n");
>> kfree(ctx->vm_pd);
>> ctx->vm_pd = NULL;
>> -}
>> +} else
>> +ctx->reserved = true;
>
>That is still not correct coding style. In general when one branch of an
>if/else uses {} the other one should use it as well.
>
>But I agree with Felix that this change looks rather superfluous to me
>as well.
>
>Regards,
>Christian.
About the code style, you are right, I checked the refers:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=90280eaa88ac1a9140dc759941123530d5545bb6#n191
The if and else should use the same style.
But i have to say there are so many code not follow the kernel code-style in
amdgpu module.
And also the ./scripts/checkpatch.pl did not throw any warning or error.
If this change looks rather superfluous to all of you, should i change to the
V1 change?
After all i don`t think there is any necessary to check "ret" again, merge the
maybe better.
Original code:
static int reserve_bo_and_cond_vms(struct kgd_mem *mem,.
if (!ret)
ctx->reserved = true;
else
pr_err("Failed to reserve buffers in ttm.\n");
if (ret) {
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
}
BR//bernard
>>
>> return ret;
>> }
>> @@ -733,15 +732,12 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
>>
>> ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
>> false, &ctx->duplicates);
>> -if (!ret)
>> -ctx->reserved = true;
>> -else
>> -pr_err("Failed to reserve buffers in ttm.\n");
>> -
>> if (ret) {
>> +pr_err("Failed to reserve buffers in ttm.\n");
>> kfree(ctx->vm_pd);
>> ctx->vm_pd = NULL;
>> -}
>> +} else
>> +ctx->reserved = true;
>>
>> return ret;
>> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Fix ref->mutex deadlock in i915_active_wait()
On Tue, Apr 21, 2020 at 11:04:13AM +0300, Joonas Lahtinen wrote: > Quoting Sultan Alsawaf (2020-04-20 18:42:16) > > On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote: > > > I think the the patch should be dropped for now before the issue is > > > properly addressed. Either by backporting the mainline fixes or if > > > those are too big and there indeed is a smaller alternative patch > > > that is properly reviewed. But the above patch is not, at least yet. > > > > Why should a fix for a bona-fide issue be dropped due to political reasons? > > This > > doesn't make sense to me. This just hurts miserable i915 users even more. > > If my > > patch is going to be dropped, it should be replaced by a different fix at > > the > > same time. > > There's no politics involved. It's all about doing the due diligence > that we're fixing upstream bugs, and we're fixing them in a way that > does not cause regressions to other users. Due diligence is the furthest thing from what I'd associate with i915. My cherryview laptop doesn't work anymore in 5.6 (it gets many GPU hangs; a RedHat engineer is working on fixing it according to the gitlab issue), my colleagues' laptops with 4k screens still suffer from GPU hangs (with fully documented gitlab reports that have gone completely unanswered), and I still get occasional FIFO underrun messages in dmesg accompanying graphical glitches on my own laptops. On top of that, PSR doesn't work correctly on any of my laptops, and it's enabled by default in i915. But when I reported the issue on gitlab, I got claims that my laptops' panels were bad, and that my reports were "not enough reason to disable PSR by default." [1] [1] https://gitlab.freedesktop.org/drm/intel/-/issues/425#note_434182 > Without being able to reproduce a bug against vanilla kernel, there's > too high of a risk that the patch that was developed will only work > on the downstream kernel it was developed for. That happens for the > best of the developers, and that is exactly why the process is in > place, to avoid human error. So no politics, just due diligence. You could have reviewed the patch in the same amount of time it took you to write this email. It's very simple and obvious. That's why this sounds more like politics to me than "due diligence." > > Also, the mainline fixes just *happen* to fix this deadlock by removing the > > mutex lock from the path in question and creating multiple other bugs in the > > process that had to be addressed with "Fixes:" commits. The regression > > potential > > was too high to include those patches for a "stable" kernel, so I made this > > patch which fixes the issue in the simplest way possible. > > The thing is that it may be that the patch fixes the exact issue you > have at hand in the downstream kernel you are testing against. But > in doing so it may as well break other usecases for other users of > vanilla kernel. That is what we're trying to avoid. I don't know of any usecase that needs a double mutex lock (except for drm code that uses mutex_trylock_recursive of course), but alright. > A patch that claims to fix a deadlock in upstream kernel should > include that splat from upstream kernel, not a speculated chain. > Again, this is just the regular due diligence, because we have > made errors in the past. It is for those self-made errors we > know not to merge fixes too quickly before we are able to > reproduce the error and make sure it is gone. I sent the splat in a previous email. And you lot are all making many errors in the present, far more so than in the past because i915 used to work at some point. The sheer number of Chris' commits with subsequent "Fixes:" for his changes is mind numbing. For Ubuntu, we've had to backport a massive amount of i915 fixes to our 5.4 kernel thus far, and the major bugs still aren't all fixed (probably since those bugs still exist in Linus' tree). And we can't backport all of the relevant fixes we find because they're either contained in massive refactor commits or they only apply to i915 code that's been massively refactored since the last kernel release. > > We put this patch into > > Ubuntu now as well, because praying for a response from i915 maintainers > > while > > the 20.04 release was on the horizon was not an option. > > > > > There is an another similar thread where there's jumping into > > > conclusions and doing ad-hoc patches for already fixed issues: > > > > > > https://lore.kernel.org/dri-devel/20200414144309.GB2082@sultan-box.localdomain/ > > > > Maybe this wouldn't have happened if I had received a proper response for > > that > > issue on gitlab from the get-go... Instead I got the run-around from Chris > > claiming that it wasn't an i915 bug: > > > > https://gitlab.freedesktop.org/drm/intel/issues/1599 > > > > > I appreciate enthusiasm to provide fixes to i915 but we should > > > continue do the regular due diligence to make sure we're properly > > > fixing bugs in upstream k
[Bug 205291] Cannot switch off Radeon HD 4330/4350/4550 with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=205291 Lukas Wunner (lu...@wunner.de) changed: What|Removed |Added CC||lu...@wunner.de --- Comment #8 from Lukas Wunner (lu...@wunner.de) --- Starting with v4.17, the power management of HDA controllers on discrete GPUs was changed such that the HDA keeps the GPU awake as long as it's in use: https://lists.freedesktop.org/archives/nouveau/2018-February/029851.html This exposed an issue with some ATI cards which was fixed in June 2018: https://git.kernel.org/linus/57cb54e53bdd So if you still experience GPU insomnia with v5.3 (which contains that fix), then it's a different problem. In one case, a user reported GPU insomnia with an Nvidia card and it turned out that it was caused by a user space tool called "tlp" which disabled runtime power management of the HDA via sysfs. Naturally, this caused the GPU to stay awake. The solution in this case was to change the configuration of "tlp". But it was also possible to manually override disablement of runtime PM on the HDA by echoing "on" to the "power/control" file in the HDA PCI device's sysfs directory: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c116 So you first may want to check whether runtime PM is disabled in sysfs, try to manually enable it and see if the GPU runtime suspends, and if that works, find out which user space tool disabled runtime PM on the HDA. It's also possible that you've got a user space tool running which has opened the HDA and thereby keeps the GPU awake. Some audio mixers do that. If none of that fixes the problem, then we may indeed be dealing with a kernel bug. The other bugs related to runtime PM of the HDA contain all the steps and several debug patches to understand what's keeping the HDA awake, so we need you to follow those instructions and report the results back. Here are the relevant bugzillas: https://bugs.freedesktop.org/show_bug.cgi?id=106597#c4 https://bugs.freedesktop.org/show_bug.cgi?id=106957#c1 One oddity I notice in your dmesg output is that there's only a single HDA controller detected in your machine and that's the one on the discrete GPU. Normally there are two HDAs, one is part of the Intel chipset and is responsible for headphones, loudspeakers, mic and so on, and the other one is on the discrete GPU and is only responsible for HDMI audio. On your machine, there's no Intel chipset HDA and the one on the discrete GPU has a Line Out for loudspeakers, headphone out, digital out and two microphone inputs. So that's a little odd and may contribute to this issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/12] arm: dts: s5pv210: Add G3D node
Hi Nikolaus, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on sunxi/sunxi/for-next v5.7-rc2 next-20200421] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/H-Nikolaus-Schaller/ARM-MIPS-DTS-add-child-nodes-describing-the-PVRSGX-GPU-present-in-some-OMAP-SoC-and-JZ4780-and-many-more/20200416-022658 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> Error: arch/arm/boot/dts/s5pv210.dtsi:523.25-26 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/10] drm/lima: add suspend/resume support
On Tue, Apr 21, 2020 at 6:37 AM Qiang Yu wrote: > > Suspend need to wait running jobs finish and put hardware in > poweroff state. Resume need to re-init hardware. > > v2: > 1. add misc patches to prepare enable runtime pm > 2. fix pmu command wait time out on mali400 gpu > 3. do power and clock gating when suspend > 4. do runtime pm > > Qiang Yu (10): > drm/lima: use module_platform_driver helper > drm/lima: print process name and pid when task error > drm/lima: check vm != NULL in lima_vm_put > drm/lima: always set page directory when switch vm > drm/lima: add lima_devfreq_resume/suspend > drm/lima: power down ip blocks when pmu exit > drm/lima: add resume/suspend callback for each ip > drm/lima: seperate clk/regulator enable/disable function s/seperate/separate I guess you can fix it before merging into drm-misc-next, no need to respin whole patchset > drm/lima: add pm resume/suspend ops > drm/lima: enable runtime pm Besides that, series is: Reviewed-by: Vasily Khoruzhick > drivers/gpu/drm/lima/lima_bcast.c| 25 +++- > drivers/gpu/drm/lima/lima_bcast.h| 2 + > drivers/gpu/drm/lima/lima_devfreq.c | 24 > drivers/gpu/drm/lima/lima_devfreq.h | 3 + > drivers/gpu/drm/lima/lima_device.c | 199 ++- > drivers/gpu/drm/lima/lima_device.h | 5 + > drivers/gpu/drm/lima/lima_dlbu.c | 17 ++- > drivers/gpu/drm/lima/lima_dlbu.h | 2 + > drivers/gpu/drm/lima/lima_drv.c | 40 +++--- > drivers/gpu/drm/lima/lima_gp.c | 21 ++- > drivers/gpu/drm/lima/lima_gp.h | 2 + > drivers/gpu/drm/lima/lima_l2_cache.c | 37 +++-- > drivers/gpu/drm/lima/lima_l2_cache.h | 2 + > drivers/gpu/drm/lima/lima_mmu.c | 48 +-- > drivers/gpu/drm/lima/lima_mmu.h | 2 + > drivers/gpu/drm/lima/lima_pmu.c | 77 ++- > drivers/gpu/drm/lima/lima_pmu.h | 2 + > drivers/gpu/drm/lima/lima_pp.c | 31 - > drivers/gpu/drm/lima/lima_pp.h | 4 + > drivers/gpu/drm/lima/lima_sched.c| 63 ++--- > drivers/gpu/drm/lima/lima_vm.h | 3 +- > 21 files changed, 496 insertions(+), 113 deletions(-) > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/exynos: gem: Rework scatter-list contiguity check on Prime import
20. 4. 22. 오후 12:37에 Inki Dae 이(가) 쓴 글:
> Hi Marek,
>
> 20. 4. 21. 오후 5:09에 Marek Szyprowski 이(가) 쓴 글:
>> Hi Inki,
>>
>> On 21.04.2020 09:38, Inki Dae wrote:
>>> 20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
Explicitly check if the imported buffer has been mapped as contiguous in
the DMA address space, what is required by all Exynos DRM CRTC drivers.
While touching this, set buffer flags depending on the availability of
the IOMMU.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 36 +
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 40514d3dcf60..9d4e4d321bda 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -458,6 +458,23 @@ exynos_drm_gem_prime_import_sg_table(struct
drm_device *dev,
int npages;
int ret;
>>> (Optional) could you leave one comment here?
>>> i.e., /* Check if DMA memory region from a exporter are mapped contiguously
>>> or not. */
>>
>> Okay.
>>
+ if (sgt->nents != 1) {
>>> How about using below condition instead?
>>> if (sgt->nents > 0) {
>>
>> This is not the same. My check for != 1 is intended. Checking contiguity
>> of the scatterlist if it has only 1 element doesn't have much sense.
>
> Oops sorry. My intention was 'if (sgt->nents > 1)' because if (sgt->nents !=
> 1) allows
> - sgt->nents < 1
> - sgt->nents > 1
>
> I think the checking would be valid only in case of having multiple entries -
> sgt->nents > 1.
>
> Thanks,
> Inki Dae
>
>>
+ dma_addr_t next_addr = sg_dma_address(sgt->sgl);
+ struct scatterlist *s;
+ unsigned int i;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ if (!sg_dma_len(s))
+ continue;
>>> Isn't it an error case if sg_dma_len(s) is 0? I think length of s is 0 then
>>> it would be invalid because all entries of sgt should be mapped before
>>> sg_dma_len() is called.
>>
>> Well, it is a grey area. Some code incorrectly sets nents as orig_nents,
>> thus this version is simply safe for both approaches. sg entries unused
>> for DMA chunks have sg_dma_len() == 0.
>>
>> The above check is more or less copied from
>> drm_gem_cma_prime_import_sg_table() (drivers/gpu/drm/drm_gem_cma_helper.c).
I looked into above original code but it seems that it allows sgt->nents to
have negative value, 'sgt->nents < 1', which could incur some bugs.
So I think the original code can be fixed like below,
if (sgt->nents > 1) { // <- here
/* check if the entries in the sg_table are contiguous */
dma_addr_t next_addr = sg_dma_address(sgt->sgl);
struct scatterlist *s;
unsigned int i;
for_each_sg(sgt->sgl, s, sgt->nents, i) {
/*
* sg_dma_address(s) is only valid for entries
* that have sg_dma_len(s) > 0 // <- here
*/
if (!sg_dma_len(s))
continue;
if (sg_dma_address(s) != next_addr)
return ERR_PTR(-EINVAL);
next_addr = sg_dma_address(s) + sg_dma_len(s);
}
}
So if you agree with me then we don't have to copy and paste this code as-is.
Regarding 'if (!sg_dma_len(s))' condition here, I'm not clear whether we are
using it correctly because scatterlist.h header description says,
/*
* These macros should be used after a dma_map_sg call has been done
* to get bus addresses of each of the SG entries and their lengths.
* You should only work with the number of sg entries dma_map_sg
* returns, or alternatively stop on the first sg_dma_len(sg) which
* is 0.
*/
According to above description, sg_dma_len() should be called after
dma_map_sg() call. Even it says to stop on the first sg_dma_len(sg) which is 0.
And we could avoid the checking function code from being duplicated by
introducing one function which checks if the entries in the sg_table are
contiguous or not as a separate patch later.
Thanks,
Inki Dae
>>
>> Best regards
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Delete an error message in three functions
Hi Markus Elfring,
20. 4. 5. 오후 9:18에 Markus Elfring 이(가) 쓴 글:
> From: Markus Elfring
> Date: Sun, 5 Apr 2020 14:10:09 +0200
>
> The function “platform_get_irq” can log an error already.
> Thus omit redundant messages for the exception handling in the
> calling functions.
>
> This issue was detected by using the Coccinelle software.
Picked it up.
Thanks,
Inki Dae.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +---
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +---
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 4 +---
> 3 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index e080aa92338c..a00c6dd16c8a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1813,10 +1813,8 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> }
>
> dsi->irq = platform_get_irq(pdev, 0);
> - if (dsi->irq < 0) {
> - dev_err(dev, "failed to request dsi irq resource\n");
> + if (dsi->irq < 0)
> return dsi->irq;
> - }
>
> irq_set_status_flags(dsi->irq, IRQ_NOAUTOEN);
> ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index dafa87b82052..2d94afba031e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -293,10 +293,8 @@ static int rotator_probe(struct platform_device *pdev)
> return PTR_ERR(rot->regs);
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (irq < 0)
> return irq;
> - }
>
> ret = devm_request_irq(dev, irq, rotator_irq_handler, 0, dev_name(dev),
> rot);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> index 93c43c8d914e..ce1857138f89 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> @@ -502,10 +502,8 @@ static int scaler_probe(struct platform_device *pdev)
> return PTR_ERR(scaler->regs);
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (irq < 0)
> return irq;
> - }
>
> ret = devm_request_threaded_irq(dev, irq, NULL, scaler_irq_handler,
> IRQF_ONESHOT, "drm_scaler", scaler);
> --
> 2.26.0
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/exynos: gem: Rework scatter-list contiguity check on Prime import
Hi Marek,
20. 4. 21. 오후 5:09에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
>
> On 21.04.2020 09:38, Inki Dae wrote:
>> 20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
>>> Explicitly check if the imported buffer has been mapped as contiguous in
>>> the DMA address space, what is required by all Exynos DRM CRTC drivers.
>>> While touching this, set buffer flags depending on the availability of
>>> the IOMMU.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 36 +
>>> 1 file changed, 25 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index 40514d3dcf60..9d4e4d321bda 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -458,6 +458,23 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
>>> *dev,
>>> int npages;
>>> int ret;
>>>
>> (Optional) could you leave one comment here?
>> i.e., /* Check if DMA memory region from a exporter are mapped contiguously
>> or not. */
>
> Okay.
>
>>> + if (sgt->nents != 1) {
>> How about using below condition instead?
>> if (sgt->nents > 0) {
>
> This is not the same. My check for != 1 is intended. Checking contiguity
> of the scatterlist if it has only 1 element doesn't have much sense.
Oops sorry. My intention was 'if (sgt->nents > 1)' because if (sgt->nents != 1)
allows
- sgt->nents < 1
- sgt->nents > 1
I think the checking would be valid only in case of having multiple entries -
sgt->nents > 1.
Thanks,
Inki Dae
>
>>> + dma_addr_t next_addr = sg_dma_address(sgt->sgl);
>>> + struct scatterlist *s;
>>> + unsigned int i;
>>> +
>>> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
>>> + if (!sg_dma_len(s))
>>> + continue;
>> Isn't it an error case if sg_dma_len(s) is 0? I think length of s is 0 then
>> it would be invalid because all entries of sgt should be mapped before
>> sg_dma_len() is called.
>
> Well, it is a grey area. Some code incorrectly sets nents as orig_nents,
> thus this version is simply safe for both approaches. sg entries unused
> for DMA chunks have sg_dma_len() == 0.
>
> The above check is more or less copied from
> drm_gem_cma_prime_import_sg_table() (drivers/gpu/drm/drm_gem_cma_helper.c).
>
> Best regards
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/amdgpu: cleanup coding style in amdkfd a bit
On 2020-04-21 21:46, Bernard Zhao wrote:
Make the code a bit more readable by using a common
error handling pattern.
With that done the patch is Reviewed-by: Christian König
.
Signed-off-by: Bernard Zhao
Thanks. The patch is
Reviewed-by: Felix Kuehling
I removed the history from the commit message, made Christian's
Reviewed-by official and applied the patch.
Regards,
Felix
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the best way to merge unnecessary if/else check branch
Changes since V4:
*Improve the subject line and commit message
Link for V1:
*https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1226587%2F&data=02%7C01%7CFelix.Kuehling%40amd.com%7C27509aa0455042beedc708d7e65efc22%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637231167951862118&sdata=JPCxsDycw0JvZfym1akV7d%2B4oPzvzQ04Zl1rv3WN%2Fj0%3D&reserved=0
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 20 +--
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..acb612c53b9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -660,15 +660,15 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else {
- pr_err("Failed to reserve buffers in ttm\n");
+ if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
+ return ret;
}
- return ret;
+ ctx->reserved = true;
+ return 0;
}
/**
@@ -733,17 +733,15 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
false, &ctx->duplicates);
- if (!ret)
- ctx->reserved = true;
- else
- pr_err("Failed to reserve buffers in ttm.\n");
-
if (ret) {
+ pr_err("Failed to reserve buffers in ttm.\n");
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
+ return ret;
}
- return ret;
+ ctx->reserved = true;
+ return 0;
}
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3] amdgpu:optimization-- reduce no need mutex_lock area
Thanks again for the patch. I'm going to apply this with some minor
fixes. The headline should start with "drm/amdgpu:". I'll also change
the wording of the headline and commit message:
drm/amdgpu: shrink critical section in
amdgpu_amdkfd_gpuvm_free_memory_of_gpu
Reduce the mem->lock`s protected code area, no need to protect pr_debug.
This also simplifies error handling.
There is one more cosmetic change I'm going to make, see inline. I'll
apply your patch with those updates if you're OK with that.
On 2020-04-21 2:48, Bernard Zhao wrote:
Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Link for V1:
*https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1226588%2F&data=02%7C01%7CFelix.Kuehling%40amd.com%7Cc715f5d02aae40846b8f08d7e5c001fd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230485152789682&sdata=4UdZiWMAbW8eR1BS2%2F6qMvs5K6cHWy5c8I32ReQ4uz0%3D&reserved=0
Link for V2:
*https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1227907%2F&data=02%7C01%7CFelix.Kuehling%40amd.com%7Cc715f5d02aae40846b8f08d7e5c001fd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230485152799673&sdata=Wt%2Bk7k4MtSX4zIDgmLEOB6ZKzfuqAd6GJZ3Creqf1aY%3D&reserved=0
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 327317c54f7c..f03d9843d723 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1285,21 +1285,21 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct bo_vm_reservation_context ctx;
struct ttm_validate_buffer *bo_list_entry;
int ret;
+ unsigned int mapped_to_gpu_memory;
I'll move this before the "int ret;" line. It makes the code more
readable if long declarations come before short ones.
Regards,
Felix
mutex_lock(&mem->lock);
+ mapped_to_gpu_memory = mem->mapped_to_gpu_memory;
+ mutex_unlock(&mem->lock);
+ /* lock is not needed after this, since mem is unused and will
+* be freed anyway
+*/
- if (mem->mapped_to_gpu_memory > 0) {
+ if (mapped_to_gpu_memory > 0) {
pr_debug("BO VA 0x%llx size 0x%lx is still mapped.\n",
mem->va, bo_size);
- mutex_unlock(&mem->lock);
return -EBUSY;
}
- mutex_unlock(&mem->lock);
- /* lock is not needed after this, since mem is unused and will
-* be freed anyway
-*/
-
/* No more MMU notifiers */
amdgpu_mn_unregister(mem->bo);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Don't reserve minors for control nodes
On Tue, Apr 21, 2020 at 4:34 PM Michał Winiarski wrote:
>
> Quoting Daniel Vetter (2020-04-21 15:13:34)
> > On Tue, Apr 21, 2020 at 2:50 PM Michał Winiarski wrote:
> > >
> > > From: Michał Winiarski
> > >
> > > Control nodes are no longer with us.
> > > While we still need to preserve render nodes numbering, there's no need
> > > to reserve the range formerly used for control. Let's repurpose it to be
> > > used by primary and remove control remains from the code entirely.
> > >
> > > References: 0d49f303e8a7 ("drm: remove all control node code")
> > > References: c9ac371d4b59 ("drm: Fix render node numbering regression from
> > > control node removal.")
> > > Signed-off-by: Michał Winiarski
> > > Cc: Daniel Vetter
> > > Cc: Eric Anholt
> > > Cc: Marcin Bernatowicz
> > > Cc: Sean Paul
> >
> > So someone plugged in 256k gpus in a single machine and we've run out
> > of minors? Or why do we need this?
> >
> > (There's 20 bits allocated to the minor, and we pre-reserve 2 bits for
> > the different flavours, which this patch reduces to 1 bit).
>
> 64 primary nodes is the limit right now. We're probably going to have to
> tackle
> the 256k GPUs usecase in the future, but perhaps not today :)
>
> > I'm asking since we might have some userspace somewhere which
> > hardcodes this and gets surprised. And I kinda don't want to audit the
> > world ... So I'm wondering what the motivation here is.
> > -Daniel
>
> You mean hardcodes the range (n in the snippet below)?
> Even if userspace would do the simplest approach of looking for drm device, so
> something like (which btw is why c9ac371d4b59 was introduced):
>
> n = 64;
> /* primary */
> for (i = 0; i < n; i++) {
> sprintf(foo, "/dev/dri/card%d", i);
> fd = open(foo);
> /* check whether this is the device we're looking for */
> }
>
> /* render */
> for (i = 128; i < n; i++) {
> sprintf(foo, "/dev/dri/renderD%d", i);
> fd = open(foo);
> /* check whether this is the device we're looking for */
> }
>
> We're changing "n" to 128 on DRM side - worst case is userspace won't find its
> device, but it wouldn't find it on older kernels anyway.
I was more worried about userspace computing render node minor as a
fixed offset of the primary node minor number. Iirc we have code like
that all over. But reading your patch again, looks all ok, you're
adjusting offests to match again.
Wrt supporting more than 64 devices. Once you've exhausted those we'll
continue allocating more at 256 minor for the next primary, or at
least that's how I thought this code works. There's 2^^20 minors
available for the drm device. If you have userspace somewhere that
goes boom already after 64 devices then it'll just go boom after 128
too. Not really sustainable, imo better to fix your userspace that
somehow assumes minors are continuous. And unfortunately (because of
that hard-coded offset between render and primary nodes) we cannot fix
this in the kernel for real for anything remotely resembling
reasonable use-cases. And yes with servers and virtual devices and a
bunch of test device drivers I think 128 drm drivers isn't any less
unrealistic than just 64.
-Daniel
>
> -Michał
>
> >
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++--
> > > include/drm/drm_file.h| 1 -
> > > 2 files changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index c15c9b4540e1..366a760bbc29 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -124,8 +124,8 @@ static int drm_minor_alloc(struct drm_device *dev,
> > > unsigned int type)
> > > spin_lock_irqsave(&drm_minor_lock, flags);
> > > r = idr_alloc(&drm_minors_idr,
> > > NULL,
> > > - 64 * type,
> > > - 64 * (type + 1),
> > > + 128 * type,
> > > + 128 * (type + 1),
> > > GFP_NOWAIT);
> > > spin_unlock_irqrestore(&drm_minor_lock, flags);
> > > idr_preload_end();
> > > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> > > index 716990bace10..45e6dae69293 100644
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > > @@ -54,7 +54,6 @@ struct file;
> > > */
> > > enum drm_minor_type {
> > > DRM_MINOR_PRIMARY,
> > > - DRM_MINOR_CONTROL,
> > > DRM_MINOR_RENDER,
> > > };
> > >
> > > --
> > > 2.26.0
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/lima: Clean up IRQ warnings
Looks good for me, patch 1&2 are:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Wed, Apr 22, 2020 at 6:51 AM Robin Murphy wrote:
>
> Use the optional form of platform_get_irq() for blocks that legitimately
> may not be present, to avoid getting an annoying barrage of spurious
> warnings for non-existent PPs on configurations like Mali-450 MP2.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/gpu/drm/lima/lima_device.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_device.c
> b/drivers/gpu/drm/lima/lima_device.c
> index 247f51fd40a2..c334d297796a 100644
> --- a/drivers/gpu/drm/lima/lima_device.c
> +++ b/drivers/gpu/drm/lima/lima_device.c
> @@ -171,8 +171,10 @@ static void lima_regulator_fini(struct lima_device *dev)
>
> static int lima_init_ip(struct lima_device *dev, int index)
> {
> + struct platform_device *pdev = to_platform_device(dev->dev);
> struct lima_ip_desc *desc = lima_ip_desc + index;
> struct lima_ip *ip = dev->ip + index;
> + const char *irq_name = desc->irq_name;
> int offset = desc->offset[dev->id];
> bool must = desc->must_have[dev->id];
> int err;
> @@ -183,8 +185,9 @@ static int lima_init_ip(struct lima_device *dev, int
> index)
> ip->dev = dev;
> ip->id = index;
> ip->iomem = dev->iomem + offset;
> - if (desc->irq_name) {
> - err = platform_get_irq_byname(dev->pdev, desc->irq_name);
> + if (irq_name) {
> + err = must ? platform_get_irq_byname(pdev, irq_name) :
> +platform_get_irq_byname_optional(pdev, irq_name);
> if (err < 0)
> goto out;
> ip->irq = err;
> --
> 2.23.0.dirty
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: imx: Unify encoder creation
Hi Adrian,
Thank you for the patch.
On Mon, Apr 20, 2020 at 01:02:22PM +0300, Adrian Ratiu wrote:
> imx drivers don't require drm encoders and they all had empty/no-op
> implementations which got converted to simple objects to pacify the
> drm core which still requires something to be defined.
>
> The problem now is that each driver duplicates the same encoder
> initialization logic and I'm working on adding yet-another driver
> (for imx6 mipi-dsi), so instead of copy-pasting the initialization
> let's move it from the drivers to a shared function in imx-drm-core.
This is one step in the right direction, but only a first small step:
what really needs to be done is to move the calls to
imx_drm_create_encoder() into the i.MX display controller driver core.
This requires turning the ldb, tve and hdmi encoders into drm_bridges.
Parallel display is already architectured in the right way, you can have
a look at it to see how to proceed. I recommend addressing ldb and tve
first, what you need to remove from them through conversion to
drm_bridge is the drm_encoder_helper_funcs.
> The imx_drm_encoder_parse_of() logic is made part of the newly added
> imx_drm_create_encoder() which was its only caller after the move to
> imx-drm-core.
>
> Suggested-by: Laurent Pinchart
> Suggested-by: Enric Balletbo Serra
> Signed-off-by: Adrian Ratiu
> ---
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 18 ++
> drivers/gpu/drm/imx/imx-drm-core.c | 13 ++---
> drivers/gpu/drm/imx/imx-drm.h | 2 +-
> drivers/gpu/drm/imx/imx-ldb.c | 8
> drivers/gpu/drm/imx/imx-tve.c | 8
> drivers/gpu/drm/imx/parallel-display.c | 11 +--
> 6 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> index ba4ca17fd4d8..a710e3d576b4 100644
> --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> @@ -18,7 +18,6 @@
> #include
> #include
> #include
> -#include
>
> #include "imx-drm.h"
>
> @@ -218,22 +217,17 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
> device *master,
> hdmi->dev = &pdev->dev;
> encoder = &hdmi->encoder;
>
> - encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
> - /*
> - * If we failed to find the CRTC(s) which this encoder is
> - * supposed to be connected to, it's because the CRTC has
> - * not been registered yet. Defer probing, and hope that
> - * the required CRTC is added later.
> - */
> - if (encoder->possible_crtcs == 0)
> - return -EPROBE_DEFER;
> -
> ret = dw_hdmi_imx_parse_dt(hdmi);
> if (ret < 0)
> return ret;
>
> + ret = imx_drm_create_encoder(drm, encoder, dev->of_node);
> + if (ret) {
> + dev_err(dev, "Failed to create drm encoder\n");
> + return ret;
> + }
> +
> drm_encoder_helper_add(encoder, &dw_hdmi_imx_encoder_helper_funcs);
> - drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
>
> platform_set_drvdata(pdev, hdmi);
>
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 2e38f1a5cf8d..eaf087ed354f 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "imx-drm.h"
> @@ -116,11 +117,11 @@ static const struct drm_mode_config_helper_funcs
> imx_drm_mode_config_helpers = {
> .atomic_commit_tail = imx_drm_atomic_commit_tail,
> };
>
> -
> -int imx_drm_encoder_parse_of(struct drm_device *drm,
> +int imx_drm_create_encoder(struct drm_device *drm,
> struct drm_encoder *encoder, struct device_node *np)
> {
> uint32_t crtc_mask = drm_of_find_possible_crtcs(drm, np);
> + int ret;
>
> /*
>* If we failed to find the CRTC(s) which this encoder is
> @@ -136,9 +137,15 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
> /* FIXME: cloning support not clear, disable it all for now */
> encoder->possible_clones = 0;
>
> + ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_NONE);
> + if (ret) {
> + DRM_ERROR("Failed to initialize simple drm encoder\n");
> + return ret;
> + }
> +
> return 0;
> }
> -EXPORT_SYMBOL_GPL(imx_drm_encoder_parse_of);
> +EXPORT_SYMBOL_GPL(imx_drm_create_encoder);
>
> static const struct drm_ioctl_desc imx_drm_ioctls[] = {
> /* none so far */
> diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
> index c3e1a3f14d30..8573a668a5f5 100644
> --- a/drivers/gpu/drm/imx/imx-drm.h
> +++ b/drivers/gpu/drm/imx/imx-drm.h
> @@ -34,7 +34,7 @@ void imx_drm_mode_config_init(struct drm_device *drm);
>
> struct drm_gem_cma_object *imx_drm_fb_get_obj(struct drm_framebuffer *fb);
>
> -int imx_drm_encoder
Re: [PATCH v2] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
Hi Adrian, Thank you for the patch. On Tue, Apr 21, 2020 at 01:58:14PM +0300, Adrian Ratiu wrote: > This converts the Synopsis MIPI DSI binding documentation to yaml and > should be quite straightforward. I've added a missing ref clk and also > added Philippe as maintainer b/c he's the original txt author following > the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org. > > Cc: Rob Herring > Cc: Philippe CORNU > Cc: devicet...@vger.kernel.org > Suggested-by: Laurent Pinchart > Signed-off-by: Adrian Ratiu > --- > Changes in v2: > - Removed unnecessary descriptions and maxItems (Rob) > - Changed maintainers entry / dropped Mark (Rob) > - Added dsi-controller.yaml ref (Rob) > --- > .../bindings/display/bridge/dw_mipi_dsi.txt | 32 --- > .../display/bridge/snps,dw-mipi-dsi.yaml | 56 +++ > 2 files changed, 56 insertions(+), 32 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > create mode 100644 > Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > deleted file mode 100644 > index b13adf30b8d3b..0 > --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > +++ /dev/null > @@ -1,32 +0,0 @@ > -Synopsys DesignWare MIPI DSI host controller > - > - > -This document defines device tree properties for the Synopsys DesignWare MIPI > -DSI host controller. It doesn't constitue a device tree binding specification > -by itself but is meant to be referenced by platform-specific device tree > -bindings. > - > -When referenced from platform device tree bindings the properties defined in > -this document are defined as follows. The platform device tree bindings are > -responsible for defining whether each optional property is used or not. > - > -- reg: Memory mapped base address and length of the DesignWare MIPI DSI > - host controller registers. (mandatory) > - > -- clocks: References to all the clocks specified in the clock-names property > - as specified in [1]. (mandatory) > - > -- clock-names: > - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) > - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) > - > -- resets: References to all the resets specified in the reset-names property > - as specified in [2]. (optional) > - > -- reset-names: string reset name, must be "apb" if used. (optional) > - > -- panel or bridge node: see [3]. (mandatory) > - > -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > -[2] Documentation/devicetree/bindings/reset/reset.txt > -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt > diff --git > a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > new file mode 100644 > index 0..d9ab464f79ff4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > @@ -0,0 +1,56 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Synopsys DesignWare MIPI DSI host controller > + > +maintainers: > + - Philippe CORNU > + > +description: | > + This document defines device tree properties for the Synopsys DesignWare > MIPI > + DSI host controller. It doesn't constitue a device tree binding > specification > + by itself but is meant to be referenced by platform-specific device tree > + bindings. > + > + When referenced from platform device tree bindings the properties defined > in > + this document are defined as follows. The platform device tree bindings are > + responsible for defining whether each property is required or optional. > + > +allOf: > + - $ref: ../dsi-controller.yaml# > + > +properties: > + reg: > +maxItems: 1 > + > + clocks: > +items: > + - description: Module clock > + - description: DSI bus clock for either AHB and APB > + - description: Pixel clock for the DPI/RGB input > +minItems: 2 > + > + clock-names: > +items: > + - const: ref > + - const: pclk > + - const: px_clk > +minItems: 2 > + > + resets: > +maxItems: 1 > + > + reset-names: > +const: apb I think you can also add the ports property and its child port@0 and port@1, as they're required in all cases. > + > +patternProperties: > + "^panel@[0-3]$": > +type: object > + > +required: > + - reg > + - clocks > + - clock-names -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver
Hi Adrian,
On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
>
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
>
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
> Signed-off-by: Liu Ying
>
> Cc: Fabio Estevam
> Cc: Enric Balletbo Serra
> Reviewed-by: Emil Velikov
> Tested-by: Adrian Pop
> Tested-by: Arnaud Ferraris
> Signed-off-by: Sjoerd Simons
> Signed-off-by: Martyn Welch
> Signed-off-by: Adrian Ratiu
> ---
> Changes since v6:
> - Replaced custom noop encoder with the simple drm encoder (Enric)
> - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF (Enric)
> - Dropped imx_mipi_dsi_register() because now it only creates the
> dummy encoder which can easily be done directly in imx_dsi_bind()
>
> Changes since v5:
> - Reword to remove unrelated device tree patch mention (Fabio)
> - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
> - Fix freescale.com -> nxp.com email addresses (Fabio)
> - Also added myself as module author (Fabio)
> - Use DRM_DEV_* macros for consistency, print more error msg
>
> Changes since v4:
> - Split off driver-specific configuration of phy timings due
> to new upstream API.
> - Move regmap infrastructure logic to separate commit (Ezequiel)
> - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
> - Minor warnings and driver name fixes
>
> Changes since v3:
> - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
>
> Changes since v2:
> - Fixed commit tags. (Emil)
>
> Changes since v1:
> - Moved register definitions & regmap initialization into bridge
> module. Platform drivers get the regmap via plat_data after
> calling the bridge probe. (Emil)
> ---
> drivers/gpu/drm/imx/Kconfig| 8 +
> drivers/gpu/drm/imx/Makefile | 1 +
> drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 391 +
> 3 files changed, 400 insertions(+)
> create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
>
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> index 207bf7409dfba..0dffc72df7922 100644
> --- a/drivers/gpu/drm/imx/Kconfig
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -39,3 +39,11 @@ config DRM_IMX_HDMI
> depends on DRM_IMX
> help
> Choose this if you want to use HDMI on i.MX6.
> +
> +config DRM_IMX6_MIPI_DSI
> + tristate "Freescale i.MX6 DRM MIPI DSI"
> + select DRM_DW_MIPI_DSI
> + depends on DRM_IMX
> + depends on OF
> + help
> + Choose this if you want to use MIPI DSI on i.MX6.
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index 21cdcc2faabc8..9a7843c593478 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>
> obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
> diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> new file mode 100644
> index 0..f8a0a4fe16e21
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> @@ -0,0 +1,391 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX6 drm driver - MIPI DSI Host Controller
> + *
> + * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019-2020 Collabora, Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx-drm.h"
> +
> +#define DSI_PWR_UP 0x04
> +#define RESET0
> +#define POWERUP BIT(0)
> +
> +#define DSI_PHY_IF_CTRL 0x5c
> +#define PHY_IF_CTRL_RESET0x0
> +
> +#define DSI_PHY_TST_CTRL00x64
> +#define PHY_TESTCLK BIT(1)
> +#define PHY_UNTESTCLK0
> +#define PHY_TESTCLR BIT(0)
> +#define PHY_UNTESTCLR0
> +
> +#define DSI_PHY_TST_CTRL10x68
> +#define PHY_TESTEN BIT(16)
> +#define PHY_UNTESTEN 0
> +#define PHY_TESTDOUT(n) (((n) & 0xff) << 8)
> +#define PHY_TESTDIN(n) (((n) & 0xff) << 0)
> +
> +struct imx_mipi_dsi {
> + struct drm_encoder encoder;
> + struct device *dev;
> + struct regmap *mux_sel;
> + struct dw_mipi_dsi *mipi_dsi;
> + struct clk *pllref_clk;
> +
> + void __iomem *base;
> + unsigned int lane_mbps;
> +};
> +
> +struct dphy_pll_testdin_map {
> + unsigned int max_mbps;
> + u8 testdin;
> +};
> +
> +/* The table is based on 27MHz DPHY pll reference clock. */
> +static const s
Re: [PATCH v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
Hi Adrian,
On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart wrote:
> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
> > This provides an example DT binding for the MIPI DSI host controller
> > present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
> >
> > Cc: Rob Herring
> > Cc: Neil Armstrong
> > Cc: Fabio Estevam
> > Cc: Laurent Pinchart
> > Cc: devicet...@vger.kernel.org
> > Tested-by: Adrian Pop
> > Tested-by: Arnaud Ferraris
> > Signed-off-by: Sjoerd Simons
> > Signed-off-by: Martyn Welch
> > Signed-off-by: Adrian Ratiu
> > ---
> > Changes since v6:
> > - Added ref to the newly created snps,dw-mipi-dsi.yaml (Laurent)
> > - Moved *-cells properties outside patternProperties (Laurent)
> > - Removed the panel port documentation (Laurent)
> > - Wrapped lines at 80 chars, typo fixes, sort includes (Laurent)
> >
> > Changes since v5:
> > - Fixed missing reg warning (Fabio)
> > - Updated dt-schema and fixed warnings (Rob)
> >
> > Changes since v4:
> > - Fixed yaml binding to pass `make dt_binding_check dtbs_check`
> > and addressed received binding feedback (Rob)
> >
> > Changes since v3:
> > - Added commit message (Neil)
> > - Converted to yaml format (Neil)
> > - Minor dt node + driver fixes (Rob)
> > - Added small panel example to the host controller binding
> >
> > Changes since v2:
> > - Fixed commit tags (Emil)
> > ---
> > .../display/imx/fsl,mipi-dsi-imx6.yaml| 135 ++
> > 1 file changed, 135 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> > b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> > new file mode 100644
> > index 0..b73e3ae33a852
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> > @@ -0,0 +1,135 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX6 DW MIPI DSI Host Controller
> > +
> > +maintainers:
> > + - Adrian Ratiu
> > +
> > +description: |
> > + The i.MX6 DSI host controller is a Synopsys DesignWare MIPI DSI v1.01
> > + IP block with a companion PHY IP.
I forgot to mention, if there's a companion PHY, shouldn't it be
referenced from the DT bindings ?
> > +
> > + These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
> > + Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
> > + the following device-specific properties.
> > +
> > +allOf:
> > + - $ref: ../bridge/snps,dw-mipi-dsi.yaml#
> > +
> > +properties:
> > + '#address-cells':
> > +const: 1
> > +
> > + '#size-cells':
> > +const: 0
> > +
> > + compatible:
> > +items:
> > + - const: fsl,imx6q-mipi-dsi
> > + - const: snps,dw-mipi-dsi
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: Module Clock
> > + - description: DSI bus clock
> > +
> > + clock-names:
> > +items:
> > + - const: ref
> > + - const: pclk
> > +
> > + fsl,gpr:
> > +description:
> > + Phandle to the iomuxc-gpr region containing the multiplexer ctrl
> > register.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + ports:
> > +type: object
> > +description: |
> > + A node containing DSI input & output port nodes with endpoint
> > + definitions as documented in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > + Documentation/devicetree/bindings/graph.txt
> > +properties:
> > + port@0:
> > +type: object
> > +description:
> > + DSI input port node, connected to the ltdc rgb output port.
> > +
> > + port@1:
> > +type: object
> > +description:
> > + RGB output port node, connected to a panel or a bridge input
> > port.
>
> Isn't it the other way around, doesn't the bridge take RGB input and
> output DSI ? And to be precise, it's not about RGB, but about the input
> being parallel interface (DSI will also carry RGB).
>
> I would add
>
> required:
> - port@0
> - port@1
>
> > +
> > +additionalProperties: false
> > +
> > +patternProperties:
> > + "^panel@[0-3]$":
> > +type: object
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - ports
> > +
> > +examples:
> > + - |+
> > +#include
> > +#include
> > +#include
> > +
> > +dsi: dsi@21e {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +compatible = "fsl,imx6q-mipi-dsi", "snps,
Re: [PATCH v7 5/8] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
Hi Adrian,
Thank you for the patch.
On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host controller
> present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
>
> Cc: Rob Herring
> Cc: Neil Armstrong
> Cc: Fabio Estevam
> Cc: Laurent Pinchart
> Cc: devicet...@vger.kernel.org
> Tested-by: Adrian Pop
> Tested-by: Arnaud Ferraris
> Signed-off-by: Sjoerd Simons
> Signed-off-by: Martyn Welch
> Signed-off-by: Adrian Ratiu
> ---
> Changes since v6:
> - Added ref to the newly created snps,dw-mipi-dsi.yaml (Laurent)
> - Moved *-cells properties outside patternProperties (Laurent)
> - Removed the panel port documentation (Laurent)
> - Wrapped lines at 80 chars, typo fixes, sort includes (Laurent)
>
> Changes since v5:
> - Fixed missing reg warning (Fabio)
> - Updated dt-schema and fixed warnings (Rob)
>
> Changes since v4:
> - Fixed yaml binding to pass `make dt_binding_check dtbs_check`
> and addressed received binding feedback (Rob)
>
> Changes since v3:
> - Added commit message (Neil)
> - Converted to yaml format (Neil)
> - Minor dt node + driver fixes (Rob)
> - Added small panel example to the host controller binding
>
> Changes since v2:
> - Fixed commit tags (Emil)
> ---
> .../display/imx/fsl,mipi-dsi-imx6.yaml| 135 ++
> 1 file changed, 135 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> new file mode 100644
> index 0..b73e3ae33a852
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> @@ -0,0 +1,135 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX6 DW MIPI DSI Host Controller
> +
> +maintainers:
> + - Adrian Ratiu
> +
> +description: |
> + The i.MX6 DSI host controller is a Synopsys DesignWare MIPI DSI v1.01
> + IP block with a companion PHY IP.
> +
> + These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
> + Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
> + the following device-specific properties.
> +
> +allOf:
> + - $ref: ../bridge/snps,dw-mipi-dsi.yaml#
> +
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + compatible:
> +items:
> + - const: fsl,imx6q-mipi-dsi
> + - const: snps,dw-mipi-dsi
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: Module Clock
> + - description: DSI bus clock
> +
> + clock-names:
> +items:
> + - const: ref
> + - const: pclk
> +
> + fsl,gpr:
> +description:
> + Phandle to the iomuxc-gpr region containing the multiplexer ctrl
> register.
> +$ref: /schemas/types.yaml#/definitions/phandle
> +
> + ports:
> +type: object
> +description: |
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> +properties:
> + port@0:
> +type: object
> +description:
> + DSI input port node, connected to the ltdc rgb output port.
> +
> + port@1:
> +type: object
> +description:
> + RGB output port node, connected to a panel or a bridge input port.
Isn't it the other way around, doesn't the bridge take RGB input and
output DSI ? And to be precise, it's not about RGB, but about the input
being parallel interface (DSI will also carry RGB).
I would add
required:
- port@0
- port@1
> +
> +additionalProperties: false
> +
> +patternProperties:
> + "^panel@[0-3]$":
> +type: object
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - ports
> +
> +examples:
> + - |+
> +#include
> +#include
> +#include
> +
> +dsi: dsi@21e {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
> +reg = <0x021e 0x4000>;
> +interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
> +fsl,gpr = <&gpr>;
> +clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
> + <&clks IMX6QDL_CLK_MIPI_IPG>;
> +clock-names = "ref", "pclk";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
port@0 is missing.
> +port@1 {
> +reg = <1>;
> +ds
Re: [PATCH AUTOSEL 5.6 084/129] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
On Wed, Apr 15, 2020 at 06:11:10PM +0200, Karol Herbst wrote: in addition to that 028a12f5aa829 "drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init" should probably get picked as well as it's fixing some runtime pm related issue on a handful of additional GPUs. I have a laptop myself which requires both of those patches. Applies to 5.5 and 5..4 as well. I've grabbed it for 5.6 and 5.4 (5.5 is EOL), thanks! -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Hi, Matthias: Matthias Brugger 於 2020年4月21日 週二 下午5:31寫道： > > > > On 4/16/20 6:22 PM, Chun-Kuang Hu wrote: > > Hi, Matthias: > > > > Matthias Brugger 於 2020年3月26日 週四 下午11:45寫道： > >> > >> > >> > >> On 26/03/2020 15:51, CK Hu wrote: > >>> Hi, Matthias: > >>> > >>> On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote: > Hi CK, > > On 26/03/2020 00:05, CK Hu wrote: > > Hi, Matthias: > > > > On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote: > >> > >> On 11/03/2020 17:53, Enric Balletbo i Serra wrote: > >>> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() > >>> functions to > >>> replace mtk_ddp_add_comp_to_path() and > >>> mtk_ddp_remove_comp_from_path(). > >>> Those functions will allow DRM driver and others to control the data > >>> path routing. > >>> > >>> Signed-off-by: Enric Balletbo i Serra > >>> Reviewed-by: Matthias Brugger > >>> Reviewed-by: CK Hu > >>> Acked-by: CK Hu > >> > >> This patch does not apply against v5.6-rc1. > >> Please rebase as this is a quite big patch and it won't be easy to do > >> that by hand. > > > > I think this patch depends on [1] which has been acked by me and I have > > not picked it. The simple way is that you pick [1] first and then pick > > this series. > > > > [1] > > https://patchwork.kernel.org/patch/11406227/ > > > > You would need to provide a stable tag for me that I can merge into my > tree. You > can also try to merge my for-next [1] which has the newest version from > Enric. > If you see any merge conflict, then we have to do something about it :) > > Regards, > Matthias > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next > > >>> > >>> You have applied this series, so I would not apply other patches which > >>> would conflict with this series. After this series land on main stream > >>> (wish it happen in this merge window), I would rebase other patch on > >>> main stream. > >>> > >> > >> I haven't (yet) send the pull request. If you want to bring in your > >> patches in > >> v5.7 as well we can find a solution to that. Shall I provide you with a > >> stable > >> branch which you can merge? This way you can add all your patches in the > >> pull > >> request as well and we don't have to wait for v5.8 to get things into > >> mainline. > >> > >> Let me know and I'll provide you with a stable branch. > > > > This series is in linux-next but does not in main stream. So would you > > please provide a stable branch so I could pull this series? > > > > Please find the pull request below: > > The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: > > Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) > > are available in the Git repository at: > > > https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/ > tags/v5.7-next-drm-stable > > for you to fetch changes up to 667c769246b01c53ad0925d603d2a2531abd3ef2: > > soc / drm: mediatek: Fix mediatek-drm device probing (2020-04-13 > 13:01:16 +0200) > > > Enric Balletbo i Serra (3): > dt-bindings: mediatek: Update mmsys binding to reflect it is a > system controller > soc / drm: mediatek: Move routing control to mmsys device > soc / drm: mediatek: Fix mediatek-drm device probing > > Matthias Brugger (2): > drm/mediatek: Omit warning on probe defers > clk / soc: mediatek: Move mt8173 MMSYS to platform driver > > Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt | 7 +-- > drivers/clk/mediatek/Kconfig | 7 +++ > drivers/clk/mediatek/Makefile | 1 + > drivers/clk/mediatek/clk-mt8173-mm.c | 146 > +++ > drivers/clk/mediatek/clk-mt8173.c | 104 > -- > drivers/gpu/drm/mediatek/Kconfig | 1 + > drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 ++- > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 ++- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 ++- > drivers/gpu/drm/mediatek/mtk_dpi.c| 12 > +++-- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 259 > + > drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 7 --- > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 45 > ++- > drivers/gp
Re: [PATCH v6 0/4] Config mipi tx current and impedance
Hi, Jitao: For this series, applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. Jitao Shi 於 2020年4月11日 週六 下午3:44寫道： > > Changes since v5: > - remove memset() > - add return to remove "else" > > Changes since v4: > - add Reviewed-by: > - move the get the calibration data code to probe. > > Changes since v3: > - refine drive-strength-microamp as from 3000 to 6000. > > Changes since v2: > - fix the title of commit message. > - rename mipitx-current-drive to drive-strength-microamp > > Changes since v1: > - fix coding style. > - change mtk_mipi_tx_config_calibration_data() to void > > Jitao Shi (4): > dt-bindings: display: mediatek: add property to control mipi tx drive > current > dt-bindings: display: mediatek: get mipitx calibration data from nvmem > drm/mediatek: add the mipitx driving control > drm/mediatek: config mipitx impedance with calibration data > > .../display/mediatek/mediatek,dsi.txt | 10 > drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 54 +++ > drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 4 ++ > drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 28 ++ > 4 files changed, 96 insertions(+) > > -- > 2.21.0 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206021] AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 Clément Guérin (li...@protonmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #8 from Clément Guérin (li...@protonmail.com) --- Moving to https://gitlab.freedesktop.org/drm/amd/-/issues/1112 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207331] commit "drm/amdgpu: fix gfx hang during suspend with video playback" breaks reboot/shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=207331 Grzegorz Kowal (custos.men...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #5 from Grzegorz Kowal (custos.men...@gmail.com) --- Fixed in stable versions 5.6.6 and 5.4.34. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 2/3] dt-bindings: display: mediatek: convert the document format from txt to yaml
Hi, Jitao:
Please fixup these checkpatch warnings.
WARNING: Missing commit description - Add an appropriate one
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.txt
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.txt
WARNING: DT binding documents should be licensed (GPL-2.0-only OR BSD-2-Clause)
#71: FILE:
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml:1:
+# SPDX-License-Identifier: GPL-2.0
Regards,
Chun-Kuang.
Jitao Shi 於 2020年4月15日 週三 上午9:13寫道：
>
> Signed-off-by: Jitao Shi
> ---
> .../bindings/display/mediatek/mediatek,dpi.txt | 42 --
> .../bindings/display/mediatek/mediatek,dpi.yaml| 97
> ++
> 2 files changed, 97 insertions(+), 42 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> deleted file mode 100644
> index 77def4456706..
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -Mediatek DPI Device
> -===
> -
> -The Mediatek DPI function block is a sink of the display subsystem and
> -provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
> -output bus.
> -
> -Required properties:
> -- compatible: "mediatek,-dpi"
> - the supported chips are mt2701 , mt8173 and mt8183.
> -- reg: Physical base address and length of the controller's registers
> -- interrupts: The interrupt signal from the function block.
> -- clocks: device clocks
> - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> -- clock-names: must contain "pixel", "engine", and "pll"
> -- port: Output port node with endpoint definitions as described in
> - Documentation/devicetree/bindings/graph.txt. This port should be connected
> - to the input port of an attached HDMI or LVDS encoder chip.
> -
> -Optional properties:
> -- pinctrl-names: Contain "default" and "sleep".
> -
> -Example:
> -
> -dpi0: dpi@1401d000 {
> - compatible = "mediatek,mt8173-dpi";
> - reg = <0 0x1401d000 0 0x1000>;
> - interrupts = ;
> - clocks = <&mmsys CLK_MM_DPI_PIXEL>,
> -<&mmsys CLK_MM_DPI_ENGINE>,
> -<&apmixedsys CLK_APMIXED_TVDPLL>;
> - clock-names = "pixel", "engine", "pll";
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <&dpi_pin_func>;
> - pinctrl-1 = <&dpi_pin_idle>;
> -
> - port {
> - dpi0_out: endpoint {
> - remote-endpoint = <&hdmi0_in>;
> - };
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> new file mode 100644
> index ..2c2d6a71cb8b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: mediatek DPI Controller Device Tree Bindings
> +
> +maintainers:
> + - CK Hu
> + - Jitao shi
> +
> +description: |
> + The Mediatek DPI function block is a sink of the display subsystem and
> + provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
> + output bus.
> +
> +properties:
> + compatible:
> +enum:
> + - mediatek,mt2701-dpi
> + - mediatek,mt8173-dpi
> + - mediatek,mt8183-dpi
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: Pixel Clock
> + - description: Engine Clock
> + - description: DPI PLL
> +
> + clock-names:
> +items:
> + - const: pixel
> + - const: engine
> + - const: pll
> +
> + pinctrl-0: true
> + pinctrl-1: true
> +
> + pinctrl-names:
> +items:
> + - const: default
> + - const: sleep
> +
> + port:
> +type: object
> +description:
> + Output port node with endpoint definitions as described in
> + Documentation/devicetree/bindings/graph.txt. This port should be
> connected
> + to the input port of an attached HDMI or LVDS encoder chip.
> +
> +properties:
> + endpoint:
> +type: object
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +dpi0: dpi@1401d000 {
> +
[PATCH 2/2] drm/lima: Clean up redundant pdev pointer
There's no point explicitly tracking the platform device when it can be
trivially derived from the regular device pointer in the couple of
places it's ever used.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/lima/lima_devfreq.c | 7 +++
drivers/gpu/drm/lima/lima_device.c | 5 ++---
drivers/gpu/drm/lima/lima_device.h | 1 -
drivers/gpu/drm/lima/lima_drv.c | 1 -
4 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index 8c4d21d07529..1d479b5924fe 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -101,13 +101,12 @@ void lima_devfreq_fini(struct lima_device *ldev)
}
if (devfreq->devfreq) {
- devm_devfreq_remove_device(&ldev->pdev->dev,
- devfreq->devfreq);
+ devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
}
if (devfreq->opp_of_table_added) {
- dev_pm_opp_of_remove_table(&ldev->pdev->dev);
+ dev_pm_opp_of_remove_table(ldev->dev);
devfreq->opp_of_table_added = false;
}
@@ -125,7 +124,7 @@ void lima_devfreq_fini(struct lima_device *ldev)
int lima_devfreq_init(struct lima_device *ldev)
{
struct thermal_cooling_device *cooling;
- struct device *dev = &ldev->pdev->dev;
+ struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
struct lima_devfreq *ldevfreq = &ldev->devfreq;
diff --git a/drivers/gpu/drm/lima/lima_device.c
b/drivers/gpu/drm/lima/lima_device.c
index c334d297796a..29285dedd124 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -297,8 +297,8 @@ static void lima_fini_pp_pipe(struct lima_device *dev)
int lima_device_init(struct lima_device *ldev)
{
+ struct platform_device *pdev = to_platform_device(ldev->dev);
int err, i;
- struct resource *res;
dma_set_coherent_mask(ldev->dev, DMA_BIT_MASK(32));
@@ -329,8 +329,7 @@ int lima_device_init(struct lima_device *ldev)
} else
ldev->va_end = LIMA_VA_RESERVE_END;
- res = platform_get_resource(ldev->pdev, IORESOURCE_MEM, 0);
- ldev->iomem = devm_ioremap_resource(ldev->dev, res);
+ ldev->iomem = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(ldev->iomem)) {
dev_err(ldev->dev, "fail to ioremap iomem\n");
err = PTR_ERR(ldev->iomem);
diff --git a/drivers/gpu/drm/lima/lima_device.h
b/drivers/gpu/drm/lima/lima_device.h
index 06fd9636dd72..99b1fb147dad 100644
--- a/drivers/gpu/drm/lima/lima_device.h
+++ b/drivers/gpu/drm/lima/lima_device.h
@@ -76,7 +76,6 @@ enum lima_pipe_id {
struct lima_device {
struct device *dev;
struct drm_device *ddev;
- struct platform_device *pdev;
enum lima_gpu_id id;
u32 gp_version;
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index bbbdc8455e2f..4e5dd75822c0 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -380,7 +380,6 @@ static int lima_pdev_probe(struct platform_device *pdev)
goto err_out0;
}
- ldev->pdev = pdev;
ldev->dev = &pdev->dev;
ldev->id = (enum lima_gpu_id)of_device_get_match_data(&pdev->dev);
--
2.23.0.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/lima: Clean up IRQ warnings
Use the optional form of platform_get_irq() for blocks that legitimately
may not be present, to avoid getting an annoying barrage of spurious
warnings for non-existent PPs on configurations like Mali-450 MP2.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/lima/lima_device.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_device.c
b/drivers/gpu/drm/lima/lima_device.c
index 247f51fd40a2..c334d297796a 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -171,8 +171,10 @@ static void lima_regulator_fini(struct lima_device *dev)
static int lima_init_ip(struct lima_device *dev, int index)
{
+ struct platform_device *pdev = to_platform_device(dev->dev);
struct lima_ip_desc *desc = lima_ip_desc + index;
struct lima_ip *ip = dev->ip + index;
+ const char *irq_name = desc->irq_name;
int offset = desc->offset[dev->id];
bool must = desc->must_have[dev->id];
int err;
@@ -183,8 +185,9 @@ static int lima_init_ip(struct lima_device *dev, int index)
ip->dev = dev;
ip->id = index;
ip->iomem = dev->iomem + offset;
- if (desc->irq_name) {
- err = platform_get_irq_byname(dev->pdev, desc->irq_name);
+ if (irq_name) {
+ err = must ? platform_get_irq_byname(pdev, irq_name) :
+platform_get_irq_byname_optional(pdev, irq_name);
if (err < 0)
goto out;
ip->irq = err;
--
2.23.0.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Clean up GPIO includes
On Wed, Apr 15, 2020 at 02:24:27PM +0200, Linus Walleij wrote: > The Tegra DRM drivers includes the legacy GPIO headers > and but what it really > uses is since only gpio_desc > structs are ever referenced. > > Include the right header on the top level tegra/drm.h > file and drop all the surplus includes. > > Signed-off-by: Linus Walleij > --- > drivers/gpu/drm/tegra/dpaux.c | 2 -- > drivers/gpu/drm/tegra/drm.h | 2 +- > drivers/gpu/drm/tegra/hdmi.c | 1 - > drivers/gpu/drm/tegra/sor.c | 1 - > 4 files changed, 1 insertion(+), 5 deletions(-) Applied, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/59] drm: Add devm_drm_dev_alloc macro
Hi > > Hm, I see the point of this (and the dev_field below, although I'd go > > with dev_member there for some consistency with other macros using > > offset_of or container_of), but I'm not sure about the dev_ prefix. > > Drivers use that sometimes for the struct device *, and usage for > > struct drm_device * is also very inconsistent. I've seen ddev, drm, > > dev and base (that one only for embedded structs ofc). So not sure > > which prefix to pick, aside from dev_ seems the most confusing. Got > > ideas? > > We have pdev for the PCI device, dev for the abstract device, and things > like mdev for struct mga_device in mgag200. So I'd go with ddev. I don't > like drm, because it could be anything in DRM. I guess struct drm_driver > is more 'drm' than struct drm_device. > > But all of this is bikeshedding. It's probably best to keep the patch > as-is, and maybe rename variables later if we ever find consent on the > naming. bikeshedding - I know. But reading code is is quite natural for me that drm equals the central drm_device data structure. Maybe thats because this was is in the code I started looking at. So as an example: drm_err(drm, "bla bla\n"); This parses nicely and is easy to type and get right. And matches nicely that drm_device => drm. But bikeshedding - I will go to bed... (Whatever is the conclusion we should not hold back the patch in questions). Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 1/2] drm/panel: add support for rm69299 visionox panel driver
Hi,
On Tue, Apr 21, 2020 at 10:25:07AM +0530, Harigovindan P wrote:
> Add support for Visionox panel driver.
>
> Signed-off-by: Harigovindan P
Please keep tags from previous versions (like my Reviewed-by from v7)
when making minimal changes.
Also there is no need to keep sending the bindings patch, it already
landed in drm-misc.
> diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> new file mode 100644
> index ..3ef4cc80044a
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
...
> +MODULE_DESCRIPTION("Visionox RM69299 DSI Panel Driver");
> --
> 2.25.1
The last two lines break the patch:
git am
/tmp/v11-1-2-drm-panel-add-support-for-rm69299-visionox-panel-driver.patch
Applying: drm/panel: add support for rm69299 visionox panel driver
error: corrupt patch at line 379
Patch failed at 0001 drm/panel: add support for rm69299 visionox panel driver
Besides the broken format:
Reviewed-by: Matthias Kaehlcke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/xen-front: Add support for Xen PV display frontend
On Tue, Apr 21, 2020 at 08:59:09PM +0200, Julia Lawall wrote:
>
>
> On Tue, 21 Apr 2020, Dan Carpenter wrote:
>
> > On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Tue, 21 Apr 2020, Dan Carpenter wrote:
> > >
> > > > Hi Kernel Janitors,
> > > >
> > > > Here is another idea that someone could work on, fixing the
> > > > IS_ERR_OR_NULL() checks in the xen driver.
> > > >
> > > > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> > > > display frontend" from Apr 3, 2018, leads to the following static
> > > > checker warning:
> > > >
> > > > drivers/gpu/drm/xen/xen_drm_front_gem.c:140
> > > > xen_drm_front_gem_create()
> > > > warn: passing zero to 'ERR_CAST'
> > > >
> > > > drivers/gpu/drm/xen/xen_drm_front_gem.c
> > > >133 struct drm_gem_object *xen_drm_front_gem_create(struct
> > > > drm_device *dev,
> > > >134 size_t size)
> > > >135 {
> > > >136 struct xen_gem_object *xen_obj;
> > > >137
> > > >138 xen_obj = gem_create(dev, size);
> > > >139 if (IS_ERR_OR_NULL(xen_obj))
> > > >140 return ERR_CAST(xen_obj);
> > >
> > > Are the other occurrences of this also a possible problem? There are a
> > > few others outside of xen.
> >
> > We sometimes check a parameter for IS_ERR_OR_NULL().
> >
> > void free_function(struct something *p)
> > {
> > if (IS_ERR_OR_NULL(p))
> > return;
> > }
> >
> > That's fine, absolutely harmless and not a bug. But if we are checking
> > a return value like this then probably most of the time it's invalid
> > code. Normally it's again like this code where we're dealing with an
> > impossible thing because the return is never NULL. The common bugs are
> > that it returns NULL to a caller which only expects error pointers or it
> > returns success instead of failure. But sometimes returning success can
> > be valid:
> >
> > obj = get_feature(dev);
> > if (IS_ERR_OR_NULL(obj))
> > return PTR_ERR(obj);
> >
> > It deliberately returns success because the rest of the function is
> > useless when we don't have the feature.
>
> The other cases are also with ERR_CAST:
I bet these are less likely to be correct because probably the optional
feature doesn't translate to a different optional feature.
>
> drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c in create_udp_flow
This can never be NULL, but look at this code:
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
427 if (trans_spec) {
428 qp_flow = create_and_add_flow(qp_grp,
429
trans_spec);
430 if (IS_ERR_OR_NULL(qp_flow)) {
431 status = qp_flow ?
PTR_ERR(qp_flow) : -EFAULT;
432 break;
433 }
434 } else {
If the create_and_add_flow() returns NULL, that's a bug because it's not
an optional feature which can be disabled in the config etc. But this
code has been future proofed in case future users decide to write buggy
code the NULL gets changed to an error code.
Is -EFAULT the correct way to handle bugs that future programmers are
going to introduce? You have to very psychic to know the answer to
that.
> fs/overlayfs/namei.c in ovl_index_upper
This code is correct. There are actually a bunch of functions in VFS
which only return NULL and error pointers, never valid pointers. VFS
is weird like that.
> sound/soc/qcom/qdsp6/q6adm.c in q6adm_open
Never NULL. It should be IS_ERR().
> drivers/clk/clk.c in clk_hw_create_clk
This is checking a parameter so it's fine.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
On Fri, Apr 17, 2020 at 7:16 AM H. Nikolaus Schaller wrote:
>
> Hi Rob,
>
> > Am 16.04.2020 um 22:41 schrieb Rob Herring :
> >
> > On Wed, 15 Apr 2020 10:35:08 +0200, "H. Nikolaus Schaller" wrote:
> >> The Imagination PVR/SGX GPU is part of several SoC from
> >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
> >> Allwinner A83 and others.
> >>
> >> With this binding, we describe how the SGX processor is
> >> interfaced to the SoC (registers, interrupt etc.).
> >>
> >> In most cases, Clock, Reset and power management is handled
> >> by a parent node or elsewhere (e.g. code in the driver).
> >>
> >> Tested by make dt_binding_check dtbs_check
> >>
> >> Signed-off-by: H. Nikolaus Schaller
> >> ---
> >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 122 ++
> >> 1 file changed, 122 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
> >>
> >
> > My bot found errors running 'make dt_binding_check' on your patch:
> >
> > Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml: while parsing a
> > block mapping
> > in "", line 74, column 13
>
> It turned out that there was a stray " in line 74 from the last editing phase.
> Will be fixed in v7.
>
> Would it be possible to make dt_binding_check not only report line/column but
> the
> contents of the line instead of ""?
This comes from ruamel.yaml module. I believe "" is
supposed to be the type of the data, not what it is. However, it is
possible to get something a bit more helpful, but it depends on which
parser is used. By default we use the C based parser (aka 'safe'). If
we use the round trip parser, we get this:
ruamel.yaml.scanner.ScannerError: while scanning a simple key
in "", line 84, column 5:
maxItems
^ (line: 84)
This can be enabled by passing '-n' (line numbers) to dt-doc-validate.
Currently, you have have to edit the Makefile to do this. The C parser
is a big difference in speed, so I don't want to change the default.
I can probably work around this and dump the erroring line, but I'm
not sure that's always useful. Many errors are indentation related and
those need some context. Plus just dumping the line can be done easily
with sed:
sed -n ${LINE}p
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/xen-front: Add support for Xen PV display frontend
On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
>
>
> On Tue, 21 Apr 2020, Dan Carpenter wrote:
>
> > Hi Kernel Janitors,
> >
> > Here is another idea that someone could work on, fixing the
> > IS_ERR_OR_NULL() checks in the xen driver.
> >
> > The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> > display frontend" from Apr 3, 2018, leads to the following static
> > checker warning:
> >
> > drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> > warn: passing zero to 'ERR_CAST'
> >
> > drivers/gpu/drm/xen/xen_drm_front_gem.c
> >133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device
> > *dev,
> >134 size_t size)
> >135 {
> >136 struct xen_gem_object *xen_obj;
> >137
> >138 xen_obj = gem_create(dev, size);
> >139 if (IS_ERR_OR_NULL(xen_obj))
> >140 return ERR_CAST(xen_obj);
>
> Are the other occurrences of this also a possible problem? There are a
> few others outside of xen.
We sometimes check a parameter for IS_ERR_OR_NULL().
void free_function(struct something *p)
{
if (IS_ERR_OR_NULL(p))
return;
}
That's fine, absolutely harmless and not a bug. But if we are checking
a return value like this then probably most of the time it's invalid
code. Normally it's again like this code where we're dealing with an
impossible thing because the return is never NULL. The common bugs are
that it returns NULL to a caller which only expects error pointers or it
returns success instead of failure. But sometimes returning success can
be valid:
obj = get_feature(dev);
if (IS_ERR_OR_NULL(obj))
return PTR_ERR(obj);
It deliberately returns success because the rest of the function is
useless when we don't have the feature.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/bochs: fix an issue of ioremap() leak
On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng wrote:
>
> It forgot to call bochs_hw_fini() to release related resources when
> bochs_pci_probe() fail. eg: io virtual address get by ioremap().
Good start, although I think the best is to switch this driver to use
pcim_*() functions and drop tons of legacy code.
> Fixes: 81da8c3b8d3df6 ("drm/bochs: add drm_driver.release callback.")
> CC: Andy Shevchenko
> Signed-off-by: Dejin Zheng
> ---
> drivers/gpu/drm/bochs/bochs_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index addb0568c1af..210a60135c8a 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -138,6 +138,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
> return ret;
>
> err_unload:
> + bochs_hw_fini(dev);
> bochs_unload(dev);
> err_free_dev:
> drm_dev_put(dev);
> --
> 2.25.0
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/msm/a6xx: update a6xx_hw_init for A640 and A650
On Mon, Apr 20, 2020 at 10:03:13AM -0400, Jonathan Marek wrote:
> Adreno 640 and 650 GPUs need some registers set differently.
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/a6xx.xml.h | 14 +++
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 ++-
> 2 files changed, 61 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
> b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
> index ed78fee2a262..47840b73cdda 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
> @@ -1047,6 +1047,8 @@ enum a6xx_tex_type {
>
> #define REG_A6XX_CP_MISC_CNTL
> 0x0840
>
> +#define REG_A6XX_CP_APRIV_CNTL
> 0x0844
> +
> #define REG_A6XX_CP_ROQ_THRESHOLDS_1 0x08c1
>
> #define REG_A6XX_CP_ROQ_THRESHOLDS_2 0x08c2
> @@ -1764,6 +1766,8 @@ static inline uint32_t
> A6XX_CP_PROTECT_REG_MASK_LEN(uint32_t val)
>
> #define REG_A6XX_RBBM_VBIF_CLIENT_QOS_CNTL 0x0010
>
> +#define REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL 0x0011
> +
> #define REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL
> 0x001f
>
> #define REG_A6XX_RBBM_INT_CLEAR_CMD 0x0037
> @@ -2418,6 +2422,16 @@ static inline uint32_t
> A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
>
> #define REG_A6XX_TPL1_NC_MODE_CNTL 0xb604
>
> +#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_0
> 0xb608
> +
> +#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_1
> 0xb609
> +
> +#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_2
> 0xb60a
> +
> +#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_3
> 0xb60b
> +
> +#define REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_4
> 0xb60c
> +
> #define REG_A6XX_TPL1_PERFCTR_TP_SEL_0
> 0xb610
>
> #define REG_A6XX_TPL1_PERFCTR_TP_SEL_1
> 0xb611
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index a860d4970e10..e1eb34fa3a99 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -414,7 +414,17 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> a6xx_set_hwcg(gpu, true);
>
> /* VBIF/GBIF start*/
> - gpu_write(gpu, REG_A6XX_RBBM_VBIF_CLIENT_QOS_CNTL, 0x3);
Oops, this should have been changed for 618 too. Only 630 had the VBIF
so you can invert this if statement.
> + if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu)) {
> + gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE0, 0x00071620);
> + gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE1, 0x00071620);
> + gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE2, 0x00071620);
> + gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE3, 0x00071620);
> + gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE3, 0x00071620);
> + gpu_write(gpu, REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL, 0x3);
> + } else {
> + gpu_write(gpu, REG_A6XX_RBBM_VBIF_CLIENT_QOS_CNTL, 0x3);
> + }
> +
> if (adreno_is_a630(adreno_gpu))
> gpu_write(gpu, REG_A6XX_VBIF_GATE_OFF_WRREQ_EN, 0x0009);
>
> @@ -429,25 +439,35 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> gpu_write(gpu, REG_A6XX_UCHE_WRITE_THRU_BASE_LO, 0xf000);
> gpu_write(gpu, REG_A6XX_UCHE_WRITE_THRU_BASE_HI, 0x0001);
>
> - /* Set the GMEM VA range [0x10:0x10 + gpu->gmem - 1] */
> - gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MIN_LO,
> - REG_A6XX_UCHE_GMEM_RANGE_MIN_HI, 0x0010);
> + if (!adreno_is_a650(adreno_gpu)) {
> + /* Set the GMEM VA range [0x10:0x10 + gpu->gmem - 1] */
> + gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MIN_LO,
> + REG_A6XX_UCHE_GMEM_RANGE_MIN_HI, 0x0010);
>
> - gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MAX_LO,
> - REG_A6XX_UCHE_GMEM_RANGE_MAX_HI,
> - 0x0010 + adreno_gpu->gmem - 1);
> + gpu_write64(gpu, REG_A6XX_UCHE_GMEM_RANGE_MAX_LO,
> + REG_A6XX_UCHE_GMEM_RANGE_MAX_HI,
> + 0x0010 + adreno_gpu->gmem - 1);
> + }
>
> gpu_write(gpu, REG_A6XX_UCHE_FILTER_CNTL, 0x804);
> gpu_write(gpu, REG_A6XX_UCHE_CACHE_WAYS, 0x4);
>
> - gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_2, 0x01c0);
> + if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu))
> + gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_2, 0x02000140);
> + else
> + gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_2, 0x01c0);
> gpu_write(gpu, REG_A6XX_CP_ROQ_THRESHOLDS_1, 0x8040362c);
>
> /* Setting the mem pool size */
>
Re: [Freedreno] [PATCH 8/9] drm/msm/a6xx: enable GMU log
On Mon, Apr 20, 2020 at 10:03:12AM -0400, Jonathan Marek wrote:
> This is required for a650 to work.
>
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 16
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
> drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 4
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index b583bf6e293b..1cdb7c832b87 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -198,6 +198,12 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
> u32 val;
>
> gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
> +
> + /* Set the log wptr index
> + * note: downstream saves the value in poweroff and restores it here
> + */
> + gmu_write(gmu, REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_RESP, 0);
> +
> gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 0);
>
> ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_CM3_FW_INIT_RESULT, val,
> @@ -739,6 +745,9 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu,
> unsigned int state)
>
> gmu_write(gmu, REG_A6XX_GMU_HFI_SFR_ADDR, chipid);
>
> + gmu_write(gmu, REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_MSG,
> + gmu->log->iova | (gmu->log->size / SZ_4K - 1));
> +
> /* Set up the lowest idle level on the GMU */
> a6xx_gmu_power_config(gmu);
>
> @@ -1416,6 +1425,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> a6xx_gmu_memory_free(gmu, gmu->dcache);
> a6xx_gmu_memory_free(gmu, gmu->dummy);
> a6xx_gmu_memory_free(gmu, gmu->debug);
> + a6xx_gmu_memory_free(gmu, gmu->log);
> a6xx_gmu_memory_free(gmu, gmu->hfi);
>
> iommu_detach_device(gmu->domain, gmu->dev);
> @@ -1495,6 +1505,11 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> if (IS_ERR(gmu->hfi))
> goto err_memory;
>
> + /* Allocate memory for the GMU log region */
> + gmu->log = a6xx_gmu_memory_alloc(gmu, SZ_4K, 0);
> + if (IS_ERR(gmu->log))
> + goto err_memory;
> +
> /* Map the GMU registers */
> gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
> if (IS_ERR(gmu->mmio))
> @@ -1542,6 +1557,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> a6xx_gmu_memory_free(gmu, gmu->dcache);
> a6xx_gmu_memory_free(gmu, gmu->dummy);
> a6xx_gmu_memory_free(gmu, gmu->debug);
> + a6xx_gmu_memory_free(gmu, gmu->log);
> a6xx_gmu_memory_free(gmu, gmu->hfi);
This is starting to feel like we could use some devres style garbage collection.
>
> if (gmu->domain) {
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> index abd425ca6682..589b9b0c348e 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> @@ -59,6 +59,7 @@ struct a6xx_gmu {
>
> struct a6xx_gmu_bo *hfi;
> struct a6xx_gmu_bo *debug;
> + struct a6xx_gmu_bo *log;
> struct a6xx_gmu_bo *icache;
> struct a6xx_gmu_bo *dcache;
> struct a6xx_gmu_bo *dummy;
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
> index b4357ea550ec..176ae94d9fe6 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
> @@ -205,6 +205,10 @@ static inline uint32_t
> A6XX_GMU_GPU_NAP_CTRL_SID(uint32_t val)
>
> #define REG_A6XX_GPU_GMU_CX_GMU_CX_FAL_INTF 0x50f0
>
> +#define REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_MSG
> 0x5100
> +
> +#define REG_A6XX_GPU_GMU_CX_GMU_PWR_COL_CP_RESP
> 0x5101
> +
> #define REG_A6XX_GMU_BOOT_KMD_LM_HANDSHAKE 0x51f0
>
> #define REG_A6XX_GMU_LLM_GLM_SLEEP_CTRL
> 0x5157
> --
> 2.26.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/msm/a6xx: gmu_pdc register values for A640 and A650
On Mon, Apr 20, 2020 at 10:03:11AM -0400, Jonathan Marek wrote: > Signed-off-by: Jonathan Marek I was wondering where this was. I don't think there is any reason to not squash this into the previous patch since the GMU won't be operational without it. > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index 3e51939eb867..b583bf6e293b 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -469,10 +469,18 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) > struct platform_device *pdev = to_platform_device(gmu->dev); > void __iomem *pdcptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc"); > void __iomem *seqptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc_seq"); > + uint32_t pdc_address_offset; > > if (!pdcptr || !seqptr) > goto err; > > + if (adreno_is_a618(adreno_gpu) || adreno_is_a640(adreno_gpu)) > + pdc_address_offset = 0x30090; > + else if (adreno_is_a650(adreno_gpu)) > + pdc_address_offset = 0x300a0; > + else > + pdc_address_offset = 0x30080; > + > /* Disable SDE clock gating */ > gmu_write_rscc(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0, BIT(24)); > > @@ -523,10 +531,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 4, 0x0); > > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 8, 0x10108); > - if (adreno_is_a618(adreno_gpu)) > - pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, 0x30090); > - else > - pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, 0x30080); > + pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, > pdc_address_offset); > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 8, 0x0); > > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK, 7); > @@ -538,17 +543,12 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) > > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 4, 0x10108); > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 4, 0x3); > - if (adreno_is_a618(adreno_gpu)) > + if (adreno_is_a618(adreno_gpu) || adreno_is_a650(adreno_gpu)) > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4, 0x2); > else > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4, 0x3); > - > - > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 8, 0x10108); > - if (adreno_is_a618(adreno_gpu)) > - pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 8, 0x30090); > - else > - pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 8, 0x30080); > + pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 8, > pdc_address_offset); > pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 8, 0x3); > > /* Setup GPU PDC */ > -- > 2.26.1 > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Couple of documentation typo fixes
On Tue, 21 Apr 2020 14:38:37 +0200 Daniel Vetter wrote: > On Mon, Apr 20, 2020 at 05:00:59PM -0600, Jonathan Corbet wrote: > > On Mon, 20 Apr 2020 10:41:15 +0300 > > Gal Pressman wrote: > > > > > Fix a couple of typos: "as" -> "has" and "int" -> "in". > > > > > > Signed-off-by: Gal Pressman > > > > Applied, thanks. > > Also applied to drm-misc-next, the dma-buf stuff is maintained as part of > drm. And maybe I actually get around to doing the doc polish for all > things dma-buf that I've been promised to do since months :-) I actually looked for it in linux-next before applying, but didn't (and don't) see it there...? Thanks, jon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/msm/a6xx: HFI v2 for A640 and A650
On Mon, Apr 20, 2020 at 10:03:08AM -0400, Jonathan Marek wrote:
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 68 ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
> drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 117 --
> drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 50 ++-
> 5 files changed, 224 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index c6ecb3189ec5..dc2d69837110 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -126,8 +126,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
> index)
> if (ret)
> dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
>
> - gmu->freq = gmu->gpu_freqs[index];
> -
> /*
>* Eventually we will want to scale the path vote with the frequency but
>* for now leave it at max so that the performance is nominal.
> @@ -151,7 +149,12 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned
> long freq)
>
> gmu->current_perf_index = perf_index;
>
> - __a6xx_gmu_set_freq(gmu, perf_index);
> + if (gmu->legacy)
> + __a6xx_gmu_set_freq(gmu, perf_index);
> + else
> + a6xx_hfi_set_freq(gmu, perf_index);
Welcome to the first great GMU schism. There are going to be a lot of these if()
statements and my guess is that it won't get any cleaner in the future.
The best option in my opinion would be to make two separate GMU implementations
and select the probe either from the gpu list or the compatible string and use
function pointers for the functions that are called from a6xx_gpu.c and
a6xx_gpu_state.c.
We _could_ make the gmu->legacy thing work but if someday there is a another
schism we would be sad that we didn't do the ground work now.
We could also do the same for HFI, but I think there is a bit less of a delta
there and there isn't a harm in having a _v1 function or two laying around.
> +
> + gmu->freq = gmu->gpu_freqs[perf_index];
> }
>
> unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
> @@ -231,19 +234,26 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
> a6xx_gmu_oob_state state)
>
> switch (state) {
> case GMU_OOB_GPU_SET:
> - request = GMU_OOB_GPU_SET_REQUEST;
> - ack = GMU_OOB_GPU_SET_ACK;
> + if (gmu->legacy) {
> + request = GMU_OOB_GPU_SET_REQUEST;
> + ack = GMU_OOB_GPU_SET_ACK;
> + } else {
> + request = GMU_OOB_GPU_SET_REQUEST_NEW;
> + ack = GMU_OOB_GPU_SET_ACK_NEW;
> + }
> name = "GPU_SET";
> break;
> case GMU_OOB_BOOT_SLUMBER:
> request = GMU_OOB_BOOT_SLUMBER_REQUEST;
> ack = GMU_OOB_BOOT_SLUMBER_ACK;
> name = "BOOT_SLUMBER";
> + WARN_ON(!gmu->legacy);
This is unlikely to be the case - these should only be called from within the
GMU code and we should be able to control it.
> break;
> case GMU_OOB_DCVS_SET:
> request = GMU_OOB_DCVS_REQUEST;
> ack = GMU_OOB_DCVS_ACK;
> name = "GPU_DCVS";
> + WARN_ON(!gmu->legacy);
Same.
> break;
> default:
> return -EINVAL;
> @@ -271,6 +281,13 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
> a6xx_gmu_oob_state state)
> /* Clear a pending OOB state in the GMU */
> void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
> {
> + if (!gmu->legacy) {
> + WARN_ON(state != GMU_OOB_GPU_SET);
> + gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
> + 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
> + return;
> + }
A good example of the usefulness of per-implementation functions.
> +
> switch (state) {
> case GMU_OOB_GPU_SET:
> gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
> @@ -293,6 +310,9 @@ static int a6xx_sptprac_enable(struct a6xx_gmu *gmu)
> int ret;
> u32 val;
>
> + if (!gmu->legacy)
> + return 0;
> +
> gmu_write(gmu, REG_A6XX_GMU_GX_SPTPRAC_POWER_CONTROL, 0x778000);
>
> ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS, val,
> @@ -312,6 +332,9 @@ static void a6xx_sptprac_disable(struct a6xx_gmu *gmu)
> u32 val;
> int ret;
>
> + if (!gmu->legacy)
> + return;
> +
> /* Make sure retention is on */
> gmu_rmw(gmu, REG_A6XX_GPU_CC_GX_GDSCR, 0, (1 << 11));
>
> @@ -355,6 +378,11 @@ static int a6xx_gmu_notify_slumber(struct a6xx_gmu *gmu)
> if (gmu->idle_level < GMU_IDLE_STATE_SPTP)
> a6xx_sptprac_disable(gmu);
>
> + if (!gmu->legacy) {
> + ret = a6xx_hfi_send_prep_slumber
[PATCH v6 6/6] drm/meson: crtc: handle commit of Amlogic FBC frames
Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 118 +
1 file changed, 88 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index e66b6271ff58..2854272dc2d9 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -291,6 +291,10 @@ static void meson_crtc_enable_vd1(struct meson_drm *priv)
VPP_VD1_PREBLEND | VPP_VD1_POSTBLEND |
VPP_COLOR_MNG_ENABLE,
priv->io_base + _REG(VPP_MISC));
+
+ writel_bits_relaxed(VIU_CTRL0_AFBC_TO_VD1,
+ priv->viu.vd1_afbc ? VIU_CTRL0_AFBC_TO_VD1 : 0,
+ priv->io_base + _REG(VIU_MISC_CTRL0));
}
static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
@@ -300,6 +304,10 @@ static void meson_g12a_crtc_enable_vd1(struct meson_drm
*priv)
VD_BLEND_POSTBLD_SRC_VD1 |
VD_BLEND_POSTBLD_PREMULT_EN,
priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+
+ writel_relaxed(priv->viu.vd1_afbc ?
+ (VD1_AXI_SEL_AFBC | AFBC_VD1_SEL) : 0,
+ priv->io_base + _REG(VD1_AFBCD0_MISC_CTRL));
}
void meson_crtc_irq(struct meson_drm *priv)
@@ -383,36 +391,86 @@ void meson_crtc_irq(struct meson_drm *priv)
/* Update the VD1 registers */
if (priv->viu.vd1_enabled && priv->viu.vd1_commit) {
- switch (priv->viu.vd1_planes) {
- case 3:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_2,
- priv->viu.vd1_addr2,
- priv->viu.vd1_stride2,
- priv->viu.vd1_height2,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 2:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_1,
- priv->viu.vd1_addr1,
- priv->viu.vd1_stride1,
- priv->viu.vd1_height1,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 1:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_0,
- priv->viu.vd1_addr0,
- priv->viu.vd1_stride0,
- priv->viu.vd1_height0,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
+ if (priv->viu.vd1_afbc) {
+ writel_relaxed(priv->viu.vd1_afbc_head_addr,
+ priv->io_base +
+ _REG(AFBC_HEAD_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_body_addr,
+ priv->io_base +
+ _REG(AFBC_BODY_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_en,
+ priv->io_base +
+ _REG(AFBC_ENABLE));
+ writel_relaxed(priv->viu.vd1_afbc_mode,
+ priv->io_base +
+ _REG(AFBC_MODE));
+ writel_relaxed(priv->viu.vd1_afbc_size_in,
+ priv->io_base +
+ _REG(AFBC_SIZE_IN));
+ writel_relaxed(priv->viu.vd1_afbc_dec_def_color,
+ priv->io_base +
+ _REG(AFBC_DEC_DEF_COLOR));
+ writel_relaxed(priv->viu.vd1_afbc_conv_ctrl,
+ priv->io_base +
+ _REG(AFBC_CONV_CTRL));
+ writel_relaxed(priv->viu.vd1_afbc_size_out,
+ priv->io_base +
+ _REG(AFB
[PATCH v6 4/6] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 2713d008cee8..b5c502876428 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,10 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC(0,
+ AMLOGIC_FBC_OPTION_MEM_SAVING))
+ priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -672,12 +676,17 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
unsigned long body_size;
- /* Default mode is 4k per superblock */
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
(ALIGN(priv->viu.vd1_height0, 32) / 32) *
- 4096;
+ block_size;
priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
@@ -735,6 +744,9 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
unsigned int layout = modifier &
DRM_FORMAT_MOD_AMLOGIC_FBC(
__fourcc_mod_amlogic_layout_mask, 0);
+ unsigned int options =
+ (modifier >> __fourcc_mod_amlogic_options_shift) &
+ __fourcc_mod_amlogic_options_mask;
if (format != DRM_FORMAT_YUV420_8BIT &&
format != DRM_FORMAT_YUV420_10BIT) {
@@ -749,6 +761,13 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
return false;
}
+ if (options &&
+ options != AMLOGIC_FBC_OPTION_MEM_SAVING) {
+ DRM_DEBUG_KMS("%llx invalid layout %x\n",
+ modifier, layout);
+ return false;
+ }
+
return true;
}
@@ -782,6 +801,8 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC,
+ AMLOGIC_FBC_OPTION_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC, 0),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.
This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
superblock in default mode.
- a 32 bytes per 128x64 header block
This layout is tranferrable between Amlogic SoCs supporting this modifier.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 74 +++
1 file changed, 74 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..b7596ba2af30 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -309,6 +309,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
/* add more to the end as needed */
@@ -804,6 +805,79 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
+/*
+ * Amlogic Video Framebuffer Compression modifiers
+ *
+ * Amlogic uses a proprietary lossless image compression protocol and format
+ * for their hardware video codec accelerators, either video decoders or
+ * video input encoders.
+ *
+ * It considerably reduces memory bandwidth while writing and reading
+ * frames in memory.
+ *
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
+ * per component YCbCr 420, single plane :
+ * - DRM_FORMAT_YUV420_8BIT
+ * - DRM_FORMAT_YUV420_10BIT
+ *
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
+ * defines the options changing the layout.
+ *
+ * Not all combinations are valid, and different SoCs may support different
+ * combinations of layout and options.
+ */
+#define __fourcc_mod_amlogic_layout_mask 0xf
+#define __fourcc_mod_amlogic_options_shift 8
+#define __fourcc_mod_amlogic_options_mask 0xf
+
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
+ fourcc_mod_code(AMLOGIC, \
+ ((__layout) & __fourcc_mod_amlogic_layout_mask) | \
+ ((__options) & __fourcc_mod_amlogic_options_mask \
+<< __fourcc_mod_amlogic_options_shift))
+
+/* Amlogic FBC Layouts */
+
+/*
+ * Amlogic FBC Basic Layout
+ *
+ * The basic layout is composed of:
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
+ * superblock in default mode.
+ * - a 32 bytes per 128x64 header block
+ *
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
+ */
+#define AMLOGIC_FBC_LAYOUT_BASIC (1ULL)
+
+/*
+ * Amlogic FBC Scatter Memory layout
+ *
+ * Indicates the header contains IOMMU references to the compressed
+ * frames content to optimize memory access and layout.
+ *
+ * In this mode, only the header memory address is needed, thus the
+ * content memory organization is tied to the current producer
+ * execution and cannot be saved/dumped neither transferrable between
+ * Amlogic SoCs supporting this modifier.
+ */
+#define AMLOGIC_FBC_LAYOUT_SCATTER (2ULL)
+
+/* Amlogic FBC Layout Options Bit Mask */
+
+/*
+ * Amlogic FBC Memory Saving mode
+ *
+ * Indicates the storage is packed when pixel size is multiple of word
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
+ * memory.
+ *
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
+ * the scatter layout.
+ */
+#define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 8/8] drm: bridge: dw-mipi-dsi: fix bad register field offsets
According to the DSI Host Registers sections available in the IMX,
STM and RK ref manuals for 1.01, 1.30 and 1.31, the register fields
are smaller or bigger than what's coded in the driver, leading to
r/w in reserved spaces which might cause undefined behaviours.
Tested-by: Adrian Pop
Tested-by: Arnaud Ferraris
Signed-off-by: Adrian Ratiu
---
New in v6.
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 46 +--
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index b45a6d19addcc..b6fef4062a0a8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -316,7 +316,7 @@ struct dw_mipi_dsi_variant {
static const struct dw_mipi_dsi_variant dw_mipi_dsi_v130_v131_layout = {
.cfg_dpi_color_coding = REG_FIELD(DSI_DPI_COLOR_CODING, 0, 3),
.cfg_dpi_18loosely_en = REG_FIELD(DSI_DPI_COLOR_CODING, 8, 8),
- .cfg_dpi_vid = REG_FIELD(DSI_DPI_VCID, 0, 2),
+ .cfg_dpi_vid = REG_FIELD(DSI_DPI_VCID, 0, 1),
.cfg_dpi_vsync_active_low = REG_FIELD(DSI_DPI_CFG_POL, 1, 1),
.cfg_dpi_hsync_active_low = REG_FIELD(DSI_DPI_CFG_POL, 2, 2),
.cfg_cmd_mode_ack_rqst_en = REG_FIELD(DSI_CMD_MODE_CFG, 1, 1),
@@ -325,29 +325,29 @@ static const struct dw_mipi_dsi_variant
dw_mipi_dsi_v130_v131_layout = {
.cfg_cmd_mode_dcs_sw_sr_en =REG_FIELD(DSI_CMD_MODE_CFG, 16, 18),
.cfg_cmd_mode_dcs_lw_en = REG_FIELD(DSI_CMD_MODE_CFG, 19, 19),
.cfg_cmd_mode_max_rd_pkt_size = REG_FIELD(DSI_CMD_MODE_CFG, 24, 24),
- .cfg_cmd_mode_en = REG_FIELD(DSI_MODE_CFG, 0, 31),
- .cfg_cmd_pkt_status = REG_FIELD(DSI_CMD_PKT_STATUS, 0, 31),
- .cfg_vid_mode_en = REG_FIELD(DSI_MODE_CFG, 0, 31),
+ .cfg_cmd_mode_en = REG_FIELD(DSI_MODE_CFG, 0, 0),
+ .cfg_cmd_pkt_status = REG_FIELD(DSI_CMD_PKT_STATUS, 0, 6),
+ .cfg_vid_mode_en = REG_FIELD(DSI_MODE_CFG, 0, 0),
.cfg_vid_mode_type =REG_FIELD(DSI_VID_MODE_CFG, 0, 1),
.cfg_vid_mode_low_power = REG_FIELD(DSI_VID_MODE_CFG, 8, 13),
.cfg_vid_mode_vpg_en = REG_FIELD(DSI_VID_MODE_CFG, 16, 16),
.cfg_vid_mode_vpg_horiz = REG_FIELD(DSI_VID_MODE_CFG, 24, 24),
- .cfg_vid_pkt_size = REG_FIELD(DSI_VID_PKT_SIZE, 0, 10),
- .cfg_vid_hsa_time = REG_FIELD(DSI_VID_HSA_TIME, 0, 31),
- .cfg_vid_hbp_time = REG_FIELD(DSI_VID_HBP_TIME, 0, 31),
- .cfg_vid_hline_time = REG_FIELD(DSI_VID_HLINE_TIME, 0, 31),
- .cfg_vid_vsa_time = REG_FIELD(DSI_VID_VSA_LINES, 0, 31),
- .cfg_vid_vbp_time = REG_FIELD(DSI_VID_VBP_LINES, 0, 31),
- .cfg_vid_vfp_time = REG_FIELD(DSI_VID_VFP_LINES, 0, 31),
- .cfg_vid_vactive_time = REG_FIELD(DSI_VID_VACTIVE_LINES, 0, 31),
+ .cfg_vid_pkt_size = REG_FIELD(DSI_VID_PKT_SIZE, 0, 13),
+ .cfg_vid_hsa_time = REG_FIELD(DSI_VID_HSA_TIME, 0, 11),
+ .cfg_vid_hbp_time = REG_FIELD(DSI_VID_HBP_TIME, 0, 11),
+ .cfg_vid_hline_time = REG_FIELD(DSI_VID_HLINE_TIME, 0, 14),
+ .cfg_vid_vsa_time = REG_FIELD(DSI_VID_VSA_LINES, 0, 9),
+ .cfg_vid_vbp_time = REG_FIELD(DSI_VID_VBP_LINES, 0, 9),
+ .cfg_vid_vfp_time = REG_FIELD(DSI_VID_VFP_LINES, 0, 9),
+ .cfg_vid_vactive_time = REG_FIELD(DSI_VID_VACTIVE_LINES, 0, 13),
.cfg_phy_txrequestclkhs = REG_FIELD(DSI_LPCLK_CTRL, 0, 0),
- .cfg_phy_bta_time = REG_FIELD(DSI_BTA_TO_CNT, 0, 31),
- .cfg_phy_max_rd_time = REG_FIELD(DSI_PHY_TMR_CFG, 0, 15),
+ .cfg_phy_bta_time = REG_FIELD(DSI_BTA_TO_CNT, 0, 15),
+ .cfg_phy_max_rd_time = REG_FIELD(DSI_PHY_TMR_CFG, 0, 14),
.cfg_phy_lp2hs_time = REG_FIELD(DSI_PHY_TMR_CFG, 16, 23),
.cfg_phy_hs2lp_time = REG_FIELD(DSI_PHY_TMR_CFG, 24, 31),
- .cfg_phy_max_rd_time_v131 = REG_FIELD(DSI_PHY_TMR_RD_CFG, 0, 15),
- .cfg_phy_lp2hs_time_v131 = REG_FIELD(DSI_PHY_TMR_CFG, 0, 15),
- .cfg_phy_hs2lp_time_v131 = REG_FIELD(DSI_PHY_TMR_CFG, 16, 31),
+ .cfg_phy_max_rd_time_v131 = REG_FIELD(DSI_PHY_TMR_RD_CFG, 0, 14),
+ .cfg_phy_lp2hs_time_v131 = REG_FIELD(DSI_PHY_TMR_CFG, 0, 9),
+ .cfg_phy_hs2lp_time_v131 = REG_FIELD(DSI_PHY_TMR_CFG, 16, 25),
.cfg_phy_clklp2hs_time =REG_FIELD(DSI_PHY_TMR_LPCLK_CFG, 0, 15),
.cfg_phy_clkhs2lp_time =REG_FIELD(DSI_PHY_TMR_LPCLK_CFG, 16,
31),
.cfg_phy_testclr = REG_FIELD(DSI_PHY_TST_CTRL0, 0, 0),
@@ -361,11 +361,11 @@ static const struct dw_mipi_dsi_variant
dw_mipi_dsi_v130_v131_
[PATCH v6 5/6] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 53 ++-
1 file changed, 35 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index b5c502876428..6aef28767fc1 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -491,6 +491,10 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AMLOGIC_FBC_OPTION_MEM_SAVING))
priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+ if ((fb->modifier & __fourcc_mod_amlogic_layout_mask) ==
+ AMLOGIC_FBC_LAYOUT_SCATTER)
+ priv->viu.vd1_afbc_mode |= AFBC_SCATTER_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -676,23 +680,32 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
- /* Default mode is 4k per superblock */
- unsigned long block_size = 4096;
- unsigned long body_size;
-
- /* 8bit mem saving mode is 3072bytes per superblock */
- if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
- block_size = 3072;
-
- body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
- (ALIGN(priv->viu.vd1_height0, 32) / 32) *
- block_size;
-
- priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
-
- /* Header is after body content */
- priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
- body_size) >> 4;
+ if (priv->viu.vd1_afbc_mode & AFBC_SCATTER_MODE) {
+ /*
+* In Scatter mode, the header contains the physical
+* body content layout, thus the body content
+* size isn't needed.
+*/
+ priv->viu.vd1_afbc_head_addr = priv->viu.vd1_addr0 >> 4;
+ priv->viu.vd1_afbc_body_addr = 0;
+ } else {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
+ unsigned long body_size;
+
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
+ body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+ (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+ block_size;
+
+ priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+ /* Header is after body content */
+ priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+ body_size) >> 4;
+ }
}
priv->viu.vd1_enabled = true;
@@ -755,7 +768,8 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
return false;
}
- if (layout != AMLOGIC_FBC_LAYOUT_BASIC) {
+ if (layout != AMLOGIC_FBC_LAYOUT_BASIC &&
+ layout != AMLOGIC_FBC_LAYOUT_SCATTER) {
DRM_DEBUG_KMS("%llx invalid layout %x\n",
modifier, layout);
return false;
@@ -801,8 +815,11 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_SCATTER,
+ AMLOGIC_FBC_OPTION_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC,
AMLOGIC_FBC_OPTION_MEM_SAVING),
+ DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_SCATTER, 0),
DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC, 0),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 7/8] drm: bridge: dw-mipi-dsi: split low power cfg register into fields
According to the Host Registers documentation for IMX, STM and RK
the LP cfg register should not be written entirely in one go because
some bits are reserved and should be kept to reset values, for eg.
BIT(15) which is reserved in all versions.
This also cleans up the code by removing the the ugly defines
and making field ranges & values written more explicit.
Tested-by: Adrian Pop
Tested-by: Arnaud Ferraris
Signed-off-by: Adrian Ratiu
---
New in v6.
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 105 ++
1 file changed, 33 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index f7e71fa5a8c64..b45a6d19addcc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -120,60 +120,6 @@
#define DSI_TO_CNT_CFG_V1010x40
#define DSI_PCKHDL_CFG_V1010x18
-#define MAX_RD_PKT_SIZE_LP BIT(24)
-#define DCS_LW_TX_LP BIT(19)
-#define DCS_SR_0P_TX_LPBIT(18)
-#define DCS_SW_1P_TX_LPBIT(17)
-#define DCS_SW_0P_TX_LPBIT(16)
-#define GEN_LW_TX_LP BIT(14)
-#define GEN_SR_2P_TX_LPBIT(13)
-#define GEN_SR_1P_TX_LPBIT(12)
-#define GEN_SR_0P_TX_LPBIT(11)
-#define GEN_SW_2P_TX_LPBIT(10)
-#define GEN_SW_1P_TX_LPBIT(9)
-#define GEN_SW_0P_TX_LPBIT(8)
-#define TEAR_FX_EN BIT(0)
-
-#define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \
-DCS_LW_TX_LP | \
-DCS_SR_0P_TX_LP | \
-DCS_SW_1P_TX_LP | \
-DCS_SW_0P_TX_LP | \
-GEN_LW_TX_LP | \
-GEN_SR_2P_TX_LP | \
-GEN_SR_1P_TX_LP | \
-GEN_SR_0P_TX_LP | \
-GEN_SW_2P_TX_LP | \
-GEN_SW_1P_TX_LP | \
-GEN_SW_0P_TX_LP)
-
-#define EN_TEAR_FX_V101BIT(14)
-#define DCS_LW_TX_LP_V101 BIT(12)
-#define GEN_LW_TX_LP_V101 BIT(11)
-#define MAX_RD_PKT_SIZE_LP_V101BIT(10)
-#define DCS_SW_2P_TX_LP_V101 BIT(9)
-#define DCS_SW_1P_TX_LP_V101 BIT(8)
-#define DCS_SW_0P_TX_LP_V101 BIT(7)
-#define GEN_SR_2P_TX_LP_V101 BIT(6)
-#define GEN_SR_1P_TX_LP_V101 BIT(5)
-#define GEN_SR_0P_TX_LP_V101 BIT(4)
-#define GEN_SW_2P_TX_LP_V101 BIT(3)
-#define GEN_SW_1P_TX_LP_V101 BIT(2)
-#define GEN_SW_0P_TX_LP_V101 BIT(1)
-
-#define CMD_MODE_ALL_LP_V101 (DCS_LW_TX_LP_V101 | \
-GEN_LW_TX_LP_V101 | \
-MAX_RD_PKT_SIZE_LP_V101 | \
-DCS_SW_2P_TX_LP_V101 | \
-DCS_SW_1P_TX_LP_V101 | \
-DCS_SW_0P_TX_LP_V101 | \
-GEN_SR_2P_TX_LP_V101 | \
-GEN_SR_1P_TX_LP_V101 | \
-GEN_SR_0P_TX_LP_V101 | \
-GEN_SW_2P_TX_LP_V101 | \
-GEN_SW_1P_TX_LP_V101 | \
-GEN_SW_0P_TX_LP_V101)
-
#define DSI_GEN_HDR0x6c
#define DSI_GEN_PLD_DATA 0x70
@@ -257,7 +203,11 @@ struct dw_mipi_dsi {
struct regmap_field *field_dpi_vsync_active_low;
struct regmap_field *field_dpi_hsync_active_low;
struct regmap_field *field_cmd_mode_ack_rqst_en;
- struct regmap_field *field_cmd_mode_all_lp_en;
+ struct regmap_field *field_cmd_mode_gen_sw_sr_en;
+ struct regmap_field *field_cmd_mode_dcs_sw_sr_en;
+ struct regmap_field *field_cmd_mode_gen_lw_en;
+ struct regmap_field *field_cmd_mode_dcs_lw_en;
+ struct regmap_field *field_cmd_mode_max_rd_pkt_size;
struct regmap_field *field_cmd_mode_en;
struct regmap_field *field_cmd_pkt_status;
struct regmap_field *field_vid_mode_en;
@@ -315,7 +265,11 @@ struct dw_mipi_dsi_variant {
struct reg_fieldcfg_dpi_hsync_active_low;
struct reg_fieldcfg_cmd_mode_en;
struct reg_fieldcfg_cmd_mode_ack_rqst_en;
- struct reg_fieldcfg_cmd_mode_all_lp_en;
+ struct reg_fieldcfg_cmd_mode_gen_sw_sr_en;
+ struct reg_f
