* Re: [PATCH v2 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Linus Walleij @ 2016-11-30 13:01 UTC (permalink / raw)
To: David Lechner
Cc: Rob Herring, Mark Rutland, Sekhar Nori, Kevin Hilman,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Axel Haslam,
Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <1480351226-3332-4-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This SoC has a separate pin controller for configuring pullup/pulldown
> bias on groups of pins.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * Moved pin-controller@22c00c device node after gpio@226000 (there seem to be
> more nodes in proper order here compared to the i2c@228000 node suggested by
> Sekhar)
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Take this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Javier Martinez Canillas @ 2016-11-30 13:11 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-wireless@vger.kernel.org, Linux Kernel,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren, Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CAJ_EiST_bpBm+spPuWH-a+47t4qVsDVFjUm=a+TtL-BWN3DHdw@mail.gmail.com>
Hello Matt,
On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
<matt@ranostay.consulting> wrote:
> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
[snip]
>
>
>>> +- pwndn-gpio: contains a power down GPIO specifier.
>>> +- reset-gpio: contains a reset GPIO specifier.
>>> +
>>
>> I wonder if we really need a custom power sequence provider for just
>> this SDIO WiFI chip though. AFAICT the only missing piece in
>> mmc-pwrseq-simple is the power down GPIO property, so maybe
>> mmc-pwrseq-simple could be extended instead to have an optional
>> powerdown-gpios property and instead in the Marvell SD8787 DT binding
>> can be mentioned which mmc-pwrseq-simple properties are required for
>> the device.
>>
>
> The reason we didn't do that is we need delay between the two
> assertions/desertions of GPIOs. It wouldn't seems good practice to
> hack the pwrseq-simple for this...
>
Yes, I noticed that. I wouldn't say that it would be a hack for the
pwrseq-simple since it already has a "post-power-on-delay-ms" DT
property, so AFAICT it would just be adding a "pre-power-on-delay-ms"
property for your use case.
It would also be more consistent since it would support a delay for
pre and post power callbacks. It would also make you avoid hardcoding
the 300 msec wait, in case other device has a similar need but with a
different wait time.
In summary, I think that devices having a power (or power down) and
enable GPIO, and needing to wait between the GPIO toggling are common.
So I would prefer to make pwrseq-simple usable for these instead of
adding device specific power sequence providers. But it's just my
opinion and not my call :-)
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>> + }
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>
>> Does this patch depend on a previous posted series? I don't see this
>> file in today's linux-next...
>
> Got renamed to ->
> Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
> seems very recently.
>
I see, that's what I thought but I wasn't able to find the commit /
patch that did it.
>>
>>> index c421aba0a5bc..08fd65d35725 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> @@ -32,6 +32,9 @@ Optional properties:
>>> so that the wifi chip can wakeup host platform under certain condition.
>>> during system resume, the irq will be disabled to make sure
>>> unnecessary interrupt is not received.
>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>>> + for documentation of MMC power sequence bindings.
>>>
>>> Example:
>>>
>>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
>>> &mmc3 {
>>> status = "okay";
>>> vmmc-supply = <&wlan_en_reg>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> bus-width = <4>;
>>> cap-power-off-card;
>>> keep-power-in-suspend;
>>
>> I think this change should be split in a separate patch as well.
>>
You didn't answer about this, but I guess you agree it should be in a
separate patch.
Best regards,
Javier
^ permalink raw reply
* [PATCH v6 0/4] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (4):
i2c: pxa: Add definition of fast and high speed modes via the regs
layout
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 26 +++++++++++++++++++++--
5 files changed, 48 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v6 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
So far, the bit masks for the fast and high speed mode were statically
defined. Some IP blocks might use different bits for these modes.
This commit introduces new fields in order to enable the definition of
different bit masks for these features. If these fields are undefined,
ICR_FM and ICR_HS are selected to preserve backward compatibility with
other IPs.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/i2c/busses/i2c-pxa.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..dc9d0a6 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -48,6 +48,8 @@ struct pxa_reg_layout {
u32 isar;
u32 ilcr;
u32 iwcr;
+ u32 fm;
+ u32 hs;
};
enum pxa_i2c_types {
@@ -193,6 +195,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ u32 fm_mask;
+ u32 hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +507,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
+ i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? pxa_reg_layout[i2c_type].fm : ICR_FM;
+ i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? pxa_reg_layout[i2c_type].hs : ICR_HS;
+
if (i2c_type != REGS_CE4100)
i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161130140017.26307-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v6:
- Revert back A3700_REGS, as asked by Wolfram and define fm_mask
and hs_mask in the register layout. I moved the generic code
for fm_mask and hs_mask to a seperated commit (1/4)
Changes in v5:
- Don't define registers for armada-3700, we can re-use the ones
for PXA3XX.
- Define registers mask when OF is not used, in probe_pdata.
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index dc9d0a6..0ded4bc 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -57,8 +57,12 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
+
/*
* I2C registers definitions
*/
@@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ .fm = ICR_BUSMODE_FM,
+ .hs = ICR_BUSMODE_HS,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 3/4] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd587..1b0fd21 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_periph_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_periph_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 4/4] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Added the tag 'Acked-by', by Rob Herring
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2 0/5] Add support for the Armada 3700 SPI controller
From: Gregory CLEMENT @ 2016-11-30 14:30 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161130094351.2748-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Romain,
On mer., nov. 30 2016, Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The Marvell Armada 3700 SoC includes an SPI controller. This controller
> supports up to 4 SPI slave devices, with dedicated chip selects, CPIO or
> FIFO mode with DMA or CPU transfers and different SPI transfer modes
> (Standard single, Dual or Quad).
>
> This set of patches adds a basic support for the CPIO mode, then it
> enables the FIFO mode (CPU-side only, DMA not supported yet). It also
> adds the required definitions of the spi nodes to the devicetree.
>
I tested the series on the Rev 1.1 and the Rev 2.0 Armada 3720 Db board
and it works on both of them: I managed at leat to read the spi
dataflash.
So for the series you can add my
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Gregory
> Romain Perier (5):
> spi: Add basic support for Armada 3700 SPI Controller
> spi: armada-3700: Add support for the FIFO mode
> dt-bindings: spi: Add documentation for the Armada 3700 SPI Controller
> arm64: dts: marvell: Add definition of SPI controller for Armada 3700
> arm64: dts: marvell: Enable spi0 on the board Armada-3720-db
>
> .../devicetree/bindings/spi/spi-armada-3700.txt | 25 +
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 30 +
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 13 +
> drivers/spi/Kconfig | 7 +
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-armada-3700.c | 1040 ++++++++++++++++++++
> 6 files changed, 1116 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-armada-3700.txt
> create mode 100644 drivers/spi/spi-armada-3700.c
>
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Ulf Hansson @ 2016-11-30 14:39 UTC (permalink / raw)
To: Javier Martinez Canillas, Matt Ranostay
Cc: linux-wireless@vger.kernel.org, Linux Kernel,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CABxcv=nc1qjtSjzfcuGTo-zUpuWdRT6OR7MZCCWaoeq4Co3Uew@mail.gmail.com>
On 30 November 2016 at 14:11, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Matt,
>
> On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
> <matt@ranostay.consulting> wrote:
>> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
>
> [snip]
>
>>
>>
>>>> +- pwndn-gpio: contains a power down GPIO specifier.
>>>> +- reset-gpio: contains a reset GPIO specifier.
>>>> +
>>>
>>> I wonder if we really need a custom power sequence provider for just
>>> this SDIO WiFI chip though. AFAICT the only missing piece in
>>> mmc-pwrseq-simple is the power down GPIO property, so maybe
>>> mmc-pwrseq-simple could be extended instead to have an optional
>>> powerdown-gpios property and instead in the Marvell SD8787 DT binding
>>> can be mentioned which mmc-pwrseq-simple properties are required for
>>> the device.
>>>
>>
>> The reason we didn't do that is we need delay between the two
>> assertions/desertions of GPIOs. It wouldn't seems good practice to
>> hack the pwrseq-simple for this...
>>
>
> Yes, I noticed that. I wouldn't say that it would be a hack for the
> pwrseq-simple since it already has a "post-power-on-delay-ms" DT
> property, so AFAICT it would just be adding a "pre-power-on-delay-ms"
> property for your use case.
>
> It would also be more consistent since it would support a delay for
> pre and post power callbacks. It would also make you avoid hardcoding
> the 300 msec wait, in case other device has a similar need but with a
> different wait time.
>
> In summary, I think that devices having a power (or power down) and
> enable GPIO, and needing to wait between the GPIO toggling are common.
> So I would prefer to make pwrseq-simple usable for these instead of
> adding device specific power sequence providers. But it's just my
> opinion and not my call :-)
This is a good idea. Please try out this approach.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: marvell: Add definition of SPI controller for Armada 3700
From: Gregory CLEMENT @ 2016-11-30 14:55 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161130094351.2748-5-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Romain,
On mer., nov. 30 2016, Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Armada 3700 SoC has an SPI Controller, this commit adds the definition
> of the SPI device node at the SoC level.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> Changes in v2:
> - Removed properties max-frequency and clock-frequency, it is no
> longer required and not used by the DT-bindings.
>
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index e9bd587..63c2002 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -98,6 +98,17 @@
> /* 32M internal register @ 0xd000_0000 */
> ranges = <0x0 0x0 0xd0000000 0x2000000>;
>
> + spi0: spi@10600 {
> + compatible = "marvell,armada-3700-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x10600 0x5d>;
The last register is at the offset 0x1065C but according tot he
datasheet the range address associated to this IP is from 0x10600 to
0x10FFF.
In the first case the size of the register set should be 0x60 (each
register is 32-bits). But I prefer that we register the full range so a
size of 0xA00.
Thanks,
Gregory
> + clocks = <&nb_periph_clk 7>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + num-cs = <4>;
> + status = "disabled";
> + };
> +
> uart0: serial@12000 {
> compatible = "marvell,armada-3700-uart";
> reg = <0x12000 0x400>;
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/5] spi: armada-3700: Add support for the FIFO mode
From: Gregory CLEMENT @ 2016-11-30 15:15 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161130094351.2748-3-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Romain,
On mer., nov. 30 2016, Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> In FIFO mode, dedicated registers are used to store the instruction,
> the address, the read mode and the data. Write and Read FIFO are used
> to store the outcoming or incoming data. The CPU no longer has to assert
> each byte. The data FIFOs are accessible via DMA or by the CPU.
>
> This commit adds support for the FIFO mode with the CPU.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> Changes in v2:
> - Removed a3700_spi_bytelen_set from the setup function, it was accidentally
> let here and not required, as it is configured in the prepare callback now
> (defaults to 4 for fifo mode). It solves unrecognized spi-nor flash memory
> detection with jedec.
>
> drivers/spi/spi-armada-3700.c | 409 ++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 399 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c
> index cc9e1b2..72f1818 100644
> --- a/drivers/spi/spi-armada-3700.c
> +++ b/drivers/spi/spi-armada-3700.c
> @@ -99,19 +99,28 @@
> /* A3700_SPI_IF_TIME_REG */
> #define A3700_SPI_CLK_CAPT_EDGE BIT(7)
>
> +/* Flags and macros for struct a3700_spi */
> +#define HAS_FIFO BIT(0)
> +#define A3700_INSTR_CNT 1
> +#define A3700_ADDR_CNT 3
> +#define A3700_DUMMY_CNT 1
> +
> struct a3700_spi {
> struct spi_master *master;
> void __iomem *base;
> struct clk *clk;
> unsigned int irq;
> unsigned int flags;
> - bool last_xfer;
> + bool xmit_data;
> const u8 *tx_buf;
> u8 *rx_buf;
> size_t buf_len;
> u8 byte_len;
> u32 wait_mask;
> struct completion done;
> + u32 addr_cnt;
> + u32 instr_cnt;
> + size_t hdr_cnt;
> };
>
> static u32 spireg_read(struct a3700_spi *a3700_spi, u32 offset)
> @@ -180,12 +189,15 @@ static int a3700_spi_pin_mode_set(struct a3700_spi *a3700_spi,
> return 0;
> }
>
> -static void a3700_spi_fifo_mode_unset(struct a3700_spi *a3700_spi)
> +static void a3700_spi_fifo_mode_set(struct a3700_spi *a3700_spi)
> {
> u32 val;
>
> val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> - val &= ~A3700_SPI_FIFO_MODE;
> + if (a3700_spi->flags & HAS_FIFO)
> + val |= A3700_SPI_FIFO_MODE;
> + else
> + val &= ~A3700_SPI_FIFO_MODE;
> spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> }
>
> @@ -255,11 +267,30 @@ static void a3700_spi_bytelen_set(struct a3700_spi *a3700_spi, unsigned int len)
> a3700_spi->byte_len = len;
> }
>
> +static int a3700_spi_fifo_flush(struct a3700_spi *a3700_spi)
> +{
> + int timeout = A3700_SPI_TIMEOUT;
> + u32 val;
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_FIFO_FLUSH;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + while (--timeout) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + if (!(val & A3700_SPI_FIFO_FLUSH))
> + return 0;
> + udelay(1);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> static int a3700_spi_init(struct a3700_spi *a3700_spi)
> {
> struct spi_master *master = a3700_spi->master;
> u32 val;
> - int i;
> + int i, ret = 0;
>
> /* Reset SPI unit */
> val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> @@ -278,10 +309,8 @@ static int a3700_spi_init(struct a3700_spi *a3700_spi)
> for (i = 0; i < master->num_chipselect; i++)
> a3700_spi_deactivate_cs(a3700_spi, i);
>
> - a3700_spi_pin_mode_set(a3700_spi, 0);
> -
> - /* Be sure that FIFO mode is disabled */
> - a3700_spi_fifo_mode_unset(a3700_spi);
> + /* Enable FIFO mode */
> + a3700_spi_fifo_mode_set(a3700_spi);
>
> /* Set SPI mode */
> a3700_spi_mode_set(a3700_spi, master->mode_bits);
> @@ -294,7 +323,7 @@ static int a3700_spi_init(struct a3700_spi *a3700_spi)
> spireg_write(a3700_spi, A3700_SPI_INT_MASK_REG, 0);
> spireg_write(a3700_spi, A3700_SPI_INT_STAT_REG, ~0U);
>
> - return 0;
> + return ret;
> }
>
> static irqreturn_t a3700_spi_interrupt(int irq, void *dev_id)
> @@ -380,14 +409,34 @@ static bool a3700_spi_transfer_wait(struct spi_device *spi,
> return a3700_spi_wait_completion(spi);
> }
>
> +static void a3700_spi_fifo_thres_set(struct a3700_spi *a3700_spi,
> + unsigned int bytes)
> +{
> + u32 val;
> +
> + if (a3700_spi->flags & HAS_FIFO) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val &= ~(A3700_SPI_FIFO_THRS_MASK << A3700_SPI_RFIFO_THRS_BIT);
> + val |= (bytes - 1) << A3700_SPI_RFIFO_THRS_BIT;
> + val &= ~(A3700_SPI_FIFO_THRS_MASK << A3700_SPI_WFIFO_THRS_BIT);
> + val |= (7 - bytes) << A3700_SPI_WFIFO_THRS_BIT;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + }
> +}
> +
> static void a3700_spi_transfer_setup(struct spi_device *spi,
> struct spi_transfer *xfer)
> {
> struct a3700_spi *a3700_spi;
> + unsigned int byte_len;
>
> a3700_spi = spi_master_get_devdata(spi->master);
>
> a3700_spi_clock_set(a3700_spi, xfer->speed_hz, spi->mode);
> +
> + byte_len = xfer->bits_per_word >> 3;
> +
> + a3700_spi_fifo_thres_set(a3700_spi, byte_len);
> }
>
> static int a3700_spi_read_data(struct a3700_spi *a3700_spi)
> @@ -447,6 +496,168 @@ static void a3700_spi_set_cs(struct spi_device *spi, bool enable)
> a3700_spi_deactivate_cs(a3700_spi, spi->chip_select);
> }
>
> +static void a3700_spi_header_set(struct a3700_spi *a3700_spi)
> +{
> + u32 instr_cnt = 0, addr_cnt = 0, dummy_cnt = 0;
> + u32 val = 0;
> +
> + /* Clear the header registers */
> + spireg_write(a3700_spi, A3700_SPI_IF_INST_REG, 0);
> + spireg_write(a3700_spi, A3700_SPI_IF_ADDR_REG, 0);
> + spireg_write(a3700_spi, A3700_SPI_IF_RMODE_REG, 0);
> +
> + /* Set header counters */
> + if (a3700_spi->tx_buf) {
> + if (a3700_spi->buf_len <= a3700_spi->instr_cnt) {
> + instr_cnt = a3700_spi->buf_len;
> + } else if (a3700_spi->buf_len <= (a3700_spi->instr_cnt +
> + a3700_spi->addr_cnt)) {
> + instr_cnt = a3700_spi->instr_cnt;
> + addr_cnt = a3700_spi->buf_len - instr_cnt;
> + } else if (a3700_spi->buf_len <= a3700_spi->hdr_cnt) {
> + instr_cnt = a3700_spi->instr_cnt;
> + addr_cnt = a3700_spi->addr_cnt;
> + /* Need to handle the normal write case with 1 byte
> + * data
> + */
> + if (!a3700_spi->tx_buf[instr_cnt + addr_cnt])
> + dummy_cnt = a3700_spi->buf_len - instr_cnt -
> + addr_cnt;
> + }
> + val |= ((instr_cnt & A3700_SPI_INSTR_CNT_MASK)
> + << A3700_SPI_INSTR_CNT_BIT);
> + val |= ((addr_cnt & A3700_SPI_ADDR_CNT_MASK)
> + << A3700_SPI_ADDR_CNT_BIT);
> + val |= ((dummy_cnt & A3700_SPI_DUMMY_CNT_MASK)
> + << A3700_SPI_DUMMY_CNT_BIT);
> + }
> + spireg_write(a3700_spi, A3700_SPI_IF_HDR_CNT_REG, val);
> +
> + /* Update the buffer length to be transferred */
> + a3700_spi->buf_len -= (instr_cnt + addr_cnt + dummy_cnt);
> +
> + /* Set Instruction */
> + val = 0;
> + while (instr_cnt--) {
> + val = (val << 8) | a3700_spi->tx_buf[0];
> + a3700_spi->tx_buf++;
> + }
> + spireg_write(a3700_spi, A3700_SPI_IF_INST_REG, val);
> +
> + /* Set Address */
> + val = 0;
> + while (addr_cnt--) {
> + val = (val << 8) | a3700_spi->tx_buf[0];
> + a3700_spi->tx_buf++;
> + }
> + spireg_write(a3700_spi, A3700_SPI_IF_ADDR_REG, val);
> +}
> +
> +static int a3700_is_wfifo_full(struct a3700_spi *a3700_spi)
> +{
> + u32 val;
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CTRL_REG);
> + return (val & A3700_SPI_WFIFO_FULL);
> +}
> +
> +static int a3700_spi_fifo_write(struct a3700_spi *a3700_spi)
> +{
> + u32 val;
> + int i = 0;
> +
> + while (!a3700_is_wfifo_full(a3700_spi) && a3700_spi->buf_len) {
> + val = 0;
> + if (a3700_spi->buf_len >= 4) {
> + val = cpu_to_le32(*(u32 *)a3700_spi->tx_buf);
> + spireg_write(a3700_spi, A3700_SPI_DATA_OUT_REG, val);
> +
> + a3700_spi->buf_len -= 4;
> + a3700_spi->tx_buf += 4;
> + } else {
> + /*
> + * If the remained buffer length is less than 4-bytes,
> + * we should pad the write buffer with all ones. So that
> + * it avoids overwrite the unexpected bytes following
> + * the last one.
> + */
> + val = GENMASK(31, 0);
> + while (a3700_spi->buf_len) {
> + val &= ~(0xff << (8 * i));
> + val |= *a3700_spi->tx_buf++ << (8 * i);
> + i++;
> + a3700_spi->buf_len--;
> +
> + spireg_write(a3700_spi, A3700_SPI_DATA_OUT_REG,
> + val);
> + }
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int a3700_is_rfifo_empty(struct a3700_spi *a3700_spi)
> +{
> + u32 val = spireg_read(a3700_spi, A3700_SPI_IF_CTRL_REG);
> +
> + return (val & A3700_SPI_RFIFO_EMPTY);
> +}
> +
> +static int a3700_spi_fifo_read(struct a3700_spi *a3700_spi)
> +{
> + u32 val;
> +
> + while (!a3700_is_rfifo_empty(a3700_spi) && a3700_spi->buf_len) {
> + val = spireg_read(a3700_spi, A3700_SPI_DATA_IN_REG);
> + if (a3700_spi->buf_len >= 4) {
> + u32 data = le32_to_cpu(val);
> + memcpy(a3700_spi->rx_buf, &data, 4);
> +
> + a3700_spi->buf_len -= 4;
> + a3700_spi->rx_buf += 4;
> + } else {
> + /*
> + * When remain bytes is not larger than 4, we should
> + * avoid memory overwriting and just write the left rx
> + * buffer bytes.
> + */
> + while (a3700_spi->buf_len) {
> + *a3700_spi->rx_buf = val & 0xff;
> + val >>= 8;
> +
> + a3700_spi->buf_len--;
> + a3700_spi->rx_buf++;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void a3700_spi_transfer_abort_fifo(struct a3700_spi *a3700_spi)
> +{
> + int timeout = A3700_SPI_TIMEOUT;
> + u32 val;
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + while (--timeout) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + if (!(val & A3700_SPI_XFER_START))
> + break;
> + udelay(1);
> + }
> +
> + a3700_spi_fifo_flush(a3700_spi);
> +
> + val &= ~A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +}
> +
> static int a3700_spi_prepare_message(struct spi_master *master,
> struct spi_message *message)
> {
> @@ -463,12 +674,28 @@ static int a3700_spi_prepare_message(struct spi_master *master,
> return 0;
> }
>
> +static int a3700_spi_prepare_fifo_message(struct spi_master *master,
> + struct spi_message *message)
> +{
> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> + int ret;
> +
> + /* Flush the FIFOs */
> + ret = a3700_spi_fifo_flush(a3700_spi);
> + if (ret)
> + return ret;
> +
> + a3700_spi_bytelen_set(a3700_spi, 4);
> +
> + return 0;
> +}
> +
> static int a3700_spi_transfer_one(struct spi_master *master,
> struct spi_device *spi,
> struct spi_transfer *xfer)
> {
> struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> - int ret = 0;
> + int ret;
>
> a3700_spi_transfer_setup(spi, xfer);
>
> @@ -505,6 +732,151 @@ static int a3700_spi_transfer_one(struct spi_master *master,
> return ret;
> }
>
> +static int a3700_spi_fifo_transfer_one(struct spi_master *master,
> + struct spi_device *spi,
> + struct spi_transfer *xfer)
> +{
> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> + int ret = 0, timeout = A3700_SPI_TIMEOUT;
> + unsigned int nbits = 0;
> + u32 val;
> +
> + a3700_spi_transfer_setup(spi, xfer);
> +
> + a3700_spi->tx_buf = xfer->tx_buf;
> + a3700_spi->rx_buf = xfer->rx_buf;
> + a3700_spi->buf_len = xfer->len;
> +
> + /* SPI transfer headers */
> + a3700_spi_header_set(a3700_spi);
> +
> + if (xfer->tx_buf)
> + nbits = xfer->tx_nbits;
> + else if (xfer->rx_buf)
> + nbits = xfer->rx_nbits;
> +
> + a3700_spi_pin_mode_set(a3700_spi, nbits);
> +
> + if (xfer->rx_buf) {
> + /* Set read data length */
> + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
> + a3700_spi->buf_len);
> + /* Start READ transfer */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val &= ~A3700_SPI_RW_EN;
> + val |= A3700_SPI_XFER_START;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + } else if (xfer->tx_buf) {
> + /* Start Write transfer */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= (A3700_SPI_XFER_START | A3700_SPI_RW_EN);
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + /*
> + * If there are data to be written to the SPI device, xmit_data
> + * flag is set true; otherwise the instruction in SPI_INSTR does
> + * not require data to be written to the SPI device, then
> + * xmit_data flag is set false.
> + */
> + a3700_spi->xmit_data = (a3700_spi->buf_len != 0);
> + }
> +
> + while (a3700_spi->buf_len) {
> + if (a3700_spi->tx_buf) {
> + /* Wait wfifo ready */
> + if (!a3700_spi_transfer_wait(spi,
> + A3700_SPI_WFIFO_RDY)) {
> + dev_err(&spi->dev,
> + "wait wfifo ready timed out\n");
> + ret = -ETIMEDOUT;
> + goto error;
> + }
> + /* Fill up the wfifo */
> + ret = a3700_spi_fifo_write(a3700_spi);
> + if (ret)
> + goto error;
> + } else if (a3700_spi->rx_buf) {
> + /* Wait rfifo ready */
> + if (!a3700_spi_transfer_wait(spi,
> + A3700_SPI_RFIFO_RDY)) {
> + dev_err(&spi->dev,
> + "wait rfifo ready timed out\n");
> + ret = -ETIMEDOUT;
> + goto error;
> + }
> + /* Drain out the rfifo */
> + ret = a3700_spi_fifo_read(a3700_spi);
> + if (ret)
> + goto error;
> + }
> + }
> +
> + /*
> + * Stop a write transfer in fifo mode:
> + * - wait all the bytes in wfifo to be shifted out
> + * - set XFER_STOP bit
> + * - wait XFER_START bit clear
> + * - clear XFER_STOP bit
> + * Stop a read transfer in fifo mode:
> + * - the hardware is to reset the XFER_START bit
> + * after the number of bytes indicated in DIN_CNT
> + * register
> + * - just wait XFER_START bit clear
> + */
> + if (a3700_spi->tx_buf) {
> + if (a3700_spi->xmit_data) {
> + /*
> + * If there are data written to the SPI device, wait
> + * until SPI_WFIFO_EMPTY is 1 to wait for all data to
> + * transfer out of write FIFO.
> + */
> + if (!a3700_spi_transfer_wait(spi,
> + A3700_SPI_WFIFO_EMPTY)) {
> + dev_err(&spi->dev, "wait wfifo empty timed out\n");
> + return -ETIMEDOUT;
> + }
> + } else {
> + /*
> + * If the instruction in SPI_INSTR does not require data
> + * to be written to the SPI device, wait until SPI_RDY
> + * is 1 for the SPI interface to be in idle.
> + */
> + if (!a3700_spi_transfer_wait(spi, A3700_SPI_XFER_RDY)) {
> + dev_err(&spi->dev, "wait xfer ready timed out\n");
> + return -ETIMEDOUT;
> + }
> + }
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + }
> +
> + while (--timeout) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + if (!(val & A3700_SPI_XFER_START))
> + break;
> + udelay(1);
> + }
> +
> + if (timeout == 0) {
> + dev_err(&spi->dev, "wait transfer start clear timed out\n");
> + ret = -ETIMEDOUT;
> + goto error;
> + }
> +
> + val &= ~A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + goto out;
> +
> +error:
> + a3700_spi_transfer_abort_fifo(a3700_spi);
> +out:
> + spi_finalize_current_transfer(master);
> +
> + return ret;
> +}
> +
> static int a3700_spi_unprepare_message(struct spi_master *master,
> struct spi_message *message)
> {
> @@ -592,6 +964,23 @@ static int a3700_spi_probe(struct platform_device *pdev)
> goto error;
> }
>
> + if (of_device_is_compatible(of_node, "marvell,armada-3700-spi"))
> {
I don't understand this test. Given the a3700_spi_dt_ids value, the
probe can only be called if the compatible is
"marvell,armada-3700-spi". So this test seems not needed and the "else"
part is never reached.
It seems you wanted to make the FIFO feature optional. But is there any
drawback with FIFO mode ? If not you can just make it the default mode
and remove the 3 functions: a3700_spi_prepare_message(),
a3700_spi_transfer_one() and a3700_spi_unprepare_message(). And if there
is an interest to have the non-FIFO mode then you should use a module
parameter for it.
Gregory
> + master->prepare_message = a3700_spi_prepare_fifo_message;
> + master->transfer_one = a3700_spi_fifo_transfer_one;
> +
> + spi->flags |= HAS_FIFO;
> + spi->instr_cnt = A3700_INSTR_CNT;
> + spi->addr_cnt = A3700_ADDR_CNT;
> + spi->hdr_cnt = A3700_INSTR_CNT + A3700_ADDR_CNT +
> + A3700_DUMMY_CNT;
> + master->mode_bits |= (SPI_RX_DUAL | SPI_RX_DUAL |
> + SPI_RX_QUAD | SPI_TX_QUAD);
> + } else {
> + master->prepare_message = a3700_spi_prepare_message;
> + master->transfer_one = a3700_spi_transfer_one;
> + master->unprepare_message = a3700_spi_unprepare_message;
> + }
> +
> ret = a3700_spi_init(spi);
> if (ret)
> goto error_clk;
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Gregory CLEMENT @ 2016-11-30 15:43 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin
In-Reply-To: <20161130140017.26307-3-romain.perier@free-electrons.com>
Hi Romain,
On mer., nov. 30 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
As the code had changed I tested it agin and it continues to work, so
you can keep my Tested-by.
However I have a small remark, see below:
> ---
>
> Changes in v6:
> - Revert back A3700_REGS, as asked by Wolfram and define fm_mask
> and hs_mask in the register layout. I moved the generic code
> for fm_mask and hs_mask to a seperated commit (1/4)
>
> Changes in v5:
> - Don't define registers for armada-3700, we can re-use the ones
> for PXA3XX.
> - Define registers mask when OF is not used, in probe_pdata.
>
> Changes in v4:
> - Replaced the type of hs_mask and fm_mask by u32, instead of
> unsigned int, As writel() take an u32 as first argument...
>
> Changes in v3:
> - Replaced the type of hs_mask and fm_mask by unsigned int,
> instead of unsigned long.
>
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index d252276..2f56a26 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -763,7 +763,7 @@ config I2C_PUV3
>
> config I2C_PXA
> tristate "Intel PXA2XX I2C adapter"
> - depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
> + depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
> help
> If you have devices in the PXA I2C bus, say yes to this option.
> This driver can also be built as a module. If so, the module
Maybe you could add that this driver is no longer only for the PXA
family but also for the Armada 37xx.
Gregory
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index dc9d0a6..0ded4bc 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -57,8 +57,12 @@ enum pxa_i2c_types {
> REGS_PXA3XX,
> REGS_CE4100,
> REGS_PXA910,
> + REGS_A3700,
> };
>
> +#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
> +#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
> +
> /*
> * I2C registers definitions
> */
> @@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
> .ilcr = 0x28,
> .iwcr = 0x30,
> },
> + [REGS_A3700] = {
> + .ibmr = 0x00,
> + .idbr = 0x04,
> + .icr = 0x08,
> + .isr = 0x0c,
> + .isar = 0x10,
> + .fm = ICR_BUSMODE_FM,
> + .hs = ICR_BUSMODE_HS,
> + },
> };
>
> static const struct platform_device_id i2c_pxa_id_table[] = {
> @@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
> { "pxa3xx-pwri2c", REGS_PXA3XX },
> { "ce4100-i2c", REGS_CE4100 },
> { "pxa910-i2c", REGS_PXA910 },
> + { "armada-3700-i2c", REGS_A3700 },
> { },
> };
> MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> @@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
> { .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> { .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
> + { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
> {}
> };
> MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 0/4] drm: Add support for the Amlogic Video Processing Unit
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, daniel-/w4YWyX8dFk,
devicetree-u79uwXL29TY76Z2rM5mHXA
This a repost of the previous version at [2] with fixes, the following patches will
be sent via a PULL Request once the DT maintainers acks the DT bindings.
The Amlogic maintainer will take the arm64 DT patches to avoid merges conflicts.
The Amlogic Meson SoCs embeds a Video Processing Unit able to output at least
a Composite/CVBS Video with embedded VDAC and an HDMI Link with Embedded HDMI
Transceiver.
Thus, the current driver does not support HDMI yet.
The Video Processig Unit is composed of multiple modules like the Video
Input Unit and the Video Post Processing that can be associated to a
CRTC with Planes management.
The last Unit is the Venc that embeds at least 3 Encoders, ENCI for Interlace
Video used by CVBS or HDMI, ENCP for Progressive Video used by the HDMI
Transceiver and ENCL for LCD Display.
The LCD Display is not planned to be supported on the Meson GX Family.
This driver is a DRM/KMS driver using the following DRM components :
- GEM-CMA
- PRIME-CMA
- Atomic Modesetting
- FBDev-CMA
For the following SoCs :
- GXBB Family (S905)
- GXL Family (S905X, S905D)
- GXM Family (S912)
The current driver only supports the CVBS PAL/NTSC output modes, but the
CRTC/Planes management should support bigger modes.
But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
a second time.
The Device Tree bindings makes use of the endpoints video interface definitions
to connect to the optional CVBS and in the future the HDMI Connector nodes.
The driver has been tested with Xorg modesetting driver and Weston DRM backend.
Changes since v1 at [2] :
- Simplify bindings to have a "composite-video-connector" to represent the on-board composite connector
- Remove the component_match binding since it's unused for now
- Moved all DRM connector code back in the venc_cvbs file
- Check for port endpoints validity to detech connector existence
- Added Daniel Vetter's ack on non-dt patches commit messages
Changes since RFC at [1] :
- Add maintainers entry
- Move all Plane and CRTC code from backend to corresponding DRM code
- Keep only init and common code in backend source files
- Move the CVBS encoder out of the CVBS DT node, only keep the connector
- Various cleanups using DRM helpers
- Cleanup of copyright headers
- Fixup of bindings documentation
[1] http://lkml.kernel.org/r/1480089791-12517-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
[2] http://lkml.kernel.org/r/1480416469-9655-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
Neil Armstrong (4):
drm: Add support for Amlogic Meson Graphic Controller
ARM64: dts: meson-gx: Add Graphic Controller nodes
dt-bindings: display: add Amlogic Meson DRM Bindings
MAINTAINERS: add entry for Amlogic DRM drivers
.../bindings/display/meson/meson-drm.txt | 101 ++
MAINTAINERS | 9 +
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 +
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 +
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/meson/Kconfig | 9 +
drivers/gpu/drm/meson/Makefile | 4 +
drivers/gpu/drm/meson/meson_canvas.c | 68 +
drivers/gpu/drm/meson/meson_canvas.h | 42 +
drivers/gpu/drm/meson/meson_crtc.c | 208 +++
drivers/gpu/drm/meson/meson_crtc.h | 32 +
drivers/gpu/drm/meson/meson_drv.c | 343 +++++
drivers/gpu/drm/meson/meson_drv.h | 60 +
drivers/gpu/drm/meson/meson_plane.c | 230 ++++
drivers/gpu/drm/meson/meson_plane.h | 30 +
drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++
drivers/gpu/drm/meson/meson_vclk.c | 167 +++
drivers/gpu/drm/meson/meson_vclk.h | 34 +
drivers/gpu/drm/meson/meson_venc.c | 254 ++++
drivers/gpu/drm/meson/meson_venc.h | 72 +
drivers/gpu/drm/meson/meson_venc_cvbs.c | 293 ++++
drivers/gpu/drm/meson/meson_venc_cvbs.h | 41 +
drivers/gpu/drm/meson/meson_viu.c | 331 +++++
drivers/gpu/drm/meson/meson_viu.h | 64 +
drivers/gpu/drm/meson/meson_vpp.c | 162 +++
drivers/gpu/drm/meson/meson_vpp.h | 35 +
33 files changed, 4078 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/meson/meson-drm.txt
create mode 100644 drivers/gpu/drm/meson/Kconfig
create mode 100644 drivers/gpu/drm/meson/Makefile
create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
create mode 100644 drivers/gpu/drm/meson/meson_drv.c
create mode 100644 drivers/gpu/drm/meson/meson_drv.h
create mode 100644 drivers/gpu/drm/meson/meson_plane.c
create mode 100644 drivers/gpu/drm/meson/meson_plane.h
create mode 100644 drivers/gpu/drm/meson/meson_registers.h
create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
create mode 100644 drivers/gpu/drm/meson/meson_venc.c
create mode 100644 drivers/gpu/drm/meson/meson_venc.h
create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
create mode 100644 drivers/gpu/drm/meson/meson_viu.c
create mode 100644 drivers/gpu/drm/meson/meson_viu.h
create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
create mode 100644 drivers/gpu/drm/meson/meson_vpp.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: airlied, khilman, carlo
Cc: Neil Armstrong, dri-devel, linux-amlogic, linux-arm-kernel,
linux-kernel, victor.wan, jerry.cao, Xing.Xu, devicetree,
laurent.pinchart, daniel
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong@baylibre.com>
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +++++++++++++++++++
.../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
8 files changed, 91 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..a27f881 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -356,5 +356,24 @@
status = "disabled";
};
};
+
+ vpu: vpu@d0100000 {
+ compatible = "amlogic,meson-gx-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port@0 {
+ reg = <0>;
+
+ cvbs_vdac_out: endpoint {
+ };
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..390f7db 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -142,6 +142,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -229,3 +240,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..44bdebf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -125,6 +125,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -234,3 +245,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..5353a20 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -506,3 +506,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..7bd0538 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -117,6 +117,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -203,3 +214,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 9f89b99..5c7a8fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -299,3 +299,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index d320727..5b99749 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -90,6 +90,17 @@
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -167,3 +178,7 @@
max-speed = <1000>;
};
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..eb2f0c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -112,3 +112,7 @@
};
};
};
+
+&vpu {
+ compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, daniel-/w4YWyX8dFk
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../bindings/display/meson/meson-drm.txt | 101 +++++++++++++++++++++
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/meson/meson-drm.txt
diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
new file mode 100644
index 0000000..e52869a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
@@ -0,0 +1,101 @@
+Amlogic Meson Display Controller
+================================
+
+The Amlogic Meson Display controller is composed of several components
+that are going to be documented below:
+
+DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
+ | vd1 _______ _____________ _________________ | |
+D |-------| |----| | | | | HDMI PLL |
+D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
+R |-------| |----| Processing | | | | |
+ | osd2 | | | |---| Enci ----------|----|-----VDAC------|
+R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
+A | osd1 | | | Blenders | | Encl ----------|----|---------------|
+M |-------|______|----|____________| |________________| | |
+___|__________________________________________________________|_______________|
+
+
+VIU: Video Input Unit
+---------------------
+
+The Video Input Unit is in charge of the pixel scanout from the DDR memory.
+It fetches the frames addresses, stride and parameters from the "Canvas" memory.
+This part is also in charge of the CSC (Colorspace Conversion).
+It can handle 2 OSD Planes and 2 Video Planes.
+
+VPP: Video Post Processing
+--------------------------
+
+The Video Post Processing is in charge of the scaling and blending of the
+various planes into a single pixel stream.
+There is a special "pre-blending" used by the video planes with a dedicated
+scaler and a "post-blending" to merge with the OSD Planes.
+The OSD planes also have a dedicated scaler for one of the OSD.
+
+VENC: Video Encoders
+--------------------
+
+The VENC is composed of the multiple pixel encoders :
+ - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
+ - ENCP : Progressive Video Encoder for HDMI
+ - ENCL : LCD LVDS Encoder
+The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
+tree and provides the scanout clock to the VPP and VIU.
+The ENCI is connected to a single VDAC for Composite Output.
+The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
+
+Device Tree Bindings:
+---------------------
+
+VPU: Video Processing Unit
+--------------------------
+
+Required properties:
+- compatible: value should be different for each SoC family as :
+ - GXBB (S905) : "amlogic,meson-gxbb-vpu"
+ - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
+ - GXM (S912) : "amlogic,meson-gxm-vpu"
+ followed by the common "amlogic,meson-gx-vpu"
+- reg: base address and size of he following memory-mapped regions :
+ - vpu
+ - hhi
+ - dmc
+- reg-names: should contain the names of the previous memory regions
+- interrupts: should contain the VENC Vsync interrupt number
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ The first port should be connected to a CVBS connector endpoint if available.
+
+Example:
+
+tv: connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+};
+
+vpu: vpu@d0100000 {
+ compatible = "amlogic,meson-gxbb-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port@0 {
+ cvbs_vdac_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] of: base: Export symbol of __of_find_all_nodes()
From: Laxman Dewangan @ 2016-11-30 15:47 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <581C1D7E.6030608-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Friday 04 November 2016 11:02 AM, Laxman Dewangan wrote:
>
> On Thursday 03 November 2016 07:46 PM, Rob Herring wrote:
>> On Thu, Nov 3, 2016 at 12:24 AM, Laxman Dewangan
>> <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Thursday 03 November 2016 09:09 AM, Rob Herring wrote:
>>>> On Fri, Oct 28, 2016 at 6:28 AM, Laxman Dewangan
>>>> <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>> wrote:
>>>>> The function __of_find_all_nodes() is used in the public header
>>>>> linux/of.h and if any driver developed using this API then
>>>>> it reports error as unknown symbol if compiled as module.
>>>>>
>>>>> Export this APIs using EXPORT_SYMBOL() so that it can be used
>>>>> from driver compiled as module.
>>>> What driver needs this? This isn't really a function I'd expect
>>>> drivers to
>>>> use.
>>>>
>>> I am using the for loop for each node using the macro
>>> for_each_of_allnodes_from() which is define as
>>>
>>> #define for_each_of_allnodes_from(from, dn) \
>>> for (dn = __of_find_all_nodes(from); dn; dn =
>>> __of_find_all_nodes(dn))
>>>
>>> and this is using the above APIs.
>> And then what driver is using this define?
> We are developing the utils/testcase on OF interface echo system. In
> one of the testcase, we want to limit the node and property name
> length to 32 (max) as per ePAPR specs. This is needed to reuse the DT
> in multi-OS environment and so want to maintain ePAPR compliance here.
>
> We are using the above macro for iterating over each node.
>
>
Hi Rob,
Any comment or suggestion?
Thanks,
Laxman
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Thomas Petazzoni @ 2016-11-30 15:49 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin
In-Reply-To: <20161130140017.26307-2-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Wed, 30 Nov 2016 15:00:14 +0100, Romain Perier wrote:
> #ifdef CONFIG_I2C_PXA_SLAVE
> dev_info(&i2c->adap.dev, "Enabling slave mode\n");
> @@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
> i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
> i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
> i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
> + i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? pxa_reg_layout[i2c_type].fm : ICR_FM;
> + i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? pxa_reg_layout[i2c_type].hs : ICR_HS;
These lines are too long according to checkpatch. What about using what
Wolfram originally suggested, i.e:
i2c->fm_mask = pxa_reg_layout[i2c_type].fm ?: ICR_FM;
which does exactly the same, but fits within 80 characters ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:56 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Xing.Xu, victor.wan, khilman, linux-kernel, dri-devel,
jerry.cao, carlo, linux-amlogic, linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
> mode 100644
> index 0000000..e52869a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> @@ -0,0 +1,101 @@
> +Amlogic Meson Display Controller
> +================================
> +
> +The Amlogic Meson Display controller is composed of several components
> +that are going to be documented below:
> +
> +DMC|---------------VPU (Video Processing Unit)------------|------HHI------|
> + | vd1 _______ _____________ _____________ | |
> +D |-------| |----| | | | | HDMI PLL |
> +D | vd2 | VIU | | Video Post | | Video Encs |<---|-----VCLK |
> +R |-------| |----| Processing | | | | |
> + | osd2 | | | |---| Enci ------|----|-----VDAC------|
> +R |-------| CSC |----| Scalers | | Encp ------|----|----HDMI-TX----|
> +A | osd1 | | | Blenders | | Encl-------|----|---------------|
> +M |-------|______|----|____________| |____________| | |
> +___|______________________________________________________|_______________|
> +
> +
> +VIU: Video Input Unit
> +---------------------
> +
> +The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> +It fetches the frames addresses, stride and parameters from the "Canvas"
> memory.
> +This part is also in charge of the CSC (Colorspace Conversion).
> +It can handle 2 OSD Planes and 2 Video Planes.
> +
> +VPP: Video Post Processing
> +--------------------------
> +
> +The Video Post Processing is in charge of the scaling and blending of the
> +various planes into a single pixel stream.
> +There is a special "pre-blending" used by the video planes with a dedicated
> +scaler and a "post-blending" to merge with the OSD Planes.
> +The OSD planes also have a dedicated scaler for one of the OSD.
> +
> +VENC: Video Encoders
> +--------------------
> +
> +The VENC is composed of the multiple pixel encoders :
> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> + - ENCP : Progressive Video Encoder for HDMI
> + - ENCL : LCD LVDS Encoder
> +The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and
> clock
> +tree and provides the scanout clock to the VPP and VIU.
> +The ENCI is connected to a single VDAC for Composite Output.
> +The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> +
> +Device Tree Bindings:
> +---------------------
> +
> +VPU: Video Processing Unit
> +--------------------------
> +
> +Required properties:
> +- compatible: value should be different for each SoC family as :
> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
> + - GXM (S912) : "amlogic,meson-gxm-vpu"
> + followed by the common "amlogic,meson-gx-vpu"
> +- reg: base address and size of he following memory-mapped regions :
> + - vpu
> + - hhi
> + - dmc
> +- reg-names: should contain the names of the previous memory regions
> +- interrupts: should contain the VENC Vsync interrupt number
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + The first port should be connected to a CVBS connector endpoint if
> available.
This is a bit vague, I propose clarifying it with a description similar to the
one in the renesas,du.txt bindings.
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port 0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7792 (V2H) DPAD 0 DPAD 1 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
R8A7796 (M3-W) DPAD HDMI LVDS -
(You should obviously replace the table with Amlogic data)
It doesn't matter if the current driver implementation only supports CVBS, the
DT bindings can already document the other ports.
> +
> +Example:
> +
> +tv: connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
I'd remove the label here, as it doesn't bring any additional information.
Unless the board you're using has a label for the connector, in case that
label should be used.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + port {
> + tv_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> +};
> +
> +vpu: vpu@d0100000 {
> + compatible = "amlogic,meson-gxbb-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port@0 {
> + cvbs_vdac_out: endpoint {
> + reg = <0>;
> + remote-endpoint = <&tv_connector_in>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:58 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Xing.Xu, victor.wan, khilman, linux-kernel, dri-devel,
jerry.cao, carlo, linux-amlogic, linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
I forgot to mention that the file should not be named meson-drm.txt as DRM is
a Linux-specific concept. You can name it meson.txt, but a better option would
be amlogic,meson.txt. By the way does it really need a subdirectory ?
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <2734274.BAOZxRirYz@avalon>
Hi Laurent,
On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>
> I forgot to mention that the file should not be named meson-drm.txt as DRM is
> a Linux-specific concept. You can name it meson.txt, but a better option would
> be amlogic,meson.txt. By the way does it really need a subdirectory ?
I took example of the sun4i layout the naming, and no it does not need a subdirector..
I will move it to amlogic,meson.txt, seems far better.
Thanks,
Neil
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Laurent Pinchart @ 2016-11-30 16:02 UTC (permalink / raw)
To: Neil Armstrong
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <1480520625-13269-3-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
> boards.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
> 8 files changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -356,5 +356,24 @@
> status = "disabled";
> };
> };
> +
> + vpu: vpu@d0100000 {
> + compatible = "amlogic,meson-gx-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port@0 {
> + reg = <0>;
> +
> + cvbs_vdac_out: endpoint {
> + };
Endpoints require a remote-endpoint property. You should move the endpoint to
board DT files.
> + };
> + };
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
> 9696820..390f7db 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -142,6 +142,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
Unless the board has a label for the connector (either on the board, on the
casing or in the user manual) I'd leave this out. Same comment for the other
boards.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -229,3 +240,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
> 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -125,6 +125,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -234,3 +245,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -506,3 +506,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
> e99101a..7bd0538 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -117,6 +117,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -203,3 +214,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -299,3 +299,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
> d320727..5b99749 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -90,6 +90,17 @@
> compatible = "mmc-pwrseq-emmc";
> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -167,3 +178,7 @@
> max-speed = <1000>;
> };
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> @@ -112,3 +112,7 @@
> };
> };
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
> +};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <13104644.f9boR54smD@avalon>
Hi Laurent,
On 11/30/2016 04:56 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>> mode 100644
>> index 0000000..e52869a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> @@ -0,0 +1,101 @@
[...]
>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +VPU: Video Processing Unit
>> +--------------------------
>> +
>> +Required properties:
>> +- compatible: value should be different for each SoC family as :
>> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>> + - GXM (S912) : "amlogic,meson-gxm-vpu"
>> + followed by the common "amlogic,meson-gx-vpu"
>> +- reg: base address and size of he following memory-mapped regions :
>> + - vpu
>> + - hhi
>> + - dmc
>> +- reg-names: should contain the names of the previous memory regions
>> +- interrupts: should contain the VENC Vsync interrupt number
>> +
>> +- ports: A ports node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt.
>> + The first port should be connected to a CVBS connector endpoint if
>> available.
>
> This is a bit vague, I propose clarifying it with a description similar to the
> one in the renesas,du.txt bindings.
>
> Required nodes:
>
> The connections to the VPU output video ports are modeled using the OF graph
> bindings specified in Documentation/devicetree/bindings/graph.txt.
>
> The following table lists for each supported model the port number
> corresponding to each DU output.
>
> Port 0 Port1 Port2 Port3
> -----------------------------------------------------------------------------
> R8A7779 (H1) DPAD 0 DPAD 1 - -
> R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
> R8A7791 (M2-W) DPAD LVDS 0 - -
> R8A7792 (V2H) DPAD 0 DPAD 1 - -
> R8A7793 (M2-N) DPAD LVDS 0 - -
> R8A7794 (E2) DPAD 0 DPAD 1 - -
> R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
> R8A7796 (M3-W) DPAD HDMI LVDS -
>
> (You should obviously replace the table with Amlogic data)
>
> It doesn't matter if the current driver implementation only supports CVBS, the
> DT bindings can already document the other ports.
>
Ok, it's a pretty table ! Will integrate this.
>> +
>> +Example:
>> +
>> +tv: connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> I'd remove the label here, as it doesn't bring any additional information.
> Unless the board you're using has a label for the connector, in case that
> label should be used.
Indeed, I already removed it in the dts.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>
[...]
Thanks for the review,
Neil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 16:07 UTC (permalink / raw)
To: Laurent Pinchart
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <10006210.eA8q2ZWXP0@avalon>
On 11/30/2016 05:02 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
>> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
>> boards.
>>
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
>> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
>> 8 files changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -356,5 +356,24 @@
>> status = "disabled";
>> };
>> };
>> +
>> + vpu: vpu@d0100000 {
>> + compatible = "amlogic,meson-gx-vpu";
>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>> + <0x0 0xc883c000 0x0 0x1000>,
>> + <0x0 0xc8838000 0x0 0x1000>;
>> + reg-names = "vpu", "hhi", "dmc";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* CVBS VDAC output port */
>> + port@0 {
>> + reg = <0>;
>> +
>> + cvbs_vdac_out: endpoint {
>> + };
>
> Endpoints require a remote-endpoint property. You should move the endpoint to
> board DT files.
OK, I was wondering, it looked dirty to me.
>
>> + };
>> + };
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
>> 9696820..390f7db 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -142,6 +142,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> Unless the board has a label for the connector (either on the board, on the
> casing or in the user manual) I'd leave this out. Same comment for the other
> boards.
OK,
Thanks,
Neil
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -229,3 +240,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
>> 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -125,6 +125,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -234,3 +245,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> @@ -506,3 +506,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
>> e99101a..7bd0538 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> @@ -117,6 +117,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -203,3 +214,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> @@ -299,3 +299,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
>> d320727..5b99749 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> @@ -90,6 +90,17 @@
>> compatible = "mmc-pwrseq-emmc";
>> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -167,3 +178,7 @@
>> max-speed = <1000>;
>> };
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> @@ -112,3 +112,7 @@
>> };
>> };
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
>> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
From: Mark Brown @ 2016-11-30 16:14 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: devicetree, linux-arm-msm, dri-devel
In-Reply-To: <1557992.zAjuUn6zCK@avalon>
[-- Attachment #1.1: Type: text/plain, Size: 1006 bytes --]
On Tue, Nov 29, 2016 at 09:37:31PM +0200, Laurent Pinchart wrote:
> On Tuesday 29 Nov 2016 11:01:25 Mark Brown wrote:
> > Please note that if you're going to CC me into a graphics thread there's
> > a good chance I will miss it, I get copied on quite a lot of graphics
> > related mail that's not really relevant so I often skip it. Changing
> > the subject line would help with that.
> I try to add a (CC'ing xxx) at the beginning of the e-mail to draw attention
> when a question is targetted at a particular person. If that's not enough I
> can change the subject, but might forget to do so from time to time. Or you
> could whitelist me, unless I'm already blacklisted ;-)
That helps if I open the mail (especially with large e-mails, I do
sometimes get bored looking for something relevant) but I also filter
just on subject lines - once you've been involved with a thread about a
topic people often seem to end up copying you for anything even vaguely
related unfortunately.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-30 16:18 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits
In-Reply-To: <e5c36597-d917-0555-89cd-35f68087c1c5@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 188 bytes --]
> What do you prefer everything in one commit or two seperated commit ? (one
> including the new fields for fm_mask and another one to add support for
> a3700-i2c).
One commit is fine!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox