soc: qcom: Add SoC info driver
Subsystems (2)
v10 cover soc: qcom: Add SoC info driver
This is patchset v10, it takes care of review comments provided in v8 and v9.
v9 --> v10:
- Removed version specific socinfo objects.
- Added a couple of PMIC models in pmic_model array.
- Corrected interpretation of PMIC information related fields.
v8 --> v9:
- Removed qcom_odm attribute.
- Re-introduce soc_of_id array to map soc-id
into human readable string.
v7 --> v8:
- Fixed compilation warning detected in v7
v6 --> v7:
- Some minor style changes
- Rather than showing string for h/w types, just show the number obtained from SMEM. The reader of this number is supposed to parse this into a human readable string as this information may be different for different ODMs
- Create an attribute 'qcom_odm' depending on the presence of corresponding property in SMEM DT entry. This information can be used for ODM specific interpretation of SMEM socinfo content
- Read machine value from DT, rather than using soc-id as index in an ever increasing array of machine names
v5 --> v6:
- use dev_ext_attribute to represent SMEM image items
- Avoid redundant function calls
- Avoid use of unnecessary global variables
- Remove redundant enums
- Avoid redundant checking of socinfo being NULL or not
- Avoid redundant checking of socinfo format version
- Rename show/store function of attributes as _show/_store rather than _get/_set
- Use an array to represent socinfo attributes and create attribute files in a loop depending on the minimum socinfo format version for which these attributes are supported
- if obtained socinfo format version is greater than the maximum known version return an error rather than falling back to maximum known version
v4 --> v5:
- Removed redundant function socinfo_print
v3 --> v4:
- Corrected makefile so that smem and socinfo are treated as one module
- Moved the code snippet to get socinfo smem item into socinfo.c
- Removed redundant use of socinfo major version as it is always zero
- Removed unused enums
- Removed redundant indirections
- Use image_version object to store information about each entry in the smem image table
- Replaced usage of snprintf with sprintf and scnprintf
- Get the address of image version table at the beginning and setup image version attributes only if image version table is available
- Do the same for platform_subtype
- Make different type of image version objects read only or readable/ writable depending on their types. For example apps image attributes can be modified via sysfs but the same can't be done for modem image
- Show PMIC model in a human readable form rather than a numeric number
- Avoid using table in single sysfs entry
- Removed checkpatch warnings about S_IRUGO
v2 --> v3:
- Add support to toss soc information data into entropy pool
- Since socinfo is rolled into smem driver, compile the relevant portion of socinfo driver with smem driver
v1 --> v2:
- Removed inclusion of system_misc.h
- merged socinfo.h into socinfo.c
- made platform type and subtype arrays static
- replaced uint32_t with u32
- made functions static to avoid exposing vendor specific interface
- Replaced usage of IS_ERR_OR_NULL with IS_ERR.
- Remove raw-id attribute usage as human readable soc-id will suffice here
- Avoid using a separate platform driver for socinfo by rolling it into smem driver itself. The sysfs setup is being done in a separate file (socinfo.c)
- Replaced macro BUILD_ID_LENGTH with SMEM_SOCINFO_BUILD_ID_LENGTH.
- For failure cases where socinfo can not be read use a single dummy socinfo with error values.
- Removed usage of early_machine_is_xxx.
Imran Khan (2):
soc: qcom: Add SoC info driver
Documentation/ABI: Add ABI infomation for QCOM socinfo driver
.../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++ drivers/soc/qcom/Kconfig | 1 + drivers/soc/qcom/Makefile | 3 +- drivers/soc/qcom/smem.c | 5 + drivers/soc/qcom/socinfo.c | 518 +++++++++++++++++++++ 5 files changed, 697 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfo create mode 100644 drivers/soc/qcom/socinfo.c
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v10 1/2 soc: qcom: Add SoC info driver
The SoC info driver provides information such as Chip ID, Chip family, serial number and other such details about Qualcomm SoCs to user space, so that if needed some user space utility(like antutu) can query such information using sysfs interface.
--- drivers/soc/qcom/Kconfig | 1 + drivers/soc/qcom/Makefile | 3 +- drivers/soc/qcom/smem.c | 5 + drivers/soc/qcom/socinfo.c | 518 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 526 insertions(+), 1 deletion(-) create mode 100644 drivers/soc/qcom/socinfo.c
drivers/soc/qcom/Kconfig +1 -0
@@ -24,6 +24,7 @@ config QCOM_SMEM tristate "Qualcomm Shared Memory Manager (SMEM)" depends on ARCH_QCOM depends on HWSPINLOCK + select SOC_BUS help Say y here to enable support for the Qualcomm Shared Memory Manager. The driver provides an interface to items in a heap shared among all
drivers/soc/qcom/Makefile +2 -1
@@ -2,7 +2,8 @@ obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o obj-$(CONFIG_QCOM_PM) += spm.o obj-$(CONFIG_QCOM_SMD) += smd.o obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o -obj-$(CONFIG_QCOM_SMEM) += smem.o +obj-$(CONFIG_QCOM_SMEM) += qcom_smem.o +qcom_smem-y := smem.o socinfo.o obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o obj-$(CONFIG_QCOM_SMP2P) += smp2p.o obj-$(CONFIG_QCOM_SMSM) += smsm.o
drivers/soc/qcom/smem.c +5 -0
@@ -85,6 +85,9 @@/* Max number of processors/hosts in a system */ #define SMEM_HOST_COUNT 9 + +extern void qcom_socinfo_init (struct device *device); +/** * struct smem_proc_comm - proc_comm communication struct (legacy) * @command: current command to be executed
@@ -751,6 +754,8 @@ static int qcom_smem_probe(struct platform_device *pdev) __smem = smem; +qcom_socinfo_init (&pdev->dev); +return 0 ; }
drivers/soc/qcom/socinfo.c new file +518 -0
518 lines not on this page · raw message
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v10 2/2 Documentation/ABI: Add ABI information for QCOM socinfo driver
In reply to Imran KhanThe socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfo
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +171 -0
@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variant +What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image. + +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image. + +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. + +What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system. + +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image. + +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC. + +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured. + +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used. + +What: /sys/devices/soc0/machine +Date: January 2017 +Contact: [email protected] +Description: + This file shows the machine name as given in the DT. + +What: /sys/devices/soc0/mpss_image_crm +What: /sys/devices/soc0/mpss_image_variant +What: /sys/devices/soc0/mpss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the MPSS image. + +What: /sys/devices/soc0/platform_subtype +Date: January 2017 +Contact: [email protected] +Description: + This file shows the sub-type of hardware platform + (SKUAA, SKUF etc.) where SoC is being used. + +What: /sys/devices/soc0/platform_version +Date: January 2017 +Contact: [email protected] +Description: + This file show the version of the hardware platform. + +What: /sys/devices/soc0/pmic_die_revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of PMIC die. + +What: /sys/devices/soc0/pmic_model +Date: January 2017 +Contact: [email protected] +Description: + This file shows name of PMIC model. + +What: /sys/devices/soc0/qcom_odm +Date: January 2017 +Contact: [email protected] +Description: + This file shows the ODM using the SoC. + +What: /sys/devices/soc0/raw_version +Date: January 2017 +Contact: [email protected] +Description: + This file shows raw version of the SoC. + +What: /sys/devices/soc0/revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of the SoC. + +What: /sys/devices/soc0/rpm_image_crm +What: /sys/devices/soc0/rpm_image_variant +What: /sys/devices/soc0/rpm_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the RPM image. + +What: /sys/devices/soc0/serial_number +Date: January 2017 +Contact: [email protected] +Description: + This file shows serial number of the SoC. + +What: /sys/devices/soc0/soc_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique numeric id of a Qualcomm SoC. + +What: /sys/devices/soc0/tz_image_crm +What: /sys/devices/soc0/tz_image_variant +What: /sys/devices/soc0/tz_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the TZ image. + +What: /sys/devices/soc0/vendor +Date: January 2017 +Contact: [email protected] +Description: + This file shows the vendor of the SoC. + +What: /sys/devices/soc0/video_image_crm +What: /sys/devices/soc0/video_image_variant +What: /sys/devices/soc0/video_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the video image.
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfo
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +4
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description:
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+ This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variant +What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.
Shouldn't this be part of the ADSP driver?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.
Assuming that the kernel and rootfs are the same image and updated together?
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected]
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. + +What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.
Build of what? The kernel already has a build version.
Quoted 5 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +5
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image. + +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.
Sounds like a standard attr.
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.
I don't see how userspace should care...
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.
What's a platform?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 74
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/machine +Date: January 2017 +Contact: [email protected] +Description: + This file shows the machine name as given in the DT.
This is already exposed.
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 83
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/mpss_image_crm +What: /sys/devices/soc0/mpss_image_variant +What: /sys/devices/soc0/mpss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the MPSS image.
Part of the MPSS driver?
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/platform_subtype +Date: January 2017 +Contact: [email protected] +Description: + This file shows the sub-type of hardware platform + (SKUAA, SKUF etc.) where SoC is being used. + +What: /sys/devices/soc0/platform_version
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 102
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+Date: January 2017 +Contact: [email protected] +Description: + This file show the version of the hardware platform. + +What: /sys/devices/soc0/pmic_die_revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of PMIC die.
Part of the PMIC driver?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 114
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +12
-0+ +What: /sys/devices/soc0/pmic_model +Date: January 2017 +Contact: [email protected] +Description: + This file shows name of PMIC model. + +What: /sys/devices/soc0/qcom_odm +Date: January 2017 +Contact: [email protected] +Description: + This file shows the ODM using the SoC.
The vendor in the top-level compatible should provide this.
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 126
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +12
-0+ +What: /sys/devices/soc0/raw_version +Date: January 2017 +Contact: [email protected] +Description: + This file shows raw version of the SoC. + +What: /sys/devices/soc0/revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of the SoC.
Why do you need both?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 135
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/rpm_image_crm +What: /sys/devices/soc0/rpm_image_variant +What: /sys/devices/soc0/rpm_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the RPM image.
RPM driver?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 141
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/serial_number +Date: January 2017 +Contact: [email protected] +Description: + This file shows serial number of the SoC.
Already have a standard property in DT.
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 147
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/soc_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique numeric id of a Qualcomm SoC.
unique per chip or per SoC model?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 156
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/tz_image_crm +What: /sys/devices/soc0/tz_image_variant +What: /sys/devices/soc0/tz_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the TZ image.
TZ driver?
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 162
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/vendor +Date: January 2017 +Contact: [email protected] +Description: + This file shows the vendor of the SoC.
Already in DT.
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 171
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/video_image_crm +What: /sys/devices/soc0/video_image_variant +What: /sys/devices/soc0/video_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the video image.
Video as in display or video codec? Should be part of the driver.
Rob
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfo
Quoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic soc_device_attribute but for custom attributes like accessory_chip, hw_platform etc., how can we implement a common base. Can we have a private pointer within generic soc_device_attribute structure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.
Quoted 15 lines
Quoted 15 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variant
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.
Quoted 4 lines
Quoted 4 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +4
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 5 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +5
-0+Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Yes. The kernel and rootfs are same image and they are updated together.
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. +
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
This is not build id of the kernel. This is build ID of complete meta image.
Quoted 9 lines
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc. hw_paltform indicates numeric id for different kind of such platforms.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 74
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/machine +Date: January 2017 +Contact: [email protected] +Description: + This file shows the machine name as given in the DT.This is already exposed.
Yeah. Will remove it from this document.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 83
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/mpss_image_crm +What: /sys/devices/soc0/mpss_image_variant +What: /sys/devices/soc0/mpss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the MPSS image.Part of the MPSS driver?
Agree. Kindly see my comment above for the ADSP image(adsp_image_xxx).
Quoted 13 lines
Quoted 13 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +13
-0+ +What: /sys/devices/soc0/platform_subtype +Date: January 2017 +Contact: [email protected] +Description: + This file shows the sub-type of hardware platform + (SKUAA, SKUF etc.) where SoC is being used. + +What: /sys/devices/soc0/platform_version +Date: January 2017 +Contact: [email protected] +Description: + This file show the version of the hardware platform.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 102
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/pmic_die_revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of PMIC die.Part of the PMIC driver?
Agree. Kindly see my comment above for the ADSP image(adsp_image_xxx).
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/pmic_model +Date: January 2017 +Contact: [email protected] +Description: + This file shows name of PMIC model.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 114
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/qcom_odm +Date: January 2017 +Contact: [email protected] +Description: + This file shows the ODM using the SoC.The vendor in the top-level compatible should provide this.
Yeah. Have removed this in the latest version of driver. Will remove it from ABI document too.
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/raw_version +Date: January 2017 +Contact: [email protected] +Description: + This file shows raw version of the SoC.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 126
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of the SoC.Why do you need both?
Revision is version of the soc like 2.0, 3.0, 3.1 etc.
and raw_version is is raw chip version which is an strictly increasing integer counter, increasing for each version of the chip. For example:
Version Raw_version
1.0 0 1.1 1 2.0 2 2.1 3 2.2 4 3.0 5
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 135
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/rpm_image_crm +What: /sys/devices/soc0/rpm_image_variant +What: /sys/devices/soc0/rpm_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the RPM image.RPM driver?
Agree. Kindly see my comment above for the ADSP image(adsp_image_xxx).
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 141
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/serial_number +Date: January 2017 +Contact: [email protected] +Description: + This file shows serial number of the SoC.Already have a standard property in DT.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 147
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/soc_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique numeric id of a Qualcomm SoC.unique per chip or per SoC model?
This is unique per SoC model. For example 8996 and 8996pro would have different soc_id.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 156
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/tz_image_crm +What: /sys/devices/soc0/tz_image_variant +What: /sys/devices/soc0/tz_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the TZ image.TZ driver?
Agree. Kindly see my comment above for the ADSP image(adsp_image_xxx).
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 162
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/vendor +Date: January 2017 +Contact: [email protected] +Description: + This file shows the vendor of the SoC.Already in DT.
Okay. Will remove this field from the driver and from the document.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 171
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/video_image_crm +What: /sys/devices/soc0/video_image_variant +What: /sys/devices/soc0/video_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the video image.Video as in display or video codec? Should be part of the driver.
Agree. Kindly see my comment above for the ADSP image(adsp_image_xxx).
Quoted 1 line
Rob
Thanks for the review comments.
Thanks and Regards,
Imran
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Hi Rob,
Quoted 19 lines · Imran Khan
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfoQuoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Quoted 6 lines
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic
soc_device_attributebut for custom attributes likeaccessory_chip,hw_platformetc., how can we implement a common base. Can we have a private pointer within genericsoc_device_attributestructure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.
Could you please provide some feedback regarding this?
Quoted 24 lines
Quoted 15 lines
Quoted 15 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Quoted 7 lines
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.
Could you please provide some feedback regarding this?
Quoted 67 lines
Quoted 4 lines
Quoted 4 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +4
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_versionQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 5 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +5
-0+Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Yes. The kernel and rootfs are same image and they are updated together.
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. +Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
This is not build id of the kernel. This is build ID of complete meta image.
Quoted 9 lines
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Quoted 5 lines
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Could you please provide some feedback regarding this?
Quoted 182 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc.
hw_paltformindicates numeric id for different kind of such platforms.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 74
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/machine +Date: January 2017 +Contact: [email protected] +Description: + This file shows the machine name as given in the DT.This is already exposed.
Yeah. Will remove it from this document.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 83
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/mpss_image_crm +What: /sys/devices/soc0/mpss_image_variant +What: /sys/devices/soc0/mpss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the MPSS image.Part of the MPSS driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 13 lines
Quoted 13 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +13
-0+ +What: /sys/devices/soc0/platform_subtype +Date: January 2017 +Contact: [email protected] +Description: + This file shows the sub-type of hardware platform + (SKUAA, SKUF etc.) where SoC is being used. + +What: /sys/devices/soc0/platform_version +Date: January 2017 +Contact: [email protected] +Description: + This file show the version of the hardware platform.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 102
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/pmic_die_revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of PMIC die.Part of the PMIC driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/pmic_model +Date: January 2017 +Contact: [email protected] +Description: + This file shows name of PMIC model.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 114
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/qcom_odm +Date: January 2017 +Contact: [email protected] +Description: + This file shows the ODM using the SoC.The vendor in the top-level compatible should provide this.
Yeah. Have removed this in the latest version of driver. Will remove it from ABI document too.
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/raw_version +Date: January 2017 +Contact: [email protected] +Description: + This file shows raw version of the SoC.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 126
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of the SoC.Why do you need both?
Revision is version of the soc like 2.0, 3.0, 3.1 etc.
andraw_versionis is raw chip version which is an strictly increasing integer counter, increasing for each version of the chip. For example:
VersionRaw_version1.0 0 1.1 1 2.0 2 2.1 3 2.2 4 3.0 5Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 135
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/rpm_image_crm +What: /sys/devices/soc0/rpm_image_variant +What: /sys/devices/soc0/rpm_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the RPM image.RPM driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 141
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/serial_number +Date: January 2017 +Contact: [email protected] +Description: + This file shows serial number of the SoC.Already have a standard property in DT.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 147
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/soc_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique numeric id of a Qualcomm SoC.unique per chip or per SoC model?
This is unique per SoC model. For example 8996 and 8996pro would have different
soc_id.Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 156
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/tz_image_crm +What: /sys/devices/soc0/tz_image_variant +What: /sys/devices/soc0/tz_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the TZ image.TZ driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 162
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/vendor +Date: January 2017 +Contact: [email protected] +Description: + This file shows the vendor of the SoC.Already in DT.
Okay. Will remove this field from the driver and from the document.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 171
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/video_image_crm +What: /sys/devices/soc0/video_image_variant +What: /sys/devices/soc0/video_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the video image.Video as in display or video codec? Should be part of the driver.
Quoted 14 lines
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 1 line
Rob
Thanks for the review comments.
Thanks and Regards,
ImranQuoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks and Regards,
Imran
Signature · 1 line
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
On 4/18/2017 7:53 PM, Imran Khan wrote:
Hi Rob,
Could you please provide some feedback so that this discussion can move forward and ABI document can be finalized?
Without the ABI document we are not able to get the corresponding driver finalized and get merged.
Thanks again for your time,
Imran
Quoted 338 lines
Hi Rob,
Quoted 19 lines · Imran Khan
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfoQuoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Quoted 6 lines
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic
soc_device_attributebut for custom attributes likeaccessory_chip,hw_platformetc., how can we implement a common base. Can we have a private pointer within genericsoc_device_attributestructure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.Could you please provide some feedback regarding this?
Quoted 24 lines
Quoted 15 lines
Quoted 15 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Quoted 7 lines
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.Could you please provide some feedback regarding this?
Quoted 67 lines
Quoted 4 lines
Quoted 4 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +4
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_versionQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 5 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +5
-0+Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Yes. The kernel and rootfs are same image and they are updated together.
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. +Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
This is not build id of the kernel. This is build ID of complete meta image.
Quoted 9 lines
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Quoted 5 lines
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Could you please provide some feedback regarding this?
Quoted 182 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc.
hw_paltformindicates numeric id for different kind of such platforms.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 74
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/machine +Date: January 2017 +Contact: [email protected] +Description: + This file shows the machine name as given in the DT.This is already exposed.
Yeah. Will remove it from this document.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 83
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/mpss_image_crm +What: /sys/devices/soc0/mpss_image_variant +What: /sys/devices/soc0/mpss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the MPSS image.Part of the MPSS driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 13 lines
Quoted 13 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +13
-0+ +What: /sys/devices/soc0/platform_subtype +Date: January 2017 +Contact: [email protected] +Description: + This file shows the sub-type of hardware platform + (SKUAA, SKUF etc.) where SoC is being used. + +What: /sys/devices/soc0/platform_version +Date: January 2017 +Contact: [email protected] +Description: + This file show the version of the hardware platform.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 102
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/pmic_die_revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of PMIC die.Part of the PMIC driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/pmic_model +Date: January 2017 +Contact: [email protected] +Description: + This file shows name of PMIC model.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 114
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/qcom_odm +Date: January 2017 +Contact: [email protected] +Description: + This file shows the ODM using the SoC.The vendor in the top-level compatible should provide this.
Yeah. Have removed this in the latest version of driver. Will remove it from ABI document too.
Quoted 6 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/raw_version +Date: January 2017 +Contact: [email protected] +Description: + This file shows raw version of the SoC.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 126
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/revision +Date: January 2017 +Contact: [email protected] +Description: + This file shows revision of the SoC.Why do you need both?
Revision is version of the soc like 2.0, 3.0, 3.1 etc.
andraw_versionis is raw chip version which is an strictly increasing integer counter, increasing for each version of the chip. For example:
VersionRaw_version1.0 0 1.1 1 2.0 2 2.1 3 2.2 4 3.0 5Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 135
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/rpm_image_crm +What: /sys/devices/soc0/rpm_image_variant +What: /sys/devices/soc0/rpm_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the RPM image.RPM driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 141
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/serial_number +Date: January 2017 +Contact: [email protected] +Description: + This file shows serial number of the SoC.Already have a standard property in DT.
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 147
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/soc_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique numeric id of a Qualcomm SoC.unique per chip or per SoC model?
This is unique per SoC model. For example 8996 and 8996pro would have different
soc_id.Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 156
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/tz_image_crm +What: /sys/devices/soc0/tz_image_variant +What: /sys/devices/soc0/tz_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the TZ image.TZ driver?
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 162
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/vendor +Date: January 2017 +Contact: [email protected] +Description: + This file shows the vendor of the SoC.Already in DT.
Okay. Will remove this field from the driver and from the document.
Quoted 12 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 171
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/video_image_crm +What: /sys/devices/soc0/video_image_variant +What: /sys/devices/soc0/video_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the video image.Video as in display or video codec? Should be part of the driver.
Quoted 14 lines
Agree. Kindly see my comment above for the ADSP
image(adsp_image_xxx).Quoted 1 line
Rob
Thanks for the review comments.
Thanks and Regards,
ImranQuoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlThanks and Regards,
Imran
Signature · 1 line
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 7 lines · Imran Khan
On 4/18/2017 7:53 PM, Imran Khan wrote:
Hi Rob,
Could you please provide some feedback so that this discussion can move forward and ABI document can be finalized?
Without the ABI document we are not able to get the corresponding driver finalized and get merged.
Quoted 32 lines
Thanks again for your time,
ImranQuoted 30 lines
Hi Rob,
Quoted 19 lines · Imran Khan
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfoQuoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Quoted 6 lines
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic
soc_device_attributebut for custom attributes likeaccessory_chip,hw_platformetc., how can we implement a common base. Can we have a private pointer within genericsoc_device_attributestructure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.Could you please provide some feedback regarding this?
Splitting things between common and private seems like a good direction.
Quoted 31 lines
Quoted 31 lines
Quoted 30 lines
Quoted 14 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
I don't think parsing things once will save you much.
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Quoted 1 line
Quoted 1 line
Quoted 1 line
Yes. The kernel and rootfs are same image and they are updated together.
Maybe for you, but generally those are separate pieces.
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected]Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. + +What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
Quoted 1 line
Quoted 1 line
Quoted 1 line
This is not build id of the kernel. This is build ID of complete meta image.
That's assuming everything is built together which generally isn't true. It doesn't seem like that is information the kernel should provide.
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Could you please provide some feedback regarding this?
The qcom compatible string format already provides this. I don't think we need 2 ABIs that are both vendor specific to expose this. Now if there's other vendors wanting to expose the foundry, then a common attr would make sense.
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 8 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc.
hw_paltformindicates numeric id for different kind of such platforms.
As above, I believe /compatible already provides that information.
Rob
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 39 lines · Rob Herring
Quoted 38 lines · Imran Khan
On 4/18/2017 7:53 PM, Imran Khan wrote:
Hi Rob,
Could you please provide some feedback so that this discussion can move forward and ABI document can be finalized?
Without the ABI document we are not able to get the corresponding driver finalized and get merged.Thanks again for your time,
ImranQuoted 29 lines
Hi Rob,
Quoted 25 lines · Imran Khan
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfoQuoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic
soc_device_attributebut for custom attributes likeaccessory_chip,hw_platformetc., how can we implement a common base. Can we have a private pointer within genericsoc_device_attributestructure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
Splitting things between common and private seems like a good direction.
But the pattern of amending the common attributes with vendor or platform-specific ones is how its done in other drivers, e.g. integrator.
Why should we for the Qualcomm case make up some other pattern?
Or am I misunderstanding your suggestion?
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 30 lines
Quoted 14 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
I don't think parsing things once will save you much.
Defining the struct in some shared header file and implementing the "parsing" throughout various drivers would probably work out fine.
What I do not fancy is where these "parsers" would be implemented and where the information would end up in sysfs.
"The ADSP driver" has to refer to the remoteproc driver for the adsp and it would be reasonable to have version information of the firmware available for a running piece of remoteproc. The same would work out for modem and wireless.
The v4l driver is responsible for controlling the venus core, so it could provide the version attribute - which would show up somewhere in the /sys/bus/platform hierarchy.
We have a mfd-like driver for communicating with the RPM, so perhaps we could shoehorn in an attribute there. But the sysfs path will be completely different, depending on platform and system configuration.
There is no driver representing the boot code.
So, when Android goes belly up and we want to produce a bugreport that describes all the pieces of the system we will have to all over sysfs to figure out the versions of the firmware...
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Yes. The kernel and rootfs are same image and they are updated together.
Maybe for you, but generally those are separate pieces.
This attribute is special in that it is populated from user space, so any tool running on apps should be able to fetch it directly anyways (e.g. from Android properties).
Imran, is there any users of this information outside the apps context? E.g. does your tools for analysing memory-dumps depend on this information being available in SMEM?
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected]Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. + +What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
This is not build id of the kernel. This is build ID of complete meta image.
That's assuming everything is built together which generally isn't true.
Not necessarily compiled together, but packaged up in something that gets a "release number" - which I presume is quite common for any type of embedded products.
E.g. we do give the Linaro releases version numbers such as "16.09".
Quoted 3 lines
It doesn't seem like that is information the kernel should provide.
I used to say that we could just store this information in a file in /etc (or in build.prop), then I started doing post-build composition and realized that you really do want a new system-version if you change e.g. the version of the boot firmware - without having to regenerate the rootfs.
So while I agree that this is none of the kernel's business I'm not sure how you would get this information from SMEM to a user space process for e.g. bugreport generation purposes.
Quoted 36 lines
Quoted 36 lines
Quoted 36 lines
Quoted 36 lines
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
The qcom compatible string format already provides this. I don't think we need 2 ABIs that are both vendor specific to expose this. Now if there's other vendors wanting to expose the foundry, then a common attr would make sense.
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
For userspace to be able to parse out this information from /proc/device-tree/compatible we need to improve that expression quite a bit! What's the foundry_id of <"acme,phone-a","qcom,platform-b-c">?
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 8 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc.
hw_paltformindicates numeric id for different kind of such platforms.As above, I believe /compatible already provides that information.
I believe this is what OMAP calls "type", in a custom attribute on the side of the common ones.
But as far as I can see this information should be trivial to derive from the compatible of the board. Imran, what is this data used for?
Regards,
Bjorn
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 136 lines · Bjorn Andersson
Quoted 39 lines · Rob Herring
Quoted 38 lines · Imran Khan
On 4/18/2017 7:53 PM, Imran Khan wrote:
Hi Rob,
Could you please provide some feedback so that this discussion can move forward and ABI document can be finalized?
Without the ABI document we are not able to get the corresponding driver finalized and get merged.Thanks again for your time,
ImranQuoted 29 lines
Hi Rob,
Quoted 25 lines · Imran Khan
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfoQuoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic
soc_device_attributebut for custom attributes likeaccessory_chip,hw_platformetc., how can we implement a common base. Can we have a private pointer within genericsoc_device_attributestructure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
Splitting things between common and private seems like a good direction.
But the pattern of amending the common attributes with vendor or platform-specific ones is how its done in other drivers, e.g. integrator.
Why should we for the Qualcomm case make up some other pattern?
Or am I misunderstanding your suggestion?
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 30 lines
Quoted 14 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
I don't think parsing things once will save you much.
Defining the struct in some shared header file and implementing the "parsing" throughout various drivers would probably work out fine.
What I do not fancy is where these "parsers" would be implemented and where the information would end up in sysfs.
"The ADSP driver" has to refer to the remoteproc driver for the adsp and it would be reasonable to have version information of the firmware available for a running piece of remoteproc. The same would work out for modem and wireless.
The v4l driver is responsible for controlling the venus core, so it could provide the version attribute - which would show up somewhere in the
/sys/bus/platformhierarchy.We have a mfd-like driver for communicating with the RPM, so perhaps we could shoehorn in an attribute there. But the sysfs path will be completely different, depending on platform and system configuration.
There is no driver representing the boot code.
So, when Android goes belly up and we want to produce a bugreport that describes all the pieces of the system we will have to all over sysfs to figure out the versions of the firmware...
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Yes. The kernel and rootfs are same image and they are updated together.
Maybe for you, but generally those are separate pieces.
Quoted 8 lines
This attribute is special in that it is populated from user space, so any tool running on apps should be able to fetch it directly anyways (e.g. from Android properties).
Imran, is there any users of this information outside the apps context? E.g. does your tools for analysing memory-dumps depend on this information being available in SMEM?
Yes, apart from apps our memory dump analyzers and diag tools make use of this information
Quoted 111 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected]Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. + +What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
This is not build id of the kernel. This is build ID of complete meta image.
That's assuming everything is built together which generally isn't true.
Not necessarily compiled together, but packaged up in something that gets a "release number" - which I presume is quite common for any type of embedded products.
E.g. we do give the Linaro releases version numbers such as "16.09".
Quoted 3 lines
It doesn't seem like that is information the kernel should provide.
I used to say that we could just store this information in a file in /etc (or in build.prop), then I started doing post-build composition and realized that you really do want a new system-version if you change e.g. the version of the boot firmware - without having to regenerate the rootfs.
So while I agree that this is none of the kernel's business I'm not sure how you would get this information from SMEM to a user space process for e.g. bugreport generation purposes.
Quoted 36 lines
Quoted 36 lines
Quoted 36 lines
Quoted 36 lines
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
The qcom compatible string format already provides this. I don't think we need 2 ABIs that are both vendor specific to expose this. Now if there's other vendors wanting to expose the foundry, then a common attr would make sense.
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
For userspace to be able to parse out this information from
/proc/device-tree/compatiblewe need to improve that expression quite a bit! What's thefoundry_idof <"acme,phone-a","qcom,platform-b-c">?Quoted 16 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 8 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc.
hw_paltformindicates numeric id for different kind of such platforms.
Quoted 9 lines
Quoted 2 lines
As above, I believe /compatible already provides that information.
I believe this is what OMAP calls "type", in a custom attribute on the side of the common ones.
But as far as I can see this information should be trivial to derive from the compatible of the board. Imran, what is this data used for?
This data is used in several cases. For example MTP and QRD boards may use different thermal calibration, different firmwares, different wcnss settings. These are the some use cases, I can recall right now, there may be others too.
Quoted 3 lines
Regards,
Bjorn
Signature · 1 line
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
In reply to Bjorn AnderssonQuoted 46 lines · Bjorn Andersson
Quoted 39 lines · Rob Herring
Quoted 38 lines · Imran Khan
On 4/18/2017 7:53 PM, Imran Khan wrote:
Hi Rob,
Could you please provide some feedback so that this discussion can move forward and ABI document can be finalized?
Without the ABI document we are not able to get the corresponding driver finalized and get merged.Thanks again for your time,
ImranQuoted 29 lines
Hi Rob,
Quoted 25 lines · Imran Khan
Quoted 11 lines · Rob Herring
Quoted 9 lines · Imran
The socinfo ABI document describes the information provided by socinfo driver and the corresponding attributes to access that information.
Signed-off-by Imran Khan <[email protected]>--- .../ABI/testing/sysfs-driver-qcom_socinfo | 171 +++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-qcom_socinfoQuoted 6 lines
Sorry to comment late on this (blame LWM), but I think creating this ABI is a mistake. The biggest issue I have is this doesn't scale if every SoC does its own thing. We should have a common interface so for example userspace can retrieve the serial number from any SoC in the same way. Yes, we can have custom attributes, but there should be common base.
Yeah, I agree about the scalability part. Could you please suggest some way to implement a common base for the custom attributes. Like for serial number I think we can put it in generic
soc_device_attributebut for custom attributes likeaccessory_chip,hw_platformetc., how can we implement a common base. Can we have a private pointer within genericsoc_device_attributestructure and this private pointer can point to custom attributes. Or if you have some other suggestion to implement this common interface, please let me know.Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
Splitting things between common and private seems like a good direction.
Quoted 7 lines
But the pattern of amending the common attributes with vendor or platform-specific ones is how its done in other drivers, e.g. integrator.
Why should we for the Qualcomm case make up some other pattern?
Or am I misunderstanding your suggestion?
I'm just trying to ensure that we make things that could be common, common. The question here was about the implementation.
Right now, drivers/soc is just a free for all dumping ground IMO.
Quoted 55 lines
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 30 lines
Quoted 14 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
I don't think parsing things once will save you much.
Defining the struct in some shared header file and implementing the "parsing" throughout various drivers would probably work out fine.
What I do not fancy is where these "parsers" would be implemented and where the information would end up in sysfs.
"The ADSP driver" has to refer to the remoteproc driver for the adsp and it would be reasonable to have version information of the firmware available for a running piece of remoteproc. The same would work out for modem and wireless.
The v4l driver is responsible for controlling the venus core, so it could provide the version attribute - which would show up somewhere in the
/sys/bus/platformhierarchy.We have a mfd-like driver for communicating with the RPM, so perhaps we could shoehorn in an attribute there. But the sysfs path will be completely different, depending on platform and system configuration.
Quoted 6 lines
There is no driver representing the boot code.
So, when Android goes belly up and we want to produce a bugreport that describes all the pieces of the system we will have to all over sysfs to figure out the versions of the firmware...
Can't you just use the meta build id? That implies the version of *everything*, right?
Quoted 50 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 23
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/apps_image_crm +What: /sys/devices/soc0/apps_image_variant +What: /sys/devices/soc0/apps_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the APPS(Linux kernel, rootfs) image.Assuming that the kernel and rootfs are the same image and updated together?
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Yes. The kernel and rootfs are same image and they are updated together.
Maybe for you, but generally those are separate pieces.
This attribute is special in that it is populated from user space, so any tool running on apps should be able to fetch it directly anyways (e.g. from Android properties).
Imran, is there any users of this information outside the apps context? E.g. does your tools for analysing memory-dumps depend on this information being available in SMEM?
Quoted 22 lines
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 11 lines
Quoted 11 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +10
-0+ +What: /sys/devices/soc0/boot_image_crm +What: /sys/devices/soc0/boot_image_variant +What: /sys/devices/soc0/boot_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the Boot(bootloader) image. +Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 39
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
This is not build id of the kernel. This is build ID of complete meta image.
Quoted 8 lines
Quoted 2 lines
That's assuming everything is built together which generally isn't true.
Not necessarily compiled together, but packaged up in something that gets a "release number" - which I presume is quite common for any type of embedded products.
E.g. we do give the Linaro releases version numbers such as "16.09".
Yes, but I doubt the release number is visible inside the release unless it is part of some existing version like the kernel's version string. If this is quite common, then lets make it common.
Why not just make this a file in the filesystem? Why does the kernel need to provide it?
Quoted 57 lines
Quoted 3 lines
It doesn't seem like that is information the kernel should provide.
I used to say that we could just store this information in a file in /etc (or in build.prop), then I started doing post-build composition and realized that you really do want a new system-version if you change e.g. the version of the boot firmware - without having to regenerate the rootfs.
So while I agree that this is none of the kernel's business I'm not sure how you would get this information from SMEM to a user space process for e.g. bugreport generation purposes.
Quoted 43 lines
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +9
-0+ +What: /sys/devices/soc0/cnss_image_crm +What: /sys/devices/soc0/cnss_image_variant +What: /sys/devices/soc0/cnss_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the CNSS image.Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 54
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+ +What: /sys/devices/soc0/family +Date: January 2017 +Contact: [email protected] +Description: + This file shows the family(e.g Snapdragon) of the SoC.Sounds like a standard attr.
Yeah. This is standard attribute. Will remove this from Documentation here.
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 61
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/foundry_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the foundry, where soc was + manufactured.I don't see how userspace should care...
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Yeah, usually user space would not care for such information. But sometimes we have come across h/w issues that were seen only on set of chips from a particular foundry. Under such situations we use this information to confirm if a certain h/w issue is specific to a batch from a particular foundry or not.
Could you please provide some feedback regarding this?
The qcom compatible string format already provides this. I don't think we need 2 ABIs that are both vendor specific to expose this. Now if there's other vendors wanting to expose the foundry, then a common attr would make sense.
Quoted 6 lines
Quoted 2 lines
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
For userspace to be able to parse out this information from
/proc/device-tree/compatiblewe need to improve that expression quite a bit! What's thefoundry_idof <"acme,phone-a","qcom,platform-b-c">?
I can't help it if QCom defines an elaborate compatible string format and then doesn't use it.
Quoted 26 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 68
Quoted 7 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +7
-0+ +What: /sys/devices/soc0/hw_platform +Date: January 2017 +Contact: [email protected] +Description: + This file shows the type of hardware platform + (e.g MTP, QRD etc) where SoC is being used.What's a platform?
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
We may use same soc on different type of platforms. For example for QCOM we have MTP (board with which a debug board can be connected), QRD (no debug connection available). Similarly other ODMs may have different kind of platforms based on same soc.
hw_paltformindicates numeric id for different kind of such platforms.As above, I believe /compatible already provides that information.
I believe this is what OMAP calls "type", in a custom attribute on the side of the common ones.
But as far as I can see this information should be trivial to derive from the compatible of the board. Imran, what is this data used for?
Regards,
Bjorn
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 3 lines · Rob Herring
Quoted 1 line · Bjorn Andersson
On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote:
[..]
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Splitting things between common and private seems like a good direction.
But the pattern of amending the common attributes with vendor or platform-specific ones is how its done in other drivers, e.g. integrator.
Quoted 9 lines
Quoted 3 lines
Why should we for the Qualcomm case make up some other pattern?
Or am I misunderstanding your suggestion?
I'm just trying to ensure that we make things that could be common, common. The question here was about the implementation.
Right now,
drivers/socis just a free for all dumping ground IMO.
Unfortunately I fully agree with this, we did spend several revisions on just trying to match Qualcomm properties to the common attributes - and I don't know if we got it right.
Quoted 58 lines
Quoted 58 lines
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 30 lines
Quoted 14 lines
Quoted 14 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +8
-0@@ -0,0 +1,171 @@ +What: /sys/devices/soc0/accessory_chip +Date: January 2017 +Contact: [email protected] +Description: + This file shows the id of the accessory chip. + +What: /sys/devices/soc0/adsp_image_crm +What: /sys/devices/soc0/adsp_image_variantQuoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 14
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/adsp_image_version +Date: January 2017 +Contact: [email protected] +Description: + These files respectively show the crm version, variant and + version of the ADSP image.Shouldn't this be part of the ADSP driver?
Yes, It can be but I wanted to keep the image information at a central location, rather than pushing it back to each driver. For image information we basically read the same item from SMEM but use different offsets within it for different images, so the idea was to read this information ( get SMEM handler) just once, rather than doing it for each driver.
But if this idea does not look correct, I can remove it from socinfo driver.Quoted 4 lines
Quoted 1 line
Quoted 1 line
Could you please provide some feedback regarding this?
I don't think parsing things once will save you much.
Defining the struct in some shared header file and implementing the "parsing" throughout various drivers would probably work out fine.
What I do not fancy is where these "parsers" would be implemented and where the information would end up in sysfs.
"The ADSP driver" has to refer to the remoteproc driver for the adsp and it would be reasonable to have version information of the firmware available for a running piece of remoteproc. The same would work out for modem and wireless.
The v4l driver is responsible for controlling the venus core, so it could provide the version attribute - which would show up somewhere in the
/sys/bus/platformhierarchy.We have a mfd-like driver for communicating with the RPM, so perhaps we could shoehorn in an attribute there. But the sysfs path will be completely different, depending on platform and system configuration.
There is no driver representing the boot code.
Quoted 7 lines
Quoted 3 lines
So, when Android goes belly up and we want to produce a bugreport that describes all the pieces of the system we will have to all over sysfs to figure out the versions of the firmware...
Can't you just use the meta build id? That implies the version of *everything*, right?
For products yes, but when _you_ ask us why WiFi doesn't work on your Dragonboard it's quite nice to be able to get hold of the boot-loader and wcnss-firmware versions - and you're likely not on an unmodified meta-build.
For me this information is more valuable than the meta-build id, but that's because I'm working with engineering builds.
[..]
Quoted 18 lines
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo line 20
Quoted 6 lines
Documentation/ABI/testing/sysfs-driver-qcom_socinfo new file +6
-0+What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
This is not build id of the kernel. This is build ID of complete meta image.
That's assuming everything is built together which generally isn't true.
Not necessarily compiled together, but packaged up in something that gets a "release number" - which I presume is quite common for any type of embedded products.
Quoted 6 lines
Quoted 1 line
E.g. we do give the Linaro releases version numbers such as "16.09".
Yes, but I doubt the release number is visible inside the release unless it is part of some existing version like the kernel's version string. If this is quite common, then lets make it common.
I don't know how common this is - as you suggest below perhaps people just put it in one of the file systems?
Quoted 1 line
Why not just make this a file in the filesystem?
Because that forces you to rebuild your file system to update the version of the system. That said I don't know the details of how Qualcomm persistently encode this information.
Quoted 2 lines
Why does the kernel need to provide it?
Imran, can you elaborate on how this information is travels from the build system to the SMEM item?
Regards,
Bjorn
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 20 lines · Bjorn Andersson
Quoted 3 lines · Rob Herring
Quoted 1 line · Bjorn Andersson
On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote:
[..]
Quoted 14 lines
Quoted 10 lines
Quoted 2 lines
Splitting things between common and private seems like a good direction.
But the pattern of amending the common attributes with vendor or platform-specific ones is how its done in other drivers, e.g. integrator.
Why should we for the Qualcomm case make up some other pattern?
Or am I misunderstanding your suggestion?
I'm just trying to ensure that we make things that could be common, common. The question here was about the implementation.
Quoted 7 lines
Quoted 2 lines
Right now,
drivers/socis just a free for all dumping ground IMO.Unfortunately I fully agree with this, we did spend several revisions on just trying to match Qualcomm properties to the common attributes - and I don't know if we got it right.
I would be glad to get further feedback in this regard as we would like it to be as close to the generic attributes as possible. But it is also true that right now generic soc_device_attributes are too few to expose the information that we are intending to expose here.
[...]
Quoted 52 lines
Quoted 8 lines
Quoted 4 lines
So, when Android goes belly up and we want to produce a bugreport that describes all the pieces of the system we will have to all over sysfs to figure out the versions of the firmware...
Can't you just use the meta build id? That implies the version of *everything*, right?
For products yes, but when _you_ ask us why WiFi doesn't work on your Dragonboard it's quite nice to be able to get hold of the boot-loader and wcnss-firmware versions - and you're likely not on an unmodified meta-build.
For me this information is more valuable than the meta-build id, but that's because I'm working with engineering builds.
[..]
Quoted 18 lines
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+What: /sys/devices/soc0/build_id +Date: January 2017 +Contact: [email protected] +Description: + This file shows the unique id of current build being used on + the system.Build of what? The kernel already has a build version.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
This is not build id of the kernel. This is build ID of complete meta image.
That's assuming everything is built together which generally isn't true.
Not necessarily compiled together, but packaged up in something that gets a "release number" - which I presume is quite common for any type of embedded products.
Quoted 6 lines
Quoted 1 line
E.g. we do give the Linaro releases version numbers such as "16.09".
Yes, but I doubt the release number is visible inside the release unless it is part of some existing version like the kernel's version string. If this is quite common, then lets make it common.
I don't know how common this is - as you suggest below perhaps people just put it in one of the file systems?
Quoted 1 line
Why not just make this a file in the filesystem?
Because that forces you to rebuild your file system to update the version of the system. That said I don't know the details of how Qualcomm persistently encode this information.
Quoted 6 lines
Quoted 2 lines
Why does the kernel need to provide it?
Imran, can you elaborate on how this information is travels from the build system to the SMEM item?
This information, along with other SMEM items for this SMEM-id is written by the bootloader (SBL). Please let me know if this much information suffices in this regard.
Thanks and Regards,
Imran
Quoted 3 lines
Regards,
Bjorn
Signature · 1 line
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 6 lines · Imran Khan
Quoted 5 lines · Bjorn Andersson
Quoted 3 lines · Rob Herring
Quoted 1 line · Bjorn Andersson
On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote:
[..]
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
+What:
/sys/devices/soc0/build_id
[..]
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
Why does the kernel need to provide it?
Imran, can you elaborate on how this information is travels from the build system to the SMEM item?
This information, along with other SMEM items for this SMEM-id is written by the bootloader (SBL). Please let me know if this much information suffices in this regard.
But where does the SBL find this information? Per my previous argument it doesn't make sense to store this information compiled into one of the components. Is it the CDT perhaps?
Regards,
Bjorn
Re: [v10, 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver
Quoted 18 lines · Bjorn Andersson
Quoted 6 lines · Imran Khan
Quoted 5 lines · Bjorn Andersson
Quoted 3 lines · Rob Herring
Quoted 1 line · Bjorn Andersson
On Mon 24 Apr 09:27 PDT 2017, Rob Herring wrote:
[..]
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
+What:
/sys/devices/soc0/build_id[..]
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Why does the kernel need to provide it?
Imran, can you elaborate on how this information is travels from the build system to the SMEM item?
Quoted 8 lines
Quoted 3 lines
This information, along with other SMEM items for this SMEM-id is written by the bootloader (SBL). Please let me know if this much information suffices in this regard.
But where does the SBL find this information? Per my previous argument it doesn't make sense to store this information compiled into one of the components. Is it the CDT perhaps?
Yes SBL is getting this information from CDT.
Thanks and Regards,
Imran
Quoted 7 lines
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation