* [PATCH v4 3/6] Documentation : can : flexcan : Add big-endian property to device tree
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
The FlexCAN controller can be modelled as little or big endian depending
on SOC design. This device tree property identifies the controller
endianness and the driver reads/writes controller registers based on
that.
This is optional property. i.e. if this property is not present in
device tree node then controller is assumed to be little endian. if this
property is present then controller is assumed to be big endian.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v4:
- document the default behaviour in the bindings if the big-endian property
is missing.
- Merged device tree changes and driver changes in one series
Changes in v3:
- No change.
Changes in v2:
- No change.
- Added one more patch in series.
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 56d6cc3..bfc0c43 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -18,6 +18,12 @@ Optional properties:
- xceiver-supply: Regulator that powers the CAN transceiver
+- big-endian: This means the registers of FlexCAN controller are big endian.
+ This is optional property.i.e. if this property is not present in
+ device tree node then controller is assumed to be little endian.
+ if this property is present then controller is assumed to be big
+ endian.
+
Example:
can@1c000 {
--
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
* [PATCH v4 2/6] can: flexcan: adding platform specific details for LS1021A
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal,
Bhupesh Sharma
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
This patch adds platform specific details for NXP SOC LS1021A to the
flexcan driver code.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Reviewed-by: Zhengxiong Jin <Jason.Jin-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v4:
- Merged device tree changes and driver changes in one series
- Remove obsolete comment about rev2 functional RX FIFO.
Changes in v3:
- Add LS1021 in FLEXCAN hardware feature flags table
- Kept LS1021 compatible in one line, even if it's more than 80
chars.
- Add PERR_STATE quirk and USE_OFF_TIMESTAMP quirk and
ENABLE_EACEN_RRS quirk for LS1021A.
- Tested on LS1021A using "cangen can0 -D 11223344DEADBEEF -L 8 -R"
and "cangen can0 -D 11223344DEADBEEF -L 8"
Changes in v2:
- No change.
drivers/net/can/flexcan.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 4c873fb..3a370d8 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -190,6 +190,7 @@
* MX53 FlexCAN2 03.00.00.00 yes no no no no
* MX6s FlexCAN3 10.00.12.00 yes yes no no yes
* VF610 FlexCAN3 ? no yes ? yes yes?
+ * LS1021A FlexCAN2 03.00.04.00 no yes no no yes
*
* Some SOCs do not have the RX_WARN & TX_WARN interrupt line connected.
*/
@@ -304,6 +305,12 @@ static const struct flexcan_devtype_data fsl_vf610_devtype_data = {
FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
};
+static const struct flexcan_devtype_data fsl_ls1021a_r2_devtype_data = {
+ .quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
+ FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_BROKEN_PERR_STATE |
+ FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
+};
+
static const struct can_bittiming_const flexcan_bittiming_const = {
.name = DRV_NAME,
.tseg1_min = 4,
@@ -1248,6 +1255,7 @@ static const struct of_device_id flexcan_of_match[] = {
{ .compatible = "fsl,imx25-flexcan", .data = &fsl_p1010_devtype_data, },
{ .compatible = "fsl,p1010-flexcan", .data = &fsl_p1010_devtype_data, },
{ .compatible = "fsl,vf610-flexcan", .data = &fsl_vf610_devtype_data, },
+ { .compatible = "fsl,ls1021ar2-flexcan", .data = &fsl_ls1021a_r2_devtype_data, },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, flexcan_of_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
* [PATCH v4 1/6] can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN controllers.
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal,
Bhupesh Sharma, Sakar Arora
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
The FlexCAN driver assumed that FlexCAN controller is big endian for
powerpc architecture and little endian for other architectures.
But this may not be the case. FlexCAN controller can be little or big
endian on any architecture. For e.g. NXP LS1021A ARM based SOC has big
endian FlexCAN controller.
Therefore, the driver has been modified to add a provision for both
types of controllers using an additional device tree property. On a
"fsl,p1010-flexcan" device BE is default, on all other devices LE is.
Big Endian controllers should have "big-endian" set in the device tree.
check "Documentation/devicetree/bindings/net/can/fsl-flexcan.txt" for
usage.
This is the standard practice followed in linux. for more info check:
Documentation/devicetree/bindings/common-properties.txt
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Sakar Arora <Sakar.Arora-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Reviewed-by: Zhengxiong Jin <Jason.Jin-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v4:
- Merged device tree changes and driver changes in one series
Changes in v3:
- Added fsl,imx25-flexcan, fsl,imx35-flexcan and fsl,imx53-flexcan
support to the driver.
- Modified patch deciption to state default endianness followed and
to include fsl-flexcan.txt referance.
Changes in v2:
- Modified patch deciption to include common-properties.txt reference.
- Reorder the LE/BE read/write APIs for better readability of code
- Added an exception to force BE API selection, for powerpc based platform
P1010. This ensures that new linux kernel works with old P1010
device-tree, while future powerpc platforms that use big endian
FlexCAN controller need to specify big-endian in device tree in
FlexCAN node.
- Tested on P1010 after backporting to freescale sdk 1.4 linux, without
any change in device-tree.
- Tested on NXP LS1021A arm based platform.
drivers/net/can/flexcan.c | 233 ++++++++++++++++++++----------------
1 file changed, 131 insertions(+), 102 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index a13a489..4c873fb 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -279,6 +279,10 @@ struct flexcan_priv {
struct clk *clk_per;
const struct flexcan_devtype_data *devtype_data;
struct regulator *reg_xceiver;
+
+ /* Read and Write APIs */
+ u32 (*read)(void __iomem *addr);
+ void (*write)(u32 val, void __iomem *addr);
};
static const struct flexcan_devtype_data fsl_p1010_devtype_data = {
@@ -312,39 +316,45 @@ static const struct can_bittiming_const flexcan_bittiming_const = {
.brp_inc = 1,
};
-/* Abstract off the read/write for arm versus ppc. This
- * assumes that PPC uses big-endian registers and everything
- * else uses little-endian registers, independent of CPU
- * endianness.
+/* FlexCAN module is essentially modelled as a little-endian IP in most
+ * SoCs, i.e the registers as well as the message buffer areas are
+ * implemented in a little-endian fashion.
+ *
+ * However there are some SoCs (e.g. LS1021A) which implement the FlexCAN
+ * module in a big-endian fashion (i.e the registers as well as the
+ * message buffer areas are implemented in a big-endian way).
+ *
+ * In addition, the FlexCAN module can be found on SoCs having ARM or
+ * PPC cores. So, we need to abstract off the register read/write
+ * functions, ensuring that these cater to all the combinations of module
+ * endianness and underlying CPU endianness.
*/
-#if defined(CONFIG_PPC)
-static inline u32 flexcan_read(void __iomem *addr)
+static inline u32 flexcan_read_be(void __iomem *addr)
{
- return in_be32(addr);
+ return ioread32be(addr);
}
-static inline void flexcan_write(u32 val, void __iomem *addr)
+static inline void flexcan_write_be(u32 val, void __iomem *addr)
{
- out_be32(addr, val);
+ iowrite32be(val, addr);
}
-#else
-static inline u32 flexcan_read(void __iomem *addr)
+
+static inline u32 flexcan_read_le(void __iomem *addr)
{
- return readl(addr);
+ return ioread32(addr);
}
-static inline void flexcan_write(u32 val, void __iomem *addr)
+static inline void flexcan_write_le(u32 val, void __iomem *addr)
{
- writel(val, addr);
+ iowrite32(val, addr);
}
-#endif
static inline void flexcan_error_irq_enable(const struct flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg_ctrl = (priv->reg_ctrl_default | FLEXCAN_CTRL_ERR_MSK);
- flexcan_write(reg_ctrl, ®s->ctrl);
+ priv->write(reg_ctrl, ®s->ctrl);
}
static inline void flexcan_error_irq_disable(const struct flexcan_priv *priv)
@@ -352,7 +362,7 @@ static inline void flexcan_error_irq_disable(const struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg_ctrl = (priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_MSK);
- flexcan_write(reg_ctrl, ®s->ctrl);
+ priv->write(reg_ctrl, ®s->ctrl);
}
static inline int flexcan_transceiver_enable(const struct flexcan_priv *priv)
@@ -377,14 +387,14 @@ static int flexcan_chip_enable(struct flexcan_priv *priv)
unsigned int timeout = FLEXCAN_TIMEOUT_US / 10;
u32 reg;
- reg = flexcan_read(®s->mcr);
+ reg = priv->read(®s->mcr);
reg &= ~FLEXCAN_MCR_MDIS;
- flexcan_write(reg, ®s->mcr);
+ priv->write(reg, ®s->mcr);
- while (timeout-- && (flexcan_read(®s->mcr) & FLEXCAN_MCR_LPM_ACK))
+ while (timeout-- && (priv->read(®s->mcr) & FLEXCAN_MCR_LPM_ACK))
udelay(10);
- if (flexcan_read(®s->mcr) & FLEXCAN_MCR_LPM_ACK)
+ if (priv->read(®s->mcr) & FLEXCAN_MCR_LPM_ACK)
return -ETIMEDOUT;
return 0;
@@ -396,14 +406,14 @@ static int flexcan_chip_disable(struct flexcan_priv *priv)
unsigned int timeout = FLEXCAN_TIMEOUT_US / 10;
u32 reg;
- reg = flexcan_read(®s->mcr);
+ reg = priv->read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS;
- flexcan_write(reg, ®s->mcr);
+ priv->write(reg, ®s->mcr);
- while (timeout-- && !(flexcan_read(®s->mcr) & FLEXCAN_MCR_LPM_ACK))
+ while (timeout-- && !(priv->read(®s->mcr) & FLEXCAN_MCR_LPM_ACK))
udelay(10);
- if (!(flexcan_read(®s->mcr) & FLEXCAN_MCR_LPM_ACK))
+ if (!(priv->read(®s->mcr) & FLEXCAN_MCR_LPM_ACK))
return -ETIMEDOUT;
return 0;
@@ -415,14 +425,14 @@ static int flexcan_chip_freeze(struct flexcan_priv *priv)
unsigned int timeout = 1000 * 1000 * 10 / priv->can.bittiming.bitrate;
u32 reg;
- reg = flexcan_read(®s->mcr);
+ reg = priv->read(®s->mcr);
reg |= FLEXCAN_MCR_HALT;
- flexcan_write(reg, ®s->mcr);
+ priv->write(reg, ®s->mcr);
- while (timeout-- && !(flexcan_read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK))
+ while (timeout-- && !(priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK))
udelay(100);
- if (!(flexcan_read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK))
+ if (!(priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK))
return -ETIMEDOUT;
return 0;
@@ -434,14 +444,14 @@ static int flexcan_chip_unfreeze(struct flexcan_priv *priv)
unsigned int timeout = FLEXCAN_TIMEOUT_US / 10;
u32 reg;
- reg = flexcan_read(®s->mcr);
+ reg = priv->read(®s->mcr);
reg &= ~FLEXCAN_MCR_HALT;
- flexcan_write(reg, ®s->mcr);
+ priv->write(reg, ®s->mcr);
- while (timeout-- && (flexcan_read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK))
+ while (timeout-- && (priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK))
udelay(10);
- if (flexcan_read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK)
+ if (priv->read(®s->mcr) & FLEXCAN_MCR_FRZ_ACK)
return -ETIMEDOUT;
return 0;
@@ -452,11 +462,11 @@ static int flexcan_chip_softreset(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->regs;
unsigned int timeout = FLEXCAN_TIMEOUT_US / 10;
- flexcan_write(FLEXCAN_MCR_SOFTRST, ®s->mcr);
- while (timeout-- && (flexcan_read(®s->mcr) & FLEXCAN_MCR_SOFTRST))
+ priv->write(FLEXCAN_MCR_SOFTRST, ®s->mcr);
+ while (timeout-- && (priv->read(®s->mcr) & FLEXCAN_MCR_SOFTRST))
udelay(10);
- if (flexcan_read(®s->mcr) & FLEXCAN_MCR_SOFTRST)
+ if (priv->read(®s->mcr) & FLEXCAN_MCR_SOFTRST)
return -ETIMEDOUT;
return 0;
@@ -467,7 +477,7 @@ static int __flexcan_get_berr_counter(const struct net_device *dev,
{
const struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->regs;
- u32 reg = flexcan_read(®s->ecr);
+ u32 reg = priv->read(®s->ecr);
bec->txerr = (reg >> 0) & 0xff;
bec->rxerr = (reg >> 8) & 0xff;
@@ -523,24 +533,24 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (cf->can_dlc > 0) {
data = be32_to_cpup((__be32 *)&cf->data[0]);
- flexcan_write(data, &priv->tx_mb->data[0]);
+ priv->write(data, &priv->tx_mb->data[0]);
}
if (cf->can_dlc > 3) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
- flexcan_write(data, &priv->tx_mb->data[1]);
+ priv->write(data, &priv->tx_mb->data[1]);
}
can_put_echo_skb(skb, dev, 0);
- flexcan_write(can_id, &priv->tx_mb->can_id);
- flexcan_write(ctrl, &priv->tx_mb->can_ctrl);
+ priv->write(can_id, &priv->tx_mb->can_id);
+ priv->write(ctrl, &priv->tx_mb->can_ctrl);
/* Errata ERR005829 step8:
* Write twice INACTIVE(0x8) code to first MB.
*/
- flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
&priv->tx_mb_reserved->can_ctrl);
- flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
&priv->tx_mb_reserved->can_ctrl);
return NETDEV_TX_OK;
@@ -659,7 +669,7 @@ static unsigned int flexcan_mailbox_read(struct can_rx_offload *offload,
u32 code;
do {
- reg_ctrl = flexcan_read(&mb->can_ctrl);
+ reg_ctrl = priv->read(&mb->can_ctrl);
} while (reg_ctrl & FLEXCAN_MB_CODE_RX_BUSY_BIT);
/* is this MB empty? */
@@ -674,17 +684,17 @@ static unsigned int flexcan_mailbox_read(struct can_rx_offload *offload,
offload->dev->stats.rx_errors++;
}
} else {
- reg_iflag1 = flexcan_read(®s->iflag1);
+ reg_iflag1 = priv->read(®s->iflag1);
if (!(reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_AVAILABLE))
return 0;
- reg_ctrl = flexcan_read(&mb->can_ctrl);
+ reg_ctrl = priv->read(&mb->can_ctrl);
}
/* increase timstamp to full 32 bit */
*timestamp = reg_ctrl << 16;
- reg_id = flexcan_read(&mb->can_id);
+ reg_id = priv->read(&mb->can_id);
if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
@@ -694,19 +704,19 @@ static unsigned int flexcan_mailbox_read(struct can_rx_offload *offload,
cf->can_id |= CAN_RTR_FLAG;
cf->can_dlc = get_can_dlc((reg_ctrl >> 16) & 0xf);
- *(__be32 *)(cf->data + 0) = cpu_to_be32(flexcan_read(&mb->data[0]));
- *(__be32 *)(cf->data + 4) = cpu_to_be32(flexcan_read(&mb->data[1]));
+ *(__be32 *)(cf->data + 0) = cpu_to_be32(priv->read(&mb->data[0]));
+ *(__be32 *)(cf->data + 4) = cpu_to_be32(priv->read(&mb->data[1]));
/* mark as read */
if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
/* Clear IRQ */
if (n < 32)
- flexcan_write(BIT(n), ®s->iflag1);
+ priv->write(BIT(n), ®s->iflag1);
else
- flexcan_write(BIT(n - 32), ®s->iflag2);
+ priv->write(BIT(n - 32), ®s->iflag2);
} else {
- flexcan_write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
- flexcan_read(®s->timer);
+ priv->write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
+ priv->read(®s->timer);
}
return 1;
@@ -718,8 +728,8 @@ static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->regs;
u32 iflag1, iflag2;
- iflag2 = flexcan_read(®s->iflag2) & priv->reg_imask2_default;
- iflag1 = flexcan_read(®s->iflag1) & priv->reg_imask1_default &
+ iflag2 = priv->read(®s->iflag2) & priv->reg_imask2_default;
+ iflag1 = priv->read(®s->iflag1) & priv->reg_imask1_default &
~FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
return (u64)iflag2 << 32 | iflag1;
@@ -735,7 +745,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
u32 reg_iflag1, reg_esr;
enum can_state last_state = priv->can.state;
- reg_iflag1 = flexcan_read(®s->iflag1);
+ reg_iflag1 = priv->read(®s->iflag1);
/* reception interrupt */
if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
@@ -758,7 +768,8 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
/* FIFO overflow interrupt */
if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {
handled = IRQ_HANDLED;
- flexcan_write(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
+ priv->write(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW,
+ ®s->iflag1);
dev->stats.rx_over_errors++;
dev->stats.rx_errors++;
}
@@ -772,18 +783,18 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
can_led_event(dev, CAN_LED_EVENT_TX);
/* after sending a RTR frame MB is in RX mode */
- flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
- &priv->tx_mb->can_ctrl);
- flexcan_write(FLEXCAN_IFLAG_MB(priv->tx_mb_idx), ®s->iflag1);
+ priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ &priv->tx_mb->can_ctrl);
+ priv->write(FLEXCAN_IFLAG_MB(priv->tx_mb_idx), ®s->iflag1);
netif_wake_queue(dev);
}
- reg_esr = flexcan_read(®s->esr);
+ reg_esr = priv->read(®s->esr);
/* ACK all bus error and state change IRQ sources */
if (reg_esr & FLEXCAN_ESR_ALL_INT) {
handled = IRQ_HANDLED;
- flexcan_write(reg_esr & FLEXCAN_ESR_ALL_INT, ®s->esr);
+ priv->write(reg_esr & FLEXCAN_ESR_ALL_INT, ®s->esr);
}
/* state change interrupt or broken error state quirk fix is enabled */
@@ -845,7 +856,7 @@ static void flexcan_set_bittiming(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg;
- reg = flexcan_read(®s->ctrl);
+ reg = priv->read(®s->ctrl);
reg &= ~(FLEXCAN_CTRL_PRESDIV(0xff) |
FLEXCAN_CTRL_RJW(0x3) |
FLEXCAN_CTRL_PSEG1(0x7) |
@@ -869,11 +880,11 @@ static void flexcan_set_bittiming(struct net_device *dev)
reg |= FLEXCAN_CTRL_SMP;
netdev_dbg(dev, "writing ctrl=0x%08x\n", reg);
- flexcan_write(reg, ®s->ctrl);
+ priv->write(reg, ®s->ctrl);
/* print chip status */
netdev_dbg(dev, "%s: mcr=0x%08x ctrl=0x%08x\n", __func__,
- flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
+ priv->read(®s->mcr), priv->read(®s->ctrl));
}
/* flexcan_chip_start
@@ -912,7 +923,7 @@ static int flexcan_chip_start(struct net_device *dev)
* choose format C
* set max mailbox number
*/
- reg_mcr = flexcan_read(®s->mcr);
+ reg_mcr = priv->read(®s->mcr);
reg_mcr &= ~FLEXCAN_MCR_MAXMB(0xff);
reg_mcr |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_HALT | FLEXCAN_MCR_SUPV |
FLEXCAN_MCR_WRN_EN | FLEXCAN_MCR_SRX_DIS | FLEXCAN_MCR_IRMQ |
@@ -926,7 +937,7 @@ static int flexcan_chip_start(struct net_device *dev)
FLEXCAN_MCR_MAXMB(priv->tx_mb_idx);
}
netdev_dbg(dev, "%s: writing mcr=0x%08x", __func__, reg_mcr);
- flexcan_write(reg_mcr, ®s->mcr);
+ priv->write(reg_mcr, ®s->mcr);
/* CTRL
*
@@ -939,7 +950,7 @@ static int flexcan_chip_start(struct net_device *dev)
* enable bus off interrupt
* (== FLEXCAN_CTRL_ERR_STATE)
*/
- reg_ctrl = flexcan_read(®s->ctrl);
+ reg_ctrl = priv->read(®s->ctrl);
reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
FLEXCAN_CTRL_ERR_STATE;
@@ -959,45 +970,45 @@ static int flexcan_chip_start(struct net_device *dev)
/* leave interrupts disabled for now */
reg_ctrl &= ~FLEXCAN_CTRL_ERR_ALL;
netdev_dbg(dev, "%s: writing ctrl=0x%08x", __func__, reg_ctrl);
- flexcan_write(reg_ctrl, ®s->ctrl);
+ priv->write(reg_ctrl, ®s->ctrl);
if ((priv->devtype_data->quirks & FLEXCAN_QUIRK_ENABLE_EACEN_RRS)) {
- reg_ctrl2 = flexcan_read(®s->ctrl2);
+ reg_ctrl2 = priv->read(®s->ctrl2);
reg_ctrl2 |= FLEXCAN_CTRL2_EACEN | FLEXCAN_CTRL2_RRS;
- flexcan_write(reg_ctrl2, ®s->ctrl2);
+ priv->write(reg_ctrl2, ®s->ctrl2);
}
/* clear and invalidate all mailboxes first */
for (i = priv->tx_mb_idx; i < ARRAY_SIZE(regs->mb); i++) {
- flexcan_write(FLEXCAN_MB_CODE_RX_INACTIVE,
- ®s->mb[i].can_ctrl);
+ priv->write(FLEXCAN_MB_CODE_RX_INACTIVE,
+ ®s->mb[i].can_ctrl);
}
if (priv->devtype_data->quirks & FLEXCAN_QUIRK_USE_OFF_TIMESTAMP) {
for (i = priv->offload.mb_first; i <= priv->offload.mb_last; i++)
- flexcan_write(FLEXCAN_MB_CODE_RX_EMPTY,
- ®s->mb[i].can_ctrl);
+ priv->write(FLEXCAN_MB_CODE_RX_EMPTY,
+ ®s->mb[i].can_ctrl);
}
/* Errata ERR005829: mark first TX mailbox as INACTIVE */
- flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
- &priv->tx_mb_reserved->can_ctrl);
+ priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ &priv->tx_mb_reserved->can_ctrl);
/* mark TX mailbox as INACTIVE */
- flexcan_write(FLEXCAN_MB_CODE_TX_INACTIVE,
- &priv->tx_mb->can_ctrl);
+ priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
+ &priv->tx_mb->can_ctrl);
/* acceptance mask/acceptance code (accept everything) */
- flexcan_write(0x0, ®s->rxgmask);
- flexcan_write(0x0, ®s->rx14mask);
- flexcan_write(0x0, ®s->rx15mask);
+ priv->write(0x0, ®s->rxgmask);
+ priv->write(0x0, ®s->rx14mask);
+ priv->write(0x0, ®s->rx15mask);
if (priv->devtype_data->quirks & FLEXCAN_QUIRK_DISABLE_RXFG)
- flexcan_write(0x0, ®s->rxfgmask);
+ priv->write(0x0, ®s->rxfgmask);
/* clear acceptance filters */
for (i = 0; i < ARRAY_SIZE(regs->mb); i++)
- flexcan_write(0, ®s->rximr[i]);
+ priv->write(0, ®s->rximr[i]);
/* On Vybrid, disable memory error detection interrupts
* and freeze mode.
@@ -1010,16 +1021,16 @@ static int flexcan_chip_start(struct net_device *dev)
* and Correction of Memory Errors" to write to
* MECR register
*/
- reg_ctrl2 = flexcan_read(®s->ctrl2);
+ reg_ctrl2 = priv->read(®s->ctrl2);
reg_ctrl2 |= FLEXCAN_CTRL2_ECRWRE;
- flexcan_write(reg_ctrl2, ®s->ctrl2);
+ priv->write(reg_ctrl2, ®s->ctrl2);
- reg_mecr = flexcan_read(®s->mecr);
+ reg_mecr = priv->read(®s->mecr);
reg_mecr &= ~FLEXCAN_MECR_ECRWRDIS;
- flexcan_write(reg_mecr, ®s->mecr);
+ priv->write(reg_mecr, ®s->mecr);
reg_mecr &= ~(FLEXCAN_MECR_NCEFAFRZ | FLEXCAN_MECR_HANCEI_MSK |
FLEXCAN_MECR_FANCEI_MSK);
- flexcan_write(reg_mecr, ®s->mecr);
+ priv->write(reg_mecr, ®s->mecr);
}
err = flexcan_transceiver_enable(priv);
@@ -1035,14 +1046,14 @@ static int flexcan_chip_start(struct net_device *dev)
/* enable interrupts atomically */
disable_irq(dev->irq);
- flexcan_write(priv->reg_ctrl_default, ®s->ctrl);
- flexcan_write(priv->reg_imask1_default, ®s->imask1);
- flexcan_write(priv->reg_imask2_default, ®s->imask2);
+ priv->write(priv->reg_ctrl_default, ®s->ctrl);
+ priv->write(priv->reg_imask1_default, ®s->imask1);
+ priv->write(priv->reg_imask2_default, ®s->imask2);
enable_irq(dev->irq);
/* print chip status */
netdev_dbg(dev, "%s: reading mcr=0x%08x ctrl=0x%08x\n", __func__,
- flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
+ priv->read(®s->mcr), priv->read(®s->ctrl));
return 0;
@@ -1067,10 +1078,10 @@ static void flexcan_chip_stop(struct net_device *dev)
flexcan_chip_disable(priv);
/* Disable all interrupts */
- flexcan_write(0, ®s->imask2);
- flexcan_write(0, ®s->imask1);
- flexcan_write(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
- ®s->ctrl);
+ priv->write(0, ®s->imask2);
+ priv->write(0, ®s->imask1);
+ priv->write(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
+ ®s->ctrl);
flexcan_transceiver_disable(priv);
priv->can.state = CAN_STATE_STOPPED;
@@ -1185,26 +1196,26 @@ static int register_flexcandev(struct net_device *dev)
err = flexcan_chip_disable(priv);
if (err)
goto out_disable_per;
- reg = flexcan_read(®s->ctrl);
+ reg = priv->read(®s->ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
- flexcan_write(reg, ®s->ctrl);
+ priv->write(reg, ®s->ctrl);
err = flexcan_chip_enable(priv);
if (err)
goto out_chip_disable;
/* set freeze, halt and activate FIFO, restrict register access */
- reg = flexcan_read(®s->mcr);
+ reg = priv->read(®s->mcr);
reg |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_FEN | FLEXCAN_MCR_SUPV;
- flexcan_write(reg, ®s->mcr);
+ priv->write(reg, ®s->mcr);
/* Currently we only support newer versions of this core
* featuring a RX hardware FIFO (although this driver doesn't
* make use of it on some cores). Older cores, found on some
* Coldfire derivates are not tested.
*/
- reg = flexcan_read(®s->mcr);
+ reg = priv->read(®s->mcr);
if (!(reg & FLEXCAN_MCR_FEN)) {
netdev_err(dev, "Could not enable RX FIFO, unsupported core\n");
err = -ENODEV;
@@ -1232,6 +1243,9 @@ static void unregister_flexcandev(struct net_device *dev)
static const struct of_device_id flexcan_of_match[] = {
{ .compatible = "fsl,imx6q-flexcan", .data = &fsl_imx6q_devtype_data, },
{ .compatible = "fsl,imx28-flexcan", .data = &fsl_imx28_devtype_data, },
+ { .compatible = "fsl,imx53-flexcan", .data = &fsl_p1010_devtype_data, },
+ { .compatible = "fsl,imx35-flexcan", .data = &fsl_p1010_devtype_data, },
+ { .compatible = "fsl,imx25-flexcan", .data = &fsl_p1010_devtype_data, },
{ .compatible = "fsl,p1010-flexcan", .data = &fsl_p1010_devtype_data, },
{ .compatible = "fsl,vf610-flexcan", .data = &fsl_vf610_devtype_data, },
{ /* sentinel */ },
@@ -1313,6 +1327,21 @@ static int flexcan_probe(struct platform_device *pdev)
dev->flags |= IFF_ECHO;
priv = netdev_priv(dev);
+
+ if (of_property_read_bool(pdev->dev.of_node, "big-endian")) {
+ priv->read = flexcan_read_be;
+ priv->write = flexcan_write_be;
+ } else {
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "fsl,p1010-flexcan")) {
+ priv->read = flexcan_read_be;
+ priv->write = flexcan_write_be;
+ } else {
+ priv->read = flexcan_read_le;
+ priv->write = flexcan_write_le;
+ }
+ }
+
priv->can.clock.freq = clock_freq;
priv->can.bittiming_const = &flexcan_bittiming_const;
priv->can.do_set_mode = flexcan_set_mode;
--
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
* [PATCH v4 0/6] Remodel FlexCAN register r/w APIs for big endian
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg, mkl, linux-can, robh+dt, mark.rutland, devicetree
Cc: V.Sethi, poonam.aggrwal, Pankaj Bansal
This patch series remodels the FlexCAN register r/w APIs for big endian.
The endianness is checked based on optional big-endian property in
device tree. if this property is not present in device tree node then
controller is assumed to be little endian. if this property is present then
controller is assumed to be big endian.
An exception to this rule is powerpc P1010RDB, which is always
big-endian, even if big-endian is not present in dts. This is
checked using p1010-flexcan compatible in dts.
Therefore, remove p1010-flexcan compatible from imx series dts,
as their flexcan core is little endian.
Finally this series adds support for NXP LS1021A SOC in flexcan,
which is arm based SOC having big-endian FlexCAN controller.
Pankaj Bansal (6):
can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN
controllers.
can: flexcan: adding platform specific details for LS1021A
Documentation : can : flexcan : Add big-endian property to device tree
powerpc: dts: P1010: Add endianness property to flexcan node
arm: dts: Remove p1010-flexcan compatible from imx series dts
arm/dts: Add nodes for flexcan devices present on LS1021A-Rev2 SoC
.../bindings/net/can/fsl-flexcan.txt | 6 +
arch/arm/boot/dts/imx25.dtsi | 4 +-
arch/arm/boot/dts/imx28.dtsi | 4 +-
arch/arm/boot/dts/imx35.dtsi | 4 +-
arch/arm/boot/dts/imx53.dtsi | 4 +-
arch/arm/boot/dts/ls1021a-qds.dts | 16 ++
arch/arm/boot/dts/ls1021a-twr.dts | 16 ++
arch/arm/boot/dts/ls1021a.dtsi | 36 +++
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 2 +
drivers/net/can/flexcan.c | 241 ++++++++++-------
10 files changed, 223 insertions(+), 110 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: Stephan Müller @ 2017-11-24 13:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Łukasz Stelmach, Rob Herring, Matt Mackall, Herbert Xu,
devicetree, linux-crypto, linux-samsung-soc, linux-kernel,
Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <CAJKOXPc2MGf_b3xA=R=p2_fQ0+SQvwLL8vfZLGhGAAEssD=hJA@mail.gmail.com>
Am Freitag, 24. November 2017, 13:09:06 CET schrieb Krzysztof Kozlowski:
Hi Krzysztof,
> >>
> >> 1. I was rather thinking about extending existing exynos-rng.c [1] so
> >> it would be using TRNG as seed for PRNG as this gives you much more
> >> random data. Instead you developed totally separate driver which has
> >> its own benefits - one can choose which interface he wants. Although
> >> it is a little bit duplication.
> >
> > As far as I can tell, these are two different devices. However, PRNG
> > shares hardware with the hash engine. Indeed there is a hardware to
> > connect TRNG and PRNG, but, IMHO, it might be hard to model that
> > dependency in kernel.
>
> It should be as simple as setting few more registers in SSS module
> (actually maybe just enabling TRNG_SEED_START in PRNG). You do not
> have to model it in a kernel like connecting some hw_rng entity to
> cryptoai's rng_alg. See the jitterentropy-kcapi.c. I understand that
> in that case existing exynos-rng.c could expose two different RNG
> devices - one PRNG based on user's seed and second TRNG (actually
> TRNG+PRNG).
>
> It does not seem difficult to model but the question is whether that
> makes sense.
The usage strategy for the PRNGs registered at the kernel crypto API is as
follows:
1. crypto_rng_alloc
2. crypto_rng_reset
3. crypto_rng_generate
If in step 2 you provide NULL as input, the kernel takes get_random_bytes as
seed source. Step 2 is the mandatory.
The Linux-RNG can be fed internally from the hw_random framework by the
function hwrng_fillfn. This function is only used if the current_quality or
default_quality values in the hw_random framework is set.
For the TRNG, it seems to be not set per default, but could be set as either a
boot argument or at runtime via /sys.
If that variable is set and the TRNG is registered, it feeds random data into
the Linux-RNG which in turn is used per default to seed a PRNG. In this case,
no detour via user space is needed to push data from TRNG to the PRNG. Using
that mechanism allows you to benefit from additional entropy the Linux-RNG
collects elsewhere.
>
> > To me it seems easier to read TRNG (or
> > /dev/random) and and write the result to PRNG manually (in software).
>
> Indeed this gives more flexibility to the user (choice of engine) but
> first, it is slower, and second it reduces the quality of random
> numbers (PRNG reseeds itself... but in this model cannot reseed from
> TRNG).
Given the reasons above, I would think that keeping the PRMG and TRNG separate
as offered by the current patch seems reasonable. If configured correctly, the
TRNG can seed the PRNG at any time (including boot time) without the need of
user space.
>
> Best regards,
> Krzysztof
Ciao
Stephan
^ permalink raw reply
* [PATCH] ARM: dts: add minimal device tree for compute model 3
From: kernel @ 2017-11-24 12:18 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Florian Fainelli,
Catalin Marinas, devicetree, linux-arm-kernel, linux-rpi-kernel,
eric
Cc: Martin Sperl
From: Martin Sperl <kernel@martin.sperl.org>
Add a minimal working device tree for the compute model 3
for both arm and arm64.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/bcm2837-rpi-cm3.dts | 38 ++++++++++++++++++++++++
arch/arm64/boot/dts/broadcom/Makefile | 1 +
arch/arm64/boot/dts/broadcom/bcm2837-rpi-cm3.dts | 2 ++
4 files changed, 42 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm2837-rpi-cm3.dts
create mode 100644 arch/arm64/boot/dts/broadcom/bcm2837-rpi-cm3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index eff87a344566..b24a682c450d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -75,6 +75,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2835-rpi-a-plus.dtb \
bcm2836-rpi-2-b.dtb \
bcm2837-rpi-3-b.dtb \
+ bcm2837-rpi-cm3.dtb \
bcm2835-rpi-zero.dtb \
bcm2835-rpi-zero-w.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += \
diff --git a/arch/arm/boot/dts/bcm2837-rpi-cm3.dts b/arch/arm/boot/dts/bcm2837-rpi-cm3.dts
new file mode 100644
index 000000000000..f387bd8bd707
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2837-rpi-cm3.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2837.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-usb-host.dtsi"
+
+/ {
+ compatible = "raspberrypi,3-compute-model", "brcm,bcm2837";
+ model = "Raspberry Pi Compute Module 3";
+
+ memory {
+ reg = <0 0x40000000>;
+ };
+
+ leds {
+ act {
+ gpios = <&gpio 47 0>;
+ };
+ };
+};
+
+&hdmi {
+ hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_gpio14>;
+ status = "okay";
+};
+
+/* SDHOST is used to drive the SD card */
+&sdhost {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhost_gpio48>;
+ status = "okay";
+ bus-width = <4>;
+};
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index 3df2db7f8878..aecf58f503ae 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
+dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-cm3.dtb
dts-dirs += northstar2
dts-dirs += stingray
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-cm3.dts b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-cm3.dts
new file mode 100644
index 000000000000..a1bba71462ed
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-cm3.dts
@@ -0,0 +1,2 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "arm/bcm2837-rpi-cm3.dts"
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: Krzysztof Kozlowski @ 2017-11-24 12:09 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Rob Herring, Matt Mackall, Herbert Xu, devicetree, linux-crypto,
linux-samsung-soc, linux-kernel, Marek Szyprowski,
Bartlomiej Zolnierkiewicz, Stephan Müller
In-Reply-To: <87o9nsde9r.fsf%l.stelmach@samsung.com>
On Thu, Nov 23, 2017 at 7:46 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
> It was <2017-11-23 czw 17:31>, when Krzysztof Kozlowski wrote:
>> On Thu, Nov 23, 2017 at 4:09 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>>> Add support for True Random Number Generator found in Samsung Exynos
>>> 5250+ SoCs.
>>>
>>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>>> ---
>>> MAINTAINERS | 7 +
>>> drivers/char/hw_random/Kconfig | 12 ++
>>> drivers/char/hw_random/Makefile | 1 +
>>> drivers/char/hw_random/exynos-trng.c | 256 +++++++++++++++++++++++++++++++++++
>>> 4 files changed, 276 insertions(+)
>>> create mode 100644 drivers/char/hw_random/exynos-trng.c
>>>
>
+Cc Stephan Müller, who reviewed intensively exynos-rng.c.
> [...]
>
>>> endif # HW_RANDOM
>>
>> Thanks for working on TRNG.
>>
>> 1. I was rather thinking about extending existing exynos-rng.c [1] so
>> it would be using TRNG as seed for PRNG as this gives you much more
>> random data. Instead you developed totally separate driver which has
>> its own benefits - one can choose which interface he wants. Although
>> it is a little bit duplication.
>
> As far as I can tell, these are two different devices. However, PRNG
> shares hardware with the hash engine. Indeed there is a hardware to
> connect TRNG and PRNG, but, IMHO, it might be hard to model that
> dependency in kernel.
It should be as simple as setting few more registers in SSS module
(actually maybe just enabling TRNG_SEED_START in PRNG). You do not
have to model it in a kernel like connecting some hw_rng entity to
cryptoai's rng_alg. See the jitterentropy-kcapi.c. I understand that
in that case existing exynos-rng.c could expose two different RNG
devices - one PRNG based on user's seed and second TRNG (actually
TRNG+PRNG).
It does not seem difficult to model but the question is whether that
makes sense.
> To me it seems easier to read TRNG (or
> /dev/random) and and write the result to PRNG manually (in software).
Indeed this gives more flexibility to the user (choice of engine) but
first, it is slower, and second it reduces the quality of random
numbers (PRNG reseeds itself... but in this model cannot reseed from
TRNG).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver
From: Andre Przywara @ 2017-11-24 12:05 UTC (permalink / raw)
To: Linus Walleij, Rob Herring
Cc: Maxime Ripard, Chen-Yu Tsai, linux-gpio, Mark Rutland, devicetree,
Linux ARM, Arnd Bergmann, Icenowy Zheng,
linux-sunxi@googlegroups.com
In-Reply-To: <CACRpkdYFoUmGJYdKz0t9gsrkK=u8-oJjaRBXtNYHaUt9kSa3_g@mail.gmail.com>
Hi,
On 24/11/17 10:28, Linus Walleij wrote:
> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote:
>
>> so far the pinctrl driver for supporting a particular Allwinner SoC requires
>> a hardcoded table in the kernel code.
> (...)
>> This series here moves the data encoded in the table so far into the DT itself,
>> removing the need for a hardcoded table in the kernel.
> (...)
>
> The DT maintainers have been pretty clear on that they don't like
> using the the DT as a generic fit-all information dump. They
> prefer to look up hardware data from per-soc compatible strings.
>
> I have been sceptic about it too, on the grounds that I think it
> make configuration and multiplatform kernels easy, while making
> debugging and reading code+device tree hard, also affecting
> maintenance cost.
>
> I'd like to have Maxime's buy-in before we progress and also some
> discussion on these themes in general.
Indeed this was one of the goals of this series. I can understand were
we came from and that we had those in-kernel tables in the past.
I am just a bit worried that with Allwinner recently playing the SKU
game we end up with tons of tables for only slightly different SoCs (see
the H3 and H5, for instance). And with single image kernels we pile up
quite some *data* in each kernel, which is of little interest for
everyone else.
Also my understanding is that the actual Allwinner pin controller IP
(register map) is very much the same across all SoCs. Mostly the only
difference is the mapping between pins and mux functions, which we
express in the DT already anyway (in the subnodes). And this is really a
poster book example of what DT should be doing: express the specific
mappings of a particular implementation. I don't see why this would need
to be per-board only, if we can pull this up to the SoC level.
>> The approach taken here is to parse the DT and generate the table with
>> the help of additional properties, then hand this table over to the existing
>> driver. This is covered by three basic extensions to the DT binding:
>
> I adressed this in the bindings patch.
>
>> The benefit of this series is two-fold:
>> - Future SoCs don't need an in-kernel table anymore. They can describe
>> everything in the DT,
>
> It can be debated whether that is really a good thing or actually
> a bad thing for the reasons stated above.
The point is that we already rely on the DT anyway, just that we use a
*string* to specify a certain mux function. The in-kernel table just
maps this to an actual SoC-specific register value. I think the GPIO
subsystem needs the name, hence I am just adding the pinmux property.
> Also an additional bad thing is inconsistency between different
> SoCs.
Well, does that mean that we should never change anything? Consistency
is nice, but should not be an excuse for not improving things. And I
tried to embrace the existing driver by designing this on top of it.
> What we have in the kernel for all-DT is pinctrl-single.c.
>
> This exists for the case where there is exactly one register per
> pin and all you have is strange macro files from the ASIC people
> that noone understands. OMAP and HiSilicon is using this.
> It's a compromise, I'm not super-happy with that driver at all times
> but it is for a very strongly specified case.
>
> Would it be possible for you guys to simply use/embrace/extend
> pinctrl-single.c if you want to go this route?
Thanks for the pointer, I will have a look.
> Any higher order of complexity than "one register per pin" I think
> is better handled by open coding it than trying to push things into
> the device tree, because of readability, debuggability and maintenance
> issues.
I don't see how this binding would make this worse.
Cheers,
Andre.
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Andre Przywara @ 2017-11-24 12:04 UTC (permalink / raw)
To: Thierry Reding, Linus Walleij
Cc: Maxime Ripard, Chen-Yu Tsai, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux ARM, Arnd Bergmann, Icenowy Zheng,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <20171124105240.GB3792@ulmo>
Hi,
(adding linux-sunxi, which I forgot at the initial post).
On 24/11/17 10:52, Thierry Reding wrote:
> On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
>> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
>>
>>> So far all the Allwinner pinctrl drivers provided a table in the
>>> kernel to describe all the pins and the link between the pinctrl functions
>>> names (strings) and their respective mux values (register values).
>>>
>>> Extend the binding to put those mappings in the DT, so that any SoC can
>>> describe its pinctrl and GPIO data fully there instead of relying on
>>> tables.
>>> This uses a generic compatible name, to be prepended with an SoC
>>> specific name in the node.
>
> This seems backwards to me. I'm not sure if Rob has any hard rules on
> this, but in the past I've seen a lot of drivers stick this kind of data
> into drivers. I personally also prefer that approach because the data is
> completely static and there's no way for any specific board to customize
> it. So the tables are in fact implied completely by the SoC compatible
> string.
But this is just *data*, and I believe it is actually package specific.
We need the DT to describe the relation between devices and pins anyway,
it's just that we use arbitrary strings today instead of the actual
register value. This is what the generic pinmux property fixes.
> Moving all of this data into device tree has a number of disadvantages:
>
> * Existing boards already use the static tables in the driver, and the
> device trees don't contain any data, so you can't get rid of any of
> the existing tables because it would break ABI.
Yes, my DeLorean is in the garage, so I can't really change this anymore
;-) But that doesn't mean we have to go on with this forever, I think.
> * Moving the table into the DT doesn't actually solve anything because
> the driver would have to validate the DT description to make sure it
> contains valid data. And in order to validate DT content, the driver
> would need a copy of the table anyway.
I don't get what the driver would need to validate? We rely on DT
information to be correct anyway, otherwise your board just won't work.
If the DT is wrong, you have much bigger problems.
Actually we gain something, because we only commit information that can
actually be tested. Right now we have a lot of information which is
copied from the manual, and nobody knows if pin H24 on the A10 is really
PATA-CS1 or not. Plus we have bugs when creating the table, plus
copy&paste bugs. I found some while grep-ing for patterns - will send
fixes ASAP.
In the moment all the table gives us is a mapping between a *string* and
the respective mux register value (per pin), plus the number of pins in
each bank. This can *easily* be put in the DT and should belong there.
Actually I believe that the current binding is not correct, because it
makes those mux strings a part of the binding, though this is not
documented anywhere. A developer cannot take the binding and write a
working driver or even a DT without looking at the code.
Plus we already changed those names in the past (for instance commit
bc0f566a98c4), basically breaking compatibility.
> I don't think you're going to do yourself any favours by pushing this. I
> also don't see the commit description give any reason why you want to
> move the table into device tree. Do you see any advantages in doing so?
We stop adding tables with SoC specific *data* in the kernel *code*
base. With being boolean Kconfig options, this gets added to every
single-image kernel.
More important: those tables help Linux, but other DT consumers (*BSD,
U-Boot) have to replicate them, which is just wrong, IMHO.
I believe the kernel is a nice collection of really good code for
complicated file systems, high performance network protocols and
sophisticated memory management, among others. It shouldn't be a dumping
ground for arbitrary, very SoC specific information. Cf. LinusT 2011.
DT is out there to fix this, so we should do so.
Cheers,
Andre.
--
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: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Maxime Ripard @ 2017-11-24 12:03 UTC (permalink / raw)
To: Linus Walleij
Cc: Andre Przywara,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Chen-Yu Tsai, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Linux ARM,
Arnd Bergmann, Icenowy Zheng
In-Reply-To: <CACRpkdbpfkM4odz425+4qyUCF5vqPWBQ=F5Yk7AtJL5SqXghpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Hi Linus,
On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
>
> > So far all the Allwinner pinctrl drivers provided a table in the
> > kernel to describe all the pins and the link between the pinctrl functions
> > names (strings) and their respective mux values (register values).
> >
> > Extend the binding to put those mappings in the DT, so that any SoC can
> > describe its pinctrl and GPIO data fully there instead of relying on
> > tables.
> > This uses a generic compatible name, to be prepended with an SoC
> > specific name in the node.
> >
> > Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> (...)
>
> I definately want feedback from Maxime before I do anything with
> this patch series.
So I've been opposed to it as well, for the reasons Rob, Thierry and
you pointed out already in that thread
I just wasn't sure what your opinion on it was, so I didn't answer
just so that I could see if I was the only one pushing back.
So I guess we all agree here.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Andre Przywara @ 2017-11-24 11:58 UTC (permalink / raw)
To: Linus Walleij, thierry.reding@gmail.com
Cc: Maxime Ripard, Chen-Yu Tsai, linux-gpio, Rob Herring,
Mark Rutland, devicetree, Linux ARM, Arnd Bergmann, Icenowy Zheng
In-Reply-To: <CACRpkdbpfkM4odz425+4qyUCF5vqPWBQ=F5Yk7AtJL5SqXghpg@mail.gmail.com>
Hi Linus,
thanks for having a look!
On 24/11/17 10:19, Linus Walleij wrote:
> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote:
>
>> So far all the Allwinner pinctrl drivers provided a table in the
>> kernel to describe all the pins and the link between the pinctrl functions
>> names (strings) and their respective mux values (register values).
>>
>> Extend the binding to put those mappings in the DT, so that any SoC can
>> describe its pinctrl and GPIO data fully there instead of relying on
>> tables.
>> This uses a generic compatible name, to be prepended with an SoC
>> specific name in the node.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> (...)
>
> I definately want feedback from Maxime before I do anything with
> this patch series.
>
>> +** Generic pinctrl binding
>> +The above binding requires knowledge of the actual mux setting values for
>> +each supported SoC in the code parsing the DT (for instance the kernel).
>> +The generic binding puts this information in the DT. It uses the
>> +"allwinner,sunxi-pinctrl" compatible, in addition to some SoC specific string.
>> +It extends the above described binding as follows:
>> +Required properties:
>> +- allwinner,gpio-pins: An array of 32-bit numbers to denote the number of
>> + implemented pins per pin controller port. Non-implemented ports can specify
>> + 0 here. There will be as many ports as this array has elements.
>
> I don't understand what this adds that gpio-ranges does not already
> provide.
> Documentation/devicetree/bindings/gpio/gpio.txt
> at the end of the file.
Ah, thanks for the pointer, will try to see if that fits in here.
Although here (despite my clumsy naming) I think this is more about the
"pinmux" pins than the GPIOs. I am not sure if it's just my
understanding or if on Allwinner we just happen to have every pinmux pin
being a GPIO pin as well, so the distinction between the two isn't so clear.
> These ranges exist exactly to map pin controller pins in a pin controller
> to GPIO lines in a gpiochip.
Which makes it a bit more confusing because we have the pinctrl and GPIO
controller drivers combined in one file.
>> +- allwinner,irq-pin-map: Contains a number of IRQ port maps, describing the
>> + relationship between interrupt banks and GPIO pins. Each map has six 32-bit
>> + members:
>> + <[IRQ port] [1st IRQ pin] [GPIO port] [1st GPIO pin] [mux value] [length]>
>> + This maps the first [length] IRQ pins starting with [IRQ port]:[1st IRQ pin]
>> + to [GPIO port]:[1st GPIO pin], all using [mux value] to select the IRQ
>> + functionality.
>
> We have recently added GPIO "bank" awareness into gpiolib
> via Thierry Reding's patches, so a gpiochip can use the generic
> GPIOLIB_IRQCHIP and specify multiple IRQ parents with a map.
>
> Please see if you can use this instead.
Thanks for the hint, will have a look.
> If any of this should be expressed in the DT bindings it should
> be genericized and not use any "allwinner,*" prefixes, and it
> should preferably just be hard-coded in the driver and switched
> in from the compatible string IMO.
I agree, this allwinner prefix was just a first shot for the RFC.
The reason for this map is that older Allwinner SoCs have *one* IRQ pin
bank, which contains pins from *multiple* GPIO banks. The A10/A20 for
instance maps the first 22 IRQ pins to Port H0-H21, the remaining 10 IRQ
pins are on port I10-I19. This irq-pin-map is an admittedly
over-engineered attempt to express this is a generic way, trying to
embrace the DT way of mapping things, like we do with the "ranges"
property, for instance.
Recent SoCs just have some GPIO banks which map directly to IRQ pin
banks (on the A64 ports B, G and H map to IRQ bank 0, 1 and 2), so this
is not really needed here. My first version indeed just had a simpler
list to express this.
This series aims to build on top of the existing driver as much as
possible, so some things are not as elegant as they could be.
>> +Optional properties:
>> +- allwinner,port-base: The number of GPIO ports to skip at the beginning.
>> +- allwinner,irq-bank-base: The number of IRQ banks to skip at the beginning.
>
> I don't understand this. It looks hacky. Can you elaborate why this
> is needed?
It is indeed hacky, and just maps the irq_bank_base member of struct
sunxi_pinctrl_desc into the DT. My understanding is that the A33 skips
the first interrupt bank in the register map, for whatever reason. Might
just be an implementation oddity.
I am just wondering if this could be expressed with the irq-pin-map
above. Or if it's more or less an A33 bug, we could derive this from the
compatible string.
>> +- allwinner,irq-read-needs-mux: Specifies that reading the line level of
>> + a pin configured as an IRQ pin is not possible. A driver needs to switch
>> + to the GPIO-in function to be able to read the level.
>
> I guess it is a bool flag?
Right, should mention that.
>> +Required properties for subnodes:
>> +- pinmux: An array of mux values to write into the respective MMIO register
>> + bits for this pin when selecting the function. If this array has less
>> + elements than pins, the *last* value will be used for all pins beyond that.
>> + This allows to use a single element for the (likely) case all pins use the
>> + same mux value.
>
> This is a standard bindings so I don't have much against it. But I
> need Maxime's input here, I think we should keep Allwinner consistent
> across SoCs.
I can understand that, and that's why I choose the new binding to just
be an extension of what we have already.
I am happy to have a discussion on that in general - actually this was
one aim of this series. See the other thread.
I might even write some summary on how it works today and why I believe
it should be improved, I just wasn't sure that was actually needed.
Cheers,
Andre.
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-nitrogen6x: Add SPI NOR partitions
From: Otavio Salvador @ 2017-11-24 11:21 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Gary Bisson, Otavio Salvador, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Russell King, Shawn Guo
This adds the partitions definition for the SPI NOR to provide
backward compatibility with the documented[1] layout used with
Boundary Devices BSP.
1. https://boundarydevices.com/boot-flash-access-linux/
It exports to Linux:
mtd0: U-Boot
mtd1: U-Boot Environment
mtd2: Bootsplash
Signed-off-by: Otavio Salvador <otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 4bdf29169d2a..f8b267875e1c 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -276,6 +276,23 @@
compatible = "sst,sst25vf016b", "jedec,spi-nor";
spi-max-frequency = <20000000>;
reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "U-Boot";
+ reg = <0x0 0xc0000>;
+ };
+
+ partition@c0000 {
+ label = "U-Boot Environment";
+ reg = <0xc0000 0x2000>;
+ };
+
+ partition@c2000 {
+ label = "Bootsplash";
+ reg = <0xc2000 0x13e000>;
+ };
};
};
--
2.15.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 related
* Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-11-24 11:09 UTC (permalink / raw)
To: Simon Horman
Cc: Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Magnus Damm, Arnd Bergmann, Rob Herring, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171124105234.25774-1-horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Fri, Nov 24, 2017 at 11:52 AM, Simon Horman
<horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.
>
> This problem is flagged by the compiler as follows:
> $ make
> ...
> DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb
> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb
> arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
> v2
> * Preserve alphabetical order of nodes present in root node.
Thanks for the update!
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [RFCv2 PATCH 10/36] vfio: Add support for Shared Virtual Memory
From: Jean-Philippe Brucker @ 2017-11-24 10:58 UTC (permalink / raw)
To: Bob Liu, linux-arm-kernel@lists.infradead.org,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
devicetree@vger.kernel.org, iommu@lists.linux-foundation.org
Cc: joro@8bytes.org, robh+dt@kernel.org, Mark Rutland,
Catalin Marinas, Will Deacon, Lorenzo Pieralisi,
hanjun.guo@linaro.org, Sudeep Holla, rjw@rjwysocki.net,
lenb@kernel.org, Robin Murphy, bhelgaas@google.com,
alex.williamson@redhat.com, tn@semihalf.com,
thunder.leizhen@huawei.com, xieyisheng1@huawei.com,
gabriele.paoloni@huawei.com, nwat
In-Reply-To: <419afe22-816d-263f-9c85-1a9e28c723b7@huawei.com>
On 24/11/17 08:23, Bob Liu wrote:
> On 2017/10/6 21:31, Jean-Philippe Brucker wrote:
>> Add two new ioctl for VFIO containers. VFIO_DEVICE_BIND_PROCESS creates a
>> bond between a container and a process address space, identified by a
>> device-specific ID named PASID. This allows the device to target DMA
>> transactions at the process virtual addresses without a need for mapping
>> and unmapping buffers explicitly in the IOMMU. The process page tables are
>> shared with the IOMMU, and mechanisms such as PCI ATS/PRI may be used to
>> handle faults. VFIO_DEVICE_UNBIND_PROCESS removed a bond identified by a
>> PASID.
>>
>
> How about hide bind/unbind into ioctl(VFIO_SET_IOMMU)?
> e.g always bind to current process in SET_IOMMU.
>
> Not sure about the real use case.
I guess you could introduce a new VFIO IOMMU type for this. I think this
would be useful for SVA without PASID: if the device supports I/O page
faults, use SET_IOMMU with a VFIO_SVA_IOMMU type (for example) and the
process is bound automatically to the default translation context of the
device. This requires a new IOMMU type because the MAP/UNMAP ioctl won't
work anymore.
I'm not keen on introducing loads of new features in the APIs at the
moment, because I only have the IOMMU point of view, not many endpoint users.
Thanks,
Jean
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Thierry Reding @ 2017-11-24 10:52 UTC (permalink / raw)
To: Linus Walleij, Andre Przywara
Cc: Maxime Ripard, Chen-Yu Tsai, linux-gpio, Rob Herring,
Mark Rutland, devicetree, Linux ARM, Arnd Bergmann, Icenowy Zheng
In-Reply-To: <CACRpkdbpfkM4odz425+4qyUCF5vqPWBQ=F5Yk7AtJL5SqXghpg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote:
>
> > So far all the Allwinner pinctrl drivers provided a table in the
> > kernel to describe all the pins and the link between the pinctrl functions
> > names (strings) and their respective mux values (register values).
> >
> > Extend the binding to put those mappings in the DT, so that any SoC can
> > describe its pinctrl and GPIO data fully there instead of relying on
> > tables.
> > This uses a generic compatible name, to be prepended with an SoC
> > specific name in the node.
This seems backwards to me. I'm not sure if Rob has any hard rules on
this, but in the past I've seen a lot of drivers stick this kind of data
into drivers. I personally also prefer that approach because the data is
completely static and there's no way for any specific board to customize
it. So the tables are in fact implied completely by the SoC compatible
string.
Moving all of this data into device tree has a number of disadvantages:
* Existing boards already use the static tables in the driver, and the
device trees don't contain any data, so you can't get rid of any of
the existing tables because it would break ABI.
* Moving the table into the DT doesn't actually solve anything because
the driver would have to validate the DT description to make sure it
contains valid data. And in order to validate DT content, the driver
would need a copy of the table anyway.
I don't think you're going to do yourself any favours by pushing this. I
also don't see the commit description give any reason why you want to
move the table into device tree. Do you see any advantages in doing so?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus
From: Simon Horman @ 2017-11-24 10:52 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-arm-kernel, Magnus Damm, Arnd Bergmann, Rob Herring,
Geert Uytterhoeven, devicetree, Simon Horman
Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
The nodes that have been moved do not have any register properties and thus
shouldn't be placed on the bus.
This problem is flagged by the compiler as follows:
$ make
...
DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb
arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v2
* Preserve alphabetical order of nodes present in root node.
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 134 +++++++++++++++----------------
1 file changed, 67 insertions(+), 67 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 6db4f10376a1..1e80b7b6516a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -184,6 +184,30 @@
clock-frequency = <0>;
};
+ pmu_a57 {
+ compatible = "arm,cortex-a57-pmu";
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a57_0>,
+ <&a57_1>,
+ <&a57_2>,
+ <&a57_3>;
+ };
+
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a53_0>,
+ <&a53_1>,
+ <&a53_2>,
+ <&a53_3>;
+ };
+
soc: soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
@@ -338,42 +362,6 @@
resets = <&cpg 905>;
};
- pmu_a57 {
- compatible = "arm,cortex-a57-pmu";
- interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a57_0>,
- <&a57_1>,
- <&a57_2>,
- <&a57_3>;
- };
-
- pmu_a53 {
- compatible = "arm,cortex-a53-pmu";
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a53_0>,
- <&a53_1>,
- <&a53_2>,
- <&a53_3>;
- };
-
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
cpg: clock-controller@e6150000 {
compatible = "renesas,r8a7795-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
@@ -2331,47 +2319,59 @@
#thermal-sensor-cells = <1>;
status = "okay";
};
+ };
- thermal-zones {
- sensor_thermal1: sensor-thermal1 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 0>;
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+ };
- trips {
- sensor1_crit: sensor1-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
+ thermal-zones {
+ sensor_thermal1: sensor-thermal1 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 0>;
+
+ trips {
+ sensor1_crit: sensor1-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
};
};
+ };
- sensor_thermal2: sensor-thermal2 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 1>;
+ sensor_thermal2: sensor-thermal2 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 1>;
- trips {
- sensor2_crit: sensor2-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
+ trips {
+ sensor2_crit: sensor2-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
};
};
+ };
- sensor_thermal3: sensor-thermal3 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 2>;
+ sensor_thermal3: sensor-thermal3 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 2>;
- trips {
- sensor3_crit: sensor3-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
+ trips {
+ sensor3_crit: sensor3-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
};
};
};
--
2.11.0
^ permalink raw reply related
* Re: [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver
From: Linus Walleij @ 2017-11-24 10:28 UTC (permalink / raw)
To: Andre Przywara, Rob Herring
Cc: Maxime Ripard, Chen-Yu Tsai, linux-gpio, Mark Rutland, devicetree,
Linux ARM, Arnd Bergmann, Icenowy Zheng
In-Reply-To: <20171113012523.2328-1-andre.przywara@arm.com>
On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> so far the pinctrl driver for supporting a particular Allwinner SoC requires
> a hardcoded table in the kernel code.
(...)
> This series here moves the data encoded in the table so far into the DT itself,
> removing the need for a hardcoded table in the kernel.
(...)
The DT maintainers have been pretty clear on that they don't like
using the the DT as a generic fit-all information dump. They
prefer to look up hardware data from per-soc compatible strings.
I have been sceptic about it too, on the grounds that I think it
make configuration and multiplatform kernels easy, while making
debugging and reading code+device tree hard, also affecting
maintenance cost.
I'd like to have Maxime's buy-in before we progress and also some
discussion on these themes in general.
> The approach taken here is to parse the DT and generate the table with
> the help of additional properties, then hand this table over to the existing
> driver. This is covered by three basic extensions to the DT binding:
I adressed this in the bindings patch.
> The benefit of this series is two-fold:
> - Future SoCs don't need an in-kernel table anymore. They can describe
> everything in the DT,
It can be debated whether that is really a good thing or actually
a bad thing for the reasons stated above.
Also an additional bad thing is inconsistency between different
SoCs.
What we have in the kernel for all-DT is pinctrl-single.c.
This exists for the case where there is exactly one register per
pin and all you have is strange macro files from the ASIC people
that noone understands. OMAP and HiSilicon is using this.
It's a compromise, I'm not super-happy with that driver at all times
but it is for a very strongly specified case.
Would it be possible for you guys to simply use/embrace/extend
pinctrl-single.c if you want to go this route?
Any higher order of complexity than "one register per pin" I think
is better handled by open coding it than trying to push things into
the device tree, because of readability, debuggability and maintenance
issues.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Linus Walleij @ 2017-11-24 10:19 UTC (permalink / raw)
To: Andre Przywara, thierry.reding@gmail.com
Cc: Maxime Ripard, Chen-Yu Tsai, linux-gpio, Rob Herring,
Mark Rutland, devicetree, Linux ARM, Arnd Bergmann, Icenowy Zheng
In-Reply-To: <20171113012523.2328-2-andre.przywara@arm.com>
On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> So far all the Allwinner pinctrl drivers provided a table in the
> kernel to describe all the pins and the link between the pinctrl functions
> names (strings) and their respective mux values (register values).
>
> Extend the binding to put those mappings in the DT, so that any SoC can
> describe its pinctrl and GPIO data fully there instead of relying on
> tables.
> This uses a generic compatible name, to be prepended with an SoC
> specific name in the node.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
(...)
I definately want feedback from Maxime before I do anything with
this patch series.
> +** Generic pinctrl binding
> +The above binding requires knowledge of the actual mux setting values for
> +each supported SoC in the code parsing the DT (for instance the kernel).
> +The generic binding puts this information in the DT. It uses the
> +"allwinner,sunxi-pinctrl" compatible, in addition to some SoC specific string.
> +It extends the above described binding as follows:
> +Required properties:
> +- allwinner,gpio-pins: An array of 32-bit numbers to denote the number of
> + implemented pins per pin controller port. Non-implemented ports can specify
> + 0 here. There will be as many ports as this array has elements.
I don't understand what this adds that gpio-ranges does not already
provide.
Documentation/devicetree/bindings/gpio/gpio.txt
at the end of the file.
These ranges exist exactly to map pin controller pins in a pin controller
to GPIO lines in a gpiochip.
> +- allwinner,irq-pin-map: Contains a number of IRQ port maps, describing the
> + relationship between interrupt banks and GPIO pins. Each map has six 32-bit
> + members:
> + <[IRQ port] [1st IRQ pin] [GPIO port] [1st GPIO pin] [mux value] [length]>
> + This maps the first [length] IRQ pins starting with [IRQ port]:[1st IRQ pin]
> + to [GPIO port]:[1st GPIO pin], all using [mux value] to select the IRQ
> + functionality.
We have recently added GPIO "bank" awareness into gpiolib
via Thierry Reding's patches, so a gpiochip can use the generic
GPIOLIB_IRQCHIP and specify multiple IRQ parents with a map.
Please see if you can use this instead.
If any of this should be expressed in the DT bindings it should
be genericized and not use any "allwinner,*" prefixes, and it
should preferably just be hard-coded in the driver and switched
in from the compatible string IMO.
> +Optional properties:
> +- allwinner,port-base: The number of GPIO ports to skip at the beginning.
> +- allwinner,irq-bank-base: The number of IRQ banks to skip at the beginning.
I don't understand this. It looks hacky. Can you elaborate why this
is needed?
> +- allwinner,irq-read-needs-mux: Specifies that reading the line level of
> + a pin configured as an IRQ pin is not possible. A driver needs to switch
> + to the GPIO-in function to be able to read the level.
I guess it is a bool flag?
> +Required properties for subnodes:
> +- pinmux: An array of mux values to write into the respective MMIO register
> + bits for this pin when selecting the function. If this array has less
> + elements than pins, the *last* value will be used for all pins beyond that.
> + This allows to use a single element for the (likely) case all pins use the
> + same mux value.
This is a standard bindings so I don't have much against it. But I
need Maxime's input here, I think we should keep Allwinner consistent
across SoCs.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 1/2] gpio: gpiolib: Generalise state persistence beyond sleep
From: Linus Walleij @ 2017-11-24 9:50 UTC (permalink / raw)
To: Andrew Jeffery
Cc: linux-gpio, Rob Herring, Mark Rutland, Frank Rowand, Joel Stanley,
Charles Keepax, Laxman Dewangan, Ryan Chen,
linux-kernel@vger.kernel.org, devicetree, OpenBMC Maillist,
linux-aspeed
In-Reply-To: <20171101040457.1200-2-andrew@aj.id.au>
On Wed, Nov 1, 2017 at 5:04 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> General support for state persistence is added to gpiolib with the
> introduction of a new pinconf parameter to propagate the request to
> hardware. The existing persistence support for sleep is adapted to
> include hardware support if the GPIO driver provides it. Persistence
> continues to be enabled by default; in-kernel consumers can opt out, but
> userspace (currently) does not have a choice.
>
> The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
> renamed, dropping the SLEEP prefix to reflect that the concept is no
> longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE
> could initially be misinterpreted, so I've further changed the symbols
> to *_TRANSITORY and *_PERSISTENT to address this.
>
> The sysfs interface is modified only to keep consistency with the
> chardev interface in enforcing persistence for userspace exports.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
This does not apply to the Torvalds master HEAD anymore
so please:
- Collect ACKs
- Rebase on Torvalds tree or v4.15-rc1 when it's out
- Resend
The functionality per se looks very nice :) so I want to apply this
ASAP.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFCv2 PATCH 10/36] vfio: Add support for Shared Virtual Memory
From: Bob Liu @ 2017-11-24 8:23 UTC (permalink / raw)
To: Jean-Philippe Brucker, linux-arm-kernel, linux-pci, linux-acpi,
devicetree, iommu
Cc: mark.rutland, xieyisheng1, gabriele.paoloni, catalin.marinas,
will.deacon, okaya, yi.l.liu, lorenzo.pieralisi, ashok.raj, tn,
joro, rfranz, lenb, jacob.jun.pan, alex.williamson, robh+dt,
thunder.leizhen, bhelgaas, dwmw2, rjw, robdclark, hanjun.guo,
sudeep.holla, robin.murphy, nwatters
In-Reply-To: <20171006133203.22803-11-jean-philippe.brucker@arm.com>
On 2017/10/6 21:31, Jean-Philippe Brucker wrote:
> Add two new ioctl for VFIO containers. VFIO_DEVICE_BIND_PROCESS creates a
> bond between a container and a process address space, identified by a
> device-specific ID named PASID. This allows the device to target DMA
> transactions at the process virtual addresses without a need for mapping
> and unmapping buffers explicitly in the IOMMU. The process page tables are
> shared with the IOMMU, and mechanisms such as PCI ATS/PRI may be used to
> handle faults. VFIO_DEVICE_UNBIND_PROCESS removed a bond identified by a
> PASID.
>
How about hide bind/unbind into ioctl(VFIO_SET_IOMMU)?
e.g always bind to current process in SET_IOMMU.
Not sure about the real use case.
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
> drivers/vfio/vfio_iommu_type1.c | 243 +++++++++++++++++++++++++++++++++++++++-
> include/uapi/linux/vfio.h | 69 ++++++++++++
> 2 files changed, 311 insertions(+), 1 deletion(-)
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: Hi3660: Fix state id for 'CPU_NAP' state
From: Leo Yan @ 2017-11-24 6:56 UTC (permalink / raw)
To: Sudeep Holla
Cc: Wei Xu, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Daniel Lezcano,
Vincent Guittot
In-Reply-To: <17639ecc-8ff8-e118-f6e1-51e2cfe4342b-5wv7dgnIgG8@public.gmane.org>
Hi Sudeep,
On Thu, Nov 23, 2017 at 02:03:51PM +0000, Sudeep Holla wrote:
> Hi Daniel,
>
> Thanks a lot for pointing me to this and having some useful discussion
> in private. That helped to dig a bit further on this.
>
> On 23/11/17 05:40, Leo Yan wrote:
> > Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
> > idle state. From ftrace log we can observe CA73 CPUs can be easily waken
> > up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle anything
> > and sleep again; so there have tons of trace events for CA73 CPUs
> > entering and exiting idle state.
> >
> > On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
> > set its psci parameter as '0x0000001' and from this parameter it can
> > calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
> > takes 1 as a invalid value for state id, so the CPU cannot enter idle
> > state and directly bail out to kernel.
> >
> > This commit changes psci parameter to '0x00000000' for state id = 0;
> > this id is accepted by ARM trusted firmware and finally CPU can stay
> > properly in 'CPU_NAP' state.
> >
>
> I would like to conditionally NACK this patch. If we can't update the
> ARM TF at all then, I will agree with this change reluctantly.
Thanks for reviewing. Just like Daniel said, we need to figure out the
right method for this. So suggestions are very welcome!
> This looks like an artifact of copy paste in ARM TF port for this
> platform. If you look as PSCI specification, CPU suspend parameter has
> some recommendations and it's good to follow then unless you have strong
> reasons not to.
>
> As Daniel pointed to me, this patch is required to satisfy TF
> particularly [1]. Now that looks like copy pasted from Juno or FVP port
> and if you look deeper, it's clearly under !ARM_RECOM_STATE_ID_ENC [2]
> which was not copied IIUC :).
Thanks for sharing pointers. It's shame that the copying is not
correct for Hikey960 :)
Come back to recommended state id, I reviewed Juno board defintion and
I found it's not align with PSCI spec defintion, in ARM-TF Juno code
defines state as below [1]:
#define ARM_LOCAL_STATE_RUN 0
#define ARM_LOCAL_STATE_RET 1
#define ARM_LOCAL_STATE_OFF 2
In PSCI spec chapter "6.5 Recommended StateID Encoding" recommends power
state id as below:
0: Run
1: Standby
2: Retention
3: Powerdown
So could you confirm on Hikey960 we should follow PSCI definition for
state id definition?
> Juno's implementation is legacy as these recommendations were added
> later in the specification while Juno is 3 year old platform now.
>
> Though strictly speaking it's not violation of the PSCI specification,
> but I would rather get this fixed not before it's too late and copied to
> the next generation of platforms. Since the firmware can be easily
> upgraded that shouldn't be that difficult.
If completely compliant with PSCI recommended state id, we need change
both for ARM-TF and kernel for this. In ARM-TF, I have sent PR [2].
For the kernel patch, we should change state id as below. Please let me
know if you have suggestion for this.
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 12544c3..812437a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -179,7 +179,7 @@
CPU_NAP: cpu-nap {
compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x0000001>;
+ arm,psci-suspend-param = <0x0000002>;
entry-latency-us = <7>;
exit-latency-us = <2>;
min-residency-us = <15>;
@@ -188,7 +188,7 @@
CPU_SLEEP: cpu-sleep {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x0010000>;
+ arm,psci-suspend-param = <0x0010003>;
entry-latency-us = <40>;
exit-latency-us = <70>;
min-residency-us = <3000>;
@@ -197,7 +197,7 @@
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x1010000>;
+ arm,psci-suspend-param = <0x1010033>;
entry-latency-us = <500>;
exit-latency-us = <5000>;
min-residency-us = <20000>;
@@ -206,7 +206,7 @@
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
- arm,psci-suspend-param = <0x1010000>;
+ arm,psci-suspend-param = <0x1010033>;
entry-latency-us = <1000>;
exit-latency-us = <5000>;
min-residency-us = <20000>;
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/include/plat/arm/common/arm_def.h#L43
[2] https://github.com/ARM-software/arm-trusted-firmware/pull/1171/commits/13d30c1c33609eb6cffadd50954e4301d2cab909
Thanks,
Leo Yan
--
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 2/3] libnvdimm: Add a device-tree interface
From: Michael Ellerman @ 2017-11-24 6:36 UTC (permalink / raw)
To: Rob Herring, Oliver O'Halloran
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw
In-Reply-To: <20171116142840.er7st25ll3o6jr7s@rob-hp-laptop>
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> On Thu, Nov 16, 2017 at 04:51:30AM +1100, Oliver O'Halloran wrote:
...
>> diff --git a/drivers/nvdimm/of_nvdimm.c b/drivers/nvdimm/of_nvdimm.c
>> new file mode 100644
>> index 000000000000..765cbbae8bcb
>> --- /dev/null
>> +++ b/drivers/nvdimm/of_nvdimm.c
>> @@ -0,0 +1,202 @@
>> +/*
>> + * Copyright 2017, IBM Corporation
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, you can access it online at
>> + * http://www.gnu.org/licenses/gpl-2.0.html.
>
> This can be SPDX tag.
Specifically:
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2017, IBM Corporation
*/
...
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 00/11] Rockchip ISP1 Driver
From: Jacob Chen @ 2017-11-24 6:15 UTC (permalink / raw)
To: open list:ARM/Rockchip SoC...
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Mauro Carvalho Chehab, Linux Media Mailing List, Sakari Ailus,
Hans Verkuil, Tomasz Figa, Shunqian Zheng, Laurent Pinchart,
钟以崇, Eddie Cai, Jeffy Chen, Allon Huang,
devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stuebner,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Jacob Chen
In-Reply-To: <20171124023706.5702-1-jacob-chen-fyOeoxGR3m/QT0dZR+AlfA@public.gmane.org>
HI all,
2017-11-24 10:36 GMT+08:00 Jacob Chen <jacob-chen-fyOeoxGR3m/QT0dZR+AlfA@public.gmane.org>:
> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 SoC.
>
> Kernel Branch:
> https://github.com/wzyy2/linux/tree/rkisp1/drivers/media/platform/rockchip/isp1
>
> Below are some infomations about driver/hardware:
>
> Rockchip ISP1 have many Hardware Blocks(simplied):
>
> MIPI --> ISP --> DCrop(Mainpath) --> RSZ(Mainpath) --> DMA(Mainpath)
> DMA-Input --> --> DCrop(Selfpath) --> RSZ(Selfpath) --> DMA(Selfpath);)
>
> (Acutally the TRM(rk3288, isp) could be found online...... which contains a more detailed block diagrams ;-P)
>
> The funcitons of each hardware block:
>
> Mainpath : up to 4k resolution, support raw/yuv format
> Selfpath : up tp 1080p, support rotate, support rgb/yuv format
> RSZ: scaling
> DCrop: crop
> ISP: 3A, Color processing, Crop
> MIPI: MIPI Camera interface
>
> Media pipelines:
>
> Mainpath, Selfpath <-- ISP subdev <-- MIPI <-- Sensor
> 3A stats <-- <-- 3A parms
>
> Code struct:
>
> capture.c : Mainpath, Selfpath, RSZ, DCROP : capture device.
> rkisp1.c : ISP : v4l2 sub-device.
> isp_params.c : 3A parms : output device.
> isp_stats.c : 3A stats : capture device.
> mipi_dphy_sy.c : MIPI : sperated v4l2 sub-device.
>
> Usage:
> ChromiumOS:
> use below v4l2-ctl command to capture frames.
>
> v4l2-ctl --verbose -d /dev/video4 --stream-mmap=2
> --stream-to=/tmp/stream.out --stream-count=60 --stream-poll
>
> use below command to playback the video on your PC.
>
> mplayer /tmp/stream.out -loop 0 --demuxer=rawvideo
> --rawvideo=w=800:h=600:size=$((800*600*2)):format=yuy2
> or
> mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
> w=800:h=600:size=$((800*600*2)):format=yuy2
>
> Linux:
> use rkcamsrc gstreamer plugin(just a modified v4l2src) to preview.
>
> gst-launch-1.0 rkcamsrc device=/dev/video0 io-mode=4 disable-3A=true
> videoconvert ! video/x-raw,format=NV12,width=640,height=480 ! kmssink
>
> Jacob Chen (7):
> media: rkisp1: add rockchip isp1 driver
> media: rkisp1: add Rockchip MIPI Synopsys DPHY driver
> dt-bindings: Document the Rockchip ISP1 bindings
> dt-bindings: Document the Rockchip MIPI RX D-PHY bindings
> ARM: dts: rockchip: add isp node for rk3288
> ARM: dts: rockchip: add rx0 mipi-phy for rk3288
> MAINTAINERS: add entry for Rockchip ISP1 driver
>
> Jeffy Chen (1):
> media: rkisp1: Add user space ABI definitions
>
> Shunqian Zheng (3):
> media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format
> arm64: dts: rockchip: add isp0 node for rk3399
> arm64: dts: rockchip: add rx0 mipi-phy for rk3399
>
> .../devicetree/bindings/media/rockchip-isp1.txt | 61 +
> .../bindings/media/rockchip-mipi-dphy.txt | 77 +
> MAINTAINERS | 10 +
> arch/arm/boot/dts/rk3288.dtsi | 24 +
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 26 +
> drivers/media/platform/Kconfig | 10 +
> drivers/media/platform/Makefile | 1 +
> drivers/media/platform/rockchip/isp1/Makefile | 8 +
> drivers/media/platform/rockchip/isp1/capture.c | 1691 ++++++++++++++++++++
> drivers/media/platform/rockchip/isp1/capture.h | 46 +
> drivers/media/platform/rockchip/isp1/common.h | 330 ++++
> drivers/media/platform/rockchip/isp1/dev.c | 632 ++++++++
> drivers/media/platform/rockchip/isp1/isp_params.c | 1556 ++++++++++++++++++
> drivers/media/platform/rockchip/isp1/isp_params.h | 81 +
> drivers/media/platform/rockchip/isp1/isp_stats.c | 537 +++++++
> drivers/media/platform/rockchip/isp1/isp_stats.h | 81 +
> .../media/platform/rockchip/isp1/mipi_dphy_sy.c | 805 ++++++++++
> drivers/media/platform/rockchip/isp1/regs.c | 251 +++
> drivers/media/platform/rockchip/isp1/regs.h | 1578 ++++++++++++++++++
> drivers/media/platform/rockchip/isp1/rkisp1.c | 1230 ++++++++++++++
> drivers/media/platform/rockchip/isp1/rkisp1.h | 130 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> include/uapi/linux/rkisp1-config.h | 554 +++++++
> include/uapi/linux/videodev2.h | 4 +
> 24 files changed, 9725 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-isp1.txt
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> create mode 100644 drivers/media/platform/rockchip/isp1/Makefile
> create mode 100644 drivers/media/platform/rockchip/isp1/capture.c
> create mode 100644 drivers/media/platform/rockchip/isp1/capture.h
> create mode 100644 drivers/media/platform/rockchip/isp1/common.h
> create mode 100644 drivers/media/platform/rockchip/isp1/dev.c
> create mode 100644 drivers/media/platform/rockchip/isp1/isp_params.c
> create mode 100644 drivers/media/platform/rockchip/isp1/isp_params.h
> create mode 100644 drivers/media/platform/rockchip/isp1/isp_stats.c
> create mode 100644 drivers/media/platform/rockchip/isp1/isp_stats.h
> create mode 100644 drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
> create mode 100644 drivers/media/platform/rockchip/isp1/regs.c
> create mode 100644 drivers/media/platform/rockchip/isp1/regs.h
> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.c
> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.h
> create mode 100644 include/uapi/linux/rkisp1-config.h
>
> --
> 2.15.0
>
Sorry, i forget to add a changelog.
changes in V2:
mipi-phy:
- use async probing
- make it be a child device of the GRF
isp:
- add dummy buffer
- change the way to get bus configuration, which make it possible to
add parallel sensor support in the future(without mipi-phy driver).
I resend it for now because i think v2 patch looks more clearly than
the old one,
the v1 patch could just be superseded.
--
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 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform
From: Baolin Wang @ 2017-11-24 5:37 UTC (permalink / raw)
To: daniel.lezcano, tglx, robh+dt, mark.rutland
Cc: devicetree, linux-kernel, broonie, baolin.wang, baolin.wang
In-Reply-To: <2aaad500b5faf51c55fc6f0ad361d9078a521db8.1511501514.git.baolin.wang@spreadtrum.com>
The Spreadtrum SC9860 platform will use the architected timers as local
clock events, but we also need a broadcast timer device to wakeup the
cpus when the cpus are in sleep mode.
Thus this patch registers the timer0 to be a broadcast timer supporting
periodic and oneshot events.
Signed-off-by: Baolin Wang <baolin.wang@spreadtrum.com>
---
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/sprd-timer.c | 213 ++++++++++++++++++++++++++++++++++++++
3 files changed, 222 insertions(+)
create mode 100644 drivers/clocksource/sprd-timer.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cc60620..aa05132 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -467,6 +467,14 @@ config MTK_TIMER
help
Support for Mediatek timer driver.
+config SPRD_TIMER
+ bool "Spreadtrum timer driver"
+ depends on GENERIC_CLOCKEVENTS
+ depends on ARCH_SPRD || COMPILE_TEST
+ select TIMER_OF
+ help
+ Enables the support for the Spreadtrum timer driver.
+
config SYS_SUPPORTS_SH_MTU2
bool
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dbc1ad1..c657d3d 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_CLKSRC_TI_32K) += timer-ti-32k.o
obj-$(CONFIG_CLKSRC_NPS) += timer-nps.o
obj-$(CONFIG_OXNAS_RPS_TIMER) += timer-oxnas-rps.o
obj-$(CONFIG_OWL_TIMER) += owl-timer.o
+obj-$(CONFIG_SPRD_TIMER) += sprd-timer.o
obj-$(CONFIG_ARC_TIMERS) += arc_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
diff --git a/drivers/clocksource/sprd-timer.c b/drivers/clocksource/sprd-timer.c
new file mode 100644
index 0000000..6fec0c5
--- /dev/null
+++ b/drivers/clocksource/sprd-timer.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (C) 2017 Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#define TIMER_NAME "sprd_timer"
+
+#define TIMER_LOAD_LO 0x0
+#define TIMER_LOAD_HI 0x4
+#define TIMER_VALUE_LO 0x8
+#define TIMER_VALUE_HI 0xc
+
+#define TIMER_CTL 0x10
+#define TIMER_CTL_PERIOD_MODE BIT(0)
+#define TIMER_CTL_ENABLE BIT(1)
+#define TIMER_CTL_64BIT_WIDTH BIT(16)
+
+#define TIMER_INT 0x14
+#define TIMER_INT_EN BIT(0)
+#define TIMER_INT_RAW_STS BIT(1)
+#define TIMER_INT_MASK_STS BIT(2)
+#define TIMER_INT_CLR BIT(3)
+
+#define TIMER_VALUE_SHDW_LO 0x18
+#define TIMER_VALUE_SHDW_HI 0x1c
+
+#define TIMER_VALUE_LO_MASK GENMASK(31, 0)
+#define TIMER_VALUE_HI_SHIFT 32
+
+struct sprd_timer_device {
+ struct clock_event_device ce;
+ void __iomem *base;
+ u32 freq;
+ int irq;
+};
+
+static inline struct sprd_timer_device *
+to_sprd_timer(struct clock_event_device *c)
+{
+ return container_of(c, struct sprd_timer_device, ce);
+}
+
+static void sprd_timer_enable(struct sprd_timer_device *timer, u32 flag)
+{
+ u32 val = readl_relaxed(timer->base + TIMER_CTL);
+
+ val |= TIMER_CTL_ENABLE;
+ if (flag & TIMER_CTL_64BIT_WIDTH)
+ val |= TIMER_CTL_64BIT_WIDTH;
+ else
+ val &= ~TIMER_CTL_64BIT_WIDTH;
+
+ if (flag & TIMER_CTL_PERIOD_MODE)
+ val |= TIMER_CTL_PERIOD_MODE;
+ else
+ val &= ~TIMER_CTL_PERIOD_MODE;
+
+ writel_relaxed(val, timer->base + TIMER_CTL);
+}
+
+static void sprd_timer_disable(struct sprd_timer_device *timer)
+{
+ u32 val = readl_relaxed(timer->base + TIMER_CTL);
+
+ val &= ~TIMER_CTL_ENABLE;
+ writel_relaxed(val, timer->base + TIMER_CTL);
+}
+
+static void sprd_timer_update_counter(struct sprd_timer_device *timer,
+ unsigned long cycles)
+{
+ writel_relaxed(cycles & TIMER_VALUE_LO_MASK,
+ timer->base + TIMER_LOAD_LO);
+ writel_relaxed(cycles >> TIMER_VALUE_HI_SHIFT,
+ timer->base + TIMER_LOAD_HI);
+}
+
+static void sprd_timer_enable_interrupt(struct sprd_timer_device *timer)
+{
+ writel_relaxed(TIMER_INT_EN, timer->base + TIMER_INT);
+}
+
+static void sprd_timer_clear_interrupt(struct sprd_timer_device *timer)
+{
+ u32 val = readl_relaxed(timer->base + TIMER_INT);
+
+ val |= TIMER_INT_CLR;
+ writel_relaxed(val, timer->base + TIMER_INT);
+}
+
+static int sprd_timer_set_next_event(unsigned long cycles,
+ struct clock_event_device *ce)
+{
+ struct sprd_timer_device *timer = to_sprd_timer(ce);
+
+ sprd_timer_disable(timer);
+ sprd_timer_update_counter(timer, cycles);
+ sprd_timer_enable(timer, TIMER_CTL_64BIT_WIDTH);
+
+ return 0;
+}
+
+static int sprd_timer_set_periodic(struct clock_event_device *ce)
+{
+ struct sprd_timer_device *timer = to_sprd_timer(ce);
+ unsigned long cycles = DIV_ROUND_UP(timer->freq, HZ);
+
+ sprd_timer_disable(timer);
+ sprd_timer_update_counter(timer, cycles);
+ sprd_timer_enable(timer, TIMER_CTL_64BIT_WIDTH | TIMER_CTL_PERIOD_MODE);
+
+ return 0;
+}
+
+static int sprd_timer_shutdown(struct clock_event_device *ce)
+{
+ struct sprd_timer_device *timer = to_sprd_timer(ce);
+
+ sprd_timer_disable(timer);
+ return 0;
+}
+
+static irqreturn_t sprd_timer_interrupt(int irq, void *dev_id)
+{
+ struct sprd_timer_device *timer = dev_id;
+
+ sprd_timer_clear_interrupt(timer);
+
+ if (clockevent_state_oneshot(&timer->ce))
+ sprd_timer_disable(timer);
+
+ timer->ce.event_handler(&timer->ce);
+ return IRQ_HANDLED;
+}
+
+static void __init sprd_timer_clkevt_init(struct sprd_timer_device *timer)
+{
+ timer->ce.features = CLOCK_EVT_FEAT_DYNIRQ | CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT;
+ timer->ce.set_next_event = sprd_timer_set_next_event;
+ timer->ce.set_state_periodic = sprd_timer_set_periodic;
+ timer->ce.set_state_shutdown = sprd_timer_shutdown;
+ timer->ce.name = TIMER_NAME;
+ timer->ce.rating = 300;
+ timer->ce.irq = timer->irq;
+ timer->ce.cpumask = cpu_possible_mask;
+
+ sprd_timer_enable_interrupt(timer);
+ clockevents_config_and_register(&timer->ce, timer->freq, 1, UINT_MAX);
+}
+
+static int __init sprd_timer_init(struct device_node *np)
+{
+ struct sprd_timer_device *timer;
+ int ret;
+
+ timer = kzalloc(sizeof(*timer), GFP_KERNEL);
+ if (!timer)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np, "clock-frequency", &timer->freq);
+ if (ret) {
+ pr_err("failed to get clock frequency\n");
+ goto err_freq;
+ }
+
+ timer->base = of_iomap(np, 0);
+ if (!timer->base) {
+ pr_err("%s: unable to map resource\n", np->name);
+ ret = -ENXIO;
+ goto err_freq;
+ }
+
+ timer->irq = irq_of_parse_and_map(np, 0);
+ if (timer->irq < 0) {
+ pr_crit("%s: unable to parse timer irq\n", np->name);
+ ret = timer->irq;
+ goto err_map_irq;
+ }
+
+ ret = request_irq(timer->irq, sprd_timer_interrupt, IRQF_TIMER,
+ TIMER_NAME, timer);
+ if (ret) {
+ pr_err("failed to setup irq %d\n", timer->irq);
+ goto err_request_irq;
+ }
+
+ sprd_timer_clkevt_init(timer);
+
+ return 0;
+
+err_request_irq:
+ irq_dispose_mapping(timer->irq);
+err_map_irq:
+ iounmap(timer->base);
+err_freq:
+ kfree(timer);
+
+ return ret;
+}
+
+TIMER_OF_DECLARE(sc9860_timer, "sprd,sc9860-timer", sprd_timer_init);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: clocksource: Add Spreadtrum SC9860 timer
From: Baolin Wang @ 2017-11-24 5:37 UTC (permalink / raw)
To: daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
broonie-DgEjT+Ai2ygdnm+yROfE0A,
baolin.wang-QSEj5FYQhm4dnm+yROfE0A,
baolin.wang-lxIno14LUO0EEoCn2XhGlw
This patch adds documentation of device tree bindings for the timers
found on Spreadtrum SC9860 platform.
Signed-off-by: Baolin Wang <baolin.wang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
---
.../bindings/timer/spreadtrum,sprd-timer.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt b/Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt
new file mode 100644
index 0000000..f9d5eb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt
@@ -0,0 +1,20 @@
+Spreadtrum timers
+
+The Spreadtrum SC9860 platform provides 3 general-purpose timers.
+These timers can support 32bit or 64bit counter, as well as supporting
+period mode or one-shot mode, and they are can be wakeup source
+during deep sleep.
+
+Required properties:
+- compatible: should be "sprd,sc9860-timer" for SC9860 platform.
+- reg: The register address of the timer device.
+- interrupts: Should contain the interrupt for the timer device.
+- clock-frequency: The frequency of the clock that drives the counter, in Hz.
+
+Example:
+ timer@40050000 {
+ compatible = "sprd,sc9860-timer";
+ reg = <0 0x40050000 0 0x20>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <32768>;
+ };
--
1.7.9.5
--
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
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