* [PATCH 2/2] ARM: davinci_all_defconfig: Enable Bluetooth
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, devicetree,
linux-kernel
In-Reply-To: <20180531202549.11255-1-david@lechnology.com>
This enables Bluetooth modules in davinic_all_defconfig needed for LEGO
MINDSTORMS EV3.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a1b6e106b867..f8448c4703c1 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -54,6 +54,13 @@ CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_NETFILTER=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=m
+CONFIG_BT_BNEP=m
+CONFIG_BT_HIDP=m
+CONFIG_BT_LEDS=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_LL=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_FW_LOADER=m
@@ -113,6 +120,7 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=3
CONFIG_SERIAL_8250_RUNTIME_UARTS=3
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_DEV_BUS=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
@@ -212,6 +220,7 @@ CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
+CONFIG_COMMON_CLK_PWM=m
CONFIG_REMOTEPROC=m
CONFIG_DA8XX_REMOTEPROC=m
CONFIG_MEMORY=y
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: da850-lego-ev3: Add Bluetooth nodes
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, devicetree,
linux-kernel
In-Reply-To: <20180531202549.11255-1-david@lechnology.com>
This adds nodes for describing the Bluetooth chip and connections on
LEGO MINDSTORMS EV3 to da850-lego-ev3.dts.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850-lego-ev3.dts | 82 ++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index bef42dc78817..fe4cc87394b9 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -187,6 +187,15 @@
rechargeable-gpios = <&gpio 136 GPIO_ACTIVE_LOW>;
};
+ bt_slow_clk: bt-clock {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap2_pins>, <&bt_clock_bias>;
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&ecap2 0 30518 0>;
+ };
+
/* ARM local RAM */
memory@ffff0000 {
compatible = "syscon", "simple-mfd";
@@ -251,6 +260,20 @@
bias-disable;
};
};
+
+ bt_clock_bias: bt-clock-bias-groups {
+ disable {
+ groups = "cp2";
+ bias-disable;
+ };
+ };
+
+ bt_pic_bias: bt-pic-bias-groups {
+ disable {
+ groups = "cp20";
+ bias-disable;
+ };
+ };
};
/* Input port 1 */
@@ -260,6 +283,22 @@
pinctrl-0 = <&serial1_rxtx_pins>;
};
+&serial2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial2_rxtx_pins>, <&serial2_rtscts_pins>, <&bt_pic_bias>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "ti,cc2560";
+ clocks = <&bt_slow_clk>;
+ clock-names = "ext_clock";
+ enable-gpios = <&gpio 73 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ nvmem-cells = <&bdaddr>;
+ nvmem-cell-names = "bd-address";
+ };
+};
+
&rtc0 {
status = "okay";
};
@@ -278,6 +317,12 @@
pagesize = <64>;
read-only;
reg = <0x50>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bdaddr: bdaddr@3f06 {
+ reg = <0x3f06 0x06>;
+ };
};
};
@@ -362,6 +407,10 @@
};
};
+&ecap2 {
+ status = "okay";
+};
+
&ehrpwm0 {
status = "okay";
};
@@ -375,6 +424,39 @@
gpios = <6 GPIO_ACTIVE_HIGH>;
output-high;
};
+
+ /* Don't impede Bluetooth clock signal */
+ bt_clock_en {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ };
+
+ /*
+ * There is a PIC microcontroller for interfacing with an Apple MFi
+ * chip. This interferes with normal Bluetooth operation, so we need
+ * to make sure it is turned off. Note: The publicly available
+ * schematics from LEGO don't show that these pins are connected to
+ * anything, but they are present in the source code from LEGO.
+ */
+
+ bt_pic_en {
+ gpio-hog;
+ gpios = <51 GPIO_ACTIVE_HIGH>;
+ output-low;
+ };
+
+ bt_pic_rst {
+ gpio-hog;
+ gpios = <78 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+
+ bt_pic_cts {
+ gpio-hog;
+ gpios = <87 GPIO_ACTIVE_HIGH>;
+ input;
+ };
};
&usb_phy {
--
2.17.0
^ permalink raw reply related
* [PATCH 0/2] ARM: LEGO MINDSTORMS EV3 Bluetooth support
From: David Lechner @ 2018-05-31 20:25 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, devicetree,
linux-kernel
This series adds Bluetooth support to LEGO MINDSTORMS EV3.
The pwm-clock depends on the common clock framework, so this requires the
recent davinci common clock series to switch to the common clock framework
before it will actually work.
David Lechner (2):
ARM: dts: da850-lego-ev3: Add Bluetooth nodes
ARM: davinci_all_defconfig: Enable Bluetooth
arch/arm/boot/dts/da850-lego-ev3.dts | 82 ++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 9 +++
2 files changed, 91 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-31 20:22 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
Define the generic R8A77980 parts of the I2C[0-5] device nodes.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- removed the DMA props for I2C3/4;
- fixed a typo in the patch description;
- added Geert's tag.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 105 ++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -16,6 +16,15 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -135,6 +144,102 @@
#power-domain-cells = <1>;
};
+ i2c0: i2c@e6500000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6500000 0 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 931>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@e6508000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 930>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 930>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@e6510000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6510000 0 0x40>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 929>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 929>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@e66d0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d0000 0 0x40>;
+ interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 928>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 928>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@e66d8000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 927>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 927>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@e66e0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66e0000 0 0x40>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 919>;
+ dmas = <&dmac1 0x9b>, <&dmac1 0x9a>,
+ <&dmac2 0x9b>, <&dmac2 0x9a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
hscif0: serial@e6540000 {
compatible = "renesas,hscif-r8a77980",
"renesas,rcar-gen3-hscif",
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980/Condor I2C support
From: Sergei Shtylyov @ 2018-05-31 20:18 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel@lists.infradead.org
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180529-v4.17-rc7' tag. We're adding the R8A77980 I2C nodes
and then describing 2 PCA9654 I/O expanders connected to the I2C0 bus on
the Condor board.
[1/2] arm64: dts: renesas: r8a77980: add I2C support
[2/2] arm64: dts: renesas: condor: add I2C0 support
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 10/11] dt-bindings: misc: add bindings for throttler
From: Rob Herring @ 2018-05-31 20:04 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Arnd Bergmann,
Greg Kroah-Hartman, Mark Rutland, linux-pm, devicetree,
linux-kernel@vger.kernel.org, Brian Norris, Douglas Anderson
In-Reply-To: <20180531183404.GB88063@google.com>
On Thu, May 31, 2018 at 1:34 PM, Matthias Kaehlcke <mka@chromium.org> wrote:
> Hi Rob,
>
> On Thu, May 31, 2018 at 11:31:59AM -0500, Rob Herring wrote:
>> On Fri, May 25, 2018 at 01:30:42PM -0700, Matthias Kaehlcke wrote:
>>
>> Commit msg?
>
> Will add some more info in the next revision.
>
>> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>> > ---
>> > .../devicetree/bindings/misc/throttler.txt | 41 +++++++++++++++++++
>> > 1 file changed, 41 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/misc/throttler.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/misc/throttler.txt b/Documentation/devicetree/bindings/misc/throttler.txt
>> > new file mode 100644
>> > index 000000000000..92f13e94451a
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/misc/throttler.txt
>> > @@ -0,0 +1,41 @@
>> > +Throttler driver
>> > +
>> > +The Throttler is used for non-thermal throttling of system components like
>> > +CPUs or devfreq devices.
>>
>> This all looks very Linux specific and not a h/w device. Perhaps you can
>> add hint properties to OPP tables as to what entries can be used for
>> throttling, but otherwise this doesn't belong in DT.
>
> My idea is to allow multiple throttlers, which might operate on
> different throttling devices or use different OPPs for the same
> device. To support this a simple boolean hint that the OPP can be used
> for throttling would not be sufficient.
>
> What should work is a property with an array of phandles of the
> throttlers that use a given OPP.
>
> AFAIK it is currently not possible to enumerate the devfreq devices in
> the system, so besides the info in the OPPs the throttler itself would
> still need a phandle to the devfreq device(s) it uses.
Why don't you fix that OS problem instead of working around it in DT?
>
> I envision something like this:
>
> gpu_opp_table: opp-table2 {
> compatible = "operating-points-v2";
>
> opp00 {
> opp-hz = /bits/ 64 <200000000>;
> opp-microvolt = <800000>;
> };
> opp01 {
> opp-hz = /bits/ 64 <297000000>;
> opp-microvolt = <800000>;
> opp-throttlers = <&cros_ec_throttler>;
> };
> ...
> };
>
> cros_ec_throttler: cros-ec-throttler {
> compatible = "google,cros-ec-throttler";
Is this an actual h/w device?
>
> devfreq-devices = <&gpu>;
> };
>
> Would this be acceptable?
>
> Thanks
>
> Matthias
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: simple-card: make sysclk index configurable
From: Daniel Mack @ 2018-05-31 20:03 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, alsa-devel, Mark Brown, lgirdwood,
kuninori.morimoto.gx
In-Reply-To: <20180531170240.GA29973@rob-hp-laptop>
On Thursday, May 31, 2018 07:02 PM, Rob Herring wrote:
> On Tue, May 29, 2018 at 10:23:48PM +0200, Daniel Mack wrote:
>> If that's the case, could you depict how the DT bindings should look like by
>> example?
>
> In clock providers, you just add #clock-cells. Then the consumer side
> defines 'clocks'. Which clock(s) comes from the dai is defined by the
> index in the 'clocks' property for that node.
>
> Both ends can be providers, but who is active is determined by defining
> the actual connections with 'clocks'. Or perhaps you have both
> directions shown and there is some other means to select which one is
> active such as solving for who can provide the desired freq.
How about entities that are a clock producer and consume their clocks
themselves? That's a rather typical thing for DAIs. Is that expressible
in DT?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 10/11] dt-bindings: misc: add bindings for throttler
From: Matthias Kaehlcke @ 2018-05-31 18:34 UTC (permalink / raw)
To: Rob Herring
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Arnd Bergmann,
Greg Kroah-Hartman, Mark Rutland, linux-pm, devicetree,
linux-kernel, Brian Norris, Douglas Anderson
In-Reply-To: <20180531163159.GA4369@rob-hp-laptop>
Hi Rob,
On Thu, May 31, 2018 at 11:31:59AM -0500, Rob Herring wrote:
> On Fri, May 25, 2018 at 01:30:42PM -0700, Matthias Kaehlcke wrote:
>
> Commit msg?
Will add some more info in the next revision.
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > .../devicetree/bindings/misc/throttler.txt | 41 +++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/throttler.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/throttler.txt b/Documentation/devicetree/bindings/misc/throttler.txt
> > new file mode 100644
> > index 000000000000..92f13e94451a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/throttler.txt
> > @@ -0,0 +1,41 @@
> > +Throttler driver
> > +
> > +The Throttler is used for non-thermal throttling of system components like
> > +CPUs or devfreq devices.
>
> This all looks very Linux specific and not a h/w device. Perhaps you can
> add hint properties to OPP tables as to what entries can be used for
> throttling, but otherwise this doesn't belong in DT.
My idea is to allow multiple throttlers, which might operate on
different throttling devices or use different OPPs for the same
device. To support this a simple boolean hint that the OPP can be used
for throttling would not be sufficient.
What should work is a property with an array of phandles of the
throttlers that use a given OPP.
AFAIK it is currently not possible to enumerate the devfreq devices in
the system, so besides the info in the OPPs the throttler itself would
still need a phandle to the devfreq device(s) it uses.
I envision something like this:
gpu_opp_table: opp-table2 {
compatible = "operating-points-v2";
opp00 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <800000>;
};
opp01 {
opp-hz = /bits/ 64 <297000000>;
opp-microvolt = <800000>;
opp-throttlers = <&cros_ec_throttler>;
};
...
};
cros_ec_throttler: cros-ec-throttler {
compatible = "google,cros-ec-throttler";
devfreq-devices = <&gpu>;
};
Would this be acceptable?
Thanks
Matthias
^ permalink raw reply
* Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Jernej Škrabec @ 2018-05-31 17:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
In-Reply-To: <20180531092133.3gqepoabvuruiztz-YififvaboMKzQB+pC5nmwQ@public.gmane.org>
Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > >> > > + if (tcon->quirks->needs_tcon_top) {
> > >> > > + struct device_node *np;
> > >> > > +
> > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
> > >> > > 0);
> > >> > > + if (np) {
> > >> > > + struct platform_device *pdev;
> > >> > > +
> > >> > > + pdev = of_find_device_by_node(np);
> > >> > > + if (pdev)
> > >> > > + tcon->tcon_top =
> > >> > > platform_get_drvdata(pdev);
> > >> > > + of_node_put(np);
> > >> > > +
> > >> > > + if (!tcon->tcon_top)
> > >> > > + return -EPROBE_DEFER;
> > >> > > + }
> > >> > > + }
> > >> > > +
> > >> >
> > >> > I might have missed it, but I've not seen the bindings additions for
> > >> > that property. This shouldn't really be done that way anyway, instead
> > >> > of using a direct phandle, you should be using the of-graph, with the
> > >> > TCON-top sitting where it belongs in the flow of data.
> > >>
> > >> Just to answer to the first question, it did describe it in "[PATCH
> > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> > >>
> > >> As why I designed it that way - HW representation could be described
> > >> that way> >>
> > >> (ASCII art makes sense when fixed width font is used to view it):
> > >> / LCD0/LVDS0
> > >>
> > >> / TCON-LCD0
> > >>
> > >> | \ MIPI DSI
> > >>
> > >> mixer0 |
> > >>
> > >> \ / TCON-LCD1 - LCD1/LVDS1
> > >>
> > >> TCON-TOP
> > >>
> > >> / \ TCON-TV0 - TVE0/RGB
> > >>
> > >> mixer1 | \
> > >>
> > >> | TCON-TOP - HDMI
> > >> |
> > >> | /
> > >>
> > >> \ TCON-TV1 - TVE1/RGB
> > >>
> > >> This is a bit simplified, since there is also TVE-TOP, which is
> > >> responsible
> > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
> > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
> > >> seems that you can arbitrarly choose which DAC is responsible for
> > >> which signal, so there is a ton of possible end combinations, but I'm
> > >> not 100% sure.
> > >>
> > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> > >> suggest more possibilities, although some of them seem wrong, like RGB
> > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
> > >> code.
> > >>
> > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
> > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
> > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
> > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
> > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
> > >> (when it works in RGB mode) and LCD. But that is just my guess since
> > >> I'm not really familiar with RGB and LCD interfaces.
> > >>
> > >> I'm really not sure what would be the best representation in OF-graph.
> > >> Can you suggest one?
> > >
> > > Rob might disagree on this one, but I don't see anything wrong with
> > > having loops in the graph. If the TCON-TOP can be both the input and
> > > output of the TCONs, then so be it, and have it described that way in
> > > the graph.
> > >
> > > The code is already able to filter out nodes that have already been
> > > added to the list of devices we need to wait for in the component
> > > framework, so that should work as well.
> > >
> > > And we'd need to describe TVE-TOP as well, even though we don't have a
> > > driver for it yet. That will simplify the backward compatibility later
> > > on.
> >
> > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
> > binds everything together, and provides signal routing, kind of like
> > DE-TOP on A64. So the signal mux controls that were originally found
> > in TCON0 and TVE0 were moved out.
> >
> > The driver needs to know about that, but the graph about doesn't make
> > much sense directly. Without looking at the manual, I understand it to
> > likely be one mux between the mixers and TCONs, and one between the
> > TCON-TVs and HDMI. Would it make more sense to just have the graph
> > connections between the muxed components, and remove TCON-TOP from
> > it, like we had in the past? A phandle could be used to reference
> > the TCON-TOP for mux controls, in addition to the clocks and resets.
> >
> > For TVE, we would need something to represent each of the output pins,
> > so the device tree can actually describe what kind of signal, be it
> > each component of RGB/YUV or composite video, is wanted on each pin,
> > if any. This is also needed on the A20 for the Cubietruck, so we can
> > describe which pins are tied to the VGA connector, and which one does
> > R, G, or B.
>
> I guess we'll see how the DT maintainers feel about this, but my
> impression is that the OF graph should model the flow of data between
> the devices. If there's a mux somewhere, then the data is definitely
> going through it, and as such it should be part of the graph.
I concur, but I spent few days thinking how to represent this sanely in graph,
but I didn't find any good solution. I'll represent here my idea and please
tell your opinion before I start implementing it.
First, let me be clear that mixer0 and mixer1 don't have same capabilities
(different number of planes, mixer0 supports writeback, mixer1 does not,
etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
obviously depends on end system.
So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
According to current practice in sun4i-drm driver, graph has to have port 0,
representing input and port 1, representing output. This would mean that graph
looks something like that:
tcon_top: tcon-top@1c70000 {
compatible = "allwinner,sun8i-r40-tcon-top";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_top_in: port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
tcon_top_in_mixer0: endpoint@0 {
reg = <0>;
remote-endpoint = <&mixer0_out_tcon_top>;
};
tcon_top_in_mixer1: endpoint@1 {
reg = <1>;
remote-endpoint = <&mixer1_out_tcon_top>;
};
tcon_top_in_tcon_tv: endpoint@2 {
reg = <2>;
// here is HDMI input connection, part of board DTS
remote-endpoint = <board specific phandle to TV TCON output>;
};
};
tcon_top_out: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
tcon_top_out_tcon0: endpoint@0 {
reg = <0>;
// here is mixer0 output connection, part of board DTS
remote-endpoint = <board specific phandle to TCON>;
};
tcon_top_out_tcon1: endpoint@1 {
reg = <1>;
// here is mixer1 output connection, part of board DTS
remote-endpoint = <board specific phandle to TCON>;
};
tcon_top_out_hdmi: endpoint@2 {
reg = <2>;
remote-endpoint = <&hdmi_in_tcon_top>;
};
};
};
};
tcon_tv0: lcd-controller@1c73000 {
compatible = "allwinner,sun8i-r40-tcon-tv-0";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_tv0_in: port@0 {
reg = <0>;
tcon_tv0_in_tcon_top: endpoint {
// endpoint depends on board, part of board DTS
remote-endpoint = <phandle to one of tcon_top_out_tcon>;
};
};
tcon_tv0_out: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// endpoints to TV TOP and TCON TOP HDMI input
...
};
};
};
tcon_tv1: lcd-controller@1c74000 {
compatible = "allwinner,sun8i-r40-tcon-tv-1";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_tv1_in: port@0 {
reg = <0>;
tcon_tv1_in_tcon_top: endpoint {
// endpoint depends on board, part of board DTS
remote-endpoint = <phandle to one of tcon_top_out_tcon>;
};
};
tcon_tv1_out: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// endpoints to TV TOP and TCON TOP HDMI input
...
};
};
};
tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
outputs would be LCD or LVDS panels or MIPI DSI encoder.
Please note that each TCON (there are 4 of them) would need to have unique
compatible and have HW index stored in quirks data. It would be used by TCON
TOP driver for configuring muxes.
What do you think about above suggestion?
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
From: Stefan Agner @ 2018-05-31 17:54 UTC (permalink / raw)
To: Miquel Raynal, boris.brezillon, robh+dt
Cc: dwmw2, computersforpeace, marek.vasut, mark.rutland,
thierry.reding, mturquette, sboyd, dev, richard, marcel, krzk,
digetx, benjamin.lindqvist, jonathanh, pdeschrijver, pgaikwad,
mirza.krak, linux-mtd, linux-tegra, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20180528000422.7f18dc5f@xps13>
Miquel, Boris,
[also adding Rob to to since it is DT related]
On 28.05.2018 00:04, Miquel Raynal wrote:
> Hi Stefan,
>
> I just see your v2 while I'm sending my review on the driver, will
> probably wait for v4 then ;)
>
> Thanks for the work though!
> Miquèl
>
> On Tue, 22 May 2018 14:07:06 +0200, Stefan Agner <stefan@agner.ch>
> wrote:
>
>> Add support for the NAND flash controller found on NVIDIA
>> Tegra 2 SoCs. This implementation does not make use of the
>> command queue feature. Regular operations/data transfers are
>> done in PIO mode. Page read/writes with hardware ECC make
>> use of the DMA for data transfer.
>>
>> Signed-off-by: Lucas Stach <dev@lynxeye.de>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>
> [...]
>
[...]
>> +
>> +static int tegra_nand_probe(struct platform_device *pdev)
>> +{
>> + struct reset_control *rst;
>> + struct tegra_nand *nand;
>
> Would you mind having another name for the tegra_nand structure than
> just 'nand'? I found it confusing as, following Boris comment, it won't
> be a 'NAND device' structure but rather more a controller structure.
>
>> + struct nand_chip *chip;
>> + struct mtd_info *mtd;
>> + struct resource *res;
>> + unsigned long value;
>
> s/value/reg/ ? or something more explicit?
>
>> + int irq, err = 0;
>> +
>> + nand = devm_kzalloc(&pdev->dev, sizeof(*nand), GFP_KERNEL);
>> + if (!nand)
>> + return -ENOMEM;
>> +
>> + nand->dev = &pdev->dev;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + nand->regs = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(nand->regs))
>> + return PTR_ERR(nand->regs);
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + err = devm_request_irq(&pdev->dev, irq, tegra_nand_irq, 0,
>> + dev_name(&pdev->dev), nand);
>> + if (err)
>> + return err;
>> +
>> + rst = devm_reset_control_get(&pdev->dev, "nand");
>> + if (IS_ERR(rst))
>> + return PTR_ERR(rst);
>> +
>> + nand->clk = devm_clk_get(&pdev->dev, "nand");
>> + if (IS_ERR(nand->clk))
>> + return PTR_ERR(nand->clk);
>> +
>> + nand->wp_gpio = gpiod_get_optional(&pdev->dev, "wp-gpios",
>> + GPIOD_OUT_HIGH);
>> + if (IS_ERR(nand->wp_gpio))
>> + return PTR_ERR(nand->wp_gpio);
>> +
>> + err = clk_prepare_enable(nand->clk);
>> + if (err)
>> + return err;
>> +
>> + reset_control_assert(rst);
>> + udelay(2);
>> + reset_control_deassert(rst);
>> +
>> + value = HWSTATUS_RDSTATUS_MASK(1) | HWSTATUS_RDSTATUS_VALUE(0) |
>> + HWSTATUS_RBSY_MASK(NAND_STATUS_READY) |
>> + HWSTATUS_RBSY_VALUE(NAND_STATUS_READY);
>> + writel(NAND_CMD_STATUS, nand->regs + HWSTATUS_CMD);
>> + writel(value, nand->regs + HWSTATUS_MASK);
>> +
>> + init_completion(&nand->command_complete);
>> + init_completion(&nand->dma_complete);
>> +
>> + /* clear interrupts */
>> + value = readl(nand->regs + ISR);
>> + writel(value, nand->regs + ISR);
>> +
>> + writel(DMA_CTRL_IS_DONE, nand->regs + DMA_CTRL);
>> +
>> + /* enable interrupts */
>> + value = IER_UND | IER_OVR | IER_CMD_DONE | IER_ECC_ERR | IER_GIE;
>> + writel(value, nand->regs + IER);
>> +
>> + /* reset config */
>> + writel(0, nand->regs + CFG);
>> +
>> + chip = &nand->chip;
>> + mtd = nand_to_mtd(chip);
>> +
>> + mtd->dev.parent = &pdev->dev;
>> + mtd->name = "tegra_nand";
>
> I just figured it was undocumented (yet) but you could have a label
> string property in your nand DT node that tells you the name of the
> MTD device instead of something too generic like tegra_nand.
>
Using label in the NAND chip subnode actually causes current U-Boot to
delete (!!) the chip node and create partitions on the controller node.
See:
https://elixir.bootlin.com/u-boot/latest/source/common/fdt_support.c#L757
The code essentially uses the property label to detect whether its a
NAND chip or a partition...
At least this is the case when using fdt_fixup_mtdparts and passing the
controller compatible ("nvidia,tegra20-nand") in node_info, what our
downstream U-Boot is currently doing. Maybe we should pass the
compatible property of the NAND chip? But afaik, chips do not have a
compatible necessarily.
So using label in the chip node is currently a no-go for me.
Will send out v3 soon.
--
Stefan
>> + mtd->owner = THIS_MODULE;
>> +
>> + nand_set_flash_node(chip, pdev->dev.of_node);
>> + nand_set_controller_data(chip, nand);
>> +
>> + chip->options = NAND_NO_SUBPAGE_WRITE;
>> + chip->exec_op = tegra_nand_exec_op;
>> + chip->select_chip = tegra_nand_select_chip;
>> + tegra_nand_setup_timing(nand, 0);
>
> You really should implement ->setup_data_interface() and let the core
> handle the timings issue entirely (mind that chipnr is not the NAND
> chip id but more the CS id asserted for the pointed NAND chip).
>
>> +
>> + err = nand_scan_ident(mtd, 1, NULL);
>> + if (err)
>> + goto err_disable_clk;
>> +
>> + if (chip->bbt_options & NAND_BBT_USE_FLASH)
>> + chip->bbt_options |= NAND_BBT_NO_OOB;
>> +
>> + nand->data_buf = dmam_alloc_coherent(&pdev->dev, mtd->writesize,
>> + &nand->data_dma, GFP_KERNEL);
>
> Do you need these buffers before nand_scan_tail() or could you simply
> use the ones allocated by the core right after?
>
>> + if (!nand->data_buf) {
>> + err = -ENOMEM;
>> + goto err_disable_clk;
>> + }
>> +
>> + nand->oob_buf = dmam_alloc_coherent(&pdev->dev, mtd->oobsize,
>> + &nand->oob_dma, GFP_KERNEL);
>> + if (!nand->oob_buf) {
>> + err = -ENOMEM;
>> + goto err_disable_clk;
>> + }
>> +
>> + chip->ecc.mode = NAND_ECC_HW;
>> + chip->ecc.size = 512;
>> + chip->ecc.read_page = tegra_nand_read_page;
>> + chip->ecc.write_page = tegra_nand_write_page;
>> +
>> + value = readl(nand->regs + CFG);
>> + value |= CFG_PIPE_EN | CFG_SKIP_SPARE | CFG_SKIP_SPARE_SIZE_4 |
>> + CFG_TAG_BYTE_SIZE(mtd_ooblayout_count_freebytes(mtd) - 1);
>> +
>> + if (chip->options & NAND_BUSWIDTH_16)
>> + value |= CFG_BUS_WIDTH_16;
>> +
>> + switch (mtd->oobsize) {
>> + case 16:
>> + mtd_set_ooblayout(mtd, &tegra_nand_oob_16_ops);
>> + chip->ecc.strength = 1;
>> + chip->ecc.bytes = 4;
>> + break;
>> + case 64:
>> + mtd_set_ooblayout(mtd, &tegra_nand_oob_64_ops);
>> + chip->ecc.strength = 8;
>> + chip->ecc.bytes = 18;
>> + value |= CFG_ECC_SEL | CFG_TVAL_8;
>> + break;
>> + case 128:
>> + mtd_set_ooblayout(mtd, &tegra_nand_oob_128_ops);
>> + chip->ecc.strength = 8;
>> + chip->ecc.bytes = 18;
>> + value |= CFG_ECC_SEL | CFG_TVAL_8;
>> + break;
>> + case 224:
>> + mtd_set_ooblayout(mtd, &tegra_nand_oob_224_ops);
>> + chip->ecc.strength = 8;
>> + chip->ecc.bytes = 18;
>> + value |= CFG_ECC_SEL | CFG_TVAL_8;
>> + break;
>> + default:
>> + dev_err(&pdev->dev, "unhandled OOB size %d\n", mtd->oobsize);
>> + err = -ENODEV;
>> + goto err_disable_clk;
>> + }
>> +
>> + switch (mtd->writesize) {
>> + case 256:
>> + value |= CFG_PS_256;
>> + break;
>> + case 512:
>> + value |= CFG_PS_512;
>> + break;
>> + case 1024:
>> + value |= CFG_PS_1024;
>> + break;
>> + case 2048:
>> + value |= CFG_PS_2048;
>> + break;
>> + case 4096:
>> + value |= CFG_PS_4096;
>> + break;
>> + default:
>> + dev_err(&pdev->dev, "unhandled writesize %d\n", mtd->writesize);
>> + err = -ENODEV;
>> + goto err_disable_clk;
>> + }
>> +
>> + writel(value, nand->regs + CFG);
>> +
>> + tegra_nand_setup_chiptiming(nand);
>> +
>> + err = nand_scan_tail(mtd);
>> + if (err)
>> + goto err_disable_clk;
>> +
>> + err = mtd_device_register(mtd, NULL, 0);
>> + if (err)
>> + goto err_cleanup_nand;
>> +
>> + platform_set_drvdata(pdev, nand);
>> +
>> + return 0;
>> +
>> +err_cleanup_nand:
>> + nand_cleanup(chip);
>> +err_disable_clk:
>> + clk_disable_unprepare(nand->clk);
>> + return err;
>> +}
>> +
>> +static int tegra_nand_remove(struct platform_device *pdev)
>> +{
>> + struct tegra_nand *nand = platform_get_drvdata(pdev);
>> +
>> + nand_release(nand_to_mtd(&nand->chip));
>> +
>> + clk_disable_unprepare(nand->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id tegra_nand_of_match[] = {
>> + { .compatible = "nvidia,tegra20-nand" },
>> + { /* sentinel */ }
>> +};
>> +
>> +static struct platform_driver tegra_nand_driver = {
>> + .driver = {
>> + .name = "tegra-nand",
>> + .of_match_table = tegra_nand_of_match,
>> + },
>> + .probe = tegra_nand_probe,
>> + .remove = tegra_nand_remove,
>> +};
>> +module_platform_driver(tegra_nand_driver);
>> +
>> +MODULE_DESCRIPTION("NVIDIA Tegra NAND driver");
>> +MODULE_AUTHOR("Thierry Reding <thierry.reding@nvidia.com>");
>> +MODULE_AUTHOR("Lucas Stach <dev@lynxeye.de>");
>> +MODULE_AUTHOR("Stefan Agner <stefan@agner.ch>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DEVICE_TABLE(of, tegra_nand_of_match);
^ permalink raw reply
* [PATCH v3 3/3] MAINTAINERS: add subfolders for nuvoton *npcm*
From: avifishman70 @ 2018-05-31 17:40 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,
Avi Fishman
In-Reply-To: <1527788430-12494-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
* [PATCH v3 2/3] USB: DT probing support to ehci-npcm7xx
From: avifishman70 @ 2018-05-31 17:40 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,
Avi Fishman
In-Reply-To: <1527788430-12494-1-git-send-email-avifishman70@gmail.com>
From: Avi Fishman <AviFishman70@gmail.com>
Device Tree documentation for Nuvoton npcm7xx EHCI.
Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
Documentation/devicetree/bindings/usb/npcm7xx-usb.txt | 17 +++++++++++++++++
1 file changed, 17 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..b682bec103f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
@@ -0,0 +1,17 @@
+Nuvoton NPCM7XX SoC USB controllers:
+-----------------------------
+
+EHCI:
+-----
+
+Required properties:
+- compatible: "nuvoton,npcm750-ehci"
+- interrupts: Should contain the EHCI interrupt
+
+Example:
+
+ ehci1: usb@f0806000 {
+ compatible = "nuvoton,npcm750-ehci";
+ reg = <0xf0806000 0x1000>;
+ interrupts = <0 61 4>;
+ };
--
2.14.1
^ permalink raw reply related
* [PATCH v3 1/3] USB host: Add USB ehci support for nuvoton npcm7xx platform
From: avifishman70 @ 2018-05-31 17:40 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,
Avi Fishman
In-Reply-To: <1527788430-12494-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..c80a8792d3b0
--- /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,npcm750-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,npcm750-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 v3 0/3] USB host: Add USB ehci support for nuvoton npcm7xx
From: avifishman70 @ 2018-05-31 17:40 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,
Avi Fishman
From: Avi Fishman <AviFishman70@gmail.com>
Changes since version 2:
- Follow Sergei Shtylyov comments to rename the node name in in device tree
documentation
Changes since version 1:
- Follow Rob Herring comments in device tree documentation
- minor log error fix in ehci-npcm7xx.c
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 | 17 ++
MAINTAINERS | 3 +
drivers/usb/host/Kconfig | 8 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-npcm7xx.c | 212 +++++++++++++++++++++
5 files changed, 241 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
* Re: [PATCH 11/11] misc/throttler: Add Chrome OS EC throttler
From: Matthias Kaehlcke @ 2018-05-31 17:33 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Arnd Bergmann,
Greg Kroah-Hartman, Rob Herring, Mark Rutland, Linux PM list,
devicetree@vger.kernel.org, linux-kernel, Brian Norris,
Douglas Anderson
In-Reply-To: <CAFqH_53iMhvq+6NXoXu50sD=PuXBf-2_D3K1Mf+iggLeGSu_mg@mail.gmail.com>
Hi Enric,
thanks for the review!
I'll address your comments in the next revision.
On Thu, May 31, 2018 at 11:05:09AM +0200, Enric Balletbo Serra wrote:
> Hi Matthias,
>
> The patch looks good to me, just three minor comments to be more
> coherent with other cros-ec drivers.
>
> 2018-05-25 22:30 GMT+02:00 Matthias Kaehlcke <mka@chromium.org>:
> > The driver subscribes to throttling events from the Chrome OS
> > embedded controller and enables/disables system throttling based
> > on these events.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > drivers/misc/throttler/Kconfig | 15 +++
> > drivers/misc/throttler/Makefile | 1 +
> > drivers/misc/throttler/cros_ec_throttler.c | 122 +++++++++++++++++++++
> > 3 files changed, 138 insertions(+)
> > create mode 100644 drivers/misc/throttler/cros_ec_throttler.c
> >
> > diff --git a/drivers/misc/throttler/Kconfig b/drivers/misc/throttler/Kconfig
> > index ef8388f6bc0a..652b6817b75c 100644
> > --- a/drivers/misc/throttler/Kconfig
> > +++ b/drivers/misc/throttler/Kconfig
> > @@ -11,3 +11,18 @@ menuconfig THROTTLER
> > Note that you also need a event monitor module usually called
> > *_throttler.
> >
> > +if THROTTLER
> > +
> > +config CROS_EC_THROTTLER
> > + tristate "Throttler event monitor for the Chrome OS Embedded Controller"
>
> s/Chrome OS/ChromeOS/ This is how other cros-ec drivers refer to the
> embedded controller, so will be good if you could maintain this
> denomination.
>
> > + default n
> > + depends on MFD_CROS_EC
> > + ---help---
> > + This driver adds support to throttle the system in reaction to
> > + Chrome OS EC events.
> > +
>
> ditto
>
> > + To compile this driver as a module, choose M here: the
> > + module will be called cros_ec_throttler.
> > +
> > +endif # THROTTLER
> > +
> > diff --git a/drivers/misc/throttler/Makefile b/drivers/misc/throttler/Makefile
> > index c8d920cee315..d9b2a77dabc9 100644
> > --- a/drivers/misc/throttler/Makefile
> > +++ b/drivers/misc/throttler/Makefile
> > @@ -1 +1,2 @@
> > obj-$(CONFIG_THROTTLER) += core.o
> > +obj-$(CONFIG_CROS_EC_THROTTLER) += cros_ec_throttler.o
> > diff --git a/drivers/misc/throttler/cros_ec_throttler.c b/drivers/misc/throttler/cros_ec_throttler.c
> > new file mode 100644
> > index 000000000000..ea6bc002d49c
> > --- /dev/null
> > +++ b/drivers/misc/throttler/cros_ec_throttler.c
> > @@ -0,0 +1,122 @@
> > +/*
> > + * Driver for throttling triggered by EC events.
> > + *
> > + * Copyright (C) 2018 Google, Inc.
> > + *
> > + * This software is licensed under the terms of the GNU General Public
> > + * License version 2, as published by the Free Software Foundation, and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * 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.
> > + *
> > + */
> > +
>
> Replace this for the SPDX header format
>
> // SPDX-License-Identifier: GPL-2.0+
> // Driver for throttling triggered by EC events.
> //
> // Copyright (C) 2018 Google, Inc.
> // Author: Matthias Kaehlcke <mka@chromium.org>
>
> > +#include <linux/kernel.h>
> > +#include <linux/mfd/cros_ec.h>
> > +#include <linux/module.h>
> > +#include <linux/notifier.h>
> > +#include <linux/of.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/throttler.h>
> > +
> > +struct cros_ec_throttler {
> > + struct cros_ec_device *ec;
> > + struct throttler *throttler;
> > + struct notifier_block nb;
> > +};
> > +
> > +static int cros_ec_throttler_event(struct notifier_block *nb,
> > + unsigned long queued_during_suspend, void *_notify)
> > +{
> > + struct cros_ec_throttler *cte =
> > + container_of(nb, struct cros_ec_throttler, nb);
>
> nit: Better add a define here instead of split the line like this ?
>
> > + u32 host_event;
> > +
> > + host_event = cros_ec_get_host_event(cte->ec);
> > + if (host_event & EC_HOST_EVENT_MASK(EC_HOST_EVENT_THROTTLE_START)) {
> > + throttler_set_level(cte->throttler, 1);
> > +
> > + return NOTIFY_OK;
> > + } else if (host_event & EC_HOST_EVENT_MASK(EC_HOST_EVENT_THROTTLE_STOP)) {
> > + throttler_set_level(cte->throttler, 0);
> > +
> > + return NOTIFY_OK;
> > + }
> > +
> > + return NOTIFY_DONE;
> > +}
> > +
> > +static int cros_ec_throttler_probe(struct platform_device *pdev)
> > +{
> > + struct cros_ec_throttler *cte;
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = pdev->dev.of_node;
> > + int ret;
> > +
> > + if (!np) {
> > + /* should never happen */
> > + return -EINVAL;
> > + }
> > +
> > + cte = devm_kzalloc(dev, sizeof(*cte), GFP_KERNEL);
> > + if (!cte)
> > + return -ENOMEM;
> > +
> > + cte->ec = dev_get_drvdata(pdev->dev.parent);
> > +
> > + cte->throttler = throttler_setup(dev);
> > + if (IS_ERR(cte->throttler))
> > + return PTR_ERR(cte->throttler);
> > +
> > + dev_set_drvdata(dev, cte);
> > +
> > + cte->nb.notifier_call = cros_ec_throttler_event;
> > + ret = blocking_notifier_chain_register(&cte->ec->event_notifier,
> > + &cte->nb);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to register notifier\n");
> > + throttler_teardown(cte->throttler);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int cros_ec_throttler_remove(struct platform_device *pdev)
> > +{
> > + struct cros_ec_throttler *cte = platform_get_drvdata(pdev);
> > +
> > + blocking_notifier_chain_unregister(&cte->ec->event_notifier,
> > + &cte->nb);
> > +
> > + throttler_teardown(cte->throttler);
> > +
> > + return 0;
> > +}
> > +
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cros_ec_throttler_of_match[] = {
> > + { .compatible = "google,cros-ec-throttler" },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, cros_ec_throttler_of_match);
> > +#endif /* CONFIG_OF */
> > +
> > +static struct platform_driver cros_ec_throttler_driver = {
> > + .driver = {
> > + .name = "cros-ec-throttler",
> > + .of_match_table = of_match_ptr(cros_ec_throttler_of_match),
> > + },
> > + .probe = cros_ec_throttler_probe,
> > + .remove = cros_ec_throttler_remove,
> > +};
> > +
> > +module_platform_driver(cros_ec_throttler_driver);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Matthias Kaehlcke <mka@chromium.org>");
> > +MODULE_DESCRIPTION("Chrome OS EC Throttler");
>
> s/Chrome OS/ChromeOS/
>
> >
>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>
> Thanks,
> Enric
^ permalink raw reply
* Re: [PATCH 1/1] dw9807: Use the dongwoon,dw9807-vcm compatible string
From: Rob Herring @ 2018-05-31 17:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, devicetree, bingbu.cao, tian.shu.qiu, rajmohan.mani
In-Reply-To: <20180529122554.3325-1-sakari.ailus@linux.intel.com>
On Tue, May 29, 2018 at 03:25:54PM +0300, Sakari Ailus wrote:
> The original dw9807 DT bindings patch proposed the dongwoon,dw9807
> compatible string. However, the device also includes an EEPROM on a
> different I�C address. Indicate that this is just the VCM part of the
> entire device.
>
> The EEPROM part is compatible with the at24c64 for read-only access, with
> 1 kiB page size.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
> Hi Rob, others,
>
> The original bindings were missing the EEPROM bit. This change recognises
> it's there, and allows adding more elaborate support for it later on if
> needed.
>
> If this change is fine, I'll squash it to the original patches that are
> not yet merged:
Looks fine to me.
>
> <URL:https://patchwork.linuxtv.org/patch/49613/>
> <URL:https://patchwork.linuxtv.org/patch/49614/>
>
> Thanks.
>
> Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 2 +-
> drivers/media/i2c/dw9807.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] Input: of_touchscreen / generic bindings - Add support for touchscreen-min-x|y
From: Rob Herring @ 2018-05-31 17:25 UTC (permalink / raw)
To: Hans de Goede
Cc: Dmitry Torokhov, Benjamin Tissoires, devicetree, linux-input
In-Reply-To: <20180529115238.12965-1-hdegoede@redhat.com>
On Tue, May 29, 2018 at 01:52:38PM +0200, Hans de Goede wrote:
> Some touchscreens, depending on the firmware and/or the digitizer report
> coordinates which never reach 0 along one or both of their axis.
>
> This has been seen for example on the Silead touchscreens on a Onda V891w
> and a Point of View mobii TAB-P800w(v2.0).
>
> This commit adds support for touchscreen-min-x and touchscreen-min-y
> device-properties which can be set to communicate the actual start
> coordinates (rather then 0,0) to userspace.
>
> When set this fixes e.g. not being able to click things in the GNOME3
> top-bar on the 2 example tablets.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../input/touchscreen/touchscreen.txt | 6 ++--
Please split bindings to separate patch.
> drivers/input/touchscreen/of_touchscreen.c | 36 ++++++++++++++-----
> 2 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> index 537643e86f61..8aff9551259f 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> @@ -1,10 +1,12 @@
> General Touchscreen Properties:
>
> Optional properties for Touchscreens:
> + - touchscreen-min-x : minimum x coordinate reported (0 if not set)
> + - touchscreen-min-y : minimum y coordinate reported (0 if not set)
Maybe a min-max range would be better if size (in pixels) is also
needed?
> - touchscreen-size-x : horizontal resolution of touchscreen
> - (in pixels)
> + (maximum x coordinate reported + 1)
This is unrelated or at least not explained in the commit msg. I agree
this probably makes sense as units are often not pixels unless the hw/fw
is doing some scaling itself.
> - touchscreen-size-y : vertical resolution of touchscreen
> - (in pixels)
> + (maximum y coordinate reported + 1)
> - touchscreen-max-pressure : maximum reported pressure (arbitrary range
> dependent on the controller)
> - touchscreen-fuzz-x : horizontal noise value of the absolute input
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: Add Mediatek X20 Development Board support
From: Rob Herring @ 2018-05-31 17:17 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: matthias.bgg, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel, taiten.peng, daniel.thompson, amit.kucheria,
manivannanece23
In-Reply-To: <20180529045258.1415-3-manivannan.sadhasivam@linaro.org>
tOn Tue, May 29, 2018 at 10:22:58AM +0530, Manivannan Sadhasivam wrote:
> Add initial device tree support for Mediatek X20 Development Board
> based on MT6797 Deca core SoC. This board is one of the 96Boards
> Consumer Edition platform.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index ac17f60f998c..5b7fd6ad96e4 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> new file mode 100644
> index 000000000000..2c09ca95d9e2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for MediaTek X20 Development Board
> + *
> + * Copyright (C) 2018, Linaro Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "mt6797.dtsi"
> +
> +/ {
> + model = "Mediatek X20 Development Board";
> + compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
The board compatible needs documenting.
> +
> + aliases {
> + serial0 = &uart1;
> + };
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0 0x40000000 0 0x1e605000>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Add vendor prefix for ArcherMind
From: Rob Herring @ 2018-05-31 17:16 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: matthias.bgg, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel, taiten.peng, daniel.thompson, amit.kucheria,
manivannanece23
In-Reply-To: <20180529045258.1415-2-manivannan.sadhasivam@linaro.org>
On Tue, May 29, 2018 at 10:22:57AM +0530, Manivannan Sadhasivam wrote:
> Add vendor prefix for ArcherMind Technology (Nanjing) Co., Ltd.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
I've applied this while you all debate the dts file.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: fsi-master-gpio: Document "no-gpio-delays" property
From: Rob Herring @ 2018-05-31 17:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, devicetree, Greg Kroah-Hartman, Jeremy Kerr,
Joel Stanley, Christopher Bostic
In-Reply-To: <1a2aaf52c2f4d948d55ccf3953db92528c296733.camel@kernel.crashing.org>
On Tue, May 29, 2018 at 11:43:40AM +1000, Benjamin Herrenschmidt wrote:
> Support for this is being added to the driver but the original
> patch forgot to add this documentation.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt | 4 ++++
> 1 file changed, 4 insertions(+)
Applied.
Rob
^ permalink raw reply
* Re: [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-05-31 17:11 UTC (permalink / raw)
To: Christopher Obbard
Cc: Maxime Ripard, Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel, linux-sunxi
In-Reply-To: <CAP03XeoY8_-gG-2h8WP+3ZZFzxeyHERG=o7Y3Btk2svy5kco_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, May 31, 2018 at 10:25 PM, Christopher Obbard <chris-ljUBoSVpJTpWk0Htik3J/w@public.gmane.org> wrote:
> Hi Jagan,
>
> I cannot find any information on this board online, so I am guessing
> it has not been released yet and you are developing software support
> now.
>
> Do you have any datasheet/overview document of the board?
It's an industrial board for a real product and not so different than
what we supported a software for other A64 boards [1], I will update
the wiki for the same in couple of days.
[1] https://openedev.amarulasolutions.com/display/ODWIKI/A64
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: [PATCH v2 0/2] slimbus: Add QCOM SLIMBus NGD driver
From: Craig Tatlor @ 2018-05-31 17:06 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: gregkh, robh+dt, kramasub, sdharia, girishm, linux-kernel,
mark.rutland, bgoswami, devicetree, broonie, linux-arm-msm,
alsa-devel
In-Reply-To: <20180525111547.18556-1-srinivas.kandagatla@linaro.org>
Tested on msm8974 with wcd9320 codec.
Tested-by: Craig Tatlor <ctatlor97@gmail.com>
On Fri, May 25, 2018 at 12:15:45PM +0100, Srinivas Kandagatla wrote:
> This patchset adds support to basic version of Qualcomm NGD SLIMBus
> controller driver found SoCs from B family.
>
> This controller is light-weight SLIMBus controller driver responsible for
> communicating with slave HW directly over the bus using messaging
> interface, and communicating with master component residing on ADSP
> for bandwidth and data-channel management.
>
> Tested this patchset on DB820c with WCD9335 codec.
> I have pushed my working branch to [1] incase someone want to try.
>
> This patch has dependency on https://lkml.org/lkml/2018/5/17/251
>
> Changes sinc v1 (https://lwn.net/Articles/754679):
> - Fixed DT binding making NGD slave of the slim controller.
> - Fixed few typos spotted by Vinod.
> - Removed unnessary dmaengine_slave_config suggested by Vinod
> - Removed few unnessary initializations.
> - fixed commit log to remove reference to B family suggested by Trilok
>
> Thanks,
> srini
>
> [1] https://git.linaro.org/people/srinivas.kandagatla/linux.git/log/?h=slimbus-ngd
>
> Srinivas Kandagatla (2):
> slimbus: ngd: dt-bindings: Add slim ngd dt bindings
> slimbus: ngd: Add qcom SLIMBus NGD driver
>
> .../bindings/slimbus/slim-ngd-qcom-ctrl.txt | 84 ++
> drivers/slimbus/Kconfig | 11 +
> drivers/slimbus/Makefile | 3 +
> drivers/slimbus/qcom-ngd-ctrl.c | 1342 ++++++++++++++++++++
> drivers/slimbus/slimbus.h | 8 +
> 5 files changed, 1448 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
> create mode 100644 drivers/slimbus/qcom-ngd-ctrl.c
>
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: simple-card: make sysclk index configurable
From: Rob Herring @ 2018-05-31 17:02 UTC (permalink / raw)
To: Daniel Mack
Cc: devicetree, alsa-devel, Mark Brown, lgirdwood,
kuninori.morimoto.gx
In-Reply-To: <f130a86f-deca-b5cf-da34-5cf52a9c39fc@zonque.org>
On Tue, May 29, 2018 at 10:23:48PM +0200, Daniel Mack wrote:
> On Tuesday, May 29, 2018 01:24 PM, Mark Brown wrote:
> > On Mon, May 28, 2018 at 09:35:02PM +0200, Daniel Mack wrote:
> > > The simple-card driver currently hard-codes the clk_id parameter in
> > > snd_soc_dai_set_sysclk() to 0. Make this configrable for both CPU and
> > > codec dai sub-nodes.
> >
> > > This still has the limitation that only one clk_id can be configured, but it
> > > should help some more platforms to use simple-card in favor to a more
> > > specific machine driver.
> >
> > If we want to get more complex usage of clocks in the DT we should be
> > moving the CODECs over to using the standard clock bindings for this
> > stuff rather than inventing custom ASoC clock bindings for it. That way
> > we don't have to deal with the pain of trying to join things up in the
> > future.
>
> This will get rather complex too though, because most codec and cpu dais can
> act as clock source xor clock consumer, depending on how the hardware is
> built. Would you want to represent everything, bit clocks, frame clocks,
> master clocks etc as clock nodes?
I have no idea if you need all the clocks or not, but they certainly
shouldn't be a node per clock. Rather the codec and/or cpu dai should be
a clock provider and can provide N clocks.
> If that's the case, could you depict how the DT bindings should look like by
> example?
In clock providers, you just add #clock-cells. Then the consumer side
defines 'clocks'. Which clock(s) comes from the dai is defined by the
index in the 'clocks' property for that node.
Both ends can be providers, but who is active is determined by defining
the actual connections with 'clocks'. Or perhaps you have both
directions shown and there is some other means to select which one is
active such as solving for who can provide the desired freq.
Hope that helps.
Rob
^ permalink raw reply
* Re: [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Christopher Obbard @ 2018-05-31 16:55 UTC (permalink / raw)
To: jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/
Cc: Maxime Ripard, Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunxi
In-Reply-To: <20180531165109.8476-1-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Hi Jagan,
I cannot find any information on this board online, so I am guessing
it has not been released yet and you are developing software support
now.
Do you have any datasheet/overview document of the board?
Rather than making a lot of noise on the various MLs, why not wait
until all hardware has a driver written for it & bugs have been been
smashed, then patch in one series?
Christopher Obbard
64 Studio Ltd.
On 31 May 2018 at 17:51, Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi WL-WAKE-AP pin connected to gpio PL3
> - 32kHz external oscillator gate clock from RTC
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> Changes for v2:
> - Move external rtc clock nodes into main rtc node definition
> of sun50i-a64.dtsi
>
> .../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> index ce4a256ff086..eac4793c8502 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> @@ -21,12 +21,43 @@
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rtc 1>;
> + clock-names = "ext_clock";
> + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
> + };
> };
>
> &ehci0 {
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_dcdc1>;
> + /*
> + * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
> + * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
> + * 0Ohm register to vcc-io-wifi so eldo1 is used.
> + */
> + vqmmc-supply = <®_eldo1>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&r_pio>;
> + interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
> + interrupt-names = "host-wake";
> + };
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..82516aec4153 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -634,6 +634,9 @@
> reg = <0x01f00000 0x54>;
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> + clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> + clocks = <&osc32k>;
> + #clock-cells = <1>;
> };
>
> r_intc: interrupt-controller@1f00c00 {
> --
> 2.14.3
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-05-31 16:51 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
- WiFi SDIO interface is connected to MMC1
- WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
- WiFi WL-WAKE-AP pin connected to gpio PL3
- 32kHz external oscillator gate clock from RTC
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v2:
- Move external rtc clock nodes into main rtc node definition
of sun50i-a64.dtsi
.../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
2 files changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index ce4a256ff086..eac4793c8502 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -21,12 +21,43 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+ };
};
&ehci0 {
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dcdc1>;
+ /*
+ * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
+ * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
+ * 0Ohm register to vcc-io-wifi so eldo1 is used.
+ */
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
+ interrupt-names = "host-wake";
+ };
+};
+
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..82516aec4153 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -634,6 +634,9 @@
reg = <0x01f00000 0x54>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
+ clocks = <&osc32k>;
+ #clock-cells = <1>;
};
r_intc: interrupt-controller@1f00c00 {
--
2.14.3
^ 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