From: Sudeep Holla <sudeep.holla@arm.com>
To: "lihuisong (C)" <lihuisong@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Bjorn Andersson <andersson@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Sudeep Holla <sudeep.holla@arm.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Shawn Guo <shawnguo@kernel.org>,
linux-kernel@vger.kernel.org, soc@kernel.org,
wanghuiqiang@huawei.com, tanxiaofei@huawei.com,
liuyonglong@huawei.com, huangdaode@huawei.com,
linux-acpi@vger.kernel.org, Len Brown <lenb@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Subject: Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC
Date: Tue, 16 May 2023 13:29:31 +0100 [thread overview]
Message-ID: <20230516122931.il4ai7fyxdo5gsff@bogus> (raw)
In-Reply-To: <aa5b1919-74c6-1f97-78af-ab5f0904c3ce@huawei.com>
On Tue, May 16, 2023 at 03:35:54PM +0800, lihuisong (C) wrote:
>
> 在 2023/5/15 21:08, Sudeep Holla 写道:
> > On Thu, May 04, 2023 at 09:16:16PM +0800, lihuisong (C) wrote:
> > > I'm tring to use CRS with GAS to report PCC channel ID and get other
> > > informations driver need by address.
> > OK you had pcc-chan-id pcc-type and device-flags in the DSD style bindings
> > to begin with. I haven't understood device-flags here so can't comment on
> > that.
>
> We want to use the 'device-flags' to report some information by bit.
Please give more details, until then NACK for the idea.
> Currently, this driver requests PCC channel and use type2 to communicate
> with firmware.
OKAY...
> But, if some platform support type3 and PCC Operation Region, driver can
> choice this method to communicate with firmware.
> So firmware and driver have to use this flag to make compatibility.
>
I would rather add such things to the spec if it is any sort of limitation
with the current specification.
> >
> > > I found a way to obtain the generic register information according to
> > > "Referencing the PCC address space" in ACPI spec.
> > > And driver also get the PCC generic register information successfully.
> > >
> > Can you elaborate ? I assume by that you must be able to get pcc-chan-id
>
> Yes,driver can get pcc-chan-id by below register.
>
> Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
>
Good to know.
> > right ? You must not need pcc-type as the pcc mailbox driver must handle
> > the type for you. If not, we may need to fix or add any missing support.
> Yes, PCC driver doesn't support it currently. And aother patch [1] we've
> been talking about does it.
> If it is applied to kernel, we can drop this pcc-type here.
>
> [1] https://patchwork.kernel.org/project/linux-acpi/patch/20230423110335.2679-2-lihuisong@huawei.com/
OK then we are good, no need for pcc-type then ?
> >
> > > But I don't know how to set and use the address in PCC register.
> > It must be same as what you would have specified in you new bindings
> > under "pcc-chan-id". I am confused as you say you were able to get the
> > PCC generic register information successfully but you still claim you
> > don't know how to set or use the address.
> My confusion about this address is mentioned below.
OK
> > > Where should this address come from?
> > > It seems that ACPI spec is not very detailed about this.
> > > Do you have any suggestions?
> > >
> > I am afraid, I don't have any as I am failing to understand the exact issue
> > you are facing.
> >
> > Let me try to ask the question explicity here:
> >
> > If you are just referring to just the <RegisterAddress,> in
> >
> > Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
> Yeah, this is what I'm using.
> >
> > then,
> >
> > RegisterAddress is usually the offset in the comms address associated with
> Communication subspace in share memory of PCC subspace?
> > the PCC subspace ID specified in AccessSize. Yes the use of AccessSize for
> > the PCC subspace ID is bit confusing though.
> >
> > You can either list all the registers with _CRS individually or the driver
> List all the registers as following way?
> Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> {
> QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
> NonCacheable, ReadWrite,
> 0x0000000000000000, // Granularity
> 0x0000000098190000, // Range Minimum
> 0x000000009819FFFF, // Range Maximum
> 0x0000000000000000, // Translation Offset
> 0x0000000000010000, // Length
> ,, , AddressRangeMemory, TypeStatic)
> })
Not sure if you can use QWordMemory here TBH.
> > can just use the PCC subspace ID in AccessSize and keep RegisterAddress = 0
> > but access individual offset based on its own knowledge. I haven't seen the
> Following words come from ACPI spec.
> -->
> As an example, the following resource template refers to the feld occupying
> bits 8 through 15 at address 0x30 in PCC
> subspace 9:
> ResourceTemplate()
> {
> Register (
> PCC, //AddressSpaceKeyword
> 8, //RegisterBitWidth
> 8, //RegisterBitOffset
> \x06pcc 0x30, //RegisterAddress
> 9 //AccessSize (subspace ID)
> )
> }
>
> If the width of the address is 32bit, set RegisterAddress to 0,
> RegisterBitOffset to 0 and set RegisterBitWidth to 64 here.
> Driver can access to the ((void __iomem *)pcc_comm_addr + 0x8 + 0) and
> ((void __iomem *)pcc_comm_addr + 0x8 + 4) address,right?
> (This virtual address = pcc mapped address + header size + offset within PCC
> subspace.)
Yes that's my understanding. I remember seeing the driver is just fetching
pcc-chan-id using DSD style key-value pair, which means you don't need
any other info other than the PCC subspace/channel ID, just have address
as 0.
Also I see the driver uses type for just rejecting the type 3 PCCT. The
question is will the driver probe and run on a platform with type 3 PCCT ?
If so what is the problem running on such a platform. I see it is useless
check in the driver and can be dropped. Also the comment above enum
HCCS_DEV_FLAGS_INTR_B is confusing and so is the way flags is used.
> > full driver yet but I assuming that's how you would have used if you went with
> > your DSD pcc-chan-id proposal.
> >
> > > On the other hand, we think that System Memory space + method can also
> > > achieve above goal. What do you think of that?
> > Again I don't understand what you mean by that.
> Sorry, here is what I want to say.
> -->
> OperationRegion (CCS0, SystemMemory, 0x00000002081000CC, 0x04)
> Field (CCS0, DWordAcc, NoLock, Preserve)
> {
> HAU1, 32
> }
> OperationRegion (CCS1, SystemMemory, 0x0000000201070410, 0x04)
> Field (CCS1, DWordAcc, NoLock, Preserve)
> {
> HCGE, 32
> }
> Method (_DSM, 2, Serialized) // _DSM: Device-Specific Method
> {
> If ((Arg0 == ToUUID ("b06b81ab-0134-4a45-9b0c-483447b95fa7")))
> {
> If ((Arg1 == One))
> {
> Return (HAU1)
> }
>
> Return (HCGE)
> }
> }
>
> Driver can call _DSM method to get some information, such as pcc_chan_id and
> device_flags.
Big fat NACK for _DSM for the above purpose, please stop abusing _DSM or _DSD
for such information which can be obtained with the existing _CRS.
--
Regards,
Sudeep
next prev parent reply other threads:[~2023-05-16 12:29 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 7:30 [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC Huisong Li
2023-04-24 8:09 ` Arnd Bergmann
2023-04-25 3:04 ` lihuisong (C)
2023-04-25 6:08 ` Arnd Bergmann
2023-04-25 9:42 ` lihuisong (C)
2023-04-25 10:30 ` Sudeep Holla
2023-04-25 13:00 ` lihuisong (C)
2023-04-25 13:19 ` Sudeep Holla
2023-04-26 12:12 ` lihuisong (C)
2023-05-04 13:16 ` lihuisong (C)
2023-05-15 3:37 ` lihuisong (C)
2023-05-15 13:08 ` Sudeep Holla
2023-05-16 7:35 ` lihuisong (C)
2023-05-16 12:29 ` Sudeep Holla [this message]
2023-05-16 14:13 ` lihuisong (C)
2023-05-16 14:35 ` Sudeep Holla
2023-05-17 7:16 ` lihuisong (C)
2023-05-17 9:30 ` Sudeep Holla
2023-05-17 11:35 ` lihuisong (C)
2023-05-17 13:16 ` Sudeep Holla
2023-05-18 8:24 ` lihuisong (C)
2023-05-18 8:38 ` Sudeep Holla
2023-05-18 12:29 ` lihuisong (C)
2023-04-24 8:42 ` Krzysztof Kozlowski
2023-04-25 3:16 ` lihuisong (C)
2023-04-25 11:24 ` Sudeep Holla
2023-05-22 7:22 ` [PATCH v2 0/2] " Huisong Li
2023-05-22 7:22 ` [PATCH v2 1/2] " Huisong Li
2023-05-23 9:39 ` Sudeep Holla
2023-05-23 11:57 ` lihuisong (C)
2023-05-23 13:41 ` Sudeep Holla
2023-05-24 9:36 ` lihuisong (C)
2023-05-25 2:41 ` lihuisong (C)
2023-05-25 7:35 ` Sudeep Holla
2023-05-25 8:12 ` lihuisong (C)
2023-05-30 2:53 ` lihuisong (C)
2023-05-30 8:43 ` Sudeep Holla
2023-05-30 10:57 ` lihuisong (C)
2023-05-22 7:22 ` [PATCH v2 2/2] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-05-30 11:27 ` [PATCH v3 0/2] soc: hisilicon: Support HCCS driver on Kunpeng SoC Huisong Li
2023-05-30 11:27 ` [PATCH v3 1/2] " Huisong Li
2023-05-30 11:27 ` [PATCH v3 2/2] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-06-19 6:32 ` [PATCH v3 0/2] soc: hisilicon: Support HCCS driver on Kunpeng SoC lihuisong (C)
2023-07-14 6:17 ` lihuisong (C)
2023-07-17 12:06 ` Krzysztof Kozlowski
2023-07-18 8:07 ` lihuisong (C)
2023-07-18 10:59 ` Krzysztof Kozlowski
2023-07-18 14:00 ` lihuisong (C)
2023-07-18 11:01 ` Wei Xu
2023-07-20 12:43 ` lihuisong (C)
2023-07-25 7:57 ` [PATCH RESEND " Huisong Li
2023-07-25 7:57 ` [PATCH RESEND v3 1/2] " Huisong Li
2023-07-25 8:55 ` Wei Xu
2023-07-26 9:54 ` lihuisong (C)
2023-07-27 3:51 ` lihuisong (C)
2023-07-25 15:28 ` Randy Dunlap
2023-07-26 9:48 ` lihuisong (C)
2023-07-25 7:57 ` [PATCH RESEND v3 2/2] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-07-25 8:59 ` Wei Xu
2023-07-26 9:56 ` lihuisong (C)
2023-07-28 3:03 ` [PATCH v4 0/2] soc: hisilicon: Support HCCS driver on Kunpeng SoC Huisong Li
2023-07-28 3:03 ` [PATCH v4 1/2] " Huisong Li
2023-07-28 3:03 ` [PATCH v4 2/2] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-07-29 8:26 ` [PATCH v5 0/2] soc: hisilicon: Support HCCS driver on Kunpeng SoC Huisong Li
2023-07-29 8:26 ` [PATCH v5 1/2] " Huisong Li
2023-07-29 22:43 ` Randy Dunlap
2023-08-01 1:30 ` lihuisong (C)
2023-07-29 8:26 ` [PATCH v5 2/2] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-08-01 2:41 ` [PATCH v6 0/2] soc: hisilicon: Support HCCS driver on Kunpeng SoC Huisong Li
2023-08-01 2:41 ` [PATCH v6 1/2] " Huisong Li
2023-08-06 15:09 ` Zenghui Yu
2023-08-07 1:14 ` lihuisong (C)
2023-08-07 1:41 ` lihuisong (C)
2023-08-01 2:41 ` [PATCH v6 2/2] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-08-08 2:36 ` [PATCH v7 0/3] soc: hisilicon: Support HCCS driver on Kunpeng SoC Huisong Li
2023-08-08 2:36 ` [PATCH v7 1/3] " Huisong Li
2023-08-08 2:36 ` [PATCH v7 2/3] soc: hisilicon: add sysfs entry to query information of HCCS Huisong Li
2023-08-08 2:36 ` [PATCH v7 3/3] doc: soc: hisilicon: Add Kunpeng HCCS driver documentation Huisong Li
2023-08-11 9:30 ` [PATCH v7 0/3] soc: hisilicon: Support HCCS driver on Kunpeng SoC Wei Xu
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=20230516122931.il4ai7fyxdo5gsff@bogus \
--to=sudeep.holla@arm.com \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=huangdaode@huawei.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lenb@kernel.org \
--cc=lihuisong@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyonglong@huawei.com \
--cc=matthias.bgg@gmail.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
--cc=soc@kernel.org \
--cc=tanxiaofei@huawei.com \
--cc=wanghuiqiang@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).