* [PATCHv2 net-next 12/16] net: mvpp2: add AXI bridge initialization for PPv2.2
From: Thomas Petazzoni @ 2016-12-28 16:46 UTC (permalink / raw)
To: netdev, David S. Miller, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Nadav Haklai, Hanna Hawa, Yehuda Yitschak, linux-arm-kernel,
Stefan Chulski, Marcin Wojtas, Thomas Petazzoni
In-Reply-To: <1482943592-12556-1-git-send-email-thomas.petazzoni@free-electrons.com>
The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this
commit adds the necessary initialization of the AXI bridge.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 85 ++++++++++++++++++++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index eb55576..d5b197d 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -157,6 +157,34 @@
#define MVPP2_WIN_REMAP(w) (0x4040 + ((w) << 2))
#define MVPP2_BASE_ADDR_ENABLE 0x4060
+/* AXI Bridge Registers */
+#define MVPP22_AXI_BM_WR_ATTR_REG 0x4100
+#define MVPP22_AXI_BM_RD_ATTR_REG 0x4104
+#define MVPP22_AXI_AGGRQ_DESCR_RD_ATTR_REG 0x4110
+#define MVPP22_AXI_TXQ_DESCR_WR_ATTR_REG 0x4114
+#define MVPP22_AXI_TXQ_DESCR_RD_ATTR_REG 0x4118
+#define MVPP22_AXI_RXQ_DESCR_WR_ATTR_REG 0x411c
+#define MVPP22_AXI_RX_DATA_WR_ATTR_REG 0x4120
+#define MVPP22_AXI_TX_DATA_RD_ATTR_REG 0x4130
+#define MVPP22_AXI_RD_NORMAL_CODE_REG 0x4150
+#define MVPP22_AXI_RD_SNOOP_CODE_REG 0x4154
+#define MVPP22_AXI_WR_NORMAL_CODE_REG 0x4160
+#define MVPP22_AXI_WR_SNOOP_CODE_REG 0x4164
+
+/* Values for AXI Bridge registers */
+#define MVPP22_AXI_ATTR_CACHE_OFFS 0
+#define MVPP22_AXI_ATTR_DOMAIN_OFFS 12
+
+#define MVPP22_AXI_CODE_CACHE_OFFS 0
+#define MVPP22_AXI_CODE_DOMAIN_OFFS 4
+
+#define MVPP22_AXI_CODE_CACHE_NON_CACHE 0x3
+#define MVPP22_AXI_CODE_CACHE_WR_CACHE 0x7
+#define MVPP22_AXI_CODE_CACHE_RD_CACHE 0xb
+
+#define MVPP22_AXI_CODE_DOMAIN_OUTER_DOM 2
+#define MVPP22_AXI_CODE_DOMAIN_SYSTEM 3
+
/* Interrupt Cause and Mask registers */
#define MVPP2_ISR_RX_THRESHOLD_REG(rxq) (0x5200 + 4 * (rxq))
#define MVPP2_MAX_ISR_RX_THRESHOLD 0xfffff0
@@ -6640,6 +6668,60 @@ static void mvpp2_rx_fifo_init(struct mvpp2 *priv)
mvpp2_write(priv, MVPP2_RX_FIFO_INIT_REG, 0x1);
}
+static void mvpp2_axi_init(struct mvpp2 *priv)
+{
+ u32 val, rdval, wrval;
+
+ mvpp2_write(priv, MVPP22_BM_ADDR_HIGH_RLS_REG, 0x0);
+
+ /* AXI Bridge Configuration */
+
+ rdval = MVPP22_AXI_CODE_CACHE_RD_CACHE
+ << MVPP22_AXI_ATTR_CACHE_OFFS;
+ rdval |= MVPP22_AXI_CODE_DOMAIN_OUTER_DOM
+ << MVPP22_AXI_ATTR_DOMAIN_OFFS;
+
+ wrval = MVPP22_AXI_CODE_CACHE_WR_CACHE
+ << MVPP22_AXI_ATTR_CACHE_OFFS;
+ wrval |= MVPP22_AXI_CODE_DOMAIN_OUTER_DOM
+ << MVPP22_AXI_ATTR_DOMAIN_OFFS;
+
+ /* BM */
+ mvpp2_write(priv, MVPP22_AXI_BM_WR_ATTR_REG, wrval);
+ mvpp2_write(priv, MVPP22_AXI_BM_RD_ATTR_REG, rdval);
+
+ /* Descriptors */
+ mvpp2_write(priv, MVPP22_AXI_AGGRQ_DESCR_RD_ATTR_REG, rdval);
+ mvpp2_write(priv, MVPP22_AXI_TXQ_DESCR_WR_ATTR_REG, wrval);
+ mvpp2_write(priv, MVPP22_AXI_TXQ_DESCR_RD_ATTR_REG, rdval);
+ mvpp2_write(priv, MVPP22_AXI_RXQ_DESCR_WR_ATTR_REG, wrval);
+
+ /* Buffer Data */
+ mvpp2_write(priv, MVPP22_AXI_TX_DATA_RD_ATTR_REG, rdval);
+ mvpp2_write(priv, MVPP22_AXI_RX_DATA_WR_ATTR_REG, wrval);
+
+ val = MVPP22_AXI_CODE_CACHE_NON_CACHE
+ << MVPP22_AXI_CODE_CACHE_OFFS;
+ val |= MVPP22_AXI_CODE_DOMAIN_SYSTEM
+ << MVPP22_AXI_CODE_DOMAIN_OFFS;
+ mvpp2_write(priv, MVPP22_AXI_RD_NORMAL_CODE_REG, val);
+ mvpp2_write(priv, MVPP22_AXI_WR_NORMAL_CODE_REG, val);
+
+ val = MVPP22_AXI_CODE_CACHE_RD_CACHE
+ << MVPP22_AXI_CODE_CACHE_OFFS;
+ val |= MVPP22_AXI_CODE_DOMAIN_OUTER_DOM
+ << MVPP22_AXI_CODE_DOMAIN_OFFS;
+
+ mvpp2_write(priv, MVPP22_AXI_RD_SNOOP_CODE_REG, val);
+
+ val = MVPP22_AXI_CODE_CACHE_WR_CACHE
+ << MVPP22_AXI_CODE_CACHE_OFFS;
+ val |= MVPP22_AXI_CODE_DOMAIN_OUTER_DOM
+ << MVPP22_AXI_CODE_DOMAIN_OFFS;
+
+ mvpp2_write(priv, MVPP22_AXI_WR_SNOOP_CODE_REG, val);
+}
+
/* Initialize network controller common part HW */
static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)
{
@@ -6659,6 +6741,9 @@ static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)
if (dram_target_info)
mvpp2_conf_mbus_windows(dram_target_info, priv);
+ if (priv->hw_version == MVPP22)
+ mvpp2_axi_init(priv);
+
/* Disable HW PHY polling */
if (priv->hw_version == MVPP21) {
val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
--
2.7.4
^ permalink raw reply related
* [PATCHv2 net-next 13/16] net: mvpp2: rework RXQ interrupt group initialization for PPv2.2
From: Thomas Petazzoni @ 2016-12-28 16:46 UTC (permalink / raw)
To: netdev, David S. Miller, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Nadav Haklai, Hanna Hawa, Yehuda Yitschak, linux-arm-kernel,
Stefan Chulski, Marcin Wojtas, Thomas Petazzoni
In-Reply-To: <1482943592-12556-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is
configured, since it changed between PPv2.1 and PPv2.2.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 ++++++++++++++++++++++++++++++++----
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index d5b197d..baad991 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -188,7 +188,21 @@
/* Interrupt Cause and Mask registers */
#define MVPP2_ISR_RX_THRESHOLD_REG(rxq) (0x5200 + 4 * (rxq))
#define MVPP2_MAX_ISR_RX_THRESHOLD 0xfffff0
-#define MVPP2_ISR_RXQ_GROUP_REG(rxq) (0x5400 + 4 * (rxq))
+#define MVPP21_ISR_RXQ_GROUP_REG(rxq) (0x5400 + 4 * (rxq))
+
+#define MVPP22_ISR_RXQ_GROUP_INDEX_REG 0x5400
+#define MVPP22_ISR_RXQ_GROUP_INDEX_SUBGROUP_MASK 0xf
+#define MVPP22_ISR_RXQ_GROUP_INDEX_GROUP_MASK 0x380
+#define MVPP22_ISR_RXQ_GROUP_INDEX_GROUP_OFFSET 7
+
+#define MVPP22_ISR_RXQ_GROUP_INDEX_SUBGROUP_MASK 0xf
+#define MVPP22_ISR_RXQ_GROUP_INDEX_GROUP_MASK 0x380
+
+#define MVPP22_ISR_RXQ_SUB_GROUP_CONFIG_REG 0x5404
+#define MVPP22_ISR_RXQ_SUB_GROUP_STARTQ_MASK 0x1f
+#define MVPP22_ISR_RXQ_SUB_GROUP_SIZE_MASK 0xf00
+#define MVPP22_ISR_RXQ_SUB_GROUP_SIZE_OFFSET 8
+
#define MVPP2_ISR_ENABLE_REG(port) (0x5420 + 4 * (port))
#define MVPP2_ISR_ENABLE_INTERRUPT(mask) ((mask) & 0xffff)
#define MVPP2_ISR_DISABLE_INTERRUPT(mask) (((mask) << 16) & 0xffff0000)
@@ -6385,7 +6399,18 @@ static int mvpp2_port_init(struct mvpp2_port *port)
}
/* Configure Rx queue group interrupt for this port */
- mvpp2_write(priv, MVPP2_ISR_RXQ_GROUP_REG(port->id), rxq_number);
+ if (priv->hw_version == MVPP21)
+ mvpp2_write(priv, MVPP21_ISR_RXQ_GROUP_REG(port->id),
+ rxq_number);
+ else {
+ u32 val;
+
+ val = (port->id << MVPP22_ISR_RXQ_GROUP_INDEX_GROUP_OFFSET);
+ mvpp2_write(priv, MVPP22_ISR_RXQ_GROUP_INDEX_REG, val);
+
+ val = (rxq_number << MVPP22_ISR_RXQ_SUB_GROUP_SIZE_OFFSET);
+ mvpp2_write(priv, MVPP22_ISR_RXQ_SUB_GROUP_CONFIG_REG, val);
+ }
/* Create Rx descriptor rings */
for (queue = 0; queue < rxq_number; queue++) {
@@ -6775,8 +6800,20 @@ static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)
mvpp2_rx_fifo_init(priv);
/* Reset Rx queue group interrupt configuration */
- for (i = 0; i < MVPP2_MAX_PORTS; i++)
- mvpp2_write(priv, MVPP2_ISR_RXQ_GROUP_REG(i), rxq_number);
+ for (i = 0; i < MVPP2_MAX_PORTS; i++) {
+ if (priv->hw_version == MVPP21)
+ mvpp2_write(priv, MVPP21_ISR_RXQ_GROUP_REG(i),
+ rxq_number);
+ else {
+ u32 val;
+
+ val = (i << MVPP22_ISR_RXQ_GROUP_INDEX_GROUP_OFFSET);
+ mvpp2_write(priv, MVPP22_ISR_RXQ_GROUP_INDEX_REG, val);
+
+ val = (rxq_number << MVPP22_ISR_RXQ_SUB_GROUP_SIZE_OFFSET);
+ mvpp2_write(priv, MVPP22_ISR_RXQ_SUB_GROUP_CONFIG_REG, val);
+ }
+ }
if (priv->hw_version == MVPP21)
writel(MVPP2_EXT_GLOBAL_CTRL_DEFAULT,
--
2.7.4
^ permalink raw reply related
* [PATCHv2 net-next 14/16] net: mvpp2: adapt rxq distribution to PPv2.2
From: Thomas Petazzoni @ 2016-12-28 16:46 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Nadav Haklai, Hanna Hawa, Yehuda Yitschak,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stefan Chulski,
Marcin Wojtas, Thomas Petazzoni
In-Reply-To: <1482943592-12556-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4
RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7
to the second port, 8->11 to the third port, etc.
In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate
RXQs from the range of 32 RXQs available for each port. So port 0 must
use RXQs in the range 0->31, port 1 in the range 32->63, etc.
This commit adapts the mvpp2 to this difference between PPv2.1 and
PPv2.2:
- The constant definition MVPP2_MAX_RXQ is replaced by a new field
'max_port_rxqs' in 'struct mvpp2', which stores the maximum number of
RXQs per port. This field is initialized during ->probe() depending
on the IP version.
- MVPP2_RXQ_TOTAL_NUM is removed, and instead we calculate the total
number of RXQs by multiplying the number of ports by the maximum of
RXQs per port. This was anyway used in only one place.
- In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted
to cope with the different allocation strategy between PPv2.1 and
PPv2.2. Due to this change, the 'next_first_rxq' argument of this
function is no longer needed and is removed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/net/ethernet/marvell/mvpp2.c | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index baad991..20e9429 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -399,15 +399,9 @@
/* Maximum number of TXQs used by single port */
#define MVPP2_MAX_TXQ 8
-/* Maximum number of RXQs used by single port */
-#define MVPP2_MAX_RXQ 8
-
/* Dfault number of RXQs in use */
#define MVPP2_DEFAULT_RXQ 4
-/* Total number of RXQs available to all ports */
-#define MVPP2_RXQ_TOTAL_NUM (MVPP2_MAX_PORTS * MVPP2_MAX_RXQ)
-
/* Max number of Rx descriptors */
#define MVPP2_MAX_RXD 128
@@ -728,6 +722,9 @@ struct mvpp2 {
/* HW version */
enum { MVPP21, MVPP22 } hw_version;
+
+ /* Maximum number of RXQs per port */
+ unsigned int max_port_rxqs;
};
struct mvpp2_pcpu_stats {
@@ -6333,7 +6330,8 @@ static int mvpp2_port_init(struct mvpp2_port *port)
struct mvpp2_txq_pcpu *txq_pcpu;
int queue, cpu, err;
- if (port->first_rxq + rxq_number > MVPP2_RXQ_TOTAL_NUM)
+ if (port->first_rxq + rxq_number >
+ MVPP2_MAX_PORTS * priv->max_port_rxqs)
return -EINVAL;
/* Disable port */
@@ -6452,8 +6450,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
/* Ports initialization */
static int mvpp2_port_probe(struct platform_device *pdev,
struct device_node *port_node,
- struct mvpp2 *priv,
- int *next_first_rxq)
+ struct mvpp2 *priv)
{
struct device_node *phy_node;
struct mvpp2_port *port;
@@ -6511,7 +6508,11 @@ static int mvpp2_port_probe(struct platform_device *pdev,
port->priv = priv;
port->id = id;
- port->first_rxq = *next_first_rxq;
+ if (priv->hw_version == MVPP21)
+ port->first_rxq = port->id * rxq_number;
+ else
+ port->first_rxq = port->id * priv->max_port_rxqs;
+
port->phy_node = phy_node;
port->phy_interface = phy_mode;
@@ -6608,8 +6609,6 @@ static int mvpp2_port_probe(struct platform_device *pdev,
}
netdev_info(dev, "Using %s mac address %pM\n", mac_from, dev->dev_addr);
- /* Increment the first Rx queue number to be used by the next port */
- *next_first_rxq += rxq_number;
priv->port_list[id] = port;
return 0;
@@ -6755,7 +6754,7 @@ static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)
u32 val;
/* Checks for hardware constraints */
- if (rxq_number % 4 || (rxq_number > MVPP2_MAX_RXQ) ||
+ if (rxq_number % 4 || (rxq_number > priv->max_port_rxqs) ||
(txq_number > MVPP2_MAX_TXQ)) {
dev_err(&pdev->dev, "invalid queue size parameter\n");
return -EINVAL;
@@ -6844,7 +6843,7 @@ static int mvpp2_probe(struct platform_device *pdev)
struct device_node *port_node;
struct mvpp2 *priv;
struct resource *res;
- int port_count, first_rxq, cpu;
+ int port_count, cpu;
int err;
priv = devm_kzalloc(&pdev->dev, sizeof(struct mvpp2), GFP_KERNEL);
@@ -6879,6 +6878,11 @@ static int mvpp2_probe(struct platform_device *pdev)
priv->cpu_base[cpu] = priv->base + cpu * addr_space_sz;
}
+ if (priv->hw_version == MVPP21)
+ priv->max_port_rxqs = 8;
+ else
+ priv->max_port_rxqs = 32;
+
priv->pp_clk = devm_clk_get(&pdev->dev, "pp_clk");
if (IS_ERR(priv->pp_clk))
return PTR_ERR(priv->pp_clk);
@@ -6921,9 +6925,8 @@ static int mvpp2_probe(struct platform_device *pdev)
}
/* Initialize ports */
- first_rxq = 0;
for_each_available_child_of_node(dn, port_node) {
- err = mvpp2_port_probe(pdev, port_node, priv, &first_rxq);
+ err = mvpp2_port_probe(pdev, port_node, priv);
if (err < 0)
goto err_gop_clk;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv2 net-next 15/16] net: mvpp2: add support for an additional clock needed for PPv2.2
From: Thomas Petazzoni @ 2016-12-28 16:46 UTC (permalink / raw)
To: netdev, David S. Miller, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Nadav Haklai, Hanna Hawa, Yehuda Yitschak, linux-arm-kernel,
Stefan Chulski, Marcin Wojtas, Thomas Petazzoni
In-Reply-To: <1482943592-12556-1-git-send-email-thomas.petazzoni@free-electrons.com>
The PPv2.2 variant of the network controller needs an additional
clock, the "MG clock" in order for the IP block to operate
properly. This commit adds support for this additional clock to the
driver, reworking as needed the error handling path.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 20e9429..194de00 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -702,6 +702,7 @@ struct mvpp2 {
/* Common clocks */
struct clk *pp_clk;
struct clk *gop_clk;
+ struct clk *mg_clk;
/* List of pointers to port structures */
struct mvpp2_port **port_list;
@@ -6899,6 +6900,18 @@ static int mvpp2_probe(struct platform_device *pdev)
if (err < 0)
goto err_pp_clk;
+ if (priv->hw_version == MVPP22) {
+ priv->mg_clk = devm_clk_get(&pdev->dev, "mg_clk");
+ if (IS_ERR(priv->mg_clk)) {
+ err = PTR_ERR(priv->mg_clk);
+ goto err_gop_clk;
+ }
+
+ err = clk_prepare_enable(priv->mg_clk);
+ if (err < 0)
+ goto err_gop_clk;
+ }
+
/* Get system's tclk rate */
priv->tclk = clk_get_rate(priv->pp_clk);
@@ -6906,14 +6919,14 @@ static int mvpp2_probe(struct platform_device *pdev)
err = mvpp2_init(pdev, priv);
if (err < 0) {
dev_err(&pdev->dev, "failed to initialize controller\n");
- goto err_gop_clk;
+ goto err_mg_clk;
}
port_count = of_get_available_child_count(dn);
if (port_count == 0) {
dev_err(&pdev->dev, "no ports enabled\n");
err = -ENODEV;
- goto err_gop_clk;
+ goto err_mg_clk;
}
priv->port_list = devm_kcalloc(&pdev->dev, port_count,
@@ -6921,19 +6934,22 @@ static int mvpp2_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!priv->port_list) {
err = -ENOMEM;
- goto err_gop_clk;
+ goto err_mg_clk;
}
/* Initialize ports */
for_each_available_child_of_node(dn, port_node) {
err = mvpp2_port_probe(pdev, port_node, priv);
if (err < 0)
- goto err_gop_clk;
+ goto err_mg_clk;
}
platform_set_drvdata(pdev, priv);
return 0;
+err_mg_clk:
+ if (priv->hw_version == MVPP22)
+ clk_disable_unprepare(priv->mg_clk);
err_gop_clk:
clk_disable_unprepare(priv->gop_clk);
err_pp_clk:
@@ -6969,6 +6985,7 @@ static int mvpp2_remove(struct platform_device *pdev)
aggr_txq->descs_phys);
}
+ clk_disable_unprepare(priv->mg_clk);
clk_disable_unprepare(priv->pp_clk);
clk_disable_unprepare(priv->gop_clk);
--
2.7.4
^ permalink raw reply related
* [PATCHv2 net-next 16/16] net: mvpp2: finally add the PPv2.2 compatible string
From: Thomas Petazzoni @ 2016-12-28 16:46 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Nadav Haklai, Hanna Hawa, Yehuda Yitschak,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stefan Chulski,
Marcin Wojtas, Thomas Petazzoni
In-Reply-To: <1482943592-12556-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Now that the mvpp2 driver has been modified to accommodate the support
for PPv2.2, we can finally advertise this support by adding the
appropriate compatible string.
At the same time, we update the Kconfig description of the MVPP2 driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/net/ethernet/marvell/Kconfig | 4 ++--
drivers/net/ethernet/marvell/mvpp2.c | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index d2555e8b..da6fb82 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -82,13 +82,13 @@ config MVNETA_BM
that all dependencies are met.
config MVPP2
- tristate "Marvell Armada 375 network interface support"
+ tristate "Marvell Armada 375/7K/8K network interface support"
depends on ARCH_MVEBU || COMPILE_TEST
depends on HAS_DMA
select MVMDIO
---help---
This driver supports the network interface units in the
- Marvell ARMADA 375 SoC.
+ Marvell ARMADA 375, 7K and 8K SoCs.
config PXA168_ETH
tristate "Marvell pxa168 ethernet support"
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 194de00..9e744d2 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6997,6 +6997,10 @@ static const struct of_device_id mvpp2_match[] = {
.compatible = "marvell,armada-375-pp2",
.data = (void *)MVPP21,
},
+ {
+ .compatible = "marvell,armada-7k-pp22",
+ .data = (void *)MVPP22,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, mvpp2_match);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 6/7] i2c: designware: enable SLAVE in platform module
From: Carlos Palminha @ 2016-12-28 16:49 UTC (permalink / raw)
To: Luis Oliveira, Andy Shevchenko
Cc: Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
In-Reply-To: <c41db9e0-756d-6697-a845-0d5b1efcaedc@synopsys.com>
On 28-12-2016 16:41, Luis Oliveira wrote:
> On 28-Dec-16 16:31, Andy Shevchenko wrote:
>> On Wed, 2016-12-28 at 15:53 +0000, Luis Oliveira wrote:
>>> On 28-Dec-16 15:44, Andy Shevchenko wrote:
>>>> On Wed, 2016-12-28 at 14:43 +0000, Luis Oliveira wrote:
>>>>> - Slave mode selected in platform module (devicetree support only)
>>>>> - Check for ACPI - not supported in SLAVE mode:
>>>>> - Changed the ifndef style to the use of ACPI_HANDLE that
>>>>> returns
>>>>> NULL
>>>>> if the device was not enumerated from ACPI namespace.
>>>>
>>>> I'm not sure what is wrong with ACPI?
>>>
>>> I dont have a way to test it. Just that.
>>
>> Okay, can you provide an excerpt to see how it will look like in DTS?
>
> Yes, it looks like this now:
>
> i2c@0x2000 {
> compatible = "snps,designware-i2c";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x2000 0x100>;
> clock-frequency = <400000>;
> clocks = <&i2cclk>;
> interrupts = <0>;
>
> eeprom@64 {
> compatible = "linux,slave-24c02";
> reg = <0x40000064>;
> };
> };
Probably this can be included as example in the device tree binding document.
>>
>>>>> - dev->functionality = I2C_FUNC_10BIT_ADDR |
>>>>> DW_IC_DEFAULT_FUNCTIONALITY;
>>>>> -
>>>>> - i2c_dw_configure_master(pdev);
>>>>> + if (ACPI_HANDLE(&pdev->dev) == NULL) {
>>>>
>>>> I don't think you need this at all.
>>>
>>> This is to avoid the use of the "ifdef" style I used before.
>>
>> My point is to drop it completely.
>>
>>>>
>>>>> + device_for_each_child_node(&pdev->dev, child) {
>>>>
>>>> This is resource agnostic.
>>>>
>>>>> + fwnode_property_read_u32(child, "reg",
>>>>> ®);
>>>>
>>>> This is as well.
>>>
>>> Are you suggesting I use of_ functions?
>>
>> Nope. See above.
>>
>>
>
^ permalink raw reply
* Re: [PATCHv2 net-next 00/16] net: mvpp2: add basic support for PPv2.2
From: David Miller @ 2016-12-28 17:06 UTC (permalink / raw)
To: thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, galak-sgV2jX0FEOL9JmXXK+q4OQ,
jason-NLaQJdtUoK4Be96aLqz0jA, andrew-g2DYL2Zd6BY,
sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w,
gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
nadavh-eYqpPyKDWXRBDgjK7y7TUQ, hannah-eYqpPyKDWXRBDgjK7y7TUQ,
yehuday-eYqpPyKDWXRBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefanc-eYqpPyKDWXRBDgjK7y7TUQ, mw-nYOzD4b6Jr9Wk0Htik3J/w
In-Reply-To: <1482943592-12556-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
From: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Date: Wed, 28 Dec 2016 17:46:16 +0100
> This series depends on the series named "net: mvpp2: misc improvements
> and preparation patches".
Please in the future only submit one patch series at a time.
If I've told you that a large patch series is hard to review and that
therefore one should keep each submitted series small and to a
reasonable size, that is completely undermined when you submit
multiple series to work around that request.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 6/7] i2c: designware: enable SLAVE in platform module
From: Andy Shevchenko @ 2016-12-28 17:10 UTC (permalink / raw)
To: Luis Oliveira, wsa, robh+dt, mark.rutland, jarkko.nikula,
mika.westerberg, linux-i2c, devicetree, linux-kernel
Cc: Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
In-Reply-To: <c41db9e0-756d-6697-a845-0d5b1efcaedc@synopsys.com>
On Wed, 2016-12-28 at 16:41 +0000, Luis Oliveira wrote:
> On 28-Dec-16 16:31, Andy Shevchenko wrote:
> > On Wed, 2016-12-28 at 15:53 +0000, Luis Oliveira wrote:
> > > On 28-Dec-16 15:44, Andy Shevchenko wrote:
> > > > On Wed, 2016-12-28 at 14:43 +0000, Luis Oliveira wrote:
> > > > > - Slave mode selected in platform module (devicetree support
> > > > > only)
> > > > > - Check for ACPI - not supported in SLAVE mode:
> > > > > - Changed the ifndef style to the use of ACPI_HANDLE that
> > > > > returns
> > > > > NULL
> > > > > if the device was not enumerated from ACPI namespace.
> > > >
> > > > I'm not sure what is wrong with ACPI?
> > >
> > > I dont have a way to test it. Just that.
> >
> > Okay, can you provide an excerpt to see how it will look like in
> > DTS?
>
> Yes, it looks like this now:
>
> i2c@0x2000 {
> compatible = "snps,designware-i2c";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x2000 0x100>;
> clock-frequency = <400000>;
> clocks = <&i2cclk>;
> interrupts = <0>;
>
> eeprom@64 {
> compatible = "linux,slave-24c02";
> reg = <0x40000064>;
> };
> };
+1 to Carlos' comment.
> >
> > > > > - dev->functionality = I2C_FUNC_10BIT_ADDR |
> > > > > DW_IC_DEFAULT_FUNCTIONALITY;
> > > > > -
> > > > > - i2c_dw_configure_master(pdev);
> > > > > + if (ACPI_HANDLE(&pdev->dev) == NULL) {
> > > >
> > > > I don't think you need this at all.
> > >
> > > This is to avoid the use of the "ifdef" style I used before.
> >
> > My point is to drop it completely.
> >
> > > >
> > > > > + device_for_each_child_node(&pdev->dev, child)
> > > > > {
> > > >
> > > > This is resource agnostic.
> > > >
> > > > > + fwnode_property_read_u32(child,
> > > > > "reg",
> > > > > ®);
> > > >
> > > > This is as well.
> > >
> > > Are you suggesting I use of_ functions?
> >
> > Nope. See above.
So, ACPI has a property to support slave mode for I2CSerialBus() macro.
I would propose to create a helper function in i2c-core.c which will be
responsible for mode detection
... i2c_slave_mode_detect()
{
...
if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
... (use of_*() here) ...
} else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev))
dev_dbg(..., "ACPI slave is not supported yet\n");
... to master ...
} else {
... default to master ...
}
}
EXPORT_...();
Make it as a separate patch.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [RESEND v2] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Krzysztof Kozlowski @ 2016-12-28 17:50 UTC (permalink / raw)
To: Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyungmin Park,
David Airlie, Rob Herring, Mark Rutland, Kukjin Kim,
Krzysztof Kozlowski, Javier Martinez Canillas,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The samsung,power-domain property is obsolete since commit 0da658704136
("ARM: dts: convert to generic power domain bindings for exynos DT").
Replace it with generic one.
Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes since v1:
1. Just add the acks/reviews.
I though it will be applied by Exynos DRM maintainer but there was no
response.
Dear Rob, could you pick it up?
---
Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt
index 3938caacf11c..8346fb18a358 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt
@@ -33,7 +33,7 @@ Required properties:
- i80-if-timings: timing configuration for lcd i80 interface support.
Optional Properties:
-- samsung,power-domain: a phandle to DECON power domain node.
+- power-domains: a phandle to DECON power domain node.
- display-timings: timing settings for DECON, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 6/7] i2c: designware: enable SLAVE in platform module
From: Luis Oliveira @ 2016-12-28 18:10 UTC (permalink / raw)
To: Andy Shevchenko, Luis Oliveira, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jarkko.nikula-VuQAYsv1563Yd54FQh9/CA,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <1482945043.9552.174.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 28-Dec-16 17:10, Andy Shevchenko wrote:
> On Wed, 2016-12-28 at 16:41 +0000, Luis Oliveira wrote:
>> On 28-Dec-16 16:31, Andy Shevchenko wrote:
>>> On Wed, 2016-12-28 at 15:53 +0000, Luis Oliveira wrote:
>>>> On 28-Dec-16 15:44, Andy Shevchenko wrote:
>>>>> On Wed, 2016-12-28 at 14:43 +0000, Luis Oliveira wrote:
>>>>>> - Slave mode selected in platform module (devicetree support
>>>>>> only)
>>>>>> - Check for ACPI - not supported in SLAVE mode:
>>>>>> - Changed the ifndef style to the use of ACPI_HANDLE that
>>>>>> returns
>>>>>> NULL
>>>>>> if the device was not enumerated from ACPI namespace.
>>>>>
>>>>> I'm not sure what is wrong with ACPI?
>>>>
>>>> I dont have a way to test it. Just that.
>>>
>>> Okay, can you provide an excerpt to see how it will look like in
>>> DTS?
>>
>> Yes, it looks like this now:
>>
>> i2c@0x2000 {
>> compatible = "snps,designware-i2c";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <0x2000 0x100>;
>> clock-frequency = <400000>;
>> clocks = <&i2cclk>;
>> interrupts = <0>;
>>
>> eeprom@64 {
>> compatible = "linux,slave-24c02";
>> reg = <0x40000064>;
>> };
>> };
>
> +1 to Carlos' comment.
Agree, I'm on it.
>
>>>
>>>>>> - dev->functionality = I2C_FUNC_10BIT_ADDR |
>>>>>> DW_IC_DEFAULT_FUNCTIONALITY;
>>>>>> -
>>>>>> - i2c_dw_configure_master(pdev);
>>>>>> + if (ACPI_HANDLE(&pdev->dev) == NULL) {
>>>>>
>>>>> I don't think you need this at all.
>>>>
>>>> This is to avoid the use of the "ifdef" style I used before.
>>>
>>> My point is to drop it completely.
>>>
>>>>>
>>>>>> + device_for_each_child_node(&pdev->dev, child)
>>>>>> {
>>>>>
>>>>> This is resource agnostic.
>>>>>
>>>>>> + fwnode_property_read_u32(child,
>>>>>> "reg",
>>>>>> ®);
>>>>>
>>>>> This is as well.
>>>>
>>>> Are you suggesting I use of_ functions?
>>>
>>> Nope. See above.
>
> So, ACPI has a property to support slave mode for I2CSerialBus() macro.
>
> I would propose to create a helper function in i2c-core.c which will be
> responsible for mode detection
>
> ... i2c_slave_mode_detect()
> {
> ...
> if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
> ... (use of_*() here) ...
> } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev))
> dev_dbg(..., "ACPI slave is not supported yet\n");
> ... to master ...
> } else {
> ... default to master ...
> }
> }
> EXPORT_...();
>
> Make it as a separate patch.
>
Oh I see, yes it looks good. I will check it. Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] dt: bindings: Add support for CSI1 bus
From: Pavel Machek @ 2016-12-28 18:30 UTC (permalink / raw)
To: robh+dt, devicetree, ivo.g.dimitrov.75, sakari.ailus, sre,
pali.rohar, pavel, linux-media
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
From: Sakari Ailus <sakari.ailus@iki.fi>
In the vast majority of cases the bus type is known to the driver(s)
since a receiver or transmitter can only support a single one. There
are cases however where different options are possible.
Document the CSI1/CCP2 properties strobe_clk_inv and strobe_clock
properties. The former tells whether the strobe/clock signal is
inverted, while the latter signifies the clock or strobe mode.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 9cd2a36..f0523f7 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -76,6 +76,10 @@ Optional endpoint properties
mode horizontal and vertical synchronization signals are provided to the
slave device (data source) by the master device (data sink). In the master
mode the data source device is also the source of the synchronization signals.
+- bus-type: data bus type. Possible values are:
+ 0 - CSI2
+ 1 - parallel / Bt656
+ 2 - CCP2
- bus-width: number of data lines actively used, valid for the parallel busses.
- data-shift: on the parallel data busses, if bus-width is used to specify the
number of data lines, data-shift can be used to specify which data lines are
@@ -110,9 +114,10 @@ Optional endpoint properties
lane and followed by the data lanes in the same order as in data-lanes.
Valid values are 0 (normal) and 1 (inverted). The length of the array
should be the combined length of data-lanes and clock-lanes properties.
- If the lane-polarities property is omitted, the value must be interpreted
- as 0 (normal). This property is valid for serial busses only.
-
+- clock-inv: Clock or strobe signal inversion.
+ Possible values: 0 -- not inverted; 1 -- inverted
+- strobe: Whether the clock signal is used as clock or strobe. Used
+ with CCP2, for instance.
Example
-------
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Arend van Spriel @ 2016-12-28 20:05 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161228155955.25518-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 28-12-16 16:59, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This new file should be used for properties handled at higher level and
> so usable with all drivers.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 0000000..c762769
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,16 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are handled by a proper
> +net layer and don't require extra driver code.
Please do not make any assumptions on how DT properties are handled nor
by what. Just state that these properties apply to all wireless devices
and are applicable to device specific bindings.
> +Optional properties:
> + - ieee80211-min-center-freq : minimal supported frequency in KHz
> + - ieee80211-max-center-freq : maximal supported frequency in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + ieee80211-min-center-freq = <2437000>;
> + ieee80211-max-center-freq = <2457000>;
> +};
Is this the proper level to define it. I was expecting a child node of
the pci(e) controller. Maybe I am misreading the example.
Regards,
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Rafał Miłecki @ 2016-12-28 20:32 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <f387d897-a1e9-c932-8317-41246be245b0-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 28 December 2016 at 21:05, Arend van Spriel
<arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On 28-12-16 16:59, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> This new file should be used for properties handled at higher level and
>> so usable with all drivers.
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> new file mode 100644
>> index 0000000..c762769
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> @@ -0,0 +1,16 @@
>> +Common IEEE 802.11 properties
>> +
>> +This provides documentation of common properties that are handled by a proper
>> +net layer and don't require extra driver code.
>
> Please do not make any assumptions on how DT properties are handled nor
> by what. Just state that these properties apply to all wireless devices
> and are applicable to device specific bindings.
OK, I'll try to improve this description.
>> +Optional properties:
>> + - ieee80211-min-center-freq : minimal supported frequency in KHz
>> + - ieee80211-max-center-freq : maximal supported frequency in KHz
>> +
>> +Example:
>> +
>> +pcie@0,0 {
>> + reg = <0x0000 0 0 0 0>;
>> + ieee80211-min-center-freq = <2437000>;
>> + ieee80211-max-center-freq = <2457000>;
>> +};
>
> Is this the proper level to define it. I was expecting a child node of
> the pci(e) controller. Maybe I am misreading the example.
This is device node, not a controller node (and yes, it's complete
node). You just need to add such a node inside the controller one.
It doesn't seem to be clearly documented, but you can see it in examples in:
Documentation/devicetree/bindings/pci/mvebu-pci.txt
Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
The assignment is done in
pci_scan_device -> pci_set_of_node -> of_pci_find_child_device
(so this isn't controller specific thing).
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Martin Blumenstingl @ 2016-12-28 20:39 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CACna6rwhC=28fCHDzXok8Ka08g3yhcD2VNgQrfUZUCQRGqksOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 28, 2016 at 9:32 PM, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 28 December 2016 at 21:05, Arend van Spriel
> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>
>>> This new file should be used for properties handled at higher level and
>>> so usable with all drivers.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>> new file mode 100644
>>> index 0000000..c762769
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>> @@ -0,0 +1,16 @@
>>> +Common IEEE 802.11 properties
>>> +
>>> +This provides documentation of common properties that are handled by a proper
>>> +net layer and don't require extra driver code.
>>
>> Please do not make any assumptions on how DT properties are handled nor
>> by what. Just state that these properties apply to all wireless devices
>> and are applicable to device specific bindings.
>
> OK, I'll try to improve this description.
>
>
>>> +Optional properties:
>>> + - ieee80211-min-center-freq : minimal supported frequency in KHz
>>> + - ieee80211-max-center-freq : maximal supported frequency in KHz
>>> +
>>> +Example:
>>> +
>>> +pcie@0,0 {
>>> + reg = <0x0000 0 0 0 0>;
>>> + ieee80211-min-center-freq = <2437000>;
>>> + ieee80211-max-center-freq = <2457000>;
>>> +};
>>
>> Is this the proper level to define it. I was expecting a child node of
>> the pci(e) controller. Maybe I am misreading the example.
>
> This is device node, not a controller node (and yes, it's complete
> node). You just need to add such a node inside the controller one.
you should name the node wifi@0,0 instead. I revised my ath9k OF
binding documentation due to similar concerns (and after seeing the
result I must admit that they were right). you can have a look at the
result here: [0]
apart from that: thanks for the patch, I will try this as soon as possible!
Regards,
Martin
[0] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/wireless/qca%2Cath9k.txt
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Rafał Miłecki @ 2016-12-28 20:43 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Arend van Spriel, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CAFBinCBNXdM-xVH9SaPZdFr3X0=k+py9aZ6Qj4ng=v1L-EvS7A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 28 December 2016 at 21:39, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> On Wed, Dec 28, 2016 at 9:32 PM, Rafał Miłecki <zajec5-Re5JQEeQqe8@public.gmane.orgm> wrote:
>> On 28 December 2016 at 21:05, Arend van Spriel
>> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>
>>>> This new file should be used for properties handled at higher level and
>>>> so usable with all drivers.
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
>>>> 1 file changed, 16 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>>> new file mode 100644
>>>> index 0000000..c762769
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>>> @@ -0,0 +1,16 @@
>>>> +Common IEEE 802.11 properties
>>>> +
>>>> +This provides documentation of common properties that are handled by a proper
>>>> +net layer and don't require extra driver code.
>>>
>>> Please do not make any assumptions on how DT properties are handled nor
>>> by what. Just state that these properties apply to all wireless devices
>>> and are applicable to device specific bindings.
>>
>> OK, I'll try to improve this description.
>>
>>
>>>> +Optional properties:
>>>> + - ieee80211-min-center-freq : minimal supported frequency in KHz
>>>> + - ieee80211-max-center-freq : maximal supported frequency in KHz
>>>> +
>>>> +Example:
>>>> +
>>>> +pcie@0,0 {
>>>> + reg = <0x0000 0 0 0 0>;
>>>> + ieee80211-min-center-freq = <2437000>;
>>>> + ieee80211-max-center-freq = <2457000>;
>>>> +};
>>>
>>> Is this the proper level to define it. I was expecting a child node of
>>> the pci(e) controller. Maybe I am misreading the example.
>>
>> This is device node, not a controller node (and yes, it's complete
>> node). You just need to add such a node inside the controller one.
> you should name the node wifi@0,0 instead. I revised my ath9k OF
> binding documentation due to similar concerns (and after seeing the
> result I must admit that they were right). you can have a look at the
> result here: [0]
Thanks for your comment, I'm far from considering myself DT expert, so
I often need help with such things, I'll change this in V2.
--
Rafał
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Arend van Spriel @ 2016-12-28 21:07 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161228155955.25518-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 28-12-16 16:59, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> They allow specifying hardware limitations of supported channels. This
> may be useful for specifying single band devices or devices that support
> only some part of the whole band.
> E.g. some tri-band routers have separated radios for lower and higher
> part of 5 GHz band.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..35ba5c7 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
> }
> EXPORT_SYMBOL(reg_initiator_name);
>
> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
> + struct ieee80211_channel *chan)
> +{
> + struct device_node *np = wiphy_dev(wiphy)->of_node;
> + u32 val;
> +
> + if (!np)
> + return true;
> +
> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val) &&
> + chan->center_freq < KHZ_TO_MHZ(val))
> + return false;
> +
> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val) &&
> + chan->center_freq > KHZ_TO_MHZ(val))
> + return false;
I suspect these functions rely on CONFIG_OF. So might not build for
!CONFIG_OF.
Regards,
Arend
^ permalink raw reply
* Re: [PATCHv2 net-next 00/16] net: mvpp2: add basic support for PPv2.2
From: Thomas Petazzoni @ 2016-12-28 21:08 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, galak-sgV2jX0FEOL9JmXXK+q4OQ,
jason-NLaQJdtUoK4Be96aLqz0jA, andrew-g2DYL2Zd6BY,
sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w,
gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
nadavh-eYqpPyKDWXRBDgjK7y7TUQ, hannah-eYqpPyKDWXRBDgjK7y7TUQ,
yehuday-eYqpPyKDWXRBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
stefanc-eYqpPyKDWXRBDgjK7y7TUQ, mw-nYOzD4b6Jr9Wk0Htik3J/w
In-Reply-To: <20161228.120644.1166014191192724301.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hello,
On Wed, 28 Dec 2016 12:06:44 -0500 (EST), David Miller wrote:
> > This series depends on the series named "net: mvpp2: misc improvements
> > and preparation patches".
>
> Please in the future only submit one patch series at a time.
>
> If I've told you that a large patch series is hard to review and that
> therefore one should keep each submitted series small and to a
> reasonable size, that is completely undermined when you submit
> multiple series to work around that request.
Sure. I'll wait for the first patch series to be merged (potentially
after several iterations) before resending the second patch series.
Thanks for the feedback!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2016-12-28 21:21 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: devicetree, Alexandre Torgue, Wolfram Sang, linux-kernel,
Linus Walleij, Patrice Chotard, linux, Rob Herring, linux-i2c,
Maxime Coquelin, linux-arm-kernel
In-Reply-To: <CAOAejn3sc1F8T_rbSTr6-wBNncNwObeK+c6=_Q0BMahDdHXxQA@mail.gmail.com>
Hello Cedric,
On Fri, Dec 23, 2016 at 01:41:15PM +0100, M'boumba Cedric Madianga wrote:
> > I don't understand why DUTY is required to reach 400 kHz. Given a parent
> > freq of 30 MHz, with CCR = 25 and DUTY = 0 we have:
> >
> > t_high = 25 * 33.333 ns = 833.333 ns
> > t_low = 2 * 25 * 33.333 ns = 1666.667 ns
> >
> > then t_high and t_low satisfy the i2c bus specification
> > (t_low > 1300 ns, t_high > 600 ns) and we have t_low + t_high = 2500 ns
> > = 1 / 400 kHz.
> >
> > Where is the error?
> Hum ok you are right. I was a bad interpretation of the datasheet.
> So now it is clearer. Thanks for that.
> I will correct and improve my comments in the V8.
The benefit of DUTY=1 is (I think) that you can reach 400 kHz also with
lower parent frequencies. And so it't probably sensible to make use of
it unconditionally for fast mode.
> >> + * So, in order to cover both SCL high/low with Duty = 1,
> >> + * CCR = 16 * SCL period * I2C CLK frequency
> >
> > I don't get that. Actually you need to use low + high, so
> > CCR = parentrate / (25 * 400 kHz), right?
> With your new inputs above, I think I could use a simpler implementation:
> CCR = scl_high_period * parent_rate
> with scl_high_period = 5 µs in standard mode to reach 100khz
> and scl_high_period = 1 µs in fast mode to reach 400khz with 1/2 or
> 16/9 duty cycle.
> So, I am wondering if I have to let the customer setting the duty
> cycle in the DT for example with "st,duty=0" or "st,duty=1" property
> (0 for 1/2 and 1 for 16/9).
> Or perhaps the best option it to use a default value. What is your
> feeling regarding this point ?
No, don't add a property to the device tree. Just take pencil and paper
and think a while about the right algorithm to choose the right register
settings.
> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> >> + freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
> >> +
> >> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
> >> + trise = freq + 1;
> >> + else
> >> + trise = freq * 300 / 1000 + 1;
> >
> > if freq is big such that freq * 300 overflows does this result in a
> > wrong result, or does the compiler optimize correctly?
> For sure the compiler will never exceeds u32 max value
If I compile
-------->8--------
#include <stdio.h>
void myfunc(unsigned freq)
{
unsigned trise = freq * 300 / 1000 + 1;
printf("trise = %u", trise);
}
-------->8--------
for arm with -O3 I get:
00000000 <myfunc>:
0: e3a01f4b mov r1, #300 ; 0x12c
4: e0010190 mul r1, r0, r1
8: e59f3010 ldr r3, [pc, #16] ; 20 <myfunc+0x20>
c: e59f0010 ldr r0, [pc, #16] ; 24 <myfunc+0x24>
10: e0812193 umull r2, r1, r3, r1
14: e1a01321 lsr r1, r1, #6
18: e2811001 add r1, r1, #1
1c: eafffffe b 0 <printf>
20: 10624dd3 .word 0x10624dd3
24: 00000000 .word 0x00000000
The mul instruction at offset 4 writes the least significant 32 bits of
300 * r0 to r1 and so doesn't handle overflow correctly.
> > This is still not really understandable.
> I have already added some comments from datasheet to explain the
> different cases.
> I don't see how I could be more understandable as it is clearly the
> hardware way of working...
You need to comment the check for the length, something like:
/*
* To end the transfer correctly the foo bit has to be cleared
* already on the last but one byte to be transferred.
*/
and bonus points if you can shrink the number of functions that check
for this stuff.
> > Just do:
> >
> > if (status & STM32F4_I2C_SR1_SB) {
> > ...
> > }
> >
> > if (status & ...) {
> >
> > }
> ok but I would prefer something like that:
> flag = status & possible_status
> if (flag & STM32F4_I2C_SR1_SB) {
> ...
> }
>
> if (flag & ...) {
> }
Ok, if you really need possible_status.
> > Then it's obvious by reading the code in which order they are handled
> > without the need to check the definitions. Do you really need to jugle
> > with possible_status?
> I think I have to use possible_status as some events could occur
> whereas the corresponding interrupt is disabled.
> For example, for a 2 byte-reception, we don't have to take into accout
> RXNE event so the corresponding interrupt is disabled.
Is it possible to make it more obvious by doing:
status = read_from_status_register() & read_from_interrupt_enable_register();
at a single place?
> >> + /* Use __fls() to check error bits first */
> >> + flag = __fls(status & possible_status);
> >> +
> >> + switch (1 << flag) {
> >> + case STM32F4_I2C_SR1_BERR:
> >> + reg = i2c_dev->base + STM32F4_I2C_SR1;
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_BERR);
> >> + msg->result = -EIO;
> >> + break;
> >> +
> >> + case STM32F4_I2C_SR1_ARLO:
> >> + reg = i2c_dev->base + STM32F4_I2C_SR1;
> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_ARLO);
> >> + msg->result = -EAGAIN;
> >> + break;
> >> +
> >> + case STM32F4_I2C_SR1_AF:
> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
> >> + msg->result = -EIO;
> >> + break;
> >> +
> >> + default:
> >> + dev_err(i2c_dev->dev,
> >> + "err it unhandled: status=0x%08x)\n", status);
> >> + return IRQ_NONE;
> >> + }
> >
> > You only check a single irq flag here.
> Yes only the first error could be reported to the i2c clients via
> msg->result that's why I don't check all errors.
> Moreover, as soon as an error occurs, the I2C device is reset.
The the "first" in the comment for __fls is misleading. Also do:
if (status & MOST_IMPORTANT_ERROR) {
...
}
if (status & SECOND_MOST_IMPORTANT_ERROR) {
...
}
(if you need including possible_status stuff).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Jason Kridner @ 2016-12-28 21:26 UTC (permalink / raw)
To: Robert Nelson
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Kridner
In-Reply-To: <20161227175837.28970-2-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> On Dec 27, 2016, at 11:58 AM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> replaced by a TI wl1835 wireless module.
>
> This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
I believe the correct statement is BWxx, but BWBx reserves the option to be software incompatible in some way. My preference is to have it boot anyway, but I believe that is only dependent in the bootloader.
>
> http://beagleboard.org/black-wireless
> https://github.com/beagleboard/beaglebone-black-wireless
>
> firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
> wl18xx mac address: /proc/device-tree/ocp/ethernet@4a100000/slave@4a100200/mac-address
>
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> CC: Jason Kridner <jkridner-hcmAuCOw+vXj4SYmN/TMmA@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-boneblack-wireless.dts | 109 ++++++++++++++++++++++++
> 2 files changed, 110 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-boneblack-wireless.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index cccdbcb557b6..9415a49bd11b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -563,6 +563,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
> am335x-base0033.dtb \
> am335x-bone.dtb \
> am335x-boneblack.dtb \
> + am335x-boneblack-wireless.dtb \
> am335x-bonegreen.dtb \
> am335x-chiliboard.dtb \
> am335x-cm-t335.dtb \
> diff --git a/arch/arm/boot/dts/am335x-boneblack-wireless.dts b/arch/arm/boot/dts/am335x-boneblack-wireless.dts
> new file mode 100644
> index 000000000000..105bd10655f7
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-boneblack-wireless.dts
> @@ -0,0 +1,109 @@
> +/*
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +#include "am335x-bone-common.dtsi"
> +#include "am335x-boneblack-common.dtsi"
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + model = "TI AM335x BeagleBone Black Wireless";
> + compatible = "ti,am335x-bone-black-wireless", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
> +
> + wlan_en_reg: fixedregulator@2 {
> + compatible = "regulator-fixed";
> + regulator-name = "wlan-en-regulator";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + startup-delay-us= <70000>;
> +
> + /* WL_EN */
> + gpio = <&gpio3 9 0>;
> + enable-active-high;
> + };
> +};
> +
> +&am33xx_pinmux {
> + bt_pins: pinmux_bt_pins {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLUP | MUX_MODE7) /* gmii1_txd0.gpio0_28 - BT_EN */
> + >;
> + };
> +
> + mmc3_pins: pinmux_mmc3_pins {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE6 ) /* (L15) gmii1_rxd1.mmc2_clk */
> + AM33XX_IOPAD(0x914, PIN_INPUT_PULLUP | MUX_MODE6 ) /* (J16) gmii1_txen.mmc2_cmd */
> + AM33XX_IOPAD(0x918, PIN_INPUT_PULLUP | MUX_MODE5 ) /* (J17) gmii1_rxdv.mmc2_dat0 */
> + AM33XX_IOPAD(0x91c, PIN_INPUT_PULLUP | MUX_MODE5 ) /* (J18) gmii1_txd3.mmc2_dat1 */
> + AM33XX_IOPAD(0x920, PIN_INPUT_PULLUP | MUX_MODE5 ) /* (K15) gmii1_txd2.mmc2_dat2 */
> + AM33XX_IOPAD(0x908, PIN_INPUT_PULLUP | MUX_MODE5 ) /* (H16) gmii1_col.mmc2_dat3 */
> + >;
> + };
> +
> + uart3_pins: pinmux_uart3_pins {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x934, PIN_INPUT_PULLUP | MUX_MODE1) /* gmii1_rxd3.uart3_rxd */
> + AM33XX_IOPAD(0x938, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* gmii1_rxd2.uart3_txd */
> + AM33XX_IOPAD(0x948, PIN_INPUT | MUX_MODE3) /* mdio_data.uart3_ctsn */
> + AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* mdio_clk.uart3_rtsn */
> + >;
> + };
> +
> + wl18xx_pins: pinmux_wl18xx_pins {
> + pinctrl-single,pins = <
> + AM33XX_IOPAD(0x92c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gmii1_txclk.gpio3_9 WL_EN */
> + AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE7) /* rmii1_refclk.gpio0_29 WL_IRQ */
> + AM33XX_IOPAD(0x930, PIN_OUTPUT_PULLUP | MUX_MODE7) /* gmii1_rxclk.gpio3_10 LS_BUF_EN */
> + >;
> + };
> +};
> +
> +&mac {
> + status = "disabled";
> +};
> +
> +&mmc3 {
> + dmas = <&edma_xbar 12 0 1
> + &edma_xbar 13 0 2>;
> + dma-names = "tx", "rx";
> + status = "okay";
> + vmmc-supply = <&wlan_en_reg>;
> + bus-width = <4>;
> + non-removable;
> + cap-power-off-card;
> + ti,needs-special-hs-handling;
> + keep-power-in-suspend;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + wlcore: wlcore@2 {
> + compatible = "ti,wl1835";
> + reg = <2>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <29 IRQ_TYPE_EDGE_RISING>;
> + };
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins &bt_pins>;
> + status = "okay";
> +};
> +
> +&gpio3 {
> + ls_buf_en {
> + gpio-hog;
> + gpios = <10 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "LS_BUF_EN";
> + };
> +};
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Rafał Miłecki @ 2016-12-28 21:28 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <491a5af2-449d-4b2a-c4ed-af0e89b2ca78-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 28 December 2016 at 22:07, Arend van Spriel
<arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On 28-12-16 16:59, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> They allow specifying hardware limitations of supported channels. This
>> may be useful for specifying single band devices or devices that support
>> only some part of the whole band.
>> E.g. some tri-band routers have separated radios for lower and higher
>> part of 5 GHz band.
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>> index 5dbac37..35ba5c7 100644
>> --- a/net/wireless/reg.c
>> +++ b/net/wireless/reg.c
>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
>> }
>> EXPORT_SYMBOL(reg_initiator_name);
>>
>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>> + struct ieee80211_channel *chan)
>> +{
>> + struct device_node *np = wiphy_dev(wiphy)->of_node;
>> + u32 val;
>> +
>> + if (!np)
>> + return true;
>> +
>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val) &&
>> + chan->center_freq < KHZ_TO_MHZ(val))
>> + return false;
>> +
>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val) &&
>> + chan->center_freq > KHZ_TO_MHZ(val))
>> + return false;
>
> I suspect these functions rely on CONFIG_OF. So might not build for
> !CONFIG_OF.
I compiled it with
# CONFIG_OF is not set
Can you test it and provide a non-working config if you see a
compilation error, please?
--
Rafał
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Rafał Miłecki @ 2016-12-28 21:30 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CACna6rwKLr-makRauYQf51330p96QrSNEhtNqu927yHT_Xm7Wg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 28 December 2016 at 22:28, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 28 December 2016 at 22:07, Arend van Spriel
> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>
>>> They allow specifying hardware limitations of supported channels. This
>>> may be useful for specifying single band devices or devices that support
>>> only some part of the whole band.
>>> E.g. some tri-band routers have separated radios for lower and higher
>>> part of 5 GHz band.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>> ---
>>> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>> index 5dbac37..35ba5c7 100644
>>> --- a/net/wireless/reg.c
>>> +++ b/net/wireless/reg.c
>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
>>> }
>>> EXPORT_SYMBOL(reg_initiator_name);
>>>
>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>> + struct ieee80211_channel *chan)
>>> +{
>>> + struct device_node *np = wiphy_dev(wiphy)->of_node;
>>> + u32 val;
>>> +
>>> + if (!np)
>>> + return true;
>>> +
>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val) &&
>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>> + return false;
>>> +
>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val) &&
>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>> + return false;
>>
>> I suspect these functions rely on CONFIG_OF. So might not build for
>> !CONFIG_OF.
>
> I compiled it with
> # CONFIG_OF is not set
>
> Can you test it and provide a non-working config if you see a
> compilation error, please?
include/linux/of.h provides a lot of dummy static inline functions if
CONFIG_OF is not used (they also allow compiler to drop most of the
code).
--
Rafał
^ permalink raw reply
* [PATCH] ARM: dts: r8a7794: link DU to VSPD
From: Sergei Shtylyov @ 2016-12-28 21:35 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1529351.Fac5N2tKoF-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
Add the "vsps" property to the DU device node in order to link this node to
the (single) VSPD node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
---
This patch is against the 'renesas-devel-20161220-v4.9' of Simon Horman's
'renesas.git' repo. It's only meaningful if the "Enable R8A7794 DU VSPD
compositor" DU driver patches are applied...
arch/arm/boot/dts/r8a7794.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -908,7 +908,7 @@
power-domains = <&sysc R8A7794_PD_ALWAYS_ON>;
};
- vsp1@fe930000 {
+ vspd0: vsp1@fe930000 {
compatible = "renesas,vsp1";
reg = <0 0xfe930000 0 0x8000>;
interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
@@ -925,6 +925,7 @@
clocks = <&mstp7_clks R8A7794_CLK_DU0>,
<&mstp7_clks R8A7794_CLK_DU0>;
clock-names = "du.0", "du.1";
+ vsps = <&vspd0>;
status = "disabled";
ports {
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Felix Fietkau @ 2016-12-28 21:35 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161228155955.25518-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2016-12-28 16:59, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This new file should be used for properties handled at higher level and
> so usable with all drivers.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 0000000..c762769
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,16 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are handled by a proper
> +net layer and don't require extra driver code.
> +
> +Optional properties:
> + - ieee80211-min-center-freq : minimal supported frequency in KHz
> + - ieee80211-max-center-freq : maximal supported frequency in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + ieee80211-min-center-freq = <2437000>;
> + ieee80211-max-center-freq = <2457000>;
I'm not sure that's the best way to deal with enabling/disabling bands.
If we get more bands in the future, there might be unsupported ones in
the middle, which min/max won't cover.
- Felix
^ permalink raw reply
* Re: [PATCH] Add Nexus 6P(msm8994) SDHCI support
From: kbuild test robot @ 2016-12-28 22:10 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, jeremymc-H+wXaHxf7aLQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, Bastian Köcher
In-Reply-To: <20161228162134.13687-1-git-LJ92rlH3Dns@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
Hi Bastian,
[auto build test ERROR on next-20161224]
[also build test ERROR on v4.10-rc1]
[cannot apply to robh/for-next v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Bastian-K-cher/Add-Nexus-6P-msm8994-SDHCI-support/20161229-035218
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/qcom/msm8994.dtsi:182.17-18 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33729 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-12-28 22:20 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, linux, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20161228212139.adkixdgvmtj2ukjs@pengutronix.de>
Hello Uwe,
2016-12-28 22:21 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello Cedric,
>
> On Fri, Dec 23, 2016 at 01:41:15PM +0100, M'boumba Cedric Madianga wrote:
>> > I don't understand why DUTY is required to reach 400 kHz. Given a parent
>> > freq of 30 MHz, with CCR = 25 and DUTY = 0 we have:
>> >
>> > t_high = 25 * 33.333 ns = 833.333 ns
>> > t_low = 2 * 25 * 33.333 ns = 1666.667 ns
>> >
>> > then t_high and t_low satisfy the i2c bus specification
>> > (t_low > 1300 ns, t_high > 600 ns) and we have t_low + t_high = 2500 ns
>> > = 1 / 400 kHz.
>> >
>> > Where is the error?
>> Hum ok you are right. I was a bad interpretation of the datasheet.
>> So now it is clearer. Thanks for that.
>> I will correct and improve my comments in the V8.
>
> The benefit of DUTY=1 is (I think) that you can reach 400 kHz also with
> lower parent frequencies. And so it't probably sensible to make use of
> it unconditionally for fast mode.
Ok I agree.
>
>> >> + * So, in order to cover both SCL high/low with Duty = 1,
>> >> + * CCR = 16 * SCL period * I2C CLK frequency
>> >
>> > I don't get that. Actually you need to use low + high, so
>> > CCR = parentrate / (25 * 400 kHz), right?
>> With your new inputs above, I think I could use a simpler implementation:
>> CCR = scl_high_period * parent_rate
>> with scl_high_period = 5 µs in standard mode to reach 100khz
>> and scl_high_period = 1 µs in fast mode to reach 400khz with 1/2 or
>> 16/9 duty cycle.
>> So, I am wondering if I have to let the customer setting the duty
>> cycle in the DT for example with "st,duty=0" or "st,duty=1" property
>> (0 for 1/2 and 1 for 16/9).
>> Or perhaps the best option it to use a default value. What is your
>> feeling regarding this point ?
>
> No, don't add a property to the device tree. Just take pencil and paper
> and think a while about the right algorithm to choose the right register
> settings.
Ok thanks
>
>
>> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
>> >> + freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
>> >> +
>> >> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
>> >> + trise = freq + 1;
>> >> + else
>> >> + trise = freq * 300 / 1000 + 1;
>> >
>> > if freq is big such that freq * 300 overflows does this result in a
>> > wrong result, or does the compiler optimize correctly?
>> For sure the compiler will never exceeds u32 max value
>
> If I compile
> -------->8--------
> #include <stdio.h>
>
> void myfunc(unsigned freq)
> {
> unsigned trise = freq * 300 / 1000 + 1;
> printf("trise = %u", trise);
> }
>
> -------->8--------
>
> for arm with -O3 I get:
>
> 00000000 <myfunc>:
> 0: e3a01f4b mov r1, #300 ; 0x12c
> 4: e0010190 mul r1, r0, r1
> 8: e59f3010 ldr r3, [pc, #16] ; 20 <myfunc+0x20>
> c: e59f0010 ldr r0, [pc, #16] ; 24 <myfunc+0x24>
> 10: e0812193 umull r2, r1, r3, r1
> 14: e1a01321 lsr r1, r1, #6
> 18: e2811001 add r1, r1, #1
> 1c: eafffffe b 0 <printf>
> 20: 10624dd3 .word 0x10624dd3
> 24: 00000000 .word 0x00000000
>
> The mul instruction at offset 4 writes the least significant 32 bits of
> 300 * r0 to r1 and so doesn't handle overflow correctly.
In case of overflow, the parent frequency has to be at least at 1431657 Mhz.
The STM32F4 SoC will never reach this value for any parent clock.
So, I think that this point is not really critical and you can
probably keep these simple lines of code without adding u32 overflow
checking for big frequency.
>
>> > This is still not really understandable.
>> I have already added some comments from datasheet to explain the
>> different cases.
>> I don't see how I could be more understandable as it is clearly the
>> hardware way of working...
>
> You need to comment the check for the length, something like:
>
> /*
> * To end the transfer correctly the foo bit has to be cleared
> * already on the last but one byte to be transferred.
> */
>
OK I will add more comments.
> and bonus points if you can shrink the number of functions that check
> for this stuff.
There are only 2 functions to handle this stuff: handle_read() for
RXNE event and handle_rx_btf() for BTF event
I would prefer to keep 2 seperate functions to handle each event
according to buffer length as I don't have to do the same thing.
For example:
- for RXNE event with count = 2, I have to disable buffer interrupts
- for BTF event with msg count = 2, I have to .generate stop or
repeated start and disable all remaining interrupts.
I think that if I gather this stuff in one function, the code will be
less understandable.
>
>> > Just do:
>> >
>> > if (status & STM32F4_I2C_SR1_SB) {
>> > ...
>> > }
>> >
>> > if (status & ...) {
>> >
>> > }
>> ok but I would prefer something like that:
>> flag = status & possible_status
>> if (flag & STM32F4_I2C_SR1_SB) {
>> ...
>> }
>>
>> if (flag & ...) {
>> }
>
> Ok, if you really need possible_status.
>
>> > Then it's obvious by reading the code in which order they are handled
>> > without the need to check the definitions. Do you really need to jugle
>> > with possible_status?
>> I think I have to use possible_status as some events could occur
>> whereas the corresponding interrupt is disabled.
>> For example, for a 2 byte-reception, we don't have to take into accout
>> RXNE event so the corresponding interrupt is disabled.
>
> Is it possible to make it more obvious by doing:
>
> status = read_from_status_register() & read_from_interrupt_enable_register();
>
> at a single place?
Ok I will add these 2 functions in order to only use one status variable.
>
>> >> + /* Use __fls() to check error bits first */
>> >> + flag = __fls(status & possible_status);
>> >> +
>> >> + switch (1 << flag) {
>> >> + case STM32F4_I2C_SR1_BERR:
>> >> + reg = i2c_dev->base + STM32F4_I2C_SR1;
>> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_BERR);
>> >> + msg->result = -EIO;
>> >> + break;
>> >> +
>> >> + case STM32F4_I2C_SR1_ARLO:
>> >> + reg = i2c_dev->base + STM32F4_I2C_SR1;
>> >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_ARLO);
>> >> + msg->result = -EAGAIN;
>> >> + break;
>> >> +
>> >> + case STM32F4_I2C_SR1_AF:
>> >> + reg = i2c_dev->base + STM32F4_I2C_CR1;
>> >> + stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
>> >> + msg->result = -EIO;
>> >> + break;
>> >> +
>> >> + default:
>> >> + dev_err(i2c_dev->dev,
>> >> + "err it unhandled: status=0x%08x)\n", status);
>> >> + return IRQ_NONE;
>> >> + }
>> >
>> > You only check a single irq flag here.
>> Yes only the first error could be reported to the i2c clients via
>> msg->result that's why I don't check all errors.
>> Moreover, as soon as an error occurs, the I2C device is reset.
>
> The the "first" in the comment for __fls is misleading. Also do:
>
> if (status & MOST_IMPORTANT_ERROR) {
> ...
> }
>
> if (status & SECOND_MOST_IMPORTANT_ERROR) {
> ...
> }
>
> (if you need including possible_status stuff).
OK
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
Best regards,
Cedric
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox