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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux