Re: [PATCH 6/7] crypto: qce: common: Add support for AEAD algorithms
On Tue 13 Apr 17:44 CDT 2021, Thara Gopinath wrote:
>
>
> On 4/13/21 6:20 PM, Bjorn Andersson wrote:
> > On Tue 13 Apr 16:31 CDT 2021, Thara Gopinath wrote:
> >
> > >
> > > Hi Bjorn,
> > >
> > > On 4/5/21 6:18 PM, Bjorn Andersson wrote:
> > > > On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> > > >
> > > > > Add register programming sequence for enabling AEAD
> > > > > algorithms on the Qualcomm crypto engine.
> > > > >
> > > > > Signed-off-by: Thara Gopinath
> > > > > ---
> > > > >drivers/crypto/qce/common.c | 155
> > > > > +++-
> > > > >1 file changed, 153 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> > > > > index 05a71c5ecf61..54d209cb0525 100644
> > > > > --- a/drivers/crypto/qce/common.c
> > > > > +++ b/drivers/crypto/qce/common.c
> > > > > @@ -15,6 +15,16 @@
> > > > >#include "core.h"
> > > > >#include "regs-v5.h"
> > > > >#include "sha.h"
> > > > > +#include "aead.h"
> > > > > +
> > > > > +static const u32 std_iv_sha1[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> > > > > + SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4, 0, 0, 0
> > > > > +};
> > > > > +
> > > > > +static const u32 std_iv_sha256[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> > > > > + SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
> > > > > + SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7
> > > > > +};
> > > > >static inline u32 qce_read(struct qce_device *qce, u32 offset)
> > > > >{
> > > > > @@ -96,7 +106,7 @@ static inline void qce_crypto_go(struct qce_device
> > > > > *qce, bool result_dump)
> > > > > qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
> > > > >}
> > > > > -#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> > > > > +#if defined(CONFIG_CRYPTO_DEV_QCE_SHA) ||
> > > > > defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> > > > >static u32 qce_auth_cfg(unsigned long flags, u32 key_size, u32
> > > > > auth_size)
> > > > >{
> > > > > u32 cfg = 0;
> > > > > @@ -139,7 +149,9 @@ static u32 qce_auth_cfg(unsigned long flags, u32
> > > > > key_size, u32 auth_size)
> > > > > return cfg;
> > > > >}
> > > > > +#endif
> > > > > +#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> > > > >static int qce_setup_regs_ahash(struct crypto_async_request
> > > > > *async_req)
> > > > >{
> > > > > struct ahash_request *req = ahash_request_cast(async_req);
> > > > > @@ -225,7 +237,7 @@ static int qce_setup_regs_ahash(struct
> > > > > crypto_async_request *async_req)
> > > > >}
> > > > >#endif
> > > > > -#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> > > > > +#if defined(CONFIG_CRYPTO_DEV_QCE_SKCIPHER) ||
> > > > > defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> > > > >static u32 qce_encr_cfg(unsigned long flags, u32 aes_key_size)
> > > > >{
> > > > > u32 cfg = 0;
> > > > > @@ -271,7 +283,9 @@ static u32 qce_encr_cfg(unsigned long flags, u32
> > > > > aes_key_size)
> > > > > return cfg;
> > > > >}
> > > > > +#endif
> > > > > +#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> > > > >static void qce_xts_swapiv(__be32 *dst, const u8 *src, unsigned
> > > > > int ivsize)
> > > > >{
> > > > > u8 swap[QCE_AES_IV_LENGTH];
> > > > > @@ -386,6 +400,139 @@ static int qce_setup_regs_skcipher(struct
> > > > > crypto_async_request *async_req)
> > > > >}
> > > > >#endif
> > > > > +#ifdef CONFIG_CRYPTO_DEV_QCE_AEAD
> > > > > +static int qce_setup_regs_aead(struct crypto_async_request
> > > > > *async_req)
> > > > > +{
> > > > > + struct aead_request *req = aead_request_cast(async_req);
> > > > > + struct qce_aead_reqctx *rctx = aead_request_ctx(req);
> >
Re: [PATCH v2 1/2] arm64: dts: qcom: Add "dmic_clk_en" for sc7180-trogdor-coachz
On Mon 12 Apr 18:16 CDT 2021, Doug Anderson wrote:
> Bjorn,
>
> On Mon, Mar 15, 2021 at 1:39 PM Douglas Anderson
> wrote:
> >
> > This was present downstream. Add upstream too. NOTE: upstream I
> > managed to get some sort of halfway state and got one pinctrl entry in
> > the coachz-r1 device tree. Remove that as part of this since it's now
> > in the dtsi.
> >
> > Cc: Srinivasa Rao Mandadapu
> > Cc: Ajit Pandey
> > Cc: Judy Hsiao
> > Cc: Cheng-Yi Chiang
> > Cc: Stephen Boyd
> > Cc: Matthias Kaehlcke
> > Signed-off-by: Douglas Anderson
> > ---
> > This applies atop the patch ("arm64: dts: qcom: Add sound node for
> > sc7180-trogdor-coachz") [1].
> >
> > NOTE: downstream this property was present in each of the board
> > revisions. There's actually no longer any reason for this and I'll
> > shortly post a downstream patch to fix this.
> >
> > [1]
> > https://lore.kernel.org/r/20210313054654.11693-3-sriva...@codeaurora.org/
> >
> > Changes in v2:
> > - Remove the pinctrl from the -r1
> >
> > .../boot/dts/qcom/sc7180-trogdor-coachz-r1.dts | 13 -
> > .../boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 16
> > 2 files changed, 16 insertions(+), 13 deletions(-)
>
> I guess this patch missed the boat for 5.13? Can it get queued up for
> 5.14 whenever that happens?
>
Meh, I scraped the inbox and thought I got everything that was ready
picked up. I'll check with Arnd, otherwise it's staged for v5.14 now.
Regards,
Bjorn
Re: [PATCH 6/7] crypto: qce: common: Add support for AEAD algorithms
On Tue 13 Apr 17:27 CDT 2021, Thara Gopinath wrote:
>
>
> On 4/5/21 6:18 PM, Bjorn Andersson wrote:
> > On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> >
> > > Add register programming sequence for enabling AEAD
> > > algorithms on the Qualcomm crypto engine.
> > >
> > > Signed-off-by: Thara Gopinath
> > > ---
> > > drivers/crypto/qce/common.c | 155 +++-
> > > 1 file changed, 153 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> > > index 05a71c5ecf61..54d209cb0525 100644
> > > --- a/drivers/crypto/qce/common.c
> > > +++ b/drivers/crypto/qce/common.c
> > > @@ -15,6 +15,16 @@
> > > #include "core.h"
> > > #include "regs-v5.h"
> > > #include "sha.h"
> > > +#include "aead.h"
> > > +
> > > +static const u32 std_iv_sha1[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> > > + SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4, 0, 0, 0
> > > +};
> > > +
> > > +static const u32 std_iv_sha256[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> > > + SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
> > > + SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7
> > > +};
> > > static inline u32 qce_read(struct qce_device *qce, u32 offset)
> > > {
> > > @@ -96,7 +106,7 @@ static inline void qce_crypto_go(struct qce_device
> > > *qce, bool result_dump)
> > > qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
> > > }
> > > -#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> > > +#if defined(CONFIG_CRYPTO_DEV_QCE_SHA) ||
> > > defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> > > static u32 qce_auth_cfg(unsigned long flags, u32 key_size, u32
> > > auth_size)
> > > {
> > > u32 cfg = 0;
> > > @@ -139,7 +149,9 @@ static u32 qce_auth_cfg(unsigned long flags, u32
> > > key_size, u32 auth_size)
> > > return cfg;
> > > }
> > > +#endif
> > > +#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> > > static int qce_setup_regs_ahash(struct crypto_async_request *async_req)
> > > {
> > > struct ahash_request *req = ahash_request_cast(async_req);
> > > @@ -225,7 +237,7 @@ static int qce_setup_regs_ahash(struct
> > > crypto_async_request *async_req)
> > > }
> > > #endif
> > > -#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> > > +#if defined(CONFIG_CRYPTO_DEV_QCE_SKCIPHER) ||
> > > defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> > > static u32 qce_encr_cfg(unsigned long flags, u32 aes_key_size)
> > > {
> > > u32 cfg = 0;
> > > @@ -271,7 +283,9 @@ static u32 qce_encr_cfg(unsigned long flags, u32
> > > aes_key_size)
> > > return cfg;
> > > }
> > > +#endif
> > > +#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> > > static void qce_xts_swapiv(__be32 *dst, const u8 *src, unsigned int
> > > ivsize)
> > > {
> > > u8 swap[QCE_AES_IV_LENGTH];
> > > @@ -386,6 +400,139 @@ static int qce_setup_regs_skcipher(struct
> > > crypto_async_request *async_req)
> > > }
> > > #endif
> > > +#ifdef CONFIG_CRYPTO_DEV_QCE_AEAD
> > > +static int qce_setup_regs_aead(struct crypto_async_request *async_req)
> > > +{
> > > + struct aead_request *req = aead_request_cast(async_req);
> > > + struct qce_aead_reqctx *rctx = aead_request_ctx(req);
> > > + struct qce_aead_ctx *ctx = crypto_tfm_ctx(async_req->tfm);
> > > + struct qce_alg_template *tmpl = to_aead_tmpl(crypto_aead_reqtfm(req));
> > > + struct qce_device *qce = tmpl->qce;
> > > + __be32 enckey[QCE_MAX_CIPHER_KEY_SIZE / sizeof(__be32)] = {0};
> > > + __be32 enciv[QCE_MAX_IV_SIZE / sizeof(__be32)] = {0};
> > > + __be32 authkey[QCE_SHA_HMAC_KEY_SIZE / sizeof(__be32)] = {0};
> > > + __be32 authiv[SHA256_DIGEST_SIZE / sizeof(__be32)] = {0};
> > > + __be32 authnonce[QCE_MAX_NONCE / sizeof(__be32)] = {0};
> > > + unsigned int enc_keylen = ctx->enc_keylen;
> > > + unsigned int auth_keylen = ctx->auth_keylen;
> > > + unsigned int enc_ivsize = rctx->ivsize;
> > > + unsigned int auth_ivsize;
> > > + unsigned int enckey_words, enciv_words;
> > > + unsigned int authkey_words, authiv_words, authnonce_words;
> > > + unsigned long flags = rctx->flags;
> > > + u32 encr_cfg = 0, auth_cfg = 0, config, totallen;
>
Re: [PATCH 6/7] crypto: qce: common: Add support for AEAD algorithms
On Tue 13 Apr 16:31 CDT 2021, Thara Gopinath wrote:
>
> Hi Bjorn,
>
> On 4/5/21 6:18 PM, Bjorn Andersson wrote:
> > On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> >
> > > Add register programming sequence for enabling AEAD
> > > algorithms on the Qualcomm crypto engine.
> > >
> > > Signed-off-by: Thara Gopinath
> > > ---
> > > drivers/crypto/qce/common.c | 155 +++-
> > > 1 file changed, 153 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> > > index 05a71c5ecf61..54d209cb0525 100644
> > > --- a/drivers/crypto/qce/common.c
> > > +++ b/drivers/crypto/qce/common.c
> > > @@ -15,6 +15,16 @@
> > > #include "core.h"
> > > #include "regs-v5.h"
> > > #include "sha.h"
> > > +#include "aead.h"
> > > +
> > > +static const u32 std_iv_sha1[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> > > + SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4, 0, 0, 0
> > > +};
> > > +
> > > +static const u32 std_iv_sha256[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> > > + SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
> > > + SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7
> > > +};
> > > static inline u32 qce_read(struct qce_device *qce, u32 offset)
> > > {
> > > @@ -96,7 +106,7 @@ static inline void qce_crypto_go(struct qce_device
> > > *qce, bool result_dump)
> > > qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
> > > }
> > > -#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> > > +#if defined(CONFIG_CRYPTO_DEV_QCE_SHA) ||
> > > defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> > > static u32 qce_auth_cfg(unsigned long flags, u32 key_size, u32
> > > auth_size)
> > > {
> > > u32 cfg = 0;
> > > @@ -139,7 +149,9 @@ static u32 qce_auth_cfg(unsigned long flags, u32
> > > key_size, u32 auth_size)
> > > return cfg;
> > > }
> > > +#endif
> > > +#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> > > static int qce_setup_regs_ahash(struct crypto_async_request *async_req)
> > > {
> > > struct ahash_request *req = ahash_request_cast(async_req);
> > > @@ -225,7 +237,7 @@ static int qce_setup_regs_ahash(struct
> > > crypto_async_request *async_req)
> > > }
> > > #endif
> > > -#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> > > +#if defined(CONFIG_CRYPTO_DEV_QCE_SKCIPHER) ||
> > > defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> > > static u32 qce_encr_cfg(unsigned long flags, u32 aes_key_size)
> > > {
> > > u32 cfg = 0;
> > > @@ -271,7 +283,9 @@ static u32 qce_encr_cfg(unsigned long flags, u32
> > > aes_key_size)
> > > return cfg;
> > > }
> > > +#endif
> > > +#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> > > static void qce_xts_swapiv(__be32 *dst, const u8 *src, unsigned int
> > > ivsize)
> > > {
> > > u8 swap[QCE_AES_IV_LENGTH];
> > > @@ -386,6 +400,139 @@ static int qce_setup_regs_skcipher(struct
> > > crypto_async_request *async_req)
> > > }
> > > #endif
> > > +#ifdef CONFIG_CRYPTO_DEV_QCE_AEAD
> > > +static int qce_setup_regs_aead(struct crypto_async_request *async_req)
> > > +{
> > > + struct aead_request *req = aead_request_cast(async_req);
> > > + struct qce_aead_reqctx *rctx = aead_request_ctx(req);
> > > + struct qce_aead_ctx *ctx = crypto_tfm_ctx(async_req->tfm);
> > > + struct qce_alg_template *tmpl = to_aead_tmpl(crypto_aead_reqtfm(req));
> > > + struct qce_device *qce = tmpl->qce;
> > > + __be32 enckey[QCE_MAX_CIPHER_KEY_SIZE / sizeof(__be32)] = {0};
> > > + __be32 enciv[QCE_MAX_IV_SIZE / sizeof(__be32)] = {0};
> > > + __be32 authkey[QCE_SHA_HMAC_KEY_SIZE / sizeof(__be32)] = {0};
> > > + __be32 authiv[SHA256_DIGEST_SIZE / sizeof(__be32)] = {0};
> > > + __be32 authnonce[QCE_MAX_NONCE / sizeof(__be32)] = {0};
> > > + unsigned int enc_keylen = ctx->enc_keylen;
> > > + unsigned int auth_keylen = ctx->auth_keylen;
> > > + unsigned int enc_ivsize = rctx->ivsize;
> > > + unsigned int auth_ivsize;
> > > + unsigned int enckey_words, enciv_words;
> > > + unsigned int authkey_words, authiv_words, authnonce_words;
> > > + unsigned long flags = rctx->flags;
> > > + u32 encr_cfg = 0, auth_cfg = 0, config, to
Re: [PATCH v4 2/2] remoteproc: stm32: add capability to detach
On Wed 31 Mar 02:33 CDT 2021, Arnaud Pouliquen wrote:
> A mechanism similar to the shutdown mailbox signal is implemented to
> detach a remote processor.
>
> Upon detachment, a signal is sent to the remote firmware, allowing it
> to perform specific actions such as stopping rpmsg communication.
>
> The Cortex-M hold boot is also disabled to allow the remote processor
> to restart in case of crash.
>
> Signed-off-by: Arnaud Pouliquen
> Reviewed-by: Mathieu Poirier
> Tested-by: Mathieu Poirier
> ---
> drivers/remoteproc/stm32_rproc.c | 39 ++--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/stm32_rproc.c
> b/drivers/remoteproc/stm32_rproc.c
> index 3d45f51de4d0..7353f9e7e7af 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -28,7 +28,7 @@
> #define RELEASE_BOOT 1
>
> #define MBOX_NB_VQ 2
> -#define MBOX_NB_MBX 3
> +#define MBOX_NB_MBX 4
>
> #define STM32_SMC_RCC0x82001000
> #define STM32_SMC_REG_WRITE 0x1
> @@ -38,6 +38,7 @@
> #define STM32_MBX_VQ1"vq1"
> #define STM32_MBX_VQ1_ID 1
> #define STM32_MBX_SHUTDOWN "shutdown"
> +#define STM32_MBX_DETACH "detach"
>
> #define RSC_TBL_SIZE 1024
>
> @@ -336,6 +337,15 @@ static const struct stm32_mbox
> stm32_rproc_mbox[MBOX_NB_MBX] = {
> .tx_done = NULL,
> .tx_tout = 500, /* 500 ms time out */
> },
> + },
> + {
> + .name = STM32_MBX_DETACH,
> + .vq_id = -1,
> + .client = {
> + .tx_block = true,
> + .tx_done = NULL,
> + .tx_tout = 200, /* 200 ms time out to detach should be
> fair enough */
> + },
> }
> };
>
> @@ -461,6 +471,25 @@ static int stm32_rproc_attach(struct rproc *rproc)
> return stm32_rproc_set_hold_boot(rproc, true);
> }
>
> +static int stm32_rproc_detach(struct rproc *rproc)
> +{
> + struct stm32_rproc *ddata = rproc->priv;
> + int err, dummy_data, idx;
> +
> + /* Inform the remote processor of the detach */
> + idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_DETACH);
> + if (idx >= 0 && ddata->mb[idx].chan) {
> + /* A dummy data is sent to allow to block on transmit */
> + err = mbox_send_message(ddata->mb[idx].chan,
> + &dummy_data);
Seems I posted my comment on v1, rather than this latest version. Please
let me know if we should do anything about this dummy_data.
Regards,
Bjorn
> + if (err < 0)
> + dev_warn(&rproc->dev, "warning: remote FW detach
> without ack\n");
> + }
> +
> + /* Allow remote processor to auto-reboot */
> + return stm32_rproc_set_hold_boot(rproc, false);
> +}
> +
> static int stm32_rproc_stop(struct rproc *rproc)
> {
> struct stm32_rproc *ddata = rproc->priv;
> @@ -597,7 +626,12 @@ stm32_rproc_get_loaded_rsc_table(struct rproc *rproc,
> size_t *table_sz)
> }
>
> done:
> - /* Assuming the resource table fits in 1kB is fair */
> + /*
> + * Assuming the resource table fits in 1kB is fair.
> + * Notice for the detach, that this 1 kB memory area has to be reserved
> in the coprocessor
> + * firmware for the resource table. On detach, the remoteproc core
> re-initializes this
> + * entire area by overwriting it with the initial values stored in
> rproc->clean_table.
> + */
> *table_sz = RSC_TBL_SIZE;
> return (struct resource_table *)ddata->rsc_va;
> }
> @@ -607,6 +641,7 @@ static const struct rproc_ops st_rproc_ops = {
> .start = stm32_rproc_start,
> .stop = stm32_rproc_stop,
> .attach = stm32_rproc_attach,
> + .detach = stm32_rproc_detach,
> .kick = stm32_rproc_kick,
> .load = rproc_elf_load_segments,
> .parse_fw = stm32_rproc_parse_fw,
> --
> 2.17.1
>
Re: [PATCH V2 1/2] soc: qcom: aoss: Expose send for generic usecase
On Thu 08 Apr 23:39 CDT 2021, Deepak Kumar Singh wrote:
[..]
> +/**
> + * qmp_get() - get a qmp handle from a device
> + * @dev: client device pointer
> + *
> + * Return: handle to qmp device on success, ERR_PTR() on failure
> + */
> +struct qmp *qmp_get(struct device *dev)
> +{
> + struct platform_device *pdev;
> + struct device_node *np;
> + struct qmp *qmp;
> +
> + if (!dev || !dev->of_node)
> + return ERR_PTR(-EINVAL);
> +
> + np = of_parse_phandle(dev->of_node, "qcom,qmp", 0);
> + if (!np)
> + return ERR_PTR(-ENODEV);
> +
> + pdev = of_find_device_by_node(np);
> + if (!pdev)
> + return ERR_PTR(-EINVAL);
> +
> + qmp = platform_get_drvdata(pdev);
> + return qmp ? qmp : ERR_PTR(-EPROBE_DEFER);
> +}
> +EXPORT_SYMBOL(qmp_get);
> +
> +void qmp_put(struct platform_device *pdev)
> +{
> + platform_device_put(pdev);
I was expecting that the devres allocated struct qmp would stick around
until the struct device's release callback came. As described in my
answer to Mani yesterday I was wrong.
As such you need to make sure that struct qmp stays around until
qmp_remove() and all qmp_put() calls has been made.
I presume a reasonable way to achieve this is to not use devm to
allocate our struct qmp, add a kref to the object. So this would have to
be a kref_put() on that instead of the platform_device_put() I asked you
to implement here.
Sorry about that.
The rest of the patch looks good.
Regards,
Bjorn
Re: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc
On Tue 23 Mar 17:02 CDT 2021, Martin Blumenstingl wrote:
> Hi Bjorn,
>
> On Thu, Mar 18, 2021 at 3:55 AM Bjorn Andersson
> wrote:
> [...]
> > > +examples:
> > > + - |
> > > +remoteproc@1c {
> > > + compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
> > > + reg = <0x1c 0x8>, <0x38 0x8>;
> >
> > I'm generally not in favor of mapping "individual" registers, do you
> > know what hardware block this is part of? Can you express the whole
> > block as an single entity in your DT?
> the answer is unfortunately not easy :-)
>
> some background information:
> Amlogic SoCs have two power domains:
> - AO (Always-On)
> - EE (Everything-Else)
>
> AO includes (at least) one ARC core for which this remoteproc dt-binding is.
> EE includes ARM Cortex-A7/15/... cores
>
> The AO registers can be accessed from the EE power-domain and vice versa
>
> Following is an extract (with comments added by me) for the AO
> registers (taken from the GPL vendor kernel):
> #define AO_RTI_STATUS_REG0 ((0x00 << 10) | (0x00 << 2))
> #define AO_RTI_STATUS_REG1 ((0x00 << 10) | (0x01 << 2))
> #define AO_RTI_STATUS_REG2 ((0x00 << 10) | (0x02 << 2))
> these three are used for communication with the firmware on the AO ARC core
> I am not sure into which Linux subsystem these would fit into best
>
> #define AO_RTI_PWR_CNTL_REG1 ((0x00 << 10) | (0x03 << 2))
> #define AO_RTI_PWR_CNTL_REG0 ((0x00 << 10) | (0x04 << 2))
> this includes various power-domains for the following functionality
> (and probably more):
> - DDR PHY I/O
> - AHB SRAM
> - video encoder/decoders
> - EE domain isolation
>
> #define AO_RTI_PIN_MUX_REG ((0x00 << 10) | (0x05 << 2))
> first part of the pin controller registers for the "AO" bank pads
> this includes various GPIOs, UART, I2C for communication with a PMIC,
> infrared remote decoder, two PWMs, etc.
> all (known) functionality can be used by Linux as well.
> especially the UART, I2C, IR decoder and GPIOs are functionality that
> we use with Linux today - without involving the AO ARC
> remote-processor.
>
> #define AO_WD_GPIO_REG ((0x00 << 10) | (0x06 << 2))
> (I think this is related to the watchdog being able to trigger the
> SoC's reset line, but there's no documentation on this register)
>
> #define AO_REMAP_REG0 ((0x00 << 10) | (0x07 << 2))
> #define AO_REMAP_REG1 ((0x00 << 10) | (0x08 << 2))
> remap registers for the AO ARC remote-processor as used in this binding
>
> #define AO_GPIO_O_EN_N ((0x00 << 10) | (0x09 << 2))
> #define AO_GPIO_I ((0x00 << 10) | (0x0A << 2))
> GPIO controller registers for the "AO" bank pads
>
> #define AO_RTI_PULL_UP_REG ((0x00 << 10) | (0x0B << 2))
> second part of the pin controller registers for the "AO" bank pads
>
> #define AO_RTI_WD_MARK ((0x00 << 10) | (0x0D << 2))
> again, I think this is somehow related to the watchdog but there's no
> documentation on this
>
> #define AO_CPU_CNTL ((0x00 << 10) | (0x0E << 2))
> #define AO_CPU_STAT ((0x00 << 10) | (0x0F << 2))
> used for booting the AO ARC remote-processor
>
> #define AO_RTI_GEN_CNTL_REG0 ((0x00 << 10) | (0x10 << 2))
> seems to be a multi purpose register as it (seems to) contains some
> reset bits (for the AO UART and RTC) - not documented
>
> (more registers are following)
>
> to summarize this: I think there's indeed three different sets of registers
> having one big device-tree node spanning all of these registers seems
> incorrect to me as the other IPs are independent of the AO ARC
> remote-processor.
> so the way I have done it in the original patch is the best I could
> come up with.
>
> Please let me know what you think!
>
I see.
Describing these kinds blocks in DT is indeed tricky, I've had
both cases where a block maps to multiple "functions" or where they
contain misc registers to be used in relation to some other block.
The prior typically lends itself to be modelled as a "simple-mfd" and
the latter as a "syscon".
So perhaps you could do a simple-mfd that spans the entire block and
then describe the remoteproc, watchdog?, pinctrl pieces as children
under that?
Regards,
Bjorn
Re: [PATCH 2/2] remoteproc: stm32: add capability to detach
On Thu 18 Mar 09:59 CDT 2021, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> A mechanism similar to the shutdown mailbox signal is implemented to
> detach a remote processor.
>
> Upon detachment, a signal is sent to the remote firmware, allowing it
> to perform specific actions such as stopping RPMsg communication.
>
> The Cortex-M hold boot is also disabled to allow the remote processor
> to restart in case of crash.
>
> Notice that for this feature to be supported, the remote firmware
> resource table must be stored at the beginning of a 1kB section
> (default size provided to the remoteproc core).
>
> This restriction should be lifted in the future by using a backup register
> to store the actual size of the resource table.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/remoteproc/stm32_rproc.c | 38 ++--
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/stm32_rproc.c
> b/drivers/remoteproc/stm32_rproc.c
> index 3d45f51de4d0..298ef5b19e27 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -28,7 +28,7 @@
> #define RELEASE_BOOT 1
>
> #define MBOX_NB_VQ 2
> -#define MBOX_NB_MBX 3
> +#define MBOX_NB_MBX 4
>
> #define STM32_SMC_RCC0x82001000
> #define STM32_SMC_REG_WRITE 0x1
> @@ -38,6 +38,7 @@
> #define STM32_MBX_VQ1"vq1"
> #define STM32_MBX_VQ1_ID 1
> #define STM32_MBX_SHUTDOWN "shutdown"
> +#define STM32_MBX_DETACH "detach"
>
> #define RSC_TBL_SIZE 1024
>
> @@ -336,6 +337,15 @@ static const struct stm32_mbox
> stm32_rproc_mbox[MBOX_NB_MBX] = {
> .tx_done = NULL,
> .tx_tout = 500, /* 500 ms time out */
> },
> + },
> + {
> + .name = STM32_MBX_DETACH,
> + .vq_id = -1,
> + .client = {
> + .tx_block = true,
> + .tx_done = NULL,
> + .tx_tout = 200, /* 200 ms time out to detach should be
> fair enough */
> + },
> }
> };
>
> @@ -461,6 +471,25 @@ static int stm32_rproc_attach(struct rproc *rproc)
> return stm32_rproc_set_hold_boot(rproc, true);
> }
>
> +static int stm32_rproc_detach(struct rproc *rproc)
> +{
> + struct stm32_rproc *ddata = rproc->priv;
> + int err, dummy_data, idx;
> +
> + /* Inform the remote processor of the detach */
> + idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_DETACH);
> + if (idx >= 0 && ddata->mb[idx].chan) {
> + /* A dummy data is sent to allow to block on transmit */
> + err = mbox_send_message(ddata->mb[idx].chan,
> + &dummy_data);
Isn't it the stm32_ipcc driver on the other side of this call? In which
case I believe "data" is ignored, and you would be able to just pass
NULL here.
As long as "data" isn't dereferenced it's probably better to send some
bugus value, than an address to this variable on the stack. If on the
other hand you pair this with one of the mailbox drivers that
dereferences "data", you should initialize it...
Apart from this, I think the patch looks good!
Regards,
Bjorn
> + if (err < 0)
> + dev_warn(&rproc->dev, "warning: remote FW detach
> without ack\n");
> + }
> +
> + /* Allow remote processor to auto-reboot */
> + return stm32_rproc_set_hold_boot(rproc, false);
> +}
> +
> static int stm32_rproc_stop(struct rproc *rproc)
> {
> struct stm32_rproc *ddata = rproc->priv;
> @@ -597,7 +626,11 @@ stm32_rproc_get_loaded_rsc_table(struct rproc *rproc,
> size_t *table_sz)
> }
>
> done:
> - /* Assuming the resource table fits in 1kB is fair */
> + /*
> + * Assuming the resource table fits in 1kB is fair.
> + * Notice for the detach, that this 1 kB memory area has to be reserved
> in the coprocessor
> + * firmware for the resource table. A clean of this whole area is done
> on detach.
> + */
> *table_sz = RSC_TBL_SIZE;
> return (struct resource_table *)ddata->rsc_va;
> }
> @@ -607,6 +640,7 @@ static const struct rproc_ops st_rproc_ops = {
> .start = stm32_rproc_start,
> .stop = stm32_rproc_stop,
> .attach = stm32_rproc_attach,
> + .detach = stm32_rproc_detach,
> .kick = stm32_rproc_kick,
> .load = rproc_elf_load_segments,
> .parse_fw = stm32_rproc_parse_fw,
> --
> 2.17.1
>
Re: [PATCH 3/7] crypto: qce: Add mode for rfc4309
On Tue 13 Apr 14:30 CDT 2021, Thara Gopinath wrote: > > > On 4/5/21 6:32 PM, Bjorn Andersson wrote: > > On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote: > > > > > rf4309 is the specification that uses aes ccm algorithms with IPsec > > > security packets. Add a submode to identify rfc4309 ccm(aes) algorithm > > > in the crypto driver. > > > > > > Signed-off-by: Thara Gopinath > > > --- > > > drivers/crypto/qce/common.h | 7 +-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/crypto/qce/common.h b/drivers/crypto/qce/common.h > > > index 3bc244bcca2d..3ffe719b79e4 100644 > > > --- a/drivers/crypto/qce/common.h > > > +++ b/drivers/crypto/qce/common.h > > > @@ -51,9 +51,11 @@ > > > #define QCE_MODE_CCMBIT(12) > > > #define QCE_MODE_MASK GENMASK(12, 8) > > > +#define QCE_MODE_CCM_RFC4309 BIT(13) > > > + > > > /* cipher encryption/decryption operations */ > > > -#define QCE_ENCRYPT BIT(13) > > > -#define QCE_DECRYPT BIT(14) > > > +#define QCE_ENCRYPT BIT(14) > > > +#define QCE_DECRYPT BIT(15) > > > > Can't we move these further up, so that next time we want to add > > something it doesn't require that we also move the ENC/DEC bits? > > Yes I will change it to BIT(30) and BIT(31) > > > > > > #define IS_DES(flags) (flags & QCE_ALG_DES) > > > #define IS_3DES(flags) (flags & QCE_ALG_3DES) > > > @@ -73,6 +75,7 @@ > > > #define IS_CTR(mode)(mode & QCE_MODE_CTR) > > > #define IS_XTS(mode)(mode & QCE_MODE_XTS) > > > #define IS_CCM(mode)(mode & QCE_MODE_CCM) > > > +#define IS_CCM_RFC4309(mode) ((mode) & QCE_MODE_CCM_RFC4309) > > > > While leaving room for the typical macro issues, none of the other > > macros wrap the argument in parenthesis. Please follow the style of the > > driver, and perhaps follow up with a cleanup patch that just wraps them > > all in parenthesis? > > This does throw up a checkpatch warning if I don't wrap "mode" in > parenthesis. How about I keep this for now and I will follow up with a clean > up for rest of the macros later ? > I don't have a problem with this approach. Regards, Bjorn > > > > Regards, > > Bjorn > > > > > #define IS_ENCRYPT(dir) (dir & QCE_ENCRYPT) > > > #define IS_DECRYPT(dir) (dir & QCE_DECRYPT) > > > -- > > > 2.25.1 > > > > > -- > Warm Regards > Thara
Re: [PATCH V2 1/4] input: pm8941-pwrkey: add support for PMK8350 PON_HLOS PMIC peripheral
On Thu 08 Apr 06:31 CDT 2021, satya priya wrote:
> From: David Collins
>
> On Qualcomm Technologies, Inc. PMIC PMK8350, the PON peripheral
> is split into two peripherals: PON_HLOS and PON_PBS. The
> application processor only has write access to PON_HLOS which
> limits it to only receiving PON interrupts.
>
> Add support for the PMK8350 PON_HLOS peripheral so that its
> KPDPWR_N and RESIN_N interrupts can be used to detect key
> presses.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: David Collins
> Signed-off-by: satya priya
> ---
> Changes in V2:
> - No change.
>
> drivers/input/misc/pm8941-pwrkey.c | 103
> ++---
> 1 file changed, 72 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/input/misc/pm8941-pwrkey.c
> b/drivers/input/misc/pm8941-pwrkey.c
> index cf81044..10e3fc0 100644
> --- a/drivers/input/misc/pm8941-pwrkey.c
> +++ b/drivers/input/misc/pm8941-pwrkey.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Copyright (c) 2010-2011, Code Aurora Forum. All rights reserved.
> + * Copyright (c) 2010-2011, 2020-2021, The Linux Foundation. All rights
> reserved.
> * Copyright (c) 2014, Sony Mobile Communications Inc.
> */
>
> @@ -22,6 +22,8 @@
> #define PON_RT_STS 0x10
> #define PON_KPDPWR_N_SETBIT(0)
> #define PON_RESIN_N_SET BIT(1)
> +#define PON_GEN3_RESIN_N_SETBIT(6)
> +#define PON_GEN3_KPDPWR_N_SET BIT(7)
>
> #define PON_PS_HOLD_RST_CTL 0x5a
> #define PON_PS_HOLD_RST_CTL2 0x5b
> @@ -38,8 +40,12 @@
> #define PON_DBC_DELAY_MASK 0x7
>
> struct pm8941_data {
> - unsigned int pull_up_bit;
> - unsigned int status_bit;
> + unsigned intpull_up_bit;
> + unsigned intstatus_bit;
> + boolsupports_ps_hold_poff_config;
> + boolsupports_debounce_config;
> + const char *name;
> + const char *phys;
> };
>
> struct pm8941_pwrkey {
> @@ -231,34 +237,40 @@ static int pm8941_pwrkey_probe(struct platform_device
> *pdev)
>
> input_set_capability(pwrkey->input, EV_KEY, pwrkey->code);
>
> - pwrkey->input->name = "pm8941_pwrkey";
> - pwrkey->input->phys = "pm8941_pwrkey/input0";
> -
> - req_delay = (req_delay << 6) / USEC_PER_SEC;
> - req_delay = ilog2(req_delay);
> -
> - error = regmap_update_bits(pwrkey->regmap,
> -pwrkey->baseaddr + PON_DBC_CTL,
> -PON_DBC_DELAY_MASK,
> -req_delay);
> - if (error) {
> - dev_err(&pdev->dev, "failed to set debounce: %d\n", error);
> - return error;
> + pwrkey->input->name = pwrkey->data->name;
> + pwrkey->input->phys = pwrkey->data->phys;
> +
> + if (pwrkey->data->supports_debounce_config) {
> + req_delay = (req_delay << 6) / USEC_PER_SEC;
> + req_delay = ilog2(req_delay);
> +
> + error = regmap_update_bits(pwrkey->regmap,
> +pwrkey->baseaddr + PON_DBC_CTL,
> +PON_DBC_DELAY_MASK,
> +req_delay);
> + if (error) {
> + dev_err(&pdev->dev, "failed to set debounce: %d\n",
> + error);
> + return error;
> + }
> }
>
> - error = regmap_update_bits(pwrkey->regmap,
> -pwrkey->baseaddr + PON_PULL_CTL,
> -pwrkey->data->pull_up_bit,
> -pull_up ? pwrkey->data->pull_up_bit : 0);
> - if (error) {
> - dev_err(&pdev->dev, "failed to set pull: %d\n", error);
> - return error;
> + if (pwrkey->data->pull_up_bit) {
> + error = regmap_update_bits(pwrkey->regmap,
> +pwrkey->baseaddr + PON_PULL_CTL,
> +pwrkey->data->pull_up_bit,
> +pull_up ? pwrkey->data->pull_up_bit :
> + 0);
> + if (error) {
> + dev_err(&pdev->dev, "failed to set pull: %d\n", error);
> + return error;
> + }
> }
>
Re: [PATCH v4 0/7] cpufreq-qcom-hw: Implement full OSM programming
On Mon 12 Apr 00:11 CDT 2021, Viresh Kumar wrote:
> On 19-01-21, 18:45, AngeloGioacchino Del Regno wrote:
> > **
> > ** NOTE: To "view the full picture", please look at the following
> > ** patch series:
> > ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355
> > ** This is a subset of that series.
> > **
> >
> > Changes in v4:
> > - Huge patch series has been split for better reviewability,
> > as suggested by Bjorn
> > - Rebased code on top of 266991721c15 ("cpufreq: qcom-hw: enable boost
> > support")
>
> Bjorn, what am I supposed to do with patchset ? Is there anyone who can give
> this some reviews from qcom team ?
>
Sorry Viresh, I've been postponing reviewing this a few times too many.
I'll take the time in the coming days to look through it properly,
including Taniya's feedback.
Regards,
Bjorn
Re: New 'make dtbs_check W=1' warnings
On Mon 12 Apr 13:52 CDT 2021, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson > wrote: > > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven > > > wrote: > > > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann wrote: > > > > So the same binding patch is picked up both in the driver and soc tree? > > I was expecting that to cause (harmless) conflicts when things arrive in > > Linus' merge queue? > > > > Or are you saying people go the length to create immutable branches for > > each binding? > > I think it's usually one immutable branch for all the bindings of a given > merge window. This avoids the merge conflicts, and you can add further > bindings on the same branch before sending it off to the soc tree. > That would be convenient to have, but the binding changes we depend on in a given window (in particular if dtbs_check is expected to pass) is scattered over a wide range of maintainer trees. > > I'm curious because it's fairly often that we introduce clocks, > > interconnects etc where the macros from the dt bindings includes aren't > > available for another release (so we use numerical constants and then go > > back and fix them up later). > > Ah right, it is particularly bad for platforms that don't have a regular > layout in these blocks and need to define a new constant every time > another clock/reset/pin/... is discovered in the downstream sources. > Even blocks following some standardized layout has this problem, because each platform will have it's own (often similar) set of clocks/resets/pins. And going back to dtbs_check, you will continue to see the warnings about missing compatibles, because most of the case they won't end up in the soc tree. > I was mainly referring to the simpler problem of defining a binding > document for a device once, and then merging the nodes. > I'm sure we all love the hardware that's simple to translate to a DT binding, unfortunately though we're dealing with complex SoCs. Regards, Bjorn
Re: [PATCH V1 1/2] soc: qcom: aoss: Expose send for generic usecase
On Fri 09 Apr 02:31 CDT 2021, Manivannan Sadhasivam wrote:
> On Sun, Apr 04, 2021 at 12:17:52PM -0500, Bjorn Andersson wrote:
> > On Fri 02 Apr 01:17 CDT 2021, Deepak Kumar Singh wrote:
> >
> > > Not all upcoming usecases will have an interface to allow the aoss
> > > driver to hook onto. Expose the send api and create a get function to
> > > enable drivers to send their own messages to aoss.
> > >
> > > Signed-off-by: Chris Lew
> > > Signed-off-by: Deepak Kumar Singh
> > > ---
> > > drivers/soc/qcom/qcom_aoss.c | 36 +++-
> > > 1 file changed, 35 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
> > > index 53acb94..5c643f0 100644
> > > --- a/drivers/soc/qcom/qcom_aoss.c
> > > +++ b/drivers/soc/qcom/qcom_aoss.c
> > > @@ -8,10 +8,12 @@
>
> [...]
>
> > > + pdev = of_find_device_by_node(np);
> >
> > of_find_device_by_node() will increment the refcount of the underlying
> > struct device of pdev, so you need to platform_device_put() once you're
> > done with it.
> >
> > As a side effect of not putting the struct device, the devm_kzalloc'ed
> > qmp pointer will remain valid. So care is needed to make sure that the
> > client doesn't end up with a dangling pointer if the qmp device is
> > removed.
> >
> > My suggestion is that you add a "qmp_put()" function, which invokes
> > platform_device_put() and that you add some sort of tracking ("bool
> > orphan"?) to the struct qmp and make qmp_send() fail if this is set.
> >
>
> I think this is a duplication of what the struct device offers. Why
> can't we use the generic infrastructure for this usecase?
>
> Like using device_initialize() in qmp_probe() along with a release
> callback for "struct device", then using get_device() in qmp_get().
> Then there should also be a qmp_put() API which calls put_device() to
> decrease the refcount.
>
> Ideally, the final refcount should be dropped in qmp_remove() and then
> the release callback will be called automatically to free "struct qmp".
>
> > That way if someone unbinds the aoss device, the client will still have
> > a "valid" pointer, but won't be able to qmp_send() after qmp_close() has
> > been called in the aoss remove function.
> >
>
> How can someone remove the qmp device if a client is holding its reference?
>
The device could be unbound using sysfs, in which case remove() is
called and I assumed that devres wouldn't be released until the struct
device's refcount hit 0.
Apparently this does not seems to be how it works, following the unbind
path I see that devres is shot down regardless of the struct device's
refcount.
So we would need to ensure that struct qmp is refcounted on its own.
For this we don't need a separate struct device, we can simply add a
kref to the struct and avoid using devres to keep track of its lifetime.
Regards,
Bjorn
> Thanks,
> Mani
>
> > Regards,
> > Bjorn
> >
> > > + if (!pdev)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + qmp = platform_get_drvdata(pdev);
> > > + return qmp ? qmp : ERR_PTR(-EPROBE_DEFER);
> > > +}
> > > +EXPORT_SYMBOL(qmp_get);
> > > +
> > > static int qmp_probe(struct platform_device *pdev)
> > > {
> > > struct resource *res;
> > > --
> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > > a Linux Foundation Collaborative Project
> > >
Re: [PATCH] phy: qcom-qmp: remove redundant error of clock bulk
On Thu 08 Apr 22:07 CDT 2021, Chunfeng Yun wrote:
> There is error log in clk_bulk_prepare/enable()
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Chunfeng Yun
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 9cdebe7..f14b8be 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -3598,10 +3598,8 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
> }
>
> ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> - if (ret) {
> - dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> + if (ret)
> goto err_rst;
> - }
>
> if (cfg->has_phy_dp_com_ctrl) {
> qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
> @@ -4035,10 +4033,8 @@ static int __maybe_unused
> qcom_qmp_phy_runtime_resume(struct device *dev)
> }
>
> ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> - if (ret) {
> - dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> + if (ret)
> return ret;
> - }
>
> ret = clk_prepare_enable(qphy->pipe_clk);
> if (ret) {
> --
> 1.8.1.1.dirty
>
Re: [PATCH v7 2/5] soc: qcom: Add SoC sleep stats driver
On Tue 06 Apr 05:27 CDT 2021, Maulik Shah wrote:
> From: Mahesh Sivasubramanian
>
> Let's add a driver to read the stats from remote processor and
> export to debugfs.
>
> The driver creates "qcom_sleep_stats" directory in debugfs and
> adds files for various low power mode available. Below is sample
> output with command
>
> cat /sys/kernel/debug/qcom_sleep_stats/ddr
> count = 0
> Last Entered At = 0
> Last Exited At = 0
> Accumulated Duration = 0
>
> Signed-off-by: Mahesh Sivasubramanian
> Signed-off-by: Lina Iyer
> [mkshah: add subsystem sleep stats, create one file for each stat]
> Signed-off-by: Maulik Shah
Thanks for picking this up again Maulik, I hope we can get it merged
soon.
> ---
> drivers/soc/qcom/Kconfig | 10 ++
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/soc_sleep_stats.c | 281
> +
> 3 files changed, 292 insertions(+)
> create mode 100644 drivers/soc/qcom/soc_sleep_stats.c
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 79b568f..e80b63a 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -190,6 +190,16 @@ config QCOM_SOCINFO
>Say yes here to support the Qualcomm socinfo driver, providing
>information about the SoC to user space.
>
> +config QCOM_SOC_SLEEP_STATS
> + tristate "Qualcomm Technologies, Inc. (QTI) SoC sleep stats driver"
> + depends on ARCH_QCOM && DEBUG_FS || COMPILE_TEST
> + depends on QCOM_SMEM
> + help
> + Qualcomm Technologies, Inc. (QTI) SoC sleep stats driver to read
> + the shared memory exported by the remote processor related to
> + various SoC level low power modes statistics and export to debugfs
> + interface.
> +
> config QCOM_WCNSS_CTRL
> tristate "Qualcomm WCNSS control driver"
> depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ad675a6..5f30d74 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
> obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
> obj-$(CONFIG_QCOM_SMSM) += smsm.o
> obj-$(CONFIG_QCOM_SOCINFO) += socinfo.o
> +obj-$(CONFIG_QCOM_SOC_SLEEP_STATS) += soc_sleep_stats.o
> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
> obj-$(CONFIG_QCOM_APR) += apr.o
> obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
> diff --git a/drivers/soc/qcom/soc_sleep_stats.c
> b/drivers/soc/qcom/soc_sleep_stats.c
> new file mode 100644
> index 000..6dfc239
> --- /dev/null
> +++ b/drivers/soc/qcom/soc_sleep_stats.c
> @@ -0,0 +1,281 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2011-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define STAT_TYPE_ADDR 0x0
> +#define COUNT_ADDR 0x4
> +#define LAST_ENTERED_AT_ADDR 0x8
> +#define LAST_EXITED_AT_ADDR 0x10
> +#define ACCUMULATED_ADDR 0x18
> +#define CLIENT_VOTES_ADDR0x1c
These aren't "addresses", they are offsets, and they are actually just
offset_of() on
> +
> +#define STAT_OFFSET(record_no, type) (((record_no)*(sizeof(struct
> sleep_stats))) + (type))
> +#define APPENDED_STAT_OFFSET(record_no) ((record_no)*(sizeof(struct
> appended_stats)))
> +
> +#ifndef readq
> +#define readq(a) ({ \
> + u64 val = readl((a) + 4); \
> + val <<= 32; \
> + val |= readl((a)); \
> + val;\
> +})
I don't like this macro, can you please write it as a static inline,
with a comment that the operation is not expected to be atomic?
> +#endif
> +
> +struct subsystem_data {
> + const char *name;
> + u32 smem_item;
> + u32 pid;
> +};
> +
> +static const struct subsystem_data subsystems[] = {
> + { "modem", 605, 1 },
> + { "wpss", 605, 13 },
> + { "adsp", 606, 2 },
> + { "cdsp", 607, 5 },
> + { "slpi", 608, 3 },
> + { "gpu", 609, 0 },
> + { "display", 610, 0 },
> + { "adsp_island", 613, 2 },
> + { "slpi_island", 613, 3 },
> +};
> +
> +struct stats_config {
> + u32 offset_addr;
> + u32 num_records;
Neither of these must be 32-bit, so please use int...or size_t instead.
> + bool appended_stats_avail;
> +};
> +
> +struct stats_prv_data {
I don't see any "public" data, so how about just dropping "prv_"?
> + bool appended_stats_avail;
> + void __iomem *reg;
Call this "base" instead.
> +};
> +
> +struct sleep_stats {
> + u32 stat_type;
> + u32 count;
> + u64 last_entered_at;
> + u64 last_exited_at;
> + u64 accumulated;
> +};
> +
> +struct appended_stats {
> + u32 client_votes;
> + u32 reserved[3];
> +};
> +
> +static void print_sleep_stats(struct seq_file *s, const struct sleep_stats
> *stat)
I would like all
Re: New 'make dtbs_check W=1' warnings
On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven > wrote: > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann wrote: > > > > > > > For this merge window, I don't think any of them are show-stoppers (Rob, > > > let me > > > know if you disagree), but in the long run we may want to gradually > > > enforce > > > a rule about not merging changes that introduce any new warnings, in > > > order to > > > have a chance of cleaning up the existing ones. > > > > This may not be as simple as it sounds, as DT binding updates typically > > follow a different path than DTS(i) updates. DT bindings updates may be > > picked up by a subsystem maintainer, by Rob, or by the platform > > maintainer. > > I checked out the bindings from linux-next, which seems to have covered > most of these. Sometimes it pays off to be lazy and merge them after > everyone else. > > > For trivial updates (e.g. adding a compatible value, and sometimes > > extending a limit), a DTS(i) update may be accepted by the platform > > maintainer before the corresponding DT binding update. The latter may > > even be merged one or more kernel revisions later, especially when > > involving subsystems that are not traditionally rooted into platforms > > using DT. > > > > Of course we could mention any expected warning regressions in our pull > > requests for soc. > > Right, that would certainly help. Some maintainers send all binding > updates both to the driver maintainers and to the soc tree, along > with the other changes that only go into one tree. That is of course > also more work on your side, but it solves the problem entirely. > So the same binding patch is picked up both in the driver and soc tree? I was expecting that to cause (harmless) conflicts when things arrive in Linus' merge queue? Or are you saying people go the length to create immutable branches for each binding? I'm curious because it's fairly often that we introduce clocks, interconnects etc where the macros from the dt bindings includes aren't available for another release (so we use numerical constants and then go back and fix them up later). Regards, Bjorn > > > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa: ports: > > > 'port@0' is a required property > > > > [...] > > > > I've replied to these as a response to your PR reply, see > > https://lore.kernel.org/linux-renesas-soc/camuhmdwhlnxgbsjp7vkudx-ynr9rskfke5ge5q_taru6hp9...@mail.gmail.com/ > > Ok, thanks. > > Arnd
Re: [PATCH v4] media: venus : hfi: add venus image info into smem
On Fri 09 Apr 06:46 CDT 2021, Dikshita Agarwal wrote:
> Fill fw version info into smem to be printed as part of
> soc info.
>
> Signed-off-by: Dikshita Agarwal
> Reported-by: kernel test robot
Why/how did kernel test robot tell you that you should write the
firmware version in SMEM?
>
> change since v3:
> added dependency on QCOM_SMEM (Stephen)
> ---
> drivers/media/platform/Kconfig | 2 +-
> drivers/media/platform/qcom/venus/hfi_msgs.c | 21 +++--
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index fd1831e..9c75e88 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -543,7 +543,7 @@ config VIDEO_TI_VPE_DEBUG
>
> config VIDEO_QCOM_VENUS
> tristate "Qualcomm Venus V4L2 encoder/decoder driver"
> - depends on VIDEO_DEV && VIDEO_V4L2
> + depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM
> depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
> select QCOM_MDT_LOADER if ARCH_QCOM
> select QCOM_SCM if ARCH_QCOM
> diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c
> b/drivers/media/platform/qcom/venus/hfi_msgs.c
> index 06a1908..74cfc4f 100644
> --- a/drivers/media/platform/qcom/venus/hfi_msgs.c
> +++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "core.h"
> @@ -14,6 +15,10 @@
> #include "hfi_msgs.h"
> #include "hfi_parser.h"
>
> +#define SMEM_IMG_VER_TBL 469
> +#define VER_STR_SZ 128
> +#define SMEM_IMG_OFFSET_VENUS (14 * 128)
> +
> static void event_seq_changed(struct venus_core *core, struct venus_inst
> *inst,
> struct hfi_msg_event_notify_pkt *pkt)
> {
> @@ -239,15 +244,27 @@ static void
> sys_get_prop_image_version(struct device *dev,
> struct hfi_msg_sys_property_info_pkt *pkt)
> {
> + u8 *smem_tbl_ptr;
> + u8 *img_ver;
> int req_bytes;
> + size_t smem_blk_sz;
>
> req_bytes = pkt->hdr.size - sizeof(*pkt);
>
> - if (req_bytes < 128 || !pkt->data[1] || pkt->num_properties > 1)
> + if (req_bytes < VER_STR_SZ || !pkt->data[1] || pkt->num_properties > 1)
> /* bad packet */
> return;
>
> - dev_dbg(dev, VDBGL "F/W version: %s\n", (u8 *)&pkt->data[1]);
> + img_ver = (u8 *)&pkt->data[1];
> +
> + dev_dbg(dev, VDBGL "F/W version: %s\n", img_ver);
> +
> + smem_tbl_ptr = qcom_smem_get(QCOM_SMEM_HOST_ANY,
> + SMEM_IMG_VER_TBL, &smem_blk_sz);
> + if (smem_tbl_ptr &&
> + smem_blk_sz >= SMEM_IMG_OFFSET_VENUS + VER_STR_SZ)
> + memcpy(smem_tbl_ptr + SMEM_IMG_OFFSET_VENUS,
> +img_ver, VER_STR_SZ);
I think you should unwrap lines, the conditional isn't even more than 80
chars...
Apart from these nits I think the patch looks good.
Regards,
Bjorn
> }
>
> static void hfi_sys_property_info(struct venus_core *core,
> --
> 2.7.4
>
[GIT PULL] remoteproc fixes for v5.12
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git tags/rproc-v5.12-fixes for you to fetch changes up to 9afeefcf06fc7b4bdab06a6e2cb06745bded34dd: remoteproc: pru: Fix firmware loading crashes on K3 SoCs (2021-03-17 14:15:07 -0500) remoteproc fixes for v5.12 This fixes an issue with firmware loading on the TI K3 PRU, fixes compatibility with GNU binutils for the same and resolves link error due to a 64-bit division in the Qualcomm PIL info. It also recognizes Mathieu Poirier as co-maintainer of the remoteproc and rpmsg subsystems. Arnd Bergmann (1): remoteproc: qcom: pil_info: avoid 64-bit division Dimitar Dimitrov (1): remoteproc: pru: Fix loading of GNU Binutils ELF Mathieu Poirier (1): MAINTAINERS: Add co-maintainer for remoteproc/RPMSG subsystems Suman Anna (1): remoteproc: pru: Fix firmware loading crashes on K3 SoCs MAINTAINERS| 2 ++ drivers/remoteproc/pru_rproc.c | 20 +++- drivers/remoteproc/qcom_pil_info.c | 2 +- 3 files changed, 22 insertions(+), 2 deletions(-)
Re: [PATCH 1/3] dt-bindings: mfd: pm8008: Add IRQ listing
On Thu 08 Apr 19:38 CDT 2021, Guru Das Srinagesh wrote: > Add a header file listing all of the IRQs that Qualcomm Technologies, > Inc. PM8008 supports. The constants defined in this file may be used in > the client device tree node to specify interrupts. > > Change-Id: I13fb096da54458f2882e8d853a3ad9c379e7d5a9 Please remember to drop the Change-Id when posting to the mailing lists. We typically don't have defines for the IRQ numbers, but I don't mind. Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Guru Das Srinagesh > --- > include/dt-bindings/mfd/qcom-pm8008.h | 19 +++ > 1 file changed, 19 insertions(+) > create mode 100644 include/dt-bindings/mfd/qcom-pm8008.h > > diff --git a/include/dt-bindings/mfd/qcom-pm8008.h > b/include/dt-bindings/mfd/qcom-pm8008.h > new file mode 100644 > index 000..eca9448 > --- /dev/null > +++ b/include/dt-bindings/mfd/qcom-pm8008.h > @@ -0,0 +1,19 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) 2021 The Linux Foundation. All rights reserved. > + */ > + > +#ifndef __DT_BINDINGS_MFD_QCOM_PM8008_H > +#define __DT_BINDINGS_MFD_QCOM_PM8008_H > + > +/* PM8008 IRQ numbers */ > +#define PM8008_IRQ_MISC_UVLO 0 > +#define PM8008_IRQ_MISC_OVLO 1 > +#define PM8008_IRQ_MISC_OTST22 > +#define PM8008_IRQ_MISC_OTST33 > +#define PM8008_IRQ_MISC_LDO_OCP 4 > +#define PM8008_IRQ_TEMP_ALARM5 > +#define PM8008_IRQ_GPIO1 6 > +#define PM8008_IRQ_GPIO2 7 > + > +#endif > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
Re: [PATCH V2 4/4] dt-bindings: rtc: qcom-pm8xxx-rtc: Add qcom pm8xxx rtc bindings
On Fri 09 Apr 08:59 CDT 2021, satya priya wrote:
> Add binding doc for qcom pm8xxx rtc device.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: satya priya
> ---
> Changes in V2:
> - Added this in V2 to have separate binding for rtc node.
>
> .../devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml | 62
> ++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
>
> diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
> b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
> new file mode 100644
> index 000..4fba6db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/qcom-pm8xxx-rtc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm PM8xxx PMIC RTC device
> +
> +maintainers:
> + - Satya Priya
> +
> +properties:
> + compatible:
> +enum:
> + - qcom,pm8058-rtc
> + - qcom,pm8921-rtc
> + - qcom,pm8941-rtc
> + - qcom,pm8018-rtc
> + - qcom,pmk8350-rtc
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + allow-set-time:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> + Indicates that the setting of RTC time is allowed by the host CPU.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +spmi_bus: spmi@c44 {
> + reg = <0x0c44 0x1100>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> + pmicintc: pmic@0 {
> +reg = <0x0 SPMI_USID>;
> +compatible = "qcom,pm8921";
> +interrupts = <104 8>;
> +#interrupt-cells = <2>;
> +interrupt-controller;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +pm8921_rtc: rtc@11d {
> + compatible = "qcom,pm8921-rtc";
> + reg = <0x11d>;
> + interrupts = <0x27 0>;
> +};
> + };
> +};
> +...
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [PATCH V2 3/4] dt-bindings: mfd: Convert pm8xxx bindings to yaml
8xxx.yaml > @@ -0,0 +1,54 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/qcom-pm8xxx.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm PM8xxx PMIC multi-function devices > + > +maintainers: > + - Satya Priya > + > +description: | > + The PM8xxx family of Power Management ICs are used to provide regulated > + voltages and other various functionality to Qualcomm SoCs. > + > +properties: > + compatible: > +enum: > + - qcom,pm8058 > + - qcom,pm8821 > + - qcom,pm8921 > + > + reg: > +maxItems: 1 > + > + '#address-cells': > +const: 1 > + > + '#size-cells': > +const: 0 > + > + interrupts: > +maxItems: 1 > + > + '#interrupt-cells': > +const: 2 > + > + interrupt-controller: true > + > +patternProperties: > + "rtc@[0-9a-f]+$": > +type: object > +$ref: "../rtc/qcom-pm8xxx-rtc.yaml" This doesn't exist, so patch 3 and 4 should come in opposite order... Apart from tat I think this looks good. Reviewed-by: Bjorn Andersson Regards, Bjorn > + > +required: > + - compatible > + - '#address-cells' > + - '#size-cells' > + - interrupts > + - '#interrupt-cells' > + - interrupt-controller > + > +additionalProperties: false > +... > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
Re: [PATCH RESEND v8 7/7] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
On Fri 09 Apr 06:30 CDT 2021, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> named.
>
> Signed-off-by: Serge Semin
> Acked-by: Krzysztof Kozlowski
> Reviewed-by: Bjorn Andersson
As mentioned previously, I would like to merge this through the qcom soc
tree to avoid conflicts with other activities, but need the driver code
(patch 6) to land first.
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
> arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
> arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
> arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
> 9 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> index defcbd15edf9..34e97da98270 100644
> --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> @@ -1064,7 +1064,7 @@ &usb2 {
> status = "okay";
> extcon = <&usb2_id>;
>
> - dwc3@760 {
> + usb@760 {
> extcon = <&usb2_id>;
> dr_mode = "otg";
> maximum-speed = "high-speed";
> @@ -1075,7 +1075,7 @@ &usb3 {
> status = "okay";
> extcon = <&usb3_id>;
>
> - dwc3@6a0 {
> + usb@6a0 {
> extcon = <&usb3_id>;
> dr_mode = "otg";
> };
> diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> index a32e5e79ab0b..7df4eb710aae 100644
> --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> @@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
> resets = <&gcc GCC_USB0_BCR>;
> status = "disabled";
>
> - dwc_0: dwc3@8a0 {
> + dwc_0: usb@8a0 {
> compatible = "snps,dwc3";
> reg = <0x8a0 0xcd00>;
> interrupts = ;
> @@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
> resets = <&gcc GCC_USB1_BCR>;
> status = "disabled";
>
> - dwc_1: dwc3@8c0 {
> + dwc_1: usb@8c0 {
> compatible = "snps,dwc3";
> reg = <0x8c0 0xcd00>;
> interrupts = ;
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index ce430ba9c118..9eb31b3e6ee7 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -1772,7 +1772,7 @@ usb3: usb@6af8800 {
> power-domains = <&gcc USB30_GDSC>;
> status = "disabled";
>
> - dwc3@6a0 {
> + usb@6a0 {
> compatible = "snps,dwc3";
> reg = <0x06a0 0xcc00>;
> interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1983,7 +1983,7 @@ usb2: usb@76f8800 {
> power-domains = <&gcc USB30_GDSC>;
> status = "disabled";
>
> - dwc3@760 {
> + usb@760 {
> compatible = "snps,dwc3";
> reg = <0x0760 0xcc00>;
> interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> index 1f2e93aa6553..9141c5d09b59 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> @@ -1962,7 +1962,7 @@ usb3: usb@a8f8800 {
>
> resets = <&gcc GCC_USB_30_BCR>;
>
> - usb3_dwc3: dwc3@a
Re: [PATCH RESEND v8 6/7] usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string
On Fri 09 Apr 06:30 CDT 2021, Serge Semin wrote:
> In accordance with the USB HCD/DRD schema all the USB controllers are
> supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
> existing DT-nodes will be renamed in a subsequent patch let's fix the DWC3
> Qcom-specific code to detect the DWC3 sub-node just by checking its
> compatible string to match the "snps,dwc3". The semantic of the code
> won't change seeing all the DWC USB3 nodes are supposed to have the
> compatible property with any of those strings set.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Serge Semin
>
> ---
>
> Changelog v7:
> - Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np,
> "dwc3");"
> pattern with using of_get_compatible_child() method.
> - Discard Bjorn Andersson Reviewed-by tag since the patch content
> has been changed.
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index fcaf04483ad0..617a1be88371 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -644,7 +644,7 @@ static int dwc3_qcom_of_register_core(struct
> platform_device *pdev)
> struct device *dev = &pdev->dev;
> int ret;
>
> - dwc3_np = of_get_child_by_name(np, "dwc3");
> + dwc3_np = of_get_compatible_child(np, "snps,dwc3");
> if (!dwc3_np) {
> dev_err(dev, "failed to find dwc3 core child\n");
> return -ENODEV;
> --
> 2.30.1
>
Re: [PATCH 2/2] pinctrl: qcom-pmic-gpio: Add support for pm8008
On Wed 07 Apr 17:35 CDT 2021, Guru Das Srinagesh wrote:
> Add support for the two GPIOs present on PM8008.
>
> Signed-off-by: Guru Das Srinagesh
> ---
> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index c2b9f2e..76e997a 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -1137,6 +1137,7 @@ static const struct of_device_id pmic_gpio_of_match[] =
> {
> { .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
> /* pmx55 has 11 GPIOs with holes on 3, 7, 10, 11 */
> { .compatible = "qcom,pmx55-gpio", .data = (void *) 11 },
> + { .compatible = "qcom,pm8008-gpio", .data = (void *) 2 },
As with the binding, please keep these sorted alphabetically.
With that:
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> { },
> };
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH 1/2] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8008 support
On Wed 07 Apr 17:34 CDT 2021, Guru Das Srinagesh wrote: > Add support for the PM8008 GPIO support to the Qualcomm PMIC GPIO > binding. > > Signed-off-by: Guru Das Srinagesh > --- > Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > index 70e119b..1818481 100644 > --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > @@ -36,6 +36,7 @@ PMIC's from Qualcomm. > "qcom,pm6150-gpio" > "qcom,pm6150l-gpio" > "qcom,pmx55-gpio" > + "qcom,pm8008-gpio" Please keep these sorted alphabetically (i.e. '8' < 'x') With that Acked-by: Bjorn Andersson Regards, Bjorn > > And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" > if the device is on an spmi bus or an ssbi bus respectively > @@ -125,6 +126,7 @@ to specify in a pin configuration subnode: > gpio1-gpio12 for pm6150l > gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 > and gpio11) > + gpio1-gpio2 for pm8008 > > - function: > Usage: required > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
Re: [PATCH 2/3] dt-bindings: mfd: Convert pm8xxx bindings to yaml
On Wed 07 Apr 10:37 CDT 2021, ska...@codeaurora.org wrote: > Hi Bjorn, > > On 2021-03-11 22:33, Bjorn Andersson wrote: > > On Thu 11 Mar 01:29 CST 2021, satya priya wrote: [..] > > > +patternProperties: > > > + "rtc@[0-9a-f]+$": > > > > Can we somehow link this to individual binding docs instead of listing > > all the possible functions here? > > > > you mean we should split this into two: > qcom-pm8xxx.yaml and qcom-pm8xxx-rtc.yaml > Please correct me if wrong. > Right, I'm worried that it will be quite hard to maintain this document once we start adding all the various pmic blocks to it. So if we somehow can maintain a series of qcom-pm8xxx-.yaml and just ref them into the main PMIC definition. @Rob, can you give us some guidance on how to structure this binding, with the various PMICs described will have some defined subset of a larger set of hardware blocks that's often shared between versions? Regards, Bjorn
Re: [PATCH v1 1/1] kernel.h: Split out panic and oops helpers
On Tue 06 Apr 08:31 CDT 2021, Andy Shevchenko wrote: > kernel.h is being used as a dump for all kinds of stuff for a long time. > Here is the attempt to start cleaning it up by splitting out panic and > oops helpers. > > At the same time convert users in header and lib folder to use new header. > Though for time being include new header back to kernel.h to avoid twisted > indirected includes for existing users. > Reviewed-by: Bjorn Andersson Regards, Bjorn
Re: [PATCH 3/7] crypto: qce: Add mode for rfc4309
On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote: > rf4309 is the specification that uses aes ccm algorithms with IPsec > security packets. Add a submode to identify rfc4309 ccm(aes) algorithm > in the crypto driver. > > Signed-off-by: Thara Gopinath > --- > drivers/crypto/qce/common.h | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/crypto/qce/common.h b/drivers/crypto/qce/common.h > index 3bc244bcca2d..3ffe719b79e4 100644 > --- a/drivers/crypto/qce/common.h > +++ b/drivers/crypto/qce/common.h > @@ -51,9 +51,11 @@ > #define QCE_MODE_CCM BIT(12) > #define QCE_MODE_MASKGENMASK(12, 8) > > +#define QCE_MODE_CCM_RFC4309 BIT(13) > + > /* cipher encryption/decryption operations */ > -#define QCE_ENCRYPT BIT(13) > -#define QCE_DECRYPT BIT(14) > +#define QCE_ENCRYPT BIT(14) > +#define QCE_DECRYPT BIT(15) Can't we move these further up, so that next time we want to add something it doesn't require that we also move the ENC/DEC bits? > > #define IS_DES(flags)(flags & QCE_ALG_DES) > #define IS_3DES(flags) (flags & QCE_ALG_3DES) > @@ -73,6 +75,7 @@ > #define IS_CTR(mode) (mode & QCE_MODE_CTR) > #define IS_XTS(mode) (mode & QCE_MODE_XTS) > #define IS_CCM(mode) (mode & QCE_MODE_CCM) > +#define IS_CCM_RFC4309(mode) ((mode) & QCE_MODE_CCM_RFC4309) While leaving room for the typical macro issues, none of the other macros wrap the argument in parenthesis. Please follow the style of the driver, and perhaps follow up with a cleanup patch that just wraps them all in parenthesis? Regards, Bjorn > > #define IS_ENCRYPT(dir) (dir & QCE_ENCRYPT) > #define IS_DECRYPT(dir) (dir & QCE_DECRYPT) > -- > 2.25.1 >
Re: [PATCH 2/7] crypto: qce: common: Make result dump optional
On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> Qualcomm crypto engine allows for IV registers and status register
> to be concatenated to the output. This option is enabled by setting the
> RESULTS_DUMP field in GOPROC register. This is useful for most of the
> algorithms to either retrieve status of operation or in case of
> authentication algorithms to retrieve the mac. But for ccm
> algorithms, the mac is part of the output stream and not retrieved
> from the IV registers, thus needing a separate buffer to retrieve it.
> Make enabling RESULTS_DUMP field optional so that algorithms can choose
> whether or not to enable the option.
> Note that in this patch, the enabled algorithms always choose
> RESULTS_DUMP to be enabled. But later with the introduction of ccm
> algorithms, this changes.
>
> Signed-off-by: Thara Gopinath
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/crypto/qce/common.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> index 7c3cb483749e..2485aa371d83 100644
> --- a/drivers/crypto/qce/common.c
> +++ b/drivers/crypto/qce/common.c
> @@ -88,9 +88,12 @@ static void qce_setup_config(struct qce_device *qce)
> qce_write(qce, REG_CONFIG, config);
> }
>
> -static inline void qce_crypto_go(struct qce_device *qce)
> +static inline void qce_crypto_go(struct qce_device *qce, bool result_dump)
> {
> - qce_write(qce, REG_GOPROC, BIT(GO_SHIFT) | BIT(RESULTS_DUMP_SHIFT));
> + if (result_dump)
> + qce_write(qce, REG_GOPROC, BIT(GO_SHIFT) |
> BIT(RESULTS_DUMP_SHIFT));
> + else
> + qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
> }
>
> #ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> @@ -219,7 +222,7 @@ static int qce_setup_regs_ahash(struct
> crypto_async_request *async_req)
> config = qce_config_reg(qce, 1);
> qce_write(qce, REG_CONFIG, config);
>
> - qce_crypto_go(qce);
> + qce_crypto_go(qce, true);
>
> return 0;
> }
> @@ -380,7 +383,7 @@ static int qce_setup_regs_skcipher(struct
> crypto_async_request *async_req)
> config = qce_config_reg(qce, 1);
> qce_write(qce, REG_CONFIG, config);
>
> - qce_crypto_go(qce);
> + qce_crypto_go(qce, true);
>
> return 0;
> }
> --
> 2.25.1
>
Re: [PATCH 6/7] crypto: qce: common: Add support for AEAD algorithms
On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> Add register programming sequence for enabling AEAD
> algorithms on the Qualcomm crypto engine.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/common.c | 155 +++-
> 1 file changed, 153 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> index 05a71c5ecf61..54d209cb0525 100644
> --- a/drivers/crypto/qce/common.c
> +++ b/drivers/crypto/qce/common.c
> @@ -15,6 +15,16 @@
> #include "core.h"
> #include "regs-v5.h"
> #include "sha.h"
> +#include "aead.h"
> +
> +static const u32 std_iv_sha1[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> + SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4, 0, 0, 0
> +};
> +
> +static const u32 std_iv_sha256[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> + SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
> + SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7
> +};
>
> static inline u32 qce_read(struct qce_device *qce, u32 offset)
> {
> @@ -96,7 +106,7 @@ static inline void qce_crypto_go(struct qce_device *qce,
> bool result_dump)
> qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
> }
>
> -#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> +#if defined(CONFIG_CRYPTO_DEV_QCE_SHA) || defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> static u32 qce_auth_cfg(unsigned long flags, u32 key_size, u32 auth_size)
> {
> u32 cfg = 0;
> @@ -139,7 +149,9 @@ static u32 qce_auth_cfg(unsigned long flags, u32
> key_size, u32 auth_size)
>
> return cfg;
> }
> +#endif
>
> +#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> static int qce_setup_regs_ahash(struct crypto_async_request *async_req)
> {
> struct ahash_request *req = ahash_request_cast(async_req);
> @@ -225,7 +237,7 @@ static int qce_setup_regs_ahash(struct
> crypto_async_request *async_req)
> }
> #endif
>
> -#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> +#if defined(CONFIG_CRYPTO_DEV_QCE_SKCIPHER) ||
> defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> static u32 qce_encr_cfg(unsigned long flags, u32 aes_key_size)
> {
> u32 cfg = 0;
> @@ -271,7 +283,9 @@ static u32 qce_encr_cfg(unsigned long flags, u32
> aes_key_size)
>
> return cfg;
> }
> +#endif
>
> +#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> static void qce_xts_swapiv(__be32 *dst, const u8 *src, unsigned int ivsize)
> {
> u8 swap[QCE_AES_IV_LENGTH];
> @@ -386,6 +400,139 @@ static int qce_setup_regs_skcipher(struct
> crypto_async_request *async_req)
> }
> #endif
>
> +#ifdef CONFIG_CRYPTO_DEV_QCE_AEAD
> +static int qce_setup_regs_aead(struct crypto_async_request *async_req)
> +{
> + struct aead_request *req = aead_request_cast(async_req);
> + struct qce_aead_reqctx *rctx = aead_request_ctx(req);
> + struct qce_aead_ctx *ctx = crypto_tfm_ctx(async_req->tfm);
> + struct qce_alg_template *tmpl = to_aead_tmpl(crypto_aead_reqtfm(req));
> + struct qce_device *qce = tmpl->qce;
> + __be32 enckey[QCE_MAX_CIPHER_KEY_SIZE / sizeof(__be32)] = {0};
> + __be32 enciv[QCE_MAX_IV_SIZE / sizeof(__be32)] = {0};
> + __be32 authkey[QCE_SHA_HMAC_KEY_SIZE / sizeof(__be32)] = {0};
> + __be32 authiv[SHA256_DIGEST_SIZE / sizeof(__be32)] = {0};
> + __be32 authnonce[QCE_MAX_NONCE / sizeof(__be32)] = {0};
> + unsigned int enc_keylen = ctx->enc_keylen;
> + unsigned int auth_keylen = ctx->auth_keylen;
> + unsigned int enc_ivsize = rctx->ivsize;
> + unsigned int auth_ivsize;
> + unsigned int enckey_words, enciv_words;
> + unsigned int authkey_words, authiv_words, authnonce_words;
> + unsigned long flags = rctx->flags;
> + u32 encr_cfg = 0, auth_cfg = 0, config, totallen;
I don't see any reason to initialize encr_cfg or auth_cfg.
> + u32 *iv_last_word;
> +
> + qce_setup_config(qce);
> +
> + /* Write encryption key */
> + qce_cpu_to_be32p_array(enckey, ctx->enc_key, enc_keylen);
> + enckey_words = enc_keylen / sizeof(u32);
> + qce_write_array(qce, REG_ENCR_KEY0, (u32 *)enckey, enckey_words);
Afaict all "array registers" in this function are affected by the
CRYPTO_SETUP little endian bit, but you set this bit before launching
the operation dependent on IS_CCM(). So is this really working for the
!IS_CCM() case?
> +
> + /* Write encryption iv */
> + qce_cpu_to_be32p_array(enciv, rctx->iv, enc_ivsize);
> + enciv_words = enc_ivsize / sizeof(u32);
> + qce_write_array(qce, REG_CNTR0_IV0, (u32 *)enciv, enciv_words);
It would be nice if this snippet was extracted to a helper function.
> +
> + if (IS_CCM(rctx->flags)) {
> + iv_last_word = (u32 *)&enciv[enciv_words - 1];
> +// qce_write(qce, REG_CNTR3_IV3, enciv[enciv_words - 1] + 1);
I believe this is a remnant of the two surrounding lines.
> + qce_write(qce, REG_CNTR3_IV3, (*iv_last_word) + 1);
enciv is an array of big endian 32-bit integers, which you tell the
compiler to treat as cpu-native endian, and then you do math on it.
Afaict from the documentation the value of
Re: [PATCH 1/7] crypto: qce: common: Add MAC failed error checking
On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> MAC_FAILED gets set in the status register if authenthication fails
> for ccm algorithms(during decryption). Add support to catch and flag
> this error.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/common.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> index dceb9579d87a..7c3cb483749e 100644
> --- a/drivers/crypto/qce/common.c
> +++ b/drivers/crypto/qce/common.c
> @@ -403,7 +403,8 @@ int qce_start(struct crypto_async_request *async_req, u32
> type)
> }
>
> #define STATUS_ERRORS\
> - (BIT(SW_ERR_SHIFT) | BIT(AXI_ERR_SHIFT) | BIT(HSD_ERR_SHIFT))
> + (BIT(SW_ERR_SHIFT) | BIT(AXI_ERR_SHIFT) | \
> + BIT(HSD_ERR_SHIFT) | BIT(MAC_FAILED_SHIFT))
>
> int qce_check_status(struct qce_device *qce, u32 *status)
> {
> @@ -417,8 +418,12 @@ int qce_check_status(struct qce_device *qce, u32 *status)
>* use result_status from result dump the result_status needs to be byte
>* swapped, since we set the device to little endian.
>*/
> - if (*status & STATUS_ERRORS || !(*status & BIT(OPERATION_DONE_SHIFT)))
> - ret = -ENXIO;
> + if (*status & STATUS_ERRORS || !(*status & BIT(OPERATION_DONE_SHIFT))) {
> + if (*status & BIT(MAC_FAILED_SHIFT))
Afaict MAC_FAILED indicates a different category of errors from the
others. So I would prefer that the conditionals are flattened.
Is OPERATION_DONE set when MAC_FAILED?
If so:
if (errors || !done)
return -ENXIO;
else if (*status & BIT(MAC_FAILED))
return -EBADMSG;
Would be cleaner in my opinion.
Regards,
Bjorn
> + ret = -EBADMSG;
> + else
> + ret = -ENXIO;
> + }
>
> return ret;
> }
> --
> 2.25.1
>
Re: [PATCH RESEND] arm64: dts: qcom: Add support for OnePlus 5/5T
On Mon 22 Mar 11:16 CDT 2021, Jami Kettunen wrote:
[..]
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
> b/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
> new file mode 100644
> index ..13b6b8ad4679
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0
The DT community prefer to get these under BSD-3-Clause instead? Would
you be willing to change this?
> +/*
> + * OnePlus 5 (cheeseburger) device tree
> + *
> + * Copyright (c) 2021, Jami Kettunen
> + */
> +
[..]
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi
> b/arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi
[..]
> +/* Disable all remoteprocs for now until RPM XO clock is usable */
> +&remoteproc_mss {
Can you please disable this in msm8998.dtsi and make devices explicitly
enable it instead - in a separate patch.
> + status = "disabled";
> +};
> +
[..]
> +/* Hold off on WLAN enablement until MSS remoteproc and friends are brought
> up */
Are you saying leave disabled until MSS is up?
If so then move the comment inside the node and make it something like
"Leave disabled until MSS is functional" - to make it clearer that this
relates to the "status" of the node.
Regards,
Bjorn
> +&wifi {
> + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
> + vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
> b/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
> new file mode 100644
> index ..b46214a32478
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * OnePlus 5T (dumpling) device tree
> + *
> + * Copyright (c) 2021, Jami Kettunen
> + */
> +
> +#include "msm8998-oneplus-common.dtsi"
> +
> +/ {
> + model = "OnePlus 5T";
> + compatible = "oneplus,dumpling", "qcom,msm8998";
> + /* Required for bootloader to select correct board */
> + qcom,board-id = <8 0 17801 43>;
> +};
> +
> +/* Update the screen height values from 1920 to 2160 on the 5T */
> +&framebuffer0 {
> + height = <2160>;
> +};
> +
> +/* Adjust digitizer area height to match the 5T's taller panel */
> +&rmi4_f12 {
> + touchscreen-y-mm = <137>;
> +};
> --
> 2.30.1
>
Re: [PATCH V2 0/5] Add PMIC DT files for sc7280
On Thu 01 Apr 04:13 CDT 2021, satya priya wrote: > Changes in V2: > - As per Matthias's comments: > - I've Split the patch into per-PMIC patches and one sc7280 patch > - Removed 2nd critical point, thermal-governer property > - s/pm8325_tz/pm7325_temp_alarm and s/pm7325_temp_alarm/pm7325_thermal > - Fixed few other minor errors. > > - As per Bjorn's comments, replaced '_' with '-' in node names and moved >DT files inclusion to board dts. > > This series is dependent on below series which adds DT files for SC7280 SoC > https://lore.kernel.org/patchwork/project/lkml/list/?series=488871 No need to mention this dependency, as you posted this after said series had been picked up. However, also picked up are patches from Vinod adding initial pm8350c and pmk8350 files, so please rebase you changes onto linux-next - in addition to follow up on Matthias feedback. Thanks, Bjorn > > satya priya (5): > arm64: dts: qcom: pm7325: Add PMIC peripherals for pm7325 > arm64: dts: qcom: pm8350c: Add PMIC peripherals for pm8350c > arm64: dts: qcom: pmk8350: Add PMIC peripherals for pmk8350 > arm64: dts: qcom: pmr735a: Add PMIC peripherals for pmr735a > arm64: dts: sc7280: Include PMIC DT files for sc7280 > > arch/arm64/boot/dts/qcom/pm7325.dtsi| 53 + > arch/arm64/boot/dts/qcom/pm8350c.dtsi | 53 + > arch/arm64/boot/dts/qcom/pmk8350.dtsi | 100 > > arch/arm64/boot/dts/qcom/pmr735a.dtsi | 53 + > arch/arm64/boot/dts/qcom/sc7280-idp.dts | 4 ++ > arch/arm64/boot/dts/qcom/sc7280.dtsi| 3 + > 6 files changed, 266 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/pm7325.dtsi > create mode 100644 arch/arm64/boot/dts/qcom/pm8350c.dtsi > create mode 100644 arch/arm64/boot/dts/qcom/pmk8350.dtsi > create mode 100644 arch/arm64/boot/dts/qcom/pmr735a.dtsi > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
Re: [PATCH V1 0/2] soc: qcom: aoss: Expose send for generic usecase
On Fri 02 Apr 01:17 CDT 2021, Deepak Kumar Singh wrote: > [Change from V0] It's typical that the first patchset, without a version specified, is considered "version 1", and as such the second submission would be "v2". > Update qmp_get to parse qmp handle with binding qcom,qmp > I won't be able to merge this until we have a user of the API, so would it be possible to get at least one consumer introduced? Regards, Bjorn > Deepak Kumar Singh (2): > soc: qcom: aoss: Expose send for generic usecase > soc: qcom: aoss: Add debugfs entry > > drivers/soc/qcom/qcom_aoss.c | 77 > +++- > 1 file changed, 76 insertions(+), 1 deletion(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
Re: [PATCH V1 1/2] soc: qcom: aoss: Expose send for generic usecase
On Fri 02 Apr 01:17 CDT 2021, Deepak Kumar Singh wrote:
> Not all upcoming usecases will have an interface to allow the aoss
> driver to hook onto. Expose the send api and create a get function to
> enable drivers to send their own messages to aoss.
>
> Signed-off-by: Chris Lew
> Signed-off-by: Deepak Kumar Singh
> ---
> drivers/soc/qcom/qcom_aoss.c | 36 +++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
> index 53acb94..5c643f0 100644
> --- a/drivers/soc/qcom/qcom_aoss.c
> +++ b/drivers/soc/qcom/qcom_aoss.c
> @@ -8,10 +8,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
I believe you forgot to 'git add' this.
>
> #define QMP_DESC_MAGIC 0x0
> #define QMP_DESC_VERSION 0x4
> @@ -223,11 +225,14 @@ static bool qmp_message_empty(struct qmp *qmp)
> *
> * Return: 0 on success, negative errno on failure
> */
> -static int qmp_send(struct qmp *qmp, const void *data, size_t len)
> +int qmp_send(struct qmp *qmp, const void *data, size_t len)
> {
> long time_left;
> int ret;
>
> + if (!qmp || !data)
I don't see a legit use case where these are NULL, so there's probably a
developer staring at the kernel log wondering why their code isn't
working. So better wrap this in a WARN_ON() to help him/her.
Also, a developer failing to check the return value of qmp_get() would
get here with qmp being -ENODEV, -EINVAL or -EPROBE_DEFER. Which we
would gladly dereference in the next conditional. So rather than !qmp,
IS_ERR_OR_NULL(qmp) would be useful.
> + return -EINVAL;
> +
> if (WARN_ON(len + sizeof(u32) > qmp->size))
> return -EINVAL;
>
> @@ -261,6 +266,7 @@ static int qmp_send(struct qmp *qmp, const void *data,
> size_t len)
>
> return ret;
> }
> +EXPORT_SYMBOL(qmp_send);
>
> static int qmp_qdss_clk_prepare(struct clk_hw *hw)
> {
> @@ -515,6 +521,34 @@ static void qmp_cooling_devices_remove(struct qmp *qmp)
> thermal_cooling_device_unregister(qmp->cooling_devs[i].cdev);
> }
>
> +/**
> + * qmp_get() - get a qmp handle from a device
> + * @dev: client device pointer
> + *
> + * Return: handle to qmp device on success, ERR_PTR() on failure
> + */
> +struct qmp *qmp_get(struct device *dev)
> +{
> + struct platform_device *pdev;
> + struct device_node *np;
> + struct qmp *qmp;
> +
> + if (!dev || !dev->of_node)
> + return ERR_PTR(-ENODEV);
Value of @dev is an invalid argument, so I think -EINVAL is suitable.
> +
> + np = of_parse_phandle(dev->of_node, "qcom,qmp", 0);
> + if (!np)
> + return ERR_PTR(-ENODEV);
> +
> + pdev = of_find_device_by_node(np);
of_find_device_by_node() will increment the refcount of the underlying
struct device of pdev, so you need to platform_device_put() once you're
done with it.
As a side effect of not putting the struct device, the devm_kzalloc'ed
qmp pointer will remain valid. So care is needed to make sure that the
client doesn't end up with a dangling pointer if the qmp device is
removed.
My suggestion is that you add a "qmp_put()" function, which invokes
platform_device_put() and that you add some sort of tracking ("bool
orphan"?) to the struct qmp and make qmp_send() fail if this is set.
That way if someone unbinds the aoss device, the client will still have
a "valid" pointer, but won't be able to qmp_send() after qmp_close() has
been called in the aoss remove function.
Regards,
Bjorn
> + if (!pdev)
> + return ERR_PTR(-EINVAL);
> +
> + qmp = platform_get_drvdata(pdev);
> + return qmp ? qmp : ERR_PTR(-EPROBE_DEFER);
> +}
> +EXPORT_SYMBOL(qmp_get);
> +
> static int qmp_probe(struct platform_device *pdev)
> {
> struct resource *res;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH V1 2/2] soc: qcom: aoss: Add debugfs entry
On Fri 02 Apr 01:17 CDT 2021, Deepak Kumar Singh wrote:
> It can be useful to control the different power states of various
> parts of hardware for device testing. Add a debugfs node for qmp so
> messages can be sent to aoss for debugging and testing purposes.
>
> Signed-off-by: Chris Lew
> Signed-off-by: Deepak Kumar Singh
> ---
> drivers/soc/qcom/qcom_aoss.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
> index 5c643f0..1789880 100644
> --- a/drivers/soc/qcom/qcom_aoss.c
> +++ b/drivers/soc/qcom/qcom_aoss.c
> @@ -4,6 +4,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -86,6 +87,9 @@ struct qmp {
> struct clk_hw qdss_clk;
> struct genpd_onecell_data pd_data;
> struct qmp_cooling_device *cooling_devs;
> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> + struct dentry *debugfs_file;
> +#endif /* CONFIG_DEBUG_FS */
> };
>
> struct qmp_pd {
> @@ -549,6 +553,34 @@ struct qmp *qmp_get(struct device *dev)
> }
> EXPORT_SYMBOL(qmp_get);
>
> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> +static ssize_t aoss_dbg_write(struct file *file, const char __user *userstr,
> + size_t len, loff_t *pos)
> +{
> + struct qmp *qmp = file->private_data;
> + char buf[QMP_MSG_LEN] = {};
> + int ret;
> +
> + if (!len || len >= QMP_MSG_LEN)
> + return len;
If len >= QMP_MSG_LEN we shouldn't lie to the caller and say that all
went well, better return -EINVAL in this case.
> +
> + ret = copy_from_user(buf, userstr, len);
> + if (ret) {
> + dev_err(qmp->dev, "copy from user failed, ret:%d\n", ret);
> + return len;
return -EFAULT;
And you don't have to print here.
The rest looks good.
Regards,
Bjorn
> + }
> +
> + ret = qmp_send(qmp, buf, QMP_MSG_LEN);
> +
> + return ret ? ret : len;
> +}
> +
> +static const struct file_operations aoss_dbg_fops = {
> + .open = simple_open,
> + .write = aoss_dbg_write,
> +};
> +#endif /* CONFIG_DEBUG_FS */
> +
> static int qmp_probe(struct platform_device *pdev)
> {
> struct resource *res;
> @@ -603,6 +635,11 @@ static int qmp_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, qmp);
>
> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> + qmp->debugfs_file = debugfs_create_file("aoss_send_message", 0220, NULL,
> + qmp, &aoss_dbg_fops);
> +#endif /* CONFIG_DEBUG_FS */
> +
> return 0;
>
> err_remove_qdss_clk:
> @@ -619,6 +656,10 @@ static int qmp_remove(struct platform_device *pdev)
> {
> struct qmp *qmp = platform_get_drvdata(pdev);
>
> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> + debugfs_remove(qmp->debugfs_file);
> +#endif /* CONFIG_DEBUG_FS */
> +
> qmp_qdss_clk_remove(qmp);
> qmp_pd_remove(qmp);
> qmp_cooling_devices_remove(qmp);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH v2] thermal/drivers/tsens: fix missing put_device error
On Sun 04 Apr 07:54 CDT 2021, zhuguangqin...@gmail.com wrote:
> From: Guangqing Zhu
>
> Fixes coccicheck error:
>
> drivers/thermal/qcom/tsens.c:759:4-10: ERROR: missing put_device; call
> of_find_device_by_node on line 715, but without a corresponding object
> release within this function.
>
> Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into
> tsens.c")
>
> Signed-off-by: Guangqing Zhu
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> v2:
> - Fix a error(missing a bracket) in v1.
>
> ---
> drivers/thermal/qcom/tsens.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index d8ce3a687b80..3c4c0516e58a 100644
> --- a/drivers/thermal/qcom/tsens.c
> +++ b/drivers/thermal/qcom/tsens.c
> @@ -755,8 +755,10 @@ int __init init_common(struct tsens_priv *priv)
> for (i = VER_MAJOR; i <= VER_STEP; i++) {
> priv->rf[i] = devm_regmap_field_alloc(dev,
> priv->srot_map,
> priv->fields[i]);
> - if (IS_ERR(priv->rf[i]))
> - return PTR_ERR(priv->rf[i]);
> + if (IS_ERR(priv->rf[i])) {
> + ret = PTR_ERR(priv->rf[i]);
> + goto err_put_device;
> + }
> }
> ret = regmap_field_read(priv->rf[VER_MINOR], &ver_minor);
> if (ret)
> --
> 2.17.1
>
Re: [PATCH V2 3/3] scsi: ufs-qcom: configure VCC voltage level in vendor file
On Thu 01 Apr 09:58 CDT 2021, nitir...@codeaurora.org wrote:
> On 2021-03-31 23:49, Bjorn Andersson wrote:
> > On Wed 24 Mar 16:55 CDT 2021, nitir...@codeaurora.org wrote:
> >
> > > On 2021-03-23 20:58, Bjorn Andersson wrote:
> > > > On Sun 21 Mar 16:57 CDT 2021, Nitin Rawat wrote:
> > > >
> > > > > As a part of vops handler, VCC voltage is updated
> > > > > as per the ufs device probed after reading the device
> > > > > descriptor. We follow below steps to configure voltage
> > > > > level.
> > > > >
> > > > > 1. Set the device to SLEEP state.
> > > > > 2. Disable the Vcc Regulator.
> > > > > 3. Set the vcc voltage according to the device type and reenable
> > > > >the regulator.
> > > > > 4. Set the device mode back to ACTIVE.
> > > > >
> > > >
> > > > When we discussed this a while back this was described as a requirement
> > > > from the device specification, you only operate on objects "owned" by
> > > > ufshcd and you invoke ufshcd operations to perform the actions.
> > > >
> > > > So why is this a ufs-qcom patch and not something in ufshcd?
> > > >
> > > > Regards,
> > > > Bjorn
> > > >
> > > > > Signed-off-by: Nitin Rawat
> > > > > Signed-off-by: Veerabhadrarao Badiganti
> > > > > ---
> > > > > drivers/scsi/ufs/ufs-qcom.c | 51
> > > > > +
> > > > > 1 file changed, 51 insertions(+)
> > > > >
> > > > > diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> > > > > index f97d7b0..ca35f5c 100644
> > > > > --- a/drivers/scsi/ufs/ufs-qcom.c
> > > > > +++ b/drivers/scsi/ufs/ufs-qcom.c
> > > > > @@ -21,6 +21,17 @@
> > > > > #define UFS_QCOM_DEFAULT_DBG_PRINT_EN\
> > > > > (UFS_QCOM_DBG_PRINT_REGS_EN | UFS_QCOM_DBG_PRINT_TEST_BUS_EN)
> > > > >
> > > > > +#define ANDROID_BOOT_DEV_MAX30
> > > > > +static char android_boot_dev[ANDROID_BOOT_DEV_MAX];
> > > > > +
> > > > > +/* Min and Max VCC voltage values for ufs 2.x and
> > > > > + * ufs 3.x devices
> > > > > + */
> > > > > +#define UFS_3X_VREG_VCC_MIN_UV 254 /* uV */
> > > > > +#define UFS_3X_VREG_VCC_MAX_UV 270 /* uV */
> > > > > +#define UFS_2X_VREG_VCC_MIN_UV 295 /* uV */
> > > > > +#define UFS_2X_VREG_VCC_MAX_UV 296 /* uV */
> > > > > +
> > > > > enum {
> > > > > TSTBUS_UAWM,
> > > > > TSTBUS_UARM,
> > > > > @@ -1293,6 +1304,45 @@ static void
> > > > > ufs_qcom_print_hw_debug_reg_all(struct ufs_hba *hba,
> > > > > print_fn(hba, reg, 9, "UFS_DBG_RD_REG_TMRLUT ", priv);
> > > > > }
> > > > >
> > > > > + /**
> > > > > + * ufs_qcom_setup_vcc_regulators - Update VCC voltage
> > > > > + * @hba: host controller instance
> > > > > + * Update VCC voltage based on UFS device(ufs 2.x or
> > > > > + * ufs 3.x probed)
> > > > > + */
> > > > > +static int ufs_qcom_setup_vcc_regulators(struct ufs_hba *hba)
> > > > > +{
> > > > > + struct ufs_dev_info *dev_info = &hba->dev_info;
> > > > > + struct ufs_vreg *vreg = hba->vreg_info.vcc;
> > > > > + int ret;
> > > > > +
> > > > > + /* Put the device in sleep before lowering VCC level */
> > > > > + ret = ufshcd_set_dev_pwr_mode(hba, UFS_SLEEP_PWR_MODE);
> > > > > +
> > > > > + /* Switch off VCC before switching it ON at 2.5v or 2.96v */
> > > > > + ret = ufshcd_disable_vreg(hba->dev, vreg);
> > > > > +
> > > > > + /* add ~2ms delay before renabling VCC at lower voltage */
> > > > > + usleep_range(2000, 2100);
> > > > > +
> > > > > + /* set VCC min and max voltage according to ufs device type */
> > > > > + if (dev_info->wspecversion >= 0x300) {
> > > > > + vreg->min_uV = UFS_3X_VREG_VCC_MIN_UV;
> > > > > + vreg->max_uV = UFS_3X_VREG_VCC_MAX_UV;
> >
Re: [PATCH V2 1/3] pinctrl: qcom: spmi-gpio: Add support for four variants
On Thu 01 Apr 07:35 CDT 2021, satya priya wrote:
> Add PM7325, PM8350c, PMK8350 and PMR735A compatibles for GPIO
> support.
>
> Signed-off-by: satya priya
> Acked-by: Bjorn Andersson
> ---
> Changes in V2:
> - No change.
>
> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index 9801c71..90f4f78 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -1131,6 +1131,10 @@ static const struct of_device_id pmic_gpio_of_match[]
> = {
> { .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
> /* pmx55 has 11 GPIOs with holes on 3, 7, 10, 11 */
> { .compatible = "qcom,pmx55-gpio", .data = (void *) 11 },
> + { .compatible = "qcom,pm7325-gpio", .data = (void *) 10 },
> + { .compatible = "qcom,pm8350c-gpio", .data = (void *) 9 },
> + { .compatible = "qcom,pmk8350-gpio", .data = (void *) 4 },
Please try to keep the list sorted alphabetically, that way you'd see
that linux-next already has pm8350c and pmk8350 defined - or at least
Linus would notice when he tries to apply your patch.
Regards,
Bjorn
> + { .compatible = "qcom,pmr735a-gpio", .data = (void *) 4 },
> { },
> };
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [PATCH V2 2/3] dt-bindings: pinctrl: qcom-pmic-gpio: Update the binding to add four new variants
On Thu 01 Apr 07:35 CDT 2021, satya priya wrote: > Update the binding to add PM7325, PM8350C, PMK8350 and PMR735A GPIO support. > > Signed-off-by: satya priya > --- > Changes in V2: > - Placed this patch before conversion patch and updated commit text >to be more clear. > > Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > index 7648ab0..da7c35e 100644 > --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > @@ -30,6 +30,10 @@ PMIC's from Qualcomm. > "qcom,pm6150-gpio" > "qcom,pm6150l-gpio" > "qcom,pmx55-gpio" > + "qcom,pm7325-gpio" > + "qcom,pm8350c-gpio" > + "qcom,pmk8350-gpio" > + "qcom,pmr735a-gpio" As with the driver, please try to keep these sorted alphabetically and please rebase on linux-next, which already defines 2 of these. Regards, Bjorn > > And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" > if the device is on an spmi bus or an ssbi bus respectively > @@ -113,6 +117,10 @@ to specify in a pin configuration subnode: > gpio1-gpio12 for pm6150l > gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 > and gpio11) > + gpio1-gpio10 for pm7325 > + gpio1-gpio9 for pm8350c > + gpio1-gpio4 for pmk8350 > + gpio1-gpio4 for pmr735a > > - function: > Usage: required > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM
On Tue 23 Mar 17:43 CDT 2021, Stephen Boyd wrote:
> These scm calls are never used outside of legacy ARMv7 based platforms.
> That's because PSCI, mandated on arm64, implements them for modern SoCs
> via the PSCI spec. Let's move them to the legacy file and only compile
> the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> stubs and fail the calls. This saves a little bit of space in an
> arm64 allmodconfig.
>
> $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> add/remove: 0/8 grow/shrink: 5/6 up/down: 509/-4401 (-3892)
> Function old new delta
> __qcom_scm_set_dload_mode.constprop 312 452+140
> qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
> qcom_scm_io_writel 288 408+120
> qcom_scm_io_readl376 492+116
> __param_str_download_mode 23 28 +5
> __warned43274326 -1
> e843419@0b3f_00010432_324 8 - -8
> qcom_scm_call228 208 -20
> CSWTCH 59255877 -48
> _sub_I_65535_1163100 163040 -60
> _sub_D_65535_0163100 163040 -60
> qcom_scm_wb 64 - -64
> qcom_scm_lock320 160-160
> qcom_scm_call_atomic 212 --212
> qcom_scm_cpu_power_down 308 --308
> scm_legacy_call_atomic 520 --520
> qcom_scm_set_warm_boot_addr 720 --720
> qcom_scm_set_cold_boot_addr 728 --728
> scm_legacy_call 1492 - -1492
> Total: Before=66737606, After=66733714, chg -0.01%
>
> Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> legacy conventions") didn't mention any motivating factors for keeping
> the legacy code around on arm64 kernels, i.e. presumably that commit
> wasn't trying to support these legacy APIs on arm64 kernels.
>
> Cc: Elliot Berman
> Cc: Brian Masney
> Cc: Stephan Gerhold
> Cc: Jeffrey Hugo
> Cc: Douglas Anderson
> Signed-off-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
>
> Followup to v1
> (https://lore.kernel.org/r/20210223214539.1336155-7-swb...@chromium.org):
> * Don't change the legacy file to use legacy calls only
> * Wrap more things in CONFIG_ARM checks
>
> drivers/firmware/Makefile | 4 +++-
> drivers/firmware/qcom_scm.c | 47 -
> drivers/firmware/qcom_scm.h | 15
> include/linux/qcom_scm.h| 21 ++---
> 4 files changed, 56 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
> index 5e013b6a3692..0b7b3a6c 100644
> --- a/drivers/firmware/Makefile
> +++ b/drivers/firmware/Makefile
> @@ -17,7 +17,9 @@ obj-$(CONFIG_ISCSI_IBFT)+= iscsi_ibft.o
> obj-$(CONFIG_FIRMWARE_MEMMAP)+= memmap.o
> obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
> obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o
> -obj-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o
> qcom_scm-legacy.o
> +obj-$(CONFIG_QCOM_SCM) += qcom_scm_objs.o
> +qcom_scm_objs-$(CONFIG_ARM) += qcom_scm-legacy.o
> +qcom_scm_objs-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o
> obj-$(CONFIG_TI_SCI_PROTOCOL)+= ti_sci.o
> obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
> obj-$(CONFIG_TURRIS_MOX_RWTM)+= turris-mox-rwtm.o
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index ee9cb545e73b..747808a8ddf4 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -49,28 +49,6 @@ struct qcom_scm_mem_map_info {
> __le64 mem_size;
> };
>
> -#define QCOM_SCM_FLAG_COLDBOOT_CPU0 0x00
> -#define QCOM_SCM_FLAG_COLDBOOT_CPU1 0x01
> -#define QCOM_SCM_FLAG_COLDBOOT_CPU2 0x08
> -#define QCOM_SCM_FLAG_COLDBOOT_CPU3 0x20
> -
> -#define QCOM_SCM_FLAG_WARMBOOT_CPU0 0x04
> -#define QCOM_SCM_FLAG_WARMBOOT_CPU1 0x02
> -#define QCOM_SCM_FLAG_WARMBOOT_CPU2 0x10
> -#define QCOM_SCM_FLAG_WARMBOOT_CPU3 0x40
> -
> -struct qcom_scm_wb_entry {
> - int flag;
> - void *entry;
> -};
> -
> -static struct qcom_scm_wb_entry qcom_scm_wb[] = {
> - { .flag = QCOM_SCM_FLAG_WARMBOOT_CPU0 },
> - { .flag = QCOM_SCM_FLAG_WARMBOOT_CPU1 },
> - { .flag = QCOM_S
Re: [PATCH][next] soundwire: qcom: Fix a u8 comparison with less than zero
On Wed 31 Mar 09:09 CDT 2021, Colin King wrote:
> From: Colin Ian King
>
> Variable devnum is being checked for a less than zero error return
> however the comparison will always be false because devnum is an 8 bit
> unsigned integer. Fix this by making devnum an int. Also there is no
> need to iniitialize devnum with zero as this value is no read, so
> remove the redundant assignment.
>
> Addresses-Coverity: ("Unsigned compared against 0")
> Fixes: c7d49c76d1d5 ("soundwire: qcom: add support to new interrupts")
> Signed-off-by: Colin Ian King
Reviewed-by: Bjorn Andersson
> ---
> drivers/soundwire/qcom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
> index b08ecb9b418c..ec86c4e53fdb 100644
> --- a/drivers/soundwire/qcom.c
> +++ b/drivers/soundwire/qcom.c
> @@ -428,7 +428,7 @@ static irqreturn_t qcom_swrm_irq_handler(int irq, void
> *dev_id)
> struct qcom_swrm_ctrl *swrm = dev_id;
> u32 value, intr_sts, intr_sts_masked, slave_status;
> u32 i;
> - u8 devnum = 0;
> + int devnum;
> int ret = IRQ_HANDLED;
>
> swrm->reg_read(swrm, SWRM_INTERRUPT_STATUS, &intr_sts);
> --
> 2.30.2
>
Re: [PATCH V2 3/3] scsi: ufs-qcom: configure VCC voltage level in vendor file
On Wed 24 Mar 16:55 CDT 2021, nitir...@codeaurora.org wrote:
> On 2021-03-23 20:58, Bjorn Andersson wrote:
> > On Sun 21 Mar 16:57 CDT 2021, Nitin Rawat wrote:
> >
> > > As a part of vops handler, VCC voltage is updated
> > > as per the ufs device probed after reading the device
> > > descriptor. We follow below steps to configure voltage
> > > level.
> > >
> > > 1. Set the device to SLEEP state.
> > > 2. Disable the Vcc Regulator.
> > > 3. Set the vcc voltage according to the device type and reenable
> > >the regulator.
> > > 4. Set the device mode back to ACTIVE.
> > >
> >
> > When we discussed this a while back this was described as a requirement
> > from the device specification, you only operate on objects "owned" by
> > ufshcd and you invoke ufshcd operations to perform the actions.
> >
> > So why is this a ufs-qcom patch and not something in ufshcd?
> >
> > Regards,
> > Bjorn
> >
> > > Signed-off-by: Nitin Rawat
> > > Signed-off-by: Veerabhadrarao Badiganti
> > > ---
> > > drivers/scsi/ufs/ufs-qcom.c | 51
> > > +
> > > 1 file changed, 51 insertions(+)
> > >
> > > diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> > > index f97d7b0..ca35f5c 100644
> > > --- a/drivers/scsi/ufs/ufs-qcom.c
> > > +++ b/drivers/scsi/ufs/ufs-qcom.c
> > > @@ -21,6 +21,17 @@
> > > #define UFS_QCOM_DEFAULT_DBG_PRINT_EN\
> > > (UFS_QCOM_DBG_PRINT_REGS_EN | UFS_QCOM_DBG_PRINT_TEST_BUS_EN)
> > >
> > > +#define ANDROID_BOOT_DEV_MAX30
> > > +static char android_boot_dev[ANDROID_BOOT_DEV_MAX];
> > > +
> > > +/* Min and Max VCC voltage values for ufs 2.x and
> > > + * ufs 3.x devices
> > > + */
> > > +#define UFS_3X_VREG_VCC_MIN_UV 254 /* uV */
> > > +#define UFS_3X_VREG_VCC_MAX_UV 270 /* uV */
> > > +#define UFS_2X_VREG_VCC_MIN_UV 295 /* uV */
> > > +#define UFS_2X_VREG_VCC_MAX_UV 296 /* uV */
> > > +
> > > enum {
> > > TSTBUS_UAWM,
> > > TSTBUS_UARM,
> > > @@ -1293,6 +1304,45 @@ static void
> > > ufs_qcom_print_hw_debug_reg_all(struct ufs_hba *hba,
> > > print_fn(hba, reg, 9, "UFS_DBG_RD_REG_TMRLUT ", priv);
> > > }
> > >
> > > + /**
> > > + * ufs_qcom_setup_vcc_regulators - Update VCC voltage
> > > + * @hba: host controller instance
> > > + * Update VCC voltage based on UFS device(ufs 2.x or
> > > + * ufs 3.x probed)
> > > + */
> > > +static int ufs_qcom_setup_vcc_regulators(struct ufs_hba *hba)
> > > +{
> > > + struct ufs_dev_info *dev_info = &hba->dev_info;
> > > + struct ufs_vreg *vreg = hba->vreg_info.vcc;
> > > + int ret;
> > > +
> > > + /* Put the device in sleep before lowering VCC level */
> > > + ret = ufshcd_set_dev_pwr_mode(hba, UFS_SLEEP_PWR_MODE);
> > > +
> > > + /* Switch off VCC before switching it ON at 2.5v or 2.96v */
> > > + ret = ufshcd_disable_vreg(hba->dev, vreg);
> > > +
> > > + /* add ~2ms delay before renabling VCC at lower voltage */
> > > + usleep_range(2000, 2100);
> > > +
> > > + /* set VCC min and max voltage according to ufs device type */
> > > + if (dev_info->wspecversion >= 0x300) {
> > > + vreg->min_uV = UFS_3X_VREG_VCC_MIN_UV;
> > > + vreg->max_uV = UFS_3X_VREG_VCC_MAX_UV;
> > > + }
> > > +
> > > + else {
> > > + vreg->min_uV = UFS_2X_VREG_VCC_MIN_UV;
> > > + vreg->max_uV = UFS_2X_VREG_VCC_MAX_UV;
> > > + }
> > > +
> > > + ret = ufshcd_enable_vreg(hba->dev, vreg);
> > > +
> > > + /* Bring the device in active now */
> > > + ret = ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE);
> > > + return ret;
> > > +}
> > > +
> > > static void ufs_qcom_enable_test_bus(struct ufs_qcom_host *host)
> > > {
> > > if (host->dbg_print_en & UFS_QCOM_DBG_PRINT_TEST_BUS_EN) {
> > > @@ -1490,6 +1540,7 @@ static const struct ufs_hba_variant_ops
> > > ufs_hba_qcom_vops = {
> > > .device_reset = ufs_qcom_device_reset,
> > > .config_scaling_param = ufs_qcom_config_scaling_param,
> > > .program_key= ufs_qcom_ice_program_key,
> > > + .setup_vcc_regulators = ufs_qcom_setup_vcc_regulators,
> > > };
> > >
> > > /**
> > > --
> > > 2.7.4
> > >
>
> Hi Bjorn,
> Thanks for your review.
> But As per the earlier discussion regarding handling of vcc voltage
> for platform supporting both ufs 2.x and ufs 3.x , it was finally concluded
> to
> use "vops and let vendors handle it, until specs or someone
> has a better suggestion". Please correct me in case i am wrong.
>
I was under the impression that this would result in something custom
per platform, but what I'm objecting to now that I see the code is that
this is completely generic.
And the concerns we discussed regarding these regulators being shared
with other devices is not considered in this implementation. But in
practice I don't see how you could support 2.x, 3.x and rail sharing at
the same time.
Regards,
Bjorn
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2399116.html
>
> Regards,
> Nitin
Re: [PATCH V2] soundwire: qcom: use signed variable for error return
On Wed 31 Mar 10:55 CDT 2021, Vinod Koul wrote: > We get warning of using a unsigned variable being compared to less than > zero. The comparison is correct as it checks for errors from previous > call to qcom_swrm_get_alert_slave_dev_num(), so we should use a signed > variable here. > > While at it, drop the superfluous initialization as well > > drivers/soundwire/qcom.c: qcom_swrm_irq_handler() warn: impossible > condition '(devnum < 0) => (0-255 < 0)' > > Reported-by: kernel test robot > Signed-off-by: Vinod Koul Reviewed-by: Bjorn Andersson > --- > drivers/soundwire/qcom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c > index b08ecb9b418c..ec86c4e53fdb 100644 > --- a/drivers/soundwire/qcom.c > +++ b/drivers/soundwire/qcom.c > @@ -428,7 +428,7 @@ static irqreturn_t qcom_swrm_irq_handler(int irq, void > *dev_id) > struct qcom_swrm_ctrl *swrm = dev_id; > u32 value, intr_sts, intr_sts_masked, slave_status; > u32 i; > - u8 devnum = 0; > + int devnum; > int ret = IRQ_HANDLED; > > swrm->reg_read(swrm, SWRM_INTERRUPT_STATUS, &intr_sts); > -- > 2.26.3 >
Re: [PATCH] soundwire: qcom: use signed variable for error return
On Wed 31 Mar 02:21 CDT 2021, Vinod Koul wrote: > We get warning for using a unsigned variable being compared to less than > zero. The comparison is correct as it checks for errors from previous > call to qcom_swrm_get_alert_slave_dev_num(), so we should use a signed > variable instead. > > drivers/soundwire/qcom.c: qcom_swrm_irq_handler() warn: impossible > condition '(devnum < 0) => (0-255 < 0)' > > Reported-by: kernel test robot > Signed-off-by: Vinod Koul > --- > drivers/soundwire/qcom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c > index b08ecb9b418c..55ed133c6704 100644 > --- a/drivers/soundwire/qcom.c > +++ b/drivers/soundwire/qcom.c > @@ -428,7 +428,7 @@ static irqreturn_t qcom_swrm_irq_handler(int irq, void > *dev_id) > struct qcom_swrm_ctrl *swrm = dev_id; > u32 value, intr_sts, intr_sts_masked, slave_status; > u32 i; > - u8 devnum = 0; > + s8 devnum = 0; At least in today's linux-next qcom_swrm_get_alert_slave_dev_num() returns an int and the code only checks to see if this is negative. So it seems like making this a full int ensures there's no truncation etc. And at least as written today there's no need to initialize the variable. Regards, Bjorn > int ret = IRQ_HANDLED; > > swrm->reg_read(swrm, SWRM_INTERRUPT_STATUS, &intr_sts); > -- > 2.26.3 >
Re: [PATCH v2] media: venus : hfi: add venus image info into smem
On Fri 26 Mar 01:33 CDT 2021, Dikshita Agarwal wrote:
> Fill fw version info into smem to be printed as part of
> soc info.
>
> Signed-off-by: Dikshita Agarwal
>
> Changes since v1:
> adressed comments from stephen.
> removed unwanted code.
> ---
> drivers/media/platform/qcom/venus/hfi_msgs.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c
> b/drivers/media/platform/qcom/venus/hfi_msgs.c
> index 06a1908..6b6d33c9 100644
> --- a/drivers/media/platform/qcom/venus/hfi_msgs.c
> +++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "core.h"
> @@ -14,6 +15,10 @@
> #include "hfi_msgs.h"
> #include "hfi_parser.h"
>
> +#define SMEM_IMG_VER_TBL 469
> +#define VER_STR_SZ 128
> +#define SMEM_IMG_INDEX_VENUS 14 * 128
14 is the index, 128 is the element size, so this is now an "offset".
> +
> static void event_seq_changed(struct venus_core *core, struct venus_inst
> *inst,
> struct hfi_msg_event_notify_pkt *pkt)
> {
> @@ -239,15 +244,27 @@ static void
> sys_get_prop_image_version(struct device *dev,
> struct hfi_msg_sys_property_info_pkt *pkt)
> {
> + size_t smem_blk_sz = 0;
You shouldn't need to initialize smem_blk_sz if you check the return
value of qcom_smem_get() first.
> + u8 *smem_tbl_ptr;
> + u8 *img_ver;
> int req_bytes;
>
> req_bytes = pkt->hdr.size - sizeof(*pkt);
>
> - if (req_bytes < 128 || !pkt->data[1] || pkt->num_properties > 1)
> + if (req_bytes < VER_STR_SZ || !pkt->data[1] || pkt->num_properties > 1)
> /* bad packet */
> return;
>
> - dev_dbg(dev, VDBGL "F/W version: %s\n", (u8 *)&pkt->data[1]);
> + img_ver = (u8 *)&pkt->data[1];
> +
> + dev_dbg(dev, VDBGL "F/W version: %s\n", img_ver);
> +
> + smem_tbl_ptr = qcom_smem_get(QCOM_SMEM_HOST_ANY,
> +SMEM_IMG_VER_TBL, &smem_blk_sz);
80 chars is just a guideline and this looks prettier if you avoid the
line wrap. That said, if you pick shorter names for smem_tbl_ptr and
smem_blk_sz you probably even have to worry.
> + if ((SMEM_IMG_INDEX_VENUS + VER_STR_SZ) <= smem_blk_sz &&
> + smem_tbl_ptr)
In English you're trying to determine: "did qcom_smem_get() return a
valid pointer and is the item's size at least as big as we need".
So just write that in C:
if (smem_tbl_ptr && smem_blk_sz >= SMEM_IMG_INDEX_VENUS + VER_STR_SZ)
> + memcpy(smem_tbl_ptr + SMEM_IMG_INDEX_VENUS,
> +img_ver, VER_STR_SZ);
Again, please avoid the line wrap...
Regards,
Bjorn
> }
>
> static void hfi_sys_property_info(struct venus_core *core,
> --
> 2.7.4
>
Re: [PATCH v3 1/2] dt-bindings: thermal: qcom-tsens: Add compatible for sm8350
On Wed 24 Mar 07:43 CDT 2021, Robert Foss wrote: > Add tsens bindings for sm8350. > > Signed-off-by: Robert Foss > Reviewed-by: Vinod Koul Reviewed-by: Bjorn Andersson @Daniel, I presume it's better that you take this patch (1/2) through your tree. I've picked patch 2. Regards, Bjorn > --- > > Changes since v1: > - Vinod: Remove comment > > Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml > b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml > index 95462e071ab4..e788378eff8d 100644 > --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml > +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml > @@ -43,6 +43,7 @@ properties: >- qcom,sdm845-tsens >- qcom,sm8150-tsens >- qcom,sm8250-tsens > + - qcom,sm8350-tsens >- const: qcom,tsens-v2 > >reg: > -- > 2.31.0.30.g398dba342d.dirty >
Re: [PATCH 3/5] arm: dts: qcom: Add support for MSM8226 SoC
On Fri 26 Mar 09:58 CDT 2021, Bartosz Dudziak wrote:
> This patch adds basic device tree support for MSM8226 SoC which belongs
> to the Snapdragon 400 family. For now, this file adds the basic nodes
> like gcc, pinctrl and other required configuration for booting up to
> the serial console.
>
> Signed-off-by: Bartosz Dudziak
> ---
> arch/arm/boot/dts/qcom-msm8226.dtsi | 152
> 1 file changed, 152 insertions(+)
> create mode 100644 arch/arm/boot/dts/qcom-msm8226.dtsi
>
> diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
> b/arch/arm/boot/dts/qcom-msm8226.dtsi
> new file mode 100644
> index 00..81bb19398e
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
> @@ -0,0 +1,152 @@
> +// SPDX-License-Identifier: GPL-2.0
Can you please make this BSD license?
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Qualcomm Technologies, Inc. MSM8226";
> + compatible = "qcom,msm8226";
model and compatible should always be specified in the .dts, so the ones
specified here would be overwritten. So drop them here.
> + interrupt-parent = <&intc>;
> +
> + chosen { };
> +
> + memory {
> + device_type = "memory";
> + /* We expect the bootloader to fill in the size */
> + reg = <0x0 0x0>;
> + };
> +
> + soc: soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@f900 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0xF900 0x1000>,
> + <0xF9002000 0x1000>;
> + };
> +
> + gcc: clock-controller@fc40 {
> + compatible = "qcom,gcc-msm8226";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + reg = <0xfc40 0x4000>;
> + };
> +
> + msmgpio: pinctrl@fd51 {
Rename the label "tlmm"
> + compatible = "qcom,msm8226-pinctrl";
> + reg = <0xfd51 0x4000>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&msmgpio 0 0 117>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = ;
> + };
> +
> + blsp1_uart3: serial@f991f000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0xf991f000 0x1000>;
> + interrupts = ;
> + clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>, <&gcc
> GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + status = "disabled";
> + };
> +
> + restart@fc4ab000 {
> + compatible = "qcom,pshold";
> + reg = <0xfc4ab000 0x4>;
> + };
> +
> + rng@f9bff000 {
> + compatible = "qcom,prng";
> + reg = <0xf9bff000 0x200>;
> + clocks = <&gcc GCC_PRNG_AHB_CLK>;
> + clock-names = "core";
> + };
> +
> + timer@f902 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "arm,armv7-timer-mem";
It's nice to have compatible & reg first in the nodes.
Regards,
Bjorn
> + reg = <0xf902 0x1000>;
> + clock-frequency = <1920>;
> +
> + frame@f9021000 {
> + frame-number = <0>;
> + interrupts = ,
> + ;
> + reg = <0xf9021000 0x1000>,
> + <0xf9022000 0x1000>;
> + };
> +
> + frame@f9023000 {
> + frame-number = <1>;
> + interrupts = ;
> + reg = <0xf9023000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9024000 {
> + frame-number = <2>;
> + interrupts = ;
> + reg = <0xf9024000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9025000 {
> + frame-number = <3>
Re: [PATCH v5 7/7] arm64: dts: qcom: use dp_phy to provide clocks to dispcc
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:
> Plug dp_phy-provided clocks to display clock controller.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 0f79e6885004..a2478bd3590a 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -2600,8 +2600,8 @@ dispcc: clock-controller@af0 {
><&dsi0_phy 1>,
><&dsi1_phy 0>,
><&dsi1_phy 1>,
> - <0>,
> - <0>,
> + <&dp_phy 0>,
> + <&dp_phy 1>,
><0>,
><0>,
><0>,
> @@ -2614,8 +2614,8 @@ dispcc: clock-controller@af0 {
> "dsi0_phy_pll_out_dsiclk",
> "dsi1_phy_pll_out_byteclk",
> "dsi1_phy_pll_out_dsiclk",
> - "dp_link_clk_divsel_ten",
> - "dp_vco_divided_clk_src_mux",
> + "dp_phy_pll_link_clk",
> + "dp_phy_pll_vco_div_clk",
> "dptx1_phy_pll_link_clk",
> "dptx1_phy_pll_vco_div_clk",
> "dptx2_phy_pll_link_clk",
> --
> 2.30.2
>
Re: [PATCH v5 6/7] arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:
> USB1 QMP PHY is not just a USB3 PHY, but USB3+DP PHY. Change device tree
> nodes accordingly.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Bjorn Andersson
@Vinod, will you let me know when you've picked the driver changes so I
can pick the two DT patches?
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 947e1accae3a..0f79e6885004 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -2097,12 +2097,11 @@ usb_2_hsphy: phy@88e4000 {
> };
>
> usb_1_qmpphy: phy@88e9000 {
> - compatible = "qcom,sm8250-qmp-usb3-phy";
> + compatible = "qcom,sm8250-qmp-usb3-dp-phy";
> reg = <0 0x088e9000 0 0x200>,
> - <0 0x088e8000 0 0x20>;
> - reg-names = "reg-base", "dp_com";
> + <0 0x088e8000 0 0x40>,
> + <0 0x088ea000 0 0x200>;
> status = "disabled";
> - #clock-cells = <1>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> @@ -2116,7 +2115,7 @@ usb_1_qmpphy: phy@88e9000 {
><&gcc GCC_USB3_PHY_PRIM_BCR>;
> reset-names = "phy", "common";
>
> - usb_1_ssphy: lanes@88e9200 {
> + usb_1_ssphy: usb3-phy@88e9200 {
> reg = <0 0x088e9200 0 0x200>,
> <0 0x088e9400 0 0x200>,
> <0 0x088e9c00 0 0x400>,
> @@ -2128,6 +2127,20 @@ usb_1_ssphy: lanes@88e9200 {
> clock-names = "pipe0";
> clock-output-names = "usb3_phy_pipe_clk_src";
> };
> +
> + dp_phy: dp-phy@88ea200 {
> + reg = <0 0x088ea200 0 0x200>,
> + <0 0x088ea400 0 0x200>,
> + <0 0x088eac00 0 0x400>,
> + <0 0x088ea600 0 0x200>,
> + <0 0x088ea800 0 0x200>,
> + <0 0x088eaa00 0 0x100>;
> + #phy-cells = <0>;
> + #clock-cells = <1>;
> + clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> + clock-names = "pipe0";
> + clock-output-names = "usb3_phy_pipe_clk_src";
> + };
> };
>
> usb_2_qmpphy: phy@88eb000 {
> --
> 2.30.2
>
Re: [PATCH v5 5/7] phy: qcom-qmp: add support for sm8250-usb3-dp phy
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:
> Add support for QMP V4 Combo USB3+DP PHY (for SM8250 platform).
>
> Signed-off-by: Dmitry Baryshkov
Acked-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 388 ++--
> drivers/phy/qualcomm/phy-qcom-qmp.h | 40 ++-
> 2 files changed, 406 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 097bc005ba43..a47da2fff7a1 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1840,6 +1840,86 @@ static const struct qmp_phy_init_tbl
> sm8250_usb3_uniphy_pcs_tbl[] = {
> QMP_PHY_INIT_CFG(QPHY_V4_PCS_REFGEN_REQ_CONFIG1, 0x21),
> };
>
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SVS_MODE_CLK_SEL, 0x05),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0x3b),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYS_CLK_CTRL, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_ENABLE1, 0x0c),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_BUF_ENABLE, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_SELECT, 0x30),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_IVCO, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x36),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x16),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CMN_CONFIG, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BG_TIMER, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORECLK_DIV_MODE0, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_CTRL, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIAS_EN_CLKBUFLR_EN, 0x17),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORE_CLK_EN, 0x1f),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_rbr[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x05),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x69),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x6f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x08),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x04),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_hbr[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x69),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x0e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x08),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_hbr2[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x01),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x8c),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x1f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x1c),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x08),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_hbr3[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x69),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x2f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x2a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x08),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_tx_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_VMODE_CTRL1, 0x40),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_PRE_STALL_LDO_BOOST_EN, 0x30),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_INTERFACE_SELECT, 0x3b),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_CLKBUF_ENABLE, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RESET_TSYNC_EN, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_TRAN_DRVR_EMP_EN, 0x0f),
> + QMP
Re: [PATCH v5 4/7] phy: qcom-qmp: rename common registers
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:
> A plenty of DP PHY registers are common between V3 and V4. To simplify
> V4 code, rename all common registers.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 50 ++---
> drivers/phy/qualcomm/phy-qcom-qmp.h | 37 ++---
> 2 files changed, 44 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 4150096fd350..097bc005ba43 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -2435,20 +2435,20 @@ static void qcom_qmp_v3_phy_dp_aux_init(struct
> qmp_phy *qphy)
> {
> writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> -qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>
> /* Turn on BIAS current for PHY/PLL */
> writel(QSERDES_V3_COM_BIAS_EN | QSERDES_V3_COM_BIAS_EN_MUX |
> QSERDES_V3_COM_CLKBUF_L_EN | QSERDES_V3_COM_EN_SYSCLK_TX_SEL,
> qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
>
> - writel(DP_PHY_PD_CTL_PSR_PWRDN, qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>
> writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> DP_PHY_PD_CTL_LANE_0_1_PWRDN |
> DP_PHY_PD_CTL_LANE_2_3_PWRDN | DP_PHY_PD_CTL_PLL_PWRDN |
> DP_PHY_PD_CTL_DP_CLAMP_EN,
> -qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>
> writel(QSERDES_V3_COM_BIAS_EN |
> QSERDES_V3_COM_BIAS_EN_MUX | QSERDES_V3_COM_CLKBUF_R_EN |
> @@ -2456,16 +2456,16 @@ static void qcom_qmp_v3_phy_dp_aux_init(struct
> qmp_phy *qphy)
> QSERDES_V3_COM_CLKBUF_RX_DRIVE_L,
> qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
>
> - writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG0);
> - writel(0x13, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG1);
> - writel(0x24, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG2);
> - writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG3);
> - writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG4);
> - writel(0x26, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG5);
> - writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG6);
> - writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG7);
> - writel(0xbb, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG8);
> - writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG9);
> + writel(0x00, qphy->pcs + QSERDES_DP_PHY_AUX_CFG0);
> + writel(0x13, qphy->pcs + QSERDES_DP_PHY_AUX_CFG1);
> + writel(0x24, qphy->pcs + QSERDES_DP_PHY_AUX_CFG2);
> + writel(0x00, qphy->pcs + QSERDES_DP_PHY_AUX_CFG3);
> + writel(0x0a, qphy->pcs + QSERDES_DP_PHY_AUX_CFG4);
> + writel(0x26, qphy->pcs + QSERDES_DP_PHY_AUX_CFG5);
> + writel(0x0a, qphy->pcs + QSERDES_DP_PHY_AUX_CFG6);
> + writel(0x03, qphy->pcs + QSERDES_DP_PHY_AUX_CFG7);
> + writel(0xbb, qphy->pcs + QSERDES_DP_PHY_AUX_CFG8);
> + writel(0x03, qphy->pcs + QSERDES_DP_PHY_AUX_CFG9);
> qphy->dp_aux_cfg = 0;
>
> writel(PHY_AUX_STOP_ERR_MASK | PHY_AUX_DEC_ERR_MASK |
> @@ -2556,9 +2556,9 @@ static int qcom_qmp_v3_phy_configure_dp_phy(struct
> qmp_phy *qphy)
>* writel(0x4c, qphy->pcs + QSERDES_V3_DP_PHY_MODE);
>*/
> val |= DP_PHY_PD_CTL_LANE_2_3_PWRDN;
> - writel(val, qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> + writel(val, qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>
> - writel(0x5c, qphy->pcs + QSERDES_V3_DP_PHY_MODE);
> + writel(0x5c, qphy->pcs + QSERDES_DP_PHY_MODE);
> writel(0x05, qphy->pcs + QSERDES_V3_DP_PHY_TX0_TX1_LANE_CTL);
> writel(0x05, qphy->pcs + QSERDES_V3_DP_PHY_TX2_TX3_LANE_CTL);
>
> @@ -2588,11 +2588,11 @@ static int qcom_qmp_v3_phy_configure_dp_phy(struct
> qmp_phy *qphy)
> clk_set_rate(dp_clks->dp_link_hw.clk, dp_opts->link_rate * 10);
> clk_set_rate(dp_clks->dp_pixel_hw.clk, pixel_freq);
>
> - writel(0x04, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG2);
> - writel(0x01, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> - writel(0x05, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> - writel(0x01, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> - writel(0x09, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> + writel(0x04, qphy->pcs + QSERDES_DP_PHY_AUX_CFG2);
>
Re: [PATCH v5 3/7] phy: qcom-qmp: move DP functions to callbacks
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:
> In preparation to adding support for V4 DP PHY move DP functions to
> callbacks at struct qmp_phy_cfg.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 438 +++-
> 1 file changed, 231 insertions(+), 207 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 9cdebe7f26cb..4150096fd350 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -2268,6 +2268,8 @@ static const struct qmp_phy_init_tbl
> sm8350_usb3_uniphy_pcs_tbl[] = {
> QMP_PHY_INIT_CFG(QPHY_V4_PCS_REFGEN_REQ_CONFIG1, 0x21),
> };
>
> +struct qmp_phy;
> +
> /* struct qmp_phy_cfg - per-PHY initialization config */
> struct qmp_phy_cfg {
> /* phy-type - PCIE/UFS/USB */
> @@ -2307,6 +2309,12 @@ struct qmp_phy_cfg {
> const struct qmp_phy_init_tbl *serdes_tbl_hbr3;
> int serdes_tbl_hbr3_num;
>
> + /* DP PHY callbacks */
> + int (*configure_dp_phy)(struct qmp_phy *qphy);
> + void (*configure_dp_tx)(struct qmp_phy *qphy);
> + int (*calibrate_dp_phy)(struct qmp_phy *qphy);
> + void (*dp_aux_init)(struct qmp_phy *qphy);
> +
> /* clock ids to be requested */
> const char * const *clk_list;
> int num_clks;
> @@ -2423,6 +2431,216 @@ struct qcom_qmp {
> struct reset_control *ufs_reset;
> };
>
> +static void qcom_qmp_v3_phy_dp_aux_init(struct qmp_phy *qphy)
> +{
> + writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> +DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> +qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +
> + /* Turn on BIAS current for PHY/PLL */
> + writel(QSERDES_V3_COM_BIAS_EN | QSERDES_V3_COM_BIAS_EN_MUX |
> +QSERDES_V3_COM_CLKBUF_L_EN | QSERDES_V3_COM_EN_SYSCLK_TX_SEL,
> +qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
> +
> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +
> + writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> +DP_PHY_PD_CTL_LANE_0_1_PWRDN |
> +DP_PHY_PD_CTL_LANE_2_3_PWRDN | DP_PHY_PD_CTL_PLL_PWRDN |
> +DP_PHY_PD_CTL_DP_CLAMP_EN,
> +qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +
> + writel(QSERDES_V3_COM_BIAS_EN |
> +QSERDES_V3_COM_BIAS_EN_MUX | QSERDES_V3_COM_CLKBUF_R_EN |
> +QSERDES_V3_COM_CLKBUF_L_EN | QSERDES_V3_COM_EN_SYSCLK_TX_SEL |
> +QSERDES_V3_COM_CLKBUF_RX_DRIVE_L,
> +qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
> +
> + writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG0);
> + writel(0x13, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG1);
> + writel(0x24, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG2);
> + writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG3);
> + writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG4);
> + writel(0x26, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG5);
> + writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG6);
> + writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG7);
> + writel(0xbb, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG8);
> + writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG9);
> + qphy->dp_aux_cfg = 0;
> +
> + writel(PHY_AUX_STOP_ERR_MASK | PHY_AUX_DEC_ERR_MASK |
> +PHY_AUX_SYNC_ERR_MASK | PHY_AUX_ALIGN_ERR_MASK |
> +PHY_AUX_REQ_ERR_MASK,
> +qphy->pcs + QSERDES_V3_DP_PHY_AUX_INTERRUPT_MASK);
> +}
> +
> +static const u8 qmp_dp_v3_pre_emphasis_hbr_rbr[4][4] = {
> + { 0x00, 0x0c, 0x14, 0x19 },
> + { 0x00, 0x0b, 0x12, 0xff },
> + { 0x00, 0x0b, 0xff, 0xff },
> + { 0x04, 0xff, 0xff, 0xff }
> +};
> +
> +static const u8 qmp_dp_v3_voltage_swing_hbr_rbr[4][4] = {
> + { 0x08, 0x0f, 0x16, 0x1f },
> + { 0x11, 0x1e, 0x1f, 0xff },
> + { 0x19, 0x1f, 0xff, 0xff },
> + { 0x1f, 0xff, 0xff, 0xff }
> +};
> +
> +static void qcom_qmp_v3_phy_configure_dp_tx(struct qmp_phy *qphy)
> +{
> + const struct phy_configure_opts_dp *dp_opts = &qphy->dp_opts;
> + unsigned int v_level = 0, p_level = 0;
> + u32 bias_en, drvr_en;
> + u8 voltage_swing_cfg, pre_emphasis_cfg;
> + int i;
> +
> + for (i = 0; i < dp_opts->lanes; i++) {
> + v_level = max(v_level, dp_opts->voltage[i]);
> + p_level = max(p_level, dp_opts->pre[i]);
> + }
> +
> + if (dp_opts->lanes == 1) {
> + bias_en = 0x3e;
> +
Re: [PATCH v5 2/7] dt-bindings: phy: qcom,qmp-usb3-dp: Add support for SM8250
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote: > Add compatible for SM8250 in QMP USB3 DP PHY bindings. > > Signed-off-by: Dmitry Baryshkov > Acked-by: Rob Herring Reviewed-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml > b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml > index 62c0179d1765..217aa6c91893 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml > @@ -15,6 +15,7 @@ properties: > enum: >- qcom,sc7180-qmp-usb3-dp-phy >- qcom,sdm845-qmp-usb3-dp-phy > + - qcom,sm8250-qmp-usb3-dp-phy >reg: > items: >- description: Address and length of PHY's USB serdes block. > -- > 2.30.2 >
Re: [PATCH v5 1/7] dt-bindings: phy: qcom,qmp-usb3-dp-phy: move usb3 compatibles back to qcom,qmp-phy.yaml
On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:
> The commit 724fabf5df13 ("dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy
> information") has support for DP part of USB3+DP combo PHYs. However
> this change is not backwards compatible, placing additional requirements
> onto qcom,sc7180-qmp-usb3-phy and qcom,sdm845-qmp-usb3-phy device nodes
> (to include separate DP part, etc). However the aforementioned nodes do
> not inclue DP part, they strictly follow the schema defined in the
> qcom,qmp-phy.yaml file. Move those compatibles, leaving
> qcom,qmp-usb3-dp-phy.yaml to describe only real "combo" USB3+DP device nodes.
>
> Fixes: 724fabf5df13 ("dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy
> information")
> Cc: Stephen Boyd
> Cc: Sandeep Maheswaram
> Signed-off-by: Dmitry Baryshkov
> Acked-by: Rob Herring
> Reviewed-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 2 ++
> Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> index 626447fee092..7808ec8bc712 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> @@ -25,11 +25,13 @@ properties:
>- qcom,msm8998-qmp-pcie-phy
>- qcom,msm8998-qmp-ufs-phy
>- qcom,msm8998-qmp-usb3-phy
> + - qcom,sc7180-qmp-usb3-phy
>- qcom,sc8180x-qmp-ufs-phy
>- qcom,sc8180x-qmp-usb3-phy
>- qcom,sdm845-qhp-pcie-phy
>- qcom,sdm845-qmp-pcie-phy
>- qcom,sdm845-qmp-ufs-phy
> + - qcom,sdm845-qmp-usb3-phy
>- qcom,sdm845-qmp-usb3-uni-phy
>- qcom,sm8150-qmp-ufs-phy
>- qcom,sm8150-qmp-usb3-phy
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> index 33974ad10afe..62c0179d1765 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> @@ -14,9 +14,7 @@ properties:
>compatible:
> enum:
>- qcom,sc7180-qmp-usb3-dp-phy
> - - qcom,sc7180-qmp-usb3-phy
>- qcom,sdm845-qmp-usb3-dp-phy
> - - qcom,sdm845-qmp-usb3-phy
>reg:
> items:
>- description: Address and length of PHY's USB serdes block.
> --
> 2.30.2
>
Re: [PATCH 2/2] arm64: dts: msm8996: Mark the GPU's SMMU as an adreno one.
On Fri 26 Mar 18:13 CDT 2021, Eric Anholt wrote:
> This enables the adreno-specific SMMU path that sets HUPCF so
> (user-managed) page faults don't wedge the GPU.
>
> Signed-off-by: Eric Anholt
Acked-by: Bjorn Andersson
@Will, can you pick this together with the driver patch? (So that they
land in order)
Regards,
Bjorn
> ---
>
> We've been seeing a flaky test per day or so in Mesa CI where the
> kernel gets wedged after an iommu fault turns into CP errors. With
> this patch, the CI isn't throwing the string of CP errors on the
> faults in any of the ~10 jobs I've run so far.
>
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 6de136e3add9..432b87ec9c5e 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -1127,7 +1127,7 @@ cci_i2c1: i2c-bus@1 {
> };
>
> adreno_smmu: iommu@b4 {
> - compatible = "qcom,msm8996-smmu-v2", "qcom,smmu-v2";
> + compatible = "qcom,msm8996-smmu-v2",
> "qcom,adreno-smmu", "qcom,smmu-v2";
> reg = <0x00b4 0x1>;
>
> #global-interrupts = <1>;
> --
> 2.31.0
>
Re: [PATCH 1/2] iommu/arm-smmu-qcom: Skip the TTBR1 quirk for db820c.
On Fri 26 Mar 18:13 CDT 2021, Eric Anholt wrote:
> db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> the GPU from wedging and then sometimes wedging the kernel after a
> page fault), but it doesn't have separate pagetables support yet in
> drm/msm so we can't go all the way to the TTBR1 path.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
>
> We've been seeing a flaky test per day or so in Mesa CI where the
> kernel gets wedged after an iommu fault turns into CP errors. With
> this patch, the CI isn't throwing the string of CP errors on the
> faults in any of the ~10 jobs I've run so far.
>
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index bcda17012aee..51f22193e456 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -130,6 +130,16 @@ static int qcom_adreno_smmu_alloc_context_bank(struct
> arm_smmu_domain *smmu_doma
> return __arm_smmu_alloc_bitmap(smmu->context_map, start, count);
> }
>
> +static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
> +{
> + const struct device_node *np = smmu->dev->of_node;
> +
> + if (of_device_is_compatible(np, "qcom,msm8996-smmu-v2"))
> + return false;
> +
> + return true;
> +}
> +
> static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
> {
> @@ -144,7 +154,8 @@ static int qcom_adreno_smmu_init_context(struct
> arm_smmu_domain *smmu_domain,
>* be AARCH64 stage 1 but double check because the arm-smmu code assumes
>* that is the case when the TTBR1 quirk is enabled
>*/
> - if ((smmu_domain->stage == ARM_SMMU_DOMAIN_S1) &&
> + if (qcom_adreno_can_do_ttbr1(smmu_domain->smmu) &&
> + (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) &&
> (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64))
> pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_ARM_TTBR1;
>
> --
> 2.31.0
>
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri 26 Mar 10:24 CDT 2021, Rob Clark wrote: > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > wrote: > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > wrote: > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > > The sc7180-trogdor-pompom board might be attached to any number of a > > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > > include: > > > > > > - KD KD116N21-30NV-A010 > > > > > > - KD KD116N09-30NH-A016 > > > > > > - Starry 2081116HHD028001-51D > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > > panels indicates that they should run with exactly the same timing > > > > > > (to > > > > > > keep things simple), the 4th panel not only needs different timing > > > > > > but > > > > > > has a different resolution. > > > > > > > > > > > > As is true in general with eDP panels, we can figure out which panel > > > > > > we have and all the info needed to drive its pixel clock by reading > > > > > > the EDID. However, we can do this only after we've powered the panel > > > > > > on. Powering on the panels requires following the timing diagram in > > > > > > each panel's datasheet which specifies delays between certain > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > handling > > > > > > things we can't just totally skip out on describing the panel like > > > > > > we > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > > possible to come up with a set of unified delays that will work on > > > > > > all > > > > > > the panels. From reading the datasheets: > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 > > > > > > ms) > > > > > > * Starry 2081116HHD028001-51D > > > > > > - HPD absent delay: 100 ms > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > * Sharp LQ116M1JW10 > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > Unified: > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > > > > > "HPD absent delay" since once the panel asserts HPD we can read the > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > pompom" > > > > > > as a panel that provides a valid EDID and can work with the standard > > > > > > pompom power sequencing. If more panels are later attached to pompom > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > provide > > > > > > the timings directly in the device tree file. As I understand it, > > > > > > trying to describe generic power sequencing in the device tree is > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > > > > > that shouldn't be repeated. Specifying a power sequence per board > > > > > > (or > > > > > > per board class) feels like a reasonable compromise. We're not > > > > > > trying > > > > > > to define fully generic power sequence bindings but we can also take > > > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > > > > > NOTE: I believe that past instances of supporting this type of thing > > > > > > have used the "white lie" approach. One representative panel was > > > > > > listed in the device tree. The power sequencings of this > > > > > > representative panel were OK to use across all panels that might be > > > > > > attached and other differences were handled by EDID. This patch > > > > > > attempts to set a new precedent and avoid the need for the white > > > > > > lie. > > > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > > --- > > > > > > > > > > Sounds reasonable to me if DT maintainers can live with this abstract > > > > > hardware definition. It's clearer than the 'white lie' approach. > > > > > > > > Yeah, it is a weird grey area between "discoverable" and "not > > > > discoverable".. but I favor DT reflecting reality as much as > > > > possible/feasible, so I think this is definity cleaner than "white > > > > lies" > > > > > > This is practically no different than the "white lie". I suppose you > > >
Re: [PATCH v2 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
On Fri 12 Mar 20:35 CST 2021, Konrad Dybcio wrote: > Hi, > > > I'm not sure I can agree. Especially for regions like IPA and > TZ-reserved, which seem the same on (almost?) all.. > Thanks Konrad, I appreciate that. > > Sure, the configuration for various remoteprocs *can* differ based on > what the vendor decided to go with, but more often than not > (especially with phones) vendors just take a MTP or CDP design, add a > screen, couple of cameras and call it their own (you can tell by how > similar most of them to the original reference designs in DT). While > this is usually the case with lower-end (so not exactly sdm845) > devices, it also kinda applies here... > Unfortunately there's not a single memory map for each reference design, the memory map do change during development based on feature set. I think we can see this already among the few devices. > > I guess for this one, we should find the lowest common denominator and > keep the nodes that are in the majority of devices in 845 DTSI and > only alter them if need be.. For WoA devices that may stray further > away, you can just add a label to reserved-memory and /delete-node/ > it, so that you can rewrite it cleanly. The proposed approach just > adds a lot - A LOT - of duplication. It will REALLY bite after more > people submit 845-based phones, of which there are plenty (4 Xperias, > a whole lot of Xiaomis, a couple of Samsungs, LGs... need I go on?). > I was hoping to make it easier to reason about the memory map for each device, but if your right about these incoming devices then I agree that the duplication isn't worth it. I'll respin patch 2, to get IPA going on the Yoga C630 and put this patch on hold until this annoys me again :) Thank you, Bjorn
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
On Tue 23 Mar 13:27 CDT 2021, Elliot Berman wrote: > On 3/22/2021 8:36 PM, Stephen Boyd wrote: > > Quoting Bjorn Andersson (2021-03-07 09:42:45) > > > On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote: > > > > > > > Quoting Elliot Berman (2021-03-05 10:18:09) > > > > > On 3/3/2021 10:14 PM, Stephen Boyd wrote: > > > > > > Quoting Elliot Berman (2021-03-03 19:35:08) > > > > > > > > > > > +desc.args[0] = flags; > > > > > > +desc.args[1] = virt_to_phys(entry); > > > > > > + > > > > > > +return scm_legacy_call_atomic(NULL, &desc, NULL); > > > > > > +} > > > > > > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr); > > > > > > > > > > This should still be qcom_scm_call. > > > > > > > > You mean s/scm_legacy_call_atomic/qcom_scm_call/ right? > > > > > > > > I don't really want to resend the rest of the patches if this last one > > > > is the only one that needs an update. This was a semi-RFC anyway so > > > > maybe it's fine if the first 5 patches get merged and then I can resend > > > > this one? Otherwise I will resend this again next week or so with less > > > > diff for this patch. > > > > > > I'm fine with merging the first 5, but was hoping that Elliot could > > > provide either a "Reviewed-by" or at least an "Acked-by" on these. > > > > > > > I'll take the silence as I should resend the whole series? > > > > I thought Bjorn was accepting the first 5 already, my apologies. > > Patches 1-5: > Acked-by: Elliot Berman Thanks Elliot. I'll pick up the first 5, so please skip these in your repost, Stephen. Regards, Bjorn
Re: [PATCH V2 3/3] scsi: ufs-qcom: configure VCC voltage level in vendor file
On Sun 21 Mar 16:57 CDT 2021, Nitin Rawat wrote:
> As a part of vops handler, VCC voltage is updated
> as per the ufs device probed after reading the device
> descriptor. We follow below steps to configure voltage
> level.
>
> 1. Set the device to SLEEP state.
> 2. Disable the Vcc Regulator.
> 3. Set the vcc voltage according to the device type and reenable
>the regulator.
> 4. Set the device mode back to ACTIVE.
>
When we discussed this a while back this was described as a requirement
from the device specification, you only operate on objects "owned" by
ufshcd and you invoke ufshcd operations to perform the actions.
So why is this a ufs-qcom patch and not something in ufshcd?
Regards,
Bjorn
> Signed-off-by: Nitin Rawat
> Signed-off-by: Veerabhadrarao Badiganti
> ---
> drivers/scsi/ufs/ufs-qcom.c | 51
> +
> 1 file changed, 51 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index f97d7b0..ca35f5c 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -21,6 +21,17 @@
> #define UFS_QCOM_DEFAULT_DBG_PRINT_EN\
> (UFS_QCOM_DBG_PRINT_REGS_EN | UFS_QCOM_DBG_PRINT_TEST_BUS_EN)
>
> +#define ANDROID_BOOT_DEV_MAX30
> +static char android_boot_dev[ANDROID_BOOT_DEV_MAX];
> +
> +/* Min and Max VCC voltage values for ufs 2.x and
> + * ufs 3.x devices
> + */
> +#define UFS_3X_VREG_VCC_MIN_UV 254 /* uV */
> +#define UFS_3X_VREG_VCC_MAX_UV 270 /* uV */
> +#define UFS_2X_VREG_VCC_MIN_UV 295 /* uV */
> +#define UFS_2X_VREG_VCC_MAX_UV 296 /* uV */
> +
> enum {
> TSTBUS_UAWM,
> TSTBUS_UARM,
> @@ -1293,6 +1304,45 @@ static void ufs_qcom_print_hw_debug_reg_all(struct
> ufs_hba *hba,
> print_fn(hba, reg, 9, "UFS_DBG_RD_REG_TMRLUT ", priv);
> }
>
> + /**
> + * ufs_qcom_setup_vcc_regulators - Update VCC voltage
> + * @hba: host controller instance
> + * Update VCC voltage based on UFS device(ufs 2.x or
> + * ufs 3.x probed)
> + */
> +static int ufs_qcom_setup_vcc_regulators(struct ufs_hba *hba)
> +{
> + struct ufs_dev_info *dev_info = &hba->dev_info;
> + struct ufs_vreg *vreg = hba->vreg_info.vcc;
> + int ret;
> +
> + /* Put the device in sleep before lowering VCC level */
> + ret = ufshcd_set_dev_pwr_mode(hba, UFS_SLEEP_PWR_MODE);
> +
> + /* Switch off VCC before switching it ON at 2.5v or 2.96v */
> + ret = ufshcd_disable_vreg(hba->dev, vreg);
> +
> + /* add ~2ms delay before renabling VCC at lower voltage */
> + usleep_range(2000, 2100);
> +
> + /* set VCC min and max voltage according to ufs device type */
> + if (dev_info->wspecversion >= 0x300) {
> + vreg->min_uV = UFS_3X_VREG_VCC_MIN_UV;
> + vreg->max_uV = UFS_3X_VREG_VCC_MAX_UV;
> + }
> +
> + else {
> + vreg->min_uV = UFS_2X_VREG_VCC_MIN_UV;
> + vreg->max_uV = UFS_2X_VREG_VCC_MAX_UV;
> + }
> +
> + ret = ufshcd_enable_vreg(hba->dev, vreg);
> +
> + /* Bring the device in active now */
> + ret = ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE);
> + return ret;
> +}
> +
> static void ufs_qcom_enable_test_bus(struct ufs_qcom_host *host)
> {
> if (host->dbg_print_en & UFS_QCOM_DBG_PRINT_TEST_BUS_EN) {
> @@ -1490,6 +1540,7 @@ static const struct ufs_hba_variant_ops
> ufs_hba_qcom_vops = {
> .device_reset = ufs_qcom_device_reset,
> .config_scaling_param = ufs_qcom_config_scaling_param,
> .program_key= ufs_qcom_ice_program_key,
> + .setup_vcc_regulators = ufs_qcom_setup_vcc_regulators,
> };
>
> /**
> --
> 2.7.4
>
Re: [PATCH] pinctrl: qcom: fix unintentional string concatenation
On Tue 23 Mar 08:17 CDT 2021, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang is clearly correct to point out a typo in a silly
> array of strings:
>
> drivers/pinctrl/qcom/pinctrl-sdx55.c:426:61: error: suspicious concatenation
> of string literals in an array initialization; did you mean to separate the
> elements with a comma? [-Werror,-Wstring-concatenation]
> "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19" "gpio20",
> "gpio21", "gpio22",
>^
> Add the missing comma that must have accidentally been removed.
That's certainly a useful warning! Thanks Arnd.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
>
> Fixes: ac43c44a7a37 ("pinctrl: qcom: Add SDX55 pincontrol driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/pinctrl/qcom/pinctrl-sdx55.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-sdx55.c
> b/drivers/pinctrl/qcom/pinctrl-sdx55.c
> index 2b5b0e2b03ad..5aaf57b40407 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sdx55.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sdx55.c
> @@ -423,7 +423,7 @@ static const char * const gpio_groups[] = {
>
> static const char * const qdss_stm_groups[] = {
> "gpio0", "gpio1", "gpio2", "gpio3", "gpio4", "gpio5", "gpio6", "gpio7",
> "gpio12", "gpio13",
> - "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19" "gpio20",
> "gpio21", "gpio22",
> + "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20",
> "gpio21", "gpio22",
> "gpio23", "gpio44", "gpio45", "gpio52", "gpio53", "gpio56", "gpio57",
> "gpio61", "gpio62",
> "gpio63", "gpio64", "gpio65", "gpio66",
> };
> --
> 2.29.2
>
Re: [PATCH 0/5] qcom: wcnss: Allow overriding firmware form DT
On Thu 18 Mar 11:56 CDT 2021, Jeffrey Hugo wrote: > form -> from in the subject? > Seems like I only failed in the cover letter, right? Regards, Bjorn > On Thu, Mar 11, 2021 at 5:34 PM Bjorn Andersson > wrote: > > > > The wireless subsystem found in Qualcomm MSM8974 and MSM8916 among others > > needs > > platform-, and perhaps even board-, specific firmware. Add support for > > providing this in devicetree.
Re: [PATCH 5/5] arm64: dts: qcom: msm8916: Enable modem and WiFi
On Mon 15 Mar 07:01 CDT 2021, Bryan O'Donoghue wrote:
> On 12/03/2021 00:33, Bjorn Andersson wrote:
> > Enable the modem and WiFi subsystems and specify msm8916 specific
> > firmware path for these and the WCNSS control service.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> > arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12
> > arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > index 6aef0c2e4f0a..448e3561ef63 100644
> > --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > @@ -305,6 +305,12 @@ &mdss {
> > status = "okay";
> > };
> > +&mpss {
> > + status = "okay";
> > +
> > + firmware-name = "qcom/msm8916/mba.mbn", "qcom/msm8916/modem.mbn";
> > +};
> > +
> > &pm8916_resin {
> > status = "okay";
> > linux,code = ;
> > @@ -312,6 +318,8 @@ &pm8916_resin {
> > &pronto {
> > status = "okay";
> > +
> > + firmware-name = "qcom/msm8916/wcnss.mbn";
> > };
>
> On Debian I have to do this
>
>
> index 2a6a23cb14ca..597cdc8f51cc 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -33,7 +33,7 @@
> #include "qcom_wcnss.h"
>
> #define WCNSS_CRASH_REASON_SMEM422
> -#define WCNSS_FIRMWARE_NAME"wcnss.mdt"
> +#define WCNSS_FIRMWARE_NAME"qcom/msm8916/wcnss.mdt"
>
> so I guess wcnss_probe() -> rproc_alloc() wants this fix too.
>
Can you confirm that you're saying that you want below patch, which I
just merged?
https://lore.kernel.org/linux-remoteproc/20210312002441.3273183-1-bjorn.anders...@linaro.org/
(Which makes it possible to specify firmware name per platform/board)
Regards,
Bjorn
Re: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc
On Tue 29 Dec 19:27 CST 2020, Martin Blumenstingl wrote:
> Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4
> controller for always-on operations, typically used for managing system
> suspend.
>
> Signed-off-by: Martin Blumenstingl
> ---
> .../remoteproc/amlogic,meson-mx-ao-arc.yaml | 87 +++
> 1 file changed, 87 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
> b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
> new file mode 100644
> index ..ba5deebaf7dc
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Amlogic Meson AO ARC Remote Processor bindings
> +
> +description:
> + Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC core
> + controller for always-on operations, typically used for managing
> + system suspend. Meson6 and older use a ARC core based on the ARCv1
> + ISA, while Meson8, Meson8b and Meson8m2 use an ARC EM4 (ARCv2 ISA)
> + core.
> +
> +maintainers:
> + - Martin Blumenstingl
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> +- amlogic,meson8-ao-arc
> +- amlogic,meson8b-ao-arc
> + - const: amlogic,meson-mx-ao-arc
> +
> + firmware-name:
> +$ref: /schemas/types.yaml#/definitions/string
> +description:
> + The name of the firmware which should be loaded for this remote
> + processor.
> +
> + reg:
> +description:
> + Address ranges of the remap and CPU control addresses for the
> + remote processor.
> +minItems: 2
> +
> + reg-names:
> +items:
> + - const: remap
> + - const: cpu
> +
> + resets:
> + minItems: 1
> +
> + clocks:
> +minItems: 1
> +
> + sram:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + phandles to a reserved SRAM region which is used as the memory of
> + the ARC core. The region should be defined as child nodes of the
> + AHB SRAM node as per the generic bindings in
> + Documentation/devicetree/bindings/sram/sram.yaml
> +
> + amlogic,secbus2:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + A phandle to the SECBUS2 region which contains some configuration
> + bits of this remote processor
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - resets
> + - clocks
> + - sram
> + - amlogic,secbus2
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +remoteproc@1c {
> + compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
> + reg = <0x1c 0x8>, <0x38 0x8>;
I'm generally not in favor of mapping "individual" registers, do you
know what hardware block this is part of? Can you express the whole
block as an single entity in your DT?
Regards,
Bjorn
> + reg-names = "remap", "cpu";
> + resets = <&media_cpu_reset>;
> + clocks = <&media_cpu_clock>;
> + sram = <&ahb_sram_ao_arc>;
> + amlogic,secbus2 = <&secbus2>;
> +};
> +
> +...
> --
> 2.30.0
>
Re: [PATCH 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor
On Tue 29 Dec 19:27 CST 2020, Martin Blumenstingl wrote:
> Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
> Always-On (AO) power-domain. This is typically used for waking up the
> ARM cores after system suspend.
>
> The configuration is spread across three different registers:
> - AO_REMAP_REG0 which must be programmed to zero, it's actual purpose
> is unknown. There is a second remap register which is not used in the
> vendor kernel (which served as reference for this driver).
> - AO_CPU_CNTL is used to start and stop the ARC core.
> - AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.
>
> To boot the ARC core we also need to enable it's gate clock and trigger
> a reset.
>
> The actual code for this ARC core can come from an ELF binary, for
> example by building the Zephyr RTOS for an ARC EM4 core and then taking
> "zephyr.elf" as firmware. This executable does not have any "rsc table"
> so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and
> rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).
>
Thanks for the patch Martin, it looks really good. Just some minor
things as I expect a respin of the DT binding as well.
> Signed-off-by: Martin Blumenstingl
> ---
> drivers/remoteproc/Kconfig | 11 ++
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/meson_mx_ao_arc.c | 240 +++
> 3 files changed, 252 insertions(+)
> create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 9e7efe542f69..0e7fb91635fe 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -125,6 +125,17 @@ config KEYSTONE_REMOTEPROC
> It's safe to say N here if you're not interested in the Keystone
> DSPs or just want to use a bare minimum kernel.
>
> +config MESON_MX_AO_ARC_REMOTEPROC
> + tristate "Amlogic Meson6/8/8b/8m2 AO ARC remote processor support"
> + depends on HAS_IOMEM
> + depends on (ARM && ARCH_MESON) || COMPILE_TEST
> + select GENERIC_ALLOCATOR
> + help
> + Say m or y here to have support for the AO ARC remote processor
> + on Amlogic Meson6/Meson8/Meson8b/Meson8m2 SoCs. This is
> + typically used for system suspend.
> + If unusre say N.
> +
> config PRU_REMOTEPROC
> tristate "TI PRU remoteproc support"
> depends on TI_PRUSS
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index bb26c9e4ef9c..ce1abeb30907 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) +=
> omap_remoteproc.o
> obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
> obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> obj-$(CONFIG_KEYSTONE_REMOTEPROC)+= keystone_remoteproc.o
> +obj-$(CONFIG_MESON_MX_AO_ARC_REMOTEPROC)+= meson_mx_ao_arc.o
> obj-$(CONFIG_PRU_REMOTEPROC) += pru_rproc.o
> obj-$(CONFIG_QCOM_PIL_INFO) += qcom_pil_info.o
> obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
> diff --git a/drivers/remoteproc/meson_mx_ao_arc.c
> b/drivers/remoteproc/meson_mx_ao_arc.c
> new file mode 100644
> index ..1deb03ca30f4
> --- /dev/null
> +++ b/drivers/remoteproc/meson_mx_ao_arc.c
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Martin Blumenstingl
>
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "remoteproc_internal.h"
> +
> +#define AO_REMAP_REG00x0
> +#define AO_REMAP_REG10x4
> +
> +#define AO_CPU_CNTL 0x0
> + #define AO_CPU_CNTL_MEM_ADDR_UPPER GENMASK(28, 16)
> + #define AO_CPU_CNTL_HALTBIT(9)
> + #define AO_CPU_CNTL_UNKNONWNBIT(8)
> + #define AO_CPU_CNTL_RUN BIT(0)
> +
> +#define AO_CPU_STAT 0x4
> +
> +#define AO_SECURE_REG0 0x0
> + #define AO_SECURE_REG0_UNKNOWN GENMASK(23, 8)
> +
> +#define MESON_AO_RPROC_SRAM_USABLE_BITS GENMASK(31, 20)
> +#define MESON_AO_RPROC_MEMORY_OFFSET 0x1000
> +
> +struct meson_mx_ao_arc_rproc_priv {
> + void __iomem*remap_base;
> + void __iomem*cpu_base;
> + unsigned long sram_va;
> + phys_addr_t sram_pa;
> + size_t sram_size;
> + struct gen_pool *sram_pool;
> + struct reset_control*arc_reset;
> + struct clk *arc_pclk;
> + struct regmap *secbus2_
Re: [PATCH 2/3] remoteproc: qcom: wcss: populate driver data for IPQ6018
On Fri 29 Jan 11:11 CST 2021, Gokul Sriram Palanisamy wrote:
> Populate hardcoded param using driver data for IPQ6018 SoCs.
>
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> drivers/remoteproc/qcom_q6v5_wcss.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
> b/drivers/remoteproc/qcom_q6v5_wcss.c
> index 7c64bfc..bc9531c 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -965,7 +965,7 @@ static int q6v5_alloc_memory_region(struct q6v5_wcss
> *wcss)
> return 0;
> }
>
> -static int ipq8074_init_clock(struct q6v5_wcss *wcss)
> +static int ipq_init_clock(struct q6v5_wcss *wcss)
> {
> int ret;
>
> @@ -1172,7 +1172,7 @@ static int q6v5_wcss_remove(struct platform_device
> *pdev)
> }
>
> static const struct wcss_data wcss_ipq8074_res_init = {
> - .init_clock = ipq8074_init_clock,
> + .init_clock = ipq_init_clock,
> .q6_firmware_name = "IPQ8074/q6_fw.mdt",
> .m3_firmware_name = "IPQ8074/m3_fw.mdt",
> .crash_reason_smem = WCSS_CRASH_REASON,
> @@ -1185,6 +1185,20 @@ static const struct wcss_data wcss_ipq8074_res_init = {
> .need_mem_protection = true,
> };
>
> +static const struct wcss_data wcss_ipq6018_res_init = {
> + .init_clock = ipq_init_clock,
> + .q6_firmware_name = "IPQ6018/q6_fw.mdt",
> + .m3_firmware_name = "IPQ6018/m3_fw.mdt",
> + .crash_reason_smem = WCSS_CRASH_REASON,
> + .aon_reset_required = true,
> + .wcss_q6_reset_required = true,
> + .bcr_reset_required = false,
> + .ssr_name = "q6wcss",
> + .ops = &q6v5_wcss_ipq8074_ops,
> + .requires_force_stop = true,
> + .need_mem_protection = true,
> +};
> +
> static const struct wcss_data wcss_qcs404_res_init = {
> .init_clock = qcs404_init_clock,
> .init_regulator = qcs404_init_regulator,
> @@ -1203,6 +1217,7 @@ static const struct wcss_data wcss_qcs404_res_init = {
>
> static const struct of_device_id q6v5_wcss_of_match[] = {
> { .compatible = "qcom,ipq8074-wcss-pil", .data = &wcss_ipq8074_res_init
> },
> + { .compatible = "qcom,ipq6018-wcss-pil", .data = &wcss_ipq6018_res_init
> },
As you rebase on the reworked dependency, please sorted alphabetically
(i.e 6 < 8)
Regards,
Bjorn
> { .compatible = "qcom,qcs404-wcss-pil", .data = &wcss_qcs404_res_init },
> { },
> };
> --
> 2.7.4
>
Re: [PATCH v8 2/9] remoteproc: qcom: Add secure PIL support
On Fri 29 Jan 23:20 CST 2021, Gokul Sriram Palanisamy wrote:
> IPQ8074 uses secure PIL. Hence, adding the support for the same.
>
Sorry for not giving this a proper review before Gokul, I've look at it
but been uncertain about what feedback to offer.
> Signed-off-by: Gokul Sriram Palanisamy
> Signed-off-by: Sricharan R
> Signed-off-by: Nikhil Prakash V
I suspect that there should have some "Co-developed-by" here (and in the
other patches)?
> ---
> drivers/remoteproc/qcom_q6v5_wcss.c | 43
> ++---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
> b/drivers/remoteproc/qcom_q6v5_wcss.c
> index c0368bb..4e35e5c 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include "qcom_common.h"
> #include "qcom_pil_info.h"
> #include "qcom_q6v5.h"
> @@ -86,6 +87,9 @@
> #define TCSR_WCSS_CLK_ENABLE 0x14
>
> #define MAX_HALT_REG 3
> +
> +#define WCNSS_PAS_ID 6
> +
> enum {
> WCSS_IPQ8074,
> WCSS_QCS404,
> @@ -134,6 +138,7 @@ struct q6v5_wcss {
> unsigned int crash_reason_smem;
> u32 version;
> bool requires_force_stop;
> + bool need_mem_protection;
>
> struct qcom_rproc_glink glink_subdev;
> struct qcom_rproc_ssr ssr_subdev;
> @@ -152,6 +157,7 @@ struct wcss_data {
> int ssctl_id;
> const struct rproc_ops *ops;
> bool requires_force_stop;
> + bool need_mem_protection;
> };
>
> static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
> @@ -251,6 +257,15 @@ static int q6v5_wcss_start(struct rproc *rproc)
>
> qcom_q6v5_prepare(&wcss->q6v5);
>
> + if (wcss->need_mem_protection) {
> + ret = qcom_scm_pas_auth_and_reset(WCNSS_PAS_ID);
> + if (ret) {
> + dev_err(wcss->dev, "wcss_reset failed\n");
> + return ret;
> + }
> + goto wait_for_reset;
This goto essentially puts the entire old function in an "else" block.
> + }
> +
> /* Release Q6 and WCSS reset */
> ret = reset_control_deassert(wcss->wcss_reset);
> if (ret) {
> @@ -285,6 +300,7 @@ static int q6v5_wcss_start(struct rproc *rproc)
> if (ret)
> goto wcss_q6_reset;
>
> +wait_for_reset:
> ret = qcom_q6v5_wait_for_start(&wcss->q6v5, 5 * HZ);
> if (ret == -ETIMEDOUT)
> dev_err(wcss->dev, "start timed out\n");
> @@ -717,6 +733,15 @@ static int q6v5_wcss_stop(struct rproc *rproc)
> struct q6v5_wcss *wcss = rproc->priv;
> int ret;
>
> + if (wcss->need_mem_protection) {
> + ret = qcom_scm_pas_shutdown(WCNSS_PAS_ID);
> + if (ret) {
> + dev_err(wcss->dev, "not able to shutdown\n");
> + return ret;
> + }
> + goto pas_done;
Same here.
> + }
> +
> /* WCSS powerdown */
> if (wcss->requires_force_stop) {
> ret = qcom_q6v5_request_stop(&wcss->q6v5, NULL);
> @@ -741,6 +766,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
> return ret;
> }
>
> +pas_done:
> clk_disable_unprepare(wcss->prng_clk);
> qcom_q6v5_unprepare(&wcss->q6v5);
>
> @@ -764,9 +790,15 @@ static int q6v5_wcss_load(struct rproc *rproc, const
> struct firmware *fw)
> struct q6v5_wcss *wcss = rproc->priv;
> int ret;
>
> - ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
> - 0, wcss->mem_region, wcss->mem_phys,
> - wcss->mem_size, &wcss->mem_reloc);
> + if (wcss->need_mem_protection)
> + ret = qcom_mdt_load(wcss->dev, fw, rproc->firmware,
> + WCNSS_PAS_ID, wcss->mem_region,
> + wcss->mem_phys, wcss->mem_size,
> + &wcss->mem_reloc);
> + else
> + ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
> + 0, wcss->mem_region, wcss->mem_phys,
> + wcss->mem_size, &wcss->mem_reloc);
And same here.
In practice this means that you're essentially overloading new logic to
all code paths though the driver. Left is some boilerplate code, which I
wish we could refactor into common helper functions in the framework
(e.g. we duplicate q6v5_alloc_memory_region() in a lot of drivers).
So with this in mind, instead of overloading new logic to this entire
driver, could you please submit a new driver for the PAS based IPQ WCSS?
Regards,
Bjorn
> if (ret)
> return ret;
>
> @@ -1032,6 +1064,9 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
> if (!desc)
> return -EINVAL;
>
> + if (desc->need_mem_protection && !qcom_scm_is_available(
Re: [PATCH 1/3] arm64: dts: qcom: sm8350: Remove second reg from pdc
On Wed 17 Mar 09:02 CDT 2021, Marc Zyngier wrote: > On Wed, 17 Mar 2021 09:48:09 +, > Maulik Shah wrote: > > > > Hi Marc, > > > > On 3/17/2021 2:47 PM, Marc Zyngier wrote: > > > On Wed, 17 Mar 2021 05:29:54 +, > > > Maulik Shah wrote: > > >> PDC interrupt controller driver do not use second reg. Remove it. > > > This is a DT file, not a driver. What the driver does is irrelevant. > > > > > > The real question is: what does this range do? > > > > > > Thanks, > > > > > > M. > > > > This is to set interrupt type in SPI config for which there was a > > change [1] but has not gone in for upstream PDC driver. > > > > The second reg is not used in upstream PDC driver, probably when > > posting downstream DT changes for sm8350/sm8250 it was carried in > > device node as is. > > > > As its not mentioned in bindigs as well, dtbs_check reports it as > > additional reg when converted to yaml. > > Then I'd rather you provide accurate documentation in the binding > rather than changing the DT files. Other operating systems may use it, > and it isn't unlikely that Linux could use the feature at some point. > I agree. Maulik, please update the DT binding to document this region as well. It also seems relevant to pursue getting [1] into the upstream Linux kernel. Is this something that you use downstream Maulik? Regards, Bjorn
[PATCH] drm/msm: Remove need for reiterating the compatibles
After spending a non-negligible time trying to figure out why
dpu_kms_init() would dereference a NULL dpu_kms->pdev, it turns out that
in addition to adding the new compatible to the msm_drv of_match_table
one also need to teach add_display_components() to register the child
nodes - which includes the DPU platform_device.
Replace the open coded test for compatibles with a check against the
match data of the mdss device to save others this trouble in the future.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/msm_drv.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..0f6e186a609d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1173,10 +1173,11 @@ static int compare_name_mdp(struct device *dev, void
*data)
return (strstr(dev_name(dev), "mdp") != NULL);
}
-static int add_display_components(struct device *dev,
+static int add_display_components(struct platform_device *pdev,
struct component_match **matchptr)
{
struct device *mdp_dev;
+ struct device *dev = &pdev->dev;
int ret;
/*
@@ -1185,9 +1186,9 @@ static int add_display_components(struct device *dev,
* Populate the children devices, find the MDP5/DPU node, and then add
* the interfaces to our components list.
*/
- if (of_device_is_compatible(dev->of_node, "qcom,mdss") ||
- of_device_is_compatible(dev->of_node, "qcom,sdm845-mdss") ||
- of_device_is_compatible(dev->of_node, "qcom,sc7180-mdss")) {
+ switch (get_mdp_ver(pdev)) {
+ case KMS_MDP5:
+ case KMS_DPU:
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
DRM_DEV_ERROR(dev, "failed to populate children
devices\n");
@@ -1206,9 +1207,11 @@ static int add_display_components(struct device *dev,
/* add the MDP component itself */
drm_of_component_match_add(dev, matchptr, compare_of,
mdp_dev->of_node);
- } else {
+ break;
+ case KMS_MDP4:
/* MDP4 */
mdp_dev = dev;
+ break;
}
ret = add_components_mdp(mdp_dev, matchptr);
@@ -1273,7 +1276,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
int ret;
if (get_mdp_ver(pdev)) {
- ret = add_display_components(&pdev->dev, &match);
+ ret = add_display_components(pdev, &match);
if (ret)
return ret;
}
--
2.29.2
Re: [PATCH 6/6] arm64: dts: qcom: sc7280: Add nodes to boot WPSS
On Sat 13 Mar 15:46 CST 2021, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-03-08 21:51:51)
> > Add miscellaneous nodes to boot the Wireless Processor Subsystem on
>
> Maybe add (WPSS) after the name so we know they're related.
>
> > SC7280 SoCs.
> >
> > Signed-off-by: Sibi Sankar
> > ---
> >
> > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=438217
> > Depends on ipcc dt node enablement from ^^
> >
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 143
> > +++
> > 1 file changed, 143 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 18637c369c1d..4f03c468df51 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -244,12 +251,131 @@
> > reg = <0 0x8000 0 0>;
> > };
> >
> > + tcsr_mutex: hwlock {
> > + compatible = "qcom,tcsr-mutex";
> > + syscon = <&tcsr_mutex_regs 0 0x1000>;
> > + #hwlock-cells = <1>;
> > + };
>
> Is this node in the right place? I think the node above it is 'memory'?
> In which case 'hwlock' comes before 'memory' alphabetically.
>
Thanks for spotting this, as it's no longer acceptable to have a
standalone "syscon" node I was asked to rewrite the binding for this a
few months ago. So the tcsr_mutex should now be represented with a reg
under /soc.
> > +
> > + smem {
> > + compatible = "qcom,smem";
> > + memory-region = <&smem_mem>;
> > + hwlocks = <&tcsr_mutex 3>;
> > + };
> > +
> > firmware {
> > scm {
> > compatible = "qcom,scm-sc7280", "qcom,scm";
> > };
> > };
> >
> > + smp2p-adsp {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <443>, <429>;
> > + interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = <&ipcc IPCC_CLIENT_LPASS
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <2>;
> > +
> > + adsp_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + adsp_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > +
> > + smp2p-cdsp {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <94>, <432>;
> > + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = <&ipcc IPCC_CLIENT_CDSP
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <5>;
> > +
> > + cdsp_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + cdsp_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > +
> > + smp2p-mpss {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <435>, <428>;
> > + interrupts-extended = <&ipcc IPCC_CLIENT_MPSS
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = <&ipcc IPCC_CLIENT_MPSS
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <1>;
> > +
> > + modem_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + modem_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
>
> Do these names need to have 'master' and 'slave' in them? We're trying
> to avoid these terms. See Documentation/process/coding-style.rst Section
> 4 naming.
>
They need to match the naming in the firmware, but I would welcome a
future change to something in line with the coding style and simply more
descriptive.
Regards
[PATCH v2 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
The reserved-memory regions used for carrying firmware to be run on the
various cores and co-processors in a Qualcomm platform differs in size,
placement and presence based on each device's feature set and security
configuration.
Rather than providing some basic set that works on the MTP and then
piecemeal patch this up on the various devices, push the configuration
of these regions out to the individual device dts files.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Added lost memory-region to the db845c wlan node, as spotted by Doug.
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 90 +--
arch/arm64/boot/dts/qcom/sdm845-db845c.dts| 87 ++
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 87 ++
.../boot/dts/qcom/sdm845-oneplus-common.dtsi | 78 +++-
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 45 ++
arch/arm64/boot/dts/qcom/sdm845.dtsi | 83 -
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 86 ++
7 files changed, 431 insertions(+), 125 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 216a74f0057c..71ef92fd8909 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -153,36 +153,66 @@ panel_in_edp: endpoint {
* all modifications to the memory map (from sdm845.dtsi) in one place.
*/
-/*
- * Our mpss_region is 8MB bigger than the default one and that conflicts
- * with venus_mem and cdsp_mem.
- *
- * For venus_mem we'll delete and re-create at a different address.
- *
- * cdsp_mem isn't used on cheza right now so we won't bother re-creating it;
but
- * that also means we need to delete cdsp_pas.
- */
-/delete-node/ &venus_mem;
-/delete-node/ &cdsp_mem;
-/delete-node/ &cdsp_pas;
-/delete-node/ &gpu_mem;
-
-/* Increase the size from 120 MB to 128 MB */
-&mpss_region {
- reg = <0 0x8e00 0 0x800>;
-};
-
-/* Increase the size from 2MB to 8MB */
-&rmtfs_mem {
- reg = <0 0x88f0 0 0x80>;
-};
-
/ {
reserved-memory {
+ tz_mem: memory@8620 {
+ reg = <0 0x8620 0 0x2d0>;
+ no-map;
+ };
+
+ rmtfs_mem: memory@88f0 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0 0x88f0 0 0x80>;
+ no-map;
+
+ qcom,client-id = <1>;
+ qcom,vmid = <15>;
+ };
+
+ ipa_fw_mem: memory@8c40 {
+ reg = <0 0x8c40 0 0x1>;
+ no-map;
+ };
+
+ ipa_gsi_mem: memory@8c41 {
+ reg = <0 0x8c41 0 0x5000>;
+ no-map;
+ };
+
+ adsp_mem: memory@8c50 {
+ reg = <0 0x8c50 0 0x1a0>;
+ no-map;
+ };
+
+ wlan_msa_mem: memory@8df0 {
+ reg = <0 0x8df0 0 0x10>;
+ no-map;
+ };
+
+ mpss_region: memory@8e00 {
+ reg = <0 0x8e00 0 0x800>;
+ no-map;
+ };
+
venus_mem: memory@9600 {
reg = <0 0x9600 0 0x50>;
no-map;
};
+
+ mba_region: memory@9650 {
+ reg = <0 0x9650 0 0x20>;
+ no-map;
+ };
+
+ slpi_mem: memory@9670 {
+ reg = <0 0x9670 0 0x140>;
+ no-map;
+ };
+
+ spss_mem: memory@97b0 {
+ reg = <0 0x97b0 0 0x10>;
+ no-map;
+ };
};
};
@@ -206,7 +236,6 @@ flash@0 {
};
};
-
&apps_rsc {
pm8998-rpmh-regulators {
compatible = "qcom,pm8998-rpmh-regulators";
@@ -645,6 +674,14 @@ &adreno_smmu {
&mss_pil {
iommus = <&apps_smmu 0x781 0x0>,
<&apps_smmu 0x724 0x3>;
+
+ mba {
+ memory-region = <&mba_region>;
+ };
+
+ mpss {
+ memory-region = <&mpss_region>;
+ };
};
&pm8998_pwrkey {
@@ -850,6 +887,7 @@ &usb_2_qmpphy {
&wifi {
status = "okay";
+ memory-region = <&wlan_msa_mem>;
vdd-0.8-cx-mx-supply = <&src_pp800_l5a >;
vdd-1.8-xo-supply = <&pp1800_l7a_wcn3990>;
@@ -1321,6 +1359,8 @@ config {
};
&venus {
+
[PATCH v2 2/2] arm64: dts: qcom: sdm850-yoga: Enable IPA
The ipa_fws.elf found in the Lenovo Yoga C630 isn't packed like the one
found in e.g. the MTP, so it doesn't fit in the "standard" ipa_fws
memory region. Further more, authentication of ipa_fws at the usual base
address is rejected by the Peripheral Authentication Service (in
TrustZone), so some shuffling and trial and error was used to come up
with acceptable regions.
With this in order, enable the IPA device.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index 7d84f8a2db4d..f40fcd5d08d3 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -73,28 +73,23 @@ rmtfs_mem: memory@88f0 {
qcom,vmid = <15>;
};
- ipa_fw_mem: memory@8c40 {
- reg = <0 0x8c40 0 0x1>;
+ wlan_msa_mem: memory@8c40 {
+ reg = <0 0x8c40 0 0x10>;
no-map;
};
- ipa_gsi_mem: memory@8c41 {
- reg = <0 0x8c41 0 0x5000>;
+ gpu_mem: memory@8c515000 {
+ reg = <0 0x8c515000 0 0x2000>;
no-map;
};
- gpu_mem: memory@8c415000 {
- reg = <0 0x8c415000 0 0x2000>;
+ ipa_fw_mem: memory@8c517000 {
+ reg = <0 0x8c517000 0 0x5a000>;
no-map;
};
- adsp_mem: memory@8c50 {
- reg = <0 0x8c50 0 0x1a0>;
- no-map;
- };
-
- wlan_msa_mem: memory@8df0 {
- reg = <0 0x8df0 0 0x10>;
+ adsp_mem: memory@8c60 {
+ reg = <0 0x8c60 0 0x1a0>;
no-map;
};
@@ -486,6 +481,11 @@ ecsh: hid@5c {
};
};
+&ipa {
+ status = "okay";
+ memory-region = <&ipa_fw_mem>;
+};
+
&mdss {
status = "okay";
};
--
2.29.2
[PATCH v2] remoteproc: qcom_q6v5_mss: Validate p_filesz in ELF loader
Analog to the issue in the common mdt_loader code the MSS ELF loader
does not validate that p_filesz bytes will fit in the memory region and
that the loaded segments are not truncated. Fix this in the same way
as proposed for the mdt_loader.
Fixes: 135b9e8d1cd8 ("remoteproc: qcom_q6v5_mss: Validate modem blob firmware
size before load")
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Don't just break the loop, goto release_firmware.
- Release seg_fw as well.
drivers/remoteproc/qcom_q6v5_mss.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 66106ba25ba3..14e0ce5f18f5 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1210,6 +1210,14 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
goto release_firmware;
}
+ if (phdr->p_filesz > phdr->p_memsz) {
+ dev_err(qproc->dev,
+ "refusing to load segment %d with p_filesz >
p_memsz\n",
+ i);
+ ret = -EINVAL;
+ goto release_firmware;
+ }
+
ptr = memremap(qproc->mpss_phys + offset, phdr->p_memsz,
MEMREMAP_WC);
if (!ptr) {
dev_err(qproc->dev,
@@ -1241,6 +1249,16 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
goto release_firmware;
}
+ if (seg_fw->size != phdr->p_filesz) {
+ dev_err(qproc->dev,
+ "failed to load segment %d from
truncated file %s\n",
+ i, fw_name);
+ ret = -EINVAL;
+ release_firmware(seg_fw);
+ memunmap(ptr);
+ goto release_firmware;
+ }
+
release_firmware(seg_fw);
}
--
2.29.2
Re: [PATCH] arm64: dts: qcom: sc7280: Add PMIC peripherals for SC7280
On Thu 11 Mar 04:40 CST 2021, satya priya wrote:
> Add PM7325/PM8350C/PMK8350/PMR735A peripherals such as PON,
> GPIOs, RTC and other PMIC infra modules for SC7280.
>
Overall this looks good, just two small things below.
> Signed-off-by: satya priya
> ---
> This patch depends on base DT and board files for SC7280 to merge first
> https://lore.kernel.org/patchwork/project/lkml/list/?series=487403
>
> arch/arm64/boot/dts/qcom/pm7325.dtsi | 60
> arch/arm64/boot/dts/qcom/pm8350c.dtsi | 60
> arch/arm64/boot/dts/qcom/pmk8350.dtsi | 104
> ++
> arch/arm64/boot/dts/qcom/pmr735a.dtsi | 60
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 8 +++
> 5 files changed, 292 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/pm7325.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/pm8350c.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/pmk8350.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/pmr735a.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/pm7325.dtsi
> b/arch/arm64/boot/dts/qcom/pm7325.dtsi
> new file mode 100644
> index 000..393b256
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/pm7325.dtsi
> @@ -0,0 +1,60 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +// Copyright (c) 2021, The Linux Foundation. All rights reserved.
> +
> +#include
> +#include
> +
> +&spmi_bus {
> + pm7325: pmic@1 {
> + compatible = "qcom,pm7325", "qcom,spmi-pmic";
> + reg = <0x1 SPMI_USID>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pm7325_tz: temp-alarm@a00 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0xa00>;
> + interrupts = <0x1 0xa 0x0 IRQ_TYPE_EDGE_BOTH>;
> + #thermal-sensor-cells = <0>;
> + };
> +
> + pm7325_gpios: gpios@8800 {
> + compatible = "qcom,pm7325-gpio", "qcom,spmi-gpio";
> + reg = <0x8800>;
> + gpio-controller;
> + gpio-ranges = <&pm7325_gpios 0 0 10>;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
> +};
> +
> +&thermal_zones {
> + pm7325_temp_alarm: pm7325_tz {
'_' is not allowed to be used in node names, there's a few of these
sprinkled through the patch. Please replace them with '-'.
> + polling-delay-passive = <100>;
> + polling-delay = <0>;
> + thermal-governor = "step_wise";
> + thermal-sensors = <&pm7325_tz>;
> +
> + trips {
> + pm7325_trip0: trip0 {
> + temperature = <95000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + pm7325_trip1: trip1 {
> + temperature = <115000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> +
> + pm7325_trip2: trip2 {
> + temperature = <145000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> + };
> +};
[..]
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 8af6d77..25402d4 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -606,4 +606,12 @@
>,
>;
> };
> +
> + thermal_zones: thermal-zones {
> + };
> };
> +
> +#include "pm7325.dtsi"
> +#include "pm8350c.dtsi"
> +#include "pmk8350.dtsi"
> +#include "pmr735a.dtsi"
Is there any particular reason for you including these at the end of
sc7270.dtsi, rather than the top like we do in other platforms?
Also, are all SC7280 devices always coming with this quartet? We've seen
variations of this in the past and therefor typically include them from
the board dts instead.
Regards,
Bjorn
Re: [PATCH] dt-bindings: mailbox: Add compatible for SM8350 IPCC
On Thu 11 Mar 23:12 CST 2021, Vinod Koul wrote: Adding Jassi as recipient. Please let Vinod know if you want him to resend this patch to you. (I send a patch for MAINTAINERS yesterday) > Add the compatible string for SM8350 IPCC block on this SoC > Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Vinod Koul > --- > Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > index 168beeb7e9f7..fe17ba9b84f2 100644 > --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > @@ -25,6 +25,7 @@ properties: > items: >- enum: >- qcom,sm8250-ipcc > + - qcom,sm8350-ipcc >- const: qcom,ipcc > >reg: > -- > 2.26.2 >
Re: [PATCH v6 1/4] dt-bindings: Introduce SoC sleep stats bindings
On Thu 04 Feb 08:21 CST 2021, Maulik Shah wrote:
> From: Mahesh Sivasubramanian
>
> Add device binding documentation for Qualcomm Technologies, Inc. (QTI)
> SoC sleep stats driver. The driver is used for displaying SoC sleep
> statistic maintained by Always On Processor or Resource Power Manager.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Mahesh Sivasubramanian
> Signed-off-by: Lina Iyer
> Signed-off-by: Maulik Shah
> Reviewed-by: Rob Herring
> Reviewed-by: Bjorn Andersson
> Reviewed-by: Stephen Boyd
> ---
> .../bindings/soc/qcom/soc-sleep-stats.yaml | 46
> ++
> 1 file changed, 46 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.yaml
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.yaml
> b/Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.yaml
> new file mode 100644
> index 000..1e012ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/qcom/soc-sleep-stats.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies, Inc. (QTI) SoC sleep stats bindings
> +
> +maintainers:
> + - Maulik Shah
> + - Lina Iyer
> +
> +description:
> + Always On Processor/Resource Power Manager maintains statistics of the SoC
> + sleep modes involving powering down of the rails and oscillator clock.
> +
> + Statistics includes SoC sleep mode type, number of times low power mode
> were
> + entered, time of last entry, time of last exit and accumulated sleep
> duration.
> +
> +properties:
> + compatible:
> +enum:
> + - qcom,rpmh-sleep-stats
> + - qcom,rpm-sleep-stats
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + # Example of rpmh sleep stats
> + - |
> +rpmh-sleep-stats@c3f {
> + compatible = "qcom,rpmh-sleep-stats";
> + reg = <0 0x0c3f 0 0x400>;
The example is built with #address-cells = <1> and #size-cells = <1>, so
this needs to be reg = <0x0c3f 0x400>.
Regards,
Bjorn
> +};
> + # Example of rpm sleep stats
> + - |
> +rpm-sleep-stats@469 {
> + compatible = "qcom,rpm-sleep-stats";
> + reg = <0 0x0469 0 0x400>;
> +};
> +...
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [PATCH v6 1/4] dt-bindings: Introduce SoC sleep stats bindings
On Mon 08 Feb 18:23 CST 2021, Stephen Boyd wrote:
> Quoting Maulik Shah (2021-02-04 06:21:45)
> > +
> > +description:
> > + Always On Processor/Resource Power Manager maintains statistics of the
> > SoC
> > + sleep modes involving powering down of the rails and oscillator clock.
> > +
> > + Statistics includes SoC sleep mode type, number of times low power mode
> > were
> > + entered, time of last entry, time of last exit and accumulated sleep
> > duration.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - qcom,rpmh-sleep-stats
> > + - qcom,rpm-sleep-stats
> > +
> > + reg:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> > + # Example of rpmh sleep stats
> > + - |
> > +rpmh-sleep-stats@c3f {
> > + compatible = "qcom,rpmh-sleep-stats";
> > + reg = <0 0x0c3f 0 0x400>;
> > +};
>
> Maybe it should just be another reg property of the rpmh or rpm node?
> Then the rpmh driver can create the stats "device" at driver probe time,
> or just roll it into the same thing. It looks pretty weird to have a
> device in DT for this given that it's not really hardware, more like a
> place that the processor writes some stuff about what's going on in the
> SoC related to power management.
>
Given that there is some hardware (although just a chunk of sram) and
that the same driver is used for RPM, which we don't represent on the
mmio bus I think the proposed design makes sense.
Regards,
Bjorn
> > + # Example of rpm sleep stats
> > + - |
> > +rpm-sleep-stats@469 {
> > + compatible = "qcom,rpm-sleep-stats";
> > + reg = <0 0x0469 0 0x400>;
> > +};
> > +...
Re: [PATCH net] net: ipa: terminate message handler arrays
On Fri 12 Mar 09:12 CST 2021, Alex Elder wrote:
> When a QMI handle is initialized, an array of message handler
> structures is provided, defining how any received message should
> be handled based on its type and message ID. The QMI core code
> traverses this array when a message arrives and calls the function
> associated with the (type, msg_id) found in the array.
>
> The array is supposed to be terminated with an empty (all zero)
> entry though. Without it, an unsupported message will cause
> the QMI core code to go past the end of the array.
>
> Fix this bug, by properly terminating the message handler arrays
> provided when QMI handles are set up by the IPA driver.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Fixes: 530f9216a9537 ("soc: qcom: ipa: AP/modem communications")
> Reported-by: Sujit Kautkar
> Signed-off-by: Alex Elder
> ---
> drivers/net/ipa/ipa_qmi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ipa/ipa_qmi.c b/drivers/net/ipa/ipa_qmi.c
> index 2fc64483f2753..e594bf3b600f0 100644
> --- a/drivers/net/ipa/ipa_qmi.c
> +++ b/drivers/net/ipa/ipa_qmi.c
> @@ -249,6 +249,7 @@ static const struct qmi_msg_handler
> ipa_server_msg_handlers[] = {
> .decoded_size = IPA_QMI_DRIVER_INIT_COMPLETE_REQ_SZ,
> .fn = ipa_server_driver_init_complete,
> },
> + { },
> };
>
> /* Handle an INIT_DRIVER response message from the modem. */
> @@ -269,6 +270,7 @@ static const struct qmi_msg_handler
> ipa_client_msg_handlers[] = {
> .decoded_size = IPA_QMI_INIT_DRIVER_RSP_SZ,
> .fn = ipa_client_init_driver,
> },
> + { },
> };
>
> /* Return a pointer to an init modem driver request structure, which contains
> --
> 2.27.0
>
[PATCH 2/2] arm64: dts: qcom: sm8350: Add wakeup-parent to tlmm
Now that TLMM has the wakeup table, specify the Power Domain Controller
to be the wakeup-parent of TLMM.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 2c02f451379b..d6295212acf7 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -642,6 +642,7 @@ tlmm: pinctrl@f10 {
interrupt-controller;
#interrupt-cells = <2>;
gpio-ranges = <&tlmm 0 0 203>;
+ wakeup-parent = <&pdc>;
qup_uart3_default_state: qup-uart3-default-state {
rx {
--
2.29.2
[PATCH 1/2] pinctrl: qcom: sm8350: add GPIO wakeup interrupt map
From: Lina Iyer
GPIOs that can be configured as wakeup sources, have their interrupt
lines routed to PDC interrupt controller. Provide the interrupt map of
the GPIO to its wakeup capable interrupt parent.
Signed-off-by: Lina Iyer
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/qcom/pinctrl-sm8350.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sm8350.c
b/drivers/pinctrl/qcom/pinctrl-sm8350.c
index a406ed0ec7d3..4d8f8636c2b3 100644
--- a/drivers/pinctrl/qcom/pinctrl-sm8350.c
+++ b/drivers/pinctrl/qcom/pinctrl-sm8350.c
@@ -1603,6 +1603,25 @@ static const struct msm_pingroup sm8350_groups[] = {
[206] = SDC_PINGROUP(sdc2_data, 0x1cf000, 9, 0),
};
+static const struct msm_gpio_wakeirq_map sm8350_pdc_map[] = {
+ { 2, 117 }, { 7, 82 }, { 11, 83 }, { 14, 80 }, { 15, 146 },
+ { 19, 121 }, { 23, 84 }, { 26, 86 }, { 27, 75 }, { 31, 85 },
+ { 32, 97 }, { 34, 98 }, { 35, 131 }, { 36, 79 }, { 38, 99 },
+ { 39, 92 }, { 40, 101 }, { 43, 137 }, { 44, 102 }, { 46, 96 },
+ { 47, 93 }, { 50, 108 }, { 51, 127 }, { 55, 128 }, { 56, 81 },
+ { 59, 112 }, { 60, 119 }, { 63, 73 }, { 67, 74 }, { 71, 134 },
+ { 75, 103 }, { 79, 104 }, { 80, 126 }, { 81, 139 }, { 82, 140 },
+ { 83, 141 }, { 84, 124 }, { 85, 109 }, { 86, 143 }, { 87, 138 },
+ { 88, 122 }, { 89, 113 }, { 90, 114 }, { 91, 115 }, { 92, 76 },
+ { 95, 147 }, { 96, 148 }, { 98, 149 }, { 99, 150 }, { 115, 125 },
+ { 116, 106 }, { 117, 105 }, { 118, 116 }, { 119, 123 }, { 130, 145 },
+ { 136, 72 }, { 140, 100 }, { 151, 110 }, { 153, 95 }, { 155, 107 },
+ { 156, 94 }, { 157, 111 }, { 159, 118 }, { 162, 77 }, { 165, 78 },
+ { 169, 70 }, { 172, 132 }, { 174, 87 }, { 175, 88 }, { 177, 89 },
+ { 179, 120 }, { 180, 129 }, { 183, 90 }, { 185, 136 }, { 187, 142 },
+ { 190, 144 }, { 198, 91 }, { 200, 133 }, { 202, 135 },
+};
+
static const struct msm_pinctrl_soc_data sm8350_tlmm = {
.pins = sm8350_pins,
.npins = ARRAY_SIZE(sm8350_pins),
@@ -1611,6 +1630,8 @@ static const struct msm_pinctrl_soc_data sm8350_tlmm = {
.groups = sm8350_groups,
.ngroups = ARRAY_SIZE(sm8350_groups),
.ngpios = 204,
+ .wakeirq_map = sm8350_pdc_map,
+ .nwakeirq_map = ARRAY_SIZE(sm8350_pdc_map),
};
static int sm8350_tlmm_probe(struct platform_device *pdev)
--
2.29.2
Re: [PATCH 3/3] drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk
On Thu 04 Mar 17:52 CST 2021, Douglas Anderson wrote:
> In commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
> DDC") we attempted to make the ti-sn65dsi86 bridge properly read the
> EDID from the panel. That commit kinda worked but it had some serious
> problems.
>
> The problems all stem from the fact that userspace wants to be able to
> read the EDID before it explicitly enables the panel. For eDP panels,
> though, we don't actually power the panel up until the pre-enable
> stage and the pre-enable call happens right before the enable call
> with no way to interject in-between. For eDP panels, you can't read
> the EDID until you power the panel. The result was that
> ti_sn_bridge_connector_get_modes() was always failing to read the EDID
> (falling back to what drm_panel_get_modes() returned) until _after_
> the EDID was needed.
>
> To make it concrete, on my system I saw this happen:
> 1. We'd attach the bridge.
> 2. Userspace would ask for the EDID (several times). We'd try but fail
>to read the EDID over and over again and fall back to the hardcoded
>modes.
> 3. Userspace would decide on a mode based only on the hardcoded modes.
> 4. Userspace would ask to turn the panel on.
> 5. Userspace would (eventually) check the modes again (in Chrome OS
>this happens on the handoff from the boot splash screen to the
>browser). Now we'd read them properly and, if they were different,
>userspace would request to change the mode.
>
> The fact that userspace would always end up using the hardcoded modes
> at first significantly decreases the benefit of the EDID
> reading. Also: if the modes were even a tiny bit different we'd end up
> doing a wasteful modeset and at boot.
>
> As a side note: at least early EDID read failures were relatively
> fast. Though the old ti_sn_bridge_connector_get_modes() did call
> pm_runtime_get_sync() it didn't program the important "HPD_DISABLE"
> bit. That meant that all the AUX transfers failed pretty quickly.
>
> In any case, enough about the problem. How are we fixing it? Obviously
> we need to power the panel on _before_ reading the EDID, but how? It
> turns out that there's really no problem with just doing all the work
> of our pre_enable() function right at attach time and reading the EDID
> right away. We'll do that. It's not as easy as it sounds, though,
> because:
>
> 1. Powering the panel up and down is a pretty expensive operation. Not
>only do we need to wait for the HPD line which seems to take up to
>200 ms on most panels, but also most panels say that once you power
>them off you need to wait at least 500 ms before powering them on
>again. We really don't want to incur 700 ms of time here.
>
> 2. If we happen not to have a fixed "refclk" we've got a
>chicken-and-egg problem. We seem to need the clock setup to read
>the EDID. Without a fixed "refclk", though, the bridge runs with
>the MIPI pixel clock which means you've got to use a hardcoded mode
>for the MIPI pixel clock.
>
> We'll solve problem #1 above by leaving the panel powered on for a
> little while after we read the EDID. If enough time passes and nobody
> turns the panel on then we'll undo our work. NOTE: there are no
> functional problems if someone turns the panel on after a long delay,
> it just might take a little longer to turn on.
>
> We'll solve problem #2 by simply _always_ using a hardcoded mode (not
> reading the EDID) if a "refclk" wasn't provided. While it might be
> possible to fudge something together to support this, it's my belief
> that nobody is using this mode in real life since it's really
> inflexible. I saw it used for some really early prototype hardware
> that was thrown in the e-waste bin years ago when we realized how
> inflexible it was. In any case, if someone is using this they're in no
> worse shape than they were before the (fairly recent) commit
> 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC").
>
> NOTE: while this patch feels a bit hackish, I'm not sure there's much
> we can do better without a more fundamental DRM API change. After
> looking at it a bunch, it also doesn't feel as hacky to me as I first
> thought. The things that pre-enable does are well defined and well
> understood and there should be no problems with doing them early nor
> with doing them before userspace requests anything.
>
> Fixes: 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC")
> Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
Re: [PATCH 2/3] drm/bridge: ti-sn65dsi86: Move code in prep for EDID read fix
On Thu 04 Mar 17:52 CST 2021, Douglas Anderson wrote:
> This patch is _only_ code motion to prepare for the patch
> ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if
> refclk") and make it easier to understand.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 196 +-
> 1 file changed, 98 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 942019842ff4..491c9c4f32d1 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -345,6 +345,104 @@ static int ti_sn_bridge_parse_regulators(struct
> ti_sn_bridge *pdata)
> pdata->supplies);
> }
>
> +static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
> +{
> + u32 bit_rate_khz, clk_freq_khz;
> + struct drm_display_mode *mode =
> + &pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> + bit_rate_khz = mode->clock *
> + mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> + clk_freq_khz = bit_rate_khz / (pdata->dsi->lanes * 2);
> +
> + return clk_freq_khz;
> +}
> +
> +/* clk frequencies supported by bridge in Hz in case derived from REFCLK pin
> */
> +static const u32 ti_sn_bridge_refclk_lut[] = {
> + 1200,
> + 1920,
> + 2600,
> + 2700,
> + 3840,
> +};
> +
> +/* clk frequencies supported by bridge in Hz in case derived from DACP/N pin
> */
> +static const u32 ti_sn_bridge_dsiclk_lut[] = {
> + 46800,
> + 38400,
> + 41600,
> + 48600,
> + 46080,
> +};
> +
> +static void ti_sn_bridge_set_refclk_freq(struct ti_sn_bridge *pdata)
> +{
> + int i;
> + u32 refclk_rate;
> + const u32 *refclk_lut;
> + size_t refclk_lut_size;
> +
> + if (pdata->refclk) {
> + refclk_rate = clk_get_rate(pdata->refclk);
> + refclk_lut = ti_sn_bridge_refclk_lut;
> + refclk_lut_size = ARRAY_SIZE(ti_sn_bridge_refclk_lut);
> + clk_prepare_enable(pdata->refclk);
> + } else {
> + refclk_rate = ti_sn_bridge_get_dsi_freq(pdata) * 1000;
> + refclk_lut = ti_sn_bridge_dsiclk_lut;
> + refclk_lut_size = ARRAY_SIZE(ti_sn_bridge_dsiclk_lut);
> + }
> +
> + /* for i equals to refclk_lut_size means default frequency */
> + for (i = 0; i < refclk_lut_size; i++)
> + if (refclk_lut[i] == refclk_rate)
> + break;
> +
> + regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG, REFCLK_FREQ_MASK,
> +REFCLK_FREQ(i));
> +}
> +
> +static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> + clk_disable_unprepare(pdata->refclk);
> +
> + pm_runtime_put_sync(pdata->dev);
> +}
> +
> +static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> + pm_runtime_get_sync(pdata->dev);
> +
> + /* configure bridge ref_clk */
> + ti_sn_bridge_set_refclk_freq(pdata);
> +
> + /*
> + * HPD on this bridge chip is a bit useless. This is an eDP bridge
> + * so the HPD is an internal signal that's only there to signal that
> + * the panel is done powering up. ...but the bridge chip debounces
> + * this signal by between 100 ms and 400 ms (depending on process,
> + * voltage, and temperate--I measured it at about 200 ms). One
> + * particular panel asserted HPD 84 ms after it was powered on meaning
> + * that we saw HPD 284 ms after power on. ...but the same panel said
> + * that instead of looking at HPD you could just hardcode a delay of
> + * 200 ms. We'll assume that the panel driver will have the hardcoded
> + * delay in its prepare and always disable HPD.
> + *
> + * If HPD somehow makes sense on some future panel we'll have to
> + * change this to be conditional on someone specifying that HPD should
> + * be used.
> + */
> + regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE,
> +HPD_DISABLE);
> +
> + drm_panel_prepare(pdata->panel);
> +}
> +
> static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
&g
Re: [PATCH 1/3] drm/bridge: ti-sn65dsi86: Simplify refclk handling
On Thu 04 Mar 17:51 CST 2021, Douglas Anderson wrote:
> The clock framework makes it simple to deal with an optional clock.
> You can call clk_get_optional() and if the clock isn't specified it'll
> just return NULL without complaint. It's valid to pass NULL to
> enable/disable/prepare/unprepare. Let's make use of this to simplify
> things a tiny bit.
>
> NOTE: this makes things look a tad bit asymmetric now since we check
> for NULL before clk_prepare_enable() but not for
> clk_disable_unprepare(). This seemed OK to me. We already have to
> check for NULL in the enable case anyway so why not avoid the extra
> call?
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f27306c51e4d..942019842ff4 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -1261,14 +1261,9 @@ static int ti_sn_bridge_probe(struct i2c_client
> *client,
> return ret;
> }
>
> - pdata->refclk = devm_clk_get(pdata->dev, "refclk");
> - if (IS_ERR(pdata->refclk)) {
> - ret = PTR_ERR(pdata->refclk);
> - if (ret == -EPROBE_DEFER)
> - return ret;
> - DRM_DEBUG_KMS("refclk not found\n");
> - pdata->refclk = NULL;
> - }
> + pdata->refclk = devm_clk_get_optional(pdata->dev, "refclk");
> + if (IS_ERR(pdata->refclk))
> + return PTR_ERR(pdata->refclk);
>
> ret = ti_sn_bridge_parse_dsi_host(pdata);
> if (ret)
> --
> 2.30.1.766.gb4fecdf3b7-goog
>
Re: [PATCH 1/3] pinctrl: qcom: spmi-gpio: Add support for four variants
On Fri 05 Mar 00:29 CST 2021, satya priya wrote:
> Add PM7325, PM8350c, PMK8350 and PMR735A compatibles for GPIO
> support.
>
Acked-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: satya priya
> ---
> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index 9801c71..90f4f78 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -1131,6 +1131,10 @@ static const struct of_device_id pmic_gpio_of_match[]
> = {
> { .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
> /* pmx55 has 11 GPIOs with holes on 3, 7, 10, 11 */
> { .compatible = "qcom,pmx55-gpio", .data = (void *) 11 },
> + { .compatible = "qcom,pm7325-gpio", .data = (void *) 10 },
> + { .compatible = "qcom,pm8350c-gpio", .data = (void *) 9 },
> + { .compatible = "qcom,pmk8350-gpio", .data = (void *) 4 },
> + { .compatible = "qcom,pmr735a-gpio", .data = (void *) 4 },
> { },
> };
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
[PATCH 3/5] soc: qcom: wcnss_ctrl: Introduce local variable "dev"
Introduce a local variable to carry the struct device *, to reduce the
line lengths in the next patch.
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/wcnss_ctrl.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index 32bed249f90e..358526b9de06 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -199,6 +199,7 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss, bool
*expect_cbc)
{
struct wcnss_download_nv_req *req;
const struct firmware *fw;
+ struct device *dev = wcnss->dev;
const void *data;
ssize_t left;
int ret;
@@ -207,9 +208,9 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss, bool
*expect_cbc)
if (!req)
return -ENOMEM;
- ret = request_firmware(&fw, NVBIN_FILE, wcnss->dev);
+ ret = request_firmware(&fw, NVBIN_FILE, dev);
if (ret < 0) {
- dev_err(wcnss->dev, "Failed to load nv file %s: %d\n",
+ dev_err(dev, "Failed to load nv file %s: %d\n",
NVBIN_FILE, ret);
goto free_req;
}
@@ -235,7 +236,7 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss, bool
*expect_cbc)
ret = rpmsg_send(wcnss->channel, req, req->hdr.len);
if (ret < 0) {
- dev_err(wcnss->dev, "failed to send smd packet\n");
+ dev_err(dev, "failed to send smd packet\n");
goto release_fw;
}
@@ -248,7 +249,7 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss, bool
*expect_cbc)
ret = wait_for_completion_timeout(&wcnss->ack, WCNSS_REQUEST_TIMEOUT);
if (!ret) {
- dev_err(wcnss->dev, "timeout waiting for nv upload ack\n");
+ dev_err(dev, "timeout waiting for nv upload ack\n");
ret = -ETIMEDOUT;
} else {
*expect_cbc = wcnss->ack_status == WCNSS_ACK_COLD_BOOTING;
--
2.29.2
[PATCH 4/5] soc: qcom: wcnss_ctrl: Allow reading firmware-name from DT
The WLAN NV firmware blob differs between platforms, and possibly
devices, so add support in the wcnss_ctrl driver for reading the path of
this file from DT in order to allow these files to live in a generic
file system (or linux-firmware).
The new property is optional and the code falls back to the old filename
if the property isn't specified.
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/wcnss_ctrl.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index 358526b9de06..2a06d631e415 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -200,6 +200,7 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss, bool
*expect_cbc)
struct wcnss_download_nv_req *req;
const struct firmware *fw;
struct device *dev = wcnss->dev;
+ const char *nvbin = NVBIN_FILE;
const void *data;
ssize_t left;
int ret;
@@ -208,10 +209,13 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss,
bool *expect_cbc)
if (!req)
return -ENOMEM;
- ret = request_firmware(&fw, NVBIN_FILE, dev);
+ ret = of_property_read_string(dev->of_node, "firmware-name", &nvbin);
+ if (ret < 0 && ret != -EINVAL)
+ goto free_req;
+
+ ret = request_firmware(&fw, nvbin, dev);
if (ret < 0) {
- dev_err(dev, "Failed to load nv file %s: %d\n",
- NVBIN_FILE, ret);
+ dev_err(dev, "Failed to load nv file %s: %d\n", nvbin, ret);
goto free_req;
}
--
2.29.2
[PATCH 5/5] arm64: dts: qcom: msm8916: Enable modem and WiFi
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 6aef0c2e4f0a..448e3561ef63 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -305,6 +305,12 @@ &mdss {
status = "okay";
};
+&mpss {
+ status = "okay";
+
+ firmware-name = "qcom/msm8916/mba.mbn", "qcom/msm8916/modem.mbn";
+};
+
&pm8916_resin {
status = "okay";
linux,code = ;
@@ -312,6 +318,8 @@ &pm8916_resin {
&pronto {
status = "okay";
+
+ firmware-name = "qcom/msm8916/wcnss.mbn";
};
&sdhc_1 {
@@ -394,6 +402,10 @@ &wcd_codec {
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
+&wcnss_ctrl {
+ firmware-name = "qcom/msm8916/WCNSS_qcom_wlan_nv.bin";
+};
+
/* Enable CoreSight */
&cti0 { status = "okay"; };
&cti1 { status = "okay"; };
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 5353da521974..1118836c15dd 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1738,7 +1738,7 @@ smd-edge {
label = "pronto";
- wcnss {
+ wcnss_ctrl: wcnss {
compatible = "qcom,wcnss";
qcom,smd-channels = "WCNSS_CTRL";
--
2.29.2
[PATCH 2/5] wcn36xx: Allow firmware name to be overridden by DT
The WLAN NV firmware blob differs between platforms, and possibly
devices, so add support in the wcn36xx driver for reading the path of
this file from DT in order to allow these files to live in a generic
file system (or linux-firmware).
For some reason the parent (wcnss_ctrl) also needs to upload this blob,
so rather than specifying the same information in both nodes wcn36xx
reads the string from the parent's of_node.
Signed-off-by: Bjorn Andersson
---
This patch can be applied independently of the others, but relates to the
acceptance of the addition to the DT binding (in patch 1/5). So my suggestion
is that this one goes through the ath tree and the others through the Qualcomm
SoC tree.
drivers/net/wireless/ath/wcn36xx/main.c| 7 +++
drivers/net/wireless/ath/wcn36xx/smd.c | 4 ++--
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index afb4877eaad8..87b5c0ff16c0 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1407,6 +1407,13 @@ static int wcn36xx_probe(struct platform_device *pdev)
goto out_wq;
}
+ wcn->nv_file = WLAN_NV_FILE;
+ ret = of_property_read_string(wcn->dev->parent->of_node,
"firmware-name", &wcn->nv_file);
+ if (ret < 0 && ret != -EINVAL) {
+ wcn36xx_err("failed to read \"firmware-name\" property\n");
+ goto out_wq;
+ }
+
wcn->smd_channel = qcom_wcnss_open_channel(wcnss, "WLAN_CTRL",
wcn36xx_smd_rsp_process, hw);
if (IS_ERR(wcn->smd_channel)) {
wcn36xx_err("failed to open WLAN_CTRL channel\n");
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index d0c3a1557e8d..7b928f988068 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -514,10 +514,10 @@ int wcn36xx_smd_load_nv(struct wcn36xx *wcn)
u16 fm_offset = 0;
if (!wcn->nv) {
- ret = request_firmware(&wcn->nv, WLAN_NV_FILE, wcn->dev);
+ ret = request_firmware(&wcn->nv, wcn->nv_file, wcn->dev);
if (ret) {
wcn36xx_err("Failed to load nv file %s: %d\n",
- WLAN_NV_FILE, ret);
+ wcn->nv_file, ret);
goto out;
}
}
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 71fa9992b118..5977af2116e3 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -185,6 +185,7 @@ struct wcn36xx {
struct device *dev;
struct list_headvif_list;
+ const char *nv_file;
const struct firmware *nv;
u8 fw_revision;
--
2.29.2
[PATCH 1/5] dt-bindings: soc: qcom: wcnss: Add firmware-name property
The WCNSS needs firmware which differs between platforms, and possibly boards. Add a new property "firmware-name" to allow the DT to specify the platform/board specific path to this firmware file. Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt index 042a2e4159bd..1382b64e1381 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt @@ -24,6 +24,13 @@ block and a BT, WiFi and FM radio block, all using SMD as command channels. "qcom,riva", "qcom,pronto" +- firmware-name: + Usage: optional + Value type: + Definition: specifies the relative firmware image path for the WLAN NV + blob. Defaults to "wlan/prima/WCNSS_qcom_wlan_nv.bin" if + not specified. + = SUBNODES The subnodes of the wcnss node are optional and describe the individual blocks in the WCNSS. -- 2.29.2
[PATCH 0/5] qcom: wcnss: Allow overriding firmware form DT
The wireless subsystem found in Qualcomm MSM8974 and MSM8916 among others needs platform-, and perhaps even board-, specific firmware. Add support for providing this in devicetree. Bjorn Andersson (5): dt-bindings: soc: qcom: wcnss: Add firmware-name property wcn36xx: Allow firmware name to be overridden by DT soc: qcom: wcnss_ctrl: Introduce local variable "dev" soc: qcom: wcnss_ctrl: Allow reading firmware-name from DT arm64: dts: qcom: msm8916: Enable modem and WiFi .../devicetree/bindings/soc/qcom/qcom,wcnss.txt | 7 +++ arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12 arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- drivers/net/wireless/ath/wcn36xx/main.c | 7 +++ drivers/net/wireless/ath/wcn36xx/smd.c| 4 ++-- drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 1 + drivers/soc/qcom/wcnss_ctrl.c | 15 ++- 7 files changed, 40 insertions(+), 8 deletions(-) -- 2.29.2
[PATCH] remoteproc: qcom_q6v5_mss: Provide errors for firmware-name parsing
Failing to read the "firmware-name" DT property without informing the
developer is annoying, add some helpful debug prints.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/qcom_q6v5_mss.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 66106ba25ba3..15abfbba78d2 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1661,8 +1661,10 @@ static int q6v5_probe(struct platform_device *pdev)
mba_image = desc->hexagon_mba_image;
ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
0, &mba_image);
- if (ret < 0 && ret != -EINVAL)
+ if (ret < 0 && ret != -EINVAL) {
+ dev_err(&pdev->dev, "unable to read mba firmware-name\n");
return ret;
+ }
rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
mba_image, sizeof(*qproc));
@@ -1680,8 +1682,10 @@ static int q6v5_probe(struct platform_device *pdev)
qproc->hexagon_mdt_image = "modem.mdt";
ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
1, &qproc->hexagon_mdt_image);
- if (ret < 0 && ret != -EINVAL)
+ if (ret < 0 && ret != -EINVAL) {
+ dev_err(&pdev->dev, "unable to read mpss firmware-name\n");
goto free_rproc;
+ }
platform_set_drvdata(pdev, qproc);
--
2.29.2
[PATCH v2] remoteproc: qcom: wcnss: Allow specifying firmware-name
Introduce a firmware-name property, in order to be able to support
device/platform specific firmware for the wireless connectivity
subsystem; in line with other Qualcomm remoteproc drivers.
Acked-by: Mathieu Poirier
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Rebased patch
- Added default filename to the definition
.../devicetree/bindings/remoteproc/qcom,wcnss-pil.txt | 6 ++
drivers/remoteproc/qcom_wcnss.c | 8 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
index da09c0d79ac0..a83080b8905c 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
@@ -34,6 +34,12 @@ on the Qualcomm WCNSS core.
Definition: should be "wdog", "fatal", optionally followed by "ready",
"handover", "stop-ack"
+- firmware-name:
+ Usage: optional
+ Value type:
+ Definition: must list the relative firmware image path for the
+ WCNSS core. Defaults to "wcnss.mdt".
+
- vddmx-supply: (deprecated for qcom,pronto-v1/2-pil)
- vddcx-supply: (deprecated for qcom,pronto-v1/2-pil)
- vddpx-supply:
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 2a6a23cb14ca..e8007cc01bfa 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -530,6 +530,7 @@ static int wcnss_alloc_memory_region(struct qcom_wcnss
*wcnss)
static int wcnss_probe(struct platform_device *pdev)
{
+ const char *fw_name = WCNSS_FIRMWARE_NAME;
const struct wcnss_data *data;
struct qcom_wcnss *wcnss;
struct resource *res;
@@ -547,8 +548,13 @@ static int wcnss_probe(struct platform_device *pdev)
return -ENXIO;
}
+ ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
+ &fw_name);
+ if (ret < 0 && ret != -EINVAL)
+ return ret;
+
rproc = rproc_alloc(&pdev->dev, pdev->name, &wcnss_ops,
- WCNSS_FIRMWARE_NAME, sizeof(*wcnss));
+ fw_name, sizeof(*wcnss));
if (!rproc) {
dev_err(&pdev->dev, "unable to allocate remoteproc\n");
return -ENOMEM;
--
2.29.2
[PATCH] remoteproc: qcom: wcnss: Fix race with iris probe
The remoteproc driver is split between the responsibilities of getting
the SoC-internal ARM core up and running and the external RF (aka
"Iris") part configured.
In order to satisfy the regulator framework's need of a struct device *
to look up supplies this was implemented as two different drivers, using
of_platform_populate() in the remoteproc part to probe the iris part.
Unfortunately it's possible that the iris part probe defers on yet not
available regulators and an attempt to start the remoteproc will have to
be rejected, until this has been resolved. But there's no useful
mechanism of knowing when this would be.
Instead replace the of_platform_populate() and the iris probe with a
function that rolls its own struct device, with the relevant of_node
associated that is enough to acquire regulators and clocks specified in
the DT node and that may propagate the EPROBE_DEFER back to the wcnss
device's probe.
Reported-by: Anibal Limon
Reported-by: Loic Poulain
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/qcom_wcnss.c | 52
drivers/remoteproc/qcom_wcnss.h | 4 +-
drivers/remoteproc/qcom_wcnss_iris.c | 120 +--
3 files changed, 91 insertions(+), 85 deletions(-)
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index e8007cc01bfa..2f482ab6aade 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -142,18 +142,6 @@ static const struct wcnss_data pronto_v2_data = {
.num_vregs = 1,
};
-void qcom_wcnss_assign_iris(struct qcom_wcnss *wcnss,
- struct qcom_iris *iris,
- bool use_48mhz_xo)
-{
- mutex_lock(&wcnss->iris_lock);
-
- wcnss->iris = iris;
- wcnss->use_48mhz_xo = use_48mhz_xo;
-
- mutex_unlock(&wcnss->iris_lock);
-}
-
static int wcnss_load(struct rproc *rproc, const struct firmware *fw)
{
struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
@@ -639,12 +627,20 @@ static int wcnss_probe(struct platform_device *pdev)
goto detach_pds;
}
+ wcnss->iris = qcom_iris_probe(&pdev->dev, &wcnss->use_48mhz_xo);
+ if (IS_ERR(wcnss->iris)) {
+ ret = PTR_ERR(wcnss->iris);
+ goto detach_pds;
+ }
+
ret = rproc_add(rproc);
if (ret)
- goto detach_pds;
+ goto remove_iris;
- return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+ return 0;
+remove_iris:
+ qcom_iris_remove(wcnss->iris);
detach_pds:
wcnss_release_pds(wcnss);
free_rproc:
@@ -657,9 +653,10 @@ static int wcnss_remove(struct platform_device *pdev)
{
struct qcom_wcnss *wcnss = platform_get_drvdata(pdev);
- of_platform_depopulate(&pdev->dev);
+ qcom_iris_remove(wcnss->iris);
- qcom_smem_state_put(wcnss->state);
+ if (wcnss->state)
+ qcom_smem_state_put(wcnss->state);
rproc_del(wcnss->rproc);
qcom_remove_sysmon_subdev(wcnss->sysmon);
@@ -687,28 +684,7 @@ static struct platform_driver wcnss_driver = {
},
};
-static int __init wcnss_init(void)
-{
- int ret;
-
- ret = platform_driver_register(&wcnss_driver);
- if (ret)
- return ret;
-
- ret = platform_driver_register(&qcom_iris_driver);
- if (ret)
- platform_driver_unregister(&wcnss_driver);
-
- return ret;
-}
-module_init(wcnss_init);
-
-static void __exit wcnss_exit(void)
-{
- platform_driver_unregister(&qcom_iris_driver);
- platform_driver_unregister(&wcnss_driver);
-}
-module_exit(wcnss_exit);
+module_platform_driver(wcnss_driver);
MODULE_DESCRIPTION("Qualcomm Peripheral Image Loader for Wireless Subsystem");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/remoteproc/qcom_wcnss.h b/drivers/remoteproc/qcom_wcnss.h
index 62c8682d0a92..6d01ee6afa7f 100644
--- a/drivers/remoteproc/qcom_wcnss.h
+++ b/drivers/remoteproc/qcom_wcnss.h
@@ -17,9 +17,9 @@ struct wcnss_vreg_info {
bool super_turbo;
};
+struct qcom_iris *qcom_iris_probe(struct device *parent, bool *use_48mhz_xo);
+void qcom_iris_remove(struct qcom_iris *iris);
int qcom_iris_enable(struct qcom_iris *iris);
void qcom_iris_disable(struct qcom_iris *iris);
-void qcom_wcnss_assign_iris(struct qcom_wcnss *wcnss, struct qcom_iris *iris,
bool use_48mhz_xo);
-
#endif
diff --git a/drivers/remoteproc/qcom_wcnss_iris.c
b/drivers/remoteproc/qcom_wcnss_iris.c
index 169acd305ae3..09720c85 100644
--- a/drivers/remoteproc/qcom_wcnss_iris.c
+++ b/drivers/remoteproc/qcom_wcnss_iris.c
@@ -17,7 +17,7 @@
#include "qcom_wcnss.h"
struct qcom_iris {
- struct device *dev;
+ struct device dev;
struct clk *xo_clk;
@@ -75,7 +75,7 @@ in
Re: [PATCH 0/6] rpmsg: enable the use of the rpmsg_char device for the Virtio backend
On Thu 11 Mar 08:04 CST 2021, Arnaud Pouliquen wrote: > This series is the first step in the division of the series: > "Introduce a generic IOCTL interface for RPMsg channels management"[1] > > The main goal here is to enable the RPMsg char interface for > the virtio RPMsg backend. > > In addition some patches have been includes in order to document the > interface and rename the rpmsg_char_init function. > > It also includes Mathieu Poirier's comments made on [1] > > Patchsets that should be the next steps: > - Extract the control part of the char dev and create the rpmsg_ctrl.c >file > - Introduce the RPMSG_CREATE_DEV_IOCTL IOCTL to instantiate RPMsg devices > > > [1]: https://patchwork.kernel.org/project/linux-remoteproc/list/?series=435523 > Reviewed-by: Bjorn Andersson Regards, Bjorn > Arnaud Pouliquen (6): > rpmsg: char: Rename rpmsg_char_init to rpmsg_chrdev_init > rpmsg: Move RPMSG_ADDR_ANY in user API > rpmsg: Add short description of the IOCTL defined in UAPI. > rpmsg: char: Use rpmsg_sendto to specify the message destination > address > rpmsg: virtio: Register the rpmsg_char device > rpmsg: char: Return an error if device already open > > drivers/rpmsg/qcom_glink_native.c | 16 > drivers/rpmsg/qcom_smd.c | 16 > drivers/rpmsg/rpmsg_char.c| 11 -- > drivers/rpmsg/virtio_rpmsg_bus.c | 62 --- > include/linux/rpmsg.h | 3 +- > include/uapi/linux/rpmsg.h| 13 ++- > 6 files changed, 108 insertions(+), 13 deletions(-) > > -- > 2.17.1 >
Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote:
> Hi Bjorn,
>
> On 2021-02-27 00:44, Bjorn Andersson wrote:
> > On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote:
> >
> >
> > The current logic picks one of:
> > 1) is the compatible mentioned in qcom_smmu_impl_of_match[]
> > 2) is the compatible an adreno
> > 3) no quirks needed
> >
> > The change flips the order of these, so the only way I can see this
> > change affecting things is if we expected a match on #2, but we got one
> > on #1.
> >
> > Which implies that the instance that we want to act according to the
> > adreno impl was listed in qcom_smmu_impl_of_match[] - which either is
> > wrong, or there's a single instance that needs both behaviors.
> >
> > (And I believe Jordan's answer confirms the latter - there's a single
> > SMMU instance that needs all them quirks at once)
> >
>
> Let me go through the problem statement in case my commit message wasn't
> clear. There are two SMMUs (APSS and GPU) on SC7280 and both are SMMU500
> (ARM SMMU IP).
>
> APSS SMMU compatible - ("qcom,sc7280-smmu-500", "arm,mmu-500")
> GPU SMMU compatible - ("qcom,sc7280-smmu-500", "qcom,adreno-smmu",
> "arm,mmu-500")
>
> Now if we take SC7180 as an example, GPU SMMU was QSMMU(QCOM SMMU IP)
> and APSS SMMU was SMMU500(ARM SMMU IP).
>
> APSS SMMU compatible - ("qcom,sc7180-smmu-500", "arm,mmu-500")
> GPU SMMU compatible - ("qcom,sc7180-smmu-v2", "qcom,adreno-smmu",
> "qcom,smmu-v2")
>
> Current code sequence without this patch,
>
> if (of_match_node(qcom_smmu_impl_of_match, np))
> return qcom_smmu_create(smmu, &qcom_smmu_impl);
>
> if (of_device_is_compatible(np, "qcom,adreno-smmu"))
> return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
>
> Now if we look at the compatible for SC7180, there is no problem because
> the APSS SMMU will match the one in qcom_smmu_impl_of_match[] and GPU SMMU
> will match "qcom,adreno-smmu" because the compatible strings are different.
> But for SC7280, both the APSS SMMU and GPU SMMU
> compatible("qcom,sc7280-smmu-500")
> are same. So GPU SMMU will match with the one in qcom_smmu_impl_of_match[]
> i.e.., "qcom,sc7280-smmu-500" which functionally doesn't cause any problem
> but we will miss settings for split pagetables which are part of GPU SMMU
> specific implementation.
>
> We can avoid this with yet another new compatible for GPU SMMU something like
> "qcom,sc7280-adreno-smmu-500" but since we can handle this easily in the
> driver and since the IPs are same, meaning if there was a hardware quirk
> required, then we would need to apply to both of them and would this
> additional
> compatible be of any help?
>
No, I think you're doing the right thing of having them both. I just
didn't remember us doing that.
> Coming to the part of quirks now, you are right saying both SMMUs will need
> to have the same quirks in SC7280 and similar others where both are based on
> same IPs but those should probably be *hardware quirks* and if they are
> software based like the S2CR quirk depending on the firmware, then it might
> not be applicable to both. In case if it is applicable, then as Jordan
> mentioned,
> we can add the same quirks in GPU SMMU implementation.
>
I do suspect that at some point (probably sooner than later) we'd have
to support both inheriting of stream from the bootloader and the Adreno
"quirks" in the same instance.
But for now this is okay to me.
Regards,
Bjorn
Re: [PATCH] arm64: dts: sc7280: Add qspi, qupv3_0 and qupv3_1 nodes
On Thu 11 Mar 15:54 CST 2021, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 10, 2021 at 7:41 PM Roja Rani Yarubandi
> wrote:
> >
> > +&qspi_cs0 {
> > + pinconf {
> > + pins = "gpio15";
> > + bias-disable;
> > + };
>
> The "pinconf" / "pinmux" subnode shouldn't be used for new SoCs. See:
>
> http://lore.kernel.org/r/CAD=FV=UY_AFRrAY0tef5jP698LEng6oN652LcX3B4nG=awh...@mail.gmail.com
>
> ...same feedback for this whole patch.
>
> > + qup_spi0_default: qup-spi0-default {
> > + pinmux {
> > + pins = "gpio0", "gpio1",
> > + "gpio2", "gpio3";
> > + function = "qup00";
> > + };
> > + };
>
> Please split these SPI nodes as per the thread above, like:
>
> tlmm: pinctrl@... {
> qup_spi0_data_clk: qup-spi0-data-clk {
> pins = "gpio0", "gpio1", "gpio2";
> function = "qup0";
> };
>
> qup_spi0_cs: qup-spi0-cs {
> pins = "gpio3";
> function = "qup0";
> };
>
> qup_spi0_cs_gpio: qup-spi0-cs-gpio {
> pins = "gpio3";
> function = "gpio";
> };
> };
>
>
> > + qup_uart0_default: qup-uart0-default {
> > + pinmux {
> > + pins = "gpio0", "gpio1",
> > + "gpio2", "gpio3";
> > + function = "qup00";
> > + };
> > + };
>
> I suspect things would actually be cleaner if we broke the uart lines
> up since the boards tend to have to adjust pulls differently for each
> line. With the new "no pinconf / pinmux" world it's pretty clean. It's
> obviously up to Bjorn, but if it were me I'd request this in the SoC
> file:
>
I'd like that.
> qup_uart0_cts: qup-uart0-cts {
> pins = "...";
> function = "qup00";
> };
>
> qup_uart0_rts: qup-uart0-rts {
> pins = "...";
> function = "qup00";
> };
>
> qup_uart0_rx: qup-uart0-rx {
> pins = "...";
> function = "qup00";
> };
>
> qup_uart0_tx: qup-uart0-tx {
> pins = "...";
> function = "qup00";
> };
>
> ...and now when the board file wants to adjust the pulls they can just
> reference each one:
>
> /*
> * Comments about why the UART0 pulls make sense.
> * Blah blah blah.
> */
>
> &qup_uart0_cts {
> bias-pull-down;
> };
>
> &qup_uart0_rts {
> drive-strength = <2>;
> bias-disable;
> };
>
> &qup_uart0_rx {
> bias-pull-up;
> };
>
> &qup_uart0_tx {
> drive-strength = <2>;
> bias-disable;
> };
>
>
> > + qspi: spi@88dc000 {
>
> I believe the qspi node is sorted incorrectly. When I apply this to
> the top of the Qualcomm tree it shows up after the "apps_smmu:
> iommu@1500" node. However:
>
> 0x088dc000 < 0x1500
>
> ...which means it should be _before_.
>
> -Doug
Re: [PATCH 0/9] qcom/sc7280: Enable various hardware blocks on SC7280 SoC
On Thu 25 Feb 03:30 CST 2021, Sai Prakash Ranjan wrote: > This series enables various hardware blocks such as LLCC, IPCC, AOSS QMP > and Coresight on SC7280 SoC. > > This series is dependent on the base support added for SC7280 in [1]. > I've picked some of these patches... It would be helpful if you split series like this based on how they will be picked up my various maintainers. E.g. I think it's quite likely Jassi won't find and pick up the mailbox binding patch. PS. I sent a patch to Jassi adding the mailbox binding directory to MAINTAINERS. Regards, Bjorn > [1] https://lore.kernel.org/patchwork/cover/1379842/ > > Sai Prakash Ranjan (9): > dt-bindings: arm: msm: Add LLCC for SC7280 > soc: qcom: llcc: Add configuration data for SC7280 > arm64: dts: qcom: sc7280: Add device tree node for LLCC > dt-bindings: mailbox: qcom-ipcc: Add compatible for SC7280 > arm64: dts: qcom: sc7280: Add IPCC for SC7280 SoC > dt-bindings: soc: qcom: aoss: Add SC7280 compatible > soc: qcom: aoss: Add AOSS QMP support for SC7280 > arm64: dts: qcom: sc7280: Add AOSS QMP node > arm64: dts: qcom: sc7280: Add Coresight support > > .../bindings/arm/msm/qcom,llcc.yaml | 1 + > .../bindings/mailbox/qcom-ipcc.yaml | 1 + > .../bindings/soc/qcom/qcom,aoss-qmp.txt | 1 + > arch/arm64/boot/dts/qcom/sc7280.dtsi | 520 ++ > drivers/soc/qcom/llcc-qcom.c | 19 + > drivers/soc/qcom/qcom_aoss.c | 1 + > 6 files changed, 543 insertions(+) > > > base-commit: d79b47c59576a51d8e288a6b98b75ccf4afb8acd > prerequisite-patch-id: d8babdd3c8a9923360af342f3d8d9876820272e5 > prerequisite-patch-id: 5757e07e4336d773d402769d09106924962ce31b > prerequisite-patch-id: 9b21eb51aa86619f5695a511c65c9236e3bc0f2b > prerequisite-patch-id: 2f834cc892f7f9109cbf32a87d504ba27b64a5df > prerequisite-patch-id: 14b1185357703d750c3411a16e97675489ca7dde > prerequisite-patch-id: 55c143f21b646c18da921a62bbd2801a5df38c8f > prerequisite-patch-id: 66f4c58aff2f1a7283b0103590ff82384907bae3 > prerequisite-patch-id: 75e73e6b13ab91ed5e3a96b59957aa5e867d65ea > prerequisite-patch-id: eb46845b4f9eb3706a26911042c2865a58577198 > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
[PATCH] MAINTAINERS: Add DT bindings directory to mailbox
DT bindings related to mailbox drivers are typically picked by the mailbox maintainer, so add the binding folder to the maintainers entry to make sure get_maintainer finds it. Signed-off-by: Bjorn Andersson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9095d182deaf..670f1461b65c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10608,6 +10608,7 @@ S: Maintained F: drivers/mailbox/ F: include/linux/mailbox_client.h F: include/linux/mailbox_controller.h +F: Documentation/devicetree/bindings/mailbox/ MAILBOX ARM MHUv2 M: Viresh Kumar -- 2.29.2
Re: [PATCH V13 00/10] remoteproc: imx_rproc: support iMX8MQ/M
On Thu 11 Mar 11:38 CST 2021, Mathieu Poirier wrote: > On Thu, Mar 11, 2021 at 01:26:25AM +, Peng Fan (OSS) wrote: > > Mathieu, > > > > > Subject: Re: [PATCH V13 00/10] remoteproc: imx_rproc: support iMX8MQ/M > > > > > > On Sat, Mar 06, 2021 at 07:24:15PM +0800, peng@oss.nxp.com wrote: > > > > From: Peng Fan > > > > > > > > V13: > > > > Add R-b tag from Rob for patch 1. > > > > Drop the reserved memory node from patch 2 per Rob's comment. > > > > Mathieu, Bjorn > > > > Only patch 2 not have R-b/A-b tag, but since Rob's only has a minor > > > comment, and > > > > addressed in this version, is it ok for you take into remoteproc next > > > branch? > > > > Thanks. > > > > > > As much as I want to, there is no way to move forward without an > > > acknowledgement from Rob. > > > > Rob has gave his R-b tag for patch 2/13, please help pick up this patchset. > > I really wanna this feature in which has been for a long time. Then > > I will move on to add new stuff. > > > > This set looks good to me - Bjorn will likely pick it up shortly. > Certainly, I'm just waiting for tuxbuild to get back with some build results before I'm pushing the new branch(es). Regards, Bjorn > > Thanks, > > Peng. > > > > > > > > > > > > > > > V12: > > > > Add maxItems to avoid dt_bindings_check fail Rebased on top of > > > > linux-next > > > > > > > > V11: > > > > Per Rob's comments, fix memory-region in patch 1/10 Rebased on top > > > > of Linux-next > > > > > > > > V10: > > > > Per Rob's comments, fix patch 1/10 > > > > > > > > V9: > > > > Per Mathieu's comments, > > > >update the tile of yaml in patch 2/10 > > > >update the Kconfig and MODULE_DESCRIPTION, I merge this change in > > > patch 8/10, > > > >since this is a minor change, I still keep Mathieu's R-b tag. If any > > > objection, I could remove. > > > >Add R-b tag in Patch 10/10 > > > > > > > > Rob, please help review patch 1/10 and 2/10 > > > > > > > > V8: > > > > Address sparse warning in patch 4/10 reported by kernel test robot > > > > > > > > V7: > > > > Add R-b tag from Mathieu > > > > vdevbuffer->vdev0buffer in patch 1/10, 7/10 correct err msg and > > > > shutdown seq per Mathieu's comments in patch 10/10 Hope this version > > > > is ok to be merged. > > > > > > > > V6: > > > > Add R-b tag from Mathieu > > > > Convert imx-rproc.txt to yaml and add dt-bindings support for > > > > i.MX8MQ/M, patch 1/10 2/10 No other changes. > > > > > > > > V5: > > > > Apply on Linux next > > > > Add V5 subject prefix > > > > Add R-b tag from Bjorn for 1/8, 2/8, 3/8 > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > > > > > hwork.kernel.org%2Fproject%2Flinux-remoteproc%2Fcover%2F20201229033 > > > 019 > > > > .25899-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n > > > xp.com%7 > > > > > > > C18c2709725e14cbab54408d8e24c6492%7C686ea1d3bc2b4c6fa92cd99c5c3 > > > 01635%7 > > > > > > > C0%7C0%7C637508165016988280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > > MC4wLjAwMD > > > > > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata > > > =bwlT > > > > uTk6iRuZke6SMhuyB2gxniStfxnX%2BKlVgm7MZuk%3D&reserved=0 > > > > > > > > V4: > > > > According to Bjorn's comments, add is_iomem for da to va usage 1/8, > > > > 2/8 is new patch 3/8, follow Bjorn's comments to correct/update the > > > > err msg. > > > > 6/8, new patch > > > > 8/8, use dev_err_probe to simplify code, use queue_work instead > > > > schedule_delayed_work > > > > > > > > V3: > > > > Since I was quite busy in the past days, V3 is late Rebased on > > > > Linux-next Add R-b tags > > > > 1/7: Add R-b tag of Mathieu, add comments > > > > 4/7: Typo fix > > > > 5/7: Add R-b tag of Mathieu, drop index Per Mathieu's comments > > > > 6/7: Add R-b tag of Mathieu > > > > 7/7: Add comment for vqid << 16, drop unneeded timeout settings of > > > mailbox > > > > Use queue_work instead of schedule_delayed_work > > > > free mbox channels when remove > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml > > > > .org%2Flkml%2F2020%2F12%2F4%2F82&data=04%7C01%7Cpeng.fan > > > %40nxp.com > > > > %7C18c2709725e14cbab54408d8e24c6492%7C686ea1d3bc2b4c6fa92cd9 > > > 9c5c301635 > > > > %7C0%7C0%7C637508165016988280%7CUnknown%7CTWFpbGZsb3d8eyJ > > > WIjoiMC4wLjAw > > > > > > > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sd > > > ata=xQ > > > > > > > ReFFdUT2ZLhWyT2Vt2v0frG0xKq2psP1ExnLx%2BLXw%3D&reserved=0 > > > > > > > > V2: > > > > Rebased on linux-next > > > > Dropped early boot feature to make patchset simple. > > > > Drop rsc-da > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > > > > > hwork.kernel.org%2Fproject%2Flinux-remoteproc%2Fcover%2F20200927064 > > > 131 > > > > .24101-1-peng.fan%40nxp.com%2F&data=04%7C01%7Cpeng.fan%40n > > > xp.com%7 > > > > > > > C18c2709725e14cbab54408d8e24c6492%7C686ea1d3bc2b4c6fa92cd99c5c3 > > > 01635%
