* [PATCH v3 3/4] ARM: dts: stm32: make hdmi-transmitter node compliant with DT bindings
From: Ricardo Cañuelo @ 2020-06-01 6:33 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-1-ricardo.canuelo@collabora.com>
Reorder the I2C slave addresses of the hdmi-transmitter node and remove
the adi,input-style and adi,input-justification properties to meet the
adi,adv7513 binding requirements.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
index 930202742a3f..b67a21a8698a 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
@@ -185,8 +185,8 @@
&i2c4 {
hdmi-transmitter@3d {
compatible = "adi,adv7513";
- reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
- reg-names = "main", "cec", "edid", "packet";
+ reg = <0x3d>, <0x4d>, <0x2d> , <0x5d>;
+ reg-names = "main", "edid", "cec", "packet";
clocks = <&cec_clock>;
clock-names = "cec";
@@ -204,8 +204,6 @@
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
ports {
#address-cells = <1>;
--
2.18.0
^ permalink raw reply related
* [PATCH v3 1/4] ARM: dts: zynq: add port definitions to hdmi-tx@39
From: Ricardo Cañuelo @ 2020-06-01 6:33 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-1-ricardo.canuelo@collabora.com>
Define a 'ports' node for 'adv7511: hdmi-tx@39' to make it compliant with
the adi,adv7511 DT binding.
This fills the minimum requirements to meet the binding requirements,
remote endpoints are not defined.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/boot/dts/zynq-zc702.dts | 10 ++++++++++
arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 27cd6cb52f1b..79fd236edded 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -135,6 +135,16 @@
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "right";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 77943c16d33f..99fa51ba6e93 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -93,6 +93,16 @@
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "evenly";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
--
2.18.0
^ permalink raw reply related
* [PATCH v3 2/4] arm64: dts: hisilicon: hikey: fixes to comply with adi,adv7533 DT binding
From: Ricardo Cañuelo @ 2020-06-01 6:33 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-1-ricardo.canuelo@collabora.com>
hi3660-hikey960.dts:
Define a 'ports' node for 'adv7533: adv7533@39' and the
'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT
binding.
This fills the requirements to meet the binding requirements,
remote endpoints are not defined.
hi6220-hikey.dts:
Change property name s/pd-gpio/pd-gpios, gpio properties should be
plural. This is just a cosmetic change.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 11 +++++++++++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index e035cf195b19..8c4bfbaf3a80 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -530,6 +530,17 @@
status = "ok";
compatible = "adi,adv7533";
reg = <0x39>;
+ adi,dsi-lanes = <4>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index c14205cd6bf5..3e47150c05ec 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -516,7 +516,7 @@
reg = <0x39>;
interrupt-parent = <&gpio1>;
interrupts = <1 2>;
- pd-gpio = <&gpio0 4 0>;
+ pd-gpios = <&gpio0 4 0>;
adi,dsi-lanes = <4>;
#sound-dai-cells = <0>;
--
2.18.0
^ permalink raw reply related
* [PATCH v3 0/4] Convert adi,adv7511.txt DT bindings to yaml
From: Ricardo Cañuelo @ 2020-06-01 6:33 UTC (permalink / raw)
To: laurent.pinchart
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
Hi,
This series convert the adi,adv7511.txt DT bindings to json-schema. As a
result of the conversion some dts files needed to be updated.
The changes to the dts files are of three types:
- Reordering of the I2C slave addresses list of the ADV75xx node. The
addresses in the 'reg' property and the matching names in
'reg-names' for an I2C slave don't need to be in any particular
order, but the DT schema defines these properties as a cell array
and a string array respectively, which are ordered, so the
definitions in the dts files must match the order in the binding.
- Filling the minimum binding requirements. Most of the time this
means creating a 'ports' node in the boards that don't define
them. Note, however, that the purpose of this is simply to make the
definition compliant with the binding. I didn't define any endpoints
for the ports.
- Removing unneeded properties.
About the binding conversion:
- The original binding covered five different devices: ADV7511,
ADV7511W, ADV7513, ADV7533 and ADV7535. They all share a common set
of properties but ADV7533 and ADV7535 have enough differences from
the rest to warrant their own binding file. In v1 I modelled all the
properties constraints for all five devices in a single file but it
turned out a bit too complex. Splitting the binding into one for
ADV7511/11W/13 and another for ADV7533/35 makes them much easier to
read and maintain.
Patches 1/4 to 3/4 contain the dts changes. Patch 4/4 contains the
binding conversion.
NOTE: the bindings have been tested with:
make dt_binding_check ARCH=<arch> DT_SCHEMA_FILES=<...adi,adv7511.yaml>
make dt_binding_check ARCH=<arch> DT_SCHEMA_FILES=<...adi,adv7533.yaml>
make dtbs_check ARCH=<arch> DT_SCHEMA_FILES=<...adi,adv7511.yaml>
make dtbs_check ARCH=<arch> DT_SCHEMA_FILES=<...adi,adv7533.yaml>
for <arch> = arm and arm64. dts changes haven't been tested in hardware.
Some existing DTs are expected to fail after this conversion.
Changes in v3:
- Removed from the patch series (already in mainline):
- arm64: dts: renesas: make hdmi encoder nodes compliant with DT bindings
- ARM: dts: renesas: make hdmi encoder nodes compliant with DT bindings
- ARM: dts: iwg20d-q7-dbcm-ca: remove unneeded properties in hdmi@39
- Additional DTs fixes:
- boot/dts/stm32mp15xx-dhcor-avenger96.dtsi.
- [Laurent] adi,adv7511.yaml and adi,adv7533.yaml.
- Documentation fixes and typos.
- Removed unnecessary allOf's.
- adi,embedded-sync data type changed to boolean.
- Power supplies defined as required.
- Examples updated.
Ricardo Cañuelo (4):
ARM: dts: zynq: add port definitions to hdmi-tx@39
arm64: dts: hisilicon: hikey: fixes to comply with adi,adv7533 DT
binding
ARM: dts: stm32: make hdmi-transmitter node compliant with DT bindings
dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
.../bindings/display/bridge/adi,adv7511.txt | 143 -----------
.../bindings/display/bridge/adi,adv7511.yaml | 231 ++++++++++++++++++
.../bindings/display/bridge/adi,adv7533.yaml | 175 +++++++++++++
.../boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 6 +-
arch/arm/boot/dts/zynq-zc702.dts | 10 +
arch/arm/boot/dts/zynq-zc706.dts | 10 +
.../boot/dts/hisilicon/hi3660-hikey960.dts | 11 +
.../arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +-
8 files changed, 440 insertions(+), 148 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
--
2.18.0
^ permalink raw reply
* [PATCH 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
From: Liu Ying @ 2020-06-01 6:11 UTC (permalink / raw)
To: dri-devel; +Cc: devicetree, thierry.reding, sam, linux-imx
This patch adds support for Kaohsiung Opto-Electronics Inc.
10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface.
The panel has dual LVDS channels.
My panel is manufactured by US Micro Products(USMP). There is a tag at
the back of the panel, which indicates the panel type is 'TX26D202VM0BWA'
and it's made by KOE in Taiwan.
The panel spec from USMP can be found at:
https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf
The below panel spec from KOE is basically the same to the one from USMP.
However, the panel type 'TX26D202VM0BAA' is a little bit different.
It looks that the two types of panel are compatible with each other.
http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
drivers/gpu/drm/panel/panel-simple.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b6ecd15..7c222ec 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2200,6 +2200,37 @@ static const struct panel_desc koe_tx14d24vm1bpa = {
},
};
+static const struct display_timing koe_tx26d202vm0bwa_timing = {
+ .pixelclock = { 151820000, 156720000, 159780000 },
+ .hactive = { 1920, 1920, 1920 },
+ .hfront_porch = { 105, 130, 142 },
+ .hback_porch = { 45, 70, 82 },
+ .hsync_len = { 30, 30, 30 },
+ .vactive = { 1200, 1200, 1200},
+ .vfront_porch = { 3, 5, 10 },
+ .vback_porch = { 2, 5, 10 },
+ .vsync_len = { 5, 5, 5 },
+};
+
+static const struct panel_desc koe_tx26d202vm0bwa = {
+ .timings = &koe_tx26d202vm0bwa_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 1000,
+ .enable = 1000,
+ .unprepare = 1000,
+ .disable = 1000,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing koe_tx31d200vm0baa_timing = {
.pixelclock = { 39600000, 43200000, 48000000 },
.hactive = { 1280, 1280, 1280 },
@@ -3832,6 +3863,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "koe,tx14d24vm1bpa",
.data = &koe_tx14d24vm1bpa,
}, {
+ .compatible = "koe,tx26d202vm0bwa",
+ .data = &koe_tx26d202vm0bwa,
+ }, {
.compatible = "koe,tx31d200vm0baa",
.data = &koe_tx31d200vm0baa,
}, {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: panel-simple: Add koe,tx26d202vm0bwa compatible
From: Liu Ying @ 2020-06-01 6:10 UTC (permalink / raw)
To: devicetree; +Cc: dri-devel, thierry.reding, sam, robh+dt, linux-imx
Add compatible to panel-simple for Kaohsiung Opto-Electronics Inc.
10.1" WUXGA(1920x1200) TX26D202VM0BWA TFT LCD panel with LVDS interface.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index d6cca14..31e3efc 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -157,6 +157,8 @@ properties:
- innolux,zj070na-01p
# Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
- koe,tx14d24vm1bpa
+ # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
+ - koe,tx26d202vm0bwa
# Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
- koe,tx31d200vm0baa
# Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] drm/panel: simple: Add a KOE WUXGA 10.1" LVDS panel support
From: Liu Ying @ 2020-06-01 6:09 UTC (permalink / raw)
To: devicetree, dri-devel; +Cc: thierry.reding, sam, linux-imx
This patch set adds a KOE WUXGA 10.1" LVDS panel support.
The panel type is TX26D202VM0BWA.
The panel has dual LVDS channels.
My panel is manufactured by US Micro Products(USMP). There is a tag at
the back of the panel, which indicates the panel type is 'TX26D202VM0BWA'
and it's made by KOE in Taiwan.
The panel spec from USMP can be found at:
https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf
The below panel spec from KOE is basically the same to the one from USMP.
However, the panel type 'TX26D202VM0BAA' is a little bit different.
It looks that the two types of panel are compatible with each other.
http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf
Patch 1/2 adds compatible for the panel in the panel-simple DT binding doc.
Patch 2/2 adds the panel support in the DRM panel-simple driver.
Liu Ying (2):
dt-bindings: panel-simple: Add koe,tx26d202vm0bwa compatible
drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c | 34 ++++++++++++++++++++++
2 files changed, 36 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH V2 2/2] arm64: tegra: Add pwm-fan profile settings
From: Sandipan Patra @ 2020-06-01 6:19 UTC (permalink / raw)
To: treding, jonathanh, linux, kamil, jdelvare, robh+dt,
u.kleine-koenig
Cc: bbasu, bbiswas, kyarlagadda, linux-pwm, linux-hwmon, devicetree,
linux-tegra, linux-kernel, Sandipan Patra
In-Reply-To: <1590992354-12623-1-git-send-email-spatra@nvidia.com>
Add support for profiles in device tree to allow
different fan settings for trip point temp/hyst/pwm.
Signed-off-by: Sandipan Patra <spatra@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index e15d1ea..ff2b980 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
@@ -219,10 +219,19 @@
fan: fan {
compatible = "pwm-fan";
- pwms = <&pwm4 0 45334>;
-
- cooling-levels = <0 64 128 255>;
#cooling-cells = <2>;
+ pwms = <&pwm4 0 45334>;
+ profiles {
+ default = "quiet";
+ quiet {
+ state_cap = <4>;
+ cooling-levels = <0 77 120 160 255 255 255 255 255 255>;
+ };
+ cool {
+ state_cap = <4>;
+ cooling-levels = <0 77 120 160 255 255 255 255 255 255>;
+ };
+ };
};
gpio-keys {
--
2.7.4
^ permalink raw reply related
* [PATCH V2 1/2] hwmon: pwm-fan: Add profile support and add remove module support
From: Sandipan Patra @ 2020-06-01 6:19 UTC (permalink / raw)
To: treding, jonathanh, linux, kamil, jdelvare, robh+dt,
u.kleine-koenig
Cc: bbasu, bbiswas, kyarlagadda, linux-pwm, linux-hwmon, devicetree,
linux-tegra, linux-kernel, Sandipan Patra
Add support for profiles mode settings.
This allows different fan settings for trip point temp/hyst/pwm.
Tegra194 has multiple fan-profiles support.
Signed-off-by: Sandipan Patra <spatra@nvidia.com>
---
PATCH V2:
Cleaned pwm_fan_remove support as it is not required.
drivers/hwmon/pwm-fan.c | 92 ++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 80 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 30b7b3e..1d2a416 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -3,8 +3,10 @@
* pwm-fan.c - Hwmon driver for fans connected to PWM lines.
*
* Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2020, NVIDIA Corporation.
*
* Author: Kamil Debski <k.debski@samsung.com>
+ * Author: Sandipan Patra <spatra@nvidia.com>
*/
#include <linux/hwmon.h>
@@ -21,6 +23,8 @@
#include <linux/timer.h>
#define MAX_PWM 255
+/* Based on OF max device tree node name length */
+#define MAX_PROFILE_NAME_LENGTH 31
struct pwm_fan_ctx {
struct mutex lock;
@@ -38,6 +42,12 @@ struct pwm_fan_ctx {
unsigned int pwm_fan_state;
unsigned int pwm_fan_max_state;
unsigned int *pwm_fan_cooling_levels;
+
+ unsigned int pwm_fan_profiles;
+ const char **fan_profile_names;
+ unsigned int **fan_profile_cooling_levels;
+ unsigned int fan_current_profile;
+
struct thermal_cooling_device *cdev;
};
@@ -227,28 +237,86 @@ static int pwm_fan_of_get_cooling_data(struct device *dev,
struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
+ struct device_node *base_profile = NULL;
+ struct device_node *profile_np = NULL;
+ const char *default_profile = NULL;
int num, i, ret;
- if (!of_find_property(np, "cooling-levels", NULL))
- return 0;
+ num = of_property_count_u32_elems(np, "cooling-levels");
+ if (num <= 0) {
+ base_profile = of_get_child_by_name(np, "profiles");
+ if (!base_profile) {
+ dev_err(dev, "Wrong Data\n");
+ return -EINVAL;
+ }
+ }
+
+ if (base_profile) {
+ ctx->pwm_fan_profiles =
+ of_get_available_child_count(base_profile);
- ret = of_property_count_u32_elems(np, "cooling-levels");
- if (ret <= 0) {
- dev_err(dev, "Wrong data!\n");
- return ret ? : -EINVAL;
+ if (ctx->pwm_fan_profiles <= 0) {
+ dev_err(dev, "Profiles used but not defined\n");
+ return -EINVAL;
+ }
+
+ ctx->fan_profile_names = devm_kzalloc(dev,
+ sizeof(const char *) * ctx->pwm_fan_profiles,
+ GFP_KERNEL);
+ ctx->fan_profile_cooling_levels = devm_kzalloc(dev,
+ sizeof(int *) * ctx->pwm_fan_profiles,
+ GFP_KERNEL);
+
+ if (!ctx->fan_profile_names
+ || !ctx->fan_profile_cooling_levels)
+ return -ENOMEM;
+
+ ctx->fan_current_profile = 0;
+ i = 0;
+ for_each_available_child_of_node(base_profile, profile_np) {
+ num = of_property_count_u32_elems(profile_np,
+ "cooling-levels");
+ if (num <= 0) {
+ dev_err(dev, "No data in cooling-levels inside profile node!\n");
+ return -EINVAL;
+ }
+
+ of_property_read_string(profile_np, "name",
+ &ctx->fan_profile_names[i]);
+ if (default_profile &&
+ !strncmp(default_profile,
+ ctx->fan_profile_names[i],
+ MAX_PROFILE_NAME_LENGTH))
+ ctx->fan_current_profile = i;
+
+ ctx->fan_profile_cooling_levels[i] =
+ devm_kzalloc(dev, sizeof(int) * num,
+ GFP_KERNEL);
+ if (!ctx->fan_profile_cooling_levels[i])
+ return -ENOMEM;
+
+ of_property_read_u32_array(profile_np, "cooling-levels",
+ ctx->fan_profile_cooling_levels[i], num);
+ i++;
+ }
}
- num = ret;
ctx->pwm_fan_cooling_levels = devm_kcalloc(dev, num, sizeof(u32),
GFP_KERNEL);
if (!ctx->pwm_fan_cooling_levels)
return -ENOMEM;
- ret = of_property_read_u32_array(np, "cooling-levels",
- ctx->pwm_fan_cooling_levels, num);
- if (ret) {
- dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
- return ret;
+ if (base_profile) {
+ memcpy(ctx->pwm_fan_cooling_levels,
+ ctx->fan_profile_cooling_levels[ctx->fan_current_profile],
+ num);
+ } else {
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return -EINVAL;
+ }
}
for (i = 0; i < num; i++) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: media: venus: Add an optional power domain for perf voting
From: Rajendra Nayak @ 2020-06-01 5:56 UTC (permalink / raw)
To: Rob Herring
Cc: stanimir.varbanov, agross, bjorn.andersson, linux-arm-msm,
linux-media, devicetree, linux-kernel, mka
In-Reply-To: <20200527193638.GA2604206@bogus>
On 5/28/2020 1:06 AM, Rob Herring wrote:
> On Wed, May 13, 2020 at 11:33:27AM +0530, Rajendra Nayak wrote:
>> Add an optional power domain which when specified can be used for
>> setting the performance state of Venus.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml | 6 +++++-
>> Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 6 +++++-
>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
>> index 764affa..ac1ed64 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
>> @@ -25,12 +25,16 @@ properties:
>> maxItems: 1
>>
>> power-domains:
>> - maxItems: 2
>> + minItems: 2
>> + maxItems: 3
>>
>> power-domain-names:
>> + minItems: 2
>> + maxItems: 3
>> items:
>> - const: venus
>> - const: vcodec0
>> + - const: opp-pd
>
> Humm, looks suspicious. This is a phyical power island in this block?
yes, this is used to represent the physical 'cx' power island in the SoC
(Its a shared power island, not a power island specific to this block)
that can be scaled to different 'performance levels' based on the frequency
the codec is expected to run at.
> Because that's what 'power-domains' are supposed to represent. Not $os
> pm-domain construct.
>
> Rob
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 2/2] USB: PHY: JZ4770: Add support for Ingenic X1000 and X1830.
From: kbuild test robot @ 2020-06-01 4:31 UTC (permalink / raw)
To: 周琰杰 (Zhou Yanjie), linux-usb
Cc: kbuild-all, clang-built-linux, linux-kernel, devicetree, balbi,
gregkh, robh+dt, dongsheng.qiu, aric.pzqi, rick.tyliu, yanfei.li
In-Reply-To: <20200530165253.17445-3-zhouyanjie@wanyeetech.com>
[-- Attachment #1: Type: text/plain, Size: 3864 bytes --]
Hi "周琰杰,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on balbi-usb/testing/next]
[also build test WARNING on v5.7]
[cannot apply to usb/usb-testing next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Zhou-Yanjie/Add-USB-PHY-support-for-Ingenic-X1000-and-X1830/20200601-030314
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 2388a096e7865c043e83ece4e26654bd3d1a20d5)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/usb/phy/phy-jz4770.c:267:19: warning: cast to smaller integer type 'enum ingenic_usb_phy_version' from 'const void *' [-Wvoid-pointer-to-enum-cast]
priv->version = (enum ingenic_usb_phy_version)match->data;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +267 drivers/usb/phy/phy-jz4770.c
253
254 static int jz4770_phy_probe(struct platform_device *pdev)
255 {
256 struct device *dev = &pdev->dev;
257 struct jz4770_phy *priv;
258 const struct of_device_id *match;
259 int err;
260
261 priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
262 if (!priv)
263 return -ENOMEM;
264
265 match = of_match_device(ingenic_usb_phy_of_matches, dev);
266 if (match)
> 267 priv->version = (enum ingenic_usb_phy_version)match->data;
268 else
269 return -ENODEV;
270
271 platform_set_drvdata(pdev, priv);
272 priv->dev = dev;
273 priv->phy.dev = dev;
274 priv->phy.otg = &priv->otg;
275 priv->phy.label = "ingenic-usb-phy";
276 priv->phy.init = jz4770_phy_init;
277 priv->phy.shutdown = jz4770_phy_shutdown;
278
279 priv->otg.state = OTG_STATE_UNDEFINED;
280 priv->otg.usb_phy = &priv->phy;
281 priv->otg.set_host = jz4770_phy_set_host;
282 priv->otg.set_peripheral = jz4770_phy_set_peripheral;
283
284 priv->base = devm_platform_ioremap_resource(pdev, 0);
285 if (IS_ERR(priv->base)) {
286 dev_err(dev, "Failed to map registers");
287 return PTR_ERR(priv->base);
288 }
289
290 priv->clk = devm_clk_get(dev, NULL);
291 if (IS_ERR(priv->clk)) {
292 err = PTR_ERR(priv->clk);
293 if (err != -EPROBE_DEFER)
294 dev_err(dev, "Failed to get clock");
295 return err;
296 }
297
298 priv->vcc_supply = devm_regulator_get(dev, "vcc");
299 if (IS_ERR(priv->vcc_supply)) {
300 err = PTR_ERR(priv->vcc_supply);
301 if (err != -EPROBE_DEFER)
302 dev_err(dev, "Failed to get regulator");
303 return err;
304 }
305
306 err = usb_add_phy(&priv->phy, USB_PHY_TYPE_USB2);
307 if (err) {
308 if (err != -EPROBE_DEFER)
309 dev_err(dev, "Unable to register PHY");
310 return err;
311 }
312
313 return devm_add_action_or_reset(dev, jz4770_phy_remove, &priv->phy);
314 }
315
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 73514 bytes --]
^ permalink raw reply
* Re: [PATCH v5 02/11] dt-bindings: dma: dw: Add max burst transaction length property
From: Viresh Kumar @ 2020-06-01 4:21 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Rob Herring, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann,
Andy Shevchenko, linux-mips, dmaengine, devicetree, linux-kernel
In-Reply-To: <20200529144054.4251-3-Sergey.Semin@baikalelectronics.ru>
On 29-05-20, 17:40, Serge Semin wrote:
> This array property is used to indicate the maximum burst transaction
> length supported by each DMA channel.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Rearrange SoBs.
> - Move $ref to the root level of the properties. So do with the
> constraints.
> - Set default max-burst-len to 256 TR-WIDTH words.
>
> Changelog v3:
> - Add more details into the property description about what limitations
> snps,max-burst-len defines.
> ---
> .../bindings/dma/snps,dma-spear1340.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v5 01/11] dt-bindings: dma: dw: Convert DW DMAC to DT binding
From: Viresh Kumar @ 2020-06-01 4:20 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Rob Herring, Andy Shevchenko,
Serge Semin, Rob Herring, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, linux-mips, dmaengine, devicetree, linux-kernel
In-Reply-To: <20200529144054.4251-2-Sergey.Semin@baikalelectronics.ru>
On 29-05-20, 17:40, Serge Semin wrote:
> Modern device tree bindings are supposed to be created as YAML-files
> in accordance with dt-schema. This commit replaces the Synopsis
> Designware DMA controller legacy bare text bindings with YAML file.
> The only required prorties are "compatible", "reg", "#dma-cells" and
> "interrupts", which will be used by the driver to correctly find the
> controller memory region and handle its events. The rest of the properties
> are optional, since in case if either "dma-channels" or "dma-masters" isn't
> specified, the driver will attempt to auto-detect the IP core
> configuration.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
From: Prakhar Srivastava @ 2020-06-01 4:05 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, linux-kernel,
linuxppc-dev, devicetree, linux-integrity, linux-security-module,
catalin.marinas, will, mpe, benh, paulus, frowand.list, zohar,
dmitry.kasatkin, jmorris, serge, pasha.tatashin, allison,
kstewart, takahiro.akashi, tglx, vincenzo.frascino, masahiroy,
james.morse, bhsharma, mbrugger, hsinyi, tao.li, christophe.leroy,
gregkh, nramas, tusharsu, balajib
In-Reply-To: <87v9knpa36.fsf@morokweng.localdomain>
On 5/22/20 9:08 PM, Thiago Jung Bauermann wrote:
>
> Hello Prakhar,
>
> Prakhar Srivastava <prsriva@linux.microsoft.com> writes:
>
>> On 5/12/20 4:05 PM, Rob Herring wrote:
>>> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:
>>>> Hi Mark,
>>>
>>> Please don't top post.
>>>
>>>> This patch set currently only address the Pure DT implementation.
>>>> EFI and ACPI implementations will be posted in subsequent patchsets.
>>>>
>>>> The logs are intended to be carried over the kexec and once read the
>>>> logs are no longer needed and in prior conversation with James(
>>>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/)
>>>> the apporach of using a chosen node doesn't
>>>> support the case.
>>>>
>>>> The DT entries make the reservation permanent and thus doesnt need kernel
>>>> segments to be used for this, however using a chosen-node with
>>>> reserved memory only changes the node information but memory still is
>>>> reserved via reserved-memory section.
>>>
>>> I think Mark's point was whether it needs to be permanent. We don't
>>> hardcode the initrd address for example.
>>>
>> Thankyou for clarifying my misunderstanding, i am modelling this keeping to the
>> TPM log implementation that uses a reserved memory. I will rev up the version
>> with chosen-node support.
>> That will make the memory reservation free after use.
>
> Nice. Do you intend to use the same property that powerpc uses
> (linux,ima-kexec-buffer)?
>
I was naming it ima-buffer, but naming is not a huge concern.
I will use linux,ima-kexec-buffer.
>>>> On 5/5/20 2:59 AM, Mark Rutland wrote:
>>>>> Hi Prakhar,
>>>>>
>>>>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote:
>>>>>> IMA during kexec(kexec file load) verifies the kernel signature and measures
>>>
>>> What's IMAIMA is a LSM attempting to detect if files have been accidentally or
>> maliciously altered, both remotely and locally, it can also be used
>> to appraise a file's measurement against a "good" value stored as an extended
>> attribute, and enforce local file integrity.
>>
>> IMA also validates and measures the signers of the kernel and initrd
>> during kexec. The measurements are extended to PCR 10(configurable) and the logs
>> stored in memory, however once kexec'd the logs are lost. Kexec is used as
>> secondary boot loader in may use cases and loosing the signer
>> creates a security hole.
>>
>> This patch is an implementation to carry over the logs and making it
>> possible to remotely validate the signers of the kernel and initrd. Such a
>> support exits only in powerpc.
>> This patch makes the carry over of logs architecture independent and puts the
>> complexity in a driver.
>
> If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually
> powerpc-specific. It could be moved to an arch-independent directory and
> used by any other architecture which supports device trees.
>
> I think that's the simplest way forward. And to be honest I'm still
> trying to understand why you didn't take that approach. Did you try it
> and hit some obstacle or noticed a disadvantage for your use case?
>
The approach i have in this patch set is to provide an abstraction layer
that can be called from any architecture.
However taking a deeper look only the setup dtb is probably architecture
specific, only because the architecture specific kexec sets up the
device tree. I can also move the code up in security/ima. However i do
have some concerns with layering. I am hoping you can provide me with
some guidance in this aspect, i will send you the patch i am working on
to get some early feedback.
Thanks,
Prakhar Srivastava
> --
> Thiago Jung Bauermann
> IBM Linux Technology Center
>
^ permalink raw reply
* [PATCH V2 3/3] clk: imx8mp: add mu root clk
From: peng.fan @ 2020-06-01 3:43 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
In-Reply-To: <1590982999-7149-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add mu root clk for mu mailbox usage.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
---
drivers/clk/imx/clk-imx8mp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b4d9db9d5bf1..ca747712400f 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -680,6 +680,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
hws[IMX8MP_CLK_I2C2_ROOT] = imx_clk_hw_gate4("i2c2_root_clk", "i2c2", ccm_base + 0x4180, 0);
hws[IMX8MP_CLK_I2C3_ROOT] = imx_clk_hw_gate4("i2c3_root_clk", "i2c3", ccm_base + 0x4190, 0);
hws[IMX8MP_CLK_I2C4_ROOT] = imx_clk_hw_gate4("i2c4_root_clk", "i2c4", ccm_base + 0x41a0, 0);
+ hws[IMX8MP_CLK_MU_ROOT] = imx_clk_hw_gate4("mu_root_clk", "ipg_root", ccm_base + 0x4210, 0);
hws[IMX8MP_CLK_OCOTP_ROOT] = imx_clk_hw_gate4("ocotp_root_clk", "ipg_root", ccm_base + 0x4220, 0);
hws[IMX8MP_CLK_PCIE_ROOT] = imx_clk_hw_gate4("pcie_root_clk", "pcie_aux", ccm_base + 0x4250, 0);
hws[IMX8MP_CLK_PWM1_ROOT] = imx_clk_hw_gate4("pwm1_root_clk", "pwm1", ccm_base + 0x4280, 0);
--
2.16.4
^ permalink raw reply related
* [PATCH V2 2/3] arm64: dts: imx8m: add mu node
From: peng.fan @ 2020-06-01 3:43 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
In-Reply-To: <1590982999-7149-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add mu node to let A53 could communicate with M Core.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 9 +++++++++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 9 +++++++++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 9 +++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 +++++++++
4 files changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71101a1..fc001fb971e9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -775,6 +775,15 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MM_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b40000 {
compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a267d4..c8290d21ccc9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -675,6 +675,15 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b40000 {
compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 45e2c0a4e889..b530804f763e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -621,6 +621,15 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MP_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
i2c5: i2c@30ad0000 {
compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..66ba8da704f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -959,6 +959,15 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MQ_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b40000 {
compatible = "fsl,imx8mq-usdhc",
"fsl,imx7d-usdhc";
--
2.16.4
^ permalink raw reply related
* [PATCH V2 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: peng.fan @ 2020-06-01 3:43 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
In-Reply-To: <1590982999-7149-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
index 26b7a88c2fea..906377acf2cd 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
@@ -18,7 +18,8 @@ Messaging Unit Device Node:
Required properties:
-------------------
- compatible : should be "fsl,<chip>-mu", the supported chips include
- imx6sx, imx7s, imx8qxp, imx8qm.
+ imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
+ imx8mp.
The "fsl,imx6sx-mu" compatible is seen as generic and should
be included together with SoC specific compatible.
There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
--
2.16.4
^ permalink raw reply related
* [PATCH V2 0/3] imx8m: add mu support
From: peng.fan @ 2020-06-01 3:43 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
V2:
Add dt-bindings
Merge dts changes into one patch, since all is to add mu node
Add mu dt bindings
Add mu node
Add i.MX8MP mu root clk
Peng Fan (3):
dt-bindings: mailbox: imx-mu: support i.MX8M
arm64: dts: imx8m: add mu node
clk: imx8mp: add mu root clk
Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 9 +++++++++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 9 +++++++++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 9 +++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 +++++++++
drivers/clk/imx/clk-imx8mp.c | 1 +
6 files changed, 39 insertions(+), 1 deletion(-)
--
2.16.4
^ permalink raw reply
* [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-01 3:35 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, hongtao.jia,
linux-pm, devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- add 'maxItems' for 'fsl,tmu-range' property;
- add 'minItems'/'maxItems' and items descriptions for 'fsl,tmu-calibration' property;
- remove description for common property '#thermal-sensor-cells';
- refine 'fsl,tmu-calibration' format in example.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..c5df999
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Hongtao Jia <hongtao.jia@freescale.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+ maxItems: 4
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+ items:
+ items:
+ - description: value for TTCFGR
+ - description: value for TSCFGR
+ minItems: 1
+ maxItems: 64
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025>,
+ <0x00000001 0x00000028>,
+ <0x00000002 0x0000002d>,
+ <0x00000003 0x00000031>,
+ <0x00000004 0x00000036>,
+ <0x00000005 0x0000003a>,
+ <0x00000006 0x00000040>,
+ <0x00000007 0x00000044>,
+ <0x00000008 0x0000004a>,
+ <0x00000009 0x0000004f>,
+ <0x0000000a 0x00000054>,
+ <0x00010000 0x0000000d>,
+ <0x00010001 0x00000013>,
+ <0x00010002 0x00000019>,
+ <0x00010003 0x0000001f>,
+ <0x00010004 0x00000025>,
+ <0x00010005 0x0000002d>,
+ <0x00010006 0x00000033>,
+ <0x00010007 0x00000043>,
+ <0x00010008 0x0000004b>,
+ <0x00010009 0x00000053>,
+ <0x00020000 0x00000010>,
+ <0x00020001 0x00000017>,
+ <0x00020002 0x0000001f>,
+ <0x00020003 0x00000029>,
+ <0x00020004 0x00000031>,
+ <0x00020005 0x0000003c>,
+ <0x00020006 0x00000042>,
+ <0x00020007 0x0000004d>,
+ <0x00020008 0x00000056>,
+ <0x00030000 0x00000012>,
+ <0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6] support gce on mt6779 platform
From: Dennis-YC Hsieh @ 2020-06-01 2:41 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Matthias Brugger, Philipp Zabel,
David Airlie, Daniel Vetter, Linux Kernel Mailing List,
linux-mediatek, Devicetree List, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <CABb+yY16FzgafSYRo8DuVMttqUR5JVzXDsaP2rX+UnrNOD6k2A@mail.gmail.com>
Hi Jassi,
Thanks for your comment
On Sat, 2020-05-30 at 15:34 -0500, Jassi Brar wrote:
> On Thu, May 28, 2020 at 12:05 PM Dennis YC Hsieh
> <dennis-yc.hsieh@mediatek.com> wrote:
> >
> > This patch support gce on mt6779 platform.
> >
> > Change since v5:
> > - spearate address shift code in client helper and mailbox controller
> > - separate write_s/write_s_mask and write_s_value/write_s_mask_value so that
> > client can decide use mask or not
> > - fix typo in header
> >
> > Change since v4:
> > - do not clear disp event again in drm driver
> > - symbolize value 1 to jump relative
> >
> > [... snip ...]
> >
> >
> >
> > Dennis YC Hsieh (16):
> > dt-binding: gce: add gce header file for mt6779
> > mailbox: cmdq: variablize address shift in platform
> > mailbox: cmdq: support mt6779 gce platform definition
> > mailbox: mediatek: cmdq: clear task in channel before shutdown
> > soc: mediatek: cmdq: return send msg error code
> > soc: mediatek: cmdq: add address shift in jump
> > soc: mediatek: cmdq: add assign function
> > soc: mediatek: cmdq: add write_s function
> > soc: mediatek: cmdq: add write_s_mask function
> > soc: mediatek: cmdq: add read_s function
> > soc: mediatek: cmdq: add write_s value function
> > soc: mediatek: cmdq: add write_s_mask value function
> > soc: mediatek: cmdq: export finalize function
> > soc: mediatek: cmdq: add jump function
> > soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
> > soc: mediatek: cmdq: add set event function
> >
> > .../devicetree/bindings/mailbox/mtk-gce.txt | 8 +-
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +-
> > drivers/mailbox/mtk-cmdq-mailbox.c | 101 ++++++--
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 163 ++++++++++++-
> > include/dt-bindings/gce/mt6779-gce.h | 222 ++++++++++++++++++
> > include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +-
> > include/linux/soc/mediatek/mtk-cmdq.h | 125 +++++++++-
> >
> Please break the patchset into two. The lower mailbox related changes
> with soc changes on top.
Ok, I'll separate patches into two patchset, thanks.
Regards,
Dennis
>
> thanks
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-06-01 2:33 UTC (permalink / raw)
To: Tomasz Figa
Cc: Sakari Ailus, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男), dongchun.zhu
In-Reply-To: <CAAFQd5AuHDpQN8xZsWgnAt6m2reAYJbs9nBp0+mBo7_FS81LbQ@mail.gmail.com>
Hi Tomasz,
On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote:
> On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Sakari,
> >
> > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari, Rob,
> > > >
> > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > Hi Rob, Dongchun,
> > > > >
> > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > + properties:
> > > > > > > > > + endpoint:
> > > > > > > > > + type: object
> > > > > > > > > + additionalProperties: false
> > > > > > > > > +
> > > > > > > > > + properties:
> > > > > > >
> > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > >
> > > > > > Yes, if you are using it.
> > > > >
> > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > lane and that it does not support lane reordering?
> > > > >
> > > >
> > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > communication links between components inside a mobile device.
> > > > The data lane has full support for HS(uni-directional) and
> > > > LP(bi-directional) data transfer mode.'
> > > >
> > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > would not be added in next release.
> > > >
> > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > be removed IMO.
> > > > >
> > > >
> > > > However, 'data-lanes' property may still be required.
> > > > It is known that either data-lanes or clock-lanes is an array of
> > > > physical data lane indexes. Position of an entry determines the logical
> > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > the clock lane is on hardware lane 0.
> > > >
> > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > there is only a clock lane for OV02A10.
> > > >
> > > > Reminder:
> > > > If 'data-lanes' property is not present, the driver would assume
> > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > property must be present and set to the right physical lane indexes.
> > > > If the hardware does not support lane reordering, monotonically
> > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > whether or not there is also a clock lane.
> > >
> > > How can the driver use four lanes, considering the device only supports a
> > > single lane??
> > >
> >
> > I understood your meaning.
> > If we omit the property 'data-lanes', the sensor should work still.
> > But then what's the meaning of the existence of 'data-lanes'?
> > If this property 'data-lanes' is always optional, then why dt-bindings
> > provide the interface?
> >
> > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > shall enable four-lane configuration, which may increase consumption of
> > both power and resource in the process of IIC communication.
>
> Wouldn't the receiver still have the data-lanes property under its
> endpoint node, telling it how many lanes and in which order should be
> used?
>
The MIPI receiver(RX) shall use
v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property
"data-lanes" under sensor output port.
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v9 2/8] tpm: tpm_tis: Fix expected bit handling and send all bytes in one shot without last byte in exception
From: Jarkko Sakkinen @ 2020-06-01 2:30 UTC (permalink / raw)
To: amirmizi6
Cc: Eyal.Cohen, oshrialkoby85, alexander.steffen, robh+dt, peterhuewe,
christophe-h.richard, jgg, arnd, gregkh, devicetree, linux-kernel,
linux-integrity, oshri.alkoby, tmaimon77, gcwilson, kgoldman,
Dan.Morav, oren.tanami, shmulik.hager, amir.mizinski,
Benoit Houyere
In-Reply-To: <20200526141658.157801-3-amirmizi6@gmail.com>
On Tue, May 26, 2020 at 05:16:52PM +0300, amirmizi6@gmail.com wrote:
> From: Amir Mizinski <amirmizi6@gmail.com>
>
> Incorrect implementation of send message was detected. We polled only
> TPM_STS.stsValid bit and then we single-checked the TPM_STS.expect bit
> value.
> TPM_STS.expected bit should be checked at the same time as
> TPM_STS.stsValid bit, and this should be repeated until timeout_A.
I don't understand what the first paragraph is trying to say. It does
not conclude to anything. Please write instead soemthing that explains
what is going on.
> To detect a TPM_STS.expected bit reset, the "wait_for_tpm_stat" function is
> modified to "wait_for_tpm_stat_result". This function regularly reads the
> status register and check the bits defined by "mask" to reach the value
> defined in "mask_result".
Please remove this and explain instead how are you are changing the
existing function.
> This correct implementation is required for using the new CRC calculation
> on I2C TPM command bytes or I2C TPM answer bytes. TPM_STS.expected bit is
> reset after all bytes are acquired and the CRC result is inserted in the
> dedicated register. It introduces a normal latency for TPM_STS.expected
> bit reset.
>
> Respectively, to send a message, as defined in
> TCG_DesignPrinciples_TPM2p0Driver_vp24_pubrev.pdf, all bytes should be
> sent in one shot instead of sending the last byte separately.
>
> Suggested-by: Benoit Houyere <benoit.houyere@st.com>
> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com>
> ---
> drivers/char/tpm/tpm_tis_core.c | 74 +++++++++++++++++------------------------
> 1 file changed, 30 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index 27c6ca0..c725b68 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -44,9 +44,10 @@ static bool wait_for_tpm_stat_cond(struct tpm_chip *chip, u8 mask,
> return false;
> }
>
> -static int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask,
> - unsigned long timeout, wait_queue_head_t *queue,
> - bool check_cancel)
> +static int wait_for_tpm_stat_result(struct tpm_chip *chip, u8 mask,
> + u8 mask_result, unsigned long timeout,
> + wait_queue_head_t *queue,
> + bool check_cancel)
Please do not change the function name.
/Jarkko
^ permalink raw reply
* Re: [PATCH v9 1/8] tpm: tpm_tis: Make implementation of read16, read32 and write32 optional
From: Jarkko Sakkinen @ 2020-06-01 2:23 UTC (permalink / raw)
To: amirmizi6
Cc: Eyal.Cohen, oshrialkoby85, alexander.steffen, robh+dt, peterhuewe,
christophe-h.richard, jgg, arnd, gregkh, devicetree, linux-kernel,
linux-integrity, oshri.alkoby, tmaimon77, gcwilson, kgoldman,
Dan.Morav, oren.tanami, shmulik.hager, amir.mizinski
In-Reply-To: <20200526141658.157801-2-amirmizi6@gmail.com>
Plese, write the short summary as
tpm: Make read{16, 32}() and write32() in tpm_tis_phy_ops optional
On Tue, May 26, 2020 at 05:16:51PM +0300, amirmizi6@gmail.com wrote:
> From: Amir Mizinski <amirmizi6@gmail.com>
>
> Only tpm_tis can use memory-mapped I/O, which is truly mapped into
> the kernel's memory space. Therefore, using ioread16/ioread32/iowrite32
> turns into a straightforward pointer dereference.
> Every other driver requires more complicated operations to read more than
> one byte at a time and will just fall back to read_bytes/write_bytes.
> Therefore, move this common code out of tpm_tis_spi and into tpm_tis_core
> so that it is used automatically when low-level drivers do not implement
> the specialized methods.
>
> Co-developed-by: Alexander Steffen <Alexander.Steffen@infineon.com>
> Signed-off-by: Alexander Steffen <Alexander.Steffen@infineon.com>
> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com>
> ---
> drivers/char/tpm/tpm_tis_core.h | 38 +++++++++++++++++++++++++++++++---
> drivers/char/tpm/tpm_tis_spi.h | 4 ----
> drivers/char/tpm/tpm_tis_spi_cr50.c | 3 ---
> drivers/char/tpm/tpm_tis_spi_main.c | 41 -------------------------------------
> 4 files changed, 35 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> index 7337819..d06c65b 100644
> --- a/drivers/char/tpm/tpm_tis_core.h
> +++ b/drivers/char/tpm/tpm_tis_core.h
> @@ -122,13 +122,35 @@ static inline int tpm_tis_read8(struct tpm_tis_data *data, u32 addr, u8 *result)
> static inline int tpm_tis_read16(struct tpm_tis_data *data, u32 addr,
> u16 *result)
> {
> - return data->phy_ops->read16(data, addr, result);
> + __le16 result_le;
> + int rc;
> +
> + if (data->phy_ops->read16)
> + return data->phy_ops->read16(data, addr, result);
> +
> + rc = data->phy_ops->read_bytes(data, addr, sizeof(u16),
> + (u8 *)&result_le);
> + if (!rc)
> + *result = le16_to_cpu(result_le);
> +
> + return rc;
> }
>
> static inline int tpm_tis_read32(struct tpm_tis_data *data, u32 addr,
> u32 *result)
> {
> - return data->phy_ops->read32(data, addr, result);
> + __le32 result_le;
> + int rc;
> +
> + if (data->phy_ops->read32)
> + return data->phy_ops->read32(data, addr, result);
> +
> + rc = data->phy_ops->read_bytes(data, addr, sizeof(u32),
> + (u8 *)&result_le);
> + if (!rc)
> + *result = le32_to_cpu(result_le);
> +
> + return rc;
> }
>
> static inline int tpm_tis_write_bytes(struct tpm_tis_data *data, u32 addr,
> @@ -145,7 +167,17 @@ static inline int tpm_tis_write8(struct tpm_tis_data *data, u32 addr, u8 value)
> static inline int tpm_tis_write32(struct tpm_tis_data *data, u32 addr,
> u32 value)
> {
> - return data->phy_ops->write32(data, addr, value);
> + __le32 value_le;
> + int rc;
> +
> + if (data->phy_ops->write32)
> + return data->phy_ops->write32(data, addr, value);
> +
> + value_le = cpu_to_le32(value);
> + rc = data->phy_ops->write_bytes(data, addr, sizeof(u32),
> + (u8 *)&value_le);
> +
> + return rc;
> }
>
> static inline bool is_bsw(void)
> diff --git a/drivers/char/tpm/tpm_tis_spi.h b/drivers/char/tpm/tpm_tis_spi.h
> index bba7397..d0f66f6 100644
> --- a/drivers/char/tpm/tpm_tis_spi.h
> +++ b/drivers/char/tpm/tpm_tis_spi.h
> @@ -31,10 +31,6 @@ extern int tpm_tis_spi_init(struct spi_device *spi, struct tpm_tis_spi_phy *phy,
> extern int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
> u8 *in, const u8 *out);
>
> -extern int tpm_tis_spi_read16(struct tpm_tis_data *data, u32 addr, u16 *result);
> -extern int tpm_tis_spi_read32(struct tpm_tis_data *data, u32 addr, u32 *result);
> -extern int tpm_tis_spi_write32(struct tpm_tis_data *data, u32 addr, u32 value);
> -
> #ifdef CONFIG_TCG_TIS_SPI_CR50
> extern int cr50_spi_probe(struct spi_device *spi);
> #else
> diff --git a/drivers/char/tpm/tpm_tis_spi_cr50.c b/drivers/char/tpm/tpm_tis_spi_cr50.c
> index 37d72e8..f339d20 100644
> --- a/drivers/char/tpm/tpm_tis_spi_cr50.c
> +++ b/drivers/char/tpm/tpm_tis_spi_cr50.c
> @@ -215,9 +215,6 @@ static int tpm_tis_spi_cr50_write_bytes(struct tpm_tis_data *data, u32 addr,
> static const struct tpm_tis_phy_ops tpm_spi_cr50_phy_ops = {
> .read_bytes = tpm_tis_spi_cr50_read_bytes,
> .write_bytes = tpm_tis_spi_cr50_write_bytes,
> - .read16 = tpm_tis_spi_read16,
> - .read32 = tpm_tis_spi_read32,
> - .write32 = tpm_tis_spi_write32,
> };
>
> static void cr50_print_fw_version(struct tpm_tis_data *data)
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c
> index d1754fd..95fef9d 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -152,44 +152,6 @@ static int tpm_tis_spi_write_bytes(struct tpm_tis_data *data, u32 addr,
> return tpm_tis_spi_transfer(data, addr, len, NULL, value);
> }
>
> -int tpm_tis_spi_read16(struct tpm_tis_data *data, u32 addr, u16 *result)
> -{
> - __le16 result_le;
> - int rc;
> -
> - rc = data->phy_ops->read_bytes(data, addr, sizeof(u16),
> - (u8 *)&result_le);
> - if (!rc)
> - *result = le16_to_cpu(result_le);
> -
> - return rc;
> -}
> -
> -int tpm_tis_spi_read32(struct tpm_tis_data *data, u32 addr, u32 *result)
> -{
> - __le32 result_le;
> - int rc;
> -
> - rc = data->phy_ops->read_bytes(data, addr, sizeof(u32),
> - (u8 *)&result_le);
> - if (!rc)
> - *result = le32_to_cpu(result_le);
> -
> - return rc;
> -}
> -
> -int tpm_tis_spi_write32(struct tpm_tis_data *data, u32 addr, u32 value)
> -{
> - __le32 value_le;
> - int rc;
> -
> - value_le = cpu_to_le32(value);
> - rc = data->phy_ops->write_bytes(data, addr, sizeof(u32),
> - (u8 *)&value_le);
> -
> - return rc;
> -}
> -
> int tpm_tis_spi_init(struct spi_device *spi, struct tpm_tis_spi_phy *phy,
> int irq, const struct tpm_tis_phy_ops *phy_ops)
> {
> @@ -205,9 +167,6 @@ int tpm_tis_spi_init(struct spi_device *spi, struct tpm_tis_spi_phy *phy,
> static const struct tpm_tis_phy_ops tpm_spi_phy_ops = {
> .read_bytes = tpm_tis_spi_read_bytes,
> .write_bytes = tpm_tis_spi_write_bytes,
> - .read16 = tpm_tis_spi_read16,
> - .read32 = tpm_tis_spi_read32,
> - .write32 = tpm_tis_spi_write32,
> };
>
> static int tpm_tis_spi_probe(struct spi_device *dev)
> --
> 2.7.4
Other than that looks good.
/Jarkko
>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: imx8qxp: Add ethernet alias
From: peng.fan @ 2020-06-01 2:06 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, Peng Fan
In-Reply-To: <1590977180-9957-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add ethernet alias, so bootloader code can use this to find the
primary ethernet device, and set the MAC address.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 8ce997110cd6..ff6368af7d39 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -23,6 +23,8 @@
i2c1 = &adma_i2c1;
i2c2 = &adma_i2c2;
i2c3 = &adma_i2c3;
+ ethernet0 = &fec1;
+ ethernet1 = &fec2;
gpio0 = &lsio_gpio0;
gpio1 = &lsio_gpio1;
gpio2 = &lsio_gpio2;
--
2.16.4
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: imx8qxp: add i2c aliases
From: peng.fan @ 2020-06-01 2:06 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, Peng Fan
In-Reply-To: <1590977180-9957-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The devices could be enumerated properly with aliases.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 33363c127478..8ce997110cd6 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -19,6 +19,10 @@
#size-cells = <2>;
aliases {
+ i2c0 = &adma_i2c0;
+ i2c1 = &adma_i2c1;
+ i2c2 = &adma_i2c2;
+ i2c3 = &adma_i2c3;
gpio0 = &lsio_gpio0;
gpio1 = &lsio_gpio1;
gpio2 = &lsio_gpio2;
--
2.16.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox