* [PATCH v3 01/13] ARM: mvebu: rename armada-370-xp.c to armada-mvebu.c
From: Jason Cooper @ 2014-02-13 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213125526.3af08c54@skate>
On Thu, Feb 13, 2014 at 12:55:26PM +0100, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
>
> On Thu, 13 Feb 2014 12:50:15 +0100, Arnd Bergmann wrote:
> > On Thursday 13 February 2014 12:04:23 Thomas Petazzoni wrote:
> > > In preparation to the introduction of the support of Armada 375 and
> > > Armada 38x, this commit renames arch/arm/mach-mvebu/armada-370-xp.c to
> > > arch/arm/mach-mvebu/armada-mvebu.c. The armada-mvebu.c name was chosen
> > > because:
> > >
> > > * As we are going to merge the support for Kirkwood and Dove into
> > > mach-mvebu, there will be other files with DT_MACHINE_START
> > > structures, so a generic name such as board-dt.c or mvebu.c does
> > > not work.
> > >
> > > * A simple armada.c does not work, because there are Marvell Armada
> > > SOCs that are not part of the MVEBU family. For example, the
> > > Marvell Armada 1500 are part of the mach-berlin family, which is a
> > > completely separate line of SOCs.
> >
> > Your reasoning for the new name makes a lot of sense, but my personal
> > opinion is that I'd rather leave the name as it is and deal with the
> > fact that it's not the best name. Renaming files often causes unexpected
> > problems, in particular if someone else wants to modify the same file.
>
> I believe it's a matter of taste here. Having a file named
> armada-370-xp.c that handles Armada 375 and Armada 38x looks highly
> confusing to me, and I believe both Gr?gory and Ezequiel were of the
> same opinion.
>
> The number of changes to this file is very limited, so the probability
> of having a large number of complicated patches touching the same file
> being in flight is fairly low.
>
> Maybe we can leave this taste decision to the mach-mvebu maintainers?
board-v7.c and then board-v5.c ?
thx,
Jason.
^ permalink raw reply
* [PATCH 0/8] OMAP: OMAP3 DSS related clock patches
From: Belisko Marek @ 2014-02-13 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392285846-13199-1-git-send-email-tomi.valkeinen@ti.com>
On Thu, Feb 13, 2014 at 11:03 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have
> them all fixed with this series. This fixes the problems for both non-DT boot,
> but also for DT boot with DSS DT support (which is not merged yet).
>
> The non-DT boot related fixes should be merged for 3.14, but I'd like the DT
> boot related fixes to be merged for 3.14 also, as that'll make handling the DSS
> DT support easier.
>
> This is based on v3.14-rc2.
Tested on gta04 board with DSS DT patches v3 (rebased on 3.14-rc2).
Panel is finally working fine.
Thanks.
Tested-by: Marek Belisko <marek@goldelico.com>
>
> Tomi
>
> Tomi Valkeinen (8):
> clk: divider: fix rate calculation for fractional rates
> clk: ti/divider: fix rate calculation for fractional rates
> ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
> ARM: dts: fix omap3 dss clock handle names
> ARM: dts: fix DPLL4 x2 clkouts on 3630
> ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
> ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
> OMAPDSS: fix rounding when calculating fclk rate
>
> arch/arm/boot/dts/omap3430es1-clocks.dtsi | 6 +--
> .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi | 6 +--
> arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 +++++++
> arch/arm/boot/dts/omap36xx.dtsi | 2 +-
> arch/arm/boot/dts/omap3xxx-clocks.dtsi | 8 +--
> arch/arm/mach-omap2/cclock3xxx_data.c | 2 +
> arch/arm/mach-omap2/dpll3xxx.c | 62 ++++++++++++++++++++++
> drivers/clk/clk-divider.c | 10 ++--
> drivers/clk/ti/divider.c | 8 +--
> drivers/video/omap2/dss/dss.c | 4 +-
> include/linux/clk/ti.h | 4 ++
> 11 files changed, 111 insertions(+), 21 deletions(-)
>
> --
> 1.8.3.2
>
> --
> 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
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* [PATCH 06/12] mfd: vexpress-sysreg: Add labels to gpio banks
From: Linus Walleij @ 2014-02-13 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392138636-29240-7-git-send-email-pawel.moll@arm.com>
On Tue, Feb 11, 2014 at 6:10 PM, Pawel Moll <pawel.moll@arm.com> wrote:
> ... so debugfs interfaces are easier to use.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
This doesn't apply to the v3.14-rc1-based GPIO tree. Can you rebase it
with Lee's ACK so I can apply this?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/9] ARM: select MIGHT_HAVE_CACHE_L2X0 for V7 multi-platform
From: Rob Herring @ 2014-02-13 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FBDA63.6030303@wwwdotorg.org>
On Wed, Feb 12, 2014 at 2:32 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/11/2014 02:11 PM, Rob Herring wrote:
>> Many V7 platforms have an L2x0 cache, so make CONFIG_MIGHT_HAVE_CACHE_L2X0
>> visible for V7 multi-platform builds.
>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>
>> config ARCH_MULTI_V6_V7
>> bool
>> + select MIGHT_HAVE_CACHE_L2X0
>
> The commit description says "V7", whereas the select got added to
> "V6_V7" rather then "V7". Was that intentional?
I'll fix the commit text. Given that most ARM11 platforms have an
L2x0, we should enable for both.
Rob
^ permalink raw reply
* [PATCH 06/12] mfd: vexpress-sysreg: Add labels to gpio banks
From: Pawel Moll @ 2014-02-13 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZjrCdhyBMF2WbDCnHuuMSpcpwiPx2k555PY3yBwdc1aw@mail.gmail.com>
On Thu, 2014-02-13 at 13:08 +0000, Linus Walleij wrote:
> On Tue, Feb 11, 2014 at 6:10 PM, Pawel Moll <pawel.moll@arm.com> wrote:
>
> > ... so debugfs interfaces are easier to use.
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Alexandre Courbot <gnurou@gmail.com>
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>
> This doesn't apply to the v3.14-rc1-based GPIO tree. Can you rebase it
> with Lee's ACK so I can apply this?
Uh, it won't apply. This series depends on the one reworking sysregs.
I'll send them separately once it's ready. Sorry about confusion and
thanks for trying!
Pawel
^ permalink raw reply
* [PATCH v3 01/13] ARM: mvebu: rename armada-370-xp.c to armada-mvebu.c
From: Thomas Petazzoni @ 2014-02-13 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213130745.GU27395@titan.lakedaemon.net>
Dear Jason Cooper,
On Thu, 13 Feb 2014 08:07:45 -0500, Jason Cooper wrote:
> > > Your reasoning for the new name makes a lot of sense, but my personal
> > > opinion is that I'd rather leave the name as it is and deal with the
> > > fact that it's not the best name. Renaming files often causes unexpected
> > > problems, in particular if someone else wants to modify the same file.
> >
> > I believe it's a matter of taste here. Having a file named
> > armada-370-xp.c that handles Armada 375 and Armada 38x looks highly
> > confusing to me, and I believe both Gr?gory and Ezequiel were of the
> > same opinion.
> >
> > The number of changes to this file is very limited, so the probability
> > of having a large number of complicated patches touching the same file
> > being in flight is fairly low.
> >
> > Maybe we can leave this taste decision to the mach-mvebu maintainers?
>
> board-v7.c and then board-v5.c ?
Why not. But since this kind of change can be done without breaking the
DT compatibility, I'd first prefer to see Dove support merged into
mach-mvebu/ with its board file named mach-mvebu/dove.c. Then
progressively see what can be combined with armada-mvebu.c so that we
can merge both of them into board-v7.c.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 01/13] ARM: mvebu: rename armada-370-xp.c to armada-mvebu.c
From: Sebastian Hesselbarth @ 2014-02-13 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213141355.00e8f2fd@skate>
On 02/13/14 14:13, Thomas Petazzoni wrote:
> On Thu, 13 Feb 2014 08:07:45 -0500, Jason Cooper wrote:
>>>> Your reasoning for the new name makes a lot of sense, but my personal
>>>> opinion is that I'd rather leave the name as it is and deal with the
>>>> fact that it's not the best name. Renaming files often causes unexpected
>>>> problems, in particular if someone else wants to modify the same file.
>>>
>>> I believe it's a matter of taste here. Having a file named
>>> armada-370-xp.c that handles Armada 375 and Armada 38x looks highly
>>> confusing to me, and I believe both Gr?gory and Ezequiel were of the
>>> same opinion.
>>>
>>> The number of changes to this file is very limited, so the probability
>>> of having a large number of complicated patches touching the same file
>>> being in flight is fairly low.
>>>
>>> Maybe we can leave this taste decision to the mach-mvebu maintainers?
>>
>> board-v7.c and then board-v5.c ?
>
> Why not. But since this kind of change can be done without breaking the
> DT compatibility, I'd first prefer to see Dove support merged into
> mach-mvebu/ with its board file named mach-mvebu/dove.c. Then
> progressively see what can be combined with armada-mvebu.c so that we
> can merge both of them into board-v7.c.
Actually, just prepared those patches today. Haven't boot tested but
compiles cleanly. The patch set will be really small compared to KW
patch set (but de-hardcoded pinctrl-dove will be a prerequisite).
I also prefer to move to mach-mvebu/dove.c and then merge with
armada-3{78}{05x} a cycle later.
Sebastian
^ permalink raw reply
* [PATCH 02/18] arm64: GICv3 device tree binding documentation
From: Rob Herring @ 2014-02-13 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391607050-540-3-git-send-email-marc.zyngier@arm.com>
On Wed, Feb 5, 2014 at 7:30 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Add the necessary documentation to support GICv3.
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Documentation/devicetree/bindings/arm/gic-v3.txt | 81 ++++++++++++++++++++++++
> 1 file changed, 81 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/gic-v3.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/gic-v3.txt b/Documentation/devicetree/bindings/arm/gic-v3.txt
> new file mode 100644
> index 0000000..93852f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic-v3.txt
> @@ -0,0 +1,81 @@
> +* ARM Generic Interrupt Controller, version 3
> +
> +AArch64 SMP cores are often associated with a GICv3, providing private
> +peripheral interrupts (PPI), shared peripheral interrupts (SPI),
> +software generated interrupts (SGI), and locality-specific peripheral
> +Interrupts (LPI).
> +
> +Main node required properties:
> +
> +- compatible : should at least contain "arm,gic-v3".
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. Must be a single cell with a value of at least 3.
> +
> + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> + interrupts. Other values are reserved for future use.
> +
> + The 2nd cell contains the interrupt number for the interrupt type.
> + SPI interrupts are in the range [0-987]. PPI interrupts are in the
> + range [0-15].
> +
> + The 3rd cell is the flags, encoded as follows:
> + bits[3:0] trigger type and level flags.
> + 1 = edge triggered
> + 2 = edge triggered (deprecated, for compatibility with GICv2)
> + 4 = level triggered
> + 8 = level triggered (deprecated, for compatibility with GICv2)
I don't really think compatibility is needed here. I'd just list 1 and 4.
> +
> + Cells 4 and beyond are reserved for future use. Where the 1st cell
> + has a value of 0 or 1, cells 4 and beyond act as padding, and may be
> + ignored. It is recommended that padding cells have a value of 0.
What future use? LPIs I suppose.
Otherwise, looks fine to me:
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH 02/18] arm64: GICv3 device tree binding documentation
From: Rob Herring @ 2014-02-13 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FCC1C2.1020203@arm.com>
On Thu, Feb 13, 2014 at 6:59 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Arnab,
>
> On 07/02/14 05:41, Arnab Basu wrote:
>> Hi Marc
>>
>> Marc Zyngier <marc.zyngier <at> arm.com> writes:
>>
>>> +
>>> +AArch64 SMP cores are often associated with a GICv3, providing private
>>> +peripheral interrupts (PPI), shared peripheral interrupts (SPI),
>>> +software generated interrupts (SGI), and locality-specific peripheral
>>> +Interrupts (LPI).
>>> +
>>> +Main node required properties:
>>> +
>>> +- compatible : should at least contain "arm,gic-v3".
>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>> + interrupt source. Must be a single cell with a value of at least 3.
>>> +
>>> + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>>> + interrupts. Other values are reserved for future use.
>>
>> These values are defined in
>> "include/dt-bindings/interrupt-controller/arm-gic.h" maybe we should start
>> mentioning that here and encourage future device treese to use those defines
>> to improve readability.
>
> It may improve readability, but it makes the definition rely on
> something else. Definition and usage are two different things, and I
> want the definition to be completely self-contained and non ambiguous.
>
> In DTS files, people can use whatever macro they decide, and it is their
> problem. They will even have out of tree DTS files, for which the
> include file is not available.
Agreed.
Rob
^ permalink raw reply
* [PATCH v3 01/13] ARM: mvebu: rename armada-370-xp.c to armada-mvebu.c
From: Thomas Petazzoni @ 2014-02-13 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FCC771.5090009@gmail.com>
Dear Sebastian Hesselbarth,
On Thu, 13 Feb 2014 14:24:01 +0100, Sebastian Hesselbarth wrote:
> > Why not. But since this kind of change can be done without breaking the
> > DT compatibility, I'd first prefer to see Dove support merged into
> > mach-mvebu/ with its board file named mach-mvebu/dove.c. Then
> > progressively see what can be combined with armada-mvebu.c so that we
> > can merge both of them into board-v7.c.
>
> Actually, just prepared those patches today. Haven't boot tested but
> compiles cleanly. The patch set will be really small compared to KW
> patch set (but de-hardcoded pinctrl-dove will be a prerequisite).
Cool! I'm planning on giving a test to your pinctrl patches this
afternoon, if all goes well.
> I also prefer to move to mach-mvebu/dove.c and then merge with
> armada-3{78}{05x} a cycle later.
Yes, I agree. I'm fully convinced by the idea of merging the v7 support
together, but we need to proceed step by step to avoid having horrible
merge issues during the 3.15 cycle.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] drivers: net: cpsw: fix buggy loop condition
From: Heiko Schocher @ 2014-02-13 13:47 UTC (permalink / raw)
To: linux-arm-kernel
commit:
>From 0cd8f9cc0654c06adde353c6532114c5f53a18e8 Mon Sep 17 00:00:00 2001
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Thu, 23 Jan 2014 00:03:12 +0530
Subject: [PATCH] drivers: net: cpsw: enable promiscuous mode support
Enable promiscuous mode support for CPSW.
Introduced a crash on an am335x based board (similiar to am335x-evm).
Reason is buggy end condition in for loop in cpsw_set_promiscious()
for (i = 0; i <= priv->data.slaves; i++)
should be
for (i = 0; i < priv->data.slaves; i++)
Fix this ...
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Markus Pargmann <mpa@pengutronix.de>
Cc: netdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
complete crash dump
[ 4.986544] Unable to handle kernel NULL pointer dereference at virtual address 00000120
[ 4.995056] pgd = c0004000
[ 4.997906] [00000120] *pgd=00000000
[ 5.001723] Internal error: Oops: 5 [#1] SMP ARM
[ 5.006560] Modules linked in:
[ 5.009773] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc1-01621-ga10cd7e-dirty #9
[ 5.018243] task: c607b540 ti: c607c000 task.ti: c607c000
[ 5.023914] PC is at cpsw_set_promiscious+0x1d8/0x2a4
[ 5.029204] LR is at cpsw_set_promiscious+0x1c0/0x2a4
[ 5.034494] pc : [<c0407c18>] lr : [<c0407c00>] psr: 60000113
[ 5.034494] sp : c607dd88 ip : c0984ab8 fp : c085c7cc
[ 5.046506] r10: 00000024 r9 : c64b31d8 r8 : 00000003
[ 5.051974] r7 : 00000000 r6 : c64ad800 r5 : c64b3080 r4 : 00000000
[ 5.058806] r3 : 00000003 r2 : c64b3190 r1 : 00000002 r0 : 00000000
[ 5.065641] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 5.073291] Control: 10c5387d Table: 80004019 DAC: 00000017
[ 5.079303] Process swapper/0 (pid: 1, stack limit = 0xc607c248)
[ 5.085592] Stack: (0xc607dd88 to 0xc607e000)
[ 5.090158] dd80: c64ad800 c05ff710 00000000 00000000 00000000 00001002
[ 5.098722] dda0: 0000016b c0409c44 00000000 00000000 c64ad800 c05ff710 00000000 00000000
[ 5.107287] ddc0: 00000000 00001002 0000016b c04cd8cc c64ad964 c64ad800 c64ad82c c04cd920
[ 5.115850] dde0: 00001003 c64ad800 c05ff710 c04cd9f0 00000000 c64ad800 00001002 c64ad800
[ 5.124414] de00: 00001003 00000001 00001002 c04cdc58 c64ad800 00000128 00001002 c08fe840
[ 5.132979] de20: 00000000 c04cdd58 c64ad800 00000003 c085c7e0 c08fe840 c085c7cc c0847ce8
[ 5.141543] de40: 00000000 c058fbf4 c607b540 c5b17cd0 c5b131c8 00000000 12400000 c02a1558
[ 5.150105] de60: c5b17d0c 00000000 00000002 00000000 00000000 00000000 00000002 00000000
[ 5.158669] de80: c05185b4 c00873ac 00000002 00000000 00000000 c05185b4 00000000 c607c030
[ 5.167233] dea0: c607c008 60000113 c08f79c0 c0901610 00000007 c090bdc0 c090bdc0 c08459c8
[ 5.175798] dec0: c0901610 00000007 c090bdc0 c08615ac 00000007 c090bdc0 c090bdc0 c0847b58
[ 5.184362] dee0: 000000bd c607c030 00000000 c0008918 00000004 c08bfa30 c08bfa30 60000113
[ 5.192926] df00: c0089d00 00000000 c08bfa2c 00000000 00000000 c0590db0 00000002 c607c000
[ 5.201489] df20: c7eff36d c05dd514 000000bd c005df1c c07d1ed4 00000007 c7eff419 00000007
[ 5.210054] df40: 60000113 c08615ac 00000007 c090bdc0 c090bdc0 c080450c 000000bd c084d950
[ 5.218620] df60: c084d948 c0804c1c 00000007 00000007 c080450c dfdedeff fcdfffff c7dd9ec0
[ 5.227183] df80: c607c018 00000000 c058668c 00000000 00000000 00000000 00000000 00000000
[ 5.235747] dfa0: 00000000 c0586694 00000000 c000e548 00000000 00000000 00000000 00000000
[ 5.244310] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 5.252873] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 fffff6f7 7ffeefbf
[ 5.261448] [<c0407c18>] (cpsw_set_promiscious) from [<c0409c44>] (cpsw_ndo_set_rx_mode+0x20/0xf8)
[ 5.270841] [<c0409c44>] (cpsw_ndo_set_rx_mode) from [<c04cd8cc>] (__dev_set_rx_mode+0x5c/0x94)
[ 5.279952] [<c04cd8cc>] (__dev_set_rx_mode) from [<c04cd920>] (dev_set_rx_mode+0x1c/0x28)
[ 5.288609] [<c04cd920>] (dev_set_rx_mode) from [<c04cd9f0>] (__dev_open+0xc4/0x110)
[ 5.296720] [<c04cd9f0>] (__dev_open) from [<c04cdc58>] (__dev_change_flags+0x88/0x170)
[ 5.305102] [<c04cdc58>] (__dev_change_flags) from [<c04cdd58>] (dev_change_flags+0x18/0x48)
[ 5.313945] [<c04cdd58>] (dev_change_flags) from [<c0847ce8>] (ip_auto_config+0x190/0x110c)
[ 5.322697] [<c0847ce8>] (ip_auto_config) from [<c0008918>] (do_one_initcall+0xe8/0x148)
[ 5.331190] [<c0008918>] (do_one_initcall) from [<c0804c1c>] (kernel_init_freeable+0x104/0x1c8)
[ 5.340316] [<c0804c1c>] (kernel_init_freeable) from [<c0586694>] (kernel_init+0x8/0x118)
[ 5.348890] [<c0586694>] (kernel_init) from [<c000e548>] (ret_from_fork+0x14/0x2c)
[ 5.356821] Code: e0829009 e2888001 e5990018 e1a03008 (e5900120)
[ 5.363291] ---[ end trace ba29586f1d312ca3 ]---
[ 5.369343] Kernel panic - not syncing: Fatal exception in interrupt
[ 5.376005] drm_kms_helper: panic occurred, switching back to text console
---
drivers/net/ethernet/ti/cpsw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index bde63e3..34b4262 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -554,7 +554,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
* common for both the interface as the interface shares
* the same hardware resource.
*/
- for (i = 0; i <= priv->data.slaves; i++)
+ for (i = 0; i < priv->data.slaves; i++)
if (priv->slaves[i].ndev->flags & IFF_PROMISC)
flag = true;
@@ -578,7 +578,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
unsigned long timeout = jiffies + HZ;
/* Disable Learn for all ports */
- for (i = 0; i <= priv->data.slaves; i++) {
+ for (i = 0; i < priv->data.slaves; i++) {
cpsw_ale_control_set(ale, i,
ALE_PORT_NOLEARN, 1);
cpsw_ale_control_set(ale, i,
@@ -606,7 +606,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 0);
/* Enable Learn for all ports */
- for (i = 0; i <= priv->data.slaves; i++) {
+ for (i = 0; i < priv->data.slaves; i++) {
cpsw_ale_control_set(ale, i,
ALE_PORT_NOLEARN, 0);
cpsw_ale_control_set(ale, i,
--
1.8.3.1
^ permalink raw reply related
* [PATCH] gpu:drm:tilcdc: backlight node never found
From: Heiko Schocher @ 2014-02-13 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In panel_probe() the backlight node is never found, correct this.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Benoit Parrot <bparrot@ti.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Sachin Kamat <sachin.kamat@linaro.org>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Cc: devicetree at vger.kernel.org
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 86c6732..0b97cf4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -356,6 +356,7 @@ static struct of_device_id panel_of_match[];
static int panel_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
+ struct device_node *backlight_node;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
struct pinctrl *pinctrl;
@@ -395,9 +396,15 @@ static int panel_probe(struct platform_device *pdev)
mod->preferred_bpp = panel_mod->info->bpp;
- panel_mod->backlight = of_find_backlight_by_node(node);
- if (panel_mod->backlight)
- dev_info(&pdev->dev, "found backlight\n");
+ backlight_node = of_parse_phandle(pdev->dev.of_node, "backlight", 0);
+ if (backlight_node) {
+ panel_mod->backlight =
+ of_find_backlight_by_node(backlight_node);
+ if (panel_mod->backlight)
+ dev_info(&pdev->dev, "found backlight\n");
+ } else {
+ dev_warn(&pdev->dev, "backlight node missing...\n");
+ }
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 02/18] arm64: GICv3 device tree binding documentation
From: Marc Zyngier @ 2014-02-13 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJMTztbjMRj1_MDevbRHVt8FoSPKLUkXEiqKx1jkzpNOg@mail.gmail.com>
On 13/02/14 13:26, Rob Herring wrote:
> On Wed, Feb 5, 2014 at 7:30 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> Add the necessary documentation to support GICv3.
>>
>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic-v3.txt | 81 ++++++++++++++++++++++++
>> 1 file changed, 81 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/gic-v3.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic-v3.txt b/Documentation/devicetree/bindings/arm/gic-v3.txt
>> new file mode 100644
>> index 0000000..93852f6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/gic-v3.txt
>> @@ -0,0 +1,81 @@
>> +* ARM Generic Interrupt Controller, version 3
>> +
>> +AArch64 SMP cores are often associated with a GICv3, providing private
>> +peripheral interrupts (PPI), shared peripheral interrupts (SPI),
>> +software generated interrupts (SGI), and locality-specific peripheral
>> +Interrupts (LPI).
>> +
>> +Main node required properties:
>> +
>> +- compatible : should at least contain "arm,gic-v3".
>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> + interrupt source. Must be a single cell with a value of at least 3.
>> +
>> + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> + interrupts. Other values are reserved for future use.
>> +
>> + The 2nd cell contains the interrupt number for the interrupt type.
>> + SPI interrupts are in the range [0-987]. PPI interrupts are in the
>> + range [0-15].
>> +
>> + The 3rd cell is the flags, encoded as follows:
>> + bits[3:0] trigger type and level flags.
>> + 1 = edge triggered
>> + 2 = edge triggered (deprecated, for compatibility with GICv2)
>> + 4 = level triggered
>> + 8 = level triggered (deprecated, for compatibility with GICv2)
>
> I don't really think compatibility is needed here. I'd just list 1 and 4.
Fair enough.
>> +
>> + Cells 4 and beyond are reserved for future use. Where the 1st cell
>> + has a value of 0 or 1, cells 4 and beyond act as padding, and may be
>> + ignored. It is recommended that padding cells have a value of 0.
>
> What future use? LPIs I suppose.
That's a possibility, for non-PCI devices. I'd rather not do that
though, but I thought that leaving some room for (wacky) expansion.
> Otherwise, looks fine to me:
>
> Acked-by: Rob Herring <robh@kernel.org>
Thanks!
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V2 11/17] i2c: nomadik: Convert to devm functions
From: Ulf Hansson @ 2014-02-13 14:09 UTC (permalink / raw)
To: linux-arm-kernel
Use devm_* functions to simplify code and error handling.
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
drivers/i2c/busses/i2c-nomadik.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index bc8ba02..5faf9e2 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -981,7 +981,7 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
return -ENODEV;
}
- dev = kzalloc(sizeof(struct nmk_i2c_dev), GFP_KERNEL);
+ dev = devm_kzalloc(&adev->dev, sizeof(struct nmk_i2c_dev), GFP_KERNEL);
if (!dev) {
dev_err(&adev->dev, "cannot allocate memory\n");
ret = -ENOMEM;
@@ -1011,27 +1011,28 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
/* If possible, let's go to idle until the first transfer */
pinctrl_pm_select_idle_state(&adev->dev);
- dev->virtbase = ioremap(adev->res.start, resource_size(&adev->res));
+ dev->virtbase = devm_ioremap(&adev->dev, adev->res.start,
+ resource_size(&adev->res));
if (!dev->virtbase) {
ret = -ENOMEM;
- goto err_no_ioremap;
+ goto err_no_mem;
}
dev->irq = adev->irq[0];
- ret = request_irq(dev->irq, i2c_irq_handler, 0,
+ ret = devm_request_irq(&adev->dev, dev->irq, i2c_irq_handler, 0,
DRIVER_NAME, dev);
if (ret) {
dev_err(&adev->dev, "cannot claim the irq %d\n", dev->irq);
- goto err_irq;
+ goto err_no_mem;
}
pm_suspend_ignore_children(&adev->dev, true);
- dev->clk = clk_get(&adev->dev, NULL);
+ dev->clk = devm_clk_get(&adev->dev, NULL);
if (IS_ERR(dev->clk)) {
dev_err(&adev->dev, "could not get i2c clock\n");
ret = PTR_ERR(dev->clk);
- goto err_no_clk;
+ goto err_no_mem;
}
adap = &dev->adap;
@@ -1053,21 +1054,13 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
ret = i2c_add_adapter(adap);
if (ret) {
dev_err(&adev->dev, "failed to add adapter\n");
- goto err_add_adap;
+ goto err_no_mem;
}
pm_runtime_put(&adev->dev);
return 0;
- err_add_adap:
- clk_put(dev->clk);
- err_no_clk:
- free_irq(dev->irq, dev);
- err_irq:
- iounmap(dev->virtbase);
- err_no_ioremap:
- kfree(dev);
err_no_mem:
return ret;
@@ -1084,13 +1077,9 @@ static int nmk_i2c_remove(struct amba_device *adev)
clear_all_interrupts(dev);
/* disable the controller */
i2c_clr_bit(dev->virtbase + I2C_CR, I2C_CR_PE);
- free_irq(dev->irq, dev);
- iounmap(dev->virtbase);
if (res)
release_mem_region(res->start, resource_size(res));
- clk_put(dev->clk);
pm_runtime_disable(&adev->dev);
- kfree(dev);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 12/17] i2c: nomadik: Remove redundant call to pm_runtime_disable
From: Ulf Hansson @ 2014-02-13 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392300547-23365-1-git-send-email-ulf.hansson@linaro.org>
The amba bus are responsible for pm_runtime_enable|disable, remove the
redundant pm_runtime_disable at driver removal.
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
drivers/i2c/busses/i2c-nomadik.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 5faf9e2..d800d0f 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -1079,7 +1079,6 @@ static int nmk_i2c_remove(struct amba_device *adev)
i2c_clr_bit(dev->virtbase + I2C_CR, I2C_CR_PE);
if (res)
release_mem_region(res->start, resource_size(res));
- pm_runtime_disable(&adev->dev);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 14/17] i2c: nomadik: Fixup deployment of runtime PM
From: Ulf Hansson @ 2014-02-13 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392300547-23365-1-git-send-email-ulf.hansson@linaro.org>
Since the runtime PM state is expected to be active according to the
amba bus, we must align our behaviour while probing to it.
Moreover, this is needed to be able to have the driver fully functional
without depending on CONFIG_RUNTIME_PM.
Since the device is active while a successful probe has been completed,
the reference counting for the clock will be screwed up and never reach
zero. We resolve this by implementing runtime PM callbacks and let them
handle the resources accordingly, including the clock.
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
Squashed with PATCH 13/17 from previous version.
Add error handling to align to previous behavior.
---
drivers/i2c/busses/i2c-nomadik.c | 77 +++++++++++++++++++++++++-------------
1 file changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index d800d0f..01b78df 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -666,7 +666,7 @@ static int nmk_i2c_xfer_one(struct nmk_i2c_dev *dev, u16 flags)
static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num_msgs)
{
- int status;
+ int status = 0;
int i;
struct nmk_i2c_dev *dev = i2c_get_adapdata(i2c_adap);
int j;
@@ -675,19 +675,6 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
pm_runtime_get_sync(&dev->adev->dev);
- status = clk_prepare_enable(dev->clk);
- if (status) {
- dev_err(&dev->adev->dev, "can't prepare_enable clock\n");
- goto out_clk;
- }
-
- /* Optionaly enable pins to be muxed in and configured */
- pinctrl_pm_select_default_state(&dev->adev->dev);
-
- status = init_hw(dev);
- if (status)
- goto out;
-
/* Attempt three times to send the message queue */
for (j = 0; j < 3; j++) {
/* setup the i2c controller */
@@ -708,12 +695,6 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
break;
}
-out:
- clk_disable_unprepare(dev->clk);
-out_clk:
- /* Optionally let pins go into idle state */
- pinctrl_pm_select_idle_state(&dev->adev->dev);
-
pm_runtime_put_sync(&dev->adev->dev);
dev->busy = false;
@@ -930,6 +911,41 @@ static int nmk_i2c_resume(struct device *dev)
#define nmk_i2c_resume NULL
#endif
+#if CONFIG_PM
+static int nmk_i2c_runtime_suspend(struct device *dev)
+{
+ struct amba_device *adev = to_amba_device(dev);
+ struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
+
+ clk_disable_unprepare(nmk_i2c->clk);
+ pinctrl_pm_select_idle_state(dev);
+ return 0;
+}
+
+static int nmk_i2c_runtime_resume(struct device *dev)
+{
+ struct amba_device *adev = to_amba_device(dev);
+ struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
+ int ret;
+
+ ret = clk_prepare_enable(nmk_i2c->clk);
+ if (ret) {
+ dev_err(dev, "can't prepare_enable clock\n");
+ return ret;
+ }
+
+ pinctrl_pm_select_default_state(dev);
+
+ ret = init_hw(nmk_i2c);
+ if (ret) {
+ clk_disable_unprepare(nmk_i2c->clk);
+ pinctrl_pm_select_idle_state(dev);
+ }
+
+ return ret;
+}
+#endif
+
/*
* We use noirq so that we suspend late and resume before the wakeup interrupt
* to ensure that we do the !pm_runtime_suspended() check in resume before
@@ -938,6 +954,9 @@ static int nmk_i2c_resume(struct device *dev)
static const struct dev_pm_ops nmk_i2c_pm = {
.suspend_noirq = nmk_i2c_suspend,
.resume_noirq = nmk_i2c_resume,
+ SET_PM_RUNTIME_PM_OPS(nmk_i2c_runtime_suspend,
+ nmk_i2c_runtime_resume,
+ NULL)
};
static unsigned int nmk_i2c_functionality(struct i2c_adapter *adap)
@@ -1006,11 +1025,6 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
amba_set_drvdata(adev, dev);
- /* Select default pin state */
- pinctrl_pm_select_default_state(&adev->dev);
- /* If possible, let's go to idle until the first transfer */
- pinctrl_pm_select_idle_state(&adev->dev);
-
dev->virtbase = devm_ioremap(&adev->dev, adev->res.start,
resource_size(&adev->res));
if (!dev->virtbase) {
@@ -1035,6 +1049,14 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
goto err_no_mem;
}
+ ret = clk_prepare_enable(dev->clk);
+ if (ret) {
+ dev_err(&adev->dev, "can't prepare_enable clock\n");
+ goto err_no_mem;
+ }
+
+ init_hw(dev);
+
adap = &dev->adap;
adap->dev.of_node = np;
adap->dev.parent = &adev->dev;
@@ -1054,13 +1076,15 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
ret = i2c_add_adapter(adap);
if (ret) {
dev_err(&adev->dev, "failed to add adapter\n");
- goto err_no_mem;
+ goto err_no_adap;
}
pm_runtime_put(&adev->dev);
return 0;
+ err_no_adap:
+ clk_disable_unprepare(dev->clk);
err_no_mem:
return ret;
@@ -1077,6 +1101,7 @@ static int nmk_i2c_remove(struct amba_device *adev)
clear_all_interrupts(dev);
/* disable the controller */
i2c_clr_bit(dev->virtbase + I2C_CR, I2C_CR_PE);
+ clk_disable_unprepare(dev->clk);
if (res)
release_mem_region(res->start, resource_size(res));
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 15/17] i2c: nomadik: Convert to late and early system PM callbacks
From: Ulf Hansson @ 2014-02-13 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392300547-23365-1-git-send-email-ulf.hansson@linaro.org>
At system suspend_late, runtime PM has been disabled by the PM core
which means we can safely operate on these resources. Consequentially
we no longer have to wait until the noirq phase of the system suspend.
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
drivers/i2c/busses/i2c-nomadik.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 01b78df..80b0fd3 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -882,9 +882,8 @@ static irqreturn_t i2c_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
}
-
-#ifdef CONFIG_PM
-static int nmk_i2c_suspend(struct device *dev)
+#ifdef CONFIG_PM_SLEEP
+static int nmk_i2c_suspend_late(struct device *dev)
{
struct amba_device *adev = to_amba_device(dev);
struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
@@ -897,7 +896,7 @@ static int nmk_i2c_suspend(struct device *dev)
return 0;
}
-static int nmk_i2c_resume(struct device *dev)
+static int nmk_i2c_resume_early(struct device *dev)
{
/* First go to the default state */
pinctrl_pm_select_default_state(dev);
@@ -906,9 +905,6 @@ static int nmk_i2c_resume(struct device *dev)
return 0;
}
-#else
-#define nmk_i2c_suspend NULL
-#define nmk_i2c_resume NULL
#endif
#if CONFIG_PM
@@ -946,14 +942,8 @@ static int nmk_i2c_runtime_resume(struct device *dev)
}
#endif
-/*
- * We use noirq so that we suspend late and resume before the wakeup interrupt
- * to ensure that we do the !pm_runtime_suspended() check in resume before
- * there has been a regular pm runtime resume (via pm_runtime_get_sync()).
- */
static const struct dev_pm_ops nmk_i2c_pm = {
- .suspend_noirq = nmk_i2c_suspend,
- .resume_noirq = nmk_i2c_resume,
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(nmk_i2c_suspend_late, nmk_i2c_resume_early)
SET_PM_RUNTIME_PM_OPS(nmk_i2c_runtime_suspend,
nmk_i2c_runtime_resume,
NULL)
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 16/17] i2c: nomadik: Remove busy check for transfers at suspend late
From: Ulf Hansson @ 2014-02-13 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392300547-23365-1-git-send-email-ulf.hansson@linaro.org>
We should never be busy performing transfers at suspend late, thus
there are no reason to check for it.
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
drivers/i2c/busses/i2c-nomadik.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 80b0fd3..8a5dc57b 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -167,7 +167,6 @@ struct i2c_nmk_client {
* @stop: stop condition.
* @xfer_complete: acknowledge completion for a I2C message.
* @result: controller propogated result.
- * @busy: Busy doing transfer.
*/
struct nmk_i2c_dev {
struct i2c_vendor_data *vendor;
@@ -185,7 +184,6 @@ struct nmk_i2c_dev {
int stop;
struct completion xfer_complete;
int result;
- bool busy;
};
/* controller's abort causes */
@@ -671,8 +669,6 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
struct nmk_i2c_dev *dev = i2c_get_adapdata(i2c_adap);
int j;
- dev->busy = true;
-
pm_runtime_get_sync(&dev->adev->dev);
/* Attempt three times to send the message queue */
@@ -697,8 +693,6 @@ static int nmk_i2c_xfer(struct i2c_adapter *i2c_adap,
pm_runtime_put_sync(&dev->adev->dev);
- dev->busy = false;
-
/* return the no. messages processed */
if (status)
return status;
@@ -888,9 +882,6 @@ static int nmk_i2c_suspend_late(struct device *dev)
struct amba_device *adev = to_amba_device(dev);
struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
- if (nmk_i2c->busy)
- return -EBUSY;
-
pinctrl_pm_select_sleep_state(dev);
return 0;
@@ -997,7 +988,6 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
goto err_no_mem;
}
dev->vendor = vendor;
- dev->busy = false;
dev->adev = adev;
nmk_i2c_of_probe(np, dev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 17/17] i2c: nomadik: Fixup system suspend
From: Ulf Hansson @ 2014-02-13 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392300547-23365-1-git-send-email-ulf.hansson@linaro.org>
For !CONFIG_PM_RUNTIME, the device were never put back into active
state while resuming.
For CONFIG_PM_RUNTIME, we blindly trusted the device to be inactive
while we were about to handle it at suspend late, which is just too
optimistic.
Even if the driver uses pm_runtime_put_sync() after each tranfer to
return it's runtime PM resources, there are no guarantees this will
actually mean the device will inactivated. The reason is that the PM
core will prevent runtime suspend during system suspend, and thus when
a transfer occurs during the early phases of system suspend the device
will be kept active after the transfer.
To handle both issues above, we need to re-use the runtime PM callbacks
and check the runtime PM state of the device before proceeding with our
operations for system suspend.
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
drivers/i2c/busses/i2c-nomadik.c | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 8a5dc57b..21539f2 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -879,21 +879,36 @@ static irqreturn_t i2c_irq_handler(int irq, void *arg)
#ifdef CONFIG_PM_SLEEP
static int nmk_i2c_suspend_late(struct device *dev)
{
- struct amba_device *adev = to_amba_device(dev);
- struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
+ if (!pm_runtime_status_suspended(dev)) {
+ int ret = 0;
+ if (dev->pm_domain && dev->pm_domain->ops.runtime_suspend)
+ ret = dev->pm_domain->ops.runtime_suspend(dev);
+ else
+ ret = dev->bus->pm->runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ pm_runtime_set_suspended(dev);
+ }
pinctrl_pm_select_sleep_state(dev);
-
return 0;
}
static int nmk_i2c_resume_early(struct device *dev)
{
- /* First go to the default state */
- pinctrl_pm_select_default_state(dev);
- /* Then let's idle the pins until the next transfer happens */
- pinctrl_pm_select_idle_state(dev);
+ int ret = 0;
+
+ if (dev->pm_domain && dev->pm_domain->ops.runtime_resume)
+ ret = dev->pm_domain->ops.runtime_resume(dev);
+ else
+ ret = dev->bus->pm->runtime_resume(dev);
+ if (ret) {
+ dev_err(dev, "problem resuming\n");
+ return ret;
+ }
+ pm_runtime_set_active(dev);
return 0;
}
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/17] i2c: nomadik: Fixup deployment of runtime PM
From: Ulf Hansson @ 2014-02-13 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrWgB8z1rtWxU7AYvVsmNj_pfGbsozwgP_FzLODpmGRwQ@mail.gmail.com>
On 10 February 2014 11:14, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 5 February 2014 15:34, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>>> Since the device is active while a successful probe has been completed,
>>> the reference counting for the clock will be screwed up and never reach
>>> zero.
>>>
>>> The issue is resolved by implementing runtime PM callbacks and let them
>>> handle the resources accordingly, including the clock.
>>>
>>> Cc: Alessandro Rubini <rubini@unipv.it>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: Wolfram Sang <wsa@the-dreams.de>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Hm do I read it right as patch 13 breaks runtime PM by leaving
>> the device active after probe() and this patch
>> 14 fixes it again? Maybe these two patches should be squashed
>> then.
In v2 I have now squashed patch 13 into this patch 14.
That means patch13 shall be dropped from this patchset.
Kind regards
Uffe
>
> You are right; but the driver will still be working, you just don't
> get the benefit from inactivating the device at request inactivity -
> as you pointed out.
>
> The reason for why I wanted to do this as separate steps was to make
> it easier for reviewing, otherwise the patch(es) would have been quite
> big and messy. I am for sure open to adopt to your proposal, but just
> wanted to give you some more background, before I go ahead and send a
> v2.
>
> Kind regards
> Ulf Hansson
>
>>
>> Yours,
>> Linus Walleij
^ permalink raw reply
* [PATCH] drivers: net: cpsw: fix buggy loop condition
From: Mugunthan V N @ 2014-02-13 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392299247-16917-1-git-send-email-hs@denx.de>
On Thursday 13 February 2014 07:17 PM, Heiko Schocher wrote:
> commit:
> From 0cd8f9cc0654c06adde353c6532114c5f53a18e8 Mon Sep 17 00:00:00 2001
> From: Mugunthan V N <mugunthanvnm@ti.com>
> Date: Thu, 23 Jan 2014 00:03:12 +0530
> Subject: [PATCH] drivers: net: cpsw: enable promiscuous mode support
>
> Enable promiscuous mode support for CPSW.
>
> Introduced a crash on an am335x based board (similiar to am335x-evm).
> Reason is buggy end condition in for loop in cpsw_set_promiscious()
>
> for (i = 0; i <= priv->data.slaves; i++)
>
> should be
>
> for (i = 0; i < priv->data.slaves; i++)
>
> Fix this ...
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Sebastian Siewior <bigeasy@linutronix.de>
> Cc: Daniel Mack <zonque@gmail.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Markus Pargmann <mpa@pengutronix.de>
> Cc: netdev at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
Ah, it's copy paste error, thanks for the fix.
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH] ARM: imx6: fix !CONFIG_PM and !CONFIG_CPU_IDLE build
From: Shawn Guo @ 2014-02-13 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392201948-16311-1-git-send-email-l.stach@pengutronix.de>
Hi Lucas,
On Wed, Feb 12, 2014 at 11:45:48AM +0100, Lucas Stach wrote:
> When building a kernel with only CONFIG_CPU_IDLE, but no
> CONFIG_PM we still need the functions to set the lpm mode
> and chicken bits.
>
> Also if both options are unset, we have to stub out the
> set_lpm function, as this one is called from the clk
> driver directly.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> This fix depends on an earlier one by Philipp:
> "ARM: imx6: Initialize low-power mode early again"
>
> Both should go to stable after a sensible sinking time.
> ---
> arch/arm/mach-imx/Makefile | 9 +++-
> arch/arm/mach-imx/common.h | 11 +++--
> arch/arm/mach-imx/pm-imx6q.c | 112 ++++++++++++++++++++++---------------------
> 3 files changed, 72 insertions(+), 60 deletions(-)
Since we already have so many stuff in pm-imx6q.c needed by a !CONFIG_PM
build, maybe we should build pm-imx6q.c without CONFIG_PM condition,
something like the following?
Shawn
---8<-----------
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index befcaf5..ec41964 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -101,11 +101,9 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o mach-imx6sl.o
-ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
# i.MX6SL reuses i.MX6Q code
obj-$(CONFIG_SOC_IMX6SL) += pm-imx6q.o headsmp.o
-endif
# i.MX5 based machines
obj-$(CONFIG_MACH_MX51_BABBAGE) += mach-mx51_babbage.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 59c3b9b..baf439d 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -144,13 +144,11 @@ void imx6q_set_chicken_bit(void);
void imx_cpu_die(unsigned int cpu);
int imx_cpu_kill(unsigned int cpu);
-#ifdef CONFIG_PM
void imx6q_pm_init(void);
void imx6q_pm_set_ccm_base(void __iomem *base);
+#ifdef CONFIG_PM
void imx5_pm_init(void);
#else
-static inline void imx6q_pm_init(void) {}
-static inline void imx6q_pm_set_ccm_base(void __iomem *base) {}
static inline void imx5_pm_init(void) {}
#endif
^ permalink raw reply related
* [PATCH] i2c: mv64xxx: Fix locked bus when offload is selected but not used on a message
From: Gregory CLEMENT @ 2014-02-13 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213094117.GA3934@katana>
Hi Wolfram,
Thanks for you review,
On 13/02/2014 10:41, Wolfram Sang wrote:
>> --- a/drivers/i2c/busses/i2c-mv64xxx.c
>> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
>> @@ -461,8 +461,15 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
>> case MV64XXX_I2C_ACTION_OFFLOAD_SEND_START:
>> if (!mv64xxx_i2c_offload_msg(drv_data))
>> break;
>> - else
>> + else {
>
> Here you break the coding style...
>
>> drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
>> + /*
>> + * Switch to the standard path, so we finally need to
>> + * prepare the io that have not been done in
>> + * mv64xxx_i2c_execute_msg
>> + */
>> + mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
>> + }
>
> ... but more importantly, NACK. The code is already hard to follow which
> is the cause for this bug. This snipplet makes the code even harder to
> read, so it needs some simplification IMO. I'll fire up a counterpatch
> in a minute to explain what I mean.
OK, as long as we have a fix for this issue.
I am waiting for your patch.
Thanks,
Gregory
>
>> /* FALLTHRU */
>> case MV64XXX_I2C_ACTION_SEND_START:
>> writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
>> --
>> 1.8.1.2
>>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 2/7] clk: samsung: add infrastructure to register cpu clocks
From: Tomasz Figa @ 2014-02-13 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9aiqTPRKha4rBVxsqfWE1q2W3nP75vsY-0H+7A5YVq4vsg@mail.gmail.com>
On 13.02.2014 08:58, Thomas Abraham wrote:
> On Wed, Feb 12, 2014 at 11:55 PM, Tomasz Figa <t.figa@samsung.com> wrote:
>> On 07.02.2014 16:55, Thomas Abraham wrote:
>>> +/* common round rate callback useable for all types of cpu clocks */
>>> +static long samsung_cpuclk_round_rate(struct clk_hw *hw,
>>> + unsigned long drate, unsigned long *prate)
>>> +{
>>> + struct clk *parent = __clk_get_parent(hw->clk);
>>> + unsigned long max_prate = __clk_round_rate(parent, UINT_MAX);
>>> + unsigned long t_prate, best_div = 1;
>>> + unsigned long delta, min_delta = UINT_MAX;
>>> +
>>> + do {
>>> + t_prate = __clk_round_rate(parent, drate * best_div);
>>> + delta = drate - (t_prate / best_div);
>>> + if (delta < min_delta) {
>>> + *prate = t_prate;
>>> + min_delta = delta;
>>> + }
>>> + if (!delta)
>>> + break;
>>> + best_div++;
>>> + } while ((drate * best_div) < max_prate && best_div <= MAX_DIV);
>>> +
>>> + return t_prate / best_div;
>>> +}
>>
>>
>> I think there is something wrong with the code above. You increment best_div
>> in every iteration of the loop and use it to calculate the final best
>> frequency. Shouldn't best_div be the divisor which was found to give the
>> least delta and so the loop should rather iterate on a different variable
>> and store best_div only if (delta < min_delta) condition is true?
>
> This function finds out the best parent frequency (APLL in this case)
> which when divided with some divider value provides the the closest
> possible drate. Probably, the name best_div is misleading since there
> is no need to know the value of best_div outside this function.
>
What I mean is that the .round_rate() method is defined with two output
values - best parent rate (*prate) and resulting rate of the clock
itself (the value returned). Now, your function uses different divisor
value to calculate the return value than the one found to give best
delta, which is wrong.
>>
>> Anyway, I wonder if you couldn't somehow reuse the code from
>> drivers/clk/clk-divider.c...
>
> Yes, there are some similarities between these but they are not
> entirely the same.
They are implemented using slightly different ways (the one in
clk-divider is more generic), but I believe they calculate exactly the same.
>>
>>
>>> +
>>> +static unsigned long _calc_div(unsigned long prate, unsigned long drate)
>>> +{
>>> + unsigned long div = prate / drate;
>>> +
>>> + WARN_ON(div >= MAX_DIV);
>>> + return (!(prate % drate)) ? div-- : div;
>>> +}
>>> +
>>> +/* helper function to register a cpu clock */
>>> +static int __init samsung_cpuclk_register(unsigned int lookup_id,
>>
>>
>> Isn't the name a bit too generic? I'd say it should be
>> exynos_cpuclk_register(), since the implementation is rather Exynos specific
>> anyway.
>
> The implementation of the cpu clock type is supposed to be usable on
> all Samsung SoCs starting from s3c24xx onwards. I should have probably
> stated that explicitly.
I'm not sure how much of the code added by this patch could be reused by
pre-Exynos platforms. AFAIK, except s5v210, their ARM frequency change
semantics are completely different, so maybe we shouldn't bloat Exynos
code by trying to make it too generic.
I believe we should keep this Exynos-specific right now to make the code
simpler and, if needed and found to be appropriate after analyzing how
cpufreq works on them, it might be extended to support older SoCs as
well in future.
>>
>>
>>> + init.parent_names = parents;
>>> + init.num_parents = 1;
>>
>>
>> I believe this clock should take two clocks as its parents, because it can
>> dynamically switch between mout_apll and mout_mpll using mout_core mux.
>
> Since the mout_core mux is encapsulated into the cpu clock type, the
> dynamic switching is not allowed from CCF API. The switching is fully
> controlled by the cpu clock type when required and hence the CCF need
> not be told about 2 parents.
>
Semantically, the ARM clock can use two different parents, which are not
encapsulated inside, but instead are fed into the ARM clock block from
outside, so CCF should know about it.
However, looking at the clock core code again, it seems to support only
num_parents > 1 when .get_parent() op is implemented, so for now it
should be safe to keep it as is.
>>
>>
>>> + init.ops = ops;
>>> +
>>> + cpuclk->hw.init = &init;
>>> + cpuclk->ctrl_base = base;
>>> +
>>> + if (soc_data && soc_data->parser) {
>>
>>
>> Is it even possible to instantiate this clock without soc_data and parser
>> function? Shouldn't it simply bail out instead?
>
> Yes, the intent was to allow Samsung cpu clock type to usable on
> non-DT platforms as well. If a platform has soc_data, then the parser
> can be called.
If we keep this Exynos-specific, which I believe is better than making
the code overly generic, this could be simplified.
>
>>
>>
>>> + ret = soc_data->parser(np, &cpuclk->data);
>>> + if (ret) {
>>> + pr_err("%s: error %d in parsing %s clock data",
>>> + __func__, ret, name);
>>> + ret = -EINVAL;
>>> + goto free_cpuclk;
>>> + }
>>> + cpuclk->offset = soc_data->offset;
>>> + init.ops = soc_data->ops;
>>> + }
>>> +
>>> + if (soc_data && soc_data->clk_cb) {
>>
>>
>> Same here. Does it make any sense to instantiate this clock without a
>> notifier callback?
>>
>>
>>> + cpuclk->clk_nb.notifier_call = soc_data->clk_cb;
>>> + if (clk_notifier_register(__clk_lookup(parents[0]),
>>> + &cpuclk->clk_nb)) {
>>> + pr_err("%s: failed to register clock notifier for
>>> %s\n",
>>> + __func__, name);
>>> + goto free_cpuclk_data;
>>> + }
>>> + }
>>> +
>>> + if (num_parents == 2) {
>>
>>
>> When num_parents could be other than 2?
>
> If any Samsung SoC needs no alternate parent clock when changing armclk rate.
>
I don't see any real need for this for now. It can be added later if
such need shows up. For now, I don't think much of this code will be
reusable on pre-s5pv210 SoCs anyway and s5pv210 needs alternate parent
too, so it's safe to support only such setup.
>>> + if (readl(base + SRC_CPU) & EXYNOS4210_MUX_HPM_MASK) {
>>> + div1 = readl(base + DIV_CPU1) & EXYNOS4210_DIV1_HPM_MASK;
>>> + div1 |= ((armclk_data->div1) & ~EXYNOS4210_DIV1_HPM_MASK);
>>> + }
>>> +
>>> + /*
>>> + * if the new and old parent clock speed is less than the clock
>>> speed
>>> + * of the alternate parent, then it should be ensured that at no
>>> point
>>> + * the armclk speed is more than the old_prate until the dividers
>>> are
>>> + * set.
>>> + */
>>> + need_safe_freq = ndata->old_rate < alt_prate &&
>>> + ndata->new_rate < alt_prate;
>>
>>
>> Are you sure this condition is correct? The parent clock (PLL) alone doesn't
>> fully determine the rate of ARM clock, because you are also changing
>> div_core. So you can end up with PLL going down, while ARM clock going up,
>> because the divisors are significantly lowered.
>
> Interesting! I did not think about this. Will fix it.
>
>>
>> I think you should compare ARM clock rates here OR just remove div_core
>> configuration, keeping it as 0 (divide by 1) all the time, except when safe
>> frequency is active.
>
> I would like to keep have div_core configuration, since it gives more
> options for armclk, not just limited to PLL speeds.
Could this be added later as an extension? The original Exynos cpufreq
doesn't seem to change these divisors and I'm not sure if we should be
touching them. I'd rather keep the semantics of the old driver, at least
for now.
>>
>> You seem to always perform the configuration in pre rate change notifier,
>> but original cpufreq code used to do it depending on whether the new
>> frequency is less than old or not, e.g.
>
> Yes, but with the clock notifier callback, we need not do it like below.
I don't think so. Your code always seem to do the transition in exactly
the same order, regardless of transition direction. I assume that
original driver contained such distinction, because of some hardware
requirements and so such semantics should be preserved in new code.
This series is a refactor and should not introduce functional changes.
Any semantic changes should be done as separate patches to make sure
that no regressions are introduced.
>>
>> The property should be prefixed with "#" as other properties defining number
>> of cells.
>
> Isn't # a unnecessary requirement here. The old dt bindings used to
> have it and I am not sure in what way it helps. And this is a samsung
> specific property. Anyways, I do not have any particular preference on
> this.
Well, all such properties used to follow this convention, so I'm not
sure why we should be changing this.
>>
>>> + prop = of_find_property(np, "samsung,armclk-divider-table", NULL);
>>> + if (!prop)
>>> + return -EINVAL;
>>> + if (!prop->value)
>>> + return -EINVAL;
>>> + if ((prop->length / sizeof(u32)) % cells)
>>> + return -EINVAL;
>>> + row = ((prop->length / sizeof(u32)) / cells) + 1;
>>
>>
>> Why + 1? Also the variable could be named in a bit more meaningful way, e.g.
>> num_rows.
>
> +1 since this is a zero terminated table. Will change the variable name.
>
To make this more clear, I'd say you should simply add 1 when calling
kzalloc() and not include sentinel row in nr_rows...
>>
>>
>>> +
>>> + *data = kzalloc(sizeof(*tdata) * row, GFP_KERNEL);
>>> + if (!*data)
>>> + ret = -ENOMEM;
>>> + tdata = *data;
>>> +
>>> + val = prop->value;
>>> + for (; row > 1; row--, tdata++) {
...then you could iterate here to 0. However to make the code more
readable I would simply rewrite this to:
for (row = 0; row < nr_rows; ++row, ++tdata) {
>>> +/**
>>> + * samsung_register_arm_clock: register arm clock with ccf.
>>> + * @lookup_id: armclk clock output id for the clock controller.
>>> + * @parent: name of the parent clock for armclk.
>>> + * @base: base address of the clock controller from which armclk is
>>> generated.
>>> + * @np: device tree node pointer of the clock controller (optional).
>>> + * @ops: clock ops for this clock (optional)
>>> + */
>>> +int __init samsung_register_arm_clock(unsigned int lookup_id,
>>> + const char **parent_names, unsigned int num_parents,
>>> + void __iomem *base, struct device_node *np, struct clk_ops
>>> *ops)
>>> +{
>>> + const struct of_device_id *match;
>>> + const struct samsung_cpuclk_soc_data *data = NULL;
>>> +
>>> + if (np) {
>>> + match = of_match_node(samsung_clock_ids_armclk, np);
>>> + data = match ? match->data : NULL;
>>> + }
>>
>>
>> Since this is rather Exynos-specific and Exynos is DT-only, np being NULL
>> would be simply an error.
>
> The cpu clock type is usable for not-dt samsung platform also.
As I said, I would recommend keeping this simple to cover just Exynos
SoCs for now. The design might also consider s5pv210, but it's going to
be fully converted to DT as well, so it should be safe to make this code
DT-only.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Select imx thermal and cpufreq
From: Fabio Estevam @ 2014-02-13 14:32 UTC (permalink / raw)
To: linux-arm-kernel
Let imx thermal and cpufreq drivers be built by default.
Generated by doing:
- Selected imx thermal and cpufreq via 'make menuconfig'
- make savedefconfig
- cp defconfig arch/arm/configs/imx_v6_v7_defconfig
(This is why CONFIG_COMMON_CLK_DEBUG is deleted)
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 7b76794..2d5834f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -47,6 +47,7 @@ CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
+CONFIG_CPU_FREQ=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_BINFMT_MISC=m
@@ -157,6 +158,9 @@ CONFIG_SPI_IMX=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_MC9S08DZ60=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_IMX_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_IMX2_WDT=y
CONFIG_MFD_DA9052_I2C=y
@@ -245,7 +249,6 @@ CONFIG_DRM_IMX_TVE=y
CONFIG_DRM_IMX_LDB=y
CONFIG_DRM_IMX_IPUV3_CORE=y
CONFIG_DRM_IMX_IPUV3=y
-CONFIG_COMMON_CLK_DEBUG=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_PWM=y
CONFIG_PWM_IMX=y
--
1.8.1.2
^ 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