[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5dr5ps4vb57xj2mfelgsxgoyrr3gg4ggwqggqchff6pda3ffsn@thxpg4h6kgel>
Date: Wed, 19 Feb 2025 00:02:06 +0100
From: Andi Shyti <andi.shyti@...nel.org>
To: Stephan Gerhold <stephan.gerhold@...nkonzept.com>
Cc: Wolfram Sang <wsa@...nel.org>, Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>,
Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org, linux-i2c@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] i2c: qup: Vote for interconnect bandwidth to DRAM
Hi Stephen,
sorry for the very late reply here. Just one question.
...
> downstream/vendor driver [1]. Due to lack of documentation about the
> interconnect setup/behavior I cannot say exactly if this is right.
> Unfortunately, this is not implemented very consistently downstream...
Can we have someone from Qualcomm or Linaro taking a peak here?
> [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/commit/67174e2624ea64814231e7e1e4af83fd882302c6
...
> @@ -1745,6 +1775,11 @@ static int qup_i2c_probe(struct platform_device *pdev)
> goto fail_dma;
> }
> qup->is_dma = true;
> +
> + qup->icc_path = devm_of_icc_get(&pdev->dev, NULL);
> + if (IS_ERR(qup->icc_path))
> + return dev_err_probe(&pdev->dev, PTR_ERR(qup->icc_path),
> + "failed to get interconnect path\n");
Can we live without it if it fails?
Thanks,
Andi
Powered by blists - more mailing lists