* [PATCH v6 0/3] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
From: Douglas Anderson @ 2020-05-13 21:58 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, airlied, daniel, robh+dt, narmstrong,
a.hajda, Laurent.pinchart, spanda
Cc: bjorn.andersson, dri-devel, swboyd, devicetree, jeffrey.l.hugo,
jernej.skrabec, linux-arm-msm, robdclark, jonas, linux-gpio,
Douglas Anderson, Krzysztof Kozlowski, Laurent Pinchart,
Paul Walmsley, linux-kernel
As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
kinda useless, at least for embedded DisplayPort (eDP). However,
despite the fact that the actual HPD pin on the bridge is mostly
useless for eDP, the concept of HPD for eDP still makes sense. It
allows us to optimize out a hardcoded delay that many panels need if
HPD isn't hooked up. Panel timing diagrams show HPD as one of the
events to measure timing from and we have to assume the worst case if
we can't actually read HPD.
One way to use HPD for eDP without using the mostly useless HPD pin on
ti-sn65dsi86 is to route the panel's HPD somewhere else in the system,
like to a GPIO. This works great because eDP panels aren't physically
hotplugged. That means the debouncing logic that caused us problems
wasn't really needed and a raw GPIO works great.
As per the above, a smart board designer would realize the value of
HPD and choose to route it to a GPIO somewhere on the board to avoid
the silly sn65dsi86 debouncing. While said "smart designer" could
theoretically route HPD anywhere on the board, a really smart designer
would realize that there are several GPIOs on the bridge itself that
are nearly useless for anything but this purpose and route HPD to one
of those.
This series of patches is intended to allow the scenario described
above.
This patch has been tested on a board that is not yet mainline. On
the hardware I have:
- Panel spec says HPD could take up to 200 ms to come up, so without
HPD hooked up we need to delay 200 ms.
- On my board the panel is powered by the same rail as the
touchscreen. By chance of probe order the touchscreen comes up
first. This means by the time we check HPD in ti_sn_bridge_enable()
it's already up. Thus we can use the panel on 200 ms earlier.
- If I measure HPD on this pane it comes up ~56 ms after the panel is
powered. This means I can save 144 ms of delay.
Side effects (though not main goals) of this series are:
- ti-sn65dsi86 GPIOs are now exported in Linux.
- ti-sn65dsi86 bindings are converted to yaml.
- Common panel bindings now have "hpd-gpios" listed.
- The simple-panel driver in Linux can delay in prepare based on
"hpd-gpios"
- ti-sn65dsi86 bindings (and current user) now specifies "no-hpd"
if HPD isn't hooked up.
Patch v6 collects tags that were sent for v5 and does the one
fix that Linus W. requested. It also drops patches that have
already landed.
Changes in v6:
- pdata->gchip.base = -1
Changes in v5:
- Use of_xlate so that numbers in dts start at 1, not 0.
- Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/
Changes in v4:
- Don't include gpio.h
- Use gpiochip_get_data() instead of container_of() to get data.
- GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
- Use Linus W's favorite syntax to read a bit from a bitfield.
- Define and use SN_GPIO_MUX_MASK.
- Add a comment about why we use a bitmap for gchip_output.
- Tacked on "or is otherwise unusable." to description.
Changes in v3:
- Becaue => Because
- Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
- More comments about how powering off affects us (get_dir, dir_input).
- Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
- Use a bitmap rather than rolling my own.
- useful implement => useful to implement
Changes in v2:
- ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
- specification => specifier.
- power up => power.
- Added back missing suspend-gpios.
- data-lanes and lane-polarities are are the right place now.
- endpoints don't need to be patternProperties.
- Specified more details for data-lanes and lane-polarities.
- Added old example back in, fixing bugs in it.
- Example i2c bus is just called "i2c", not "i2c1" now.
- ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
Douglas Anderson (3):
drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
.../bindings/display/bridge/ti,sn65dsi86.txt | 87 ------
.../bindings/display/bridge/ti,sn65dsi86.yaml | 293 ++++++++++++++++++
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 215 +++++++++++++
3 files changed, 508 insertions(+), 87 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
--
2.26.2.645.ge9eca65c58-goog
^ permalink raw reply
* [PATCH v6 1/3] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
From: Douglas Anderson @ 2020-05-13 21:59 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, airlied, daniel, robh+dt, narmstrong,
a.hajda, Laurent.pinchart, spanda
Cc: bjorn.andersson, dri-devel, swboyd, devicetree, jeffrey.l.hugo,
jernej.skrabec, linux-arm-msm, robdclark, jonas, linux-gpio,
Douglas Anderson, linux-kernel
In-Reply-To: <20200513215902.261547-1-dianders@chromium.org>
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system. Each pin can be configured as input,
output, or a special function for the bridge chip. These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM
Let's expose these pins as GPIOs. A few notes:
- Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
- These pins can't be configured for IRQ.
- There are no programmable pulls or other fancy features.
- Keeping the bridge chip powered might be expensive. The driver is
setup such that if all used GPIOs are only inputs we'll power the
bridge chip on just long enough to read the GPIO and then power it
off again. Setting a GPIO as output will keep the bridge powered.
- If someone releases a GPIO we'll implicitly switch it to an input so
we no longer need to keep the bridge powered for it.
Because of all of the above limitations we just need to implement a
bare-bones GPIO driver. The device tree bindings already account for
this device being a GPIO controller so we only need the driver changes
for it.
NOTE: Despite the fact that these pins are nominally muxable I don't
believe it makes sense to expose them through the pinctrl interface as
well as the GPIO interface. The special functions are things that the
bridge chip driver itself would care about and it can just configure
the pins as needed.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v6:
- pdata->gchip.base = -1
Changes in v5:
- Use of_xlate so that numbers in dts start at 1, not 0.
Changes in v4:
- Don't include gpio.h
- Use gpiochip_get_data() instead of container_of() to get data.
- GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
- Use Linus W's favorite syntax to read a bit from a bitfield.
- Define and use SN_GPIO_MUX_MASK.
- Add a comment about why we use a bitmap for gchip_output.
Changes in v3:
- Becaue => Because
- Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
- More comments about how powering off affects us (get_dir, dir_input).
- Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
- Use a bitmap rather than rolling my own.
Changes in v2:
- ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 215 ++++++++++++++++++++++++++
1 file changed, 215 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6ad688b320ae..3b91fa0ebdf9 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -4,9 +4,11 @@
* datasheet: http://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
*/
+#include <linux/bits.h>
#include <linux/clk.h>
#include <linux/debugfs.h>
#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
#include <linux/i2c.h>
#include <linux/iopoll.h>
#include <linux/module.h>
@@ -54,6 +56,14 @@
#define BPP_18_RGB BIT(0)
#define SN_HPD_DISABLE_REG 0x5C
#define HPD_DISABLE BIT(0)
+#define SN_GPIO_IO_REG 0x5E
+#define SN_GPIO_INPUT_SHIFT 4
+#define SN_GPIO_OUTPUT_SHIFT 0
+#define SN_GPIO_CTRL_REG 0x5F
+#define SN_GPIO_MUX_INPUT 0
+#define SN_GPIO_MUX_OUTPUT 1
+#define SN_GPIO_MUX_SPECIAL 2
+#define SN_GPIO_MUX_MASK 0x3
#define SN_AUX_WDATA_REG(x) (0x64 + (x))
#define SN_AUX_ADDR_19_16_REG 0x74
#define SN_AUX_ADDR_15_8_REG 0x75
@@ -88,6 +98,35 @@
#define SN_REGULATOR_SUPPLY_NUM 4
+#define SN_NUM_GPIOS 4
+#define SN_GPIO_PHYSICAL_OFFSET 1
+
+/**
+ * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
+ * @dev: Pointer to our device.
+ * @regmap: Regmap for accessing i2c.
+ * @aux: Our aux channel.
+ * @bridge: Our bridge.
+ * @connector: Our connector.
+ * @debugfs: Used for managing our debugfs.
+ * @host_node: Remote DSI node.
+ * @dsi: Our MIPI DSI source.
+ * @refclk: Our reference clock.
+ * @panel: Our panel.
+ * @enable_gpio: The GPIO we toggle to enable the bridge.
+ * @supplies: Data for bulk enabling/disabling our regulators.
+ * @dp_lanes: Count of dp_lanes we're using.
+ *
+ * @gchip: If we expose our GPIOs, this is used.
+ * @gchip_output: A cache of whether we've set GPIOs to output. This
+ * serves double-duty of keeping track of the direction and
+ * also keeping track of whether we've incremented the
+ * pm_runtime reference count for this pin, which we do
+ * whenever a pin is configured as an output. This is a
+ * bitmap so we can do atomic ops on it without an extra
+ * lock so concurrent users of our 4 GPIOs don't stomp on
+ * each other's read-modify-write.
+ */
struct ti_sn_bridge {
struct device *dev;
struct regmap *regmap;
@@ -102,6 +141,9 @@ struct ti_sn_bridge {
struct gpio_desc *enable_gpio;
struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM];
int dp_lanes;
+
+ struct gpio_chip gchip;
+ DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
};
static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
@@ -874,6 +916,173 @@ static int ti_sn_bridge_parse_dsi_host(struct ti_sn_bridge *pdata)
return 0;
}
+static int tn_sn_bridge_of_xlate(struct gpio_chip *chip,
+ const struct of_phandle_args *gpiospec,
+ u32 *flags)
+{
+ if (WARN_ON(gpiospec->args_count < chip->of_gpio_n_cells))
+ return -EINVAL;
+
+ if (gpiospec->args[0] > chip->ngpio || gpiospec->args[0] < 1)
+ return -EINVAL;
+
+ if (flags)
+ *flags = gpiospec->args[1];
+
+ return gpiospec->args[0] - SN_GPIO_PHYSICAL_OFFSET;
+}
+
+static int ti_sn_bridge_gpio_get_direction(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
+
+ /*
+ * We already have to keep track of the direction because we use
+ * that to figure out whether we've powered the device. We can
+ * just return that rather than (maybe) powering up the device
+ * to ask its direction.
+ */
+ return test_bit(offset, pdata->gchip_output) ?
+ GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
+}
+
+static int ti_sn_bridge_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
+ unsigned int val;
+ int ret;
+
+ /*
+ * When the pin is an input we don't forcibly keep the bridge
+ * powered--we just power it on to read the pin. NOTE: part of
+ * the reason this works is that the bridge defaults (when
+ * powered back on) to all 4 GPIOs being configured as GPIO input.
+ * Also note that if something else is keeping the chip powered the
+ * pm_runtime functions are lightweight increments of a refcount.
+ */
+ pm_runtime_get_sync(pdata->dev);
+ ret = regmap_read(pdata->regmap, SN_GPIO_IO_REG, &val);
+ pm_runtime_put(pdata->dev);
+
+ if (ret)
+ return ret;
+
+ return !!(val & BIT(SN_GPIO_INPUT_SHIFT + offset));
+}
+
+static void ti_sn_bridge_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+ struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
+ int ret;
+
+ if (!test_bit(offset, pdata->gchip_output)) {
+ dev_err(pdata->dev, "Ignoring GPIO set while input\n");
+ return;
+ }
+
+ val &= 1;
+ ret = regmap_update_bits(pdata->regmap, SN_GPIO_IO_REG,
+ BIT(SN_GPIO_OUTPUT_SHIFT + offset),
+ val << (SN_GPIO_OUTPUT_SHIFT + offset));
+}
+
+static int ti_sn_bridge_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
+ int shift = offset * 2;
+ int ret;
+
+ if (!test_and_clear_bit(offset, pdata->gchip_output))
+ return 0;
+
+ ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,
+ SN_GPIO_MUX_MASK << shift,
+ SN_GPIO_MUX_INPUT << shift);
+ if (ret) {
+ set_bit(offset, pdata->gchip_output);
+ return ret;
+ }
+
+ /*
+ * NOTE: if nobody else is powering the device this may fully power
+ * it off and when it comes back it will have lost all state, but
+ * that's OK because the default is input and we're now an input.
+ */
+ pm_runtime_put(pdata->dev);
+
+ return 0;
+}
+
+static int ti_sn_bridge_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int val)
+{
+ struct ti_sn_bridge *pdata = gpiochip_get_data(chip);
+ int shift = offset * 2;
+ int ret;
+
+ if (test_and_set_bit(offset, pdata->gchip_output))
+ return 0;
+
+ pm_runtime_get_sync(pdata->dev);
+
+ /* Set value first to avoid glitching */
+ ti_sn_bridge_gpio_set(chip, offset, val);
+
+ /* Set direction */
+ ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,
+ SN_GPIO_MUX_MASK << shift,
+ SN_GPIO_MUX_OUTPUT << shift);
+ if (ret) {
+ clear_bit(offset, pdata->gchip_output);
+ pm_runtime_put(pdata->dev);
+ }
+
+ return ret;
+}
+
+static void ti_sn_bridge_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+ /* We won't keep pm_runtime if we're input, so switch there on free */
+ ti_sn_bridge_gpio_direction_input(chip, offset);
+}
+
+static const char * const ti_sn_bridge_gpio_names[SN_NUM_GPIOS] = {
+ "GPIO1", "GPIO2", "GPIO3", "GPIO4"
+};
+
+static int ti_sn_setup_gpio_controller(struct ti_sn_bridge *pdata)
+{
+ int ret;
+
+ /* Only init if someone is going to use us as a GPIO controller */
+ if (!of_property_read_bool(pdata->dev->of_node, "gpio-controller"))
+ return 0;
+
+ pdata->gchip.label = dev_name(pdata->dev);
+ pdata->gchip.parent = pdata->dev;
+ pdata->gchip.owner = THIS_MODULE;
+ pdata->gchip.of_xlate = tn_sn_bridge_of_xlate;
+ pdata->gchip.of_gpio_n_cells = 2;
+ pdata->gchip.free = ti_sn_bridge_gpio_free;
+ pdata->gchip.get_direction = ti_sn_bridge_gpio_get_direction;
+ pdata->gchip.direction_input = ti_sn_bridge_gpio_direction_input;
+ pdata->gchip.direction_output = ti_sn_bridge_gpio_direction_output;
+ pdata->gchip.get = ti_sn_bridge_gpio_get;
+ pdata->gchip.set = ti_sn_bridge_gpio_set;
+ pdata->gchip.can_sleep = true;
+ pdata->gchip.names = ti_sn_bridge_gpio_names;
+ pdata->gchip.ngpio = SN_NUM_GPIOS;
+ pdata->gchip.base = -1;
+ ret = devm_gpiochip_add_data(pdata->dev, &pdata->gchip, pdata);
+ if (ret)
+ dev_err(pdata->dev, "can't add gpio chip\n");
+
+ return ret;
+}
+
static int ti_sn_bridge_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -937,6 +1146,12 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
pm_runtime_enable(pdata->dev);
+ ret = ti_sn_setup_gpio_controller(pdata);
+ if (ret) {
+ pm_runtime_disable(pdata->dev);
+ return ret;
+ }
+
i2c_set_clientdata(client, pdata);
pdata->aux.name = "ti-sn65dsi86-aux";
--
2.26.2.645.ge9eca65c58-goog
^ permalink raw reply related
* [PATCH v6 2/3] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
From: Douglas Anderson @ 2020-05-13 21:59 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, airlied, daniel, robh+dt, narmstrong,
a.hajda, Laurent.pinchart, spanda
Cc: bjorn.andersson, dri-devel, swboyd, devicetree, jeffrey.l.hugo,
jernej.skrabec, linux-arm-msm, robdclark, jonas, linux-gpio,
Douglas Anderson, Krzysztof Kozlowski, Laurent Pinchart,
Paul Walmsley, linux-kernel
In-Reply-To: <20200513215902.261547-1-dianders@chromium.org>
This moves the bindings over, based a lot on toshiba,tc358768.yaml.
Unless there's someone known to be better, I've set the maintainer in
the yaml as the first person to submit bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
I removed Stephen's review tag on v5 since I squashed in a bunch of
other stuff.
Changes in v6: None
Changes in v5:
- Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/
Changes in v4: None
Changes in v3: None
Changes in v2:
- specification => specifier.
- power up => power.
- Added back missing suspend-gpios.
- data-lanes and lane-polarities are are the right place now.
- endpoints don't need to be patternProperties.
- Specified more details for data-lanes and lane-polarities.
- Added old example back in, fixing bugs in it.
- Example i2c bus is just called "i2c", not "i2c1" now.
.../bindings/display/bridge/ti,sn65dsi86.txt | 87 ------
.../bindings/display/bridge/ti,sn65dsi86.yaml | 285 ++++++++++++++++++
2 files changed, 285 insertions(+), 87 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
deleted file mode 100644
index 8ec4a7f2623a..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-SN65DSI86 DSI to eDP bridge chip
---------------------------------
-
-This is the binding for Texas Instruments SN65DSI86 bridge.
-http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
-
-Required properties:
-- compatible: Must be "ti,sn65dsi86"
-- reg: i2c address of the chip, 0x2d as per datasheet
-- enable-gpios: gpio specification for bridge_en pin (active high)
-
-- vccio-supply: A 1.8V supply that powers up the digital IOs.
-- vpll-supply: A 1.8V supply that powers up the displayport PLL.
-- vcca-supply: A 1.2V supply that powers up the analog circuits.
-- vcc-supply: A 1.2V supply that powers up the digital core.
-
-Optional properties:
-- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
-
-- gpio-controller: Marks the device has a GPIO controller.
-- #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify flags.
- See ../../gpio/gpio.txt for more information.
-- #pwm-cells : Should be one. See ../../pwm/pwm.yaml for description of
- the cell formats.
-
-- clock-names: should be "refclk"
-- clocks: Specification for input reference clock. The reference
- clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
-
-- data-lanes: See ../../media/video-interface.txt
-- lane-polarities: See ../../media/video-interface.txt
-
-- suspend-gpios: specification for GPIO1 pin on bridge (active low)
-
-Required nodes:
-This device has two video ports. Their connections are modelled using the
-OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for DSI input
-- Video port 1 for eDP output
-
-Example
--------
-
-edp-bridge@2d {
- compatible = "ti,sn65dsi86";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x2d>;
-
- enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
- suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>;
-
- interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>;
-
- vccio-supply = <&pm8916_l17>;
- vcca-supply = <&pm8916_l6>;
- vpll-supply = <&pm8916_l17>;
- vcc-supply = <&pm8916_l6>;
-
- clock-names = "refclk";
- clocks = <&input_refclk>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- edp_bridge_in: endpoint {
- remote-endpoint = <&dsi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- edp_bridge_out: endpoint {
- data-lanes = <2 1 3 0>;
- lane-polarities = <0 1 0 1>;
- remote-endpoint = <&edp_panel_in>;
- };
- };
- };
-}
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
new file mode 100644
index 000000000000..07d26121afca
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -0,0 +1,285 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi86.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI86 DSI to eDP bridge chip
+
+maintainers:
+ - Sandeep Panda <spanda@codeaurora.org>
+
+description: |
+ The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP.
+ http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
+
+properties:
+ compatible:
+ const: ti,sn65dsi86
+
+ reg:
+ const: 0x2d
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO specifier for bridge_en pin (active high).
+
+ suspend-gpios:
+ maxItems: 1
+ description: GPIO specifier for GPIO1 pin on bridge (active low).
+
+ vccio-supply:
+ description: A 1.8V supply that powers the digital IOs.
+
+ vpll-supply:
+ description: A 1.8V supply that powers the DisplayPort PLL.
+
+ vcca-supply:
+ description: A 1.2V supply that powers the analog circuits.
+
+ vcc-supply:
+ description: A 1.2V supply that powers the digital core.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ Clock specifier for input reference clock. The reference clock rate must
+ be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+ clock-names:
+ const: refclk
+
+ gpio-controller: true
+ '#gpio-cells':
+ const: 2
+ description:
+ First cell is pin number, second cell is flags. GPIO pin numbers are
+ 1-based to match the datasheet. See ../../gpio/gpio.txt for more
+ information.
+
+ '#pwm-cells':
+ const: 1
+ description: See ../../pwm/pwm.yaml for description of the cell formats.
+
+ ports:
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ port@0:
+ type: object
+ additionalProperties: false
+
+ description:
+ Video port for MIPI DSI input
+
+ properties:
+ reg:
+ const: 0
+
+ endpoint:
+ type: object
+ additionalProperties: false
+ properties:
+ remote-endpoint: true
+
+ required:
+ - reg
+
+ port@1:
+ type: object
+ additionalProperties: false
+
+ description:
+ Video port for eDP output (panel or connector).
+
+ properties:
+ reg:
+ const: 1
+
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ remote-endpoint: true
+
+ data-lanes:
+ oneOf:
+ - minItems: 1
+ maxItems: 1
+ uniqueItems: true
+ items:
+ enum:
+ - 0
+ - 1
+ description:
+ If you have 1 logical lane the bridge supports routing
+ to either port 0 or port 1. Port 0 is suggested.
+ See ../../media/video-interface.txt for details.
+
+ - minItems: 2
+ maxItems: 2
+ uniqueItems: true
+ items:
+ enum:
+ - 0
+ - 1
+ description:
+ If you have 2 logical lanes the bridge supports
+ reordering but only on physical ports 0 and 1.
+ See ../../media/video-interface.txt for details.
+
+ - minItems: 4
+ maxItems: 4
+ uniqueItems: true
+ items:
+ enum:
+ - 0
+ - 1
+ - 2
+ - 3
+ description:
+ If you have 4 logical lanes the bridge supports
+ reordering in any way.
+ See ../../media/video-interface.txt for details.
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum:
+ - 0
+ - 1
+ description: See ../../media/video-interface.txt
+
+ dependencies:
+ lane-polarities: [data-lanes]
+
+ required:
+ - reg
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - vccio-supply
+ - vpll-supply
+ - vcca-supply
+ - vcc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2d {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2d>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+
+ enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
+
+ vpll-supply = <&src_pp1800_s4a>;
+ vccio-supply = <&src_pp1800_s4a>;
+ vcca-supply = <&src_pp1200_l2a>;
+ vcc-supply = <&src_pp1200_l2a>;
+
+ clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
+ clock-names = "refclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2d {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2d>;
+
+ enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
+ suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>;
+
+ interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>;
+
+ vccio-supply = <&pm8916_l17>;
+ vcca-supply = <&pm8916_l6>;
+ vpll-supply = <&pm8916_l17>;
+ vcc-supply = <&pm8916_l6>;
+
+ clock-names = "refclk";
+ clocks = <&input_refclk>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ edp_bridge_out: endpoint {
+ data-lanes = <2 1 3 0>;
+ lane-polarities = <0 1 0 1>;
+ remote-endpoint = <&edp_panel_in>;
+ };
+ };
+ };
+ };
+ };
--
2.26.2.645.ge9eca65c58-goog
^ permalink raw reply related
* [PATCH v6 3/3] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
From: Douglas Anderson @ 2020-05-13 21:59 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, airlied, daniel, robh+dt, narmstrong,
a.hajda, Laurent.pinchart, spanda
Cc: bjorn.andersson, dri-devel, swboyd, devicetree, jeffrey.l.hugo,
jernej.skrabec, linux-arm-msm, robdclark, jonas, linux-gpio,
Douglas Anderson, Laurent Pinchart, linux-kernel
In-Reply-To: <20200513215902.261547-1-dianders@chromium.org>
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware. Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for knowing when the panel is ready, not for
detecting physical plug events.
Currently the driver in Linux just assumes that nobody has HPD hooked
up. It relies on folks setting the "no-hpd" property in the panel
node to specify that HPD isn't hooked up and then the panel driver
using this to add some worst case delays when turning on the panel.
Apparently it's also useful to specify "no-hpd" in the bridge node so
that the bridge driver can make sure it's doing the right thing
without peeking into the panel [1]. This would be used if anyone ever
found it useful to implement support for the HW HPD pin on the bridge.
Let's add this property to the bindings.
NOTES:
- This is somewhat of a backward-incompatible change. All current
known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
bridge node yet none of them had HPD hooked up. This worked because
the current Linux driver just assumed that HPD was never hooked up.
We could make it less incompatible by saying that for this bridge
it's assumed HPD isn't hooked up _unless_ a property is defined, but
"no-hpd" is much more standard and it's unlikely to matter unless
someone quickly goes and implements HPD in the driver.
- It is sensible to specify "no-hpd" at the bridge chip level and
specify "hpd-gpios" at the panel level. That would mean HPD is
hooked up to some other GPIO in the system, just not the hardware
HPD pin on the bridge chip.
[1] https://lore.kernel.org/r/20200417180819.GE5861@pendragon.ideasonboard.com
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes in v6: None
Changes in v5: None
Changes in v4:
- Tacked on "or is otherwise unusable." to description.
Changes in v3:
- useful implement => useful to implement
Changes in v2:
- ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
.../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 07d26121afca..be10e8cf31e1 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -28,6 +28,12 @@ properties:
maxItems: 1
description: GPIO specifier for GPIO1 pin on bridge (active low).
+ no-hpd:
+ type: boolean
+ description:
+ Set if the HPD line on the bridge isn't hooked up to anything or is
+ otherwise unusable.
+
vccio-supply:
description: A 1.8V supply that powers the digital IOs.
@@ -213,6 +219,8 @@ examples:
clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
clock-names = "refclk";
+ no-hpd;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.26.2.645.ge9eca65c58-goog
^ permalink raw reply related
* Re: [RFC PATCH V4 0/4] media: platform: Add support for Face Detection (FD) on mt8183 SoC
From: Tomasz Figa @ 2020-05-13 21:45 UTC (permalink / raw)
To: Jerry-ch Chen
Cc: hans.verkuil@cisco.com, laurent.pinchart+renesas@ideasonboard.com,
matthias.bgg@gmail.com, mchehab@kernel.org, pihsun@chromium.org,
yuzhao@chromium.org, zwisler@chromium.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Sean Cheng (鄭昇弘),
Sj Huang (黃信璋),
Christie Yu (游雅惠),
Frederic Chen (陳俊元),
Jungo Lin (林明俊), linux-media@vger.kernel.org,
srv_heupstream, devicetree@vger.kernel.org
In-Reply-To: <1588903371.16825.14.camel@mtksdccf07>
Hi Jerry,
On Fri, May 8, 2020 at 4:03 AM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
>
> Hi Laurent, Tomasz, Matthias,
>
> gentle ping for this patch set,
> If no new comments, I would like to send a newer version.
>
Sorry, I still haven't had a chance to look at the series, so feel
free to send a new version and I will take a look at the new one.
Best regards,
Tomasz
> Thanks and Best Regards,
> Jerry
>
> On Wed, 2019-12-04 at 20:47 +0800, Jerry-ch Chen wrote:
> > Hello,
> >
> > This RFC patch series is adding Face Detection (FD) driver on Mediatek
> > mt8183 SoC. It belongs to the first Mediatek's camera driver series based
> > on V4L2 and media controller framework. I posted the main part of the FD
> > driver as RFC to discuss first and would like some review comments.
> >
> > ==============
> > Introduction
> > ==============
> >
> > Face Detection (FD) unit provides hardware accelerated face detection
> > feature. It can detect different sizes of faces in a given image.
> >
> > The driver is implemented as a normal V4L2 memory-to-memory device and
> > supports V4L2 controls for detection settings. It has two buffer queues.
> >
> > 1. Video output buffer: RAW image for face detection.
> >
> > 2. Meta capture buffer: Result of the detected faces.
> >
> > ==================
> > Changes in v4
> > ==================
> >
> > RFC v4 includes the following modification:
> > 1. Includes v4l2-mem2mem changes: add v4l2_m2m_suspend, v4l2_m2m_resume
> >
> > 2. Move FD V4L2 control ids back inside FD driver
> >
> > 3. Depend on newer SCP driver api
> >
> > 4. Add exit hw flow for FD driver
> >
> > 5. Add hardware timeout handling in the FD firmware
> >
> > 6. Move allocation of dma buffer from connect / disconnect to driver probe
> > / remove
> >
> > Todo:
> > - Add v4l2 control menus for private mtk fd control
> > ==================
> > Changes in v3
> > ==================
> >
> > RFC v3 includes the following modification:
> > 1. Adjust the private control ids and place them in
> > include/uapi/linux/mtk-fd-v4l2-controls.h
> >
> > 2. Merge struct mtk_fd_hw info struct mtk_fd_dev
> >
> > 3. Define FD meta capture buffer in include/uapi/linux/videodev2.h
> >
> > 4. Remove the usage of get_reserved_memory by scp driver,
> > use dma_alloc api instead
> >
> > Todo:
> > - Add v4l2 control menus for private mtk fd control
> > - Refine the job finish flow when system suspend
> > ==================
> > Changes in v2
> > ==================
> >
> > RFC v2 includes the following modification:
> > 1. Implement FD as a V4L2 mem2mem driver
> >
> > 2. Replace meta input with V4L2 controls
> >
> > ==================
> > Changes in v1
> > ==================
> >
> > RFC v1 includes the following modification:
> > 1. Uses Request API instead of FD's buffer collection design
> >
> > 2. removed unnecessary abstraction structurally, including mtk_fd_ctx and
> > related ops
> >
> > 3. removed the fd_smem node from device tree
> >
> > 4. Fixed the common issues Tomasz commented on Mediatek ISP Pass 1's RFC v0
> > patch series
> >
> > ==================
> > Dependent patch
> > ==================
> >
> > FD driver depends on SCP driver. The patches are as following:
> >
> > [1]. Add support for mt8183 SCP
> > https://patchwork.kernel.org/cover/1152350/
> >
> > ==================
> > Compliance test
> > ==================
> >
> > * Version: https://git.linuxtv.org/v4l-utils.git/commit/?id=b16f9e945d74aa5
> > * Note: Some failures are caused by the implementation of FD driver,
> > whic is a m2m device with VIDEO_OUT and META_CAPTURE queues,
> > therefore we can't set V4L2_CAP_VIDEO_M2M in device capability, and
> > fail in some non-m2m v4l2 test cases.
> > * Test command: v4l2-compliance -m 2
> > * test output:
> >
> > v4l2-compliance SHA: not available, 32 bits
> >
> > Compliance test for mtk-fd-4.0 device /dev/media2:
> >
> > Media Driver Info:
> > Driver name : mtk-fd-4.0
> > Model : mtk-fd-4.0
> > Serial :
> > Bus info : platform:1502b000.fd
> > Media version : 4.19.84
> > Hardware revision: 0x00000000 (0)
> > Driver version : 4.19.84
> >
> > Required ioctls:
> > test MEDIA_IOC_DEVICE_INFO: OK
> >
> > Allow for multiple opens:
> > test second /dev/media2 open: OK
> > test MEDIA_IOC_DEVICE_INFO: OK
> > test for unlimited opens: OK
> >
> > Media Controller ioctls:
> > test MEDIA_IOC_G_TOPOLOGY: OK
> > Entities: 3 Interfaces: 1 Pads: 4 Links: 4
> > test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
> > test MEDIA_IOC_SETUP_LINK: OK
> >
> > Total for mtk-fd-4.0 device /dev/media2: 7, Succeeded: 7, Failed: 0, Warnings: 0
> > --------------------------------------------------------------------------------
> > Compliance test for mtk-fd-4.0 device /dev/video32:
> >
> > Driver Info:
> > Driver name : mtk-fd-4.0
> > Card type : mtk-fd-4.0
> > Bus info : platform:1502b000.fd
> > Driver version : 4.19.84
> > Capabilities : 0x84a02000
> > Video Output Multiplanar
> > Metadata Capture
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04a02000
> > Video Output Multiplanar
> > Metadata Capture
> > Streaming
> > Extended Pix Format
> > Media Driver Info:
> > Driver name : mtk-fd-4.0
> > Model : mtk-fd-4.0
> > Serial :
> > Bus info : platform:1502b000.fd
> > Media version : 4.19.84
> > Hardware revision: 0x00000000 (0)
> > Driver version : 4.19.84
> > Interface Info:
> > ID : 0x0300000c
> > Type : V4L Video
> > Entity Info:
> > ID : 0x00000001 (1)
> > Name : mtk-fd-4.0-source
> > Function : V4L2 I/O
> > Pad 0x01000002 : 0: Source
> > Link 0x02000008: to remote pad 0x1000005 of entity 'mtk-fd-4.0-proc': Data, Enabled, Immutable
> >
> > Required ioctls:
> > test MC information (see 'Media Driver Info' above): OK
> > fail: v4l2-compliance.cpp(668): dcaps & output_caps
> > test VIDIOC_QUERYCAP: FAIL
> >
> > Allow for multiple opens:
> > test second /dev/video32 open: OK
> > fail: v4l2-compliance.cpp(668): dcaps & output_caps
> > test VIDIOC_QUERYCAP: FAIL
> > test VIDIOC_G/S_PRIORITY: OK
> > test for unlimited opens: OK
> >
> > Debug ioctls:
> > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > test VIDIOC_LOG_STATUS: OK (Not Supported)
> >
> > Input ioctls:
> > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> > test VIDIOC_ENUMAUDIO: OK (Not Supported)
> > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 0 Audio Inputs: 0 Tuners: 0
> >
> > Output ioctls:
> > test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> > Outputs: 0 Audio Outputs: 0 Modulators: 0
> >
> > Input/Output configuration ioctls:
> > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> > test VIDIOC_G/S_EDID: OK (Not Supported)
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> > test VIDIOC_QUERYCTRL: OK
> > test VIDIOC_G/S_CTRL: OK
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 1 Private Controls: 6
> >
> > Format ioctls:
> > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> > test VIDIOC_G/S_PARM: OK (Not Supported)
> > test VIDIOC_G_FBUF: OK (Not Supported)
> > fail: v4l2-test-formats.cpp(457): pixelformat 00000000 () for buftype 10 not reported by ENUM_FMT
> > test VIDIOC_G_FMT: FAIL
> > fail: v4l2-test-formats.cpp(457): pixelformat 00000000 () for buftype 10 not reported by ENUM_FMT
> > test VIDIOC_TRY_FMT: FAIL
> > fail: v4l2-test-formats.cpp(457): pixelformat ffffffff (-BE) for buftype 10 not reported by ENUM_FMT
> > test VIDIOC_S_FMT: FAIL
> > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > test Cropping: OK (Not Supported)
> > test Composing: OK (Not Supported)
> > test Scaling: OK (Not Supported)
> >
> > Codec ioctls:
> > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> > test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >
> > Buffer ioctls:
> > fail: v4l2-test-buffers.cpp(667): q2.reqbufs(node->node2, 1) != EBUSY
> > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
> > test VIDIOC_EXPBUF: OK
> > test Requests: OK
> >
> > Total for mtk-fd-4.0 device /dev/video32: 45, Succeeded: 39, Failed: 6, Warnings: 0
> >
> > Grand Total for mtk-fd-4.0 device /dev/media2: 52, Succeeded: 46, Failed: 6, Warnings: 0
> >
>
^ permalink raw reply
* [PATCH v3 0/5] Add support for PinePhone LCD panel
From: Ondrej Jirman @ 2020-05-13 21:24 UTC (permalink / raw)
To: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng
Cc: Ondrej Jirman, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, Samuel Holland, Martijn Braam, Luca Weiss,
Bhushan Shah
This patchset adds support for the LCD panel of PinePhone.
The first 3 patches are for the panel itself, and the last 2 patches are
for enabling it on PinePhone.
I've tested this on PinePhone 1.0 and 1.2.
Please take a look.
thank you and regards,
Ondrej Jirman
Changes in v3:
- Panel driver renamed to the name of the LCD controller
- Re-organize the driver slightly to more easily support more panels
based on the same controller.
- Add patch to enable the touchscreen to complete the LCD support
on PinePhone.
- Dropped the "DSI fix" patch (the driver seems to work for me without it)
- Improved brightness levels handling:
- PinePhone 1.0 uses default levels generated by the driver
- On PinePhone 1.1 duty cycles < 20% lead to black screen, so
default levels can't be used. Martijn Braam came up with a
list of duty cycle values that lead to perception of linear
brigtness level <-> light intensity on PinePhone 1.1
- There was some feedback on v2 about this being similar to st7701.
It's only similar in name. Most of the "user commands" are different,
so I opted to keep this in a new driver instead of creating st770x.
Anyone who likes to check the differences, here are datasheets:
- https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf
- https://megous.com/dl/tmp/ST7701.pdf
Changes in v2:
- DT Example fix.
- DT Format fix.
- Raised copyright info to 2020.
- Sort panel operation functions.
- Sort inclusion.
-- For phone owners: --
There's an open question on how to set the backlight brightness values
on post 1.0 revision phone, since lower duty cycles (< 10-20%) lead
to backlight being black. It would be nice if more people can test
the various backlight levels on 1.1 and 1.2 revision with this change
in dts:
brightness-levels = <0 1000>;
num-interpolated-steps = <1000>;
and report at what brightness level the backlight turns on. So far it
seems this has a wide range. Lowest useable duty cycle for me is ~7%
on 1.2 and for Martijn ~20% on 1.1.
Icenowy Zheng (4):
dt-bindings: vendor-prefixes: Add Xingbangda
dt-bindings: panel: Add binding for Xingbangda XBD599 panel
drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
Ondrej Jirman (1):
arm64: dts: sun50i-a64-pinephone: Add touchscreen support
.../display/panel/sitronix,st7703.yaml | 63 +++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
.../allwinner/sun50i-a64-pinephone-1.1.dts | 19 +
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 54 +++
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 386 ++++++++++++++++++
7 files changed, 535 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7703.yaml
create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
--
2.26.2
^ permalink raw reply
* [PATCH v3 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
From: Ondrej Jirman @ 2020-05-13 21:24 UTC (permalink / raw)
To: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
Samuel Holland, Martijn Braam, Luca Weiss, Bhushan Shah,
Ondrej Jirman
In-Reply-To: <20200513212451.1919013-1-megous@megous.com>
From: Icenowy Zheng <icenowy@aosc.io>
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
It is based on Sitronix ST7703 LCD controller.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 386 ++++++++++++++++++
3 files changed, 397 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..b7bc157b0612 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -395,6 +395,16 @@ config DRM_PANEL_SITRONIX_ST7701
ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
system interfaces.
+config DRM_PANEL_SITRONIX_ST7703
+ tristate "Sitronix ST7703 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Sitronix
+ ST7703 controller for 720X1440 LCD panels with MIPI/RGB/SPI
+ system interfaces.
+
config DRM_PANEL_SITRONIX_ST7789V
tristate "Sitronix ST7789V panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..47f4789a8685 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
+obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
new file mode 100644
index 000000000000..092dd73c86d0
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -0,0 +1,386 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DRM driver for Sitronix ST7703 MIPI DSI panel
+ *
+ * Copyright (C) 2020 Ondrej Jirman <megous@megous.com>
+ * Copyright (C) 2019-2020 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ 0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+struct st7703_panel_desc {
+ const struct drm_display_mode *mode;
+ unsigned int lanes;
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ const char *const *supply_names;
+ unsigned int num_supplies;
+};
+
+struct st7703 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data *supplies;
+ const struct st7703_panel_desc *desc;
+ bool prepared;
+};
+
+static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
+{
+ return container_of(panel, struct st7703, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret; \
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0) \
+ return ret; \
+ } while (0)
+
+static int st7703_init_sequence(struct st7703 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+ * Init sequence was supplied by the panel vendor.
+ */
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
+ 0x00, 0x00, 0x37);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
+ 0x25, 0x22, 0x20, 0x03);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
+ 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
+ 0x00, 0x00);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
+ 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70,
+ 0x00);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0xF0);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ,
+ 0x00, 0x00, 0x0B, 0x0B, 0x10, 0x10, 0x00, 0x00,
+ 0x00, 0x00, 0xFF, 0x00, 0xC0, 0x10);
+ dsi_dcs_write_seq(dsi, 0xC6, 0x01, 0x00, 0xFF, 0xFF, 0x00);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER,
+ 0x74, 0x00, 0x32, 0x32, 0x77, 0xF1, 0xFF, 0xFF,
+ 0xCC, 0xCC, 0x77, 0x77);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x07, 0x07);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x2C, 0x2C);
+ dsi_dcs_write_seq(dsi, 0xBF, 0x02, 0x11, 0x00);
+
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1,
+ 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12,
+ 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
+ 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00,
+ 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88,
+ 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64,
+ 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
+ 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2,
+ 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88,
+ 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13,
+ 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
+ 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A,
+ 0xA5, 0x00, 0x00, 0x00, 0x00);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA,
+ 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35,
+ 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12,
+ 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41,
+ 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12,
+ 0x12, 0x18);
+ msleep(20);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
+ return ret;
+ }
+ msleep(250);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret)
+ return ret;
+ msleep(50);
+
+ DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
+ return 0;
+}
+
+static int st7703_prepare(struct drm_panel *panel)
+{
+ struct st7703 *ctx = panel_to_st7703(panel);
+ int ret;
+
+ if (ctx->prepared)
+ return 0;
+
+ ret = regulator_bulk_enable(ctx->desc->num_supplies, ctx->supplies);
+ if (ret)
+ return ret;
+
+ DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel\n");
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(20, 40);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(20);
+
+ ctx->prepared = true;
+
+ return 0;
+}
+
+static int st7703_enable(struct drm_panel *panel)
+{
+ struct st7703 *ctx = panel_to_st7703(panel);
+ int ret;
+
+ ret = st7703_init_sequence(ctx);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int st7703_disable(struct drm_panel *panel)
+{
+ struct st7703 *ctx = panel_to_st7703(panel);
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ return mipi_dsi_dcs_set_display_off(dsi);
+}
+
+static int st7703_unprepare(struct drm_panel *panel)
+{
+ struct st7703 *ctx = panel_to_st7703(panel);
+
+ if (!ctx->prepared)
+ return 0;
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ regulator_bulk_disable(ctx->desc->num_supplies, ctx->supplies);
+ ctx->prepared = false;
+
+ return 0;
+}
+
+static int st7703_get_modes(struct drm_panel *panel,
+ struct drm_connector *connector)
+{
+ struct st7703 *ctx = panel_to_st7703(panel);
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
+ if (!mode) {
+ DRM_DEV_ERROR(ctx->dev, "Failed to add mode\n");
+ return -ENOMEM;
+ }
+
+ drm_mode_set_name(mode);
+
+ mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ connector->display_info.width_mm = mode->width_mm;
+ connector->display_info.height_mm = mode->height_mm;
+ drm_mode_probed_add(connector, mode);
+
+ return 1;
+}
+
+static const struct drm_panel_funcs st7703_drm_funcs = {
+ .prepare = st7703_prepare,
+ .enable = st7703_enable,
+ .disable = st7703_disable,
+ .unprepare = st7703_unprepare,
+ .get_modes = st7703_get_modes,
+};
+
+static const struct drm_display_mode xbd599_mode = {
+ .hdisplay = 720,
+ .hsync_start = 720 + 40,
+ .hsync_end = 720 + 40 + 40,
+ .htotal = 720 + 40 + 40 + 40,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 18,
+ .vsync_end = 1440 + 18 + 10,
+ .vtotal = 1440 + 18 + 10 + 17,
+ .vrefresh = 60,
+ .clock = 69000,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+
+ .width_mm = 68,
+ .height_mm = 136,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const char * const xbd599_supply_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+static const struct st7703_panel_desc xbd599_desc = {
+ .mode = &xbd599_mode,
+ .lanes = 4,
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+ .format = MIPI_DSI_FMT_RGB888,
+ .supply_names = xbd599_supply_names,
+ .num_supplies = ARRAY_SIZE(xbd599_supply_names),
+};
+
+static int st7703_probe(struct mipi_dsi_device *dsi)
+{
+ const struct st7703_panel_desc *desc;
+ struct device *dev = &dsi->dev;
+ struct st7703 *ctx;
+ int i, ret;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ ctx->dev = dev;
+ ctx->desc = desc = of_device_get_match_data(dev);
+
+ dsi->mode_flags = desc->flags;
+ dsi->format = desc->format;
+ dsi->lanes = desc->lanes;
+
+ ctx->supplies = devm_kcalloc(&dsi->dev, desc->num_supplies,
+ sizeof(*ctx->supplies),
+ GFP_KERNEL);
+ if (!ctx->supplies)
+ return -ENOMEM;
+
+ for (i = 0; i < desc->num_supplies; i++)
+ ctx->supplies[i].supply = desc->supply_names[i];
+
+ ret = devm_regulator_bulk_get(&dsi->dev, desc->num_supplies,
+ ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ctx->reset_gpio)) {
+ DRM_DEV_ERROR(dev, "Can't get reset gpio\n");
+ return PTR_ERR(ctx->reset_gpio);
+ }
+
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ drm_panel_init(&ctx->panel, &dsi->dev, &st7703_drm_funcs,
+ DRM_MODE_CONNECTOR_DSI);
+
+ ret = drm_panel_of_backlight(&ctx->panel);
+ if (ret)
+ return ret;
+
+ drm_panel_add(&ctx->panel);
+
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void st7703_shutdown(struct mipi_dsi_device *dsi)
+{
+ struct st7703 *ctx = mipi_dsi_get_drvdata(dsi);
+ int ret;
+
+ ret = drm_panel_unprepare(&ctx->panel);
+ if (ret < 0)
+ DRM_DEV_ERROR(&dsi->dev, "Failed to unprepare panel: %d\n",
+ ret);
+}
+
+static int st7703_remove(struct mipi_dsi_device *dsi)
+{
+ struct st7703 *ctx = mipi_dsi_get_drvdata(dsi);
+ int ret;
+
+ st7703_shutdown(dsi);
+
+ ret = mipi_dsi_detach(dsi);
+ if (ret < 0)
+ DRM_DEV_ERROR(&dsi->dev, "Failed to detach from DSI host: %d\n",
+ ret);
+
+ drm_panel_remove(&ctx->panel);
+
+ return 0;
+}
+
+static const struct of_device_id st7703_of_match[] = {
+ { .compatible = "xingbangda,xbd599", .data = &xbd599_desc },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, st7703_of_match);
+
+static struct mipi_dsi_driver st7703_driver = {
+ .probe = st7703_probe,
+ .remove = st7703_remove,
+ .shutdown = st7703_shutdown,
+ .driver = {
+ .name = "st7703",
+ .of_match_table = st7703_of_match,
+ },
+};
+module_mipi_dsi_driver(st7703_driver);
+
+MODULE_AUTHOR("Icenowy Zheng <icenowy@aosc.io>");
+MODULE_DESCRIPTION("DRM driver for Sitronix ST7703 MIPI DSI panel");
+MODULE_LICENSE("GPL v2");
--
2.26.2
^ permalink raw reply related
* [PATCH v3 4/5] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
From: Ondrej Jirman @ 2020-05-13 21:24 UTC (permalink / raw)
To: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
Samuel Holland, Martijn Braam, Luca Weiss, Bhushan Shah,
Ondrej Jirman
In-Reply-To: <20200513212451.1919013-1-megous@megous.com>
From: Icenowy Zheng <icenowy@aosc.io>
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Backlight levels curve was optimized by Martijn Braam using a
lux meter.
Add its device nodes.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Martijn Braam <martijn@brixit.nl>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../allwinner/sun50i-a64-pinephone-1.1.dts | 19 ++++++++++
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 35 +++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
index 06a775c41664..3e99a87e9ce5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
@@ -9,3 +9,22 @@ / {
model = "Pine64 PinePhone Braveheart (1.1)";
compatible = "pine64,pinephone-1.1", "allwinner,sun50i-a64";
};
+
+&backlight {
+ power-supply = <®_ldo_io0>;
+ /*
+ * PWM backlight circuit on this PinePhone revision was changed since
+ * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
+ * being off is around 20%. Duty cycle for the lowest brightness level
+ * also varries quite a bit between individual boards, so the lowest
+ * value here was chosen as a safe default.
+ */
+ brightness-levels = <
+ 774 793 814 842
+ 882 935 1003 1088
+ 1192 1316 1462 1633
+ 1830 2054 2309 2596
+ 2916 3271 3664 4096>;
+ num-interpolated-steps = <50>;
+ default-brightness-level = <400>;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..e60b57f8ac14 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,13 @@ aliases {
serial0 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
+ enable-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ /* Backlight configuration differs per PinePhone revision. */
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +91,30 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599", "sitronix,st7703";
+ reg = <0>;
+ reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -188,6 +219,10 @@ &r_pio {
*/
};
+&r_pwm {
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
--
2.26.2
^ permalink raw reply related
* [PATCH v3 5/5] arm64: dts: sun50i-a64-pinephone: Add touchscreen support
From: Ondrej Jirman @ 2020-05-13 21:24 UTC (permalink / raw)
To: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng
Cc: Ondrej Jirman, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, Samuel Holland, Martijn Braam, Luca Weiss,
Bhushan Shah
In-Reply-To: <20200513212451.1919013-1-megous@megous.com>
Pinephone has a Goodix GT917S capacitive touchscreen controller on
I2C0 bus. Add support for it.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index e60b57f8ac14..6b2ff431cddb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -123,6 +123,25 @@ &ehci1 {
status = "okay";
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ touchscreen@5d {
+ compatible = "goodix,gt917s", "goodix,gt911";
+ reg = <0x5d>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 4 IRQ_TYPE_LEVEL_HIGH>; /* PH4 */
+ irq-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ reset-gpios = <&pio 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ AVDD28-supply = <®_ldo_io0>;
+ VDDIO-supply = <®_ldo_io0>;
+ touchscreen-size-x = <720>;
+ touchscreen-size-y = <1440>;
+ };
+};
+
&i2c1 {
status = "okay";
--
2.26.2
^ permalink raw reply related
* [PATCH v3 2/5] dt-bindings: panel: Add binding for Xingbangda XBD599 panel
From: Ondrej Jirman @ 2020-05-13 21:24 UTC (permalink / raw)
To: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
Samuel Holland, Martijn Braam, Luca Weiss, Bhushan Shah,
Ondrej Jirman
In-Reply-To: <20200513212451.1919013-1-megous@megous.com>
From: Icenowy Zheng <icenowy@aosc.io>
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. It is based on
Sitronix ST7703 LCD controller.
Add its device tree binding.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../display/panel/sitronix,st7703.yaml | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7703.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7703.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7703.yaml
new file mode 100644
index 000000000000..6e1606db4ab4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7703.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sitronix,st7703.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7703 MIPI DSI panel
+
+maintainers:
+ - Icenowy Zheng <icenowy@aosc.io>
+ - Ondrej Jirman <megous@megous.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - xingbangda,xbd599
+ - const: sitronix,st7703
+
+ reg:
+ description: DSI virtual channel used by that screen
+ maxItems: 1
+
+ vcc-supply:
+ description: regulator that supplies the VCC voltage
+
+ iovcc-supply:
+ description: regulator that supplies the IOVCC voltage
+
+ reset-gpios: true
+
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+ - iovcc-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "xingbangda,xbd599", "sitronix,st7703";
+ reg = <0>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+ };
+
--
2.26.2
^ permalink raw reply related
* [PATCH v3 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
From: Ondrej Jirman @ 2020-05-13 21:24 UTC (permalink / raw)
To: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
Samuel Holland, Martijn Braam, Luca Weiss, Bhushan Shah,
Ondrej Jirman
In-Reply-To: <20200513212451.1919013-1-megous@megous.com>
From: Icenowy Zheng <icenowy@aosc.io>
Shenzhen Xingbangda Display Technology Co., Ltd is a company which
produces LCD modules. It supplies the LCD panels for the PinePhone.
Add the vendor prefix of it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 442579a4c837..7504440dba36 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1139,6 +1139,8 @@ patternProperties:
description: Xiaomi Technology Co., Ltd.
"^xillybus,.*":
description: Xillybus Ltd.
+ "^xingbangda,.*":
+ description: Shenzhen Xingbangda Display Technology Co., Ltd
"^xinpeng,.*":
description: Shenzhen Xinpeng Technology Co., Ltd
"^xlnx,.*":
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: msm8916: Disable coresight by default
From: Bjorn Andersson @ 2020-05-13 21:22 UTC (permalink / raw)
To: michael.srba
Cc: Andy Gross, Jeffrey Hugo, Rob Herring, Mathieu Poirier,
Suzuki K Poulose, Mike Leach, linux-arm-msm, devicetree,
linux-kernel, ~postmarketos/upstreaming
In-Reply-To: <20200513184735.30104-1-michael.srba@seznam.cz>
On Wed 13 May 11:47 PDT 2020, michael.srba@seznam.cz wrote:
> From: Michael Srba <michael.srba@seznam.cz>
>
> On some msm8916 devices, attempts at initializing coresight cause the boot to
> fail. This was fixed by disabling the coresight-related nodes in the board dts
> files. However, a cleaner approach was chosen for fixing the same issue on
> msm8998: disabling coresight by default, and enabling it in board dts files
> where desired.
>
> This patch implements the same solution for msm8916, removes now redundant
> overwrites in board specific dts files and and enables coresight in db410c's
> board dts in order to keep the current behavior.
>
Applied, with Jeff's r-b.
Thanks,
Bjorn
> Fixes: b1fcc5702a41 ("arm64: dts: qcom: msm8916: Add CTI options")
> Signed-off-by: Michael Srba <michael.srba@seznam.cz>
>
> ---
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 21 +++++++++++
> .../boot/dts/qcom/msm8916-longcheer-l8150.dts | 23 ------------
> .../qcom/msm8916-samsung-a2015-common.dtsi | 23 ------------
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 35 +++++++++++++++++++
> 4 files changed, 56 insertions(+), 46 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 14982762088d..07c150b0ed54 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -519,6 +519,27 @@ mpps@a000 {
> wcnss@a21b000 {
> status = "okay";
> };
> +
> + tpiu@820000 { status = "okay"; };
> + funnel@821000 { status = "okay"; };
> + replicator@824000 { status = "okay"; };
> + etf@825000 { status = "okay"; };
> + etr@826000 { status = "okay"; };
> + funnel@841000 { status = "okay"; };
> + debug@850000 { status = "okay"; };
> + debug@852000 { status = "okay"; };
> + debug@854000 { status = "okay"; };
> + debug@856000 { status = "okay"; };
> + etm@85c000 { status = "okay"; };
> + etm@85d000 { status = "okay"; };
> + etm@85e000 { status = "okay"; };
> + etm@85f000 { status = "okay"; };
> + cti@810000 { status = "okay"; };
> + cti@811000 { status = "okay"; };
> + cti@858000 { status = "okay"; };
> + cti@859000 { status = "okay"; };
> + cti@85a000 { status = "okay"; };
> + cti@85b000 { status = "okay"; };
> };
>
> usb2513 {
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> index d1ccb9472c8b..691eb1a87bc9 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> @@ -82,29 +82,6 @@ phy {
> wcnss@a21b000 {
> status = "okay";
> };
> -
> - /*
> - * Attempting to enable these devices causes a "synchronous
> - * external abort". Suspected cause is that the debug power
> - * domain is not enabled by default on this device.
> - * Disable these devices for now to avoid the crash.
> - *
> - * See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
> - */
> - tpiu@820000 { status = "disabled"; };
> - funnel@821000 { status = "disabled"; };
> - replicator@824000 { status = "disabled"; };
> - etf@825000 { status = "disabled"; };
> - etr@826000 { status = "disabled"; };
> - funnel@841000 { status = "disabled"; };
> - debug@850000 { status = "disabled"; };
> - debug@852000 { status = "disabled"; };
> - debug@854000 { status = "disabled"; };
> - debug@856000 { status = "disabled"; };
> - etm@85c000 { status = "disabled"; };
> - etm@85d000 { status = "disabled"; };
> - etm@85e000 { status = "disabled"; };
> - etm@85f000 { status = "disabled"; };
> };
>
> // FIXME: Use extcon device provided by charger driver when available
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> index 43c5e0f882f1..af812f76e8be 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> @@ -75,29 +75,6 @@ phy {
> wcnss@a21b000 {
> status = "okay";
> };
> -
> - /*
> - * Attempting to enable these devices causes a "synchronous
> - * external abort". Suspected cause is that the debug power
> - * domain is not enabled by default on this device.
> - * Disable these devices for now to avoid the crash.
> - *
> - * See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
> - */
> - tpiu@820000 { status = "disabled"; };
> - funnel@821000 { status = "disabled"; };
> - replicator@824000 { status = "disabled"; };
> - etf@825000 { status = "disabled"; };
> - etr@826000 { status = "disabled"; };
> - funnel@841000 { status = "disabled"; };
> - debug@850000 { status = "disabled"; };
> - debug@852000 { status = "disabled"; };
> - debug@854000 { status = "disabled"; };
> - debug@856000 { status = "disabled"; };
> - etm@85c000 { status = "disabled"; };
> - etm@85d000 { status = "disabled"; };
> - etm@85e000 { status = "disabled"; };
> - etm@85f000 { status = "disabled"; };
> };
>
> gpio-keys {
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 8b429954ea29..5cf117e247df 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1228,6 +1228,8 @@ tpiu@820000 {
> clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> clock-names = "apb_pclk", "atclk";
>
> + status = "disabled";
> +
> in-ports {
> port {
> tpiu_in: endpoint {
> @@ -1244,6 +1246,8 @@ funnel@821000 {
> clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> clock-names = "apb_pclk", "atclk";
>
> + status = "disabled";
> +
> in-ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1283,6 +1287,8 @@ replicator@824000 {
> clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> clock-names = "apb_pclk", "atclk";
>
> + status = "disabled";
> +
> out-ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1317,6 +1323,8 @@ etf@825000 {
> clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> clock-names = "apb_pclk", "atclk";
>
> + status = "disabled";
> +
> in-ports {
> port {
> etf_in: endpoint {
> @@ -1341,6 +1349,8 @@ etr@826000 {
> clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> clock-names = "apb_pclk", "atclk";
>
> + status = "disabled";
> +
> in-ports {
> port {
> etr_in: endpoint {
> @@ -1357,6 +1367,8 @@ funnel@841000 { /* APSS funnel only 4 inputs are used */
> clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> clock-names = "apb_pclk", "atclk";
>
> + status = "disabled";
> +
> in-ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1402,6 +1414,7 @@ debug@850000 {
> clocks = <&rpmcc RPM_QDSS_CLK>;
> clock-names = "apb_pclk";
> cpu = <&CPU0>;
> + status = "disabled";
> };
>
> debug@852000 {
> @@ -1410,6 +1423,7 @@ debug@852000 {
> clocks = <&rpmcc RPM_QDSS_CLK>;
> clock-names = "apb_pclk";
> cpu = <&CPU1>;
> + status = "disabled";
> };
>
> debug@854000 {
> @@ -1418,6 +1432,7 @@ debug@854000 {
> clocks = <&rpmcc RPM_QDSS_CLK>;
> clock-names = "apb_pclk";
> cpu = <&CPU2>;
> + status = "disabled";
> };
>
> debug@856000 {
> @@ -1426,6 +1441,7 @@ debug@856000 {
> clocks = <&rpmcc RPM_QDSS_CLK>;
> clock-names = "apb_pclk";
> cpu = <&CPU3>;
> + status = "disabled";
> };
>
> etm0: etm@85c000 {
> @@ -1438,6 +1454,8 @@ etm0: etm@85c000 {
>
> cpu = <&CPU0>;
>
> + status = "disabled";
> +
> out-ports {
> port {
> etm0_out: endpoint {
> @@ -1457,6 +1475,8 @@ etm1: etm@85d000 {
>
> cpu = <&CPU1>;
>
> + status = "disabled";
> +
> out-ports {
> port {
> etm1_out: endpoint {
> @@ -1476,6 +1496,8 @@ etm2: etm@85e000 {
>
> cpu = <&CPU2>;
>
> + status = "disabled";
> +
> out-ports {
> port {
> etm2_out: endpoint {
> @@ -1495,6 +1517,8 @@ etm3: etm@85f000 {
>
> cpu = <&CPU3>;
>
> + status = "disabled";
> +
> out-ports {
> port {
> etm3_out: endpoint {
> @@ -1512,6 +1536,8 @@ cti@810000 {
>
> clocks = <&rpmcc RPM_QDSS_CLK>;
> clock-names = "apb_pclk";
> +
> + status = "disabled";
> };
>
> /* CTI 1 - TPIU connections */
> @@ -1521,6 +1547,8 @@ cti@811000 {
>
> clocks = <&rpmcc RPM_QDSS_CLK>;
> clock-names = "apb_pclk";
> +
> + status = "disabled";
> };
>
> /* CTIs 2-11 - no information - not instantiated */
> @@ -1538,6 +1566,7 @@ cti@858000 {
> cpu = <&CPU0>;
> arm,cs-dev-assoc = <&etm0>;
>
> + status = "disabled";
> };
>
> /* CTI - CPU-1 */
> @@ -1551,6 +1580,8 @@ cti@859000 {
>
> cpu = <&CPU1>;
> arm,cs-dev-assoc = <&etm1>;
> +
> + status = "disabled";
> };
>
> /* CTI - CPU-2 */
> @@ -1564,6 +1595,8 @@ cti@85a000 {
>
> cpu = <&CPU2>;
> arm,cs-dev-assoc = <&etm2>;
> +
> + status = "disabled";
> };
>
> /* CTI - CPU-3 */
> @@ -1577,6 +1610,8 @@ cti@85b000 {
>
> cpu = <&CPU3>;
> arm,cs-dev-assoc = <&etm3>;
> +
> + status = "disabled";
> };
>
>
> --
> 2.24.0
>
^ permalink raw reply
* Re: [PATCH 1/5] spi: dt-bindings: sifive: Add missing 2nd register region
From: Paul Walmsley @ 2020-05-13 21:22 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-clk, linux-usb, linux-spi, linux-kernel,
Greg Kroah-Hartman, Mark Brown, Palmer Dabbelt, linux-riscv
In-Reply-To: <20200512204543.22090-1-robh@kernel.org>
On Tue, 12 May 2020, Rob Herring wrote:
> The 'reg' description and example have a 2nd register region for memory
> mapped flash, but the schema says there is only 1 region. Fix this.
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: linux-spi@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Please ack, dependency for patch 5.
Acked-by: Paul Walmsley <paul.walmsley@sifive.com>
- Paul
^ permalink raw reply
* Re: [PATCH v2] video: fbdev: ssd1307fb: Added support to Column offset
From: kbuild test robot @ 2020-05-13 20:58 UTC (permalink / raw)
To: Rodrigo Rolim Mendes de Alencar, linux-fbdev
Cc: kbuild-all, linux-kernel, b.zolnierkie, andy.shevchenko,
devicetree, Rodrigo Rolim Mendes de Alencar, Rodrigo Alencar
In-Reply-To: <1589388975-15499-1-git-send-email-alencar.fmce@imbel.gov.br>
[-- Attachment #1: Type: text/plain, Size: 8162 bytes --]
Hi Rodrigo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20200512]
[cannot apply to robh/for-next linus/master linux/master v5.7-rc5 v5.7-rc4 v5.7-rc3 v5.7-rc5]
[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/Rodrigo-Rolim-Mendes-de-Alencar/video-fbdev-ssd1307fb-Added-support-to-Column-offset/20200514-010137
base: e098d7762d602be640c53565ceca342f81e55ad2
config: parisc-randconfig-r022-20200513 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/video/fbdev/ssd1307fb.c: In function 'ssd1307fb_probe':
>> drivers/video/fbdev/ssd1307fb.c:630:31: error: 'node' undeclared (first use in this function); did you mean 'inode'?
630 | if (device_property_read_u32(node, "solomon,col-offset", &par->col_offset))
| ^~~~
| inode
drivers/video/fbdev/ssd1307fb.c:630:31: note: each undeclared identifier is reported only once for each function it appears in
vim +630 drivers/video/fbdev/ssd1307fb.c
579
580 static int ssd1307fb_probe(struct i2c_client *client)
581 {
582 struct device *dev = &client->dev;
583 struct backlight_device *bl;
584 char bl_name[12];
585 struct fb_info *info;
586 struct fb_deferred_io *ssd1307fb_defio;
587 u32 vmem_size;
588 struct ssd1307fb_par *par;
589 void *vmem;
590 int ret;
591
592 info = framebuffer_alloc(sizeof(struct ssd1307fb_par), dev);
593 if (!info)
594 return -ENOMEM;
595
596 par = info->par;
597 par->info = info;
598 par->client = client;
599
600 par->device_info = device_get_match_data(dev);
601
602 par->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
603 if (IS_ERR(par->reset)) {
604 dev_err(dev, "failed to get reset gpio: %ld\n",
605 PTR_ERR(par->reset));
606 ret = PTR_ERR(par->reset);
607 goto fb_alloc_error;
608 }
609
610 par->vbat_reg = devm_regulator_get_optional(dev, "vbat");
611 if (IS_ERR(par->vbat_reg)) {
612 ret = PTR_ERR(par->vbat_reg);
613 if (ret == -ENODEV) {
614 par->vbat_reg = NULL;
615 } else {
616 dev_err(dev, "failed to get VBAT regulator: %d\n", ret);
617 goto fb_alloc_error;
618 }
619 }
620
621 if (device_property_read_u32(dev, "solomon,width", &par->width))
622 par->width = 96;
623
624 if (device_property_read_u32(dev, "solomon,height", &par->height))
625 par->height = 16;
626
627 if (device_property_read_u32(dev, "solomon,page-offset", &par->page_offset))
628 par->page_offset = 1;
629
> 630 if (device_property_read_u32(node, "solomon,col-offset", &par->col_offset))
631 par->col_offset = 0;
632
633 if (device_property_read_u32(dev, "solomon,com-offset", &par->com_offset))
634 par->com_offset = 0;
635
636 if (device_property_read_u32(dev, "solomon,prechargep1", &par->prechargep1))
637 par->prechargep1 = 2;
638
639 if (device_property_read_u32(dev, "solomon,prechargep2", &par->prechargep2))
640 par->prechargep2 = 2;
641
642 if (!device_property_read_u8_array(dev, "solomon,lookup-table",
643 par->lookup_table,
644 ARRAY_SIZE(par->lookup_table)))
645 par->lookup_table_set = 1;
646
647 par->seg_remap = !device_property_read_bool(dev, "solomon,segment-no-remap");
648 par->com_seq = device_property_read_bool(dev, "solomon,com-seq");
649 par->com_lrremap = device_property_read_bool(dev, "solomon,com-lrremap");
650 par->com_invdir = device_property_read_bool(dev, "solomon,com-invdir");
651 par->area_color_enable =
652 device_property_read_bool(dev, "solomon,area-color-enable");
653 par->low_power = device_property_read_bool(dev, "solomon,low-power");
654
655 par->contrast = 127;
656 par->vcomh = par->device_info->default_vcomh;
657
658 /* Setup display timing */
659 if (device_property_read_u32(dev, "solomon,dclk-div", &par->dclk_div))
660 par->dclk_div = par->device_info->default_dclk_div;
661 if (device_property_read_u32(dev, "solomon,dclk-frq", &par->dclk_frq))
662 par->dclk_frq = par->device_info->default_dclk_frq;
663
664 vmem_size = DIV_ROUND_UP(par->width, 8) * par->height;
665
666 vmem = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
667 get_order(vmem_size));
668 if (!vmem) {
669 dev_err(dev, "Couldn't allocate graphical memory.\n");
670 ret = -ENOMEM;
671 goto fb_alloc_error;
672 }
673
674 ssd1307fb_defio = devm_kzalloc(dev, sizeof(*ssd1307fb_defio),
675 GFP_KERNEL);
676 if (!ssd1307fb_defio) {
677 dev_err(dev, "Couldn't allocate deferred io.\n");
678 ret = -ENOMEM;
679 goto fb_alloc_error;
680 }
681
682 ssd1307fb_defio->delay = HZ / refreshrate;
683 ssd1307fb_defio->deferred_io = ssd1307fb_deferred_io;
684
685 info->fbops = &ssd1307fb_ops;
686 info->fix = ssd1307fb_fix;
687 info->fix.line_length = DIV_ROUND_UP(par->width, 8);
688 info->fbdefio = ssd1307fb_defio;
689
690 info->var = ssd1307fb_var;
691 info->var.xres = par->width;
692 info->var.xres_virtual = par->width;
693 info->var.yres = par->height;
694 info->var.yres_virtual = par->height;
695
696 info->screen_buffer = vmem;
697 info->fix.smem_start = __pa(vmem);
698 info->fix.smem_len = vmem_size;
699
700 fb_deferred_io_init(info);
701
702 i2c_set_clientdata(client, info);
703
704 if (par->reset) {
705 /* Reset the screen */
706 gpiod_set_value_cansleep(par->reset, 1);
707 udelay(4);
708 gpiod_set_value_cansleep(par->reset, 0);
709 udelay(4);
710 }
711
712 if (par->vbat_reg) {
713 ret = regulator_enable(par->vbat_reg);
714 if (ret) {
715 dev_err(dev, "failed to enable VBAT: %d\n", ret);
716 goto reset_oled_error;
717 }
718 }
719
720 ret = ssd1307fb_init(par);
721 if (ret)
722 goto regulator_enable_error;
723
724 ret = register_framebuffer(info);
725 if (ret) {
726 dev_err(dev, "Couldn't register the framebuffer\n");
727 goto panel_init_error;
728 }
729
730 snprintf(bl_name, sizeof(bl_name), "ssd1307fb%d", info->node);
731 bl = backlight_device_register(bl_name, dev, par, &ssd1307fb_bl_ops,
732 NULL);
733 if (IS_ERR(bl)) {
734 ret = PTR_ERR(bl);
735 dev_err(dev, "unable to register backlight device: %d\n", ret);
736 goto bl_init_error;
737 }
738
739 bl->props.brightness = par->contrast;
740 bl->props.max_brightness = MAX_CONTRAST;
741 info->bl_dev = bl;
742
743 dev_info(dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
744
745 return 0;
746
747 bl_init_error:
748 unregister_framebuffer(info);
749 panel_init_error:
750 if (par->device_info->need_pwm) {
751 pwm_disable(par->pwm);
752 pwm_put(par->pwm);
753 }
754 regulator_enable_error:
755 if (par->vbat_reg)
756 regulator_disable(par->vbat_reg);
757 reset_oled_error:
758 fb_deferred_io_cleanup(info);
759 fb_alloc_error:
760 framebuffer_release(info);
761 return ret;
762 }
763
---
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: 33691 bytes --]
^ permalink raw reply
* Re: [PATCH v7 RESEND 13/13] dmaengine: imx-sdma: add uart rom script
From: Fabio Estevam @ 2020-05-13 21:06 UTC (permalink / raw)
To: Robin Gong
Cc: Sascha Hauer, Vinod, Shawn Guo, Uwe Kleine-König,
Rob Herring, Dan Williams, Mark Rutland, Catalin Marinas,
Will Deacon, Lucas Stach, Martin Fuzzey, Sascha Hauer, linux-spi,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel, NXP Linux Team, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <1589218356-17475-14-git-send-email-yibin.gong@nxp.com>
Hi Robin,
On Mon, May 11, 2020 at 6:33 AM Robin Gong <yibin.gong@nxp.com> wrote:
> Please get latest sdma firmware from the below and put them into the path
> (/lib/firmware/imx/sdma/):
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> /tree/imx/sdma
"latest sdma firmware" is too vague. Better specify the commit ID of
the firmware where this is valid.
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8916: Disable coresight by default
From: Jeffrey Hugo @ 2020-05-13 20:24 UTC (permalink / raw)
To: michael.srba
Cc: Andy Gross, Bjorn Andersson, Rob Herring, Mathieu Poirier,
Suzuki K Poulose, Mike Leach, MSM, DTML, lkml,
~postmarketos/upstreaming
In-Reply-To: <20200513184735.30104-1-michael.srba@seznam.cz>
On Wed, May 13, 2020 at 12:50 PM <michael.srba@seznam.cz> wrote:
>
> From: Michael Srba <michael.srba@seznam.cz>
>
> On some msm8916 devices, attempts at initializing coresight cause the boot to
> fail. This was fixed by disabling the coresight-related nodes in the board dts
> files. However, a cleaner approach was chosen for fixing the same issue on
> msm8998: disabling coresight by default, and enabling it in board dts files
> where desired.
>
> This patch implements the same solution for msm8916, removes now redundant
> overwrites in board specific dts files and and enables coresight in db410c's
> board dts in order to keep the current behavior.
>
> Fixes: b1fcc5702a41 ("arm64: dts: qcom: msm8916: Add CTI options")
> Signed-off-by: Michael Srba <michael.srba@seznam.cz>
Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 0/6] allow ramoops to collect all kmesg_dump events
From: Kees Cook @ 2020-05-13 20:15 UTC (permalink / raw)
To: Pavel Tatashin
Cc: Petr Mladek, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Rob Herring, Benson Leung,
Enric Balletbo i Serra, Sergey Senozhatsky, Steven Rostedt,
James Morris, Sasha Levin, Linux Doc Mailing List, LKML,
devicetree
In-Reply-To: <CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com>
On Wed, May 13, 2020 at 10:35:16AM -0400, Pavel Tatashin wrote:
> > > + reason: panic, oops, emergency, shutdown (ordered by severity)
> > > + handling: restart, halt, poweroff
> > >
> > > Or we might just replace KMSG_DUMP_RESTART, KMSG_DUMP_HALT,
> > > KMSG_DUMP_POWEROFF with a single KMSG_DUMP_SHUTDOWN.
> > >
> > > Then the max reason variable would make sense.
> >
> > That would work for me, yeah. Pavel, is that enough granularity for you?
> >
>
> Yes, I like the second approach: where we combine all shutdown type
> events into a single type.
> max_reason will have 4 levels:
>
> KMSG_DUMP_PANIC,
> KMSG_DUMP_OOPS,
> KMSG_DUMP_EMERG,
> KMSG_DUMP_SHUTDOWN,
>
> If needed it is possible to determine from dmesg logs what kind of
> shutdown was taken, because there is a message logged right before
> every kmsg_dump() for these events:
>
> 249 if (!cmd)
> 250 pr_emerg("Restarting system\n");
> 251 else
> 252 pr_emerg("Restarting system with command '%s'\n", cmd);
> 253 kmsg_dump(KMSG_DUMP_RESTART);
>
> 276 pr_emerg("System halted\n");
> 277 kmsg_dump(KMSG_DUMP_HALT);
>
> 294 pr_emerg("Power down\n");
> 295 kmsg_dump(KMSG_DUMP_POWEROFF);
>
> Kees, I will submit a new series with these changes soon.
Great; thanks!
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Alan Cooper @ 2020-05-13 19:42 UTC (permalink / raw)
To: Florian Fainelli
Cc: Alan Stern, Greg Kroah-Hartman, : Linux Kernel Mailing List,
Andy Shevchenko, BCM Kernel Feedback, DTML, Krzysztof Kozlowski,
USB list, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <c0642cf4-1436-aec4-96fd-355a897f6418@gmail.com>
On Wed, May 13, 2020 at 1:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 5/13/2020 10:39 AM, Alan Stern wrote:
> > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> >> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> >>>
> >>>
> >>> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> >>>> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> >>>>>
> >>>>>
> >>>>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> >>>>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >>>>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >>>>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >>>>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> >>>>>>> has XHCI linking at the bottom which will result in the XHIC driver
> >>>>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >>>>>>> device will be seen as a 2.0 device. Moving the XHCI linking
> >>>>>>> above the EHCI and OHCI linking fixes the issue.
> >>>>>>
> >>>>>> What happens if all of these are modules and they are loaded in a
> >>>>>> different order? This makefile change will not help with that, you need
> >>>>>> to have logic in the code in order to properly coordinate this type of
> >>>>>> mess, sorry.
> >>>>>
> >>>>> I believe we should be using module soft dependencies to instruct the
> >>>>> module loaders to load the modules in the correct order, so something
> >>>>> like this would do (not tested) for xhci-plat-hcd.c:
> >>>>>
> >>>>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> >>>>>
> >>>>> and I am not sure whether we need to add the opposite for ehci-hcd and
> >>>>> ohci-hcd:
> >>>>>
> >>>>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> >>>>
> >>>> That's a nice start, but what happens if that isn't honored? This
> >>>> really needs to work properly for any order as you never can guarantee
> >>>> module/driver loading order in a system of modules.
> >>>
> >>> I also suggested that device links may help, though I am not sure. What
> >>> do you suggest to be done?
> >>
> >> No idea. device links will help if you defer the probe properly until
> >> you see the proper drivers binding correctly.
> >
> > I suspect that in general there is no way to do this properly.
> >
> > We can't modify ehci-hcd and ohci-hcd to make them wait. In fact, for
> > all they know, xhci-hcd will _never_ be loaded.
> >
> > One thing that might be possible (although not all platforms may support
> > it) is if xhci-hcd could somehow disconnect all devices attached to a
> > peer port when it starts up. But that would be disruptive to any
> > devices that aren't USB-3.
> >
> > We faced a very similar ordering problem between ehci-hcd and
> > [ou]hci-hcd many years ago, and we never found a good solution.
> > We did arrange the link order so that ehci-hcd precedes the others, and
> > we added a warning message to ehci-hcd which gets printed if the module
> > initialization routine runs after [ou]hci-hcd is loaded. Also, there
> > are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
>
> Given that these modules are used on specific SoC platforms, where we
> usually provide a reference implementation of user space and kernel
> space and documentation, it seems to me that the MODULE_SOFTDEP(),
> despite being a hint and best effort from user space module loaders is
> probably acceptable.
> --
> Florian
What I found in the past is that things work. For example if the ehci
driver starts first, the USB device will come up as a 2.0 device and
when the XHCI driver comes up the device will switch to 3.0. I've see
the same thing happen if OHCI starts before EHCI. It's just that there
are some poorly behaved USB devices that have trouble with this.
Al
^ permalink raw reply
* Re: [PATCH 2/3] remoteproc/k3-dsp: Add a remoteproc driver of K3 C66x DSPs
From: Mathieu Poirier @ 2020-05-13 19:40 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, Linux Kernel Mailing List
In-Reply-To: <908c1244-b9d8-e9bf-87d7-b60a73e98f18@ti.com>
On Wed, 13 May 2020 at 12:14, Suman Anna <s-anna@ti.com> wrote:
>
> Hi Mathieu,
>
> On 4/27/20 5:57 PM, Mathieu Poirier wrote:
> > On Wed, Mar 25, 2020 at 03:18:38PM -0500, Suman Anna wrote:
> >> The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN
> >> voltage domain that are based on the TI's standard TMS320C66x DSP CorePac
> >> module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each
> >> of L1P & L1D SRAMs that can be configured and partitioned as either RAM
> >> and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as
> >> either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA),
> >> External Memory Controller (EMC), Extended Memory Controller (XMC) with a
> >> Region Address Translator (RAT) unit for 32-bit to 48-bit address
> >> extension/translations, an Interrupt Controller (INTC) and a Powerdown
> >> Controller (PDC).
> >>
> >> A new remoteproc module is added to perform the device management of
> >> these DSP devices. The support is limited to images using only external
> >> DDR memory at the moment, the loading support to internal memories and
> >> any on-chip RAM memories will be added in a subsequent patch. RAT support
> >> is also left for a future patch, and as such the reserved memory carveout
> >> regions are all expected to be using memory regions within the first 2 GB.
> >> Error Recovery and Power Management features are not currently supported.
> >>
> >> The C66x remote processors do not have an MMU, and so require fixed memory
> >> carveout regions matching the firmware image addresses. Support for this
> >> is provided by mandating multiple memory regions to be attached to the
> >> remoteproc device. The first memory region will be used to serve as the
> >> DMA pool for all dynamic allocations like the vrings and vring buffers.
> >> The remaining memory regions are mapped into the kernel at device probe
> >> time, and are used to provide address translations for firmware image
> >> segments without the need for any RSC_CARVEOUT entries. Any firmware
> >> image using memory outside of the supplied reserved memory carveout
> >> regions will be errored out.
> >>
> >> The driver uses various TI-SCI interfaces to talk to the System Controller
> >> (DMSC) for managing configuration, power and reset management of these
> >> cores. IPC between the A72 cores and the DSP cores is supported through
> >> the virtio rpmsg stack using shared memory and OMAP Mailboxes.
> >>
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >> ---
> >> drivers/remoteproc/Kconfig | 16 +
> >> drivers/remoteproc/Makefile | 1 +
> >> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 736 ++++++++++++++++++++++
> >> 3 files changed, 753 insertions(+)
> >> create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
> >>
> >> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >> index 073048b4c0fb..66a76acb15b6 100644
> >> --- a/drivers/remoteproc/Kconfig
> >> +++ b/drivers/remoteproc/Kconfig
> >> @@ -240,6 +240,22 @@ config TI_K3_R5_REMOTEPROC
> >> It's safe to say N here if you're not interested in utilizing
> >> a slave processor
> >>
> >> +config TI_K3_DSP_REMOTEPROC
> >> + tristate "TI K3 DSP remoteproc support"
> >> + depends on ARCH_K3
> >> + select MAILBOX
> >> + select OMAP2PLUS_MBOX
> >> + help
> >> + Say y here to support TI's C66x and C71x DSP remote processor
> >> + subsystems on various TI K3 family of SoCs through the remote
> >> + processor framework.
> >> +
> >> + You want to say m here in order to offload some processing
> >> + tasks to these processors.
> >
> > Building this driver has a module, i.e 'm', has nothing to do with what the
> > remote processor does. I would simply remove the above 2 lines.
>
> Yes, can drop. I will switch the "Say y" to "Say m" - that would be the
> preferred option. Having the driver built-in means the firmware has to
> be part of initramfs.
>
> >
> >> +
> >> + It's safe to say N here if you're not interested in utilizing
> >> + the DSP slave processors.
> >> +
> >> endif # REMOTEPROC
> >>
> >> endmenu
> >> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >> index 00ba826818af..eb51cc09e47b 100644
> >> --- a/drivers/remoteproc/Makefile
> >> +++ b/drivers/remoteproc/Makefile
> >> @@ -29,3 +29,4 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> >> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> >> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> >> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> >> +obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> >> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> >> new file mode 100644
> >> index 000000000000..fd0d84f46f90
> >> --- /dev/null
> >> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> >> @@ -0,0 +1,736 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * TI K3 DSP Remote Processor(s) driver
> >> + *
> >> + * Copyright (C) 2018-2020 Texas Instruments Incorporated - http://www.ti.com/
> >> + * Suman Anna <s-anna@ti.com>
> >> + */
> >> +
> >> +#include <linux/io.h>
> >> +#include <linux/module.h>
> >> +#include <linux/of_device.h>
> >> +#include <linux/of_reserved_mem.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/pm_runtime.h>
> >> +#include <linux/remoteproc.h>
> >> +#include <linux/mailbox_client.h>
> >> +#include <linux/omap-mailbox.h>
> >
> > Please move these two up.
>
> OK.
>
> >
> >> +#include <linux/reset.h>
> >> +#include <linux/soc/ti/ti_sci_protocol.h>
> >> +
> >> +#include "omap_remoteproc.h"
> >> +#include "remoteproc_internal.h"
> >> +#include "ti_sci_proc.h"
> >> +
> >> +#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK (SZ_16M - 1)
> >> +
> >> +/**
> >> + * struct k3_dsp_rproc_mem - internal memory structure
> >> + * @cpu_addr: MPU virtual address of the memory region
> >> + * @bus_addr: Bus address used to access the memory region
> >> + * @dev_addr: Device address of the memory region from DSP view
> >> + * @size: Size of the memory region
> >> + */
> >> +struct k3_dsp_rproc_mem {
> >
> > I would rename this 'k3_dsp_mem' to be consistent with k3_r5_mem.
>
> Yeah, will rename.
>
> >
> >> + void __iomem *cpu_addr;
> >> + phys_addr_t bus_addr;
> >> + u32 dev_addr;
> >> + size_t size;
> >> +};
> >> +
> >> +/**
> >> + * struct k3_dsp_mem_data - memory definitions for a DSP
> >> + * @name: name for this memory entry
> >> + * @dev_addr: device address for the memory entry
> >> + */
> >> +struct k3_dsp_mem_data {
> >> + const char *name;
> >> + const u32 dev_addr;
> >> +};
> >> +
> >> +/**
> >> + * struct k3_dsp_dev_data - device data structure for a DSP
> >> + * @mems: pointer to memory definitions for a DSP
> >> + * @num_mems: number of memory regions in @mems
> >> + * @boot_align_addr: boot vector address alignment granularity
> >> + * @uses_lreset: flag to denote the need for local reset management
> >> + */
> >> +struct k3_dsp_dev_data {
> >> + const struct k3_dsp_mem_data *mems;
> >> + u32 num_mems;
> >> + u32 boot_align_addr;
> >> + bool uses_lreset;
> >> +};
> >> +
> >> +/**
> >> + * struct k3_dsp_rproc - k3 DSP remote processor driver structure
> >> + * @dev: cached device pointer
> >> + * @rproc: remoteproc device handle
> >> + * @mem: internal memory regions data
> >> + * @num_mems: number of internal memory regions
> >> + * @rmem: reserved memory regions data
> >> + * @num_rmems: number of reserved memory regions
> >> + * @reset: reset control handle
> >> + * @data: pointer to DSP-specific device data
> >> + * @tsp: TI-SCI processor control handle
> >> + * @ti_sci: TI-SCI handle
> >> + * @ti_sci_id: TI-SCI device identifier
> >> + * @mbox: mailbox channel handle
> >> + * @client: mailbox client to request the mailbox channel
> >> + */
> >> +struct k3_dsp_rproc {
> >> + struct device *dev;
> >> + struct rproc *rproc;
> >> + struct k3_dsp_rproc_mem *mem;
> >> + int num_mems;
> >> + struct k3_dsp_rproc_mem *rmem;
> >> + int num_rmems;
> >> + struct reset_control *reset;
> >> + const struct k3_dsp_dev_data *data;
> >> + struct ti_sci_proc *tsp;
> >> + const struct ti_sci_handle *ti_sci;
> >> + u32 ti_sci_id;
> >> + struct mbox_chan *mbox;
> >> + struct mbox_client client;
> >> +};
> >> +
> >> +/**
> >> + * k3_dsp_rproc_mbox_callback() - inbound mailbox message handler
> >> + * @client: mailbox client pointer used for requesting the mailbox channel
> >> + * @data: mailbox payload
> >> + *
> >> + * This handler is invoked by the OMAP mailbox driver whenever a mailbox
> >> + * message is received. Usually, the mailbox payload simply contains
> >> + * the index of the virtqueue that is kicked by the remote processor,
> >> + * and we let remoteproc core handle it.
> >> + *
> >> + * In addition to virtqueue indices, we also have some out-of-band values
> >> + * that indicate different events. Those values are deliberately very
> >> + * large so they don't coincide with virtqueue indices.
> >> + */
> >> +static void k3_dsp_rproc_mbox_callback(struct mbox_client *client, void *data)
> >> +{
> >> + struct k3_dsp_rproc *kproc = container_of(client, struct k3_dsp_rproc,
> >> + client);
> >
> > Indentation problem.
>
> Thanks. Hmm, checkpatch didn't catch this.
>
> >
> >> + struct device *dev = kproc->rproc->dev.parent;
> >> + const char *name = kproc->rproc->name;
> >> + u32 msg = omap_mbox_message(data);
> >> +
> >> + dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> >> +
> >> + switch (msg) {
> >> + case RP_MBOX_CRASH:
> >> + /*
> >> + * remoteproc detected an exception, but error recovery is not
> >> + * supported. So, just log this for now
> >> + */
> >> + dev_err(dev, "K3 DSP rproc %s crashed\n", name);
> >> + break;
> >> + case RP_MBOX_ECHO_REPLY:
> >> + dev_info(dev, "received echo reply from %s\n", name);
> >> + break;
> >> + default:
> >> + /* silently handle all other valid messages */
> >> + if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> >> + return;
> >> + if (msg > kproc->rproc->max_notifyid) {
> >> + dev_dbg(dev, "dropping unknown message 0x%x", msg);
> >> + return;
> >> + }
> >> + /* msg contains the index of the triggered vring */
> >> + if (rproc_vq_interrupt(kproc->rproc, msg) == IRQ_NONE)
> >> + dev_dbg(dev, "no message was found in vqid %d\n", msg);
> >> + }
> >> +}
> >> +
> >> +/*
> >> + * Kick the remote processor to notify about pending unprocessed messages.
> >> + * The vqid usage is not used and is inconsequential, as the kick is performed
> >> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
> >> + * the remote processor is expected to process both its Tx and Rx virtqueues.
> >> + */
> >> +static void k3_dsp_rproc_kick(struct rproc *rproc, int vqid)
> >> +{
> >> + struct k3_dsp_rproc *kproc = rproc->priv;
> >> + struct device *dev = rproc->dev.parent;
> >> + mbox_msg_t msg = (mbox_msg_t)vqid;
> >> + int ret;
> >> +
> >> + /* send the index of the triggered virtqueue in the mailbox payload */
> >> + ret = mbox_send_message(kproc->mbox, (void *)msg);
> >> + if (ret < 0)
> >> + dev_err(dev, "failed to send mailbox message, status = %d\n",
> >> + ret);
> >> +}
> >> +
> >> +/* Put the DSP processor into reset */
> >> +static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
> >> +{
> >> + struct device *dev = kproc->dev;
> >> + int ret;
> >> +
> >> + ret = reset_control_assert(kproc->reset);
> >> + if (ret) {
> >> + dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> >> + kproc->ti_sci_id);
> >> + if (ret) {
> >> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
> >> + if (reset_control_deassert(kproc->reset))
> >> + dev_warn(dev, "local-reset deassert back failed\n");
> >> + }
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +/* Release the DSP processor from reset */
> >> +static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> >> +{
> >> + struct device *dev = kproc->dev;
> >> + int ret;
> >> +
> >> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> >> + kproc->ti_sci_id);
> >
> > Indentation problem.
>
> Thanks for catching, will fix.
>
> >
> >> + if (ret) {
> >> + dev_err(dev, "module-reset deassert failed, ret = %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + ret = reset_control_deassert(kproc->reset);
> >> + if (ret) {
> >> + dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> >> + if (kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> >> + kproc->ti_sci_id))
> >> + dev_warn(dev, "module-reset assert back failed\n");
> >> + }
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +/*
> >> + * Power up the DSP remote processor.
> >> + *
> >> + * This function will be invoked only after the firmware for this rproc
> >> + * was loaded, parsed successfully, and all of its resource requirements
> >> + * were met.
> >> + */
> >> +static int k3_dsp_rproc_start(struct rproc *rproc)
> >> +{
> >> + struct k3_dsp_rproc *kproc = rproc->priv;
> >> + struct mbox_client *client = &kproc->client;
> >> + struct device *dev = kproc->dev;
> >> + u32 boot_addr;
> >> + int ret;
> >> +
> >> + client->dev = dev;
> >> + client->tx_done = NULL;
> >> + client->rx_callback = k3_dsp_rproc_mbox_callback;
> >> + client->tx_block = false;
> >> + client->knows_txdone = false;
> >> +
> >> + kproc->mbox = mbox_request_channel(client, 0);
> >> + if (IS_ERR(kproc->mbox)) {
> >> + ret = -EBUSY;
> >> + dev_err(dev, "mbox_request_channel failed: %ld\n",
> >> + PTR_ERR(kproc->mbox));
> >> + return ret;
> >> + }
> >> +
> >> + /*
> >> + * Ping the remote processor, this is only for sanity-sake for now;
> >> + * there is no functional effect whatsoever.
> >> + *
> >> + * Note that the reply will _not_ arrive immediately: this message
> >> + * will wait in the mailbox fifo until the remote processor is booted.
> >> + */
> >> + ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
> >> + if (ret < 0) {
> >> + dev_err(dev, "mbox_send_message failed: %d\n", ret);
> >> + goto put_mbox;
> >> + }
> >> +
> >> + boot_addr = rproc->bootaddr;
> >> + if (boot_addr & (kproc->data->boot_align_addr - 1)) {
> >> + dev_err(dev, "invalid boot address 0x%x, must be aligned on a 0x%x boundary\n",
> >> + boot_addr, kproc->data->boot_align_addr);
> >> + ret = -EINVAL;
> >> + goto put_mbox;
> >> + }
> >> +
> >> + dev_err(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
> >> + ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0);
> >> + if (ret)
> >> + goto put_mbox;
> >> +
> >> + ret = k3_dsp_rproc_release(kproc);
> >> + if (ret)
> >> + goto put_mbox;
> >> +
> >> + return 0;
> >> +
> >> +put_mbox:
> >> + mbox_free_channel(kproc->mbox);
> >> + return ret;
> >> +}
> >> +
> >> +/*
> >> + * Stop the DSP remote processor.
> >> + *
> >> + * This function puts the DSP processor into reset, and finishes processing
> >> + * of any pending messages.
> >> + */
> >> +static int k3_dsp_rproc_stop(struct rproc *rproc)
> >> +{
> >> + struct k3_dsp_rproc *kproc = rproc->priv;
> >> +
> >> + mbox_free_channel(kproc->mbox);
> >> +
> >> + k3_dsp_rproc_reset(kproc);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +/*
> >> + * Custom function to translate a DSP device address (internal RAMs only) to a
> >> + * kernel virtual address. The DSPs can access their RAMs at either an internal
> >> + * address visible only from a DSP, or at the SoC-level bus address. Both these
> >> + * addresses need to be looked through for translation. The translated addresses
> >> + * can be used either by the remoteproc core for loading (when using kernel
> >> + * remoteproc loader), or by any rpmsg bus drivers.
> >> + */
> >> +static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> >> +{
> >> + struct k3_dsp_rproc *kproc = rproc->priv;
> >> + void __iomem *va = NULL;
> >> + phys_addr_t bus_addr;
> >> + u32 dev_addr, offset;
> >> + size_t size;
> >> + int i;
> >> +
> >> + if (len == 0)
> >> + return NULL;
> >> +
> >> + for (i = 0; i < kproc->num_mems; i++) {
> >> + bus_addr = kproc->mem[i].bus_addr;
> >> + dev_addr = kproc->mem[i].dev_addr;
> >> + size = kproc->mem[i].size;
> >> +
> >> + if (da < KEYSTONE_RPROC_LOCAL_ADDRESS_MASK) {
> >> + /* handle DSP-view addresses */
> >> + if (da >= dev_addr &&
> >> + ((da + len) <= (dev_addr + size))) {
> >> + offset = da - dev_addr;
> >> + va = kproc->mem[i].cpu_addr + offset;
> >> + return (__force void *)va;
> >> + }
> >> + } else {
> >> + /* handle SoC-view addresses */
> >> + if (da >= bus_addr &&
> >> + (da + len) <= (bus_addr + size)) {
> >> + offset = da - bus_addr;
> >> + va = kproc->mem[i].cpu_addr + offset;
> >> + return (__force void *)va;
> >> + }
> >> + }
> >> + }
> >> +
> >> + /* handle static DDR reserved memory regions */
> >> + for (i = 0; i < kproc->num_rmems; i++) {
> >> + dev_addr = kproc->rmem[i].dev_addr;
> >> + size = kproc->rmem[i].size;
> >> +
> >> + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> >> + offset = da - dev_addr;
> >> + va = kproc->rmem[i].cpu_addr + offset;
> >> + return (__force void *)va;
> >> + }
> >> + }
> >> +
> >> + return NULL;
> >> +}
> >> +
> >> +static const struct rproc_ops k3_dsp_rproc_ops = {
> >> + .start = k3_dsp_rproc_start,
> >> + .stop = k3_dsp_rproc_stop,
> >> + .kick = k3_dsp_rproc_kick,
> >> + .da_to_va = k3_dsp_rproc_da_to_va,
> >> +};
> >> +
> >> +static const char *k3_dsp_rproc_get_firmware(struct device *dev)
> >> +{
> >> + const char *fw_name;
> >> + int ret;
> >> +
> >> + ret = of_property_read_string(dev->of_node, "firmware-name",
> >> + &fw_name);
> >> + if (ret) {
> >> + dev_err(dev, "failed to parse firmware-name property, ret = %d\n",
> >> + ret);
> >> + return ERR_PTR(ret);
> >> + }
> >> +
> >> + return fw_name;
> >> +}
> >
> > The above is a carbon copy of k3_r5_rproc_get_firmware(). Please reuse the same
> > function.
>
> Yeah, I can add this as a common helper to rproc core, would be useful
> beyond just the TI rproc drivers.
>
> >
> >> +
> >> +static int k3_dsp_rproc_of_get_memories(struct platform_device *pdev,
> >> + struct k3_dsp_rproc *kproc)
> >> +{
> >> + const struct k3_dsp_dev_data *data = kproc->data;
> >> + struct device *dev = &pdev->dev;
> >> + struct resource *res;
> >> + int num_mems = 0;
> >> + int i;
> >> +
> >> + num_mems = kproc->data->num_mems;
> >> + kproc->mem = devm_kcalloc(kproc->dev, num_mems,
> >> + sizeof(*kproc->mem), GFP_KERNEL);
> >> + if (!kproc->mem)
> >> + return -ENOMEM;
> >> +
> >> + for (i = 0; i < num_mems; i++) {
> >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> + data->mems[i].name);
> >> + if (!res) {
> >> + dev_err(dev, "found no memory resource for %s\n",
> >> + data->mems[i].name);
> >> + return -EINVAL;
> >> + }
> >> + if (!devm_request_mem_region(dev, res->start,
> >> + resource_size(res),
> >> + dev_name(dev))) {
> >> + dev_err(dev, "could not request %s region for resource\n",
> >> + data->mems[i].name);
> >> + return -EBUSY;
> >> + }
> >> +
> >> + kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
> >> + resource_size(res));
> >> + if (IS_ERR(kproc->mem[i].cpu_addr)) {
> >> + dev_err(dev, "failed to map %s memory\n",
> >> + data->mems[i].name);
> >> + return PTR_ERR(kproc->mem[i].cpu_addr);
> >> + }
> >> + kproc->mem[i].bus_addr = res->start;
> >> + kproc->mem[i].dev_addr = data->mems[i].dev_addr;
> >> + kproc->mem[i].size = resource_size(res);
> >> +
> >> + dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> >> + data->mems[i].name, &kproc->mem[i].bus_addr,
> >> + kproc->mem[i].size, kproc->mem[i].cpu_addr,
> >> + kproc->mem[i].dev_addr);
> >> +
> >> + /* zero out memories to start in a pristine state */
> >> + /*
> >> + * FIXME: comment out until kernel crash is fixed, possible
> >> + * issue with local resets.
> >> + * memset((__force void *)kproc->mem[i].cpu_addr, 0,
> >> + * kproc->mem[i].size);
> >> + */
> >
> > Things still work without zero'ing out the memory? As such is it mandatory to
> > do so? Function k3_r5_core_of_get_internal_memories does not do a memset(). And
> > didn't Peng also had this problem?
>
> This is a stale comment, I will clean this up. The zeroing out is not
> strictly needed, it is only to ensure that the DSPs are started in a
> pristine condition. The issue is unrelated to what Peng reported, it is
> not the ARM memset issue (which won't be an issue since I am already
> using the ioremap_wc variant), but rather related to device being
> powered-on to be able to access the DSP internal memories from ARM. This
> won't be powered on at the time this function is invoked anyway. The R5F
> does needs to memzero it for ECC reasons, and does so in the
> k3_r5_rproc_prepare().
>
> >
> >> + }
> >> + kproc->num_mems = num_mems;
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int k3_dsp_reserved_mem_init(struct k3_dsp_rproc *kproc)
> >> +{
> >> + struct device *dev = kproc->dev;
> >> + struct device_node *np = dev->of_node;
> >> + struct device_node *rmem_np;
> >> + struct reserved_mem *rmem;
> >> + int num_rmems;
> >> + int ret, i;
> >> +
> >> + num_rmems = of_property_count_elems_of_size(np, "memory-region",
> >> + sizeof(phandle));
> >> + if (num_rmems <= 0) {
> >> + dev_err(dev, "device does not reserved memory regions, ret = %d\n",
> >> + num_rmems);
> >> + return -EINVAL;
> >> + }
> >> + if (num_rmems < 2) {
> >> + dev_err(dev, "device needs atleast two memory regions to be defined, num = %d\n",
> >> + num_rmems);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + /* use reserved memory region 0 for vring DMA allocations */
> >> + ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
> >> + if (ret) {
> >> + dev_err(dev, "device cannot initialize DMA pool, ret = %d\n",
> >> + ret);
> >> + return ret;
> >> + }
> >> +
> >> + num_rmems--;
> >> + kproc->rmem = kcalloc(num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
> >> + if (!kproc->rmem) {
> >> + ret = -ENOMEM;
> >> + goto release_rmem;
> >> + }
> >> +
> >> + /* use remaining reserved memory regions for static carveouts */
> >> + for (i = 0; i < num_rmems; i++) {
> >> + rmem_np = of_parse_phandle(np, "memory-region", i + 1);
> >> + if (!rmem_np) {
> >> + ret = -EINVAL;
> >> + goto unmap_rmem;
> >> + }
> >> +
> >> + rmem = of_reserved_mem_lookup(rmem_np);
> >> + if (!rmem) {
> >> + of_node_put(rmem_np);
> >> + ret = -EINVAL;
> >> + goto unmap_rmem;
> >> + }
> >> + of_node_put(rmem_np);
> >> +
> >> + kproc->rmem[i].bus_addr = rmem->base;
> >> + /* 64-bit address regions currently not supported */
> >> + kproc->rmem[i].dev_addr = (u32)rmem->base;
> >> + kproc->rmem[i].size = rmem->size;
> >> + kproc->rmem[i].cpu_addr = ioremap_wc(rmem->base, rmem->size);
> >> + if (!kproc->rmem[i].cpu_addr) {
> >> + dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
> >> + i + 1, &rmem->base, &rmem->size);
> >> + ret = -ENOMEM;
> >> + goto unmap_rmem;
> >> + }
> >> +
> >> + dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> >> + i + 1, &kproc->rmem[i].bus_addr,
> >> + kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
> >> + kproc->rmem[i].dev_addr);
> >> + }
> >> + kproc->num_rmems = num_rmems;
> >> +
> >> + return 0;
> >> +
> >> +unmap_rmem:
> >> + for (i--; i >= 0; i--) {
> >> + if (kproc->rmem[i].cpu_addr)
> >> + iounmap(kproc->rmem[i].cpu_addr);
> >> + }
> >> + kfree(kproc->rmem);
> >> +release_rmem:
> >> + of_reserved_mem_device_release(kproc->dev);
> >> + return ret;
> >> +}
> >
> > Other than the type of structure passed to the function, this is an exact
> > replica of k3_r5_reserved_mem_init(). Do you foresee either of them changing
> > to a point where reusing code would be counter productive? I think we are right
> > on the edge where duplication is better than using the same function.
>
> Yeah, nothing at the moment. The number of regions can change, I have
> not enabled the support for addresses beyond 32-bit atm, so that is
> another factor.
>
Right, it is entirely up to you to make the call. Lease as is or
reused based on what you think is best.
> >
> >> +
> >> +static void k3_dsp_reserved_mem_exit(struct k3_dsp_rproc *kproc)
> >> +{
> >> + int i;
> >> +
> >> + for (i = 0; i < kproc->num_rmems; i++)
> >> + iounmap(kproc->rmem[i].cpu_addr);
> >> + kfree(kproc->rmem);
> >> +
> >> + of_reserved_mem_device_release(kproc->dev);
> >> +}
> >> +
> >> +static
> >> +struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
> >> + const struct ti_sci_handle *sci)
> >> +{
> >> + struct ti_sci_proc *tsp;
> >> + u32 temp[2];
> >> + int ret;
> >> +
> >> + ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
> >> + temp, 2);
> >> + if (ret < 0)
> >> + return ERR_PTR(ret);
> >> +
> >> + tsp = kzalloc(sizeof(*tsp), GFP_KERNEL);
> >> + if (!tsp)
> >> + return ERR_PTR(-ENOMEM);
> >> +
> >> + tsp->dev = dev;
> >> + tsp->sci = sci;
> >> + tsp->ops = &sci->ops.proc_ops;
> >> + tsp->proc_id = temp[0];
> >> + tsp->host_id = temp[1];
> >> +
> >> + return tsp;
> >> +}
> >
> > Contrary to k3_dsp_reserved_mem_init(), this one can definitely be reused for
> > both c66 and r5.
>
> Yeah, but is it worth it introduce a common module for one function?
> Little bit large to define this as an inline function like I have done
> with most of the ti_sci_proc helpers.
>
I see your point.
> >
> >> +
> >> +static int k3_dsp_rproc_probe(struct platform_device *pdev)
> >> +{
> >> + struct device *dev = &pdev->dev;
> >> + struct device_node *np = dev->of_node;
> >> + const struct k3_dsp_dev_data *data;
> >> + struct k3_dsp_rproc *kproc;
> >> + struct rproc *rproc;
> >> + const char *fw_name;
> >> + int ret = 0;
> >> + int ret1;
> >> +
> >> + data = of_device_get_match_data(dev);
> >> + if (!data)
> >> + return -ENODEV;
> >> +
> >> + fw_name = k3_dsp_rproc_get_firmware(dev);
> >> + if (IS_ERR(fw_name))
> >> + return PTR_ERR(fw_name);
> >> +
> >> + rproc = rproc_alloc(dev, dev_name(dev), &k3_dsp_rproc_ops, fw_name,
> >> + sizeof(*kproc));
> >> + if (!rproc)
> >> + return -ENOMEM;
> >> +
> >> + rproc->has_iommu = false;
> >> + rproc->recovery_disabled = true;
> >> + kproc = rproc->priv;
> >> + kproc->rproc = rproc;
> >> + kproc->dev = dev;
> >> + kproc->data = data;
> >> +
> >> + kproc->ti_sci = ti_sci_get_by_phandle(np, "ti,sci");
> >> + if (IS_ERR(kproc->ti_sci)) {
> >> + ret = PTR_ERR(kproc->ti_sci);
> >> + if (ret != -EPROBE_DEFER) {
> >> + dev_err(dev, "failed to get ti-sci handle, ret = %d\n",
> >> + ret);
> >> + }
> >> + kproc->ti_sci = NULL;
> >> + goto free_rproc;
> >> + }
> >> +
> >> + ret = of_property_read_u32(np, "ti,sci-dev-id", &kproc->ti_sci_id);
> >> + if (ret) {
> >> + dev_err(dev, "missing 'ti,sci-dev-id' property\n");
> >> + goto put_sci;
> >> + }
> >> +
> >> + kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
> >> + if (IS_ERR(kproc->reset)) {
> >> + ret = PTR_ERR(kproc->reset);
> >> + dev_err(dev, "failed to get reset, status = %d\n", ret);
> >> + goto put_sci;
> >> + }
> >> +
> >> + kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
> >> + if (IS_ERR(kproc->tsp)) {
> >> + dev_err(dev, "failed to construct ti-sci proc control, ret = %d\n",
> >> + ret);
> >> + ret = PTR_ERR(kproc->tsp);
> >> + goto put_sci;
> >> + }
> >> +
> >> + ret = ti_sci_proc_request(kproc->tsp);
> >> + if (ret < 0) {
> >> + dev_err(dev, "ti_sci_proc_request failed, ret = %d\n", ret);
> >> + goto free_tsp;
> >> + }
> >> +
> >> + pm_runtime_enable(dev);
> >> + ret = pm_runtime_get_sync(dev);
> >
> > What do these give you since the dev_pm_ops is not set for the
> > k3_dsp_rproc_driver platform diver and there is no clock specified in the DT?
>
> Yeah, I can drop this. Adding a clock in DT would not have made any
> difference here, but a power-domains property would have. And I don't
> use the power-domains property because of the genpd handling in driver
> core that messes with the device state.
>
> regards
> Sumahn
>
> >
> > Thanks,
> > Mathieu
> >
> >> + if (ret < 0) {
> >> + dev_err(dev, "failed to enable clock, status = %d\n", ret);
> >> + pm_runtime_put_noidle(dev);
> >> + goto disable_rpm;
> >> + }
> >> +
> >> + ret = k3_dsp_rproc_of_get_memories(pdev, kproc);
> >> + if (ret)
> >> + goto disable_clk;
> >> +
> >> + ret = k3_dsp_reserved_mem_init(kproc);
> >> + if (ret) {
> >> + dev_err(dev, "reserved memory init failed, ret = %d\n", ret);
> >> + goto disable_clk;
> >> + }
> >> +
> >> + ret = rproc_add(rproc);
> >> + if (ret) {
> >> + dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
> >> + ret);
> >> + goto release_mem;
> >> + }
> >> +
> >> + platform_set_drvdata(pdev, kproc);
> >> +
> >> + return 0;
> >> +
> >> +release_mem:
> >> + k3_dsp_reserved_mem_exit(kproc);
> >> +disable_clk:
> >> + pm_runtime_put_sync(dev);
> >> +disable_rpm:
> >> + pm_runtime_disable(dev);
> >> + ret1 = ti_sci_proc_release(kproc->tsp);
> >> + if (ret1)
> >> + dev_err(dev, "failed to release proc, ret = %d\n", ret1);
> >> +free_tsp:
> >> + kfree(kproc->tsp);
> >> +put_sci:
> >> + ret1 = ti_sci_put_handle(kproc->ti_sci);
> >> + if (ret1)
> >> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret1);
> >> +free_rproc:
> >> + rproc_free(rproc);
> >> + return ret;
> >> +}
> >> +
> >> +static int k3_dsp_rproc_remove(struct platform_device *pdev)
> >> +{
> >> + struct k3_dsp_rproc *kproc = platform_get_drvdata(pdev);
> >> + struct device *dev = &pdev->dev;
> >> + int ret;
> >> +
> >> + rproc_del(kproc->rproc);
> >> + pm_runtime_put_sync(&pdev->dev);
> >> + pm_runtime_disable(&pdev->dev);
> >> +
> >> + ret = ti_sci_proc_release(kproc->tsp);
> >> + if (ret)
> >> + dev_err(dev, "failed to release proc, ret = %d\n", ret);
> >> +
> >> + kfree(kproc->tsp);
> >> +
> >> + ret = ti_sci_put_handle(kproc->ti_sci);
> >> + if (ret)
> >> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret);
> >> +
> >> + k3_dsp_reserved_mem_exit(kproc);
> >> + rproc_free(kproc->rproc);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static const struct k3_dsp_mem_data c66_mems[] = {
> >> + { .name = "l2sram", .dev_addr = 0x800000 },
> >> + { .name = "l1pram", .dev_addr = 0xe00000 },
> >> + { .name = "l1dram", .dev_addr = 0xf00000 },
> >> +};
> >> +
> >> +static const struct k3_dsp_dev_data c66_data = {
> >> + .mems = c66_mems,
> >> + .num_mems = ARRAY_SIZE(c66_mems),
> >> + .boot_align_addr = SZ_1K,
> >> + .uses_lreset = true,
> >> +};
> >> +
> >> +static const struct of_device_id k3_dsp_of_match[] = {
> >> + { .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
> >> + { /* sentinel */ },
> >> +};
> >> +MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
> >> +
> >> +static struct platform_driver k3_dsp_rproc_driver = {
> >> + .probe = k3_dsp_rproc_probe,
> >> + .remove = k3_dsp_rproc_remove,
> >> + .driver = {
> >> + .name = "k3-dsp-rproc",
> >> + .of_match_table = k3_dsp_of_match,
> >> + },
> >> +};
> >> +
> >> +module_platform_driver(k3_dsp_rproc_driver);
> >> +
> >> +MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
> >> +MODULE_LICENSE("GPL v2");
> >> +MODULE_DESCRIPTION("TI K3 DSP Remoteproc driver");
> >> --
> >> 2.23.0
> >>
>
^ permalink raw reply
* Re: [PATCH net-next v1] net: phy: tja11xx: add cable-test support
From: David Miller @ 2020-05-13 19:36 UTC (permalink / raw)
To: o.rempel
Cc: andrew, f.fainelli, hkallweit1, mark.rutland, robh+dt, kernel,
linux-kernel, netdev, marex, david, devicetree
In-Reply-To: <20200513123440.19580-1-o.rempel@pengutronix.de>
From: Oleksij Rempel <o.rempel@pengutronix.de>
Date: Wed, 13 May 2020 14:34:40 +0200
> Add initial cable testing support.
> This PHY needs only 100usec for this test and it is recommended to run it
> before the link is up. For now, provide at least ethtool support, so it
> can be tested by more developers.
>
> This patch was tested with TJA1102 PHY with following results:
> - No cable, is detected as open
> - 1m cable, with no connected other end and detected as open
> - a 40m cable (out of spec, max lenght should be 15m) is detected as OK.
>
> Current patch do not provide polarity test support. This test would
> indicate not proper wire connection, where "+" wire of main phy is
> connected to the "-" wire of the link partner.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v1] net: phy: tja11xx: add cable-test support
From: Florian Fainelli @ 2020-05-13 19:34 UTC (permalink / raw)
To: Oleksij Rempel, Andrew Lunn, Heiner Kallweit, Mark Rutland,
Rob Herring
Cc: Pengutronix Kernel Team, linux-kernel, David S. Miller, netdev,
Marek Vasut, David Jander, devicetree
In-Reply-To: <20200513123440.19580-1-o.rempel@pengutronix.de>
On 5/13/2020 5:34 AM, Oleksij Rempel wrote:
> Add initial cable testing support.
> This PHY needs only 100usec for this test and it is recommended to run it
> before the link is up. For now, provide at least ethtool support, so it
> can be tested by more developers.
>
> This patch was tested with TJA1102 PHY with following results:
> - No cable, is detected as open
> - 1m cable, with no connected other end and detected as open
> - a 40m cable (out of spec, max lenght should be 15m) is detected as OK.
>
> Current patch do not provide polarity test support. This test would
> indicate not proper wire connection, where "+" wire of main phy is
> connected to the "-" wire of the link partner.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v1] net: phy: tja11xx: add cable-test support
From: Andrew Lunn @ 2020-05-13 19:30 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Mark Rutland, Marek Vasut, Florian Fainelli, devicetree, netdev,
linux-kernel, Rob Herring, Pengutronix Kernel Team, David Jander,
David S. Miller, Heiner Kallweit
In-Reply-To: <20200513174011.kl6l767cimeo6dpy@pengutronix.de>
> > Do these registers all conform to the standard? Can we pull this code
> > out into a library which all standards conformant PHY drivers can use?
>
> According to opensig, this functionality should be present on all new T1 PHYs.
> But the register/bit layout is no specified as standard. At least I was not able
> to find it. I assume, current layout is TJA11xx specific.
O.K. then:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: omap4-droid4: Configure modem for serdev-ngsm
From: Pavel Machek @ 2020-05-13 19:27 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, Johan Hovold, Rob Herring, Alan Cox,
Lee Jones, Jiri Slaby, Merlijn Wajer, Peter Hurley,
Sebastian Reichel, linux-serial, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20200512214713.40501-7-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
On Tue 2020-05-12 14:47:13, Tony Lindgren wrote:
> Let's enable the TS 27.010 /dev/gsmmux* interfaces via Linux n_gsm that
> can be used for voice calls and SMS with commands using a custom Motorola
> format.
>
> And let's also enable the kernel GNSS driver via serdev-ngsm that uses a
> dedicated TS 27.010 channel.
>
> Note that voice call audio mixer is not supported yet.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: serdev: ngsm: Add binding for GNSS child node
From: Pavel Machek @ 2020-05-13 19:26 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, Johan Hovold, Rob Herring, Alan Cox,
Lee Jones, Jiri Slaby, Merlijn Wajer, Peter Hurley,
Sebastian Reichel, linux-serial, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20200512214713.40501-4-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
On Tue 2020-05-12 14:47:10, Tony Lindgren wrote:
> For motorola modem case, we may have a GNSS device on channel 4.
> Let's add that to the binding and example.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
BTW it looks like Alan's email address no longer works.
<gnomes@lxorguk.ukuu.org.uk>: host mail.llwyncelyn.cymru[82.70.14.225] said:
550 5.1.1 <gnomes@lxorguk.ukuu.org.uk>... User unknown (in reply to RCPT TO
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] tty: n_gsm: Add support for serdev drivers
From: Pavel Machek @ 2020-05-13 19:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, Johan Hovold, Rob Herring, Alan Cox,
Lee Jones, Jiri Slaby, Merlijn Wajer, Peter Hurley,
Sebastian Reichel, linux-serial, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20200512214713.40501-2-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
On Tue 2020-05-12 14:47:08, Tony Lindgren wrote:
> We can make use of serdev drivers to do simple device drivers for
> TS 27.010 chanels, and we can handle vendor specific protocols on top
> of TS 27.010 with serdev drivers.
>
> So far this has been tested with Motorola droid4 where there is a custom
> packet numbering protocol on top of TS 27.010 for the MDM6600 modem.
>
> I initially though about adding the serdev support into a separate file,
> but that will take some refactoring of n_gsm.c. And I'd like to have
> things working first. Then later on we might want to consider splitting
> n_gsm.c into three pieces for core, tty and serdev parts. And then maybe
> the serdev related parts can be just moved to live under something like
> drivers/tty/serdev/protocol/ngsm.c.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
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