* [PATCH 2/2] ARM: dts: cfa10049: Add spidev to drive the DAC on SSP3
From: Maxime Ripard @ 2012-10-26 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351238873-25230-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 05c892e..d91d16c 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -29,6 +29,7 @@
0x01c1 /* MX28_PAD_GPMI_RESETN__SSP3_CMD */
0x0111 /* MX28_PAD_GPMI_CE1N__SSP3_D3 */
0x01a2 /* MX28_PAD_GPMI_ALE__SSP3_D4 */
+ 0x01b2 /* MX28_PAD_GPMI_CLE__SSP3_D5 */
>;
fsl,drive-strength = <1>;
fsl,voltage = <1>;
@@ -60,6 +61,11 @@
spi-max-frequency = <100000>;
};
+ spidev: spidev at 2 {
+ compatible = "linux,spidev";
+ reg = <2>;
+ spi-max-frequency = <100000>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 8/8] cpufreq: db8500: Use armss clk to update frequency
From: Ulf Hansson @ 2012-10-26 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-9-git-send-email-ulf.hansson@stericsson.com>
On 10 October 2012 13:42, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Using the armss clk to update the frequency makes the driver no more
> directly dependant on the prmcu API.
>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/cpufreq/db8500-cpufreq.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
> index dea9a49..4f154bc 100644
> --- a/drivers/cpufreq/db8500-cpufreq.c
> +++ b/drivers/cpufreq/db8500-cpufreq.c
> @@ -14,10 +14,11 @@
> #include <linux/delay.h>
> #include <linux/slab.h>
> #include <linux/platform_device.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/clk.h>
> #include <mach/id.h>
>
> static struct cpufreq_frequency_table *freq_table;
> +static struct clk *armss_clk;
>
> static struct freq_attr *db8500_cpufreq_attr[] = {
> &cpufreq_freq_attr_scaling_available_freqs,
> @@ -58,9 +59,9 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
> for_each_cpu(freqs.cpu, policy->cpus)
> cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
>
> - /* request the PRCM unit for opp change */
> - if (prcmu_set_arm_opp(freq_table[idx].index)) {
> - pr_err("db8500-cpufreq: Failed to set OPP level\n");
> + /* update armss clk frequency */
> + if (clk_set_rate(armss_clk, freq_table[idx].frequency * 1000)) {
> + pr_err("db8500-cpufreq: Failed to update armss clk\n");
> return -EINVAL;
> }
>
> @@ -74,16 +75,16 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
> static unsigned int db8500_cpufreq_getspeed(unsigned int cpu)
> {
> int i = 0;
> - /* request the prcm to get the current ARM opp */
> - int opp = prcmu_get_arm_opp();
> + unsigned long freq = clk_get_rate(armss_clk) / 1000;
>
> while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> - if (opp == freq_table[i].index)
> + if (freq <= freq_table[i].frequency)
> return freq_table[i].frequency;
> i++;
> }
>
> - /* We could not find a corresponding opp frequency. */
> + /* We could not find a corresponding frequency. */
> + pr_err("db8500-cpufreq: Failed to find cpufreq speed\n");
> return 0;
> }
>
> @@ -92,6 +93,12 @@ static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
> int i = 0;
> int res;
>
> + armss_clk = clk_get(NULL, "armss");
> + if (IS_ERR(armss_clk)) {
> + pr_err("db8500-cpufreq : Failed to get armss clk\n");
> + return PTR_ERR(armss_clk);
> + }
> +
> pr_info("db8500-cpufreq : Available frequencies:\n");
> while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
> @@ -104,6 +111,7 @@ static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
> cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
> else {
> pr_err("db8500-cpufreq : Failed to read policy table\n");
> + clk_put(armss_clk);
> return res;
> }
>
> --
> 1.7.10
>
Just a kind reminder on this Rafael; trying to collect acks, do you
think we can advise Mike to merge this though his clk tree?
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Ulf Hansson @ 2012-10-26 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011151947.GD15428@gmail.com>
On 11 October 2012 17:19, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 11 Oct 2012, Linus Walleij wrote:
>
>> On Thu, Oct 11, 2012 at 3:44 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> >> Patches are based on Linus Torvalds tree with latest commit as of okt 10.
>> >
>> > Hmm... I get:
>> >
>> > Applying: clk: ux500: Support for prcmu_scalable_rate clock
>> > error: drivers/clk/ux500/clk-prcmu.c: does not exist in index
>> > error: drivers/clk/ux500/clk.h: does not exist in index
>> > Patch failed at 0001 clk: ux500: Support for prcmu_scalable_rate clock
>> >
>> > So when did drivers/clk/ux500/* arrive?
>>
>> Exactly here, 10 days ago on Torvalds' master branch:
>
> Ah I see. Basing patches on commits half way through the merge
> window. Good move! ;)
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
Samuel, a kind reminder on this, trying to collect acks to be able to
advise Mike to take this series through his clk tree. There are two
mfd patches.
[PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
[PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
Kind regards
Ulf Hansson
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Hiremath, Vaibhav @ 2012-10-26 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019160041.GB4730@atomide.com>
On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > >
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> >
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> >
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1. But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> >
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
>
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.
>
Tony,
It may not be true always, as we always work simultaneously and there are
high chances that some patches/development is dependent on others from
functionality perspective (especially baseport), but still they are
independent modules (may be for other devices).
Lets take a example of AM33xx and OMAP5 here, we started submitting baseport
patches to the list (almost 6-8 months now), not all the patches gets
accepted together in one shot.
As you know, when we started pushing AM33xx and OMAP5 baseport patches, we
were at the stage where both DT and hwmod was required. First attempt for
board file submission did not went through, since we decided to force all
new devices migrate to DT, right?
So the criteria initially was, build should not break and submit patches
step-by-step.
Now, with baseport patches submitted to list, individual developer can also
start submitting patches to the respective driver's list, making sure that,
driver doesn't change irrespective of platform. I do not see anything wrong
with this, as we always consider driver independent.
In this particular case, note that, all the patches Richard posted recently
are AM33xx SoC integration specific patches only.
Thanks,
Vaibhav
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Hiremath, Vaibhav @ 2012-10-26 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024050853.GA2124@netboy.at.omicron.at>
On Wed, Oct 24, 2012 at 10:38:53, Richard Cochran wrote:
> On Tue, Oct 23, 2012 at 10:12:29AM +0000, Hiremath, Vaibhav wrote:
> >
> > I understand, and as you mentioned we are not fully there at v3.7-rc1 with
> > all the drivers/module support, due to all known reasons. Its good that with
> > v3.7-rc2, Beaglebone boots up out of box from mainline.
>
> Can you say whether we have working Ethernet on the beaglebone in v3.7?
>
No, certainly not. The DT patches are still pending to get merged and v3.7
merge window is closed now. I expect it to get merged to v3.8.
Thanks,
Vaibhav
> Thanks,
> Richard
>
^ permalink raw reply
* [RFC PATCH v3 00/16] DMA Engine support for AM33XX
From: Russ Dill @ 2012-10-26 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350566815-409-1-git-send-email-mporter@ti.com>
On Thu, Oct 18, 2012 at 6:26 AM, Matt Porter <mporter@ti.com> wrote:
> Changes since v2:
> - Rebased on 3.7-rc1
> - Fixed bug in DT/pdata parsing first found by Gururaja
> that turned out to be masked by some toolchains
> - Dropped unused mach-omap2/devices.c hsmmc patch
> - Added AM33XX crossbar DMA event mux support
> - Added am335x-evm support
>
> Changes since v1:
> - Rebased on top of mainline from 12250d8
> - Dropped the feature removal schedule patch
> - Implemented dma_request_slave_channel_compat() and
> converted the mmc and spi drivers to use it
> - Dropped unneeded #address-cells and #size-cells from
> EDMA DT support
> - Moved private EDMA header to linux/platform_data/ and
> removed some unneeded definitions
> - Fixed parsing of optional properties
>
> TODO:
> - Add dmaengine support for per-channel caps so the
> hack to set the maximum segments can be replaced with
> a query to the dmaengine driver
>
> This series adds DMA Engine support for AM33xx, which uses
> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> a private API implementation (much like the situation with OMAP
> DMA) found on the DaVinci family of SoCs.
This pretty far along and looks great.
Reviewed-by: Russ.Dill at ti.com
> The series applies on top of 3.7-rc1 and the following patches:
>
> - GPMC fails to reserve memory fix:
> http://www.spinics.net/lists/linux-omap/msg79675.html
> - TPS65910 regulator fix:
> https://patchwork.kernel.org/patch/1593651/
> - dmaengine DT support from Vinod's dmaengine_dt branch in
> git://git.infradead.org/users/vkoul/slave-dma.git since
> 027478851791df751176398be02a3b1c5f6aa824
>
> The approach taken is similar to how OMAP DMA is being converted to
> DMA Engine support. With the functional EDMA private API already
> existing in mach-davinci/dma.c, we first move that to an ARM common
> area so it can be shared. Adding DT and runtime PM support to the
> private EDMA API implementation allows it to run on AM33xx. AM33xx
> *only* boots using DT so we leverage Jon's generic DT DMA helpers to
> register EDMA DMAC with the of_dma framework and then add support
> for calling the dma_request_slave_channel() API to both the mmc
> and spi drivers.
>
> With this series both BeagleBone and the AM335x EVM have working
> MMC and SPI support.
>
> This is tested on BeagleBone with a SPI framebuffer driver and MMC
> rootfs. A trivial gpio DMA event misc driver was used to test the
> crossbar DMA event support. It is also tested on the AM335x EVM
> with the onboard SPI flash and MMC rootfs. The branch at
> https://github.com/ohporter/linux/tree/edma-dmaengine-v3 has the
> complete series, dependencies, and some test drivers/defconfigs.
>
> Regression testing was done on AM180x-EVM (which also makes use
> of the EDMA dmaengine driver and the EDMA private API) using SD,
> SPI flash, and the onboard audio supported by the ASoC Davinci
> driver.
>
> After this series, the plan is to convert the last in-tree user
> of the private EDMA API (davinci-pcm/mcasp) and then eliminate
> the private EDMA API by folding its functionality into
> drivers/dma/edma.c.
>
> Matt Porter (16):
> dmaengine: edma: fix slave config dependency on direction
> ARM: davinci: move private EDMA API to arm/common
> ARM: edma: remove unused transfer controller handlers
> ARM: edma: add DT and runtime PM support for AM33XX
> ARM: edma: add AM33XX crossbar event support
> dmaengine: edma: enable build for AM33XX
> dmaengine: edma: Add TI EDMA device tree binding
> ARM: dts: add AM33XX EDMA support
> dmaengine: add dma_request_slave_channel_compat()
> mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
> mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
> mmc: omap_hsmmc: add generic DMA request support to the DT binding
> ARM: dts: add AM33XX MMC support
> spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
> spi: omap2-mcspi: add generic DMA request support to the DT binding
> ARM: dts: add AM33XX SPI support
>
> Documentation/devicetree/bindings/dma/ti-edma.txt | 51 +
> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +-
> Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
> arch/arm/Kconfig | 1 +
> arch/arm/boot/dts/am335x-bone.dts | 23 +
> arch/arm/boot/dts/am335x-evm.dts | 15 +
> arch/arm/boot/dts/am33xx.dtsi | 101 ++
> arch/arm/common/Kconfig | 3 +
> arch/arm/common/Makefile | 1 +
> arch/arm/common/edma.c | 1841 ++++++++++++++++++++
> arch/arm/mach-davinci/Makefile | 2 +-
> arch/arm/mach-davinci/board-da830-evm.c | 4 +-
> arch/arm/mach-davinci/board-da850-evm.c | 8 +-
> arch/arm/mach-davinci/board-dm646x-evm.c | 4 +-
> arch/arm/mach-davinci/board-omapl138-hawk.c | 8 +-
> arch/arm/mach-davinci/board-tnetv107x-evm.c | 2 +-
> arch/arm/mach-davinci/davinci.h | 2 +-
> arch/arm/mach-davinci/devices-da8xx.c | 8 +-
> arch/arm/mach-davinci/devices-tnetv107x.c | 6 +-
> arch/arm/mach-davinci/devices.c | 7 +-
> arch/arm/mach-davinci/dm355.c | 6 +-
> arch/arm/mach-davinci/dm365.c | 6 +-
> arch/arm/mach-davinci/dm644x.c | 6 +-
> arch/arm/mach-davinci/dm646x.c | 6 +-
> arch/arm/mach-davinci/dma.c | 1588 -----------------
> arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
> arch/arm/mach-davinci/include/mach/edma.h | 267 ---
> arch/arm/plat-omap/Kconfig | 1 +
> drivers/dma/Kconfig | 2 +-
> drivers/dma/edma.c | 57 +-
> drivers/mmc/host/davinci_mmc.c | 1 +
> drivers/mmc/host/omap_hsmmc.c | 20 +-
> drivers/spi/spi-omap2-mcspi.c | 65 +-
> include/linux/dmaengine.h | 10 +
> include/linux/mfd/davinci_voicecodec.h | 3 +-
> include/linux/platform_data/edma.h | 199 +++
> include/linux/platform_data/spi-davinci.h | 2 +-
> sound/soc/davinci/davinci-evm.c | 1 +
> sound/soc/davinci/davinci-pcm.c | 1 +
> sound/soc/davinci/davinci-pcm.h | 2 +-
> sound/soc/davinci/davinci-sffsdr.c | 6 +-
> 41 files changed, 2436 insertions(+), 1954 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
> create mode 100644 arch/arm/common/edma.c
> delete mode 100644 arch/arm/mach-davinci/dma.c
> delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
> create mode 100644 include/linux/platform_data/edma.h
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RFT] ARM64: dma-mapping: support debug_dma_mapping_error
From: Santosh Shilimkar @ 2012-10-26 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351205220.6851.3.camel@lorien2>
On Friday 26 October 2012 04:17 AM, Shuah Khan wrote:
> Add support for debug_dma_mapping_error() call to avoid warning from
> debug_dma_unmap() interface when it checks for mapping error checked
> status. Without this patch, device driver failed to check map error
> warning is generated.
>
> Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> ---
Looks good. Similar fix for 32bit ARM port is done in below commit.
From 871ae57adc5ed092c1341f411514d0e8482e2611 Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei@canonical.com>
Date: Mon, 22 Oct 2012 20:44:03 +0800
Subject: [PATCH] ARM: dma-mapping: support debug_dma_mapping_error
Regards
Santosh
^ permalink raw reply
* [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Vinod Koul @ 2012-10-26 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokEXAGD-nUF6u8tugvF2ffJx3HLLd+Zgc2+6GB9hxnT6Q@mail.gmail.com>
On Fri, 2012-10-26 at 14:25 +0530, Viresh Kumar wrote:
> Hi Vinod,
>
> On 16 October 2012 09:49, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > dw_dmac driver already supports device tree but it used to have its platform
> > data passed the non-DT way.
> >
> > This patch does following changes:
> > - pass platform data via DT, non-DT way still takes precedence if both are used.
> > - create generic filter routine
> > - Earlier slave information was made available by slave specific filter routines
> > in chan->private field. Now, this information would be passed from within dmac
> > DT node. Slave drivers would now be required to pass bus_id (a string) as
> > parameter to this generic filter(), which would be compared against the slave
> > data passed from DT, by the generic filter routine.
> > - Update binding document
>
> I can see that you applied these patches and they are present in
> linux-next. But i feel
> the order of patches is bad.
Yes looks like I forgot to sort the mbox series :(
since all patches were applied nicely, and they seem fairly independent
of each other it should cause issue. Let me know if you wnat me to redo
my -next.
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-26 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <169edae67b9a051ca7448e5b62c3cd2c5c1db470.1350360935.git.viresh.kumar@linaro.org>
Hi Vinod,
On 16 October 2012 09:49, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> dw_dmac driver already supports device tree but it used to have its platform
> data passed the non-DT way.
>
> This patch does following changes:
> - pass platform data via DT, non-DT way still takes precedence if both are used.
> - create generic filter routine
> - Earlier slave information was made available by slave specific filter routines
> in chan->private field. Now, this information would be passed from within dmac
> DT node. Slave drivers would now be required to pass bus_id (a string) as
> parameter to this generic filter(), which would be compared against the slave
> data passed from DT, by the generic filter routine.
> - Update binding document
I can see that you applied these patches and they are present in
linux-next. But i feel
the order of patches is bad.
git log --oneline gives following:
879a0ec dmaengine: dw_dmac: Update documentation style comments for
dw_dma_platform_data
d0e35f3 dmaengine: dw_dmac: Enhance device tree support
4c4c30c ARM: SPEAr13xx: Pass DW DMAC platform data from DT
The last patch "ARM: SPEAr13xx: Pass DW DMAC platform data from DT" has
dependency on second patch.
The correct order would be:
4c4c30c ARM: SPEAr13xx: Pass DW DMAC platform data from DT
d0e35f3 dmaengine: dw_dmac: Enhance device tree support
879a0ec dmaengine: dw_dmac: Update documentation style comments for
dw_dma_platform_data
PS: We are looking at output of git log. Last patch (or first from
bottom) was applied first.
--
viresh
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Linus Walleij @ 2012-10-26 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFof65xAVyOo3FrdS2uYQwB1Wq3553PKj04FR6JXaJsH6Q@mail.gmail.com>
On Fri, Oct 26, 2012 at 10:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Samuel, a kind reminder on this, trying to collect acks to be able to
> advise Mike to take this series through his clk tree. There are two
> mfd patches.
> [PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
> [PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
Two weeks of slack for review is good enough, involved
subsystem maintainers have been Cc:ed.
Mike T, can you just apply the patches please.
Yours,
Linus Walleij
^ permalink raw reply
* Build broken on linus/master?
From: Santosh Shilimkar @ 2012-10-26 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBE9565@DBDE01.ent.ti.com>
On Friday 26 October 2012 01:18 PM, Bedia, Vaibhav wrote:
> Hi,
>
> Compiling the current linus/master (2ab3f29) using omap2plus_defconfig
> throws up the following error
>
> $make -j7 uImage
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
> CC arch/arm/kernel/asm-offsets.s
> In file included from include/linux/dma-mapping.h:76:0,
> from arch/arm/kernel/asm-offsets.c:15:
> /datalocal/kernel/arch/arm/include/asm/dma-mapping.h: In function 'dma_mapping_error':
> /datalocal/kernel/arch/arm/include/asm/dma-mapping.h:94:2: error: implicit declaration of function 'debug_dma_mapping_error'
> make[1]: *** [arch/arm/kernel/asm-offsets.s] Error 1
> make: *** [prepare0] Error 2
>
Looks like it might break build on all ARM machines. I just
noticed a patch adding debug_dma_mapping_error() for aarm64 arch.
Marek, Shuah,
Is kernel missing a patch which adds definition of
debug_dma_mapping_error() to linux/dma-debug.h ?
I can't seems to find this symbol in kernel grep.
Regards
Santosh
^ permalink raw reply
* [PATCH 2/2] ARM: mach-imx: CAN clock fix for i.MX53
From: Sascha Hauer @ 2012-10-26 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351164400-27940-2-git-send-email-stigge@antcom.de>
On Thu, Oct 25, 2012 at 01:26:40PM +0200, Roland Stigge wrote:
> This patch fixes CAN clocking on i.MX53.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
>
> ---
> arch/arm/mach-imx/clk-imx51-imx53.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> --- linux-2.6.orig/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ linux-2.6/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -426,10 +426,10 @@ int __init mx53_clocks_init(unsigned lon
> clk[usb_phy2_gate] = imx_clk_gate2("usb_phy2_gate", "usb_phy_sel", MXC_CCM_CCGR4, 12);
> clk[can_sel] = imx_clk_mux("can_sel", MXC_CCM_CSCMR2, 6, 2,
> mx53_can_sel, ARRAY_SIZE(mx53_can_sel));
> - clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR6, 22);
> - clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR6, 20);
> - clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 8);
> - clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 6);
I just rechecked. The above matches the i.MX53 Reference Manual rev 2.1
> + clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR4, 6);
> + clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
> + clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 6);
> + clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
This doesn't.
Can you elaborate why you think this is necessary?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-26 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351241315.7077.16.camel@vkoul-udesk3>
On 26 October 2012 14:18, Vinod Koul <vkoul@infradead.org> wrote:
> On Fri, 2012-10-26 at 14:25 +0530, Viresh Kumar wrote:
>> I can see that you applied these patches and they are present in
>> linux-next. But i feel
>> the order of patches is bad.
> Yes looks like I forgot to sort the mbox series :(
>
> since all patches were applied nicely, and they seem fairly independent
> of each other it should cause issue. Let me know if you wnat me to redo
> my -next.
yes. The ARCH specific patch 3/3 uses a routine created in 2/3. So they have
to be in right order for git bisect to work.
--
viresh
^ permalink raw reply
* [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Vinod Koul @ 2012-10-26 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=4QDBuFZJrdCkXzijx4aD0rNXf1X2wS9LG17zg_LeAYg@mail.gmail.com>
On Fri, 2012-10-26 at 14:35 +0530, Viresh Kumar wrote:
> >> I can see that you applied these patches and they are present in
> >> linux-next. But i feel
> >> the order of patches is bad.
> > Yes looks like I forgot to sort the mbox series :(
> >
> > since all patches were applied nicely, and they seem fairly independent
> > of each other it should cause issue. Let me know if you wnat me to redo
> > my -next.
>
> yes. The ARCH specific patch 3/3 uses a routine created in 2/3. So they have
> to be in right order for git bisect to work.
Done, it should reflect now.
Sorry for the mess.
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH 2/2] ARM: mach-imx: CAN clock fix for i.MX53
From: Roland Stigge @ 2012-10-26 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026085934.GA1641@pengutronix.de>
Hi!
On 10/26/2012 10:59 AM, Sascha Hauer wrote:
> On Thu, Oct 25, 2012 at 01:26:40PM +0200, Roland Stigge wrote:
>> This patch fixes CAN clocking on i.MX53.
>>
>> Signed-off-by: Roland Stigge <stigge@antcom.de>
>>
>> ---
>> arch/arm/mach-imx/clk-imx51-imx53.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> --- linux-2.6.orig/arch/arm/mach-imx/clk-imx51-imx53.c
>> +++ linux-2.6/arch/arm/mach-imx/clk-imx51-imx53.c
>> @@ -426,10 +426,10 @@ int __init mx53_clocks_init(unsigned lon
>> clk[usb_phy2_gate] = imx_clk_gate2("usb_phy2_gate", "usb_phy_sel", MXC_CCM_CCGR4, 12);
>> clk[can_sel] = imx_clk_mux("can_sel", MXC_CCM_CSCMR2, 6, 2,
>> mx53_can_sel, ARRAY_SIZE(mx53_can_sel));
>> - clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR6, 22);
>> - clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR6, 20);
>> - clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 8);
>> - clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 6);
>
> I just rechecked. The above matches the i.MX53 Reference Manual rev 2.1
>
>> + clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR4, 6);
>> + clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>> + clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 6);
>> + clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>
> This doesn't.
This may be right, but unfortunately, since the introduction of your
can1 + can2 clocking change, the first block stopped working for me.
My above patch is basically a rollback which works for the first block.
An interesting hint is: can2 (which was the only one defined _before_
your can1 + can2 change) didn't work before and afterwards at all. (But
I'm not using it anyway.)
Thanks,
Roland
^ permalink raw reply
* [GIT PULL] ux500 fixes due for v3.7 RCs
From: Arnd Bergmann @ 2012-10-26 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025154832.GJ4008@gmail.com>
On Thursday 25 October 2012, Lee Jones wrote:
> On Thu, 25 Oct 2012, Linus Walleij wrote:
>
> > On Thu, Oct 25, 2012 at 3:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > Since we're now getting pull requests from both of you, Lee and Linus,
> > > I'd like to understand how you are organized.
> > >
> > > Lee, are you just sending bug fixes directly and send future work through
> > > Linus, or are you acting as backup maintainer when he is busy otherwise
> > > in general?
> >
> > Let us say that Lee is pushing stuff that is DT-related, e.g. fixes that
> > only manifest in DT environments and I'm pushing most other stuff.
> >
> > I'm happy that Lee is doing some nice offloading as pinctrl and gpio is
> > currently quite busy.
> >
> > One day Srinidhi may also send pull requests, as co-maintainer.
>
> Right. As I was creating quite a lot of traffic, I've basically been
> asked to push all my own stuff after I've acquired the right Acks.
> I won't be pushing/acking anything else i.e. not acting as a co-
> maintainer.
>
> Hope that clears things up.
Ok, thanks for the explanations,
Arnd
^ permalink raw reply
* [GIT PULL] Samsung fixes-2 for v3.7
From: Kukjin Kim @ 2012-10-26 9:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
Here is Samsung fixes, 3 patches for v3.7.
One is spi stuff for fix the device names for the different subtypes of the
spi controller. And the other is adding missing .smp field for exynos4-dt
and fixing memory sections for exynos4210-trats board.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.7-samsung-fixes-2
If any problems, please kindly let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.7-samsung-fixes-2
Heiko Stuebner (1):
ARM: SAMSUNG: Add naming of s3c64xx-spi devices
Tomasz Figa (2):
ARM: dts: Split memory into 4 sections for exynos4210-trats
ARM: EXYNOS: Set .smp field of machine descriptor for exynos4-dt
arch/arm/boot/dts/exynos4210-trats.dts | 6 +++-
arch/arm/mach-exynos/common.c | 5 ++++
arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
arch/arm/mach-s3c24xx/s3c2416.c | 2 +
arch/arm/mach-s3c24xx/s3c2443.c | 4 +++
arch/arm/mach-s5p64x0/common.c | 3 ++
arch/arm/mach-s5pc100/common.c | 3 ++
arch/arm/mach-s5pv210/common.c | 3 ++
arch/arm/plat-samsung/include/plat/spi-core.h | 30
+++++++++++++++++++++++++
9 files changed, 55 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-samsung/include/plat/spi-core.h
^ permalink raw reply
* [PATCH v2 0/2] ARM: exynos: Enable TMU support in exynos platforms
From: Amit Daniel Kachhap @ 2012-10-26 9:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Amit Daniel Kachhap <amit.daniel@samsung.com>
These TMU enablement patches are needed for exynos4 and exynos5 TMU
driver already merged(drivers/thermal/exynos_thermal.c).
This patchset is based on Samsung Maintainer's tree,
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
Amit Daniel Kachhap (2):
ARM: exynos4: Add devicetree node for TMU driver
ARM: exynos5: Add devicetree node for TMU driver
arch/arm/boot/dts/exynos4210.dtsi | 7 +++++++
arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
arch/arm/mach-exynos/clock-exynos4.c | 4 ++++
arch/arm/mach-exynos/clock-exynos5.c | 5 +++++
arch/arm/mach-exynos/include/mach/irqs.h | 3 +++
arch/arm/mach-exynos/include/mach/map.h | 3 +++
arch/arm/mach-exynos/mach-exynos4-dt.c | 2 ++
arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++
8 files changed, 32 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] ARM: exynos4: Add devicetree node for TMU driver
From: Amit Daniel Kachhap @ 2012-10-26 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351243746-4173-1-git-send-email-amit.daniel@samsung.com>
From: Amit Daniel Kachhap <amit.daniel@samsung.com>
This patch adds necessary source definations needed for TMU driver and
adds devicetree node for exynos4210.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
---
arch/arm/boot/dts/exynos4210.dtsi | 7 +++++++
arch/arm/mach-exynos/clock-exynos4.c | 4 ++++
arch/arm/mach-exynos/include/mach/irqs.h | 3 +++
arch/arm/mach-exynos/include/mach/map.h | 2 ++
arch/arm/mach-exynos/mach-exynos4-dt.c | 2 ++
5 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 214c557..038de97 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -303,4 +303,11 @@
#gpio-cells = <4>;
};
};
+
+ tmu at 100C0000 {
+ compatible = "samsung,exynos4210-tmu";
+ interrupt-parent = <&combiner>;
+ reg = <0x100C0000 0x100>;
+ interrupts = <2 4>;
+ };
};
diff --git a/arch/arm/mach-exynos/clock-exynos4.c b/arch/arm/mach-exynos/clock-exynos4.c
index fa8a134..cf121f4 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -576,6 +576,10 @@ static struct clk exynos4_init_clocks_off[] = {
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit = (1 << 15),
}, {
+ .name = "tmu_apbif",
+ .enable = exynos4_clk_ip_perir_ctrl,
+ .ctrlbit = (1 << 17),
+ }, {
.name = "keypad",
.enable = exynos4_clk_ip_perir_ctrl,
.ctrlbit = (1 << 16),
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h
index 35bced6..5adacd1 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -136,6 +136,9 @@
#define EXYNOS4_IRQ_TSI IRQ_SPI(115)
#define EXYNOS4_IRQ_SATA IRQ_SPI(116)
+#define EXYNOS4_IRQ_TMU_TRIG0 COMBINER_IRQ(2, 4)
+#define EXYNOS4_IRQ_TMU_TRIG1 COMBINER_IRQ(3, 4)
+
#define EXYNOS4_IRQ_SYSMMU_MDMA0_0 COMBINER_IRQ(4, 0)
#define EXYNOS4_IRQ_SYSMMU_SSS_0 COMBINER_IRQ(4, 1)
#define EXYNOS4_IRQ_SYSMMU_FIMC0_0 COMBINER_IRQ(4, 2)
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 8480849..772acd3 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -88,6 +88,8 @@
#define EXYNOS4_PA_TWD 0x10500600
#define EXYNOS4_PA_L2CC 0x10502000
+#define EXYNOS4_PA_TMU 0x100C0000
+
#define EXYNOS4_PA_MDMA0 0x10810000
#define EXYNOS4_PA_MDMA1 0x12850000
#define EXYNOS4_PA_PDMA0 0x12680000
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
index eadf4b5..0746e5a 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -77,6 +77,8 @@ static const struct of_dev_auxdata exynos4_auxdata_lookup[] __initconst = {
"exynos4210-spi.2", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA0, "dma-pl330.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-tmu", EXYNOS4_PA_TMU,
+ "exynos-tmu", NULL),
{},
};
--
1.7.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: exynos5: Add devicetree node for TMU driver
From: Amit Daniel Kachhap @ 2012-10-26 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351243746-4173-2-git-send-email-amit.daniel@samsung.com>
From: Amit Daniel Kachhap <amit.daniel@samsung.com>
This patch adds necessary source definations needed for TMU driver and
adds devicetree node for exynos5250.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
arch/arm/mach-exynos/clock-exynos5.c | 5 +++++
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 49546bc..670dfdb 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -74,6 +74,12 @@
interrupts = <0 43 0>, <0 44 0>;
};
+ tmu at 10060000 {
+ compatible = "samsung,exynos5250-tmu";
+ reg = <0x10060000 0x100>;
+ interrupts = <0 65 0>;
+ };
+
serial at 12C00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-exynos/clock-exynos5.c
index 2ca9391..d4ae64e 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -616,6 +616,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_peric_ctrl,
.ctrlbit = (1 << 24),
}, {
+ .name = "tmu_apbif",
+ .parent = &exynos5_clk_aclk_66.clk,
+ .enable = exynos5_clk_ip_peris_ctrl,
+ .ctrlbit = (1 << 21),
+ }, {
.name = "rtc",
.parent = &exynos5_clk_aclk_66.clk,
.enable = exynos5_clk_ip_peris_ctrl,
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 772acd3..2a28ef9 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -89,6 +89,7 @@
#define EXYNOS4_PA_L2CC 0x10502000
#define EXYNOS4_PA_TMU 0x100C0000
+#define EXYNOS5_PA_TMU 0x10060000
#define EXYNOS4_PA_MDMA0 0x10810000
#define EXYNOS4_PA_MDMA1 0x12850000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index b7f1154..f8d5a9b 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -76,6 +76,8 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA("samsung,exynos5-gsc", EXYNOS5_PA_GSC3,
"exynos-gsc.3", NULL),
OF_DEV_AUXDATA("samsung,mfc-v6", 0x11000000, "s5p-mfc-v6", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-tmu", EXYNOS5_PA_TMU,
+ "exynos-tmu", NULL),
{},
};
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] ARM: SMP_TWD: use clk_prepare_enable()
From: Ulf Hansson @ 2012-10-26 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350640038-26358-1-git-send-email-linus.walleij@linaro.org>
On 19 October 2012 11:47, Linus Walleij <linus.walleij@linaro.org> wrote:
> A minor code refactoring saving a few lines by merging prepare()
> and enable() calls.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/kernel/smp_twd.c | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index b22d700..b92d524 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -248,17 +248,9 @@ static struct clk *twd_get_clock(void)
> return clk;
> }
>
> - err = clk_prepare(clk);
> + err = clk_prepare_enable(clk);
> if (err) {
> - pr_err("smp_twd: clock failed to prepare: %d\n", err);
> - clk_put(clk);
> - return ERR_PTR(err);
> - }
> -
> - err = clk_enable(clk);
> - if (err) {
> - pr_err("smp_twd: clock failed to enable: %d\n", err);
> - clk_unprepare(clk);
> + pr_err("smp_twd: clock failed to prepare+enable: %d\n", err);
> clk_put(clk);
> return ERR_PTR(err);
> }
> --
> 1.7.11.7
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Looks nice!
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
^ permalink raw reply
* [PATCH v2] arch/arm/mach-davinci/board-dm646x-evm.c: Remove unecessary semicolon
From: Sekhar Nori @ 2012-10-26 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347987599-30802-1-git-send-email-peter.senna@gmail.com>
On 9/18/2012 10:29 PM, Peter Senna Tschudin wrote:
> Found by http://coccinelle.lip6.fr/
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Queuing this for v3.8
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Laurent Pinchart @ 2012-10-26 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbaCM+MWiHARvdfaGL6w0c7g4_keAm0ADw1vkSeiZ0CZPw@mail.gmail.com>
Hi Ohad,
On Friday 26 October 2012 07:50:56 Ohad Ben-Cohen wrote:
> On Thu, Oct 25, 2012 at 11:39 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Joerg and Ohad, do you have any opinions on this?
>
> I agree that there's some merit in having a separate header file for
> IOVMM, since it's a different layer from the IOMMU API.
>
> But in reality it's tightly coupled with OMAP's IOMMU, and ideally it
> really should go away and be replaced with the DMA API.
>
> For this reason, and for the fact that anyway there's only a single
> user for it (omap3isp) and there will never be any more, maybe we
> shouldn't pollute include/linux anymore.
>
> Anyone volunteering to remove IOVMM and adapt omap3isp to the DMA API
> instead ? ;)
That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2,
adding DT support, moving to the common clock framework (when that will be
available for the OMAP3), supporting missing V4L2 features, ... All this in my
spare time of course, otherwise it wouldn't be fun, would it ? ;-)
I would also like to move the tidspbridge to the DMA API, but I think we'll
need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an
intermediate step would allow splitting patches in reviewable chunks. I know
it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a
temporary nuisance to make the leap easier.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL] Urgent DMA-mapping fix for v3.7-rc3
From: Marek Szyprowski @ 2012-10-26 9:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
I would like to ask for pulling an urgent fix for ARM DMA-mapping
framework for v3.7-rc3. Due to my mistake, my previous pull request
(merged as cff7b8ba60e332377568c3d55c8036e9b1de32e6) contained a patch
which is aimed for v3.8 and lacks its dependences. This pull request
reverts it and fixes build break of ARM architecture.
Thanks!
Best regards
Marek Szyprowski
Samsung Poland R&D Center
----------------------------------------------------------------
The following changes since commit 2ab3f29dddfb444c9fcc0a2f3a56ed4bdba41969:
Merge branch 'akpm' (Andrew's fixes) (2012-10-25 16:05:57 -0700)
are available in the git repository at:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes_for_linus
for you to fetch changes up to 697575896670ba9e76760ce8bbc1f5a3001967d6:
Revert "ARM: dma-mapping: support debug_dma_mapping_error" (2012-10-26 07:39:13 +0200)
----------------------------------------------------------------
Marek Szyprowski (1):
Revert "ARM: dma-mapping: support debug_dma_mapping_error"
arch/arm/include/asm/dma-mapping.h | 1 -
1 file changed, 1 deletion(-)
^ permalink raw reply
* [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur
From: Viresh Kumar @ 2012-10-26 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Avoid calling cpufreq driver's target() routine if new frequency is same as
policies current frequency.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/cpufreq.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 261ef65..28dc134 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1476,6 +1476,10 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
target_freq, relation);
+
+ if (target_freq == policy->cur)
+ return 0;
+
if (cpu_online(policy->cpu) && cpufreq_driver->target)
retval = cpufreq_driver->target(policy, target_freq, relation);
--
1.7.12.rc2.18.g61b472e
^ 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