* 答复: [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support
From: liyi 00215672 @ 2014-07-22 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721084823.GA15666@arm.com>
Hi Will,
You need to add the SMBIOS support in UEFI on JUNO ,then you will get some proper information from DMI driver.
Thanks!
Yi
-----????-----
???: Will Deacon [mailto:will.deacon at arm.com]
????: 2014?7?21? 16:48
???: Ard Biesheuvel
??: Catalin Marinas; yi.li at linaro.org; liyi 00215672; grant.likely at linaro.org; leif.lindholm at linaro.org; linux-arm-kernel at lists.infradead.org; Mark Rutland
??: Re: [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support
On Sun, Jul 20, 2014 at 11:25:34AM +0100, Ard Biesheuvel wrote:
> On 14 July 2014 15:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 14 July 2014 15:36, Will Deacon <will.deacon@arm.com> wrote:
> >> On Fri, Jul 11, 2014 at 12:46:50PM +0100, Ard Biesheuvel wrote:
> >>> From: Yi Li <yi.li@linaro.org>
> >>>
> >>> SMbios is important for server hardware vendors. It implements a spec for
> >>> providing descriptive information about the platform. Things like serial
> >>> numbers, physical layout of the ports, build configuration data, and the like.
> >>>
> >>> This has been tested by dmidecode and lshw tools.
> >>>
> >>> Signed-off-by: Yi Li <yi.li@linaro.org>
> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>> ---
> >>> Changes since previous version:
> >>> - changed double inclusion guard to arm64 flavour
> >>> - use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
> >>> - do a sanity check on the size of the requested mapping
> >>
> >> Technically, this patch looks fine to me:
> >>
> >> Reviewed-by: Will Deacon <will.deacon@arm.com>
> >>
>
> Hello Catalin,
>
> This has been tested by Yi on FVP and Juno.
> Are you ok to take this?
Out of interest, how did you test it on Juno? I tried but got some messages
about missing/invalid DMI data or something similar. Leif reckons I need
some tricked out firmware for the FVP to get something working, but even
then the information is apparently bogus.
Will
^ permalink raw reply
* [PATCH v2 14/16] cpufreq: Add cpufreq driver for Tegra124
From: Rafael J. Wysocki @ 2014-07-22 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405957142-19416-15-git-send-email-ttynkkynen@nvidia.com>
On Monday, July 21, 2014 06:39:00 PM Tuomas Tynkkynen wrote:
> Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
> the CPU clocksource, switch immediately to the DFLL. It allows the use
> of higher clock rates, and will automatically scale the CPU voltage as
> well. Besides the CPU clocksource switch, we let the cpufreq-cpu0 driver
> for all the cpufreq operations.
>
> This driver also relies on the DFLL driver to fill the OPP table for the
> CPU0 device, so that the cpufreq-cpu0 driver knows what frequencies to
> use.
>
> This driver is a completely independent of the old cpufreq driver
> (tegra-cpufreq), which is only used on Tegra20.
>
> Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
I'm leaving this to Viresh. If he AKCs it for you, please feel free to push
this through whatever tree you think is appropriate.
> ---
> v2 changes:
> - use the cpufreq-cpu0 driver
>
> drivers/cpufreq/Kconfig.arm | 1 +
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/tegra124-cpufreq.c | 169 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 171 insertions(+)
> create mode 100644 drivers/cpufreq/tegra124-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 7364a53..df3c73e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -244,6 +244,7 @@ config ARM_SPEAR_CPUFREQ
> config ARM_TEGRA_CPUFREQ
> bool "TEGRA CPUFreq support"
> depends on ARCH_TEGRA
> + depends on GENERIC_CPUFREQ_CPU0
> default y
> help
> This adds the CPUFreq driver support for TEGRA SOCs.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index db6d9a2..3437d24 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
> obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA_CPUFREQ) += tegra-cpufreq.o
> +obj-$(CONFIG_ARM_TEGRA_CPUFREQ) += tegra124-cpufreq.o
> obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
>
> ##################################################################################
> diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
> new file mode 100644
> index 0000000..65ff428
> --- /dev/null
> +++ b/drivers/cpufreq/tegra124-cpufreq.c
> @@ -0,0 +1,169 @@
> +/*
> + * Tegra 124 cpufreq driver
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/clk.h>
> +#include <linux/cpufreq.h>
> +#include <linux/cpu.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/types.h>
> +
> +static struct cpufreq_frequency_table *freq_table;
> +
> +static struct device *cpu_dev;
> +static struct clk *cpu_clk;
> +static struct clk *pllp_clk;
> +static struct clk *pllx_clk;
> +static struct clk *dfll_clk;
> +
> +static int tegra124_cpu_switch_to_dfll(void)
> +{
> + struct clk *original_cpu_clk_parent;
> + unsigned long rate;
> + struct dev_pm_opp *opp;
> + int ret;
> +
> + rate = clk_get_rate(cpu_clk);
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> +
> + ret = clk_set_rate(dfll_clk, rate);
> + if (ret)
> + return ret;
> +
> + original_cpu_clk_parent = clk_get_parent(cpu_clk);
> + clk_set_parent(cpu_clk, pllp_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(dfll_clk);
> + if (ret)
> + goto out_switch_to_original_parent;
> +
> + clk_set_parent(cpu_clk, dfll_clk);
> +
> + return 0;
> +
> +out_switch_to_original_parent:
> + clk_set_parent(cpu_clk, original_cpu_clk_parent);
> +
> + return ret;
> +}
> +
> +static struct platform_device_info cpufreq_cpu0_devinfo = {
> + .name = "cpufreq-cpu0",
> +};
> +
> +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> +{
> + int ret;
> +
> + cpu_dev = get_cpu_device(0);
> + if (!cpu_dev)
> + return -ENODEV;
> +
> + cpu_clk = of_clk_get_by_name(cpu_dev->of_node, "cpu_g");
> + if (IS_ERR(cpu_clk))
> + return PTR_ERR(cpu_clk);
> +
> + dfll_clk = of_clk_get_by_name(cpu_dev->of_node, "dfll");
> + if (IS_ERR(dfll_clk)) {
> + ret = PTR_ERR(dfll_clk);
> + goto out_put_cpu_clk;
> + }
> +
> + pllx_clk = of_clk_get_by_name(cpu_dev->of_node, "pll_x");
> + if (IS_ERR(pllx_clk)) {
> + ret = PTR_ERR(pllx_clk);
> + goto out_put_dfll_clk;
> + }
> +
> + pllp_clk = of_clk_get_by_name(cpu_dev->of_node, "pll_p");
> + if (IS_ERR(pllp_clk)) {
> + ret = PTR_ERR(pllp_clk);
> + goto out_put_pllx_clk;
> + }
> +
> + ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> + if (ret)
> + goto out_put_pllp_clk;
> +
> + ret = tegra124_cpu_switch_to_dfll();
> + if (ret)
> + goto out_free_table;
> +
> + platform_device_register_full(&cpufreq_cpu0_devinfo);
> +
> + return 0;
> +
> +out_free_table:
> + dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
> +out_put_pllp_clk:
> + clk_put(pllp_clk);
> +out_put_pllx_clk:
> + clk_put(pllx_clk);
> +out_put_dfll_clk:
> + clk_put(dfll_clk);
> +out_put_cpu_clk:
> + clk_put(cpu_clk);
> +
> + return ret;
> +}
> +
> +static struct platform_driver tegra124_cpufreq_platdrv = {
> + .driver = {
> + .name = "cpufreq-tegra124",
> + .owner = THIS_MODULE,
> + },
> + .probe = tegra124_cpufreq_probe,
> +};
> +
> +static const struct of_device_id soc_of_matches[] = {
> + { .compatible = "nvidia,tegra124", },
> + {}
> +};
> +
> +static int __init tegra_cpufreq_init(void)
> +{
> + int ret;
> + struct platform_device *pdev;
> +
> + if (!of_find_matching_node(NULL, soc_of_matches))
> + return -ENODEV;
> +
> + ret = platform_driver_register(&tegra124_cpufreq_platdrv);
> + if (ret)
> + return ret;
> +
> + pdev = platform_device_register_simple("cpufreq-tegra124", -1, NULL, 0);
> + if (IS_ERR(pdev)) {
> + platform_driver_unregister(&tegra124_cpufreq_platdrv);
> + return PTR_ERR(pdev);
> + }
> +
> + return 0;
> +}
> +
> +MODULE_AUTHOR("Tuomas Tynkkynen <ttynkkynen@nvidia.com>");
> +MODULE_DESCRIPTION("cpufreq driver for nVIDIA Tegra124");
> +MODULE_LICENSE("GPLv2");
> +module_init(tegra_cpufreq_init);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH v8 00/13] Add Maxim 77802 PMIC support
From: Javier Martinez Canillas @ 2014-07-22 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722001053.GO17528@sirena.org.uk>
On 07/22/2014 02:10 AM, Mark Brown wrote:
> On Mon, Jul 21, 2014 at 02:44:07PM +0200, Javier Martinez Canillas wrote:
>> On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote:
>
>> Mark, Mike and Alessandro,
>
>> This is a gentle reminder to look at the patches that touches your subsystems
>> and provide acks if possible so Lee can merge the remainder set through the mfd
>> tree.
>
> Please stop nagging, you are chasing after only one week which is
> excessive for something that isn't an urgent bugfix (especially
> with a series like this that has had many rapid repins). Several weeks
> to a month would be more appropriate, and then resending the patches
> rather than sending contentless pings is more useful. Sending mails
> like this just means that people have more mail to read that isn't your
> patch, it is more likely to get you negative attention than positive -
> for example, I will tend to deprioritise things where I'm being chased
> too urgently as I do not wish to encourage such behaviour by being seen
> to reward it.
>
I didn't mean to bother you. It's true that it has been only a week since I
posted v8 of this series but I didn't have feedback for the clock, rtc and
regulator drivers since v5 which was posted on June, 26 so I thought that a ping
just to be sure it was not forgotten was not that bad. But sorry I won't do it
again and will just wait.
About the many re-spins, as most mfd drivers this PMIC support touches different
subsystems and the series had many patches so each time I had feedback for some
patches I prepared a new version and reposted the whole series. This doesn't
mean that all the patches changed from version to version though, some patches
have not changed for several revisions.
> In general I would recommend taking a step back, slowing down, and if
> you are not getting a response either thinking of something else to do
> in parallel or trying to do things that make it easier to accept your
> change if there are any (sometimes it's just a case of waiting). Look
> at how frequently the relevant maintainers tend to respond, at what the
> previous review comments have been and also consider the possibility
> that people might take holidays or just be busy.
>
Sorry, I didn't mean to imply that you are not busy or might be on holidays. I
guess I just got anxious due the merge window being close...
Best regards,
Javier
^ permalink raw reply
* [PATCH v7 8/9] ARM: vdso initialization, mapping, and synchronization
From: Andy Lutomirski @ 2014-07-22 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140702185422.GP24879@arm.com>
On Wed, Jul 2, 2014 at 11:54 AM, Will Deacon <will.deacon@arm.com> wrote:
> Cheers for this, Andy.
>
> On Wed, Jul 02, 2014 at 07:34:22PM +0100, Andy Lutomirski wrote:
>> On Wed, Jul 2, 2014 at 10:24 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > ELF Header:
>> > Start of section headers: 1888 (bytes into file)
>> > Size of section headers: 64 (bytes)
>> > Number of section headers: 14
>>
>> That's 896 bytes for the section table, starting at offset 1888.
>>
>> > Section header string table index: 13
>>
>>
>> >
>> > Section Headers:
>> > [13] .shstrtab STRTAB 0000000000000000 000006e8
>> > 0000000000000078 0000000000000000 0 0 1
>>
>> 120 bytes of section headers strings, starting at offset 1768 (and not
>> allocatable -- no 'A' here).
>>
>> >
>> > Program Headers:
>> > Type Offset VirtAddr PhysAddr
>> > FileSiz MemSiz Flags Align
>> > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
>> > 0x00000000000006e8 0x00000000000006e8 R E 10
>>
>> The loadable segment is 1768 bytes long, starting at the beginning of
>> the file (and therefore the beginning of the mapping).
>>
>> So you have a total of 1016 bytes of non-allocatable stuff at the end
>> that I've accounted for. I assume that the whole file is 2784 bytes.
>
> Correct.
>
>> If you added text or data to bring PT_LOAD to between 3081 and 4095
>> bytes, then the section headers and/or section string table would
>> cross a page boundary.
>
> Ok, so that explains why things are working at the moment and it sounds like
> we have some wiggle room too. I'll look at moving the datapage anyway, since
> having these artificial limits is error-prone and fragile, but I don't think
> it's something we need to panic about immediately.
>
> Also, if you get to the bottom of your binutils issues with the section
> allocation, that might work for us since we don't really have any legacy
> binutils supporting arm64.
Just in case anyone still cares about this thread, moving the vvar
area back before the vdso text is queued up for 3.17. I gave up on
reliably keeping binutils happy with my ugly hack.
--Andy
^ permalink raw reply
* [PATCH 0/6] vf610: Add USB support
From: Peter Chen @ 2014-07-22 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405702442.git.stefan@agner.ch>
On Fri, Jul 18, 2014 at 07:01:36PM +0200, Stefan Agner wrote:
> This patchset adds USB support for Vybrid VF610 SoC. It extends the
> clock framework to support the USB PHY cocks, extends the device
> tree files and adds support for the non-core registers in the
> usbmisc_imx driver.
>
> This patchset needs the eSDHC length fix available in Shawn's
> for-next branch.
>
Why it is related to USB patchset?
> The whole patchset proved to be working on a Colibri VF61. The
> first USB controller runs in peripheral mode. I could successfully
> use RNDIS, however with some stability issues: Suddenly the other
> side was not reachable anymore and the interface needed to brought
> down and back up again. I'm still investigating this.
Do you use ubuntu as host distribution? I find ubuntu will lost the
first connection for usb-ethernet-gadget(usb0) as network interface,
but once you re-config usb0 again (ifconfig usb0 ip up), it should work
and will not lose connection any more.
>
> The second USB controller, running in USB host mode, showed no
> issues so far.
>
> Stefan Agner (6):
> ARM: dts: vf610: add USB PHY and controller
> ARM: imx: clk-vf610: add USBPHY clocks
> ARM: dts: vf610: Add usbmisc for non-core registers
> chipidea: usbmisc_imx: Add USB support for VF610 SoCs
> usb: phy: mxs: Add VF610 USB PHY support
> ARM: dts: vf610-colibri: add USB support
>
> arch/arm/boot/dts/vf610-colibri.dts | 10 +++++
> arch/arm/boot/dts/vf610.dtsi | 55 ++++++++++++++++++++++--
> arch/arm/mach-imx/clk-vf610.c | 12 +++++-
> drivers/usb/chipidea/usbmisc_imx.c | 76 +++++++++++++++++++++++----------
> drivers/usb/phy/phy-mxs-usb.c | 5 +++
> include/dt-bindings/clock/vf610-clock.h | 5 ++-
> 6 files changed, 135 insertions(+), 28 deletions(-)
>
> --
> 2.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v8 00/13] Add Maxim 77802 PMIC support
From: Mark Brown @ 2014-07-22 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CD0B17.5040706@collabora.co.uk>
On Mon, Jul 21, 2014 at 02:44:07PM +0200, Javier Martinez Canillas wrote:
> On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote:
> Mark, Mike and Alessandro,
> This is a gentle reminder to look at the patches that touches your subsystems
> and provide acks if possible so Lee can merge the remainder set through the mfd
> tree.
Please stop nagging, you are chasing after only one week which is
excessive for something that isn't an urgent bugfix (especially
with a series like this that has had many rapid repins). Several weeks
to a month would be more appropriate, and then resending the patches
rather than sending contentless pings is more useful. Sending mails
like this just means that people have more mail to read that isn't your
patch, it is more likely to get you negative attention than positive -
for example, I will tend to deprioritise things where I'm being chased
too urgently as I do not wish to encourage such behaviour by being seen
to reward it.
In general I would recommend taking a step back, slowing down, and if
you are not getting a response either thinking of something else to do
in parallel or trying to do things that make it easier to accept your
change if there are any (sometimes it's just a case of waiting). Look
at how frequently the relevant maintainers tend to respond, at what the
previous review comments have been and also consider the possibility
that people might take holidays or just be busy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/d23818bb/attachment-0001.sig>
^ permalink raw reply
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
From: Matthew Longnecker @ 2014-07-21 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403856699-2140-5-git-send-email-mperttunen@nvidia.com>
On 6/27/2014 1:11 AM, Mikko Perttunen wrote:
> This adds the soctherm thermal sensing and management unit to the
> Tegra124 device tree along with the four thermal zones it exports.
Mikko, soctherm doesn't "export thermal zones". I would rewrite your
desription like this:
Extend the Tegra124 device tree by adding the soctherm thermal
sensing and management unit and by defining four thermal zones --
one for each temperature sensor in soctherm.
System integrators have some flexibility in deciding how many thermal
zones to define for their platform. For example, an integrator could
define a single zone for the entire Tegra chip (giving a simple system
at runtime) or with multiple zones (giving potentially higher
performance near thermal limits). That's why I don't like the
implication that soctherm dictates the existence of particular thermal
zones.
-Matt
^ permalink raw reply
* [PATCH v6 3/7] arm64: kernel: introduce cpu_init_idle CPU operation
From: Stephen Boyd @ 2014-07-21 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405958786-17243-4-git-send-email-lorenzo.pieralisi@arm.com>
On 07/21/14 09:06, Lorenzo Pieralisi wrote:
> diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
> new file mode 100644
> index 0000000..46eb3ea
> --- /dev/null
> +++ b/arch/arm64/kernel/cpuidle.c
> @@ -0,0 +1,27 @@
> +/*
> + * ARM64 CPU idle arch support
> + *
> + * Copyright (C) 2014 ARM Ltd.
> + * Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <asm/cpu_ops.h>
> +
> +int cpu_init_idle(unsigned int cpu)
sparse will probably complain here unless we include <asm/cpuidle.h> right?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 4/4] (RFC) X86: add IPI tracepoints
From: Steven Rostedt @ 2014-07-21 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1407181656160.3647@knanqh.ubzr>
On Fri, 18 Jul 2014 16:59:50 -0400 (EDT)
Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 18 Jul 2014, Steven Rostedt wrote:
>
> > On Fri, 18 Jul 2014 01:18:55 -0400
> > Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >
> >
> > > diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> > > index be8e1bde07..e154d176cf 100644
> > > --- a/arch/x86/kernel/smp.c
> > > +++ b/arch/x86/kernel/smp.c
> > > @@ -31,6 +31,12 @@
> > > #include <asm/apic.h>
> > > #include <asm/nmi.h>
> > > #include <asm/trace/irq_vectors.h>
> > > +
> > > +#define CREATE_TRACE_POINTS
> > > +#undef TRACE_INCLUDE_PATH
> > > +#undef TRACE_INCLUDE_FILE
> >
> > I'm curious to why you added the #undefs. I wouldn't think they were
> > needed.
>
> They are needed because asm/trace/irq_vectors.h included prior that
> point defines them for itself and that makes the inclusion of
> trace/events/ipi.h fail.
>
Bah, I tried to get rid of the need for those, but it seems that the
macro magic is getting a bit out of hand. I need a new macro magic
hat :-p
What you got here will have to do.
-- Steve
^ permalink raw reply
* [PATCH 5/8] of: Add Tegra124 EMC bindings
From: Andrew Bresticker @ 2014-07-21 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CD860B.7030800@wwwdotorg.org>
On Mon, Jul 21, 2014 at 2:28 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/11/2014 10:43 AM, Andrew Bresticker wrote:
>> On Fri, Jul 11, 2014 at 7:18 AM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
>>> Add binding documentation for the nvidia,tegra124-emc device tree
>>> node.
>>
>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
>>
>>> +Required properties :
>>> +- compatible : "nvidia,tegra124-emc".
>>> +- reg : Should contain 1 or 2 entries:
>>> + - EMC register set
>>> + - MC register set : Required only if no node with
>>> + 'compatible = "nvidia,tegra124-mc"' exists. The MC register set
>>> + is first read from the MC node. If it doesn't exist, it is read
>>> + from this property.
>>> +- timings : Should contain 1 entry for each supported clock rate.
>>> + Entries should be named "timing at n" where n is a 0-based increasing
>>> + number. The timings must be listed in rate-ascending order.
>>
>> There are upcoming boards which support multiple DRAM configurations
>> and require a separate set of timings for each configuration. Could
>> we instead have multiple sets of timings with the proper one selected
>> at runtime by RAM code, as reported by PMC_STRAPPING_OPT_A_0?
>> Something like:
>>
>> emc {
>> emc-table at 0 {
>> nvidia,ram-code = <0>;
>> timing at 0 {
>> ...
>> };
>> ...
>> };
>
> Until recently, there was a binding for Tegra20 EMC in mainline. We
> should make sure the Tegra124 driver (or rather binding...) is at least
> as feature-ful as that was.
>
> Furthermore, I thought that with some boards, there were more RAM
> options that there were available RAM code strap bits. I assume that in
> mainline, we'll simply have different base DT files for the different
> sets of configurations? Or, will we want to add another level to the DT
> to represent different sets of RAM code values? I'm not sure what data
> source the bootloader uses to determine which set of RAM configuration
> to use when there aren't enough entries in the BCT for the boot ROM to
> do this automatically, and whether we have any way to get that value
> into the kernel, so it could use it for the extra DT level lookup?
For the ChromeOS boards at least we are neither limited by the number
of strapping bits (4) nor the number of BCT entries supported by the
boot ROM (since coreboot does not rely on the boot ROM for SDRAM
initialization), so having a single set of SDRAM configurations for
each board, indexed by APBDEV_PMC_STRAPPING_OPT_A_0[7:4] works just
fine. Not sure how boards which do use the boot ROM for SDRAM
initialization handle the BCT limitation. I believe we considered
using more board ID strapping bits in order to map the RAM codes to
sets of configurations before switching to having coreboot do SDRAM
initialization.
^ permalink raw reply
* [PATCH v6 1/7] Documentation: arm: define DT idle states bindings
From: Nicolas Pitre @ 2014-07-21 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405958786-17243-2-git-send-email-lorenzo.pieralisi@arm.com>
On Mon, 21 Jul 2014, Lorenzo Pieralisi wrote:
> ARM based platforms implement a variety of power management schemes that
> allow processors to enter idle states at run-time.
> The parameters defining these idle states vary on a per-platform basis forcing
> the OS to hardcode the state parameters in platform specific static tables
> whose size grows as the number of platforms supported in the kernel increases
> and hampers device drivers standardization.
>
> Therefore, this patch aims at standardizing idle state device tree bindings
> for ARM platforms. Bindings define idle state parameters inclusive of entry
> methods and state latencies, to allow operating systems to retrieve the
> configuration entries from the device tree and initialize the related power
> management drivers, paving the way for common code in the kernel to deal with
> idle states and removing the need for static data in current and previous
> kernel versions.
>
> ARM64 platforms require the DT to define an entry-method property
> for idle states.
>
> On system implementing PSCI as an enable-method to enter low-power
> states the PSCI CPU suspend method requires the power_state parameter to
> be passed to the PSCI CPU suspend function.
>
> This parameter is specific to a power state and platform specific,
> therefore must be provided by firmware to the OS in order to enable
> proper call sequence.
>
> Thus, this patch also adds a property in the PSCI bindings that
> describes how the PSCI CPU suspend power_state parameter should be
> defined in DT in all device nodes that rely on PSCI CPU suspend method usage.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 8 +
> .../devicetree/bindings/arm/idle-states.txt | 679 +++++++++++++++++++++
> Documentation/devicetree/bindings/arm/psci.txt | 14 +-
> 3 files changed, 700 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/idle-states.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 1fe72a0..a44d4fd 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -215,6 +215,12 @@ nodes to be present and contain the properties described below.
> Value type: <phandle>
> Definition: Specifies the ACC[2] node associated with this CPU.
>
> + - cpu-idle-states
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition:
> + # List of phandles to idle state nodes supported
> + by this cpu [3].
>
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> @@ -411,3 +417,5 @@ cpus {
> --
> [1] arm/msm/qcom,saw2.txt
> [2] arm/msm/qcom,kpss-acc.txt
> +[3] ARM Linux kernel documentation - idle states bindings
> + Documentation/devicetree/bindings/arm/idle-states.txt
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
> new file mode 100644
> index 0000000..37375c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -0,0 +1,679 @@
> +==========================================
> +ARM idle states binding description
> +==========================================
> +
> +==========================================
> +1 - Introduction
> +==========================================
> +
> +ARM systems contain HW capable of managing power consumption dynamically,
> +where cores can be put in different low-power states (ranging from simple
> +wfi to power gating) according to OS PM policies. The CPU states representing
> +the range of dynamic idle states that a processor can enter at run-time, can be
> +specified through device tree bindings representing the parameters required
> +to enter/exit specific idle states on a given processor.
> +
> +According to the Server Base System Architecture document (SBSA, [3]), the
> +power states an ARM CPU can be put into are identified by the following list:
> +
> +- Running
> +- Idle_standby
> +- Idle_retention
> +- Sleep
> +- Off
> +
> +The power states described in the SBSA document define the basic CPU states on
> +top of which ARM platforms implement power management schemes that allow an OS
> +PM implementation to put the processor in different idle states (which include
> +states listed above; "off" state is not an idle state since it does not have
> +wake-up capabilities, hence it is not considered in this document).
> +
> +Idle state parameters (eg entry latency) are platform specific and need to be
> +characterized with bindings that provide the required information to OS PM
> +code so that it can build the required tables and use them at runtime.
> +
> +The device tree binding definition for ARM idle states is the subject of this
> +document.
> +
> +===========================================
> +2 - idle-states definitions
> +===========================================
> +
> +Idle states are characterized for a specific system through a set of
> +timing and energy related properties, that underline the HW behaviour
> +triggered upon idle states entry and exit.
> +
> +The following diagram depicts the CPU execution phases and related timing
> +properties required to enter and exit an idle state:
> +
> +..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
> + | | | | |
> +
> + |<------ entry ------->|
> + | latency |
> + |<- exit ->|
> + | latency |
> + |<-------- min-residency -------->|
> + |<------- wakeup-latency ------->|
> +
> + Diagram 1: CPU idle state execution phases
> +
> +EXEC: Normal CPU execution.
> +
> +PREP: Preparation phase before committing the hardware to idle mode
> + like cache flushing. This is abortable on pending wake-up
> + event conditions. The abort latency is assumed to be negligible
> + (i.e. less than the ENTRY + EXIT duration). If aborted, CPU
> + goes back to EXEC. This phase is optional. If not abortable,
> + this should be included in the ENTRY phase instead.
> +
> +ENTRY: The hardware is committed to idle mode. This period must run
> + to completion up to IDLE before anything else can happen.
> +
> +IDLE: This is the actual energy-saving idle period. This may last
> + between 0 and infinite time, until a wake-up event occurs.
> +
> +EXIT: Period during which the CPU is brought back to operational
> + mode (EXEC).
> +
> +entry-latency: Worst case latency required to enter the idle state. The
> +exit-latency may be guaranteed only after entry-latency has passed.
> +
> +min-residency: Minimum period, including preparation and entry, for a given
> +idle state to be worthwhile energywise.
> +
> +wakeup-latency: Maximum delay between the signaling of a wake-up event and the
> +CPU being able to execute normal code again. If not specified, this is assumed
> +to be entry-latency + exit-latency.
> +
> +These timing parameters can be used by an OS in different circumstances.
> +
> +An idle CPU requires the expected min-residency time to select the most
> +appropriate idle state based on the expected expiry time of the next IRQ
> +(ie wake-up) that causes the CPU to return to the EXEC phase.
> +
> +An operating system scheduler may need to compute the shortest wake-up delay
> +for CPUs in the system by detecting how long will it take to get a CPU out
> +of an idle state, eg:
> +
> +wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
> +
> +In other words, the scheduler can make its scheduling decision by selecting
> +(eg waking-up) the CPU with the shortest wake-up latency.
> +The wake-up latency must take into account the entry latency if that period
> +has not expired. The abortable nature of the PREP period can be ignored
> +if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
> +the worst case since it depends on the CPU operating conditions, ie caches
> +state).
> +
> +An OS has to reliably probe the wakeup-latency since some devices can enforce
> +latency constraints guarantees to work properly, so the OS has to detect the
> +worst case wake-up latency it can incur if a CPU is allowed to enter an
> +idle state, and possibly to prevent that to guarantee reliable device
> +functioning.
> +
> +The min-residency time parameter deserves further explanation since it is
> +expressed in time units but must factor in energy consumption coefficients.
> +
> +The energy consumption of a cpu when it enters a power state can be roughly
> +characterised by the following graph:
> +
> + |
> + |
> + |
> + e |
> + n | /---
> + e | /------
> + r | /------
> + g | /-----
> + y | /------
> + | ----
> + | /|
> + | / |
> + | / |
> + | / |
> + | / |
> + | / |
> + |/ |
> + -----|-------+----------------------------------
> + 0| 1 time(ms)
> +
> + Graph 1: Energy vs time example
> +
> +The graph is split in two parts delimited by time 1ms on the X-axis.
> +The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
> +and denotes the energy costs incurred whilst entering and leaving the idle
> +state.
> +The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
> +shallower slope and essentially represents the energy consumption of the idle
> +state.
> +
> +min-residency is defined for a given idle state as the minimum expected
> +residency time for a state (inclusive of preparation and entry) after
> +which choosing that state become the most energy efficient option. A good
> +way to visualise this, is by taking the same graph above and comparing some
> +states energy consumptions plots.
> +
> +For sake of simplicity, let's consider a system with two idle states IDLE1,
> +and IDLE2:
> +
> + |
> + |
> + |
> + | /-- IDLE1
> + e | /---
> + n | /----
> + e | /---
> + r | /-----/--------- IDLE2
> + g | /-------/---------
> + y | ------------ /---|
> + | / /---- |
> + | / /--- |
> + | / /---- |
> + | / /--- |
> + | --- |
> + | / |
> + | / |
> + |/ | time
> + ---/----------------------------+------------------------
> + |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
> + |
> + IDLE2-min-residency
> +
> + Graph 2: idle states min-residency example
> +
> +In graph 2 above, that takes into account idle states entry/exit energy
> +costs, it is clear that if the idle state residency time (ie time till next
> +wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
> +choice energywise.
> +
> +This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
> +than IDLE2.
> +
> +However, the lower power consumption (ie shallower energy curve slope) of idle
> +state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
> +efficient.
> +
> +The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
> +shallower states in a system with multiple idle states) is defined
> +IDLE2-min-residency and corresponds to the time when energy consumption of
> +IDLE1 and IDLE2 states breaks even.
> +
> +The definitions provided in this section underpin the idle states
> +properties specification that is the subject of the following sections.
> +
> +===========================================
> +3 - idle-states node
> +===========================================
> +
> +ARM processor idle states are defined within the idle-states node, which is
> +a direct child of the cpus node [1] and provides a container where the
> +processor idle states, defined as device tree nodes, are listed.
> +
> +- idle-states node
> +
> + Usage: Optional - On ARM systems, it is a container of processor idle
> + states nodes. If the system does not provide CPU
> + power management capabilities or the processor just
> + supports idle_standby an idle-states node is not
> + required.
> +
> + Description: idle-states node is a container node, where its
> + subnodes describe the CPU idle states.
> +
> + Node name must be "idle-states".
> +
> + The idle-states node's parent node must be the cpus node.
> +
> + The idle-states node's child nodes can be:
> +
> + - one or more state nodes
> +
> + Any other configuration is considered invalid.
> +
> + An idle-states node defines the following properties:
> +
> + - entry-method
> + Value type: <stringlist>
> + Usage and definition depend on ARM architecture version.
> + # On ARM v8 64-bit this property is required and must
> + be one of:
> + - "psci" (see bindings in [2])
> + # On ARM 32-bit systems this property is optional
> +
> +The nodes describing the idle states (state) can only be defined within the
> +idle-states node, any other configuration is considered invalid and therefore
> +must be ignored.
> +
> +===========================================
> +4 - state node
> +===========================================
> +
> +A state node represents an idle state description and must be defined as
> +follows:
> +
> +- state node
> +
> + Description: must be child of the idle-states node
> +
> + The state node name shall follow standard device tree naming
> + rules ([5], 2.2.1 "Node names"), in particular state nodes which
> + are siblings within a single common parent must be given a unique name.
> +
> + The idle state entered by executing the wfi instruction (idle_standby
> + SBSA,[3][4]) is considered standard on all ARM platforms and therefore
> + must not be listed.
> +
> + With the definitions provided above, the following list represents
> + the valid properties for a state node:
> +
> + - compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must be "arm,idle-state".
> +
> + - local-timer-stop
> + Usage: See definition
> + Value type: <none>
> + Definition: if present the CPU local timer control logic is
> + lost on state entry, otherwise it is retained.
> +
> + - entry-latency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency in
> + microseconds required to enter the idle state.
> + The exit-latency-us duration may be guaranteed
> + only after entry-latency-us has passed.
> +
> + - exit-latency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to exit the idle state.
> +
> + - min-residency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing minimum residency duration
> + in microseconds, inclusive of preparation and
> + entry, for this idle state to be considered
> + worthwhile energy wise (refer to section 2 of
> + this document for a complete description).
> +
> + - wakeup-latency-us:
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing maximum delay between the
> + signaling of a wake-up event and the CPU being
> + able to execute normal code again. If omitted,
> + this is assumed to be equal to:
> +
> + entry-latency-us + exit-latency-us
> +
> + It is important to supply this value on systems
> + where the duration of PREP phase (see diagram 1,
> + section 2) is non-neglibigle.
> + In such systems entry-latency-us + exit-latency-us
> + will exceed wakeup-latency-us by this duration.
> +
> + In addition to the properties listed above, a state node may require
> + additional properties specifics to the entry-method defined in the
> + idle-states node, please refer to the entry-method bindings
> + documentation for properties definitions.
> +
> +===========================================
> +4 - Examples
> +===========================================
> +
> +Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x1>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU2: cpu at 100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU3: cpu at 101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x101>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU4: cpu at 10000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10000>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU5: cpu at 10001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10001>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU6: cpu at 10100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU7: cpu at 10101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10101>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU8: cpu at 100000000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x0>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU9: cpu at 100000001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x1>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU10: cpu at 100000100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU11: cpu at 100000101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x101>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU12: cpu at 100010000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10000>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU13: cpu at 100010001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10001>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU14: cpu at 100010100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU15: cpu at 100010101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10101>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
> + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
> + };
> +
> + idle-states {
> + entry-method = "arm,psci";
> +
> + CPU_RETENTION_0_0: cpu-retention-0-0 {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x0010000>;
> + entry-latency-us = <20>;
> + exit-latency-us = <40>;
> + min-residency-us = <80>;
> + };
> +
> + CLUSTER_RETENTION_0: cluster-retention-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x1010000>;
> + entry-latency-us = <50>;
> + exit-latency-us = <100>;
> + min-residency-us = <250>;
> + wakeup-latency-us = <130>;
> + };
> +
> + CPU_SLEEP_0_0: cpu-sleep-0-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x0010000>;
> + entry-latency-us = <250>;
> + exit-latency-us = <500>;
> + min-residency-us = <950>;
> + };
> +
> + CLUSTER_SLEEP_0: cluster-sleep-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x1010000>;
> + entry-latency-us = <600>;
> + exit-latency-us = <1100>;
> + min-residency-us = <2700>;
> + wakeup-latency-us = <1500>;
> + };
> +
> + CPU_RETENTION_1_0: cpu-retention-1-0 {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x0010000>;
> + entry-latency-us = <20>;
> + exit-latency-us = <40>;
> + min-residency-us = <90>;
> + };
> +
> + CLUSTER_RETENTION_1: cluster-retention-1 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x1010000>;
> + entry-latency-us = <50>;
> + exit-latency-us = <100>;
> + min-residency-us = <270>;
> + wakeup-latency-us = <100>;
> + };
> +
> + CPU_SLEEP_1_0: cpu-sleep-1-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x0010000>;
> + entry-latency-us = <70>;
> + exit-latency-us = <100>;
> + min-residency-us = <300>;
> + wakeup-latency-us = <150>;
> + };
> +
> + CLUSTER_SLEEP_1: cluster-sleep-1 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x1010000>;
> + entry-latency-us = <500>;
> + exit-latency-us = <1200>;
> + min-residency-us = <3500>;
> + wakeup-latency-us = <1300>;
> + };
> + };
> +
> +};
> +
> +Example 2 (ARM 32-bit, 8-cpu system, two clusters):
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <1>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x0>;
> + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x1>;
> + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU2: cpu at 2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x2>;
> + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU3: cpu at 3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x3>;
> + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
> + };
> +
> + CPU4: cpu at 100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x100>;
> + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU5: cpu at 101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x101>;
> + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU6: cpu at 102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x102>;
> + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
> + };
> +
> + CPU7: cpu at 103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x103>;
> + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
> + };
> +
> + idle-states {
> + CPU_SLEEP_0_0: cpu-sleep-0-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + entry-latency-us = <200>;
> + exit-latency-us = <100>;
> + min-residency-us = <400>;
> + wakeup-latency-us = <250>;
> + };
> +
> + CLUSTER_SLEEP_0: cluster-sleep-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + entry-latency-us = <500>;
> + exit-latency-us = <1500>;
> + min-residency-us = <2500>;
> + wakeup-latency-us = <1700>;
> + };
> +
> + CPU_SLEEP_1_0: cpu-sleep-1-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + entry-latency-us = <300>;
> + exit-latency-us = <500>;
> + min-residency-us = <900>;
> + wakeup-latency-us = <600>;
> + };
> +
> + CLUSTER_SLEEP_1: cluster-sleep-1 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + entry-latency-us = <800>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6500>;
> + wakeup-latency-us = <2300>;
> + };
> + };
> +
> +};
> +
> +===========================================
> +5 - References
> +===========================================
> +
> +[1] ARM Linux Kernel documentation - CPUs bindings
> + Documentation/devicetree/bindings/arm/cpus.txt
> +
> +[2] ARM Linux Kernel documentation - PSCI bindings
> + Documentation/devicetree/bindings/arm/psci.txt
> +
> +[3] ARM Server Base System Architecture (SBSA)
> + http://infocenter.arm.com/help/index.jsp
> +
> +[4] ARM Architecture Reference Manuals
> + http://infocenter.arm.com/help/index.jsp
> +
> +[5] ePAPR standard
> + https://www.power.org/documentation/epapr-version-1-1/
> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> index b4a58f3..5aa40ed 100644
> --- a/Documentation/devicetree/bindings/arm/psci.txt
> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> @@ -50,6 +50,16 @@ Main node optional properties:
>
> - migrate : Function ID for MIGRATE operation
>
> +Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
> +state nodes, as per bindings in [1]) must specify the following properties:
> +
> +- arm,psci-suspend-param
> + Usage: Required for state nodes[1] if the corresponding
> + idle-states node entry-method property is set
> + to "psci".
> + Value type: <u32>
> + Definition: power_state parameter to pass to the PSCI
> + suspend call.
>
> Example:
>
> @@ -64,7 +74,6 @@ Case 1: PSCI v0.1 only.
> migrate = <0x95c10003>;
> };
>
> -
> Case 2: PSCI v0.2 only
>
> psci {
> @@ -88,3 +97,6 @@ Case 3: PSCI v0.2 and PSCI v0.1.
>
> ...
> };
> +
> +[1] Kernel documentation - ARM idle states bindings
> + Documentation/devicetree/bindings/arm/idle-states.txt
> --
> 1.9.1
>
>
>
^ permalink raw reply
* [PATCH 2/8] ARM: tegra: Remove TEGRA124_CLK_EMC from tegra124-car.h
From: Stephen Warren @ 2014-07-21 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405088313-20048-3-git-send-email-mperttunen@nvidia.com>
On 07/11/2014 08:18 AM, Mikko Perttunen wrote:
> Remove the TEGRA124_CLK_EMC cell value define for tegra124-car
> from the binding headers. This clock has never been able to do
> anything and is being replaced with a separate EMC driver with
> its own device tree node. Removing the define ensures that any
> user will not mistakenly refer to <&tegra_car TEGRA124_CLK_EMC>
> instead of <&emc> or similar.
If the clock physically exists in HW, I see no reason to remove it from
the binding definition, even if we don't implement it (or remove the
implementation of it) in the Linux clock driver.
^ permalink raw reply
* [PATCHv4 5/5] arm64: Add atomic pool for non-coherent and CMA allocations.
From: Laura Abbott @ 2014-07-21 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718134343.GA4608@arm.com>
On 7/18/2014 6:43 AM, Catalin Marinas wrote:
> On Wed, Jul 02, 2014 at 07:03:38PM +0100, Laura Abbott wrote:
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 4164c5a..a2487f1 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
> [...]
>> static void *__dma_alloc_coherent(struct device *dev, size_t size,
>> dma_addr_t *dma_handle, gfp_t flags,
>> struct dma_attrs *attrs)
>> @@ -53,7 +103,8 @@ static void *__dma_alloc_coherent(struct device *dev, size_t size,
>> if (IS_ENABLED(CONFIG_ZONE_DMA) &&
>> dev->coherent_dma_mask <= DMA_BIT_MASK(32))
>> flags |= GFP_DMA;
>> - if (IS_ENABLED(CONFIG_DMA_CMA)) {
>> +
>> + if (!(flags & __GFP_WAIT) && IS_ENABLED(CONFIG_DMA_CMA)) {
>> struct page *page;
>>
>> size = PAGE_ALIGN(size);
>
> I think that's the wrong condition here. You want to use CMA if
> (flags & __GFP_WAIT). CMA does not support atomic allocations so it can
> fall back to swiotlb_alloc_coherent().
>
>> @@ -73,50 +124,56 @@ static void __dma_free_coherent(struct device *dev, size_t size,
>> void *vaddr, dma_addr_t dma_handle,
>> struct dma_attrs *attrs)
>> {
>> + bool freed;
>> + phys_addr_t paddr = dma_to_phys(dev, dma_handle);
>> +
>> if (dev == NULL) {
>> WARN_ONCE(1, "Use an actual device structure for DMA allocation\n");
>> return;
>> }
>>
>> - if (IS_ENABLED(CONFIG_DMA_CMA)) {
>> - phys_addr_t paddr = dma_to_phys(dev, dma_handle);
>>
>> - dma_release_from_contiguous(dev,
>> + freed = dma_release_from_contiguous(dev,
>> phys_to_page(paddr),
>> size >> PAGE_SHIFT);
>> - } else {
>> + if (!freed)
>> swiotlb_free_coherent(dev, size, vaddr, dma_handle);
>> - }
>> }
>
> Is __dma_free_coherent() ever called in atomic context? If yes, the
> dma_release_from_contiguous() may not like it since it tries to acquire
> a mutex. But since we don't have the gfp flags here, we don't have an
> easy way to know what to call.
>
> So the initial idea of always calling __alloc_from_pool() for both
> coherent/non-coherent cases would work better (but still with a single
> shared pool, see below).
>
We should be okay
__dma_free_coherent -> dma_release_from_contiguous -> cma_release which
bounds checks the CMA region before taking any mutexes unless I missed
something.
The existing behavior on arm is to not allow non-atomic allocations to be
freed atomic context when CMA is enabled so we'd be giving arm64 more
leeway there. Is being able to free non-atomic allocations in atomic
context really necessary?
>> static void *__dma_alloc_noncoherent(struct device *dev, size_t size,
>> dma_addr_t *dma_handle, gfp_t flags,
>> struct dma_attrs *attrs)
>> {
>> - struct page *page, **map;
>> + struct page *page;
>> void *ptr, *coherent_ptr;
>> - int order, i;
>>
>> size = PAGE_ALIGN(size);
>> - order = get_order(size);
>> +
>> + if (!(flags & __GFP_WAIT)) {
>> + struct page *page = NULL;
>> + void *addr = __alloc_from_pool(size, &page);
>> +
>> + if (addr)
>> + *dma_handle = phys_to_dma(dev, page_to_phys(page));
>> +
>> + return addr;
>> +
>> + }
>
> If we do the above for the __dma_alloc_coherent() case, we could use the
> same pool but instead of returning addr it could just return
> page_address(page). The downside of sharing the pool is that you need
> cache flushing for every allocation (which we already do for the
> non-atomic case).
>
>> @@ -332,6 +391,67 @@ static struct notifier_block amba_bus_nb = {
>>
>> extern int swiotlb_late_init_with_default_size(size_t default_size);
>>
>> +static int __init atomic_pool_init(void)
>> +{
>> + pgprot_t prot = __pgprot(PROT_NORMAL_NC);
>> + unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
>> + struct page *page;
>> + void *addr;
>> +
>> +
>> + if (dev_get_cma_area(NULL))
>
> Is it worth using this condition for other places where we check
> IS_ENABLED(CONFIG_DMA_CMA) (maybe as a separate patch).
>
Yes, it would be good to match arm in that respect.
>> + page = dma_alloc_from_contiguous(NULL, nr_pages,
>> + get_order(atomic_pool_size));
>> + else
>> + page = alloc_pages(GFP_KERNEL, get_order(atomic_pool_size));
>
> One problem here is that the atomic pool wouldn't be able to honour
> GFP_DMA (in the latest kernel, CMA is by default in ZONE_DMA). You
> should probably pass GFP_KERNEL|GFP_DMA here. You could also use the
> swiotlb_alloc_coherent() which, with a NULL dev, assumes 32-bit DMA mask
> but it still expects GFP_DMA to be passed.
>
I think I missed updating this to GFP_DMA. The only advantage I would see
to using swiotlb_alloc_coherent vs. alloc_pages directly would be to
allow the fallback to using a bounce buffer if __get_free_pages failed.
I'll keep this as alloc_pages for now; it can be changed later if there
is a particular need for swiotlb behavior.
>> + if (page) {
>> + int ret;
>> +
>> + atomic_pool = gen_pool_create(PAGE_SHIFT, -1);
>> + if (!atomic_pool)
>> + goto free_page;
>> +
>> + addr = dma_common_contiguous_remap(page, atomic_pool_size,
>> + VM_USERMAP, prot, atomic_pool_init);
>> +
>> + if (!addr)
>> + goto destroy_genpool;
>> +
>> + memset(addr, 0, atomic_pool_size);
>> + __dma_flush_range(addr, addr + atomic_pool_size);
>
> If you add the flushing in the __dma_alloc_noncoherent(), it won't be
> needed here (of course, more efficient here but it would not work if we
> share the pool).
>
>> +postcore_initcall(atomic_pool_init);
>
> Why not arch_initcall? Or even better, we could have a common DMA init
> function that calls swiotlb_late_init() and atomic_pool_init() (in this
> order if you decide to use swiotlb allocation above).
>
Good point. I'll combine the two.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 5/8] of: Add Tegra124 EMC bindings
From: Stephen Warren @ 2014-07-21 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405088313-20048-6-git-send-email-mperttunen@nvidia.com>
On 07/11/2014 08:18 AM, Mikko Perttunen wrote:
> Add binding documentation for the nvidia,tegra124-emc device tree
> node.
> diff --git a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
> +Required properties :
> +- compatible : "nvidia,tegra124-emc".
> +- reg : Should contain 1 or 2 entries:
> + - EMC register set
> + - MC register set : Required only if no node with
> + 'compatible = "nvidia,tegra124-mc"' exists. The MC register set
> + is first read from the MC node. If it doesn't exist, it is read
> + from this property.
I echo what Thierry said about the MC register sharing.
> +- timings : Should contain 1 entry for each supported clock rate.
s/entry/node/ I think.
> + Entries should be named "timing at n" where n is a 0-based increasing
> + number. The timings must be listed in rate-ascending order.
That implies that #address-cells and #size-cells are required too.
> +Required properties for timings :
... and a reg property is needed here.
> +- clock-frequency : Should contain the memory clock rate.
> +- nvidia,parent-clock-frequency : Should contain the rate of the EMC
> + clock's parent clock.
> +- clocks : Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names : Must include the following entries:
> + - emc-parent : EMC's parent clock.
Shouldn't clocks/clock-names be part of the main node, not the
per-timing node?
> +- The following properties contain EMC timing characterization values:
> + - nvidia,emc-zcal-cnt-long
> + - nvidia,emc-auto-cal-interval
> + - nvidia,emc-ctt-term-ctrl
> + - nvidia,emc-cfg
> + - nvidia,emc-cfg-2
> + - nvidia,emc-sel-dpd-ctrl
> + - nvidia,emc-cfg-dig-dll
> + - nvidia,emc-bgbias-ctl0
> + - nvidia,emc-auto-cal-config
> + - nvidia,emc-auto-cal-config2
> + - nvidia,emc-auto-cal-config3
> + - nvidia,emc-mode-reset
> + - nvidia,emc-mode-1
> + - nvidia,emc-mode-2
> + - nvidia,emc-mode-4
> +- nvidia,emc-burst-data : EMC timing characterization data written to
> + EMC registers.
> +- nvidia,mc-burst-data : EMC timing characterization data written to
> + MC registers.
>
^ permalink raw reply
* [PATCH 4/4] (RFC) X86: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-21 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405887954.11927.5.camel@buesod1.americas.hpqcorp.net>
On Sun, 20 Jul 2014, Davidlohr Bueso wrote:
> On Fri, 2014-07-18 at 01:18 -0400, Nicolas Pitre wrote:
> > On X86 there are already tracepoints for IRQ vectors through which IPIs
> > are handled. However this is highly X86 specific, and the IPI signaling
> > is not currently traced.
> >
> > This is an attempt at adding generic IPI tracepoints to X86.
>
> I welcome this, and fwiw have been trying out this patch. One thing I
> would like to see, but due to overhead would probably be better suited
> in userspace (trace-cmd, maybe?), is a more packed description of the
> IPI. Ie: unifying ipi_init and ipi_exit and show overall cost of the
> IPI.
That's best suited for the tool consuming the log in user space. The
same is done with IRQ events already.
Nicolas
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721170630.GG21766@n2100.arm.linux.org.uk>
On Mon, Jul 21, 2014 at 06:06:30PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 21, 2014 at 03:43:13PM +0200, Boris BREZILLON wrote:
> > How about using a list instead of an array ?
> > This way we can add elements to this list when parsing the EDID.
> >
> > Or we can just define a maximum size for the bus_formats array when
> > retrieving this info from EDID. If I'm correct we have at most 18 bus
> > formats:
> > - 3 color formats:
> > * RGB 4:4:4
> > * YCbCr 4:4:4
> > * YCbCr 4:4:2
> > - 6 color depths: 6, 8, 10, 12, 14 and 16 bits per color
>
> This starts to worry me. What are we trying to do here - are we trying
> to encode the connection between the CRTC and the encoder, the encoder
> and the connector, or the connector and the device?
This is about the bus format of the panel device. That would make it the
latter.
> The encoder to connector and connector to device is mostly a function of
> the interface spec itself (for example, many HDMI encoders take either a
> RGB or YUV input and can convert it to the HDMI specified colourspaces for
> transmission over the connector.)
The discussion here started because we currently have no way to store
information about the interface for raw RGB. That means currently all
drivers need to hardcode assumptions about the mode. The idea was to
make this information available via a field in drm_display_info so that
drivers could reconfigure depending on what the attached panel expects.
This doesn't only apply to panels, though, the issue is the same when a
bridge (RGB/LVDS for example) is connected to the encoder.
> If you want to do encoder to connector, what about VGA or some other
> analogue signalling such as TV composite? It's easy to take this too
> far...
>
> Surely the only one which matters is the CRTC to the encoder - that's
> certainly true of all the setups I've come across so far. As for that
> interface, CRTCs I've seen can produce a /wide/ range of different
> representations.
>
> Some CRTCs (eg, AMBA CLCD) produce R, G, B signals scrunched down on to
> the LSB bits of a LCD data bus (so RGB888 uses 24 bits, RGB444 would
> use the LSB 12 bits of those 24 - rather than outputting the R4 bits on
> a subset of the R8 bits.)
>
> What about RGB565 - where you have differing number of bits for the
> green channel from red/blue?
>
> Then you have red/blue colour swapping at the CRTC (and similar for YUV)
> such as on Dove / Armada.
>
> Then there are some encoders have the ability to almost arbitarily map
> their input pins according to whatever you choose (eg, TDA998x).
>
> This problem isn't as quite as simple as "this is what EDID gives us"
> and "these are the number of bits representing a colour".
I think what we need is a way to pass information from whatever device
is behind the encoder (be it a bridge or a panel) to the encoder. And
likely we'll need a similar (or the same) way to pass that information
from bridge to bridge or from bridge to panel.
That way the encoder can ask the bridge (or panel) about the format it
requires and reconfigure itself accordingly. This should be able to work
with an arbitrary bridge -> [bridge... ->] panel chain where each
element in the chain can reconfigure depending on what the next element
requires (or fail if it can't work, which should really never happen).
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/42d90e28/attachment-0001.sig>
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6062556.5zQdTSJFua@avalon>
On Mon, Jul 21, 2014 at 08:30:31PM +0200, Laurent Pinchart wrote:
> Hi Boris and Thierry,
>
> On Monday 21 July 2014 16:21:36 Boris BREZILLON wrote:
> > On Mon, 21 Jul 2014 15:54:12 +0200 Thierry Reding wrote:
> > > On Mon, Jul 21, 2014 at 03:47:52PM +0200, Laurent Pinchart wrote:
> > >> On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> > >>> On Mon, 21 Jul 2014 15:30:35 +0200 Thierry Reding wrote:
> > >>>> On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> > >>>>> On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> > >>>>>> On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> > >>>>>>> On Mon, 21 Jul 2014 14:16:42 +0200 Laurent Pinchart wrote:
> > >>>>>>>> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
>
> [snip]
>
> > >>>>>>>>> Quoting from your paste:
> > >>>>>>>>> + const enum video_bus_format *bus_formats;
> > >>>>>>>>> + int nbus_formats;
> > >>>>>>>>>
> > >>>>>>>>> Do we really need more than one?
> > >>>>>>>>
> > >>>>>>>> We do if we want to replace the color_formats and bpc fields.
> > >>>>>>>
> > >>>>>>> Yes, that's what I was about to answer :-).
> > >>>>>>
> > >>>>>> Maybe we don't need to replace color_formats and bpc field
> > >>>>>> immediately. That could be done in a follow-up patch.
> > >>>>>
> > >>>>> We don't need to replace them right now, but we should at least
> > >>>>> agree on how to replace them. Introducing a new field that would
> > >>>>> need to be replaced in the near future when removing color_formats
> > >>>>> and bpc would be a waste of time.
> > >>>>
> > >>>> Sure. One of the problems I see with replacing color_formats and bpc
> > >>>> with the above is that some of the bits within color_formats are set
> > >>>> when the EDID is parsed. That implies that if they are replaced with
> > >>>> an array of formats, the array would need to be reallocated during
> > >>>> EDID parsing. That sounds like ugliness.
> > >>>>
> > >>>> But if you can find a nice way to make it work that'd be great.
> > >>>
> > >>> How about using a list instead of an array ?
> > >>> This way we can add elements to this list when parsing the EDID.
> > >>>
> > >>> Or we can just define a maximum size for the bus_formats array when
> > >>> retrieving this info from EDID. If I'm correct we have at most 18 bus
> > >>>
> > >>> formats:
> > >>> - 3 color formats:
> > >>> * RGB 4:4:4
> > >>> * YCbCr 4:4:4
> > >>> * YCbCr 4:4:2
> > >>> - 6 color depths: 6, 8, 10, 12, 14 and 16 bits per color
> > >>
> > >> bpc isn't a bitmask, so EDID supports up to three formats only.
> > >>
> > >> The color_formats field is computed in the drm_add_display_info()
> > >> function. You could easily turn it into a local variable and allocate
> > >> and fill the formats array at the end of the function.
> > >
> > > But you also need to be careful to keep whatever formats the driver might
> > > have set explicitly.
>
> Do we have drivers that explicitly add formats to the formats parsed from EDID
> data ? If so, what's the use case ?
Drivers could specifically add them if there's no EDID or if the EDID
is known to be broken. If the former this is probably irrelevant. In the
latter maybe a better option would be to ignore the EDID-probed ones
rather than use the union of those provided by the driver and EDID.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/4735739e/attachment.sig>
^ permalink raw reply
* [PATCHv4 5/5] arm64: Add atomic pool for non-coherent and CMA allocations.
From: Laura Abbott @ 2014-07-21 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140704133517.GA9860@ulmo>
On 7/4/2014 6:35 AM, Thierry Reding wrote:
> On Wed, Jul 02, 2014 at 11:03:38AM -0700, Laura Abbott wrote:
> [...]
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> [...]
>> +static struct gen_pool *atomic_pool;
>> +
>> +#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
>> +static size_t atomic_pool_size = DEFAULT_DMA_COHERENT_POOL_SIZE;
>
> There doesn't seem to be much use for this since it can't be overridden
> via init_dma_coherent_pool_size like on ARM.
>
There is still the command line option coherent_pool=<size> though
[...]
>> + if (page) {
>> + int ret;
>> +
>> + atomic_pool = gen_pool_create(PAGE_SHIFT, -1);
>> + if (!atomic_pool)
>> + goto free_page;
>> +
>> + addr = dma_common_contiguous_remap(page, atomic_pool_size,
>> + VM_USERMAP, prot, atomic_pool_init);
>> +
>> + if (!addr)
>> + goto destroy_genpool;
>> +
>> + memset(addr, 0, atomic_pool_size);
>> + __dma_flush_range(addr, addr + atomic_pool_size);
>> +
>> + ret = gen_pool_add_virt(atomic_pool, (unsigned long)addr,
>> + page_to_phys(page),
>> + atomic_pool_size, -1);
>> + if (ret)
>> + goto remove_mapping;
>> +
>> + gen_pool_set_algo(atomic_pool,
>> + gen_pool_first_fit_order_align, NULL);
>> +
>> + pr_info("DMA: preallocated %zd KiB pool for atomic allocations\n",
>
> I think this should be "%zu" because atomic_pool_size is a size_t, not a
> ssize_t.
>
Yes, will fix.
>> + atomic_pool_size / 1024);
>> + return 0;
>> + }
>> + goto out;
>> +
>> +remove_mapping:
>> + dma_common_free_remap(addr, atomic_pool_size, VM_USERMAP);
>> +destroy_genpool:
>> + gen_pool_destroy(atomic_pool);
>> + atomic_pool == NULL;
>
> This probably doesn't belong here.
>
Dastardly typo.
>> +free_page:
>> + if (!dma_release_from_contiguous(NULL, page, nr_pages))
>> + __free_pages(page, get_order(atomic_pool_size));
>
> You use get_order(atomic_pool_size) a lot, perhaps it should be a
> temporary variable?
>
Yes, three usages is probably enough.
>> +out:
>> + pr_err("DMA: failed to allocate %zx KiB pool for atomic coherent allocation\n",
>> + atomic_pool_size / 1024);
>
> Print in decimal rather than hexadecimal?
>
I actually prefer hexadecimal but I should at least be consistent between
error and non-error paths.
> Thierry
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] arm64: make CONFIG_ZONE_DMA user settable
From: Mark Salter @ 2014-07-21 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718110718.GC19850@arm.com>
On Fri, 2014-07-18 at 12:07 +0100, Catalin Marinas wrote:
> On Tue, Jun 24, 2014 at 03:38:34PM +0100, Mark Salter wrote:
> > On Tue, 2014-06-24 at 15:14 +0100, Catalin Marinas wrote:
> > > On Mon, Jun 23, 2014 at 02:17:03PM +0100, Mark Salter wrote:
> > > > On Mon, 2014-06-23 at 12:09 +0100, Catalin Marinas wrote:
> > > > > My proposal (in the absence of any kind of description) is to still
> > > > > create a ZONE_DMA if we have DMA memory below 32-bit, otherwise just add
> > > > > everything (>32-bit) to ZONE_DMA. Basically an extension from your CMA
> > > > > patch, make dma_phys_limit static in that file and set it to
> > > > > memblock_end_of_DRAM() if no 32-bit DMA. Re-use it in the
> > > > > zone_sizes_init() function for ZONE_DMA (maybe with a pr_info for no
> > > > > 32-bit only DMA zone).
> > > >
> > > > There's a performance issue with all memory being in ZONE_DMA. It means
> > > > all normal allocations will fail on ZONE_NORMAL and then have to fall
> > > > back to ZONE_DMA. It would be better to put some percentage of memory
> > > > in ZONE_DMA.
> > >
> > > Is the performance penalty real or just theoretical? I haven't run any
> > > benchmarks myself.
> >
> > It is real insofar as you must eat cycles eliminating ZONE_NORMAL from
> > consideration in the page allocation hot path. How much that really
> > costs, I don't know. But it seems like it could be easily avoided by
> > limiting ZONE_DMA size. Is there any reason it needs to be larger than
> > 4GiB?
>
> Basically ZONE_DMA should allow a 32-bit dma mask. When memory starts
> above 4G, in the absence of an IOMMU, it is likely that 32-bit devices
> get some offset for the top bits to be able to address the bottom of the
> memory. The problem is that dma_to_phys() that early in the kernel has
> no idea about DMA offsets until later (they can be specified in DT per
> device).
>
> The patch belows tries to guess a DMA offset and use the bottom 32-bit
> of the DRAM as ZONE_DMA.
>
> -------8<-----------------------
>
> From 133656f8378dbb838ad5f12ea29aa9303d7ca922 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Fri, 18 Jul 2014 11:54:37 +0100
> Subject: [PATCH] arm64: Create non-empty ZONE_DMA when DRAM starts above 4GB
>
> ZONE_DMA is created to allow 32-bit only devices to access memory in the
> absence of an IOMMU. On systems where the memory starts above 4GB, it is
> expected that some devices have a DMA offset hardwired to be able to
> access the bottom of the memory. Linux currently supports DT bindings
> for the DMA offsets but they are not (easily) available early during
> boot.
>
> This patch tries to guess a DMA offset and assumes that ZONE_DMA
> corresponds to the 32-bit mask above the start of DRAM.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Salter <msalter@redhat.com>
> ---
Tested-by: Mark Salter <msalter@redhat.com>
Thanks.
^ permalink raw reply
* [PATCH 2/6] clk: tegra: make tegra_clocks_apply_init_table arch_initcall
From: Thierry Reding @ 2014-07-21 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CD896C.3030605@wwwdotorg.org>
On Mon, Jul 21, 2014 at 03:43:08PM -0600, Stephen Warren wrote:
> On 07/16/2014 02:27 AM, Peter De Schrijver wrote:
> > On Wed, Jul 16, 2014 at 09:19:33AM +0200, Thierry Reding wrote:
> >> * PGP Signed by an unknown key
> >>
> >> On Tue, Jul 15, 2014 at 06:24:32PM +0300, Peter De Schrijver wrote:
> >> [...]
> >>> diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
> >>> index d081732..65cde4e 100644
> >>> --- a/drivers/clk/tegra/clk.c
> >>> +++ b/drivers/clk/tegra/clk.c
> >>> @@ -290,10 +290,13 @@ struct clk ** __init tegra_lookup_dt_id(int clk_id,
> >>>
> >>> tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
> >>>
> >>> -void __init tegra_clocks_apply_init_table(void)
> >>> +static int __init tegra_clocks_apply_init_table(void)
> >>> {
> >>> if (!tegra_clk_apply_init_table)
> >>> - return;
> >>> + return 0;
> >>
> >> Shouldn't this be an error? Or perhaps WARN()? To make sure this gets
> >
> > An arch_initcall will be called for every ARM platform I think? In case
> > this gets called on a non-Tegra platform, tegra_clk_apply_init_table will not
> > be set and therefore a silent return 0; seems the most appropriate thing to do
> > to me?
>
> This is one reason that doing all the initialization from separate
> initcalls sucks. Much better to have a single top-level initialization
> function that calls exactly what is needed, only what is needed, and
> only runs on the correct SoCs.
>
> But failing that, I guess you need to say something like
> of_is_compatible(root node, "nvidia Tegra"), but of course the
> definition of "nvidia Tegra" is an ever-growing list of possible values
> that needs to be used from each separate initcall...
FWIW, we have soc_is_tegra() now in include/soc/tegra/common.h which is
meant to be used for exactly this purpose. I agree that it isn't optimal
but it's pretty good. It should be easy to refactor this to make it
callable from a top-level initialization function when a decision
regarding that has been made.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/07496a14/attachment.sig>
^ permalink raw reply
* [PATCH 2/6] clk: tegra: make tegra_clocks_apply_init_table arch_initcall
From: Stephen Warren @ 2014-07-21 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140716082740.GK23218@tbergstrom-lnx.Nvidia.com>
On 07/16/2014 02:27 AM, Peter De Schrijver wrote:
> On Wed, Jul 16, 2014 at 09:19:33AM +0200, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Tue, Jul 15, 2014 at 06:24:32PM +0300, Peter De Schrijver wrote:
>> [...]
>>> diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
>>> index d081732..65cde4e 100644
>>> --- a/drivers/clk/tegra/clk.c
>>> +++ b/drivers/clk/tegra/clk.c
>>> @@ -290,10 +290,13 @@ struct clk ** __init tegra_lookup_dt_id(int clk_id,
>>>
>>> tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
>>>
>>> -void __init tegra_clocks_apply_init_table(void)
>>> +static int __init tegra_clocks_apply_init_table(void)
>>> {
>>> if (!tegra_clk_apply_init_table)
>>> - return;
>>> + return 0;
>>
>> Shouldn't this be an error? Or perhaps WARN()? To make sure this gets
>
> An arch_initcall will be called for every ARM platform I think? In case
> this gets called on a non-Tegra platform, tegra_clk_apply_init_table will not
> be set and therefore a silent return 0; seems the most appropriate thing to do
> to me?
This is one reason that doing all the initialization from separate
initcalls sucks. Much better to have a single top-level initialization
function that calls exactly what is needed, only what is needed, and
only runs on the correct SoCs.
But failing that, I guess you need to say something like
of_is_compatible(root node, "nvidia Tegra"), but of course the
definition of "nvidia Tegra" is an ever-growing list of possible values
that needs to be used from each separate initcall...
^ permalink raw reply
* [PATCH 2/2] ARM: tegra: Convert PMC to a driver
From: Thierry Reding @ 2014-07-21 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CD8161.2030204@wwwdotorg.org>
On Mon, Jul 21, 2014 at 03:08:49PM -0600, Stephen Warren wrote:
> On 07/07/2014 08:16 AM, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > This commit converts the PMC support code to a platform driver. Because
> > the boot process needs to call into this driver very early, set up a
> > minimalistic environment via an early initcall.
>
> Can we do this without using standalone initcalls? There's no way to
> ensure ordering with initcalls, which seems like it'll be problematic
> once we start converting more stuff.
This driver uses an early_initcall to setup the basic environment
required for SMP. That basic environment will stay intact until the
proper driver takes over the resources sometime at device_initcall
time.
Obviously this type of ordering should only be used for this type of
low-level code that has no other dependencies.
> Instead, can we have some "driver" that binds to the top-level DT node,
> does all the low-/chip-level init, then continues processing the DT? I
> suspect that Pawel's "platform: Make platform_bus device a platform
> device" will help out here. He just posted it today:
>
> http://www.spinics.net/lists/arm-kernel/msg349328.html
I'm not entirely convinced that this is really necessary. Ideally the
early code should be fairly limited. Given that the ARM64 maintainers
prefer to have SMP handled using a firmware interface this whole
discussion may become moot anyway.
Handling this in firmware is going to create a whole new set of
problems, though, I guess. For instance on Tegra we need to program the
PMC to bring up CPUs. The operations that toggle the power partition
state aren't atomic, so there's always the possibility that firmware
will try to power-up/down a CPU while some other driver is trying to
power-up/down some other partition. How are firmware and kernel supposed
to serialize register accesses?
> > While at it, also move the driver out to drivers/power so that it can be
> > shared with 64-bit SoCs.
>
> > arch/arm/mach-tegra/pmc.c | 402 -----------------
> > arch/arm/mach-tegra/powergate.c | 503 ---------------------
>
> > drivers/power/tegra-pmc.c | 948 ++++++++++++++++++++++++++++++++++++++++
>
> It's a bit hard to review this patch because two files at the source
> were merged into one at the destination, and so "git diff -M" couldn't
> detect/represent any changes that happened during the move and highlight
> just those. I assume this just cut/pastes the whole of pmc.c and
> powergate.c into the new tegra-pmc.c without actually changing anything
> much?
Yes, it's simply a cut-and-paste job. Well, there's a slight difference
in what functions are being built. The old code didn't conditionally
build the CONFIG_PM_SLEEP and CONFIG_SMP functions in the driver (though
the prototypes were conditionalized). The new driver restores
consistency. That was to fix randconfig build errors that Arnd reported.
> I wonder if putting the file into drivers/power/ directly makes sense?
> We have "class"-specific sub-directories drivers/power/supply (after
> this series) and drives/power/{avs,reset}/ before. Should we have a
> drivers/power/domain or drivers/power/soc/? instead?
Yeah, moving the code into a subdirectory should be fine. It seemed a
little pointless since there was only one, but if drivers/power
maintainers ever agree to this restructuring I'll happily create another
subdirectory for power domain or SoC power drivers.
> That said, drivers/soc/tegra still feels fine to me for this code...
I agree. At this point in time it's unlikely that we'll be able to come
up with a generic framework to accomodate this driver. Until that time I
don't think it makes sense to move this anywhere else.
But if people insist there shouldn't be a problem to move this out again
since the difficult part of untangling the dependencies is done now, so
it should simply be a matter of doing a git mv and adjusting the Kconfig
and/or Makefile.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/89794850/attachment.sig>
^ permalink raw reply
* [PATCH 5/8] of: Add Tegra124 EMC bindings
From: Stephen Warren @ 2014-07-21 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL1qeaGHfjQhLHvgzt85hmbuY4FOG5-k=f80=CNvzPDEgi9_6w@mail.gmail.com>
On 07/11/2014 10:43 AM, Andrew Bresticker wrote:
> On Fri, Jul 11, 2014 at 7:18 AM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
>> Add binding documentation for the nvidia,tegra124-emc device tree
>> node.
>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
>
>> +Required properties :
>> +- compatible : "nvidia,tegra124-emc".
>> +- reg : Should contain 1 or 2 entries:
>> + - EMC register set
>> + - MC register set : Required only if no node with
>> + 'compatible = "nvidia,tegra124-mc"' exists. The MC register set
>> + is first read from the MC node. If it doesn't exist, it is read
>> + from this property.
>> +- timings : Should contain 1 entry for each supported clock rate.
>> + Entries should be named "timing at n" where n is a 0-based increasing
>> + number. The timings must be listed in rate-ascending order.
>
> There are upcoming boards which support multiple DRAM configurations
> and require a separate set of timings for each configuration. Could
> we instead have multiple sets of timings with the proper one selected
> at runtime by RAM code, as reported by PMC_STRAPPING_OPT_A_0?
> Something like:
>
> emc {
> emc-table at 0 {
> nvidia,ram-code = <0>;
> timing at 0 {
> ...
> };
> ...
> };
Until recently, there was a binding for Tegra20 EMC in mainline. We
should make sure the Tegra124 driver (or rather binding...) is at least
as feature-ful as that was.
Furthermore, I thought that with some boards, there were more RAM
options that there were available RAM code strap bits. I assume that in
mainline, we'll simply have different base DT files for the different
sets of configurations? Or, will we want to add another level to the DT
to represent different sets of RAM code values? I'm not sure what data
source the bootloader uses to determine which set of RAM configuration
to use when there aren't enough entries in the BCT for the boot ROM to
do this automatically, and whether we have any way to get that value
into the kernel, so it could use it for the extra DT level lookup?
^ permalink raw reply
* [GIT PULL] qcom clock changes for 3.17
From: Stephen Boyd @ 2014-07-21 21:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike,
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-clocks-for-3.17
for you to fetch changes up to e216ce60a9e05ab399d098f05cd86fd95c9da8d5:
clk: qcom: Add support for APQ8064 multimedia clocks (2014-07-15 16:39:03 -0700)
----------------------------------------------------------------
qcom clock changes for 3.17
These patches add support for a handful of Qualcomm's SoC clock
controllers: APQ8084 gcc and mmcc, IPQ8064 gcc, and APQ8064.
There's also a small collection of bug fixes that aren't critical
-rc worthy regressions because the consumer drivers aren't present
or using the buggy clocks and one optimization for HDMI.
----------------------------------------------------------------
Georgi Djakov (4):
clk: qcom: Add APQ8084 Global Clock Controller documentation
clk: qcom: Add APQ8084 Global Clock Controller support
clk: qcom: Add APQ8084 clocks for SATA, PCIe and UFS
clk: qcom: Add APQ8084 Multimedia Clock Controller (MMCC) support
Kumar Gala (1):
clk: qcom: Add support for IPQ8064's global clock controller (GCC)
Srinivas Kandagatla (1):
clk: qcom: add clocks necessary for apq8064 sdcc
Stephen Boyd (7):
clk: qcom: Fully support apq8064 global clock control
clk: qcom: Support bypass RCG configuration
clk: qcom: Fix MN frequency tables, parent map, and jpegd
clk: qcom: Fix PLL rate configurations
clk: qcom: mdp_lut_clk is a child of mdp_src
clk: qcom: pll: Add support for configuring SR PLLs
clk: qcom: Add support for APQ8064 multimedia clocks
.../devicetree/bindings/clock/qcom,gcc.txt | 2 +
.../devicetree/bindings/clock/qcom,mmcc.txt | 2 +
drivers/clk/qcom/Kconfig | 25 +
drivers/clk/qcom/Makefile | 3 +
drivers/clk/qcom/clk-pll.c | 15 +-
drivers/clk/qcom/clk-pll.h | 2 +
drivers/clk/qcom/clk-rcg.c | 51 +-
drivers/clk/qcom/clk-rcg.h | 1 +
drivers/clk/qcom/common.c | 39 +-
drivers/clk/qcom/common.h | 6 +
drivers/clk/qcom/gcc-apq8084.c | 3611 ++++++++++++++++++++
drivers/clk/qcom/gcc-ipq806x.c | 2424 +++++++++++++
drivers/clk/qcom/gcc-msm8960.c | 583 +++-
drivers/clk/qcom/mmcc-apq8084.c | 3352 ++++++++++++++++++
drivers/clk/qcom/mmcc-msm8960.c | 526 ++-
drivers/clk/qcom/mmcc-msm8974.c | 10 +-
include/dt-bindings/clock/qcom,gcc-apq8084.h | 351 ++
include/dt-bindings/clock/qcom,gcc-ipq806x.h | 293 ++
include/dt-bindings/clock/qcom,gcc-msm8960.h | 11 +
include/dt-bindings/clock/qcom,mmcc-apq8084.h | 183 +
include/dt-bindings/clock/qcom,mmcc-msm8960.h | 8 +
include/dt-bindings/reset/qcom,gcc-apq8084.h | 109 +
include/dt-bindings/reset/qcom,gcc-ipq806x.h | 132 +
include/dt-bindings/reset/qcom,gcc-msm8960.h | 16 +
include/dt-bindings/reset/qcom,mmcc-apq8084.h | 64 +
include/dt-bindings/reset/qcom,mmcc-msm8960.h | 8 +
26 files changed, 11747 insertions(+), 80 deletions(-)
create mode 100644 drivers/clk/qcom/gcc-apq8084.c
create mode 100644 drivers/clk/qcom/gcc-ipq806x.c
create mode 100644 drivers/clk/qcom/mmcc-apq8084.c
create mode 100644 include/dt-bindings/clock/qcom,gcc-apq8084.h
create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq806x.h
create mode 100644 include/dt-bindings/clock/qcom,mmcc-apq8084.h
create mode 100644 include/dt-bindings/reset/qcom,gcc-apq8084.h
create mode 100644 include/dt-bindings/reset/qcom,gcc-ipq806x.h
create mode 100644 include/dt-bindings/reset/qcom,mmcc-apq8084.h
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCHv4 4/5] arm: use genalloc for the atomic pool
From: Laura Abbott @ 2014-07-21 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140704134254.GA4142@ulmo>
On 7/4/2014 6:42 AM, Thierry Reding wrote:
> On Wed, Jul 02, 2014 at 11:03:37AM -0700, Laura Abbott wrote:
> [...]
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> [...]
>> index f5190ac..02a1939 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -26,6 +26,7 @@
>> #include <linux/io.h>
>> #include <linux/vmalloc.h>
>> #include <linux/sizes.h>
>> +#include <linux/genalloc.h>
>
> Includes should be sorted alphabetically. I realize that's not the case
> for this particular file, but the downside of that is that your patch no
> longer applies cleanly on top of linux-next because some other patch did
> add linux/cma.h at the same location.
>
Yes, I'll fix that up. I'll put genalloc.h before gfp.h.
>> static int __init early_coherent_pool(char *p)
>> {
>> - atomic_pool.size = memparse(p, &p);
>> + atomic_pool_size = memparse(p, &p);
>> return 0;
>> }
>> early_param("coherent_pool", early_coherent_pool);
>>
>> +
>
> There's a gratuituous blank line her.
>
> I also need the below hunk on top of you patch to make this compile on
> ARM.
>
Yes, that does indeed need to be fixed up.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ 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