* [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 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
* [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
* [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
* [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
* [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
* [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
* [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
* [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
* [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 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 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 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 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 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
* [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Boris BREZILLON @ 2014-01-29 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA6C01D@DBDE04.ent.ti.com>
Le 29/01/2014 19:02, Gupta, Pekon a ?crit :
> 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.
You meant "You do not think", right ?
If so, I think even if the retrieval and control of the GPIO is done is
each NAND
controller, we could at least use a common property name for all drivers
using
a GPIO to detect the R/B state.
> 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
I missed this thread, but I can definitely use the nand-ecc-strength and
nand-ecc-step-size instead of the one I defined (nand-ecc-level), as long
as there is a proper way to define these informations in the DT.
I'll let DT and MTD maintainers decide ;-).
Best Regards,
Boris
>
> with regards, pekon
^ permalink raw reply
* [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: Gupta, Pekon @ 2014-01-29 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA6C01D@DBDE04.ent.ti.com>
Dear Rob, and other DT maintainers,
(apologies, fixed typos in earlier mail)
>>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 _not_ 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 there are still no replies [1].
[1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html
with regards, pekon
^ permalink raw reply
* [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Boris BREZILLON @ 2014-01-29 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129175331.GA27143@localhost>
Hello Ezequiel
Le 29/01/2014 18:53, Ezequiel Garcia a ?crit :
> 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?
Never, this is a proposal based on my needs, and this was not present in the
1st version of this series :-).
> 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?
Yes it is.
> IMHO, the former is more human-readable, but other than that I see no
> difference.
As I already said to Pekon, I won't complain if my proposal is not chosen,
as long as there is a proper way to define these ECC requirements ;-).
Best Regards,
Boris
>
> Brian? DT-guys?
^ permalink raw reply
* [PATCH v3 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t
From: Andrew Morton @ 2014-01-29 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129182956.14275.72264@capellas-linux>
On Wed, 29 Jan 2014 10:29:56 -0800 Sebastian Capella <sebastian.capella@linaro.org> wrote:
> 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.
Yes, I wrote it ;)
I didn't think sysfs_streq() is well suited to this problem. And the
issue of possibly-null-terminated-strings coming in from userspace is a
common one, so it is desirable that we build up the suite of utilities
to handle this.
There are probably quite a lot of open-coded \n trimming loops which
can be cleaned up using such tools.
grep -r "if .* == '\\\n'" .
> My preference is copying the string and cleaning it up before passing
> it to internal functions, even though we incur an allocation.
Yes. Here on the kernel/userspace boundary we are typically running in
GFP_KERNEL context and the code is not performance critical - it is a
good fit.
^ permalink raw reply
* [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Ezequiel Garcia @ 2014-01-29 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129175641.GF1427@obsidianresearch.com>
On Wed, Jan 29, 2014 at 10:56:42AM -0700, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2014 at 03:34:18PM +0100, Boris BREZILLON wrote:
>
> [..]
>
> > +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.
>
Yes. And I believe this is a requirement from the ONFI 2.1 spec:
"""
4.1.4.3. Source Synchronous to Asynchronous
[..]
The host shall transition to the asynchronous data interface. Then the
host shall issue the Reset (FFh) command described in the previous paragraph
using asynchronous timing mode 0, thus the host transitions to the asynchronous
data interface prior to issuing the Reset (FFh). A device in any timing mode is
required to recognize a Reset (FFh) command issued in asynchronous timing
mode 0.
[..]
After CE# has been pulled high and then transitioned low again, the host
should issue a Set Features to select the appropriate asynchronous timing mode.
"""
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 5/6] X86: remove redundant cpuidle_idle_call()
From: Olof Johansson @ 2014-01-29 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-6-git-send-email-nicolas.pitre@linaro.org>
Hi,
On Wed, Jan 29, 2014 at 9:45 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> 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();
You're taking out the local_irq_enable() here but I don't see the
equivalent of adding it back in the 1/6 patch that moves the
cpuidle_idle_call() up to common code. It seems that one of the call
paths through cpuidle_idle_call() don't re-enable it on its own.
Even if this is the right thing to do, why it's OK to do so should
probably be documented in the patch description.
-Olof
^ permalink raw reply
* [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Boris BREZILLON @ 2014-01-29 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129175641.GF1427@obsidianresearch.com>
Le 29/01/2014 18:56, Jason Gunthorpe a ?crit :
> 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 ?
Indeed. I haven't tested this part as I don't own any board with an ONFI
compatible chip.
> What sets clk_rate to non-zero if there
> is no DT property?
It is set to 20 MHz by default, but it should definitely be set to the
rate fulfilling mode 0.
I'll fix this.
>
> 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.
Absolutely.
>
> 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 08/14] mtd: nand: add sunxi NAND flash controller support
From: Jason Gunthorpe @ 2014-01-29 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129184619.GC27143@localhost>
On Wed, Jan 29, 2014 at 03:46:20PM -0300, Ezequiel Garcia wrote:
> After CE# has been pulled high and then transitioned low again, the host
> should issue a Set Features to select the appropriate asynchronous timing mode.
> """
Oh, I had forgot you should do a set feature too
Boris, I think the core core should handle this dance and the driver
should just implement a call back to change the timing mode on the
interface..
If I ever get a moment I can work on support for timing setting in the
mvebu driver, I have boards here with ONFI NAND..
Regards,
Jason
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-29 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E92494.1090407@nod.at>
On Wed, Jan 29, 2014 at 04:56:04PM +0100, Richard Weinberger wrote:
> Does the issue also happen if you disable preemption?
> i.e. CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT_NONE=y still breaks. I suspect that sync_filesystem
has some blocking behavior that allows other processes to schedule.
Another log is attached and the patch I used to create this log is
below. I think the most interesting part of this patch is the last hunk
that modifies ubifs_remount_ro. This clearly shows that after the mount
has been marked as read-only we have dirty inodes waiting for the
writeback to come in and hit all the asserts.
Here's some of the important parts of the log:
170 pre sync_filesystem
# Notice that while we were running sync_filesystem
# a inode (0xd75ab658) snuck in with a sys_rename
204 inode: d75ab658
205 ------------[ cut here ]------------
206 WARNING: CPU: 0 PID: 625 at fs/fs-writeback.c:1213 __mark_inode_dirty+0x2a4/0x2f4()
207 Modules linked in:
208 CPU: 0 PID: 625 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #250
209 [<c0014f54>] (unwind_backtrace+0x0/0x128) from [<c001235c>] (show_stack+0x20/0x24)
210 [<c001235c>] (show_stack+0x20/0x24) from [<c0344574>] (dump_stack+0x20/0x28)
211 [<c0344574>] (dump_stack+0x20/0x28) from [<c00206d4>] (warn_slowpath_common+0x78/0x98)
212 [<c00206d4>] (warn_slowpath_common+0x78/0x98) from [<c00207b0>] (warn_slowpath_null+0x2c/0x34)
213 [<c00207b0>] (warn_slowpath_null+0x2c/0x34) from [<c00f0e8c>] (__mark_inode_dirty+0x2a4/0x2f4)
214 [<c00f0e8c>] (__mark_inode_dirty+0x2a4/0x2f4) from [<c0136428>] (ubifs_rename+0x4a4/0x600)
215 [<c0136428>] (ubifs_rename+0x4a4/0x600) from [<c00d9f44>] (vfs_rename+0x280/0x3f4)
216 [<c00d9f44>] (vfs_rename+0x280/0x3f4) from [<c00dabe4>] (SyS_renameat+0x18c/0x218)
217 [<c00dabe4>] (SyS_renameat+0x18c/0x218) from [<c00dac9c>] (SyS_rename+0x2c/0x30)
218 [<c00dac9c>] (SyS_rename+0x2c/0x30) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
219 ---[ end trace 35ebec8569a53526 ]---
754 post sync_filesystem
755 pre prepare_remount
756 post prepare_remount
757 prepare_remount success
758 UBIFS: background thread "ubifs_bgt0_0" stops
759 we are now a read-only mount
760 bdi.work_list = d7ac4110, .next = d7ac4110
# WE HAVE DIRTY I/O (notice the .next != &b_dirty)
761 bdi.wb.b_dirty = d7ac40d8, .next = d75accd0
762 bdi.wb.b_io = d7ac40e0, .next = d7ac40e0
763 bdi.wb.b_more_io = d7ac40e8, .next = d7ac40e8
764 do_remount_sb success
# And now our friend (inode 0xd75ab658) comes in with a writeback after
# we are read-only triggering the assert
779 inode: d75ab658
780 UBIFS assert failed in reserve_space at 125 (pid 11)
781 CPU: 0 PID: 11 Comm: kworker/u2:1 Tainted: G W 3.12.0-00041-g7f12d39-dirty #250
782 Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
783 [<c0014f54>] (unwind_backtrace+0x0/0x128) from [<c001235c>] (show_stack+0x20/0x24)
784 [<c001235c>] (show_stack+0x20/0x24) from [<c0344574>] (dump_stack+0x20/0x28)
785 [<c0344574>] (dump_stack+0x20/0x28) from [<c012f90c>] (make_reservation+0x8c/0x560)
786 [<c012f90c>] (make_reservation+0x8c/0x560) from [<c0130c60>] (ubifs_jnl_write_inode+0xbc/0x214)
787 [<c0130c60>] (ubifs_jnl_write_inode+0xbc/0x214) from [<c0137ce0>] (ubifs_write_inode+0xec/0x17c)
788 [<c0137ce0>] (ubifs_write_inode+0xec/0x17c) from [<c00f0a00>] (__writeback_single_inode+0x1fc/0x308)
789 [<c00f0a00>] (__writeback_single_inode+0x1fc/0x308) from [<c00f1780>] (writeback_sb_inodes+0x1f8/0x3c4)
790 [<c00f1780>] (writeback_sb_inodes+0x1f8/0x3c4) from [<c00f19cc>] (__writeback_inodes_wb+0x80/0xc0)
791 [<c00f19cc>] (__writeback_inodes_wb+0x80/0xc0) from [<c00f1ba4>] (wb_writeback+0x198/0x310)
792 [<c00f1ba4>] (wb_writeback+0x198/0x310) from [<c00f2328>] (bdi_writeback_workfn+0x15c/0x454)
793 [<c00f2328>] (bdi_writeback_workfn+0x15c/0x454) from [<c0038348>] (process_one_work+0x280/0x420)
794 [<c0038348>] (process_one_work+0x280/0x420) from [<c00389e4>] (worker_thread+0x240/0x380)
795 [<c00389e4>] (worker_thread+0x240/0x380) from [<c003dff8>] (kthread+0xbc/0xc8)
796 [<c003dff8>] (kthread+0xbc/0xc8) from [<c000e8b0>] (ret_from_fork+0x14/0x20)
- Andy
--- patch ---
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 9f4935b..48e4272 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -93,6 +93,10 @@ static void bdi_queue_work(struct backing_dev_info *bdi,
{
trace_writeback_queue(bdi, work);
+ do {
+ extern bool ubifs_enable_debug;
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
spin_lock_bh(&bdi->wb_lock);
list_add_tail(&work->list, &bdi->work_list);
spin_unlock_bh(&bdi->wb_lock);
@@ -194,6 +198,11 @@ static void redirty_tail(struct inode *inode, struct bdi_writeback *wb)
if (time_before(inode->dirtied_when, tail->dirtied_when))
inode->dirtied_when = jiffies;
}
+ do {
+ extern bool ubifs_enable_debug;
+ if (ubifs_enable_debug) pr_info("inode: %p\n", inode);
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
list_move(&inode->i_wb_list, &wb->b_dirty);
}
@@ -204,6 +213,11 @@ static void requeue_io(struct inode *inode, struct bdi_writeback *wb)
{
assert_spin_locked(&wb->list_lock);
list_move(&inode->i_wb_list, &wb->b_more_io);
+ do {
+ extern bool ubifs_enable_debug;
+ if (ubifs_enable_debug) pr_info("inode: %p\n", inode);
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
}
static void inode_sync_complete(struct inode *inode)
@@ -437,6 +451,8 @@ __writeback_single_inode(struct inode *inode, struct writeback_control *wbc)
unsigned dirty;
int ret;
+ extern bool ubifs_enable_debug;
+ if (ubifs_enable_debug) pr_info("inode: %p\n", inode);
WARN_ON(!(inode->i_state & I_SYNC));
trace_writeback_single_inode_start(inode, wbc, nr_to_write);
@@ -1191,6 +1207,11 @@ void __mark_inode_dirty(struct inode *inode, int flags)
inode->dirtied_when = jiffies;
list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
+ do {
+ extern bool ubifs_enable_debug;
+ if (ubifs_enable_debug) pr_info("inode: %p\n", inode);
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
spin_unlock(&bdi->wb.list_lock);
if (wakeup_bdi)
diff --git a/fs/super.c b/fs/super.c
index 0225c20..29afc68 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -737,6 +737,12 @@ int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
int retval;
int remount_ro;
+ extern bool ubifs_enable_debug;
+ if (flags & MS_RDONLY) {
+ ubifs_enable_debug = true;
+ }
+ WARN_ON(ubifs_enable_debug);
+
if (sb->s_writers.frozen != SB_UNFROZEN)
return -EBUSY;
@@ -747,8 +753,11 @@ int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
if (flags & MS_RDONLY)
acct_auto_close(sb);
+ pr_info("pre shrink_dcache_sb\n");
shrink_dcache_sb(sb);
+ pr_info("pre sync_filesystem\n");
sync_filesystem(sb);
+ pr_info("post sync_filesystem\n");
remount_ro = (flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY);
@@ -758,9 +767,12 @@ int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
if (force) {
mark_files_ro(sb);
} else {
+ pr_info("pre prepare_remount\n");
retval = sb_prepare_remount_readonly(sb);
+ pr_info("post prepare_remount\n");
if (retval)
return retval;
+ pr_info("prepare_remount success\n");
}
}
@@ -789,6 +801,7 @@ int do_remount_sb(struct super_block *sb, int flags, void *data, int force)
*/
if (remount_ro && sb->s_bdev)
invalidate_bdev(sb->s_bdev);
+ pr_info("do_remount_sb success\n");
return 0;
cancel_readonly:
diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index 123c79b..c9f2d5d 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -902,6 +902,8 @@ static int do_writepage(struct page *page, int len)
struct inode *inode = page->mapping->host;
struct ubifs_info *c = inode->i_sb->s_fs_info;
+ WARN_ON(c->ro_mount);
+
#ifdef UBIFS_DEBUG
spin_lock(&ui->ui_lock);
ubifs_assert(page->index <= ui->synced_i_size << PAGE_CACHE_SIZE);
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 3e4aa72..8cbb731 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -38,6 +38,8 @@
#include <linux/writeback.h>
#include "ubifs.h"
+bool ubifs_enable_debug;
+
/*
* Maximum amount of memory we may 'kmalloc()' without worrying that we are
* allocating too much.
@@ -1756,6 +1758,11 @@ static void ubifs_remount_ro(struct ubifs_info *c)
err = dbg_check_space_info(c);
if (err)
ubifs_ro_mode(c, err);
+ pr_info("we are now a read-only mount\n");
+ pr_info("bdi.work_list = %p, .next = %p\n", &c->bdi.work_list, c->bdi.work_list.next);
+ pr_info("bdi.wb.b_dirty = %p, .next = %p\n", &c->bdi.wb.b_dirty, c->bdi.wb.b_dirty.next);
+ pr_info("bdi.wb.b_io = %p, .next = %p\n", &c->bdi.wb.b_io, c->bdi.wb.b_io.next);
+ pr_info("bdi.wb.b_more_io = %p, .next = %p\n", &c->bdi.wb.b_more_io, c->bdi.wb.b_more_io.next);
mutex_unlock(&c->umount_mutex);
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: experiments11.small.txt.gz
Type: application/x-gunzip
Size: 5974 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140129/fc352ff5/attachment-0001.bin>
^ permalink raw reply related
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Varun Sethi @ 2014-01-29 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129141429.GD19326@alberich>
> -----Original Message-----
> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> bounces at lists.linux-foundation.org] On Behalf Of Andreas Herrmann
> Sent: Wednesday, January 29, 2014 7:44 PM
> To: Sethi Varun-B16395
> Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; Will Deacon;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> notifier block
>
> On Tue, Jan 28, 2014 at 11:00:35AM +0000, Varun Sethi wrote:
> >
> >
> > > -----Original Message-----
> > > From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> > > bounces at lists.linux-foundation.org] On Behalf Of Andreas Herrmann
> > > Sent: Friday, January 24, 2014 1:27 AM
> > > To: Sethi Varun-B16395
> > > Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; Will Deacon;
> > > linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> > > notifier block
> > >
> > > On Wed, Jan 22, 2014 at 07:07:40PM +0000, Varun Sethi wrote:
> > > > > -----Original Message-----
> > > > > From: Will Deacon [mailto:will.deacon at arm.com]
> > > > > Sent: Wednesday, January 22, 2014 9:04 PM
> > > > > To: Sethi Varun-B16395
> > > > > Cc: Andreas Herrmann; iommu at lists.linux-foundation.org;
> > > > > linux-arm- kernel at lists.infradead.org; Andreas Herrmann
> > > > > Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce
> > > > > iommu_group notifier block
> > > > >
> > > > > On Wed, Jan 22, 2014 at 01:54:11PM +0000, Varun Sethi wrote:
> > > > > > > > > Ok, so are you suggesting that we perform the isolation
> > > > > > > > > mapping in arm_smmu_add_device and drop the notifier
> > > altogether?
> > > > > > > > I think that should be fine, until we want to delay
> > > > > > > > mapping creation till driver bind time.
> > > > > > >
> > > > > > > Is there a hard dependency on that?
> > > > > > >
> > > > > > Not sure, may be Andreas can answer that.
> > > > >
> > > > > Ok. Andreas? I would have thought doing this *earlier* shouldn't
> > > > > be a problem (the DMA ops must be swizzled before the driver is
> probed).
> > > > >
> > > > > > > > But the "isolate device" property should dictate iommu
> > > > > > > > group
> > > > > creation.
> > > > > > >
> > > > > > > The reason we added automatic group creation (per-device) is
> > > > > > > for VFIO, which expects all devices to be in a group
> > > > > > > regardless of the device isolation configuration.
> > > > > > >
> > > > > > IIUC, with the "isolate devices" property we ensure that there
> > > > > > would be independent SMR and S2CR per device. Is that correct?
> > > > >
> > > > > Yes, as part of giving them independent sets of page tables.
> > > > > Initially these tables don't have any valid mappings, but the
> > > > > dma-mapping API will populate them in response to
> > > dma_map_*/dma_alloc/etc.
> > > > >
> > > > > Not sure what this has to do with us putting devices into their
> > > > > own groups...
> > >
> > > > [Sethi Varun-B16395] Devices in an iommu group would share the dma
> > > > mapping, so shouldn't they be sharing the SMR and context
> registers?
> > >
> > > I aggree with the context but SMRs won't be shared. I think you just
> > > can say that a certain subset of the available SMRs will be used to
> > > map all devices in an iommu group to the same context. Depending on
> > > what streamIDs each device has you might have to use separate SMRs
> > > for each device to map it to the same context.
>
> > [Sethi Varun-B16395] IIUC the SMRs would unique per device, but there
> > is a possibility where the number of context registers are restricted?
> > In that case IOMMU groups should correspond to unique stream IDs (and
> > corresponding SMRs).
>
> > > > In case of the "isolate devices" property, each device would have
> > > > its own SMR and context registers, thus allowing the devices to
> > > > have independent mappings and allowing them to fall in separate
> > > > iommu groups.
> > >
> > > I aggree with Varun's view here. (Now that I take iommu groups into
> > > consideration.)
> > >
> > > But my goal with the "isolate devices" thing was twofold:
> > >
> > > 1. actual make use of SMMU for address translation for all master
> > > devices (instead of just bypassing the SMMU)
>
> > [Sethi Varun-B16395] even if masters have to share translation? But
> > from the patch it seemed that we are creating mapping only if we find
> > the isolate devices property.
>
> Yes, the patch creates mappings only if isolate-devices property is
> given. Currently there is no trigger to create a common mapping for all
> devices attached to the same SMMU.
>
> > > plus
> > >
> > > 2. put each master into it's own domain to isolate it
> > >
> > > The latter matches usage of separate iommu groups for devices. If we
> > > now use the isolate devices property to just control whether master
> > > devices fall into the same or separate iommu groups it seems to me
> > > we would need to have another mechanism that triggers the creation
> > > of a mapping for a group.
> > >
> > > What do you think?
> > >
>
> > [Sethi Varun-B16395] As mentioned before, we should be having iommu
> > group per device (having a unique stream id). Isolate devices property
> > just ensures that each device has a unique context. Now, for the
> > devices for which we don't have the isolate device property, can't we
> > have the multiple devices point to a common mapping.
>
> Hmm, the isolate-devices option is per SMMU. So if this is set for an
> SMMU the driver tries to create a mapping per device. (And this is done
> for all master devices of this SMMU.)
>
> Are you requesting to change the default behaviour of the driver to
> create a shared mapping in case the isolate-devices property is not
> specified in DT for an SMMU node?
>
> Or maybe your concern is that you have x master devices for an SMMU which
> support y number of contexts and x > y? Which would imply that not all
> devices can be isolated and some need to share a context?
>
[Sethi Varun-B16395] I am trying to understand the requirement for the "isolate devices" property. Currently no default in mapping is created in the SMMU driver. The new property allows default mapping to be created for all masters. Why can't we create default mappings for all masters without this property?
-Varun
^ 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