* Re: [PATCH v2 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
From: Mark Brown @ 2014-02-07 17:27 UTC (permalink / raw)
To: Keerthy
Cc: Keerthy, rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg, rob-VoJi6FS/r0vR7s880joybQ,
sameo-VuQAYsv1563Yd54FQh9/CA, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <52F4E685.4060605-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
On Fri, Feb 07, 2014 at 07:28:29PM +0530, Keerthy wrote:
> On Thursday 06 February 2014 11:20 AM, Keerthy wrote:
> If there are no further comments on this could you
> please pull this?
You've sent this mail a day after sending the original patch, don't do
that.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Mark Brown @ 2014-02-07 17:31 UTC (permalink / raw)
To: Josh Cartwright
Cc: Kumar Gala, Ivan T. Ivanov, Grant Likely, Rob Herring,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alok Chauhan, Gilad Avidov,
Kiran Gunda, Sagar Dharia, Andy Gross
In-Reply-To: <20140207172051.GW20228-OP5zVEFNDbfdOxZ39nK119BPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Fri, Feb 07, 2014 at 11:20:51AM -0600, Josh Cartwright wrote:
> On Fri, Feb 07, 2014 at 05:18:34PM +0000, Mark Brown wrote:
> > On Fri, Feb 07, 2014 at 10:51:27AM -0600, Josh Cartwright wrote:
> > > config SPI_QUP
> > > tristate "Qualcomm SPI Support with QUP interface"
> > > depends on OF
> > > depends on ARM
> > Does this really depend on ARM? If so why?
> The ARM dependency is there for the use of _relaxed io accessor
> variants.
That's not ARM only and I thought we were getting generic versions of it
anyway? ARMv8, MIPS, Microblaze, Hexagon and SH also define it.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-07 17:31 UTC (permalink / raw)
To: Nishanth Menon
Cc: Sudeep.Holla, Thomas Abraham, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <CAGo_u6raZY0sKdDn4d92SKpi=eqUpf23vW8K_bEi-v62V2jdPA@mail.gmail.com>
On 07/02/14 16:43, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 16:15, Sudeep Holla wrote:
>>> On 07/02/14 15:19, Thomas Abraham wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Add a new optional boost-frequency binding for specifying the frequencies
>>>> usable in boost mode.
>>>>
>>>> Cc: Nishanth Menon <nm@ti.com>
>>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>>> ---
>>>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> new file mode 100644
>>>> index 0000000..d925e38
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> @@ -0,0 +1,11 @@
>>>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>>>> +
>>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>>>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>>>> +operating conditions.
>>>> +
>>>> +Optional Properties:
>>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>>>> + This list should be a subset of frequencies listed in "operating-points"
>>>> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>>>> + details about "operating-points" property.
>>>>
>>>
>>> Won't single entry for boost frequency suffice which would be the starting
>>> frequency in the boost range. IOW will there be OPP list with frequencies:
>>> A > B > C > D, but only B and C are boost frequency. That seems little odd,
>>> unless it's some configuration chosen purely on software basis rather than
>>> hardware. For me B marks the beginning of over-clocking.
>>>
>> Ah, I meant A < B < C < D in the above example.
>
> Should'nt we let the SoC dts define that - traditionally, yes, but
> consider the following:
> A, B, C uses clk_parent X which describes B, C as overclocked.
> and say D uses clk_parent Y which is not "over clocked", then you have
> the scenario that on the first look seems counter-intutive.
>
Yes I thought of exactly similar clock setup, but was not convinced that it
should be part of OPP. In that case it looks like we are trying to represent
clock internals through some OPP bindings.
Yes I think its counter-intuitive as it's visible to the userspace(list of
frequencies and the boost parameters are exposed through sysfs)
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Andy Gross @ 2014-02-07 17:32 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Mark Brown, Grant Likely, Rob Herring,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alok Chauhan, Gilad Avidov,
Kiran Gunda, Sagar Dharia
In-Reply-To: <1391766753.27491.60.camel@iivanov-dev>
On Fri, Feb 07, 2014 at 11:52:33AM +0200, Ivan T. Ivanov wrote:
>
> Hi Andy,
>
> On Fri, 2014-02-07 at 01:39 -0600, Andy Gross wrote:
> > On Thu, Feb 06, 2014 at 06:57:48PM +0200, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov" <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
> > >
> > > Qualcomm Universal Peripheral (QUP) core is an AHB slave that
> > > provides a common data path (an output FIFO and an input FIFO)
> > > for serial peripheral interface (SPI) mini-core. SPI in master mode
> > > support up to 50MHz, up to four chip selects, and a programmable
> > > data path from 4 bits to 32 bits; MODE0..3 protocols
> > >
> > > Signed-off-by: Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
> > > Cc: Alok Chauhan <alokc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > Cc: Gilad Avidov <gavidov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > Cc: Kiran Gunda <kgunda-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > Cc: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > ---
> > > drivers/spi/Kconfig | 14 +
> > > drivers/spi/Makefile | 1 +
> > > drivers/spi/spi-qup.c | 898 +++++++++++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 913 insertions(+)
> > > create mode 100644 drivers/spi/spi-qup.c
> > >
> > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > > index ba9310b..bf8ce6b 100644
> > > --- a/drivers/spi/Kconfig
> > > +++ b/drivers/spi/Kconfig
> > > @@ -381,6 +381,20 @@ config SPI_RSPI
> > > help
> > > SPI driver for Renesas RSPI blocks.
> > >
> > > +config SPI_QUP
> > > + tristate "Qualcomm SPI Support with QUP interface"
> > > + depends on ARCH_MSM
> >
> > I'd change to ARCH_MSM_DT. This ensures the OF component is there.
>
> Ok. will change.
>
> >
> > > + help
> > > + Qualcomm Universal Peripheral (QUP) core is an AHB slave that
> > > + provides a common data path (an output FIFO and an input FIFO)
> > > + for serial peripheral interface (SPI) mini-core. SPI in master
> > > + mode support up to 50MHz, up to four chip selects, and a
> > > + programmable data path from 4 bits to 32 bits; supports numerous
> > > + protocol variants.
> > > +
> > > + This driver can also be built as a module. If so, the module
> > > + will be called spi_qup.
> > > +
> > > config SPI_S3C24XX
> > > tristate "Samsung S3C24XX series SPI"
> > > depends on ARCH_S3C24XX
> > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> > > index 95af48d..e598147 100644
> > > --- a/drivers/spi/Makefile
> > > +++ b/drivers/spi/Makefile
> > > @@ -59,6 +59,7 @@ spi-pxa2xx-platform-$(CONFIG_SPI_PXA2XX_PXADMA) += spi-pxa2xx-pxadma.o
> > > spi-pxa2xx-platform-$(CONFIG_SPI_PXA2XX_DMA) += spi-pxa2xx-dma.o
> > > obj-$(CONFIG_SPI_PXA2XX) += spi-pxa2xx-platform.o
> > > obj-$(CONFIG_SPI_PXA2XX_PCI) += spi-pxa2xx-pci.o
> > > +obj-$(CONFIG_SPI_QUP) += spi-qup.o
> > > obj-$(CONFIG_SPI_RSPI) += spi-rspi.o
> > > obj-$(CONFIG_SPI_S3C24XX) += spi-s3c24xx-hw.o
> > > spi-s3c24xx-hw-y := spi-s3c24xx.o
> > > diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
> > > new file mode 100644
> > > index 0000000..5eb5e8f
> > > --- /dev/null
> > > +++ b/drivers/spi/spi-qup.c
> > > @@ -0,0 +1,898 @@
> > > +/*
> > > + * Copyright (c) 2008-2014, The Linux foundation. All rights reserved.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License rev 2 and
> > > + * only rev 2 as published by the free Software foundation.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or fITNESS fOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#include <linux/clk.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/err.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/io.h>
> > > +#include <linux/list.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/pm_runtime.h>
> >
> > Remove this for now. No runtime support.
>
> Did you see any particular issue with the implementation
> or this is just because this platform didn't have support
> for power management?
>
The platform doesn't have support for PM right now. So it's probably better to
remove all this and revisit later when it is in place.
> > > +#include <linux/spi/spi.h>
> > > +
>
> <snip>
>
> > > +
> > > +static int spi_qup_transfer_do(struct spi_qup *controller,
> > > + struct spi_qup_device *chip,
> > > + struct spi_transfer *xfer)
> > > +{
> > > + unsigned long timeout;
> > > + int ret = -EIO;
> > > +
> > > + reinit_completion(&controller->done);
> > > +
> > > + timeout = DIV_ROUND_UP(controller->speed_hz, MSEC_PER_SEC);
> > > + timeout = DIV_ROUND_UP(xfer->len * 8, timeout);
> > > + timeout = 100 * msecs_to_jiffies(timeout);
> > > +
> > > + controller->rx_bytes = 0;
> > > + controller->tx_bytes = 0;
> > > + controller->error = 0;
> > > + controller->xfer = xfer;
> > > +
> > > + if (spi_qup_set_state(controller, QUP_STATE_RUN)) {
> > > + dev_warn(controller->dev, "cannot set RUN state\n");
> > > + goto exit;
> > > + }
> > > +
> > > + if (spi_qup_set_state(controller, QUP_STATE_PAUSE)) {
> > > + dev_warn(controller->dev, "cannot set PAUSE state\n");
> > > + goto exit;
> > > + }
> > > +
> > > + spi_qup_fifo_write(controller, xfer);
> > > +
> > > + if (spi_qup_set_state(controller, QUP_STATE_RUN)) {
> > > + dev_warn(controller->dev, "cannot set EXECUTE state\n");
> > > + goto exit;
> > > + }
> > > +
> > > + if (!wait_for_completion_timeout(&controller->done, timeout))
> > > + ret = -ETIMEDOUT;
> > > + else
> > > + ret = controller->error;
> > > +exit:
> > > + controller->xfer = NULL;
> >
> > Should the manipulation of controller->xfer be protected by spinlock?
>
> :-). Probably. I am wondering, could I avoid locking if firstly place
> QUP into RESET state and then access these field. This should stop
> all activities in it, right?
It's generally safest to not assume the hardware is going to do sane things.
I'm concerned about spurious IRQs.
> >
> > > + controller->error = 0;
> > > + controller->rx_bytes = 0;
> > > + controller->tx_bytes = 0;
> > > + spi_qup_set_state(controller, QUP_STATE_RESET);
> > > + return ret;
> > > +}
> > > +
>
> <snip>
>
> > > +
> > > +/* set clock freq, clock ramp, bits per work */
> > > +static int spi_qup_io_setup(struct spi_device *spi,
> > > + struct spi_transfer *xfer)
> > > +{
>
> <snip>
>
> > > +
> > > + /*
> > > + * TODO: In BAM mode mask INPUT and OUTPUT service flags in
> > > + * to prevent IRQs on FIFO status change.
> > > + */
> >
> > Remove the TODO. Not necessary. This stuff can be added when it becomes BAM
> > enabled.
>
> Ok.
>
> >
> > > + writel_relaxed(0, controller->base + QUP_OPERATIONAL_MASK);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int spi_qup_transfer_one(struct spi_master *master,
> > > + struct spi_message *msg)
> > > +{
> > > + struct spi_qup *controller = spi_master_get_devdata(master);
> > > + struct spi_qup_device *chip = spi_get_ctldata(msg->spi);
> > > + struct spi_transfer *xfer;
> > > + struct spi_device *spi;
> > > + unsigned cs_change;
> > > + int status;
> > > +
> > > + spi = msg->spi;
> > > + cs_change = 1;
> > > + status = 0;
> > > +
> > > + list_for_each_entry(xfer, &msg->transfers, transfer_list) {
> > > +
> > > + status = spi_qup_io_setup(spi, xfer);
> > > + if (status)
> > > + break;
> > > +
> >
> > no locking? This whole code block needs to have some type of mutex_lock to keep
> > others from trouncing the hardware while you are doing this transfer.
>
> This is handled by SPI framework.
>
Ah I looked through that and didn't see it the first time. But looking again, I
see it. You're right, you can ignore this comment.
> >
> > > + if (cs_change)
> > > + spi_qup_assert_cs(controller, chip);
> >
> > Should the CS be done outside the loop? I'd expect the following sequence to
> > happen:
> > - change CS
> > - Loop and do some transfers
> > - deassert CS
> >
> > In this code, you reinitialize and assert/deassert CS for every transaction.
> >
> > > +
> > > + cs_change = xfer->cs_change;
>
>
> Not exactly. It is allowed that CS goes inactive after every
> transaction. This is how I read struct spi_transfer description.
Ah ok. This is fine then.
>
> > > +
> > > + /* Do actual transfer */
> > > + status = spi_qup_transfer_do(controller, chip, xfer);
> > > + if (status)
> > > + break;
> > > +
> > > + msg->actual_length += xfer->len;
> > > +
> > > + if (xfer->delay_usecs)
> > > + udelay(xfer->delay_usecs);
> > > +
> > > + if (cs_change)
> > > + spi_qup_deassert_cs(controller, chip);
> > > + }
> > > +
> > > + if (status || !cs_change)
> > > + spi_qup_deassert_cs(controller, chip);
> > > +
> > > + msg->status = status;
> > > + spi_finalize_current_message(master);
> > > + return status;
> > > +}
> > > +
> > > +static int spi_qup_probe(struct platform_device *pdev)
> > > +{
> > > + struct spi_master *master;
> > > + struct clk *iclk, *cclk;
> > > + struct spi_qup *controller;
> > > + struct resource *res;
> > > + struct device *dev;
> > > + void __iomem *base;
> > > + u32 data, max_freq, iomode;
> > > + int ret, irq, size;
> > > +
> > > + dev = &pdev->dev;
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + base = devm_ioremap_resource(dev, res);
> > > + if (IS_ERR(base))
> > > + return PTR_ERR(base);
> > > +
> > > + irq = platform_get_irq(pdev, 0);
> > > +
> > > + if (irq < 0)
> > > + return irq;
> > > +
> > > + cclk = devm_clk_get(dev, "core");
> > > + if (IS_ERR(cclk)) {
> > > + dev_err(dev, "cannot get core clock\n");
> > No need to error print. devm_clk_get already outputs something
>
> Ok.
>
> > > + return PTR_ERR(cclk);
> > > + }
> > > +
> > > + iclk = devm_clk_get(dev, "iface");
> > > + if (IS_ERR(iclk)) {
> > > + dev_err(dev, "cannot get iface clock\n");
> >
> > No need to error print. devm_clk_get already outputs something
>
> Ok.
>
> >
> > > + return PTR_ERR(iclk);
> > > + }
> > > +
> > > + if (of_property_read_u32(dev->of_node, "spi-max-frequency", &max_freq))
> > > + max_freq = 19200000;
> >
> > I'd set the default to 50MHz as that is the max supported by hardware. I'd just
> > set max_freq declaration to 50MHz and then check the value if it is changed via
> > DT.
>
> 50MHz doesn't seems to be supported on all chip sets. Currently common
> denominator on all chip sets, that I can see, is 19.2MHz. I have tried
> to test it with more than 19.2MHz on APQ8074 and it fails.
>
I guess my stance is to set it to the hardware max supported frequency if it is
not specified. If that needs to be lower on a board because of whatever reason,
they override it.
> >
> > > +
> > > + if (!max_freq) {
> > > + dev_err(dev, "invalid clock frequency %d\n", max_freq);
> > > + return -ENXIO;
> > > + }
> >
> > This is buggy. Remove this and collapse into the of_property_read_u32 if
> > statement. On non-zero, check the range for validity.
>
> True. Will fix.
>
> >
> > > +
> > > + ret = clk_set_rate(cclk, max_freq);
> > > + if (ret)
> > > + dev_warn(dev, "fail to set SPI frequency %d\n", max_freq);
> >
> > Bail here?
>
> I don't know. What will be the consequences if controller continue to
> operate on its default rate?
>
It is unclear. But if you can't set the rate that is configured or if there is
a misconfiguration, it's probably better to exit the probe and catch it here.
> > > +
> > > + ret = clk_prepare_enable(cclk);
> > > + if (ret) {
> > > + dev_err(dev, "cannot enable core clock\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = clk_prepare_enable(iclk);
> > > + if (ret) {
> > > + clk_disable_unprepare(cclk);
> > > + dev_err(dev, "cannot enable iface clock\n");
> > > + return ret;
> > > + }
> > > +
> > > + data = readl_relaxed(base + QUP_HW_VERSION);
> > > +
> > > + if (data < QUP_HW_VERSION_2_1_1) {
> > > + clk_disable_unprepare(cclk);
> > > + clk_disable_unprepare(iclk);
> > > + dev_err(dev, "v.%08x is not supported\n", data);
> > > + return -ENXIO;
> > > + }
> > > +
> > > + master = spi_alloc_master(dev, sizeof(struct spi_qup));
> > > + if (!master) {
> > > + clk_disable_unprepare(cclk);
> > > + clk_disable_unprepare(iclk);
> > > + dev_err(dev, "cannot allocate master\n");
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + master->bus_num = pdev->id;
> > > + master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP;
> > > + master->num_chipselect = SPI_NUM_CHIPSELECTS;
> > > + master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
> > > + master->setup = spi_qup_setup;
> > > + master->cleanup = spi_qup_cleanup;
> > > + master->transfer_one_message = spi_qup_transfer_one;
> > > + master->dev.of_node = pdev->dev.of_node;
> > > + master->auto_runtime_pm = true;
> >
> > Remove this. No runtime support
> >
> > > +
> > > + platform_set_drvdata(pdev, master);
> > > +
> > > + controller = spi_master_get_devdata(master);
> > > +
> > > + controller->dev = dev;
> > > + controller->base = base;
> > > + controller->iclk = iclk;
> > > + controller->cclk = cclk;
> > > + controller->irq = irq;
> > > + controller->max_speed_hz = clk_get_rate(cclk);
> > > + controller->speed_hz = controller->max_speed_hz;
> > > +
> > > + init_completion(&controller->done);
> > > +
> > > + iomode = readl_relaxed(base + QUP_IO_M_MODES);
> > > +
> > > + size = QUP_IO_M_OUTPUT_BLOCK_SIZE(iomode);
> > > + if (size)
> > > + controller->out_blk_sz = size * 16;
> > > + else
> > > + controller->out_blk_sz = 4;
> > > +
> > > + size = QUP_IO_M_INPUT_BLOCK_SIZE(iomode);
> > > + if (size)
> > > + controller->in_blk_sz = size * 16;
> > > + else
> > > + controller->in_blk_sz = 4;
> > > +
> > > + size = QUP_IO_M_OUTPUT_FIFO_SIZE(iomode);
> > > + controller->out_fifo_sz = controller->out_blk_sz * (2 << size);
> > > +
> > > + size = QUP_IO_M_INPUT_FIFO_SIZE(iomode);
> > > + controller->in_fifo_sz = controller->in_blk_sz * (2 << size);
> > > +
> > > + dev_info(dev, "v.%08x IN:block:%d, fifo:%d, OUT:block:%d, fifo:%d\n",
> > > + data, controller->in_blk_sz, controller->in_fifo_sz,
> > > + controller->out_blk_sz, controller->out_fifo_sz);
> > > +
> > > + writel_relaxed(1, base + QUP_SW_RESET);
> > > +
> > > + ret = spi_qup_set_state(controller, QUP_STATE_RESET);
> > > + if (ret) {
> > > + dev_err(dev, "cannot set RESET state\n");
> > > + goto error;
> > > + }
> > > +
> > > + writel_relaxed(0, base + QUP_OPERATIONAL);
> > > + writel_relaxed(0, base + QUP_IO_M_MODES);
> > > + writel_relaxed(0, base + QUP_OPERATIONAL_MASK);
> > > + writel_relaxed(SPI_ERROR_CLK_UNDER_RUN | SPI_ERROR_CLK_OVER_RUN,
> > > + base + SPI_ERROR_FLAGS_EN);
> > > +
> > > + writel_relaxed(0, base + SPI_CONFIG);
> > > + writel_relaxed(SPI_IO_C_NO_TRI_STATE, base + SPI_IO_CONTROL);
> > > +
> > > + ret = devm_request_irq(dev, irq, spi_qup_qup_irq,
> > > + IRQF_TRIGGER_HIGH, pdev->name, controller);
> > > + if (ret) {
> > > + dev_err(dev, "cannot request IRQ %d\n", irq);
> >
> > unnecessary print
>
> Will remove.
>
> >
> > > + goto error;
> > > + }
> > > +
> > > + ret = devm_spi_register_master(dev, master);
> > > + if (!ret) {
> > > + pm_runtime_set_autosuspend_delay(dev, MSEC_PER_SEC);
> > > + pm_runtime_use_autosuspend(dev);
> > > + pm_runtime_set_active(dev);
> > > + pm_runtime_enable(dev);
> >
> > Remove all the runtime stuff. not supported right now.
> >
> > > + return ret;
> > > + }
> > > +error:
> > > + clk_disable_unprepare(cclk);
> > > + clk_disable_unprepare(iclk);
> > > + spi_master_put(master);
> > > + return ret;
> > > +}
> > > +
>
> <snip>
>
> >
> > > +
> > > +static int spi_qup_remove(struct platform_device *pdev)
> > > +{
> > > + struct spi_master *master = dev_get_drvdata(&pdev->dev);
> > > + struct spi_qup *controller = spi_master_get_devdata(master);
> > > +
> > > + pm_runtime_get_sync(&pdev->dev);
> > > +
> >
> > Do we need to wait for any current transactions to complete
> > and do a devm_free_irq()?
> >
> > > + clk_disable_unprepare(controller->cclk);
> > > + clk_disable_unprepare(controller->iclk);
>
> My understanding is:
>
> Disabling clocks will timeout transaction, if any. Core Device driver
> will call: devm_spi_unregister(), which will wait pending transactions
> to complete and then remove the SPI master.
Disabling clocks will confuse the hardware. We cannot disable clocks while the
spi core is active and transferring data.
>
> > > +
> > > + pm_runtime_put_noidle(&pdev->dev);
> > > + pm_runtime_disable(&pdev->dev);
> > > + return 0;
> > > +}
> > > +
> > > +static struct of_device_id spi_qup_dt_match[] = {
> > > + { .compatible = "qcom,spi-qup-v2", },
> >
> > Need compatible tags of qcom,spi-qup-v2.1.1 (msm8974 v1) or qcom,spi-qup-v2.2.1
> > (msm8974 v2)
>
> I am not aware of the difference. My board report v.20020000.
> Is there difference of handling these controllers?
There were some bug fixes between versions. None of those affect SPI (that I
can tell), but it's better to be more descriptive and use the full versions in
the compatible tags.
>
>
> Thanks,
> Ivan
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Nishanth Menon @ 2014-02-07 17:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: Thomas Abraham, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <52F51888.5010608@arm.com>
On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> Yes I thought of exactly similar clock setup, but was not convinced that it
> should be part of OPP. In that case it looks like we are trying to represent
> clock internals through some OPP bindings.
And this series (rightly) does not make it an OPP behavior. instead
all it does is to list the boost-frequencies and mark those in cpufreq
table. the description is left to the dts and implementation to the
clock drivers involved.
> Yes I think its counter-intuitive as it's visible to the userspace(list of
> frequencies and the boost parameters are exposed through sysfs)
That will be a different problem -> as currently every single
frequency in the cpufreq list has ability to be marked as boost
frequency - if userspace does not maintain that, then, IMHO, fix the
userspace :D
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Nishanth Menon @ 2014-02-07 17:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: Thomas Abraham, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <CAGo_u6ofC4NNPiTNcSnXUvT3RZJo54=XyjetR-ok5hCBrVZkKg@mail.gmail.com>
On Fri, Feb 7, 2014 at 11:37 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> Yes I thought of exactly similar clock setup, but was not convinced that it
>> should be part of OPP. In that case it looks like we are trying to represent
>> clock internals through some OPP bindings.
>
> And this series (rightly) does not make it an OPP behavior. instead
> all it does is to list the boost-frequencies and mark those in cpufreq
> table. the description is left to the dts and implementation to the
> clock drivers involved.
One more thing, before I forget -> currently
dev_pm_opp_[init|free]_cpufreq_table is in drivers/base/power/opp.c ->
this probably should go away to drivers/cpufreq to keep opp.c
independent of frameworks using it. i dont see any code that is
introduced in the mentioned functions as being OPP behavior specific,
instead, I consider them as cpufreq+opp behaviors, which this change
fits into.
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH v6 05/19] watchdog: orion: Make sure the watchdog is initially stopped
From: Jason Gunthorpe @ 2014-02-07 17:43 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Guenter Roeck, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Wim Van Sebroeck,
Jason Cooper, Thomas Petazzoni, Gregory Clement, Lior Amsalem,
Sebastian Hesselbarth, Andrew Lunn
In-Reply-To: <20140207104044.GA11063@localhost>
On Fri, Feb 07, 2014 at 07:40:45AM -0300, Ezequiel Garcia wrote:
> Well, this is related to the discussion about the bootloader not
> reseting the watchdog properly, provoking spurious watchdog triggering.
>
> Jason Gunthorpe explained [1] that we needed a particular sequence:
>
> 1. Disable WDT
> 2. Clear bridge
> 3. Enable WDT
>
> We added the irq handling to satisfy (2), and the watchdog stop for (1).
The issue here is the driver configures two 'machine kill' elements:
the PANIC IRQ and the RstOut setup.
Before configuring either of those the driver needs to ensure that any
old watchdog events are cleared out of the HW. We must not get a
spurious event.
I agree not disabling an already functional and properly configured
counter from the bootloader is desirable.
So lets break it down a bit..
1) The IRQ:
It looks like the cause bit latches high on watchdog timer
expiration but has no side effect unless it is unmasked.
The new IRQ flow code ensures the bit is cleared during request_irq
so no old events can trigger the IRQ. Thus it is solved now.
2) The RstOut:
It is a bit unspecific, but I think this signal latches high when
any unmasked rst event occurs and stays high until the RstIn pin
is asserted.
So we don't need to worry about clearing old events from here
Alternatively the WDRstOutEn routes the Cause bit into the RstOut
pin.
3) The timer itself:
The WDT is just a general timer with an optional hookup to the
rst control. If it is harmlessly counting but not resetting we need
to stop that before enabling rst out.
So, how about this for psuedo-code in probe:
if (readl(RSTOUTn) & WDRstOutEn)
{
/* Watchdog is configured and may be down counting,
don't touch it */
request_irq(..);
}
else
{
/* Watchdog is not configured, fully disable the timer
and configure for watchdog operation. */
disable_watchdog();
request_irq();
writel(RSTOUTn), .. WDRstOutEn);
}
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Josh Cartwright @ 2014-02-07 17:46 UTC (permalink / raw)
To: Mark Brown
Cc: Kumar Gala, Ivan T. Ivanov, Grant Likely, Rob Herring,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alok Chauhan, Gilad Avidov,
Kiran Gunda, Sagar Dharia, Andy Gross
In-Reply-To: <20140207173108.GH1757-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Fri, Feb 07, 2014 at 05:31:08PM +0000, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 11:20:51AM -0600, Josh Cartwright wrote:
> > On Fri, Feb 07, 2014 at 05:18:34PM +0000, Mark Brown wrote:
> > > On Fri, Feb 07, 2014 at 10:51:27AM -0600, Josh Cartwright wrote:
> > > > config SPI_QUP
> > > > tristate "Qualcomm SPI Support with QUP interface"
> > > > depends on OF
> > > > depends on ARM
>
> > > Does this really depend on ARM? If so why?
>
> > The ARM dependency is there for the use of _relaxed io accessor
> > variants.
>
> That's not ARM only and I thought we were getting generic versions of it
> anyway? ARMv8, MIPS, Microblaze, Hexagon and SH also define it.
Okay, that's fair. I'm only vaguely familiar with the generic _relaxed
variants, but until they land, how do we appropriately declare the
dependency to prevent breaking COMPILE_TEST builds on architectures that
don't have them? Or should we either bother?
Do we need to introduce a HAVE_RELAXED_IO_ACCESSORS selected by those
architectures with support?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Devicetree Maintenance in barebox
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-02-07 17:51 UTC (permalink / raw)
To: Jason Cooper
Cc: Grant Likely, barebox-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Campbell
In-Reply-To: <20140207141028.GT8533-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On 09:10 Fri 07 Feb , Jason Cooper wrote:
> Hi Sascha,
>
> + Grant Likely, Ian Campbell, devicetree ML
>
> This discussion started on the barebox bootloader mailinglist
>
> On Fri, Feb 07, 2014 at 08:13:32AM +0100, Sascha Hauer wrote:
> > It's becoming more obvious that devicetree maintenance is painful
> > because we have to sync them to the kernel regularly. My hope was that
> > this would get simpler once the devicetrees get their own repository
> > outside the kernel, but it seems that won't happen anytime soon.
>
> hmm. Ian Campbell has a tree he is working on:
>
> git://xenbits.xen.org/people/ianc/device-tree-rebasing.git
>
> Also, In the DT meeting earlier this week, Grant Likely said he has the
> request in to create a separate mailinglist for collaboration between
> the different devicetree users (BSD, Linux, etc).
>
> > So my current idea to continue with barebox devicetrees is:
> >
> > - Maintain a kernel branch which has all devicetree changes we need in
> > barebox in a clean step-by-step series
> > - rebase this branch regularly on the newer kernel
> > - Copy the resulting devicetrees to barebox
> >
> > The upside is that we have up to date devicetrees in barebox without
> > having to resync them by hand on a per SoC basis. Of course this also
> > means that we lose the devicetree history and breakage may be introduced
> > with some huge commits saying "Update devicetrees to Linux-3.x".
> >
> > Any better ideas? I think we have to do something.
>
> I think the proper solution will percolate out of the first
> cross-project discussions on the new ML.
>
> imho, the goal is to not have any project tied to a specific version of
> the devicetree. iow, we don't break backwards compatibility in the
> devicetrees, and projects should revert to default behavior if new dt
> parameters are missing. This means Linux and BSD shouldn't need to keep
> a current copy of the devicetree in their trees. However, building the
> bootloader is a different animal. It needs to provide the dt blob...
>
> Definitely fodder for the new ML.
>
> Grant, can you please add Sascha to the list of folks to notify when the
> new ML is ready?
Yes we do need to split the DT ASAP
Best Regards,
J.
>
> thx,
>
> Jason.
>
> _______________________________________________
> barebox mailing list
> barebox-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Mark Brown @ 2014-02-07 17:52 UTC (permalink / raw)
To: Andy Gross
Cc: Ivan T. Ivanov, Grant Likely, Rob Herring, linux-spi,
linux-arm-msm, linux-kernel, devicetree, Alok Chauhan,
Gilad Avidov, Kiran Gunda, Sagar Dharia
In-Reply-To: <20140207173207.GA19974@qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On Fri, Feb 07, 2014 at 11:32:07AM -0600, Andy Gross wrote:
> On Fri, Feb 07, 2014 at 11:52:33AM +0200, Ivan T. Ivanov wrote:
To repeat what I said in my earlier e-mail please delete irrelevant
context from your mails so any new content you are including is
discoverable.
> > Did you see any particular issue with the implementation
> > or this is just because this platform didn't have support
> > for power management?
> The platform doesn't have support for PM right now. So it's probably better to
> remove all this and revisit later when it is in place.
No, runtime PM does not require any platform support at all and is good
practice - look at what the driver is doing with it, it's useful as-is.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Mark Brown @ 2014-02-07 17:57 UTC (permalink / raw)
To: Josh Cartwright
Cc: Kumar Gala, Ivan T. Ivanov, Grant Likely, Rob Herring, linux-spi,
linux-arm-msm, linux-kernel, devicetree, Alok Chauhan,
Gilad Avidov, Kiran Gunda, Sagar Dharia, Andy Gross
In-Reply-To: <20140207174643.GX20228@joshc.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Fri, Feb 07, 2014 at 11:46:43AM -0600, Josh Cartwright wrote:
> On Fri, Feb 07, 2014 at 05:31:08PM +0000, Mark Brown wrote:
> > That's not ARM only and I thought we were getting generic versions of it
> > anyway? ARMv8, MIPS, Microblaze, Hexagon and SH also define it.
> Okay, that's fair. I'm only vaguely familiar with the generic _relaxed
> variants, but until they land, how do we appropriately declare the
> dependency to prevent breaking COMPILE_TEST builds on architectures that
> don't have them? Or should we either bother?
> Do we need to introduce a HAVE_RELAXED_IO_ACCESSORS selected by those
> architectures with support?
I think that or just getting generic versions done would be the way
forwards. Right now it's a bit of a shambles.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-07 18:02 UTC (permalink / raw)
To: Nishanth Menon
Cc: Sudeep.Holla, Thomas Abraham, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <CAGo_u6ofC4NNPiTNcSnXUvT3RZJo54=XyjetR-ok5hCBrVZkKg@mail.gmail.com>
On 07/02/14 17:37, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
[...]
>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>> frequencies and the boost parameters are exposed through sysfs)
>
> That will be a different problem -> as currently every single
> frequency in the cpufreq list has ability to be marked as boost
> frequency - if userspace does not maintain that, then, IMHO, fix the
> userspace :D
>
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
the list of frequencies based on the state of the boost feature at anytime.
Intuitively the list without boost shouldn't have any frequency above the range
when it's enabled :), that's what I was referring to. So I am not talking about
any issue with user-space maintenance.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/3] sound: soc: codecs: Add es8328 codec
From: Mark Brown @ 2014-02-07 18:12 UTC (permalink / raw)
To: Sean Cross; +Cc: devicetree, alsa-devel, Shawn Guo, Liam Girdwood, Sascha Hauer
In-Reply-To: <1391749517-11787-2-git-send-email-xobs@kosagi.com>
[-- Attachment #1.1: Type: text/plain, Size: 3747 bytes --]
On Fri, Feb 07, 2014 at 01:05:15PM +0800, Sean Cross wrote:
Please use subject likes matching the style for the subsystem. If your
changelog looks different to others in the same area it probably needs
an update.
In general this looks like it should be making much more use of the
framework rather than open coding, it looks like it's very much hard
coded for one use cae.
> +config SND_SOC_ES8328
> + tristate
> +
It looks like you're going to use this on an ARM system, you should add
DT support and make it visible in Kconfig.
> +static const struct snd_soc_dapm_widget es8328_dapm_widgets[] = {
> + SND_SOC_DAPM_DAC("Speaker Volume", "HiFi Playback", SND_SOC_NOPM, 0, 0),
Don't declare a stream by name, use DAPM routes to connect the stream to
the widget.
> + SND_SOC_DAPM_OUTPUT("VOUTL"),
> + SND_SOC_DAPM_OUTPUT("VOUTR"),
> + SND_SOC_DAPM_INPUT("LINE_IN"),
> + SND_SOC_DAPM_INPUT("MIC_IN"),
> + SND_SOC_DAPM_OUTPUT("HP_OUT"),
> + SND_SOC_DAPM_OUTPUT("SPK_OUT"),
Something is messed up with your indentation, spaces vs tabs I expect.
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> +
> + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
An else clause is more idiomatic here.
> + snd_soc_write(codec, ES8328_ADCCONTROL5, adc);
It's more idiomatic to use update_bits() here and save doing a manual
read/modify/write cycle - it also avoids the write if not needed.
> +static int es8328_adc_enable(struct snd_soc_codec *codec)
> +{
> + u16 reg = snd_soc_read(codec, ES8328_CHIPPOWER);
> + reg &= ~(ES8328_CHIPPOWER_ADCVREF_OFF |
> + ES8328_CHIPPOWER_ADCPLL_OFF |
> + ES8328_CHIPPOWER_ADCSTM_RESET |
> + ES8328_CHIPPOWER_ADCDIG_OFF);
> + snd_soc_write(codec, ES8328_CHIPPOWER, reg);
This looks like it should be done in DAPM.
> +
> + /* Set up microphone to be differential input */
> + snd_soc_write(codec, ES8328_ADCCONTROL2, 0xf0);
This looks like something that should be platform data and/or DAPM -
other platforms may be wired differently.
> + /* Set ADC to act as I2S master */
> + snd_soc_write(codec, ES8328_ADCCONTROL3, 0x02);
set_dai_fmt().
> + /* Set I2S to 16-bit mode */
> + snd_soc_write(codec, ES8328_ADCCONTROL4, 0x18);
This should be being done in hw_params.
> + /* Frequency clock of 272 */
> + snd_soc_write(codec, ES8328_ADCCONTROL5, 0x02);
What is the frequency clock in this context?
> + /* Power up LOUT2 ROUT2, and power down xOUT1 */
> + snd_soc_write(codec, ES8328_DACPOWER,
> + ES8328_DACPOWER_ROUT2_ON |
> + ES8328_DACPOWER_LOUT2_ON);
This looks like it should be being done in DAPM.
> + /* Enable click-free power up */
> + snd_soc_write(codec, ES8328_DACCONTROL6, ES8328_DACCONTROL6_CLICKFREE);
> + snd_soc_write(codec, ES8328_DACCONTROL3, 0x36);
Just do this once on startup?
> + /* Set I2S to 16-bit mode */
> + snd_soc_write(codec, ES8328_DACCONTROL1, ES8328_DACCONTROL1_DACWL_16);
hw_params().
> + /* No attenuation */
> + snd_soc_write(codec, ES8328_DACCONTROL4, 0x00);
> + snd_soc_write(codec, ES8328_DACCONTROL5, 0x00);
This and the rest of the function looks like it should be done in a
combination of DAPM and normal ALSA controls.
> + for (i = 0; i < 4; i++)
> + snd_soc_write(codec, i + ES8328_DACCONTROL24, old_volumes[i]);
You are probably looking for something like SOC_DAPM_SINGLE_AUTODISABLE.
> +static const struct snd_soc_dai_ops es8328_dai_ops = {
> + .hw_params = es8328_hw_params,
> + .prepare = es8328_pcm_prepare,
> + .shutdown = es8328_pcm_shutdown,
> +// .digital_mute = es8328_mute,
Hrm?
> +static const struct of_device_id es8328_of_match[] = {
> + { .compatible = "everest,es8328", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, es8328_of_match);
Any device tree device needs a binding document.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] sound: soc: fsl: Add support for Novena onboard audio
From: Mark Brown @ 2014-02-07 18:14 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Shawn Guo, Sascha Hauer,
Liam Girdwood
In-Reply-To: <1391749517-11787-3-git-send-email-xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
On Fri, Feb 07, 2014 at 01:05:16PM +0800, Sean Cross wrote:
> Novena uses an ES8328 audio codec connected via I2S.
The CODEC looked pretty simple, can this use simple-card?
> + /* Headphone jack detection */
> + if (gpio_is_valid(data->jack_gpio)) {
> + ret = snd_soc_jack_new(rtd->codec, "Headset",
> + SND_JACK_HEADSET | SND_JACK_BTN_0,
> + &headset_jack);
> + if (ret)
> + return ret;
> +
> + headset_jack_gpios[0].gpio = data->jack_gpio;
> + ret = snd_soc_jack_add_gpios(&headset_jack,
> + ARRAY_SIZE(headset_jack_gpios),
> + headset_jack_gpios);
> + }
We'd need to add support for this but that shouldn't be too hard.
> +static int imx_set_frequency(struct imx_novena_data *data, int freq) {
> + int ret;
> +
> + ret = clk_set_parent(data->system_cko, data->codec_clk);
> + if (ret) {
> + dev_err(data->dev, "unable to set clk output");
> + return ret;
> + }
> +
> + ret = clk_set_parent(data->codec_clk_sel, data->codec_clk_post_div);
> + if (ret) {
> + dev_err(data->dev, "unable to set clk parent");
> + return ret;
> + }
There's supposed to be support for this sort of thing going into the
clock API with some sort of generic binding.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Andy Gross @ 2014-02-07 19:12 UTC (permalink / raw)
To: Mark Brown
Cc: Ivan T. Ivanov, Grant Likely, Rob Herring,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alok Chauhan, Gilad Avidov,
Kiran Gunda, Sagar Dharia
In-Reply-To: <20140207175234.GJ1757-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Fri, Feb 07, 2014 at 05:52:34PM +0000, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 11:32:07AM -0600, Andy Gross wrote:
> > On Fri, Feb 07, 2014 at 11:52:33AM +0200, Ivan T. Ivanov wrote:
>
[... snip ...]
> > The platform doesn't have support for PM right now. So it's probably better to
> > remove all this and revisit later when it is in place.
>
> No, runtime PM does not require any platform support at all and is good
> practice - look at what the driver is doing with it, it's useful as-is.
Fair enough.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/5] Add Allwinner A31 SPI controller support
From: Maxime Ripard @ 2014-02-07 19:28 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf
In-Reply-To: <1391605507-30981-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
On Wed, Feb 05, 2014 at 02:05:02PM +0100, Maxime Ripard wrote:
> Hi everyone,
>
> This patchset brings support for the SPI controller found in the
> Allwinner A31 SoC.
>
> Even though the controller supports DMA, the driver only supports PIO
> mode for now. This driver will be used to bring up and test DMA on the
> SoC, so support for the DMA will come eventually.
>
> It doesn't support transfer larger than the FIFO size (128 bytes) for
> now, I expect it to be fixed in the future.
>
> Thanks!
> Maxime
>
> Changes from v3:
> - Rebased on top of 3.14-rc1
> - Removed the dependency on devm_spi_alloc_master
> - Modified the pm_runtime code according to reviews
>
> Changes from v2:
> - Removed the select on runtime_pm
> - Fixed the clock error messages
> - Trigger the CS manually, and honour the enable bit in set_cs
> - Convert to devm_* functions
> - Remove useless clk_disable_unprepare in probe
>
> Changes from v1:
> - Switched to using the transfer_one and set_cs callbacks
> - Switched to using runtime_pm
> - Report an error when we try to do a transfer larger than the FIFO
> size, instead of silently timeouting.
> - Added a Kconfig symbol
> - Move the clock ratio change at transfer time
> - Fixed the PLL6 cell size in the DTSI
> - A few fixes here and there: typos, etc.
>
> Maxime Ripard (5):
> clk: sunxi: Add support for PLL6 on the A31
> ARM: sun6i: dt: Add PLL6 and SPI module clocks
> spi: sunxi: Add Allwinner A31 SPI controller driver
> ARM: sun6i: dt: Add SPI controllers to the A31 DTSI
> ARM: sunxi: Enable A31 SPI and SID in the defconfig
Applied patch 2 and 4 to sunxi/dt-for-3.15, and patch 5 to sunxi/defconfig-for-3.15
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-07 19:29 UTC (permalink / raw)
To: Hans de Goede
Cc: Emilio López, Mike Turquette, Philipp Zabel, Grant Likely,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Roman Byshko
In-Reply-To: <1391786513-20780-3-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On Fri, Feb 07, 2014 at 04:21:50PM +0100, Hans de Goede wrote:
> From: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Add register definitions for the usb-clk register found on sun4i, sun5i and
> sun7i SoCs.
>
> Signed-off-by: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/5] clk: sunxi: Add support for USB clock-register reset bits
From: Maxime Ripard @ 2014-02-07 19:30 UTC (permalink / raw)
To: Hans de Goede
Cc: Emilio López, Mike Turquette, Philipp Zabel, Grant Likely,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1391786513-20780-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Fri, Feb 07, 2014 at 04:21:49PM +0100, Hans de Goede wrote:
> The usb-clk register is special in that it not only contains clk gate bits,
> but also has a few reset bits. This commit adds support for this by allowing
> gates type sunxi clks to also register a reset controller.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks!
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/14] Add support for MSM's mmio clock/reset controller
From: Frank Rowand @ 2014-02-07 19:38 UTC (permalink / raw)
To: Joe Perches
Cc: devicetree, Mike Turquette, linux-arm-msm, Stephen Boyd,
linux-kernel, Saravana Kannan, linux-arm-kernel
In-Reply-To: <1391749891.15777.31.camel@joe-AO722>
On 2/6/2014 9:11 PM, Joe Perches wrote:
> On Thu, 2014-02-06 at 20:15 -0800, Frank Rowand wrote:
>> On 1/15/2014 10:47 AM, Stephen Boyd wrote:
>>> The first breaks a reset-controller include ordering requirement. It got
>>> an ack so I think we're ok for it to go through the clock tree.
>>>
>>
>> < snip >
>>
>> checkpatch is whining about patches
>>
>> 4
>> 5
>> 6
>> 7
>> 8
>>
>> (Just for completeness if someone thinks I did not check all the patches,
>> it also whines about patch 11, but I think the whining should be ignored,
>> and it whines about patch 1 but I think that might be a checkpatch bug.)
>
> Hi Frank.
>
> For patch 1, what checkpatch bug might that be?
see below
>
> I think all the checkpatch whinges in patch 11 are correct.
Agreed on patch 11, judgement call on whether to ignore the warnings.
>
> I didn't check any of 4-8.
Hi Joe,
Thanks for jumping in. I did not want to bother you until I dug a little
deeper into the warning to see if I was just misunderstanding something.
Sorry, it is patch 2, not patch 1 ("[PATCH v5 02/14] clk: Add set_rate_and_parent() op"):
WARNING: Multiple spaces after return type
#188: FILE: include/linux/clk-provider.h:154:
+ int (*set_rate_and_parent)(struct clk_hw *hw,
total: 0 errors, 1 warnings, 152 lines checked
-Frank
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Nishanth Menon @ 2014-02-07 19:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Thomas Abraham, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <52F51FCD.5000009@arm.com>
On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.
>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
Fair enough - but i still think it has nothing to do with dt binding
itself -> and i think the discussion we've had should be good for the
binding provided in this patch.. I hope.. if documentation needs a bit
of better explanation to prevent a repeat of the same discussion at a
later point of time, now might be a good time to add it in.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] net: rfkill-regulator: Add devicetree support.
From: Marek Belisko @ 2014-02-07 19:48 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
linville, johannes, davem, grant.likely
Cc: neilb, hns, devicetree, linux-doc, linux-kernel, linux-wireless,
netdev, Marek Belisko
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
Based on Neil's patch and extend for documentation and bindings include.
.../bindings/net/rfkill/rfkill-relugator.txt | 28 ++++++++++++++++
include/dt-bindings/net/rfkill-regulator.h | 23 +++++++++++++
net/rfkill/rfkill-regulator.c | 38 ++++++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
create mode 100644 include/dt-bindings/net/rfkill-regulator.h
diff --git a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
new file mode 100644
index 0000000..cdb7dd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
@@ -0,0 +1,28 @@
+Regulator consumer for rfkill devices
+
+Required properties:
+- compatible : Must be "rfkill-regulator".
+- label : Name of rfkill device.
+- type : Type of rfkill device.
+
+Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
+ RFKILL_TYPE_ALL
+ RFKILL_TYPE_WLAN
+ RFKILL_TYPE_BLUETOOTH
+ RFKILL_TYPE_UWB
+ RFKILL_TYPE_WIMAX
+ RFKILL_TYPE_WWAN
+ RFKILL_TYPE_GPS
+ RFKILL_TYPE_FM
+ RFKILL_TYPE_NFC
+
+- vrfkill-supply - regulator device.
+
+Example:
+ gps-rfkill {
+ compatible = "rfkill-regulator";
+ label = "GPS";
+ type = <RFKILL_TYPE_GPS>;
+ vrfkill-supply = <®>;
+ };
+
diff --git a/include/dt-bindings/net/rfkill-regulator.h b/include/dt-bindings/net/rfkill-regulator.h
new file mode 100644
index 0000000..ae32273
--- /dev/null
+++ b/include/dt-bindings/net/rfkill-regulator.h
@@ -0,0 +1,23 @@
+/*
+ * This header provides macros for rfkill-regulator bindings.
+ *
+ * Copyright (C) 2014 Marek Belisko <marek@goldelico.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef __DT_BINDINGS_RFKILL_REGULATOR_H__
+#define __DT_BINDINGS_RFKILL_REGULATOR_H__
+
+
+#define RFKILL_TYPE_ALL (0)
+#define RFKILL_TYPE_WLAN (1)
+#define RFKILL_TYPE_BLUETOOTH (2)
+#define RFKILL_TYPE_UWB (3)
+#define RFKILL_TYPE_WIMAX (4)
+#define RFKILL_TYPE_WWAN (5)
+#define RFKILL_TYPE_GPS (6)
+#define RFKILL_TYPE_FM (7)
+#define RFKILL_TYPE_NFC (8)
+
+#endif /* __DT_BINDINGS_RFKILL_REGULATOR_H__ */
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
index cf5b145..a04aff8 100644
--- a/net/rfkill/rfkill-regulator.c
+++ b/net/rfkill/rfkill-regulator.c
@@ -19,6 +19,7 @@
#include <linux/regulator/consumer.h>
#include <linux/rfkill.h>
#include <linux/rfkill-regulator.h>
+#include <linux/of_platform.h>
struct rfkill_regulator_data {
struct rfkill *rf_kill;
@@ -57,6 +58,31 @@ static struct rfkill_ops rfkill_regulator_ops = {
.set_block = rfkill_regulator_set_block,
};
+#ifdef CONFIG_OF
+static struct rfkill_regulator_platform_data *
+rfkill_regulator_parse_pdata(struct device *dev)
+{
+ struct rfkill_regulator_platform_data *pdata;
+ struct device_node *np = dev->of_node;
+ u32 num;
+ if (!np)
+ return NULL;
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+ if (of_property_read_u32(np, "type", &num) == 0)
+ pdata->type = num;
+ of_property_read_string(np, "label", &pdata->name);
+ return pdata;
+}
+#else
+static inline struct rfkill_regulator_platform_data *
+rfkill_regulator_parse_pdata(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static int rfkill_regulator_probe(struct platform_device *pdev)
{
struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
@@ -65,6 +91,9 @@ static int rfkill_regulator_probe(struct platform_device *pdev)
struct rfkill *rf_kill;
int ret = 0;
+ if (!pdata)
+ pdata = rfkill_regulator_parse_pdata(&pdev->dev);
+
if (pdata == NULL) {
dev_err(&pdev->dev, "no platform data\n");
return -ENODEV;
@@ -137,12 +166,21 @@ static int rfkill_regulator_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id rfkill_regulator_match[] = {
+ {.compatible = "rfkill-regulator"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, rfkill_regulator_match);
+#endif
+
static struct platform_driver rfkill_regulator_driver = {
.probe = rfkill_regulator_probe,
.remove = rfkill_regulator_remove,
.driver = {
.name = "rfkill-regulator",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(rfkill_regulator_match),
},
};
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v5 00/14] Add support for MSM's mmio clock/reset controller
From: Joe Perches @ 2014-02-07 20:51 UTC (permalink / raw)
To: frowand.list
Cc: Stephen Boyd, Mike Turquette, linux-kernel, linux-arm-msm,
linux-arm-kernel, devicetree, Saravana Kannan
In-Reply-To: <52F53642.3030606@gmail.com>
On Fri, 2014-02-07 at 11:38 -0800, Frank Rowand wrote:
> On 2/6/2014 9:11 PM, Joe Perches wrote:
> > For patch 1, what checkpatch bug might that be?
[]
> Sorry, it is patch 2, not patch 1 ("[PATCH v5 02/14] clk: Add set_rate_and_parent() op"):
>
> WARNING: Multiple spaces after return type
> #188: FILE: include/linux/clk-provider.h:154:
> + int (*set_rate_and_parent)(struct clk_hw *hw,
>
> total: 0 errors, 1 warnings, 152 lines checked
Yup, that one might be a bit aggressive.
It's a complaint about function pointer declaration style.
from checkpatch:
------------------------------------------------------
# unnecessary space "type (*funcptr)(args...)"
elsif ($declare =~ /\s{2,}$/) {
WARN("SPACING",
"Multiple spaces after return type\n" . $herecurr);
}
------------------------------------------------------
This is warning about style equivalent to declarations like:
int foo(int bar);
checkpatch doesn't warn about declarations of that style,
so likely checkpatch shouldn't warn about multiple spaces
after a function pointer return type either.
I don't have a strong opinion one way or another about it.
If you think it should be silenced, it could be either
downgraded to a CHK or removed altogether.
^ permalink raw reply
* [PATCH v3 6/7] devicetree: bindings: Document Krait performance monitor units (PMU)
From: Stephen Boyd @ 2014-02-07 21:01 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, devicetree
In-Reply-To: <1391806885-24210-1-git-send-email-sboyd@codeaurora.org>
Document the Krait PMU compatible string.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Documentation/devicetree/bindings/arm/pmu.txt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
index 3e1e498fea96..ce731441e64f 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -16,7 +16,14 @@ Required properties:
"arm,arm11mpcore-pmu"
"arm,arm1176-pmu"
"arm,arm1136-pmu"
-- interrupts : 1 combined interrupt or 1 per core.
+ "qcom,krait-pmu"
+- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
+ interrupt (PPI) then 1 interrupt should be specified.
+
+Optional properties:
+
+- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
+ events.
Example:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 10/9] ARM: msm: Remove board-dt.c
From: Stephen Boyd @ 2014-02-07 21:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, linux-arm-msm, Rohit Vaswani, David Brown,
Kumar Gala, devicetree, Mark Rutland, Arnd Bergmann, Russell King
In-Reply-To: <1387845593-10050-1-git-send-email-sboyd@codeaurora.org>
The default machine descriptor satisfies our needs now that the
SMP ops are set based on the enable-method in devicetree and we're
part of the multiplatform kernel. Drop this file.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/mach-msm/Makefile | 1 -
arch/arm/mach-msm/board-dt.c | 27 ---------------------------
2 files changed, 28 deletions(-)
delete mode 100644 arch/arm/mach-msm/board-dt.c
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 721f27f50d96..e6b33cca67c2 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -26,6 +26,5 @@ obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o b
obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o
obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
-obj-$(CONFIG_ARCH_MSM_DT) += board-dt.o
obj-$(CONFIG_MSM_GPIOMUX) += gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o
diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
deleted file mode 100644
index 1e3af2ba9981..000000000000
--- a/arch/arm/mach-msm/board-dt.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/* Copyright (c) 2010-2012,2013 The Linux Foundation. All rights reserved.
- *
- * 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.
- */
-
-#include <linux/init.h>
-
-#include <asm/mach/arch.h>
-
-static const char * const msm_dt_match[] __initconst = {
- "qcom,msm8660-fluid",
- "qcom,msm8660-surf",
- "qcom,msm8960-cdp",
- "qcom,apq8074-dragonboard",
- NULL
-};
-
-DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
- .dt_compat = msm_dt_match,
-MACHINE_END
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v4 0/7] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: David Lanzendörfer @ 2014-02-07 21:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo, Maxime Ripard,
Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello
The following patchset adds support for the SD/MMC host found in the Allwinner SoCs.
It contains all the necessary modifications for clock environment and also the device
tree script modification which add it to all the boards using it.
The clock environment function needed for phase offset configuration has
been proposed and implemented by Emilio.
A lot of work and cleanup has been done by Hans de Goede. Special thanks to him!
This patchset is the 4th attempt to send this driver upstream.
Changes since v1:
-Using mmc_of_parse instead of diy dt parsing
-Adding nodes for all mmc controller to the dtsi files,
including sofar unused controllers
-Using generic GPIO slot library for WP/CD
-Adding additional MMC device nodes into DTSI files
Changes since v2:
-Add missing Signed-off-by tags
-Stop using __raw_readl / __raw_writel so that barriers are properly used
-Adding missing new lines
-Adding missing patch for automatic reparenting of clocks
Changes since v3:
-Move clk_enable / disable into host_init / exit (Hans)
-Fix hang on boot caused by irq storm (Hans)
regards
David
---
David Lanzendörfer (4):
ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
ARM: dts: sun7i: Add support for mmc
ARM: dts: sun4i: Add support for mmc
ARM: dts: sun5i: Add support for mmc
Emilio López (2):
clk: sunxi: factors: automatic reparenting support
clk: sunxi: Implement MMC phase control
Hans de Goede (1):
ARM: sunxi: clk: export clk_sunxi_mmc_phase_control
arch/arm/boot/dts/sun4i-a10-a1000.dts | 8
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 8
arch/arm/boot/dts/sun4i-a10.dtsi | 54 +
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 30 +
arch/arm/boot/dts/sun5i-a10s.dtsi | 44 +
arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts | 15
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 15
arch/arm/boot/dts/sun5i-a13.dtsi | 37 +
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 8
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 23 +
arch/arm/boot/dts/sun7i-a20.dtsi | 61 ++
drivers/clk/sunxi/clk-factors.c | 36 +
drivers/clk/sunxi/clk-sunxi.c | 35 +
drivers/mmc/host/Kconfig | 7
drivers/mmc/host/Makefile | 2
drivers/mmc/host/sunxi-mci.c | 871 ++++++++++++++++++++++
drivers/mmc/host/sunxi-mci.h | 239 ++++++
include/linux/clk/sunxi.h | 22 +
19 files changed, 1523 insertions(+)
create mode 100644 drivers/mmc/host/sunxi-mci.c
create mode 100644 drivers/mmc/host/sunxi-mci.h
create mode 100644 include/linux/clk/sunxi.h
--
Signature
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox