Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Arnd Bergmann]

On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:

> diff --git a/drivers/soc/hisilicon/Kconfig 
> b/drivers/soc/hisilicon/Kconfig
> new file mode 100644
> index 000000000000..81768d47f572
> --- /dev/null
> +++ b/drivers/soc/hisilicon/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +menu "Hisilicon SoC drivers"
> +	depends on ARCH_HISI
> +
> +config KUNPENG_HCCS
> +	tristate "HCCS driver on Kunpeng SoC"
> +	depends on ARM64 && ACPI

Is there a compile-time dependency on ARM64? If not, it would
be good to allow compile testing. At the same time, you
can probably tighten this to ARCH_HISI instead of ARM64,
since no other vendors are going to use it:

       depends on ACPI
       depends on (ARM64 && ARCH_HISI) || COMPILE_TEST

> +
> +#include "kunpeng_hccs.h"
> +
> +/* PCC defines */
> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)

Should these perhaps be in include/acpi/pcc.h? The 0x50434300
number is just "PCC\0", so it appears to not be HCCS specific.

> +
> +static int hccs_get_device_property(struct hccs_dev *hdev)
> +{
> +	struct device *dev = hdev->dev;
> +
> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
> +		dev_err(hdev->dev, "no device-flags property.\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
> +		dev_err(hdev->dev, "no pcc-type property.\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
> +		dev_err(hdev->dev, "no pcc-channel property.\n");
> +		return -ENODEV;
> +	}
> +
> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
> +	if (!hccs_dev_property_supported(hdev))
> +		return -EOPNOTSUPP;
> +

Where are the device properties documented? I'm never quite sure how
to handle these for ACPI-only drivers, since we don't normally have the
bindings in Documentation/devicetree/bindings/, but it feels like there
should be some properly reviewed document somewhere else.

Adding ACPI and devicetree maintainers to Cc for clarification. 

> +static int hccs_check_chan_cmd_complete(struct hccs_dev *hdev)
> +{
> +	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
> +	struct acpi_pcct_shared_memory *comm_base = cl_info->pcc_comm_addr;
> +	u16 status;
> +	int ret;
> +
> +	/*
> +	 * Poll PCC status register every 3us(delay_us) for maximum of
> +	 * deadline_us(timeout_us) until PCC command complete bit is set(cond)
> +	 */
> +	ret = readw_relaxed_poll_timeout(&comm_base->status, status,
> +					 status & HCCS_PCC_STATUS_CMD_COMPLETE,
> +					 HCCS_POLL_STATUS_TIME_INTERVAL_US,
> +					 cl_info->deadline_us);

Is it both safe and faster to use a relaxed readw here, compared
to the normal one? If there is any access to shared memory
involved, you need the implied barrier for serialization, and since this
is already a sleeping operation, I would guess that you don't care
about the last nanosecond of latency here.

> +static ssize_t hccs_show(struct kobject *k, struct attribute *attr, 
> char *buf)
> +{
> +	struct kobj_attribute *kobj_attr;
> +
> +	kobj_attr = container_of(attr, struct kobj_attribute, attr);
> +
> +	return kobj_attr->show(k, kobj_attr, buf);
> +}
> +
> +static const struct sysfs_ops hccs_comm_ops = {
> +	.show = hccs_show,
> +};

Every sysfs interface needs to be documented in Documentation/ABI/

> diff --git a/drivers/soc/hisilicon/kunpeng_hccs.h 
> b/drivers/soc/hisilicon/kunpeng_hccs.h
> new file mode 100644
> index 000000000000..ca557ef115ea
> --- /dev/null
> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
> @@ -0,0 +1,204 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright (c) 2023 Hisilicon Limited. */
> +
> +#ifndef __KUNPENG_HCCS_H__
> +#define __KUNPENG_HCCS_H__

Are you planning to add more drivers that share this file? If not,
just fold the contents into the driver itself.

     Arnd

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

Hi Arnd,

Thanks for your review. My reply is as follows.


在 2023/4/24 16:09, Arnd Bergmann 写道:
> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
>
>> diff --git a/drivers/soc/hisilicon/Kconfig
>> b/drivers/soc/hisilicon/Kconfig
>> new file mode 100644
>> index 000000000000..81768d47f572
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/Kconfig
>> @@ -0,0 +1,18 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +menu "Hisilicon SoC drivers"
>> +	depends on ARCH_HISI
>> +
>> +config KUNPENG_HCCS
>> +	tristate "HCCS driver on Kunpeng SoC"
>> +	depends on ARM64 && ACPI
> Is there a compile-time dependency on ARM64? If not, it would
Yes, no compile-time dependency on ARM64.
> be good to allow compile testing. At the same time, you
> can probably tighten this to ARCH_HISI instead of ARM64,
> since no other vendors are going to use it:
>
>         depends on ACPI
>         depends on (ARM64 && ARCH_HISI) || COMPILE_TEST
What do you think of adjusting it as below?
menu "Hisilicon SoC drivers"
     depends on ARCH_HISI || COMPILE_TEST

config KUNPENG_HCCS
     depends on ACPI
     depends on ARM64 || COMPILE_TEST

>
>> +
>> +#include "kunpeng_hccs.h"
>> +
>> +/* PCC defines */
>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
> Should these perhaps be in include/acpi/pcc.h? The 0x50434300
> number is just "PCC\0", so it appears to not be HCCS specific.
This is a PCC signature. As stated in the APCI,
"The signature of a subspace is computed by a bitwiseor of the value 
0x50434300
with the subspace ID. For example, subspace 3 has the signature 0x50434303."

I am not sure if all driver need to use this fixed signature mask.
As far as I know, cppc_acpi.c didn't use this signature and 
xgene-hwmon.c used another mask defined in its driver.
So I place it here.
>
>> +
>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>> +{
>> +	struct device *dev = hdev->dev;
>> +
>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>> +		dev_err(hdev->dev, "no device-flags property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>> +	if (!hccs_dev_property_supported(hdev))
>> +		return -EOPNOTSUPP;
>> +
> Where are the device properties documented? I'm never quite sure how
> to handle these for ACPI-only drivers, since we don't normally have the
> bindings in Documentation/devicetree/bindings/, but it feels like there
> should be some properly reviewed document somewhere else.
These are ACPI-only, instead of DT.
I will add a comment here as Krzysztof suggested.
>
> Adding ACPI and devicetree maintainers to Cc for clarification.
>
>> +static int hccs_check_chan_cmd_complete(struct hccs_dev *hdev)
>> +{
>> +	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
>> +	struct acpi_pcct_shared_memory *comm_base = cl_info->pcc_comm_addr;
>> +	u16 status;
>> +	int ret;
>> +
>> +	/*
>> +	 * Poll PCC status register every 3us(delay_us) for maximum of
>> +	 * deadline_us(timeout_us) until PCC command complete bit is set(cond)
>> +	 */
>> +	ret = readw_relaxed_poll_timeout(&comm_base->status, status,
>> +					 status & HCCS_PCC_STATUS_CMD_COMPLETE,
>> +					 HCCS_POLL_STATUS_TIME_INTERVAL_US,
>> +					 cl_info->deadline_us);
> Is it both safe and faster to use a relaxed readw here, compared
> to the normal one? If there is any access to shared memory
> involved, you need the implied barrier for serialization, and since this
> is already a sleeping operation, I would guess that you don't care
> about the last nanosecond of latency here.
Great comment. I will use the normal one.
>
>> +static ssize_t hccs_show(struct kobject *k, struct attribute *attr,
>> char *buf)
>> +{
>> +	struct kobj_attribute *kobj_attr;
>> +
>> +	kobj_attr = container_of(attr, struct kobj_attribute, attr);
>> +
>> +	return kobj_attr->show(k, kobj_attr, buf);
>> +}
>> +
>> +static const struct sysfs_ops hccs_comm_ops = {
>> +	.show = hccs_show,
>> +};
> Every sysfs interface needs to be documented in Documentation/ABI/
All right, I will add another patch to do this.
>
>> diff --git a/drivers/soc/hisilicon/kunpeng_hccs.h
>> b/drivers/soc/hisilicon/kunpeng_hccs.h
>> new file mode 100644
>> index 000000000000..ca557ef115ea
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
>> @@ -0,0 +1,204 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/* Copyright (c) 2023 Hisilicon Limited. */
>> +
>> +#ifndef __KUNPENG_HCCS_H__
>> +#define __KUNPENG_HCCS_H__
> Are you planning to add more drivers that share this file? If not,
> just fold the contents into the driver itself.
Yes, we will add more drivers in this file.

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Arnd Bergmann]

On Tue, Apr 25, 2023, at 05:04, lihuisong (C) wrote:
> 在 2023/4/24 16:09, Arnd Bergmann 写道:
>> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:

>>         depends on ACPI
>>         depends on (ARM64 && ARCH_HISI) || COMPILE_TEST
> What do you think of adjusting it as below?
> menu "Hisilicon SoC drivers"
>      depends on ARCH_HISI || COMPILE_TEST
>
> config KUNPENG_HCCS
>      depends on ACPI
>      depends on ARM64 || COMPILE_TEST

Yes, that's perfect.

>>
>>> +
>>> +#include "kunpeng_hccs.h"
>>> +
>>> +/* PCC defines */
>>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
>> Should these perhaps be in include/acpi/pcc.h? The 0x50434300
>> number is just "PCC\0", so it appears to not be HCCS specific.
> This is a PCC signature. As stated in the APCI,
> "The signature of a subspace is computed by a bitwiseor of the value 
> 0x50434300
> with the subspace ID. For example, subspace 3 has the signature 0x50434303."
>
> I am not sure if all driver need to use this fixed signature mask.
> As far as I know, cppc_acpi.c didn't use this signature and 
> xgene-hwmon.c used another mask defined in its driver.
> So I place it here.

I would still put it into the generic header, but it doesn't
really matter much, so do it whichever way you prefer. No need
for a separate patch if you decide to use the global header,
it can just be part of your normal patch.

>>> +
>>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>>> +{
>>> +	struct device *dev = hdev->dev;
>>> +
>>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>>> +		dev_err(hdev->dev, "no device-flags property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>>> +	if (!hccs_dev_property_supported(hdev))
>>> +		return -EOPNOTSUPP;
>>> +
>> Where are the device properties documented? I'm never quite sure how
>> to handle these for ACPI-only drivers, since we don't normally have the
>> bindings in Documentation/devicetree/bindings/, but it feels like there
>> should be some properly reviewed document somewhere else.
> These are ACPI-only, instead of DT.
> I will add a comment here as Krzysztof suggested.

I understand that they are ACPI-only, what I'm more interested here is
the general question of how we should document them, to ensure these
are handled consistently across drivers.

>>> --- /dev/null
>>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
>>> @@ -0,0 +1,204 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>> +/* Copyright (c) 2023 Hisilicon Limited. */
>>> +
>>> +#ifndef __KUNPENG_HCCS_H__
>>> +#define __KUNPENG_HCCS_H__
>> Are you planning to add more drivers that share this file? If not,
>> just fold the contents into the driver itself.
> Yes, we will add more drivers in this file.

Ok.


       Arnd

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/4/25 14:08, Arnd Bergmann 写道:
> On Tue, Apr 25, 2023, at 05:04, lihuisong (C) wrote:
>> 在 2023/4/24 16:09, Arnd Bergmann 写道:
>>> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
>>>          depends on ACPI
>>>          depends on (ARM64 && ARCH_HISI) || COMPILE_TEST
>> What do you think of adjusting it as below?
>> menu "Hisilicon SoC drivers"
>>       depends on ARCH_HISI || COMPILE_TEST
>>
>> config KUNPENG_HCCS
>>       depends on ACPI
>>       depends on ARM64 || COMPILE_TEST
> Yes, that's perfect.
>
>>>> +
>>>> +#include "kunpeng_hccs.h"
>>>> +
>>>> +/* PCC defines */
>>>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>>>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
>>> Should these perhaps be in include/acpi/pcc.h? The 0x50434300
>>> number is just "PCC\0", so it appears to not be HCCS specific.
>> This is a PCC signature. As stated in the APCI,
>> "The signature of a subspace is computed by a bitwiseor of the value
>> 0x50434300
>> with the subspace ID. For example, subspace 3 has the signature 0x50434303."
>>
>> I am not sure if all driver need to use this fixed signature mask.
>> As far as I know, cppc_acpi.c didn't use this signature and
>> xgene-hwmon.c used another mask defined in its driver.
>> So I place it here.
> I would still put it into the generic header, but it doesn't
> really matter much, so do it whichever way you prefer. No need
> for a separate patch if you decide to use the global header,
> it can just be part of your normal patch.
ok, keep it the way it is now.
>
>>>> +
>>>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>>>> +{
>>>> +	struct device *dev = hdev->dev;
>>>> +
>>>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>>>> +		dev_err(hdev->dev, "no device-flags property.\n");
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>>>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>>>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>>>> +	if (!hccs_dev_property_supported(hdev))
>>>> +		return -EOPNOTSUPP;
>>>> +
>>> Where are the device properties documented? I'm never quite sure how
>>> to handle these for ACPI-only drivers, since we don't normally have the
>>> bindings in Documentation/devicetree/bindings/, but it feels like there
>>> should be some properly reviewed document somewhere else.
>> These are ACPI-only, instead of DT.
>> I will add a comment here as Krzysztof suggested.
> I understand that they are ACPI-only, what I'm more interested here is
> the general question of how we should document them, to ensure these
> are handled consistently across drivers.
These device properties are reported by ACPI table in firmware.
They are fixed in platform firmware. The user cannot modify them.
Do we need to document them?
>
>>>> --- /dev/null
>>>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
>>>> @@ -0,0 +1,204 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>>> +/* Copyright (c) 2023 Hisilicon Limited. */
>>>> +
>>>> +#ifndef __KUNPENG_HCCS_H__
>>>> +#define __KUNPENG_HCCS_H__
>>> Are you planning to add more drivers that share this file? If not,
>>> just fold the contents into the driver itself.
>> Yes, we will add more drivers in this file.
> Ok.
>
>
>         Arnd
> .

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

Thanks Arnd for cc-ing the ALKML.

On Mon, Apr 24, 2023 at 10:09:47AM +0200, Arnd Bergmann wrote:
> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:

[...]

> > +
> > +static int hccs_get_device_property(struct hccs_dev *hdev)
> > +{
> > +	struct device *dev = hdev->dev;
> > +
> > +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
> > +		dev_err(hdev->dev, "no device-flags property.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
> > +		dev_err(hdev->dev, "no pcc-type property.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
> > +		dev_err(hdev->dev, "no pcc-channel property.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
> > +	if (!hccs_dev_property_supported(hdev))
> > +		return -EOPNOTSUPP;
> > +
>
> Where are the device properties documented? I'm never quite sure how
> to handle these for ACPI-only drivers, since we don't normally have the
> bindings in Documentation/devicetree/bindings/, but it feels like there
> should be some properly reviewed document somewhere else.
>
> Adding ACPI and devicetree maintainers to Cc for clarification.

Why are these DSD style properties added here ? Why can't we just make
use of _CRS with Generic Address Structure(GAS) register entry for each
of the PCC channel which eliminates the need of "pcc-chan-id". The type
must be deduced from the order in the list of _CRS if needed. I don't
quite understand what magic the flags contain here to provide any info
there.

--
Regards,
Sudeep

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/4/25 18:30, Sudeep Holla 写道:
> Thanks Arnd for cc-ing the ALKML.
>
> On Mon, Apr 24, 2023 at 10:09:47AM +0200, Arnd Bergmann wrote:
>> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
> [...]
>
>>> +
>>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>>> +{
>>> +	struct device *dev = hdev->dev;
>>> +
>>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>>> +		dev_err(hdev->dev, "no device-flags property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>>> +	if (!hccs_dev_property_supported(hdev))
>>> +		return -EOPNOTSUPP;
>>> +
>> Where are the device properties documented? I'm never quite sure how
>> to handle these for ACPI-only drivers, since we don't normally have the
>> bindings in Documentation/devicetree/bindings/, but it feels like there
>> should be some properly reviewed document somewhere else.
>>
>> Adding ACPI and devicetree maintainers to Cc for clarification.
> Why are these DSD style properties added here ? Why can't we just make
> use of _CRS with Generic Address Structure(GAS) register entry for each
> of the PCC channel which eliminates the need of "pcc-chan-id". The type
> must be deduced from the order in the list of _CRS if needed. I don't
For firmware, DSD way is simpler and easier to manage these virtual 
platform devices,
and it's an usual way in kernel.
Driver only needs to get a fixed value, like pcc-id and type, here.

Any vantage if using _CRS with GAS compared with DSD?
> quite understand what magic the flags contain here to provide any info
> there.
This flag is used to report other properties, and every bit means a 
property.
For instance, driver doesn't need to request PCC channel during the 
probing phase if driver use PCC operation Region.
>
> .

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
> 
> For firmware, DSD way is simpler and easier to manage these virtual platform
> devices, and it's an usual way in kernel.

Any specific examples you are referring here. We had lots of debate when
DSD was introduced. It must be used only when there is no standard ACPI
way to achieve the same. But in this I don't (yet) think that is the case.
Further "simplicity" is remotely not the reason why you must use DSD.
So until you provide me technical reasons as why _CRS can't work, I
have to NACK this approach. DSD in this case seems like pure hack.

> Driver only needs to get a fixed value, like pcc-id and type, here.
>

Yes and _CRS is used to get similar such properties in ACPI. It includes
normally MMIO and interrupts and since GAS supports PCC and _CRS can
contain GAS, you must simply use that.

> Any vantage if using _CRS with GAS compared with DSD?

Simple IMO, it is also existing standard to achieve things you are trying
to here and DSD is not. You are defining new properties to make DSD work.

So the real question is if _CRS can be used what is the point in defining
DSD for that. Unless I hear more technical and solid reasoning, I see
DSD as just hack and misuse here. It wasn't designed for that and must not
be allowed to make use of it for such use case.

Anyways in case we decide to take DSD route(after more deeper and technical
discussions), as in the kernel docs, please refer [1] for DSD. You need
to publish properties there so that no one comes up with similar but
alternate solution to do exactly this.

> > quite understand what magic the flags contain here to provide any info
> > there.
> This flag is used to report other properties, and every bit means a
> property.
> For instance, driver doesn't need to request PCC channel during the probing
> phase if driver use PCC operation Region.

Sorry I still don't understand it fully.

-- 
Regards,
Sudeep

[1] https://github.com/UEFI/DSD-Guide

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/4/25 21:19, Sudeep Holla 写道:
> On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
>> For firmware, DSD way is simpler and easier to manage these virtual platform
>> devices, and it's an usual way in kernel.
> Any specific examples you are referring here. We had lots of debate when
> DSD was introduced. It must be used only when there is no standard ACPI
> way to achieve the same. But in this I don't (yet) think that is the case.
> Further "simplicity" is remotely not the reason why you must use DSD.
> So until you provide me technical reasons as why _CRS can't work, I
> have to NACK this approach. DSD in this case seems like pure hack.
>
>> Driver only needs to get a fixed value, like pcc-id and type, here.
>>
> Yes and _CRS is used to get similar such properties in ACPI. It includes
> normally MMIO and interrupts and since GAS supports PCC and _CRS can
> contain GAS, you must simply use that.
Hi Sudeep,
Can you give me some usage examples about this? I will try to do it.
>
>> Any vantage if using _CRS with GAS compared with DSD?
> Simple IMO, it is also existing standard to achieve things you are trying
> to here and DSD is not. You are defining new properties to make DSD work.
>
> So the real question is if _CRS can be used what is the point in defining
> DSD for that. Unless I hear more technical and solid reasoning, I see
> DSD as just hack and misuse here. It wasn't designed for that and must not
> be allowed to make use of it for such use case.
>
> Anyways in case we decide to take DSD route(after more deeper and technical
> discussions), as in the kernel docs, please refer [1] for DSD. You need
> to publish properties there so that no one comes up with similar but
> alternate solution to do exactly this.
All right.
>
>>> quite understand what magic the flags contain here to provide any info
>>> there.
>> This flag is used to report other properties, and every bit means a
>> property.
>> For instance, driver doesn't need to request PCC channel during the probing
>> phase if driver use PCC operation Region.
> Sorry I still don't understand it fully.
If a driver uses type2 with polling way on one platform, and uses PCC 
operation Region way to obtain some information on other platform.
The driver doesn't need to request PCC channel when it uses PCC 
Operation Region.
So this driver must be aware of the communication way in advance in a 
way during initialization.

>

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/4/25 21:19, Sudeep Holla 写道:
> On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
>> For firmware, DSD way is simpler and easier to manage these virtual platform
>> devices, and it's an usual way in kernel.
> Any specific examples you are referring here. We had lots of debate when
> DSD was introduced. It must be used only when there is no standard ACPI
> way to achieve the same. But in this I don't (yet) think that is the case.
> Further "simplicity" is remotely not the reason why you must use DSD.
> So until you provide me technical reasons as why _CRS can't work, I
> have to NACK this approach. DSD in this case seems like pure hack.
>
>> Driver only needs to get a fixed value, like pcc-id and type, here.
>>
> Yes and _CRS is used to get similar such properties in ACPI. It includes
> normally MMIO and interrupts and since GAS supports PCC and _CRS can
> contain GAS, you must simply use that.
Hi Sudeep,

I'm tring to use CRS with GAS to report PCC channel ID and get other 
informations driver need by address.
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.

But I don't know how to set and use the address in PCC register.
Where should this address come from?
It seems that ACPI spec is not very detailed about this.
Do you have any suggestions?

On the other hand, we think that System Memory space + method can also 
achieve above goal.
What do you think of that?

Best regards,
Huisong

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/5/4 21:16, lihuisong (C) 写道:
>
> 在 2023/4/25 21:19, Sudeep Holla 写道:
>> On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
>>> For firmware, DSD way is simpler and easier to manage these virtual 
>>> platform
>>> devices, and it's an usual way in kernel.
>> Any specific examples you are referring here. We had lots of debate when
>> DSD was introduced. It must be used only when there is no standard ACPI
>> way to achieve the same. But in this I don't (yet) think that is the 
>> case.
>> Further "simplicity" is remotely not the reason why you must use DSD.
>> So until you provide me technical reasons as why _CRS can't work, I
>> have to NACK this approach. DSD in this case seems like pure hack.
>>
>>> Driver only needs to get a fixed value, like pcc-id and type, here.
>>>
>> Yes and _CRS is used to get similar such properties in ACPI. It includes
>> normally MMIO and interrupts and since GAS supports PCC and _CRS can
>> contain GAS, you must simply use that.
> Hi Sudeep,
>
> I'm tring to use CRS with GAS to report PCC channel ID and get other 
> informations driver need by address.
> 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.
>
> But I don't know how to set and use the address in PCC register.
> Where should this address come from?
> It seems that ACPI spec is not very detailed about this.
> Do you have any suggestions?
>
> On the other hand, we think that System Memory space + method can also 
> achieve above goal.
> What do you think of that?
>
>
Hi Sudeep,

Can you give us some suggestions about above question and idea?

Looking forward to your reply.

/Huisong

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[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.

> 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
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.

> 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.

> 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)

then,

RegisterAddress is usually the offset in the comms address associated with
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
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
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.

-- 
Regards,
Sudeep

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 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.
Currently, this driver requests PCC channel and use type2 to communicate 
with firmware.
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 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)

> 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/
>
>> 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.
>> 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)
})
> 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
     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.)
> 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.
>

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

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

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

Hi Sudeep,

Thanks for your reply.


在 2023/5/16 20:29, Sudeep Holla 写道:
> 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.
ok.
>
>> 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.
Agreed. but I think there isn't any limitation for this with the current 
specification.
There is no strong connection between PCC Operation Region and type3.
Driver can also use PCC to communicate with platform even if the type is 
type3.
In other words, it depends on driver's choice.

Here, we want to use one bit in device-flags to indicates that
firmware and driver use PCC operation Region on feature platform instead 
of only using PCC.

Sorry, I have to admit that the implementation of this driver about this 
really needs
to be optimized to make it more clear.
>
>>>> 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 ?
If driver may support more PCC types, the type also need be known by driver.
Because not all types have the same header size.
The PCC type can be obtained from the PCCT by requesting PCC channel.
 From this point, this pcc type here is unnecessary, right?
>
>>>> 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.
Above way is what you say?
>
>>> 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.
But I still need the device-flags to report if use PCC operation Region.
If so I have to dig one address register from comm subspace, right?
>
> 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 ?
Yes，some platforms may use PCC operation Region.
> If so what is the problem running on such a platform. I see it is useless
I didn't found any problems. But this driver should consider the 
possibility above mentioned.
> 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.
Thanks for you bringing it up.
Indeed, this HCCS_DEV_FLAGS_INTR_B is not good.
I'm going to replace it with PCC operation Region flag.
>
>>> 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.
Get it. Thanks.
> .

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

On Tue, May 16, 2023 at 10:13:58PM +0800, lihuisong (C) wrote:
[...]

>
> But I still need the device-flags to report if use PCC operation Region.
> If so I have to dig one address register from comm subspace, right?

[...]

> Thanks for you bringing it up.
> Indeed, this HCCS_DEV_FLAGS_INTR_B is not good.
> I'm going to replace it with PCC operation Region flag.

From the above 2, I am getting a sense that all these flags dance is for
sharing a PCC subspace ID between this driver and the firmware PCC Opregion ?
If so that may not work as the current implementation of PCC Opregion
assumes the exclusive access to the channel. Since it is initialised
quite early, Opregion must succeed to get the mbox channel acquired and
this driver must fail if they are sharing the channel. Making the sharing
across firmware and this driver may need changes in the PCC Opregion
support code. One possible way is to acquire and release the channel for
each transaction which will be definitely overhead.

-- 
Regards,
Sudeep

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/5/16 22:35, Sudeep Holla 写道:
> On Tue, May 16, 2023 at 10:13:58PM +0800, lihuisong (C) wrote:
> [...]
>
>> But I still need the device-flags to report if use PCC operation Region.
>> If so I have to dig one address register from comm subspace, right?
> [...]
>
>> Thanks for you bringing it up.
>> Indeed, this HCCS_DEV_FLAGS_INTR_B is not good.
>> I'm going to replace it with PCC operation Region flag.
> >From the above 2, I am getting a sense that all these flags dance is for
> sharing a PCC subspace ID between this driver and the firmware PCC Opregion ?
No. I want to use this flag to make compability between different platforms.
This driver only use PCC OpRegion to access to the channel if platform 
support use PCC OpRegion.
Driver must select one of them (PCC and PCC OpRegion) to communicate 
with firmware on one platform.
> If so that may not work as the current implementation of PCC Opregion
> assumes the exclusive access to the channel. Since it is initialised
> quite early, Opregion must succeed to get the mbox channel acquired and
> this driver must fail if they are sharing the channel. Making the sharing
> across firmware and this driver may need changes in the PCC Opregion
Only using PCC OpRegion after requesting and releasing PCC channel 
shouldn't change PCC OpRegion code?
> support code. One possible way is to acquire and release the channel for
> each transaction which will be definitely overhead.
Yes, transaction will be definitely overhead.
The following method should be no such problem.
-->
If driver want to obtain other info by RegisterAddress and offset in PCC 
Register(),
driver generally needs to do it as follows:
1> get channel ID and RegisterAddress and offset.
2> call pcc_mbox_request_channel to acquire the channel.
3> ioremap 'shmem_base_addr' to get 'pcc_comm_addr'
4> obtain other info based on RegisterAddress, offset and 'pcc_comm_addr'.
If driver selects PCC OpRegion method, driver may also need to release 
this PCC channel by calling pcc_mbox_free_channel.
Because this channel will be requested when PCC OpRegion method is 
executed for the first time.


Overall, the above process is a bit cumbersome if this driver only use 
PCC OpRegion.
In addition, I have to dig one address from comm space in share memory,
which will cause the available size of comm space to decrease, right?
So it is better to use other way to do get channel ID and other info if 
it is possible.
What do you think?
>

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:

[...]

> No. I want to use this flag to make compability between different platforms.
> This driver only use PCC OpRegion to access to the channel if platform
> support use PCC OpRegion.

What do you mean by that ? It is not correct. If there is a PCC Opregion,
then you need to make it work with drivers/acpi/acpi_pcc.c

You need to have all the other details in the firmware(ASL). By looking
at the driver, it has no connection to PCC Opregion IMO unless I am missing
something.

> Driver must select one of them (PCC and PCC OpRegion) to communicate with
> firmware on one platform.

No for reasons mentioned above. PCC Opregion support in the kernel will
be minimal and already there. Fix that if it is not working. If you are
attempting to do something with PCC Opregion in this driver, it is just
wrong and I will NACK it if I see anything around that.

> > If so that may not work as the current implementation of PCC Opregion
> > assumes the exclusive access to the channel. Since it is initialised
> > quite early, Opregion must succeed to get the mbox channel acquired and
> > this driver must fail if they are sharing the channel. Making the sharing
> > across firmware and this driver may need changes in the PCC Opregion
> Only using PCC OpRegion after requesting and releasing PCC channel shouldn't
> change PCC OpRegion code?

I don't understand what exactly that means. The spec states clearly that
PCC subspaces that are used for PCC Operation Regions must not be used
as PCC subspaces for other std ACPI features. I don't understand what
really is going on, on this platform as I don't see what you are saying
(which is wrong and I disagree with approach) in the code posted yet.

> > support code. One possible way is to acquire and release the channel for
> > each transaction which will be definitely overhead.
> Yes, transaction will be definitely overhead.
> The following method should be no such problem.
> -->
> If driver want to obtain other info by RegisterAddress and offset in PCC
> Register(), driver generally needs to do it as follows:
> 1> get channel ID and RegisterAddress and offset.
> 2> call pcc_mbox_request_channel to acquire the channel.
> 3> ioremap 'shmem_base_addr' to get 'pcc_comm_addr'
> 4> obtain other info based on RegisterAddress, offset and 'pcc_comm_addr'.

Above sound good but it is not PCC Opregion. Either you are not giving
full context or you are confusing what PCC Opregion means. There is a
section "Declaring PCC Operation Regions", please refer and see if that
is what you have on your platform.

> If driver selects PCC OpRegion method, driver may also need to release this
> PCC channel by calling pcc_mbox_free_channel.

As I mentioned, the driver must not do anything related to PCC Opregion.

> Because this channel will be requested when PCC OpRegion method is executed
> for the first time.
>

drivers/acpi/acpi_pcc.c must take care of that. If not patch that and get
it working. It must be generic and nothing to do with your platform.

> 
> Overall, the above process is a bit cumbersome if this driver only use PCC
> OpRegion.

Yes and hence must not touch anything around PCC Opregion.

> In addition, I have to dig one address from comm space in share memory,
> which will cause the available size of comm space to decrease, right?
> So it is better to use other way to do get channel ID and other info if it
> is possible.
> What do you think?

I am more confused about your platform than yesterday, so I don't have
much valuable suggestions ATM.

-- 
Regards,
Sudeep

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/5/17 17:30, Sudeep Holla 写道:
> On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
>
> [...]
>
>> No. I want to use this flag to make compability between different platforms.
>> This driver only use PCC OpRegion to access to the channel if platform
>> support use PCC OpRegion.
> What do you mean by that ? It is not correct. If there is a PCC Opregion,
> then you need to make it work with drivers/acpi/acpi_pcc.c
>
> You need to have all the other details in the firmware(ASL). By looking
> at the driver, it has no connection to PCC Opregion IMO unless I am missing
> something.
Driver just needs to call these APIs, such as acpi_evaluate_integer(), 
if want to use PCC OpRegion.
I know that. I have tested PCC OpRegion before.
You've completely misunderstood what I said.😅

I mean that this driver plans to support both PCC and PCC OpRegion.
For example,
Platform A: this driver use PCC (as the current implementation)
Platform B: this driver use PCC OpRegion (Currently, this patch does not 
implement it, but it may be available in the future.)
Note:
This driver selects only one of them (PCC and PCC OpRegion) to 
communicate with firmware on one platform.
We use one bit in device-flags to know which one this driver will use.

I'm not sure if you can understand what I mean by saing that.
If you're not confused about this now, can you reply to my last email 
again?😁
>

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
> 
> 在 2023/5/17 17:30, Sudeep Holla 写道:
> > On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
> > 
> > [...]
> > 
> > > No. I want to use this flag to make compability between different platforms.
> > > This driver only use PCC OpRegion to access to the channel if platform
> > > support use PCC OpRegion.
> > What do you mean by that ? It is not correct. If there is a PCC Opregion,
> > then you need to make it work with drivers/acpi/acpi_pcc.c
> > 
> > You need to have all the other details in the firmware(ASL). By looking
> > at the driver, it has no connection to PCC Opregion IMO unless I am missing
> > something.
> Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
> want to use PCC OpRegion.

OK, please provide examples. I am definitely lost as it doesn't match with
my understanding of how PCC Opregions are/can be used.

> I know that. I have tested PCC OpRegion before.

Cool, examples please.

> You've completely misunderstood what I said.😅
>

Hmm, may be but I need examples.

> I mean that this driver plans to support both PCC and PCC OpRegion.
> For example,
> Platform A: this driver use PCC (as the current implementation)

Good, then just keep what it needs in the implementation nothing more
until you add support for something you have described below(not that
I agree, just want you to make progress here based on what is actually
required today)

> Platform B: this driver use PCC OpRegion (Currently, this patch does not
> implement it, but it may be available in the future.)

Then let us discuss that in the future, don't add unnecessary complexity
for some future use case today. You can always add it when you introduce
that feature or support in the future.

> Note:
> This driver selects only one of them (PCC and PCC OpRegion) to communicate
> with firmware on one platform.

Let us keep it simple(KISS). The driver works just for PCC not PCC Opregion
for now.

> We use one bit in device-flags to know which one this driver will use.
>

NACK again just to re-iterate my point if you have not yet accepted that
fact.

> I'm not sure if you can understand what I mean by saing that.
> If you're not confused about this now, can you reply to my last email
> again?😁
>

The example you had IIRC is use of System Memory Opregion to demonstrate
some _DSM. That has nothing to do with PCC Opregion.

Commit 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for
the PCC Type 3 subtype") has the example in the commit message. IIRC,
you have even fixed couple of bugs in that driver. That is the reason
why I don't understand how you think this driver and that can or must
work together. At least I fail to see how ATM(examples please, by that
I mean ASL snippet for PCC vs PCC Opregion usage to work with this driver)

-- 
Regards,
Sudeep

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/5/17 21:16, Sudeep Holla 写道:
> On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
>> 在 2023/5/17 17:30, Sudeep Holla 写道:
>>> On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
>>>
>>> [...]
>>>
>>>> No. I want to use this flag to make compability between different platforms.
>>>> This driver only use PCC OpRegion to access to the channel if platform
>>>> support use PCC OpRegion.
>>> What do you mean by that ? It is not correct. If there is a PCC Opregion,
>>> then you need to make it work with drivers/acpi/acpi_pcc.c
>>>
>>> You need to have all the other details in the firmware(ASL). By looking
>>> at the driver, it has no connection to PCC Opregion IMO unless I am missing
>>> something.
>> Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
>> want to use PCC OpRegion.
> OK, please provide examples. I am definitely lost as it doesn't match with
> my understanding of how PCC Opregions are/can be used.
>
>> I know that. I have tested PCC OpRegion before.
> Cool, examples please.
>
>> You've completely misunderstood what I said.😅
>>
> Hmm, may be but I need examples.
As you said below, the driver works just for PCC not PCC Opregion for now.
not sure if we need to discuss how PCC Opregion is used here.
>
>> I mean that this driver plans to support both PCC and PCC OpRegion.
>> For example,
>> Platform A: this driver use PCC (as the current implementation)
> Good, then just keep what it needs in the implementation nothing more
> until you add support for something you have described below(not that
> I agree, just want you to make progress here based on what is actually
> required today)
Agreed.
>
>> Platform B: this driver use PCC OpRegion (Currently, this patch does not
>> implement it, but it may be available in the future.)
> Then let us discuss that in the future, don't add unnecessary complexity
> for some future use case today. You can always add it when you introduce
> that feature or support in the future.
Yes. We just need to focus on the current.
If there are any usage problems with PCC OpRegion in the future, we can 
discuss that later.

My original full scheme is as follows:
-->
dev_flags = get_device_flags();  // to know if use PCC OpRegion
if (USE_PCC_OPREGION_B in dev_flags is 0) {
     chan_id = get_pcc_chan_id();
     init_mbox_client();
     pcc_mbox_request_channel(cl, chan_id)
} else {
     /* we need to return unsupport now because of no this feature in 
this driver. */
     do_nothing();
}

void get_some_info(...) {
     if (USE_PCC_OPREGION_B in dev_flags is 0)
         pcc_cmd_send();  // use PCC to communicate with Platform
     else
         acpi_evaluate_object(); // will be used in future.
}

As described in the pseudocode above,
it is necessary to put "dev_flags" in this current driver first in case of
the version driver runs on the platform which just use PCC Opregion.
>
>> Note:
>> This driver selects only one of them (PCC and PCC OpRegion) to communicate
>> with firmware on one platform.
> Let us keep it simple(KISS). The driver works just for PCC not PCC Opregion
> for now.
ok.
>
>> We use one bit in device-flags to know which one this driver will use.
>>
> NACK again just to re-iterate my point if you have not yet accepted that
> fact.
Above is our plan. Do you still think we shouldn't add this device-flags?
please let me know.
>> I'm not sure if you can understand what I mean by saing that.
>> If you're not confused about this now, can you reply to my last email
>> again?😁
>>
> The example you had IIRC is use of System Memory Opregion to demonstrate
> some _DSM. That has nothing to do with PCC Opregion.
Yes, it doesn't matter.
I just want to have a way to get device-flags which contains many 
bits(every bits can be used to as one feature for expanding), rigtht?
>
> Commit 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for
> the PCC Type 3 subtype") has the example in the commit message. IIRC,
Your example is very useful to the user.
> you have even fixed couple of bugs in that driver. That is the reason
> why I don't understand how you think this driver and that can or must
Understand you, Sudeep.
At that time, I tested it by a simple demo driver on the platform 
supported type3.

This driver will support multiple platforms.
On some platforms, we can only use PCC with polling way.
And we will add PCC Opregion way for others platforms.
What's more, every platform just use one of them(PCC and PCC Opregion).
> work together. At least I fail to see how ATM(examples please, by that
> I mean ASL snippet for PCC vs PCC Opregion usage to work with this driver)
ok!
For PCC, ASL snippet is little.
I will add ASL snippet when this driver addes PCC Opregion way.
>

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[Sudeep Holla]

On Thu, May 18, 2023 at 04:24:36PM +0800, lihuisong (C) wrote:
> 
> 在 2023/5/17 21:16, Sudeep Holla 写道:
> > On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
> > > 在 2023/5/17 17:30, Sudeep Holla 写道:
> > > > On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > No. I want to use this flag to make compability between different platforms.
> > > > > This driver only use PCC OpRegion to access to the channel if platform
> > > > > support use PCC OpRegion.
> > > > What do you mean by that ? It is not correct. If there is a PCC Opregion,
> > > > then you need to make it work with drivers/acpi/acpi_pcc.c
> > > > 
> > > > You need to have all the other details in the firmware(ASL). By looking
> > > > at the driver, it has no connection to PCC Opregion IMO unless I am missing
> > > > something.
> > > Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
> > > want to use PCC OpRegion.
> > OK, please provide examples. I am definitely lost as it doesn't match with
> > my understanding of how PCC Opregions are/can be used.
> > 
> > > I know that. I have tested PCC OpRegion before.
> > Cool, examples please.
> > 
> > > You've completely misunderstood what I said.😅
> > > 
> > Hmm, may be but I need examples.
> As you said below, the driver works just for PCC not PCC Opregion for now.
> not sure if we need to discuss how PCC Opregion is used here.

Good let us drop the idea of using PCC Opregion with this driver for now.

> > 
> > > I mean that this driver plans to support both PCC and PCC OpRegion.
> > > For example,
> > > Platform A: this driver use PCC (as the current implementation)
> > Good, then just keep what it needs in the implementation nothing more
> > until you add support for something you have described below(not that
> > I agree, just want you to make progress here based on what is actually
> > required today)
> Agreed.
> > 
> > > Platform B: this driver use PCC OpRegion (Currently, this patch does not
> > > implement it, but it may be available in the future.)
> > Then let us discuss that in the future, don't add unnecessary complexity
> > for some future use case today. You can always add it when you introduce
> > that feature or support in the future.
> Yes. We just need to focus on the current.
> If there are any usage problems with PCC OpRegion in the future, we can
> discuss that later.
>

Agreed.

> My original full scheme is as follows:
> -->
> dev_flags = get_device_flags();  // to know if use PCC OpRegion
> if (USE_PCC_OPREGION_B in dev_flags is 0) {
>     chan_id = get_pcc_chan_id();
>     init_mbox_client();
>     pcc_mbox_request_channel(cl, chan_id)
> } else {
>     /* we need to return unsupport now because of no this feature in this
> driver. */
>     do_nothing();
> }
> 
> void get_some_info(...) {
>     if (USE_PCC_OPREGION_B in dev_flags is 0)
>         pcc_cmd_send();  // use PCC to communicate with Platform
>     else
>         acpi_evaluate_object(); // will be used in future.
> }
> 
> As described in the pseudocode above,
> it is necessary to put "dev_flags" in this current driver first in case of
> the version driver runs on the platform which just use PCC Opregion.

No, you can't randomly define dev_flags just to assist your driver
implementation. If you need it, you need to get the spec updated. We
will not add anything unless that happens.

Note that I don't agree with the flags at all but if you convince and get
them added to spec, I won't object.

> >
> > > Note:
> > > This driver selects only one of them (PCC and PCC OpRegion) to communicate
> > > with firmware on one platform.
> > Let us keep it simple(KISS). The driver works just for PCC not PCC Opregion
> > for now.
> ok.

Good

> > 
> > > We use one bit in device-flags to know which one this driver will use.
> > > 
> > NACK again just to re-iterate my point if you have not yet accepted that
> > fact.
> Above is our plan. Do you still think we shouldn't add this device-flags?
> please let me know.

Correct, no device flags as I see no use for it with your PCC only use case
for now, right ?

> > > I'm not sure if you can understand what I mean by saing that.
> > > If you're not confused about this now, can you reply to my last email
> > > again?😁
> > > 
> > The example you had IIRC is use of System Memory Opregion to demonstrate
> > some _DSM. That has nothing to do with PCC Opregion.
> Yes, it doesn't matter.
> I just want to have a way to get device-flags which contains many bits(every
> bits can be used to as one feature for expanding), rigtht?

Get it through the spec, we don't allow random additions for some
implementations like this.

> > 
> > Commit 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for
> > the PCC Type 3 subtype") has the example in the commit message. IIRC,
> Your example is very useful to the user.
> > you have even fixed couple of bugs in that driver. That is the reason
> > why I don't understand how you think this driver and that can or must
> Understand you, Sudeep.
> At that time, I tested it by a simple demo driver on the platform supported
> type3.
>

OK

> This driver will support multiple platforms.
> On some platforms, we can only use PCC with polling way.
> And we will add PCC Opregion way for others platforms.

Again when you do please post the patch with the ASL snippet as I am
very much interested in understanding how you would make that work.

> What's more, every platform just use one of them(PCC and PCC Opregion).

OK

> > work together. At least I fail to see how ATM(examples please, by that
> > I mean ASL snippet for PCC vs PCC Opregion usage to work with this driver)
> ok!
> For PCC, ASL snippet is little.
> I will add ASL snippet when this driver addes PCC Opregion way.


Sounds like a plan to make progress at-least for now.

-- 
Regards,
Sudeep

Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

[lihuisong (C)]

在 2023/5/18 16:38, Sudeep Holla 写道:
> On Thu, May 18, 2023 at 04:24:36PM +0800, lihuisong (C) wrote:
>> 在 2023/5/17 21:16, Sudeep Holla 写道:
>>> On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
>>>> 在 2023/5/17 17:30, Sudeep Holla 写道:
>>>>> On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> No. I want to use this flag to make compability between different platforms.
>>>>>> This driver only use PCC OpRegion to access to the channel if platform
>>>>>> support use PCC OpRegion.
>>>>> What do you mean by that ? It is not correct. If there is a PCC Opregion,
>>>>> then you need to make it work with drivers/acpi/acpi_pcc.c
>>>>>
>>>>> You need to have all the other details in the firmware(ASL). By looking
>>>>> at the driver, it has no connection to PCC Opregion IMO unless I am missing
>>>>> something.
>>>> Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
>>>> want to use PCC OpRegion.
>>> OK, please provide examples. I am definitely lost as it doesn't match with
>>> my understanding of how PCC Opregions are/can be used.
>>>
>>>> I know that. I have tested PCC OpRegion before.
>>> Cool, examples please.
>>>
>>>> You've completely misunderstood what I said.😅
>>>>
>>> Hmm, may be but I need examples.
>> As you said below, the driver works just for PCC not PCC Opregion for now.
>> not sure if we need to discuss how PCC Opregion is used here.
> Good let us drop the idea of using PCC Opregion with this driver for now.
>
>>>> I mean that this driver plans to support both PCC and PCC OpRegion.
>>>> For example,
>>>> Platform A: this driver use PCC (as the current implementation)
>>> Good, then just keep what it needs in the implementation nothing more
>>> until you add support for something you have described below(not that
>>> I agree, just want you to make progress here based on what is actually
>>> required today)
>> Agreed.
>>>> Platform B: this driver use PCC OpRegion (Currently, this patch does not
>>>> implement it, but it may be available in the future.)
>>> Then let us discuss that in the future, don't add unnecessary complexity
>>> for some future use case today. You can always add it when you introduce
>>> that feature or support in the future.
>> Yes. We just need to focus on the current.
>> If there are any usage problems with PCC OpRegion in the future, we can
>> discuss that later.
>>
> Agreed.
>
>> My original full scheme is as follows:
>> -->
>> dev_flags = get_device_flags();  // to know if use PCC OpRegion
>> if (USE_PCC_OPREGION_B in dev_flags is 0) {
>>      chan_id = get_pcc_chan_id();
>>      init_mbox_client();
>>      pcc_mbox_request_channel(cl, chan_id)
>> } else {
>>      /* we need to return unsupport now because of no this feature in this
>> driver. */
>>      do_nothing();
>> }
>>
>> void get_some_info(...) {
>>      if (USE_PCC_OPREGION_B in dev_flags is 0)
>>          pcc_cmd_send();  // use PCC to communicate with Platform
>>      else
>>          acpi_evaluate_object(); // will be used in future.
>> }
>>
>> As described in the pseudocode above,
>> it is necessary to put "dev_flags" in this current driver first in case of
>> the version driver runs on the platform which just use PCC Opregion.
> No, you can't randomly define dev_flags just to assist your driver
> implementation. If you need it, you need to get the spec updated. We
> will not add anything unless that happens.
>
> Note that I don't agree with the flags at all but if you convince and get
> them added to spec, I won't object.
Ok，let us drop it.
>>>> Note:
>>>> This driver selects only one of them (PCC and PCC OpRegion) to communicate
>>>> with firmware on one platform.
>>> Let us keep it simple(KISS). The driver works just for PCC not PCC Opregion
>>> for now.
>> ok.
> Good
>
>>>> We use one bit in device-flags to know which one this driver will use.
>>>>
>>> NACK again just to re-iterate my point if you have not yet accepted that
>>> fact.
>> Above is our plan. Do you still think we shouldn't add this device-flags?
>> please let me know.
> Correct, no device flags as I see no use for it with your PCC only use case
> for now, right ?
Yes, it can still work well.
As for PCC Opregion way on other platform, I think of other way.
>
>>>> I'm not sure if you can understand what I mean by saing that.
>>>> If you're not confused about this now, can you reply to my last email
>>>> again?😁
>>>>
>>> The example you had IIRC is use of System Memory Opregion to demonstrate
>>> some _DSM. That has nothing to do with PCC Opregion.
>> Yes, it doesn't matter.
>> I just want to have a way to get device-flags which contains many bits(every
>> bits can be used to as one feature for expanding), rigtht?
> Get it through the spec, we don't allow random additions for some
> implementations like this.
Get it.
>>> Commit 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for
>>> the PCC Type 3 subtype") has the example in the commit message. IIRC,
>> Your example is very useful to the user.
>>> you have even fixed couple of bugs in that driver. That is the reason
>>> why I don't understand how you think this driver and that can or must
>> Understand you, Sudeep.
>> At that time, I tested it by a simple demo driver on the platform supported
>> type3.
>>
> OK
>
>> This driver will support multiple platforms.
>> On some platforms, we can only use PCC with polling way.
>> And we will add PCC Opregion way for others platforms.
> Again when you do please post the patch with the ASL snippet as I am
> very much interested in understanding how you would make that work.
All right.
>
>> What's more, every platform just use one of them(PCC and PCC Opregion).
> OK
>
>>> work together. At least I fail to see how ATM(examples please, by that
>>> I mean ASL snippet for PCC vs PCC Opregion usage to work with this driver)
>> ok!
>> For PCC, ASL snippet is little.
>> I will add ASL snippet when this driver addes PCC Opregion way.
>
> Sounds like a plan to make progress at-least for now.
>