* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-05-30 14:11 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
Cc: paul, tony, faiz_abbas, t-kristo, robh+dt, bcousson
In-Reply-To: <20180530141133.3711-1-faiz_abbas@ti.com>
Add clkctrl data for the m_can clocks and register it within the
clkctrl driver
CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
drivers/clk/ti/clk-7xx.c | 1 +
include/dt-bindings/clock/dra7.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index fb249a1637a5..71a122b2dc67 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -708,6 +708,7 @@ static const struct omap_clkctrl_reg_data dra7_wkupaon_clkctrl_regs[] __initcons
{ DRA7_COUNTER_32K_CLKCTRL, NULL, 0, "wkupaon_iclk_mux" },
{ DRA7_UART10_CLKCTRL, dra7_uart10_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0060:24" },
{ DRA7_DCAN1_CLKCTRL, dra7_dcan1_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0068:24" },
+ { DRA7_ADC_CLKCTRL, NULL, CLKF_SW_SUP, "mcan_clk" },
{ 0 },
};
diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
index 5e1061b15aed..d7549c57cac3 100644
--- a/include/dt-bindings/clock/dra7.h
+++ b/include/dt-bindings/clock/dra7.h
@@ -168,5 +168,6 @@
#define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
#define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
#define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
+#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
#endif
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/6] ARM: dts: dra762: Add MCAN clock support
From: Faiz Abbas @ 2018-05-30 14:11 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
Cc: robh+dt, bcousson, tony, paul, t-kristo, faiz_abbas
In-Reply-To: <20180530141133.3711-1-faiz_abbas@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
arch/arm/boot/dts/dra76x.dtsi | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c581ff18..bfc82636999c 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
&crossbar_mpu {
ti,irqs-skip = <10 67 68 133 139 140>;
};
+
+&scm_conf_clocks {
+ dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck@3fc {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&dpll_gmac_x2_ck>;
+ ti,max-div = <63>;
+ reg = <0x03fc>;
+ ti,bit-shift=<20>;
+ ti,latch-bit=<26>;
+ assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+ assigned-clock-rates = <80000000>;
+ };
+
+ dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck@3fc {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+ reg = <0x3fc>;
+ ti,bit-shift = <29>;
+ ti,latch-bit=<26>;
+ assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+ assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+ };
+
+ mcan_clk: mcan_clk@3fc {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+ ti,bit-shift = <27>;
+ reg = <0x3fc>;
+ };
+};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Faiz Abbas @ 2018-05-30 14:11 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
Cc: robh+dt, bcousson, tony, paul, t-kristo, faiz_abbas
In-Reply-To: <20180530141133.3711-1-faiz_abbas@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Add MCAN hwmod data and register it for dra762 silicons.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 62352d1e6361..a2cd7f865a60 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1355,6 +1355,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
},
};
+/*
+ * 'mcan' class
+ *
+ */
+static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
+ .name = "mcan",
+};
+
+/* mcan */
+static struct omap_hwmod dra76x_mcan_hwmod = {
+ .name = "mcan",
+ .class = &dra76x_mcan_hwmod_class,
+ .clkdm_name = "wkupaon_clkdm",
+ .main_clk = "mcan_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_WKUPAON_ADC_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_WKUPAON_ADC_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/*
* 'mcspi' class
*
@@ -3818,6 +3841,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss2 = {
.user = OCP_USER_MPU,
};
+/* l3_main_1 -> mcan */
+static struct omap_hwmod_ocp_if dra76x_l3_main_1__mcan = {
+ .master = &dra7xx_l3_main_1_hwmod,
+ .slave = &dra76x_mcan_hwmod,
+ .clk = "l3_iclk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l3_main_1__dmm,
&dra7xx_l3_main_2__l3_instr,
@@ -3958,6 +3989,7 @@ static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
/* SoC variant specific hwmod links */
static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l4_per3__usb_otg_ss4,
+ &dra76x_l3_main_1__mcan,
NULL,
};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/6] Add MCAN Support for dra76x
From: Faiz Abbas @ 2018-05-30 14:11 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk
Cc: robh+dt, bcousson, tony, paul, t-kristo, faiz_abbas
The following patches add dts, hwmod and sysconfig support
for MCAN on TI's dra76 SOCs
The patches depend on the following series:
https://patchwork.kernel.org/patch/10221105/
Changes in v2:
1. Added Support for mcan in the ti-sysc driver
Also added the target-module node for the same
2. Added clkctrl data for mcan clocks
Faiz Abbas (3):
clk: ti: dra7: Add clkctrl clock data for the mcan clocks
bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
ARM: dts: Add generic interconnect target module node for MCAN
Franklin S Cooper Jr (1):
ARM: dts: dra76x: Add MCAN node
Lokesh Vutla (2):
ARM: dra762: hwmod: Add MCAN support
ARM: dts: dra762: Add MCAN clock support
.../devicetree/bindings/bus/ti-sysc.txt | 1 +
arch/arm/boot/dts/dra76-evm.dts | 7 ++
arch/arm/boot/dts/dra76x.dtsi | 67 +++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++++++++
drivers/bus/ti-sysc.c | 17 +++++
drivers/clk/ti/clk-7xx.c | 1 +
include/dt-bindings/bus/ti-sysc.h | 2 +
include/dt-bindings/clock/dra7.h | 1 +
include/linux/platform_data/ti-sysc.h | 1 +
9 files changed, 129 insertions(+)
--
2.17.0
^ permalink raw reply
* Re: [PATCH 2/4] arcnet: com20020: bindings for smsc com20020
From: Andrea Greco @ 2018-05-30 14:07 UTC (permalink / raw)
To: Rob Herring
Cc: Tobin C. Harding, Andrea Greco, Mark Rutland, netdev, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqL1M3SuH_cJGUhh0+Xg+UYDjAc-=a+USENOKznvWib1Ng@mail.gmail.com>
On 05/24/2018 04:36 PM, Rob Herring wrote> If you want to add it, that's
fine. But it's really not something that
> comes up often. For UARTs, there's already the "current-speed"
> property and most other things I can think of use Hz to express
> speeds.
No, Pref keep standard and use Hz.
This if finally:
```
SMSC com20020 Arcnet network controller
Required property:
- timeout-ns: Arcnet bus timeout, Idle Time (328000 - 20500)
- bus-speed-bps: Arcnet bus speed (10000000 - 156250)
- smsc,xtal-mhz: External oscillator frequency
- smsc,backplane-enabled: Controller use backplane mode
- reset-gpios: Chip reset pin
- interrupts: Should contain controller interrupt
arcnet@28000000 {
compatible = "smsc,com20020";
timeout-ns = <20500>;
bus-speed-hz = <10000000>;
smsc,xtal-mhz = <20>;
smsc,backplane-enabled;
reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
interrupts = <&gpio2 10 GPIO_ACTIVE_LOW>;
};
```
If confirmed, for me is right
Andrea
^ permalink raw reply
* RE: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
From: Phil Edworthy @ 2018-05-30 13:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: M P, Michel Pollet, Linux-Renesas, Simon Horman, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <CAMuHMdV8Hey=L6jv7HFyTUbeKdcC8ygn7PFjW2akETHe44MjeQ@mail.gmail.com>
Hi Geert,
On 30 May 2018 14:37 Geert Uytterhoeven wrote:
> On Wed, May 30, 2018 at 3:30 PM, Phil Edworthy wrote:
> > On 25 May 2018 10:13 Geert Uytterhoeven wrote:
> > [snip]
> >
> >> Now, given the clock definitions for RZ/N1[DSL] are the same
> >> (although some don't exist on some variants), you could keep on using
> >> RZN1_CLK_FOO for the names of the defines, and store them in a
> common
> >> file, included by the soc-specific file. But please make clear the
> >> common file cannot be included directly, so the filename does not
> >> become part of the DT ABI, and you are shielded from future marketing
> >> silliness (e.g. next quarter's RZ/N1X being totally different).
> > How does an include filename become part of the DT ABI?
> > I thought the dtb is the ABI, not the dts. Am I wrong?
>
> You're right. In se the DT ABI applies to the DTB, not to the DTS.
>
> The definitions inside the include file are part of the DT bindings, and thus
> cannot be changed. Your DTS files get these definitions by including the
> header file, so the header filename is also part of the bindings, and thus can't
> be changed that easily.
That seems a bit onerous...
It makes sense that bindings that affect the dtb can only be added to, so that
an old dtb still works. However, I would have thought it's the value of the
constant that is the ABI, not the symbol name used to specify it.
Thanks for you feedback!
Phil
^ permalink raw reply
* Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
From: Geert Uytterhoeven @ 2018-05-30 13:36 UTC (permalink / raw)
To: Phil Edworthy
Cc: M P, Michel Pollet, Linux-Renesas, Simon Horman, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <TY1PR01MB1769DFD4CD9803D10CE1CA4BF56C0@TY1PR01MB1769.jpnprd01.prod.outlook.com>
Hi Phil,
On Wed, May 30, 2018 at 3:30 PM, Phil Edworthy
<phil.edworthy@renesas.com> wrote:
> On 25 May 2018 10:13 Geert Uytterhoeven wrote:
> [snip]
>
>> Now, given the clock definitions for RZ/N1[DSL] are the same (although some
>> don't exist on some variants), you could keep on using RZN1_CLK_FOO for
>> the names of the defines, and store them in a common file, included by the
>> soc-specific file. But please make clear the common file cannot be included
>> directly, so the filename does not become part of the DT ABI, and you are
>> shielded from future marketing silliness (e.g. next quarter's RZ/N1X being
>> totally different).
> How does an include filename become part of the DT ABI?
> I thought the dtb is the ABI, not the dts. Am I wrong?
You're right. In se the DT ABI applies to the DTB, not to the DTS.
The definitions inside the include file are part of the DT bindings,
and thus cannot
be changed. Your DTS files get these definitions by including the header file,
so the header filename is also part of the bindings, and thus can't be changed
that easily.
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
* RE: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
From: Phil Edworthy @ 2018-05-30 13:30 UTC (permalink / raw)
To: Geert Uytterhoeven, M P
Cc: Michel Pollet, Linux-Renesas, Simon Horman, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <CAMuHMdWVde-DfbLVbvZT4rQfsVz1z7AMyQVgbO2DXrQKsEdVcw@mail.gmail.com>
Hi Geert,
On 25 May 2018 10:13 Geert Uytterhoeven wrote:
[snip]
> Now, given the clock definitions for RZ/N1[DSL] are the same (although some
> don't exist on some variants), you could keep on using RZN1_CLK_FOO for
> the names of the defines, and store them in a common file, included by the
> soc-specific file. But please make clear the common file cannot be included
> directly, so the filename does not become part of the DT ABI, and you are
> shielded from future marketing silliness (e.g. next quarter's RZ/N1X being
> totally different).
How does an include filename become part of the DT ABI?
I thought the dtb is the ABI, not the dts. Am I wrong?
Thanks
Phil
^ permalink raw reply
* Re: [PATCH 09/13] Bluetooth: hci_serdev: Fix HCI_UART_INIT_PENDING not working
From: Rob Herring @ 2018-05-30 13:25 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Johan Hedberg, Martin Blumenstingl, Jeremy Cline,
open list:BLUETOOTH DRIVERS, open list:SERIAL DRIVERS, linux-acpi,
devicetree
In-Reply-To: <20180527190457.2632-10-hdegoede@redhat.com>
On Sun, May 27, 2018 at 2:04 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Init hci_uart->init_ready so that hci_uart_init_ready() works properly.
Why do you need to init in a wq? For serdev devices, probe is async
already. So my thought was this wouldn't be needed.
Rob
^ permalink raw reply
* Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
From: Laurent Pinchart @ 2018-05-30 13:20 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Maciej Purski, linux-kernel, linux-arm-kernel, linux-samsung-soc,
devicetree, dri-devel, David Airlie, Rob Herring, Mark Rutland,
Thierry Reding, Kukjin Kim, Krzysztof Kozlowski, Archit Taneja,
Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyungmin Park,
Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20180530130731eucas1p160d53c3f8500bcecd000bd8895843817~zbgGgQw3b1079710797eucas1p1H@eucas1p1.samsung.com>
Hi Andrzej,
On Wednesday, 30 May 2018 16:07:29 EEST Andrzej Hajda wrote:
> On 30.05.2018 14:35, Laurent Pinchart wrote:
> > On Wednesday, 30 May 2018 12:59:12 EEST Andrzej Hajda wrote:
> >> On 28.05.2018 12:18, Laurent Pinchart wrote:
> >>> On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote:
> >>>> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> >>>> Bindings describe power supplies, reset gpio and video interfaces.
> >>>>
> >>>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> >>>> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> >>>> ---
> >>>>
> >>>> .../bindings/display/bridge/toshiba,tc358764.txt | 42
> >>>> ++++++++++++++++
> >>>> 1 file changed, 42 insertions(+)
> >>>> create mode 100644
> >>>>
> >>>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> new
> >>>> file mode 100644
> >>>> index 0000000..d09bdc2
> >>>> --- /dev/null
> >>>> +++
> >>>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>>> @@ -0,0 +1,42 @@
> >>>> +TC358764 MIPI-DSI to LVDS panel bridge
> >>>> +
> >>>> +Required properties:
> >>>> + - compatible: "toshiba,tc358764"
> >>>> + - reg: the virtual channel number of a DSI peripheral
> >>>> + - vddc-supply: core voltage supply
> >>>> + - vddio-supply: I/O voltage supply
> >>>> + - vddmipi-supply: MIPI voltage supply
> >>>> + - vddlvds133-supply: LVDS1 3.3V voltage supply
> >>>> + - vddlvds112-supply: LVDS1 1.2V voltage supply
> >>>
> >>> That's a lot of power supplies. Could some of them be merged together ?
> >>> See https://patchwork.freedesktop.org/patch/216058/ for an earlier
> >>> discussion on the same subject.
> >>
> >> Specs says about 3 supply voltage values:
> >> - 1.2V - digital core, DSI-RX PHY
> >> - 1.8-3.3V - digital I/O
> >> - 3.3V - LVDS-TX PHY
> >>
> >> So I guess it should be minimal number of supplies. Natural candidates:
> >>
> >> - vddc-supply: core voltage supply, 1.2V
> >> - vddio-supply: I/O voltage supply, 1.8V or 3.3V
> >> - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
> >>
> >> I have changed name of the latest supply to be more consistent with
> >> other supplies, and changed 1.8-3.3 (which incorrectly suggest voltage
> >> range), to more precise voltage alternative.
> >
> > This looks fine to me.
> >
> >>>> + - reset-gpios: a GPIO spec for the reset pin
> >>>> +
> >>>> +The device node can contain zero to two 'port' child nodes, each with
> >>>> one
> >>>> +child
> >>>> +'endpoint' node, according to the bindings defined in [1].
> >>>> +The following are properties specific to those nodes.
> >>>> +
> >>>> +port:
> >>>> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
> >>>
> >>> This seems pretty vague to me. It could be read as meaning that ports
> >>> are
> >>> completely optional, and that the port number you list can be used, but
> >>> that something else could be used to.
> >>>
> >>> Let's make the port nodes mandatory. I propose the following.
> >>>
> >>> Required nodes:
> >>>
> >>> The TC358764 has DSI and LVDS ports whose connections are described
> >>> using
> >>> the OF graph bindings defined in
> >>> Documentation/devicetree/bindings/graph.txt. The device node must
> >>> contain
> >>> one 'port' child node per DSI and LVDS port. The port nodes are numbered
> >>> as follows.
> >>>
> >>> Port Number
> >>>
> >>> -------------------------------------------------------------------
> >>>
> >>> DSI Input 0
> >>> LVDS Output 1
> >>>
> >>> Each port node must contain endpoint nodes describing the hardware
> >>> connections.
> >>
> >> Since the bridge is controlled via DSI bus, DSI input port is not
> >> necessary.
> >
> > I don't agree with this. Regardless of how the bridge is controlled, I
> > think we should always use ports to describe the data connections.
> > Otherwise it would get more complicated for display controller drivers to
> > use different types of bridges.
>
> It was discussed already, and DT guideline is to skip graphs in simple
> case of parent/child nodes, see for example [1].
>
> [1]: https://marc.info/?l=dri-devel&m=148354108702517&w=2
That's when the child as no other connection at all. I don't think it makes
sense to mix description of connections through parent/child relationships and
through ports for a single device.
And that being said, I don't agree with Rob's comment there. Having two
different methods to describe connections means that you have to implement
them both in all display controller drivers (and even all bridge drivers in
the case of chained bridges). That's an extra complexity that can easily be
avoided by standardizing DT bindings.
I also wonder whether Rob's position hasn't been reconsidered since then; I
vaguely recalled another more recent discussion on this topic. I'm a bit too
busy now to try and dig it up now I'm afraid :-/
> >>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >>>> +
> >>>> +Example:
> >>>> +
> >>>> + bridge@0 {
> >>>> + reg = <0>;
> >>>> + compatible = "toshiba,tc358764";
> >>>> + vddc-supply = <&vcc_1v2_reg>;
> >>>> + vddio-supply = <&vcc_1v8_reg>;
> >>>> + vddmipi-supply = <&vcc_1v2_reg>;
> >>>> + vddlvds133-supply = <&vcc_3v3_reg>;
> >>>> + vddlvds112-supply = <&vcc_1v2_reg>;
> >>>> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + port@1 {
> >>>> + reg = <1>;
> >>>> + lvds_ep: endpoint {
> >>>> + remote-endpoint = <&panel_ep>;
> >>>> + };
> >>>> + };
> >>>> + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 10/11] ARM64: dts: ls1046a: Remove fsl, qspi-has-second-chip as it is not used
From: Frieder Schrempf @ 2018-05-30 13:14 UTC (permalink / raw)
To: linux-mtd, boris.brezillon, linux-spi
Cc: Mark Rutland, yogeshnarayan.gaur, Madalin Bucur, Catalin Marinas,
broonie, Will Deacon, Minghuan Lian, miquel.raynal, david.wolfe,
richard, marek.vasut, Frieder Schrempf, devicetree, Hou Zhiqiang,
Rob Herring, han.xu, linux-arm-kernel, computersforpeace,
Yuantian Tang, Shawn Guo, linux-kernel, prabhakar.kushwaha,
fabio.estevam, Ran Wang, dwmw2
In-Reply-To: <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de>
After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.
The driver now uses the 'reg' property to determine the bus and
the chipselect.
Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa..871189e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -247,7 +247,6 @@
clock-names = "qspi_en", "qspi";
clocks = <&clockgen 4 1>, <&clockgen 4 1>;
big-endian;
- fsl,qspi-has-second-chip;
status = "disabled";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 09/11] ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used
From: Frieder Schrempf @ 2018-05-30 13:14 UTC (permalink / raw)
To: linux-mtd, boris.brezillon, linux-spi
Cc: dwmw2, computersforpeace, marek.vasut, richard, miquel.raynal,
broonie, david.wolfe, fabio.estevam, prabhakar.kushwaha,
yogeshnarayan.gaur, han.xu, Frieder Schrempf, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de>
After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.
The driver now uses the 'reg' property to determine the bus and
the chipselect.
Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index 6a83f30..d3a1a73 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,7 +203,6 @@
};
&qspi {
- fsl,qspi-has-second-chip;
status = "okay";
flash: flash@0 {
--
2.7.4
^ permalink raw reply related
* [PATCH 06/11] arm64: dts: Reflect change of FSL QSPI driver and remove unused properties
From: Frieder Schrempf @ 2018-05-30 13:14 UTC (permalink / raw)
To: linux-mtd, boris.brezillon, linux-spi
Cc: dwmw2, computersforpeace, marek.vasut, richard, miquel.raynal,
broonie, david.wolfe, fabio.estevam, prabhakar.kushwaha,
yogeshnarayan.gaur, han.xu, Frieder Schrempf, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Shawn Guo, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de>
The FSL QSPI driver was moved to the SPI framework and it now
acts as a SPI controller. Therefore the subnodes need to set
spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.
Also the properties 'num-cs' and 'bus-num' were never read by the
driver and can be removed.
The property 'fsl,qspi-has-second-chip' is not needed anymore
and will be removed after the old driver was disabled to avoid
breaking fsl-ls1046a-rdb.dts.
Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 3 ++-
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 4 ++--
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 6 ++++--
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 6341281..31e7b31 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -170,7 +170,6 @@
};
&qspi {
- bus-num = <0>;
status = "okay";
qflash0: s25fl128s@0 {
@@ -178,6 +177,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index 434383b..dc10105 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -198,8 +198,6 @@
};
&qspi {
- num-cs = <2>;
- bus-num = <0>;
status = "okay";
qflash0: s25fl128s@0 {
@@ -207,6 +205,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 5dc2782..1848c33 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -136,8 +136,6 @@
};
&qspi {
- num-cs = <2>;
- bus-num = <0>;
status = "okay";
qflash0: s25fs512s@0 {
@@ -145,6 +143,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
@@ -153,6 +153,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <1>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
index 1de6188..fc62ed9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
@@ -170,6 +170,8 @@
#size-cells = <1>;
compatible = "st,m25p80";
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
flash2: s25fl256s1@2 {
@@ -177,6 +179,8 @@
#size-cells = <1>;
compatible = "st,m25p80";
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <2>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 05/11] ARM: dts: Reflect change of FSL QSPI driver and remove unused properties
From: Frieder Schrempf @ 2018-05-30 13:14 UTC (permalink / raw)
To: linux-mtd, boris.brezillon, linux-spi
Cc: dwmw2, computersforpeace, marek.vasut, richard, miquel.raynal,
broonie, david.wolfe, fabio.estevam, prabhakar.kushwaha,
yogeshnarayan.gaur, han.xu, Frieder Schrempf, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Rob Herring, Mark Rutland,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de>
The FSL QSPI driver was moved to the SPI framework and it now
acts as a SPI controller. Therefore the subnodes need to set
spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.
Also the properties 'bus-num', 'fsl,spi-num-chipselects' and
'fsl,spi-flash-chipselects' were never read by the driver and
can be removed.
The 'reg' properties are adjusted to reflect the what bus and
chipselect the flash is connected to, as the new driver needs
this information.
The property 'fsl,qspi-has-second-chip' is not needed anymore
and will be removed after the old driver was disabled to avoid
breaking ls1021a-moxa-uc-8410a.dts.
Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 ++++++--
arch/arm/boot/dts/imx6sx-sdb.dts | 8 ++++++--
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
4 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
index e3533e7..1a6f680 100644
--- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
@@ -131,13 +131,17 @@
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
- flash1: s25fl128s@1 {
- reg = <1>;
+ flash1: s25fl128s@2 {
+ reg = <2>;
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
};
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 6dd9beb..9acfda8 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -117,15 +117,19 @@
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
- flash1: n25q256a@1 {
+ flash1: n25q256a@2 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
- reg = <1>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ reg = <2>;
};
};
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 32a0723..c2c9a2a 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -176,6 +176,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index d01f64b..6a83f30 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,9 +203,6 @@
};
&qspi {
- bus-num = <0>;
- fsl,spi-num-chipselects = <2>;
- fsl,spi-flash-chipselects = <0>;
fsl,qspi-has-second-chip;
status = "okay";
@@ -214,6 +211,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
partitions@0 {
--
2.7.4
^ permalink raw reply related
* [PATCH 04/11] dt-bindings: spi: Move and adjust the bindings for the fsl-qspi driver
From: Frieder Schrempf @ 2018-05-30 13:14 UTC (permalink / raw)
To: linux-mtd, boris.brezillon, linux-spi
Cc: dwmw2, computersforpeace, marek.vasut, richard, miquel.raynal,
broonie, david.wolfe, fabio.estevam, prabhakar.kushwaha,
yogeshnarayan.gaur, han.xu, Frieder Schrempf, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de>
Move the documentation of the old SPI NOR driver to the place of the new
SPI memory interface based driver and adjust the content to reflect the
new drivers settings.
Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
.../devicetree/bindings/mtd/fsl-quadspi.txt | 65 ------------------
.../devicetree/bindings/spi/spi-fsl-qspi.txt | 69 ++++++++++++++++++++
2 files changed, 69 insertions(+), 65 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
deleted file mode 100644
index 483e9cf..0000000
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-* Freescale Quad Serial Peripheral Interface(QuadSPI)
-
-Required properties:
- - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
- "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
- "fsl,ls1021a-qspi"
- or
- "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
- "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
- - reg : the first contains the register location and length,
- the second contains the memory mapping address and length
- - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
- - interrupts : Should contain the interrupt for the device
- - clocks : The clocks needed by the QuadSPI controller
- - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
-
-Optional properties:
- - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
- Each bus can be connected with two NOR flashes.
- Most of the time, each bus only has one NOR flash
- connected, this is the default case.
- But if there are two NOR flashes connected to the
- bus, you should enable this property.
- (Please check the board's schematic.)
- - big-endian : That means the IP register is big endian
-
-Example:
-
-qspi0: quadspi@40044000 {
- compatible = "fsl,vf610-qspi";
- reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
- reg-names = "QuadSPI", "QuadSPI-memory";
- interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks VF610_CLK_QSPI0_EN>,
- <&clks VF610_CLK_QSPI0>;
- clock-names = "qspi_en", "qspi";
-
- flash0: s25fl128s@0 {
- ....
- };
-};
-
-Example showing the usage of two SPI NOR devices:
-
-&qspi2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_qspi2>;
- status = "okay";
-
- flash0: n25q256a@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "micron,n25q256a", "jedec,spi-nor";
- spi-max-frequency = <29000000>;
- reg = <0>;
- };
-
- flash1: n25q256a@1 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "micron,n25q256a", "jedec,spi-nor";
- spi-max-frequency = <29000000>;
- reg = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
new file mode 100644
index 0000000..0ee9cd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
@@ -0,0 +1,69 @@
+* Freescale Quad Serial Peripheral Interface(QuadSPI)
+
+Required properties:
+ - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
+ "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
+ "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
+ or
+ "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
+ - reg : the first contains the register location and length,
+ the second contains the memory mapping address and length
+ - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
+ - interrupts : Should contain the interrupt for the device
+ - clocks : The clocks needed by the QuadSPI controller
+ - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
+
+Optional properties:
+ - big-endian : That means the IP registers format is big endian
+
+Required SPI slave node properties:
+ - reg: There are two buses (A and B) with two chip selects each.
+ This encodes to which bus and CS the flash is connected:
+ <0>: Bus A, CS 0
+ <1>: Bus A, CS 1
+ <2>: Bus B, CS 0
+ <3>: Bus B, CS 1
+
+Example:
+
+qspi0: quadspi@40044000 {
+ compatible = "fsl,vf610-qspi";
+ reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
+ reg-names = "QuadSPI", "QuadSPI-memory";
+ interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_QSPI0_EN>,
+ <&clks VF610_CLK_QSPI0>;
+ clock-names = "qspi_en", "qspi";
+
+ flash0: s25fl128s@0 {
+ ....
+ };
+};
+
+Example showing the usage of two SPI NOR devices on bus A:
+
+&qspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi2>;
+ status = "okay";
+
+ flash0: n25q256a@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q256a", "jedec,spi-nor";
+ spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ reg = <0>;
+ };
+
+ flash1: n25q256a@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q256a", "jedec,spi-nor";
+ spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ reg = <1>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
From: Andrzej Hajda @ 2018-05-30 13:07 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maciej Purski, linux-kernel, linux-arm-kernel, linux-samsung-soc,
devicetree, dri-devel, David Airlie, Rob Herring, Mark Rutland,
Thierry Reding, Kukjin Kim, Krzysztof Kozlowski, Archit Taneja,
Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyungmin Park,
Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1928297.lKUBOH9NhR@avalon>
On 30.05.2018 14:35, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday, 30 May 2018 12:59:12 EEST Andrzej Hajda wrote:
>> On 28.05.2018 12:18, Laurent Pinchart wrote:
>>> On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote:
>>>> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
>>>> Bindings describe power supplies, reset gpio and video interfaces.
>>>>
>>>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>>>> Signed-off-by: Maciej Purski <m.purski@samsung.com>
>>>> ---
>>>>
>>>> .../bindings/display/bridge/toshiba,tc358764.txt | 42 ++++++++++++++++
>>>> 1 file changed, 42 insertions(+)
>>>> create mode 100644
>>>>
>>>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>>>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>>>> new
>>>> file mode 100644
>>>> index 0000000..d09bdc2
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>>>> @@ -0,0 +1,42 @@
>>>> +TC358764 MIPI-DSI to LVDS panel bridge
>>>> +
>>>> +Required properties:
>>>> + - compatible: "toshiba,tc358764"
>>>> + - reg: the virtual channel number of a DSI peripheral
>>>> + - vddc-supply: core voltage supply
>>>> + - vddio-supply: I/O voltage supply
>>>> + - vddmipi-supply: MIPI voltage supply
>>>> + - vddlvds133-supply: LVDS1 3.3V voltage supply
>>>> + - vddlvds112-supply: LVDS1 1.2V voltage supply
>>> That's a lot of power supplies. Could some of them be merged together ?
>>> See https://patchwork.freedesktop.org/patch/216058/ for an earlier
>>> discussion on the same subject.
>> Specs says about 3 supply voltage values:
>> - 1.2V - digital core, DSI-RX PHY
>> - 1.8-3.3V - digital I/O
>> - 3.3V - LVDS-TX PHY
>>
>> So I guess it should be minimal number of supplies. Natural candidates:
>>
>> - vddc-supply: core voltage supply, 1.2V
>> - vddio-supply: I/O voltage supply, 1.8V or 3.3V
>> - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
>>
>> I have changed name of the latest supply to be more consistent with
>> other supplies, and changed 1.8-3.3 (which incorrectly suggest voltage
>> range), to more precise voltage alternative.
> This looks fine to me.
>
>>>> + - reset-gpios: a GPIO spec for the reset pin
>>>> +
>>>> +The device node can contain zero to two 'port' child nodes, each with
>>>> one
>>>> +child
>>>> +'endpoint' node, according to the bindings defined in [1].
>>>> +The following are properties specific to those nodes.
>>>> +
>>>> +port:
>>>> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
>>> This seems pretty vague to me. It could be read as meaning that ports are
>>> completely optional, and that the port number you list can be used, but
>>> that something else could be used to.
>>>
>>> Let's make the port nodes mandatory. I propose the following.
>>>
>>> Required nodes:
>>>
>>> The TC358764 has DSI and LVDS ports whose connections are described using
>>> the OF graph bindings defined in
>>> Documentation/devicetree/bindings/graph.txt. The device node must contain
>>> one 'port' child node per DSI and LVDS port. The port nodes are numbered
>>> as follows.
>>>
>>> Port Number
>>> -------------------------------------------------------------------
>>> DSI Input 0
>>> LVDS Output 1
>>>
>>> Each port node must contain endpoint nodes describing the hardware
>>> connections.
>> Since the bridge is controlled via DSI bus, DSI input port is not necessary.
> I don't agree with this. Regardless of how the bridge is controlled, I think
> we should always use ports to describe the data connections. Otherwise it
> would get more complicated for display controller drivers to use different
> types of bridges.
It was discussed already, and DT guideline is to skip graphs in simple
case of parent/child nodes, see for example [1].
[1]: https://marc.info/?l=dri-devel&m=148354108702517&w=2
Regards
Andrzej
>>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>>> +
>>>> +Example:
>>>> +
>>>> + bridge@0 {
>>>> + reg = <0>;
>>>> + compatible = "toshiba,tc358764";
>>>> + vddc-supply = <&vcc_1v2_reg>;
>>>> + vddio-supply = <&vcc_1v8_reg>;
>>>> + vddmipi-supply = <&vcc_1v2_reg>;
>>>> + vddlvds133-supply = <&vcc_3v3_reg>;
>>>> + vddlvds112-supply = <&vcc_1v2_reg>;
>>>> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + port@1 {
>>>> + reg = <1>;
>>>> + lvds_ep: endpoint {
>>>> + remote-endpoint = <&panel_ep>;
>>>> + };
>>>> + };
>>>> + };
^ permalink raw reply
* Re: Applied "regulator: bd71837: BD71837 PMIC regulator driver" to the regulator tree
From: Matti Vaittinen @ 2018-05-30 12:58 UTC (permalink / raw)
To: Mark Brown
Cc: Matti Vaittinen, Matti Vaittinen, mturquette, sboyd, robh+dt,
mark.rutland, lee.jones, lgirdwood, linux-clk, devicetree,
linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180530111714.GJ6920@sirena.org.uk>
On Wed, May 30, 2018 at 12:17:14PM +0100, Mark Brown wrote:
> On Wed, May 30, 2018 at 02:14:25PM +0300, Matti Vaittinen wrote:
>
> > The patch 1/6 contains the header file
> > include/linux/mfd/bd71837.h with bunch of definitions this patch is
> > requiring.
>
> Your driver won't actually get built until the MFD parts end up in the
> same tree since the regulator driver depends on the MFD so there's no
> problem, the code will just sit there and not cause any problems.
Oh, right. Thanks! So MFD and clk portions should go through the other
trees then.
Br,
Matti Vaittinen
^ permalink raw reply
* Re: [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
From: Matti Vaittinen @ 2018-05-30 12:56 UTC (permalink / raw)
To: Mark Brown
Cc: Matti Vaittinen, Matti Vaittinen, mturquette, sboyd, robh+dt,
mark.rutland, lee.jones, lgirdwood, linux-clk, devicetree,
linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180530110000.GI6920@sirena.org.uk>
On Wed, May 30, 2018 at 12:00:00PM +0100, Mark Brown wrote:
> On Wed, May 30, 2018 at 12:05:12PM +0300, Matti Vaittinen wrote:
>
> > Other 4 can be used on PWM or PFM switching mode. When PWM is used
> > voltages can be changed without disabling regulator. On PFM this should
> > not be done. These latter 4 regulators can be forced to PWM mode via
> > control bit in register. This driver does not support controlling this
> > mode though. So this driver version just checks if regulator is enabled
> > before changing the voltage and if it is the voltage change fails with
> > -EBUSY
>
> It probably should support setting modes (especially if the device isn't
> smart enough to automatically shift which sounds like the case) but
> that's a separate thing.
Thanks for the guidance! The first 4 BUCKs (which support DVS) do change
the mode automatically. Latter 4 do not. I however didn't find example
on how to allow doing this mode change via regulator framework and thus
the driver is not allowing mode change. For me it would sound good to
allow setting the mode via device-tree property - and via in-kernel API
or sysfs - but as I said I didn't yet find a nice example on that. (But
I assume this device is not first one allowing mode change and thus
there should be an example and I probably should not invent own DT
properties or sysfs entries for this. Guess I just need to search harder).
>
> > My question is whether it would be good idea to also read the 'force
> > PWM' bit when voltage is changed and allow the change if PWM mode is
> > forced to be used? Problem is that the check and voltage change can't be
> > atomic so there is a chance someone changes the mode (bypassing the
> > driver and regulator core) after this check but before we get to modify
> > the voltage. Furthermore, I doubt the 'force PWM' is widely used (but I
> > can't say for sure as I can't imagine all use cases) as it is not so
> > power efficient.
>
> Why would anything else be changing the mode configuration of the
> regulator while the system is running? That sounds like a bad idea.
This was also my initial thought. Still with my lack of experience on this
area (and with my experience on people inventing strange solutions) I
felt unsure.
> In any case if the hardware really needs to be manually put into force
> PWM to change voltage then the simplest thing would be to just move it
> into force PWM mode, do the change, then change back if it wasn't
> already in force PWM mode.
I see 4 options for these last 4 bucks which can't switch to PWM
automatically when voltage is changed.
1. prohibit voltage change if regulator is enabled (safest? current
approach)
2. allow voltage change if regulator is enabled and force PWM is used
3. switch to 'force PWM' when changing voltage (as suggested by Mark)
4. disable regulator for duration of voltage change (discarded option)
So option 4 was discarded. Option 1 is the current approach. I will ask
from ROHM PMIC HW colleagues what they think of Mark's suggestion
(option 3) and implement it if HW behaves Ok. I guess option 2 is not
worth the hassle.
>
> The tradeoff with forced PWM mode is that the quality of regulation will
> be a lot better, especially if the load changes suddenly (as things like
> CPUs often do). Most hardware that's at all current is able respond to
> changes in load and switch modes automatically when it's appropriate,
> except possibly in some very low power modes.
Yes. The mode switching is automatic. But there is this control bit for
disabling automatic mode switching and forcing the PWM. Problem with
these 4 last bucks is just that if regulator is in PFM (and it may be
if not forced to PWM - due to this automatic switching) then the voltage
change is not behaving well.
Thanks for all the support Mark!
Br,
Matti Vaittinen
^ permalink raw reply
* Re: [PATCH v2 1/6] soc: qcom: rpmpd: Add a powerdomain driver to model corners
From: Ulf Hansson @ 2018-05-30 12:44 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Viresh Kumar, Stephen Boyd, Andy Gross, devicetree, linux-arm-msm,
Linux Kernel Mailing List, collinsd
In-Reply-To: <0e07d577-9728-e97a-2da0-dd7dd324f058@codeaurora.org>
[...]
>>> +
>>> +static DEFINE_MUTEX(rpmpd_lock);
>>> +
>>> +/* msm8996 RPM powerdomains */
>>> +DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1);
>>> +DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2);
>>> +DEFINE_RPMPD_CORN_LDOA(msm8996, vddsscx, 26);
>>> +
>>> +DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
>>> +DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
>>> +
>>> +static struct rpmpd *msm8996_rpmpds[] = {
>>> + [0] = &msm8996_vddcx,
>>> + [1] = &msm8996_vddcx_ao,
>>> + [2] = &msm8996_vddcx_vfc,
>>> + [3] = &msm8996_vddmx,
>>> + [4] = &msm8996_vddmx_ao,
>>> + [5] = &msm8996_vddsscx,
>>> + [6] = &msm8996_vddsscx_vfc,
>>> +};
>>
>> It's not my call, but honestly the above all macros makes the code
>> less readable.
>
> This is all static data per SoC. The macros will keep the new additions
> needed for every new SoC to a minimal. Currently this supports only
> msm8996.
Right, that's fine then.
>
>>
>> Anyway, I think you should convert to allocate these structs
>> dynamically from the heap (kzalloc/kcalloc), instead of statically as
>> above.
However, I assume this is still doable!?
[...]
>>> + for (i = 0; i < num; i++) {
>>> + if (!rpmpds[i])
>>> + continue;
>>> +
>>> + rpmpds[i]->rpm = rpm;
>>> + rpmpds[i]->pd.power_off = rpmpd_power_off;
>>> + rpmpds[i]->pd.power_on = rpmpd_power_on;
>>> + pm_genpd_init(&rpmpds[i]->pd, NULL, true);
>>
>> Question: Is there no hierarchical topology of the PM domains. No
>> genpd subdomains?
>
> The hierarchy if any is all handled by the remote core (RPM in this case).
> For Linux its just a flat view.
Okay, thanks for clarifying!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
From: Laurent Pinchart @ 2018-05-30 12:36 UTC (permalink / raw)
To: Maciej Purski
Cc: linux-kernel, linux-arm-kernel, linux-samsung-soc, devicetree,
dri-devel, David Airlie, Rob Herring, Mark Rutland,
Thierry Reding, Kukjin Kim, Krzysztof Kozlowski, Archit Taneja,
Andrzej Hajda, Inki Dae, Joonyoung Shim, Seung-Woo Kim,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1527682561-1386-8-git-send-email-m.purski@samsung.com>
Hi Maciej,
On Wednesday, 30 May 2018 15:15:58 EEST Maciej Purski wrote:
> From: Andrzej Hajda <a.hajda@samsung.com>
>
> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> Bindings describe power supplies, reset gpio and video interfaces.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> .../bindings/display/bridge/toshiba,tc358764.txt | 37 +++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt new
> file mode 100644
> index 0000000..6eda14f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> @@ -0,0 +1,37 @@
> +TC358764 MIPI-DSI to LVDS panel bridge
> +
> +Required properties:
> + - compatible: "toshiba,tc358764"
> + - reg: the virtual channel number of a DSI peripheral
> + - vddc-supply: core voltage supply, 1.2V
> + - vddio-supply: I/O voltage supply, 1.8V or 3.3V
> + - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
> + - reset-gpios: a GPIO spec for the reset pin
> +
> +The device node can contain zero to two 'port' child nodes, each with one
> +child 'endpoint' node, according to the bindings defined in [1].
> +The following are properties specific to those nodes.
> +
> +port:
> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Could you please take the comments I made on v1 into account when you'll post
v3 ?
> +Example:
> +
> + bridge@0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <&vcc_1v2_reg>;
> + vddio-supply = <&vcc_1v8_reg>;
> + vddlvds-supply = <&vcc_3v3_reg>;
> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@1 {
> + reg = <1>;
> + lvds_ep: endpoint {
> + remote-endpoint = <&panel_ep>;
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
From: Laurent Pinchart @ 2018-05-30 12:35 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Maciej Purski, linux-kernel, linux-arm-kernel, linux-samsung-soc,
devicetree, dri-devel, David Airlie, Rob Herring, Mark Rutland,
Thierry Reding, Kukjin Kim, Krzysztof Kozlowski, Archit Taneja,
Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyungmin Park,
Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20180530095915eucas1p27f09c8424d0c3c0619d134c5e7319fa3~zY7uP6Y6R1391213912eucas1p23@eucas1p2.samsung.com>
Hi Andrzej,
On Wednesday, 30 May 2018 12:59:12 EEST Andrzej Hajda wrote:
> On 28.05.2018 12:18, Laurent Pinchart wrote:
> > On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote:
> >> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> >> Bindings describe power supplies, reset gpio and video interfaces.
> >>
> >> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> >> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> >> ---
> >>
> >> .../bindings/display/bridge/toshiba,tc358764.txt | 42 ++++++++++++++++
> >> 1 file changed, 42 insertions(+)
> >> create mode 100644
> >>
> >> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >> new
> >> file mode 100644
> >> index 0000000..d09bdc2
> >> --- /dev/null
> >> +++
> >> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> >> @@ -0,0 +1,42 @@
> >> +TC358764 MIPI-DSI to LVDS panel bridge
> >> +
> >> +Required properties:
> >> + - compatible: "toshiba,tc358764"
> >> + - reg: the virtual channel number of a DSI peripheral
> >> + - vddc-supply: core voltage supply
> >> + - vddio-supply: I/O voltage supply
> >> + - vddmipi-supply: MIPI voltage supply
> >> + - vddlvds133-supply: LVDS1 3.3V voltage supply
> >> + - vddlvds112-supply: LVDS1 1.2V voltage supply
> >
> > That's a lot of power supplies. Could some of them be merged together ?
> > See https://patchwork.freedesktop.org/patch/216058/ for an earlier
> > discussion on the same subject.
>
> Specs says about 3 supply voltage values:
> - 1.2V - digital core, DSI-RX PHY
> - 1.8-3.3V - digital I/O
> - 3.3V - LVDS-TX PHY
>
> So I guess it should be minimal number of supplies. Natural candidates:
>
> - vddc-supply: core voltage supply, 1.2V
> - vddio-supply: I/O voltage supply, 1.8V or 3.3V
> - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
>
> I have changed name of the latest supply to be more consistent with
> other supplies, and changed 1.8-3.3 (which incorrectly suggest voltage
> range), to more precise voltage alternative.
This looks fine to me.
> >> + - reset-gpios: a GPIO spec for the reset pin
> >> +
> >> +The device node can contain zero to two 'port' child nodes, each with
> >> one
> >> +child
> >> +'endpoint' node, according to the bindings defined in [1].
> >> +The following are properties specific to those nodes.
> >> +
> >> +port:
> >> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
> >
> > This seems pretty vague to me. It could be read as meaning that ports are
> > completely optional, and that the port number you list can be used, but
> > that something else could be used to.
> >
> > Let's make the port nodes mandatory. I propose the following.
> >
> > Required nodes:
> >
> > The TC358764 has DSI and LVDS ports whose connections are described using
> > the OF graph bindings defined in
> > Documentation/devicetree/bindings/graph.txt. The device node must contain
> > one 'port' child node per DSI and LVDS port. The port nodes are numbered
> > as follows.
> >
> > Port Number
> > -------------------------------------------------------------------
> > DSI Input 0
> > LVDS Output 1
> >
> > Each port node must contain endpoint nodes describing the hardware
> > connections.
>
> Since the bridge is controlled via DSI bus, DSI input port is not necessary.
I don't agree with this. Regardless of how the bridge is controlled, I think
we should always use ports to describe the data connections. Otherwise it
would get more complicated for display controller drivers to use different
types of bridges.
> >> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >> +
> >> +Example:
> >> +
> >> + bridge@0 {
> >> + reg = <0>;
> >> + compatible = "toshiba,tc358764";
> >> + vddc-supply = <&vcc_1v2_reg>;
> >> + vddio-supply = <&vcc_1v8_reg>;
> >> + vddmipi-supply = <&vcc_1v2_reg>;
> >> + vddlvds133-supply = <&vcc_3v3_reg>;
> >> + vddlvds112-supply = <&vcc_1v2_reg>;
> >> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + port@1 {
> >> + reg = <1>;
> >> + lvds_ep: endpoint {
> >> + remote-endpoint = <&panel_ep>;
> >> + };
> >> + };
> >> + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Krzysztof Kozlowski @ 2018-05-30 12:32 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Kukjin Kim, Vincent Guittot,
ionela.voinescu, Daniel Lezcano, chris.redpath, devicetree,
linux-arm-kernel, linux-samsung-soc@vger.kernel.org, linux-kernel
In-Reply-To: <20180530043806.ksen4xyh3x3x4fqn@vireshk-i7>
On Wed, May 30, 2018 at 6:38 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
>> Thanks for the patch.
>>
>> In case of Exynos, the booting CPU always has these information in DT
>> and the booting CPU cannot be changed (chosen by firmware/hardware
>> configuration).
>
> But can the booting CPU be offlined ?
>
> If yes, then this is how things are broken right now.
>
> Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
> cpufreq driver and that will try to find these properties in CPU1.
OK, I see the possibility although it is still far away from use
cases. You cannot hotplug booting CPU (CPU0) on Exynos kernels. It
never worked. Strictly speaking - offlining will work. But bringing it
online will likely hang the system.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 10/10] ARM: dts: exynos5250-arndale: add DSI and panel nodes
From: Maciej Purski @ 2018-05-30 12:16 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linux-samsung-soc, devicetree,
dri-devel
Cc: David Airlie, Rob Herring, Mark Rutland, Thierry Reding,
Kukjin Kim, Krzysztof Kozlowski, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Inki Dae, Joonyoung Shim, Seung-Woo Kim,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz,
Maciej Purski
In-Reply-To: <1527682561-1386-1-git-send-email-m.purski@samsung.com>
From: Andrzej Hajda <a.hajda@samsung.com>
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board and
regulators required by the bridge.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 61 ++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7a8a5c5..816d89d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -71,6 +71,17 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <&vcc_3v3_reg>;
+ enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <&bridge_out_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -97,6 +108,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vcc_1v8_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vcc_3v3_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
fixed-rate-clocks {
@@ -119,6 +154,32 @@
cpu0-supply = <&buck2_reg>;
};
+&dsi_0 {
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+ samsung,pll-clock-frequency = <24000000>;
+ samsung,burst-clock-frequency = <320000000>;
+ samsung,esc-clock-frequency = <10000000>;
+ status = "okay";
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddlvds-supply = <&vcc_3v3_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
+};
+
&dp {
status = "okay";
samsung,color-space = <0>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 09/10] ARM: dts: exynos5250: add DSI node
From: Maciej Purski @ 2018-05-30 12:16 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linux-samsung-soc, devicetree,
dri-devel
Cc: Mark Rutland, Maciej Purski, Archit Taneja, Joonyoung Shim,
Bartlomiej Zolnierkiewicz, David Airlie, Seung-Woo Kim,
Krzysztof Kozlowski, Inki Dae, Andrzej Hajda, Kyungmin Park,
Rob Herring, Thierry Reding, Kukjin Kim, Marek Szyprowski,
Laurent Pinchart
In-Reply-To: <1527682561-1386-1-git-send-email-m.purski@samsung.com>
From: Andrzej Hajda <a.hajda@samsung.com>
The patch adds common part of DSI node for Exynos5250 platforms
and a required mipi-phy node.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505..9965eca 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -733,6 +733,27 @@
#phy-cells = <0>;
};
+ mipi_phy: video-phy@10040710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040710 0x100>;
+ #phy-cells = <1>;
+ syscon = <&pmu_system_controller>;
+ };
+
+ dsi_0: dsi@14500000 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x14500000 0x10000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ samsung,power-domain = <&pd_disp1>;
+ phys = <&mipi_phy 3>;
+ phy-names = "dsim";
+ clocks = <&clock CLK_DSIM0>, <&clock CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "sclk_mipi";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
adc: adc@12d10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 08/10] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Maciej Purski @ 2018-05-30 12:15 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linux-samsung-soc, devicetree,
dri-devel
Cc: David Airlie, Rob Herring, Mark Rutland, Thierry Reding,
Kukjin Kim, Krzysztof Kozlowski, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Inki Dae, Joonyoung Shim, Seung-Woo Kim,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz,
Maciej Purski
In-Reply-To: <1527682561-1386-1-git-send-email-m.purski@samsung.com>
From: Andrzej Hajda <a.hajda@samsung.com>
Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/gpu/drm/bridge/Kconfig | 9 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/tc358764.c | 547 ++++++++++++++++++++++++++++++++++++++
3 files changed, 557 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/tc358764.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index fa2c799..9bd3eb8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -110,6 +110,15 @@ config DRM_THINE_THC63LVD1024
---help---
Thine THC63LVD1024 LVDS/parallel converter driver.
+config DRM_TOSHIBA_TC358764
+ tristate "TC358764 DSI/LVDS bridge"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+ help
+ Toshiba TC358764 DSI/LVDS bridge driver
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 35f88d4..bf7c0ce 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c
new file mode 100644
index 0000000..3109eba
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -0,0 +1,547 @@
+/*
+ * Copyright (C) 2018 Samsung Electronics Co., Ltd
+ *
+ * Authors:
+ * Andrzej Hajda <a.hajda@samsung.com>
+ * Maciej Purski <m.purski@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ *
+ */
+
+#include <drm/drm_atomic_helper.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_panel.h>
+
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+#include <linux/gpio/consumer.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+
+#include <video/mipi_display.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
+
+#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << (end))
+#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
+
+/* PPI layer registers */
+#define PPI_STARTPPI 0x0104 /* START control bit */
+#define PPI_LPTXTIMECNT 0x0114 /* LPTX timing signal */
+#define PPI_LANEENABLE 0x0134 /* Enables each lane */
+#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */
+#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */
+#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */
+#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */
+#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */
+#define PPI_START_FUNCTION 1
+
+/* DSI layer registers */
+#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */
+#define DSI_LANEENABLE 0x0210 /* Enables each lane */
+#define DSI_RX_START 1
+
+/* Video path registers */
+#define VP_CTRL 0x0450 /* Video Path Control */
+#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */
+#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */
+#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */
+#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */
+#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */
+#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */
+#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */
+#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */
+#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */
+#define VP_HTIM1_HBP(v) FLD_VAL(v, 24, 16)
+#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0)
+#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */
+#define VP_HTIM2_HFP(v) FLD_VAL(v, 24, 16)
+#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0)
+#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */
+#define VP_VTIM1_VBP(v) FLD_VAL(v, 23, 16)
+#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0)
+#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */
+#define VP_VTIM2_VFP(v) FLD_VAL(v, 23, 16)
+#define VP_VTIM2_VACT(v) FLD_VAL(v, 10, 0)
+#define VP_VFUEN 0x0464 /* Video Frame Timing Update Enable */
+
+/* LVDS registers */
+#define LV_MX0003 0x0480 /* Mux input bit 0 to 3 */
+#define LV_MX0407 0x0484 /* Mux input bit 4 to 7 */
+#define LV_MX0811 0x0488 /* Mux input bit 8 to 11 */
+#define LV_MX1215 0x048C /* Mux input bit 12 to 15 */
+#define LV_MX1619 0x0490 /* Mux input bit 16 to 19 */
+#define LV_MX2023 0x0494 /* Mux input bit 20 to 23 */
+#define LV_MX2427 0x0498 /* Mux input bit 24 to 27 */
+#define LV_MX(b0, b1, b2, b3) (FLD_VAL(b0, 4, 0) | FLD_VAL(b1, 12, 8) | \
+ FLD_VAL(b2, 20, 16) | FLD_VAL(b3, 28, 24))
+
+/* Input bit numbers used in mux registers */
+enum {
+ LVI_R0,
+ LVI_R1,
+ LVI_R2,
+ LVI_R3,
+ LVI_R4,
+ LVI_R5,
+ LVI_R6,
+ LVI_R7,
+ LVI_G0,
+ LVI_G1,
+ LVI_G2,
+ LVI_G3,
+ LVI_G4,
+ LVI_G5,
+ LVI_G6,
+ LVI_G7,
+ LVI_B0,
+ LVI_B1,
+ LVI_B2,
+ LVI_B3,
+ LVI_B4,
+ LVI_B5,
+ LVI_B6,
+ LVI_B7,
+ LVI_HS,
+ LVI_VS,
+ LVI_DE,
+ LVI_L0
+};
+
+#define LV_CFG 0x049C /* LVDS Configuration */
+#define LV_PHY0 0x04A0 /* LVDS PHY 0 */
+#define LV_PHY0_RST(v) FLD_VAL(v, 22, 22) /* PHY reset */
+#define LV_PHY0_IS(v) FLD_VAL(v, 15, 14)
+#define LV_PHY0_ND(v) FLD_VAL(v, 4, 0) /* Frequency range select */
+#define LV_PHY0_PRBS_ON(v) FLD_VAL(v, 20, 16) /* Clock/Data Flag pins */
+
+/* System registers */
+#define SYS_RST 0x0504 /* System Reset */
+#define SYS_ID 0x0580 /* System ID */
+
+#define SYS_RST_I2CS BIT(0) /* Reset I2C-Slave controller */
+#define SYS_RST_I2CM BIT(1) /* Reset I2C-Master controller */
+#define SYS_RST_LCD BIT(2) /* Reset LCD controller */
+#define SYS_RST_BM BIT(3) /* Reset Bus Management controller */
+#define SYS_RST_DSIRX BIT(4) /* Reset DSI-RX and App controller */
+#define SYS_RST_REG BIT(5) /* Reset Register module */
+
+#define LPX_PERIOD 2
+#define TTA_SURE 3
+#define TTA_GET 0x20000
+
+/* Lane enable PPI and DSI register bits */
+#define LANEENABLE_CLEN BIT(0)
+#define LANEENABLE_L0EN BIT(1)
+#define LANEENABLE_L1EN BIT(2)
+#define LANEENABLE_L2EN BIT(3)
+#define LANEENABLE_L3EN BIT(4)
+
+/* LVCFG fields */
+#define LV_CFG_LVEN BIT(0)
+#define LV_CFG_LVDLINK BIT(1)
+#define LV_CFG_CLKPOL1 BIT(2)
+#define LV_CFG_CLKPOL2 BIT(3)
+
+static const char * const tc358764_supplies[] = {
+ "vddc", "vddio", "vddmipi", "vddlvds133", "vddlvds112"
+};
+
+struct tc358764 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
+ struct gpio_desc *gpio_reset;
+
+ struct drm_panel *panel;
+};
+
+static int tc358764_read(struct tc358764 *ctx, u16 addr, u32 *val)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+ struct mipi_dsi_msg msg = {
+ .type = MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM,
+ .channel = dsi->channel,
+ .flags = MIPI_DSI_MSG_USE_LPM,
+ .tx_buf = &addr,
+ .tx_len = 2,
+ .rx_buf = val,
+ .rx_len = 4
+ };
+ ssize_t ret;
+
+ if (!ops || !ops->transfer)
+ return -EINVAL;
+
+ cpu_to_le16s(&addr);
+
+ ret = ops->transfer(dsi->host, &msg);
+ if (ret >= 0)
+ le32_to_cpus(val);
+
+ dev_dbg(ctx->dev, "read: %d, addr: %d\n", addr, *val);
+
+ return ret;
+}
+
+static int tc358764_write(struct tc358764 *ctx, u16 addr, u32 val)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+ u8 data[6];
+ int ret;
+ struct mipi_dsi_msg msg = {
+ .type = MIPI_DSI_GENERIC_LONG_WRITE,
+ .channel = dsi->channel,
+ .flags = MIPI_DSI_MSG_USE_LPM | MIPI_DSI_MSG_REQ_ACK,
+ .tx_buf = data,
+ .tx_len = 6
+ };
+
+ if (!ops || !ops->transfer)
+ return -EINVAL;
+
+ data[0] = addr;
+ data[1] = addr >> 8;
+ data[2] = val;
+ data[3] = val >> 8;
+ data[4] = val >> 16;
+ data[5] = val >> 24;
+
+ ret = ops->transfer(dsi->host, &msg);
+
+ return ret;
+}
+
+static inline struct tc358764 *bridge_to_tc358764(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct tc358764, bridge);
+}
+
+static inline
+struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
+{
+ return container_of(connector, struct tc358764, connector);
+}
+
+static int tc358764_init(struct tc358764 *ctx)
+{
+ u32 v = 0;
+
+ tc358764_read(ctx, SYS_ID, &v);
+ dev_info(ctx->dev, "ID: %#x\n", v);
+
+ /* configure PPI counters */
+ tc358764_write(ctx, PPI_TX_RX_TA, TTA_GET | TTA_SURE);
+ tc358764_write(ctx, PPI_LPTXTIMECNT, LPX_PERIOD);
+ tc358764_write(ctx, PPI_D0S_CLRSIPOCOUNT, 5);
+ tc358764_write(ctx, PPI_D1S_CLRSIPOCOUNT, 5);
+ tc358764_write(ctx, PPI_D2S_CLRSIPOCOUNT, 5);
+ tc358764_write(ctx, PPI_D3S_CLRSIPOCOUNT, 5);
+
+ /* enable four data lanes and clock lane */
+ tc358764_write(ctx, PPI_LANEENABLE, LANEENABLE_L3EN | LANEENABLE_L2EN |
+ LANEENABLE_L1EN | LANEENABLE_L0EN | LANEENABLE_CLEN);
+ tc358764_write(ctx, DSI_LANEENABLE, LANEENABLE_L3EN | LANEENABLE_L2EN |
+ LANEENABLE_L1EN | LANEENABLE_L0EN | LANEENABLE_CLEN);
+
+ /* start */
+ tc358764_write(ctx, PPI_STARTPPI, PPI_START_FUNCTION);
+ tc358764_write(ctx, DSI_STARTDSI, DSI_RX_START);
+
+ /* configure video path */
+ tc358764_write(ctx, VP_CTRL, VP_CTRL_VSDELAY(15) | VP_CTRL_RGB888(1) |
+ VP_CTRL_EVTMODE(1) | VP_CTRL_HSPOL | VP_CTRL_VSPOL);
+
+ /* reset PHY */
+ tc358764_write(ctx, LV_PHY0, LV_PHY0_RST(1) |
+ LV_PHY0_PRBS_ON(4) | LV_PHY0_IS(2) | LV_PHY0_ND(6));
+ tc358764_write(ctx, LV_PHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_IS(2) |
+ LV_PHY0_ND(6));
+
+ /* reset bridge */
+ tc358764_write(ctx, SYS_RST, SYS_RST_LCD);
+
+ /* set bit order */
+ tc358764_write(ctx, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2, LVI_R3));
+ tc358764_write(ctx, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5, LVI_G0));
+ tc358764_write(ctx, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_G6, LVI_G7));
+ tc358764_write(ctx, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5, LVI_B0));
+ tc358764_write(ctx, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1, LVI_B2));
+ tc358764_write(ctx, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5, LVI_L0));
+ tc358764_write(ctx, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE, LVI_R6));
+ tc358764_write(ctx, LV_CFG, LV_CFG_CLKPOL2 | LV_CFG_CLKPOL1 |
+ LV_CFG_LVEN);
+
+ return 0;
+}
+
+static void tc358764_reset(struct tc358764 *ctx)
+{
+ msleep(20);
+ gpiod_set_value(ctx->gpio_reset, 0);
+ msleep(20);
+ gpiod_set_value(ctx->gpio_reset, 1);
+ msleep(40);
+}
+
+static void tc358764_poweroff(struct tc358764 *ctx)
+{
+ int ret;
+
+ tc358764_reset(ctx);
+
+ drm_panel_disable(ctx->panel);
+ msleep(40);
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
+}
+
+static int tc358764_get_modes(struct drm_connector *connector)
+{
+ struct tc358764 *ctx = connector_to_tc358764(connector);
+
+ if (ctx->panel && ctx->panel->funcs && ctx->panel->funcs->get_modes)
+ return ctx->panel->funcs->get_modes(ctx->panel);
+
+ return 0;
+}
+
+static const
+struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
+ .get_modes = tc358764_get_modes,
+};
+
+static const struct drm_connector_funcs tc358764_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .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 void tc358764_disable(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+
+ tc358764_poweroff(ctx);
+}
+
+static void tc358764_pre_enable(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+ int ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ dev_err(ctx->dev, "error enabling regulators (%d)\n", ret);
+
+ tc358764_reset(ctx);
+ tc358764_init(ctx);
+}
+
+static void tc358764_enable(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+ int ret;
+
+ drm_panel_prepare(ctx->panel);
+
+ ret = drm_panel_enable(ctx->panel);
+ if (ret < 0)
+ pr_err("panel enable failed\n");
+
+ msleep(40);
+}
+
+static int tc358764_attach(struct drm_bridge *bridge)
+{
+ struct tc358764 *ctx = bridge_to_tc358764(bridge);
+ struct drm_device *drm = bridge->dev;
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Encoder not found\n");
+ return -ENODEV;
+ }
+
+ ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
+ ret = drm_connector_init(drm, &ctx->connector,
+ &tc358764_connector_funcs,
+ DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector\n");
+ return ret;
+ }
+
+ drm_connector_helper_add(&ctx->connector,
+ &tc358764_connector_helper_funcs);
+
+ drm_mode_connector_attach_encoder(&ctx->connector, bridge->encoder);
+
+ if (ctx->panel)
+ drm_panel_attach(ctx->panel, &ctx->connector);
+
+ drm_atomic_helper_connector_reset(&ctx->connector);
+ drm_connector_register(&ctx->connector);
+
+ return 0;
+}
+
+static const struct drm_bridge_funcs tc358764_bridge_funcs = {
+ .disable = tc358764_disable,
+ .enable = tc358764_enable,
+ .pre_enable = tc358764_pre_enable,
+ .attach = tc358764_attach,
+};
+
+static struct device_node *tc358764_of_find_panel_node(struct device *dev)
+{
+ struct device_node *np, *ep;
+
+ ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, 0);
+ if (!ep) {
+ pr_err("faile to get endpoint\n");
+ return NULL;
+ }
+
+ np = of_graph_get_remote_port_parent(ep);
+
+ return np;
+}
+
+static int tc358764_parse_dt(struct tc358764 *ctx)
+{
+ struct device *dev = ctx->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *lvds;
+
+ ctx->gpio_reset = devm_gpiod_get_from_of_node(dev, np, "reset", 0,
+ GPIOD_OUT_LOW,
+ "tc358764-reset");
+ if (IS_ERR(ctx->gpio_reset)) {
+ dev_err(dev, "no reset GPIO pin provided\n");
+ return PTR_ERR(ctx->gpio_reset);
+ }
+
+ lvds = tc358764_of_find_panel_node(ctx->dev);
+ if (!lvds) {
+ dev_err(dev, "cannot find panel node\n");
+ return -EINVAL;
+ }
+
+ ctx->panel = of_drm_find_panel(lvds);
+ if (!ctx->panel) {
+ dev_err(dev, "panel not registered\n");
+ return -EPROBE_DEFER;
+ }
+
+ return 0;
+}
+
+static int tc358764_configure_regulators(struct tc358764 *ctx)
+{
+ int i, ret;
+
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); ++i)
+ ctx->supplies[i].supply = tc358764_supplies[i];
+
+ ret = devm_regulator_bulk_get(ctx->dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ dev_err(ctx->dev, "failed to get regulators: %d\n", ret);
+
+ return ret;
+}
+
+static int tc358764_probe(struct mipi_dsi_device *dsi)
+{
+ struct device *dev = &dsi->dev;
+ struct tc358764 *ctx;
+ int ret;
+
+ ctx = devm_kzalloc(dev, sizeof(struct tc358764), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ ctx->dev = dev;
+
+ dsi->lanes = 4;
+ dsi->format = MIPI_DSI_FMT_RGB888;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST
+ | MIPI_DSI_MODE_VIDEO_AUTO_VERT;
+
+ ret = tc358764_parse_dt(ctx);
+ if (ret < 0)
+ return ret;
+
+ ret = tc358764_configure_regulators(ctx);
+ if (ret < 0)
+ return ret;
+
+ ctx->bridge.funcs = &tc358764_bridge_funcs;
+ ctx->bridge.of_node = dev->of_node;
+
+ drm_bridge_add(&ctx->bridge);
+
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_bridge_remove(&ctx->bridge);
+ dev_err(dev, "failed to attach dsi\n");
+ }
+
+ return ret;
+}
+
+static int tc358764_remove(struct mipi_dsi_device *dsi)
+{
+ struct tc358764 *ctx = mipi_dsi_get_drvdata(dsi);
+
+ tc358764_poweroff(ctx);
+
+ mipi_dsi_detach(dsi);
+ drm_bridge_remove(&ctx->bridge);
+
+ return 0;
+}
+
+static const struct of_device_id tc358764_of_match[] = {
+ { .compatible = "toshiba,tc358764" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, tc358764_of_match);
+
+static struct mipi_dsi_driver tc358764_driver = {
+ .probe = tc358764_probe,
+ .remove = tc358764_remove,
+ .driver = {
+ .name = "tc358764",
+ .owner = THIS_MODULE,
+ .of_match_table = tc358764_of_match,
+ },
+};
+module_mipi_dsi_driver(tc358764_driver);
+
+MODULE_AUTHOR("Andrzej Hajda <a.hajda@samsung.com>");
+MODULE_AUTHOR("Maciej Purski <m.purski@samsung.com>");
+MODULE_DESCRIPTION("MIPI-DSI based Driver for TC358764 DSI/LVDS Bridge");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox