[PATCH] net/macb: Update DT bindings documentation
Add missing "cdns,at91sam9260-macb", "atmel,sama5d3-gem" and
"atmel,sama5d4-gem" compatible strings.
Signed-off-by: Boris Brezillon
Reviewed-by: Alexandre Belloni
Acked-by: Nicolas Ferre
---
Documentation/devicetree/bindings/net/macb.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index aaa6964..ba19d67 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -2,10 +2,13 @@
Required properties:
- compatible: Should be "cdns,[-]{macb|gem}"
- Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
+ Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
+ available on sama5d3 SoCs.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form:
"cdns,macb".
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
+ Use "cdns,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs.
+ Use "cdns,sama5d4-gem" for the Gigabit IP available on Atmel sama5d4 SoCs.
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- phy-mode: See ethernet.txt file in the same directory.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] net/macb: merge at91_ether driver into macb driver
Hello Dave, On Fri, 06 Mar 2015 15:18:30 -0500 (EST) David Miller wrote: > From: Boris Brezillon > Date: Fri, 6 Mar 2015 11:48:39 +0100 > > > Changes since v2: > > - rebase after changed brought by [1] > > Ugh, actually I'm tossing all of your changes. Please do not make > complex dependencies like this. Okay, I'll remember that next time I submit patches to netdev. I've sent a new series integrating the patch this series depends on. Let me know if there's something wrong in this one. > > And furthermore, don't reference other sets of changes via lkml > postings. Reference them by where they are in patchwork which is > the definitive location for networking patch submissions. Noted. Best Regards, Boris -- Boris Brezillon, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] net: macb: remove #if defined(CONFIG_ARCH_AT91) sections
With multi platform support those sections could lead to unexpected
behavior if both ARCH_AT91 and another ARM SoC using the MACB IP are
selected.
Add two new capabilities to encode the default MII mode and the presence
of a CLKEN bit in USRIO register.
Then define the appropriate config for IPs embedded in at91 SoCs.
Signed-off-by: Boris Brezillon
Reviewed-by: Alexandre Belloni
---
drivers/net/ethernet/cadence/macb.c | 32 +---
drivers/net/ethernet/cadence/macb.h | 2 ++
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index ad76b8e..86e915f 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2113,6 +2113,10 @@ static const struct net_device_ops macb_netdev_ops = {
};
#if defined(CONFIG_OF)
+static struct macb_config at91sam9260_config = {
+ .caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII,
+};
+
static struct macb_config pc302gem_config = {
.caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE,
.dma_burst_length = 16,
@@ -2130,7 +2134,7 @@ static struct macb_config sama5d4_config = {
static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,at32ap7000-macb" },
- { .compatible = "cdns,at91sam9260-macb" },
+ { .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
{ .compatible = "cdns,macb" },
{ .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
{ .compatible = "cdns,gem", .data = &pc302gem_config },
@@ -2388,21 +2392,19 @@ static int macb_probe(struct platform_device *pdev)
bp->phy_interface = err;
}
+ config = 0;
if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
- macb_or_gem_writel(bp, USRIO, GEM_BIT(RGMII));
- else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII)
-#if defined(CONFIG_ARCH_AT91)
- macb_or_gem_writel(bp, USRIO, (MACB_BIT(RMII) |
- MACB_BIT(CLKEN)));
-#else
- macb_or_gem_writel(bp, USRIO, 0);
-#endif
- else
-#if defined(CONFIG_ARCH_AT91)
- macb_or_gem_writel(bp, USRIO, MACB_BIT(CLKEN));
-#else
- macb_or_gem_writel(bp, USRIO, MACB_BIT(MII));
-#endif
+ config = GEM_BIT(RGMII);
+ else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
+(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ config = MACB_BIT(RMII);
+ else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ config = MACB_BIT(MII);
+
+ if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
+ config |= MACB_BIT(CLKEN);
+
+ macb_or_gem_writel(bp, USRIO, config);
err = register_netdev(dev);
if (err) {
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 31dc080..efe0247 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -389,6 +389,8 @@
/* Capability mask bits */
#define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x0001
+#define MACB_CAPS_USRIO_HAS_CLKEN 0x0002
+#define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x0004
#define MACB_CAPS_FIFO_MODE0x1000
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
#define MACB_CAPS_SG_DISABLED 0x4000
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] ARM: at91/dt: fix macb compatible strings
Some at91 SoCs embed a 10/100 Mbit Ethernet IP, that is based on the
at91sam9260 SoC.
Fix at91 DTs accordingly.
Signed-off-by: Boris Brezillon
Reviewed-by: Alexandre Belloni
---
arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5_macb0.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5_macb1.dtsi | 2 +-
arch/arm/boot/dts/sama5d3_emac.dtsi | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index fff0ee6..9f7c737 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -842,7 +842,7 @@
};
macb0: ethernet@fffc4000 {
- compatible = "cdns,at32ap7000-macb",
"cdns,macb";
+ compatible = "cdns,at91sam9260-macb",
"cdns,macb";
reg = <0xfffc4000 0x100>;
interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 1f67bb4..340179e 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -845,7 +845,7 @@
};
macb0: ethernet@fffbc000 {
- compatible = "cdns,at32ap7000-macb",
"cdns,macb";
+ compatible = "cdns,at91sam9260-macb",
"cdns,macb";
reg = <0xfffbc000 0x100>;
interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index ee80aa9..586eab7 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -956,7 +956,7 @@
};
macb0: ethernet@fffbc000 {
- compatible = "cdns,at32ap7000-macb",
"cdns,macb";
+ compatible = "cdns,at91sam9260-macb",
"cdns,macb";
reg = <0xfffbc000 0x100>;
interrupts = <25 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
b/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
index 57e89d1..73d7e30 100644
--- a/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
@@ -53,7 +53,7 @@
};
macb0: ethernet@f802c000 {
- compatible = "cdns,at32ap7000-macb",
"cdns,macb";
+ compatible = "cdns,at91sam9260-macb",
"cdns,macb";
reg = <0xf802c000 0x100>;
interrupts = <24 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
b/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
index 663676c..d81980c 100644
--- a/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
@@ -41,7 +41,7 @@
};
macb1: ethernet@f803 {
- compatible = "cdns,at32ap7000-macb",
"cdns,macb";
+ compatible = "cdns,at91sam9260-macb",
"cdns,macb";
reg = <0xf803 0x100>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/sama5d3_emac.dtsi
b/arch/arm/boot/dts/sama5d3_emac.dtsi
index fe2af92..b4544cf 100644
--- a/arch/arm/boot/dts/sama5d3_emac.dtsi
+++ b/arch/arm/boot/dts/sama5d3_emac.dtsi
@@ -41,7 +41,7 @@
};
macb1: ethernet@f802c000 {
- compatible = "cdns,at32ap7000-macb",
"cdns,macb";
+ compatible = "cdns,at91sam9260-macb",
"cdns,macb";
reg = <0xf802c000 0x100>;
interrupts = <35 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] net/macb: merge at91_ether driver into macb driver
From: Cyrille Pitchen
macb and at91_ether drivers can be compiled as modules, but the at91_ether
driver use some functions and variables defined in the macb one, thus
creating a dependency on the macb driver.
Since these drivers are sharing the same logic we can easily merge
at91_ether into macb.
In order to factorize common probing logic we've added an ->init() function
to struct macb_config (the structure associated with the compatible
string), and moved macb specific init code from macb_probe to macb_init.
Signed-off-by: Cyrille Pitchen
Signed-off-by: Boris Brezillon
Tested-by: Alexandre Belloni
---
drivers/net/ethernet/cadence/Kconfig | 8 -
drivers/net/ethernet/cadence/Makefile | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 481 --
drivers/net/ethernet/cadence/macb.c | 639 ++
drivers/net/ethernet/cadence/macb.h | 10 +-
5 files changed, 484 insertions(+), 655 deletions(-)
delete mode 100644 drivers/net/ethernet/cadence/at91_ether.c
diff --git a/drivers/net/ethernet/cadence/Kconfig
b/drivers/net/ethernet/cadence/Kconfig
index 321d2ad..fb8d09b 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -20,14 +20,6 @@ config NET_CADENCE
if NET_CADENCE
-config ARM_AT91_ETHER
- tristate "AT91RM9200 Ethernet support"
- depends on HAS_DMA && (ARCH_AT91 || COMPILE_TEST)
- select MACB
- ---help---
- If you wish to compile a kernel for the AT91RM9200 and enable
- ethernet support, then you should always answer Y to this.
-
config MACB
tristate "Cadence MACB/GEM support"
depends on HAS_DMA && (PLATFORM_AT32AP || ARCH_AT91 || ARCH_PICOXCELL
|| ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST)
diff --git a/drivers/net/ethernet/cadence/Makefile
b/drivers/net/ethernet/cadence/Makefile
index 9068b83..91f79b1 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,5 +2,4 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_MACB) += macb.o
diff --git a/drivers/net/ethernet/cadence/at91_ether.c
b/drivers/net/ethernet/cadence/at91_ether.c
deleted file mode 100644
index 7ef55f5..000
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ /dev/null
@@ -1,481 +0,0 @@
-/*
- * Ethernet driver for the Atmel AT91RM9200 (Thunder)
- *
- * Copyright (C) 2003 SAN People (Pty) Ltd
- *
- * Based on an earlier Atmel EMAC macrocell driver by Atmel and Lineo Inc.
- * Initial version by Rick Bronson 01/11/2003
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "macb.h"
-
-/* 1518 rounded up */
-#define MAX_RBUFF_SZ 0x600
-/* max number of receive buffers */
-#define MAX_RX_DESCR 9
-
-/* Initialize and start the Receiver and Transmit subsystems */
-static int at91ether_start(struct net_device *dev)
-{
- struct macb *lp = netdev_priv(dev);
- dma_addr_t addr;
- u32 ctl;
- int i;
-
- lp->rx_ring = dma_alloc_coherent(&lp->pdev->dev,
-(MAX_RX_DESCR *
- sizeof(struct macb_dma_desc)),
-&lp->rx_ring_dma, GFP_KERNEL);
- if (!lp->rx_ring)
- return -ENOMEM;
-
- lp->rx_buffers = dma_alloc_coherent(&lp->pdev->dev,
- MAX_RX_DESCR * MAX_RBUFF_SZ,
- &lp->rx_buffers_dma, GFP_KERNEL);
- if (!lp->rx_buffers) {
- dma_free_coherent(&lp->pdev->dev,
- MAX_RX_DESCR * sizeof(struct macb_dma_desc),
- lp->rx_ring, lp->rx_ring_dma);
- lp->rx_ring = NULL;
- return -ENOMEM;
- }
-
- addr = lp->rx_buffers_dma;
- for (i = 0; i < MAX_RX_DESCR; i++) {
- lp->rx_ring[i].addr = addr;
- lp->rx_ring[i].ctrl = 0;
- addr += MAX_RBUFF_SZ;
- }
-
- /* Set the Wrap bit on the last descriptor */
- lp->rx_ring[MAX_RX_DESCR - 1].addr |= MACB_BIT(RX_WRAP);
-
- /* Reset buffer index */
- lp->rx_tail = 0;
-
- /* Program address of descriptor list in Rx Buffer Queue register */
- macb_writel(lp, RBQP, lp->rx_ring_dma);
-
- /* Enable Receive and Transmit */
- ctl = macb_readl(lp, NCR);
- macb_writel(lp, NCR, ctl | MACB_BIT(RE) | MACB_BIT(TE));
-
- return 0;
-}
-
-/* Open the ethernet interface */
-stati
[PATCH v4 3/4] net/macb: unify clock management
From: Cyrille Pitchen
Most of the functions from the Common Clk Framework handle NULL pointer as
input argument.
Since the TX clock is optional, we now set tx_clk to NULL value
instead of ERR_PTR(-ENOENT) when this clock is not available. This simplifies
the clock management and avoid the need to test tx_clk value.
Signed-off-by: Cyrille Pitchen
Acked-by: Boris Brezillon
Acked-by: Alexandre Belloni
---
drivers/net/ethernet/cadence/macb.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 86e915f..d8748c5 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -213,6 +213,9 @@ static void macb_set_tx_clk(struct clk *clk, int speed,
struct net_device *dev)
{
long ferr, rate, rate_rounded;
+ if (!clk)
+ return;
+
switch (speed) {
case SPEED_10:
rate = 250;
@@ -292,8 +295,7 @@ static void macb_handle_link_change(struct net_device *dev)
spin_unlock_irqrestore(&bp->lock, flags);
- if (!IS_ERR(bp->tx_clk))
- macb_set_tx_clk(bp->tx_clk, phydev->speed, dev);
+ macb_set_tx_clk(bp->tx_clk, phydev->speed, dev);
if (status_change) {
if (phydev->link) {
@@ -2244,6 +2246,8 @@ static int macb_probe(struct platform_device *pdev)
}
tx_clk = devm_clk_get(&pdev->dev, "tx_clk");
+ if (IS_ERR(tx_clk))
+ tx_clk = NULL;
err = clk_prepare_enable(pclk);
if (err) {
@@ -2257,13 +2261,10 @@ static int macb_probe(struct platform_device *pdev)
goto err_out_disable_pclk;
}
- if (!IS_ERR(tx_clk)) {
- err = clk_prepare_enable(tx_clk);
- if (err) {
- dev_err(&pdev->dev, "failed to enable tx_clk (%u)\n",
- err);
- goto err_out_disable_hclk;
- }
+ err = clk_prepare_enable(tx_clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable tx_clk (%u)\n", err);
+ goto err_out_disable_hclk;
}
err = -ENOMEM;
@@ -2435,8 +2436,7 @@ err_out_unregister_netdev:
err_out_free_netdev:
free_netdev(dev);
err_out_disable_clocks:
- if (!IS_ERR(tx_clk))
- clk_disable_unprepare(tx_clk);
+ clk_disable_unprepare(tx_clk);
err_out_disable_hclk:
clk_disable_unprepare(hclk);
err_out_disable_pclk:
@@ -2460,8 +2460,7 @@ static int macb_remove(struct platform_device *pdev)
kfree(bp->mii_bus->irq);
mdiobus_free(bp->mii_bus);
unregister_netdev(dev);
- if (!IS_ERR(bp->tx_clk))
- clk_disable_unprepare(bp->tx_clk);
+ clk_disable_unprepare(bp->tx_clk);
clk_disable_unprepare(bp->hclk);
clk_disable_unprepare(bp->pclk);
free_netdev(dev);
@@ -2479,8 +2478,7 @@ static int __maybe_unused macb_suspend(struct device *dev)
netif_carrier_off(netdev);
netif_device_detach(netdev);
- if (!IS_ERR(bp->tx_clk))
- clk_disable_unprepare(bp->tx_clk);
+ clk_disable_unprepare(bp->tx_clk);
clk_disable_unprepare(bp->hclk);
clk_disable_unprepare(bp->pclk);
@@ -2495,8 +2493,7 @@ static int __maybe_unused macb_resume(struct device *dev)
clk_prepare_enable(bp->pclk);
clk_prepare_enable(bp->hclk);
- if (!IS_ERR(bp->tx_clk))
- clk_prepare_enable(bp->tx_clk);
+ clk_prepare_enable(bp->tx_clk);
netif_device_attach(netdev);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] net/macb: merge at91_ether driver into macb driver
Hello, The rm9200 boards use the dedicated at91_ether driver instead of the regular macb driver. Both the macb and at91_ether drivers can be compiled as separated modules. Since the at91_ether driver uses code from the macb driver, at91_ether.ko depends on macb.ko. However the macb.ko module always fails to load on rm9200 boards: the macb_probe() function expects a hclk clock which doesn't exist on rm9200. Then the at91_ether.ko can't be loaded in turn due to unresolved dependencies. This series of patches fix this issue by merging at91_ether into macb. Patch 1 is fixing a problem that might happen when enabling ARM multi-platform suppot. Best Regards, Boris Changes since v3: - move "net: macb: remove #if defined(CONFIG_ARCH_AT91) sections" patch into this series to avoid dependency on other patch series. Changes since v2: - rebase after changed brought by commit "net: macb: remove #if defined(CONFIG_ARCH_AT91) sections" Changes since v1: - rework probe functions to share common probing logic Boris Brezillon (2): ARM: at91/dt: fix macb compatible strings net: macb: remove #if defined(CONFIG_ARCH_AT91) sections Cyrille Pitchen (2): net/macb: unify clock management net/macb: merge at91_ether driver into macb driver arch/arm/boot/dts/at91sam9260.dtsi| 2 +- arch/arm/boot/dts/at91sam9263.dtsi| 2 +- arch/arm/boot/dts/at91sam9g45.dtsi| 2 +- arch/arm/boot/dts/at91sam9x5_macb0.dtsi | 2 +- arch/arm/boot/dts/at91sam9x5_macb1.dtsi | 2 +- arch/arm/boot/dts/sama5d3_emac.dtsi | 2 +- drivers/net/ethernet/cadence/Kconfig | 8 - drivers/net/ethernet/cadence/Makefile | 1 - drivers/net/ethernet/cadence/at91_ether.c | 481 -- drivers/net/ethernet/cadence/macb.c | 662 ++ drivers/net/ethernet/cadence/macb.h | 12 +- 11 files changed, 503 insertions(+), 673 deletions(-) delete mode 100644 drivers/net/ethernet/cadence/at91_ether.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt/bindings: control CS via standard GPIO operations instead of SPI-HW
On 03/04/2015 09:40 AM, ker...@martin.sperl.org wrote:
> From: Martin Sperl
>
> Change the device tree to use cs-gpios for the spi bus master
> and standard gpio operation instead of relying on the HW with
> just 2 chip_selects using ALT0.
>
> This reassigns the existing CS pins 7(=CS1) and 8(=CS0)
> as output instead of ALT0 (=SPI HW block controlled)
> and adds them in the list of cs-gpios for the spi-bus.
These pins aren't used by anything on the board, but are rather part of
the expansion header. I wonder if we wouldn't be better off removing any
configuration of the pins from the DT. After all, we can't guarantee how
the user has connected them. The "default" usage, a/k/a the expansion
header signal naming, isn't any guarantee.
Rather, the user should specify what they want to use the pin as; as a
GPIO input, GPIO output, or an SPI chip-select.
> diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
> b/arch/arm/boot/dts/bcm2835-rpi.dtsi
> gpioout: gpioout {
> - brcm,pins = <6>;
> + brcm,pins = <6 7 8>;
> brcm,function = <1>; /* GPIO out */
> };
>
> alt0: alt0 {
> - brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
> + brcm,pins = <0 1 2 3 4 5 9 10 11 14 15 40 45>;
> brcm,function = <4>; /* alt0 */
> };
While the existing DT already has this issue, note that this forces
these pins to be driven as outputs. What if the user has hooked up an
external device that drives these signals, and wants to use the pins as
GPIO inputs?
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> #address-cells = <1>;
> #size-cells = <0>;
> status = "disabled";
> + cs-gpios = <&gpio 8 0>, <&gpio 7 0>;
> };
This shouldn't be in the SoC .dtsi file. It's quite possible for someone
to use other GPIOs as SPI CS. It's board or even use-case specific
whether those are the correct values.
I would argue that we should not put any cs-gpios into any in-kernel DT
file, since there's no on-board usage of SPI on the RPi boards.
For SPI to be useful, the user has to add a DT node to represent the SPI
device itself anyway, so adding some properties to the controller to
define which GPIOs to use for SPI CS can be done then too.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] SPI: control CS via standard GPIO operations instead of SPI-HW
On 03/04/2015 09:40 AM, ker...@martin.sperl.org wrote:
> From: Martin Sperl
>
> Allow the cs-gpios property in DT to be used instead of the
> fixed two chip-selects provided by the SPI-HW itself
>
> Signed-off-by: Martin Sperl
>
> ---
>
> There is the question if we still need to support the chip_selects
> provided by the hardware (plus the buggy CSPOL_HIGH support for those cases)
> or if we could just make the cs-gpios a required setting for this driver.
> Going with the GPIO only solution would clean up the code a bit.
Yes, I believe so. Any existing DT file needs to continue working with a
new kernel; DT is an ABI.
BTW, you forgot to Cc the SPI maintainer, so he probably won't see your
patch and apply it.
I assume that the SPI core parses the cs-gpios property from DT, hence
why this patch doesn't add any DT parsing, and doesn't modify any DT
bindings?
> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
> @@ -205,12 +219,24 @@ static int bcm2835_spi_start_transfer(struct spi_device
> *spi,
> cs |= BCM2835_SPI_CS_CPHA;
>
> if (!(spi->mode & SPI_NO_CS)) {
> - if (spi->mode & SPI_CS_HIGH) {
> - cs |= BCM2835_SPI_CS_CSPOL;
> - cs |= BCM2835_SPI_CS_CSPOL0 << spi->chip_select;
> - }
> + if (spi->cs_gpio >= 0)
> + bcm2835_set_cs(spi, 1);
> + else {
> + /* do we need to support this ?
As mentioned above, yes I believe so. You'd need to amend this comment
to remove the question, I suspect.
This patch looks OK with that change made.
> + * note that there is a bug in this when there are
> + * multiple devices on the bus with at least one
> + * having SPI_CS_HIGH set (the other CS_CSPOLX get
> + * reset to 0 when any other device
> + * starts a transfer
> + */
> + if (spi->mode & SPI_CS_HIGH) {
> + cs |= BCM2835_SPI_CS_CSPOL;
> + cs |= BCM2835_SPI_CS_CSPOL0
> + << spi->chip_select;
> + }
>
> - cs |= spi->chip_select;
> + cs |= spi->chip_select;
> + }
> }
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller
This core originated in Set-Top Box chips (BCM7xxx) but is used in a
variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and
iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it
to those architectures.
There are multiple revisions of this core throughout the years, and
almost every version broke register compatibility in some small way, but
with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0,
and v7.1. It's been tested on v5.0, v6.0, v7.0, and v7.1 recently, so
there hopefully are no more lurking inconsistencies.
Signed-off-by: Brian Norris
---
drivers/mtd/nand/Kconfig|8 +
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/brcmstb_nand.c | 2182 +++
3 files changed, 2191 insertions(+)
create mode 100644 drivers/mtd/nand/brcmstb_nand.c
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b76a173cd95..6445323a8cff 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -394,6 +394,14 @@ config MTD_NAND_GPMI_NAND
block, such as SD card. So pay attention to it when you enable
the GPMI.
+config MTD_NAND_BRCMSTB
+ tristate "Broadcom STB NAND controller"
+ depends on ARM || MIPS
+ help
+ Enables the Broadcom NAND controller driver. The controller was
+ originally designed for Set-Top Box but is used on various BCM7xxx,
+ BCM3xxx, BCM63xxx, iProc/Cygnus and more.
+
config MTD_NAND_BCM47XXNFLASH
tristate "Support for NAND flash on BCM4706 BCMA bus"
depends on BCMA_NFLASH
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 582bbd05aff7..3b1adddc83dd 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o
obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/
obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o
obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMSTB) += brcmstb_nand.o
nand-objs := nand_base.o nand_bbt.o nand_timings.o
diff --git a/drivers/mtd/nand/brcmstb_nand.c b/drivers/mtd/nand/brcmstb_nand.c
new file mode 100644
index ..4d74f7a17dc3
--- /dev/null
+++ b/drivers/mtd/nand/brcmstb_nand.c
@@ -0,0 +1,2182 @@
+/*
+ * Copyright © 2010-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This flag controls if WP stays on between erase/write commands to mitigate
+ * flash corruption due to power glitches. Values:
+ * 0: NAND_WP is not used or not available
+ * 1: NAND_WP is set by default, cleared for erase/write operations
+ * 2: NAND_WP is always cleared
+ */
+static int wp_on = 1;
+module_param(wp_on, int, 0444);
+
+/***
+ * Definitions
+ ***/
+
+#define DRV_NAME "brcmstb_nand"
+
+#define CMD_NULL 0x00
+#define CMD_PAGE_READ 0x01
+#define CMD_SPARE_AREA_READ0x02
+#define CMD_STATUS_READ0x03
+#define CMD_PROGRAM_PAGE 0x04
+#define CMD_PROGRAM_SPARE_AREA 0x05
+#define CMD_COPY_BACK 0x06
+#define CMD_DEVICE_ID_READ 0x07
+#define CMD_BLOCK_ERASE0x08
+#define CMD_FLASH_RESET0x09
+#define CMD_BLOCKS_LOCK0x0a
+#define CMD_BLOCKS_LOCK_DOWN 0x0b
+#define CMD_BLOCKS_UNLOCK 0x0c
+#define CMD_READ_BLOCKS_LOCK_STATUS0x0d
+#define CMD_PARAMETER_READ 0x0e
+#define CMD_PARAMETER_CHANGE_COL 0x0f
+#define CMD_LOW_LEVEL_OP 0x10
+
+struct brcm_nand_dma_desc {
+ u32 next_desc;
+ u32 next_desc_ext;
+ u32 cmd_irq;
+ u32 dram_addr;
+ u32 dram_addr_ext;
+ u32 tfr_len;
+ u32 total_len;
+ u32 flash_addr;
+ u32 flash_addr_ext;
+ u32 cs;
+ u32 pad2[5];
+ u32 status_valid;
+} __packed;
+
+/* Bitfields for brcm_nand_dma_desc::status_valid */
+#define FLASH_DMA_ECC_ERROR(1 << 8)
+#define FLASH_DMA_CORR_ERROR (1 << 9)
+
+/* 512B flash cache in the NAND controller
[PATCH 1/3] mtd: nand: add common DT init code
These are already-documented common bindings for NAND chips. Let's
handle them in nand_base.
If NAND controller drivers need to act on this data before bringing up
the NAND chip (e.g., fill out ECC callback functions, change HW modes,
etc.), then they can do so between calling nand_scan_ident() and
nand_scan_tail().
Signed-off-by: Brian Norris
---
drivers/mtd/nand/nand_base.c | 41 +
include/linux/mtd/nand.h | 5 +
2 files changed, 46 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index df7eb4ff07d1..271866b038b3 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
/* Define default oob placement schemes for large and small page devices */
static struct nand_ecclayout nand_oob_8 = {
@@ -3779,6 +3780,39 @@ ident_done:
return type;
}
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip,
+ struct device_node *dn)
+{
+ int ecc_mode, ecc_strength, ecc_step;
+
+ if (of_get_nand_bus_width(dn) == 16)
+ chip->options |= NAND_BUSWIDTH_16;
+
+ if (of_get_nand_on_flash_bbt(dn))
+ chip->bbt_options |= NAND_BBT_USE_FLASH;
+
+ ecc_mode = of_get_nand_ecc_mode(dn);
+ ecc_strength = of_get_nand_ecc_strength(dn);
+ ecc_step = of_get_nand_ecc_step_size(dn);
+
+ if ((ecc_step >= 0 && !(ecc_strength >= 0)) ||
+ (!(ecc_step >= 0) && ecc_strength >= 0)) {
+ pr_err("must set both strength and step size in DT\n");
+ return -EINVAL;
+ }
+
+ if (ecc_mode >= 0)
+ chip->ecc.mode = ecc_mode;
+
+ if (ecc_strength >= 0)
+ chip->ecc.strength = ecc_strength;
+
+ if (ecc_step > 0)
+ chip->ecc.size = ecc_step;
+
+ return 0;
+}
+
/**
* nand_scan_ident - [NAND Interface] Scan for the NAND device
* @mtd: MTD device structure
@@ -3796,6 +3830,13 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
int i, nand_maf_id, nand_dev_id;
struct nand_chip *chip = mtd->priv;
struct nand_flash_dev *type;
+ int ret;
+
+ if (chip->dn) {
+ ret = nand_dt_init(mtd, chip, chip->dn);
+ if (ret)
+ return ret;
+ }
/* Set the default functions */
nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 3d4ea7eb2b68..e0f40e12a2c8 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -26,6 +26,8 @@
struct mtd_info;
struct nand_flash_dev;
+struct device_node;
+
/* Scan and identify a NAND device */
extern int nand_scan(struct mtd_info *mtd, int max_chips);
/*
@@ -542,6 +544,7 @@ struct nand_buffers {
* flash device
* @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
* flash device.
+ * @dn:[BOARDSPECIFIC] device node describing this
instance
* @read_byte: [REPLACEABLE] read one byte from the chip
* @read_word: [REPLACEABLE] read one word from the chip
* @write_byte:[REPLACEABLE] write a single byte to the chip
on the
@@ -644,6 +647,8 @@ struct nand_chip {
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
+ struct device_node *dn;
+
uint8_t (*read_byte)(struct mtd_info *mtd);
u16 (*read_word)(struct mtd_info *mtd);
void (*write_byte)(struct mtd_info *mtd, uint8_t byte);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] mtd: nand: add Broadcom NAND controller support
Hi, This adds (long in coming) support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs. There are a few more features I'd like add in the near future, mostly to support more SoCs, but this is the base set, which should only need relatively minor additions to support chips like BCM63138, BCM3384, and Cygnus/iProc. Particularly, we may need to straighten out some endianness issues for the data path on iProc, and interrupt enabling/acking on iProc, BCM63xxx, BCM3xxx, and others. TODO: add this to the DTS(I) files for BCM7445. Happy reviewing! (Speaking of which, I need to catch up on reviewing everybody else's MTD submissions...) Brian Brian Norris (3): mtd: nand: add common DT init code Documentation: devicetree: add binding doc for Broadcom NAND controller mtd: nand: add NAND driver for Broadcom STB NAND controller .../devicetree/bindings/mtd/brcmstb_nand.txt | 109 + drivers/mtd/nand/Kconfig |8 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/brcmstb_nand.c| 2182 drivers/mtd/nand/nand_base.c | 41 + include/linux/mtd/nand.h |5 + 6 files changed, 2346 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt create mode 100644 drivers/mtd/nand/brcmstb_nand.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
Signed-off-by: Brian Norris
---
.../devicetree/bindings/mtd/brcmstb_nand.txt | 109 +
1 file changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
new file mode 100644
index ..933d44943cbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
@@ -0,0 +1,109 @@
+* Broadcom STB NAND Controller
+
+The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND
+flash chips. It has a memory-mapped register interface for both control
+registers and for its data input/output buffer. On some SoCs, this controller
is
+paired with a custom DMA engine (inventively named "Flash DMA") which supports
+basic PROGRAM and READ functions, among other features.
+
+This controller was originally designed for STB SoCs (BCM7xxx) but is now
+available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and
+iProc/Cygnus. Its history includes several similar (but not fully register
+compatible) versions.
+
+Required properties:
+- compatible : should contain "brcm,brcmnand" and an appropriate version
+ compatibility string, like "brcm,brcmnand-v7.0"
+ Possible values:
+ brcm,brcmnand-v4.0
+ brcm,brcmnand-v5.0
+ brcm,brcmnand-v6.0
+ brcm,brcmnand-v7.0
+ brcm,brcmnand-v7.1
+ brcm,brcmnand
+- reg : the register start and length for NAND register region.
+ (optional) Flash DMA register range (if present)
+ (optional) NAND flash cache range (if at non-standard
offset)
+- reg-names: a list of the names corresponding to the previous register
+ ranges. Should contain "nand" and (optionally)
+ "flash-dma" and/or "nand-cache".
+- interrupts : The NAND CTLRDY interrupt and (if Flash DMA is available)
+ FLASH_DMA_DONE
+- interrupt-names : May be "nand_ctlrdy" or "flash_dma_done"
+- interrupt-parent : See standard interrupt bindings
+- #address-cells : <1> - subnodes give the chip-select number
+- #size-cells : <0>
+
+Optional properties:
+- brcm,nand-has-wp : Some versions of this IP include a write-protect
+ (WP) control bit. It is always available on >=
+ v7.0. Use this property to describe the rare
+ earlier versions of this core that include WP
+
+* NAND chip-select
+
+Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes
+to represent enabled chip-selects which (may) contain NAND flash chips. Their
+properties are as follows.
+
+Required properties:
+- compatible: should contain "brcm,nandcs"
+- reg : a single integer representing the chip-select
+ number (e.g., 0, 1, 2, etc.)
+- #address-cells: see partition.txt
+- #size-cells : see partition.txt
+- nand-ecc-strength : see nand.txt
+- nand-ecc-step-size: must be 512 or 1024. See nand.txt
+
+Optional properties:
+- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this
+ chip-select. See nand.txt
+- brcm,nand-oob-sector-size : integer, to denote the spare area sector size
+ expected for the ECC layout in use. This size, in
+ addition to the strength and step-size,
+ determines how the hardware BCH engine will lay
+ out the parity bytes it stores on the flash.
+ This property can be automatically determined by
+ the flash geometry (particularly the NAND page
+ and OOB size) in many cases, but when booting
+ from NAND, the boot controller has only a limited
+ number of available options for its default ECC
+ layout.
+
+Each nandcs device node may optionally contain sub-nodes describing the flash
+partition mapping. See partition.txt for more detail.
+
+Example:
+
+nand@f0442800 {
+ compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand";
+ reg = <0xF0442800 0x600>,
+ <0xF0443000 0x100>;
+ reg-names = "nand", "flash-dma";
+ interrupt-parent = <&hif_intr2_intc>;
+ interrupts = <24>, <4>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nandcs@1 {
+ compatible = "brcm,nandcs";
+ reg = <1>; // Chip select 1
+ nand-on-flash-bbt;
+ nand-ecc-stren
Re: [PATCH 0/2] ARM: shmobile: ape6evm: Fix GPIO keys and wake-up
On Fri, Mar 06, 2015 at 01:33:05PM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Friday 06 March 2015 20:30:29 Simon Horman wrote: > > On Thu, Mar 05, 2015 at 12:42:07PM +0200, Laurent Pinchart wrote: > > > On Thursday 05 March 2015 09:34:33 Simon Horman wrote: > > >> On Fri, Feb 27, 2015 at 06:48:37PM +0100, Geert Uytterhoeven wrote: > > >>> Hi Simon, Magnus, > > >>> > > >>> This patch series adds the missing pull-up bias configuration for the > > >>> switches on the r8a73a4/ape6evm development board, and configures the > > >>> custom switch as a wake-up source. > > >>> > > >>> After this, the keys actually work, and the system can be resumed from > > >>> s2ram by pressing the custom switch. > > >>> > > >>> This depends functionally on "[PATCH 1/4] pinctrl: sh-pfc: Do not > > >>> overwrite bias configuration" in the series "[PATCH 0/4] pinctrl: > > >>> sh-pfc: Fix pin bias and cleanups" which I've just sent. But as this > > >>> is DTS, it can be applied independently. > > >>> > > >>> Thanks for your comments! > > >> > > >> Hi Geert, > > >> > > >> this seems fine to me. But I am reluctant to queue it up before the PFC > > >> changes are accepted, lest there be some change in direction. > > >> > > >> Please repost once the PFC changes have been accepted. > > > > > > I've acked the dependency, but we should probably wait for Linus to apply > > > it. > > > > Thanks Laurent, of course that plan is fine by me. > > Linus has just applied it, so I think you can go forward with this series. Thanks, done. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Fri, Mar 06, 2015 at 10:21:55AM -0800, Dmitry Torokhov wrote:
> On Fri, Mar 06, 2015 at 07:21:38PM +0100, Sébastien Szymanski wrote:
> > Signed-off-by: Sébastien Szymanski
> > ---
> > drivers/input/touchscreen/Kconfig | 11 ++
> > drivers/input/touchscreen/Makefile | 1 +
> > drivers/input/touchscreen/sx8654.c | 285
> > +
> > 3 files changed, 297 insertions(+)
> > create mode 100644 drivers/input/touchscreen/sx8654.c
> >
> > diff --git a/drivers/input/touchscreen/Kconfig
> > b/drivers/input/touchscreen/Kconfig
> > index 5891752..6f713fd0 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -961,6 +961,17 @@ config TOUCHSCREEN_SUR40
> > To compile this driver as a module, choose M here: the
> > module will be called sur40.
> >
> > +config TOUCHSCREEN_SX8654
> > + tristate "Semtech SX8654 touchscreen"
> > + depends on I2C && OF
>
> Does it have to depend on OF? I do not see anything OF-specific there...
>
> No need to resumbit.
Applied with some cosmetic edits and DT bindings folded into this patch.
Thank you.
>
> > + help
> > + Say Y here if you have a Semtech SX8654 touchscreen controller.
> > +
> > + If unsure, say N
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called sx8654.
> > +
> > config TOUCHSCREEN_TPS6507X
> > tristate "TPS6507x based touchscreens"
> > depends on I2C
> > diff --git a/drivers/input/touchscreen/Makefile
> > b/drivers/input/touchscreen/Makefile
> > index 0242fea..a06a752 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -79,5 +79,6 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL)+=
> > atmel-wm97xx.o
> > obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE) += mainstone-wm97xx.o
> > obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE) += zylonite-wm97xx.o
> > obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
> > +obj-$(CONFIG_TOUCHSCREEN_SX8654) += sx8654.o
> > obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> > obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
> > diff --git a/drivers/input/touchscreen/sx8654.c
> > b/drivers/input/touchscreen/sx8654.c
> > new file mode 100644
> > index 000..58cc478
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/sx8654.c
> > @@ -0,0 +1,285 @@
> > +/*
> > + * drivers/input/touchscreen/sx8654.c
> > + *
> > + * Copyright (c) 2015 Armadeus Systems
> > + * Sébastien Szymanski
> > + *
> > + * Using code from:
> > + * - sx865x.c
> > + * Copyright (c) 2013 U-MoBo Srl
> > + * Pierluigi Passaro
> > + * - sx8650.c
> > + * Copyright (c) 2009 Wayne Roberts
> > + * - tsc2007.c
> > + * Copyright (c) 2008 Kwangwoo Lee
> > + * - ads7846.c
> > + * Copyright (c) 2005 David Brownell
> > + * Copyright (c) 2006 Nokia Corporation
> > + * - corgi_ts.c
> > + * Copyright (C) 2004-2005 Richard Purdie
> > + * - omap_ts.[hc], ads7846.h, ts_osk.c
> > + * Copyright (C) 2002 MontaVista Software
> > + * Copyright (C) 2004 Texas Instruments
> > + * Copyright (C) 2005 Dirk Behme
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* register addresses */
> > +#define I2C_REG_TOUCH0 0x00
> > +#define I2C_REG_TOUCH1 0x01
> > +#define I2C_REG_CHANMASK 0x04
> > +#define I2C_REG_IRQMASK0x22
> > +#define I2C_REG_IRQSRC 0x23
> > +#define I2C_REG_SOFTRESET 0x3f
> > +
> > +/* commands */
> > +#define CMD_READ_REGISTER 0x40
> > +#define CMD_MANUAL 0xc0
> > +#define CMD_PENTRG 0xe0
> > +
> > +/* value for I2C_REG_SOFTRESET */
> > +#define SOFTRESET_VALUE0xde
> > +
> > +/* bits for I2C_REG_IRQSRC */
> > +#define IRQ_PENTOUCH_TOUCHCONVDONE 0x08
> > +#define IRQ_PENRELEASE 0x04
> > +
> > +/* bits for RegTouch1 */
> > +#define CONDIRQ0x20
> > +#define FILT_7SA 0x03
> > +
> > +/* bits for I2C_REG_CHANMASK */
> > +#define CONV_X 0x80
> > +#define CONV_Y 0x40
> > +
> > +/* coordinates rate: higher nibble of CTRL0 register */
> > +#define RATE_MANUAL0x00
> > +#define RATE_5000CPS 0xf0
> > +
> > +/* power delay: lower nibble of CTRL0 register */
> > +#define POWDLY_1_1MS 0x0b
> > +
> > +#define MAX_12BIT ((1 << 12) - 1)
> > +
> > +struct sx8654 {
> > + struct input_dev *input;
> > + struct i2c_client *client;
> > +};
> > +
> > +static irqreturn_t sx8654_irq(int irq, void *handle
Re: [PATCH v3] input: goodix: Add device tree support
On Fri, Mar 06, 2015 at 01:23:45PM +0100, Bastien Nocera wrote: > On Thu, 2015-03-05 at 20:32 +0300, Aleksei Mamlin wrote: > > This patch adds device tree support and binding information for > > Goodix GT9xx series touchscreen controller. > > It also adds support for 5-finger chips, like GT911 and GT912, which > > can be found on ARM tablets, like Wexler TAB7200 and MSI Primo73. > > > > Changes since v2: > > * Split to two patches: > > The first one for use max number of touches from device config. > > The second one adds device tree support. > > > > Changes since v1: > > * Merge patches into single patch. > > * Use max touch number from config instead of hardcoding. > > * Update description in Kconfig. > > > > Datasheets can be found here: > > https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing > > > > Signed-off-by: Aleksei Mamlin > > Reviewed-by: Bastien Nocera Applied, thank you. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] input: goodix: Use max touch number from device config
On Fri, Mar 06, 2015 at 02:42:31PM +0100, Antonio Ospite wrote:
> On Thu, 5 Mar 2015 20:32:24 +0300
> Aleksei Mamlin wrote:
>
> > Use max number of touches from device config instead of hardcoding.
> >
> > Signed-off-by: Aleksei Mamlin
>
> Tested-by: Antonio Ospite
>
> Some minor comments below, but no need to resend IMHO.
Applied, thank you.
>
> > ---
> > drivers/input/touchscreen/goodix.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index ca19668..a3e2057 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -48,6 +48,7 @@ struct goodix_ts_data {
> > #define GOODIX_REG_VERSION 0x8140
> >
> > #define RESOLUTION_LOC 1
> > +#define MAX_CONTACTS_LOC 5
> > #define TRIGGER_LOC6
> >
> > static const unsigned long goodix_irq_flags[] = {
> > @@ -99,7 +100,7 @@ static int goodix_ts_read_input_report(struct
> > goodix_ts_data *ts, u8 *data)
> > }
> >
> > touch_num = data[0] & 0x0f;
> > - if (touch_num > GOODIX_MAX_CONTACTS)
> > + if (touch_num > ts->max_touch_num)
> > return -EPROTO;
> >
> > if (touch_num > 1) {
> > @@ -141,7 +142,7 @@ static void goodix_ts_report_touch(struct
> > goodix_ts_data *ts, u8 *coor_data)
> > */
> > static void goodix_process_events(struct goodix_ts_data *ts)
> > {
> > - u8 point_data[1 + GOODIX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
> > + u8 point_data[1 + GOODIX_CONTACT_SIZE * ts->max_touch_num];
> > int touch_num;
> > int i;
> >
> > @@ -202,21 +203,23 @@ static void goodix_read_config(struct goodix_ts_data
> > *ts)
> > ts->abs_x_max = GOODIX_MAX_WIDTH;
> > ts->abs_y_max = GOODIX_MAX_HEIGHT;
> > ts->int_trigger_type = GOODIX_INT_TRIGGER;
> > + ts->max_touch_num = GOODIX_MAX_CONTACTS;
> > return;
> > }
> >
> > ts->abs_x_max = get_unaligned_le16(&config[RESOLUTION_LOC]);
> > ts->abs_y_max = get_unaligned_le16(&config[RESOLUTION_LOC + 2]);
> > ts->int_trigger_type = (config[TRIGGER_LOC]) & 0x03;
> > - if (!ts->abs_x_max || !ts->abs_y_max) {
> > + ts->max_touch_num = (config[MAX_CONTACTS_LOC]) & 0x0f;
>
> Parentheses are not really needed here, but I see that you just followed
> the style from the line above, so it's OK, I'll send a cleanup patch
> to remove them from both lines.
>
> > + if (!ts->abs_x_max || !ts->abs_y_max || !ts->max_touch_num) {
> > dev_err(&ts->client->dev,
> > "Invalid config, using defaults\n");
> > ts->abs_x_max = GOODIX_MAX_WIDTH;
> > ts->abs_y_max = GOODIX_MAX_HEIGHT;
> > + ts->max_touch_num = GOODIX_MAX_CONTACTS;
> > }
> > }
> >
> > -
>
> This is an unrelated change, it's not a big deal of course but in
> general it is a good practice to differentiate cosmetic changes from
> functional ones.
>
> > /**
> > * goodix_read_version - Read goodix touchscreen version
> > *
> > @@ -295,7 +298,7 @@ static int goodix_request_input_dev(struct
> > goodix_ts_data *ts)
> > input_set_abs_params(ts->input_dev, ABS_MT_WIDTH_MAJOR, 0, 255, 0, 0);
> > input_set_abs_params(ts->input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
> >
> > - input_mt_init_slots(ts->input_dev, GOODIX_MAX_CONTACTS,
> > + input_mt_init_slots(ts->input_dev, ts->max_touch_num,
> > INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
> >
> > ts->input_dev->name = "Goodix Capacitive TouchScreen";
> > --
> > 2.0.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-input" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Thanks,
>Antonio
>
> --
> Antonio Ospite
> http://ao2.it
>
> A: Because it messes up the order in which people normally read text.
>See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
On Fri, 6 Mar 2015, Dave Gerlach wrote: > On 03/06/2015 11:44 AM, Paul Walmsley wrote: > > On Fri, 6 Mar 2015, Dave Gerlach wrote: > >> On 03/05/2015 10:26 PM, Paul Walmsley wrote: > >>> On Thu, 5 Mar 2015, Dave Gerlach wrote: > >>> > RTC hwmod is needed for proper operation of PM features like > rtcwake and rtc-only mode so reuse the am33xx rtc hwmod. > > Signed-off-by: Dave Gerlach > >>> > >>> Thanks, queued for v4.1. > >> > >> Thanks, but please note as I just commented in Patch 1 of this series, > >> without > >> the ti,no-init flag in place that is introduced there this patch will > >> cause the > >> am43x-epos-evm to fail to boot. > > > > If that's so, shouldn't it appear in the series after patch 3, then? > > If only patches 1 and 2 are applied, then won't the boot be broken on > > am43x-epos-evm ? > > Hmm yes you are correct that would be the case, seems I should have swapped > the > order. I've gotten into the habit of putting dt patches last to enable what > gets > introduced previously, guess it's not always the best thing to do. Thanks for > pointing this out. OK dropped until this thing is sorted out. - Paul -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: imx: add required clocks property to binding
On Tue, Mar 03, 2015 at 11:57:08AM -0500, Matt Porter wrote: > A clock specifier is required for i.MX I2C and is > provided in all DTS implementations. Add this to the > list of required properties in the binding. > > Signed-off-by: Matt Porter Applied to for-current, thanks! signature.asc Description: Digital signature
[RFC/PATCHv2 2/3] dt-binding: spi: spi-dw: Select 16b or 32b access for Designware SPI
From: Thor Thayer Altera's Arria10 architecture requires a 32bit write accesses for APB peripherals. The current spi-dw driver uses 16bit accesses in some locations. This patch updated the bindings with an optional field in the devicetree to select 32bit accesses. Signed-off-by: Thor Thayer --- Documentation/devicetree/bindings/spi/spi-dw.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-dw.txt b/Documentation/devicetree/bindings/spi/spi-dw.txt index 7b63ed6..034dbdd 100644 --- a/Documentation/devicetree/bindings/spi/spi-dw.txt +++ b/Documentation/devicetree/bindings/spi/spi-dw.txt @@ -11,6 +11,7 @@ Required properties: Optional properties: - cs-gpios: see spi-bus.txt +- 32bit_access : use 32 bit register accesses Example: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCHv2 3/3] spi: dw-spi: Pointers select 16b vs. 32b DesignWare access
From: Thor Thayer
Altera's Arria10 SoC interconnect requires a 32 bit write for APB
peripherals. The current spi-dw driver uses 16bit accesses in
some locations. Use function pointers to support 32 bit accesses
but retain legacy 16 bit access.
Signed-off-by: Thor Thayer
---
drivers/spi/spi-dw-mmio.c |7 ++-
drivers/spi/spi-dw.c | 29 +
drivers/spi/spi-dw.h | 12
3 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index eb03e12..c4fe9e9 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -76,8 +76,13 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
num_cs = 4;
- if (pdev->dev.of_node)
+ if (pdev->dev.of_node) {
of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
+ if (of_property_read_bool(pdev->dev.of_node, "32bit_access")) {
+ dws->read_w = dw_readw32;
+ dws->write_w = dw_writew32;
+ }
+ }
dws->num_cs = num_cs;
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index c5fa2be..d008791 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -157,7 +157,7 @@ static inline u32 tx_max(struct dw_spi *dws)
u32 tx_left, tx_room, rxtx_gap;
tx_left = (dws->tx_end - dws->tx) / dws->n_bytes;
- tx_room = dws->fifo_len - dw_readw(dws, DW_SPI_TXFLR);
+ tx_room = dws->fifo_len - dws->read_w(dws, DW_SPI_TXFLR);
/*
* Another concern is about the tx/rx mismatch, we
@@ -178,7 +178,7 @@ static inline u32 rx_max(struct dw_spi *dws)
{
u32 rx_left = (dws->rx_end - dws->rx) / dws->n_bytes;
- return min_t(u32, rx_left, dw_readw(dws, DW_SPI_RXFLR));
+ return min_t(u32, rx_left, dws->read_w(dws, DW_SPI_RXFLR));
}
static void dw_writer(struct dw_spi *dws)
@@ -194,7 +194,7 @@ static void dw_writer(struct dw_spi *dws)
else
txw = *(u16 *)(dws->tx);
}
- dw_writew(dws, DW_SPI_DR, txw);
+ dws->write_w(dws, DW_SPI_DR, txw);
dws->tx += dws->n_bytes;
}
}
@@ -205,7 +205,7 @@ static void dw_reader(struct dw_spi *dws)
u16 rxw;
while (max--) {
- rxw = dw_readw(dws, DW_SPI_DR);
+ rxw = dws->read_w(dws, DW_SPI_DR);
/* Care rx only if the transfer's original "rx" is not null */
if (dws->rx_end - dws->len) {
if (dws->n_bytes == 1)
@@ -254,11 +254,11 @@ static void int_error_stop(struct dw_spi *dws, const char
*msg)
static irqreturn_t interrupt_transfer(struct dw_spi *dws)
{
- u16 irq_status = dw_readw(dws, DW_SPI_ISR);
+ u16 irq_status = dws->read_w(dws, DW_SPI_ISR);
/* Error handling */
if (irq_status & (SPI_INT_TXOI | SPI_INT_RXOI | SPI_INT_RXUI)) {
- dw_readw(dws, DW_SPI_ICR);
+ dws->read_w(dws, DW_SPI_ICR);
int_error_stop(dws, "interrupt_transfer: fifo
overrun/underrun");
return IRQ_HANDLED;
}
@@ -283,7 +283,7 @@ static irqreturn_t dw_spi_irq(int irq, void *dev_id)
{
struct spi_master *master = dev_id;
struct dw_spi *dws = spi_master_get_devdata(master);
- u16 irq_status = dw_readw(dws, DW_SPI_ISR) & 0x3f;
+ u16 irq_status = dws->read_w(dws, DW_SPI_ISR) & 0x3f;
if (!irq_status)
return IRQ_NONE;
@@ -379,7 +379,7 @@ static int dw_spi_transfer_one(struct spi_master *master,
cr0 |= (chip->tmode << SPI_TMOD_OFFSET);
}
- dw_writew(dws, DW_SPI_CTRL0, cr0);
+ dws->write_w(dws, DW_SPI_CTRL0, cr0);
/* Check if current transfer is a DMA transaction */
dws->dma_mapped = map_dma_buffers(master, spi, transfer);
@@ -393,7 +393,7 @@ static int dw_spi_transfer_one(struct spi_master *master,
*/
if (!dws->dma_mapped && !chip->poll_mode) {
txlevel = min_t(u16, dws->fifo_len / 2, dws->len /
dws->n_bytes);
- dw_writew(dws, DW_SPI_TXFLTR, txlevel);
+ dws->write_w(dws, DW_SPI_TXFLTR, txlevel);
/* Set the interrupt mask */
imask |= SPI_INT_TXEI | SPI_INT_TXOI |
@@ -516,11 +516,11 @@ static void spi_hw_init(struct device *dev, struct dw_spi
*dws)
u32 fifo;
for (fifo = 1; fifo < 256; fifo++) {
- dw_writew(dws, DW_SPI_TXFLTR, fifo);
- if (fifo != dw_readw(dws, DW_SPI_TXFLTR))
+ dws->write_w(dws, DW_SPI_TXFLTR, fifo);
+ if (fifo != dws->read_w(dws, DW_SPI_TXFLTR))
break;
}
- dw_writew(dws, DW_SPI_TXFLTR, 0);
+ dws->write_w(dws, DW_SPI_TXFLTR, 0);
[RFC/PATCHv2 1/3] spi: dw-spi: Single Register read to clear IRQs
From: Thor Thayer
Instead of clearing the RxU, RxO, and TxO IRQs individually with
3 register reads, a single read of the ICR register will do the
same thing.
Signed-off-by: Thor Thayer
Signed-off-by: Andy Shevchenko
---
drivers/spi/spi-dw.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 950bc50..c5fa2be 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -258,9 +258,7 @@ static irqreturn_t interrupt_transfer(struct dw_spi *dws)
/* Error handling */
if (irq_status & (SPI_INT_TXOI | SPI_INT_RXOI | SPI_INT_RXUI)) {
- dw_readw(dws, DW_SPI_TXOICR);
- dw_readw(dws, DW_SPI_RXOICR);
- dw_readw(dws, DW_SPI_RXUICR);
+ dw_readw(dws, DW_SPI_ICR);
int_error_stop(dws, "interrupt_transfer: fifo
overrun/underrun");
return IRQ_HANDLED;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCHv2 0/3] spi: spi-dw: Select 16b or 32b register access
From: Thor Thayer The Altera Arria10 SoC interconnect requires 32 bit write accesses to APB peripherals. The DesignWare SPI peripheral registers are on 32bit boundaries so this patch is minimal. Function pointers are used to select 32bit access or 16bit accesses Thor Thayer (3): spi: dw-spi: Single Register read to clear IRQs dt-binding: spi: spi-dw: Select 16b or 32b access for Designware SPI spi: dw-spi: Pointers select 16b vs. 32b DesignWare access Documentation/devicetree/bindings/spi/spi-dw.txt |1 + drivers/spi/spi-dw-mmio.c|7 - drivers/spi/spi-dw.c | 31 -- drivers/spi/spi-dw.h | 12 + 4 files changed, 36 insertions(+), 15 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: dts: add dts files for Cubieboard4
From: Tyler Baker This series adds basic support for the Cubietech Cubieboard4. The Cubietech Cubieboard4 is a A80 based development board with 2GB DDR3, 8GB eMMC, Micro SD, HDMI, VGA, 3.5mm audio jack. One USB OTG port and four USB 2.0 ports. The sun9i-a80-optimus device tree[1] has been used to boot this board for some time now, as the two platforms are very similar. But there are differences, so it deserves it's own device tree. I've tested this series on a Cubieboard4[2][3] and can confirm UART, eMMC, and MMC are working properly. This patch series is based on arm-soc v4.0-rc2. [1] http://kernelci.org/boot/sun9i-a80-cubieboard4/ [2] http://lava.kernelci.org/scheduler/job/47969/log_file#L_13_308 [3] http://lava.kernelci.org/scheduler/job/47969/log_file#L_17_11 Tyler Baker (2): ARM: dts: add cubietech cubieboard4 ARM: dts: add vendor prefix for cubietech .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/sun9i-a80-cubieboard4.dts| 100 + 3 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: add vendor prefix for cubietech
From: Tyler Baker Add a cubietech vendor prefix, as it is missing. The cubietruck, cubieboard2, and cubieboard all already reference this prefix. Signed-off-by: Tyler Baker --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index aeb5bb5..58364cf 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -45,6 +45,7 @@ cnxt Conexant Systems, Inc. cortinaCortina Systems, Inc. cosmic Cosmic Circuits crystalfontz Crystalfontz America, Inc. +cubietech Cubietech, Ltd. dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. denx Denx Software Engineering -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: add cubietech cubieboard4
From: Tyler Baker
Add a Cubietech Cubieboard4 device tree and instruct make to build it. This
device tree has been derived from the sun9i-a80-optimus.dts as they are very
similar in design[1]. Notably, I2C3 is not used on Cubieboard4 and the LED/PWM
definitions will need to be updated in the future.
[1] http://dl.cubieboard.org/model/cc-a80/Hardware/CC-A80-HW-V1.1.pdf
Signed-off-by: Tyler Baker
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 100
2 files changed, 102 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4837044..0f67dab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -553,7 +553,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a23-ippo-q8h-v5.dtb \
sun8i-a23-ippo-q8h-v1.2.dtb
dtb-$(CONFIG_MACH_SUN9I) += \
- sun9i-a80-optimus.dtb
+ sun9i-a80-optimus.dtb \
+ sun9i-a80-cubieboard4.dtb
dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
tegra20-harmony.dtb \
tegra20-iris-512.dtb \
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
new file mode 100644
index 000..b239b39
--- /dev/null
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -0,0 +1,100 @@
+/*
+ * Copyright 2015 Tyler Baker
+ *
+ * Tyler Baker
+ * Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun9i-a80.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Cubietech Cubieboard4";
+ compatible = "cubietech,a80-cubietruck", "allwinner,sun9i-a80";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ bootargs = "earlyprintk console=ttyS0,115200";
+ };
+
+};
+
+&pio {
+
+ mmc0_cd_pin_cubieboard4: mmc0_cd_pin@0 {
+ allwinner,pins = "PH18";
+ allwinner,function = "gpio_in";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_cubieboard4>;
+ vmmc-supply = <®_vcc3v0>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */
+ cd-inverted;
+ status = "okay";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_8bit_pins>;
+ vmmc-supply = <®_vcc3v0>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] spi: spi-dw: Select 16b or 32b register access
On 03/05/2015 03:54 PM, Andy Shevchenko wrote:
On Thu, 2015-03-05 at 14:41 -0600, Thor Thayer wrote:
Hi Andy,
On 03/05/2015 04:43 AM, Andy Shevchenko wrote:
On Wed, 2015-03-04 at 16:01 -0600, Thor Thayer wrote:
Hi Andy,
On 03/04/2015 02:44 PM, Andy Shevchenko wrote:
On Wed, 2015-03-04 at 14:31 -0600, ttha...@opensource.altera.com wrote:
From: Thor Thayer
The Altera Arria10 SoC requires 32 bit accesses to peripherals. The
DesignWare SPI peripheral registers are on 32bit boundaries so this
patch is minimal. Function pointers are used to select 32bit access
or 16bit accesses.
So, what is exactly the issue when we read only half of the register?
Bus lock, or what?
The read actually works on our chip but I changed both read and write to
be consistent. For Arria10, on a 16 bit write the data isn't written
into the DesignWare register.
How did you exactly check this?
Sorry, I should have been more clear. The architecture of the Arria10
SoC enforces 32 bit writes - even for the APB bus. The Arria10's
interconnect only allows 32 bit writes.
Hmm… So, reads are okay, but writes are 32 bit only? Have you any link
to the documentation where I could read this?
Currently Table 7-6 in the Arria10 Technical Reference Manual [1] on
page 141 shows SPI Master as a 32 bit wide interface but it doesn't
explicitly note the 32bit write requirement. We're adding a note to
table 7-6 as a result of this discussion.
[1] http://www.altera.com/literature/hb/arria-10/a10_5v4.pdf
As a result, the solution below doesn't work for us.
My thought was about post writes. That's why I was wondering and still
wonder if something to clarify in the documentation.
I do have a much cleaner patch to re-submit but I haven't applied it on
top of your patches yet & tested yet.
Okay, please, apply the above as a part of commit message.
I also would like to test it on Intel Medfield.
In reply to your other email, yes it does support the DW_apb_ssi but the
Arria10 architecture requires 32 bit access (actually as you point out,
32 bit writes). We're using the original driver on our older chips but
Arria10 requires upstream changes.
Can you check if the following helps in your case:
--- a/drivers/spi/spi-dw.h
+++ b/drivers/spi/spi-dw.h
@@ -170,6 +170,8 @@ static inline u16 dw_readw(struct dw_spi *dws, u32 offset)
static inline void dw_writew(struct dw_spi *dws, u32 offset, u16 val)
{
__raw_writew(val, dws->regs + offset);
+ mmiowb():
+ __raw_readw(dws->regs + offset);
}
static inline void spi_enable_chip(struct dw_spi *dws, int enable)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/6] clk: add of_clk_get_parent_rate function
Quoting Ray Jui (2015-03-06 12:07:13) > Hi Mike, > > On 3/6/2015 11:55 AM, Mike Turquette wrote: > > Quoting Sascha Hauer (2015-02-26 00:43:19) > >> On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote: > >>> On 2/25/2015 10:51 PM, Sascha Hauer wrote: > On Wed, Feb 25, 2015 at 10:13:15PM -0800, Ray Jui wrote: > > Hi Sascha, > > > > On 2/25/2015 9:54 PM, Sascha Hauer wrote: > >> Hi Ray, > >> > >> On Wed, Feb 04, 2015 at 04:55:00PM -0800, Ray Jui wrote: > >>> Sometimes a clock needs to know the rate of its parent before itself > >>> is > >>> registered to the framework. An example is that a PLL may need to > >>> initialize itself to a specific VCO frequency, before registering to > >>> the > >>> framework. The parent rate needs to be known, for PLL multipliers and > >>> divisors to be configured properly. > >>> > >>> Introduce helper function of_clk_get_parent_rate, which can be used to > >>> obtain the parent rate of a clock, given a device node and index. > >> > >> I can't see how this patch helps you. First it's not guaranteed that > >> the parent is already registered, what do you do in this case? > > > > In the case when clock parent is not found, as you can see from the > > code, it simply returns zero, just like other clk get rate APIs. > > Yes, but what do you do with the 0 result then in your PLL > initialization? > > >>> > >>> As of the current code, it fails the PLL frequency initialization and > >>> bails out. Thinking about it more, it actually makes more sense to just > >>> warn and still go ahead to register the clock, in which case it will use > >>> whatever default frequency after chip power on reset or a frequency > >>> configured in the bootloader. > >>> > > > > I thought the order of clock registration is based on order of the clock > > nodes in device tree. It makes sense to me to declare the parent clock > > before a child clock, so it's guaranteed that the parent is registered > > before the child. > > No, you can't rely on that. The order of the device nodes may happen to > define the order of clock initialization now, but that may change. > device nodes are usually ordered by bus addresses, not by intended > initialization order. Even if you reorder them everything must still > work. > > >>> > >>> Okay I get your point that the order of device nodes may not be relied > >>> on for device initialization order. But then another mechanism should be > >>> deployed to give developers the option to decide on the clock > >>> initialization sequence. It can be optional but it should be there. > >>> > > > >> Then the clock framework doesn't require that you initialize the PLL > >> before registering. That can be done in the clk ops later. > > > > Sure it's not mandatory. But what's wrong with me choosing to initialize > > the PLL clock to a known frequency before registering it to the > > framework? > > Appearantly you don't know the (input) frequency of the PLL when > registering it to the framework, so the question must be: What's wrong > with keeping it uninitialized? > > If the PLL is unused then you don't care about it's initialization > status. If it happens to be enabled by a bootloader and still unused > at late_initcall time the clock framework will disable it so you > have a known state then. If a consumer for the PLL appears it's its > job to initialize it through the clk api. > > Sascha > > >>> > >>> Okay, what we need here is to initialize the PLL to a desired frequency, > >>> based on device tree settings (since it will be configured differently, > >>> among different boards). This is a PLL that 1) has limited options of > >>> frequencies which it can be configured to, and 2) has multiple child > >>> clocks, where is a more suitable place to initialize it to the desired > >>> frequency than right before registering it to the framework? I know a > >>> lot of people do it in the bootloader, but I thought we should be given > >>> the flexibility of configuring it in the kernel. > >>> > >>> When you say "consumers", do you mean 1) the device driver that uses the > >>> PLL; or 2) the device driver that use the child clock of the PLL? If > >>> it's case 1), then we don't really have a device driver that directly > >>> uses the PLL, and I thought that's quite normal, as most PLLs don't > >>> directly feed into any peripherals. > >> > >> I meant 1) and 2). Before a consumer comes along the state of the PLL > >> doesn't matter. When a consumer shows up it has to call > >> clk_prepare_enable which (directly or indirectly) will enable your PLL. > >> Then it's still time to apply the default settings you found out during > >> probe of the PLL. > > > > My review comments are really for iproc_pll_setup() in patch #3, but the > >
Re: [PATCH 00/10] omap3 crypto fixes
Hi, On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: > Are there any fixes in this series that should go into > v4.0-rc series, or can it all wait for v4.1? I think these all should wait for v4.1. A. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch V7 02/10] ASoC: qcom: Document LPASS CPU bindings
On Mar 6, 2015, at 4:03 PM, Kenneth Westfield wrote: > On Fri, Mar 06, 2015 at 10:07:01AM -0600, Kumar Gala wrote: >> On Mar 5, 2015, at 7:51 PM, Kenneth Westfield >> wrote: >>> On Thu, Mar 05, 2015 at 12:52:30PM -0600, Kumar Gala wrote: On Mar 3, 2015, at 6:21 PM, Kenneth Westfield wrote: > +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt > @@ -0,0 +1,49 @@ > +* Qualcomm Technologies LPASS CPU DAI > + > +Required subnodes: > + > +- qcom,adsp : Audio DSP sub-node > + > +Optional Audio DSP subnode properties: > + > +- status : "disabled" indicates the adsp is not available. > + What is the intent of this subnode? >>> >>> From the cover letter: >>> Even though the ipq806x LPASS does not contain an audio DSP, other SOCs >>> do have one. For those SOCs, the audio DSP typically controls the >>> hardware blocks in the LPASS. Hence, different CPU DAI driver(s) would >>> need to be used in order to facilitate audio with the DSP. As such, the >>> LPASS DT contains an adsp subnode, which is disabled for this SOC. The >>> same subnode should be enabled and populated for other SOCs that do >>> contain an audio DSP. Not using the audio DSP would require different >>> CPU DAI driver(s), in addition to possible bootloader and/or firmware >>> changes. >>> >>> This was the result of a request from Mark. See here: >>> http://thread.gmane.org/gmane.linux.drivers.devicetree/109331/focus=11633 >> >> Two quick comments before I read Mark?s comments. >> >> 1. Its not normal practice to put something into a DT that does not exist. >> Having a node, but marking it disabled implies existence. > > Will change the DT definition to optional. > >> 2. How would one normally address the audio DSP if it did exist. I?m just >> wondering if having a subnode is the proper solution vs maybe a phandle > > The audio DSP is, in fact, contained within the audio subsystem. The > representation of that relationship in the DT, I believe, would be a subnode. > OTOH, if there is a strong sentiment towards using a phandle, that would be > fine with me. Just depends on how we communicate with the DSP. If its mostly via MMIO access than a sub node makes sense. If its via some other RPC/communication mechanism than possibly a phandle. Trying to understand a bit more to than see what I’d recommend. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch V7 02/10] ASoC: qcom: Document LPASS CPU bindings
On Fri, Mar 06, 2015 at 10:07:01AM -0600, Kumar Gala wrote: > On Mar 5, 2015, at 7:51 PM, Kenneth Westfield wrote: > > On Thu, Mar 05, 2015 at 12:52:30PM -0600, Kumar Gala wrote: > >> On Mar 3, 2015, at 6:21 PM, Kenneth Westfield > >> wrote: > >> > >>> +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt > >>> @@ -0,0 +1,49 @@ > >>> +* Qualcomm Technologies LPASS CPU DAI > >>> + > >>> +Required subnodes: > >>> + > >>> +- qcom,adsp : Audio DSP sub-node > >>> + > >>> +Optional Audio DSP subnode properties: > >>> + > >>> +- status : "disabled" indicates the adsp is not available. > >>> + > >> > >> What is the intent of this subnode? > >> > > > > From the cover letter: > > Even though the ipq806x LPASS does not contain an audio DSP, other SOCs > > do have one. For those SOCs, the audio DSP typically controls the > > hardware blocks in the LPASS. Hence, different CPU DAI driver(s) would > > need to be used in order to facilitate audio with the DSP. As such, the > > LPASS DT contains an adsp subnode, which is disabled for this SOC. The > > same subnode should be enabled and populated for other SOCs that do > > contain an audio DSP. Not using the audio DSP would require different > > CPU DAI driver(s), in addition to possible bootloader and/or firmware > > changes. > > > > This was the result of a request from Mark. See here: > > http://thread.gmane.org/gmane.linux.drivers.devicetree/109331/focus=11633 > > Two quick comments before I read Mark?s comments. > > 1. Its not normal practice to put something into a DT that does not exist. > Having a node, but marking it disabled implies existence. Will change the DT definition to optional. > 2. How would one normally address the audio DSP if it did exist. I?m just > wondering if having a subnode is the proper solution vs maybe a phandle The audio DSP is, in fact, contained within the audio subsystem. The representation of that relationship in the DT, I believe, would be a subnode. OTOH, if there is a strong sentiment towards using a phandle, that would be fine with me. -- Kenneth Westfield Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] mailbox: Enable BCM2835 mailbox support
On 03/06/2015 01:29 PM, Stephen Warren wrote:
On 03/06/2015 01:00 PM, Eric Anholt wrote:
Stephen Warren writes:
On 03/04/2015 11:20 AM, Eric Anholt wrote:
Stephen Warren writes:
On 03/02/2015 01:54 PM, Eric Anholt wrote:
From: Lubomir Rintel
Implement BCM2835 mailbox support as a device registered with
the general purpose mailbox framework. Implementation based on
commits by Lubomir Rintel [1], Suman Anna and Jassi Brar [2] on
which to base the implementation.
diff --git a/drivers/mailbox/bcm2835-mailbox.c
b/drivers/mailbox/bcm2835-mailbox.c
+static irqreturn_t bcm2835_mbox_irq(int irq, void *dev_id) +{
+struct bcm2835_mbox *mbox = (struct bcm2835_mbox *) dev_id; +
struct device *dev = mbox->dev; + +while (!(readl(mbox->regs +
MAIL0_STA) & ARM_MS_EMPTY)) { +u32 msg = readl(mbox->regs +
MAIL0_RD); +unsigned int chan = MBOX_CHAN(msg); + +if
(!mbox->channel[chan].started) { +dev_err(dev, "Reply on
stopped channel %d\n", chan); +continue; +} +
dev_dbg(dev, "Reply 0x%08X\n", msg); +
mbox_chan_received_data(mbox->channel[chan].link, +
(void *)
MBOX_DATA28(msg)); +} +rmb(); /* Finished last mailbox read.
*/
I know the PDF mentioned in the comment earlier in the patch says
to put in barriers between accesses to different peripherals,
which this seems compliant with, but I don't see quite what this
barrier achieves. I think the PDF is talking generalities, not
imposing a rule that must be blindly followed. Besides, if
there's a context-switch you can't actually implement the rules
the PDF suggests. What read operation is this barrier attempting
to ensure happens after reading all mailbox messages and any
associated DRAM buffer?
Looking at this bit of code in particular:
"As interrupts can appear anywhere in the code so you should
safeguard those. If an interrupt routine reads from a peripheral
the routine should start with a memory read barrier. If an
interrupt routine writes to a peripheral the routine should end
with a memory write barrier."
I can see that doing that would be safe, but I don't think following
those rules is actually necessary in the general case. Following those
rules would cause lots of unnecessary barriers in code.
Barriers shouldn't be used arbitrarily at the start/end of ISRs, but
rather at specific chosen locations in the code that actually need to
enforce some kind of memory ordering.
According to the architecture docs, if you don't RMB at the start of
your ISR, then the following timeline could get the wrong values:
Which architecture doc and section/... specifically?
Ah, this is BCM2835-ARM-Peripherals.pdf still. I found the footnote you
mentioned.
some other device driver our isr
---
rmb()
read from device
read from device
examine value read
exit isr
examine value raed.
The ISR could get the device driver's value. This is made explicit in
footnote 2 on page 7.
Are you saying that the "read from device" in the right -hand "our isr"
column could end up returning the value actually read during "read from
device" in the left-hand "some other device driver" column, or vice-versa?
That doesn't make any sense.
Barriers are about ensuring that accesses happen (are visible or
complete) in the desired order, not about ensuring that the results of
two unrelated reads don't get swapped.
Ah. I've been thinking about the typical uses of barriers to ensure
ordering of transactions on a standards-compliant ARM CPU.
It was pointed out on IRC that perhaps the barriers are to work around a
CPU/SoC bug. In which case, if the CPU/bus really can swap results, then
I can see how barriers might be required and how they might solve the
problem. If this is the real reason, it sounds truly massively scary.
I think this deserves a complete description in each driver file and in
the commit description for any commit that introduces these barriers.
Otherwise someone else will just want to rip them out.
I'm also concerned that we need to add barriers in many more places than
just that start/end of ISRs. For example, what if the ISR for the
mailbox ends up calling back into some other driver that goes and
touches a different HW module. Now we need to put barriers either at the
start/end of that callback function, or immediately before/after we call
that callback function. This has potential to need barriers in a whole
bunch of places one wouldn't expect.
I sure hope this was fixed on bcm2836, or that the ordering issue
appears separately within each CPU core and there's no interaction
between multiple CPU cores. Otherwise, two separate pieces of code
running on two separate CPU cores are going to have trouble when they
start touching different peripherals.
--
To unsubscribe from this list: send the line "u
[PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
Signed-off-by: Sébastien Szymanski
---
drivers/input/touchscreen/Kconfig | 11 ++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/sx8654.c | 285 +
3 files changed, 297 insertions(+)
create mode 100644 drivers/input/touchscreen/sx8654.c
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..6f713fd0 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -961,6 +961,17 @@ config TOUCHSCREEN_SUR40
To compile this driver as a module, choose M here: the
module will be called sur40.
+config TOUCHSCREEN_SX8654
+ tristate "Semtech SX8654 touchscreen"
+ depends on I2C && OF
+ help
+ Say Y here if you have a Semtech SX8654 touchscreen controller.
+
+ If unsure, say N
+
+ To compile this driver as a module, choose M here: the
+ module will be called sx8654.
+
config TOUCHSCREEN_TPS6507X
tristate "TPS6507x based touchscreens"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 0242fea..a06a752 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -79,5 +79,6 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL)+=
atmel-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE) += mainstone-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE) += zylonite-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
+obj-$(CONFIG_TOUCHSCREEN_SX8654) += sx8654.o
obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
diff --git a/drivers/input/touchscreen/sx8654.c
b/drivers/input/touchscreen/sx8654.c
new file mode 100644
index 000..58cc478
--- /dev/null
+++ b/drivers/input/touchscreen/sx8654.c
@@ -0,0 +1,285 @@
+/*
+ * drivers/input/touchscreen/sx8654.c
+ *
+ * Copyright (c) 2015 Armadeus Systems
+ * Sébastien Szymanski
+ *
+ * Using code from:
+ * - sx865x.c
+ * Copyright (c) 2013 U-MoBo Srl
+ * Pierluigi Passaro
+ * - sx8650.c
+ * Copyright (c) 2009 Wayne Roberts
+ * - tsc2007.c
+ * Copyright (c) 2008 Kwangwoo Lee
+ * - ads7846.c
+ * Copyright (c) 2005 David Brownell
+ * Copyright (c) 2006 Nokia Corporation
+ * - corgi_ts.c
+ * Copyright (C) 2004-2005 Richard Purdie
+ * - omap_ts.[hc], ads7846.h, ts_osk.c
+ * Copyright (C) 2002 MontaVista Software
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2005 Dirk Behme
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* register addresses */
+#define I2C_REG_TOUCH0 0x00
+#define I2C_REG_TOUCH1 0x01
+#define I2C_REG_CHANMASK 0x04
+#define I2C_REG_IRQMASK0x22
+#define I2C_REG_IRQSRC 0x23
+#define I2C_REG_SOFTRESET 0x3f
+
+/* commands */
+#define CMD_READ_REGISTER 0x40
+#define CMD_MANUAL 0xc0
+#define CMD_PENTRG 0xe0
+
+/* value for I2C_REG_SOFTRESET */
+#define SOFTRESET_VALUE0xde
+
+/* bits for I2C_REG_IRQSRC */
+#define IRQ_PENTOUCH_TOUCHCONVDONE 0x08
+#define IRQ_PENRELEASE 0x04
+
+/* bits for RegTouch1 */
+#define CONDIRQ0x20
+#define FILT_7SA 0x03
+
+/* bits for I2C_REG_CHANMASK */
+#define CONV_X 0x80
+#define CONV_Y 0x40
+
+/* coordinates rate: higher nibble of CTRL0 register */
+#define RATE_MANUAL0x00
+#define RATE_5000CPS 0xf0
+
+/* power delay: lower nibble of CTRL0 register */
+#define POWDLY_1_1MS 0x0b
+
+#define MAX_12BIT ((1 << 12) - 1)
+
+struct sx8654 {
+ struct input_dev *input;
+ struct i2c_client *client;
+};
+
+static irqreturn_t sx8654_irq(int irq, void *handle)
+{
+ struct sx8654 *sx8654 = handle;
+ u8 irqsrc;
+ u8 data[4];
+ unsigned int x, y;
+ int retval;
+
+ irqsrc = i2c_smbus_read_byte_data(sx8654->client,
+ (CMD_READ_REGISTER | I2C_REG_IRQSRC));
+ dev_dbg(&sx8654->client->dev, "irqsrc = 0x%x", irqsrc);
+
+ if (irqsrc < 0)
+ goto out;
+
+ if (irqsrc & IRQ_PENRELEASE) {
+ dev_dbg(&sx8654->client->dev, "pen release interrupt");
+
+ input_report_key(sx8654->input, BTN_TOUCH, 0);
+ input_sync(sx8654->input);
+ }
+
+ if (irqsrc & IRQ_PENTOUCH_TOUCHCONVDONE) {
+ dev_dbg(&sx8654->client->dev, "pen touch interrupt");
+
+
Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
On Mar 6, 2015, at 1:15 PM, Olof Johansson wrote: > On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala wrote: >> >> On Mar 5, 2015, at 7:59 PM, Olof Johansson wrote: >> >>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala wrote: On Mar 5, 2015, at 1:42 PM, Kevin Hilman wrote: > Kumar Gala writes: > >> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders >> on Qualcomm MSM platforms to determine which device tree should be >> utilized and passed to the kernel. >> >> Cc: >> Signed-off-by: Kumar Gala > > Is this the special magic that allows qcom bootloaders to take a kernel > plus multiple DTBs and figure out which DTB to pass? > > Kevin yes >>> >>> That's a bummer. >>> >>> Luckily, the solution for upstream is still quite simple: Provide only >>> one devicetree, and it'll be used, right? >> >> We can provide only one, we still need the IDs in the DT. > > How are the DTS provided? Concatenated with the kernel, or in a > wrapped data format? Or in a separate partition from the kernel? Its a wrapped data format that is than concatenated with the kernel if I remember correctly. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] mailbox: Enable BCM2835 mailbox support
On 03/06/2015 01:00 PM, Eric Anholt wrote:
Stephen Warren writes:
On 03/04/2015 11:20 AM, Eric Anholt wrote:
Stephen Warren writes:
On 03/02/2015 01:54 PM, Eric Anholt wrote:
From: Lubomir Rintel
Implement BCM2835 mailbox support as a device registered with
the general purpose mailbox framework. Implementation based on
commits by Lubomir Rintel [1], Suman Anna and Jassi Brar [2] on
which to base the implementation.
diff --git a/drivers/mailbox/bcm2835-mailbox.c
b/drivers/mailbox/bcm2835-mailbox.c
+static irqreturn_t bcm2835_mbox_irq(int irq, void *dev_id) +{
+ struct bcm2835_mbox *mbox = (struct bcm2835_mbox *) dev_id; +
struct device *dev = mbox->dev; + + while (!(readl(mbox->regs +
MAIL0_STA) & ARM_MS_EMPTY)) { + u32 msg = readl(mbox->regs +
MAIL0_RD); +unsigned int chan = MBOX_CHAN(msg); + + if
(!mbox->channel[chan].started) { + dev_err(dev, "Reply on
stopped channel %d\n", chan); +continue; + } +
dev_dbg(dev, "Reply 0x%08X\n", msg); +
mbox_chan_received_data(mbox->channel[chan].link, + (void *)
MBOX_DATA28(msg)); +} + rmb(); /* Finished last mailbox read.
*/
I know the PDF mentioned in the comment earlier in the patch says
to put in barriers between accesses to different peripherals,
which this seems compliant with, but I don't see quite what this
barrier achieves. I think the PDF is talking generalities, not
imposing a rule that must be blindly followed. Besides, if
there's a context-switch you can't actually implement the rules
the PDF suggests. What read operation is this barrier attempting
to ensure happens after reading all mailbox messages and any
associated DRAM buffer?
Looking at this bit of code in particular:
"As interrupts can appear anywhere in the code so you should
safeguard those. If an interrupt routine reads from a peripheral
the routine should start with a memory read barrier. If an
interrupt routine writes to a peripheral the routine should end
with a memory write barrier."
I can see that doing that would be safe, but I don't think following
those rules is actually necessary in the general case. Following those
rules would cause lots of unnecessary barriers in code.
Barriers shouldn't be used arbitrarily at the start/end of ISRs, but
rather at specific chosen locations in the code that actually need to
enforce some kind of memory ordering.
According to the architecture docs, if you don't RMB at the start of
your ISR, then the following timeline could get the wrong values:
Which architecture doc and section/... specifically?
some other device driver our isr
---
rmb()
read from device
read from device
examine value read
exit isr
examine value raed.
The ISR could get the device driver's value. This is made explicit in
footnote 2 on page 7.
Are you saying that the "read from device" in the right -hand "our isr"
column could end up returning the value actually read during "read from
device" in the left-hand "some other device driver" column, or vice-versa?
That doesn't make any sense.
Barriers are about ensuring that accesses happen (are visible or
complete) in the desired order, not about ensuring that the results of
two unrelated reads don't get swapped.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: dt: at91: new binding
> On Mar 6, 2015, at 11:08 PM, Nicolas Ferre wrote:
>
> Le 26/02/2015 10:34, Jean-Christophe PLAGNIOL-VILLARD a écrit :
>> Today if we want to disable a pio bank we may will siliently break pinctrl
>> configuration in the DT. This will be detected only at runtime.
>>
>> So move the pinctrl configuration to the bank instead of the bus.
>> This allow to detect pinctrl issue at DT compiling time when disable a bank.
>>
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
>> Cc: Linus Walleij
>> Cc: devicetree@vger.kernel.org
>> ---
>> .../bindings/pinctrl/atmel,at91-pinctrl.txt| 66
>> ++
>> 1 file changed, 66 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
>> b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
>> index b7a93e8..78355ee 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
>> @@ -148,3 +148,69 @@ dbgu: serial@f200 {
>> pinctrl-0 = <&pinctrl_dbgu>;
>> status = "disabled";
>> };
>> +
>> +II) New Bindings per PIO Block
>
> Sorry but NACK.
>
> I don't want to manage another flavor of the pinmux biding with no real
> benefit. I would have been good if we had it from day-1. Now it's too late.
yes we do, we catch but a compiling time instead of RUNTIME which is critical
so I’ll pass on the NACK
>
> Moreover, splitting a binding definition if you have a function given by
> multiple banks can be weird and not well understood in regard to our
> current group+function definition scheme (Cf. your last example).
>
Others already do so and this is not complex at all
Best Regards,
J.
>
>> +This allow to detect pinctrl issue at DT compiling time when disable a bank
>> +
>> +Required properties for iomux controller:
>> +- compatible: "atmel,at91rm9200-pio-pinctrl" or
>> "atmel,at91sam9x5-pio-pinctrl"
>> +or "atmel,sama5d3-pio-pinctrl"
>> +- atmel,mux-mask: array of mask (periph per bank) to describe if a pin can
>> be
>> + configured in this periph mode. All the periph and bank need to be
>> describe.
>> +
>> +How to create such array:
>> +
>> +Each column will represent the possible peripheral of the pinctrl for the
>> bank
>> +
>> +Take an example on the 9260
>> +Peripheral: 2 ( A and B)
>> +=>
>> +
>> + /*A B */
>> + 0x 0xffc00c3b /* pioA */
>> +
>> +For each peripheral/bank we will descibe in a u32 if a pin can be
>> +configured in it by putting 1 to the pin bit (1 << pin)
>> +
>> +Required properties for pin configuration node:
>> +- atmel,pins: 3 integers array, represents a group of pins mux and config
>> + setting. The format is atmel,pins = .
>> + The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
>> +
>> +Bits used for CONFIG:
>> +cf atmel,at91-pinctrl
>> +
>> +pioB: gpio@f600 {
>> +compatible = "atmel,at91rm9200-gpio", "atmel,at91rm9200-pio-pinctrl";
>> +reg = <0xf600 0x200>;
>> +interrupts = <3 IRQ_TYPE_LEVEL_HIGH 1>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +clocks = <&pioB_clk>;
>> +
>> + /*A B */
>> +atmel,mux-mask = <0x 0x7fff3ccf>;
>> +
>> +dbgu {
>> +pinctrl_dbgu: dbgu-0 {
>> +atmel,pins =
>> +<14 0x1 0x0 /* PB14 periph A */
>> + 15 0x1 0x1>; /* PB15 periph A with pullup */
>> +};
>> +};
>> +};
>> +
>> +dbgu: serial@f200 {
>> +compatible = "atmel,at91sam9260-usart";
>> +reg = <0xf200 0x200>;
>> +interrupts = <1 4 7>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&pinctrl_dbgu>;
>> +status = "disabled";
>> +};
>> +
>> +if you have to use multiple bank
>> +pinctrl-0 = <&pinctrl_ip_piaa>, <&pinctrl_ip_piab>;
>>
>
> Best regards,
> --
> Nicolas Ferre
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] net/macb: merge at91_ether driver into macb driver
From: Boris Brezillon Date: Fri, 6 Mar 2015 11:48:39 +0100 > Changes since v2: > - rebase after changed brought by [1] Ugh, actually I'm tossing all of your changes. Please do not make complex dependencies like this. And furthermore, don't reference other sets of changes via lkml postings. Reference them by where they are in patchwork which is the definitive location for networking patch submissions. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] net/macb: merge at91_ether driver into macb driver
From: Boris Brezillon Date: Fri, 6 Mar 2015 07:13:57 +0100 > The rm9200 boards use the dedicated at91_ether driver instead of the > regular macb driver. > > Both the macb and at91_ether drivers can be compiled as separated > modules. > Since the at91_ether driver uses code from the macb driver, at91_ether.ko > depends on macb.ko. > > However the macb.ko module always fails to load on rm9200 boards: the > macb_probe() function expects a hclk clock which doesn't exist on rm9200. > Then the at91_ether.ko can't be loaded in turn due to unresolved > dependencies. > > This series of patches fix this issue by merging at91_ether into macb. Series applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/6] clk: add of_clk_get_parent_rate function
Hi Mike, On 3/6/2015 11:55 AM, Mike Turquette wrote: > Quoting Sascha Hauer (2015-02-26 00:43:19) >> On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote: >>> On 2/25/2015 10:51 PM, Sascha Hauer wrote: On Wed, Feb 25, 2015 at 10:13:15PM -0800, Ray Jui wrote: > Hi Sascha, > > On 2/25/2015 9:54 PM, Sascha Hauer wrote: >> Hi Ray, >> >> On Wed, Feb 04, 2015 at 04:55:00PM -0800, Ray Jui wrote: >>> Sometimes a clock needs to know the rate of its parent before itself is >>> registered to the framework. An example is that a PLL may need to >>> initialize itself to a specific VCO frequency, before registering to the >>> framework. The parent rate needs to be known, for PLL multipliers and >>> divisors to be configured properly. >>> >>> Introduce helper function of_clk_get_parent_rate, which can be used to >>> obtain the parent rate of a clock, given a device node and index. >> >> I can't see how this patch helps you. First it's not guaranteed that >> the parent is already registered, what do you do in this case? > > In the case when clock parent is not found, as you can see from the > code, it simply returns zero, just like other clk get rate APIs. Yes, but what do you do with the 0 result then in your PLL initialization? >>> >>> As of the current code, it fails the PLL frequency initialization and >>> bails out. Thinking about it more, it actually makes more sense to just >>> warn and still go ahead to register the clock, in which case it will use >>> whatever default frequency after chip power on reset or a frequency >>> configured in the bootloader. >>> > > I thought the order of clock registration is based on order of the clock > nodes in device tree. It makes sense to me to declare the parent clock > before a child clock, so it's guaranteed that the parent is registered > before the child. No, you can't rely on that. The order of the device nodes may happen to define the order of clock initialization now, but that may change. device nodes are usually ordered by bus addresses, not by intended initialization order. Even if you reorder them everything must still work. >>> >>> Okay I get your point that the order of device nodes may not be relied >>> on for device initialization order. But then another mechanism should be >>> deployed to give developers the option to decide on the clock >>> initialization sequence. It can be optional but it should be there. >>> > >> Then the clock framework doesn't require that you initialize the PLL >> before registering. That can be done in the clk ops later. > > Sure it's not mandatory. But what's wrong with me choosing to initialize > the PLL clock to a known frequency before registering it to the framework? Appearantly you don't know the (input) frequency of the PLL when registering it to the framework, so the question must be: What's wrong with keeping it uninitialized? If the PLL is unused then you don't care about it's initialization status. If it happens to be enabled by a bootloader and still unused at late_initcall time the clock framework will disable it so you have a known state then. If a consumer for the PLL appears it's its job to initialize it through the clk api. Sascha >>> >>> Okay, what we need here is to initialize the PLL to a desired frequency, >>> based on device tree settings (since it will be configured differently, >>> among different boards). This is a PLL that 1) has limited options of >>> frequencies which it can be configured to, and 2) has multiple child >>> clocks, where is a more suitable place to initialize it to the desired >>> frequency than right before registering it to the framework? I know a >>> lot of people do it in the bootloader, but I thought we should be given >>> the flexibility of configuring it in the kernel. >>> >>> When you say "consumers", do you mean 1) the device driver that uses the >>> PLL; or 2) the device driver that use the child clock of the PLL? If >>> it's case 1), then we don't really have a device driver that directly >>> uses the PLL, and I thought that's quite normal, as most PLLs don't >>> directly feed into any peripherals. >> >> I meant 1) and 2). Before a consumer comes along the state of the PLL >> doesn't matter. When a consumer shows up it has to call >> clk_prepare_enable which (directly or indirectly) will enable your PLL. >> Then it's still time to apply the default settings you found out during >> probe of the PLL. > > My review comments are really for iproc_pll_setup() in patch #3, but the > discussion is here so I'll respond to this thread. > > I think the root of this problem is that your pll clk_ops does not > support .set_rate. That is why your clock driver hacks in a call to > pll_set_rate in iproc_pll_setup. > > Due to the above shortcoming you also d
Re: [PATCH 02/10] mailbox: Enable BCM2835 mailbox support
Stephen Warren writes:
> On 03/04/2015 11:20 AM, Eric Anholt wrote:
>> Stephen Warren writes:
>>
>>> On 03/02/2015 01:54 PM, Eric Anholt wrote:
From: Lubomir Rintel
Implement BCM2835 mailbox support as a device registered with
the general purpose mailbox framework. Implementation based on
commits by Lubomir Rintel [1], Suman Anna and Jassi Brar [2] on
which to base the implementation.
>>>
diff --git a/drivers/mailbox/bcm2835-mailbox.c
b/drivers/mailbox/bcm2835-mailbox.c
>
+static irqreturn_t bcm2835_mbox_irq(int irq, void *dev_id) +{
+ struct bcm2835_mbox *mbox = (struct bcm2835_mbox *) dev_id; +
struct device *dev = mbox->dev; + +while (!(readl(mbox->regs +
MAIL0_STA) & ARM_MS_EMPTY)) { +u32 msg = readl(mbox->regs +
MAIL0_RD); + unsigned int chan = MBOX_CHAN(msg); + +
if
(!mbox->channel[chan].started) { + dev_err(dev, "Reply on
stopped channel %d\n", chan); +continue; +
} +
dev_dbg(dev, "Reply 0x%08X\n", msg); +
mbox_chan_received_data(mbox->channel[chan].link, +
(void *)
MBOX_DATA28(msg)); + } + rmb(); /* Finished last mailbox read.
*/
>>>
>>> I know the PDF mentioned in the comment earlier in the patch says
>>> to put in barriers between accesses to different peripherals,
>>> which this seems compliant with, but I don't see quite what this
>>> barrier achieves. I think the PDF is talking generalities, not
>>> imposing a rule that must be blindly followed. Besides, if
>>> there's a context-switch you can't actually implement the rules
>>> the PDF suggests. What read operation is this barrier attempting
>>> to ensure happens after reading all mailbox messages and any
>>> associated DRAM buffer?
>>
>> Looking at this bit of code in particular:
>>
>> "As interrupts can appear anywhere in the code so you should
>> safeguard those. If an interrupt routine reads from a peripheral
>> the routine should start with a memory read barrier. If an
>> interrupt routine writes to a peripheral the routine should end
>> with a memory write barrier."
>
> I can see that doing that would be safe, but I don't think following
> those rules is actually necessary in the general case. Following those
> rules would cause lots of unnecessary barriers in code.
>
> Barriers shouldn't be used arbitrarily at the start/end of ISRs, but
> rather at specific chosen locations in the code that actually need to
> enforce some kind of memory ordering.
According to the architecture docs, if you don't RMB at the start of
your ISR, then the following timeline could get the wrong values:
some other device driver our isr
---
rmb()
read from device
read from device
examine value read
exit isr
examine value raed.
The ISR could get the device driver's value. This is made explicit in
footnote 2 on page 7.
>> So it seems like the IRQ handler at least wants:
>>
>> diff --git a/drivers/mailbox/bcm2835-mailbox.c
>> b/drivers/mailbox/bcm2835-mailbox.c index 604beb7..7e528f6 100644
>> --- a/drivers/mailbox/bcm2835-mailbox.c +++
>> b/drivers/mailbox/bcm2835-mailbox.c @@ -88,6 +88,13 @@ static
>> irqreturn_t bcm2835_mbox_irq(int irq, void *dev_id) struct
>> bcm2835_mbox *mbox = (struct bcm2835_mbox *) dev_id; struct device
>> *dev = mbox->dev;
>>
>> +/* + * BCM2835-ARM-Peripherals.pdf says "If an interrupt
>> routine + * reads from a peripheral the routine should start with
>> a + * memory read barrier." + */ + rmb(); + while
>> (!(readl(mbox->regs + MAIL0_STA) & ARM_MS_EMPTY)) { u32 msg =
>> readl(mbox->regs + MAIL0_RD); unsigned int chan = MBOX_CHAN(msg);
>> @@ -100,7 +107,6 @@ static irqreturn_t bcm2835_mbox_irq(int irq,
>> void *dev_id) mbox_chan_received_data(mbox->channel[chan].link,
>> (void *) MBOX_DATA28(msg)); } - rmb(); /* Finished last mailbox
>> read. */ return IRQ_HANDLED; }
>
> In this case, I don't think neither the original barrier is needed,
> nor the extra one you added.
Your formatting got completely destroyed here.
signature.asc
Description: PGP signature
Re: [PATCH v5 1/6] clk: add of_clk_get_parent_rate function
Quoting Sascha Hauer (2015-02-26 00:43:19) > On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote: > > On 2/25/2015 10:51 PM, Sascha Hauer wrote: > > > On Wed, Feb 25, 2015 at 10:13:15PM -0800, Ray Jui wrote: > > >> Hi Sascha, > > >> > > >> On 2/25/2015 9:54 PM, Sascha Hauer wrote: > > >>> Hi Ray, > > >>> > > >>> On Wed, Feb 04, 2015 at 04:55:00PM -0800, Ray Jui wrote: > > Sometimes a clock needs to know the rate of its parent before itself is > > registered to the framework. An example is that a PLL may need to > > initialize itself to a specific VCO frequency, before registering to > > the > > framework. The parent rate needs to be known, for PLL multipliers and > > divisors to be configured properly. > > > > Introduce helper function of_clk_get_parent_rate, which can be used to > > obtain the parent rate of a clock, given a device node and index. > > >>> > > >>> I can't see how this patch helps you. First it's not guaranteed that > > >>> the parent is already registered, what do you do in this case? > > >> > > >> In the case when clock parent is not found, as you can see from the > > >> code, it simply returns zero, just like other clk get rate APIs. > > > > > > Yes, but what do you do with the 0 result then in your PLL initialization? > > > > > > > As of the current code, it fails the PLL frequency initialization and > > bails out. Thinking about it more, it actually makes more sense to just > > warn and still go ahead to register the clock, in which case it will use > > whatever default frequency after chip power on reset or a frequency > > configured in the bootloader. > > > > >> > > >> I thought the order of clock registration is based on order of the clock > > >> nodes in device tree. It makes sense to me to declare the parent clock > > >> before a child clock, so it's guaranteed that the parent is registered > > >> before the child. > > > > > > No, you can't rely on that. The order of the device nodes may happen to > > > define the order of clock initialization now, but that may change. > > > device nodes are usually ordered by bus addresses, not by intended > > > initialization order. Even if you reorder them everything must still > > > work. > > > > > > > Okay I get your point that the order of device nodes may not be relied > > on for device initialization order. But then another mechanism should be > > deployed to give developers the option to decide on the clock > > initialization sequence. It can be optional but it should be there. > > > > >> > > >>> Then the clock framework doesn't require that you initialize the PLL > > >>> before registering. That can be done in the clk ops later. > > >> > > >> Sure it's not mandatory. But what's wrong with me choosing to initialize > > >> the PLL clock to a known frequency before registering it to the > > >> framework? > > > > > > Appearantly you don't know the (input) frequency of the PLL when > > > registering it to the framework, so the question must be: What's wrong > > > with keeping it uninitialized? > > > > > > If the PLL is unused then you don't care about it's initialization > > > status. If it happens to be enabled by a bootloader and still unused > > > at late_initcall time the clock framework will disable it so you > > > have a known state then. If a consumer for the PLL appears it's its > > > job to initialize it through the clk api. > > > > > > Sascha > > > > > > > Okay, what we need here is to initialize the PLL to a desired frequency, > > based on device tree settings (since it will be configured differently, > > among different boards). This is a PLL that 1) has limited options of > > frequencies which it can be configured to, and 2) has multiple child > > clocks, where is a more suitable place to initialize it to the desired > > frequency than right before registering it to the framework? I know a > > lot of people do it in the bootloader, but I thought we should be given > > the flexibility of configuring it in the kernel. > > > > When you say "consumers", do you mean 1) the device driver that uses the > > PLL; or 2) the device driver that use the child clock of the PLL? If > > it's case 1), then we don't really have a device driver that directly > > uses the PLL, and I thought that's quite normal, as most PLLs don't > > directly feed into any peripherals. > > I meant 1) and 2). Before a consumer comes along the state of the PLL > doesn't matter. When a consumer shows up it has to call > clk_prepare_enable which (directly or indirectly) will enable your PLL. > Then it's still time to apply the default settings you found out during > probe of the PLL. My review comments are really for iproc_pll_setup() in patch #3, but the discussion is here so I'll respond to this thread. I think the root of this problem is that your pll clk_ops does not support .set_rate. That is why your clock driver hacks in a call to pll_set_rate in iproc_pll_setup. Due to the above shortcoming you
Re: [PATCH] regulator: act8865: Add act8600 support
On Fri, Feb 27, 2015 at 05:04:04PM +, Zubair Lutfullah Kakakhel wrote: > This patch adds act8600 support to the act8865 driver. > > VBUS and USB charger supported by this chip can be added later > > Tested on MIPS Creator CI20 Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 00/10] omap3 crypto fixes
* Pali Rohár [150306 11:16]: > On Friday 06 March 2015 19:36:32 Tony Lindgren wrote: > > * Pali Rohár [150226 05:54]: > > > This patch series fix crypto support for omap3 devices which > > > use DT. > > > > > > It enables AES and SHAM on N9/N950 and SHAM on N900. AES is > > > still disabled for N900. > > > > > > Pali Rohár (10): > > > ARM: OMAP2+: Return correct error values from device and > > > hwmod ARM: OMAP3: Fix crypto support for HS devices > > > crypto: omap-sham: Add support for omap3 devices > > > crypto: omap-sham: Check for return value from > > > pm_runtime_get_sync ARM: dts: omap3 hs: Remove timer12 > > > ARM: dts: omap3: Add missing dmas for crypto > > > ARM: dts: n9/n950: Enable omap crypto support > > > ARM: dts: n900: Enable omap sham and include directly > > > omap34xx.dtsi ARM: dts: omap3-tao3530: Include directly > > > omap34xx.dtsi ARM: dts: Remove files omap34xx-hs.dtsi and > > > omap36xx-hs.dtsi > > > > > > arch/arm/boot/dts/omap3-n900.dts | 16 +- > > > arch/arm/boot/dts/omap3-n950-n9.dtsi |2 +- > > > arch/arm/boot/dts/omap3-tao3530.dtsi | 11 +++- > > > arch/arm/boot/dts/omap3.dtsi |4 ++ > > > arch/arm/boot/dts/omap34xx-hs.dtsi | 16 -- > > > arch/arm/boot/dts/omap36xx-hs.dtsi | 16 -- > > > arch/arm/mach-omap2/omap_device.c | 30 > > > ++- arch/arm/mach-omap2/omap_hwmod.c | > > > 10 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 79 > > > +++- drivers/crypto/omap-sham.c > > > | 13 - 10 files changed, 131 > > > insertions(+), 66 deletions(-) delete mode 100644 > > > arch/arm/boot/dts/omap34xx-hs.dtsi delete mode 100644 > > > arch/arm/boot/dts/omap36xx-hs.dtsi > > > > Are there any fixes in this series that should go into > > v4.0-rc series, or can it all wait for v4.1? > > > > Regards, > > > > Tony > > I do not know which patches are you sending to 4.0-rc series, but > omap crypto is totally broken in linus tree for both GP & HS > omap3 devices when DT booting is used. This patch series fix that > problem. OK so the whole series is needed then. It seems too intrusive for the v4.0-rc series unless this fixes a regression with some earlier commit. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][ASoC]Add DT bindings for generic ASoC AC97 CODEC driver
Add and document DT bindings for generic ASoC AC97 CODEC driver,
make it selectable in config.
Signed-off-by: Maciej Szmigiero
diff --git a/Documentation/devicetree/bindings/sound/ac97-generic-codec.txt
b/Documentation/devicetree/bindings/sound/ac97-generic-codec.txt
new file mode 100644
index 000..ce98698
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ac97-generic-codec.txt
@@ -0,0 +1,24 @@
+Generic ASoC AC97 CODEC driver
+
+Allows using codecs supported by generic ALSA AC97 code as codecs in ASoC.
+
+Required properties:
+
+ - compatible : "linux,ac97-codec"
+
+Optional properties:
+
+ - playback-rates : A list of supported playback rates.
+
+ - capture-rates : A list of supported capture rates.
+
+In case one or both of above properties are missing the relevant rate(s) are
assumed
+to be 8000, 11025, 22050, 44100, 48000.
+
+Example:
+
+ac97codec: ac97-hifi {
+ compatible = "linux,ac97-codec";
+ playback-rates = <48000 44100 32000 24000 22050 16000 12000 11025 8000>;
+ capture-rates = <48000>;
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0bddd92..92d6d39 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -16,7 +16,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_88PM860X if MFD_88PM860X
select SND_SOC_L3
select SND_SOC_AB8500_CODEC if ABX500_CORE
- select SND_SOC_AC97_CODEC if SND_SOC_AC97_BUS
+ select SND_SOC_AC97_CODEC
select SND_SOC_AD1836 if SPI_MASTER
select SND_SOC_AD193X_SPI if SPI_MASTER
select SND_SOC_AD193X_I2C if I2C
@@ -210,8 +210,9 @@ config SND_SOC_AB8500_CODEC
tristate
config SND_SOC_AC97_CODEC
- tristate
+ tristate "Build generic ASoC AC97 CODEC driver"
select SND_AC97_CODEC
+ select SND_SOC_AC97_BUS
config SND_SOC_AD1836
tristate
diff --git a/sound/soc/codecs/ac97.c b/sound/soc/codecs/ac97.c
index d0ac723..25125bf 100644
--- a/sound/soc/codecs/ac97.c
+++ b/sound/soc/codecs/ac97.c
@@ -23,6 +23,12 @@
#include
#include
+struct ac97_private {
+ struct snd_ac97 *ac97;
+ struct snd_pcm_hw_constraint_list playback_rate_constraints;
+ struct snd_pcm_hw_constraint_list capture_rate_constraints;
+};
+
static const struct snd_soc_dapm_widget ac97_widgets[] = {
SND_SOC_DAPM_INPUT("RX"),
SND_SOC_DAPM_OUTPUT("TX"),
@@ -33,22 +39,41 @@ static const struct snd_soc_dapm_route ac97_routes[] = {
{ "TX", NULL, "AC97 Playback" },
};
+static const unsigned int default_rates[] = {
+ 8000, 11025, 22050, 44100, 48000
+};
+
+static int ac97_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec);
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ snd_pcm_hw_constraint_list(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ &ac97->playback_rate_constraints);
+ else
+ snd_pcm_hw_constraint_list(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ &ac97->capture_rate_constraints);
+
+ return 0;
+}
+
static int ac97_prepare(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_codec *codec = dai->codec;
- struct snd_ac97 *ac97 = snd_soc_codec_get_drvdata(codec);
+ struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec);
int reg = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ?
AC97_PCM_FRONT_DAC_RATE : AC97_PCM_LR_ADC_RATE;
- return snd_ac97_set_rate(ac97, reg, substream->runtime->rate);
+ return snd_ac97_set_rate(ac97->ac97, reg, substream->runtime->rate);
}
-#define STD_AC97_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\
- SNDRV_PCM_RATE_22050 | SNDRV_PCM_RATE_44100 |\
- SNDRV_PCM_RATE_48000)
-
static const struct snd_soc_dai_ops ac97_dai_ops = {
+ .startup= ac97_startup,
.prepare= ac97_prepare,
};
@@ -58,20 +83,21 @@ static struct snd_soc_dai_driver ac97_dai = {
.stream_name = "AC97 Playback",
.channels_min = 1,
.channels_max = 2,
- .rates = STD_AC97_RATES,
+ .rates = SNDRV_PCM_RATE_KNOT,
.formats = SND_SOC_STD_AC97_FMTS,},
.capture = {
.stream_name = "AC97 Capture",
.channels_min = 1,
.channels_max = 2,
- .rates = STD_AC97_RATES,
+ .rates = SNDRV_PCM_RATE_KNOT,
.formats = SND_SOC_STD_AC97_FMTS,},
.ops = &ac97_dai_ops,
};
static int ac97_soc_probe(struct snd_soc_codec *codec)
{
- struct snd_ac97 *ac97;
+ struct ac97_private *ac97 = snd_soc_codec_get_drvdata(codec);
+
Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala wrote: > > On Mar 5, 2015, at 7:59 PM, Olof Johansson wrote: > >> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala wrote: >>> >>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman wrote: >>> Kumar Gala writes: > The top level qcom,msm-id and qcom,board-id are utilized by bootloaders > on Qualcomm MSM platforms to determine which device tree should be > utilized and passed to the kernel. > > Cc: > Signed-off-by: Kumar Gala Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass? Kevin >>> >>> yes >> >> That's a bummer. >> >> Luckily, the solution for upstream is still quite simple: Provide only >> one devicetree, and it'll be used, right? > > We can provide only one, we still need the IDs in the DT. How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel? -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] omap3 crypto fixes
On Friday 06 March 2015 19:36:32 Tony Lindgren wrote: > * Pali Rohár [150226 05:54]: > > This patch series fix crypto support for omap3 devices which > > use DT. > > > > It enables AES and SHAM on N9/N950 and SHAM on N900. AES is > > still disabled for N900. > > > > Pali Rohár (10): > > ARM: OMAP2+: Return correct error values from device and > > hwmod ARM: OMAP3: Fix crypto support for HS devices > > crypto: omap-sham: Add support for omap3 devices > > crypto: omap-sham: Check for return value from > > pm_runtime_get_sync ARM: dts: omap3 hs: Remove timer12 > > ARM: dts: omap3: Add missing dmas for crypto > > ARM: dts: n9/n950: Enable omap crypto support > > ARM: dts: n900: Enable omap sham and include directly > > omap34xx.dtsi ARM: dts: omap3-tao3530: Include directly > > omap34xx.dtsi ARM: dts: Remove files omap34xx-hs.dtsi and > > omap36xx-hs.dtsi > > > > arch/arm/boot/dts/omap3-n900.dts | 16 +- > > arch/arm/boot/dts/omap3-n950-n9.dtsi |2 +- > > arch/arm/boot/dts/omap3-tao3530.dtsi | 11 +++- > > arch/arm/boot/dts/omap3.dtsi |4 ++ > > arch/arm/boot/dts/omap34xx-hs.dtsi | 16 -- > > arch/arm/boot/dts/omap36xx-hs.dtsi | 16 -- > > arch/arm/mach-omap2/omap_device.c | 30 > > ++- arch/arm/mach-omap2/omap_hwmod.c | > > 10 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 79 > > +++- drivers/crypto/omap-sham.c > > | 13 - 10 files changed, 131 > > insertions(+), 66 deletions(-) delete mode 100644 > > arch/arm/boot/dts/omap34xx-hs.dtsi delete mode 100644 > > arch/arm/boot/dts/omap36xx-hs.dtsi > > Are there any fixes in this series that should go into > v4.0-rc series, or can it all wait for v4.1? > > Regards, > > Tony I do not know which patches are you sending to 4.0-rc series, but omap crypto is totally broken in linus tree for both GP & HS omap3 devices when DT booting is used. This patch series fix that problem. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 00/10] omap3 crypto fixes
* Pali Rohár [150226 05:54]: > This patch series fix crypto support for omap3 devices which use DT. > > It enables AES and SHAM on N9/N950 and SHAM on N900. AES is still disabled > for N900. > > Pali Rohár (10): > ARM: OMAP2+: Return correct error values from device and hwmod > ARM: OMAP3: Fix crypto support for HS devices > crypto: omap-sham: Add support for omap3 devices > crypto: omap-sham: Check for return value from pm_runtime_get_sync > ARM: dts: omap3 hs: Remove timer12 > ARM: dts: omap3: Add missing dmas for crypto > ARM: dts: n9/n950: Enable omap crypto support > ARM: dts: n900: Enable omap sham and include directly omap34xx.dtsi > ARM: dts: omap3-tao3530: Include directly omap34xx.dtsi > ARM: dts: Remove files omap34xx-hs.dtsi and omap36xx-hs.dtsi > > arch/arm/boot/dts/omap3-n900.dts | 16 +- > arch/arm/boot/dts/omap3-n950-n9.dtsi |2 +- > arch/arm/boot/dts/omap3-tao3530.dtsi | 11 +++- > arch/arm/boot/dts/omap3.dtsi |4 ++ > arch/arm/boot/dts/omap34xx-hs.dtsi | 16 -- > arch/arm/boot/dts/omap36xx-hs.dtsi | 16 -- > arch/arm/mach-omap2/omap_device.c | 30 ++- > arch/arm/mach-omap2/omap_hwmod.c | 10 ++-- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 79 > +++- > drivers/crypto/omap-sham.c | 13 - > 10 files changed, 131 insertions(+), 66 deletions(-) > delete mode 100644 arch/arm/boot/dts/omap34xx-hs.dtsi > delete mode 100644 arch/arm/boot/dts/omap36xx-hs.dtsi Are there any fixes in this series that should go into v4.0-rc series, or can it all wait for v4.1? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
Quoting Lee Jones (2015-03-04 04:00:03) > Mike, > > Do you want me to resend this set with Robert's Reviewed-by applied, > or are you happy to apply it yourself? No need for the resend. I am hoping for a final review from a DT human. This approach looks fine to me. In practice I think it is restricted to hardware blocks that don't exist in DT yet (e.g. no driver, in the case of your interconnect) and that restriction is probably for the best. Regards, Mike > > > v2 => v3: > > - Ensure DT actually reflects h/w > > - i.e. Nodes should not contain a mishmash of different IP > > blocks, but should identify related h/w. In the current > > example we use interconnects > > - Change naming from clkdomain to clk-always-on > > - Place "do not abuse" warning in documentation > > > > v1 => v2: > > - Turned the ST specific driver into a generic one > > > > Hardware can have a bunch of clocks which must not be turned off. > > If drivers a) fail to obtain a reference to any of these or b) give > > up a previously obtained reference during suspend, the common clk > > framework will attempt to turn them off and the hardware will > > subsequently die. The only way to recover from this failure is to > > restart. > > > > To avoid either of these two scenarios from catastrophically > > disabling the running system we have implemented a clock domain > > where clocks are consumed and references are taken, thus preventing > > them from being shut down by the framework. > > > > *** BLURB HERE *** > > > > Lee Jones (4): > > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > > ARM: sti: stih407-family: Add platform interconnects to always-on clk > > domain > > clk: Provide an always-on clock domain framework > > clk: dt: Introduce always-on clock domain documentation > > > > .../devicetree/bindings/clock/clk-always-on.txt| 35 > > arch/arm/boot/dts/stih407-family.dtsi | 15 ++ > > drivers/clk/Makefile | 1 + > > drivers/clk/clk-always-on.c| 62 > > ++ > > include/dt-bindings/clock/stih407-clks.h | 4 ++ > > 5 files changed, 117 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/clock/clk-always-on.txt > > create mode 100644 drivers/clk/clk-always-on.c > > > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] of: add optional options parameter to of_find_node_by_path()
On 03/06/2015 01:11 PM, Peter Hurley wrote:
> On 03/06/2015 11:52 AM, Leif Lindholm wrote:
[...]
>> Could you give the below a spin, and if it works for you, send me the
>> above tests as a full patch so that I can post both as a series?
>
> Will do as soon as I finish testing.
All passed with your patch; patch for testcases below.
Regards,
Peter Hurley
--- >% ---
From: Peter Hurley
Subject: [PATCH] of: unittest: Add options string testcase variants
Add testcase variants with '/' in the options string to test for
scan beyond end path name terminated by ':'.
Signed-off-by: Peter Hurley
---
drivers/of/unittest.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 0cf9a23..b2d7547 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -92,6 +92,11 @@ static void __init of_selftest_find_node_by_name(void)
"option path test failed\n");
of_node_put(np);
+ np = of_find_node_opts_by_path("/testcase-data:test/option", &options);
+ selftest(np && !strcmp("test/option", options),
+"option path test, subcase #1 failed\n");
+ of_node_put(np);
+
np = of_find_node_opts_by_path("/testcase-data:testoption", NULL);
selftest(np, "NULL option path test failed\n");
of_node_put(np);
@@ -102,6 +107,12 @@ static void __init of_selftest_find_node_by_name(void)
"option alias path test failed\n");
of_node_put(np);
+ np = of_find_node_opts_by_path("testcase-alias:test/alias/option",
+ &options);
+ selftest(np && !strcmp("test/alias/option", options),
+"option alias path test, subcase #1 failed\n");
+ of_node_put(np);
+
np = of_find_node_opts_by_path("testcase-alias:testaliasoption", NULL);
selftest(np, "NULL option alias path test failed\n");
of_node_put(np);
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Input: sx8654 - add device tree bindings
Signed-off-by: Sébastien Szymanski
---
.../devicetree/bindings/input/touchscreen/sx8654.txt | 16
1 file changed, 16 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
new file mode 100644
index 000..5aaa6b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
@@ -0,0 +1,16 @@
+* Semtech SX8654 I2C Touchscreen Controller
+
+Required properties:
+- compatible: must be "semtech,sx8654"
+- reg: i2c slave address
+- interrupt-parent: the phandle for the interrupt controller
+- interrupts: touch controller interrupt
+
+Example:
+
+ sx8654@48 {
+ compatible = "semtech,sx8654";
+ reg = <0x48>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ };
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pinctrl: Add Pistachio SoC pin control driver
On Fri, Mar 6, 2015 at 3:55 AM, Linus Walleij wrote:
> On Tue, Feb 24, 2015 at 3:15 AM, Andrew Bresticker
> wrote:
>
>> Add a driver for the pin controller present on the IMG Pistachio SoC.
>> This driver provides pinmux and pinconfig operations as well as GPIO
>> and IRQ chips for the GPIO banks.
>>
>> Signed-off-by: Damien Horsley
>> Signed-off-by: Govindraj Raja
>> Signed-off-by: Andrew Bresticker
>
> (...)
>> +static inline u32 pctl_readl(struct pistachio_pinctrl *pctl, u32 reg)
>> +{
>> + return readl(pctl->base + reg);
>> +}
>> +
>> +static inline void pctl_writel(struct pistachio_pinctrl *pctl, u32 val, u32
>> reg)
>> +{
>> + writel(val, pctl->base + reg);
>> +}
>> +
>> +static inline u32 gpio_readl(struct pistachio_gpio_bank *bank, u32 reg)
>> +{
>> + return readl(bank->base + reg);
>> +}
>> +
>> +static inline void gpio_writel(struct pistachio_gpio_bank *bank, u32 val,
>> + u32 reg)
>> +{
>> + writel(val, bank->base + reg);
>> +}
>
> I don't see the point of these special readl/writel accessors. Just
> use readl/writel
> directly. Or consider readl/writel_relaxed() if MIPS has this.
I actually find these useful for tracing MMIO accesses within a driver
and it seems many other drivers do this too. I can drop them though
if you'd prefer.
>> +static inline void gpio_mask_writel(struct pistachio_gpio_bank *bank,
>> + u32 reg, unsigned int bit, u32 val)
>> +{
>> + gpio_writel(bank, (0x1 | val) << bit, reg);
>> +}
>
> Magic mask? Some comment on what is happening here when OR:in
> on 0x1?
Sure.
> (...)
>> +static int pistachio_gpio_get_direction(struct gpio_chip *chip, unsigned
>> offset)
>> +{
>> + struct pistachio_gpio_bank *bank = gc_to_bank(chip);
>> +
>> + if (gpio_readl(bank, GPIO_OUTPUT_EN) & BIT(offset))
>> + return GPIOF_DIR_OUT;
>> + return GPIOF_DIR_IN;
>> +}
>
> These flags are not for the driver API.
>
> Do this:
>
> return !gpio_readl(bank, GPIO_OUTPUT_EN) & BIT(offset));
Ok.
> (...)
>> +static void pistachio_gpio_irq_handler(unsigned int irq, struct irq_desc
>> *desc)
>> +{
>> + struct gpio_chip *gc = irq_get_handler_data(irq);
>> + struct pistachio_gpio_bank *bank = gc_to_bank(gc);
>> + struct irq_chip *chip = irq_get_chip(irq);
>> + unsigned long pending;
>> + unsigned int pin, virq;
>
> Don't call it virq, just call it irq. All Linux irq numbers are virtual
> so just go with irq.
Ok.
> (...)
>> +static int pistachio_gpio_register(struct pistachio_pinctrl *pctl)
>> +{
>> + struct device_node *child, *node = pctl->dev->of_node;
>> + struct pistachio_gpio_bank *bank;
>> + unsigned int i = 0;
>> + int irq, ret = 0;
>> +
>> + for_each_child_of_node(node, child) {
>> + if (!of_find_property(child, "gpio-controller", NULL))
>> + continue;
>
> So why not instead specify "simple-bus" as compatible on the parent node
> and have each subnode be its own device (simple-bus will spawn platform
> devices for all subnodes).
>
> Overall this composite-device pattern is discouraged if we can instead have
> unique devices for each bank.
I think there's an issue here though if some other device probes
between the pinctrl driver and the gpiochip drivers. Since all these
pins are configured as GPIOs at POR, the pinctrl driver needs to clear
the GPIO enable bit on a pin when enabling a pinmux function for that
pin (see pistachio_pinmux_enable()). If the gpiochip driver has yet
to probe, attempting to map the pinctrl pin to a GPIO range/pin (via
pinctrl_find_gpio_range_from_pin()) will fail and we won't be able to
disable the GPIO function for that pin. Also it doesn't look like
there's a good way to tell gpiolib to disable a GPIO form the pinctrl
driver. Any ideas? I suppose I could keep the pin-to-GPIO mapping in
the pinctrl driver in addition to expressing it in the DT with
gpio-ranges, but that doesn't seem too nice.
> Apart from these things the driver looks very nice!
Thanks for the review!
-Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: dt: at91: new binding
> On Mar 7, 2015, at 2:23 AM, Boris Brezillon
> wrote:
>
> Hi Jean-Christophe,
>
> On Sat, 7 Mar 2015 00:49:55 +0800
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>
>>
>>> On Mar 6, 2015, at 11:08 PM, Nicolas Ferre wrote:
>>>
>>> Le 26/02/2015 10:34, Jean-Christophe PLAGNIOL-VILLARD a écrit :
Today if we want to disable a pio bank we may will siliently break pinctrl
configuration in the DT. This will be detected only at runtime.
So move the pinctrl configuration to the bank instead of the bus.
This allow to detect pinctrl issue at DT compiling time when disable a
bank.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
Cc: Linus Walleij
Cc: devicetree@vger.kernel.org
---
.../bindings/pinctrl/atmel,at91-pinctrl.txt| 66
++
1 file changed, 66 insertions(+)
diff --git
a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index b7a93e8..78355ee 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -148,3 +148,69 @@ dbgu: serial@f200 {
pinctrl-0 = <&pinctrl_dbgu>;
status = "disabled";
};
+
+II) New Bindings per PIO Block
>>>
>>> Sorry but NACK.
>>>
>>> I don't want to manage another flavor of the pinmux biding with no real
>>> benefit. I would have been good if we had it from day-1. Now it's too late.
>>
>> yes we do, we catch but a compiling time instead of RUNTIME which is critical
>>
>> so I’ll pass on the NACK
>
> Tell me, how can you pass on a NACK coming from the at91 maintainer
> (which is also your co-maintainer) when you modify bindings of an at91
> driver ?
> Please let's try to be constructive here, so that we can find an
> acceptable solution.
I do pass on it which means, I do not accept to stop here the discussion
because of this
as Nicolas did for dropping the soc detection when I NACK
>
>>
>>>
>>> Moreover, splitting a binding definition if you have a function given by
>>> multiple banks can be weird and not well understood in regard to our
>>> current group+function definition scheme (Cf. your last example).
>>>
>
> I don't think it's a good idea either: you'll have to split pinconf
> definitions and that definitely doesn't improve readability.
in HW it’s already the CASE. And today disable a bank you BROKE a board without
even known it. This is NOT acceptable when we can detect it at compiling TIME.
>
>>
>> Others already do so and this is not complex at all
>
> Could you point out these bindings (and real examples please).
look at ST-E 9500 pinctrl they DO use it
>
> Best Regards,
>
> Boris
>
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: dt: at91: new binding
Hi Jean-Christophe,
On Sat, 7 Mar 2015 00:49:55 +0800
Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> > On Mar 6, 2015, at 11:08 PM, Nicolas Ferre wrote:
> >
> > Le 26/02/2015 10:34, Jean-Christophe PLAGNIOL-VILLARD a écrit :
> >> Today if we want to disable a pio bank we may will siliently break pinctrl
> >> configuration in the DT. This will be detected only at runtime.
> >>
> >> So move the pinctrl configuration to the bank instead of the bus.
> >> This allow to detect pinctrl issue at DT compiling time when disable a
> >> bank.
> >>
> >> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> >> Cc: Linus Walleij
> >> Cc: devicetree@vger.kernel.org
> >> ---
> >> .../bindings/pinctrl/atmel,at91-pinctrl.txt| 66
> >> ++
> >> 1 file changed, 66 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> index b7a93e8..78355ee 100644
> >> --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> @@ -148,3 +148,69 @@ dbgu: serial@f200 {
> >>pinctrl-0 = <&pinctrl_dbgu>;
> >>status = "disabled";
> >> };
> >> +
> >> +II) New Bindings per PIO Block
> >
> > Sorry but NACK.
> >
> > I don't want to manage another flavor of the pinmux biding with no real
> > benefit. I would have been good if we had it from day-1. Now it's too late.
>
> yes we do, we catch but a compiling time instead of RUNTIME which is critical
>
> so I’ll pass on the NACK
Tell me, how can you pass on a NACK coming from the at91 maintainer
(which is also your co-maintainer) when you modify bindings of an at91
driver ?
Please let's try to be constructive here, so that we can find an
acceptable solution.
>
> >
> > Moreover, splitting a binding definition if you have a function given by
> > multiple banks can be weird and not well understood in regard to our
> > current group+function definition scheme (Cf. your last example).
> >
I don't think it's a good idea either: you'll have to split pinconf
definitions and that definitely doesn't improve readability.
>
> Others already do so and this is not complex at all
Could you point out these bindings (and real examples please).
Best Regards,
Boris
--
Boris Brezillon, 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add support for Semtech SX8654 I2C touchscreen controller
On Fri, Mar 06, 2015 at 07:21:38PM +0100, Sébastien Szymanski wrote:
> Signed-off-by: Sébastien Szymanski
> ---
> drivers/input/touchscreen/Kconfig | 11 ++
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/sx8654.c | 285
> +
> 3 files changed, 297 insertions(+)
> create mode 100644 drivers/input/touchscreen/sx8654.c
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 5891752..6f713fd0 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -961,6 +961,17 @@ config TOUCHSCREEN_SUR40
> To compile this driver as a module, choose M here: the
> module will be called sur40.
>
> +config TOUCHSCREEN_SX8654
> + tristate "Semtech SX8654 touchscreen"
> + depends on I2C && OF
Does it have to depend on OF? I do not see anything OF-specific there...
No need to resumbit.
> + help
> + Say Y here if you have a Semtech SX8654 touchscreen controller.
> +
> + If unsure, say N
> +
> + To compile this driver as a module, choose M here: the
> + module will be called sx8654.
> +
> config TOUCHSCREEN_TPS6507X
> tristate "TPS6507x based touchscreens"
> depends on I2C
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index 0242fea..a06a752 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -79,5 +79,6 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL) +=
> atmel-wm97xx.o
> obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE) += mainstone-wm97xx.o
> obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)+= zylonite-wm97xx.o
> obj-$(CONFIG_TOUCHSCREEN_W90X900)+= w90p910_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_SX8654) += sx8654.o
> obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
> diff --git a/drivers/input/touchscreen/sx8654.c
> b/drivers/input/touchscreen/sx8654.c
> new file mode 100644
> index 000..58cc478
> --- /dev/null
> +++ b/drivers/input/touchscreen/sx8654.c
> @@ -0,0 +1,285 @@
> +/*
> + * drivers/input/touchscreen/sx8654.c
> + *
> + * Copyright (c) 2015 Armadeus Systems
> + * Sébastien Szymanski
> + *
> + * Using code from:
> + * - sx865x.c
> + * Copyright (c) 2013 U-MoBo Srl
> + * Pierluigi Passaro
> + * - sx8650.c
> + * Copyright (c) 2009 Wayne Roberts
> + * - tsc2007.c
> + * Copyright (c) 2008 Kwangwoo Lee
> + * - ads7846.c
> + * Copyright (c) 2005 David Brownell
> + * Copyright (c) 2006 Nokia Corporation
> + * - corgi_ts.c
> + * Copyright (C) 2004-2005 Richard Purdie
> + * - omap_ts.[hc], ads7846.h, ts_osk.c
> + * Copyright (C) 2002 MontaVista Software
> + * Copyright (C) 2004 Texas Instruments
> + * Copyright (C) 2005 Dirk Behme
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* register addresses */
> +#define I2C_REG_TOUCH0 0x00
> +#define I2C_REG_TOUCH1 0x01
> +#define I2C_REG_CHANMASK 0x04
> +#define I2C_REG_IRQMASK 0x22
> +#define I2C_REG_IRQSRC 0x23
> +#define I2C_REG_SOFTRESET0x3f
> +
> +/* commands */
> +#define CMD_READ_REGISTER0x40
> +#define CMD_MANUAL 0xc0
> +#define CMD_PENTRG 0xe0
> +
> +/* value for I2C_REG_SOFTRESET */
> +#define SOFTRESET_VALUE 0xde
> +
> +/* bits for I2C_REG_IRQSRC */
> +#define IRQ_PENTOUCH_TOUCHCONVDONE 0x08
> +#define IRQ_PENRELEASE 0x04
> +
> +/* bits for RegTouch1 */
> +#define CONDIRQ 0x20
> +#define FILT_7SA 0x03
> +
> +/* bits for I2C_REG_CHANMASK */
> +#define CONV_X 0x80
> +#define CONV_Y 0x40
> +
> +/* coordinates rate: higher nibble of CTRL0 register */
> +#define RATE_MANUAL 0x00
> +#define RATE_5000CPS 0xf0
> +
> +/* power delay: lower nibble of CTRL0 register */
> +#define POWDLY_1_1MS 0x0b
> +
> +#define MAX_12BIT((1 << 12) - 1)
> +
> +struct sx8654 {
> + struct input_dev *input;
> + struct i2c_client *client;
> +};
> +
> +static irqreturn_t sx8654_irq(int irq, void *handle)
> +{
> + struct sx8654 *sx8654 = handle;
> + u8 irqsrc;
> + u8 data[4];
> + unsigned int x, y;
> + int retval;
> +
> + irqsrc = i2c_smbus_read_byte_data(sx8654->client,
> + (CMD_READ_REGISTER | I2C_REG_IRQSRC));
> + dev_dbg(&sx8654->client->dev, "irqsrc = 0x%x", irqsrc);
> +
> + if (irqsrc <
Re: [PATCH v3 2/3] of: add optional options parameter to of_find_node_by_path()
On 03/06/2015 11:52 AM, Leif Lindholm wrote:
> Hi Peter,
>
> On Wed, Mar 04, 2015 at 10:45:02AM -0500, Peter Hurley wrote:
>> The path parsing gets lost if the string after ':' contains '/'.
>
> Doh!
Hardly.
I only noticed because I had to implement the corresponding algorithm
for earlycon and FDT, where the string scanning is obvious.
> Thanks for reporting (and sorry for slow response).
No worries :)
Rather, I'd like to thank you for implementing the options string so
that bootloader -> earlycon -> console works so seamlessly now.
Can't wait to see 300Mb/s console from boot.
And thanks for the quick patch. I'm still testing because, while there weren't
those failures, there were some other messages. So I just need to go back
and see if those are regressions.
>> The selftests below fail with:
>> [1.365528] ### dt-test ### FAIL of_selftest_find_node_by_name():99
>> option path test failed
>> [1.365610] ### dt-test ### FAIL of_selftest_find_node_by_name():115
>> option alias path test failed
>>
>> Regards,
>> Peter Hurley
>>
>>
>> --- >% ---
>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>> index 41a4a13..07ba5aa 100644
>> --- a/drivers/of/unittest.c
>> +++ b/drivers/of/unittest.c
>> @@ -94,6 +94,11 @@ static void __init of_selftest_find_node_by_name(void)
>> "option path test failed\n");
>> of_node_put(np);
>>
>> +np = of_find_node_opts_by_path("/testcase-data:test/option", &options);
>> +selftest(np && !strcmp("test/option", options),
>> + "option path test failed\n");
>> +of_node_put(np);
>> +
>> np = of_find_node_opts_by_path("/testcase-data:testoption", NULL);
>> selftest(np, "NULL option path test failed\n");
>> of_node_put(np);
>> @@ -104,6 +109,12 @@ static void __init of_selftest_find_node_by_name(void)
>> "option alias path test failed\n");
>> of_node_put(np);
>>
>> +np = of_find_node_opts_by_path("testcase-alias:test/alias/option",
>> + &options);
>> +selftest(np && !strcmp("test/alias/option", options),
>> + "option alias path test failed\n");
>> +of_node_put(np);
>> +
>> np = of_find_node_opts_by_path("testcase-alias:testaliasoption", NULL);
>> selftest(np, "NULL option alias path test failed\n");
>> of_node_put(np);
>
> Could you give the below a spin, and if it works for you, send me the
> above tests as a full patch so that I can post both as a series?
Will do as soon as I finish testing.
Regards,
Peter Hurley
> From bf4ab0b2e33902ba88809a3c4a2cdf07efd02dde Mon Sep 17 00:00:00 2001
> From: Leif Lindholm
> Date: Fri, 6 Mar 2015 16:38:54 +
> Subject: [PATCH] of: fix handling of '/' in options for of_find_node_by_path()
>
> Ensure proper handling of paths with appended options (after ':'),
> where those options may contain a '/'.
>
> Fixes: 7914a7c5651a ("of: support passing console options with stdout-path")
> Reported-by: Peter Hurley
> Signed-off-by: Leif Lindholm
> ---
> drivers/of/base.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 0a8aeb8..8b904e5 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -714,16 +714,17 @@ static struct device_node
> *__of_find_node_by_path(struct device_node *parent,
> const char *path)
> {
> struct device_node *child;
> - int len = strchrnul(path, '/') - path;
> - int term;
> + int len;
> + const char *end;
>
> + end = strchr(path, ':');
> + if (!end)
> + end = strchrnul(path, '/');
> +
> + len = end - path;
> if (!len)
> return NULL;
>
> - term = strchrnul(path, ':') - path;
> - if (term < len)
> - len = term;
> -
> __for_each_child_of_node(parent, child) {
> const char *name = strrchr(child->full_name, '/');
> if (WARN(!name, "malformed device_node %s\n", child->full_name))
> @@ -768,8 +769,12 @@ struct device_node *of_find_node_opts_by_path(const char
> *path, const char **opt
>
> /* The path could begin with an alias */
> if (*path != '/') {
> - char *p = strchrnul(path, '/');
> - int len = separator ? separator - path : p - path;
> + int len;
> + const char *p = separator;
> +
> + if (!p)
> + p = strchrnul(path, '/');
> + len = p - path;
>
> /* of_aliases must not be NULL */
> if (!of_aliases)
> @@ -794,6 +799,8 @@ struct device_node *of_find_node_opts_by_path(const char
> *path, const char **opt
> path++; /* Increment past '/' delimiter */
> np = __of_find_node_by_path(np, path);
> path = strchrnul(path, '/');
> + if (separator && separator < path)
> + break;
>
Re: [PATCH 1/2] pinctrl: Add Pistachio SoC pin control binding document
On Fri, Mar 6, 2015 at 3:37 AM, Linus Walleij wrote:
> On Tue, Feb 24, 2015 at 3:15 AM, Andrew Bresticker
> wrote:
>
>> Add a device-tree binding document for the pin controller present
>> on the IMG Pistachio SoC.
>>
>> Signed-off-by: Damien Horsley
>> Signed-off-by: Andrew Bresticker
> (...)
>> +Note that the GPIO bank sub-nodes *must* be listed in order.
>
> Usually we use aliases to mark the order of things. e.g.:
>
> aliases {
> gpio0 = &gpio0;
> gpio1 = &gpio1;
> gpio2 = &gpio2;
> ethernet0 = ð0;
> ethernet1 = ð1;
> };
>
> (arch/arm/boot/dts/armada-375.dtsi)
Ok.
>> +Required properties for pin configuration sub-nodes:
>> +
>> + - pins: List of pins to which the configuration applies. See below for a
>> + list of possible pins.
>> +
>> +Optional properties for pin configuration sub-nodes:
>> +
>> + - function: Mux function for the specified pins. This is not applicable for
>> + non-MFIO pins. See below for a list of valid functions for each pin.
>> + - bias-high-impedance: Enable high-impedance mode.
>> + - bias-pull-up: Enable weak pull-up.
>> + - bias-pull-down: Enable weak pull-down.
>> + - bias-bus-hold: Enable bus-keeper mode.
>> + - drive-strength: Drive strength in mA. Supported values: 2, 4, 8, 12.
>> + - input-schmitt-enable: Enable Schmitt trigger.
>> + - input-schmitt-disable: Disable Schmitt trigger.
>> + - slew-rate: Slew rate control. 0 for slow, 1 for fast.
>
> We actually haven't specified that function+pins is a valid pattern,
> a lot of drivers just started doing that :(
>
> function+groups is documented for muxing.
>
> group + config opts is documented for config.
>
> Please consider patching the generic bindings to reflect this
> mux use of pins... We need to discuss it.
Sure, I can update that documentation.
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] pinctrl: Support for IMG Pistachio
On Fri, Mar 6, 2015 at 3:29 AM, Linus Walleij wrote: > On Tue, Feb 24, 2015 at 3:15 AM, Andrew Bresticker > wrote: > >> I'd like this to go through the MIPS tree with >> Linus'/Alex's ACKs if possible. > > Why? It will only help creating merge conflicts. > There seem to be no compile-related dependencies, just Kconfig > symbols, so patches using this can go in orthogonally. Ah, ok. If the missing Kconfig symbol is not a big deal, then let's take them through your tree. -Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Hi Dmitry,
On 3/6/2015 9:35 AM, Dmitry Torokhov wrote:
> On Fri, Mar 6, 2015 at 9:26 AM, Ray Jui wrote:
>> Hi Paul,
>>
>> On 3/6/2015 3:00 AM, Paul Bolle wrote:
>>> On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -106,4 +106,21 @@ config PCI_VERSATILE
bool "ARM Versatile PB PCI controller"
depends on ARCH_VERSATILE
+config PCIE_IPROC
+bool "Broadcom iProc PCIe controller"
>>>
>>> bool symbol.
>>>
+help
+ This enables the iProc PCIe core controller support for Broadcom's
+ iProc family of SoCs. An appropriate bus interface driver also needs
+ to be enabled
+
+config PCIE_IPROC_PLTFM
+bool "Broadcom iProc PCIe platform bus driver"
>>>
>>> Another bool symbol.
>>>
+depends on ARCH_BCM_IPROC || COMPILE_TEST
+depends on OF
+select PCIE_IPROC
+default ARCH_BCM_IPROC
+help
+ Say Y here if you want to use the Broadcom iProc PCIe controller
+ through the generic platform bus interface
+
endmenu
>>>
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
>>>
+obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
+obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
>>>
>>> Both objectfiles will never be part of a module.
>>>
--- /dev/null
+++ b/drivers/pci/host/pcie-iproc-pltfm.c
>>>
+#include
>>>
>>> Is this needed?
>>>
+MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>>>
>>> This macro will be preprocessed away, won't it?
>>>
+static struct platform_driver iproc_pcie_pltfm_driver = {
+.driver = {
+.name = "iproc-pcie",
+.of_match_table = of_match_ptr(iproc_pcie_of_match_table),
+.suppress_bind_attrs = true,
+},
+.probe = iproc_pcie_pltfm_probe,
+};
+module_platform_driver(iproc_pcie_pltfm_driver);
>>>
>>> Perhaps it's clearer to have make this a call to
>>> platform_driver_register(), put that in a wrapper function, and invoke
>>> that wrapper function through device_initcall() or similar. I haven't
>>> actually tested that, so the details could be off.
>>>
+MODULE_AUTHOR("Ray Jui ");
+MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
+MODULE_LICENSE("GPL v2");
>>>
>>> And these three macros will, effectively, be preprocessed away.
>>>
--- /dev/null
+++ b/drivers/pci/host/pcie-iproc.c
>>>
+#include
>>>
>>> See above.
>>>
+MODULE_AUTHOR("Ray Jui ");
+MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
+MODULE_LICENSE("GPL v2");
>>>
>>> Ditto.
>>>
>>>
>>> Paul Bolle
>>>
>>
>> So every single PCIe host driver under drivers/pci/host/* has their
>> config flag of "bool" type, and all of them except pci-keystone-dw.c
>> have these MODULE based macros in their driver. While I agree with you
>> that these macros will preprocessed away while compiled as statically
>> linked in, I thought it's a convention to have these macros in the
>> driver. At least it provides information on the author, driver
>> description, and license (although one can also argue you can find all
>> of those info from the maintainer list, Kconfig, and license header).
>>
>> Would you be able to sort this out with a developer or subsystem
>> maintainer who is familiar with this matter and let us know what is the
>> convention for MODULE macros usage in a driver when its config flag is
>> set to "bool" instead of "tristate"?
>
> Is there a technical reason why the driver can't be a module? We can
> suppress module unloading if unloading properly is hard (i see you
> already suppress unbinding via sysfs), but we should be able to load
> it after kernel booted, no?
>
> Thanks,
> Dmitry
>
Although I have not tested it, but to my best knowledge there shouldn't
be any technical issue by making the PCIe iProc driver a loadable module
and installing the module later after the kernel finishes booting.
But I wonder why I haven't seen any PCIe host driver being allowed to be
compiled as module? Maybe there's no obvious benefit of doing that.
People typically opt to load slave devices as module but tend to keep
the bus or host devices compiled in.
And to allow a PCI host driver to be compiled as module, some PCI
functions need to have their symbols exported:
ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_assign_unassigned_bus_resources"
[drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
Maybe Bjorn can help to shed some light here? Should I go ahead and
export_symbol these PCI functions and make the iPro
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
* Dave Gerlach [150306 09:28]: > On 03/05/2015 06:41 PM, Tony Lindgren wrote: > > * Tony Lindgren [150305 12:24]: > >> * Dave Gerlach [150305 11:53]: > >>> On 03/05/2015 12:49 PM, Tony Lindgren wrote: > * Paul Walmsley [150305 10:16]: > > On Thu, 5 Mar 2015, Dave Gerlach wrote: > > > >> Introduce a dt property, ti,no-init, that prevents hwmod > >> initialization. > >> Even if a dt node is marked as disabled, hwmod still at least enables > >> the hwmod and programs the sysconfig before attempting to idle it at > >> boot. If an IP has been disabled by the hardware configuration on a > >> platform, this will cause a hang due to writing to inactive registers. > >> This property prevents that from happening by marking the hwmod as > >> _HWMOD_STATE_DISABLED during init. > > > > I'm kind of wondering if hwmod should even touch a device if it's > > marked > > as disabled in the DT. Tony, what do you think? > > Well nothing happens if a device is status = "disabled". No dev entry > gets created for it at all and hwmod won't have any data for the device > populated. The only way hwmod code could see that device if the device > gets it's data from the legacy omap_hwmod_*_data.c instead of DT. > > >>> > >>> We still need this for the sysconfig programming, correct? hwmod programs > >>> that > >>> regardless of dt status and then idles the IP, > >> > >> Well hwmod does not even know about the IP IO addresses if it's marked > >> with status = "disabled".. Which IP are you having problems with? > >> > >>> which is why I needed the ti,no-init for the epos evm. It isn't just a > >>> matter of we shouldnt write to it because we don't want to use it; we > >>> can't write to it because the module is held off so it causes an > >>> external abort if we do. > >> > >> Well hard to say not knowing which module this is.. Pretty much all > >> the modules have drivers and the driver just does pm_runtime_get() > >> on it? > > > > Heh OK this thread is about the RTC driver, so I assume that's the > > problem :) So if you set the rtc to status = "disabled" how can the > > hwmod code do anything as AFAIK it won't even get the rtc IO address? > > > > Or am I missing something here? > > Perhaps I am mistaken, but from what I understand, all hwmods have _init and > _setup called on them, and all hwmods read the IO address regardless of DT > status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets > called > which calls _enable for the hwmod, and this calls both _enable_sysc and > _update_sysc_cache which touch the sysconfig register of the IP. Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(), sorry. Looks like the hwmod IO address data does get populated even for status = "disabled" although the dev entry won't get created and omap_device_build_from_dt() never gets called. > Normally this is fine regardless of whether or not we are using an IP because > the module will wake up for a moment, have it's sysc programmed, and then be > put > back to sleep later, potentially never to be woken again if we bind no driver > for it, which is fine for 99% of cases. In the case of am43x epos evm, you can > take the same piece of silicon that will boot happily on the gp evm with the > rtc > hwmod in place and it will hang during boot on the epos evm because the board > uses a pin to hold the RTC IP in reset. There is no way to detect this in > software, the module can be turned on as normal using the clk_ctrl, but if you > touch any of the IP registers you get an abort. OK sounds like some dts property is needed to signal this. > So we need to prevent this from happening but of course we can't selectively > choose when the rtc hwmod gets added based on which board we are using so it > seemed a DT flag was appropriate to indicate that we do not want to init the > rtc > IP at all only on this board. > > Without this flag in place but with the rtc hwmod added, the am43x-epos-evm > fails booting with an imprecise abort. OK thanks for explaining it. I'm fine with this patch, Paul may have other issues. The other option would be to use status = "disabled" to not touch the device at all like Paul suggested. I wonder if that's going to break PM on some devices though.. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
Paul,
On 03/06/2015 11:44 AM, Paul Walmsley wrote:
> Hi Dave,
>
> On Fri, 6 Mar 2015, Dave Gerlach wrote:
>
>> Paul,
>> On 03/05/2015 10:26 PM, Paul Walmsley wrote:
>>> On Thu, 5 Mar 2015, Dave Gerlach wrote:
>>>
RTC hwmod is needed for proper operation of PM features like
rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb8592..9070535 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if
*am43xx_hwmod_ocp_ifs[] __initdata = {
&am43xx_l4_ls__dss,
&am43xx_l4_ls__dss_dispc,
&am43xx_l4_ls__dss_rfbi,
+ &am33xx_l4_wkup__rtc,
NULL,
};
>>>
>>> Thanks, queued for v4.1.
>>
>> Thanks, but please note as I just commented in Patch 1 of this series,
>> without
>> the ti,no-init flag in place that is introduced there this patch will cause
>> the
>> am43x-epos-evm to fail to boot.
>
> If that's so, shouldn't it appear in the series after patch 3, then?
> If only patches 1 and 2 are applied, then won't the boot be broken on
> am43x-epos-evm ?
Hmm yes you are correct that would be the case, seems I should have swapped the
order. I've gotten into the habit of putting dt patches last to enable what gets
introduced previously, guess it's not always the best thing to do. Thanks for
pointing this out.
Regards,
Dave
>
> - Paul
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] dtc: Plugin (object) device tree support.
On Do, 2015-03-05 at 10:34 +1100, David Gibson wrote:
> On Fri, Feb 27, 2015 at 08:55:45PM +0200, Pantelis Antoniou wrote:
> > Enables the generation of a __fixups__ node for trees compiled
> > using the -@ option that are using the /plugin/ tag.
> >
> > The __fixups__ node make possible the dynamic resolution of phandle
> > references which are present in the plugin tree but lie in the
> > tree that are applying the overlay against.
>
> It seems to me you've really missed an opportunity in designing the
> plugin syntax. You have dtc generating the fixups nodes, but you
> still have to manually lay out your fragments in the right format,
> and
> manually construct the target properties. Instead you could re-use
> the existing dts overlay syntax. For a plugin tree, you wouldn't need
> the base tree piece. So, allow something like:
>
> /dts-v1/ /plugin/;
>
> &res {
> baz_res: baz_res { ... };
> };
>
> &ocp {
> baz { ... };
> };
During our initial experiments with overlays in Barebox, Sascha Hauer
did a simple patch to DTC to implement this. I've recently rebased it on
Pantelis' series. It makes writing overlays much more natural:
>From e7082dd7160082c64d242b4ed2ebb9eb0b8aad42 Mon Sep 17 00:00:00 2001
From: Sascha Hauer
Date: Thu, 8 Aug 2013 23:08:31 +0200
Subject: [PATCH] dtc: convert unresolved labels into overlay nodes
Signed-off-by: Sascha Hauer
Signed-off-by: Jan Luebbe
---
dtc-parser.y | 10 +++---
dtc.h| 3 ++-
livetree.c | 23 +++
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index d23927d99215..f431bdd6e57c 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -172,10 +172,14 @@ devicetree:
{
struct node *target = get_node_by_ref($1, $2);
- if (target)
+ if (target) {
merge_nodes(target, $3);
- else
- ERROR(&@2, "Label or path %s not found", $2);
+ } else {
+ if (symbol_fixup_support)
+ add_orphan_node($1, $3, $2);
+ else
+ ERROR(&@2, "Label or path %s not
found", $2);
+ }
$$ = $1;
}
| devicetree DT_DEL_NODE DT_REF ';'
diff --git a/dtc.h b/dtc.h
index f163b22b14b8..fc7330e9013e 100644
--- a/dtc.h
+++ b/dtc.h
@@ -20,7 +20,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
* USA
*/
-
+#define _GNU_SOURCE
#include
#include
#include
@@ -234,6 +234,7 @@ struct node *build_node_delete(void);
struct node *name_node(struct node *node, char *name);
struct node *chain_node(struct node *first, struct node *list);
struct node *merge_nodes(struct node *old_node, struct node *new_node);
+void add_orphan_node(struct node *old_node, struct node *new_node, char *ref);
void add_property(struct node *node, struct property *prop);
void delete_property_by_name(struct node *node, char *name);
diff --git a/livetree.c b/livetree.c
index e229b84432f9..ed16b8c216f4 100644
--- a/livetree.c
+++ b/livetree.c
@@ -216,6 +216,29 @@ struct node *merge_nodes(struct node *old_node, struct
node *new_node)
return old_node;
}
+void add_orphan_node(struct node *dt, struct node *new_node, char *ref)
+{
+ struct node *ovl = xmalloc(sizeof(*ovl));
+ struct property *p;
+ struct data d = empty_data;
+ char *name;
+
+ memset(ovl, 0, sizeof(*ovl));
+
+ d = data_add_marker(d, REF_PHANDLE, ref);
+ d = data_append_integer(d, 0xdeadbeef, 32);
+
+ p = build_property("target", d);
+ add_property(ovl, p);
+
+ asprintf(&name, "fragment@%s", ref);
+ name_node(ovl, name);
+ name_node(new_node, "__overlay__");
+
+ add_child(dt, ovl);
+ add_child(ovl, new_node);
+}
+
struct node *chain_node(struct node *first, struct node *list)
{
assert(first->next_sibling == NULL);
--
2.1.4
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
Hi Dave,
On Fri, 6 Mar 2015, Dave Gerlach wrote:
> Paul,
> On 03/05/2015 10:26 PM, Paul Walmsley wrote:
> > On Thu, 5 Mar 2015, Dave Gerlach wrote:
> >
> >> RTC hwmod is needed for proper operation of PM features like
> >> rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
> >>
> >> Signed-off-by: Dave Gerlach
> >> ---
> >> arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> index 8eb8592..9070535 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> @@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if
> >> *am43xx_hwmod_ocp_ifs[] __initdata = {
> >>&am43xx_l4_ls__dss,
> >>&am43xx_l4_ls__dss_dispc,
> >>&am43xx_l4_ls__dss_rfbi,
> >> + &am33xx_l4_wkup__rtc,
> >>NULL,
> >> };
> >
> > Thanks, queued for v4.1.
>
> Thanks, but please note as I just commented in Patch 1 of this series, without
> the ti,no-init flag in place that is introduced there this patch will cause
> the
> am43x-epos-evm to fail to boot.
If that's so, shouldn't it appear in the series after patch 3, then?
If only patches 1 and 2 are applied, then won't the boot be broken on
am43x-epos-evm ?
- Paul
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding
* Dave Gerlach [150227 17:14]: > Currently both am33xx and am43xx have the macro for SLEWCTRL_FAST > in pinctrl dt-bindings reversed so that selecting the macro actually > sets SLEWCTRL_SLOW in the pad control registers. These patches > correct the bindings but leave the pinctrl states that use the binding > *UNMODIFIED*. Previously i2c and mdio on am33xx and i2c, mdio, and > uart on am43xx had been using this macro and selecting SLEWCTRL_FAST > while actually programming SLEWCTRL_SLOW in the pad config registers. > > Because the intended selection was SLEWCTRL_FAST the macros are > unchanged. I tested on am335x-gp-evm and am437x-gp-evm with no > difference in functionality seen. Applying both into omap-for-v4.0/fixes thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
On Fri, Mar 6, 2015 at 9:26 AM, Ray Jui wrote:
> Hi Paul,
>
> On 3/6/2015 3:00 AM, Paul Bolle wrote:
>> On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
>>> --- a/drivers/pci/host/Kconfig
>>> +++ b/drivers/pci/host/Kconfig
>>> @@ -106,4 +106,21 @@ config PCI_VERSATILE
>>> bool "ARM Versatile PB PCI controller"
>>> depends on ARCH_VERSATILE
>>>
>>> +config PCIE_IPROC
>>> +bool "Broadcom iProc PCIe controller"
>>
>> bool symbol.
>>
>>> +help
>>> + This enables the iProc PCIe core controller support for Broadcom's
>>> + iProc family of SoCs. An appropriate bus interface driver also needs
>>> + to be enabled
>>> +
>>> +config PCIE_IPROC_PLTFM
>>> +bool "Broadcom iProc PCIe platform bus driver"
>>
>> Another bool symbol.
>>
>>> +depends on ARCH_BCM_IPROC || COMPILE_TEST
>>> +depends on OF
>>> +select PCIE_IPROC
>>> +default ARCH_BCM_IPROC
>>> +help
>>> + Say Y here if you want to use the Broadcom iProc PCIe controller
>>> + through the generic platform bus interface
>>> +
>>> endmenu
>>
>>> --- a/drivers/pci/host/Makefile
>>> +++ b/drivers/pci/host/Makefile
>>
>>> +obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>>> +obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
>>
>> Both objectfiles will never be part of a module.
>>
>>> --- /dev/null
>>> +++ b/drivers/pci/host/pcie-iproc-pltfm.c
>>
>>> +#include
>>
>> Is this needed?
>>
>>> +MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>>
>> This macro will be preprocessed away, won't it?
>>
>>> +static struct platform_driver iproc_pcie_pltfm_driver = {
>>> +.driver = {
>>> +.name = "iproc-pcie",
>>> +.of_match_table = of_match_ptr(iproc_pcie_of_match_table),
>>> +.suppress_bind_attrs = true,
>>> +},
>>> +.probe = iproc_pcie_pltfm_probe,
>>> +};
>>> +module_platform_driver(iproc_pcie_pltfm_driver);
>>
>> Perhaps it's clearer to have make this a call to
>> platform_driver_register(), put that in a wrapper function, and invoke
>> that wrapper function through device_initcall() or similar. I haven't
>> actually tested that, so the details could be off.
>>
>>> +MODULE_AUTHOR("Ray Jui ");
>>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
>>> +MODULE_LICENSE("GPL v2");
>>
>> And these three macros will, effectively, be preprocessed away.
>>
>>> --- /dev/null
>>> +++ b/drivers/pci/host/pcie-iproc.c
>>
>>> +#include
>>
>> See above.
>>
>>> +MODULE_AUTHOR("Ray Jui ");
>>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
>>> +MODULE_LICENSE("GPL v2");
>>
>> Ditto.
>>
>>
>> Paul Bolle
>>
>
> So every single PCIe host driver under drivers/pci/host/* has their
> config flag of "bool" type, and all of them except pci-keystone-dw.c
> have these MODULE based macros in their driver. While I agree with you
> that these macros will preprocessed away while compiled as statically
> linked in, I thought it's a convention to have these macros in the
> driver. At least it provides information on the author, driver
> description, and license (although one can also argue you can find all
> of those info from the maintainer list, Kconfig, and license header).
>
> Would you be able to sort this out with a developer or subsystem
> maintainer who is familiar with this matter and let us know what is the
> convention for MODULE macros usage in a driver when its config flag is
> set to "bool" instead of "tristate"?
Is there a technical reason why the driver can't be a module? We can
suppress module unloading if unloading properly is hard (i see you
already suppress unbinding via sysfs), but we should be able to load
it after kernel booted, no?
Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
Paul,
On 03/05/2015 10:26 PM, Paul Walmsley wrote:
> On Thu, 5 Mar 2015, Dave Gerlach wrote:
>
>> RTC hwmod is needed for proper operation of PM features like
>> rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
>>
>> Signed-off-by: Dave Gerlach
>> ---
>> arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> index 8eb8592..9070535 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> @@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
>> __initdata = {
>> &am43xx_l4_ls__dss,
>> &am43xx_l4_ls__dss_dispc,
>> &am43xx_l4_ls__dss_rfbi,
>> +&am33xx_l4_wkup__rtc,
>> NULL,
>> };
>
> Thanks, queued for v4.1.
Thanks, but please note as I just commented in Patch 1 of this series, without
the ti,no-init flag in place that is introduced there this patch will cause the
am43x-epos-evm to fail to boot.
Regards,
Dave
>
>
> - Paul
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding
On 03/06/2015 11:13 AM, Tony Lindgren wrote: > * Dave Gerlach [150227 17:14]: >> Currently both am33xx and am43xx have the macro for SLEWCTRL_FAST >> in pinctrl dt-bindings reversed so that selecting the macro actually >> sets SLEWCTRL_SLOW in the pad control registers. These patches >> correct the bindings but leave the pinctrl states that use the binding >> *UNMODIFIED*. Previously i2c and mdio on am33xx and i2c, mdio, and >> uart on am43xx had been using this macro and selecting SLEWCTRL_FAST >> while actually programming SLEWCTRL_SLOW in the pad config registers. >> >> Because the intended selection was SLEWCTRL_FAST the macros are >> unchanged. I tested on am335x-gp-evm and am437x-gp-evm with no >> difference in functionality seen. > > Applying both into omap-for-v4.0/fixes thanks. Thanks! Regards, Dave > > Tony > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
On 03/05/2015 06:41 PM, Tony Lindgren wrote: > * Tony Lindgren [150305 12:24]: >> * Dave Gerlach [150305 11:53]: >>> On 03/05/2015 12:49 PM, Tony Lindgren wrote: * Paul Walmsley [150305 10:16]: > On Thu, 5 Mar 2015, Dave Gerlach wrote: > >> Introduce a dt property, ti,no-init, that prevents hwmod initialization. >> Even if a dt node is marked as disabled, hwmod still at least enables >> the hwmod and programs the sysconfig before attempting to idle it at >> boot. If an IP has been disabled by the hardware configuration on a >> platform, this will cause a hang due to writing to inactive registers. >> This property prevents that from happening by marking the hwmod as >> _HWMOD_STATE_DISABLED during init. > > I'm kind of wondering if hwmod should even touch a device if it's marked > as disabled in the DT. Tony, what do you think? Well nothing happens if a device is status = "disabled". No dev entry gets created for it at all and hwmod won't have any data for the device populated. The only way hwmod code could see that device if the device gets it's data from the legacy omap_hwmod_*_data.c instead of DT. >>> >>> We still need this for the sysconfig programming, correct? hwmod programs >>> that >>> regardless of dt status and then idles the IP, >> >> Well hwmod does not even know about the IP IO addresses if it's marked >> with status = "disabled".. Which IP are you having problems with? >> >>> which is why I needed the ti,no-init for the epos evm. It isn't just a >>> matter of we shouldnt write to it because we don't want to use it; we >>> can't write to it because the module is held off so it causes an >>> external abort if we do. >> >> Well hard to say not knowing which module this is.. Pretty much all >> the modules have drivers and the driver just does pm_runtime_get() >> on it? > > Heh OK this thread is about the RTC driver, so I assume that's the > problem :) So if you set the rtc to status = "disabled" how can the > hwmod code do anything as AFAIK it won't even get the rtc IO address? > > Or am I missing something here? Perhaps I am mistaken, but from what I understand, all hwmods have _init and _setup called on them, and all hwmods read the IO address regardless of DT status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets called which calls _enable for the hwmod, and this calls both _enable_sysc and _update_sysc_cache which touch the sysconfig register of the IP. Normally this is fine regardless of whether or not we are using an IP because the module will wake up for a moment, have it's sysc programmed, and then be put back to sleep later, potentially never to be woken again if we bind no driver for it, which is fine for 99% of cases. In the case of am43x epos evm, you can take the same piece of silicon that will boot happily on the gp evm with the rtc hwmod in place and it will hang during boot on the epos evm because the board uses a pin to hold the RTC IP in reset. There is no way to detect this in software, the module can be turned on as normal using the clk_ctrl, but if you touch any of the IP registers you get an abort. So we need to prevent this from happening but of course we can't selectively choose when the rtc hwmod gets added based on which board we are using so it seemed a DT flag was appropriate to indicate that we do not want to init the rtc IP at all only on this board. Without this flag in place but with the rtc hwmod added, the am43x-epos-evm fails booting with an imprecise abort. Regards, Dave > > Regards, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Hi Paul,
On 3/6/2015 3:00 AM, Paul Bolle wrote:
> On Thu, 2015-03-05 at 17:01 -0800, Ray Jui wrote:
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -106,4 +106,21 @@ config PCI_VERSATILE
>> bool "ARM Versatile PB PCI controller"
>> depends on ARCH_VERSATILE
>>
>> +config PCIE_IPROC
>> +bool "Broadcom iProc PCIe controller"
>
> bool symbol.
>
>> +help
>> + This enables the iProc PCIe core controller support for Broadcom's
>> + iProc family of SoCs. An appropriate bus interface driver also needs
>> + to be enabled
>> +
>> +config PCIE_IPROC_PLTFM
>> +bool "Broadcom iProc PCIe platform bus driver"
>
> Another bool symbol.
>
>> +depends on ARCH_BCM_IPROC || COMPILE_TEST
>> +depends on OF
>> +select PCIE_IPROC
>> +default ARCH_BCM_IPROC
>> +help
>> + Say Y here if you want to use the Broadcom iProc PCIe controller
>> + through the generic platform bus interface
>> +
>> endmenu
>
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>
>> +obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>> +obj-$(CONFIG_PCIE_IPROC_PLTFM) += pcie-iproc-pltfm.o
>
> Both objectfiles will never be part of a module.
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-iproc-pltfm.c
>
>> +#include
>
> Is this needed?
>
>> +MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>
> This macro will be preprocessed away, won't it?
>
>> +static struct platform_driver iproc_pcie_pltfm_driver = {
>> +.driver = {
>> +.name = "iproc-pcie",
>> +.of_match_table = of_match_ptr(iproc_pcie_of_match_table),
>> +.suppress_bind_attrs = true,
>> +},
>> +.probe = iproc_pcie_pltfm_probe,
>> +};
>> +module_platform_driver(iproc_pcie_pltfm_driver);
>
> Perhaps it's clearer to have make this a call to
> platform_driver_register(), put that in a wrapper function, and invoke
> that wrapper function through device_initcall() or similar. I haven't
> actually tested that, so the details could be off.
>
>> +MODULE_AUTHOR("Ray Jui ");
>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe platform driver");
>> +MODULE_LICENSE("GPL v2");
>
> And these three macros will, effectively, be preprocessed away.
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-iproc.c
>
>> +#include
>
> See above.
>
>> +MODULE_AUTHOR("Ray Jui ");
>> +MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
>> +MODULE_LICENSE("GPL v2");
>
> Ditto.
>
>
> Paul Bolle
>
So every single PCIe host driver under drivers/pci/host/* has their
config flag of "bool" type, and all of them except pci-keystone-dw.c
have these MODULE based macros in their driver. While I agree with you
that these macros will preprocessed away while compiled as statically
linked in, I thought it's a convention to have these macros in the
driver. At least it provides information on the author, driver
description, and license (although one can also argue you can find all
of those info from the maintainer list, Kconfig, and license header).
Would you be able to sort this out with a developer or subsystem
maintainer who is familiar with this matter and let us know what is the
convention for MODULE macros usage in a driver when its config flag is
set to "bool" instead of "tristate"?
Thanks,
Ray
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-lxm: Use rmii-clock-ext
* George McCollister [150226 08:53]:
> Use external clock for RMII since the internal clock doesn't meet the
> jitter requirements.
>
> Signed-off-by: George McCollister
> ---
> arch/arm/boot/dts/am335x-lxm.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-lxm.dts
> b/arch/arm/boot/dts/am335x-lxm.dts
> index 7266a00..5c5667a 100644
> --- a/arch/arm/boot/dts/am335x-lxm.dts
> +++ b/arch/arm/boot/dts/am335x-lxm.dts
> @@ -328,6 +328,10 @@
> dual_emac_res_vlan = <3>;
> };
>
> +&phy_sel {
> + rmii-clock-ext;
> +};
> +
> &mac {
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&cpsw_default>;
Applying into omap-for-v4.0/fixes thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver
On Fri, Mar 06 2015 at 02:48:17 AM, wrote:
> From: Yong Wu
>
> This patch adds support for mediatek m4u (MultiMedia Memory Management Unit).
> Currently this only supports m4u gen 2 with 2 levels of page table on mt8173.
[...]
> +static int mtk_iommu_invalidate_tlb(const struct mtk_iommu_info *piommu,
> + int isinvall, unsigned int iova_start,
> + unsigned int iova_end)
> +{
> + void __iomem *m4u_base = piommu->m4u_base;
> + u32 val;
> + u64 start, end;
> +
> + start = sched_clock();
> +
> + if (!isinvall) {
> + iova_start = round_down(iova_start, SZ_4K);
> + iova_end = round_up(iova_end, SZ_4K);
> + }
> +
> + val = F_MMU_INV_EN_L2 | F_MMU_INV_EN_L1;
> +
> + writel(val, m4u_base + REG_INVLID_SEL);
> +
> + if (isinvall) {
> + writel(F_MMU_INV_ALL, m4u_base + REG_MMU_INVLD);
> + } else {
> + writel(iova_start, m4u_base + REG_MMU_INVLD_SA);
> + writel(iova_end, m4u_base + REG_MMU_INVLD_EA);
> + writel(F_MMU_INV_RANGE, m4u_base + REG_MMU_INVLD);
> +
> + while (!readl(m4u_base + REG_MMU_CPE_DONE)) {
> + end = sched_clock();
> + if (end - start >= 1ULL) {
> + dev_warn(piommu->dev, "invalid don't done\n");
> + writel(F_MMU_INV_ALL, m4u_base + REG_MMU_INVLD);
> + }
> + };
Superfluous `;'. Also, maybe you should be using readl_poll_timeout?
> + writel(0, m4u_base + REG_MMU_CPE_DONE);
> + }
> +
> + return 0;
> +}
-Mitch
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: dt: at91: new binding
On 07/03/2015 at 00:49:55 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote : > > > > Sorry but NACK. > > > > I don't want to manage another flavor of the pinmux biding with no real > > benefit. I would have been good if we had it from day-1. Now it's too late. > > yes we do, we catch but a compiling time instead of RUNTIME which is critical > > so I’ll pass on the NACK > If you are changing the binding, how about doing it right this time and completely drop the current mess? > > > > Moreover, splitting a binding definition if you have a function given by > > multiple banks can be weird and not well understood in regard to our > > current group+function definition scheme (Cf. your last example). > > > > Others already do so and this is not complex at all > -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI
* Jyri Sarha [150306 07:57]: > On 03/06/15 17:36, Tony Lindgren wrote: > >* Jyri Sarha [150306 07:37]: > >>Use new binding for the external tda19988 HDMI encoder. > > > >Can this be merged separately after the driver code is > >merged with things still working? > > > > Yes absolutely. That is why DRM_TILCDC_SLAVE_COMPAT is there for. Great, thanks for sorting it out properly. Please ping me to apply this patch when the driver changes are in Linux next. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx
* Tero Kristo [150224 23:39]: > On 02/24/2015 07:15 PM, Tony Lindgren wrote: > >* Vignesh R [150209 22:43]: > >>In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of > >>PWMSS. The schematics and TRMs show that there is only one input clock to > >>the PWMSS. But currently, tbclk is wrongly shown to be deriving from > >>dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT. > >> > >>Fixing ehrpwm tbclk data to reflect the right clk source. > >>Tested on beaglebone and am437x-gp-evm. > >> > >>Vignesh R (2): > >> ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx > >> ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx > >> > >> arch/arm/boot/dts/am33xx-clocks.dtsi | 6 +++--- > >> arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++-- > >> 2 files changed, 9 insertions(+), 9 deletions(-) > > > >Tero, care to check this one too and ack if OK? > > These look fine also, just verified from TRM. These two were actually buried > in my mailbox, sorry about that. > > Acked-by: Tero Kristo Thanks applying both into omap-for-v4.0/fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] of: add optional options parameter to of_find_node_by_path()
Hi Peter,
On Wed, Mar 04, 2015 at 10:45:02AM -0500, Peter Hurley wrote:
> The path parsing gets lost if the string after ':' contains '/'.
Doh!
Thanks for reporting (and sorry for slow response).
> The selftests below fail with:
> [1.365528] ### dt-test ### FAIL of_selftest_find_node_by_name():99 option
> path test failed
> [1.365610] ### dt-test ### FAIL of_selftest_find_node_by_name():115
> option alias path test failed
>
> Regards,
> Peter Hurley
>
>
> --- >% ---
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 41a4a13..07ba5aa 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -94,6 +94,11 @@ static void __init of_selftest_find_node_by_name(void)
>"option path test failed\n");
> of_node_put(np);
>
> + np = of_find_node_opts_by_path("/testcase-data:test/option", &options);
> + selftest(np && !strcmp("test/option", options),
> + "option path test failed\n");
> + of_node_put(np);
> +
> np = of_find_node_opts_by_path("/testcase-data:testoption", NULL);
> selftest(np, "NULL option path test failed\n");
> of_node_put(np);
> @@ -104,6 +109,12 @@ static void __init of_selftest_find_node_by_name(void)
>"option alias path test failed\n");
> of_node_put(np);
>
> + np = of_find_node_opts_by_path("testcase-alias:test/alias/option",
> +&options);
> + selftest(np && !strcmp("test/alias/option", options),
> + "option alias path test failed\n");
> + of_node_put(np);
> +
> np = of_find_node_opts_by_path("testcase-alias:testaliasoption", NULL);
> selftest(np, "NULL option alias path test failed\n");
> of_node_put(np);
Could you give the below a spin, and if it works for you, send me the
above tests as a full patch so that I can post both as a series?
Regards,
Leif
>From bf4ab0b2e33902ba88809a3c4a2cdf07efd02dde Mon Sep 17 00:00:00 2001
From: Leif Lindholm
Date: Fri, 6 Mar 2015 16:38:54 +
Subject: [PATCH] of: fix handling of '/' in options for of_find_node_by_path()
Ensure proper handling of paths with appended options (after ':'),
where those options may contain a '/'.
Fixes: 7914a7c5651a ("of: support passing console options with stdout-path")
Reported-by: Peter Hurley
Signed-off-by: Leif Lindholm
---
drivers/of/base.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 0a8aeb8..8b904e5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -714,16 +714,17 @@ static struct device_node *__of_find_node_by_path(struct
device_node *parent,
const char *path)
{
struct device_node *child;
- int len = strchrnul(path, '/') - path;
- int term;
+ int len;
+ const char *end;
+ end = strchr(path, ':');
+ if (!end)
+ end = strchrnul(path, '/');
+
+ len = end - path;
if (!len)
return NULL;
- term = strchrnul(path, ':') - path;
- if (term < len)
- len = term;
-
__for_each_child_of_node(parent, child) {
const char *name = strrchr(child->full_name, '/');
if (WARN(!name, "malformed device_node %s\n", child->full_name))
@@ -768,8 +769,12 @@ struct device_node *of_find_node_opts_by_path(const char
*path, const char **opt
/* The path could begin with an alias */
if (*path != '/') {
- char *p = strchrnul(path, '/');
- int len = separator ? separator - path : p - path;
+ int len;
+ const char *p = separator;
+
+ if (!p)
+ p = strchrnul(path, '/');
+ len = p - path;
/* of_aliases must not be NULL */
if (!of_aliases)
@@ -794,6 +799,8 @@ struct device_node *of_find_node_opts_by_path(const char
*path, const char **opt
path++; /* Increment past '/' delimiter */
np = __of_find_node_by_path(np, path);
path = strchrnul(path, '/');
+ if (separator && separator < path)
+ break;
}
raw_spin_unlock_irqrestore(&devtree_lock, flags);
return np;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/2] mfd: AXP20x: Add bindings documentation
On Fri, Feb 20, 2015 at 7:19 PM, Chen-Yu Tsai wrote: > From: Carlo Caione > > Bindings documentation for the AXP20x driver. In this file also > sub-nodes are documented. > > Signed-off-by: Carlo Caione > [w...@csie.org: clarify interrupt source for the axp PMIC] > [w...@csie.org: explain dcdc-workmode in detail and trim lines to 80 chars] > [w...@csie.org: make regulator supplies optional if using unregulated input] > [w...@csie.org: use cubieboard2 regulator nodes as example] > [w...@csie.org: x-powers,dcdc-workmode default changed to 'current hardware > setting'] > [w...@csie.org: reorganized regulator related properties into separate > section.] > Signed-off-by: Chen-Yu Tsai Ping? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] net/macb: Update DT bindings documentation
Le 06/03/2015 11:24, Boris Brezillon a écrit :
> Add missing "cdns,at91sam9260-macb", "atmel,sama5d3-gem" and
> "atmel,sama5d4-gem" compatible strings.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alexandre Belloni
Acked-by: Nicolas Ferre
> ---
> Documentation/devicetree/bindings/net/macb.txt | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt
> b/Documentation/devicetree/bindings/net/macb.txt
> index aaa6964..ba19d67 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -2,10 +2,13 @@
>
> Required properties:
> - compatible: Should be "cdns,[-]{macb|gem}"
> - Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
> + Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
> + available on sama5d3 SoCs.
>Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form:
> "cdns,macb".
>Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based
> on
>the Cadence GEM, or the generic form: "cdns,gem".
> + Use "cdns,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs.
> + Use "cdns,sama5d4-gem" for the Gigabit IP available on Atmel sama5d4 SoCs.
> - reg: Address and length of the register set for the device
> - interrupts: Should contain macb interrupt
> - phy-mode: See ethernet.txt file in the same directory.
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] net: macb: remove #if defined(CONFIG_ARCH_AT91) sections
Le 06/03/2015 11:24, Boris Brezillon a écrit :
> With multi platform support those sections could lead to unexpected
> behavior if both ARCH_AT91 and another ARM SoC using the MACB IP are
> selected.
> Add two new capabilities to encode the default MII mode and the presence
> of a CLKEN bit in USRIO register.
> Then define the appropriate config for IPs embedded in at91 SoCs.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alexandre Belloni
Acked-by: Nicolas Ferre
> ---
> drivers/net/ethernet/cadence/macb.c | 32 +---
> drivers/net/ethernet/cadence/macb.h | 2 ++
> 2 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index ad76b8e..86e915f 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2113,6 +2113,10 @@ static const struct net_device_ops macb_netdev_ops = {
> };
>
> #if defined(CONFIG_OF)
> +static struct macb_config at91sam9260_config = {
> + .caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII,
> +};
> +
> static struct macb_config pc302gem_config = {
> .caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE,
> .dma_burst_length = 16,
> @@ -2130,7 +2134,7 @@ static struct macb_config sama5d4_config = {
>
> static const struct of_device_id macb_dt_ids[] = {
> { .compatible = "cdns,at32ap7000-macb" },
> - { .compatible = "cdns,at91sam9260-macb" },
> + { .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
> { .compatible = "cdns,macb" },
> { .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
> { .compatible = "cdns,gem", .data = &pc302gem_config },
> @@ -2388,21 +2392,19 @@ static int macb_probe(struct platform_device *pdev)
> bp->phy_interface = err;
> }
>
> + config = 0;
> if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
> - macb_or_gem_writel(bp, USRIO, GEM_BIT(RGMII));
> - else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII)
> -#if defined(CONFIG_ARCH_AT91)
> - macb_or_gem_writel(bp, USRIO, (MACB_BIT(RMII) |
> -MACB_BIT(CLKEN)));
> -#else
> - macb_or_gem_writel(bp, USRIO, 0);
> -#endif
> - else
> -#if defined(CONFIG_ARCH_AT91)
> - macb_or_gem_writel(bp, USRIO, MACB_BIT(CLKEN));
> -#else
> - macb_or_gem_writel(bp, USRIO, MACB_BIT(MII));
> -#endif
> + config = GEM_BIT(RGMII);
> + else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
> + (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> + config = MACB_BIT(RMII);
> + else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> + config = MACB_BIT(MII);
> +
> + if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
> + config |= MACB_BIT(CLKEN);
> +
> + macb_or_gem_writel(bp, USRIO, config);
>
> err = register_netdev(dev);
> if (err) {
> diff --git a/drivers/net/ethernet/cadence/macb.h
> b/drivers/net/ethernet/cadence/macb.h
> index 31dc080..efe0247 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -389,6 +389,8 @@
>
> /* Capability mask bits */
> #define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x0001
> +#define MACB_CAPS_USRIO_HAS_CLKEN0x0002
> +#define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x0004
> #define MACB_CAPS_FIFO_MODE 0x1000
> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
> #define MACB_CAPS_SG_DISABLED0x4000
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes
* Tero Kristo [150225 00:05]: > On 02/24/2015 06:27 PM, Tony Lindgren wrote: > >* Ravikumar Kattekola [150219 08:13]: > >>On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote: > >>>Fix bypass clock source for a few DPLLs. > >>> > >>>On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected > >>>to a mux and the output from mux is routed to the bypass clkout. > >>>Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents. > >>> > >>>Tested against: > >>> tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git > >>> branch: master > >>>On: > >>>CPU : OMAP5432 ES2.0 > >>>Board: OMAP5432 uEVM > >>>and > >>>CPU : DRA752 ES1.0 > >>>Board: DRA7xx > >>> > >>> > >>>Ravikumar Kattekola (2): > >>> ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others > >>> ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others > >>> > >>> arch/arm/boot/dts/dra7xx-clocks.dtsi | 90 > >>> > >>> arch/arm/boot/dts/omap54xx-clocks.dtsi | 41 +-- > >>> 2 files changed, 118 insertions(+), 13 deletions(-) > >>> > >>Hi Benoit, > >> Can these fixes be looked into for 3.20-rc? > > > >Seem like valid fixes to me. Tero, care to take a look at these and ack > >if OK? > > Yes, both are good to go. > > Acked-by: Tero Kristo Applying both into omap-for-v4.0/fixes thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: at91/dt: fix macb compatible strings
Le 06/03/2015 11:24, Boris Brezillon a écrit :
> Some at91 SoCs embed a 10/100 Mbit Ethernet IP, that is based on the
> at91sam9260 SoC.
> Fix at91 DTs accordingly.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alexandre Belloni
Acked-by: Nicolas Ferre
> ---
> arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9x5_macb0.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9x5_macb1.dtsi | 2 +-
> arch/arm/boot/dts/sama5d3_emac.dtsi | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
> b/arch/arm/boot/dts/at91sam9260.dtsi
> index fff0ee6..9f7c737 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -842,7 +842,7 @@
> };
>
> macb0: ethernet@fffc4000 {
> - compatible = "cdns,at32ap7000-macb",
> "cdns,macb";
> + compatible = "cdns,at91sam9260-macb",
> "cdns,macb";
> reg = <0xfffc4000 0x100>;
> interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
> b/arch/arm/boot/dts/at91sam9263.dtsi
> index 1f67bb4..340179e 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -845,7 +845,7 @@
> };
>
> macb0: ethernet@fffbc000 {
> - compatible = "cdns,at32ap7000-macb",
> "cdns,macb";
> + compatible = "cdns,at91sam9260-macb",
> "cdns,macb";
> reg = <0xfffbc000 0x100>;
> interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
> b/arch/arm/boot/dts/at91sam9g45.dtsi
> index ee80aa9..586eab7 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -956,7 +956,7 @@
> };
>
> macb0: ethernet@fffbc000 {
> - compatible = "cdns,at32ap7000-macb",
> "cdns,macb";
> + compatible = "cdns,at91sam9260-macb",
> "cdns,macb";
> reg = <0xfffbc000 0x100>;
> interrupts = <25 IRQ_TYPE_LEVEL_HIGH 3>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
> b/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
> index 57e89d1..73d7e30 100644
> --- a/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
> @@ -53,7 +53,7 @@
> };
>
> macb0: ethernet@f802c000 {
> - compatible = "cdns,at32ap7000-macb",
> "cdns,macb";
> + compatible = "cdns,at91sam9260-macb",
> "cdns,macb";
> reg = <0xf802c000 0x100>;
> interrupts = <24 IRQ_TYPE_LEVEL_HIGH 3>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
> b/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
> index 663676c..d81980c 100644
> --- a/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
> @@ -41,7 +41,7 @@
> };
>
> macb1: ethernet@f803 {
> - compatible = "cdns,at32ap7000-macb",
> "cdns,macb";
> + compatible = "cdns,at91sam9260-macb",
> "cdns,macb";
> reg = <0xf803 0x100>;
> interrupts = <27 IRQ_TYPE_LEVEL_HIGH 3>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/sama5d3_emac.dtsi
> b/arch/arm/boot/dts/sama5d3_emac.dtsi
> index fe2af92..b4544cf 100644
> --- a/arch/arm/boot/dts/sama5d3_emac.dtsi
> +++ b/arch/arm/boot/dts/sama5d3_emac.dtsi
> @@ -41,7 +41,7 @@
> };
>
> macb1: ethernet@f802c000 {
> - compatible = "cdns,at32ap7000-macb",
> "cdns,macb";
> + compatible = "cdns,at91sam9260-macb",
> "cdns,macb";
> reg = <0xf802c000 0x100>;
> interrupts = <35 IRQ_TYPE_LEVEL_HIGH 3>;
> pinctrl-names = "default";
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] net: macb: rework at91 specific handling
Le 06/03/2015 11:23, Boris Brezillon a écrit : > Hello, > > This removes the #if defined(ARCH_AT91) sections to prevent any problem > when enabling ARM multi-platform support. > The at91 specific logic is now activated when the "at91sam9260-macb" > compatible string is found. > > Best Regards, > > Boris I'm okay with the whole series: Acked-by: Nicolas Ferre > > Changes since v1: > - avoid changing existing behavior as Alexandre suggested > > Boris Brezillon (3): > net/macb: Update DT bindings documentation > ARM: at91/dt: fix macb compatible strings > net: macb: remove #if defined(CONFIG_ARCH_AT91) sections > > Documentation/devicetree/bindings/net/macb.txt | 5 +++- > arch/arm/boot/dts/at91sam9260.dtsi | 2 +- > arch/arm/boot/dts/at91sam9263.dtsi | 2 +- > arch/arm/boot/dts/at91sam9g45.dtsi | 2 +- > arch/arm/boot/dts/at91sam9x5_macb0.dtsi| 2 +- > arch/arm/boot/dts/at91sam9x5_macb1.dtsi| 2 +- > arch/arm/boot/dts/sama5d3_emac.dtsi| 2 +- > drivers/net/ethernet/cadence/macb.c| 32 > ++ > drivers/net/ethernet/cadence/macb.h| 2 ++ > 9 files changed, 29 insertions(+), 22 deletions(-) > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/17] crypto: talitos - Add support for SEC1
The purpose of this set of patchs is to add to talitos crypto driver the support for the SEC1 version of the security engine, which is found in mpc885 and mpc8272 processors. The approach has been to split the driver in two main parts: * talitos.c and talitos.h contains parts that are common * talitos2.c and talitos2.h contains specificities of SEC2 Then * talitos1.c and talitos1.h has been created with SEC1 specificities v2 applies cleanly on this afternoon's (06 March 2015) cryptodev-2.6 tree (commit c83d45d5) Patchset: [01/17] crypto: talitos - base address for Execution Units and macro for ISR masks [02/17] crypto: talitos - Externalise specific SEC2 reset actions [03/17] crypto: talitos - Use zero entry to init descriptors ptrs to zero [04/17] crypto: talitos - Refactor the sg in/out chain allocation [05/17] crypto: talitos - isolate scatter/gather handling for ahash [06/17] crypto: talitos - Add talitos2.c to isolate SEC2 specific functions [07/17] crypto: talitos - Split talitos.h into 2 parts [08/17] crypto: talitos - Deport SEC2 error handling [09/17] crypto: talitos - Move reset/init helpers into talitos2.h [10/17] crypto: talitos - Move interrupt related macros in talitos2.h [11/17] crypto: talitos - Move hash chain handling into talitos2.h [12/17] crypto: talitos - Define compatible in talitos2.h instead of talitos.c [13/17] crypto: talitos - move sg_count() helper into talitos.h [14/17] crypto: talitos - Add a helper function to clear j_extent field [15/17] crypto: talitos - Implementation of SEC1 [16/17] crypto: talitos - SEC1 bugs on 0 data hash [17/17] crypto: talitos - Update DT bindings with SEC1 Signed-off-by: Christophe Leroy .../devicetree/bindings/crypto/fsl-sec2.txt| 5 +- drivers/crypto/Kconfig | 8 + drivers/crypto/Makefile| 2 + drivers/crypto/talitos.c | 927 + drivers/crypto/talitos.h | 183 ++-- drivers/crypto/talitos1.c | 197 + drivers/crypto/talitos1.h | 343 drivers/crypto/talitos2.c | 696 drivers/crypto/talitos2.h | 335 9 files changed, 1734 insertions(+), 962 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 17/17] crypto: talitos - Update DT bindings with SEC1
This patch updates the documentation by including SEC1 into SEC2/3 doc Signed-off-by: Christophe Leroy --- Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt index 38988ef..570d6a2 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt @@ -1,9 +1,10 @@ -Freescale SoC SEC Security Engines versions 2.x-3.x +Freescale SoC SEC Security Engines versions 1.x-2.x-3.x Required properties: - compatible : Should contain entries for this and backward compatible - SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" + SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" (SEC2/3) + e.g., "fsl,sec1.2", "fsl,sec1.0" (SEC1) - reg : Offset and length of the register set for the device - interrupts : the SEC's interrupt number - fsl,num-channels : An integer representing the number of channels -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
On Fri, Mar 06, 2015 at 09:16:44AM -0600, Rob Herring wrote:
> On Fri, Mar 6, 2015 at 9:09 AM, Matt Porter wrote:
> > The imx-pwm binding contains language indicating compatible
> > strings to be used that is not valid for all supported parts
> > e.g. Should be "fsl,-pwm". Fix this by enumerating the
> > valid compatible strings that represent the two versions of
> > this peripheral in use.
> >
> > The binding is also missing the clocks/clock-names properties
> > so document these,the two required ipg and per clocks, and add
> > add these properties to the example.
> >
> > Signed-off-by: Matt Porter
> > ---
> > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > index b50d7a6d..30d2b82 100644
> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > @@ -1,10 +1,16 @@
> > Freescale i.MX PWM controller
> >
> > Required properties:
> > -- compatible: should be "fsl,-pwm"
> > +- compatible :
> > + - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> > + - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
>
> This should be one of these and a more specific value as the example
> below shows.
Ok, yes, I wasn't sure if that was expected to be explicit in the bindings
or not as others don't seem to represent that properly. What about this?
- compatible: should be "fsl,-pwm" and one of the following
compatible strings:
"fsl,imx1-pwm" for an iMX1 compatible PWM
"fsl,imx27-pwm" for an iMX27 compatible PWM
> > - reg: physical base address and length of the controller's registers
> > - #pwm-cells: should be 2. See pwm.txt in this directory for a description
> > of
> >the cells format.
> > +- clocks : Clock specifiers for both ipg and per clocks.
> > +- clock-names : Clock names should include both "ipg" and "per"
> > +See the clock consumer binding,
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt
> > - interrupts: The interrupt for the pwm controller
> >
> > Example:
> > @@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
> > #pwm-cells = <2>;
> > compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> > reg = <0x53fb4000 0x4000>;
> > + clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
> > +<&clks IMX5_CLK_PWM1_HF_GATE>;
> > + clock-names = "ipg", "per";
> > interrupts = <61>;
> > };
> > --
> > 1.8.4
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] SATA: OCTEON: support SATA on OCTEON platform
On 03/06/2015 02:06 AM, Hans de Goede wrote:
Hi,
On 05-03-15 15:58, Aleksey Makarov wrote:
The OCTEON SATA controller is currently found on cn71XX devices.
Signed-off-by: David Daney
Signed-off-by: Vinita Gupta
Signed-off-by: Aleksey Makarov
---
[...]
diff --git
a/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
new file mode 100644
index 000..59e86a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
@@ -0,0 +1,28 @@
+* UCTL SATA controller glue
+
+Properties:
+- compatible: "cavium,octeon-7130-sata-uctl"
+
+ Compatibility with the cn7130 SOC.
+
+- reg: The base address of the UCTL register bank.
+
+- #address-cells, #size-cells, and ranges must be present and hold
+suitable values to map all child nodes.
+
+Example:
+
+uctl@118006c00 {
+compatible = "cavium,octeon-7130-sata-uctl";
+reg = <0x11800 0x6c00 0x0 0x100>;
+ranges; /* Direct mapping */
+#address-cells = <2>;
+#size-cells = <2>;
+
+sata: sata@16c00 {
+compatible = "cavium,octeon-7130-ahci";
+reg = <0x16c00 0x 0x0 0x200>;
+interrupt-parent = <&cibsata>;
+interrupts = <2 4>; /* Bit: 2, level */
+};
+};
Sorry for jumping into this discussion a bit late, but this nonsense
nesting of what clearly are 2 related but different hw blocks,
both living at completely different register addresses is unacceptable,
this is not a proper operating system dependent hw description as
devicetree is supposed to be. This is an ugly hack to ensure a
certain init ordering, and requiring manual instantiation of
the platform device for the nested dt-node.
NACK.
Can you point to the portion of the device tree specification that
states that if a node has both "reg" *and* "ranges" properties, the
parent-bus-address ranges must be a proper subset of the "reg" property
ranges of the parent? Because that seems like what you are saying
here. I would really like to read the documentation myself so that we
can get a better understanding of the requirements.
For what it's worth, there are existing bindings that take the same
form, and they don't seem to break anything. See for example
Documentation/devicetree/bindings/mips/cavium/uctl.txt
In any event, it is somewhat moot at this point. The device tree being
effectively being a frozen ABI, cannot really be changed. We are merely
documenting what is supplied by the preexisting system boot ROMs, not
starting from scratch and discussing what the proper device tree binding
for the device should be.
Thanks,
David Daney
[...]
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch V7 02/10] ASoC: qcom: Document LPASS CPU bindings
On Mar 5, 2015, at 7:51 PM, Kenneth Westfield wrote: > On Thu, Mar 05, 2015 at 12:52:30PM -0600, Kumar Gala wrote: >> >> On Mar 3, 2015, at 6:21 PM, Kenneth Westfield >> wrote: >> >>> +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt >>> @@ -0,0 +1,49 @@ >>> +* Qualcomm Technologies LPASS CPU DAI >>> + >>> +Required subnodes: >>> + >>> +- qcom,adsp: Audio DSP sub-node >>> + >>> +Optional Audio DSP subnode properties: >>> + >>> +- status : "disabled" indicates the adsp is not available. >>> + >> >> What is the intent of this subnode? >> > > From the cover letter: > Even though the ipq806x LPASS does not contain an audio DSP, other SOCs > do have one. For those SOCs, the audio DSP typically controls the > hardware blocks in the LPASS. Hence, different CPU DAI driver(s) would > need to be used in order to facilitate audio with the DSP. As such, the > LPASS DT contains an adsp subnode, which is disabled for this SOC. The > same subnode should be enabled and populated for other SOCs that do > contain an audio DSP. Not using the audio DSP would require different > CPU DAI driver(s), in addition to possible bootloader and/or firmware > changes. > > This was the result of a request from Mark. See here: > http://thread.gmane.org/gmane.linux.drivers.devicetree/109331/focus=11633 Two quick comments before I read Mark’s comments. 1. Its not normal practice to put something into a DT that does not exist. Having a node, but marking it disabled implies existence. 2. How would one normally address the audio DSP if it did exist. I’m just wondering if having a subnode is the proper solution vs maybe a phandle - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
On Mar 5, 2015, at 7:59 PM, Olof Johansson wrote: > On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala wrote: >> >> On Mar 5, 2015, at 1:42 PM, Kevin Hilman wrote: >> >>> Kumar Gala writes: >>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel. Cc: Signed-off-by: Kumar Gala >>> >>> Is this the special magic that allows qcom bootloaders to take a kernel >>> plus multiple DTBs and figure out which DTB to pass? >>> >>> Kevin >> >> yes > > That's a bummer. > > Luckily, the solution for upstream is still quite simple: Provide only > one devicetree, and it'll be used, right? We can provide only one, we still need the IDs in the DT. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
On 6 Mar 2015, ste...@agner.ch wrote:
> On 2015-03-06 07:15, Sascha Hauer wrote:
>> Hi Stefan,
>> On Thu, Mar 05, 2015 at 12:10:20AM +0100, Stefan Agner wrote:
>>> +
>>> +static int vf610_nfc_probe_dt(struct device *dev, struct
>>> vf610_nfc_config *cfg)
>>> +{
>>> + struct device_node *np = dev->of_node;
>>> + int buswidth;
>>> + u32 clkrate;
>>> +
>>> + if (!np)
>>> + return 1;
>>> +
>>> + cfg->flash_bbt = of_get_nand_on_flash_bbt(np);
>>> +
>>> + if (!of_property_read_u32(np, "clock-frequency", &clkrate))
>>> + cfg->clkrate = clkrate;
>> Normally the clock-frequency property tells the driver at which
>> frequency the device actually is running, not to tell the driver at
>> which frequency the device *should* run. It's strange to use the
>> value of the clock-frequency property as input to
>> clk_set_rate(). Maybe the assigned clock binding is more appropriate
>> here, see Documentation/devicetree/bindings/clock/clock-bindings.txt.
> What we try to do here is to specify the hardware limitations. There
> seem to be some hardware restrictions when it comes to clock
> frequencies. There has been a rather long discussion over at
> Freescales community about it:
> https://community.freescale.com/thread/317074
> Not sure if this is the right way to specify the supported
> frequencies, or should we create a custom property for this, something
> like fsl,max-nfc-frequency = <3300>?
On most SOC's with this controller, the input clock to the controller
affects the NAND flash timing and other factors; so you will want to set
it based on the board/NAND stuffed. The clock is for synchronous logic
in the controller and affects many properties.
I guess Sascha's point is, the board's DT should just have some
'&nfc_clk' node and not have this part of the driver? Either way works.
However, this clock is very important to get the driver to function. It
seem better for a user/porter to have this info in the node. I guess
you need to be trained to look at every node in the sub-tree for a
device. I think the other way might be better or a sub-system
maintainer. I looked at 'i2c' and other node which have a
'clock-frequency' parameter.
In the Documentation/devicetree/bindings/clock/clock-bindings.txt,
uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
interrupts = <33>;
clocks = <&osc 0>, <&pll 1>;
clock-names = "baud", "register";
};
Here, this uart clock may affect the maximum baud rate supported by the
device. For this controller (vf610_nfc), the clock is like setting the
'baud rate'; it affect the NAND memory cycles. There is not really any
'wait state' type logic in the controller register set that would allow
the driver to work with a 'given clock' rate. For certain a board
should set this clock for the NAND chips they wish to support.
What would the board file look like to use clock node?
[generic]
nfc: nand@400e {
compatible = "fsl,vf610-nfc";
reg = <0x400e 0x4000>;
clocks = <&clks VF610_CLK_NFC>;
clock-names = "nfc_clk";
status = "disabled";
};
[board]
&nfc {
nand-bus-width = <16>;
nand-ecc-mode = "hw";
nand-on-flash-bbt;
nand-ecc-strength = <24>;
nand-ecc-step-size = <2048>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nfc_1>;
status = "okay";
&nfc_clk { frequency = <3300>} /* Like this? */
};
I don't know how to do the 'Like this?' part. I don't think the
'clock-bindings.txt' explains it. I see this is better as the the
driver needs no 'clock handling' code. It is definitely a little more
obtuse for the users.
[snip]
>> Does this driver work without device tree or not? Currently the
>> driver bails out when device tree support is enabled but no device
>> node is given. When device tree support is disabled in the kernel
>> though the driver happily continues here.
> Hm, I never tried using this Driver without DT.
[snip]
I also didn't test this. The driver was ported from Linux versions
where DT did not exist. It is used in some OpenWRT/68k/coldfire
(patched) kernels and I wanted it to be useful for them. However, we
could probably remove the 'platform support'. Other people are using
this on PPC platforms and they will also have dt/of.
Currently the platform control has no way to 'pass data', so the driver
only works with whatever defaults it has (or that is my belief). For
instance, those OpenWRT kernels have a 'machine file' which will set the
'clock-frequency' and other parameters. We could remove the platform
support completely if it is misleading. I guess the KConfig would need
a 'depends on CONFIG_OF'.
Thanks for the review,
Bill Pringlemeir.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI
On 03/06/15 17:36, Tony Lindgren wrote: * Jyri Sarha [150306 07:37]: Use new binding for the external tda19988 HDMI encoder. Can this be merged separately after the driver code is merged with things still working? Yes absolutely. That is why DRM_TILCDC_SLAVE_COMPAT is there for. Cheers, Jyri -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI
* Jyri Sarha [150306 07:37]:
> Use new binding for the external tda19988 HDMI encoder.
Can this be merged separately after the driver code is
merged with things still working?
Otherwise we can have glitches with the output working and
have dependencies between kernel branches.
Regards,
Tony
> Signed-off-by: Jyri Sarha
> ---
> arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index 5c42d25..eadbba3 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -68,16 +68,26 @@
>
> &lcdc {
> status = "okay";
> + port {
> + lcdc_0: endpoint@0 {
> + remote-endpoint = <&hdmi_0>;
> + };
> + };
> };
>
> -/ {
> - hdmi {
> - compatible = "ti,tilcdc,slave";
> - i2c = <&i2c0>;
> +&i2c0 {
> + tda19988 {
> + compatible = "nxp,tda998x";
> + reg = <0x70>;
> pinctrl-names = "default", "off";
> pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> - status = "okay";
> +
> + port {
> + hdmi_0: endpoint@0 {
> + remote-endpoint = <&lcdc_0>;
> + };
> + };
> };
> };
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support
Adds a CONFIG_DRM_TILCDC_SLAVE_COMPAT module for "ti,tilcdc,slave"
node conversion. The implementation is in tilcdc_slave_compat.c and it
uses tilcdc_slave_compat.dts as a basis for creating a DTS
overlay. The DTS overlay adds an external tda998x encoder to tilcdc
that corresponds to the old tda998x based slave encoder.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/Kconfig | 13 ++
drivers/gpu/drm/tilcdc/Makefile| 3 +
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 270 +
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 +++
4 files changed, 358 insertions(+)
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 8394a0b..7e1e72b 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,3 +1,15 @@
+config DRM_TILCDC_SLAVE_COMPAT
+ bool "Support device tree blobs using TI LCDC Slave binding"
+ depends on DRM_TILCDC
+ default y
+ select OF_RESOLVE
+ select OF_OVERLAY
+ help
+ Choose this option if you need a kernel that is compatible
+ with device tree blobs using the obsolete "ti,tilcdc,slave"
+ binding. If you find "ti,tilcdc,slave"-string from your DTB,
+ you probably need this. Otherwise you do not.
+
config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM && HAVE_DMA_ATTRS
@@ -8,6 +20,7 @@ config DRM_TILCDC
select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
select BACKLIGHT_LCD_SUPPORT
+ select DRM_TILCDC_INIT
help
Choose this option if you have an TI SoC with LCDC display
controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index e1f738b..deeca48 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,9 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
endif
+obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \
+tilcdc_slave_compat.dtb.o
+
tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
new file mode 100644
index 000..cc9572d
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+/*
+ * To support the old "ti,tilcdc,slave" binding the binding has to be
+ * transformed to the new external encoder binding.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct kfree_table {
+ int total;
+ int num;
+ void **table;
+};
+
+static int __init kfree_table_init(struct kfree_table *kft)
+{
+ kft->total = 32;
+ kft->num = 0;
+ kft->table = kmalloc(kft->total * sizeof(*kft->table),
+GFP_KERNEL);
+ if (!kft->table)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int __init kfree_table_add(struct kfree_table *kft, void *p)
+{
+ if (kft->num == kft->total) {
+ void **old = kft->table;
+
+ kft->total *= 2;
+ kft->table = krealloc(old, kft->total * sizeof(*kft->table),
+ GFP_KERNEL);
+ if (!kft->table) {
+ kft->table = old;
+ kfree(p);
+ return -ENOMEM;
+ }
+ }
+ kft->table[kft->num++] = p;
+ return 0;
+}
+
+static void __init kfree_table_free(struct kfree_table *kft)
+{
+ int i;
+
+ for (i = 0; i < kft->num; i++)
+ kfree(kft->table[i]);
+
+ kfree(kft->table);
+}
+
+static
+struct property * __init tilcdc_prop_dup(const struct property *prop,
+struct kfree_table *kft)
+{
+ struct property *nprop;
+
+ nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
+ if (!nprop || kfree_table_add(kft, nprop))
+ return NULL;
+
+ nprop->name = kstrdup(prop->name, GFP_KERNEL);
+ if (!nprop->name || kfree_table_add(kft, nprop->name))
+ return NULL;
+
+ nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL);
+ if (!nprop->value || kfree_table_add(kft, nprop->value))
+ return NULL;
+
+ nprop->length = prop->length;
+
+ return nprop;
+}
+
+static void __init tilcdc_copy_props(struct device_node *from,
[PATCH v2 4/7] drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
This patch should be dropped/reverterd if/after "of: Decrement refcount
of previous endpoint in of_graph_get_next_endpoint" patch has been
merged.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 61f8aee..1dd6c20 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -83,6 +83,7 @@ int tilcdc_get_external_components(struct device *dev,
struct device_node *node;
node = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
if (!node && !of_device_is_available(node)) {
of_node_put(node);
continue;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
If I read Documentation/kbuild/makefiles.txt section 3.6 right, this patch should not be needed. However, without this patch the objects needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is built as module. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..ad7f10f 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ +obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc/ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ obj-$(CONFIG_DRM_MSM) += msm/ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] drm/tilcdc: Remove tilcdc slave support for tda998x driver
Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/drm/tilcdc/slave.txt | 18 -
drivers/gpu/drm/tilcdc/Makefile| 1 -
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 13 -
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 1 -
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 411 -
drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 --
6 files changed, 470 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
- muxing properly for pins that connect to TFP410 device
-
-Example:
-
- hdmi {
- compatible = "ti,tilcdc,slave";
- i2c = <&i2c0>;
- pinctrl-names = "default";
- pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
- };
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
- tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 095fca9..0f1e099 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,13 +20,11 @@
#include "tilcdc_drv.h"
#include "tilcdc_regs.h"
#include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
#include "tilcdc_panel.h"
#include "drm_fb_helper.h"
static LIST_HEAD(module_list);
-static bool slave_probing;
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(&mod->list);
}
-void tilcdc_slave_probedefer(bool defered)
-{
- slave_probing = defered;
-}
-
static struct of_device_id tilcdc_of_match[];
static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}
- /* defer probing if slave is in deferred probing */
- if (slave_probing == true)
- return -EPROBE_DEFER;
-
return drm_platform_init(&tilcdc_driver, pdev);
}
@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
{
DBG("init");
tilcdc_tfp410_init();
- tilcdc_slave_init();
tilcdc_panel_init();
return platform_driver_register(&tilcdc_platform_driver);
}
@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
DBG("fini");
platform_driver_unregister(&tilcdc_platform_driver);
tilcdc_panel_fini();
- tilcdc_slave_fini();
tilcdc_tfp410_fini();
}
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7596c14..6336512 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);
/* Panel config that needs to be set in the crtc, but is not coming from
* the mode timings. The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
deleted file mode 100644
index 3775fd4..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ /dev/null
@@ -1,411 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You sho
[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI
Use new binding for the external tda19988 HDMI encoder.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@
&lcdc {
status = "okay";
+ port {
+ lcdc_0: endpoint@0 {
+ remote-endpoint = <&hdmi_0>;
+ };
+ };
};
-/ {
- hdmi {
- compatible = "ti,tilcdc,slave";
- i2c = <&i2c0>;
+&i2c0 {
+ tda19988 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
- status = "okay";
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = <&lcdc_0>;
+ };
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Use DRM component API in tilcdc to connect to tda998x
Changes since first version of the patch-set: - Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible - Add separate: drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint - Reduce info-level spam - Use component_master_add_with_match() - Be more explicit about tda998x being the only supported external encoder Remove tilcdc slave support and connect to tda998x trough its component DRM API. For dtb backward compatibility the code creates at boot time a DT overlay based on the earlier binding. The overlay conforms to the new graph based binding. The first patch is just a bugfix and can be applied or dropped independently. Jyri Sarha (7): drm/tilcdc: Fix module unloading drm/tilcdc: Remove tilcdc slave support for tda998x driver drm/tilcdc: Add support for external tda998x encoder drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT ARM: dts: am335x-boneblack: Use new binding for HDMI .../devicetree/bindings/drm/tilcdc/slave.txt | 18 - .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 27 ++ arch/arm/boot/dts/am335x-boneblack.dts | 20 +- drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/tilcdc/Kconfig | 13 + drivers/gpu/drm/tilcdc/Makefile| 5 +- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 36 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c| 89 +++-- drivers/gpu/drm/tilcdc/tilcdc_drv.h| 5 +- drivers/gpu/drm/tilcdc/tilcdc_external.c | 105 ++ drivers/gpu/drm/tilcdc/tilcdc_external.h | 24 ++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 411 - drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 -- drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 270 ++ drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 15 files changed, 633 insertions(+), 489 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] drm/tilcdc: Add support for external tda998x encoder
Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The current
implementation supports only tda998x encoder.
I got the idea and some lines of code from Jean-Francois Moine's
"drm/tilcdc: Change the interface with the tda998x driver"-patch.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/drm/tilcdc/tilcdc.txt | 27 ++
drivers/gpu/drm/tilcdc/Makefile| 1 +
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 33 +++
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 76 ---
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 4 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 104 +
drivers/gpu/drm/tilcdc/tilcdc_external.h | 24 +
7 files changed, 256 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
- max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+ binding follows Documentation/devicetree/bindings/graph.txt and
+ suppors a single port with a single endpoint.
+
Example:
fb: fb@4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
+
+ port {
+ lcdc_0: endpoint@0 {
+ remote-endpoint = <&hdmi_0>;
+ };
+ };
+ };
+
+ tda19988: tda19988 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+
+ pinctrl-names = "default", "off";
+ pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = <&lcdc_0>;
+ };
+ };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+ tilcdc_external.o \
tilcdc_drv.o
obj-$(CONFIG_DRM_TILCDC) += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {
/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+ /* Only set if an external encoder is connected */
+ bool simulate_vesa_sync;
};
#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+ if (!tilcdc_crtc->simulate_vesa_sync)
+ return true;
+
+ /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+ adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+ adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+ adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+ adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+ } else {
+ adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+ adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+ }
+
return true;
}
@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc->info = info;
}
+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+ bool simulate_vesa_sync)
+{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+ tilcdc_crtc->simulate_vesa_sync = simulate_vesa_sync;
+}
+
void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
diff --git a/drivers/
[PATCH v2 1/7] drm/tilcdc: Fix module unloading
Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
}
+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
- WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
+ tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: jz4740: Add jz4780 support
The jz4780 and jz4740 have very similar i2s blocks.
The slight difference is in Rx/Tx fifos.
And the bitclocks for input/output are different.
This patch adds jz4780 support to the driver
Signed-off-by: Zubair Lutfullah Kakakhel
---
Patch based on 4.0-rc2
Tested on the MIPS Creator CI20.
---
.../bindings/sound/ingenic,jz4740-i2s.txt | 2 +-
sound/soc/jz4740/jz4740-i2s.c | 63 ++
2 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
b/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
index b414333..b623d50 100644
--- a/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/ingenic,jz4740-i2s.txt
@@ -1,7 +1,7 @@
Ingenic JZ4740 I2S controller
Required properties:
-- compatible : "ingenic,jz4740-i2s"
+- compatible : "ingenic,jz4740-i2s" or "ingenic,jz4780-i2s"
- reg : I2S registers location and length
- clocks : AIC and I2S PLL clock specifiers.
- clock-names: "aic" and "i2s"
diff --git a/sound/soc/jz4740/jz4740-i2s.c b/sound/soc/jz4740/jz4740-i2s.c
index 07f7781..630ea96 100644
--- a/sound/soc/jz4740/jz4740-i2s.c
+++ b/sound/soc/jz4740/jz4740-i2s.c
@@ -58,6 +58,12 @@
#define JZ_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET 12
#define JZ_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET 8
+#define JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET 24
+#define JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET 16
+#define JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_MASK \
+ (0xf << JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET)
+#define JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_MASK \
+ (0x1f << JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET)
#define JZ_AIC_CTRL_OUTPUT_SAMPLE_SIZE_MASK (0x7 << 19)
#define JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_MASK (0x7 << 16)
@@ -79,6 +85,7 @@
#define JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_OFFSET 16
#define JZ_AIC_I2S_FMT_DISABLE_BIT_CLK BIT(12)
+#define JZ_AIC_I2S_FMT_DISABLE_BIT_ICLK BIT(13)
#define JZ_AIC_I2S_FMT_ENABLE_SYS_CLK BIT(4)
#define JZ_AIC_I2S_FMT_MSB BIT(0)
@@ -87,6 +94,13 @@
#define JZ_AIC_CLK_DIV_MASK 0xf
#define I2SDIV_DV_SHIFT 8
#define I2SDIV_DV_MASK (0xf << I2SDIV_DV_SHIFT)
+#define I2SDIV_IDV_SHIFT 8
+#define I2SDIV_IDV_MASK (0xf << I2SDIV_IDV_SHIFT)
+
+enum jz47xx_i2s_version {
+ JZ_I2S_JZ4740,
+ JZ_I2S_JZ4780,
+};
struct jz4740_i2s {
struct resource *mem;
@@ -98,6 +112,8 @@ struct jz4740_i2s {
struct snd_dmaengine_dai_dma_data playback_dma_data;
struct snd_dmaengine_dai_dma_data capture_dma_data;
+
+ enum jz47xx_i2s_version version;
};
static inline uint32_t jz4740_i2s_read(const struct jz4740_i2s *i2s,
@@ -267,13 +283,22 @@ static int jz4740_i2s_hw_params(struct snd_pcm_substream
*substream,
ctrl |= JZ_AIC_CTRL_MONO_TO_STEREO;
else
ctrl &= ~JZ_AIC_CTRL_MONO_TO_STEREO;
+
+ div_reg &= ~I2SDIV_DV_MASK;
+ div_reg |= (div - 1) << I2SDIV_DV_SHIFT;
} else {
ctrl &= ~JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_MASK;
ctrl |= sample_size << JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_OFFSET;
+
+ if (i2s->version >= JZ_I2S_JZ4780) {
+ div_reg &= ~I2SDIV_IDV_MASK;
+ div_reg |= (div - 1) << I2SDIV_IDV_SHIFT;
+ } else {
+ div_reg &= ~I2SDIV_DV_MASK;
+ div_reg |= (div - 1) << I2SDIV_DV_SHIFT;
+ }
}
- div_reg &= ~I2SDIV_DV_MASK;
- div_reg |= (div - 1) << I2SDIV_DV_SHIFT;
jz4740_i2s_write(i2s, JZ_REG_AIC_CTRL, ctrl);
jz4740_i2s_write(i2s, JZ_REG_AIC_CLK_DIV, div_reg);
@@ -369,11 +394,19 @@ static int jz4740_i2s_dai_probe(struct snd_soc_dai *dai)
snd_soc_dai_init_dma_data(dai, &i2s->playback_dma_data,
&i2s->capture_dma_data);
- conf = (7 << JZ_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET) |
- (8 << JZ_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET) |
- JZ_AIC_CONF_OVERFLOW_PLAY_LAST |
- JZ_AIC_CONF_I2S |
- JZ_AIC_CONF_INTERNAL_CODEC;
+ if (i2s->version >= JZ_I2S_JZ4780) {
+ conf = (7 << JZ4780_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET) |
+ (8 << JZ4780_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET) |
+ JZ_AIC_CONF_OVERFLOW_PLAY_LAST |
+ JZ_AIC_CONF_I2S |
+ JZ_AIC_CONF_INTERNAL_CODEC;
+ } else {
+ conf = (7 << JZ_AIC_CONF_FIFO_RX_THRESHOLD_OFFSET) |
+ (8 << JZ_AIC_CONF_FIFO_TX_THRESHOLD_OFFSET) |
+ JZ_AIC_CONF_OVERFLOW_PLAY_LAST |
+ JZ_AIC_CONF_I2S |
+ JZ_AIC_CONF_INTERNAL_CODEC;
+ }
jz4740_i2s_write(i2s, JZ_REG_AIC_CONF, JZ_AIC_CONF_RESET);
jz4740_i2s_write(i2s, JZ_REG_AIC_CONF, conf);
@@ -428,7 +461
Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver
BTW I am getting doubles of your messages, both addressed to the mailings lists, but only one also addressed to me. You should just send one copy, with everyone on CC. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver
On Fri, Mar 06, 2015 at 10:50:08AM +, Stathis Voukelatos wrote: > Although the PTP way appears to be the best from an architectural point > of view, we have some questions as whether it is suitable for the audio > use cases that this module is mainly intended for. > To use the PTP terminology in a large installation we would have a > potentially large number of clock domains. > It is not clear how to easily manage the creation and allocation of > domains. In addition the clock will be pulled according to the audio > stream and it would be undesirable for other unrelated PTPv2 devices > on the network to join the clock domain and have their clocks > synchronized to it. I don't really know what the problem here is. Yes, there is some networking configuration that you need to do when administering a network using PTP protocols. But these protocols (1588 aka PTP, and 802.1AS aka gPTP) do offer means for dealing with this. In particular, there is no danger mixing 1588 devices with audio devices, because the gPTP protocol uses a different transport flag. In any case, this has nothing at all to do with the kernel interface. > The patch in its current form would allow a move to Linux using our > existing synchronization protocols (which are open-source). A move > to PTP is something to consider but will involve a fair amount of > redesign including upgrade of legacy products. If you want to try and integrate your custom protocols into the networking stack, by all means please post them. I would certainly support expanding the time stamping interface to include your protocol's packet types (like adding them to hwtstamp_rx_filters). Maybe that would be enough for you? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
