* [PATCH v3 05/11] clk: davinci - add dm644x clock initialization
From: Murali Karicheri @ 2012-11-05 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50951C81.5050501@ti.com>
On 11/03/2012 09:30 AM, Sekhar Nori wrote:
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> This patch adds dm644x clock initialization code that consists of
>> clocks data for various clocks and clock register callouts to
>> various clock drivers. It uses following clk drivers for this
>>
>> 1. clk-fixed-rate - for ref clock
>> 2. clk-mux - for mux at the input and output of main pll
>> 3. davinci specific clk-pll for main pll clock
>> 4. davinci specific clk-div for pll divider clock
>> 5. clk-fixed-factor for fixed factor clock such as auxclk
>> 6. davinci specific clk-psc for psc clocks
>>
>> This patch also moves all of the PLL and PSC register definitions
>> from clock.h and psc.h under davinci to the clk/davinci folder so
>> that various soc specific clock initialization code can share these
>> definitions.
> Except this patch does not move the defines, it creates a copy of them
> (which is bad since you quickly lose track of which is the correct
> copy). Is this done to avoid including mach/ header files here? It will
> actually be better to include the mach/ files here as a temporary
> solution and then remove the include mach/ files once all the SoCs have
> been converted over.
>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> drivers/clk/davinci/dm644x-clock.c | 304 ++++++++++++++++++++++++++++++++++++
>> drivers/clk/davinci/pll.h | 83 ++++++++++
>> drivers/clk/davinci/psc.h | 215 +++++++++++++++++++++++++
>> 3 files changed, 602 insertions(+)
>> create mode 100644 drivers/clk/davinci/dm644x-clock.c
>> create mode 100644 drivers/clk/davinci/pll.h
>> create mode 100644 drivers/clk/davinci/psc.h
>>
>> +/* all clocks available in DM644x SoCs */
>> +enum dm644x_clk {
>> + clkin, oscin, ref_clk_mux, pll1, pll1_plldiv_clk_mux, auxclk,
>> + clk_pll1_sysclk1, clk_pll1_sysclk2, clk_pll1_sysclk3, clk_pll1_sysclk4,
>> + clk_pll1_sysclk5, clk_pll1_sysclkbp, pll2, pll2_plldiv_clk_mux,
>> + clk_pll2_sysclk1, clk_pll2_sysclk2, clk_pll2_sysclkbp, dsp, arm, vicp,
>> + vpss_master, vpss_slave, uart0, uart1, uart2, emac, i2c, ide, asp,
>> + mmcsd, spi, gpio, usb, vlynq, aemif, pwm0, pwm1, pwm2, timer0, timer1,
>> + timer2, clk_max
>> +};
>> +
>> +static struct davinci_clk *psc_clocks[] = {
>> + &clk_dsp, &clk_arm, &clk_vicp, &clk_vpss_master, &clk_vpss_slave,
>> + &clk_uart0, &clk_uart1, &clk_uart2, &clk_emac, &clk_i2c, &clk_ide,
>> + &clk_asp0, &clk_mmcsd, &clk_spi, &clk_gpio, &clk_usb, &clk_vlynq,
>> + &clk_aemif, &clk_pwm0, &clk_pwm1, &clk_pwm2, &clk_timer0, &clk_timer1,
>> + &clk_timer2
>> +};
> You rely on perfect order between this array and dm644x_clk enum above.
> Can you initialize this array using the enum as the index so that it is
> clear. Current method is too error prone.
Are you expecting something like this?
static struct davinci_clk *psc_clocks[] = {
[dsp - dsp] = &clk_dsp,
[arm - dsp] = &clk_arm,
[vicp - dsp] = &clk_vicp,
[vpss_maste - dsp] = &clk_vpss_master,
[vpss_slave - dsp] = &clk_vpss_slave,
[uart0 - dsp] = &clk_uart0,
[uart1 - dsp] = &clk_uart1,
Murali
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 08/16] mm: use vm_unmapped_area() in hugetlbfs
From: Rik van Riel @ 2012-11-05 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-9-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the hugetlb_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 10/16] mm: use vm_unmapped_area() on mips architecture
From: Rik van Riel @ 2012-11-05 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-11-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the mips arch_get_unmapped_area[_topdown] functions to make
> use of vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 12/16] mm: use vm_unmapped_area() on sh architecture
From: Rik van Riel @ 2012-11-05 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-13-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the sh arch_get_unmapped_area[_topdown] functions to make
> use of vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 11/16] mm: use vm_unmapped_area() on arm architecture
From: Rik van Riel @ 2012-11-05 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-12-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the arm arch_get_unmapped_area[_topdown] functions to make
> use of vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 13/16] mm: use vm_unmapped_area() on sparc64 architecture
From: Rik van Riel @ 2012-11-05 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-14-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the sparc64 arch_get_unmapped_area[_topdown] functions to make
> use of vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 14/16] mm: use vm_unmapped_area() in hugetlbfs on sparc64 architecture
From: Rik van Riel @ 2012-11-05 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-15-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the sparc64 hugetlb_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 15/16] mm: use vm_unmapped_area() on sparc32 architecture
From: Rik van Riel @ 2012-11-05 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-16-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the sparc32 arch_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH 16/16] mm: use vm_unmapped_area() in hugetlbfs on tile architecture
From: Rik van Riel @ 2012-11-05 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-17-git-send-email-walken@google.com>
On 11/05/2012 05:47 PM, Michel Lespinasse wrote:
> Update the tile hugetlb_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH] ARM: OMAP4: PM: fix regulator name for VDD_MPU
From: Kevin Hilman @ 2012-11-05 23:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
commit 24d7b40a (ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for
MPU-SS) updated the regulator name used for the MPU regulator, but only
updated OMAP3, not OMAP4. Fix the OMAP4 name as well, otherwise CPUfreq
fails to find the MPU regulator.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
Applies to v3.7-rc4
arch/arm/mach-omap2/twl-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 635e109..44c4205 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -366,7 +366,7 @@ static struct regulator_init_data omap4_clk32kg_idata = {
};
static struct regulator_consumer_supply omap4_vdd1_supply[] = {
- REGULATOR_SUPPLY("vcc", "mpu.0"),
+ REGULATOR_SUPPLY("vcc", "cpu0"),
};
static struct regulator_consumer_supply omap4_vdd2_supply[] = {
--
1.8.0
^ permalink raw reply related
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Gregory CLEMENT @ 2012-11-05 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121104223215.GA28327@n2100.arm.linux.org.uk>
On 11/04/2012 11:32 PM, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 12:23:10PM +0200, Gregory CLEMENT wrote:
>> On 10/23/2012 12:00 PM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 23, 2012 at 11:43:02AM +0200, Gregory CLEMENT wrote:
>>>> On 10/23/2012 11:01 AM, Russell King - ARM Linux wrote:
>>>>> On Thu, Sep 27, 2012 at 11:35:23AM +0200, Gregory CLEMENT wrote:
>>>>>> Aurora Cache Controller was designed to be compatible with the ARM L2
>>>>>> Cache Controller. It comes with some difference or improvement such
>>>>>> as:
>>>>>> - no cache id part number available through hardware (need to get it
>>>>>> by the DT).
>>>>>> - always write through mode available.
>>>>>> - two flavors of the controller outer cache and system cache (meaning
>>>>>> maintenance operations on L1 are broadcasted to the L2 and L2
>>>>>> performs the same operation).
>>>>>> - in outer cache mode, the cache maintenance operations are improved and
>>>>>> can be done on a range inside a page and are not limited to a cache
>>>>>> line.
>>>>>
>>>>> This adds new build warnings:
>>>>>
>>>>> arch/arm/mm/cache-l2x0.c:328:13: warning: 'aurora_inv_range' defined but not used
>>>>> arch/arm/mm/cache-l2x0.c:347:13: warning: 'aurora_clean_range' defined but not used
>>>>> arch/arm/mm/cache-l2x0.c:365:13: warning: 'aurora_flush_range' defined but not used
>>>>>
>>>>> to the realview build (non-DT). Please investigate, thanks.
>>>>
>>>> OK I found the problem: aurora cache support is new so it is only
>>>> enable with device tree support. I moved all this functions in the
>>>> under OF_CONFIG (see the patch below). Do you want I submit it on the
>>>> patch system, or can you get it directly from this email?
>>>
>>> Easier by the patch system, and much less likely to get buried and lost
>>> between now and when I do the update, thanks.
>>>
>> OK, the initial patch 7547/1 was superseded by the patch 7547/2 that I have just
>> pushed in the patch system. I hope I have done it right.
>
> I know it's been a while, but it looks like it's still producing a warning.
>
> arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not used
>
> This seems to be used only by the aurora code, which is wholely contained
> within a CONFIG_OF block, and this is outside of said block...
The initial patch 7547/2 was superseded by the patch 7547/3 that I have just
pushed in the patch system. Last time first I fixed the code then I used the
versatile_defconfig configuration to test the compilation and didn't realize
that it did set CONFIG_OF by default.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
From: Gregory CLEMENT @ 2012-11-05 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105140258.GO3351@mudshark.cambridge.arm.com>
On 11/05/2012 03:02 PM, Will Deacon wrote:
> Hi Gregory,
Hi Will,
>
> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
>> new file mode 100644
>> index 0000000..69e130d
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -0,0 +1,89 @@
>> +/*
>> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Yehuda Yitschak <yehuday@marvell.com>
>> + * Gregory Clement <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
>> + * responsible for ensuring hardware coherency between all CPUs and between
>> + * CPUs and I/O masters. This file initializes the coherency fabric and
>> + * supplies basic routines for configuring and controlling hardware coherency
>> + */
>
> [...]
>
>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>> +{
>> + int reg;
>> +
>> + if (!coherency_base) {
>> + pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>> + pr_warn("Coherency fabric is not initialized\n");
>> + return 1;
>> + }
>> +
>> + /* Enable the CPU in coherency fabric */
>> + reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> + reg |= 1 << (24 + hw_cpu_id);
>> + writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +
>> + /* Add CPU to SMP group */
>> + reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> + reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>> + writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +
>> + return 0;
>> +}
>
> These writels may expand to code containing calls to outer_sync(), which
> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> coherent, how does this play out with the exclusive store instruction in the
> lock?
I forward this question to the Marvell experts.
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-11-06 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORVsuUGcydD13-VcaNjmAmrsyo9ZVHGTRoSKgLyr4-Bkw7zhg@mail.gmail.com>
Jean Pihet <jean.pihet@newoldbits.com> writes:
[...]
> I ran some intensive stress tests on the I2C and ... unfortunately I
> could not trigger the problem. It looks like the issue is caused by
> some transient situation where the CORE and/or I2C is in a low power
> state.
FYI... I just ran across what appears to be the same bug on 3430/n900
during suspend/resume testing. With CPUidle enabled, this happens every
time.
Reverting the I2C QoS patch makes it work again.
Kevin
# rtcwake -m mem -s 1
Date: Fri Dec 31 17:00:34 MST 1999
hwclock: Sat Jan 1 00:00:34 2000 0.000000 seconds
[ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready
wakeup from "mem" at Sat Jan 1 00:00:36 2000
[ 38.841949] PM: Syncing filesystems ... done.
[ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 38.916412] Suspending console(s) (use no_console_suspend to debug)
[ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 39.944305] twl: i2c_read failed to transfer all messages
[ 39.944305] twl_rtc: Could not read TWLregister D - error -110
[ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110
[ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready
[ 40.975555] twl: i2c_read failed to transfer all messages
[ 40.975555] VMMC2_IO_18: failed to disable
[ 40.978698] PM: suspend of devices complete after 2049.163 msecs
[ 40.984222] PM: late suspend of devices complete after 5.493 msecs
[ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs
[ 40.992187] Disabling non-boot CPUs ...
[ 40.992675] Successfully put all powerdomains to target state
[ 40.997009] PM: noirq resume of devices complete after 4.058 msecs
[ 41.002014] PM: early resume of devices complete after 3.601 msecs
[ 41.179016] PM: resume of devices complete after 176.818 msecs
[ 41.277740] Restarting tasks ... done.
real 0m 3.50s
user 0m 0.00s
sys 0m 0.10s
Date: Fri Dec 31 17:00:40 MST 1999
hwclock: Sat Jan 1 00:00:40 2000 0.000000 seconds
^ permalink raw reply
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Russell King - ARM Linux @ 2012-11-06 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509850C5.9080903@free-electrons.com>
On Tue, Nov 06, 2012 at 12:50:29AM +0100, Gregory CLEMENT wrote:
> The initial patch 7547/2 was superseded by the patch 7547/3 that I have just
> pushed in the patch system. Last time first I fixed the code then I used the
> versatile_defconfig configuration to test the compilation and didn't realize
> that it did set CONFIG_OF by default.
Are you sure you put the right patch in there?
diff -u <(pdb getpatch 7547/2) <(pdb getpatch 7547/3)
--- /dev/fd/63 2012-11-06 00:23:54.451978759 +0000
+++ /dev/fd/62 2012-11-06 00:23:54.452978749 +0000
@@ -1,5 +1,5 @@
===============================================================================
-Patch: 7547/2: cache-l2x0: add support for Aurora L2 cache ctrl
+Patch: 7547/3: cache-l2x0: add support for Aurora L2 cache ctrl
From: Gregory CLEMENT
Email: gregory.clement@free-electrons.com
Status: 3.7-rc1
@@ -10,6 +10,8 @@
arch/arm/mm/cache-l2x0.c | 222 +++++++++++++++++++++++++++--
3 files changed, 268 insertions(+), 13 deletions(-)
-------------------------------------------------------------------------------
+diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
+index 5f2c7b4..3b2c40b 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -102,6 +102,10 @@
@@ -443,3 +445,5 @@
if (data->save)
+
+
Looks mostly idential to me...
^ permalink raw reply
* [PATCH] pinctrl: sirf: Staticize non-exported symbol
From: Barry Song @ 2012-11-06 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352123068.14769.6.camel@phoenix>
2012/11/5 Axel Lin <axel.lin@ingics.com>:
> Staticize sirfsoc_gpio_irq_map() function.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Barry Song <Baohua.Song@csr.com>
> ---
> drivers/pinctrl/pinctrl-sirf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-sirf.c b/drivers/pinctrl/pinctrl-sirf.c
> index 9ecacf3..e3b2c53 100644
> --- a/drivers/pinctrl/pinctrl-sirf.c
> +++ b/drivers/pinctrl/pinctrl-sirf.c
> @@ -1621,8 +1621,8 @@ static void sirfsoc_gpio_set_value(struct gpio_chip *chip, unsigned offset,
> spin_unlock_irqrestore(&bank->lock, flags);
> }
>
> -int sirfsoc_gpio_irq_map(struct irq_domain *d, unsigned int irq,
> - irq_hw_number_t hwirq)
> +static int sirfsoc_gpio_irq_map(struct irq_domain *d, unsigned int irq,
> + irq_hw_number_t hwirq)
> {
> struct sirfsoc_gpio_bank *bank = d->host_data;
>
> --
> 1.7.9.5
>
-barry
^ permalink raw reply
* [PATCH v2 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-11-06 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509833A9.8080902@ti.com>
On 05.11.2012 22:46, Jon Hunter wrote:
>
> On 11/02/2012 03:23 PM, Daniel Mack wrote:
>> On 02.11.2012 20:57, Jon Hunter wrote:
>>> On 11/02/2012 02:23 PM, Daniel Mack wrote:
>>>> On 02.11.2012 20:18, Jon Hunter wrote:
>>>>> On 11/02/2012 06:14 AM, Daniel Mack wrote:
>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..6f44487
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>>>>>>> @@ -0,0 +1,73 @@
>>>>>>>> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
>>>>>>>> +
>>>>>>>> +The actual devices are instantiated from the child nodes of a GPMC node.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +
>>>>>>>> + - compatible: Should be set to "ti,gpmc"
>>>>>>>> + - reg: A resource specifier for the register space
>>>>>>>> + (see the example below)
>>>>>>>> + - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
>>>>>>>> + completed.
>>>>>>>> + - #address-cells: Must be set to 2 to allow memory address translation
>>>>>>>> + - #size-cells: Must be set to 1 to allow CS address passing
>>>>>>>> + - ranges: Must be set up to reflect the memory layout
>>>>>>>> + Note that this property is not currently parsed.
>>>>>>>> + Calculated values derived from the contents of
>>>>>>>> + GPMC_CS_CONFIG7 as set up by the bootloader. That will
>>>>>>>> + change in the future, so be sure to fill the correct
>>>>>>>> + values here.
>>>>>>>
>>>>>>> I still think it would be good to add number of chip-selects and
>>>>>>> wait-pins here.
>>>>>>
>>>>>> The number of chip-selects can be derived from the ranges property.
>>>>>> Namely, each 4-value entry to this property maps to one chip-select. I
>>>>>> can try and make the more clear in the documentation.
>>>>>
>>>>> Yes but that only tells you how many you are using. The binding should
>>>>> describe the hardware and so should tell us how many chip-selects we
>>>>> have. We should get away from using GPMC_CS_NUM in the code.
>>>>
>>>> Maybe I don't get your point, but we only need to care for as many cs
>>>> lines as we actually use, right?
>>>
>>> But how many does your device have? How many clients can you support?
>>
>> Well, you state that in the ranges property. Even if the chip could in
>> theory support 8 CS lines - if the actual setup only uses the first one
>> of them, the code would only need to allocate and set up the one that is
>> in use. And as the entries in "ranges" are mandatory, there can actually
>> be no mis-allocation.
>
> Ah, I see your point now. Well typically, we have been putting the
> device-level peripheral info in the device's *.dtsi (ie. am33xx.dtsi)
> and then board specific stuff in the board *.dts file (am335x-bone.dts).
> So I would envision that the device-level info (reg, ti,hwmods,
> interrupt, num-cs) be in am33xx.dtsi and ranges be in am335x.dts. So it
> would still be nice to catch any badly configured ranges property in the
> driver by querying in the number of chip-selects.
>
>> I can still add the maximum number as a separate property, but I wanted
>> to outline my idea here. Is "num-cs" a good name for the property?
>
> Sounds good.
>
>>> If we know how many the device has and then we can get rid of "#define
>>> GPMC_CS_NUM". We currently allocate the CS by calling gpmc_cs_request().
>>> Hmmm ... I now see that your patch is not calling this before
>>> configuring the CS and so that needs to be fixed too.
>>
>> It does implicitly, by calling gpmc_nand_init().
>
> Yes, you are right!
>
>>> Without knowing the total CS available, how do we ensure we have the CS
>>> available that someone is asking for?
>>>
>>>>> What about wait-pins?
>>>>
>>>> Afaik, their use depends on the driver acting as GPMC client, right?
>>>> Could you point me to code that acts conditionally and that should be
>>>> reflected in DT?
>>>
>>> Again we need to know how many the device has. Clients may or may not
>>> use these. However, if a client wants one they need to request one which
>>> is just like a chip-select. This is not in the current driver but Afzal
>>> has a patch for this [1].
>>
>> Ah, thanks for the pointer to the patch. Ok, I'll add a "num-waitpins"
>> property. Does that name sound appropriate?
>
> Yes, that would be great!
>
>>> Bottom line, for such hardware specific features, device tree is a good
>>> place to describe how many resources we have. Then we can eliminate such
>>> #defines from the driver code.
>>
>> Agreed.
>>
>>>> Quoting Documentation/devicetree/bindings/mtd/gpmc-nand.txt:
>>>>
>>>> For NAND specific properties such as ECC modes or bus width,
>>>> please refer to Documentation/devicetree/bindings/mtd/nand.txt
>>>
>>> Ok, thanks I see that now. Looking at other bindings, some also include
>>> these details but not all. Could be worth listing ecc-mode under
>>> mandatory and bus-width under optional with a reference to nand.txt
>>> binding. I don't think it is worth duplicating but listing the actual
>>> property names would be nice.
>>
>> Ok, I amended my local version. With the details above sorted out and
>> "num-cs" and "num-waitpins" in place, do you think we're ready for v4?
>
> Yes, thanks for doing this.
I'll integrate the details mentioned by Philip Avinash on top of yours
and then send a v4, hopefully tomorrow!
Thanks for all the feddback, much appreciated!
Daniel
^ permalink raw reply
* [GIT PULL] ARM: OMAP: PM: few more fixes for v3.7-rc
From: Kevin Hilman @ 2012-11-06 0:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
Here's a couple more trivial fixes for v3.7-rc.
Thanks,
Kevin
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/khilman/linux-omap-pm.git tags/for_3.7-rc5-fixes-pm
for you to fetch changes up to 73c503cb981394872db41dd5cde385cb5373b4b9:
ARM: OMAP4: PM: fix regulator name for VDD_MPU (2012-11-05 16:30:29 -0800)
----------------------------------------------------------------
Minor OMAP PM fixes for v3.7-rc
----------------------------------------------------------------
Kevin Hilman (2):
ARM: OMAP2+: PM: add missing newline to VC warning message
ARM: OMAP4: PM: fix regulator name for VDD_MPU
arch/arm/mach-omap2/twl-common.c | 2 +-
arch/arm/mach-omap2/vc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Gregory CLEMENT @ 2012-11-06 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106002444.GL28327@n2100.arm.linux.org.uk>
On 11/06/2012 01:24 AM, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 12:50:29AM +0100, Gregory CLEMENT wrote:
>> The initial patch 7547/2 was superseded by the patch 7547/3 that I have just
>> pushed in the patch system. Last time first I fixed the code then I used the
>> versatile_defconfig configuration to test the compilation and didn't realize
>> that it did set CONFIG_OF by default.
>
> Are you sure you put the right patch in there?
>
> diff -u <(pdb getpatch 7547/2) <(pdb getpatch 7547/3)
> --- /dev/fd/63 2012-11-06 00:23:54.451978759 +0000
> +++ /dev/fd/62 2012-11-06 00:23:54.452978749 +0000
> @@ -1,5 +1,5 @@
> ===============================================================================
> -Patch: 7547/2: cache-l2x0: add support for Aurora L2 cache ctrl
> +Patch: 7547/3: cache-l2x0: add support for Aurora L2 cache ctrl
> From: Gregory CLEMENT
> Email: gregory.clement at free-electrons.com
> Status: 3.7-rc1
> @@ -10,6 +10,8 @@
> arch/arm/mm/cache-l2x0.c | 222 +++++++++++++++++++++++++++--
> 3 files changed, 268 insertions(+), 13 deletions(-)
> -------------------------------------------------------------------------------
> +diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
> +index 5f2c7b4..3b2c40b 100644
> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
> @@ -102,6 +102,10 @@
> @@ -443,3 +445,5 @@
>
> if (data->save)
>
> +
> +
>
> Looks mostly idential to me...
>
Right, I amend the wrong commit :(
The patch 7547/4 should be the good one.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCHv7 00/21] ARM: OMAP3+: auto retention support
From: Kevin Hilman @ 2012-11-06 1:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348590833-12335-1-git-send-email-t-kristo@ti.com>
Hi Tero,
Tero Kristo <t-kristo@ti.com> writes:
> This set applies on top of linux-3.6-rc5 + func-pwrst code (from Jean) +
> omap4 core retention set (from me) + PM usecounting changes set (from me).
Since the functional pwrst and usecounting changes are still under
review, I've taken the patches from this series that are not dependent
on either of those series and queued them up here for v3.8 (branch:
for_3.8/pm/voltage.)
That includes patches the core voltage layer changes (patches 1-10 and
14-17) and the 4460 OPP data (patch 18.)
I've left out the TPS changes so I can review those closer, and also
left out the main auto-ret/auto off patch (PATCH 13/21) because of the
dependencies on the usecounting series.
With this, I tested DVFS on 3430/n900, 4430/Panda and 4460/PandaES and
voltage scaling seems to be working well.
Kevin
> Changes compared to previous version:
> - Added proper OMAP4 auto-retention support (now that the PM usecount set
> below supports OMAP4 also properly)
> - Merged TPS6236x support to this set (patches 16,18-20), without this
> there will be an issue with patch #21, as panda board will misbehave
> without TPS support and auto-ret enabled
> - Patch #15 fixes the addressing of voltage channels for OMAP4, without this
> the voltage channels either end up changing wrong voltage channel or not
> changing anything at all
> - Patch #16 is new based on the discussion earlier on the separate TPS set
> * uses proper I2C parameters based on board data, this is still in a data
> table though, as calculating these runtime would be rather complicated
> (if even possible, as it requires some higher order mathematics according
> to my understanding)
> - Patch #17 enables high speed I2C communication for voltage channel on OMAP4
> (this now works thanks to patch #16)
> - Patch #18 is needed for 4460 boards, otherwise the boot-up OPP detection
> fails and voltage control doesn't work at all on 4460 boards
> - Patch #19 was pulled from the TPS support set
> - Patch #20 was pulled from the TPS support set, with following changes:
> * board setup for the GPIOs was sanitized a bit
> * dropped a number of unused defines from the code
>
> Working branch available:
> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> branch: mainline-3.6-rc5-omap-auto-ret-v7
>
> Testing done:
> - hw used: omap3 beagle rev c4, omap4460 gp panda, omap4430 emu blaze
> - suspend + cpuidle
> - measured core + mpu voltage rails on all setups to verify that the
> voltage transitions work properly during idle
>
> -Tero
>
> --
> 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 15/16] mm: use vm_unmapped_area() on sparc32 architecture
From: David Miller @ 2012-11-06 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352155633-8648-16-git-send-email-walken@google.com>
From: Michel Lespinasse <walken@google.com>
Date: Mon, 5 Nov 2012 14:47:12 -0800
> Update the sparc32 arch_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
Hmmm...
> - if (flags & MAP_SHARED)
> - addr = COLOUR_ALIGN(addr);
> - else
> - addr = PAGE_ALIGN(addr);
What part of vm_unmapped_area() is going to duplicate this special
aligning logic we need on sparc?
^ permalink raw reply
* [PATCH 4/4] FEC: Add time stamping code and a PTP hardware clock
From: Frank Li @ 2012-11-06 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102091902.GA3437@netboy.at.omicron.at>
>> + Say Y here if you want to use PTP Hardware Clock (PHC) in the
>> + driver. Only the basic clock operations have been implemented.
>> +
>
> Does the PTP function work with every FEC on ColdFire and i.MX?
No, I just test i.MX.
>
> Or do you need to limit this option in some way?
Okay, I will do that at new patch because this patch have been accepted.
>
> You can reduce the time that the spin lock is held by moving the next
> four lines before the locked region:
>
>> + fep->cc.mult = FEC_CC_MULT;
>> + diff = fep->cc.mult;
>> + diff *= ppb;
>> + diff = div_u64(diff, 1000000000ULL);
>
Okay, I will do that at new patch and fix a bug when two boards
directly connect at 1G mode.
^ permalink raw reply
* [GIT PULL v3] Renesas ARM-based SoC boards for v3.8
From: Simon Horman @ 2012-11-06 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351730411-1874-1-git-send-email-horms@verge.net.au>
On Thu, Nov 01, 2012 at 08:40:03AM +0800, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following board enhancements for 3.8.
Ping.
> This differs from v2 of this pull request in that:
> * Several patches have been moved to the soc branch which
> I will send a pull request for shortly.
> - ARM: shmobile: r8a7779: add HSPI clock support
> - ARM: shmobile: r8a7779: add I2C clock support
> - ARM: shmobile: r8a7779: add I2C driver support
> - ARM: shmobile: r8a7740: Enable PMU
> * Several new patches have been added.
> - ARM: shmobile: Remove G4EVM machine support
> - ARM: shmobile: Remove G3EVM machine support
>
> ---------------------------------------------------------------
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git boards
>
> for you to fetch changes up to 631a7b5d958d2ef2c2333b105794c693642f0641:
>
> ARM: shmobile: Remove G4EVM machine support (2012-10-30 15:25:59 +0800)
>
> ----------------------------------------------------------------
> Kuninori Morimoto (2):
> ARM: shmobile: armadillo800eva: enable restart
> ARM: shmobile: marzen: add HSPI support
>
> Nobuhiro Iwamatsu (3):
> ARM: mach-shmobile: Use DT_MACHINE for mackerel
> ARM: shmobile: Remove G3EVM machine support
> ARM: shmobile: Remove G4EVM machine support
>
> Tetsuyuki Kobayashi (3):
> ARM: shmobile: kzm9g: enable magnetometer ak8975.
> ARM: shmobile: kzm9g: enable three-axis digital accelerometer ADXL345
> ARM: shmobile: kzm9g: enable DMAEngine on SHDI0 and SDHI2
>
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/sh7372-mackerel.dts | 22 ++
> arch/arm/configs/g3evm_defconfig | 57 ----
> arch/arm/configs/g4evm_defconfig | 57 ----
> arch/arm/configs/kzm9g_defconfig | 4 +
> arch/arm/configs/marzen_defconfig | 4 +
> arch/arm/mach-shmobile/Kconfig | 17 +-
> arch/arm/mach-shmobile/Makefile | 2 -
> arch/arm/mach-shmobile/board-armadillo800eva.c | 8 +
> arch/arm/mach-shmobile/board-g3evm.c | 343 ---------------------
> arch/arm/mach-shmobile/board-g4evm.c | 384 ------------------------
> arch/arm/mach-shmobile/board-kzm9g.c | 14 +-
> arch/arm/mach-shmobile/board-mackerel.c | 8 +-
> arch/arm/mach-shmobile/board-marzen.c | 25 ++
> 14 files changed, 87 insertions(+), 861 deletions(-)
> create mode 100644 arch/arm/boot/dts/sh7372-mackerel.dts
> delete mode 100644 arch/arm/configs/g3evm_defconfig
> delete mode 100644 arch/arm/configs/g4evm_defconfig
> delete mode 100644 arch/arm/mach-shmobile/board-g3evm.c
> delete mode 100644 arch/arm/mach-shmobile/board-g4evm.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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
* [GIT PULL v3] Renesas ARM-based SoC for v3.8
From: Simon Horman @ 2012-11-06 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351730513-2952-1-git-send-email-horms@verge.net.au>
On Thu, Nov 01, 2012 at 08:41:42AM +0800, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following SoC enhancements for 3.8.
Ping.
> ----------------------------------------------------------------
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc
>
> for you to fetch changes up to 7b9621fb8a7f3602f86773e688e4fa4dd9bbfb73:
>
> ARM: shmobile: r8a7740: Enable PMU (2012-10-30 15:31:40 +0800)
>
> ----------------------------------------------------------------
> Bastian Hecht (4):
> ARM: shmobile: emev2: Replace modify_scu_cpu_psr with scu_power_mode
> ARM: shmobile: sh73a0: Replace modify_scu_cpu_psr with scu_power_mode
> ARM: shmobile: r8a7779: Replace modify_scu_cpu_psr with scu_power_mode
> ARM: mach-shmobile: add FLCTL DMA slave definitions for sh7372
>
> Kuninori Morimoto (4):
> ARM: shmobile: r8a7740: fixup DT machine desc name typo
> ARM: shmobile: r8a7779: add HSPI clock support
> ARM: shmobile: r8a7779: add I2C clock support
> ARM: shmobile: r8a7779: add I2C driver support
>
> Nobuhiro Iwamatsu (3):
> ARM: shmobile: Remove SH7367 support
> ARM: shmobile: Remove SH7377 support
> ARM: shmobile: r8a7740: Enable PMU
>
> arch/arm/boot/dts/sh7377.dtsi | 21 -
> arch/arm/configs/armadillo800eva_defconfig | 1 +
> arch/arm/configs/marzen_defconfig | 2 +
> arch/arm/mach-shmobile/Kconfig | 12 -
> arch/arm/mach-shmobile/Makefile | 6 -
> arch/arm/mach-shmobile/clock-r8a7779.c | 16 +-
> arch/arm/mach-shmobile/clock-sh7367.c | 355 ------
> arch/arm/mach-shmobile/clock-sh7377.c | 366 ------
> arch/arm/mach-shmobile/include/mach/common.h | 18 -
> arch/arm/mach-shmobile/include/mach/sh7367.h | 332 -----
> arch/arm/mach-shmobile/include/mach/sh7372.h | 4 +
> arch/arm/mach-shmobile/include/mach/sh7377.h | 360 ------
> arch/arm/mach-shmobile/intc-sh7367.c | 413 ------
> arch/arm/mach-shmobile/intc-sh7377.c | 592 ---------
> arch/arm/mach-shmobile/pfc-sh7367.c | 1727 --------------------------
> arch/arm/mach-shmobile/pfc-sh7372.c | 1663 -------------------------
> arch/arm/mach-shmobile/pfc-sh7377.c | 1688 -------------------------
> arch/arm/mach-shmobile/setup-r8a7740.c | 18 +-
> arch/arm/mach-shmobile/setup-r8a7779.c | 77 ++
> arch/arm/mach-shmobile/setup-sh7367.c | 481 -------
> arch/arm/mach-shmobile/setup-sh7372.c | 20 +
> arch/arm/mach-shmobile/setup-sh7377.c | 549 --------
> arch/arm/mach-shmobile/smp-emev2.c | 22 +-
> arch/arm/mach-shmobile/smp-r8a7779.c | 25 +-
> arch/arm/mach-shmobile/smp-sh73a0.c | 23 +-
> 25 files changed, 143 insertions(+), 8648 deletions(-)
> delete mode 100644 arch/arm/boot/dts/sh7377.dtsi
> delete mode 100644 arch/arm/mach-shmobile/clock-sh7367.c
> delete mode 100644 arch/arm/mach-shmobile/clock-sh7377.c
> delete mode 100644 arch/arm/mach-shmobile/include/mach/sh7367.h
> delete mode 100644 arch/arm/mach-shmobile/include/mach/sh7377.h
> delete mode 100644 arch/arm/mach-shmobile/intc-sh7367.c
> delete mode 100644 arch/arm/mach-shmobile/intc-sh7377.c
> delete mode 100644 arch/arm/mach-shmobile/pfc-sh7367.c
> delete mode 100644 arch/arm/mach-shmobile/pfc-sh7372.c
> delete mode 100644 arch/arm/mach-shmobile/pfc-sh7377.c
> delete mode 100644 arch/arm/mach-shmobile/setup-sh7367.c
> delete mode 100644 arch/arm/mach-shmobile/setup-sh7377.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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
* [GIT PULL v2] Renesas ARM-based SoC defconfig for v3.8
From: Simon Horman @ 2012-11-06 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351731731-8435-1-git-send-email-horms@verge.net.au>
On Thu, Nov 01, 2012 at 09:02:08AM +0800, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following defconfig enhancements for 3.8.
Ping.
> I will work on the suggestions by Arnd to reduce the number
> of defconfigs for shmobile - in essence moving towards one or
> two generic configs rather than per-board configs. However,
> this seems to be somewhat non-trivial and in the mean time
> I would like to keep updating the existing defcoings.
>
> ----------------------------------------------------------------
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git defconfig
>
> for you to fetch changes up to 67e13cbb807c6b95706e4ec0ca2c068f14f25588:
>
> ARM: shmobile: leave CONFIG_INOTIFY_USER enabled by default (2012-11-01 08:51:34 +0800)
>
> ----------------------------------------------------------------
> Guennadi Liakhovetski (1):
> ARM: shmobile: leave CONFIG_INOTIFY_USER enabled by default
>
> Kuninori Morimoto (2):
> ARM: shmobile: mackerel: defconfig update
> ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig
>
> arch/arm/configs/ap4evb_defconfig | 1 -
> arch/arm/configs/armadillo800eva_defconfig | 2 +-
> arch/arm/configs/kota2_defconfig | 1 -
> arch/arm/configs/kzm9g_defconfig | 1 -
> arch/arm/configs/mackerel_defconfig | 19 ++++++++++++++++---
> 5 files changed, 17 insertions(+), 7 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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] clk: spear: Add stub functions for spear3[0|1|2]0_clk_init()
From: Axel Lin @ 2012-11-06 2:34 UTC (permalink / raw)
To: linux-arm-kernel
This fixes compile error if one of SPEAr3xx implementations is not selected.
CC drivers/clk/spear/spear3xx_clock.o
drivers/clk/spear/spear3xx_clock.c: In function 'spear3xx_clk_init':
drivers/clk/spear/spear3xx_clock.c:599:3: error: implicit declaration of function 'spear300_clk_init' [-Werror=implicit-function-declaration]
drivers/clk/spear/spear3xx_clock.c:601:3: error: implicit declaration of function 'spear310_clk_init' [-Werror=implicit-function-declaration]
drivers/clk/spear/spear3xx_clock.c:603:3: error: implicit declaration of function 'spear320_clk_init' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/clk/spear/spear3xx_clock.o] Error 1
make[2]: *** [drivers/clk/spear] Error 2
make[1]: *** [drivers/clk] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/clk/spear/spear3xx_clock.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/spear/spear3xx_clock.c b/drivers/clk/spear/spear3xx_clock.c
index c315745..59049cf 100644
--- a/drivers/clk/spear/spear3xx_clock.c
+++ b/drivers/clk/spear/spear3xx_clock.c
@@ -157,6 +157,8 @@ static void __init spear300_clk_init(void)
1);
clk_register_clkdev(clk, NULL, "a0000000.kbd");
}
+#else
+static inline void spear300_clk_init(void) { }
#endif
/* array of all spear 310 clock lookups */
@@ -197,6 +199,8 @@ static void __init spear310_clk_init(void)
1);
clk_register_clkdev(clk, NULL, "b2200000.serial");
}
+#else
+static inline void spear310_clk_init(void) { }
#endif
/* array of all spear 320 clock lookups */
@@ -336,6 +340,8 @@ static void __init spear320_clk_init(void)
&_lock);
clk_register_clkdev(clk, NULL, "60100000.serial");
}
+#else
+static inline void spear320_clk_init(void) { }
#endif
void __init spear3xx_clk_init(void)
--
1.7.9.5
^ 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