* [PATCH v3 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t
From: Sebastian Capella @ 2014-01-29 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128205830.14275.80319@capellas-linux>
Hi Andrew,
By the way, I do see a call (sysfs_streq) in use for this purpose
other places. Sorry, I didn't find it while looking at the original
problem. I'm not sure if this is preferable, but it appears to have
been added specifically for the strings coming through sysfs.
My preference is copying the string and cleaning it up before passing
it to internal functions, even though we incur an allocation.
Thanks,
Sebastian
^ permalink raw reply
* [PATCH v4 2/5] arm: add new asm macro update_sctlr
From: Leif Lindholm @ 2014-01-29 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122112055.GF1621@mudshark.cambridge.arm.com>
On Wed, Jan 22, 2014 at 11:20:55AM +0000, Will Deacon wrote:
> > +#ifdef CONFIG_CPU_CP15
> > +/* Macro for setting/clearing bits in sctlr */
> > + .macro update_sctlr, set:req, clear:req, tmp:req, tmp2:req
> > + mrc p15, 0, \tmp, c1, c0, 0
> > + ldr \tmp2, =\set
> > + orr \tmp, \tmp, \tmp2
> > + ldr \tmp2, =\clear
> > + mvn \tmp2, \tmp2
> > + and \tmp, \tmp, \tmp2
> > + mcr p15, 0, \tmp, c1, c0, 0
>
> I think this would be cleaner if you force the caller to put set and clear
> into registers beforehand, rather than have to do the literal load every
> time. Also, I don't think set and clear should be required (and then you can
> lose tmp2 as well).
I can't figure out how to make register-parameters non-required
(i.e. conditionalise on whether an optional parameter was provided),
so my attempt of refactoring actually ends up using an additional
register:
#ifdef CONFIG_CPU_CP15
/* Macro for setting/clearing bits in sctlr */
.macro update_sctlr, set:req, clear:req, tmp:req
mrc p15, 0, \tmp, c1, c0, 0
orr \tmp, \set
mvn \clear, \clear
and \tmp, \tmp, \clear
mcr p15, 0, \tmp, c1, c0, 0
.endm
#endif
If you think that's an improvement I can do that, and I have (just)
enough registers to spare.
If I'm being daft with my macro issues, do point it out.
/
Leif
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-29 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> A new round, mostly fixing some minor nitpicks.
>
If anyone wants to give this a test, here's a public branch:
https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
I'll be resending a new v6 adressing Russell's last comment about the
clock initialization, as soon as v3.14-rc1 is out.
Go, testers, go!
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU
From: Nishanth Menon @ 2014-01-29 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391019557-22313-1-git-send-email-nm@ti.com>
OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
dpll_mpu clock.
Latency used is the generic latency defined in omap-cpufreq
driver.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 4 ++++
arch/arm/boot/dts/am4372.dtsi | 5 +++++
arch/arm/boot/dts/dra7.dtsi | 5 +++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
arch/arm/boot/dts/omap4.dtsi | 5 +++++
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
6 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..4bbba26 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -58,6 +58,10 @@
275000 1125000
>;
voltage-tolerance = <2>; /* 2 percentage */
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c6bd4d9..33798d9 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -33,6 +33,11 @@
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..ce591e5 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -47,6 +47,11 @@
1000000 1060000
1176000 1160000
>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
cpu at 1 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..01f2b3b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -35,6 +35,11 @@
compatible = "arm,cortex-a8";
device_type = "cpu";
reg = <0x0>;
+
+ clocks = <&dpll1_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..ce87996 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,11 @@
device_type = "cpu";
next-level-cache = <&L2>;
reg = <0x0>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
};
cpu at 1 {
compatible = "arm,cortex-a9";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..8bb4134 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -49,6 +49,12 @@
1000000 1060000
1500000 1250000
>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+
/* cooling options */
cooling-min-level = <0>;
cooling-max-level = <2>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] clk: ti: am335x: remove unecessary cpu0 clk node
From: Nishanth Menon @ 2014-01-29 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391019557-22313-1-git-send-email-nm@ti.com>
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/clk/ti/clk-33xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index 776ee45..028b337 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
DT_CLK(NULL, "dpll_core_m5_ck", "dpll_core_m5_ck"),
DT_CLK(NULL, "dpll_core_m6_ck", "dpll_core_m6_ck"),
DT_CLK(NULL, "dpll_mpu_ck", "dpll_mpu_ck"),
- DT_CLK("cpu0", NULL, "dpll_mpu_ck"),
DT_CLK(NULL, "dpll_mpu_m2_ck", "dpll_mpu_m2_ck"),
DT_CLK(NULL, "dpll_ddr_ck", "dpll_ddr_ck"),
DT_CLK(NULL, "dpll_ddr_m2_ck", "dpll_ddr_m2_ck"),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] ARM: dts/OMAP: add cpu clock nodes
From: Nishanth Menon @ 2014-01-29 18:19 UTC (permalink / raw)
To: linux-arm-kernel
Add clock nodes for all existing OMAP platforms where cpufreq-cpu0
can be used.
Sanity tested with linux next-20140128 tag, applies on
master 0e47c96 Merge tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd
Ofcourse, I have send 7 different versions[1] previously, so I will start from
version 1 again considering that I have finally based on master.
If folks feel that the clock nodes must be split out into various platforms, I
can regenerate the series again.
Nishanth Menon (2):
clk: ti: am335x: remove unecessary cpu0 clk node
ARM: dts: OMAP3+: add clock nodes for CPU
arch/arm/boot/dts/am33xx.dtsi | 4 ++++
arch/arm/boot/dts/am4372.dtsi | 5 +++++
arch/arm/boot/dts/dra7.dtsi | 5 +++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
arch/arm/boot/dts/omap4.dtsi | 5 +++++
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
drivers/clk/ti/clk-33xx.c | 1 -
7 files changed, 30 insertions(+), 1 deletion(-)
[1] Last version of the patch series was posted here:
http://marc.info/?l=linux-omap&m=138245695726479&w=2
--
1.7.9.5
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Will Deacon @ 2014-01-29 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E940FC.9050602@amd.com>
On Wed, Jan 29, 2014 at 05:57:16PM +0000, Suravee Suthikulanit wrote:
> On 1/29/2014 11:29 AM, Will Deacon wrote:
> > On Wed, Jan 29, 2014 at 05:26:35PM +0000, Suravee Suthikulanit wrote:
> >> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
> >>> On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
> >>>> Actually, we are using 32 on the AMD system. So, do you think we can set
> >>>> this to 32 instead?
> >>>
> >>> I think that's ok.
> >>>
> >>> But are we really talking about number of SMRs or number of StreamIDs
> >>> per master device here? Ie. are you just having 32 SMRs for an SMMU on
> >>> your AMD system or do you have master devices which have 32 StreamIDs?
> >>>
> >>> If it's just number of SMRs we don't need to modify this macro.
> >>>
> >>
> >> I am referring to the case where each mmu-master can have upto 32 streamID.
> >
> > Crikey, how many SMRs do you have? Andreas and I have been struggling to
> > write a decent allocator for those, so if you have any algorithms that don't
> > require a quantum computer, we'd love to hear from you :)!
> >
> > Will
> >
>
> Are you talking about the __arm_smmu_alloc_bitmap()?
>
> Currently, we have configured the each SMMU to have 32 SMRs and using
> 15-bit streamID. However, we mostly have upto 32 streamID for each
> master, and most of the SMMU only have one master. So it looks like the
> current logic should be ok.
Interesting... how does that work for PCI? Do you force all devices behind a
given RC into the same address space?
Will
^ permalink raw reply
* [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Gupta, Pekon @ 2014-01-29 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLVr1gSLArqtfOiHce+u6ZK8FiKMX0o9bvMrMoGGhATvg@mail.gmail.com>
Dear Rob, and other DT maintainers,
>From: Rob Herring
[...]
>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>> + standard.
>
>Add to generic nand binding.
>
>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>> + or
>> +- rb-gpios : shall contain the gpios used as R/B pins.
>
>Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>pin is an option? If so, don't you need some fixed time delay
>properties like max erase time?
>
>rb-gpios could be added to the generic nand binding as well.
>
I do think this should go into generic nand binding, as this is controller specific.
Some controllers have dedicated R/B pin (Ready/Busy) while others may use
GPIO instead. It's the way a hardware controller is designed.
Request you to please consider Ack from MTD Maintainers 'at-least' for
generic NAND DT bindings. There is already a discussion going in
a separate thread for which is still not awaiting replies [1].
[1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html
with regards, pekon
^ permalink raw reply
* [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Boris BREZILLON @ 2014-01-29 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLVr1gSLArqtfOiHce+u6ZK8FiKMX0o9bvMrMoGGhATvg@mail.gmail.com>
Hello Rob,
Le 29/01/2014 18:11, Rob Herring a ?crit :
> On Wed, Jan 29, 2014 at 8:34 AM, Boris BREZILLON
> <b.brezillon.dev@gmail.com> wrote:
>> Add the sunxi NAND Flash Controller dt bindings documentation.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
>> ---
>> .../devicetree/bindings/mtd/sunxi-nand.txt | 46 ++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>> new file mode 100644
>> index 0000000..b0e55a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>> @@ -0,0 +1,46 @@
>> +Allwinner NAND Flash Controller (NFC)
>> +
>> +Required properties:
>> +- compatible : "allwinner,sun4i-nand".
>> +- reg : shall contain registers location and length for data and reg.
>> +- interrupts : shall define the nand controller interrupt.
>> +- #address-cells: shall be set to 1. Encode the nand CS.
>> +- #size-cells : shall be set to 0.
>> +- clocks : shall reference nand controller clocks.
>> +- clock-names : nand controller internal clock names. Shall contain :
>> + * "ahb_clk" : AHB gating clock
>> + * "sclk" : nand controller clock
>> +
>> +Optional children nodes:
>> +Children nodes represent the available nand chips.
>> +
>> +Optional properties:
> For the controller or per nand chip?
>
>> +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
>> + standard.
> Add to generic nand binding.
>
>> +- allwinner,rb : shall contain the native Ready/Busy ids.
>> + or
>> +- rb-gpios : shall contain the gpios used as R/B pins.
> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
> pin is an option?
Both are optional. In case none of the properties are defined the dev_ready
callback is set to NULL and the nand_base waiting loop is used.
> If so, don't you need some fixed time delay
> properties like max erase time?
This is handled in nand_base (using the chip_delay field), but I guess
we could
use the information retrieved from nand timings and the operation in
progress...
> rb-gpios could be added to the generic nand binding as well.
Sure.
>
> Rob
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-29 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127155755.GH32608@arm.com>
On Mon, 27 Jan 2014, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 03:51:02PM +0000, Nicolas Pitre wrote:
> > On Mon, 27 Jan 2014, Catalin Marinas wrote:
> >
> > > For arm64, we could simply remove any reference to FIQs. I'm not aware
> > > of anyone using them.
> >
> > OK. What if I sumply remove arch_cpu_idle_prepare() and let you
> > remove the rest?
> >
> > IMHO I'd simply remove local_fiq_{enable/disable}() from
> > arm64/kernel/smp.c and leave the infrastructure in place in case someone
> > needs it eventually. In which case I could include that into my patch
> > as well.
>
> Sounds good. We can keep the local_fiq_*() functions but remove about 4
> calling sites (process.c and smp.c) until needed.
OK here it is. Please feel free to merge this into your tree directly
as it no longer has any dependency issues with other patches.
----- >8
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Subject: [PATCH] ARM64: FIQs are unused
So any FIQ handling is superfluous at the moment. The functions to
disable/enable FIQs is kept around if ever someone needs them in the
future, but existing calling sites including arch_cpu_idle_prepare()
may go for now.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index de17c89985..adeabe8c6b 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -84,11 +84,6 @@ EXPORT_SYMBOL_GPL(pm_power_off);
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
EXPORT_SYMBOL_GPL(arm_pm_restart);
-void arch_cpu_idle_prepare(void)
-{
- local_fiq_enable();
-}
-
/*
* This is our default idle handler.
*/
@@ -135,7 +130,6 @@ void machine_restart(char *cmd)
/* Disable interrupts first */
local_irq_disable();
- local_fiq_disable();
/* Now call the architecture specific reboot code. */
if (arm_pm_restart)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index a0c2ca602c..94576c02f5 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -159,7 +159,6 @@ asmlinkage void secondary_start_kernel(void)
complete(&cpu_running);
local_irq_enable();
- local_fiq_enable();
local_async_enable();
/*
@@ -491,7 +490,6 @@ static void ipi_cpu_stop(unsigned int cpu)
set_cpu_online(cpu, false);
- local_fiq_disable();
local_irq_disable();
while (1)
^ permalink raw reply related
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Suravee Suthikulanit @ 2014-01-29 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129172932.GQ26622@mudshark.cambridge.arm.com>
On 1/29/2014 11:29 AM, Will Deacon wrote:
> On Wed, Jan 29, 2014 at 05:26:35PM +0000, Suravee Suthikulanit wrote:
>> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
>>> On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
>>>> Actually, we are using 32 on the AMD system. So, do you think we can set
>>>> this to 32 instead?
>>>
>>> I think that's ok.
>>>
>>> But are we really talking about number of SMRs or number of StreamIDs
>>> per master device here? Ie. are you just having 32 SMRs for an SMMU on
>>> your AMD system or do you have master devices which have 32 StreamIDs?
>>>
>>> If it's just number of SMRs we don't need to modify this macro.
>>>
>>
>> I am referring to the case where each mmu-master can have upto 32 streamID.
>
> Crikey, how many SMRs do you have? Andreas and I have been struggling to
> write a decent allocator for those, so if you have any algorithms that don't
> require a quantum computer, we'd love to hear from you :)!
>
> Will
>
Are you talking about the __arm_smmu_alloc_bitmap()?
Currently, we have configured the each SMMU to have 32 SMRs and using
15-bit streamID. However, we mostly have upto 32 streamID for each
master, and most of the SMMU only have one master. So it looks like the
current logic should be ok.
Suravee
^ permalink raw reply
* [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Jason Gunthorpe @ 2014-01-29 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-9-git-send-email-b.brezillon.dev@gmail.com>
On Wed, Jan 29, 2014 at 03:34:18PM +0100, Boris BREZILLON wrote:
> +static int sunxi_nand_chip_init_timings(struct sunxi_nand_chip *chip,
> + struct device_node *np)
> +{
> + const struct nand_sdr_timings *timings;
> + u32 min_clk_period = 0;
> + int ret;
> +
> + ret = onfi_get_async_timing_mode(&chip->nand);
> + if (ret == ONFI_TIMING_MODE_UNKNOWN) {
> + ret = of_get_nand_onfi_timing_mode(np);
> + if (ret < 0)
> + return ret;
> + }
[..]
> +static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
[..]
> + ret = sunxi_nand_chip_init_timings(chip, np);
> + if (ret)
> + return ret;
[..]
> + ret = nand_scan_ident(mtd, nsels, NULL);
This ordering looks a bit problematic, will onfi_get_async_timing_mode
ever return anything other than ONFI_TIMING_MODE_UNKNOWN if it is
called before nand_scan_ident ? What sets clk_rate to non-zero if there
is no DT property?
For a flow that uses onfi_get_async_timing_mode rather than DT the
driver should set the interface to timing mode 0 (slowest) and then
call nand_scan_ident, and then reset the interface to the detected
timing mode.
Maybe this should be implemented in the core code through a new
callback (nand->set_timing_mode ?)
Regards,
Jason
^ permalink raw reply
* [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Ezequiel Garcia @ 2014-01-29 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-4-git-send-email-b.brezillon.dev@gmail.com>
On Wed, Jan 29, 2014 at 03:34:13PM +0100, Boris BREZILLON wrote:
> nand-ecc-level property statically defines NAND chip's ECC requirements.
>
> Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> index 03855c8..0c962296 100644
> --- a/Documentation/devicetree/bindings/mtd/nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> @@ -3,5 +3,8 @@
> - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> "soft_bch".
> +- nand-ecc-level : Two cells property defining the ECC level requirements.
> + The first cell represent the strength and the second cell the ECC block size.
> + E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
> - nand-bus-width : 8 or 16 bus width if not present 8
> - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
Hm.. when was this proposal agreed? It seems I've missed the
discussion...
FWIW, we've already proposed an equivalent one, but it received no
feedback from the devicetree maintainers:
http://comments.gmane.org/gmane.linux.drivers.devicetree/58764
Maybe we can discuss about it now?
nand-ecc-strength : integer ECC required strength.
nand-ecc-size : integer step size associated to the ECC strength.
vs.
nand-ecc-level : Two cells property defining the ECC level requirements.
The first cell represent the strength and the second cell the ECC block size.
E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
It's really the same proposal but with a different format, right?
IMHO, the former is more human-readable, but other than that I see no
difference.
Brian? DT-guys?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
Integration of cpuidle with the scheduler requires that the idle loop be
closely integrated with the scheduler proper. Moving cpu/idle.c into the
sched directory will allow for a smoother integration, and eliminate a
subdirectory which contained only one source file.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
kernel/Makefile | 1 -
kernel/cpu/Makefile | 1 -
kernel/sched/Makefile | 2 +-
kernel/{cpu => sched}/idle.c | 0
4 files changed, 1 insertion(+), 3 deletions(-)
delete mode 100644 kernel/cpu/Makefile
rename kernel/{cpu => sched}/idle.c (100%)
diff --git a/kernel/Makefile b/kernel/Makefile
index bc010ee272..6f1c7e5cfc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -22,7 +22,6 @@ obj-y += sched/
obj-y += locking/
obj-y += power/
obj-y += printk/
-obj-y += cpu/
obj-y += irq/
obj-y += rcu/
diff --git a/kernel/cpu/Makefile b/kernel/cpu/Makefile
deleted file mode 100644
index 59ab052ef7..0000000000
--- a/kernel/cpu/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-y = idle.o
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 7b621409cf..ac3e0ea68f 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -11,7 +11,7 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
endif
-obj-y += core.o proc.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
+obj-y += core.o proc.o clock.o cputime.o idle_task.o idle.o fair.o rt.o stop_task.o
obj-y += wait.o completion.o
obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
diff --git a/kernel/cpu/idle.c b/kernel/sched/idle.c
similarity index 100%
rename from kernel/cpu/idle.c
rename to kernel/sched/idle.c
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 5/6] X86: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
arch/x86/kernel/process.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8..4505e2a950 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -298,10 +298,7 @@ void arch_cpu_idle_dead(void)
*/
void arch_cpu_idle(void)
{
- if (cpuidle_idle_call())
- x86_idle();
- else
- local_irq_enable();
+ x86_idle();
}
/*
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 4/6] SH: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
arch/sh/kernel/idle.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
index 2ea4483fd7..be616ee0cf 100644
--- a/arch/sh/kernel/idle.c
+++ b/arch/sh/kernel/idle.c
@@ -16,7 +16,6 @@
#include <linux/thread_info.h>
#include <linux/irqflags.h>
#include <linux/smp.h>
-#include <linux/cpuidle.h>
#include <linux/atomic.h>
#include <asm/pgalloc.h>
#include <asm/smp.h>
@@ -40,8 +39,7 @@ void arch_cpu_idle_dead(void)
void arch_cpu_idle(void)
{
- if (cpuidle_idle_call())
- sh_idle();
+ sh_idle();
}
void __init select_idle_routine(void)
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 3/6] PPC: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
The core idle loop now takes care of it. However a few things need
checking:
- Invocation of cpuidle_idle_call() in pseries_lpar_idle() happened
through arch_cpu_idle() and was therefore always preceded by a call
to ppc64_runlatch_off(). To preserve this property now that
cpuidle_idle_call() is invoked directly from core code, a call to
ppc64_runlatch_off() has been added to idle_loop_prolog() in
platforms/pseries/processor_idle.c.
- Similarly, cpuidle_idle_call() was followed by ppc64_runlatch_off()
so a call to the later has been added to idle_loop_epilog().
- And since arch_cpu_idle() always made sure to re-enable IRQs if they
were not enabled, this is now
done in idle_loop_epilog() as well.
The above was made in order to keep the execution flow close to the
original. I don't know if that was strictly necessary. Someone well
aquainted with the platform details might find some room for possible
optimizations.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/processor_idle.c | 5 ++++
arch/powerpc/platforms/pseries/setup.c | 34 ++++++++++---------------
2 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index a166e38bd6..72ddfe3d2f 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -33,6 +33,7 @@ static struct cpuidle_state *cpuidle_state_table;
static inline void idle_loop_prolog(unsigned long *in_purr)
{
+ ppc64_runlatch_off();
*in_purr = mfspr(SPRN_PURR);
/*
* Indicate to the HV that we are idle. Now would be
@@ -49,6 +50,10 @@ static inline void idle_loop_epilog(unsigned long in_purr)
wait_cycles += mfspr(SPRN_PURR) - in_purr;
get_lppaca()->wait_state_cycles = cpu_to_be64(wait_cycles);
get_lppaca()->idle = 0;
+
+ if (irqs_disabled())
+ local_irq_enable();
+ ppc64_runlatch_on();
}
static int snooze_loop(struct cpuidle_device *dev,
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index c1f1908587..7604c19d54 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -39,7 +39,6 @@
#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
-#include <linux/cpuidle.h>
#include <linux/of.h>
#include <linux/kexec.h>
@@ -356,29 +355,24 @@ early_initcall(alloc_dispatch_log_kmem_cache);
static void pseries_lpar_idle(void)
{
- /* This would call on the cpuidle framework, and the back-end pseries
- * driver to go to idle states
+ /*
+ * Default handler to go into low thread priority and possibly
+ * low power mode by cedeing processor to hypervisor
*/
- if (cpuidle_idle_call()) {
- /* On error, execute default handler
- * to go into low thread priority and possibly
- * low power mode by cedeing processor to hypervisor
- */
- /* Indicate to hypervisor that we are idle. */
- get_lppaca()->idle = 1;
+ /* Indicate to hypervisor that we are idle. */
+ get_lppaca()->idle = 1;
- /*
- * Yield the processor to the hypervisor. We return if
- * an external interrupt occurs (which are driven prior
- * to returning here) or if a prod occurs from another
- * processor. When returning here, external interrupts
- * are enabled.
- */
- cede_processor();
+ /*
+ * Yield the processor to the hypervisor. We return if
+ * an external interrupt occurs (which are driven prior
+ * to returning here) or if a prod occurs from another
+ * processor. When returning here, external interrupts
+ * are enabled.
+ */
+ cede_processor();
- get_lppaca()->idle = 0;
- }
+ get_lppaca()->idle = 0;
}
/*
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 2/6] ARM: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
arch/arm/kernel/process.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 92f7b15dd2..adabeababe 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -30,7 +30,6 @@
#include <linux/uaccess.h>
#include <linux/random.h>
#include <linux/hw_breakpoint.h>
-#include <linux/cpuidle.h>
#include <linux/leds.h>
#include <linux/reboot.h>
@@ -133,7 +132,11 @@ EXPORT_SYMBOL_GPL(arm_pm_restart);
void (*arm_pm_idle)(void);
-static void default_idle(void)
+/*
+ * Called from the core idle loop.
+ */
+
+void arch_cpu_idle(void)
{
if (arm_pm_idle)
arm_pm_idle();
@@ -168,15 +171,6 @@ void arch_cpu_idle_dead(void)
#endif
/*
- * Called from the core idle loop.
- */
-void arch_cpu_idle(void)
-{
- if (cpuidle_idle_call())
- default_idle();
-}
-
-/*
* Called by kexec, immediately prior to machine_kexec().
*
* This must completely disable all secondary CPUs; simply causing those CPUs
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
In order to integrate cpuidle with the scheduler, we must have a better
proximity in the core code with what cpuidle is doing and not delegate
such interaction to arch code.
Architectures implementing arch_cpu_idle() should simply enter
a cheap idle mode in the absence of a proper cpuidle driver.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
kernel/cpu/idle.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cpu/idle.c b/kernel/cpu/idle.c
index 988573a9a3..ffcd3ee9af 100644
--- a/kernel/cpu/idle.c
+++ b/kernel/cpu/idle.c
@@ -3,6 +3,7 @@
*/
#include <linux/sched.h>
#include <linux/cpu.h>
+#include <linux/cpuidle.h>
#include <linux/tick.h>
#include <linux/mm.h>
#include <linux/stackprotector.h>
@@ -95,7 +96,8 @@ static void cpu_idle_loop(void)
if (!current_clr_polling_and_test()) {
stop_critical_timings();
rcu_idle_enter();
- arch_cpu_idle();
+ if (cpuidle_idle_call())
+ arch_cpu_idle();
WARN_ON_ONCE(irqs_disabled());
rcu_idle_exit();
start_critical_timings();
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 0/6] setting the table for integration of cpuidle with the scheduler
From: Nicolas Pitre @ 2014-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
As everyone should know by now, we want to integrate the cpuidle
governor with the scheduler for a more efficient idling of CPUs.
In order to help the transition, this small patch series moves the
existing interaction with cpuidle from architecture code to generic
core code. The ARM, PPC, SH and X86 architectures are concerned.
No functional change should have occurred yet.
@peterz: Are you willing to pick up those patches?
Change from v1:
- dropped removal of arch_cpu_idle_prepare()
arch/arm/kernel/process.c | 16 +++------
arch/powerpc/platforms/pseries/processor_idle.c | 5 +++
arch/powerpc/platforms/pseries/setup.c | 34 ++++++++-----------
arch/sh/kernel/idle.c | 4 +--
arch/x86/kernel/process.c | 5 +--
kernel/Makefile | 1 -
kernel/cpu/Makefile | 1 -
kernel/sched/Makefile | 2 +-
kernel/{cpu => sched}/idle.c | 4 ++-
9 files changed, 30 insertions(+), 42 deletions(-)
Nicolas
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Will Deacon @ 2014-01-29 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E939CB.1020705@amd.com>
On Wed, Jan 29, 2014 at 05:26:35PM +0000, Suravee Suthikulanit wrote:
> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
> > On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
> >> Actually, we are using 32 on the AMD system. So, do you think we can set
> >> this to 32 instead?
> >
> > I think that's ok.
> >
> > But are we really talking about number of SMRs or number of StreamIDs
> > per master device here? Ie. are you just having 32 SMRs for an SMMU on
> > your AMD system or do you have master devices which have 32 StreamIDs?
> >
> > If it's just number of SMRs we don't need to modify this macro.
> >
>
> I am referring to the case where each mmu-master can have upto 32 streamID.
Crikey, how many SMRs do you have? Andreas and I have been struggling to
write a decent allocator for those, so if you have any algorithms that don't
require a quantum computer, we'd love to hear from you :)!
Will
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Suravee Suthikulanit @ 2014-01-29 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129171611.GB13543@alberich>
On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
> On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
>> On 1/29/2014 10:57 AM, Rob Herring wrote:
>>>>> diff --git a/include/linux/of.h b/include/linux/of.h
>>>>>>> index 276c546..24e1b28 100644
>>>>>>> --- a/include/linux/of.h
>>>>>>> +++ b/include/linux/of.h
>>>>>>> @@ -67,7 +67,7 @@ struct device_node {
>>>>>>> #endif
>>>>>>> };
>>>>>>>
>>>>>>> -#define MAX_PHANDLE_ARGS 8
>>>>>>> +#define MAX_PHANDLE_ARGS 16
>>>>>
>>>>>
>>>>> Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
>>>>> this be changed to be able to support 128 StreamIDs as well? Although I am
>>>>> not sure if this would be too big to have on the stack per Rob's comment in
>>>>> the previous patch set.
>>> Do you actually need 128 now? If not, then we can deal with that when
>>> we get there. There are lots of things in spec's that are not actually
>>> implemented or supported.
>>
>> Actually, we are using 32 on the AMD system. So, do you think we can set
>> this to 32 instead?
>
> I think that's ok.
>
> But are we really talking about number of SMRs or number of StreamIDs
> per master device here? Ie. are you just having 32 SMRs for an SMMU on
> your AMD system or do you have master devices which have 32 StreamIDs?
>
> If it's just number of SMRs we don't need to modify this macro.
>
>
> Andreas
>
I am referring to the case where each mmu-master can have upto 32 streamID.
Suravee
^ permalink raw reply
* [PATCH v3 4/6] ARM: tegra: Add efuse bindings
From: Rob Herring @ 2014-01-29 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-5-git-send-email-pdeschrijver@nvidia.com>
On Tue, Jan 28, 2014 at 5:36 PM, Peter De Schrijver
<pdeschrijver@nvidia.com> wrote:
> Add efuse bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
>
> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Rob
> ---
> .../devicetree/bindings/fuse/fuse-tegra.txt | 32 ++++++++++++++++++++
> arch/arm/boot/dts/tegra114.dtsi | 7 ++++
> arch/arm/boot/dts/tegra124.dtsi | 7 ++++
> arch/arm/boot/dts/tegra20.dtsi | 7 ++++
> arch/arm/boot/dts/tegra30.dtsi | 7 ++++
> 5 files changed, 60 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fuse/fuse-tegra.txt
>
> diff --git a/Documentation/devicetree/bindings/fuse/fuse-tegra.txt b/Documentation/devicetree/bindings/fuse/fuse-tegra.txt
> new file mode 100644
> index 0000000..8a566a1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fuse/fuse-tegra.txt
> @@ -0,0 +1,32 @@
> +NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 fuse driver.
> +
> +Required properties:
> +- compatible : should be:
> + "nvidia,tegra20-efuse"
> + "nvidia,tegra30-efuse"
> + "nvidia,tegra114-efuse"
> + "nvidia,tegra124-efuse"
> + Details:
> + nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data
> + due to a hardware bug. Tegra20 also lacks certain information which is
> + available in later generations such as fab code, lot code, wafer id,..
> + nvidia,tegra30-efuse, nvidia,tegra114-efuse and nvidia,tegra124-efuse:
> + The differences between these SoCs are the size of the efuse array,
> + the location of the spare (OEM programmable) bits and the location of
> + the speedo data.
> +- reg: Should contain 2 entries: the first entry gives the physical address
> + and length of the fuse registers, the second entry gives the physical
> + address and length of the apbmisc registers. These are used to provide
> + the chipid, chip revision and strapping options.
> +- clocks: Should contain a pointer to the fuse clock.
> +
> +Example:
> +
> + fuse at 7000f800 {
> + compatible = "nvidia,tegra20-efuse";
> + reg = <0x7000F800 0x400>,
> + <0x70000000 0x400>;
> + clocks = <&tegra_car TEGRA20_CLK_FUSE>;
> + };
> +
> +
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> index 389e987..05ca90b 100644
> --- a/arch/arm/boot/dts/tegra114.dtsi
> +++ b/arch/arm/boot/dts/tegra114.dtsi
> @@ -481,6 +481,13 @@
> clock-names = "pclk", "clk32k_in";
> };
>
> + fuse at 7000f800 {
> + compatible = "nvidia,tegra114-efuse";
> + reg = <0x7000f800 0x400>,
> + <0x70000000 0x400>;
> + clocks = <&tegra_car TEGRA114_CLK_FUSE>;
> + };
> +
> iommu at 70019010 {
> compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu";
> reg = <0x70019010 0x02c
> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
> index ec0698a..30faa73 100644
> --- a/arch/arm/boot/dts/tegra124.dtsi
> +++ b/arch/arm/boot/dts/tegra124.dtsi
> @@ -381,6 +381,13 @@
> clock-names = "pclk", "clk32k_in";
> };
>
> + fuse at 7000f800 {
> + compatible = "nvidia,tegra124-efuse";
> + reg = <0x7000f800 0x400>,
> + <0x70000000 0x400>;
> + clocks = <&tegra_car TEGRA124_CLK_FUSE>;
> + };
> +
> sdhci at 700b0000 {
> compatible = "nvidia,tegra124-sdhci";
> reg = <0x700b0000 0x200>;
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> index 480ecda..a1a15d7 100644
> --- a/arch/arm/boot/dts/tegra20.dtsi
> +++ b/arch/arm/boot/dts/tegra20.dtsi
> @@ -541,6 +541,13 @@
> #size-cells = <0>;
> };
>
> + fuse at 7000f800 {
> + compatible = "nvidia,tegra20-efuse";
> + reg = <0x7000F800 0x400>,
> + <0x70000000 0x400>;
> + clocks = <&tegra_car TEGRA20_CLK_FUSE>;
> + };
> +
> pcie-controller at 80003000 {
> compatible = "nvidia,tegra20-pcie";
> device_type = "pci";
> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
> index ed8e770..1ec80fa 100644
> --- a/arch/arm/boot/dts/tegra30.dtsi
> +++ b/arch/arm/boot/dts/tegra30.dtsi
> @@ -623,6 +623,13 @@
> nvidia,ahb = <&ahb>;
> };
>
> + fuse at 7000f800 {
> + compatible = "nvidia,tegra30-efuse";
> + reg = <0x7000f800 0x400>,
> + <0x70000000 0x400>;
> + clocks = <&tegra_car TEGRA30_CLK_FUSE>;
> + };
> +
> ahub at 70080000 {
> compatible = "nvidia,tegra30-ahub";
> reg = <0x70080000 0x200
> --
> 1.7.7.rc0.72.g4b5ea.dirty
>
^ permalink raw reply
* [PATCH 3/5] x86: align x86 arch with generic CPU modalias handling
From: H. Peter Anvin @ 2014-01-29 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391014246-9715-4-git-send-email-ard.biesheuvel@linaro.org>
On 01/29/2014 08:50 AM, Ard Biesheuvel wrote:
> The x86 CPU feature modalias handling existed before it was reimplemented
> generically. This patch aligns the x86 handling so that it
> (a) reuses some more code that is now generic;
> (b) uses the generic format for the modalias module metadata entry, i.e., it
> now uses 'cpu:type:x86,venVVVVfamFFFFmodMMMM:feature:,XXXX,YYYY' instead of
> the 'x86cpu:vendor:VVVV:family:FFFF:model:MMMM:feature,XXXX,YYYY' that was
> used before.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Looks good, although I have not tested it.
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
-hpa
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Andreas Herrmann @ 2014-01-29 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E93360.1000904@amd.com>
On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
> On 1/29/2014 10:57 AM, Rob Herring wrote:
> >>> diff --git a/include/linux/of.h b/include/linux/of.h
> >>> >>index 276c546..24e1b28 100644
> >>> >>--- a/include/linux/of.h
> >>> >>+++ b/include/linux/of.h
> >>> >>@@ -67,7 +67,7 @@ struct device_node {
> >>> >> #endif
> >>> >> };
> >>> >>
> >>> >>-#define MAX_PHANDLE_ARGS 8
> >>> >>+#define MAX_PHANDLE_ARGS 16
> >> >
> >> >
> >> >Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
> >> >this be changed to be able to support 128 StreamIDs as well? Although I am
> >> >not sure if this would be too big to have on the stack per Rob's comment in
> >> >the previous patch set.
> > Do you actually need 128 now? If not, then we can deal with that when
> > we get there. There are lots of things in spec's that are not actually
> > implemented or supported.
>
> Actually, we are using 32 on the AMD system. So, do you think we can set
> this to 32 instead?
I think that's ok.
But are we really talking about number of SMRs or number of StreamIDs
per master device here? Ie. are you just having 32 SMRs for an SMMU on
your AMD system or do you have master devices which have 32 StreamIDs?
If it's just number of SMRs we don't need to modify this macro.
Andreas
^ 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