mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Luca Weiss <luca@z3ntu.xyz>,
	~postmarketos/upstreaming@lists.sr.ht,
	phone-devel@vger.kernel.org, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Brian Masney <masneyb@onstation.org>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] soc: qcom: ocmem: Add OCMEM hardware version print
Date: Mon, 29 May 2023 11:30:38 +0200	[thread overview]
Message-ID: <dc9442f4-d1c5-37f1-a8be-d19162cd0dbe@linaro.org> (raw)
In-Reply-To: <2680722.mvXUDI8C0e@z3ntu.xyz>



On 29.05.2023 10:38, Luca Weiss wrote:
> On Freitag, 26. Mai 2023 21:39:44 CEST Konrad Dybcio wrote:
>> On 23.05.2023 22:32, Luca Weiss wrote:
>>> It might be useful to know what hardware version of the OCMEM block the
>>> SoC contains. Add a debug print for that.
>>>
>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>> ---
>>> This patch is depends on [0] but could also be applied in the other
>>> order, if conflicts are resolved.
>>>
>>> [0]
>>> https://lore.kernel.org/linux-arm-msm/20230506-msm8226-ocmem-v1-1-3e24e27
>>> 24f01@z3ntu.xyz/ ---
>>> Changes in v2:
>>> - Use FIELD_GET macros for getting correct bits from register (take
>>>
>>>   wording from mdp5: major, minor, step which hopefully is sort of
>>>   accurate)
>>
>> Qualcomm uses that (or that-ish) nomenclature for many hw blocks, so
>> it's likely spot on.
>>
>>> - Link to v1:
>>> https://lore.kernel.org/r/20230509-ocmem-hwver-v1-1-b83ece3f2168@z3ntu.xy
>>> z ---
>>>
>>>  drivers/soc/qcom/ocmem.c | 9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
>>> index c3e78411c637..9f7c3348cbb9 100644
>>> --- a/drivers/soc/qcom/ocmem.c
>>> +++ b/drivers/soc/qcom/ocmem.c
>>> @@ -76,6 +76,10 @@ struct ocmem {
>>>
>>>  #define OCMEM_REG_GFX_MPU_START			0x00001004
>>>  #define OCMEM_REG_GFX_MPU_END			0x00001008
>>>
>>> +#define OCMEM_HW_VERSION_MAJOR(val)		FIELD_GET(GENMASK(31, 28), val)
>>> +#define OCMEM_HW_VERSION_MINOR(val)		FIELD_GET(GENMASK(27, 16), val)
>>> +#define OCMEM_HW_VERSION_STEP(val)		FIELD_GET(GENMASK(15, 0), val)
>>> +
>>>
>>>  #define OCMEM_HW_PROFILE_NUM_PORTS(val)		FIELD_GET(0x0000000f, (val))
>>>  #define OCMEM_HW_PROFILE_NUM_MACROS(val)	FIELD_GET(0x00003f00, (val))
>>>
>>> @@ -355,6 +359,11 @@ static int ocmem_dev_probe(struct platform_device
>>> *pdev)> 
>>>  		}
>>>  	
>>>  	}
>>>
>>> +	reg = ocmem_read(ocmem, OCMEM_REG_HW_VERSION);
>>> +	dev_dbg(dev, "OCMEM hardware version: %ld.%ld.%ld\n",
>>
>> reg is an unsigned long (u32), this should probably be %u
> 
> I can make it %lu, just %u gives me this warning
Right, grumpy compilers care about types that have been meaningless for
longer than I've been alive.. 

Konrad
> 
> drivers/soc/qcom/ocmem.c:363:22: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'long unsigned int' [-Wformat=]
>   363 |         dev_dbg(dev, "OCMEM hardware version: %u.%u.%u\n",
>       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> Will send a v3 with that.
> 
>>
>>> +		OCMEM_HW_VERSION_MAJOR(reg), OCMEM_HW_VERSION_MINOR(reg),
>>> +		OCMEM_HW_VERSION_STEP(reg));
>>
>> Nit: one per line would make this the tiniest bit easier to read
> 
> ack
> 
> Regards
> Luca
> 
>>
>> Konrad
>>
>>> +
>>>
>>>  	reg = ocmem_read(ocmem, OCMEM_REG_HW_PROFILE);
>>>  	ocmem->num_ports = OCMEM_HW_PROFILE_NUM_PORTS(reg);
>>>  	ocmem->num_macros = OCMEM_HW_PROFILE_NUM_MACROS(reg);
>>>
>>> ---
>>> base-commit: 8705151771af822ac794b44504cd72eebc423499
>>> change-id: 20230509-ocmem-hwver-99bcb33b028b
>>>
>>> Best regards,
> 
> 
> 
> 

      reply	other threads:[~2023-05-29  9:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 20:32 Luca Weiss
2023-05-26 19:39 ` Konrad Dybcio
2023-05-29  8:38   ` Luca Weiss
2023-05-29  9:30     ` Konrad Dybcio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc9442f4-d1c5-37f1-a8be-d19162cd0dbe@linaro.org \
    --to=konrad.dybcio@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca@z3ntu.xyz \
    --cc=masneyb@onstation.org \
    --cc=phone-devel@vger.kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®