* [PATCH v2 2/4] ARM: dts: imx6dl-riotboard: remove regulators bus node
From: Alexander Kurz @ 2018-05-29 6:20 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, devicetree, Alexander Kurz, linux-arm-kernel
In-Reply-To: <20180529062021.3154-1-akurz@blala.de>
To match the convention, move regulator-fixed nodes directly into
the root node.
Signed-off-by: Alexander Kurz <akurz@blala.de>
---
arch/arm/boot/dts/imx6dl-riotboard.dts | 55 ++++++++++++++--------------------
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 2e98c92adff7..a6851bfebbdb 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -19,38 +19,6 @@
reg = <0x10000000 0x40000000>;
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg_2p5v: regulator@0 {
- compatible = "regulator-fixed";
- reg = <0>;
- regulator-name = "2P5V";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- };
-
- reg_3p3v: regulator@1 {
- compatible = "regulator-fixed";
- reg = <1>;
- regulator-name = "3P3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- reg_usb_otg_vbus: regulator@2 {
- compatible = "regulator-fixed";
- reg = <2>;
- regulator-name = "usb_otg_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio3 22 0>;
- enable-active-high;
- };
- };
-
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -82,6 +50,29 @@
mux-int-port = <1>;
mux-ext-port = <3>;
};
+
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_usb_otg_vbus: regulator-usbotgvbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&audmux {
--
2.11.0
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: imx6qdl-wandboard: enable USB OTG
From: Alexander Kurz @ 2018-05-29 6:20 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, devicetree, Alexander Kurz, linux-arm-kernel
In-Reply-To: <20180529062021.3154-1-akurz@blala.de>
Enable USB OTG (dual-role) on the Wandboard.
Note, that the USB_OTG_VBUS current is quite limited due to a 22R resistor
in the power line. Hence, the overcurrent signal of 1A will never be
triggered on this board.
Signed-off-by: Alexander Kurz <akurz@blala.de>
---
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index b9c6c9d5d357..01ee36af7ba4 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -48,6 +48,16 @@
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
+
+ reg_usb_otg_vbus: regulator-usbotgvbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotgvbus>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_LOW>;
+ };
};
&audmux {
@@ -162,6 +172,12 @@
>;
};
+ pinctrl_usbotgvbus: usbotgvbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17059
@@ -236,10 +252,11 @@
};
&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbotg>;
disable-over-current;
- dr_mode = "peripheral";
+ dr_mode = "otg";
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: imx6dl-riotboard: fix OTG regulator polarity
From: Alexander Kurz @ 2018-05-29 6:20 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, devicetree, Alexander Kurz, linux-arm-kernel
In-Reply-To: <20180529062021.3154-1-akurz@blala.de>
USB OTG power is switched on when the GPIO is pulled low.
Signed-off-by: Alexander Kurz <akurz@blala.de>
---
arch/arm/boot/dts/imx6dl-riotboard.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
index a6851bfebbdb..89b06e20480d 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -70,8 +70,7 @@
regulator-name = "usb_otg_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
- enable-active-high;
+ gpio = <&gpio3 22 GPIO_ACTIVE_LOW>;
};
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 0/2] Add Mediatek X20 Development Board support
From: Matthias Brugger @ 2018-05-29 6:38 UTC (permalink / raw)
To: Manivannan Sadhasivam, robh+dt
Cc: linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
taiten.peng, daniel.thompson, amit.kucheria, manivannanece23,
Mars Cheng, Saber Rezvani
In-Reply-To: <20180529045258.1415-1-manivannan.sadhasivam@linaro.org>
Hi Manivannan,
it's nice to see that someone at Linaro cares about upstreaming the 96 board.
>From what I can see, your patches add the very same support to the board as
does the mt6797 evaluation board. Do you have plans to upstream more drivers for
the board? Do you have a roadmap or something?
I'm asking becuase I don't want to have just another dead devicetree in the
kernel which does nothing but provides a boot to rootfs. Especially as this can
be achieved on the same board with the EVB dts.
Regards,
Matthias
On 29/05/18 06:52, Manivannan Sadhasivam wrote:
> Add devicetree support for Mediatek X20 Development Board by Archermind.
> This board is based on the Deca-Core MT6797 SoC from Mediatek and is
> one of the 96Boards Consumer Edition platform.
>
> With this devicetree change, board can boot into initramfs.
>
> More information about this board can be found in 96Boards product page:
> https://www.96boards.org/product/mediatek-x20/
>
> Manivannan Sadhasivam (2):
> dt-bindings: Add vendor prefix for ArcherMind
> arm64: dts: Add Mediatek X20 Development Board support
>
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
> 3 files changed, 35 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>
^ permalink raw reply
* Re: [PATCH v7 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
From: Andrzej Hajda @ 2018-05-29 6:41 UTC (permalink / raw)
To: Sandeep Panda, dri-devel, linux-arm-msm, freedreno, devicetree
Cc: hoegsberg, chandanu, ryadav, abhinavk
In-Reply-To: <1527180079-12721-3-git-send-email-spanda@codeaurora.org>
On 24.05.2018 18:41, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>
> Changes in v1:
> - Rephrase the dt-binding descriptions to be more inline with existing
> bindings (Andrzej Hajda).
> - Add missing dt-binding that are parsed by corresponding driver
> (Andrzej Hajda).
>
> Changes in v2:
> - Remove edp panel specific dt-binding entries. Only keep bridge
> specific entries (Sean Paul).
> - Remove custom-modes dt entry since its usage is removed from driver also (Sean Paul).
> - Remove is-pluggable dt entry since this will not be needed anymore (Sean Paul).
>
> Changes in v3:
> - Remove irq-gpio dt entry and instead populate is an interrupt
> property (Rob Herring).
>
> Changes in v4:
> - Add link to bridge chip datasheet (Stephen Boyd)
> - Add vpll and vcc regulator supply bindings (Stephen Boyd)
> - Add ref clk optional dt binding (Stephen Boyd)
> - Add gpio-controller optional dt binding (Stephen Boyd)
>
> Changes in v5:
> - Use clock property to specify the input refclk (Stephen Boyd).
> - Update gpio cell and pwm cell numbers (Stephen Boyd).
>
> Changes in v6:
> - Add property to mention the lane mapping scheme and polarity inversion
> (Stephen Boyd).
>
> Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
> ---
> .../bindings/display/bridge/ti,sn65dsi86.txt | 89 ++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 0000000..4a771a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,89 @@
> +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: OF device-tree gpio specification for bridge_en pin
info about active high should be added
> +
> +- 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: Specifier for the SN65DSI86 interrupt line.
> +- hpd-gpios: Specifications for HPD gpio pin.
Again, please specify active level.
> +
> +- 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.txt 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.
> +
> +- lane-config: Specification to describe the logical to physical lane
> + mapping scheme and polarity inversion of lanes.
Please describe this property, I guess it is about DSI lanes, and it
should be exact(?) four pair of numbers, what are meaning and ranges of
both numbers. What should be assumed if property is not present. Btw you
can look into other bindings for reference, I guess there are already
bindings having such property.
Regards
Andrzej
> +
> +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>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <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>;
> +
> + lane-config = <0 0>, /* Lane 0 logical is lane 0 phys (!inv) */
> + <1 1>, /* Lane 1 logical is lane 1 phys (inv) */
> + <2 0>, /* Lane 2 logical is lane 2 phys (!inv) */
> + <3 1>; /* Lane 3 logical is lane 3 phys (inv) */
> +
> + 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 {
> + remote-endpoint = <&edp_panel_in>;
> + };
> + };
> + };
> +}
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
From: Geert Uytterhoeven @ 2018-05-29 6:48 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Simon Horman, Catalin Marinas, Magnus Damm, open list,
DRI Development, Linux-Renesas, Rob Herring, Kieran Bingham,
Laurent Pinchart, Will Deacon,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)
In-Reply-To: <8736yb5jez.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On Tue, May 29, 2018 at 3:44 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> > +&hdmi0_con {
>> > + remote-endpoint = <&rcar_dw_hdmi0_out>;
>> > +};
>>
>> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
>> Can we do that now (with stubs?), or does this have to wait until r8a77965 has
>> received HDMI sound support?
>
> HDMI sound doesn't use hdmi0_con.
> You can do it now, thanks
Thanks, so hdmi0_con can be moved now.
But HDMI sound does use hdmi0/ports/port@2. right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Javier Martinez Canillas @ 2018-05-29 7:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Mark Rutland, Kukjin Kim, Pankaj Dubey,
Bartlomiej Zolnierkiewicz, Marek Szyprowski, devicetree,
linux-arm-kernel, linux-samsung-soc, Linux Kernel, Chanwoo Choi,
Seung-Woo Kim, Inki Dae, Sylwester Nawrocki, Alim Akhtar,
Arnd Bergmann, Olof Johansson
In-Reply-To: <20180528191327.23772-1-krzk@kernel.org>
On Mon, May 28, 2018 at 9:13 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> From: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings, make development of new platforms easier and allow to make
> cleanup of the existing code and device tree files, lets mark some
> Samsung Exynos SoC platform bindings as unstable. This means that
> bindings can may change at any time and users should use the dtb file
> compiled from the same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
Javier
^ permalink raw reply
* Re: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Vinod @ 2018-05-29 7:07 UTC (permalink / raw)
To: Wen He; +Cc: dmaengine, robh+dt, devicetree, leoyang.li, jiafei.pan,
jiaheng.fan
In-Reply-To: <20180525111920.24498-2-wen.he_1@nxp.com>
On 25-05-18, 19:19, Wen He wrote:
> +/**
> + * struct fsl_qdma_format - This is the struct holding describing compound
> + * descriptor format with qDMA.
> + * @status: This field which describes command status and
> + * enqueue status notification.
> + * @cfg: This field which describes frame offset and frame
> + * format.
> + * @addr_lo: This field which indicating the start of the buffer
> + * holding the compound descriptor of the lower 32-bits
> + * address in memory 40-bit address.
> + * @addr_hi: This field's the same as above field, but point high
> + * 8-bits in memory 40-bit address.
> + * @__reserved1: Reserved field.
> + * @cfg8b_w1: This field which describes compound descriptor
> + * command queue origin produced by qDMA and dynamic
you may remove 'This field which describes'... in above lines, give reader no
information :)
> + * debug field.
> + * @data Pointer to the memory 40-bit address, describes DMA
> + * source informaion and DMA destination information.
typo informaion
> +static struct fsl_qdma_queue *fsl_qdma_alloc_queue_resources(
> + struct platform_device *pdev,
> + unsigned int queue_num)
> +{
> + struct fsl_qdma_queue *queue_head, *queue_temp;
> + int ret, len, i;
> + unsigned int queue_size[FSL_QDMA_QUEUE_MAX];
> +
> + if (queue_num > FSL_QDMA_QUEUE_MAX)
> + queue_num = FSL_QDMA_QUEUE_MAX;
> + len = sizeof(*queue_head) * queue_num;
> + queue_head = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
> + if (!queue_head)
> + return NULL;
> +
> + ret = device_property_read_u32_array(&pdev->dev, "queue-sizes",
> + queue_size, queue_num);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't get queue-sizes.\n");
> + return NULL;
> + }
> +
> + for (i = 0; i < queue_num; i++) {
> + if (queue_size[i] > FSL_QDMA_CIRCULAR_DESC_SIZE_MAX
> + || queue_size[i] < FSL_QDMA_CIRCULAR_DESC_SIZE_MIN) {
> + dev_err(&pdev->dev, "Get wrong queue-sizes.\n");
> + return NULL;
the indents here are bad for reading..
> +static int fsl_qdma_queue_transfer_complete(struct fsl_qdma_engine *fsl_qdma)
> +{
> + struct fsl_qdma_queue *fsl_queue = fsl_qdma->queue;
> + struct fsl_qdma_queue *fsl_status = fsl_qdma->status;
> + struct fsl_qdma_queue *temp_queue;
> + struct fsl_qdma_comp *fsl_comp;
> + struct fsl_qdma_format *status_addr;
> + struct fsl_qdma_format *csgf_src;
> + struct fsl_pre_status pre;
> + void __iomem *block = fsl_qdma->block_base;
> + u32 reg, i;
> + bool duplicate, duplicate_handle;
> +
> + memset(&pre, 0, sizeof(struct fsl_pre_status));
> +
> + while (1) {
> + duplicate = 0;
> + duplicate_handle = 0;
> + reg = qdma_readl(fsl_qdma, block + FSL_QDMA_BSQSR);
> + if (reg & FSL_QDMA_BSQSR_QE)
> + return 0;
> + status_addr = fsl_status->virt_head;
> + if (qdma_ccdf_get_queue(status_addr) == pre.queue &&
> + qdma_ccdf_addr_get64(status_addr) == pre.addr)
> + duplicate = 1;
> + i = qdma_ccdf_get_queue(status_addr);
> + pre.queue = qdma_ccdf_get_queue(status_addr);
> + pre.addr = qdma_ccdf_addr_get64(status_addr);
> + temp_queue = fsl_queue + i;
> + spin_lock(&temp_queue->queue_lock);
> + if (list_empty(&temp_queue->comp_used)) {
> + if (duplicate)
> + duplicate_handle = 1;
code style mandates braces for this as else has braces..
> + else {
> + spin_unlock(&temp_queue->queue_lock);
> + return -EAGAIN;
> + }
> + } else {
> + fsl_comp = list_first_entry(&temp_queue->comp_used,
> + struct fsl_qdma_comp,
> + list);
> + csgf_src = fsl_comp->virt_addr + 2;
> + if (fsl_comp->bus_addr + 16 != pre.addr) {
> + if (duplicate)
> + duplicate_handle = 1;
here as well
> +static irqreturn_t fsl_qdma_error_handler(int irq, void *dev_id)
> +{
> + struct fsl_qdma_engine *fsl_qdma = dev_id;
> + unsigned int intr;
> + void __iomem *status = fsl_qdma->status_base;
> +
> + intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
> +
> + if (intr)
> + dev_err(fsl_qdma->dma_dev.dev, "DMA transaction error!\n");
> +
> + qdma_writel(fsl_qdma, 0xffffffff, status + FSL_QDMA_DEDR);
why unconditional write, was expecting that you would write if intr is non null
> +static int fsl_qdma_reg_init(struct fsl_qdma_engine *fsl_qdma)
> +{
> + struct fsl_qdma_queue *fsl_queue = fsl_qdma->queue;
> + struct fsl_qdma_queue *temp;
> + void __iomem *ctrl = fsl_qdma->ctrl_base;
> + void __iomem *status = fsl_qdma->status_base;
> + void __iomem *block = fsl_qdma->block_base;
> + int i, ret;
> + u32 reg;
> +
> + /* Try to halt the qDMA engine first. */
> + ret = fsl_qdma_halt(fsl_qdma);
> + if (ret) {
> + dev_err(fsl_qdma->dma_dev.dev, "DMA halt failed!");
> + return ret;
> + }
> +
> + /*
> + * Clear the command queue interrupt detect register for all queues.
> + */
> + qdma_writel(fsl_qdma, 0xffffffff, block + FSL_QDMA_BCQIDR(0));
bunch of writes with 0xffffffff, can you explain why? Also helps to make a
macro for this
> +
> + for (i = 0; i < fsl_qdma->n_queues; i++) {
> + temp = fsl_queue + i;
> + /*
> + * Initialize Command Queue registers to point to the first
> + * command descriptor in memory.
> + * Dequeue Pointer Address Registers
> + * Enqueue Pointer Address Registers
> + */
> + qdma_writel(fsl_qdma, temp->bus_addr,
> + block + FSL_QDMA_BCQDPA_SADDR(i));
> + qdma_writel(fsl_qdma, temp->bus_addr,
> + block + FSL_QDMA_BCQEPA_SADDR(i));
> +
> + /* Initialize the queue mode. */
> + reg = FSL_QDMA_BCQMR_EN;
> + reg |= FSL_QDMA_BCQMR_CD_THLD(ilog2(temp->n_cq)-4);
> + reg |= FSL_QDMA_BCQMR_CQ_SIZE(ilog2(temp->n_cq)-6);
space around - in the above two lines
> +static enum dma_status fsl_qdma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie, struct dma_tx_state *txstate)
> +{
> + enum dma_status ret;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> + if (ret == DMA_COMPLETE || !txstate)
> + return ret;
> +
> + return ret;
hmmm, this seems same as return dma_cookie_status() so why should we have rest
of the code
> +static void fsl_qdma_issue_pending(struct dma_chan *chan)
> +{
> + struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
> + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&fsl_queue->queue_lock, flags);
> + spin_lock(&fsl_chan->vchan.lock);
> + if (vchan_issue_pending(&fsl_chan->vchan))
> + fsl_qdma_enqueue_desc(fsl_chan);
> + spin_unlock(&fsl_chan->vchan.lock);
> + spin_unlock_irqrestore(&fsl_queue->queue_lock, flags);
why do we need two locks, and since you are doing vchan why should you add your
own lock on top
...
Overall the patch has some code style issues which keep catching my eye, can
you please check them. Also would help to run checkpatch with --strict and
--codespell option to catch typos and alignment issue. Please beware checkpatch
is a guide and NOT a rulebook so use your discretion :)
--
~Vinod
^ permalink raw reply
* Re: [patch v22 1/4] drivers: jtag: Add JTAG core driver
From: Greg KH @ 2018-05-29 7:16 UTC (permalink / raw)
To: Oleksandr Shamray
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
openbmc@lists.ozlabs.org, joel@jms.id.au, jiri@resnulli.us,
tklauser@distanz.ch, linux-serial@vger.kernel.org,
Vadim Pasternak, system-sw-low-level, robh+dt@kernel.org,
openocd-devel-owner@lists.sourceforge.net,
linux-api@vger.kernel.org, davem
In-Reply-To: <AM5PR0501MB24490173AD50A2E478DFCF35B16E0@AM5PR0501MB2449.eurprd05.prod.outlook.com>
On Mon, May 28, 2018 at 03:59:46PM +0000, Oleksandr Shamray wrote:
> > > + const struct jtag_ops *ops;
> > > + int id;
> > > + bool opened;
> >
> > You shouldn't care about this, but ok...
>
> Jtag HW not support to using with multiple requests from different users. So we prohibit this.
Ok, but then that's a userspace problem, not your driver's problem.
Serial ports can't handle multiple requests in a sane way either, and so
it's a userspace bug if they do that. It's not up to the kernel to try
to prevent it, and really, you are not preventing this from happening at
all, you are only keeping more than one open() call from happening. You
aren't serializing the device access at all.
So you are giving yourself a false sense of "We are protecting the
device" here. Just drop the whole "only one open() call" logic
entirely. It will make your kernel code simpler and you aren't giving
yourself false-hope that you really prevented userspace from doing
something stupid :)
> > > + case JTAG_IOCRUNTEST:
> > > + if (copy_from_user(&idle, (const void __user *)arg,
> > > + sizeof(struct jtag_run_test_idle)))
> > > + return -EFAULT;
> > > +
> > > + if (idle.endstate > JTAG_STATE_PAUSEDR)
> > > + return -EINVAL;
> >
> > No validation that idle contains sane values? Don't make every jtag driver
> > have to do this type of validation please.
> >
>
> I have partially validation of idle structure (if (idle.endstate > JTAG_STATE_PAUSEDR)).
> But I will add more validation.
Go to the nearest whiteboard and write this at the top:
ALL INPUT IS EVIL
Don't erase it. You have to validate all the things, otherwise
something bad will happen, I guarantee it. Wait until the syzbot gets
ahold of this layer if you don't believe me :)
> > > +static int jtag_open(struct inode *inode, struct file *file) {
> > > + struct jtag *jtag = container_of(file->private_data, struct jtag,
> > > +miscdev);
> > > +
> > > + if (mutex_lock_interruptible(&jtag->open_lock))
> > > + return -ERESTARTSYS;
> >
> > Why restart? Just grab the lock, you don't want to have to do restartable
> > logic in userspace, right?
>
> Will change like:
>
> ret = mutex_lock_interruptible(&jtag->open_lock);
> if (ret)
> return ret;
No, what's wrong with a simple:
mutex_lock();
?
You are only holding it for a very short time, people can wait, there is
no rush here or "fast path" happening.
Anyway, this whole lock should just go away entirely, due to the lack of
needing to track open() calls. But in the future, keep locks simple, no
need to add complexity when it is not warranted.
> > > + if (jtag->opened) {
> > > + mutex_unlock(&jtag->open_lock);
> > > + return -EBUSY;
> >
> > Why do you care about only 1 userspace open call? What does that buy you?
> > Userspace can always pass around that file descriptor and use it in multiple
> > places, so you are not really "protecting" yourself from anything.
> >
>
> Accessing to JTAG HW from multiple processes will make confusion in the work of the JTAG protocol.
> And I want to prohibit this.
See my previous comments for why your attempt at protecting open() does
not prevent this from happening. Hint, you forgot about dup(3) :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/2] Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-05-29 7:27 UTC (permalink / raw)
To: Matthias Brugger
Cc: robh+dt, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel, taiten.peng, daniel.thompson, amit.kucheria,
manivannanece23, Mars Cheng, Saber Rezvani
In-Reply-To: <06dbc5ef-5bba-f3e0-1b57-3eaeab26ed68@gmail.com>
Hi Matthias,
On Tue, May 29, 2018 at 08:38:27AM +0200, Matthias Brugger wrote:
> Hi Manivannan,
>
> it's nice to see that someone at Linaro cares about upstreaming the 96 board.
> From what I can see, your patches add the very same support to the board as
> does the mt6797 evaluation board. Do you have plans to upstream more drivers for
> the board? Do you have a roadmap or something?
>
> I'm asking becuase I don't want to have just another dead devicetree in the
> kernel which does nothing but provides a boot to rootfs. Especially as this can
> be achieved on the same board with the EVB dts.
>
I can understand your concern here. I do have plans to add more drivers
in the future for this board but I can't give you any roadmap for that
since it mostly falls under the spare time work and I have been doing a
similar kind of work for the Bubblegum-96 board in parallel.
At most I can guarentee that this board's functionality will be added
gradually in upcoming days.
Thanks,
Mani
> Regards,
> Matthias
>
> On 29/05/18 06:52, Manivannan Sadhasivam wrote:
> > Add devicetree support for Mediatek X20 Development Board by Archermind.
> > This board is based on the Deca-Core MT6797 SoC from Mediatek and is
> > one of the 96Boards Consumer Edition platform.
> >
> > With this devicetree change, board can boot into initramfs.
> >
> > More information about this board can be found in 96Boards product page:
> > https://www.96boards.org/product/mediatek-x20/
> >
> > Manivannan Sadhasivam (2):
> > dt-bindings: Add vendor prefix for ArcherMind
> > arm64: dts: Add Mediatek X20 Development Board support
> >
> > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
> > 3 files changed, 35 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> >
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Lee Jones @ 2018-05-29 7:36 UTC (permalink / raw)
To: Amelie DELAUNAY
Cc: Linus Walleij, Rob Herring, Mark Rutland, Russell King,
Alexandre TORGUE, Maxime Coquelin, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM
In-Reply-To: <8d8b0f05-7f04-e718-7a45-148af38a03d4@st.com>
On Mon, 28 May 2018, Amelie DELAUNAY wrote:
> On 05/24/2018 09:13 AM, Linus Walleij wrote:
> > On Fri, May 18, 2018 at 9:29 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> >> On 05/17/2018 08:36 AM, Lee Jones wrote:
> >>> On Wed, 16 May 2018, Amelie DELAUNAY wrote:
> >>>> On 05/16/2018 04:20 PM, Linus Walleij wrote:
> >>>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> >>>>>
> >>>>>> Indeed, stmfx has other functions than GPIO. But, after comments done
> >>>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
> >>>>>> child drivers into a single PINCTRL/GPIO driver because of the following
> >>>>>> reasons:
> >>>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are
> >>>>>> not used on any of the boards using an stmfx and supported by Linux, so
> >>>>>> no way to test these functions, and no need to maintain them while they
> >>>>>> are not being used.
> >>>>>> - But, in the case a new board will use more than GPIO function on
> >>>>>> stmfx, the actual implementation allow to easily extract common init
> >>>>>> part of stmfx and put it in an MFD driver.
> >>>>>>
> >>>>>> So I could remove gpio sub-node and put its contents in stmfx node and
> >>>>>> keep single PINCTRL/GPIO driver for the time being.
> >>>>>> Please advise,
> >>>>>
> >>>>> I would normally advice to use the right modeling from the start, create
> >>>>> the MFD driver and spawn the devices from there. It is confusing
> >>>>> if the layout of the driver(s) doesn't really match the layout of the
> >>>>> hardware.
> >>>>>
> >>>>> I understand that it is a pain to write new MFD drivers to get your
> >>>>> things going and it would be "nice to get this working really quick
> >>>>> now" but in my experience it is better to do it right from the start.
> >>>>>
> >>>>
> >>>> Hi Linus,
> >>>>
> >>>> Thanks for your advice. I understand the point.
> >>>> So, the right modeling would be to:
> >>>> - create an MFD driver with the common init part of stmfx
> >>>> - remove all common init part of stmfx-pinctrl driver and keep only all
> >>>> gpio/pinctrl functions.
> >>>>
> >>>> I will not develop the other stmfx functions (IDD measurement driver and
> >>>> TouchScreen controller driver) because, as explained ealier, they are
> >>>> not used on any of the boards using an stmfx and supported by Linux, so
> >>>> no way to test these functions, and no need to maintain them while they
> >>>> are not being used.
> >>>>
> >>>> Lee, are you OK with that ?
> >>>
> >>> I missed a lot of this conversation I think, but from what I've read,
> >>> it sounds fine.
> >>>
> >>
> >> I summarize the situation:
> >> - I still don't have an official datasheet for STMFX device which could
> >> justify the use of an MFD driver;
> >> - the MFD driver will contain the STMFX chip initialization stuff such
> >> as regmap initialization (regmap structure will be shared with the
> >> child), chip initialization, global interrupt management;
> >> - there will be only one child (GPIO/PINCTRL node) for the time being.
> >
> > But there will be more devices in it. And they will invariably be put
> > to use later, and there will be new versions of the chip as well, and
> > then you will be happy about doing the MFD core, which makes it
> > easy to add new variants with different subdevices.
> >
> >> So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does
> >> it still sound fine after this summary ? :)
> >
> > No I think it should use an MFD core.
> >
> > Mainly because of device tree concerns.
> >
> > The main reason is that the device tree bindings will be different if
> > you add an MFD core later, the GPIO and pinctrl driver will
> > move to a child node, making old device trees incompatible.
> >
> > We could have a single driver in GPIO+pin control if it is a child
> > of an MFD node in the device tree, but it doesn't make much
> > sense as the I2C device need to be probing to the MFD core.
> >
>
> I agree with you Linus, and that's why all STMFX chip initialization
> stuff was decorrelated in pinctrl-stmfx. This shows that this stuff
> needs to be in an MFD core.
>
> But as there is only one child for now (due to the reasons mentioned
> earlier), it can suggest that it is not a Multi-Function Device.
>
> I'm not able to target when IDD or TS functions will be required on a
> Linux product, but it still makes sense to consider that these functions
> will be used on a Linux product.
>
> So, I think MFD core + GPIO/pinctrl driver is the right modeling, but I
> wanted to be sure that this is okay for everyone. I don't want to spend
> time on something that will not be accepted due to its modeling.
It's fine. Go ahead.
Thanks for seeing this through to a reasonable conclusion.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
From: Lee Jones @ 2018-05-29 7:39 UTC (permalink / raw)
To: Matti Vaittinen
Cc: mturquette, sboyd, robh+dt, mark.rutland, lgirdwood, broonie,
mazziesaccount, linux-clk, devicetree, linux-kernel,
mikko.mutanen, heikki.haikola
In-Reply-To: <20180528090003.GA8778@localhost.localdomain>
On Mon, 28 May 2018, Matti Vaittinen wrote:
> Patch series adding support for ROHM BD71837 PMIC.
>
> BD71837 is a programmable Power Management IC for powering single-core,
> dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
> low BOM cost and compact solution footprint. It integrates 8 buck
> regulators and 7 LDO’s to provide all the power rails required by the
> SoC and the commonly used peripherals.
>
> The driver aims to not limit the usage of PMIC. Thus the buck and LDO
> naming is generic and not tied to any specific purposes. However there
> is following limitations which make it mostly suitable for use cases
> where the processor where PMIC driver is running is powered by the PMIC:
>
> - The PMIC is not re-initialized if it resets. PMIC may reset as a
> result of voltage monitoring (over/under voltage) or due to reset
> request. Driver is only initializing PMIC at probe. This is not
> problem as long as processor controlling PMIC is powered by PMIC.
>
> - The PMIC internal state machine is ignored by driver. Driver assumes
> the PMIC is wired so that it is always in "run" state when controlled
> by the driver.
FYI, this patch-set is going to be difficult to manage since it was
not sent 'threaded'. As people start replying to different patches,
they are going to scatter-bomb throughout all of the recipient's
inboxes.
If/when you send a subsequent version, could you please ensure you
send the set threaded so the patches keep in relation to one another
as they are reviewed?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 4/6] clk: tegra20: init NDFLASH clock to sensible rate
From: Peter De Schrijver @ 2018-05-29 7:48 UTC (permalink / raw)
To: Stefan Agner
Cc: boris.brezillon, dwmw2, computersforpeace, marek.vasut, robh+dt,
mark.rutland, thierry.reding, mturquette, sboyd, dev,
miquel.raynal, richard, marcel, krzk, digetx, benjamin.lindqvist,
jonathanh, pgaikwad, mirza.krak, linux-mtd, linux-tegra,
devicetree, linux-kernel, linux-clk
In-Reply-To: <5665b799f763daa82dced238fb494863@agner.ch>
On Mon, May 28, 2018 at 05:53:08PM +0200, Stefan Agner wrote:
> On 28.05.2018 09:55, Peter De Schrijver wrote:
> > On Sun, May 27, 2018 at 11:54:40PM +0200, Stefan Agner wrote:
> >> From: Lucas Stach <dev@lynxeye.de>
> >>
> >> Set up the NAND Flash controller clock to run at 150MHz
> >> instead of the rate set by the bootloader. This is a
> >> conservative rate which also yields good performance.
> >>
> >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >> ---
> >> drivers/clk/tegra/clk-tegra20.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> >> index 0ee56dd04cec..dff8c425cd28 100644
> >> --- a/drivers/clk/tegra/clk-tegra20.c
> >> +++ b/drivers/clk/tegra/clk-tegra20.c
> >> @@ -1049,6 +1049,7 @@ static struct tegra_clk_init_table init_table[] __initdata = {
> >> { TEGRA20_CLK_GR2D, TEGRA20_CLK_PLL_C, 300000000, 0 },
> >> { TEGRA20_CLK_GR3D, TEGRA20_CLK_PLL_C, 300000000, 0 },
> >> { TEGRA20_CLK_VDE, TEGRA20_CLK_CLK_MAX, 300000000, 0 },
> >> + { TEGRA20_CLK_NDFLASH, TEGRA20_CLK_PLL_P, 150000000, 0 },
> >> /* must be the last entry */
> >> { TEGRA20_CLK_CLK_MAX, TEGRA20_CLK_CLK_MAX, 0, 0 },
> >> };
> >> --
> >> 2.17.0
> >>
> >
> > Maybe better to specify this in the Tegra20 dtsi? See
> > "Assigned clock parents and rates" in
> > Documentation/devicetree/bindings/clock/clock-bindings.txt
>
> assigned-clocks indeed works just fine for this case. Thanks for
> bringing this up, will drop this patch and add the device tree
> properties in v3.
>
> Hm, interesting that none of the Tegra device tree make use of the
> feature so far. I guess there would be other cases where this would be
> useful as well (the one just above, VDE?).
>
Yes, historically this feature wasn't available, so we used these init tables.
Unfortunately it's not easy to get rid of them for parent and rate
configuration, because new kernels should also work with existing DTBs, so we
can't just add assigned-clock properties and remove the existing table
entries. What we could do is use the CLK_IS_CRITICAL flag for all clocks which
are only enabled by the init table. For not yet merged blocks, this is
ofcourse not a concern.
Cheers,
Peter.
^ permalink raw reply
* Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
From: Kuninori Morimoto @ 2018-05-29 8:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Simon Horman, Catalin Marinas, Magnus Damm, open list,
DRI Development, Linux-Renesas, Rob Herring, Kieran Bingham,
Laurent Pinchart, Will Deacon,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)
In-Reply-To: <CAMuHMdWPFOjT9qk0Z4+-nSTumjhN_Q6Ntwh3__CgBCobquX8Rg@mail.gmail.com>
Hi Geert
> > HDMI sound doesn't use hdmi0_con.
> > You can do it now, thanks
>
> Thanks, so hdmi0_con can be moved now.
>
> But HDMI sound does use hdmi0/ports/port@2. right?
Yes
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v7 1/4] drm/bridge: add support for sn65dsi86 bridge driver
From: Andrzej Hajda @ 2018-05-29 8:25 UTC (permalink / raw)
To: Sandeep Panda, dri-devel, linux-arm-msm, freedreno, devicetree
Cc: hoegsberg, chandanu, ryadav, abhinavk
In-Reply-To: <1527180079-12721-2-git-send-email-spanda@codeaurora.org>
On 24.05.2018 18:41, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
>
> Changes in v1:
> - Split the dt-bindings and the driver support into separate patches
> (Andrzej Hajda).
> - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
> (Andrzej Hajda).
> - Use macros to define the register offsets (Andrzej Hajda).
>
> Changes in v2:
> - Separate out edp panel specific HW resource handling from bridge
> driver and create a separate edp panel drivers to handle panel
> specific mode information and HW resources (Sean Paul).
> - Replace pr_* APIs to DRM_* APIs to log error or debug information
> (Sean Paul).
> - Remove some of the unnecessary structure/variable from driver (Sean
> Paul).
> - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge"
> (Sean Paul / Rob Herring).
> - Remove most of the hard-coding and modified the bridge init sequence
> based on current mode (Sean Paul).
> - Remove the existing function to retrieve the EDID data and
> implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul).
> - Remove the dummy irq handler implementation, will add back the
> proper irq handling later (Sean Paul).
> - Capture the required enable gpios in a single array based on dt entry
> instead of having individual descriptor for each gpio (Sean Paul).
>
> Changes in v3:
> - Remove usage of irq_gpio and replace it as "interrupts" property (Rob
> Herring).
> - Remove the unnecessary header file inclusions (Sean Paul).
> - Rearrange the header files in alphabetical order (Sean Paul).
> - Use regmap interface to perform i2c transactions.
> - Update Copyright/License field and address other review comments
> (Jordan Crouse).
>
> Changes in v4:
> - Update License/Copyright (Sean Paul).
> - Add Kconfig and Makefile changes (Sean Paul).
> - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios
> will be handled by i2c master.
> - Update required supplies names.
> - Remove unnecessary goto statements (Sean Paul).
> - Add mutex lock to power_ctrl API to avoid race conditions (Sean
> Paul).
> - Add support to parse reference clk frequency from dt(optional).
> - Update the bridge chip enable/disable sequence.
>
> Changes in v5:
> - Fixed Kbuild test service reported warnings.
>
> Changes in v6:
> - Use PM runtime based ref-counting instead of local ref_count mechanism
> (Stephen Boyd).
> - Clean up some debug logs and indentations (Sean Paul).
> - Simplify dp rate calculation (Sean Paul).
> - Add support to configure refclk based on input REFCLK pin or DACP/N
> pin (Stephen Boyd).
>
> Changes in v7:
> - Use static supply entries instead of dynamic allocation (Andrzej
> Hajda).
> - Defer bridge driver probe if panel is not probed (Andrzej Hajda).
> - Update of_graph APIs for correct node reference management. (Andrzej
> Hajda).
> - Remove local display_mode object (Andrzej Hajda).
> - Remove version id check function from driver.
>
> Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
> ---
> drivers/gpu/drm/bridge/Kconfig | 9 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 675 ++++++++++++++++++++++++++++++++++
> 3 files changed, 685 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..8153150 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -108,6 +108,15 @@ config DRM_TI_TFP410
> ---help---
> Texas Instruments TFP410 DVI/HDMI Transmitter driver
>
> +config DRM_TI_SN65DSI86
> + tristate "TI SN65DSI86 DSI to eDP bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + select DRM_PANEL
> + ---help---
> + Texas Instruments SN65DSI86 DSI to eDP Bridge driver
> +
> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..3711be8 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 0000000..3c71789
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,675 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <linux/clk.h>
> +#include <linux/gpio.h>
It is legacy header, linux/gpio/consumer.h should be probably used.
> +#include <linux/i2c.h>
> +#include <linux/of_gpio.h>
I suspect it could be removed as well, to be checked.
> +#include <linux/of_graph.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +
> +/* Link Training specific registers */
> +#define SN_DEVICE_REV_REG 0x08
> +#define SN_HPD_DISABLE_REG 0x5C
> +#define SN_REFCLK_FREQ_REG 0x0A
> +#define SN_DSI_LANES_REG 0x10
> +#define SN_DSIA_CLK_FREQ_REG 0x12
> +#define SN_ENH_FRAME_REG 0x5A
> +#define SN_SSC_CONFIG_REG 0x93
> +#define SN_DATARATE_CONFIG_REG 0x94
> +#define SN_PLL_ENABLE_REG 0x0D
> +#define SN_SCRAMBLE_CONFIG_REG 0x95
> +#define SN_AUX_WDATA0_REG 0x64
> +#define SN_AUX_ADDR_19_16_REG 0x74
> +#define SN_AUX_ADDR_15_8_REG 0x75
> +#define SN_AUX_ADDR_7_0_REG 0x76
> +#define SN_AUX_LENGTH_REG 0x77
> +#define SN_AUX_CMD_REG 0x78
> +#define SN_ML_TX_MODE_REG 0x96
> +/* video config specific registers */
> +#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
> +#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG 0x25
> +#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
> +#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG 0x2D
> +#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
> +#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG 0x31
> +#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
> +#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
> +#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
> +#define SN_CHA_VERTICAL_FRONT_PORCH_REG 0x3A
> +#define SN_DATA_FORMAT_REG 0x5B
> +
> +#define MIN_DSI_CLK_FREQ_MHZ 40
> +
> +/* fudge factor required to account for 8b/10b encoding */
> +#define DP_CLK_FUDGE_NUM 10
> +#define DP_CLK_FUDGE_DEN 8
> +
> +#define DPPLL_CLK_SRC_REFCLK 0
> +#define DPPLL_CLK_SRC_DSICLK 1
> +
> +#define SN_DSIA_REFCLK_OFFSET 1
> +#define SN_DSIA_LANE_OFFSET 3
> +#define SN_DP_LANE_OFFSET 4
> +#define SN_DP_DATA_RATE_OFFSET 5
> +#define SN_TIMING_HIGH_OFFSET 8
From the code it looks like it is just number of bits in byte, so you
can drop it and use 8 instead.
> +
> +#define SN_ENABLE_VID_STREAM_BIT BIT(3)
> +#define SN_DSIA_NUM_LANES_BITS (BIT(4) | BIT(3))
> +#define SN_DP_NUM_LANES_BITS (BIT(5) | BIT(4))
> +#define SN_DP_DATA_RATE_BITS (BIT(7) | BIT(6) | BIT(5))
> +#define SN_HPD_DISABLE_BIT BIT(0)
> +
> +#define SN_REGULATOR_SUPPLY_NUM 4
> +
> +struct ti_sn_bridge {
> + struct device *dev;
> + struct regmap *regmap;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> + struct device_node *host_node;
> + struct mipi_dsi_device *dsi;
> + struct clk *refclk;
> + struct drm_panel *panel;
> + struct gpio_desc *enable_gpio;
> + struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM];
> + struct i2c_adapter *ddc;
> +};
> +
> +static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> + { .range_min = 0, .range_max = 0xff },
> +};
> +
> +static const struct regmap_access_table ti_sn_bridge_volatile_table = {
> + .yes_ranges = ti_sn_bridge_volatile_ranges,
> + .n_yes_ranges = ARRAY_SIZE(ti_sn_bridge_volatile_ranges),
> +};
> +
> +static const struct regmap_config ti_sn_bridge_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .volatile_table = &ti_sn_bridge_volatile_table,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
> +{
> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + ret = regulator_bulk_enable(SN_REGULATOR_SUPPLY_NUM, pdata->supplies);
> + if (ret) {
> + DRM_ERROR("failed to enable supplies %d\n", ret);
> + return ret;
> + }
> +
> + gpiod_set_value(pdata->enable_gpio, 1);
> +
> + return ret;
> +}
> +
> +static int __maybe_unused ti_sn_bridge_suspend(struct device *dev)
> +{
> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + gpiod_set_value(pdata->enable_gpio, 0);
> +
> + ret = regulator_bulk_disable(SN_REGULATOR_SUPPLY_NUM, pdata->supplies);
> + if (ret)
> + DRM_ERROR("failed to disable supplies %d\n", ret);
> +
> + return ret;
> +}
> +
> +static const struct dev_pm_ops ti_sn_bridge_pm_ops = {
> + SET_RUNTIME_PM_OPS(ti_sn_bridge_suspend, ti_sn_bridge_resume, NULL)
> +};
> +
> +/* Connector funcs */
> +static struct ti_sn_bridge *
> +connector_to_ti_sn_bridge(struct drm_connector *connector)
> +{
> + return container_of(connector, struct ti_sn_bridge, connector);
> +}
> +
> +static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector)
> +{
> + struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> + struct edid *edid;
> + u32 num_modes;
> +
> + if (pdata->panel) {
> + DRM_DEBUG_KMS("get mode from connected drm_panel\n");
> + return drm_panel_get_modes(pdata->panel);
> + }
> +
> + if (!pdata->ddc)
> + return 0;
> +
> + pm_runtime_get_sync(pdata->dev);
> + edid = drm_get_edid(connector, pdata->ddc);
> + pm_runtime_put_sync(pdata->dev);
> + if (!edid)
> + return 0;
> +
> + drm_mode_connector_update_edid_property(connector, edid);
> + num_modes = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> +
> + return num_modes;
> +}
> +
> +static enum drm_mode_status
> +ti_sn_bridge_connector_mode_valid(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + /* maximum supported resolution is 4K at 60 fps */
> + if (mode->clock > 594000)
> + return MODE_CLOCK_HIGH;
I wonder if training results shouldn't be taken into account.
> +
> + return MODE_OK;
> +}
> +
> +static struct drm_connector_helper_funcs ti_sn_bridge_connector_helper_funcs = {
> + .get_modes = ti_sn_bridge_connector_get_modes,
> + .mode_valid = ti_sn_bridge_connector_mode_valid,
> +};
> +
> +static enum drm_connector_status
> +ti_sn_bridge_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> +
> + /**
> + * TODO: Currently if drm_panel is present, then always
> + * return the status as connected. Need to add support to detect
> + * device state for no panel(hot pluggable) scenarios.
> + */
> + if (pdata->panel)
> + return connector_status_connected;
> + else
> + return connector_status_unknown;
> +}
> +
> +static const struct drm_connector_funcs ti_sn_bridge_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .detect = ti_sn_bridge_connector_detect,
> + .destroy = drm_connector_cleanup,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static struct ti_sn_bridge *bridge_to_ti_sn_bridge(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct ti_sn_bridge, bridge);
> +}
> +
> +static const char * const ti_sn_bridge_supply_names[] = {
> + "vcca",
> + "vcc",
> + "vccio",
> + "vpll",
> +};
If you use this array only in following function, you can put the
definition there.
> +
> +static int ti_sn_bridge_parse_regulators(struct ti_sn_bridge *pdata)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < SN_REGULATOR_SUPPLY_NUM; i++)
> + pdata->supplies[i].supply = ti_sn_bridge_supply_names[i];
> +
> + return devm_regulator_bulk_get(pdata->dev, SN_REGULATOR_SUPPLY_NUM,
> + pdata->supplies);
> +}
> +
> +static int ti_sn_bridge_attach(struct drm_bridge *bridge)
> +{
> + struct mipi_dsi_host *host;
> + struct mipi_dsi_device *dsi;
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> + int ret;
> + const struct mipi_dsi_device_info info = { .type = "ti_sn_bridge",
> + .channel = 0,
> + .node = NULL,
> + };
> +
> + if (!bridge->encoder) {
> + DRM_ERROR("Parent encoder object not found\n");
> + return -ENODEV;
> + }
drm_bridge_attach assures it wont happen, so you can remove the check above.
> +
> + ret = drm_connector_init(bridge->dev, &pdata->connector,
> + &ti_sn_bridge_connector_funcs,
> + DRM_MODE_CONNECTOR_eDP);
> + if (ret) {
> + DRM_ERROR("Failed to initialize connector with drm\n");
> + return ret;
> + }
> +
> + drm_connector_helper_add(&pdata->connector,
> + &ti_sn_bridge_connector_helper_funcs);
> + drm_mode_connector_attach_encoder(&pdata->connector, bridge->encoder);
> +
> + host = of_find_mipi_dsi_host_by_node(pdata->host_node);
> + if (!host) {
> + DRM_ERROR("failed to find dsi host\n");
> + return -ENODEV;
> + }
Hmm, this is resource, so it should be rather acquired in probe
(together with dsi dev register), is there a reason to put it here?
If it must be here you should undo things on all below error paths
(drm_connector_cleanup).
> +
> + dsi = mipi_dsi_device_register_full(host, &info);
> + if (IS_ERR(dsi)) {
> + DRM_ERROR("failed to create dsi device\n");
> + ret = PTR_ERR(dsi);
> + return ret;
> + }
> +
> + /* TODO: setting to 4 lanes always for now */
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + DRM_ERROR("failed to attach dsi to host\n");
> + mipi_dsi_device_unregister(dsi);
> + return ret;
> + }
> +
> + pdata->dsi = dsi;
> +
> + DRM_DEBUG_KMS("ti_sn_bridge attached to dsi\n");
> + /* attach panel to bridge */
> + if (pdata->panel)
> + drm_panel_attach(pdata->panel, &pdata->connector);
> +
> + return 0;
> +}
> +
> +static void ti_sn_bridge_disable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> + if (pdata->panel) {
> + drm_panel_disable(pdata->panel);
> + drm_panel_unprepare(pdata->panel);
> + }
> +
> + /* disable video stream */
> + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG,
> + SN_ENABLE_VID_STREAM_BIT, 0);
> + /* semi auto link training mode OFF */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0);
> + /* disable DP PLL */
> + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0);
> +}
> +
> +static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
> +{
> + u32 bit_rate_khz, clk_freq_khz;
> + struct drm_display_mode *mode =
> + &pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> + bit_rate_khz = mode->clock *
> + mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> + clk_freq_khz = bit_rate_khz / (pdata->dsi->lanes * 2);
> +
> + return clk_freq_khz;
> +}
> +
> +#define REFCLK_LUT_SIZE 5
> +
> +/* clk frequencies supported by bridge in Hz in case derived from REFCLK pin */
> +static const u32 ti_sn_bridge_refclk_lut[] = {
> + 12000000,
> + 19200000,
> + 26000000,
> + 27000000,
> + 38400000,
> +};
> +
> +/* clk frequencies supported by bridge in Hz in case derived from DACP/N pin */
> +static const u32 ti_sn_bridge_dsiclk_lut[] = {
> + 468000000,
> + 384000000,
> + 416000000,
> + 486000000,
> + 460800000,
> +};
> +
> +static void ti_sn_bridge_set_refclk(struct ti_sn_bridge *pdata)
> +{
> + int i = 0;
> + u8 refclk_src;
> + u32 refclk_rate;
> + const u32 *refclk_lut;
> +
> + if (pdata->refclk) {
> + refclk_src = DPPLL_CLK_SRC_REFCLK;
> + refclk_rate = clk_get_rate(pdata->refclk);
> + refclk_lut = ti_sn_bridge_refclk_lut;
> + clk_prepare_enable(pdata->refclk);
> + } else {
> + refclk_src = DPPLL_CLK_SRC_DSICLK;
> + refclk_rate = ti_sn_bridge_get_dsi_freq(pdata) * 1000;
> + refclk_lut = ti_sn_bridge_dsiclk_lut;
> + }
> +
> + /* for i equals to REFCLK_LUT_SIZE means default frequency */
> + for (i = 0; i < REFCLK_LUT_SIZE; i++)
> + if (refclk_lut[i] == refclk_rate)
> + break;
> +
> + regmap_write(pdata->regmap, SN_REFCLK_FREQ_REG,
> + (refclk_src | (i << SN_DSIA_REFCLK_OFFSET)));
> +}
> +
> +/**
> + * LUT index corresponds to register value and
> + * LUT values corresponds to dp data rate supported
> + * by the bridge in Mbps unit.
> + */
> +static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
> + 0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
> +};
> +
> +static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge *pdata)
> +{
> + unsigned int bit_rate_mhz, clk_freq_mhz, dp_rate_mhz;
> + unsigned int val = 0, i = 0;
> + struct drm_display_mode *mode =
> + &pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> + /* set DSIA clk frequency */
> + bit_rate_mhz = (mode->clock / 1000) *
> + mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> + clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
> +
> + /* for each increment in val, frequency increases by 5MHz */
> + val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
> + (((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
> + regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> +
> + /* set DP data rate */
> + dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) * DP_CLK_FUDGE_NUM) /
> + DP_CLK_FUDGE_DEN;
> + for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
> + if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
> + break;
> +
> + regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> + SN_DP_DATA_RATE_BITS, i << SN_DP_DATA_RATE_OFFSET);
> +}
> +
> +static void ti_sn_bridge_set_video_timings(struct ti_sn_bridge *pdata)
> +{
> + struct drm_display_mode *mode =
> + &pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> + regmap_write(pdata->regmap, SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG,
> + mode->hdisplay & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG,
> + (mode->hdisplay >> SN_TIMING_HIGH_OFFSET) & 0xFF);
Since you have multiple writes of 16bit words into consecutive registers
you can create helper to make it more readable, for example:
void ti_sn_bridge_write_u16(struct ti_sn_bridge *pdata, unsigned int
reg, u16 val)
{
regmap_write(pdata->regmap, reg, val & 0xff);
regmap_write(pdata->regmap, reg + 1, val >> 8);
}
> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG,
> + mode->vdisplay & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG,
> + (mode->vdisplay >> SN_TIMING_HIGH_OFFSET) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG,
> + (mode->hsync_end - mode->hsync_start) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG,
> + ((mode->hsync_end - mode->hsync_start) >>
> + SN_TIMING_HIGH_OFFSET) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG,
> + (mode->vsync_end - mode->vsync_start) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG,
> + ((mode->vsync_end - mode->vsync_start) >>
> + SN_TIMING_HIGH_OFFSET) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_HORIZONTAL_BACK_PORCH_REG,
> + (mode->htotal - mode->hsync_end) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_BACK_PORCH_REG,
> + (mode->vtotal - mode->vsync_end) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_HORIZONTAL_FRONT_PORCH_REG,
> + (mode->hsync_start - mode->hdisplay) & 0xFF);
> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_FRONT_PORCH_REG,
> + (mode->vsync_start - mode->vdisplay) & 0xFF);
> + usleep_range(10000, 10500); /* 10ms delay recommended by spec */
> +}
> +
> +static void ti_sn_bridge_enable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> + unsigned int val = 0;
> +
> + if (pdata->panel) {
> + drm_panel_prepare(pdata->panel);
> + /* in case drm_panel is connected then HPD is not supported */
> + regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG,
> + SN_HPD_DISABLE_BIT, SN_HPD_DISABLE_BIT);
regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG,
SN_HPD_DISABLE_BIT, ~0);
> + }
> +
> + /* DSI_A lane config */
> + val = (4 - pdata->dsi->lanes) << SN_DSIA_LANE_OFFSET;
> + regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
> + SN_DSIA_NUM_LANES_BITS, val);
> +
> + /* DP lane config */
> + val = (pdata->dsi->lanes - 1) << SN_DP_LANE_OFFSET;
> + regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG,
> + SN_DP_NUM_LANES_BITS, val);
> +
> + /* set dsi/dp clk frequency value */
> + ti_sn_bridge_set_dsi_dp_rate(pdata);
> +
> + /* enable DP PLL */
> + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
> + usleep_range(10000, 10500); /* 10ms delay recommended by spec */
> +
> + /**
> + * The SN65DSI86 only supports ASSR Display Authentication method and
> + * this method is enabled by default. An eDP panel must support this
> + * authentication method. We need to enable this method in the eDP panel
> + * at DisplayPort address 0x0010A prior to link training.
> + */
> + regmap_write(pdata->regmap, SN_AUX_WDATA0_REG, 0x01);
> + regmap_write(pdata->regmap, SN_AUX_ADDR_19_16_REG, 0x00);
> + regmap_write(pdata->regmap, SN_AUX_ADDR_15_8_REG, 0x01);
> + regmap_write(pdata->regmap, SN_AUX_ADDR_7_0_REG, 0x0A);
> + regmap_write(pdata->regmap, SN_AUX_LENGTH_REG, 0x01);
> + regmap_write(pdata->regmap, SN_AUX_CMD_REG, 0x81);
> + usleep_range(10000, 10500); /* 10ms delay recommended by spec */
> +
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + msleep(20); /* 20ms delay recommended by spec */
> +
> + /* config video parameters */
> + ti_sn_bridge_set_video_timings(pdata);
> +
> + /* enable video stream */
> + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG,
> + SN_ENABLE_VID_STREAM_BIT, SN_ENABLE_VID_STREAM_BIT);
> +
> + if (pdata->panel)
> + drm_panel_enable(pdata->panel);
> +}
> +
> +static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> + pm_runtime_get_sync(pdata->dev);
> +
> + /* configure bridge CLK_SRC and ref_clk */
> + ti_sn_bridge_set_refclk(pdata);
> +}
> +
> +static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> + if (pdata->refclk)
> + clk_disable_unprepare(pdata->refclk);
> +
> + pm_runtime_put_sync(pdata->dev);
> +}
> +
> +static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
> + .attach = ti_sn_bridge_attach,
> + .pre_enable = ti_sn_bridge_pre_enable,
> + .enable = ti_sn_bridge_enable,
> + .disable = ti_sn_bridge_disable,
> + .post_disable = ti_sn_bridge_post_disable,
> +};
> +
> +static int ti_sn_bridge_parse_dsi_host(struct ti_sn_bridge *pdata)
> +{
> + struct device_node *np = pdata->dev->of_node;
> +
> + pdata->host_node = of_graph_get_remote_node(np, 0, 0);
> +
> + if (!pdata->host_node) {
> + DRM_ERROR("remote dsi host node not found\n");
> + return -ENODEV;
> + }
> + of_node_put(pdata->host_node);
of_node_put should be called in remove.
> +
> + return 0;
> +}
> +
> +static int ti_sn_bridge_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct ti_sn_bridge *pdata;
> + struct device_node *ddc_node;
> + int ret = 0;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + DRM_ERROR("device doesn't support I2C\n");
> + return -ENODEV;
> + }
> +
> + pdata = devm_kzalloc(&client->dev, sizeof(struct ti_sn_bridge),
> + GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + pdata->dev = &client->dev;
> + dev_set_drvdata(&client->dev, pdata);
> +
> + ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
> + &pdata->panel, NULL);
> + if (ret) {
> + DRM_ERROR("could not find any drm panel node\n");
> + return ret;
> + }
> +
> + pdata->regmap = devm_regmap_init_i2c(client,
> + &ti_sn_bridge_regmap_config);
> + if (IS_ERR(pdata->regmap)) {
> + DRM_ERROR("regmap i2c init failed\n");
> + return PTR_ERR(pdata->regmap);
> + }
> +
> + pdata->enable_gpio = devm_gpiod_get(pdata->dev,
> + "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(pdata->enable_gpio)) {
> + DRM_ERROR("failed to get enable gpio from DT\n");
> + ret = PTR_ERR(pdata->enable_gpio);
> + return ret;
> + }
> +
> + ret = ti_sn_bridge_parse_regulators(pdata);
> + if (ret) {
> + DRM_ERROR("failed to parse regulators\n");
> + return ret;
> + }
> +
> + ret = ti_sn_bridge_parse_dsi_host(pdata);
> + if (ret)
> + return ret;
> +
> + pm_runtime_enable(pdata->dev);
> +
> + pdata->refclk = devm_clk_get(pdata->dev, "refclk");
> +
> + ddc_node = of_parse_phandle(pdata->dev->of_node, "ddc-i2c-bus", 0);
ddc-i2c-bus is not documented in bindings.
> + if (ddc_node) {
> + pdata->ddc = of_find_i2c_adapter_by_node(ddc_node);
> + of_node_put(ddc_node);
> + if (!pdata->ddc) {
> + DRM_DEBUG_KMS("failed to read ddc node\n");
> + pm_runtime_disable(pdata->dev);
> + return -EPROBE_DEFER;
> + }
> + } else {
> + DRM_DEBUG_KMS("no ddc property found\n");
> + }
If you put pm_runtime_enable after 'if', you can remove
pm_runtime_disable above.
> +
> + i2c_set_clientdata(client, pdata);
> +
> + pdata->bridge.funcs = &ti_sn_bridge_funcs;
> + pdata->bridge.of_node = client->dev.of_node;
> +
> + drm_bridge_add(&pdata->bridge);
> +
> + return 0;
> +}
> +
> +static int ti_sn_bridge_remove(struct i2c_client *client)
> +{
> + struct ti_sn_bridge *pdata = i2c_get_clientdata(client);
> +
> + if (!pdata)
> + return -EINVAL;
> +
> + mipi_dsi_detach(pdata->dsi);
> + mipi_dsi_device_unregister(pdata->dsi);
dsi attach and register are performed in panel attach callback, this is
asymmetric and can cause oops if bridge is unbind before attaching, as I
said earlier please consider moving dsi attach/register to probe.
Regards
Andrzej
> +
> + drm_bridge_remove(&pdata->bridge);
> + pm_runtime_disable(pdata->dev);
> + i2c_put_adapter(pdata->ddc);
> +
> + return 0;
> +}
> +
> +static struct i2c_device_id ti_sn_bridge_id[] = {
> + { "ti,sn65dsi86", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ti_sn_bridge_id);
> +
> +static const struct of_device_id ti_sn_bridge_match_table[] = {
> + {.compatible = "ti,sn65dsi86"},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ti_sn_bridge_match_table);
> +
> +static struct i2c_driver ti_sn_bridge_driver = {
> + .driver = {
> + .name = "ti_sn65dsi86",
> + .of_match_table = ti_sn_bridge_match_table,
> + .pm = &ti_sn_bridge_pm_ops,
> + },
> + .probe = ti_sn_bridge_probe,
> + .remove = ti_sn_bridge_remove,
> + .id_table = ti_sn_bridge_id,
> +};
> +
> +module_i2c_driver(ti_sn_bridge_driver);
> +MODULE_DESCRIPTION("sn65dsi86 DSI to eDP bridge driver");
> +MODULE_LICENSE("GPL v2");
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v1 0/3] USB host: Add USB ehci support for nuvoton npcm7xx
From: avifishman70 @ 2018-05-29 8:35 UTC (permalink / raw)
To: gregkh, stern
Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
linux-usb, openbmc, robh+dt, mark.rutland, devicetree, davem,
mchehab+samsung, akpm, rdunlap, Avi Fishman
From: Avi Fishman <AviFishman70@gmail.com>
This patch adds support for ehci controller for the Nuvoton npcm7xx platform.
Most of the code was taken from ehci-spear.c + specific initialization code
Avi Fishman (3):
USB host: Add USB ehci support for nuvoton npcm7xx platform
USB: DT probing support to ehci-npcm7xx
MAINTAINERS: add subfolders for nuvoton *npcm*
.../devicetree/bindings/usb/npcm7xx-usb.txt | 18 ++
MAINTAINERS | 3 +
drivers/usb/host/Kconfig | 8 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-npcm7xx.c | 212 +++++++++++++++++++++
5 files changed, 242 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
create mode 100644 drivers/usb/host/ehci-npcm7xx.c
--
2.14.1
^ permalink raw reply
* [PATCH v1 1/3] USB host: Add USB ehci support for nuvoton npcm7xx platform
From: avifishman70 @ 2018-05-29 8:35 UTC (permalink / raw)
To: gregkh, stern
Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
linux-usb, openbmc, robh+dt, mark.rutland, devicetree, davem,
mchehab+samsung, akpm, rdunlap, Avi Fishman
In-Reply-To: <1527582935-31175-1-git-send-email-avifishman70@gmail.com>
From: Avi Fishman <AviFishman70@gmail.com>
This patch adds support for ehci controller for the Nuvoton
npcm7xx platform.
Most of the code was taken from ehci-spear.c + specific initialization
code
Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
drivers/usb/host/Kconfig | 8 ++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-npcm7xx.c | 212 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 221 insertions(+)
create mode 100644 drivers/usb/host/ehci-npcm7xx.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 9f0aeb068acb..e3100b249f0f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -185,6 +185,14 @@ config USB_EHCI_MXC
---help---
Variation of ARC USB block used in some Freescale chips.
+config USB_EHCI_HCD_NPCM7XX
+ tristate "Support for Nuvoton NPCM7XX on-chip EHCI USB controller"
+ depends on (USB_EHCI_HCD && ARCH_NPCM7XX) || COMPILE_TEST
+ default y
+ help
+ Enables support for the on-chip EHCI controller on
+ Nuvoton NPCM7XX chips.
+
config USB_EHCI_HCD_OMAP
tristate "EHCI support for OMAP3 and later chips"
depends on ARCH_OMAP
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8a8cffe0b445..fcf5dab5efa4 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
+obj-$(CONFIG_USB_EHCI_HCD_NPCM7XX) += ehci-npcm7xx.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
diff --git a/drivers/usb/host/ehci-npcm7xx.c b/drivers/usb/host/ehci-npcm7xx.c
new file mode 100644
index 000000000000..a2f23a90ad1c
--- /dev/null
+++ b/drivers/usb/host/ehci-npcm7xx.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Nuvoton NPCM7xx driver for EHCI HCD
+ *
+ * Copyright (C) 2018 Nuvoton Technologies,
+ * Avi Fishman <avi.fishman@nuvoton.com> <avifishman70@gmail.com>
+ * Tomer Maimon <tomer.maimon@nuvoton.com> <tmaimon77@gmail.com>
+ *
+ * Based on various ehci-spear.c driver
+ */
+
+
+#include <linux/dma-mapping.h>
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
+
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#define DRIVER_DESC "EHCI npcm7xx driver"
+
+static const char hcd_name[] = "npcm7xx-ehci";
+
+#define USB2PHYCTL_OFFSET 0x144
+
+#define IPSRST2_OFFSET 0x24
+#define IPSRST3_OFFSET 0x34
+
+
+static struct hc_driver __read_mostly ehci_npcm7xx_hc_driver;
+
+#ifdef CONFIG_PM_SLEEP
+static int ehci_npcm7xx_drv_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ bool do_wakeup = device_may_wakeup(dev);
+
+ return ehci_suspend(hcd, do_wakeup);
+}
+
+static int ehci_npcm7xx_drv_resume(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+ ehci_resume(hcd, false);
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(ehci_npcm7xx_pm_ops, ehci_npcm7xx_drv_suspend,
+ ehci_npcm7xx_drv_resume);
+
+static int npcm7xx_ehci_hcd_drv_probe(struct platform_device *pdev)
+{
+ struct usb_hcd *hcd;
+ struct resource *res;
+ struct regmap *gcr_regmap;
+ struct regmap *rst_regmap;
+ const struct hc_driver *driver = &ehci_npcm7xx_hc_driver;
+ int irq;
+ int retval;
+
+ dev_dbg(&pdev->dev, "initializing npcm7xx ehci USB Controller\n");
+
+ gcr_regmap = syscon_regmap_lookup_by_compatible("nuvoton,npcm750-gcr");
+ if (IS_ERR(gcr_regmap)) {
+ dev_err(&pdev->dev, "%s: failed to find nuvoton,npcm7xx-gcr\n",
+ __func__);
+ return IS_ERR(gcr_regmap);
+ }
+
+ rst_regmap = syscon_regmap_lookup_by_compatible("nuvoton,npcm750-rst");
+ if (IS_ERR(rst_regmap)) {
+ dev_err(&pdev->dev, "%s: failed to find nuvoton,npcm7xx-rst\n",
+ __func__);
+ return IS_ERR(rst_regmap);
+ }
+
+ /********* phy init ******/
+ // reset usb host
+ regmap_update_bits(rst_regmap, IPSRST2_OFFSET,
+ (0x1 << 26), (0x1 << 26));
+ regmap_update_bits(rst_regmap, IPSRST3_OFFSET,
+ (0x1 << 25), (0x1 << 25));
+ regmap_update_bits(gcr_regmap, USB2PHYCTL_OFFSET,
+ (0x1 << 28), 0);
+
+ udelay(1);
+
+ // enable phy
+ regmap_update_bits(rst_regmap, IPSRST3_OFFSET,
+ (0x1 << 25), 0);
+
+ udelay(50); // enable phy
+
+ regmap_update_bits(gcr_regmap, USB2PHYCTL_OFFSET,
+ (0x1 << 28), (0x1 << 28));
+
+ // enable host
+ regmap_update_bits(rst_regmap, IPSRST2_OFFSET,
+ (0x1 << 26), 0);
+
+ if (usb_disabled())
+ return -ENODEV;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ retval = irq;
+ goto fail;
+ }
+
+ /*
+ * Right now device-tree probed devices don't get dma_mask set.
+ * Since shared usb code relies on it, set it here for now.
+ * Once we have dma capability bindings this can go away.
+ */
+ retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (retval)
+ goto fail;
+
+ hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
+ if (!hcd) {
+ retval = -ENOMEM;
+ goto fail;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ retval = PTR_ERR(hcd->regs);
+ goto err_put_hcd;
+ }
+ hcd->rsrc_start = res->start;
+ hcd->rsrc_len = resource_size(res);
+
+ /* registers start at offset 0x0 */
+ hcd_to_ehci(hcd)->caps = hcd->regs;
+
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (retval)
+ goto err_put_hcd;
+
+ device_wakeup_enable(hcd->self.controller);
+ return retval;
+
+err_put_hcd:
+ usb_put_hcd(hcd);
+fail:
+ dev_err(&pdev->dev, "init fail, %d\n", retval);
+
+ return retval;
+}
+
+static int npcm7xx_ehci_hcd_drv_remove(struct platform_device *pdev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+
+ usb_remove_hcd(hcd);
+
+ usb_put_hcd(hcd);
+
+ return 0;
+}
+
+static const struct of_device_id npcm7xx_ehci_id_table[] = {
+ { .compatible = "nuvoton,npcm750-ehci" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, npcm7xx_ehci_id_table);
+
+static struct platform_driver npcm7xx_ehci_hcd_driver = {
+ .probe = npcm7xx_ehci_hcd_drv_probe,
+ .remove = npcm7xx_ehci_hcd_drv_remove,
+ .shutdown = usb_hcd_platform_shutdown,
+ .driver = {
+ .name = "npcm7xx-ehci",
+ .bus = &platform_bus_type,
+ .pm = &ehci_npcm7xx_pm_ops,
+ .of_match_table = npcm7xx_ehci_id_table,
+ }
+};
+
+static int __init ehci_npcm7xx_init(void)
+{
+ if (usb_disabled())
+ return -ENODEV;
+
+ pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+ ehci_init_driver(&ehci_npcm7xx_hc_driver, NULL);
+ return platform_driver_register(&npcm7xx_ehci_hcd_driver);
+}
+module_init(ehci_npcm7xx_init);
+
+static void __exit ehci_npcm7xx_cleanup(void)
+{
+ platform_driver_unregister(&npcm7xx_ehci_hcd_driver);
+}
+module_exit(ehci_npcm7xx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS("platform:npcm7xx-ehci");
+MODULE_AUTHOR("Avi Fishman");
+MODULE_LICENSE("GPL v2");
--
2.14.1
^ permalink raw reply related
* [PATCH v1 2/3] USB: DT probing support to ehci-npcm7xx
From: avifishman70 @ 2018-05-29 8:35 UTC (permalink / raw)
To: gregkh, stern
Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
linux-usb, openbmc, robh+dt, mark.rutland, devicetree, davem,
mchehab+samsung, akpm, rdunlap, Avi Fishman
In-Reply-To: <1527582935-31175-1-git-send-email-avifishman70@gmail.com>
From: Avi Fishman <AviFishman70@gmail.com>
Device Tree documentation for Nuvoton npcm7xx EHCI driver.
Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
Documentation/devicetree/bindings/usb/npcm7xx-usb.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
new file mode 100644
index 000000000000..628692dff7e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
@@ -0,0 +1,18 @@
+Nuvoton NPCM7XX SoC USB controllers:
+-----------------------------
+
+EHCI:
+-----
+
+Required properties:
+- compatible: "nuvoton,npcm750-ehci"
+ that services interrupts for this device
+- interrupts: Should contain the EHCI interrupt
+
+Example:
+
+ ehci@e1800000 {
+ compatible = "nuvoton,npcm750-ehci", "usb-ehci";
+ reg = <0xf0806000 0x1000>;
+ interrupts = <0 61 4>;
+ };
--
2.14.1
^ permalink raw reply related
* [PATCH v1 3/3] MAINTAINERS: add subfolders for nuvoton *npcm*
From: avifishman70 @ 2018-05-29 8:35 UTC (permalink / raw)
To: gregkh, stern
Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
linux-usb, openbmc, robh+dt, mark.rutland, devicetree, davem,
mchehab+samsung, akpm, rdunlap, Avi Fishman
In-Reply-To: <1527582935-31175-1-git-send-email-avifishman70@gmail.com>
From: Avi Fishman <AviFishman70@gmail.com>
Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e0ce3c5f32e5..23c450adad44 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1727,7 +1727,10 @@ F: arch/arm/mach-npcm/
F: arch/arm/boot/dts/nuvoton-npcm*
F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
F: drivers/*/*npcm*
+F: drivers/*/*/*npcm*
F: Documentation/*/*npcm*
+F: Documentation/*/*/*npcm*
+F: Documentation/*/*/*/*npcm*
ARM/NUVOTON W90X900 ARM ARCHITECTURE
M: Wan ZongShun <mcuos.com@gmail.com>
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
From: Matti Vaittinen @ 2018-05-29 8:35 UTC (permalink / raw)
To: Lee Jones
Cc: Matti Vaittinen, mturquette, sboyd, robh+dt, mark.rutland,
lgirdwood, broonie, mazziesaccount, linux-clk, devicetree,
linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180529073958.GB4790@dell>
Hello,
On Tue, May 29, 2018 at 08:39:58AM +0100, Lee Jones wrote:
> On Mon, 28 May 2018, Matti Vaittinen wrote:
>
> > Patch series adding support for ROHM BD71837 PMIC.
> FYI, this patch-set is going to be difficult to manage since it was
> not sent 'threaded'.
>
> If/when you send a subsequent version, could you please ensure you
> send the set threaded so the patches keep in relation to one another
> as they are reviewed?
Thanks for the guidance. I have not sent so many patches to community so
I am grateful also from all the practical tips =) Just one slight problem.
I have only seen emails being threaded when one is replying to an email.
So how should I send my patches in same thread? Just send first one and
then send subsequent patches as replies?
I just killed some unused definitions and one unused variable from the
code so I am about to send new version. I'll try doing that as a threaded
series and resend all the patches as v3.
Br,
Matti Vaittinen
^ permalink raw reply
* Re: [PATCH v2] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998
From: Lee Jones @ 2018-05-29 8:38 UTC (permalink / raw)
To: Stephen Boyd; +Cc: linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20180502163535.208548-1-swboyd@chromium.org>
On Wed, 02 May 2018, Stephen Boyd wrote:
> Add the compatibles and PMIC ids for the pm8005, pm8998, and pmi8998
> PMICS found on MSM8998 and SDM845 based platforms.
>
> Cc: <devicetree@vger.kernel.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
>
> Changes from v1:
> * Picked up review tags
> * Reordered lists to be based on id numbers
>
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 3 +++
> drivers/mfd/qcom-spmi-pmic.c | 6 ++++++
> 2 files changed, 9 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] i2c: rcar: document R8A77980 bindings
From: Simon Horman @ 2018-05-29 8:48 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, linux-i2c, devicetree, Mark Rutland,
linux-renesas-soc
In-Reply-To: <95b945f7-1e6c-39f1-e101-06ed748ccec2@cogentembedded.com>
On Mon, May 28, 2018 at 10:39:05PM +0300, Sergei Shtylyov wrote:
> R-Car V3H (R8A77980) SoC also has the R-Car gen3 compatible I2C controller,
> so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
> The patch is against Wolfram Sang's 'linux.git' repo's 'i2c/for-next' branch
> but I wouldn't mind if it was applied to the 'i2c/for-current' branch. :-)
>
> Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> ===================================================================
> --- linux.orig/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> +++ linux/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> @@ -15,6 +15,7 @@ Required properties:
> "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
> "renesas,i2c-r8a77965" if the device is a part of a R8A77965 SoC.
> "renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC.
> + "renesas,i2c-r8a77980" if the device is a part of a R8A77980 SoC.
> "renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC.
> "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
> "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible
>
^ permalink raw reply
* Re: [PATCH v2 4/5] clk: renesas: r8a7795: add ccree clock bindings
From: Geert Uytterhoeven @ 2018-05-29 8:48 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller,
Ofir Drang, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-clk
In-Reply-To: <1527171551-21979-5-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 4:19 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, queueing in clk-renesas-for-v4.19, with "bindings" dropped from the
one-line summary.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 0/5] ARM: dts: dra7/am7xx: USB fixes and enhancements
From: Roger Quadros @ 2018-05-29 9:00 UTC (permalink / raw)
To: tony; +Cc: linux-omap, devicetree, linux-kernel, Roger Quadros
Hi Tony,
These are some fixes and enhancements for USB ports on dra7 and am57xx-idk EVMs.
If OK, please queue these for v4.18. Thanks.
Roger Quadros (5):
ARM: dts: dra7: Disable metastability workaround for USB2
ARM: dts: am57xx-idk: Enable dual role for USB2 port
ARM: dts: dra7-evm: Add extcon to USB2 port
ARM: dts: dra71-evm: Add VBUS GPIO to USB1/USB2 extcon
ARM: dts: dra76-evm: Add VBUS GPIO to USB1/USB2 extcon
arch/arm/boot/dts/am571x-idk.dts | 4 ----
arch/arm/boot/dts/am572x-idk-common.dtsi | 4 ----
arch/arm/boot/dts/am57xx-idk-common.dtsi | 7 ++++++-
arch/arm/boot/dts/dra7-evm-common.dtsi | 10 ++++++++++
arch/arm/boot/dts/dra7-evm.dts | 9 ---------
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/dra71-evm.dts | 8 ++++++++
arch/arm/boot/dts/dra72-evm-common.dtsi | 1 +
arch/arm/boot/dts/dra76-evm.dts | 8 ++++++++
9 files changed, 34 insertions(+), 19 deletions(-)
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH 1/5] ARM: dts: dra7: Disable metastability workaround for USB2
From: Roger Quadros @ 2018-05-29 9:00 UTC (permalink / raw)
To: tony; +Cc: linux-omap, devicetree, linux-kernel, Roger Quadros, [4.16+]
In-Reply-To: <1527584458-6257-1-git-send-email-rogerq@ti.com>
Disable the metastability workaround for USB2. The original
patch disabled the workaround on the wrong USB port.
Fixes: b8c9c6fa2002 ("ARM: dts: dra7: Disable USB metastability workaround for USB2")
Cc: <stable@vger.kernel.org> [4.16+]
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f4ddd86..9cace9f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1582,7 +1582,6 @@
dr_mode = "otg";
snps,dis_u3_susphy_quirk;
snps,dis_u2_susphy_quirk;
- snps,dis_metastability_quirk;
};
};
@@ -1610,6 +1609,7 @@
dr_mode = "otg";
snps,dis_u3_susphy_quirk;
snps,dis_u2_susphy_quirk;
+ snps,dis_metastability_quirk;
};
};
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox