* [PATCH] i2c: uniphier[-f]: fix bool logic calculation
From: Masahiro Yamada @ 2016-12-20 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476851911-21729-1-git-send-email-yamada.masahiro@socionext.com>
Hi.
I have not got any comment, but does this seem
a right thing to do?
2016-10-19 13:38 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> This code is working, but it should not depend on how "bool" is
> typedef'ed, or the bit position of I2C_M_RD.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/i2c/busses/i2c-uniphier-f.c | 2 +-
> drivers/i2c/busses/i2c-uniphier.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
> index db9105e..b54448e 100644
> --- a/drivers/i2c/busses/i2c-uniphier-f.c
> +++ b/drivers/i2c/busses/i2c-uniphier-f.c
> @@ -309,7 +309,7 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
> struct i2c_msg *msg, bool stop)
> {
> struct uniphier_fi2c_priv *priv = i2c_get_adapdata(adap);
> - bool is_read = msg->flags & I2C_M_RD;
> + bool is_read = !!(msg->flags & I2C_M_RD);
> unsigned long time_left;
>
> dev_dbg(&adap->dev, "%s: addr=0x%02x, len=%d, stop=%d\n",
> diff --git a/drivers/i2c/busses/i2c-uniphier.c b/drivers/i2c/busses/i2c-uniphier.c
> index 56e92af..cc80bb2 100644
> --- a/drivers/i2c/busses/i2c-uniphier.c
> +++ b/drivers/i2c/busses/i2c-uniphier.c
> @@ -177,7 +177,7 @@ static int uniphier_i2c_stop(struct i2c_adapter *adap)
> static int uniphier_i2c_master_xfer_one(struct i2c_adapter *adap,
> struct i2c_msg *msg, bool stop)
> {
> - bool is_read = msg->flags & I2C_M_RD;
> + bool is_read = !!(msg->flags & I2C_M_RD);
> bool recovery = false;
> int ret;
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RFC PATCH net-next v4 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
From: Rafal Ozieblo @ 2016-12-20 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720175-12703-2-git-send-email-andrei.pistirica@microchip.com>
From: Andrei Pistirica [mailto:andrei.pistirica at microchip.com]
Sent: 14 grudnia 2016 13:56
> This patch does the following:
> - Enable HW time stamp for the following platforms: SAMA5D2, SAMA5D3 and
> SAMA5D4.
> - HW time stamp capabilities are advertised via ethtool and macb ioctl is
> updated accordingly.
> - HW time stamp on the PTP Ethernet packets are received using the
> SO_TIMESTAMPING API. Where timers are obtained from the PTP event/peer
> registers.
>
> Note: Patch on net-next, on December 7th.
>
> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
> ---
> Patch history:
>
> Version 1:
> Integration with SAMA5D2 only. This feature wasn't tested on any other platform that might use cadence/gem.
>
> Patch is not completely ported to the very latest version of net-next, and it will be after review.
>
> Version 2 modifications:
> - add PTP caps for SAMA5D2/3/4 platforms
> - and cosmetic changes
>
> Version 3 modifications:
> - add support for sama5D2/3/4 platforms using GEM-PTP interface.
>
> Version 4 modifications:
> - time stamp only PTP_V2 events
> - maximum adjustment value is set based on Richard's input
>
> Note: Patch on net-next, on December 14th.
>
> drivers/net/ethernet/cadence/macb.c | 168 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 163 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 538544a..8d5c976 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -714,6 +714,8 @@ static void macb_tx_interrupt(struct macb_queue *queue)
>
> /* First, update TX stats if needed */
> if (skb) {
> + gem_ptp_do_txstamp(bp, skb);
> +
I think, you can not do it in that way.
It will hold two locks. If you enable appropriate option in kernel (as far as I
remember CONFIG_DEBUG_SPINLOCK) you will get a warning here.
Please look at following call-stack:
1. macb_interrupt() // spin_lock(&bp->lock) is taken
2. macb_tx_interrupt()
3. macb_handle_txtstamp()
4. skb_tstamp_tx()
5. __skb_tstamp_tx()
6. skb_may_tx_timestamp()
7. read_lock_bh() // second lock is taken
I know that those are different locks and different types. But this could lead
to deadlocks. This is the reason of warning I could see.
And this is the reason why I get timestamp in interrupt routine but pass it to
skb outside interrupt (using circular buffer).
Please, refer to this:
https://lkml.org/lkml/2016/11/18/168
1. macb_tx_interrupt()
2. macb_tx_timestamp_add() and schedule_work(&queue->tx_timestamp_task)
Then, outside interrupt (without holding a lock) :
1. macb_tx_timestamp_flush()
2. macb_tstamp_tx()
3. skb_tstamp_tx()
> netdev_vdbg(bp->dev, "skb %u (data %p) TX complete\n",
> macb_tx_ring_wrap(bp, tail),
> skb->data);
> @@ -878,6 +880,8 @@ static int gem_rx(struct macb *bp, int budget)
> GEM_BFEXT(RX_CSUM, ctrl) & GEM_RX_CSUM_CHECKED_MASK)
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> + gem_ptp_do_rxstamp(bp, skb);
> +
> bp->stats.rx_packets++;
> bp->stats.rx_bytes += skb->len;
>
> @@ -2080,6 +2084,9 @@ static int macb_open(struct net_device *dev)
>
> netif_tx_start_all_queues(dev);
>
> + if (bp->ptp_info)
> + bp->ptp_info->ptp_init(dev);
> +
> return 0;
> }
>
> @@ -2101,6 +2108,9 @@ static int macb_close(struct net_device *dev)
>
> macb_free_consistent(bp);
>
> + if (bp->ptp_info)
> + bp->ptp_info->ptp_remove(dev);
> +
> return 0;
> }
>
> @@ -2374,6 +2384,133 @@ static int macb_set_ringparam(struct net_device *netdev,
> return 0;
> }
>
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> +static unsigned int gem_get_tsu_rate(struct macb *bp) {
> + /* Note: TSU rate is hardwired to PCLK. */
> + return clk_get_rate(bp->pclk);
> +}
Not exactly. There could be separate TSU clock.
In my solution I check tsu_clk in DT before I decide to take pclk.
But it could be change in macb_ptp_info.
> +
> +static s32 gem_get_ptp_max_adj(void)
> +{
> + return 3921508;
> +}
> +
> +static int gem_get_ts_info(struct net_device *dev,
> + struct ethtool_ts_info *info)
> +{
> + struct macb *bp = netdev_priv(dev);
> +
> + ethtool_op_get_ts_info(dev, info);
> + info->so_timestamping =
> + SOF_TIMESTAMPING_TX_SOFTWARE |
> + SOF_TIMESTAMPING_RX_SOFTWARE |
> + SOF_TIMESTAMPING_SOFTWARE |
> + SOF_TIMESTAMPING_TX_HARDWARE |
> + SOF_TIMESTAMPING_RX_HARDWARE |
> + SOF_TIMESTAMPING_RAW_HARDWARE;
> + info->phc_index = -1;
> +
> + if (bp->ptp_clock)
> + info->phc_index = ptp_clock_index(bp->ptp_clock);
> +
> + return 0;
> +}
> +
> +static int gem_set_hwtst(struct net_device *netdev,
> + struct ifreq *ifr, int cmd)
> +{
> + struct hwtstamp_config config;
> + struct macb *priv = netdev_priv(netdev);
> + u32 regval;
> +
> + netdev_vdbg(netdev, "macb_hwtstamp_ioctl\n");
> +
> + if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
> + return -EFAULT;
> +
> + /* reserved for future extensions */
> + if (config.flags)
> + return -EINVAL;
> +
> + switch (config.tx_type) {
> + case HWTSTAMP_TX_OFF:
> + priv->hwts_tx_en = false;
> + break;
> + case HWTSTAMP_TX_ON:
> + priv->hwts_tx_en = true;
> + break;
> + default:
> + return -ERANGE;
> + }
> +
> + switch (config.rx_filter) {
> + case HWTSTAMP_FILTER_NONE:
> + if (priv->hwts_rx_en)
> + priv->hwts_rx_en = false;
> + break;
> + case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
> + config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
> + regval = macb_readl(priv, NCR);
> + macb_writel(priv, NCR, (regval | MACB_BIT(SRTSM)));
> +
> + if (!priv->hwts_rx_en)
> + priv->hwts_rx_en = true;
> + break;
> + default:
> + config.rx_filter = HWTSTAMP_FILTER_NONE;
> + return -ERANGE;
> + }
> +
> + return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
> + -EFAULT : 0;
> +}
> +
> +static int gem_get_hwtst(struct net_device *netdev,
> + struct ifreq *ifr)
> +{
> + struct hwtstamp_config config;
> + struct macb *priv = netdev_priv(netdev);
> +
> + config.flags = 0;
> + config.tx_type = priv->hwts_tx_en ? HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
> + config.rx_filter = (priv->hwts_rx_en ?
> + HWTSTAMP_FILTER_ALL : HWTSTAMP_FILTER_NONE);
> +
> + return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
> + -EFAULT : 0;
> +}
> +
> +static struct macb_ptp_info gem_ptp_info = {
> + .ptp_init = gem_ptp_init,
> + .ptp_remove = gem_ptp_remove,
> + .get_ptp_max_adj = gem_get_ptp_max_adj,
> + .get_tsu_rate = gem_get_tsu_rate,
> + .get_ts_info = gem_get_ts_info,
> + .get_hwtst = gem_get_hwtst,
> + .set_hwtst = gem_set_hwtst,
> +};
> +#endif
> +
> +static int macb_get_ts_info(struct net_device *netdev,
> + struct ethtool_ts_info *info)
> +{
> + struct macb *bp = netdev_priv(netdev);
> +
> + if (bp->ptp_info)
> + return bp->ptp_info->get_ts_info(netdev, info);
> +
> + return ethtool_op_get_ts_info(netdev, info); }
> +
> static const struct ethtool_ops macb_ethtool_ops = {
> .get_regs_len = macb_get_regs_len,
> .get_regs = macb_get_regs,
> @@ -2391,7 +2528,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
> .get_regs_len = macb_get_regs_len,
> .get_regs = macb_get_regs,
> .get_link = ethtool_op_get_link,
> - .get_ts_info = ethtool_op_get_ts_info,
> + .get_ts_info = macb_get_ts_info,
> .get_ethtool_stats = gem_get_ethtool_stats,
> .get_strings = gem_get_ethtool_strings,
> .get_sset_count = gem_get_sset_count,
> @@ -2404,6 +2541,7 @@ static const struct ethtool_ops gem_ethtool_ops = { static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) {
> struct phy_device *phydev = dev->phydev;
> + struct macb *bp = netdev_priv(dev);
>
> if (!netif_running(dev))
> return -EINVAL;
> @@ -2411,7 +2549,20 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> if (!phydev)
> return -ENODEV;
>
> - return phy_mii_ioctl(phydev, rq, cmd);
> + switch (cmd) {
> + case SIOCSHWTSTAMP:
> + if (bp->ptp_info)
> + return bp->ptp_info->set_hwtst(dev, rq, cmd);
> +
> + return -EOPNOTSUPP;
> + case SIOCGHWTSTAMP:
> + if (bp->ptp_info)
> + return bp->ptp_info->get_hwtst(dev, rq);
> +
> + return -EOPNOTSUPP;
> + default:
> + return phy_mii_ioctl(phydev, rq, cmd);
> + }
> }
>
> static int macb_set_features(struct net_device *netdev, @@ -2485,6 +2636,12 @@ static void macb_configure_caps(struct macb *bp,
> dcfg = gem_readl(bp, DCFG2);
> if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF))) == 0)
> bp->caps |= MACB_CAPS_FIFO_MODE;
> +
> + /* iff HWSTAMP is configure and gem has the capability */ #ifdef
> +CONFIG_MACB_USE_HWSTAMP
> + if (gem_has_ptp(bp))
> + bp->ptp_info = &gem_ptp_info;
> +#endif
> }
>
> dev_dbg(&bp->pdev->dev, "Cadence caps 0x%08x\n", bp->caps); @@ -3041,7 +3198,7 @@ static const struct macb_config pc302gem_config = { };
>
> static const struct macb_config sama5d2_config = {
> - .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
> + .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_GEM_HAS_PTP,
There are many IP cores with many configuration. If it is possible, capabilities should be read from IP directly.
And it is possible in that case:
Design Configuration Register 5 (0x290)
bit 8: tsu
There is now PTP hardware support without that bit.
> .dma_burst_length = 16,
> .clk_init = macb_clk_init,
> .init = macb_init,
> @@ -3049,14 +3206,15 @@ static const struct macb_config sama5d2_config = {
>
> static const struct macb_config sama5d3_config = {
> .caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE
> - | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
> + | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII
> + | MACB_CAPS_GEM_HAS_PTP,
> .dma_burst_length = 16,
> .clk_init = macb_clk_init,
> .init = macb_init,
> };
>
> static const struct macb_config sama5d4_config = {
> - .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
> + .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_GEM_HAS_PTP,
> .dma_burst_length = 4,
> .clk_init = macb_clk_init,
> .init = macb_init,
> --
> 2.7.4
In macb_start_xmit() there is also invoked skb_tx_timestamp() for software timestamping.
I think, it should be disabled if you do hardware timestamping.
Best regards,
Rafal Ozieblo | Firmware System Engineer,
www.cadence.com
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Marc Zyngier @ 2016-12-20 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482246864-16399-1-git-send-email-will.deacon@arm.com>
On 20/12/16 15:14, Will Deacon wrote:
> Booting Linux on an ARM fastmodel containing an SMMU emulation results
> in an unexpected I/O page fault from the legacy virtio-blk PCI device:
>
> [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>
> <system hangs failing to read partition table>
>
> This is because the virtio-blk is behind an SMMU, so we have consequently
> swizzled its DMA ops and configured the SMMU to translate accesses. This
> then requires the vring code to use the DMA API to establish translations,
> otherwise all transactions will result in fatal faults and termination.
>
> Given that ARM-based systems only see an SMMU if one is really present
> (the topology is all described by firmware tables such as device-tree or
> IORT), then we can safely use the DMA API for all virtio devices.
>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/virtio/virtio_ring.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index ed9c9eeedfe5..06b91e29d1b7 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -159,6 +159,10 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> if (xen_domain())
> return true;
>
> + /* On ARM-based machines, the DMA ops will do the right thing */
> + if (IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64))
> + return true;
> +
> return false;
> }
>
>
This patch makes my model usable again, so FWIW:
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Will Deacon @ 2016-12-20 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58529799.9060206@codeaurora.org>
On Thu, Dec 15, 2016 at 06:46:09PM +0530, Srinivas Ramana wrote:
> On 12/12/2016 04:12 PM, Will Deacon wrote:
> >On Mon, Dec 12, 2016 at 10:31:52AM +0530, Srinivas Ramana wrote:
> >>On 12/06/2016 05:43 PM, Will Deacon wrote:
> >>>On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote:
> >>>>On 12/02/2016 04:38 PM, Will Deacon wrote:
> >>>>>On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
> >>>>>>Extend the trace_clock to support the arch timer cycle
> >>>>>>counter so that we can get the monotonic cycle count
> >>>>>>in the traces. This will help in correlating the traces with the
> >>>>>>timestamps/events in other subsystems in the soc which share
> >>>>>>this common counter for driving their timers.
> >>>>>
> >>>>>I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
> >>>>>particular, the "perf" trace_clock hangs off sched_clock, which should
> >>>>>be backed by the architected counter anyway. What does the cycle counter in
> >>>>>isolation tell you, given that the frequency isn't architected?
> >>>>>
> >>>>>I think I'm missing something here.
> >>>>>
> >>>>
> >>>>Having cycle counter would help in the cases where we want to correlate the
> >>>>time with other subsystems which are outside cpu subsystem.
> >>>
> >>>Do you have an example of these subsystems? Can they be used to generate
> >>>trace data with mainline?
> >>
> >>Some of the subsystems i can list are Modem(on a mobilephone), GPU or video
> >>subsystem, or a DSP among others.
> >
> >Oh, you're talking about hardware subsystems. That makes this slightly more
> >compelling, but I don't think you want the virtual counter here, since
> >I assume those other subsystems don't take into account CNTVOFF (and I
> >don't really see how they could, it being a per-cpu thing). So, if you
> >want to expose the *physical* counter as a trace clock, I think that's
> >justifiable.
> >
> Yes, I meant HW subsystems. Sorry if I was not clear.
> In ARM64, it seems the access to physical counter is removed with commit
> "clocksource: arch_timer: Fix code to use physical timers when requested".
> Only ARM (32) is allowed to used physical counter in the current timer API.
> It seems only EL2 is supposed to access this. But yes, if there is an
> offset, it seems it would be difficult to get the exact value at EL0.
> However for systems where CNTVOFF is '0', this will work seamless. This
> clock would not be the default anyways and is optional. Local clock would
> continue to be the default for traces.
That still doesn't sound useful to userspace. I think we need to expose
the clock only in the cases where it's useful, so restricting it to the
physical counter is the right thing to do.
> >>>>local_clock or even the perf track_clock uses sched_clock which gets
> >>>>suspended during system suspend. Yes, they are backed up by the
> >>>>architected counter but they ignore the cycles spent in suspend.i
> >>>
> >>>Does mono_raw solve this (also hangs off the architected counter and is
> >>>supported in the vdso)?
> >>
> >>Doesn't seem like. Any of the existing clock sources are designed not show
> >>the jump, when there is a suspend and resume. Even though they run out of
> >>architected counter they just cane give exact correlation with the counter.
> >>Furthermore, during the initial kernel boot, these just run out of jiffies
> >>clock source. They also not account for the time spent in boot loaders.
> >
> >Hmm, there's a thing called CLOCK_BOOTTIME, but I don't think that helps
> >you when CNTVOFF comes into play.
> >
> CLOCK_BOOTTIME includes the time spent in suspend. But this also doesn't
> give exact counter value since power ON. So for the purpose of comparing
> with global counter, this would not help.
>
> >>>>so, when comparing with monotonically increasing cycle counter, other
> >>>>clocks doesn't help. It seems X86 uses the TSC counter to help such cases.
> >>>
> >>>Does this mean we need a way to expose the frequency to userspace, too?
> >>
> >>Not really. The CNTFRQ_EL0 of timer subsystem holds the clock frequency of
> >>system timer and is available to EL0.
> >
> >Experience shows that CNTFRQ_EL0 is often unreliable, and the frequency
> >can be overridden by the device-tree. There are also systems where the
> >counter stops ticking across suspend. Whilst both of these can be considered
> >"broken", I suspect we want runtime buy-in from the arch-timer driver
> >before registering this trace_clock.
>
> Agree. It doesnt seem like architecture mandates initializing this.
> For those systems where tick would stop, if not arch counter, i assume there
> is some counter which falls in 'always ON' domain without which they cant
> keep track of time.
We just need to avoid exposing this trace clock if the frequency was
provided by firmware.
Will
^ permalink raw reply
* [PATCH v6 2/5] lib: implement __arch_bitrev8x4()
From: Joshua Clayton @ 2016-12-20 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219100614.GC4508@arm.com>
Will,
On 12/19/2016 02:06 AM, Will Deacon wrote:
> On Fri, Dec 16, 2016 at 03:17:51PM -0800, Joshua Clayton wrote:
>> Implement faster bitrev8x4() for arm, arm64 and mips, all the platforms
>> with CONFIG_HAVE_ARCH_BITREVERSE.
>> ARM platforms just need a byteswap added to the existing __arch_bitrev32()
>> Amusingly, the mips implementation is exactly the opposite, requiring
>> removal of the byteswap from its __arch_bitrev32()
>>
>> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
>> ---
>> arch/arm/include/asm/bitrev.h | 6 ++++++
>> arch/arm64/include/asm/bitrev.h | 6 ++++++
>> arch/mips/include/asm/bitrev.h | 6 ++++++
>> include/linux/bitrev.h | 1 +
>> 4 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
>> index ec291c3..9482f78 100644
>> --- a/arch/arm/include/asm/bitrev.h
>> +++ b/arch/arm/include/asm/bitrev.h
>> @@ -17,4 +17,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
>> return __arch_bitrev32((u32)x) >> 24;
>> }
>>
>> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
>> +{
>> + __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
>> + return x;
>> +}
>> +
>> #endif
>> diff --git a/arch/arm64/include/asm/bitrev.h b/arch/arm64/include/asm/bitrev.h
>> index a5a0c36..1801078 100644
>> --- a/arch/arm64/include/asm/bitrev.h
>> +++ b/arch/arm64/include/asm/bitrev.h
>> @@ -16,4 +16,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
>> return __arch_bitrev32((u32)x) >> 24;
>> }
>>
>> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
>> +{
>> + __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
> This is broken -- you're operating on 64-bit registers. I only noticed
> because if you write:
Ugh. mea culpa. I squinted at the AARCH64 asm and erroneously
believed it to be the same as arm.
> swab32(bitrev32(x))
>
> then GCC generates:
>
> rbit w0, w0
> rev w0, w0
>
> so perhaps we should just implement the asm-generic version like that
> and not bother with the arch-specific stuff?
>
> Will
You are so right.
That is exactly what I will do.
Thanks,
Joshua
^ permalink raw reply
* [PATCH v3] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: David Daney @ 2016-12-20 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220115630.GD10132@arm.com>
On 12/20/2016 03:56 AM, Will Deacon wrote:
> On Tue, Dec 20, 2016 at 11:52:58AM +0000, Marc Zyngier wrote:
>> On 20/12/16 11:06, Geetha sowjanya wrote:
>>> From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
>>> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
>>> +/*
>>> + * Cavium ThunderX erratum 28168
>>> + *
>>> + * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
>>> + * controller are delivered to the interrupt controller before older
>>> + * PCI-inbound memory stores are committed. Doing a sync on SMMU
>>> + * will make sure all prior data transfers are completed before
>>> + * invoking ISR.
>>> + *
>>> + */
>>> +void dev_smmu_tlb_sync(struct device *dev)
>>> +{
>>> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>>> + struct arm_smmu_device *smmu = fwspec_smmu(fwspec);
>>> +
>>> + if (smmu)
>>> + __arm_smmu_tlb_sync(smmu);
>>> +}
>>> +#endif
>>
>> I'll let Robin and Will comment on this, but it strikes be as rather odd
>> that nothing will happen if the SMMU is in bypass or simply compiled
>> out. So this workaround is at best incomplete.
>
> Agreed. Unless the SMMU is the cause of the issue, relying on it to
> implement the workaround is fragile and unnecessarily introduces a linkage
> between SMMU driver internals and the interrupt handling code.
The SMMU is not the cause of the problem, it is the solution, and as
such is required.
Perhaps we should have a Kconfig "select" for the SMMU driver if
CAVIUM_ERRATUM_28168 is selected.
>
> Not a fan.
In general, I don't think anybody is a big fan of errata and their
workarounds.
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] i2c: uniphier[-f]: fix bool logic calculation
From: Joe Perches @ 2016-12-20 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATrR9dSuuUZR98f=uOZqSGqUBnUNZmrUqUZgubHHE+X4A@mail.gmail.com>
On Wed, 2016-12-21 at 01:20 +0900, Masahiro Yamada wrote:
> Hi.
>
> I have not got any comment, but does this seem
> a right thing to do?
> This code is working, but it should not depend on how "bool" is
> typedef'ed, or the bit position of I2C_M_RD.
<shrug>
I think bool can be guaranteed to be _Bool.
So a change not necessary as the original code
has a c90 guarantee of the same result.
6.3.1.2 Boolean type
1
When any scalar value is converted to _Bool, the result is 0 if the value compares equal
to 0; otherwise, the result is 1.
> 2016-10-19 13:38 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
[]
> > diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
[]
> > @@ -309,7 +309,7 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
> > struct i2c_msg *msg, bool stop)
> > {
> > struct uniphier_fi2c_priv *priv = i2c_get_adapdata(adap);
> > - bool is_read = msg->flags & I2C_M_RD;
> > + bool is_read = !!(msg->flags & I2C_M_RD);
> > unsigned long time_left;
> >
> > dev_dbg(&adap->dev, "%s: addr=0x%02x, len=%d, stop=%d\n",
^ permalink raw reply
* [PATCH net 0/3] Fix integration of eee-broken-modes
From: David Miller @ 2016-12-20 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Mon, 19 Dec 2016 16:05:35 +0100
> The purpose of this series is to fix the integration of the ethernet phy
> property "eee-broken-modes" [0]
>
> The v3 of this series has been merged, missing a fix (error reported by
> kbuild robot) available in the v4 [1]
>
> More importantly, Florian opposed adding a DT property mapping a device
> register this directly [2]. The concern was that the property could be
> abused to implement platform configuration policy. After discussing it,
> I think we agreed that such information about the HW (defect) should appear
> in the platform DT. However, the preferred way is to add a boolean property
> for each EEE broken mode.
>
> [0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet at baylibre.com
> [1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet at baylibre.com
> [2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080 at gmail.com
Series applied, thank you.
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: add a delay after reset xr819 on Orange Pi Zero
From: Maxime Ripard @ 2016-12-20 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220055826.30725-1-icenowy@aosc.xyz>
On Tue, Dec 20, 2016 at 01:58:26PM +0800, Icenowy Zheng wrote:
> XR819 seems to need a delay after its reset line to be deasserted,
> otherwise it may not respond MMC commands correctly, and fail to
> initialize.
>
> Add a 200ms delay in the mmc-pwrseq.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/4f8055a3/attachment.sig>
^ permalink raw reply
* [linux-sunxi][PATCH] ARM: dts: sun6i: Mele I7: Enable internal audio codec
From: Maxime Ripard @ 2016-12-20 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220102344.2519-1-codekipper@gmail.com>
1;4600;0c
On Tue, Dec 20, 2016 at 11:23:44AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> The Mele I7 has an audio jack for the SoC's internal codec.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/65d7c9fc/attachment.sig>
^ permalink raw reply
* [linux-sunxi][PATCH] clk: sunxi-ng: A31: Fix spdif clock register
From: Maxime Ripard @ 2016-12-20 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220104446.22638-1-codekipper@gmail.com>
On Tue, Dec 20, 2016 at 11:44:46AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> As the SPDIF was rarely documented on the earlier Allwinner SoCs
> it was assumed that it had a similar clock register to the one
> described in the H3 User Manual.
>
> However this is not the case and it looks to shares the same setup
> as the I2S clock registers.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/632bbf56/attachment.sig>
^ permalink raw reply
* [linux-sunxi][PATCH 1/3] ARM: dts: sun6i: Add SPDIF TX pin to the A31
From: Maxime Ripard @ 2016-12-20 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220104038.22532-2-codekipper@gmail.com>
On Tue, Dec 20, 2016 at 11:40:36AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> Add the SPDIF TX pin to the A31 dtsi.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/804105e1/attachment.sig>
^ permalink raw reply
* [linux-sunxi][PATCH 2/3] ARM: dts: sun6i: Add the SPDIF block to the A31
From: Maxime Ripard @ 2016-12-20 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEKpxBn4J0sXVx6b0d_v3LivnNS5WENp9DD6fFE9N6u=J=n7ww@mail.gmail.com>
On Tue, Dec 20, 2016 at 03:34:10PM +0100, Code Kipper wrote:
> On 20 December 2016 at 15:07, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Dec 20, 2016 at 11:40:37AM +0100, codekipper at gmail.com wrote:
> >> From: Marcus Cooper <codekipper@gmail.com>
> >>
> >> Add the SPDIF transceiver controller block to the A31 dtsi.
> >>
> >> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> >> ---
> >> arch/arm/boot/dts/sun6i-a31.dtsi | 14 ++++++++++++++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> >> index 7370ba6c9993..559c53efa7e6 100644
> >> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> >> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> >> @@ -613,6 +613,20 @@
> >> reg = <0x01c20ca0 0x20>;
> >> };
> >>
> >> + spdif: spdif at 01c21000 {
> >> + #sound-dai-cells = <0>;
> >> + compatible = "allwinner,sun6i-a31-spdif";
> >> + reg = <0x01c21000 0x400>;
> >> + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> >> + clocks = <&ccu CLK_APB1_SPDIF>, <&ccu CLK_SPDIF>;
> >> + resets = <&ccu RST_APB1_SPDIF>;
> >> + clock-names = "apb", "spdif";
> >> + dmas = <&dma 2>, <&dma 2>;
> >> + dma-names = "rx", "tx";
> >> + spdif-out = "disabled";
> >
> > That property isn't documented anywhere, and doesn't seem to be used
> > in your driver either.
>
> Ooops....do you want me to respin a new patch or will you do your
> magic with 'dd'?
Sorry, it's C-w for me :)
> It fell through the cracks as it was cherry picked from my dev
> branch where I was at one time playing with spdif-in. This has
> pretty much been relegated to the bottom of my todo/finish list.
I fixed and applied.
> > On a separate topic, is the channel inversion bug also found on the
> > A31?
>
> I have seen this and I'm sure that was also on my A31 hardware but
> I've just fired her up and the speaker test worked as expected. I also
> repeated the test on my A10 device and didn't hear the issue.
Ok.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/20d095e5/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] ASoC: sun4i-spdif: remove legacy dapm components
From: Maxime Ripard @ 2016-12-20 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220144914.30945-2-codekipper@gmail.com>
On Tue, Dec 20, 2016 at 03:49:13PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> The dapm components are now handled by the ALSA SoC SPDIF DIT driver
> so can be removed.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/8560510e/attachment.sig>
^ permalink raw reply
* [RFC PATCH] Memory hotplug support for arm64 platform
From: Scott Branden @ 2016-12-20 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481717765-31186-1-git-send-email-m.bielski@virtualopensystems.com>
Hi Maciej,
I have applied that patch ontop of the patches I previously sent out
and tested.
It does recognized the memory in /proc/iomem but I get memory corruption
of the original system RAM soon after. It appears the page allocation
gets corrupted. I will try to dig into it further but if somebody else
could try it out in their system to see what results they get it would help.
Regards,
Scott
On 16-12-14 04:16 AM, Maciej Bielski wrote:
> This patch relates to the work previously announced in [1]. This builds on the
> work by Scott Branden [2] and, henceforth, it needs to be applied on top of
> Scott's patches [2]. Comments are very welcome.
>
> Changes from the original patchset and known issues:
>
> - Compared to Scott's original patchset, this work adds the mapping of
> the new hotplugged pages into the kernel page tables. This is done by
> copying the old swapper_pg_dir over a new page, adding the new mappings,
> and then switching to the newly built pg_dir (see `hotplug_paging` in
> arch/arm64/mmu.c). There might be better ways to to this: suggestions
> are more than welcome.
>
> - The stub function for `arch_remove_memory` has been removed for now; we
> are working in parallel on memory hot remove, and we plan to contribute
> it as a separate patch.
>
> - Corresponding Kconfig flags have been added;
>
> - Note that this patch does not work when NUMA is enabled; in fact,
> the function `memory_add_physaddr_to_nid` does not have an
> implementation when the NUMA flag is on: this function is supposed to
> return the nid the hotplugged memory should be associated with. However
> it is not really clear to us yet what the semantics of this function
> in the context of a NUMA system should be. A quick and dirty fix would
> be to always attach to the first available NUMA node.
>
> - In arch/arm64/mm/init.c `arch_add_memory`, we are doing a hack with the
> nomap memory block flags to satisfy preconditions and postconditions of
> `__add_pages` and postconditions of `arch_add_memory`. Compared to
> memory hotplug implementation for other architectures, the "issue"
> seems to be in the implemenation of `pfn_valid`. Suggestions on how
> to cleanly avoid this hack are welcome.
>
> This patchset can be tested by starting the kernel with the `mem=X` flag, where
> X is less than the total available physical memory and has to be multiple of
> MIN_MEMORY_BLOCK_SIZE. We also tested it on a customised version of QEMU
> capable to emulate physical hotplug on arm64 platform.
>
> To enable the feature the CONFIG_MEMORY_HOTPLUG compilation flag
> needs to be set to true. Then, after memory is physically hotplugged,
> the standard two steps to make it available (as also documented in
> Documentation/memory-hotplug.txt) are:
>
> (1) Notify memory hot-add
> echo '0xYY000000' > /sys/devices/system/memory/probe
>
> where 0xYY000000 is the first physical address of the new memory section.
>
> (2) Online new memory block(s)
> echo online > /sys/devices/system/memory/memoryXXX/state
>
> where XXX corresponds to the ids of newly added blocks.
>
> Onlining can optionally be automatic at hot-add notification by enabling
> the global flag:
> echo online > /sys/devices/system/memory/auto_online_blocks
> or by setting the corresponding config flag in the kernel build.
>
> Again, any comment is highly appreciated.
>
> [1] https://lkml.org/lkml/2016/11/17/49
> [2] https://lkml.org/lkml/2016/12/1/811
>
> Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
> Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
> ---
> arch/arm64/Kconfig | 4 +--
> arch/arm64/include/asm/mmu.h | 3 +++
> arch/arm64/mm/init.c | 58 +++++++++++++++++++++++++++++++-------------
> arch/arm64/mm/mmu.c | 24 ++++++++++++++++++
> include/linux/memblock.h | 1 +
> mm/memblock.c | 10 ++++++++
> 6 files changed, 80 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 2482fdd..bd8ddf2 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -577,9 +577,7 @@ config HOTPLUG_CPU
> can be controlled through /sys/devices/system/cpu.
>
> config ARCH_ENABLE_MEMORY_HOTPLUG
> - def_bool y
> -
> -config ARCH_ENABLE_MEMORY_HOTREMOVE
> + depends on !NUMA
> def_bool y
>
> # Common NUMA Features
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 8d9fce0..2499745 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -36,5 +36,8 @@ extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
> unsigned long virt, phys_addr_t size,
> pgprot_t prot, bool allow_block_mappings);
> extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +extern void hotplug_paging(phys_addr_t start, phys_addr_t size);
> +#endif
>
> #endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 687d087..a7c740e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -544,37 +544,61 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> struct zone *zone;
> unsigned long start_pfn = start >> PAGE_SHIFT;
> unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long end_pfn = start_pfn + nr_pages;
> + unsigned long max_sparsemem_pfn = 1UL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
> + unsigned long pfn;
> int ret;
>
> + if (end_pfn > max_sparsemem_pfn) {
> + pr_err("end_pfn too big");
> + return -1;
> + }
> + hotplug_paging(start, size);
> +
> + /*
> + * Mark all the page range as unsuable.
> + * This is needed because __add_section (within __add_pages)
> + * wants pfn_valid to be false, and in arm64 pfn falid is implemented
> + * by just checking at the nomap flag for existing blocks
> + */
> + memblock_mark_nomap(start, size);
> +
> pgdat = NODE_DATA(nid);
>
> zone = pgdat->node_zones +
> zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
> ret = __add_pages(nid, zone, start_pfn, nr_pages);
>
> - if (ret)
> - pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
> - __func__, ret);
> + /*
> + * Make the pages usable after they have been added.
> + * This will make pfn_valid return true
> + */
> + memblock_clear_nomap(start, size);
>
> - return ret;
> -}
> + /*
> + * This is a hack to avoid having to mix arch specific code into arch
> + * independent code. SetPageReserved is supposed to be called by __add_zone
> + * (within __add_section, within __add_pages). However, when it is called
> + * there, it assumes that pfn_valid returns true. For the way pfn_valid is
> + * implemented in arm64 (a check on the nomap flag), the only way to make
> + * this evaluate true inside __add_zone is to clear the nomap flags of
> + * blocks in architecture independent code.
> + *
> + * To avoid this, we set the Reserved flag here after we cleared the nomap
> + * flag in the line above.
> + */
> + for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) {
> + if (!pfn_valid(pfn))
> + continue;
>
> -#ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> -{
> - unsigned long start_pfn = start >> PAGE_SHIFT;
> - unsigned long nr_pages = size >> PAGE_SHIFT;
> - struct zone *zone;
> - int ret;
> + SetPageReserved(pfn_to_page(pfn));
> + }
>
> - zone = page_zone(pfn_to_page(start_pfn));
> - ret = __remove_pages(zone, start_pfn, nr_pages);
> if (ret)
> - pr_warn("%s: Problem encountered in __remove_pages() ret=%d\n",
> + pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
> __func__, ret);
>
> return ret;
> }
> #endif
> -#endif
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 05615a3..9efa7d1 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -493,6 +493,30 @@ void __init paging_init(void)
> SWAPPER_DIR_SIZE - PAGE_SIZE);
> }
>
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +/*
> + * hotplug_paging() is used by memory hotplug to build new page tables
> + * for hot added memory.
> + */
> +void hotplug_paging(phys_addr_t start, phys_addr_t size)
> +{
> + phys_addr_t pgd_phys = pgd_pgtable_alloc();
> + pgd_t *pgd = pgd_set_fixmap(pgd_phys);
> +
> + memcpy(pgd, swapper_pg_dir, PAGE_SIZE);
> +
> + __create_pgd_mapping(pgd, start, __phys_to_virt(start), size,
> + PAGE_KERNEL, pgd_pgtable_alloc, false);
> +
> + cpu_replace_ttbr1(__va(pgd_phys));
> + memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
> + cpu_replace_ttbr1(swapper_pg_dir);
> +
> + pgd_clear_fixmap();
> + memblock_free(pgd_phys, PAGE_SIZE);
> +}
> +#endif
> +
> /*
> * Check whether a kernel address is valid (derived from arch/x86/).
> */
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5b759c9..5f78257 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -92,6 +92,7 @@ int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
> int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
> int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
> +int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
> ulong choose_memblock_flags(void);
>
> /* Low level functions */
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7608bc3..05e7676 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -814,6 +814,16 @@ int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
> }
>
> /**
> + * memblock_clear_nomap - Clear a flag of MEMBLOCK_NOMAP memory region
> + * @base: the base phys addr of the region
> + * @size: the size of the region
> + */
> +int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
> +{
> + return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
> +}
> +
> +/**
> * __next_reserved_mem_region - next function for for_each_reserved_region()
> * @idx: pointer to u64 loop variable
> * @out_start: ptr to phys_addr_t for start address of the region, can be %NULL
>
^ permalink raw reply
* [PATCH 2/2] ASoC: sun4i-spdif: Add quirks to the spdif driver
From: Maxime Ripard @ 2016-12-20 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220144914.30945-3-codekipper@gmail.com>
On Tue, Dec 20, 2016 at 03:49:14PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> It has been seen that some newer SoCs have a different TX FIFO
> address and we already have the difference with the A31 requiring
> a reset. Add a quirks structure so that these can be managed
> easily.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/f7369346/attachment.sig>
^ permalink raw reply
* [PATCH] ASoC: sun4i-i2s: Add quirks for newer SoCs
From: Maxime Ripard @ 2016-12-20 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220145524.31047-1-codekipper@gmail.com>
Hi,
On Tue, Dec 20, 2016 at 03:55:24PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> Newer SoCs have additional functionality so a quirks structure
> has been added to handle them. So far we've seen the use of a
> reset controller, a different address for the TXFIFO and varying
> register changes.
>
> This patch prepares the driver for these changes and adds the
> reset specifier.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> .../devicetree/bindings/sound/sun4i-i2s.txt | 2 +
> sound/soc/sunxi/sun4i-i2s.c | 47 ++++++++++++++++++++--
> 2 files changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> index 7a2c0945fd22..494a881ccd21 100644
> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> @@ -18,6 +18,8 @@ Required properties:
> - "apb" : clock for the I2S bus interface
> - "mod" : module clock for the I2S controller
> - #sound-dai-cells : Must be equal to 0
> +- resets: reset specifier for the ahb reset (A31 and newer only)
> +
>
> Example:
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index f24d19526603..80fe4f1d6e3b 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -14,9 +14,11 @@
> #include <linux/clk.h>
> #include <linux/dmaengine.h>
> #include <linux/module.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/regmap.h>
> +#include <linux/reset.h>
>
> #include <sound/dmaengine_pcm.h>
> #include <sound/pcm_params.h>
> @@ -92,6 +94,7 @@ struct sun4i_i2s {
> struct clk *bus_clk;
> struct clk *mod_clk;
> struct regmap *regmap;
> + struct reset_control *rst;
>
> unsigned int mclk_freq;
>
> @@ -104,6 +107,13 @@ struct sun4i_i2s_clk_div {
> u8 val;
> };
>
> +struct sun4i_i2s_quirks {
> + unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
> + bool has_reset;
> + const struct regmap_config *sun4i_i2s_regmap;
> + const struct snd_soc_dai_ops *ops;
> +};
> +
This is quite hard to review without actual example of what you'll put
in there.
> static const struct sun4i_i2s_clk_div sun4i_i2s_bclk_div[] = {
> { .div = 2, .val = 0 },
> { .div = 4, .val = 1 },
> @@ -541,7 +551,6 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
> .rates = SNDRV_PCM_RATE_8000_192000,
> .formats = SNDRV_PCM_FMTBIT_S16_LE,
> },
> - .ops = &sun4i_i2s_dai_ops,
> .symmetric_rates = 1,
> };
>
> @@ -655,6 +664,7 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
> {
> struct sun4i_i2s *i2s;
> struct resource *res;
> + const struct sun4i_i2s_quirks *quirks;
> void __iomem *regs;
> int irq, ret;
>
> @@ -680,8 +690,14 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
> return PTR_ERR(i2s->bus_clk);
> }
>
> + quirks = of_device_get_match_data(&pdev->dev);
> + if (quirks == NULL) {
> + dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
> + return -ENODEV;
> + }
> +
> i2s->regmap = devm_regmap_init_mmio(&pdev->dev, regs,
> - &sun4i_i2s_regmap_config);
> + quirks->sun4i_i2s_regmap);
> if (IS_ERR(i2s->regmap)) {
> dev_err(&pdev->dev, "Regmap initialisation failed\n");
> return PTR_ERR(i2s->regmap);
> @@ -692,13 +708,25 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "Can't get our mod clock\n");
> return PTR_ERR(i2s->mod_clk);
> }
> +
Spurious change?
>
> - i2s->playback_dma_data.addr = res->start + SUN4I_I2S_FIFO_TX_REG;
> + i2s->playback_dma_data.addr = res->start + quirks->reg_dac_txdata;
> i2s->playback_dma_data.maxburst = 4;
>
> i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
> i2s->capture_dma_data.maxburst = 4;
>
> + if (quirks->has_reset) {
> + i2s->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
> + if (IS_ERR(i2s->rst) && PTR_ERR(i2s->rst) == -EPROBE_DEFER) {
> + ret = -EPROBE_DEFER;
> + dev_err(&pdev->dev, "Failed to get reset: %d\n", ret);
> + goto err_pm_disable;
> + }
> + if (!IS_ERR(i2s->rst))
> + reset_control_deassert(i2s->rst);
> + }
> +
That reset line is not optional. The <A31 SoCs don't need it, and you
cover that case already, but it is definitely mandatory for the A31.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/368fceb7/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: sun4i: A1000: add axp209 regulator nodes
From: Maxime Ripard @ 2016-12-20 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220155542.22047-1-codekipper@gmail.com>
On Tue, Dec 20, 2016 at 04:55:42PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> This patch adds the regulator nodes for the axp209 by including
> the axp209 dtsi.
>
> DCDC2 is used as the cpu power supply. This patch also references
> it from the cpu node.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/88378e27/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Magnus Lilja @ 2016-12-20 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482211233.10253607@f408.i.mail.ru>
On 20 December 2016 at 06:20, Alexander Shiyan <shc_work@mail.ru> wrote:
>>???????, 20 ??????? 2016, 0:28 +03:00 ?? Magnus Lilja <lilja.magnus@gmail.com>:
>>
>>All supported mc13xxx devices have active high interrupt outputs. Make sure
>>to configure the interrupt as active high by passing the IRQF_TRIGGER_HIGH
>>flag. This is required at least on the i.MX31 PDK board.
>>
>>Signed-off-by: Magnus Lilja < lilja.magnus@gmail.com >
>>---
>>
>> drivers/mfd/mc13xxx-core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
>>index d7f54e4..4cbe6b7 100644
>>--- a/drivers/mfd/mc13xxx-core.c
>>+++ b/drivers/mfd/mc13xxx-core.c
>>@@ -440,7 +440,7 @@ int mc13xxx_common_init(struct device *dev)
>> mc13xxx->irq_chip.irqs = mc13xxx->irqs;
>> mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
>>
>>-ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
>>+ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
>> 0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
>> if (ret)
>> return ret;
>
> IRQ line can be passed through inverter to IC.
> On my opinion the best way to handle all possible situations is parse
> devicetree IRQ flags and pass to the driver.
My guess is that most boards follow the evaluation boards/kits and
don't have an inverter so I think the default should be TRIG_HIGH
since that will make most boards work automatically. But I can have a
look at making it configurable (with and without the use of device
tree), but for the device tree stuff I would need pointers to similar
code since my experience with that is none.
Any pointers to similar code?
Regards. Magnus
^ permalink raw reply
* [PATCH] ASoC: sun4i-i2s: Add quirks for newer SoCs
From: Code Kipper @ 2016-12-20 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220191656.xrmovtlslwcofsts@lukather>
On 20 December 2016 at 20:16, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Dec 20, 2016 at 03:55:24PM +0100, codekipper at gmail.com wrote:
>> From: Marcus Cooper <codekipper@gmail.com>
>>
>> Newer SoCs have additional functionality so a quirks structure
>> has been added to handle them. So far we've seen the use of a
>> reset controller, a different address for the TXFIFO and varying
>> register changes.
>>
>> This patch prepares the driver for these changes and adds the
>> reset specifier.
>>
>> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
>> ---
>> .../devicetree/bindings/sound/sun4i-i2s.txt | 2 +
>> sound/soc/sunxi/sun4i-i2s.c | 47 ++++++++++++++++++++--
>> 2 files changed, 45 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> index 7a2c0945fd22..494a881ccd21 100644
>> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> @@ -18,6 +18,8 @@ Required properties:
>> - "apb" : clock for the I2S bus interface
>> - "mod" : module clock for the I2S controller
>> - #sound-dai-cells : Must be equal to 0
>> +- resets: reset specifier for the ahb reset (A31 and newer only)
>> +
>>
>> Example:
>>
>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
>> index f24d19526603..80fe4f1d6e3b 100644
>> --- a/sound/soc/sunxi/sun4i-i2s.c
>> +++ b/sound/soc/sunxi/sun4i-i2s.c
>> @@ -14,9 +14,11 @@
>> #include <linux/clk.h>
>> #include <linux/dmaengine.h>
>> #include <linux/module.h>
>> +#include <linux/of_device.h>
>> #include <linux/platform_device.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/regmap.h>
>> +#include <linux/reset.h>
>>
>> #include <sound/dmaengine_pcm.h>
>> #include <sound/pcm_params.h>
>> @@ -92,6 +94,7 @@ struct sun4i_i2s {
>> struct clk *bus_clk;
>> struct clk *mod_clk;
>> struct regmap *regmap;
>> + struct reset_control *rst;
>>
>> unsigned int mclk_freq;
>>
>> @@ -104,6 +107,13 @@ struct sun4i_i2s_clk_div {
>> u8 val;
>> };
>>
>> +struct sun4i_i2s_quirks {
>> + unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
>> + bool has_reset;
>> + const struct regmap_config *sun4i_i2s_regmap;
>> + const struct snd_soc_dai_ops *ops;
>> +};
>> +
>
> This is quite hard to review without actual example of what you'll put
> in there.
Fair enough...I have a patch for the A31 but haven't got any hardware
that I can verify it on. I've confirmed on the H3 but I feel like that
patch needs some tidying up. That being said...I'll push it as a patch
set and we can talk about the setup.
>
>> static const struct sun4i_i2s_clk_div sun4i_i2s_bclk_div[] = {
>> { .div = 2, .val = 0 },
>> { .div = 4, .val = 1 },
>> @@ -541,7 +551,6 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
>> .rates = SNDRV_PCM_RATE_8000_192000,
>> .formats = SNDRV_PCM_FMTBIT_S16_LE,
>> },
>> - .ops = &sun4i_i2s_dai_ops,
>> .symmetric_rates = 1,
>> };
>>
>> @@ -655,6 +664,7 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
>> {
>> struct sun4i_i2s *i2s;
>> struct resource *res;
>> + const struct sun4i_i2s_quirks *quirks;
>> void __iomem *regs;
>> int irq, ret;
>>
>> @@ -680,8 +690,14 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
>> return PTR_ERR(i2s->bus_clk);
>> }
>>
>> + quirks = of_device_get_match_data(&pdev->dev);
>> + if (quirks == NULL) {
>> + dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
>> + return -ENODEV;
>> + }
>> +
>> i2s->regmap = devm_regmap_init_mmio(&pdev->dev, regs,
>> - &sun4i_i2s_regmap_config);
>> + quirks->sun4i_i2s_regmap);
>> if (IS_ERR(i2s->regmap)) {
>> dev_err(&pdev->dev, "Regmap initialisation failed\n");
>> return PTR_ERR(i2s->regmap);
>> @@ -692,13 +708,25 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
>> dev_err(&pdev->dev, "Can't get our mod clock\n");
>> return PTR_ERR(i2s->mod_clk);
>> }
>> +
>
> Spurious change?
ACK
>
>>
>> - i2s->playback_dma_data.addr = res->start + SUN4I_I2S_FIFO_TX_REG;
>> + i2s->playback_dma_data.addr = res->start + quirks->reg_dac_txdata;
>> i2s->playback_dma_data.maxburst = 4;
>>
>> i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
>> i2s->capture_dma_data.maxburst = 4;
>>
>> + if (quirks->has_reset) {
>> + i2s->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
>> + if (IS_ERR(i2s->rst) && PTR_ERR(i2s->rst) == -EPROBE_DEFER) {
>> + ret = -EPROBE_DEFER;
>> + dev_err(&pdev->dev, "Failed to get reset: %d\n", ret);
>> + goto err_pm_disable;
>> + }
>> + if (!IS_ERR(i2s->rst))
>> + reset_control_deassert(i2s->rst);
>> + }
>> +
>
> That reset line is not optional. The <A31 SoCs don't need it, and you
> cover that case already, but it is definitely mandatory for the A31.
OK..I'll search for a better function call. Thanks for this and the
other reviews.
CK
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v6 4/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2016-12-20 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219072326.fael3uughtghexl4@pengutronix.de>
Uwe,
Thanks so much for your review.
On 12/18/2016 11:23 PM, Uwe Kleine-K?nig wrote:
> On Fri, Dec 16, 2016 at 03:17:53PM -0800, Joshua Clayton wrote:
>> cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
>> interface on Altera Cyclone FPGAS.
>>
>> This is one of the simpler ways to set up an FPGA at runtime.
>> The signal interface is close to unidirectional spi with lsb first.
>>
>> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
>> ---
>> drivers/fpga/Kconfig | 7 ++
>> drivers/fpga/Makefile | 1 +
>> drivers/fpga/cyclone-ps-spi.c | 186 ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 194 insertions(+)
>> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>>
>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> index ce861a2..e6c032d 100644
>> --- a/drivers/fpga/Kconfig
>> +++ b/drivers/fpga/Kconfig
>> @@ -20,6 +20,13 @@ config FPGA_REGION
>> FPGA Regions allow loading FPGA images under control of
>> the Device Tree.
>>
>> +config FPGA_MGR_CYCLONE_PS_SPI
>> + tristate "Altera Cyclone FPGA Passive Serial over SPI"
>> + depends on SPI
>> + help
>> + FPGA manager driver support for Altera Cyclone using the
>> + passive serial interface over SPI
>> +
>> config FPGA_MGR_SOCFPGA
>> tristate "Altera SOCFPGA FPGA Manager"
>> depends on ARCH_SOCFPGA || COMPILE_TEST
>> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
>> index 8df07bc..a112bef 100644
>> --- a/drivers/fpga/Makefile
>> +++ b/drivers/fpga/Makefile
>> @@ -6,6 +6,7 @@
>> obj-$(CONFIG_FPGA) += fpga-mgr.o
>>
>> # FPGA Manager Drivers
>> +obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
>> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
>> obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
>> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
>> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
>> new file mode 100644
>> index 0000000..f9126f9
>> --- /dev/null
>> +++ b/drivers/fpga/cyclone-ps-spi.c
>> @@ -0,0 +1,186 @@
>> +/**
>> + * Altera Cyclone Passive Serial SPI Driver
>> + *
>> + * Copyright (c) 2017 United Western Technologies, Corporation
> In which timezone it's already 2017? s/ / /
>
LOL. It will be 2017 long before 4.11 was my thinking.
I guess I've never spent much time on time stamp etiquette for copyright.
It said "2015" in v5, despite still being revised.
>> + *
>> + * Joshua Clayton <stillcompiling@gmail.com>
>> + *
>> + * Manage Altera FPGA firmware that is loaded over spi using the passive
>> + * serial configuration method.
>> + * Firmware must be in binary "rbf" format.
>> + * Works on Cyclone V. Should work on cyclone series.
>> + * May work on other Altera FPGAs.
> I can test this later on an Arria 10. I'm not sure what the connection
> between "Cyclone" and "Arria" is, but the protocol looks similar.
My guess was it would be.
Would be wonderful to have someone to test.
>> + *
>> + */
>> +
>> +#include <linux/bitrev.h>
>> +#include <linux/delay.h>
>> +#include <linux/fpga/fpga-mgr.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/module.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/spi/spi.h>
>> +#include <linux/sizes.h>
>> +
>> +#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
>> +#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
>> +#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
>> +
>> +struct cyclonespi_conf {
>> + struct gpio_desc *config;
>> + struct gpio_desc *status;
>> + struct spi_device *spi;
>> +};
>> +
>> +static const struct of_device_id of_ef_match[] = {
>> + { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, of_ef_match);
> barebox already has such a driver, the binding is available at
>
> https://git.pengutronix.de/cgit/barebox/tree/Documentation/devicetree/bindings/firmware/altr,passive-serial.txt
>
> (This isn't completely accurate because nstat is optional in the driver.)
Interesting.
The binding looks ... like we should synchronize those bindings.
In the case of my hardware, I don't have access to the confd, but do
have access to nstat. I was thinking that using confd to signal done
would be a nice but optional... Ideally you'd have both.
>> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
>> +{
>> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> +
>> + if (gpiod_get_value(conf->status))
>> + return FPGA_MGR_STATE_RESET;
>> +
>> + return FPGA_MGR_STATE_UNKNOWN;
>> +}
>> +
>> +static int cyclonespi_write_init(struct fpga_manager *mgr,
>> + struct fpga_image_info *info,
>> + const char *buf, size_t count)
>> +{
>> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> + int i;
>> +
>> + if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
>> + return -EINVAL;
>> + }
>> +
>> + gpiod_set_value(conf->config, 1);
>> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
>> + if (!gpiod_get_value(conf->status)) {
>> + dev_err(&mgr->dev, "Status pin should be low.\n");
> You write this when get_value returns 0. There is something fishy.
I'll take a look. These gpios are "active low", so a logical 1 is a
physical low, IIRC. Maybe I should change the wording:
Something like dev_err(&mgr->dev, "Status pin should be in reset.\n");
Perhaps?
>> + return -EIO;
>> + }
>> +
>> + gpiod_set_value(conf->config, 0);
>> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
>> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
>> + if (!gpiod_get_value(conf->status))
>> + return 0;
>> + }
>> +
>> + dev_err(&mgr->dev, "Status pin not ready.\n");
>> + return -EIO;
> For Arria 10 the documentation has:
>
> To ensure a successful configuration, send the entire
> configuration data to the device. CONF_DONE is released high
> when the device receives all the configuration data
> successfully. After CONF_DONE goes high, send two additional
> falling edges on DCLK to begin initialization and enter user
> mode.
>
> ISTR this is necessary for Arria V, too.
DCLK is the spi clock, yes?
Would sending an extra byte after CONF_DONE is released suffice?
>> +}
>> +
>> +static void rev_buf(void *buf, size_t len)
>> +{
>> + u32 *fw32 = (u32 *)buf;
>> + const u32 *fw_end = (u32 *)(buf + len);
>> +
>> + /* set buffer to lsb first */
>> + while (fw32 < fw_end) {
>> + *fw32 = bitrev8x4(*fw32);
>> + fw32++;
>> + }
> Is the size of the firmware always a multiple of 32 bit? If len isn't a
> multiple of 4 you access data after the end of buf.
The rbf cyclone V bitstream is padded out with extra bytes of FFFFFFFF
and always a multiple of 4 bytes.
I could not find anywhere this is documented.
I guess we should not assume this will always be the case.
I'll add something to handle the tail.
>> +}
>> +
>> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
>> + size_t count)
>> +{
>> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> + const char *fw_data = buf;
>> + const char *fw_data_end = fw_data + count;
>> +
>> + while (fw_data < fw_data_end) {
>> + int ret;
>> + size_t stride = min(fw_data_end - fw_data, SZ_4K);
>> +
>> + rev_buf((void *)fw_data, stride);
> This isn't necessary if the spi controller supports SPI_LSB_FIRST. At
> least the mvebu spi core can do this for you. (The driver doesn't
> support it yet, though.)
This is true, but many of them do not.
Moritz Fischer had proposal to add things like this with a flag.
It could then be part of the library, rather than part of the driver
Speaking of which,
I made an unsuccessful attempt to hack generic lsb first SPI
with an extra bounce buffer.
Sending was fine, but I ran into trouble with LSB first rx
(I think) because of dma.
>> + ret = spi_write(conf->spi, fw_data, stride);
>> + if (ret) {
>> + dev_err(&mgr->dev, "spi error in firmware write: %d\n",
>> + ret);
>> + return ret;
>> + }
>> + fw_data += stride;
>> + }
>> +
>> + return 0;
>> +}
>> [...]
>> +static int cyclonespi_probe(struct spi_device *spi)
>> +{
>> + struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
>> + GFP_KERNEL);
> please indent to the opening (.
Will fix.
>> +
>> + if (!conf)
>> + return -ENOMEM;
>> +
>> + conf->spi = spi;
>> + conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_HIGH);
>> + if (IS_ERR(conf->config)) {
>> + dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
>> + PTR_ERR(conf->config));
>> + return PTR_ERR(conf->config);
>> + }
>> +
>> + conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
>> + if (IS_ERR(conf->status)) {
>> + dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
>> + PTR_ERR(conf->status));
>> + return PTR_ERR(conf->status);
>> + }
>> +
>> + return fpga_mgr_register(&spi->dev,
>> + "Altera Cyclone PS SPI FPGA Manager",
>> + &cyclonespi_ops, conf);
>> +}
>> +
>> +static int cyclonespi_remove(struct spi_device *spi)
>> +{
>> + fpga_mgr_unregister(&spi->dev);
>> +
>> + return 0;
>> +}
>> +
>> +static struct spi_driver cyclonespi_driver = {
>> + .driver = {
>> + .name = "cyclone-ps-spi",
>> + .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(of_ef_match),
>> + },
>> + .probe = cyclonespi_probe,
>> + .remove = cyclonespi_remove,
>> +};
> I'm not a big fan of aligning the assignment operators. This tends to
> get out of sync or results in bigger than necessary changes in follow up
> patches. Note that it's out of sync already now, so I suggest to use a
> single space before =.
Yes, I can see it your way. Will change.
>> +
>> +module_spi_driver(cyclonespi_driver)
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
>> +MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
>> --
> Best regards
> Uwe
>
Even bester regards,
Joshua
^ permalink raw reply
* [PATCH 0/3] TI DA8xx/OMAPL13x/AM17xx/AM18xx UART
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
To: linux-arm-kernel
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx UART.
This SoCs have a non-standard register for UART power management that needs
special handling in the UART driver.
David Lechner (3):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx
ARM: da850: Add ti,da830-uart compatible for serial ports
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
6 files changed, 40 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482265384-715-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482265384-715-1-git-send-email-david@lechnology.com>
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These
SoCs have standard 8250 registers plus some extra non-standard registers.
The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
.data = (void *)PORT_ALTR_16550_F128, },
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
+ { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..ea854054 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_DA830] = {
+ .name = "TI DA8xx/OMAPL13x/AM17xx/AM18xx",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO | UART_CAP_AFE,
+ },
};
/* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_out(port, UART_LCR, 0);
}
+ if (port->type == PORT_DA830) {
+ /* Reset the port */
+ serial_port_out(port, UART_IER, 0);
+ serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+ mdelay(10);
+
+ /* Enable Tx, Rx and free run mode */
+ serial_port_out(port, UART_DA830_PWREMU_MGMT,
+ UART_DA830_PWREMU_MGMT_UTRST |
+ UART_DA830_PWREMU_MGMT_URRST |
+ UART_DA830_PWREMU_MGMT_FREE);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..a126d05 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250 30 /* max port ID */
+#define PORT_DA830 31 /* TI DA8xx/OMAP13x/AM17xx/AM18xx */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..0e72eeb 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
#define SERIAL_RSA_BAUD_BASE (921600)
#define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
+/* Extra registers for TI DA8xx/OMAP13x/AM17xx/AM18xx */
+#define UART_DA830_PWREMU_MGMT 12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE (1 << 0) /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST (1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST (1 << 14) /* Transmitter reset/enable */
+
/*
* Extra serial register definitions for the internal UARTs
* in TI OMAP processors.
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: da850: Add ti, da830-uart compatible for serial ports
From: David Lechner @ 2016-12-20 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482265384-715-1-git-send-email-david@lechnology.com>
TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
interrupt-names = "edm3_tcerrint";
};
serial0: serial at 42000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x42000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
status = "disabled";
};
serial1: serial at 10c000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10c000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
status = "disabled";
};
serial2: serial at 10d000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10d000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
status = "disabled";
--
2.7.4
^ 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