On 26.09.2023 01:26, Richard Acayan wrote:
> The Snapdragon 670 uses similar clocks (with one frequency added) to the
> Snapdragon 845 but reports DPU revision 4.1. Add support for this DPU
> with configuration from the Pixel 3a downstream kernel.
>
> Since revision 4.0 is SDM845, reuse some confi
On 26.09.2023 21:10, Danila Tikhonov wrote:
>
> I think you mean by name downstream dt - sdmmagpie-gpu.dtsi
>
> You can see the forked version of the mainline here:
> https://github.com/sm7150-mainline/linux/blob/next/arch/arm64/boot/dts/qcom/sm7150.dtsi
>
> All fdt that we got here, if it is us
I think you mean by name downstream dt - sdmmagpie-gpu.dtsi
You can see the forked version of the mainline here:
https://github.com/sm7150-mainline/linux/blob/next/arch/arm64/boot/dts/qcom/sm7150.dtsi
All fdt that we got here, if it is useful for you:
https://github.com/sm7150-mainline/downstrea
On 26.09.2023 19:42, Danila Tikhonov wrote:
> SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
> 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
> to zero decimal places.
>
> Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn).
>
> Add t
On 26.09.2023 20:24, Konrad Dybcio wrote:
> Non-Chrome SC7280-family platforms ship a ZAP shader with the Adreno GPU.
> Describe that and make sure it doesn't interfere with Chrome devices.
>
> Signed-off-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 2 ++
> arc
On 26.09.2023 20:24, Konrad Dybcio wrote:
> The SMMUs on sc7280 are cache-coherent. APPS_SMMU is marked as such,
> mark the GPU one as well.
>
> Signed-off-by: Konrad Dybcio
> ---
Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Sorry.
Konrad
A643 (A635 speedbin 0xac) tops out at 812 MHz. Fill in the
opp-supported-hw appropriately.
Note that fuseval 0xac is referred to as speedbin 1 downstream, but
that was already in use upstream, so 2 was chosen instead.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 12 ++
The SMMUs on sc7280 are cache-coherent. APPS_SMMU is marked as such,
mark the GPU one as well.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
in
GPU_SMMU SID 1 is meant for Adreno LPAC (Low Priority Async Compute).
On platforms that support it (in firmware), it is necessary to
describe that link, or Adreno register access will hang the board.
Add that and fix up the SMR mask of SID 0, which seems to have been
copypasted from another SoC.
Non-Chrome SC7280-family platforms ship a ZAP shader with the Adreno GPU.
Describe that and make sure it doesn't interfere with Chrome devices.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 2 ++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 10 +++
When opp-supported-hw is present under an OPP node, but no form of
opp_set_supported_hw() has been called, that OPP is ignored by the API
and marked as unsupported.
Before Commit c928a05e4415 ("drm/msm/adreno: Move speedbin mapping to
device table"), an unknown speedbin would result in marking all
Downstream calls this the "speedbin 1", but that number is already
occupied. Use index two.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adr
Some (many?) devices with A635 expect a ZAP shader to be loaded.
Set the file name to allow for that.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm
files changed, 24 insertions(+), 8 deletions(-)
---
base-commit: 4ae73bba62a367f2314f6ce69e3085a941983d8b
change-id: 20230926-topic-a643-a7ec9a08a3a1
Best regards,
--
Konrad Dybcio
This patch adds support for SM7150 SoC machine.
Changes in v2:
- Use a630_gmu.bin instead of a618_gmu.bin.
- Use squashed version of a615_zap (.mbn).
- Drop .revn.
- Link to v1:
https://lore.kernel.org/all/20230913191957.26537-1-dan...@jiaxyga.com/
Danila Tikhonov (1):
drm/msm/adreno: Add suppo
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
to zero decimal places.
Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn).
Add this as machine = "qcom,sm7150", because speed-bin values a
On 2023-08-28 20:05, Jessica Zhang wrote:
> Some drivers support hardware that have optimizations for solid fill
> planes. This series aims to expose these capabilities to userspace as
> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> hardware composer HAL) that can be
On Mon, Sep 25, 2023 at 04:24:25PM -0500, Rob Herring wrote:
> Make it explicit that child nodes have additional properties and the
> child node schema is not complete. The complete schemas are applied
> separately based the compatible strings.
>
> Signed-off-by: Rob Herring
I cross-checked only
On Mon, Sep 25, 2023 at 04:24:24PM -0500, Rob Herring wrote:
> Just as unevaluatedProperties or additionalProperties are required at
> the top level of schemas, they should (and will) also be required for
> child node schemas. That ensures only documented properties are
> present for any node.
>
>
: 8fff9184d1b5810dca5dd1a02726d4f844af88fc
patch link:
https://lore.kernel.org/r/20230628-topic-a7xx_drmmsm-v5-7-3dc527b472d7%40linaro.org
patch subject: [PATCH v5 07/10] drm/msm/a6xx: Mostly implement A7xx gpu_state
config: sparc-allyesconfig
(https://download.01.org/0day-ci/archive/20230926/202309261932
On Tue, 12 Sept 2023 at 01:18, Abhinav Kumar wrote:
>
> Currently, dpu_plane_atomic_check() does not check whether the
> plane can process the image without exceeding the per chipset
> limits for MDP clock. This leads to underflow issues because the
> SSPP is not able to complete the processing fo
On Tue, 12 Sept 2023 at 01:16, Abhinav Kumar wrote:
>
> It's certainly possible that for large resolutions a single DPU SSPP
> cannot process the image without exceeding the MDP clock limits but
> it can still process it in multirect mode because the source rectangles
> will get divided and can fa
22 matches
Mail list logo
