* [PATCH 28/28] Remove LOCAL_TIMERS
From: Richard Weinberger @ 2014-02-09 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-1-git-send-email-richard@nod.at>
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/arm/mach-omap2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 653b489..2817f1f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -54,7 +54,6 @@ config SOC_OMAP5
select ARM_GIC
select CPU_V7
select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if LOCAL_TIMERS
select HAVE_SMP
select HAVE_ARM_ARCH_TIMER
select ARM_ERRATA_798181 if SMP
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH 12/28] Remove GENERIC_TIME
From: Alexander Shiyan @ 2014-02-09 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-13-git-send-email-richard@nod.at>
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> arch/arm/mach-bcm/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index b1aa6a9..8dd5fbf 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -19,7 +19,6 @@ config ARCH_BCM_MOBILE
> select CPU_V7
> select CLKSRC_OF
> select GENERIC_CLOCKEVENTS
> - select GENERIC_TIME
> select GPIO_BCM_KONA
> select SPARSE_IRQ
> select TICK_ONESHOT
> --
> 1.8.4.2
I sent a similar patch in November, maintainers nothing did with it.
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/278293
---
^ permalink raw reply
* [PATCH 08/12] clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442
From: Tomasz Figa @ 2014-02-09 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201312131401.52029.heiko@sntech.de>
Hi Heiko,
On 13.12.2013 14:01, Heiko St?bner wrote:
> This driver can handle the clock controllers of the socs mentioned above,
> as they share a common clock tree with only small differences.
[snip]
> diff --git a/drivers/clk/samsung/clk-s3c2410.c b/drivers/clk/samsung/clk-s3c2410.c
> new file mode 100644
> index 0000000..8358cad
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-s3c2410.c
[snip]
> +static struct clk_div_table divslow_d[] = {
> + { .val = 0, .div = 1 },
> + { .val = 1, .div = 2 },
> + { .val = 2, .div = 4 },
> + { .val = 3, .div = 6 },
> + { .val = 4, .div = 8 },
> + { .val = 5, .div = 10 },
> + { .val = 6, .div = 12 },
> + { .val = 7, .div = 14 },
> + { .div = 0 },
nit: It might be just a matter of preference, but I'd say the more
common pattern is to define the last entry as:
{ /* sentinel */ },
It will be initialized to all-zeroes anyway, but the comment will tell
its purpose.
> +};
> +
> +struct samsung_div_clock s3c2410_common_dividers[] __initdata = {
> + DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
> + DIV(PCLK, "pclk", "hclk", CLKDIVN, 0, 1),
> +};
[snip]
> +static struct samsung_pll_rate_table pll_s3c2410_12mhz_tbl[] __initdata = {
> + /* sorted in descending order */
> + /* 2410A extras */
> + PLL_35XX_RATE(270000000, 127, 1, 1),
> + PLL_35XX_RATE(268000000, 126, 1, 1),
> + PLL_35XX_RATE(266000000, 125, 1, 1),
> + PLL_35XX_RATE(226000000, 105, 1, 1),
> + PLL_35XX_RATE(210000000, 132, 2, 1),
> + /* 2410 common */
> + PLL_35XX_RATE(203000000, 161, 3, 1),
> + PLL_35XX_RATE(192000000, 88, 1, 1),
> + PLL_35XX_RATE(186000000, 85, 1, 1),
> + PLL_35XX_RATE(180000000, 82, 1, 1),
> + PLL_35XX_RATE(170000000, 77, 1, 1),
> + PLL_35XX_RATE(158000000, 71, 1, 1),
> + PLL_35XX_RATE(152000000, 68, 1, 1),
> + PLL_35XX_RATE(147000000, 90, 2, 1),
> + PLL_35XX_RATE(135000000, 82, 2, 1),
> + PLL_35XX_RATE(124000000, 116, 1, 2),
> + PLL_35XX_RATE(118000000, 150, 2, 2),
> + PLL_35XX_RATE(113000000, 105, 1, 2),
> + PLL_35XX_RATE(101000000, 127, 2, 2),
> + PLL_35XX_RATE(90000000, 112, 2, 2),
> + PLL_35XX_RATE(85000000, 105, 2, 2),
> + PLL_35XX_RATE(79000000, 71, 1, 2),
> + PLL_35XX_RATE(68000000, 82, 2, 2),
> + PLL_35XX_RATE(56000000, 142, 2, 3),
> + PLL_35XX_RATE(48000000, 120, 2, 3),
> + PLL_35XX_RATE(51000000, 161, 3, 3),
> + PLL_35XX_RATE(45000000, 82, 1, 3),
> + PLL_35XX_RATE(34000000, 82, 2, 3),
> + { },
nit: The same comment about the sentinel as above.
> +};
> +
> +static struct samsung_pll_clock s3c2410_plls[] __initdata = {
> + [mpll] = PLL(pll_s3c2410_mpll, MPLL, "mpll", "xti",
> + LOCKTIME, MPLLCON, NULL),
> + [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
> + LOCKTIME, UPLLCON, NULL),
> +};
[snip]
> +static struct samsung_pll_rate_table pll_s3c244x_12mhz_tbl[] __initdata = {
> + /* sorted in descending order */
> + PLL_35XX_RATE(400000000, 0x5c, 1, 1),
> + PLL_35XX_RATE(390000000, 0x7a, 2, 1),
> + PLL_35XX_RATE(380000000, 0x57, 1, 1),
> + PLL_35XX_RATE(370000000, 0xb1, 4, 1),
> + PLL_35XX_RATE(360000000, 0x70, 2, 1),
> + PLL_35XX_RATE(350000000, 0xa7, 4, 1),
> + PLL_35XX_RATE(340000000, 0x4d, 1, 1),
> + PLL_35XX_RATE(330000000, 0x66, 2, 1),
> + PLL_35XX_RATE(320000000, 0x98, 4, 1),
> + PLL_35XX_RATE(310000000, 0x93, 4, 1),
> + PLL_35XX_RATE(300000000, 0x75, 3, 1),
> + PLL_35XX_RATE(240000000, 0x70, 1, 2),
> + PLL_35XX_RATE(230000000, 0x6b, 1, 2),
> + PLL_35XX_RATE(220000000, 0x66, 1, 2),
> + PLL_35XX_RATE(210000000, 0x84, 2, 2),
> + PLL_35XX_RATE(200000000, 0x5c, 1, 2),
> + PLL_35XX_RATE(190000000, 0x57, 1, 2),
> + PLL_35XX_RATE(180000000, 0x70, 2, 2),
> + PLL_35XX_RATE(170000000, 0x4d, 1, 2),
> + PLL_35XX_RATE(160000000, 0x98, 4, 2),
> + PLL_35XX_RATE(150000000, 0x75, 3, 2),
> + PLL_35XX_RATE(120000000, 0x70, 1, 3),
> + PLL_35XX_RATE(110000000, 0x66, 1, 3),
> + PLL_35XX_RATE(100000000, 0x5c, 1, 3),
> + PLL_35XX_RATE(90000000, 0x70, 2, 3),
> + PLL_35XX_RATE(80000000, 0x98, 4, 3),
> + PLL_35XX_RATE(75000000, 0x75, 3, 3),
Hmm, don't you need a sentinel here?
> +};
> +
> +static struct samsung_pll_clock s3c244x_common_plls[] __initdata = {
> + [mpll] = PLL(pll_s3c2440_mpll, MPLL, "mpll", "xti",
> + LOCKTIME, MPLLCON, NULL),
> + [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
> + LOCKTIME, UPLLCON, NULL),
> +};
> +
> +PNAME(hclk_p) = { "fclk", "div_hclk_2", "div_hclk_4", "div_hclk_3" };
> +PNAME(armclk_p) = { "fclk", "hclk" };
> +
> +struct samsung_mux_clock s3c244x_common_muxes[] __initdata = {
> + MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
> + MUX(ARMCLK, "armclk", armclk_p, CAMDIVN, 12, 1),
> +};
> +
> +struct samsung_fixed_factor_clock s3c244x_common_ffactor[] __initdata = {
> + FFACTOR(0, "div_hclk_2", "fclk", 1, 2, 0),
> + FFACTOR(0, "ff_cam", "div_cam", 2, 1, CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_div_table div_hclk_4_d[] = {
> + { .val = 0, .div = 4 },
> + { .val = 1, .div = 8 },
Missing sentinel?
> +};
> +
> +static struct clk_div_table div_hclk_3_d[] = {
> + { .val = 0, .div = 3 },
> + { .val = 1, .div = 6 },
Ditto.
> +};
> +
> +struct samsung_div_clock s3c244x_common_dividers[] __initdata = {
> + DIV(UCLK, "uclk", "upll", CLKDIVN, 3, 1),
> + DIV(0, "div_hclk", "fclk", CLKDIVN, 1, 1),
> + DIV_T(0, "div_hclk_4", "fclk", CAMDIVN, 9, 1, div_hclk_4_d),
> + DIV_T(0, "div_hclk_3", "fclk", CAMDIVN, 8, 1, div_hclk_3_d),
> + DIV(0, "div_cam", "upll", CAMDIVN, 0, 3),
> +};
[snip]
> +/*
> + * fixed rate clocks generated outside the soc
> + * Only necessary until the devicetree-move is complete
> + */
> +struct samsung_fixed_rate_clock s3c2410_common_frate_clks[] __initdata = {
> + FRATE(XTI, "xti", NULL, CLK_IS_ROOT, 0),
Do you need to assign this clock an ID? When DT is used, it's defined as
a separate clock provider using fixed clock bindings, so it is not
provided by this driver.
> +};
> +
> +static void __init s3c2410_common_clk_register_fixed_ext(unsigned long xti_f)
> +{
> + struct samsung_clock_alias xti_alias = ALIAS(XTI, NULL, "xtal");
> +
> + s3c2410_common_frate_clks[0].fixed_rate = xti_f;
> + samsung_clk_register_fixed_rate(s3c2410_common_frate_clks,
> + ARRAY_SIZE(s3c2410_common_frate_clks));
> +
> + samsung_clk_register_alias(&xti_alias, 1);
> +}
[snip]
> diff --git a/include/dt-bindings/clock/samsung,s3c2410-clock.h b/include/dt-bindings/clock/samsung,s3c2410-clock.h
> new file mode 100644
> index 0000000..66c278f
> --- /dev/null
> +++ b/include/dt-bindings/clock/samsung,s3c2410-clock.h
I know this is nitpiccking, but I'd say that the name of this file could
be made a simple "s3c2410.h", as it's already located in "clock"
directory and "s3c2410" is specific enough to not add "samsung" prefix.
At the time of writing the s3c64xx CCF driver I went for full compatible
string as the file name, but at that time there was just a few DT
binding headers available and so no widely used naming convention. Now
looking at file names, other platforms seem to use just a simple name
and we decided to do the same for Exynos as well, so I think s3c24xx
should follow the same.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Remove MACH_NOKIA_N800
From: Aaro Koskinen @ 2014-02-09 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391958088.25424.17.camel@x220>
Hi,
On Sun, Feb 09, 2014 at 04:01:28PM +0100, Paul Bolle wrote:
> The last caller of machine_is_nokia_n800() was removed in commit
> 5a87cde490e1 ("ARM: OMAP2+: Remove legacy booting support for n8x0").
> That means that the Kconfig symbol MACH_NOKIA_N800 is now unused. It can
> safely be removed.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
> ---
> Untested.
>
> arch/arm/mach-omap2/Kconfig | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 653b489..66da3f5 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -268,9 +268,6 @@ config MACH_OMAP_3430SDP
> default y
> select OMAP_PACKAGE_CBB
>
> -config MACH_NOKIA_N800
> - bool
> -
> config MACH_NOKIA_N810
> bool
>
> @@ -281,7 +278,6 @@ config MACH_NOKIA_N8X0
> bool "Nokia N800/N810"
> depends on SOC_OMAP2420
> default y
> - select MACH_NOKIA_N800
> select MACH_NOKIA_N810
> select MACH_NOKIA_N810_WIMAX
> select OMAP_PACKAGE_ZAC
> --
> 1.8.5.3
>
> --
> 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 00/12] ARM: S3C24XX: convert s3c2410, s3c2440 s3c2442 to common clock framework
From: Tomasz Figa @ 2014-02-09 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201312131356.40755.heiko@sntech.de>
Hi Heiko,
On 13.12.2013 13:56, Heiko St?bner wrote:
> This series converts the earliest s3c socs to use a clock driver based on the
> common clock framework instead of the old Samsung clock implementation.
>
> The only obstacle I found was the configuration of the clkout outputs in
> the different machines. As I lack hardware test and knowledge on what is
> expected there, somebody with interest in these machines will have to
> step up to implement the clkout configuration
> This can for example be done in the machine_init function after
> the platform-devices (and thus the dclk-device) are populated.
>
> This leaves the s3c2412 soc to be converted, as it has yet another different
> clock tree.
>
> Tested on an Openmoko Neo Freerunner (S3C2442), but of course more tests
> would be really helpful.
>
> Heiko Stuebner (12):
> ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
> dt-bindings: document s3c24xx controller for external clock output
> clk: samsung: add clock driver for external clock outputs
> ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled
> ARM: S3C24XX: only store clock registers when old clock code is active
> clk: samsung: add plls used by the early s3c24xx cpus
> dt-bindings: add documentation for s3c2410 clock controller
> clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442
> ARM: S3C24XX: add platform code for conversion to the common clock framework
> ARM: S3C24XX: convert s3c2440 and s3c2442 to common clock framework
> ARM: S3C24XX: convert s3c2410 to common clock framework
> ARM: S3C24XX: remove legacy clock code
>
> .../bindings/clock/samsung,s3c2410-clock.txt | 50 ++
> .../bindings/clock/samsung,s3c2410-dclk.txt | 53 ++
> arch/arm/mach-s3c24xx/Kconfig | 50 +-
> arch/arm/mach-s3c24xx/Makefile | 6 +-
> arch/arm/mach-s3c24xx/clock-dclk.c | 195 --------
> arch/arm/mach-s3c24xx/clock-s3c2410.c | 285 -----------
> arch/arm/mach-s3c24xx/clock-s3c2440.c | 217 --------
> arch/arm/mach-s3c24xx/clock-s3c244x.c | 141 ------
> arch/arm/mach-s3c24xx/common.c | 45 +-
> arch/arm/mach-s3c24xx/common.h | 11 +-
> arch/arm/mach-s3c24xx/cpufreq-utils.c | 13 +
> arch/arm/mach-s3c24xx/include/mach/regs-clock.h | 18 -
> arch/arm/mach-s3c24xx/include/mach/regs-gpio.h | 3 -
> arch/arm/mach-s3c24xx/mach-amlm5900.c | 9 +-
> arch/arm/mach-s3c24xx/mach-anubis.c | 15 +-
> arch/arm/mach-s3c24xx/mach-at2440evb.c | 10 +-
> arch/arm/mach-s3c24xx/mach-bast.c | 15 +-
> arch/arm/mach-s3c24xx/mach-gta02.c | 8 +-
> arch/arm/mach-s3c24xx/mach-h1940.c | 10 +-
> arch/arm/mach-s3c24xx/mach-mini2440.c | 10 +-
> arch/arm/mach-s3c24xx/mach-n30.c | 12 +-
> arch/arm/mach-s3c24xx/mach-nexcoder.c | 10 +-
> arch/arm/mach-s3c24xx/mach-osiris.c | 15 +-
> arch/arm/mach-s3c24xx/mach-otom.c | 10 +-
> arch/arm/mach-s3c24xx/mach-qt2410.c | 9 +-
> arch/arm/mach-s3c24xx/mach-rx1950.c | 15 +-
> arch/arm/mach-s3c24xx/mach-rx3715.c | 10 +-
> arch/arm/mach-s3c24xx/mach-smdk2410.c | 9 +-
> arch/arm/mach-s3c24xx/mach-smdk2440.c | 10 +-
> arch/arm/mach-s3c24xx/mach-tct_hammer.c | 9 +-
> arch/arm/mach-s3c24xx/mach-vr1000.c | 15 +-
> arch/arm/mach-s3c24xx/pm.c | 13 +-
> arch/arm/mach-s3c24xx/s3c2410.c | 56 ---
> arch/arm/mach-s3c24xx/s3c2442.c | 111 -----
> arch/arm/mach-s3c24xx/s3c244x.c | 59 +--
> drivers/clk/samsung/Makefile | 2 +
> drivers/clk/samsung/clk-pll.c | 182 +++++++
> drivers/clk/samsung/clk-pll.h | 3 +
> drivers/clk/samsung/clk-s3c2410-dclk.c | 517 ++++++++++++++++++++
> drivers/clk/samsung/clk-s3c2410.c | 428 ++++++++++++++++
> include/dt-bindings/clock/samsung,s3c2410-clock.h | 64 +++
> include/dt-bindings/clock/samsung,s3c2410-dclk.h | 28 ++
> 42 files changed, 1575 insertions(+), 1176 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2410-dclk.txt
> delete mode 100644 arch/arm/mach-s3c24xx/clock-dclk.c
> delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2410.c
> delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2440.c
> delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c244x.c
> create mode 100644 drivers/clk/samsung/clk-s3c2410-dclk.c
> create mode 100644 drivers/clk/samsung/clk-s3c2410.c
> create mode 100644 include/dt-bindings/clock/samsung,s3c2410-clock.h
> create mode 100644 include/dt-bindings/clock/samsung,s3c2410-dclk.h
>
For patches 4, 5, 9, 10, 11, 12:
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
For patches 6, 7:
Acked-by: Tomasz Figa <t.figa@samsung.com>
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 12/28] Remove GENERIC_TIME
From: Richard Weinberger @ 2014-02-09 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391972239.567717844@f148.i.mail.ru>
Am 09.02.2014 19:57, schrieb Alexander Shiyan:
>> The symbol is an orphan, get rid of it.
>>
>> Signed-off-by: Richard Weinberger <richard@nod.at>
>> ---
>> arch/arm/mach-bcm/Kconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index b1aa6a9..8dd5fbf 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -19,7 +19,6 @@ config ARCH_BCM_MOBILE
>> select CPU_V7
>> select CLKSRC_OF
>> select GENERIC_CLOCKEVENTS
>> - select GENERIC_TIME
>> select GPIO_BCM_KONA
>> select SPARSE_IRQ
>> select TICK_ONESHOT
>> --
>> 1.8.4.2
>
> I sent a similar patch in November, maintainers nothing did with it.
> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/278293
Then it is time to push it. :D
Thanks,
//richard
^ permalink raw reply
* [PATCH 01/10] watchdog: xilinx: Convert driver to the watchdog framework
From: Guenter Roeck @ 2014-02-09 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ed4cb31c9a549343e6b492cf62fc962d39034bd0.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> - Remove uneeded headers, fops functions
> - Use xilinx_wdt prefix in start/stop/keepalive functions
> and in new structures
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Hi Michal,
> static int xwdt_probe(struct platform_device *pdev)
> {
> int rc;
> @@ -314,7 +184,7 @@ static int xwdt_probe(struct platform_device *pdev)
> "xlnx,wdt-enable-once", NULL);
> if (tmptr == NULL) {
> pr_warn("Parameter \"xlnx,wdt-enable-once\" not found in device tree!\n");
> - xdev.nowayout = WATCHDOG_NOWAYOUT;
> + watchdog_set_nowayout(&xilinx_wdt_wdd, true);
Sure you want to set this to always true instead of using WATCHDOG_NOWAYOUT ?
Assuming this is what you want:
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Thanks,
Guenter
^ permalink raw reply
* [PATCH 02/10] watchdog: xilinx: Move control_status_reg to functions
From: Guenter Roeck @ 2014-02-09 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ca50a63f8e204043247268217f7981102da1e530.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> control_status_reg is temp variables and should be
> used locally by specific function.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [03/10] watchdog: xilinx: Simplify probe and remove functions
From: Guenter Roeck @ 2014-02-09 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <578455fd630e70b5de8bae6091568f05e7769057.1391177880.git.michal.simek@xilinx.com>
On Fri, Jan 31, 2014 at 10:18:12PM -0000, Michal Simek wrote:
> Use devm_ helper function to simplify probe and error path.
> Move ioremap to the beginning of probe function.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH 04/10] watchdog: xilinx: Move no_timeout to probe function
From: Guenter Roeck @ 2014-02-09 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8273bfbdf42dcd94f4e05a543de19b200f192e66.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> no_timeout should be local variable because it is used
> only in probe function.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH 05/10] watchdog: xilinx: Allocate private structure per device
From: Guenter Roeck @ 2014-02-09 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <255ff18dc52347e1bc8b0a0060eaa1037e02bdaa.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> Only one watchdog could be used by this driver.
> Create driver private data structure and move there
> all variables for one instance.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH 06/10] watchdog: xilinx: Fix all printk messages
From: Guenter Roeck @ 2014-02-09 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcb21f8907a2025371c612b818a0f2a04a2aa3af.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> Use dev_ functions for printk messages.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH 07/10] watchdog: xilinx: Fix OF binding
From: Guenter Roeck @ 2014-02-09 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26d172891694e4041e73b7dae85a1848adf38034.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> Use of_property_read_u32 functions to clean OF probing.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Arnd Bergmann @ 2014-02-09 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206203114.GW26684@n2100.arm.linux.org.uk>
On Thursday 06 February 2014, Russell King - ARM Linux wrote:
> On Thu, Feb 06, 2014 at 09:28:52AM +0100, Arnd Bergmann wrote:
> > It certainly seems workable. OTOH if we just manage to do a
> > helper that scans the OF ranges, allocates the I/O window,
> > remaps it and calls the existing pci_add_resource_offset()
> > helper, PCI host drivers don't need to worry about the
> > io_offsets computation either and just need to pull out the
> > correct window locations if they need to set up the hardware
> > translation windows (which I'd hope we can often let the boot
> > loader take care of).
...
> So, whenever you enumerate a PCI bus, and read the resource information
> out of the BARs, you must know how that address region specified in
> the BAR as a bus address maps to the host address space.
>
None of that contradicts what I wrote. Please try to understand what
I suggested, which is to have a common way to communicate that
information from DT to the PCI core without involving the PCI host
bridge driver.
All the bus scanning is done in common code, which already knows
how to factor in io_offset and mem_offset. The mem_offset can be
trivially computed from the ranges property, and the io_offset
is known by the time we call pci_ioremap_io() or rather a
replacement such as the one I proposed that also contains an
allocator.
Arnd
^ permalink raw reply
* [PATCH 08/10] watchdog: xilinx: Use correct comment indentation
From: Guenter Roeck @ 2014-02-09 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45680208de6e22a49fe8311d49877096ccd702af.1391177880.git.michal.simek@xilinx.com>
On 01/31/2014 06:18 AM, Michal Simek wrote:
> No functional changes.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Arnd Bergmann @ 2014-02-09 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140208142207.GR4993@e106497-lin.cambridge.arm.com>
On Saturday 08 February 2014, Liviu Dudau wrote:
> Yes, that parsing code of ranges is incorrect in light of the current discussion. I
> will try to propose a fix in the v2 series.
>
> Regarding your PCI IO range: if your bus address starts at 0x8000_0000, would
> that not cause problems with devices that use less than 32bits for address
> decoding? It is a rather unusual setup, I believe the x86 world (even PCI spec?)
> mandates IO bus ranges in the first 16MB of address range?
Actually even less than that. The common location of the I/O aperture is
0x0000-0xffff in bus space, which comes from the way the x86 instruction
set handles it. You can have larger bus addresses, but you can easily get
into trouble that way. One limitation is that the total I/O space size for
all buses combined is 2MB on arm32 (to be extended to 16MB on arm64 as
it stands right now), the other is that we probably have code assuming that
io_offset is a non-negative number, i.e. the bus address is equal or less
than the logial I/O port number, which in turn is limited to a few MB.
Arnd
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Arnd Bergmann @ 2014-02-09 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207114607.GE5976@mudshark.cambridge.arm.com>
On Friday 07 February 2014, Will Deacon wrote:
> On Wed, Feb 05, 2014 at 08:26:17PM +0000, Arnd Bergmann wrote:
> > On Wednesday 05 February 2014 19:09:47 Will Deacon wrote:
> > > On Tue, Feb 04, 2014 at 07:13:49PM +0000, Arnd Bergmann wrote:
> > If you mandate that, your code is actually correct and you do not
> > require an io_offset or mem_offset.
>
> Right, so that's what I've currently been relying on. If I mandate that,
> will I be making this driver significantly less useful?
After thinking about it some more, I think we should really try to
keep that logic completely out of the host controller driver and instead
make it generic enough to cover all possible cases.
Let's make sure that nobody ever has to call the range parser from
a PCI host driver again, no matter how weird their hardware setup is,
and put the necessary code in a common location. This will make your
driver even simpler.
> > * You might have multiple sections of the PCI bus space mapped
> > into CPU physical space. If you want to support legacy VGA
> > console, you probably want to map the first 16MB of the bus
> > space at an arbitrary location (with the mem_offset as above),
> > plus a second, larger section of the bus space with an identity
> > mapping (mem_offset_= 0) for all devices other than VGA.
> > You'd also need to copy some VGA specific code from arm32 to
> > arm64 to actually make this work.
>
> Again, I'd rather cross that bridge (no pun intended) when we decide we want
> legacy VGA.
Fair enough.
>
> > > > This shows once more that the range parser code is suboptimal. So far
> > > > every single driver got the I/O space wrong here, because the obvious
> > > > way to write this function is also completely wrong.
> > >
> > > I see you mentioned to Liviu that you should register a logical resource,
> > > rather than physical resource returned from the parser. It seems odd that
> > > I/O space appears to work with this code as-is (I've tested it on arm using
> > > kvmtool by removing the memory bars).
> >
> > what do you see in /proc/ioports and /proc/iomem then?
>
> bash-4.2# cat /proc/ioports
> 00006200-000065ff : virtio-pci
> 00006600-000069ff : virtio-pci
> 00006a00-00006dff : virtio-pci
> 00006e00-000071ff : virtio-pci
>
> bash-4.2# cat /proc/iomem
> 40000000-40ffffff : /pci
> 41000400-410005ff : virtio-pci
> 41000c00-41000dff : virtio-pci
> 41001400-410015ff : virtio-pci
> 41001c00-41001dff : virtio-pci
> 80000000-93ffffff : System RAM
> 80008000-8053df0b : Kernel code
> 80570000-805c07fb : Kernel data
You should normally see a parent resource for the PCI bus and the virtio-pci
resources under that. For some reason, neither of the two appears to have
been registered correctly.
Arnd
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Russell King - ARM Linux @ 2014-02-09 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402092118.19701.arnd@arndb.de>
On Sun, Feb 09, 2014 at 09:18:19PM +0100, Arnd Bergmann wrote:
> On Thursday 06 February 2014, Russell King - ARM Linux wrote:
> > On Thu, Feb 06, 2014 at 09:28:52AM +0100, Arnd Bergmann wrote:
> > > It certainly seems workable. OTOH if we just manage to do a
> > > helper that scans the OF ranges, allocates the I/O window,
> > > remaps it and calls the existing pci_add_resource_offset()
> > > helper, PCI host drivers don't need to worry about the
> > > io_offsets computation either and just need to pull out the
> > > correct window locations if they need to set up the hardware
> > > translation windows (which I'd hope we can often let the boot
> > > loader take care of).
>
> ...
>
> > So, whenever you enumerate a PCI bus, and read the resource information
> > out of the BARs, you must know how that address region specified in
> > the BAR as a bus address maps to the host address space.
> >
>
> None of that contradicts what I wrote. Please try to understand what
> I suggested, which is to have a common way to communicate that
> information from DT to the PCI core without involving the PCI host
> bridge driver.
Please explain it better then.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* OMAP baseline test results for v3.13
From: Paul Walmsley @ 2014-02-09 21:06 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.13.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.13/20140127101347/
Test summary
------------
Build: zImage:
Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only
Build: uImage+dtb:
Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone,
omap2plus_defconfig/omap4-panda,
omap2plus_defconfig/omap4-panda-es
Build: uImage:
Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig
Boot to userspace:
skip ( 2/ 2): 5912osk, 4460varsomom
Pass (10/10): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm,
37xxevm, 4430es2panda, 4460pandaes, am335xbone,
am335xbonelt, cmt3517
PM: chip retention via suspend:
skip ( 1/ 7): 4460varsomom
FAIL ( 2/ 7): 2430sdp, 4430es2panda
Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes
PM: chip retention via dynamic idle:
skip ( 1/ 7): 4460varsomom
FAIL ( 4/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 7): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
skip ( 1/ 5): 4460varsomom
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 5): 3530es3beagle
PM: chip off via dynamic idle:
skip ( 1/ 5): 4460varsomom
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 5): 3530es3beagle
vmlinux object size
(delta in bytes from test_v3.13-rc8 (7e22e91102c6b9df7c4ae2168910e19d2bb14cd6)):
text data bss total kernel
-20 0 0 -20 omap1_defconfig
-20 +8 0 -12 omap1_defconfig_1510innovator_only
-52 0 0 -52 omap1_defconfig_5912osk_only
+116 0 0 +116 omap2plus_defconfig
-44 0 0 -44 omap2plus_defconfig_2430sdp_only
+180 0 0 +180 omap2plus_defconfig_cpupm
-96 0 0 -96 omap2plus_defconfig_n800_multi_omap2xxx
-96 -8 0 -104 omap2plus_defconfig_n800_only_a
+180 0 0 +180 omap2plus_defconfig_no_pm
+116 0 0 +116 omap2plus_defconfig_omap2_4_only
+180 -8 0 +172 omap2plus_defconfig_omap3_4_only
+80 0 +16 +96 rmk_omap3430_ldp_allnoconfig
-32 -8 0 -40 rmk_omap3430_ldp_oldconfig
+180 0 +8 +188 rmk_omap4430_sdp_allnoconfig
+256 0 0 +256 rmk_omap4430_sdp_oldnoconfig
Boot-time memory difference
(delta in bytes from test_v3.13-rc8 (7e22e91102c6b9df7c4ae2168910e19d2bb14cd6))
avail rsrvd high freed board kconfig
(no differences)
The 4460 VAR-SOM-OM test failures have been reclassified as "skip" rather
than failures, to reflect my belief that these problems are due to a
failure of my local board rather than a software problem.
^ permalink raw reply
* [PATCH] ARM: mm: fix reporting of read-only PMD bits
From: Kees Cook @ 2014-02-09 22:06 UTC (permalink / raw)
To: linux-arm-kernel
On non-LPAE, read-only PMD bits are defined with the combination
"PMD_SECT_APX | PMD_SECT_AP_WRITE". Adjusted the bit masks to correctly
detect this.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/arm/mm/dump.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 2b3a56414271..1f7b1e13d945 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -123,19 +123,19 @@ static const struct prot_bits section_bits[] = {
#ifndef CONFIG_ARM_LPAE
/* These are approximate */
{
- .mask = PMD_SECT_AP_READ | PMD_SECT_AP_WRITE,
- .val = 0,
+ .mask = PMD_SECT_AP_READ | PMD_SECT_APX | PMD_SECT_AP_WRITE,
+ .val = PMD_SECT_APX | PMD_SECT_AP_WRITE,
.set = " ro",
}, {
- .mask = PMD_SECT_AP_READ | PMD_SECT_AP_WRITE,
+ .mask = PMD_SECT_AP_READ | PMD_SECT_APX | PMD_SECT_AP_WRITE,
.val = PMD_SECT_AP_WRITE,
.set = " RW",
}, {
- .mask = PMD_SECT_AP_READ | PMD_SECT_AP_WRITE,
+ .mask = PMD_SECT_AP_READ | PMD_SECT_APX | PMD_SECT_AP_WRITE,
.val = PMD_SECT_AP_READ,
.set = "USR ro",
}, {
- .mask = PMD_SECT_AP_READ | PMD_SECT_AP_WRITE,
+ .mask = PMD_SECT_AP_READ | PMD_SECT_APX | PMD_SECT_AP_WRITE,
.val = PMD_SECT_AP_READ | PMD_SECT_AP_WRITE,
.set = "USR RW",
#else
--
1.7.9.5
--
Kees Cook
Chrome OS Security
^ permalink raw reply related
* [PATCH] ARM: mm: report both sections from PMD
From: Kees Cook @ 2014-02-09 22:18 UTC (permalink / raw)
To: linux-arm-kernel
On 2-level page table systems, the PMD has 2 section entries. Report
these, otherwise ARM_PTDUMP will miss reporting permission changes on
odd section boundaries.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/arm/include/asm/pgtable-3level.h | 4 ----
arch/arm/include/asm/pgtable.h | 4 ++++
arch/arm/mm/dump.c | 3 +++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 03243f7eeddf..fb3de59ee811 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -138,10 +138,6 @@
#define pud_none(pud) (!pud_val(pud))
#define pud_bad(pud) (!(pud_val(pud) & 2))
#define pud_present(pud) (pud_val(pud))
-#define pmd_table(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
- PMD_TYPE_TABLE)
-#define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
- PMD_TYPE_SECT)
#define pmd_large(pmd) pmd_sect(pmd)
#define pud_clear(pudp) \
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 7d59b524f2af..934aa5b60c7c 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -183,6 +183,10 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
#define pmd_none(pmd) (!pmd_val(pmd))
#define pmd_present(pmd) (pmd_val(pmd))
+#define pmd_table(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
+ PMD_TYPE_TABLE)
+#define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
+ PMD_TYPE_SECT)
static inline pte_t *pmd_page_vaddr(pmd_t pmd)
{
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 1f7b1e13d945..ff1559f9200c 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -264,6 +264,9 @@ static void walk_pmd(struct pg_state *st, pud_t *pud, unsigned long start)
note_page(st, addr, 3, pmd_val(*pmd));
else
walk_pte(st, pmd, addr);
+
+ if (SECTION_SIZE < PMD_SIZE && pmd_sect(*pmd))
+ note_page(st, addr + SECTION_SIZE, 3, pmd_val(pmd[1]));
}
}
--
1.7.9.5
--
Kees Cook
Chrome OS Security
^ permalink raw reply related
* [PATCH 26/28] Remove LOCAL_TIMERS
From: Paul Bolle @ 2014-02-09 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-27-git-send-email-richard@nod.at>
On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
Orphaned a year ago, see commit 060f3043e5e ("ARM: smp: Remove local
timer API"). But this one got added after that, in the same relase
cycle.
> Signed-off-by: Richard Weinberger <richard@nod.at>
This gets my
Acked-by: Paul Bolle <pebolle@tiscali.nl>
as it's correct (we're dropping a nop) but I'd appreciate it if you'd
resend with the above info added. That would easy review by others too.
Paul Bolle
> arch/arm/mach-shmobile/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 3386406..c055388 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -8,7 +8,6 @@ config ARCH_SHMOBILE_MULTI
> select CPU_V7
> select GENERIC_CLOCKEVENTS
> select HAVE_ARM_SCU if SMP
> - select HAVE_ARM_TWD if LOCAL_TIMERS
> select HAVE_SMP
> select ARM_GIC
> select MIGHT_HAVE_CACHE_L2X0
^ permalink raw reply
* [PATCH 28/28] Remove LOCAL_TIMERS
From: Paul Bolle @ 2014-02-09 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-29-git-send-email-richard@nod.at>
On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
Merge with 26/28? Anyhow, my comments are basically identical to those
on that patch. So:
Acked-by: Paul Bolle <pebolle@tiscali.nl>
Paul Bolle
> arch/arm/mach-omap2/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 653b489..2817f1f 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -54,7 +54,6 @@ config SOC_OMAP5
> select ARM_GIC
> select CPU_V7
> select HAVE_ARM_SCU if SMP
> - select HAVE_ARM_TWD if LOCAL_TIMERS
> select HAVE_SMP
> select HAVE_ARM_ARCH_TIMER
> select ARM_ERRATA_798181 if SMP
^ permalink raw reply
* imx6qdl, weim ranges and gpr1
From: Philippe De Muyter @ 2014-02-10 0:15 UTC (permalink / raw)
To: linux-arm-kernel
Hello linux on i.mx6 experts,
on our i.mx6q/dl-based custom hardware we have used the weim interface to
connect some peripherals. Our weim dts description looks like that:
&weim {
compatible = "fsl,imx6q-weim";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_weim_sram_1>;
clocks = <&clks 196>;
reg = <0x021b8000 0x4000>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x04000000>, /* 64Mb for CS0 */
<1 0 0x0c000000 0x04000000>; /* 64Mb for CS1 */
status = "okay";
...
};
Actually, to achieve this mapping, I must configure some bits in IOMUXC_GPR1,
like that:
regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff, 0x1b);
Would it be possible to set the IOMUXC_GPR1 bits automagically, based on the
dts description ? Where should that go, in drivers/bus/imx-weim.c or in
arch/arm/mach-imx/mach-imx6q.c ? Also, I do not know how to retrieve
the 'ranges' property of the weim description.
Thanks in advance
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply
* [PATCH 0/7] Remove HAVE_PWM config option
From: Jingoo Han @ 2014-02-10 1:07 UTC (permalink / raw)
To: linux-arm-kernel
The HAVE_PWM symbol is only for legacy platforms that provide
the PWM API without using the generic framework, while PWM symbol
is used for PWM drivers using the generic PWM framework.
I looked at all HAVE_PWMs in the latest mainline kernel 3.14-rc1.
Three platforms are still using HAVE_PWM as below:
1. ARM - PXA
./arch/arm/mach-pxa/Kconfig
2. ARM - NXP LPC32XX
./arch/arm/Kconfig
config ARCH_LPC32XX
select HAVE_PWM
3. MIPS - Ingenic JZ4740 based machines
./arch/mips/Kconfig
config MACH_JZ4740
select HAVE_PWM
However, the legacy PWM drivers for PXA, LPC32XX, and JZ474 were
already moved to the generic PWM framework.
./drivers/pwm/pwm-pxa.c
./drivers/pwm/pwm-lpc32xx.c
./drivers/pwm/pwm-jz4740.c
In conclusion, HAVE_PWM should be removed, because HAVE_PWM is
NOT required anymore.
Jingoo Han (7):
ARM: pxa: don't select HAVE_PWM
ARM: lpc32xx: don't select HAVE_PWM
ARM: remove HAVE_PWM config option
MIPS: jz4740: don't select HAVE_PWM
Input: max8997_haptic: remove HAVE_PWM dependencies
Input: pwm-beepe: remove HAVE_PWM dependencies
pwm: don't use IS_ENABLED(CONFIG_HAVE_PWM)
arch/arm/Kconfig | 4 ----
arch/arm/mach-pxa/Kconfig | 15 ---------------
arch/mips/Kconfig | 1 -
drivers/input/misc/Kconfig | 4 ++--
include/linux/pwm.h | 2 +-
5 files changed, 3 insertions(+), 23 deletions(-)
I would like to merge these patches as below:
1. Through arm-soc tree
[PATCH 1/7] ARM: pxa: don't select HAVE_PWM
[PATCH 2/7] ARM: lpc32xx: don't select HAVE_PWM
[PATCH 3/7] ARM: remove HAVE_PWM config option
2. Through MIPS tree
[PATCH 4/7] MIPS: jz4740: don't select HAVE_PWM
3. Through Input tree
[PATCH 5/7] Input: max8997_haptic: remove HAVE_PWM dependencies
[PATCH 6/7] Input: pwm-beepe: remove HAVE_PWM dependencies
4. Through PWM tree
[PATCH 7/7] pwm: don't use IS_ENABLED(CONFIG_HAVE_PWM)
After merging these patches, all HAVE_PWM will be removed from
the mainline kernel. Thank you. :-)
Best regards,
Jingoo Han
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox