* [PATCH v6 2/7] drivers: cpuidle: implement DT based idle states infrastructure
From: Ashwin Chaugule @ 2014-07-23 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723173204.GB21746@e102568-lin.cambridge.arm.com>
Hi Lorenzo,
On 23 July 2014 13:32, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> > +/**
>> > + * dt_init_idle_driver() - Parse the DT idle states and initialize the
>> > + * idle driver states array
>> > + *
>> > + * @drv: Pointer to CPU idle driver to be initialized
>> > + * @start_idx: First idle state index to be initialized
>> > + *
>> > + * On success the states array in the cpuidle driver contains
>> > + * initialized entries in the states array, starting from index start_idx.
>> > + *
>> > + * Return:
>> > + * 0 on success
>> > + * <0 on failure
>> > + */
>> > +int dt_init_idle_driver(struct cpuidle_driver *drv, unsigned int start_idx)
>> > +{
>> > + unsigned int i, state_idx = start_idx;
>> > + struct cpuidle_state *idle_state;
>> > + struct device_node *state_node, *cpu_node;
>> > +
>> > +
>> > + if (state_idx >= CPUIDLE_STATE_MAX)
>> > + return -EINVAL;
>> > + /*
>> > + * We get the idle states for the first logical cpu in the
>> > + * driver mask. The kernel does not check idle states on all
>> > + * cpus in the driver mask, they are assumed to be the same
>> > + * by default.
>> > + */
>> > + cpu_node = of_cpu_device_node_get(cpumask_first(drv->cpumask));
>>
>> Is this an assumption for the short term? My understanding from the
>> corresponding ACPI discussions is that the order of idle states may
>> not necessarily be same for all CPUs, even for big.Little?
>
> Well, it is more of a problem of the CPUidle infrastructure than related
> to this specific patchset. The idle states for a specific cpumask (ie CPUidle
> driver) are expected to be all the same, same order same data.
>
> Current driver can be used on homegeneous ARM64 SMP systems, but I am fairly
> confident we can extend it for big.LITTLE and also other funky SMP
> configurations, the parsing code only expects all cpus in the mask
> to have the same set of idle states (and so does the CPUidle core), if that's
> not the case, the cpus belong in different CPUidle drivers (ie a CPUidle
> driver is a set of states valid on a cpumask).
>
> So my answer is yes, it is a proper assumption and not only for the
> short term, but in general.
>
> HTH,
> Lorenzo
Ok. Thanks for the explanation. I just had a look at
drivers/cpuidle/cpuidle-big_little.c. So, you'll need another call to
cpuidle_register() should there be another cpumask with a different
set of idle states.
Cheers,
Ashwin
^ permalink raw reply
* [PATCH v2 14/16] cpufreq: Add cpufreq driver for Tegra124
From: Tuomas Tynkkynen @ 2014-07-23 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohponLh66Ubr6=wY2OZCCrK11KZDj=DmXXqXsGGTHSG45wpA@mail.gmail.com>
On 23/07/14 19:50, Viresh Kumar wrote:
> On 23 July 2014 17:27, Tuomas Tynkkynen <ttynkkynen@nvidia.com> wrote:
>> The platform device is required for the deferred probe that can happen if the
>> DFLL driver hasn't initialized yet, and module_init() callbacks don't seem to
>> respect -EPROBE_DEFER.
>
> Oh, which call in this file will return EPROBE_DEFER? I couldn't make out
> which one will depend on DFLL driver.
>
It's this:
+static int tegra124_cpufreq_probe(struct platform_device *pdev)
+{
[...]
+
+ dfll_clk = of_clk_get_by_name(cpu_dev->of_node, "dfll");
+ if (IS_ERR(dfll_clk)) {
+ ret = PTR_ERR(dfll_clk);
+ goto out_put_cpu_clk;
+ }
--
nvpublic
^ permalink raw reply
* [PATCH v3 0/8] Two-phase seccomp and x86 tracing changes
From: Andy Lutomirski @ 2014-07-23 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jJ93-vto9voMENc4jX5itcd_Rm5AZjeChF57fpMYnWocA@mail.gmail.com>
On Tue, Jul 22, 2014 at 12:37 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jul 21, 2014 at 6:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> [applies on jmorris's security-next tree]
>>
>> This is both a cleanup and a speedup. It reduces overhead due to
>> installing a trivial seccomp filter by 87%. The speedup comes from
>> avoiding the full syscall tracing mechanism for filters that don't
>> return SECCOMP_RET_TRACE.
>>
>> This series works by splitting the seccomp hooks into two phases.
>> The first phase evaluates the filter; it can skip syscalls, allow
>> them, kill the calling task, or pass a u32 to the second phase. The
>> second phase requires a full tracing context, and it sends ptrace
>> events if necessary.
>>
>> Once this is done, I implemented a similar split for the x86 syscall
>> entry work. The C callback is invoked in two phases: the first has
>> only a partial frame, and it can request phase 2 processing with a
>> full frame.
>>
>> Finally, I switch the 64-bit system_call code to use the new split
>> entry work. This is a net deletion of assembly code: it replaces
>> all of the audit entry muck.
>>
>> In the process, I fixed some bugs.
>>
>> If this is acceptable, someone can do the same tweak for the
>> ia32entry and entry_32 code.
>>
>> This passes all seccomp tests that I know of. Now that it's properly
>> rebased, even the previously expected failures are gone.
>>
>> Kees, if you like this version, can you create a branch with patches
>> 1-4? I think that the rest should go into tip/x86 once everyone's happy
>> with it.
>>
>> Changes from v2:
>> - Fixed 32-bit x86 build (and the tests pass).
>> - Put the doc patch where it belongs.
>
> Thanks! This looks good to me. I'll add it to my tree.
>
> Peter, how do you feel about this series? Do the x86 changes look good to you?
>
It looks like patches 1-4 have landed here:
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=seccomp/fastpath
hpa, what's the route forward for the x86 part?
--Andy
^ permalink raw reply
* [PATCH v3] platform: Make platform_bus device a platform device
From: Greg Kroah-Hartman @ 2014-07-23 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406135762.25343.151.camel@hornet>
On Wed, Jul 23, 2014 at 06:16:02PM +0100, Pawel Moll wrote:
> On Tue, 2014-07-22 at 19:15 +0100, Greg Kroah-Hartman wrote:
> > > > diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c
> > > > index 1b4366a..48c3817 100644
> > > > --- a/arch/arm/mach-imx/devices/devices.c
> > > > +++ b/arch/arm/mach-imx/devices/devices.c
> > > > @@ -24,12 +24,12 @@
> > > >
> > > > struct device mxc_aips_bus = {
> > > > .init_name = "mxc_aips",
> > > > - .parent = &platform_bus,
> > > > + .parent = &platform_bus.dev,
> > > > };
> > > >
> > > > struct device mxc_ahb_bus = {
> > > > .init_name = "mxc_ahb",
> > > > - .parent = &platform_bus,
> > > > + .parent = &platform_bus.dev,
> > > > };
> > > >
> > > > int __init mxc_device_init(void)
> > >
> > > Seems that the author meant to have those two bus devices hanging from
> > > the platform_bus in device hierarchy. Seems fair enough to me.
> >
> > No, not at all, this is a different bus, put the root bus at the root of
> > the sysfs tree, not at some "arbritrary" point on a platform device.
>
> I think the author considers platform bus is understood as a
> representation of the MMIO space (and he's not alone). So then he wants
> to represent the physical hierarchy of the interconnect to get it in
> separate places in the /sys/devices/* tree.
That's fine, but again, it's not a "child" of the platform bus.
Otherwise you could argue that all busses should belong under the
platform bus as well, which isn't going to happen.
> Whether it's a good thing to do or not, have no strong opinion, but can
> understand his approach. I don't think it's a big deal either way.
Great, make it NULL :)
> > > > diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c
> > > > index bd37747..4e4b7a2 100644
> > > > --- a/drivers/char/tile-srom.c
> > > > +++ b/drivers/char/tile-srom.c
> > > > @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index)
> > > > SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0)
> > > > return -EIO;
> > > >
> > > > - dev = device_create(srom_class, &platform_bus,
> > > > + dev = device_create(srom_class, &platform_bus.dev,
> > > > MKDEV(srom_major, index), srom, "%d", index);
> > > > return PTR_ERR_OR_ZERO(dev);
> > > > }
> > >
> > > Again, non-platform device placed in the hierarchy.
> >
> > Again, not ok. If it's a platform device, it's a platform device, and
> > make it one. If it isn't, like this one, make it a virtual device and
> > pass NULL here.
>
> Yeah, I can't disagree here.
>
> > > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> > > > index 7e834fb..9a2b0d0 100644
> > > > --- a/drivers/mmc/host/sdhci-pltfm.c
> > > > +++ b/drivers/mmc/host/sdhci-pltfm.c
> > > > @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
> > > > dev_err(&pdev->dev, "Invalid iomem size!\n");
> > > >
> > > > /* Some PCI-based MFD need the parent here */
> > > > - if (pdev->dev.parent != &platform_bus && !np)
> > > > + if (pdev->dev.parent != &platform_bus.dev && !np)
> > > > host = sdhci_alloc_host(pdev->dev.parent,
> > > > sizeof(struct sdhci_pltfm_host) + priv_size);
> > > > else
> > >
> > > Special treatment for non-platform devices.
> >
> > Ugh, why should you care? I don't understand the logic here.
>
> Neither do I, but maybe there is' some :-) I definitely wouldn't like to
> change the behaviour without checking with the maintainers.
Then let's ask :)
> > > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> > > > index 3cbb57a..c14c36f 100644
> > > > --- a/drivers/scsi/hosts.c
> > > > +++ b/drivers/scsi/hosts.c
> > > > @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev,
> > > > goto fail;
> > > >
> > > > if (!shost->shost_gendev.parent)
> > > > - shost->shost_gendev.parent = dev ? dev : &platform_bus;
> > > > + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev;
> > > > if (!dma_dev)
> > > > dma_dev = shost->shost_gendev.parent;
> > > >
> > >
> > > shost_gendev is a generic (as in struct device, non-platform one)
> > > device, that is being explicitly placed in the hierarchy.
> >
> > Then make it a virtual device, as that's what it is, replace this with
> > NULL.
>
> Makes sense to me, I just wonder what the author meant.
With scsi code, who knows :)
> > > So it makes it 4, not 3 ;-) places where referencing platform_bus
> > > *maybe* makes some sense.
> >
> > Nope, see above :)
>
> Let me just point out that I'm just playing the devil's advocate
> here :-)
Of course, I'm not "shooting the messenger" at all, just pointing out
problems with the code, you didn't write it.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 3/3] crypto: Add Allwinner Security System crypto accelerator
From: Marek Vasut @ 2014-07-23 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D0045C.6090605@gmail.com>
On Wednesday, July 23, 2014 at 08:52:12 PM, Corentin LABBE wrote:
> Le 23/07/2014 17:51, Marek Vasut a ?crit :
> > On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> >> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> >>> On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> >>>> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> >>>>>> + }
> >>>>>> +#endif
> >>>>>> +
> >>>>>> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> >>>>>> + err = crypto_register_shash(&sunxi_md5_alg);
> >>>>>
> >>>>> Do not use shash for such device. This is clearly and ahash (and
> >>>>> async in general) device. The rule of a thumb here is that you use
> >>>>> sync algos only for devices which have dedicated instructions for
> >>>>> computing the transformation. For devices which are attached to some
> >>>>> kind of bus, you use async algos (ahash etc).
> >>>>
> >>>> I'm sorry that I didn't catch this earlier but there is no such
> >>>> rule.
> >>>>
> >>>> Unless you need the async interface you should stick to the sync
> >>>> interfaces for the sake of simplicity.
> >>>>
> >>>> We have a number of existing drivers that are synchronous but
> >>>> using the async interface. They should either be converted
> >>>> over to the sync interface or made interrupt-driven if possible.
> >>>
> >>> Sure, but this device is interrupt driven and uses DMA to feed the
> >>> crypto engine, therefore async, right ?
> >>
> >> If it's interrupt-driven, then yes it would certainly make sense to
> >> be async. But all I see is polling in the latest posting, was the
> >> first version different?
> >
> > I stand corrected then, sorry.
> >
> > Is it possible to use DMA to feed the crypto accelerator, Corentin?
> >
> > Best regards,
> > Marek Vasut
>
> Yes, DMA is possible and will be implemented soon.
> So if I have well understood, I keep using async interface.
Yeah, in this case, using DMA and async interface combo is the way to go.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH RFC] arm/mach-imximx/iomux-v3: Do not export symbol without public declaration
From: Arnd Bergmann @ 2014-07-23 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406120520-14390-1-git-send-email-alexander.stein@systec-electronic.com>
On Wednesday 23 July 2014, Alexander Stein wrote:
> Both mxc_iomux_v3_setup_pad and mxc_iomux_v3_setup_multiple_pads are
> declared in iomux-v3.h which can't be used in any module. None of the
> objects in this directory is tristate. Neither can the header be included
> in out-of-tree modules.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Makese sense, but I think if you do this, it would be reasonable
to do the same for all three iomux implementations (v1, imx31, v3).
Arnd
^ permalink raw reply
* [PATCH CFT] arm: netx: Migrate DEBUG_LL macros to shared directory
From: Arnd Bergmann @ 2014-07-23 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406108463-11726-1-git-send-email-daniel.thompson@linaro.org>
On Wednesday 23 July 2014, Daniel Thompson wrote:
> As part of the migration we introduce DEBUG_UART_PHYS/DEBUG_UART_VIRT
> which default to UART1 but allow a user to configure UART2 or UART3.
> We also introduce symbolic names for the registers and flags.
>
> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
Looks good to me.
Acked-by: Arnd Bergmann <arnd@arndb.de
^ permalink raw reply
* [PATCH 1/3] ARM: exynos: remove unused <mach/memory.h>
From: Uwe Kleine-König @ 2014-07-23 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgA0fc0_8JOOE01y=UKv-eAZuWiAkAKHG5iam0Zkhp9TA@mail.gmail.com>
Hello,
On Tue, Jul 22, 2014 at 09:14:33AM -0700, Olof Johansson wrote:
> > Patch 2 (v2!)
> >
> > ARM: remove remaining definitions of PLAT_PHYS_OFFSET from <mach/memory.h>
> >
> > touches several arch/arm/mach-*/include/mach/memory.h and
> > arch/arm/Kconfig. armsoc? Russell?
>
> This can go through either, but Russell has already reviewed it once
> so send it to his patch tracker.
>
> > Patch 3 fixes a warning regarding nommu and touches the Kconfig entry
> > for Integrator and Renesas (non-multiplatform). armsoc?
>
> Don't know without seeing the patch. What's the patch subject so I can find it?
I talked to Olof on irc. I sent patches 2 and 3 to the patch tracker as
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8112/1
and
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8113/1
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH RESEND v2] bus: ARM CCN PMU driver
From: Arnd Bergmann @ 2014-07-23 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406050379-15199-1-git-send-email-pawel.moll@arm.com>
On Tuesday 22 July 2014, Pawel Moll wrote:
> Driver providing perf backend for ARM Cache Coherent Network
> interconnect. Supports counting all hardware events and crosspoint
> watchpoints.
>
> Currently works with CCN-504 only, although there should be
> no changes required for CCN-508 (just impossible to test it now).
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Applied to next/drivers, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: efm32: switch to vendor,device compatible strings
From: Uwe Kleine-König @ 2014-07-23 20:29 UTC (permalink / raw)
To: linux-arm-kernel
The mainline drivers were fixed in commits
- 4ea8dafd2475 (serial: efm32: use $vendor,$device scheme for
compatible string)
- 12f6dd860cf8 (spi: efm32: use $vendor,$device scheme for compatible
string)
- 63cc122381bd (clocksource: efm32: use $vendor,$device scheme for
compatible string)
which are all in 3.16-rc1 to also support these compatible strings.
For the other affected peripherals (adc and gpio) there are no drivers in
mainline yet.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/efm32gg.dtsi | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/efm32gg.dtsi b/arch/arm/boot/dts/efm32gg.dtsi
index 106d505c5d3d..c747983771c7 100644
--- a/arch/arm/boot/dts/efm32gg.dtsi
+++ b/arch/arm/boot/dts/efm32gg.dtsi
@@ -23,7 +23,7 @@
soc {
adc: adc at 40002000 {
- compatible = "efm32,adc";
+ compatible = "energymicro,efm32-adc";
reg = <0x40002000 0x400>;
interrupts = <7>;
clocks = <&cmu clk_HFPERCLKADC0>;
@@ -31,7 +31,7 @@
};
gpio: gpio at 40006000 {
- compatible = "efm32,gpio";
+ compatible = "energymicro,efm32-gpio";
reg = <0x40006000 0x1000>;
interrupts = <1 11>;
gpio-controller;
@@ -45,7 +45,7 @@
i2c0: i2c at 4000a000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "efm32,i2c";
+ compatible = "energymicro,efm32-i2c";
reg = <0x4000a000 0x400>;
interrupts = <9>;
clocks = <&cmu clk_HFPERCLKI2C0>;
@@ -56,7 +56,7 @@
i2c1: i2c at 4000a400 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "efm32,i2c";
+ compatible = "energymicro,efm32-i2c";
reg = <0x4000a400 0x400>;
interrupts = <10>;
clocks = <&cmu clk_HFPERCLKI2C1>;
@@ -67,7 +67,7 @@
spi0: spi at 4000c000 { /* USART0 */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "efm32,spi";
+ compatible = "energymicro,efm32-spi";
reg = <0x4000c000 0x400>;
interrupts = <3 4>;
clocks = <&cmu clk_HFPERCLKUSART0>;
@@ -77,7 +77,7 @@
spi1: spi at 4000c400 { /* USART1 */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "efm32,spi";
+ compatible = "energymicro,efm32-spi";
reg = <0x4000c400 0x400>;
interrupts = <15 16>;
clocks = <&cmu clk_HFPERCLKUSART1>;
@@ -87,7 +87,7 @@
spi2: spi at 4000c800 { /* USART2 */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "efm32,spi";
+ compatible = "energymicro,efm32-spi";
reg = <0x4000c800 0x400>;
interrupts = <18 19>;
clocks = <&cmu clk_HFPERCLKUSART2>;
@@ -95,7 +95,7 @@
};
uart0: uart at 4000c000 { /* USART0 */
- compatible = "efm32,uart";
+ compatible = "energymicro,efm32-uart";
reg = <0x4000c000 0x400>;
interrupts = <3 4>;
clocks = <&cmu clk_HFPERCLKUSART0>;
@@ -103,7 +103,7 @@
};
uart1: uart at 4000c400 { /* USART1 */
- compatible = "efm32,uart";
+ compatible = "energymicro,efm32-uart";
reg = <0x4000c400 0x400>;
interrupts = <15 16>;
clocks = <&cmu clk_HFPERCLKUSART1>;
@@ -111,7 +111,7 @@
};
uart2: uart at 4000c800 { /* USART2 */
- compatible = "efm32,uart";
+ compatible = "energymicro,efm32-uart";
reg = <0x4000c800 0x400>;
interrupts = <18 19>;
clocks = <&cmu clk_HFPERCLKUSART2>;
@@ -119,7 +119,7 @@
};
uart3: uart at 4000e000 { /* UART0 */
- compatible = "efm32,uart";
+ compatible = "energymicro,efm32-uart";
reg = <0x4000e000 0x400>;
interrupts = <20 21>;
clocks = <&cmu clk_HFPERCLKUART0>;
@@ -127,7 +127,7 @@
};
uart4: uart at 4000e400 { /* UART1 */
- compatible = "efm32,uart";
+ compatible = "energymicro,efm32-uart";
reg = <0x4000e400 0x400>;
interrupts = <22 23>;
clocks = <&cmu clk_HFPERCLKUART1>;
@@ -135,28 +135,28 @@
};
timer0: timer at 40010000 {
- compatible = "efm32,timer";
+ compatible = "energymicro,efm32-timer";
reg = <0x40010000 0x400>;
interrupts = <2>;
clocks = <&cmu clk_HFPERCLKTIMER0>;
};
timer1: timer at 40010400 {
- compatible = "efm32,timer";
+ compatible = "energymicro,efm32-timer";
reg = <0x40010400 0x400>;
interrupts = <12>;
clocks = <&cmu clk_HFPERCLKTIMER1>;
};
timer2: timer at 40010800 {
- compatible = "efm32,timer";
+ compatible = "energymicro,efm32-timer";
reg = <0x40010800 0x400>;
interrupts = <13>;
clocks = <&cmu clk_HFPERCLKTIMER2>;
};
timer3: timer at 40010c00 {
- compatible = "efm32,timer";
+ compatible = "energymicro,efm32-timer";
reg = <0x40010c00 0x400>;
interrupts = <14>;
clocks = <&cmu clk_HFPERCLKTIMER3>;
--
2.0.0
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 3)
From: Arnd Bergmann @ 2014-07-23 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722205706.GA23220@titan.lakedaemon.net>
On Tuesday 22 July 2014, Jason Cooper wrote:
> All,
>
> Here's the cpufreq changes I mentioned over the weekend. It's been in
> -next for a while. Once I get the new version of cpuidle from ThomasP,
> I'll push that as quickly as possible.
Just for my information, is this coordinated with the cpufreq maintainers?
I remember being asked to ensure all cpufreq/cpuidle stuff has an Ack
from them, even stuff that doesn't touch drivers/cpufreq at all.
The contents look good to me. I can merge them if there are no objections
from Viresh, feel free to send the next batch already without waiting
for me to pull.
> As usual (do I need to type this each time any more? :) ), this is an
> incremental pull request from tags/mvebu-soc-3.17-2 up to
> tags/mvebu-soc-3.17-3 on the mvebu/soc branch.
It certainly helps me to have this information, but you can write it
more briefly, e.g. "based on tags/mvebu-soc-3.17-2".
Arnd
> The following changes since commit ba364fc752daeded072a5ef31e43b84cb1f9e5fd:
>
> ARM: Kirkwood: Remove mach-kirkwood (2014-07-13 22:13:39 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-soc-3.17-3
>
> for you to fetch changes up to ba3ec5780bba27819bbc4f669e6c77418a00f14b:
>
> Merge branch 'mvebu/soc-cpufreq' into mvebu/soc (2014-07-22 20:46:48 +0000)
>
> ----------------------------------------------------------------
>
> mvebu SoC changes for v3.17 (round 3)
>
> - mvebu:
> - Add cpufreq support for Armada XP
>
> ----------------------------------------------------------------
> Jason Cooper (1):
> Merge branch 'mvebu/soc-cpufreq' into mvebu/soc
>
> Thomas Petazzoni (3):
> ARM: mvebu: ensure CPU clocks are enabled
> ARM: mvebu: extend PMSU code to support dynamic frequency scaling
> clk: mvebu: extend clk-cpu for dynamic frequency scaling
>
> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 5 +-
> arch/arm/mach-mvebu/platsmp.c | 1 +
> arch/arm/mach-mvebu/pmsu.c | 162 +++++++++++++++++++++
> drivers/clk/mvebu/clk-cpu.c | 80 +++++++++-
> include/linux/mvebu-pmsu.h | 20 +++
> 5 files changed, 261 insertions(+), 7 deletions(-)
> create mode 100644 include/linux/mvebu-pmsu.h
>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: DT fixes for v3.17 (round 3)
From: Arnd Bergmann @ 2014-07-23 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723121847.GD23220@titan.lakedaemon.net>
On Wednesday 23 July 2014, Jason Cooper wrote:
> All,
>
> This is a small round of fixes for new nodes adding ethernet support to
> Armada 375. Since the nodes were only added for v3.17, these patches
> are queued for v3.17, instead of as fixes for v3.16-rcX.
>
> This is an incremental pull request from tags/mvebu-dt-3.17-2 up to
> tags/mvebu-dt-3.17-3 on the mvebu/dt branch.
>
> Please pull.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Xilinx Zynq dt changes for v3.17 - second pull request
From: Arnd Bergmann @ 2014-07-23 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CFAA00.3080008@monstr.eu>
On Wednesday 23 July 2014, Michal Simek wrote:
> Hi,
>
> please add these two patches to your arm-soc tree.
> This branch is based on zynq/dt branch which is already
> in your tree.
> http://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/log/?h=zynq/dt
>
> GPIO driver and binding are already available in Linus gpio tree
> and it enables us to do testing on Linux-next.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCHv8 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
From: Jonathan Cameron @ 2014-07-23 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405994696-3117-2-git-send-email-cw00.choi@samsung.com>
On 22/07/14 03:04, Chanwoo Choi wrote:
> This patchset add 'exynos_adc_data' structure which includes some functions
> to control ADC operation and specific data according to ADC version (v1 or v2).
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Reviewed-by: Tomasz Figa <t.figa@samsung.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.
2 minor tweaks where you had duplicate consts that gcc moaned about during my
build tests.
Jonathan
> ---
> drivers/iio/adc/exynos_adc.c | 226 ++++++++++++++++++++++++++++---------------
> 1 file changed, 147 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 010578f..dde4ca8 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -39,11 +39,6 @@
> #include <linux/iio/machine.h>
> #include <linux/iio/driver.h>
>
> -enum adc_version {
> - ADC_V1,
> - ADC_V2
> -};
> -
> /* EXYNOS4412/5250 ADC_V1 registers definitions */
> #define ADC_V1_CON(x) ((x) + 0x00)
> #define ADC_V1_DLY(x) ((x) + 0x08)
> @@ -85,6 +80,7 @@ enum adc_version {
> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>
> struct exynos_adc {
> + struct exynos_adc_data *data;
> void __iomem *regs;
> void __iomem *enable_reg;
> struct clk *clk;
> @@ -97,43 +93,139 @@ struct exynos_adc {
> unsigned int version;
> };
>
> -static const struct of_device_id exynos_adc_match[] = {
> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
> - {},
> +struct exynos_adc_data {
> + int num_channels;
> +
> + void (*init_hw)(struct exynos_adc *info);
> + void (*exit_hw)(struct exynos_adc *info);
> + void (*clear_irq)(struct exynos_adc *info);
> + void (*start_conv)(struct exynos_adc *info, unsigned long addr);
> };
> -MODULE_DEVICE_TABLE(of, exynos_adc_match);
>
> -static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
> {
> - const struct of_device_id *match;
> + u32 con1;
>
> - match = of_match_node(exynos_adc_match, pdev->dev.of_node);
> - return (unsigned int)match->data;
> + writel(1, info->enable_reg);
> +
> + /* set default prescaler values and Enable prescaler */
> + con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
> +
> + /* Enable 12-bit ADC resolution */
> + con1 |= ADC_V1_CON_RES;
> + writel(con1, ADC_V1_CON(info->regs));
> +}
> +
> +static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
> +{
> + u32 con;
> +
> + writel(0, info->enable_reg);
> +
> + con = readl(ADC_V1_CON(info->regs));
> + con |= ADC_V1_CON_STANDBY;
> + writel(con, ADC_V1_CON(info->regs));
> +}
> +
> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
> +{
> + writel(1, ADC_V1_INTCLR(info->regs));
> }
>
> -static void exynos_adc_hw_init(struct exynos_adc *info)
> +static void exynos_adc_v1_start_conv(struct exynos_adc *info,
> + unsigned long addr)
> +{
> + u32 con1;
> +
> + writel(addr, ADC_V1_MUX(info->regs));
> +
> + con1 = readl(ADC_V1_CON(info->regs));
> + writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
> +}
> +
> +static const struct exynos_adc_data const exynos_adc_v1_data = {
duplicate const
> + .num_channels = MAX_ADC_V1_CHANNELS,
> +
> + .init_hw = exynos_adc_v1_init_hw,
> + .exit_hw = exynos_adc_v1_exit_hw,
> + .clear_irq = exynos_adc_v1_clear_irq,
> + .start_conv = exynos_adc_v1_start_conv,
> +};
> +
> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
> {
> u32 con1, con2;
>
> - if (info->version == ADC_V2) {
> - con1 = ADC_V2_CON1_SOFT_RESET;
> - writel(con1, ADC_V2_CON1(info->regs));
> + writel(1, info->enable_reg);
>
> - con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
> - ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
> - writel(con2, ADC_V2_CON2(info->regs));
> + con1 = ADC_V2_CON1_SOFT_RESET;
> + writel(con1, ADC_V2_CON1(info->regs));
>
> - /* Enable interrupts */
> - writel(1, ADC_V2_INT_EN(info->regs));
> - } else {
> - /* set default prescaler values and Enable prescaler */
> - con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
> + con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
> + ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
> + writel(con2, ADC_V2_CON2(info->regs));
>
> - /* Enable 12-bit ADC resolution */
> - con1 |= ADC_V1_CON_RES;
> - writel(con1, ADC_V1_CON(info->regs));
> - }
> + /* Enable interrupts */
> + writel(1, ADC_V2_INT_EN(info->regs));
> +}
> +
> +static void exynos_adc_v2_exit_hw(struct exynos_adc *info)
> +{
> + u32 con;
> +
> + writel(0, info->enable_reg);
> +
> + con = readl(ADC_V2_CON1(info->regs));
> + con &= ~ADC_CON_EN_START;
> + writel(con, ADC_V2_CON1(info->regs));
> +}
> +
> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
> +{
> + writel(1, ADC_V2_INT_ST(info->regs));
> +}
> +
> +static void exynos_adc_v2_start_conv(struct exynos_adc *info,
> + unsigned long addr)
> +{
> + u32 con1, con2;
> +
> + con2 = readl(ADC_V2_CON2(info->regs));
> + con2 &= ~ADC_V2_CON2_ACH_MASK;
> + con2 |= ADC_V2_CON2_ACH_SEL(addr);
> + writel(con2, ADC_V2_CON2(info->regs));
> +
> + con1 = readl(ADC_V2_CON1(info->regs));
> + writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
> +}
> +
> +static const struct exynos_adc_data const exynos_adc_v2_data = {
duplicate const
> + .num_channels = MAX_ADC_V2_CHANNELS,
> +
> + .init_hw = exynos_adc_v2_init_hw,
> + .exit_hw = exynos_adc_v2_exit_hw,
> + .clear_irq = exynos_adc_v2_clear_irq,
> + .start_conv = exynos_adc_v2_start_conv,
> +};
> +
> +static const struct of_device_id exynos_adc_match[] = {
> + {
> + .compatible = "samsung,exynos-adc-v1",
> + .data = &exynos_adc_v1_data,
> + }, {
> + .compatible = "samsung,exynos-adc-v2",
> + .data = &exynos_adc_v2_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_adc_match);
> +
> +static struct exynos_adc_data *exynos_adc_get_data(struct platform_device *pdev)
> +{
> + const struct of_device_id *match;
> +
> + match = of_match_node(exynos_adc_match, pdev->dev.of_node);
> + return (struct exynos_adc_data *)match->data;
> }
>
> static int exynos_read_raw(struct iio_dev *indio_dev,
> @@ -144,7 +236,6 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> {
> struct exynos_adc *info = iio_priv(indio_dev);
> unsigned long timeout;
> - u32 con1, con2;
> int ret;
>
> if (mask != IIO_CHAN_INFO_RAW)
> @@ -154,28 +245,15 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> reinit_completion(&info->completion);
>
> /* Select the channel to be used and Trigger conversion */
> - if (info->version == ADC_V2) {
> - con2 = readl(ADC_V2_CON2(info->regs));
> - con2 &= ~ADC_V2_CON2_ACH_MASK;
> - con2 |= ADC_V2_CON2_ACH_SEL(chan->address);
> - writel(con2, ADC_V2_CON2(info->regs));
> -
> - con1 = readl(ADC_V2_CON1(info->regs));
> - writel(con1 | ADC_CON_EN_START,
> - ADC_V2_CON1(info->regs));
> - } else {
> - writel(chan->address, ADC_V1_MUX(info->regs));
> -
> - con1 = readl(ADC_V1_CON(info->regs));
> - writel(con1 | ADC_CON_EN_START,
> - ADC_V1_CON(info->regs));
> - }
> + if (info->data->start_conv)
> + info->data->start_conv(info, chan->address);
>
> timeout = wait_for_completion_timeout
> (&info->completion, EXYNOS_ADC_TIMEOUT);
> if (timeout == 0) {
> dev_warn(&indio_dev->dev, "Conversion timed out! Resetting\n");
> - exynos_adc_hw_init(info);
> + if (info->data->init_hw)
> + info->data->init_hw(info);
> ret = -ETIMEDOUT;
> } else {
> *val = info->value;
> @@ -193,13 +271,11 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> struct exynos_adc *info = (struct exynos_adc *)dev_id;
>
> /* Read value */
> - info->value = readl(ADC_V1_DATX(info->regs)) &
> - ADC_DATX_MASK;
> + info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
> +
> /* clear irq */
> - if (info->version == ADC_V2)
> - writel(1, ADC_V2_INT_ST(info->regs));
> - else
> - writel(1, ADC_V1_INTCLR(info->regs));
> + if (info->data->clear_irq)
> + info->data->clear_irq(info);
>
> complete(&info->completion);
>
> @@ -277,6 +353,12 @@ static int exynos_adc_probe(struct platform_device *pdev)
>
> info = iio_priv(indio_dev);
>
> + info->data = exynos_adc_get_data(pdev);
> + if (!info->data) {
> + dev_err(&pdev->dev, "failed getting exynos_adc_data\n");
> + return -EINVAL;
> + }
> +
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> info->regs = devm_ioremap_resource(&pdev->dev, mem);
> if (IS_ERR(info->regs))
> @@ -319,10 +401,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
> if (ret)
> goto err_disable_reg;
>
> - writel(1, info->enable_reg);
> -
> - info->version = exynos_adc_get_version(pdev);
> -
> platform_set_drvdata(pdev, indio_dev);
>
> indio_dev->name = dev_name(&pdev->dev);
> @@ -331,11 +409,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
> indio_dev->info = &exynos_adc_iio_info;
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->channels = exynos_adc_iio_channels;
> -
> - if (info->version == ADC_V1)
> - indio_dev->num_channels = MAX_ADC_V1_CHANNELS;
> - else
> - indio_dev->num_channels = MAX_ADC_V2_CHANNELS;
> + indio_dev->num_channels = info->data->num_channels;
>
> ret = request_irq(info->irq, exynos_adc_isr,
> 0, dev_name(&pdev->dev), info);
> @@ -349,7 +423,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
> if (ret)
> goto err_irq;
>
> - exynos_adc_hw_init(info);
> + if (info->data->init_hw)
> + info->data->init_hw(info);
>
> ret = of_platform_populate(np, exynos_adc_match, NULL, &indio_dev->dev);
> if (ret < 0) {
> @@ -366,7 +441,8 @@ err_of_populate:
> err_irq:
> free_irq(info->irq, info);
> err_disable_clk:
> - writel(0, info->enable_reg);
> + if (info->data->exit_hw)
> + info->data->exit_hw(info);
> clk_disable_unprepare(info->clk);
> err_disable_reg:
> regulator_disable(info->vdd);
> @@ -382,7 +458,8 @@ static int exynos_adc_remove(struct platform_device *pdev)
> exynos_adc_remove_devices);
> iio_device_unregister(indio_dev);
> free_irq(info->irq, info);
> - writel(0, info->enable_reg);
> + if (info->data->exit_hw)
> + info->data->exit_hw(info);
> clk_disable_unprepare(info->clk);
> regulator_disable(info->vdd);
>
> @@ -394,19 +471,10 @@ static int exynos_adc_suspend(struct device *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> struct exynos_adc *info = iio_priv(indio_dev);
> - u32 con;
>
> - if (info->version == ADC_V2) {
> - con = readl(ADC_V2_CON1(info->regs));
> - con &= ~ADC_CON_EN_START;
> - writel(con, ADC_V2_CON1(info->regs));
> - } else {
> - con = readl(ADC_V1_CON(info->regs));
> - con |= ADC_V1_CON_STANDBY;
> - writel(con, ADC_V1_CON(info->regs));
> - }
> + if (info->data->exit_hw)
> + info->data->exit_hw(info);
>
> - writel(0, info->enable_reg);
> clk_disable_unprepare(info->clk);
> regulator_disable(info->vdd);
>
> @@ -427,8 +495,8 @@ static int exynos_adc_resume(struct device *dev)
> if (ret)
> return ret;
>
> - writel(1, info->enable_reg);
> - exynos_adc_hw_init(info);
> + if (info->data->init_hw)
> + info->data->init_hw(info);
>
> return 0;
> }
>
^ permalink raw reply
* [PATCHv8 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Jonathan Cameron @ 2014-07-23 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405994696-3117-3-git-send-email-cw00.choi@samsung.com>
On 22/07/14 03:04, Chanwoo Choi wrote:
> This patch control special clock for ADC in Exynos series's FSYS block.
> If special clock of ADC is registerd on clock list of common clk framework,
> Exynos ADC drvier have to control this clock.
>
> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
> - 'adc' clock: bus clock for ADC
>
> Exynos3250 has additional 'sclk_adc' clock as following:
> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>
> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
> clock in FSYS_BLK.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: Tomasz Figa <t.figa@samsung.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Another minor tweak but otherwise applied to the togreg branch of iio.git - to
be initially pushed out as testing (this took a while as my local tree was eaten
by a file corruption this evening...)
> ---
> drivers/iio/adc/exynos_adc.c | 111 +++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 103 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index dde4ca8..87e0895 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -24,6 +24,7 @@
> #include <linux/platform_device.h>
> #include <linux/interrupt.h>
> #include <linux/delay.h>
> +#include <linux/errno.h>
> #include <linux/kernel.h>
> #include <linux/slab.h>
> #include <linux/io.h>
> @@ -70,8 +71,9 @@
> #define ADC_V2_CON2_ACH_SEL(x) (((x) & 0xF) << 0)
> #define ADC_V2_CON2_ACH_MASK 0xF
>
> -#define MAX_ADC_V2_CHANNELS 10
> -#define MAX_ADC_V1_CHANNELS 8
> +#define MAX_ADC_V2_CHANNELS 10
> +#define MAX_ADC_V1_CHANNELS 8
> +#define MAX_EXYNOS3250_ADC_CHANNELS 2
>
> /* Bit definitions common for ADC_V1 and ADC_V2 */
> #define ADC_CON_EN_START (1u << 0)
> @@ -81,9 +83,11 @@
>
> struct exynos_adc {
> struct exynos_adc_data *data;
> + struct device *dev;
> void __iomem *regs;
> void __iomem *enable_reg;
> struct clk *clk;
> + struct clk *sclk;
> unsigned int irq;
> struct regulator *vdd;
>
> @@ -95,6 +99,7 @@ struct exynos_adc {
>
> struct exynos_adc_data {
> int num_channels;
> + bool needs_sclk;
>
> void (*init_hw)(struct exynos_adc *info);
> void (*exit_hw)(struct exynos_adc *info);
> @@ -102,6 +107,66 @@ struct exynos_adc_data {
> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
> };
>
> +static void exynos_adc_unprepare_clk(struct exynos_adc *info)
> +{
> + if (info->data->needs_sclk)
> + clk_unprepare(info->sclk);
> + clk_unprepare(info->clk);
> +}
> +
> +static int exynos_adc_prepare_clk(struct exynos_adc *info)
> +{
> + int ret;
> +
> + ret = clk_prepare(info->clk);
> + if (ret) {
> + dev_err(info->dev, "failed preparing adc clock: %d\n", ret);
> + return ret;
> + }
> +
> + if (info->data->needs_sclk) {
> + ret = clk_prepare(info->sclk);
> + if (ret) {
> + clk_unprepare(info->clk);
> + dev_err(info->dev,
> + "failed preparing sclk_adc clock: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void exynos_adc_disable_clk(struct exynos_adc *info)
> +{
> + if (info->data->needs_sclk)
> + clk_disable(info->sclk);
> + clk_disable(info->clk);
> +}
> +
> +static int exynos_adc_enable_clk(struct exynos_adc *info)
> +{
> + int ret;
> +
> + ret = clk_enable(info->clk);
> + if (ret) {
> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
> + return ret;
> + }
> +
> + if (info->data->needs_sclk) {
> + ret = clk_enable(info->sclk);
> + if (ret) {
> + clk_disable(info->clk);
> + dev_err(info->dev,
> + "failed enabling sclk_adc clock: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> static void exynos_adc_v1_init_hw(struct exynos_adc *info)
> {
> u32 con1;
> @@ -208,6 +273,16 @@ static const struct exynos_adc_data const exynos_adc_v2_data = {
> .start_conv = exynos_adc_v2_start_conv,
> };
>
> +static const struct exynos_adc_data const exynos3250_adc_data = {
and another duplicate const.
> + .num_channels = MAX_EXYNOS3250_ADC_CHANNELS,
> + .needs_sclk = true,
> +
> + .init_hw = exynos_adc_v2_init_hw,
> + .exit_hw = exynos_adc_v2_exit_hw,
> + .clear_irq = exynos_adc_v2_clear_irq,
> + .start_conv = exynos_adc_v2_start_conv,
> +};
> +
> static const struct of_device_id exynos_adc_match[] = {
> {
> .compatible = "samsung,exynos-adc-v1",
> @@ -215,6 +290,9 @@ static const struct of_device_id exynos_adc_match[] = {
> }, {
> .compatible = "samsung,exynos-adc-v2",
> .data = &exynos_adc_v2_data,
> + }, {
> + .compatible = "samsung,exynos3250-adc",
> + .data = &exynos3250_adc_data,
> },
> {},
> };
> @@ -376,6 +454,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
> }
>
> info->irq = irq;
> + info->dev = &pdev->dev;
>
> init_completion(&info->completion);
>
> @@ -386,6 +465,16 @@ static int exynos_adc_probe(struct platform_device *pdev)
> return PTR_ERR(info->clk);
> }
>
> + if (info->data->needs_sclk) {
> + info->sclk = devm_clk_get(&pdev->dev, "sclk");
> + if (IS_ERR(info->sclk)) {
> + dev_err(&pdev->dev,
> + "failed getting sclk clock, err = %ld\n",
> + PTR_ERR(info->sclk));
> + return PTR_ERR(info->sclk);
> + }
> + }
> +
> info->vdd = devm_regulator_get(&pdev->dev, "vdd");
> if (IS_ERR(info->vdd)) {
> dev_err(&pdev->dev, "failed getting regulator, err = %ld\n",
> @@ -397,10 +486,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = clk_prepare_enable(info->clk);
> + ret = exynos_adc_prepare_clk(info);
> if (ret)
> goto err_disable_reg;
>
> + ret = exynos_adc_enable_clk(info);
> + if (ret)
> + goto err_unprepare_clk;
> +
> platform_set_drvdata(pdev, indio_dev);
>
> indio_dev->name = dev_name(&pdev->dev);
> @@ -443,7 +536,9 @@ err_irq:
> err_disable_clk:
> if (info->data->exit_hw)
> info->data->exit_hw(info);
> - clk_disable_unprepare(info->clk);
> + exynos_adc_disable_clk(info);
> +err_unprepare_clk:
> + exynos_adc_unprepare_clk(info);
> err_disable_reg:
> regulator_disable(info->vdd);
> return ret;
> @@ -460,7 +555,8 @@ static int exynos_adc_remove(struct platform_device *pdev)
> free_irq(info->irq, info);
> if (info->data->exit_hw)
> info->data->exit_hw(info);
> - clk_disable_unprepare(info->clk);
> + exynos_adc_disable_clk(info);
> + exynos_adc_unprepare_clk(info);
> regulator_disable(info->vdd);
>
> return 0;
> @@ -474,8 +570,7 @@ static int exynos_adc_suspend(struct device *dev)
>
> if (info->data->exit_hw)
> info->data->exit_hw(info);
> -
> - clk_disable_unprepare(info->clk);
> + exynos_adc_disable_clk(info);
> regulator_disable(info->vdd);
>
> return 0;
> @@ -491,7 +586,7 @@ static int exynos_adc_resume(struct device *dev)
> if (ret)
> return ret;
>
> - ret = clk_prepare_enable(info->clk);
> + ret = exynos_adc_enable_clk(info);
> if (ret)
> return ret;
>
>
^ permalink raw reply
* [PATCHv8 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Jonathan Cameron @ 2014-07-23 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405994696-3117-4-git-send-email-cw00.choi@samsung.com>
On 22/07/14 03:04, Chanwoo Choi wrote:
> This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
> special clock ('sclk_adc') for ADC which provide clock to internal ADC.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
> Reviewed-by: Tomasz Figa <t.figa@samsung.com>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied to the togreg branch of iio.git - pushed out as testing for now.
> ---
> .../devicetree/bindings/arm/samsung/exynos-adc.txt | 25 ++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index 832fe8c..adc61b0 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -14,14 +14,21 @@ Required properties:
> for exynos4412/5250 controllers.
> Must be "samsung,exynos-adc-v2" for
> future controllers.
> + Must be "samsung,exynos3250-adc" for
> + controllers compatible with ADC of Exynos3250.
> - reg: Contains ADC register address range (base address and
> length) and the address of the phy enable register.
> - interrupts: Contains the interrupt information for the timer. The
> format is being dependent on which interrupt controller
> the Samsung device uses.
> - #io-channel-cells = <1>; As ADC has multiple outputs
> -- clocks From common clock binding: handle to adc clock.
> -- clock-names From common clock binding: Shall be "adc".
> +- clocks From common clock bindings: handles to clocks specified
> + in "clock-names" property, in the same order.
> +- clock-names From common clock bindings: list of clock input names
> + used by ADC block:
> + - "adc" : ADC bus clock
> + - "sclk" : ADC special clock (only for Exynos3250 and
> + compatible ADC block)
> - vdd-supply VDD input supply.
>
> Note: child nodes can be added for auto probing from device tree.
> @@ -41,6 +48,20 @@ adc: adc at 12D10000 {
> vdd-supply = <&buck5_reg>;
> };
>
> +Example: adding device info in dtsi file for Exynos3250 with additional sclk
> +
> +adc: adc at 126C0000 {
> + compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
> + reg = <0x126C0000 0x100>, <0x10020718 0x4>;
> + interrupts = <0 137 0>;
> + #io-channel-cells = <1>;
> + io-channel-ranges;
> +
> + clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
> + clock-names = "adc", "sclk";
> +
> + vdd-supply = <&buck5_reg>;
> +};
>
> Example: Adding child nodes in dts file
>
>
^ permalink raw reply
* [PATCHv8 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC
From: Jonathan Cameron @ 2014-07-23 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405994696-3117-5-git-send-email-cw00.choi@samsung.com>
On 22/07/14 03:04, Chanwoo Choi wrote:
> This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
> need to control only special clock for ADC. Exynos SoC except for Exynos3250
> has not included special clock for ADC. The exynos ADC driver can control
> special clock if compatible string is 'exynos3250-adc-v2'.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: Tomasz Figa <t.figa@samsung.com>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied to the togreg branch of iio.git - initially pushed out as testing.
Thanks
Jonathan
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
> index 15c9c87..767189a 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -407,10 +407,11 @@
> };
>
> adc: adc at 126C0000 {
> - compatible = "samsung,exynos-adc-v3";
> + compatible = "samsung,exynos3250-adc",
> + "samsung,exynos-adc-v2";
> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
> interrupts = <0 137 0>;
> - clock-names = "adc", "sclk_tsadc";
> + clock-names = "adc", "sclk";
> clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
> #io-channel-cells = <1>;
> io-channel-ranges;
>
^ permalink raw reply
* [GIT PULL v2.1] Mediatek basic support for v3.17
From: Arnd Bergmann @ 2014-07-23 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722181857.GK21766@n2100.arm.linux.org.uk>
On Tuesday 22 July 2014, Russell King - ARM Linux wrote:
> Your To: header contains many tens of people. Which person out of
> all those do you expect to pull your changes?
>
> Email has a way to identify whom you are talking _to_ and whom you wish
> to _copy_ for information purposes.
>
> These are the "To:" and "Cc:" fields on email. Those on the "To:" list
> are those who you are directly addressing your message. Those on the
> Cc: list are "Carbon Copy" recipients, in other words, ones you are
> notifying for information purposes.
Absolutely. In addition, I'd recommend always addressing the maintainer
by name, with a friendly greeting, to ensure they really know they
are meant.
I would also add that you should be careful with the number of people
on Cc in any email. If the Cc list exceeds 1024 characters, the kernel.org
mailing lists will reject your mail. It normally isn't necessary to
have all those people on Cc.
As a special case for arm-soc, please send the patches "To: arm at kernel.org"
so it ends up in the right folders for Olof and me.
> > ----------------------------------------------------------------
> > The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
> >
> > Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
> >
> > are available in the git repository at:
> >
> > https://github.com/mbgg/linux-mediatek.git tags/v3.17-next-mediatek-support
> >
> > for you to fetch changes up to afaedea451149ab8f08c37ce688c8021ed347811:
> >
> > arm: mediatek: add dts for Aquaris5 mobile phone (2014-07-22 17:52:38 +0200)
> >
> > ----------------------------------------------------------------
> > This patch set adds basic support for the Mediatek Cortex-A7 SoCs.
> >
> > Support is quite basic, as the only component working up to now are the
> > timers.
> >
> > Signed-off-by: Matthias Brugger matthias.bgg at gmail.com
> >
> > ----------------------------------------------------------------
> > Matthias Brugger (3):
> > arm: add basic support for Mediatek MT6589 boards
> > dt-bindings: add documentation for Mediatek SoC
> > arm: mediatek: add dts for Aquaris5 mobile phone
Patches look good, I've pulled them into the next/soc tree. It would be
good for the future to sign your tags with a gpg key that is signed by
other kernel developers you know.
Two other patches I'd like to see are:
- adding the dts file to ls arch/arm/boot/dts/Makefile
- adding your platform and all drivers you need to multi_v7_defconfig
so they are included in regular build tests.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 2/2] Adding lenovo in vendor
From: Benoit Masson @ 2014-07-23 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723172646.GI23220@titan.lakedaemon.net>
Looking at the vendor list it should then be "Lenovo Group Ltd." since no other vendor except 1 use Limited all other use Ltd.
Fine with this ?
Le 23 juil. 2014 ? 19:26, Jason Cooper <jason@lakedaemon.net> a ?crit :
> On Wed, Jul 23, 2014 at 05:10:33PM +0200, Andrew Lunn wrote:
>>>> +lenovo LENOVO
>>>
>>> is this their official, registered company name?
>>
>> http://www.lenovo.com/ww/lenovo/FAQs.html says
>>
>> 1. What is Lenovo?s stock symbol (ticker)?
>> HKSE: 992.hk
>> ADR (Level I): LNVGY
>>
>> So i think lenovo is probably the more understandable vendor prefix,
>> even if it is not the official stock ticker.
>>
>> However there official registered company name appears to be
>> Lenovo Group Limited.
>
> Agreed, Benoit, please do 'lenovo Lenovo Group Limited'
>
> thx,
>
> Jason.
^ permalink raw reply
* [PATCH] ARM: mvebu: fix build without platforms selected
From: Arnd Bergmann @ 2014-07-23 21:05 UTC (permalink / raw)
To: linux-arm-kernel
When building a multiplatform kernel that enables 'ARCH_MVEBU' but
none of the individual options under it, we get this link error:
arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init':
:(.text+0x190): undefined reference to `mvebu_setup_boot_addr_wa'
The best solution seems to be to ensure that in this configuration,
we don't actually build any of the mvebu code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 955d4a3afabd..c1e4567a5ab3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -14,11 +14,15 @@ menuconfig ARCH_MVEBU
if ARCH_MVEBU
+config MACH_MVEBU_ANY
+ bool
+
config MACH_MVEBU_V7
bool
select ARMADA_370_XP_TIMER
select CACHE_L2X0
select ARM_CPU_SUSPEND
+ select MACH_MVEBU_ANY
config MACH_ARMADA_370
bool "Marvell Armada 370 boards" if ARCH_MULTI_V7
@@ -75,6 +79,7 @@ config MACH_DOVE
select CACHE_L2X0
select CPU_PJ4
select DOVE_CLK
+ select MACH_MVEBU_ANY
select ORION_IRQCHIP
select ORION_TIMER
select PINCTRL_DOVE
@@ -87,6 +92,7 @@ config MACH_KIRKWOOD
select ARCH_REQUIRE_GPIOLIB
select CPU_FEROCEON
select KIRKWOOD_CLK
+ select MACH_MVEBU_ANY
select ORION_IRQCHIP
select ORION_TIMER
select PCI
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index bc7689e530a4..e24136b42765 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
CFLAGS_pmsu.o := -march=armv7-a
-obj-y += system-controller.o mvebu-soc-id.o
+obj-$(CONFIG_MACH_MVEBU_ANY) += system-controller.o mvebu-soc-id.o
ifeq ($(CONFIG_MACH_MVEBU_V7),y)
obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o
^ permalink raw reply related
* [PATCH 1/2] Added dts defintion for Lenovo ix4-300d nas
From: Benoit Masson @ 2014-07-23 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723164958.GH2856@lunn.ch>
Well after several test with the original BSP driver I found that this is not fully WOL related. It could be that the LED pin is linked to poweron for WOL, yet here the issue is on shutdown pulling up MPP24 should poweroff the deice but only reboots it except is both PHY have some reg written to...
By the way the current nv_neta does not seems to support WOL for 88e1318 and still having them both up is enough to have poweroff to work, which is why I'm putting the WOL as a side track.
Both phy are :
marvell,88e1318
example of a minimal reg write that lead MPP24 to shutdown instead of rebooting on original BSP driver
XXXXX BasicInit
XXXXXXXXXXXXXX phyAdr 0: regOffs: 16 data: 3 caller: mvEthE1310PhyBasicInit+0x2c/0x58
XXXXXXXXXXXXXX phyAdr 0: regOffs: 10 data: 830 caller: mvEthE1310PhyBasicInit+0x3c/0x58
XXXXXXXXXXXXXX phyAdr 0: regOffs: 16 data: 0 caller: mvEthE1310PhyBasicInit+0x4c/0x58
XXXXX BasicInit
XXXXXXXXXXXXXX phyAdr 1: regOffs: 16 data: 3 caller: mvEthE1310PhyBasicInit+0x2c/0x58
XXXXXXXXXXXXXX phyAdr 1: regOffs: 10 data: 830 caller: mvEthE1310PhyBasicInit+0x3c/0x58
XXXXXXXXXXXXXX phyAdr 1: regOffs: 16 data: 0 caller: mvEthE1310PhyBasicInit+0x4c/0x58
I've tried something like:
compatible = "marvell,88e1318";
device_type = "ethernet-phy";
marvell,reg-init =
/* Init led/activity workaround for MP24 shutdown. */
<3 0x10 0 0x830>;
In the dts but without luck
Regards,
Benoit
Le 23 juil. 2014 ? 18:49, Andrew Lunn <andrew@lunn.ch> a ?crit :
>> Well actually the PHY need to be initialized (at least 1 mII reg
>> written), which from marvel LSP driver always occurs, while it
>> doesn't with mainline PHY driver (drivers/net/phy/marvell.c), so the
>> only simple way I found to have at least one PHY reg on both
>> interface written is to have both eth up at OS config level.
>
> Thanks for the information. This sounds like a wake on LAN feature.
> I've seen other Marvell hardware connect a PHY LED output pin to the
> circuit controlling the main power supply. When the PHY detects the
> magic wake-up packet, it 'blinks' the LED so turning the power back
> on.
>
> My guess is, the register write to the PHY is configuring the LED. Do
> you have the datasheet for the PHY? Can you check this?
>
>> Probably the best option would be to have a reg-init = <reg offset
>> value> on both phy dts definition but the current armada mii doesn't
>> support this dts config...
>
> Once we understand what is going on here, we can consider adding
> support for this.
>
> Andrew
^ permalink raw reply
* [PATCH v6 1/2] iio: adc: add driver for Rockchip saradc
From: Heiko Stübner @ 2014-07-23 21:24 UTC (permalink / raw)
To: linux-arm-kernel
The ADC is a 3-channel signal-ended 10-bit Successive Approximation
Register (SAR) A/D Converter. It uses the supply and ground as its reference
and converts the analog input signal into 10-bit binary digital codes.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Hartmut Knaack <knaack.h@gmx.de>
---
changes since v5:
- address comments from Lars-Peter Clausen:
- reinit_completion
- use devm_ioremap_resource
- init_completion before requesting irq
- set clock statically. As pointed out, this is not really a property
of the board, but at most a user setting. But we'll simply wait for
a user of this to come along and set the clock statically for now.
changes since v4:
- address comments from Hartmut Knaack
- explain the DLY_PU_SOC value
- determine regulator voltage in IIO_CHAN_INFO_SCALE
- return ENODEV directly in the !np case
changes since v3:
- address comments from Jonathan Cameron
- explicitly check for negative values in error checks
- change Kconfig depends to ARCH_ROCKCHIP || (ARM && COMPILE_TEST)
to prevent issues due to undefined writel_relaxed functions
The previous check for OF was unecessary, as the only used function
is of_property_read_u32, for which a stub is defined for the !OF case.
changes since v2:
- address more comments from Peter Meerwald
mainly the missing info_mask_shared_by_type element
changes since v1:
- address comments from Peter Meerwald
drivers/iio/adc/Kconfig | 10 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/rockchip_saradc.c | 317 ++++++++++++++++++++++++++++++++++++++
3 files changed, 328 insertions(+)
create mode 100644 drivers/iio/adc/rockchip_saradc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a80d236..01c6ed6 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -187,6 +187,16 @@ config NAU7802
To compile this driver as a module, choose M here: the
module will be called nau7802.
+config ROCKCHIP_SARADC
+ tristate "Rockchip SARADC driver"
+ depends on ARCH_ROCKCHIP || (ARM && COMPILE_TEST)
+ help
+ Say yes here to build support for the SARADC found in SoCs from
+ Rockchip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rockchip_saradc.
+
config TI_ADC081C
tristate "Texas Instruments ADC081C021/027"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9d60f2d..8e2932d 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c
new file mode 100644
index 0000000..1fad964
--- /dev/null
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -0,0 +1,317 @@
+/*
+ * Rockchip Successive Approximation Register (SAR) A/D Converter
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/regulator/consumer.h>
+#include <linux/iio/iio.h>
+
+#define SARADC_DATA 0x00
+#define SARADC_DATA_MASK 0x3ff
+
+#define SARADC_STAS 0x04
+#define SARADC_STAS_BUSY BIT(0)
+
+#define SARADC_CTRL 0x08
+#define SARADC_CTRL_IRQ_STATUS BIT(6)
+#define SARADC_CTRL_IRQ_ENABLE BIT(5)
+#define SARADC_CTRL_POWER_CTRL BIT(3)
+#define SARADC_CTRL_CHN_MASK 0x7
+
+#define SARADC_DLY_PU_SOC 0x0c
+#define SARADC_DLY_PU_SOC_MASK 0x3f
+
+#define SARADC_BITS 10
+#define SARADC_TIMEOUT msecs_to_jiffies(100)
+
+struct rockchip_saradc {
+ void __iomem *regs;
+ struct clk *pclk;
+ struct clk *clk;
+ struct completion completion;
+ struct regulator *vref;
+ u16 last_val;
+};
+
+static int rockchip_saradc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct rockchip_saradc *info = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ mutex_lock(&indio_dev->mlock);
+
+ reinit_completion(&info->completion);
+
+ /* 8 clock periods as delay between power up and start cmd */
+ writel_relaxed(8, info->regs + SARADC_DLY_PU_SOC);
+
+ /* Select the channel to be used and trigger conversion */
+ writel(SARADC_CTRL_POWER_CTRL
+ | (chan->channel & SARADC_CTRL_CHN_MASK)
+ | SARADC_CTRL_IRQ_ENABLE,
+ info->regs + SARADC_CTRL);
+
+ if (!wait_for_completion_timeout(&info->completion,
+ SARADC_TIMEOUT)) {
+ writel_relaxed(0, info->regs + SARADC_CTRL);
+ mutex_unlock(&indio_dev->mlock);
+ return -ETIMEDOUT;
+ }
+
+ *val = info->last_val;
+ mutex_unlock(&indio_dev->mlock);
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ ret = regulator_get_voltage(info->vref);
+ if (ret < 0) {
+ dev_err(&indio_dev->dev, "failed to get voltage\n");
+ return ret;
+ }
+
+ *val = ret / 1000;
+ *val2 = SARADC_BITS;
+ return IIO_VAL_FRACTIONAL_LOG2;
+ default:
+ return -EINVAL;
+ }
+}
+
+static irqreturn_t rockchip_saradc_isr(int irq, void *dev_id)
+{
+ struct rockchip_saradc *info = (struct rockchip_saradc *)dev_id;
+
+ /* Read value */
+ info->last_val = readl_relaxed(info->regs + SARADC_DATA);
+ info->last_val &= SARADC_DATA_MASK;
+
+ /* Clear irq & power down adc */
+ writel_relaxed(0, info->regs + SARADC_CTRL);
+
+ complete(&info->completion);
+
+ return IRQ_HANDLED;
+}
+
+static const struct iio_info rockchip_saradc_iio_info = {
+ .read_raw = rockchip_saradc_read_raw,
+ .driver_module = THIS_MODULE,
+};
+
+#define ADC_CHANNEL(_index, _id) { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _index, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = _id, \
+}
+
+static const struct iio_chan_spec rockchip_saradc_iio_channels[] = {
+ ADC_CHANNEL(0, "adc0"),
+ ADC_CHANNEL(1, "adc1"),
+ ADC_CHANNEL(2, "adc2"),
+};
+
+static int rockchip_saradc_probe(struct platform_device *pdev)
+{
+ struct rockchip_saradc *info = NULL;
+ struct device_node *np = pdev->dev.of_node;
+ struct iio_dev *indio_dev = NULL;
+ struct resource *mem;
+ int ret;
+ int irq;
+ u32 rate;
+
+ if (!np)
+ return -ENODEV;
+
+ indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
+ if (!indio_dev) {
+ dev_err(&pdev->dev, "failed allocating iio device\n");
+ return -ENOMEM;
+ }
+ info = iio_priv(indio_dev);
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ info->regs = devm_ioremap_resource(&pdev->dev, mem);
+ if (IS_ERR(info->regs))
+ return PTR_ERR(info->regs);
+
+ init_completion(&info->completion);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no irq resource?\n");
+ return irq;
+ }
+
+ ret = devm_request_irq(&pdev->dev, irq, rockchip_saradc_isr,
+ 0, dev_name(&pdev->dev), info);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed requesting irq %d\n", irq);
+ return ret;
+ }
+
+ info->pclk = devm_clk_get(&pdev->dev, "apb_pclk");
+ if (IS_ERR(info->pclk)) {
+ dev_err(&pdev->dev, "failed to get pclk\n");
+ return PTR_ERR(info->pclk);
+ }
+
+ info->clk = devm_clk_get(&pdev->dev, "saradc");
+ if (IS_ERR(info->clk)) {
+ dev_err(&pdev->dev, "failed to get adc clock\n");
+ return PTR_ERR(info->clk);
+ }
+
+ info->vref = devm_regulator_get(&pdev->dev, "vref");
+ if (IS_ERR(info->vref)) {
+ dev_err(&pdev->dev, "failed to get regulator, %ld\n",
+ PTR_ERR(info->vref));
+ return PTR_ERR(info->vref);
+ }
+
+ /*
+ * Use a default of 1MHz for the converter clock.
+ * This may become user-configurable in the future.
+ */
+ ret = clk_set_rate(info->clk, 1000000);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to set adc clk rate, %d\n", ret);
+ return ret;
+ }
+
+ ret = regulator_enable(info->vref);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to enable vref regulator\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(info->pclk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to enable pclk\n");
+ goto err_reg_voltage;
+ }
+
+ ret = clk_prepare_enable(info->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to enable converter clock\n");
+ goto err_pclk;
+ }
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ indio_dev->name = dev_name(&pdev->dev);
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->dev.of_node = pdev->dev.of_node;
+ indio_dev->info = &rockchip_saradc_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ indio_dev->channels = rockchip_saradc_iio_channels;
+ indio_dev->num_channels = ARRAY_SIZE(rockchip_saradc_iio_channels);
+
+ ret = iio_device_register(indio_dev);
+ if (ret)
+ goto err_clk;
+
+ return 0;
+
+err_clk:
+ clk_disable_unprepare(info->clk);
+err_pclk:
+ clk_disable_unprepare(info->pclk);
+err_reg_voltage:
+ regulator_disable(info->vref);
+ return ret;
+}
+
+static int rockchip_saradc_remove(struct platform_device *pdev)
+{
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct rockchip_saradc *info = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+ clk_disable_unprepare(info->clk);
+ clk_disable_unprepare(info->pclk);
+ regulator_disable(info->vref);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int rockchip_saradc_suspend(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct rockchip_saradc *info = iio_priv(indio_dev);
+
+ clk_disable_unprepare(info->clk);
+ clk_disable_unprepare(info->pclk);
+ regulator_disable(info->vref);
+
+ return 0;
+}
+
+static int rockchip_saradc_resume(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct rockchip_saradc *info = iio_priv(indio_dev);
+ int ret;
+
+ ret = regulator_enable(info->vref);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(info->pclk);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(info->clk);
+ if (ret)
+ return ret;
+
+ return ret;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(rockchip_saradc_pm_ops,
+ rockchip_saradc_suspend, rockchip_saradc_resume);
+
+static const struct of_device_id rockchip_saradc_match[] = {
+ { .compatible = "rockchip,saradc" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rockchip_saradc_match);
+
+static struct platform_driver rockchip_saradc_driver = {
+ .probe = rockchip_saradc_probe,
+ .remove = rockchip_saradc_remove,
+ .driver = {
+ .name = "rockchip-saradc",
+ .owner = THIS_MODULE,
+ .of_match_table = rockchip_saradc_match,
+ .pm = &rockchip_saradc_pm_ops,
+ },
+};
+
+module_platform_driver(rockchip_saradc_driver);
--
1.9.0
^ permalink raw reply related
* [PATCH v6 2/2] dt-bindings: document Rockchip saradc
From: Heiko Stübner @ 2014-07-23 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1984475.34C1XMW1q3@diego>
This add the necessary binding documentation for the saradc found in all recent
processors from Rockchip.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes since v5:
- remove clock-frquency property as described in patch 1/2
.../bindings/iio/adc/rockchip-saradc.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
new file mode 100644
index 0000000..5d3ec1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
@@ -0,0 +1,24 @@
+Rockchip Successive Approximation Register (SAR) A/D Converter bindings
+
+Required properties:
+- compatible: Should be "rockchip,saradc"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Shall be "saradc" for the converter-clock, and "apb_pclk" for
+ the peripheral clock.
+- vref-supply: The regulator supply ADC reference voltage.
+- #io-channel-cells: Should be 1, see ../iio-bindings.txt
+
+Example:
+ saradc: saradc at 2006c000 {
+ compatible = "rockchip,saradc";
+ reg = <0x2006c000 0x100>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
+ clock-names = "saradc", "apb_pclk";
+ #io-channel-cells = <1>;
+ vref-supply = <&vcc18>;
+ };
--
1.9.0
^ permalink raw reply related
* arm64 flushing 255GB of vmalloc space takes too long
From: Mark Salter @ 2014-07-23 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140711124553.GG11473@arm.com>
On Fri, 2014-07-11 at 13:45 +0100, Catalin Marinas wrote:
> On Fri, Jul 11, 2014 at 02:26:48AM +0100, Laura Abbott wrote:
> > On 7/9/2014 11:04 AM, Eric Miao wrote:
> > > On Wed, Jul 9, 2014 at 10:40 AM, Catalin Marinas
> > > <catalin.marinas@arm.com> wrote:
> > >> On Wed, Jul 09, 2014 at 05:53:26PM +0100, Eric Miao wrote:
> > >>> On Tue, Jul 8, 2014 at 6:43 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> > >>>> I have an arm64 target which has been observed hanging in __purge_vmap_area_lazy
> > >>>> in vmalloc.c The root cause of this 'hang' is that flush_tlb_kernel_range is
> > >>>> attempting to flush 255GB of virtual address space. This takes ~2 seconds and
> > >>>> preemption is disabled at this time thanks to the purge lock. Disabling
> > >>>> preemption for that time is long enough to trigger a watchdog we have setup.
> > >>
> > >> That's definitely not good.
> > >>
> > >>>> A couple of options I thought of:
> > >>>> 1) Increase the timeout of our watchdog to allow the flush to occur. Nobody
> > >>>> I suggested this to likes the idea as the watchdog firing generally catches
> > >>>> behavior that results in poor system performance and disabling preemption
> > >>>> for that long does seem like a problem.
> > >>>> 2) Change __purge_vmap_area_lazy to do less work under a spinlock. This would
> > >>>> certainly have a performance impact and I don't even know if it is plausible.
> > >>>> 3) Allow module unloading to trigger a vmalloc purge beforehand to help avoid
> > >>>> this case. This would still be racy if another vfree came in during the time
> > >>>> between the purge and the vfree but it might be good enough.
> > >>>> 4) Add 'if size > threshold flush entire tlb' (I haven't profiled this yet)
> > >>>
> > >>> We have the same problem. I'd agree with point 2 and point 4, point 1/3 do not
> > >>> actually fix this issue. purge_vmap_area_lazy() could be called in other
> > >>> cases.
> > >>
> > >> I would also discard point 2 as it still takes ~2 seconds, only that not
> > >> under a spinlock.
> > >
> > > Point is - we could still end up a good amount of time in that function,
> > > giving the default value of lazy_vfree_pages to be 32MB * log(ncpu),
> > > worst case of all vmap areas being only one page, tlb flush page by
> > > page, and traversal of the list, calling __free_vmap_area() that many
> > > times won't likely to reduce the execution time to microsecond level.
> > >
> > > If it's something inevitable - we do it in a bit cleaner way.
>
> In general I think it makes sense to add a mutex instead of a spinlock
> here if slowdown is caused by other things as well. That's independent
> of the TLB invalidation optimisation for arm64.
>
> > > Or we end up having platform specific tlb flush implementation just as we
> > > did for cache ops. I would expect only few platforms will have their own
> > > thresholds. A simple heuristic guess of the threshold based on number of
> > > tlb entries would be good to go?
> >
> > Mark Salter actually proposed a fix to this back in May
> >
> > https://lkml.org/lkml/2014/5/2/311
> >
> > I never saw any further comments on it though. It also matches what x86
> > does with their TLB flushing. It fixes the problem for me and the threshold
> > seems to be the best we can do unless we want to introduce options per
> > platform. It will need to be rebased to the latest tree though.
>
> There were other patches in this area and I forgot about this. The
> problem is that the ARM architecture does not define the actual
> micro-architectural implementation of the TLBs (and it shouldn't), so
> there is no way to guess how many TLB entries there are. It's not an
> easy figure to get either since there are multiple levels of caching for
> the TLBs.
>
> So we either guess some value here (we may not always be optimal) or we
> put some time bound (e.g. based on sched_clock()) on how long to loop.
> The latter is not optimal either, the only aim being to avoid
> soft-lockups.
>
Sorry for the late reply...
So, what would you like to see wrt this, Catalin? A reworked patch based
on time? IMO, something based on loop count or time seems better than
the status quo of a CPU potentially wasting 10s of seconds flushing the
tlb.
^ permalink raw reply
* [PATCH RESEND v2] bus: ARM CCN PMU driver
From: Arnd Bergmann @ 2014-07-23 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407232223.39341.arnd@arndb.de>
On Wednesday 23 July 2014 22:23:38 Arnd Bergmann wrote:
> On Tuesday 22 July 2014, Pawel Moll wrote:
> > Driver providing perf backend for ARM Cache Coherent Network
> > interconnect. Supports counting all hardware events and crosspoint
> > watchpoints.
> >
> > Currently works with CCN-504 only, although there should be
> > no changes required for CCN-508 (just impossible to test it now).
> >
> > Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>
> Applied to next/drivers, thanks!
I'm getting build errors with CONFIG_PERF_EVENTS disabled.
Is the patch below the right answer, or should we still load
the driver and #ifdef the perf-events code?
It seems to me that the driver doesn't do anything besides
perf events, but I could be missing something.
Arnd
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5c0c2764839f..603eb1be4f6a 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -53,6 +53,7 @@ config ARM_CCI
config ARM_CCN
bool "ARM CCN driver support"
depends on ARM || ARM64
+ depends on PERF_EVENTS
help
PMU (perf) driver supporting the ARM CCN (Cache Coherent Network)
interconnect.
^ 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