* [PATCH v4 04/12] clk: qcom: Add HFPLL driver
From: Rob Herring @ 2017-12-12 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512726150-7204-5-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:22PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> On some devices (MSM8974 for example), the HFPLLs are
> instantiated within the Krait processor subsystem as separate
> register regions. Add a driver for these PLLs so that we can
> provide HFPLL clocks for use by the system.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt | 40 ++++++++
> drivers/clk/qcom/Kconfig | 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/hfpll.c | 106 +++++++++++++++++++++
> 4 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> create mode 100644 drivers/clk/qcom/hfpll.c
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> new file mode 100644
> index 0000000..fee92bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> @@ -0,0 +1,40 @@
> +High-Frequency PLL (HFPLL)
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: must be "qcom,hfpll"
Fine for a fallback, but please add SoC specific compatibles.
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: address and size of HPLL registers. An optional second
> + element specifies the address and size of the alias
> + register region.
> +
> +- clock-output-names:
> + Usage: required
> + Value type: <string>
> + Definition: Name of the PLL. Typically hfpllX where X is a CPU number
> + starting at 0. Otherwise hfpll_Y where Y is more specific
> + such as "l2".
> +
> +Example:
> +
> +1) An HFPLL for the L2 cache.
> +
> + clock-controller at f9016000 {
> + compatible = "qcom,hfpll";
> + reg = <0xf9016000 0x30>;
> + clock-output-names = "hfpll_l2";
> + };
> +
> +2) An HFPLL for CPU0. This HFPLL has the alias register region.
> +
> + clock-controller at f908a000 {
> + compatible = "qcom,hfpll";
> + reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
> + clock-output-names = "hfpll0";
> + };
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 20b5d6f..6c811bd 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -205,3 +205,11 @@ config SPMI_PMIC_CLKDIV
> Technologies, Inc. SPMI PMIC. It configures the frequency of
> clkdiv outputs of the PMIC. These clocks are typically wired
> through alternate functions on GPIO pins.
> +
> +config QCOM_HFPLL
> + tristate "High-Frequency PLL (HFPLL) Clock Controller"
> + depends on COMMON_CLK_QCOM
> + help
> + Support for the high-frequency PLLs present on Qualcomm devices.
> + Say Y if you want to support CPU frequency scaling on devices
> + such as MSM8974, APQ8084, etc.
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 4795e21..4a4bf38 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
> +obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> new file mode 100644
> index 0000000..7405bb6
> --- /dev/null
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
It's 2017.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Use SPDX tags.
Rob
^ permalink raw reply
* [PATCH] ARM: pxa/lubbock: add GPIO driver for LUB_MISC_WR register
From: Robert Jarzmik @ 2017-12-12 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eOTFj-0008MB-Fj@rmk-PC.armlinux.org.uk>
Russell King <rmk+kernel@armlinux.org.uk> writes:
> Add a gpio driver for the lubbock miscellaneous write IO register so we
> can take advantage of subsystems modelled around gpiolib, rather than
> having to provide platform specific callbacks.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Hi Russell and Linux,
It looks certainly good to me. It's unfortunate in the current status of
linux-next I have, gpio-reg.c seems broken (that one is for Linus in [1] and
[2]), and therefore I can't test it live.
Nonetheless, do you want me to carry it through the pxa tree or do you want to
keep it through your tree ?
Cheers.
--
Robert
[1] For Linus if he wasn't notified before :
---8>---
CC drivers/gpio/gpio-reg.o
drivers/gpio/gpio-reg.c: In function 'gpio_reg_to_irq':
drivers/gpio/gpio-reg.c:106:19: error: 'struct gpio_reg' has no member named 'irq'
if (irq >= 0 && r->irq.domain)
^
drivers/gpio/gpio-reg.c:107:27: error: 'struct gpio_reg' has no member named 'irq'
irq = irq_find_mapping(r->irq.domain, irq);
^
make[2]: *** [drivers/gpio/gpio-reg.o] Erreur 1
---8>---
[2] For Linux, git commit of my linux-next tip
d20787938ddb ("Add linux-next specific files for 20171212")
^ permalink raw reply
* [PATCH v8 10/13] IIO: ADC: add stm32 DFSDM support for PDM microphone
From: Jonathan Cameron @ 2017-12-12 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512987524-2901-11-git-send-email-arnaud.pouliquen@st.com>
On Mon, 11 Dec 2017 11:18:41 +0100
Arnaud Pouliquen <arnaud.pouliquen@st.com> wrote:
> This code offers a way to handle PDM audio microphones in
> ASOC framework. Audio driver should use consumer API.
> A specific management is implemented for DMA, with a
> callback, to allows to handle audio buffers efficiently.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Hi Arnaud,
I raise a few queries on v7 of this patch.
https://marc.info/?l=linux-iio&m=151292965915376&w=2
Jonathan
> ---
> .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 16 +
> drivers/iio/adc/stm32-dfsdm-adc.c | 508 ++++++++++++++++++++-
> include/linux/iio/adc/stm32-dfsdm-adc.h | 18 +
> 3 files changed, 534 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> new file mode 100644
> index 0000000..da98223
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> @@ -0,0 +1,16 @@
> +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_spi_clk_freq
> +KernelVersion: 4.14
> +Contact: arnaud.pouliquen at st.com
> +Description:
> + For audio purpose only.
> + Used by audio driver to set/get the spi input frequency.
> + This is mandatory if DFSDM is slave on SPI bus, to
> + provide information on the SPI clock frequency during runtime
> + Notice that the SPI frequency should be a multiple of sample
> + frequency to ensure the precision.
> + if DFSDM input is SPI master
> + Reading SPI clkout frequency,
> + error on writing
> + If DFSDM input is SPI Slave:
> + Reading returns value previously set.
> + Writing value before starting conversions.
> \ No newline at end of file
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> index 68b5920..2d6aed5 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -6,19 +6,25 @@
> * Author: Arnaud Pouliquen <arnaud.pouliquen@st.com>.
> */
>
> +#include <linux/dmaengine.h>
> +#include <linux/dma-mapping.h>
> #include <linux/interrupt.h>
> #include <linux/iio/buffer.h>
> #include <linux/iio/hw-consumer.h>
> #include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> #include <linux/module.h>
> -#include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> #include <linux/slab.h>
>
> #include "stm32-dfsdm.h"
>
> +#define DFSDM_DMA_BUFFER_SIZE (4 * PAGE_SIZE)
> +
> /* Conversion timeout */
> #define DFSDM_TIMEOUT_US 100000
> #define DFSDM_TIMEOUT (msecs_to_jiffies(DFSDM_TIMEOUT_US / 1000))
> @@ -58,6 +64,18 @@ struct stm32_dfsdm_adc {
> struct completion completion;
> u32 *buffer;
>
> + /* Audio specific */
> + unsigned int spi_freq; /* SPI bus clock frequency */
> + unsigned int sample_freq; /* Sample frequency after filter decimation */
> + int (*cb)(const void *data, size_t size, void *cb_priv);
> + void *cb_priv;
> +
> + /* DMA */
> + u8 *rx_buf;
> + unsigned int bufi; /* Buffer current position */
> + unsigned int buf_sz; /* Buffer size */
> + struct dma_chan *dma_chan;
> + dma_addr_t dma_buf;
> };
>
> struct stm32_dfsdm_str2field {
> @@ -351,10 +369,63 @@ int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> return 0;
> }
>
> +static ssize_t dfsdm_adc_audio_get_spiclk(struct iio_dev *indio_dev,
> + uintptr_t priv,
> + const struct iio_chan_spec *chan,
> + char *buf)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> +
> + return snprintf(buf, PAGE_SIZE, "%d\n", adc->spi_freq);
> +}
> +
> +static ssize_t dfsdm_adc_audio_set_spiclk(struct iio_dev *indio_dev,
> + uintptr_t priv,
> + const struct iio_chan_spec *chan,
> + const char *buf, size_t len)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
> + struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[adc->ch_id];
> + unsigned int sample_freq = adc->sample_freq;
> + unsigned int spi_freq;
> + int ret;
> +
> + dev_err(&indio_dev->dev, "enter %s\n", __func__);
> + /* If DFSDM is master on SPI, SPI freq can not be updated */
> + if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
> + return -EPERM;
> +
> + ret = kstrtoint(buf, 0, &spi_freq);
> + if (ret)
> + return ret;
> +
> + if (!spi_freq)
> + return -EINVAL;
> +
> + if (sample_freq) {
> + if (spi_freq % sample_freq)
> + dev_warn(&indio_dev->dev,
> + "Sampling rate not accurate (%d)\n",
> + spi_freq / (spi_freq / sample_freq));
> +
> + ret = stm32_dfsdm_set_osrs(fl, 0, (spi_freq / sample_freq));
> + if (ret < 0) {
> + dev_err(&indio_dev->dev,
> + "No filter parameters that match!\n");
> + return ret;
> + }
> + }
> + adc->spi_freq = spi_freq;
> +
> + return len;
> +}
> +
> static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc, bool dma)
> {
> struct regmap *regmap = adc->dfsdm->regmap;
> int ret;
> + unsigned int dma_en = 0, cont_en = 0;
>
> ret = stm32_dfsdm_start_channel(adc->dfsdm, adc->ch_id);
> if (ret < 0)
> @@ -365,6 +436,24 @@ static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc, bool dma)
> if (ret < 0)
> goto stop_channels;
>
> + if (dma) {
> + /* Enable DMA transfer*/
> + dma_en = DFSDM_CR1_RDMAEN(1);
> + /* Enable conversion triggered by SPI clock*/
> + cont_en = DFSDM_CR1_RCONT(1);
> + }
> + /* Enable DMA transfer*/
> + ret = regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
> + DFSDM_CR1_RDMAEN_MASK, dma_en);
> + if (ret < 0)
> + goto stop_channels;
> +
> + /* Enable conversion triggered by SPI clock*/
> + ret = regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
> + DFSDM_CR1_RCONT_MASK, cont_en);
> + if (ret < 0)
> + goto stop_channels;
> +
> ret = stm32_dfsdm_start_filter(adc->dfsdm, adc->fl_id);
> if (ret < 0)
> goto stop_channels;
> @@ -398,6 +487,231 @@ static void stm32_dfsdm_stop_conv(struct stm32_dfsdm_adc *adc)
> stm32_dfsdm_stop_channel(adc->dfsdm, adc->ch_id);
> }
>
> +static int stm32_dfsdm_set_watermark(struct iio_dev *indio_dev,
> + unsigned int val)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + unsigned int watermark = DFSDM_DMA_BUFFER_SIZE / 2;
> +
> + /*
> + * DMA cyclic transfers are used, buffer is split into two periods.
> + * There should be :
> + * - always one buffer (period) DMA is working on
> + * - one buffer (period) driver pushed to ASoC side.
> + */
> + watermark = min(watermark, val * (unsigned int)(sizeof(u32)));
> + adc->buf_sz = watermark * 2;
> +
> + return 0;
> +}
> +
> +static unsigned int stm32_dfsdm_adc_dma_residue(struct stm32_dfsdm_adc *adc)
> +{
> + struct dma_tx_state state;
> + enum dma_status status;
> +
> + status = dmaengine_tx_status(adc->dma_chan,
> + adc->dma_chan->cookie,
> + &state);
> + if (status == DMA_IN_PROGRESS) {
> + /* Residue is size in bytes from end of buffer */
> + unsigned int i = adc->buf_sz - state.residue;
> + unsigned int size;
> +
> + /* Return available bytes */
> + if (i >= adc->bufi)
> + size = i - adc->bufi;
> + else
> + size = adc->buf_sz + i - adc->bufi;
> +
> + return size;
> + }
> +
> + return 0;
> +}
> +
> +static void stm32_dfsdm_audio_dma_buffer_done(void *data)
> +{
> + struct iio_dev *indio_dev = data;
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + int available = stm32_dfsdm_adc_dma_residue(adc);
> + size_t old_pos;
> +
> + /*
> + * FIXME: In Kernel interface does not support cyclic DMA buffer,and
> + * offers only an interface to push data samples per samples.
> + * For this reason IIO buffer interface is not used and interface is
> + * bypassed using a private callback registered by ASoC.
> + * This should be a temporary solution waiting a cyclic DMA engine
> + * support in IIO.
> + */
> +
> + dev_dbg(&indio_dev->dev, "%s: pos = %d, available = %d\n", __func__,
> + adc->bufi, available);
> + old_pos = adc->bufi;
> +
> + while (available >= indio_dev->scan_bytes) {
> + u32 *buffer = (u32 *)&adc->rx_buf[adc->bufi];
> +
> + /* Mask 8 LSB that contains the channel ID */
> + *buffer = (*buffer & 0xFFFFFF00) << 8;
> + available -= indio_dev->scan_bytes;
> + adc->bufi += indio_dev->scan_bytes;
> + if (adc->bufi >= adc->buf_sz) {
> + if (adc->cb)
> + adc->cb(&adc->rx_buf[old_pos],
> + adc->buf_sz - old_pos, adc->cb_priv);
> + adc->bufi = 0;
> + old_pos = 0;
> + }
> + }
> + if (adc->cb)
> + adc->cb(&adc->rx_buf[old_pos], adc->bufi - old_pos,
> + adc->cb_priv);
> +}
> +
> +static int stm32_dfsdm_adc_dma_start(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct dma_async_tx_descriptor *desc;
> + dma_cookie_t cookie;
> + int ret;
> +
> + if (!adc->dma_chan)
> + return -EINVAL;
> +
> + dev_dbg(&indio_dev->dev, "%s size=%d watermark=%d\n", __func__,
> + adc->buf_sz, adc->buf_sz / 2);
> +
> + /* Prepare a DMA cyclic transaction */
> + desc = dmaengine_prep_dma_cyclic(adc->dma_chan,
> + adc->dma_buf,
> + adc->buf_sz, adc->buf_sz / 2,
> + DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT);
> + if (!desc)
> + return -EBUSY;
> +
> + desc->callback = stm32_dfsdm_audio_dma_buffer_done;
> + desc->callback_param = indio_dev;
> +
> + cookie = dmaengine_submit(desc);
> + ret = dma_submit_error(cookie);
> + if (ret) {
> + dmaengine_terminate_all(adc->dma_chan);
> + return ret;
> + }
> +
> + /* Issue pending DMA requests */
> + dma_async_issue_pending(adc->dma_chan);
> +
> + return 0;
> +}
> +
> +static int stm32_dfsdm_postenable(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + /* Reset adc buffer index */
> + adc->bufi = 0;
> +
> + ret = stm32_dfsdm_start_dfsdm(adc->dfsdm);
> + if (ret < 0)
> + return ret;
> +
> + ret = stm32_dfsdm_start_conv(adc, true);
> + if (ret) {
> + dev_err(&indio_dev->dev, "Can't start conversion\n");
> + goto stop_dfsdm;
> + }
> +
> + if (adc->dma_chan) {
> + ret = stm32_dfsdm_adc_dma_start(indio_dev);
> + if (ret) {
> + dev_err(&indio_dev->dev, "Can't start DMA\n");
> + goto err_stop_conv;
> + }
> + }
> +
> + return 0;
> +
> +err_stop_conv:
> + stm32_dfsdm_stop_conv(adc);
> +stop_dfsdm:
> + stm32_dfsdm_stop_dfsdm(adc->dfsdm);
> +
> + return ret;
> +}
> +
> +static int stm32_dfsdm_predisable(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> +
> + if (adc->dma_chan)
> + dmaengine_terminate_all(adc->dma_chan);
> +
> + stm32_dfsdm_stop_conv(adc);
> +
> + stm32_dfsdm_stop_dfsdm(adc->dfsdm);
> +
> + return 0;
> +}
> +
> +static const struct iio_buffer_setup_ops stm32_dfsdm_buffer_setup_ops = {
> + .postenable = &stm32_dfsdm_postenable,
> + .predisable = &stm32_dfsdm_predisable,
> +};
> +
> +/**
> + * stm32_dfsdm_get_buff_cb() - register a callback that will be called when
> + * DMA transfer period is achieved.
> + *
> + * @iio_dev: Handle to IIO device.
> + * @cb: Pointer to callback function:
> + * - data: pointer to data buffer
> + * - size: size in byte of the data buffer
> + * - private: pointer to consumer private structure.
> + * @private: Pointer to consumer private structure.
> + */
> +int stm32_dfsdm_get_buff_cb(struct iio_dev *iio_dev,
> + int (*cb)(const void *data, size_t size,
> + void *private),
> + void *private)
> +{
> + struct stm32_dfsdm_adc *adc;
> +
> + if (!iio_dev)
> + return -EINVAL;
> + adc = iio_priv(iio_dev);
> +
> + adc->cb = cb;
> + adc->cb_priv = private;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(stm32_dfsdm_get_buff_cb);
> +
> +/**
> + * stm32_dfsdm_release_buff_cb - unregister buffer callback
> + *
> + * @iio_dev: Handle to IIO device.
> + */
> +int stm32_dfsdm_release_buff_cb(struct iio_dev *iio_dev)
> +{
> + struct stm32_dfsdm_adc *adc;
> +
> + if (!iio_dev)
> + return -EINVAL;
> + adc = iio_priv(iio_dev);
> +
> + adc->cb = NULL;
> + adc->cb_priv = NULL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(stm32_dfsdm_release_buff_cb);
> +
> static int stm32_dfsdm_single_conv(struct iio_dev *indio_dev,
> const struct iio_chan_spec *chan, int *res)
> {
> @@ -453,15 +767,41 @@ static int stm32_dfsdm_write_raw(struct iio_dev *indio_dev,
> {
> struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
> + struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[adc->ch_id];
> + unsigned int spi_freq = adc->spi_freq;
> int ret = -EINVAL;
>
> - if (mask == IIO_CHAN_INFO_OVERSAMPLING_RATIO) {
> + switch (mask) {
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> ret = stm32_dfsdm_set_osrs(fl, 0, val);
> if (!ret)
> adc->oversamp = val;
> +
> + return ret;
> +
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + if (!val)
> + return -EINVAL;
> + if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
> + spi_freq = adc->dfsdm->spi_master_freq;
> +
> + if (spi_freq % val)
> + dev_warn(&indio_dev->dev,
> + "Sampling rate not accurate (%d)\n",
> + spi_freq / (spi_freq / val));
> +
> + ret = stm32_dfsdm_set_osrs(fl, 0, (spi_freq / val));
> + if (ret < 0) {
> + dev_err(&indio_dev->dev,
> + "Not able to find parameter that match!\n");
> + return ret;
> + }
> + adc->sample_freq = val;
> +
> + return 0;
> }
>
> - return ret;
> + return -EINVAL;
> }
>
> static int stm32_dfsdm_read_raw(struct iio_dev *indio_dev,
> @@ -494,11 +834,22 @@ static int stm32_dfsdm_read_raw(struct iio_dev *indio_dev,
> *val = adc->oversamp;
>
> return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *val = adc->sample_freq;
> +
> + return IIO_VAL_INT;
> }
>
> return -EINVAL;
> }
>
> +static const struct iio_info stm32_dfsdm_info_audio = {
> + .hwfifo_set_watermark = stm32_dfsdm_set_watermark,
> + .read_raw = stm32_dfsdm_read_raw,
> + .write_raw = stm32_dfsdm_write_raw,
> +};
> +
> static const struct iio_info stm32_dfsdm_info_adc = {
> .read_raw = stm32_dfsdm_read_raw,
> .write_raw = stm32_dfsdm_write_raw,
> @@ -531,6 +882,60 @@ static irqreturn_t stm32_dfsdm_irq(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +/*
> + * Define external info for SPI Frequency and audio sampling rate that can be
> + * configured by ASoC driver through consumer.h API
> + */
> +static const struct iio_chan_spec_ext_info dfsdm_adc_audio_ext_info[] = {
> + /* spi_clk_freq : clock freq on SPI/manchester bus used by channel */
> + {
> + .name = "spi_clk_freq",
> + .shared = IIO_SHARED_BY_TYPE,
> + .read = dfsdm_adc_audio_get_spiclk,
> + .write = dfsdm_adc_audio_set_spiclk,
> + },
> + {},
> +};
> +
> +static int stm32_dfsdm_dma_request(struct iio_dev *indio_dev)
> +{
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct dma_slave_config config;
> + int ret;
> +
> + adc->dma_chan = dma_request_slave_channel(&indio_dev->dev, "rx");
> + if (!adc->dma_chan)
> + return -EINVAL;
> +
> + adc->rx_buf = dma_alloc_coherent(adc->dma_chan->device->dev,
> + DFSDM_DMA_BUFFER_SIZE,
> + &adc->dma_buf, GFP_KERNEL);
> + if (!adc->rx_buf) {
> + ret = -ENOMEM;
> + goto err_release;
> + }
> +
> + /* Configure DMA channel to read data register */
> + memset(&config, 0, sizeof(config));
> + config.src_addr = (dma_addr_t)adc->dfsdm->phys_base;
> + config.src_addr += DFSDM_RDATAR(adc->fl_id);
> + config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> +
> + ret = dmaengine_slave_config(adc->dma_chan, &config);
> + if (ret)
> + goto err_free;
> +
> + return 0;
> +
> +err_free:
> + dma_free_coherent(adc->dma_chan->device->dev, DFSDM_DMA_BUFFER_SIZE,
> + adc->rx_buf, adc->dma_buf);
> +err_release:
> + dma_release_channel(adc->dma_chan);
> +
> + return ret;
> +}
> +
> static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
> struct iio_chan_spec *ch)
> {
> @@ -551,7 +956,12 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
> ch->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
> ch->info_mask_shared_by_all = BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO);
>
> - ch->scan_type.sign = 'u';
> + if (adc->dev_data->type == DFSDM_AUDIO) {
> + ch->scan_type.sign = 's';
> + ch->ext_info = dfsdm_adc_audio_ext_info;
> + } else {
> + ch->scan_type.sign = 'u';
> + }
> ch->scan_type.realbits = 24;
> ch->scan_type.storagebits = 32;
> adc->ch_id = ch->channel;
> @@ -560,6 +970,64 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
> &adc->dfsdm->ch_list[ch->channel]);
> }
>
> +static int stm32_dfsdm_audio_init(struct iio_dev *indio_dev)
> +{
> + struct iio_chan_spec *ch;
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> + struct stm32_dfsdm_channel *d_ch;
> + int ret;
> +
> + ret = stm32_dfsdm_dma_request(indio_dev);
> + if (ret) {
> + dev_err(&indio_dev->dev, "DMA request failed\n");
> + return ret;
> + }
> +
> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
> +
> + ret = iio_triggered_buffer_setup(indio_dev,
> + &iio_pollfunc_store_time,
> + NULL,
> + &stm32_dfsdm_buffer_setup_ops);
> + if (ret) {
> + dev_err(&indio_dev->dev, "Buffer setup failed\n");
> + goto err_dma_disable;
> + }
> +
> + ch = devm_kzalloc(&indio_dev->dev, sizeof(*ch), GFP_KERNEL);
> + if (!ch)
> + return -ENOMEM;
> +
> + ch->scan_index = 0;
> + ret = stm32_dfsdm_adc_chan_init_one(indio_dev, ch);
> + if (ret < 0) {
> + dev_err(&indio_dev->dev, "channels init failed\n");
> + goto err_buffer_cleanup;
> + }
> + ch->info_mask_separate = BIT(IIO_CHAN_INFO_SAMP_FREQ);
> +
> + d_ch = &adc->dfsdm->ch_list[adc->ch_id];
> + if (d_ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
> + adc->spi_freq = adc->dfsdm->spi_master_freq;
> +
> + indio_dev->num_channels = 1;
> + indio_dev->channels = ch;
> +
> + return 0;
> +
> +err_buffer_cleanup:
> + iio_triggered_buffer_cleanup(indio_dev);
> +
> +err_dma_disable:
> + if (adc->dma_chan) {
> + dma_free_coherent(adc->dma_chan->device->dev,
> + DFSDM_DMA_BUFFER_SIZE,
> + adc->rx_buf, adc->dma_buf);
> + dma_release_channel(adc->dma_chan);
> + }
> + return ret;
> +}
> +
> static int stm32_dfsdm_adc_init(struct iio_dev *indio_dev)
> {
> struct iio_chan_spec *ch;
> @@ -612,11 +1080,20 @@ static const struct stm32_dfsdm_dev_data stm32h7_dfsdm_adc_data = {
> .init = stm32_dfsdm_adc_init,
> };
>
> +static const struct stm32_dfsdm_dev_data stm32h7_dfsdm_audio_data = {
> + .type = DFSDM_AUDIO,
> + .init = stm32_dfsdm_audio_init,
> +};
> +
> static const struct of_device_id stm32_dfsdm_adc_match[] = {
> {
> .compatible = "st,stm32-dfsdm-adc",
> .data = &stm32h7_dfsdm_adc_data,
> },
> + {
> + .compatible = "st,stm32-dfsdm-dmic",
> + .data = &stm32h7_dfsdm_audio_data,
> + },
> {}
> };
>
> @@ -667,8 +1144,13 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> name = devm_kzalloc(dev, sizeof("dfsdm-adc0"), GFP_KERNEL);
> if (!name)
> return -ENOMEM;
> - iio->info = &stm32_dfsdm_info_adc;
> - snprintf(name, sizeof("dfsdm-adc0"), "dfsdm-adc%d", adc->fl_id);
> + if (dev_data->type == DFSDM_AUDIO) {
> + iio->info = &stm32_dfsdm_info_audio;
> + snprintf(name, sizeof("dfsdm-pdm0"), "dfsdm-pdm%d", adc->fl_id);
> + } else {
> + iio->info = &stm32_dfsdm_info_adc;
> + snprintf(name, sizeof("dfsdm-adc0"), "dfsdm-adc%d", adc->fl_id);
> + }
> iio->name = name;
>
> /*
> @@ -700,7 +1182,10 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> - return iio_device_register(iio);
> + iio_device_register(iio);
> + if (dev_data->type == DFSDM_AUDIO)
> + return devm_of_platform_populate(&pdev->dev);
> + return 0;
> }
>
> static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
> @@ -709,7 +1194,14 @@ static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
> struct iio_dev *indio_dev = iio_priv_to_dev(adc);
>
> iio_device_unregister(indio_dev);
> -
> + if (indio_dev->pollfunc)
> + iio_triggered_buffer_cleanup(indio_dev);
> + if (adc->dma_chan) {
> + dma_free_coherent(adc->dma_chan->device->dev,
> + DFSDM_DMA_BUFFER_SIZE,
> + adc->rx_buf, adc->dma_buf);
> + dma_release_channel(adc->dma_chan);
> + }
> return 0;
> }
>
> diff --git a/include/linux/iio/adc/stm32-dfsdm-adc.h b/include/linux/iio/adc/stm32-dfsdm-adc.h
> new file mode 100644
> index 0000000..e7dc7a5
> --- /dev/null
> +++ b/include/linux/iio/adc/stm32-dfsdm-adc.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * This file discribe the STM32 DFSDM IIO driver API for audio part
> + *
> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
> + * Author(s): Arnaud Pouliquen <arnaud.pouliquen@st.com>.
> + */
> +
> +#ifndef STM32_DFSDM_ADC_H
> +#define STM32_DFSDM_ADC_H
> +
> +int stm32_dfsdm_get_buff_cb(struct iio_dev *iio_dev,
> + int (*cb)(const void *data, size_t size,
> + void *private),
> + void *private);
> +int stm32_dfsdm_release_buff_cb(struct iio_dev *iio_dev);
> +
> +#endif
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-12 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513076836.25007.641.camel@linux.intel.com>
On 12/12/2017 05:07 AM, Andy Shevchenko wrote:
> Not ACPI standards as of my knowledge. ACPI standard defines a common
> scheme how to define properties, it doesn't tell anything about property
> names or any mappings between names to values or names to "OS
> subsystem").
There was an attempt a while back to standardize this like we do for
device tree, but it fell apart. Device-specific ACPI-only properties
are not standarized. This driver is initialized only on ACPI systems.
It has no device tree binding.
> As for GPIO we just follow *de facto* what DT has right now, i.e. "xxx-
> gpio" or "xxx-gpios" pattern is used to map ACPI standard resource to a
> GPIO name. That's how GPIO ACPI lib is being developed.
GPIOs in device tree are defined completely differently than in ACPI.
On DT, the kernel controls the pin muxing. On ACPI, pins are muxed by
firmware and never re-muxed by the operating system. So all this driver
does is expose a few pins as simple GPIOs.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-12 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513073105.25007.618.camel@linux.intel.com>
On 12/12/2017 04:05 AM, Andy Shevchenko wrote:
>> +static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
>> + {"QCOM8001", QDF2XXX_V1},
>> + {"QCOM8002", QDF2XXX_V2},
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
>>
>> + const struct acpi_device_id *id =
>> + acpi_match_device(qdf2xxx_acpi_ids, &pdev->dev);
> JFYI: there is no need to move IDs like this.
> Use members of struct device_driver wisely.
I have to move it, otherwise I get:
drivers/pinctrl/qcom/pinctrl-qdf2xxx.c:49:21: error: 'qdf2xxx_acpi_ids'
undeclared (first use in this function); did you mean 'qdf2xxx_pinctrl'?
I reference the structure in qdf2xxx_pinctrl_probe().
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/4] [v2] gpiolib: add bitmask for valid GPIO lines
From: Timur Tabi @ 2017-12-12 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513072725.25007.614.camel@linux.intel.com>
On 12/12/2017 03:58 AM, Andy Shevchenko wrote:
> On Fri, 2017-12-01 at 17:28 -0600, Timur Tabi wrote:
>> Add support for specifying that some GPIOs within a range are
>> unavailable.
>> Some systems have a sparse list of GPIOs, where a range of GPIOs is
>> specified (usually 0 to n-1), but some subset within that range is
>> absent or unavailable for whatever reason.
>>
>> To support this, allow drivers to specify a bitmask of GPIOs that
>> are present or absent. Gpiolib will then block access to those that
>> are absent.
>
>> - status = gpiochip_irqchip_init_valid_mask(chip);
>> + status = gpiochip_init_valid_mask(chip);
>> if (status)
>> goto err_remove_from_list;
>>
>> + status = gpiochip_irqchip_init_valid_mask(chip);
>> + if (status)
>> + goto err_remove_valid_mask;
>
> Yes, this way it looks good!
I've discovered that I can remove all this code. I don't need a valid
mask, all I need to do is block the request properly.
>> +static bool gpiochip_available(const struct gpio_chip *gpiochip,
>> + unsigned int offset)
>> +{
>
>> + pr_info("%s:%u offset=%u\n", __func__, __LINE__, offset);
>
> Debug leftover?
Fixed, thanks.
>
>> +
>> + /* No mask means all valid */
>> + if (likely(!gpiochip->valid_mask))
>> + return true;
>> +
>> + return test_bit(offset, gpiochip->valid_mask);
>
> Not sure which one is better
> return test_bit();
> or
> return !!test_bit();
I've removed this function also.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813
From: Jonathan Cameron @ 2017-12-12 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <873410df-046e-bd86-584d-0d35b9d8c993@free-electrons.com>
On Mon, 11 Dec 2017 09:35:43 +0100
Quentin Schulz <quentin.schulz@free-electrons.com> wrote:
> Hi Jonathan,
>
> On 10/12/2017 17:49, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:51 +0100
> > Quentin Schulz <quentin.schulz@free-electrons.com> wrote:
> >
> >> The X-Powers AXP813 PMIC has got some slight differences from
> >> AXP20X/AXP22X PMICs:
> >> - the maximum voltage supplied by the PMIC is 4.35 instead of 4.36/4.24
> >> for AXP20X/AXP22X,
> >> - the constant charge current formula is different,
> >>
> >> It also has a bit to tell whether the battery percentage returned by the
> >> PMIC is valid.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> >
> > I'd use switch statements when matching the IDs as that'll be more elegant
> > as you perhaps add further devices going forward...
> >
> > Other than that, looks good to me.
> >
>
> Well, I was wondering if it shouldn't be better to define a structure
> for each device containing their quirks, functions, etc... like it is
> done for the ADC or the ACIN power supply driver part.
>
Even better.
> struct axp20x_data {
> bool has_valid_fg_reg;
> void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val);
> void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val);
> int get_max_voltage(struct axp20x_batt_ps *axp, int *val);
> [...]
> };
>
> static const struct of_device_id axp20x_battery_ps_id[] = {
> { .compatible = "x-powers,axp209-battery-power-supply", .data = (void
> *)&axp209_data, }, {}
> };
>
> void probe()
> {
> [...]
> axp20x_batt->info = of_device_get_match_data(&pdev->dev);
> [...]
> }
>
> Sebastian, any objection on doing this?
>
> Thanks,
> Quentin
>
> > Jonathan
> >
> >> ---
> >> drivers/power/supply/axp20x_battery.c | 44 +++++++++++++++++++++++++++-
> >> 1 file changed, 43 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
> >> index 7494f0f..cb30302 100644
> >> --- a/drivers/power/supply/axp20x_battery.c
> >> +++ b/drivers/power/supply/axp20x_battery.c
> >> @@ -46,6 +46,8 @@
> >> #define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
> >> #define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
> >>
> >> +#define AXP813_CHRG_CTRL1_TGT_4_35V (3 << 5)
> >> +
> >> #define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
> >> #define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
> >>
> >> @@ -123,10 +125,41 @@ static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> >> return 0;
> >> }
> >>
> >> +static int axp813_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> >> + int *val)
> >> +{
> >> + int ret, reg;
> >> +
> >> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
> >
> > You could do a lookup based from a table instead which might
> > be ever so slightly more elegant..
> >
> >> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
> >> + *val = 4100000;
> >> + break;
> >> + case AXP20X_CHRG_CTRL1_TGT_4_15V:
> >> + *val = 4150000;
> >> + break;
> >> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
> >> + *val = 4200000;
> >> + break;
> >> + case AXP813_CHRG_CTRL1_TGT_4_35V:
> >> + *val = 4350000;
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val)
> >> {
> >> if (axp->axp_id == AXP209_ID)
> >> *val = *val * 100000 + 300000;
> >> + else if (axp->axp_id == AXP813_ID)
> >> + *val = *val * 200000 + 200000;
> >> else
> >> *val = *val * 150000 + 300000;
> >
> > Switch?
> >
> >> }
> >> @@ -135,6 +168,8 @@ static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val)
> >> {
> >> if (axp->axp_id == AXP209_ID)
> >> *val = (*val - 300000) / 100000;
> >> + else if (axp->axp_id == AXP813_ID)
> >> + *val = (*val - 200000) / 200000;
> >> else
> >> *val = (*val - 300000) / 150000;
> >> }
> >> @@ -269,7 +304,8 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> >> if (ret)
> >> return ret;
> >>
> >> - if (axp20x_batt->axp_id == AXP221_ID &&
> >> + if ((axp20x_batt->axp_id == AXP221_ID ||
> >> + axp20x_batt->axp_id == AXP813_ID) &&
> >> !(reg & AXP22X_FG_VALID))
> >> return -EINVAL;
> >>
> >> @@ -284,6 +320,9 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> >> if (axp20x_batt->axp_id == AXP209_ID)
> >> return axp20x_battery_get_max_voltage(axp20x_batt,
> >> &val->intval);
> >> + else if (axp20x_batt->axp_id == AXP813_ID)
> >> + return axp813_battery_get_max_voltage(axp20x_batt,
> >> + &val->intval);
> >> return axp22x_battery_get_max_voltage(axp20x_batt,
> >> &val->intval);
> >
> > Worth converting to a switch statement to make it more elegant for future
> > devices?
> >
> >>
> >> @@ -467,6 +506,9 @@ static const struct of_device_id axp20x_battery_ps_id[] = {
> >> }, {
> >> .compatible = "x-powers,axp221-battery-power-supply",
> >> .data = (void *)AXP221_ID,
> >> + }, {
> >> + .compatible = "x-powers,axp813-battery-power-supply",
> >> + .data = (void *)AXP813_ID,
> >> }, { /* sentinel */ },
> >> };
> >> MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
> >
>
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Russell King - ARM Linux @ 2017-12-12 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Brd7pZtF5e8RLu63MpUo1Sc01vWC1WeccEMTkGBL0Rqw@mail.gmail.com>
On Tue, Dec 12, 2017 at 05:44:07PM -0200, Fabio Estevam wrote:
> Hi Paul,
>
> On Tue, Dec 12, 2017 at 5:36 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> >> Ok, just tested with CONFIG_BL_SWITCHER=y on a imx6q-cubox-i:
> >
> > Just to confirm, your dmesg below is illustrating the hang, correct?
>
> Sorry for not being clear. Let me clarify my tests.
>
> If I run a mainline kernel on a imx6q I do see the exact same RCU
> warning as reported by Peng Fan in this thread.
>
> This is 100% reproducible: the first time I do a suspend/resume after
> boot the RCU warning is present. Subsequent suspend/resume cycles do
> not show the warning.
>
> With your patch applied I don't see the RCU warning anymore.
>
> I originally tested the standard imx_v6_v7_defconfig and also a kernel
> with CONFIG_BL_SWITCHER=y as suggested by Russell.
>
> In my tests even with CONFIG_BL_SWITCHER=y suspend/resume works fine
> and no more RCU warnings were seen.
>
> The dmesg I shared shows the normal output without the RCU warning.
Which is exactly what I would expect with imx6. Just because it
works for imx6 does not mean it works for everyone.
I need to get Will Deacon's permission before I can send an email
containing our discussion on the points here from 2013, and that
probably won't happen until tomorrow - and I'm having to do that
because none of you seem to be listening to what I'm saying wrt
that spinlock.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH net-next v5 2/2] net: thunderx: add timestamping support
From: Joe Perches @ 2017-12-12 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233641.cs7zdw34qkngicmj@localhost>
On Mon, 2017-12-11 at 15:36 -0800, Richard Cochran wrote:
> On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote:
> > @@ -880,6 +889,46 @@ static void nic_pause_frame(struct nicpf *nic, int vf, struct pfc *cfg)
> > }
> > }
> >
> > +/* Enable or disable HW timestamping by BGX for pkts received on a LMAC */
> > +static void nic_config_timestamp(struct nicpf *nic, int vf, struct set_ptp *ptp)
> > +{
> > + struct pkind_cfg *pkind;
> > + u8 lmac, bgx_idx;
> > + u64 pkind_val, pkind_idx;
> > +
> > + if (vf >= nic->num_vf_en)
> > + return;
> > +
> > + bgx_idx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
> > + lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
> > +
> > + pkind_idx = lmac + bgx_idx * MAX_LMAC_PER_BGX;
> > + pkind_val = nic_reg_read(nic, NIC_PF_PKIND_0_15_CFG | (pkind_idx << 3));
> > + pkind = (struct pkind_cfg *)&pkind_val;
> > +
> > + if (ptp->enable && !pkind->hdr_sl) {
> > + /* Skiplen to exclude 8byte timestamp while parsing pkt
> > + * If not configured, will result in L2 errors.
> > + */
> > + pkind->hdr_sl = 4;
> > + /* Adjust max packet length allowed */
> > + pkind->maxlen += (pkind->hdr_sl * 2);
Are all compilers smart enough to set this to 8?
I rather doubt a compiler is even allowed to.
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-12 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212193638.GH7829@linux.vnet.ibm.com>
Hi Paul,
On Tue, Dec 12, 2017 at 5:36 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
>> Ok, just tested with CONFIG_BL_SWITCHER=y on a imx6q-cubox-i:
>
> Just to confirm, your dmesg below is illustrating the hang, correct?
Sorry for not being clear. Let me clarify my tests.
If I run a mainline kernel on a imx6q I do see the exact same RCU
warning as reported by Peng Fan in this thread.
This is 100% reproducible: the first time I do a suspend/resume after
boot the RCU warning is present. Subsequent suspend/resume cycles do
not show the warning.
With your patch applied I don't see the RCU warning anymore.
I originally tested the standard imx_v6_v7_defconfig and also a kernel
with CONFIG_BL_SWITCHER=y as suggested by Russell.
In my tests even with CONFIG_BL_SWITCHER=y suspend/resume works fine
and no more RCU warnings were seen.
The dmesg I shared shows the normal output without the RCU warning.
Thanks
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Paul E. McKenney @ 2017-12-12 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DBMpCHfgmNND6=qJD+sxOLMPFqEsyz+GiBVhMzN3H+Zg@mail.gmail.com>
On Tue, Dec 12, 2017 at 04:11:07PM -0200, Fabio Estevam wrote:
> Hi Russell,
>
> On Tue, Dec 12, 2017 at 3:34 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>
> > It's fundamentally unsafe.
> >
> > You need to test with CONFIG_BL_SWITCHER enabled - there's spinlocks
> > in smp_call_function_single() path that are conditional on that symbol.
> > If CONFIG_BL_SWITCHER is disabled, then the spinlocks are not present.
>
> Ok, just tested with CONFIG_BL_SWITCHER=y on a imx6q-cubox-i:
Just to confirm, your dmesg below is illustrating the hang, correct?
Thanx, Paul
> # echo enabled > /sys/class/tty/ttymxc0/power/wakeup
> # echo mem > /sys/power/state
> [ 10.503462] PM: suspend entry (deep)
> [ 10.507479] PM: Syncing filesystems ... done.
> [ 10.555024] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [ 10.564511] OOM killer disabled.
> [ 10.567760] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) d.
> [ 10.577420] Suspending console(s) (use no_console_suspend to debug)
> [ 10.657748] PM: suspend devices took 0.080 seconds
> [ 10.669329] Disabling non-boot CPUs ...
> [ 10.717049] IRQ17 no longer affine to CPU1
> [ 10.837141] Enabling non-boot CPUs ...
> [ 10.839386] CPU1 is up
> [ 10.840342] CPU2 is up
> [ 10.841300] CPU3 is up
> [ 11.113735] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
> [ 11.115676] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 11.117595] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 11.121014] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [ 11.124454] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [ 11.177299] ata1: SATA link down (SStatus 0 SControl 300)
> [ 11.181930] PM: resume devices took 0.330 seconds
> [ 11.243729] OOM killer enabled.
> [ 11.246886] Restarting tasks ... done.
> [ 11.253012] PM: suspend exit
>
^ permalink raw reply
* [PATCH v5 15/30] arm64/sve: Signal handling support
From: Kees Cook @ 2017-12-12 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212111125.GL22781@e103592.cambridge.arm.com>
On Tue, Dec 12, 2017 at 3:11 AM, Dave Martin <Dave.Martin@arm.com> wrote:
> On Tue, Dec 12, 2017 at 10:40:30AM +0000, Will Deacon wrote:
>> On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
>> > On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
>> > >> My question is mainly: why not just use copy_*() everywhere instead?
>> > >> Having these things so spread out makes it fragile, and there's very
>> > >> little performance benefit from using __copy_*() over copy_*().
>> > >
>> > > I think that's more of a general question. Why not just remove the __
>> > > versions from the kernel entirely if they're not worth the perf?
>> >
>> > That has been something Linus has strongly suggested in the past, so
>> > I've kind of been looking for easy places to drop the __copy_*
>> > versions. :)
>>
>> Tell you what then: I'll Ack the arm64 patch if it's part of a series
>> removing the thing entirely :p
>>
>> I guess we'd still want to the validation of the whole sigframe though,
>> so we don't end up pushing half a signal stack before running into an
>> access_ok failure?
>
> That's an interesting question. In many cases access_ok() might become
> redundant, but for syscalls that you don't want to have side-effects
> on user memory on failure it's still relevant.
>
> In the signal case we'd still an encompassing access_ok() to prevent
> stack guard overruns, because the signal frame can be large and isn't
> written or read contiguously or in a well-defined order.
Yeah, I think bailing early is fine. I think the existing access_ok()
checks are fine; I wouldn't want to drop those.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU
From: Paul E. McKenney @ 2017-12-12 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212173759.GE10595@n2100.armlinux.org.uk>
On Tue, Dec 12, 2017 at 05:37:59PM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote:
> > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> > does so after RCU has stopped watching the outgoing CPU, which results
> > in lockdep complaints because complete() invokes functions containing RCU
> > readers. This patch therefore uses Thomas Gleixner's trick of delegating
> > the complete() call to a surviving CPU via smp_call_function_single().
> >
> > Reported-by: Peng Fan <van.freenix@gmail.com>
> > Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Tested-by: Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: <linux-arm-kernel@lists.infradead.org>
>
> As I just described in response to Fabio's testing, this doesn't solve
> anything if CONFIG_BL_SWITCHER is enabled. We could lose the unlock of
> a spinlock in the GIC code for sending the IPI. As I already said
> previously in our discussion (but I guess you just don't believe me):
Sorry, Russell, but most days I don't even believe myself. So it is
nothing personal, just one of the occupational hazards of being me.
> "2. there's some optional locking in the GIC driver that cause problems
> for the cpu dying path.
>
> The concensus last time around was that the IPI solution is a non-
> starter, so the seven year proven-reliable solution (disregarding the
> RCU warning) persists because I don't think anyone came up with a
> better solution."
>
> Using smp_call_function_single() invokes the IPI paths.
OK, another approach is to have the dying CPU simply set an in-memory
flag, which a surviving CPU polls for. There are of course any number
of ways of doing the polling loop.
So what bad thing happens when you use that approach?
Thanx, Paul
^ permalink raw reply
* [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU
From: Paul E. McKenney @ 2017-12-12 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212174046.gn4t3qeck3bq7scw@tarshish>
On Tue, Dec 12, 2017 at 07:40:46PM +0200, Baruch Siach wrote:
> Hi Paul,
>
> On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote:
> > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> > does so after RCU has stopped watching the outgoing CPU, which results
> > in lockdep complaints because complete() invokes functions containing RCU
> > readers. This patch therefore uses Thomas Gleixner's trick of delegating
> > the complete() call to a surviving CPU via smp_call_function_single().
> >
> > Reported-by: Peng Fan <van.freenix@gmail.com>
> > Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Tested-by: Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
>
> Fabio reported only once, though he might have tested twice.
Actually, he did test twice. Apparently this patch has problems
with CONFIG_BL_SWITCHER=y kernels.
But yes, I guess I did get a bit carried away with the Tested-by's,
didn't I? ;-)
Thanx, Paul
> baruch
>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: <linux-arm-kernel@lists.infradead.org>
> >
> > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> > index b4fbf00ee4ad..75f85e20aafa 100644
> > --- a/arch/arm/kernel/smp.c
> > +++ b/arch/arm/kernel/smp.c
> > @@ -267,6 +267,14 @@ void __cpu_die(unsigned int cpu)
> > }
> >
> > /*
> > + * Invoke complete() on behalf of the outgoing CPU.
> > + */
> > +static void arch_cpu_idle_dead_complete(void *arg)
> > +{
> > + complete(&cpu_died);
> > +}
> > +
> > +/*
> > * Called from the idle thread for the CPU which has been shutdown.
> > *
> > * Note that we disable IRQs here, but do not re-enable them
> > @@ -293,9 +301,11 @@ void arch_cpu_idle_dead(void)
> > /*
> > * Tell __cpu_die() that this CPU is now safe to dispose of. Once
> > * this returns, power and/or clocks can be removed at any point
> > - * from this CPU and its cache by platform_cpu_kill().
> > + * from this CPU and its cache by platform_cpu_kill(). We cannot
> > + * call complete() this late, so we delegate it to an online CPU.
> > */
> > - complete(&cpu_died);
> > + smp_call_function_single(cpumask_first(cpu_online_mask),
> > + arch_cpu_idle_dead_complete, NULL, 0);
> >
> > /*
> > * Ensure that the cache lines associated with that completion are
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
>
^ permalink raw reply
* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Johan Hovold @ 2017-12-12 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212180731.GA22805@red-moon>
On Tue, Dec 12, 2017 at 06:07:31PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Dec 12, 2017 at 11:25:37AM -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 11, 2017 at 10:42:33AM +0000, Lorenzo Pieralisi wrote:
> > > On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote:
> > > > On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> > > > > Fix child-node lookup during initialisation which was using the wrong
> > > > > OF-helper and ended up searching the whole device tree depth-first
> > > > > starting at the parent rather than just matching on its children.
> > > > >
> > > > > To make things worse, the parent pci node could end up being prematurely
> > > > > freed as of_find_node_by_name() drops a reference to its first argument.
> > > > > Any matching child interrupt-controller node was also leaked.
> > > > >
> > > > > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > > > > Cc: stable <stable@vger.kernel.org> # 3.18
> > > > > Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> > > > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > ---
> > > > >
> > > > > v2
> > > > > - amend commit message and mention explicitly that of_find_node_by_name()
> > > > > drops a reference to the start node
> > > > > - add Murali's and Lorenzo's acks
> > > >
> > > > This one hasn't shown up in linux-next, so sending a reminder to make
> > > > sure it doesn't fall between the cracks.
> > >
> > > Hi Johan,
> > >
> > > yes it is in the list of fixes to be sent upstream - I was about to
> > > ask Bjorn to apply it.
> >
> > Is this something that needs to be merged for v4.15? If so, I need to
> > be able to defend it to Linus as being a critical fix. If the issue
> > been around for 3 years (v3.18 was tagged Dec 7 2014), that requires
> > pretty "clear and present danger."
> >
> > From the commit log, I see a sub-optimal search (not critical), a
> > possible use-after-free (could conceivably be critical if people are
> > tripping over this, but would need more specifics about that), and a
> > leak (not critical).
> >
> > Given what I can see now, my inclination would be for Lorenzo to queue
> > it for v4.16, which would still get in linux-next soonish.
>
> It is fine by me and I think, as already mentioned, that the stable
> tag is dubious so I will probably drop it.
The unbalanced put can indeed cause serious problems, for example, after
probe deferrals. Crashes after probe deferrals has been reported for
other drivers with the same type of bug, and I have reproduced it
locally (using yet another driver).
I'm also fine with holding this one off for 4.16 (as we're at -rc3), but
I do think the stable tag is still warranted.
Johan
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-12 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcab4daa-678c-ee48-a5ec-9d22c535ff29@osg.samsung.com>
Hello Shuah,
On Tue, Dec 12, 2017 at 7:26 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote:
[snip]
>>>
>>> Not directly. I still didn't find time to properly add support for
>>> devices, which were left in-working state (with active DMA
>>> transactions) by bootloader, but due to some other changes in the
>>> order of operations during boot process, power domains are
>>> initialized very early and due to temporary lack of devices (which
>>> are not yet added to the system), are turned off. This practically
>>> stops FIMD for scanning framebuffer and "solves" this issue.
>>>
>>> I've checked now and Exynos Snow Chromebook boots fine with IOMMU
>>> support enabled, both with v4.15-rc3 and linux-next.
>
> Would it make sense to enable EXYNOS_IOMMU in exynos_defconfig. I sent
> a patch to do that a while back. The decision at the time to not pull
> that patch is was based on systems not booting with it enabled.
>
> Is it time to revisit that or the recommendation is for IOMMU to be
> enabled in configs manually on systems it is safe to do so?
>
Yes, I think it would be good to have it enabled by default if that
doesn't cause boot issues anymore.
Could you please resend your patch and cc Marek and me so we can test
on Snow and Peach Chromebooks?
> thanks,
> -- Shuah
Best regards,
Javier
^ permalink raw reply
* [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals
From: Peter Maydell @ 2017-12-12 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211144937.4537-8-marc.zyngier@arm.com>
On 11 December 2017 at 14:49, Marc Zyngier <marc.zyngier@arm.com> wrote:
> We lack a way to encode operations such as AND, ORR, EOR that take
> an immediate value. Doing so is quite involved, and is all about
> reverse engineering the decoding algorithm described in the
> pseudocode function DecodeBitMasks().
Is it possible to borrow the existing tested implementation
which a compiler surely must have for this, rather than having
to reinvent this rather complicated wheel? Here's LLVM's version:
https://github.com/llvm-mirror/llvm/blob/93e6e5414ded14bcbb233baaaa5567132fee9a0c/lib/Target/AArch64/MCTargetDesc/AArch64AddressingModes.h#L209
(confirming that the LLVM license is GPLv2 compatible is
left as an exercise for the reader, but I'm pretty sure it is)
PS: typo in subject: 'literal'.
thanks
-- PMM
^ permalink raw reply
* [PATCH 3/3] ARM: dts: r8a7745: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0fa7861..765a80d 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -235,6 +235,36 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer at ffca0000 {
+ compatible = "renesas,r8a7745-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ };
+
+ cmt1: timer at e6130000 {
+ compatible = "renesas,r8a7745-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ };
+
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7745-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 59860c8..0e2834a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -262,6 +262,36 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer at ffca0000 {
+ compatible = "renesas,r8a7743-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ };
+
+ cmt1: timer at e6130000 {
+ compatible = "renesas,r8a7743-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ };
+
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7743-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] Add CMT support to r8a774[35]
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: linux-arm-kernel
This series adds CMT support for r8a7743 and r8a7745.
Thanks,
Fabrizio Castro (3):
dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
ARM: dts: r8a7743: Add CMT SoC specific support
ARM: dts: r8a7745: Add CMT SoC specific support
.../devicetree/bindings/timer/renesas,cmt.txt | 12 ++++++---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++
arch/arm/boot/dts/r8a7745.dtsi | 30 ++++++++++++++++++++++
3 files changed, 69 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals
From: James Morse @ 2017-12-12 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211144937.4537-8-marc.zyngier@arm.com>
Hi Marc,
On 11/12/17 14:49, Marc Zyngier wrote:
> We lack a way to encode operations such as AND, ORR, EOR that take
> an immediate value. Doing so is quite involved, and is all about
> reverse engineering the decoding algorithm described in the
> pseudocode function DecodeBitMasks().
As this is over my head, I've been pushing random encodings through gas/objdump
and then tracing them through here.... can this encode 0xf80000000fffffff?
gas thinks this is legal:
| 0: 92458000 and x0, x0, #0xf80000000fffffff
I make that N=1, S=0x20, R=0x05.
(I'm still working out what 'S' means)
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index 7e432662d454..326b17016485 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> +static u32 aarch64_encode_immediate(u64 imm,
> + enum aarch64_insn_variant variant,
> + u32 insn)
> +{
> + unsigned int immr, imms, n, ones, ror, esz, tmp;
> + u64 mask;
[...]
> + /* N is only set if we're encoding a 64bit value */
> + n = esz == 64;
> +
> + /* Trim imm to the element size */
> + mask = BIT(esz - 1) - 1;
> + imm &= mask;
Won't this lose the top bit of a 64bit immediate?
(but then you put it back later, so something funny is going on)
This becomes 0x780000000fffffff,
> +
> + /* That's how many ones we need to encode */
> + ones = hweight64(imm);
meaning we're short a one here,
> +
> + /*
> + * imms is set to (ones - 1), prefixed with a string of ones
> + * and a zero if they fit. Cap it to 6 bits.
> + */
> + imms = ones - 1;
> + imms |= 0xf << ffs(esz);
> + imms &= BIT(6) - 1;
so imms is 0x1f, not 0x20.
> + /* Compute the rotation */
> + if (range_of_ones(imm)) {
> + /*
> + * Pattern: 0..01..10..0
> + *
> + * Compute how many rotate we need to align it right
> + */
> + ror = ffs(imm) - 1;
(how come range_of_ones() uses __ffs64() on the same value?)
> + } else {
> + /*
> + * Pattern: 0..01..10..01..1
> + *
> + * Fill the unused top bits with ones, and check if
> + * the result is a valid immediate (all ones with a
> + * contiguous ranges of zeroes).
> + */
> + imm |= ~mask;
but here we put the missing one back,
> + if (!range_of_ones(~imm))
> + return AARCH64_BREAK_FAULT;
meaning we pass this check and carry on, (even though 0x780000000fffffff isn't a
legal value)
(this next bit I haven't worked out yet)
> + /*
> + * Compute the rotation to get a continuous set of
> + * ones, with the first bit set at position 0
> + */
> + ror = fls(~imm);
> + }
> +
> + /*
> + * immr is the number of bits we need to rotate back to the
> + * original set of ones. Note that this is relative to the
> + * element size...
> + */
> + immr = (esz - ror) & (esz - 1);
If I've followed this through correctly, this results in:
| 0: 92457c00 and x0, x0, #0xf800000007ffffff
... which wasn't the immediate I started with.
Unless I've gone wrong, I think the 'Trim imm to the element size' code needs to
move up into the esz-reducing loop so it doesn't happen for a 64bit immediate.
Thanks,
James
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Shuah Khan @ 2017-12-12 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <beef1026-3dbe-5284-d2fa-a2298c52e7c0@osg.samsung.com>
On 12/12/2017 07:47 AM, Shuah Khan wrote:
> On 12/12/2017 01:47 AM, Marek Szyprowski wrote:
>> Hi Javier,
>>
>> On 2017-12-12 09:00, Javier Martinez Canillas wrote:
>>> On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> On 2017-12-12 00:25, Shuah Khan wrote:
>>>>> On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
>>>>>> On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
>>>>>>> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas
>>>>>>> wrote:
>>>>>>>> So I gave a quick look to this, and at the very least there's a bug in
>>>>>>>> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
>>>>>>>> exynos: Add status property to Exynos 542x Mixer nodes").
>>>>>>>>
>>>>>>>> I've posted a fix for that:
>>>>>>>>
>>>>>>>> https://patchwork.kernel.org/patch/10105921/
>>>>>>>>
>>>>>>>> I believe this could be also be the cause for the boot failure, since
>>>>>>>> I see in the boot log that things start to go wrong after exynos-drm
>>>>>>>> fails to bind the HDMI component:
>>>>>>>>
>>>>>>>> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
>>>>>>>> 0xc1398690): -1
>>>>>>> Umm, -1 ?? Looking that error code up in
>>>>>>> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>>>>>>>
>>>>>>> I suspect that's someone just returning -1 because they're lazy...
>>>>>>> which is real bad form and needs fixing.
>>>>>> Oh, it really is -EPERM:
>>>>>>
>>>>>> struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device
>>>>>> *drm_dev,
>>>>>> ???????????????????????????????????????? enum exynos_drm_output_type
>>>>>> out_type)
>>>>>> {
>>>>>> ????????? struct drm_crtc *crtc;
>>>>>>
>>>>>> ????????? drm_for_each_crtc(crtc, drm_dev)
>>>>>> ????????????????? if (to_exynos_crtc(crtc)->type == out_type)
>>>>>> ????????????????????????? return to_exynos_crtc(crtc);
>>>>>>
>>>>>> ????????? return ERR_PTR(-EPERM);
>>>>>> }
>>>>>>
>>>>>> Does "Operation not permitted" really convey the error here?? It doesn't
>>>>>> look like a permission error to me.
>>>>>>
>>>>>> Can we please avoid abusing errno codes?
>>>>> I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
>>>>> with top commit g968edbd worked just fine for me last Friday. I ran
>>>>> several
>>>>> tests and everything checked out except the exynos-gsc lockdep issue I
>>>>> sent
>>>>> a 4.14 patch for.
>>>>>
>>>>> However, with 4.15-rc3, dmesg is gets filled with
>>>>>
>>>>> [? 342.337181] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 342.337470] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 342.337851] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.382346] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.396682] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.399244] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.399496] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.399848] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.400163] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.400495] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.401294] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.401595] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>>
>>>>> Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
>>>>>
>>>>> I will start bisect and try to isolate the problem. I suspect this is
>>>>> related to dts
>>>>> changes perhaps? I used to this problem a while back and it has been
>>>>> fixed.
>>>>
>>>> This warning has been added intentionally, see following discussions:
>>>> https://patchwork.kernel.org/patch/10034919/
>>>> https://patchwork.kernel.org/patch/10070475/
>>>>
>>>> This means that your test apps should be updated or you should enable Exynos
>>>> IOMMU support in your config. Maybe it is a good time to finally enable it
>>>> in exynos_defconfig.
>>>>
>>> Has the issue that the boot-loader keeps the display controller
>>> enabled and scanning pages on the Exynos Chromebooks resolved?
>>>
>>> I think that's that preventing to enable it by default in
>>> exynos_defconfig since it caused boot failures when enabled on these
>>> machines. I don't follow exynos development too closely nowadays so
>>> maybe there's a fix in place now.
>>
>> Not directly. I still didn't find time to properly add support for
>> devices, which were left in-working state (with active DMA
>> transactions) by bootloader, but due to some other changes in the
>> order of operations during boot process, power domains are
>> initialized very early and due to temporary lack of devices (which
>> are not yet added to the system), are turned off. This practically
>> stops FIMD for scanning framebuffer and "solves" this issue.
>>
>> I've checked now and Exynos Snow Chromebook boots fine with IOMMU
>> support enabled, both with v4.15-rc3 and linux-next.
Would it make sense to enable EXYNOS_IOMMU in exynos_defconfig. I sent
a patch to do that a while back. The decision at the time to not pull
that patch is was based on systems not booting with it enabled.
Is it time to revisit that or the recommendation is for IOMMU to be
enabled in configs manually on systems it is safe to do so?
thanks,
-- Shuah
^ permalink raw reply
* [PATCH 5/5] ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
This patch enables SGTL5000 audio codec on the carrier board.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 54470c6..2070b14 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -20,6 +20,20 @@
stdout-path = "serial0:115200n8";
};
+ audio_clock: audio_clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ reg_1p5v: 1p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P5V";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
vcc_sdhi1: regulator-vcc-sdhi1 {
compatible = "regulator-fixed";
@@ -83,6 +97,16 @@
compatible = "ti,bq32000";
reg = <0x68>;
};
+
+ sgtl5000: codec at 0a {
+ compatible = "fsl,sgtl5000";
+ #sound-dai-cells = <0>;
+ reg = <0x0a>;
+ clocks = <&audio_clock>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_3p3v>;
+ VDDD-supply = <®_1p5v>;
+ };
};
&pci0 {
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: r8a7743: Add sound support
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Define the generic r8a7743(RZ/G1M) part of the sound device node.
This patch is based on the r8a7791 sound work by Kuninori Morimoto.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 185 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 185 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index b60527a..59860c8 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1290,6 +1290,191 @@
resets = <&cpg 319>;
status = "disabled";
};
+
+ rcar_sound: sound at ec500000 {
+ /*
+ * #sound-dai-cells is required
+ *
+ * Single DAI : #sound-dai-cells = <0>; <&rcar_sound>;
+ * Multi DAI : #sound-dai-cells = <1>; <&rcar_sound N>;
+ */
+ compatible = "renesas,rcar_sound-r8a7743",
+ "renesas,rcar_sound-gen2";
+ reg = <0 0xec500000 0 0x1000>, /* SCU */
+ <0 0xec5a0000 0 0x100>, /* ADG */
+ <0 0xec540000 0 0x1000>, /* SSIU */
+ <0 0xec541000 0 0x280>, /* SSI */
+ <0 0xec740000 0 0x200>; /* Audio DMAC peri peri*/
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+ clocks = <&cpg CPG_MOD 1005>,
+ <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+ <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+ <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+ <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+ <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+ <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+ <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+ <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+ <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+ <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+ <&cpg CPG_MOD 1021>, <&cpg CPG_MOD 1020>,
+ <&cpg CPG_MOD 1021>, <&cpg CPG_MOD 1020>,
+ <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+ <&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>,
+ <&cpg CPG_CORE R8A7743_CLK_M2>;
+ clock-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+ "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
+ "src.9", "src.8", "src.7", "src.6", "src.5",
+ "src.4", "src.3", "src.2", "src.1", "src.0",
+ "ctu.0", "ctu.1",
+ "mix.0", "mix.1",
+ "dvc.0", "dvc.1",
+ "clk_a", "clk_b", "clk_c", "clk_i";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 1005>,
+ <&cpg 1006>, <&cpg 1007>, <&cpg 1008>, <&cpg 1009>,
+ <&cpg 1010>, <&cpg 1011>, <&cpg 1012>, <&cpg 1013>,
+ <&cpg 1014>, <&cpg 1015>;
+ reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+ "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0";
+ status = "disabled";
+
+ rcar_sound,dvc {
+ dvc0: dvc-0 {
+ dmas = <&audma1 0xbc>;
+ dma-names = "tx";
+ };
+ dvc1: dvc-1 {
+ dmas = <&audma1 0xbe>;
+ dma-names = "tx";
+ };
+ };
+
+ rcar_sound,mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
+ rcar_sound,ctu {
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
+ };
+
+ rcar_sound,src {
+ src0: src-0 {
+ interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x85>, <&audma1 0x9a>;
+ dma-names = "rx", "tx";
+ };
+ src1: src-1 {
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x87>, <&audma1 0x9c>;
+ dma-names = "rx", "tx";
+ };
+ src2: src-2 {
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x89>, <&audma1 0x9e>;
+ dma-names = "rx", "tx";
+ };
+ src3: src-3 {
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x8b>, <&audma1 0xa0>;
+ dma-names = "rx", "tx";
+ };
+ src4: src-4 {
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x8d>, <&audma1 0xb0>;
+ dma-names = "rx", "tx";
+ };
+ src5: src-5 {
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x8f>, <&audma1 0xb2>;
+ dma-names = "rx", "tx";
+ };
+ src6: src-6 {
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x91>, <&audma1 0xb4>;
+ dma-names = "rx", "tx";
+ };
+ src7: src-7 {
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x93>, <&audma1 0xb6>;
+ dma-names = "rx", "tx";
+ };
+ src8: src-8 {
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x95>, <&audma1 0xb8>;
+ dma-names = "rx", "tx";
+ };
+ src9: src-9 {
+ interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x97>, <&audma1 0xba>;
+ dma-names = "rx", "tx";
+ };
+ };
+
+ rcar_sound,ssi {
+ ssi0: ssi-0 {
+ interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi1: ssi-1 {
+ interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi2: ssi-2 {
+ interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi3: ssi-3 {
+ interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi4: ssi-4 {
+ interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi5: ssi-5 {
+ interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi6: ssi-6 {
+ interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi7: ssi-7 {
+ interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi8: ssi-8 {
+ interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi9: ssi-9 {
+ interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ };
+ };
};
/* External root clock */
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: r8a7743: Add audio DMAC support
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Instantiate the two audio DMA controllers on the r8a7743 device tree.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 62 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 2f0ec9d..b60527a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -359,6 +359,68 @@
dma-channels = <15>;
};
+ audma0: dma-controller at ec700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xec700000 0 0x10000>;
+ interrupts = <GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+ clocks = <&cpg CPG_MOD 502>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 502>;
+ #dma-cells = <1>;
+ dma-channels = <13>;
+ };
+
+ audma1: dma-controller at ec720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xec720000 0 0x10000>;
+ interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+ clocks = <&cpg CPG_MOD 501>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 501>;
+ #dma-cells = <1>;
+ dma-channels = <13>;
+ };
+
usb_dmac0: dma-controller at e65a0000 {
compatible = "renesas,r8a7743-usb-dmac",
"renesas,usb-dmac";
--
1.9.1
^ 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