* [PATCH 09/20] ARM64 / ACPI: Implement core functions for parsing MADT table
From: Hanjun Guo @ 2014-01-24 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E15756.4060705@arm.com>
Hi Marc,
On 2014?01?24? 01:54, Marc Zyngier wrote:
> Hi Hanjun,
>
> On 17/01/14 12:25, Hanjun Guo wrote:
>> Implement core functions for parsing MADT table to get the information
>> about GIC cpu interface and GIC distributor to prepare for SMP and GIC
>> initialization.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/include/asm/acpi.h | 3 +
>> drivers/acpi/plat/arm-core.c | 139 ++++++++++++++++++++++++++++++++++++++++-
>> drivers/acpi/tables.c | 21 +++++++
>> 3 files changed, 162 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index e108d9c..c335c6d 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -83,6 +83,9 @@ void arch_fix_phys_package_id(int num, u32 slot);
>> extern int (*acpi_suspend_lowlevel)(void);
>> #define acpi_wakeup_address (0)
>>
>> +#define MAX_GIC_CPU_INTERFACE 256
> I'll bite. Where on Earth is this value coming from?
I just thought 256 is big enough for now :(
Yes, should be a larger number for GICv3.
> If that's for
> GICv2, 8 is the maximum. For GICv3+, that's incredibly low, and should
> be probed probed at runtime anyway.
I would prefer to do that, but this value is used to
probe CPUs in MADT :)
>
>> +#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> No support for cascaded GICs?
Yes, no cascade GICs in ACPI at now.
>
>> +
>> #else /* !CONFIG_ACPI */
>> #define acpi_disabled 1 /* ACPI sometimes enabled on ARM */
>> #define acpi_noirq 1 /* ACPI sometimes enabled on ARM */
>> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
>> index 1835b21..8ba3e6f 100644
>> --- a/drivers/acpi/plat/arm-core.c
>> +++ b/drivers/acpi/plat/arm-core.c
>> @@ -46,6 +46,16 @@ EXPORT_SYMBOL(acpi_disabled);
>> int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
>> EXPORT_SYMBOL(acpi_pci_disabled);
>>
>> +/*
>> + * Local interrupt controller address,
>> + * GIC cpu interface base address on ARM/ARM64
>> + */
>> +static u64 acpi_lapic_addr __initdata;
> If that's a GIC address, why not call it as such?
thanks for the suggesting, I will update.
>
>> +#define BAD_MADT_ENTRY(entry, end) ( \
>> + (!entry) || (unsigned long)entry + sizeof(*entry) > end || \
>> + ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
>> +
>> #define PREFIX "ACPI: "
> Just do:
> #define pr_fmt(fmt) "ACPI: " fmt
>
> and remove all the occurrences of PREFIX.
>
>> /* FIXME: this function should be moved to topology.c when it is ready */
>> @@ -92,6 +102,115 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>> return;
>> }
>>
>> +static int __init acpi_parse_madt(struct acpi_table_header *table)
>> +{
>> + struct acpi_table_madt *madt = NULL;
> No need to initialize this to NULL, you're doing an assignment at the
> next line...
>
>> +
>> + madt = (struct acpi_table_madt *)table;
>> + if (!madt) {
>> + pr_warn(PREFIX "Unable to map MADT\n");
> There is no mapping here, please fix the message accordingly.
Ok, I will address your comments above in next version.
>
>> + return -ENODEV;
>> + }
>> +
>> + if (madt->address) {
>> + acpi_lapic_addr = (u64) madt->address;
> So you're updating this static variable, for the distributor and each
> CPU interface? /me puzzled...
Good catch. So I have a question: do we really have some SoCs
without banked registers on ARM64? if not , I think we can use
a single static variable is ok.
>
>> + pr_info(PREFIX "Local APIC address 0x%08x\n", madt->address);
> Away with this APIC madness. GICC and GICD are the concepts we're all
> familiar with here, and using the proper terminology would certainly
> help reviewing these patches...
That make sense to me too, will update.
>
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * GIC structures on ARM are somthing like Local APIC structures on x86,
>> + * which means GIC cpu interfaces for GICv2/v3. Every GIC structure in
>> + * MADT table represents a cpu in the system.
> And what do you do when your GICv3 doesn't have a memory-mapped
> interface, but only uses system registers?
>
>> + * GIC distributor structures are somthing like IOAPIC on x86. GIC can
>> + * be initialized with information in this structure.
>> + *
>> + * Please refer to chapter5.2.12.14/15 of ACPI 5.0
> A pointer to that documentation?
Please refer to http://www.acpi.info/
>
>> + */
>> +
>> +static int __init
>> +acpi_parse_gic(struct acpi_subtable_header *header, const unsigned long end)
>> +{
>> + struct acpi_madt_generic_interrupt *processor = NULL;
>> +
>> + processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> + if (BAD_MADT_ENTRY(processor, end))
>> + return -EINVAL;
>> +
>> + acpi_table_print_madt_entry(header);
>> +
>> + return 0;
>> +}
>> +
>> +static int __init
>> +acpi_parse_gic_distributor(struct acpi_subtable_header *header,
>> + const unsigned long end)
>> +{
>> + struct acpi_madt_generic_distributor *distributor = NULL;
>> +
>> + distributor = (struct acpi_madt_generic_distributor *)header;
>> +
>> + if (BAD_MADT_ENTRY(distributor, end))
>> + return -EINVAL;
>> +
>> + acpi_table_print_madt_entry(header);
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC cpu interface related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_entries(void)
>> +{
>> + int count;
>> +
>> + /*
>> + * do a partial walk of MADT to determine how many CPUs
>> + * we have including disabled CPUs
>> + */
>> + count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
>> + acpi_parse_gic, MAX_GIC_CPU_INTERFACE);
>> +
>> + if (!count) {
>> + pr_err(PREFIX "No GIC entries present\n");
>> + return -ENODEV;
>> + } else if (count < 0) {
>> + pr_err(PREFIX "Error parsing GIC entry\n");
>> + return count;
>> + }
> So you do a lot of parsing to count stuff, and then discard the number
> of counted objects... You might as well check that there is at least one
> valid object and stop there.
>
>> + return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC distributor related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_distributor_entries(void)
>> +{
>> + int count;
>> +
>> + count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
>> + acpi_parse_gic_distributor, MAX_GIC_DISTRIBUTOR);
>> +
>> + if (!count) {
>> + pr_err(PREFIX "No GIC distributor entries present\n");
>> + return -ENODEV;
>> + } else if (count < 0) {
>> + pr_err(PREFIX "Error parsing GIC distributor entry\n");
>> + return count;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
>> {
>> *irq = gsi_to_irq(gsi);
>> @@ -141,11 +260,29 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>
>> static void __init early_acpi_process_madt(void)
>> {
>> - return;
>> + acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
>> }
>>
>> static void __init acpi_process_madt(void)
>> {
>> + int error;
>> +
>> + if (!acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt)) {
> How many times are you going to parse the same table? Surely you can
> stash whatever information you need and be done with it?
good catch, we already addressed this problem, and will
update in next version.
>
>> + /*
>> + * Parse MADT GIC cpu interface entries
>> + */
>> + error = acpi_parse_madt_gic_entries();
>> + if (!error) {
>> + /*
>> + * Parse MADT GIC distributor entries
>> + */
>> + acpi_parse_madt_gic_distributor_entries();
>> + }
>> + }
>> +
>> + pr_info("Using ACPI for processor (GIC) configuration information\n");
>> +
>> return;
>> }
>>
>> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>> index d67a1fe..b3e4615 100644
>> --- a/drivers/acpi/tables.c
>> +++ b/drivers/acpi/tables.c
>> @@ -191,6 +191,27 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>> }
>> break;
>>
>> + case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
>> + {
>> + struct acpi_madt_generic_interrupt *p =
>> + (struct acpi_madt_generic_interrupt *)header;
>> + printk(KERN_INFO PREFIX
> Use pr_info
this function use printk always, should change all of them?
>
>> + "GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
>> + p->uid, p->gic_id,
>> + (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
>> + }
>> + break;
>> +
>> + case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
>> + {
>> + struct acpi_madt_generic_distributor *p =
>> + (struct acpi_madt_generic_distributor *)header;
>> + printk(KERN_INFO PREFIX
>> + "GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
>> + p->gic_id, p->base_address, p->global_irq_base);
>> + }
>> + break;
>> +
>> default:
>> printk(KERN_WARNING PREFIX
>> "Found unsupported MADT entry (type = 0x%x)\n",
>>
> Most of that code seems to be repeatedly parsing and printing stuff, and
> I fail to see what it actually does.
yes, just print some information when booting.
Thank you very much for the comments.
Hanjun
^ permalink raw reply
* [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
From: Shawn Guo @ 2014-01-24 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124115005.GG814@e106331-lin.cambridge.arm.com>
On Fri, Jan 24, 2014 at 11:50:05AM +0000, Mark Rutland wrote:
> > @@ -18,6 +18,19 @@
> > memory {
> > reg = <0x10000000 0x80000000>;
> > };
> > +
> > + regulators {
> > + compatible = "simple-bus";
>
> This is _not_ a simple bus. It doesn't have the required ranges
> property.
Maybe the real question is that if the required ranges property is
missing, why kernel still accepts it as a simple bus and populate the
devices under it?
>
> Why do these need to be in a regulators container node? We don't group
> dma controllers under a dmas node, or uarts under a uarts node.
Grouping fixed clocks under 'clocks' and fixed regulators under
'regulators' is a common pattern which can be found on most of the ARM
dts files.
Shawn
>
> > +
> > + reg_usb_otg_vbus: usb_otg_vbus {
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb_otg_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + gpio = <&gpio4 15 0>;
> > + enable-active-low;
> > + };
> > + };
> > };
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH] sunxi: dts: add a note that memory size is adjusted by boot loader.
From: Hans de Goede @ 2014-01-24 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390572852-15027-1-git-send-email-ijc@hellion.org.uk>
Hi,
On 01/24/2014 03:14 PM, Ian Campbell wrote:
> I had to spend a couple of minutes proving to myself that this was the case on
> cubietruck, so add a comment to save the next guy some effort.
Seems like a good idea to me, one small nitpick though see comments inline.
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-sunxi at googlegroups.com
> ---
> This patch applies cleanly against v3.13 and Hans' sunxi-devel branch.
>
> A plausible alternative would be to pull the memory node out of the dtsi files
> and into the board specific files. I didn't go straight to that since I'd have
> to research all the various boards ;-)
That won't help, some boards ie the original cubieboard and the mele-a1000 come
in both 512 MB and 1024 MB versions, and I don't think we want to start maintaining
2 different dts files just for that.
>
> I considered maing it "reg = <0 0>" but decided that having some sort of least
> common denominator would let things work even if the bootloader were broken.
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
> arch/arm/boot/dts/sun5i-a10s.dtsi | 1 +
> arch/arm/boot/dts/sun5i-a13.dtsi | 1 +
> arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
> arch/arm/boot/dts/sun7i-a20.dtsi | 1 +
> 5 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 3e60883..9ba0beb 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -30,6 +30,7 @@
> };
>
> memory {
> + /* 1GB by default, will be updated by U-Boot */
> reg = <0x40000000 0x80000000>;
> };
>
The comment says 1GB, but the range says 2GB, note 2GB is consistent with what the
datasheet claims as max RAM.
> diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
> index 0376c50..d12ed7e 100644
> --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
> @@ -27,6 +27,7 @@
> };
>
> memory {
> + /* 512MB by default, will be updated by U-Boot */
> reg = <0x40000000 0x20000000>;
> };
>
This seems wrong (copy paste from A13 error) I've a10s boards with 1G, and the data
sheet claims 2GB max RAM.
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> index b81aeb9..6f8bfd9 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -27,6 +27,7 @@
> };
>
> memory {
> + /* 512MB by default, will be updated by U-Boot */
> reg = <0x40000000 0x20000000>;
> };
>
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index 3f6f07b..bcbef9a 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -46,6 +46,7 @@
> };
>
> memory {
> + /* 2GB by default, will be updated by U-Boot */
> reg = <0x40000000 0x80000000>;
> };
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 907cfcc..658e74b 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -38,6 +38,7 @@
> };
>
> memory {
> + /* 1GB by default, will be updated by U-Boot */
> reg = <0x40000000 0x80000000>;
> };
The comment says 1GB, but the range says 2GB, note 2GB is consistent with what the
datasheet claims as max RAM.
Regards,
Hans
^ permalink raw reply
* [PATCH v2 3/7] devicetree: bindings: add cpu clock configuration data binding for Exynos4/5
From: Thomas Abraham @ 2014-01-24 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9ai+5+t=WKvvxK7MzriAFd2fBXOVVt9YgZ18XQ5a9mr4Og@mail.gmail.com>
Hi Rob,
On Tue, Jan 21, 2014 at 1:01 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> Hi Rob,
>
>
> On Sat, Jan 18, 2014 at 8:52 PM, Rob Herring <robherring2@gmail.com> wrote:
>> On Sat, Jan 18, 2014 at 6:10 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> The clk ops of the new Samsung cpu clock provider type requires configuration
>>> data that will be programmed in the multiple clock blocks encapsulated within
>>> the cpu clock provider type. This configuration data is held in the clock
>>> controller node. Update clock binding documentation about this configuration
>>> data format for Samsung Exynos4 and Exynos5 platforms.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>
>> Please copy all maintainers.
>
> Okay.
>
>>
>>> Cc: Tomasz Figa <t.figa@samsung.com>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>> .../devicetree/bindings/clock/exynos4-clock.txt | 30 ++++++++++++++++++++
>>> .../devicetree/bindings/clock/exynos5250-clock.txt | 21 ++++++++++++++
>>> 2 files changed, 51 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
>>> index a2ac2d9..c28aabd 100644
>>> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
>>> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
>>> @@ -15,6 +15,29 @@ Required Properties:
>>>
>>> - #clock-cells: should be 1.
>>>
>>> +- arm-frequency-table: defines the list of arm clock speeds supported and
>>
>> Seems like a Samsung specific property and nothing to do with ARM, so
>> it should be named accordingly.
>
> Okay.
>
>>
>>> + the associated configuration values required to setup the clock controller
>>> + for generating those speeds. The format of each entry included in the
>>> + arm-frequency-table should be as defined below (#cells per entry = 13)
>>> +
>>> + - for Exynos4210 and Exynos4212 based platforms:
>>> + cell #1: arm clock frequency
>>> + cell #2: expected arm clock parent frequency
>>> + cell #3 ~ cell 12#: value of clock divider in the following order
>>> + core_ratio, corem0_ratio, corem1_ratio, periph_ratio,
>>> + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio,
>>> + copy_ratio, hpm_ratio.
>>> + cell #13: reserved (should be zero).
>>> +
>>> + - for Exynos4412 based platforms:
>>> + cell #1: arm clock frequency
>>> + cell #2: expected arm clock parent frequency
>>> + cell #3 ~ cell #13: value of clock divider in the following order
>>> + core_ratio, corem0_ratio, corem1_ratio, periph_ratio,
>>> + atb_ratio, pclk_dbg_ratio, apll_ratio, core2_ratio,
>>> + copy_ratio, hpm_ratio, cores_ratio
>>
>> You don't need voltages? Are the h/w limitations really ratios or each
>> clock has a max frequency that must be maintained? I would expect the
>> latter and think it would be better to specify maximum frequencies of
>> each clock. Then you can calculate the dividers to keep frequencies in
>> range.
>
> Voltage is not needed here since the cpu clock speed is managed by the
> cpufreq driver which will take care of setting appropriate voltage.
> Any other users apart from cpufreq will have to setup the voltage
> appropriately.
>
> About the ratios, yes the user manual lists the optimal clock
> frequency for these clocks. As suggested, I will remove the ratio list
> for these clocks.
I tried the approach of listing the optimal frequencies of these
clocks in dt and then calculating a divider value. But it turns out
that the divider values for these clocks is dependent on the frequency
of the PLL from which they are derived (or the voltage applied to the
CPU clock domain). During tests, the system is unstable if divider
values are calculated using the optimal clock speed listed in the SoC
manual.
So the list of divider values as used in this series (and documented
above) is required. Can I continue to use the binding as documented
above?
Thanks,
Thomas.
>
>>
>> How will this scale to multi-cluster chips with different frequency ranges?
>
> Usually, each cluster would have its own independent clock input. So
> there will be two or more cpu clocks in multi-cluster chips. So the
> clocks can be independently programmed as required by the cluster.
>
>>
>> Rob
>>
>
> Thanks Rob for your review.
>
> Thomas.
>
>>> +
>>> +
>>> The following is the list of clocks generated by the controller. Each clock is
>>> assigned an identifier and client nodes use this identifier to specify the
>>> clock which they consume. Some of the clocks are available only on a particular
>>> @@ -275,6 +298,13 @@ Example 1: An example of a clock controller node is listed below.
>>> compatible = "samsung,exynos4210-clock";
>>> reg = <0x10030000 0x20000>;
>>> #clock-cells = <1>;
>>> +
>>> + arm-frequency-table = <1200000 1200000 0 3 7 3 4 1 7 0 5 0>,
>>> + <1000000 1000000 0 3 7 3 4 1 7 0 4 0>,
>>> + < 800000 800000 0 3 7 3 3 1 7 0 3 0>,
>>> + < 500000 500000 0 3 7 3 3 1 7 0 3 0>,
>>> + < 400000 400000 0 3 7 3 3 1 7 0 3 0>,
>>> + < 200000 200000 0 1 3 1 1 1 0 0 3 0>;
>>> };
>>>
>>> Example 2: UART controller node that consumes the clock generated by the clock
>>> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>>> index 72ce617..99eae9c 100644
>>> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>>> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>>> @@ -13,6 +13,20 @@ Required Properties:
>>>
>>> - #clock-cells: should be 1.
>>>
>>> +- arm-frequency-table: defines the list of arm clock speeds supported and
>>> + the associated configuration values required to setup the clock controller
>>> + for generating those speeds. The format of each entry included in the
>>> + arm-frequency-table should be as defined below (#cells per entry = 13)
>>> +
>>> + cell #1: arm clock frequency
>>> + cell #2: expected arm clock parent frequency
>>> + cell #3 ~ cell #12: value of clock divider in the following order
>>> + arm_ratio, cpud_ratio, acp_ratio, periph_ratio,
>>> + atb_ratio, pclk_dbg_ratio, apll_ratio, arm2_ratio,
>>> + copy_ratio, hpm_ratio
>>> + cell #13: reserved (should be zero)
>>> +
>>> +
>>> The following is the list of clocks generated by the controller. Each clock is
>>> assigned an identifier and client nodes use this identifier to specify the
>>> clock which they consume.
>>> @@ -177,6 +191,13 @@ Example 1: An example of a clock controller node is listed below.
>>> compatible = "samsung,exynos5250-clock";
>>> reg = <0x10010000 0x30000>;
>>> #clock-cells = <1>;
>>> +
>>> + arm-frequency-table = <1700000 1700000 0 3 7 7 7 3 5 0 0 2>,
>>> + <1600000 1600000 0 3 7 7 7 1 4 0 0 2>,
>>> + <1500000 1500000 0 2 7 7 7 1 4 0 0 2>,
>>> + <1400000 1400000 0 2 7 7 6 1 4 0 0 2>,
>>> + <1300000 1300000 0 2 7 7 6 1 3 0 0 2>,
>>> + <1200000 1200000 0 2 7 7 5 1 3 0 0 2>;
>>> };
>>>
>>> Example 2: UART controller node that consumes the clock generated by the clock
>>> --
>>> 1.6.6.rc2
>>>
^ permalink raw reply
* [PATCH] arm64: delete non-required instances of <linux/init.h>
From: Catalin Marinas @ 2014-01-24 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390501611-31691-1-git-send-email-paul.gortmaker@windriver.com>
On Thu, Jan 23, 2014 at 06:26:51PM +0000, Paul Gortmaker wrote:
> None of these files are actually using any __init type directives
> and hence don't need to include <linux/init.h>. Most are just a
> left over from __devinit and __cpuinit removal, or simply due to
> code getting copied from one place to the next.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> [Build tested on today's linux-next ; thanks to Will for the pointer
> to a prebuilt toolchain. Patch to be added to init cleanup series:
> http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git ]
I assume you are pushing this upstream as part of your cleanup series.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Catalin Marinas @ 2014-01-24 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124120815.GH814@e106331-lin.cambridge.arm.com>
On Fri, Jan 24, 2014 at 12:08:15PM +0000, Mark Rutland wrote:
> On Fri, Jan 24, 2014 at 12:20:46AM +0000, Hanjun Guo wrote:
> > On 2014?01?22? 19:45, Mark Rutland wrote:
> > > On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
> > >> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > >>
> > >>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
> > >>>
> > >>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> > >>> name from the ACPI timer table is matched with all the registered
> > >>> timer controllers and matching initialisation routine is invoked.
> > >>>
> > >>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> > >>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > >> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> > >> to TIMER_OF_DECLARE() and I think this macro, if needed, should
> > >> be named TIMER_ACPI_DECLARE().
> > >>
> > >> The reason is that "clocksource" is a Linux-internal name and this
> > >> macro pertains to the hardware name in respective system
> > >> description type.
> > >>
> > >>> +#ifdef CONFIG_ACPI
> > >>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
> > >>> + static const struct acpi_device_id __clksrc_acpi_table_##name \
> > >>> + __used __section(__clksrc_acpi_table) \
> > >>> + = { .id = compat, \
> > >>> + .driver_data = (kernel_ulong_t)fn }
> > >>> +#else
> > >>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> > >>> +#endif
> > >> This hammers down the world to compile one binary for ACPI
> > >> and one binary for device tree. Maybe that's fine, I don't know.
> > > How does it do that?
> > >
> > > As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
> > > exclusive, and this just means that we only build the datastructures for
> > > matching from ACPI when CONFIG_ACPI is enabled.
> > >
> > > Have I missed something?
> > >
> > > I definitely don't want to see mutually exclusive ACPI and DT support.
> >
> > ACPI and DT did the same job so I think they should mutually exclusive.
> > if we enable both DT and ACPI in one system, this will leading confusions.
>
> ACPI and DT do similar jobs, and we should be mutually exclusive at
> runtime. However, they should not be mutually exclusive at compile-time.
>
> Being mutually exclusive at compile-time is just broken. It creates more
> work for distributions (who need to ship double the number of kernels),
> it increases the number of configurations requiring testing, and it
> makes it easier for bugs to be introduced. It's just painful, and
> there's no reason for it.
I fully agree (IOW, I'll NAK patches that break this assumption; we want
single kernel image whether it uses DT or ACPI).
> At boot time the kernel needs to decide which to use for hardware
> description, and completely ignore the other (which should not be
> present, but lets not assume that or inevitably someone will break that
> assumption for a quick hack).
>
> The same kernel should boot on a system that has a DTB or a system that
> has ACPI tables. On a system that's provided both it should use one or
> the other, but not both.
Do we still need the chosen node to be passed via DT for command line,
even if the kernel uses ACPI?
--
Catalin
^ permalink raw reply
* [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
From: Shawn Guo @ 2014-01-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119185246.GB28056@quad.lixom.net>
On Sun, Jan 19, 2014 at 10:52:46AM -0800, Olof Johansson wrote:
> I'm well aware that the DT branch has not been merged, and that's because
> there has been no consensus from DT maintainers on the massive rework
> you did as the base of the branch.
I guess the 'massive rework' you're talking about is the patch series
that begins with 'ARM: dts: imx6qdl: make pinctrl nodes board specific'?
If so, I hope you would agree that we're trying to solve a real
problem [1], even though the solution does not look like the best to
you.
So which specific part of the solution are you objecting to? Those
MX6QDL_*_PINGRP macros defined in imx6qdl-pingrp.h? If that's the
case, I can send a follow-up patch to kill the macros by filling in the
pin group definitions directly. The pros is that the pin group
definitions for given board will be more intuitive, and the cons is that
the change set will be even more massive, because the same multi-lines
pin group definitions will be duplicated in multiple board dts files,
which use the same group of pins for given device.
Or any other better idea?
>
> Given the timing, it's not looking like it will be resolved in time for
> the 3.14 merge window (which might open today).
That's frustrating and will be surprising a lot of people who expect to
see their board support in 3.14 release.
Shawn
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/275912/
^ permalink raw reply
* [PATCH 11/20] ARM64 / ACPI: Get the enable method for SMP initialization
From: Hanjun Guo @ 2014-01-24 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123175031.GJ27520@arm.com>
Hi Catalin,
On 2014?01?24? 01:50, Catalin Marinas wrote:
> On Fri, Jan 17, 2014 at 12:25:05PM +0000, Hanjun Guo wrote:
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -48,6 +48,7 @@
>> #include <asm/sections.h>
>> #include <asm/tlbflush.h>
>> #include <asm/ptrace.h>
>> +#include <asm/acpi.h>
>>
>> /*
>> * as from 2.5, kernels no longer have an init_tasks structure
>> @@ -280,7 +281,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>> * cpu logical map array containing MPIDR values related to logical
>> * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>> */
>> -void __init smp_init_cpus(void)
>> +static int __init of_smp_init_cpus(void)
>> {
>> struct device_node *dn = NULL;
>> unsigned int i, cpu = 1;
>> @@ -364,6 +365,10 @@ next:
>> cpu++;
>> }
>>
>> + /* No device tree or no CPU node in DT */
>> + if (cpu == 1 && !bootcpu_valid)
>> + return -ENODEV;
>> +
>> /* sanity check */
>> if (cpu > NR_CPUS)
>> pr_warning("no. of cores (%d) greater than configured maximum of %d - clipping\n",
>> @@ -371,7 +376,7 @@ next:
>>
>> if (!bootcpu_valid) {
>> pr_err("DT missing boot CPU MPIDR, not enabling secondaries\n");
>> - return;
>> + return -EINVAL;
>> }
>>
>> /*
>> @@ -381,6 +386,39 @@ next:
>> for (i = 0; i < NR_CPUS; i++)
>> if (cpu_logical_map(i) != INVALID_HWID)
>> set_cpu_possible(i, true);
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> + int cpu;
>> + const char *enable_method;
>> +
>> + for_each_possible_cpu(cpu) {
>> + enable_method = acpi_get_enable_method(cpu);
>> + if (!enable_method)
>> + continue;
>> +
>> + cpu_ops[cpu] = cpu_get_ops(enable_method);
>> + if (!cpu_ops[cpu])
>> + continue;
>> +
>> + cpu_ops[cpu]->cpu_init(NULL, cpu);
>> + }
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> + if (!of_smp_init_cpus())
>> + return;
>> +
>> + acpi_smp_init_cpus();
>> }
> With DT we initialise the cpu_ops[0] via cpu_read_bootcpu_ops() called
> from setup_arch(). This is needed because with PSCI we use cpu_ops for
> power management even if it's a UP system. Do you get a some kernel
> warning about device node for the boot cpu not found?
Thanks for pointing this out, actually we didn't find a dts file with
spin-table method for SMP initialization, and this patch is not fully
tested (only spin-table method is supported in ACPI now), we are
working on that and get this patch fully tested.
I will review the code carefully in your comments, and update
the code accordingly.
>
>> --- a/drivers/acpi/plat/arm-core.c
>> +++ b/drivers/acpi/plat/arm-core.c
>> @@ -367,6 +367,32 @@ static void __init acpi_process_madt(void)
>> }
>>
>> /*
>> + * To see PCSI is enabled or not.
>> + *
>> + * PSCI is not available for ACPI 5.0, return FALSE for now.
>> + *
>> + * FIXME: should we introduce early_param("psci", func) for test purpose?
>> + */
>> +static bool acpi_psci_smp_available(int cpu)
>> +{
>> + return FALSE;
>> +}
>> +
>> +static const char *enable_method[] = {
>> + "psci",
>> + "spin-table",
>> + NULL
>> +};
>> +
>> +const char *acpi_get_enable_method(int cpu)
>> +{
>> + if (acpi_psci_smp_available(cpu))
>> + return enable_method[0];
>> + else
>> + return enable_method[1];
>> +}
> You could just use literal strings here, actually even ignoring PSCI
> until available.
Ok.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 07/20] ARM64 / ACPI: Enable ARM64 in Kconfig
From: Hanjun Guo @ 2014-01-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123163939.GB25927@localhost>
On 2014?01?24? 00:39, Catalin Marinas wrote:
> On Fri, Jan 17, 2014 at 12:25:01PM +0000, Hanjun Guo wrote:
>> Add Kconfigs to build ACPI on ARM64, and make ACPI runable on ARM64.
>>
>> acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
>> depends on X86 || IA64, and implement it on ARM/ARM64 in the furture.
>>
>> In order to make arm-core.c can both run on ARM and ARM64, introduce
>> CONFIG_ACPI_ARM to support it.
>>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/Kconfig | 2 ++
>> drivers/acpi/Kconfig | 11 ++++++++---
>> drivers/acpi/plat/Makefile | 2 +-
>> 3 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 6d4dd22..2b1fb1d 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -279,6 +279,8 @@ source "net/Kconfig"
>>
>> source "drivers/Kconfig"
>>
>> +source "drivers/acpi/Kconfig"
>> +
>> source "fs/Kconfig"
>>
>> source "arch/arm64/kvm/Kconfig"
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 4770de5..cae5dc9 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -2,13 +2,16 @@
>> # ACPI Configuration
>> #
>>
>> +config ACPI_ARM
>> + bool
> Could be better as def_bool ARM64
>
>> +
>> menuconfig ACPI
>> bool "ACPI (Advanced Configuration and Power Interface) Support"
>> depends on !IA64_HP_SIM
>> - depends on IA64 || X86
>> - depends on PCI
>> + depends on ((IA64 || X86) && PCI) || ARM64
>> select PNP
>> - default y
>> + select ACPI_ARM if ARM64
> And remove this select here.
Thanks for the guidance, will update in next version.
>
^ permalink raw reply
* [PATCH 03/20] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64
From: Hanjun Guo @ 2014-01-24 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123161918.GA25927@localhost>
On 2014?01?24? 00:19, Catalin Marinas wrote:
> On Mon, Jan 20, 2014 at 09:20:38AM +0000, Hanjun Guo wrote:
>> On 2014-1-17 22:25, Sudeep Holla wrote:
>>> On 17/01/14 12:24, Hanjun Guo wrote:
>>>> --- a/arch/arm64/kernel/process.c
>>>> +++ b/arch/arm64/kernel/process.c
>>>> @@ -89,6 +89,9 @@ void arch_cpu_idle_prepare(void)
>>>> local_fiq_enable();
>>>> }
>>>>
>>>> +unsigned long boot_option_idle_override = IDLE_NO_OVERRIDE;
>>>> +EXPORT_SYMBOL(boot_option_idle_override);
>>>> +
>>> This is what I mentioned in other email. Do we really foresee use of this in
>>> ARM64 or it's just added to avoid build issues ?
>> Just avoid build issues, can not foresee use of this in ARM64 :)
> So ideally we should look for a better solution here.
Ok, I will try my best.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 02/20] ARM64 : Add dummy asm/cpu.h
From: Hanjun Guo @ 2014-01-24 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123161505.GB23939@localhost>
On 2014?01?24? 00:15, Catalin Marinas wrote:
> On Fri, Jan 17, 2014 at 12:24:56PM +0000, Hanjun Guo wrote:
>> ACPI requires a cpu.h, add a dummy one copied from arm. This will need
>> updated or replaced as ACPI based cpu hotplug or cpu topology for armv8
>> is worked out.
>>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/include/asm/cpu.h | 25 +++++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644 arch/arm64/include/asm/cpu.h
>>
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> new file mode 100644
>> index 0000000..8625eb1
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Copyright (C) 2004-2005 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef __ASM_ARM_CPU_H
>> +#define __ASM_ARM_CPU_H
>> +
>> +#include <linux/percpu.h>
>> +#include <linux/cpu.h>
>> +#include <linux/topology.h>
>> +
>> +struct cpuinfo_arm {
>> + struct cpu cpu;
>> + u64 cpuid;
>> +#ifdef CONFIG_SMP
>> + unsigned int loops_per_jiffy;
>> +#endif
>> +};
>> +
>> +DECLARE_PER_CPU(struct cpuinfo_arm, cpu_data);
>> +
>> +#endif
> Could you not leave this file empty until you add the code that actually
> makes use of cpu_data?
Of course, I will update in next version :)
Thanks
Hanjun
^ permalink raw reply
* Samsung-clk patches for 3.15
From: Tomasz Figa @ 2014-01-24 14:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Linux 3.14 is going to include Andrzej Hajda's patches converting
Samsung clock drivers to use clock ID defines in include/dt-bindings,
instead of local enums, but to avoid unnecessary merge conflicts we have
converted only the clock driver, leaving DTS files unchanged yet.
We intend to complete the conversion in 3.15, by replacing magic numbers
in DTS files with respective preprocessor macros, but to reduce
potential conflicts we need help of you, Samsung clock patches authors :).
I'd like to ask anybody who already has patches for DTS files adding any
clock-related contents still using numeric IDs, e.g. clock properties in
nodes or full nodes containing clock properties, to make sure that the
patches are merged before Andrzej sends the conversion patches. Then
Andrzej's script will generate patches updating all clock properties,
leaving no numeric IDs in DTS files.
If you are just starting your work on a patch that introduces changes as
mentioned above, please make sure to already use clock macros, not
numeric IDs. Otherwise you risk having needless rebases with a lot of
conflicts. You have been warned ;).
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id
From: Hanjun Guo @ 2014-01-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122155331.GD24288@e102568-lin.cambridge.arm.com>
Hi Lorenzo,
On 2014?01?22? 23:53, Lorenzo Pieralisi wrote:
> On Fri, Jan 17, 2014 at 12:25:04PM +0000, Hanjun Guo wrote:
>
> [...]
>
>> +/* map logic cpu id to physical GIC id */
>> +extern int arm_cpu_to_apicid[NR_CPUS];
>> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
> Sudeep already commented on this, please update it accordingly.
Actually after some careful review of the ACPI code, I can't
update it as MPIDR here.
MPIDR can be the ACPI uid and NOT the GIC id, the mapping
of them are something like this in ACPI driver now:
logic cpu id <---> APIC Id (GIC ID) <---> ACPI uid (MPIDR on ARM)
but not logic cpu id <---> ACPI uid directly, you can refer to
the code of processor_core.c
So here I can only map GIC id to logical cpu id.
>
>> +
>> #else /* !CONFIG_ACPI */
>> #define acpi_disabled 1 /* ACPI sometimes enabled on ARM */
>> #define acpi_noirq 1 /* ACPI sometimes enabled on ARM */
>> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
>> index 8ba3e6f..1d9b789 100644
>> --- a/drivers/acpi/plat/arm-core.c
>> +++ b/drivers/acpi/plat/arm-core.c
>> @@ -31,6 +31,7 @@
>> #include <linux/smp.h>
>>
>> #include <asm/pgtable.h>
>> +#include <asm/cputype.h>
>>
>> /*
>> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> @@ -52,6 +53,13 @@ EXPORT_SYMBOL(acpi_pci_disabled);
>> */
>> static u64 acpi_lapic_addr __initdata;
> Is this variable actually needed ?
Yes, needed for GIC initialization.
>
>>
>> +/* available_cpus here means enabled cpu in MADT */
>> +static int available_cpus;
> Ditto.
>
>> +
>> +/* Map logic cpu id to physical GIC id (physical CPU id). */
>> +int arm_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
>> +static int boot_cpu_apic_id = -1;
> Do we need all these variables ? I think we should reuse cpu_logical_map
> data structures for that, it looks suspiciously familiar.
MPIDR is the different part. if we use MPIDR as GIC id, i think
we can reuse cpu_logical_map, but Sudeep suggested not
use MPIDR as GIC id.
>
>> #define BAD_MADT_ENTRY(entry, end) ( \
>> (!entry) || (unsigned long)entry + sizeof(*entry) > end || \
>> ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
>> @@ -132,6 +140,55 @@ static int __init acpi_parse_madt(struct acpi_table_header *table)
>> * Please refer to chapter5.2.12.14/15 of ACPI 5.0
>> */
>>
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
>> + * @id: gic cpu interface id to register
>> + * @enabled: this cpu is enabled or not
>> + *
>> + * Returns the logic cpu number which maps to the gic cpu interface
>> + */
>> +static int acpi_register_gic_cpu_interface(int id, u8 enabled)
>> +{
>> + int cpu;
>> +
>> + if (id >= MAX_GIC_CPU_INTERFACE) {
>> + pr_info(PREFIX "skipped apicid that is too big\n");
>> + return -EINVAL;
>> + }
>> +
>> + total_cpus++;
>> + if (!enabled)
>> + return -EINVAL;
>> +
>> + if (available_cpus >= NR_CPUS) {
>> + pr_warn(PREFIX "NR_CPUS limit of %d reached,"
>> + " Processor %d/0x%x ignored.\n", NR_CPUS, total_cpus, id);
>> + return -EINVAL;
>> + }
> Hmm...what if you are missing the boot CPU ? It is a worthy check.
> Have a look at smp_init_cpus(), it does not bail out on cpu>= NR_CPUS
> because you do want to make sure that the DT contains the boot CPU
> node. Same logic applies.
Thanks, I will review he code you mentioned and find a solution
for ACPI part.
>
>> +
>> + available_cpus++;
>> +
> Is available_cpus != num_possible_cpus() ? It does not look like hence
> available_cpus can go.
No, possible cpus include available cpus and disabled cpus
this is useful for ACPI based CPU hot-plug features.
>
>> + /* allocate a logic cpu id for the new comer */
>> + if (boot_cpu_apic_id == id) {
>> + /*
>> + * boot_cpu_init() already hold bit 0 in cpu_present_mask
>> + * for BSP, no need to allocte again.
>> + */
>> + cpu = 0;
>> + } else {
>> + cpu = cpumask_next_zero(-1, cpu_present_mask);
>> + }
>> +
>> + /* map the logic cpu id to APIC id */
>> + arm_cpu_to_apicid[cpu] = id;
>> +
>> + set_cpu_present(cpu, true);
>> + set_cpu_possible(cpu, true);
> This is getting nasty. Before adding this patch and previous ones we
> need to put in place a method for the kernel to make a definite choice between
> ACPI and DT and stick to that. We can't initialize the logical map twice
> (which will happen if your DT has valid cpu nodes and a chosen node pointing
> to proper ACPI tables) or even having some entries initialized from DT and
> others by ACPI. It is a big fat no-no, please update the series accordingly.
really good catch here :)
so the problem here is that should we use both ACPI and DT in one system?
>
>> +
>> + return cpu;
>> +}
>> +
>> static int __init
>> acpi_parse_gic(struct acpi_subtable_header *header, const unsigned long end)
>> {
>> @@ -144,6 +201,16 @@ acpi_parse_gic(struct acpi_subtable_header *header, const unsigned long end)
>>
>> acpi_table_print_madt_entry(header);
>>
>> + /*
>> + * We need to register disabled CPU as well to permit
>> + * counting disabled CPUs. This allows us to size
>> + * cpus_possible_map more accurately, to permit
>> + * to not preallocating memory for all NR_CPUS
>> + * when we use CPU hotplug.
>> + */
>> + acpi_register_gic_cpu_interface(processor->gic_id,
>> + processor->flags & ACPI_MADT_ENABLED);
>> +
>> return 0;
>> }
>>
>> @@ -186,6 +253,19 @@ static int __init acpi_parse_madt_gic_entries(void)
>> return count;
>> }
>>
>> +#ifdef CONFIG_SMP
>> + if (available_cpus == 0) {
>> + pr_info(PREFIX "Found 0 CPUs; assuming 1\n");
>> + arm_cpu_to_apicid[available_cpus] =
>> + read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> + available_cpus = 1; /* We've got at least one of these */
>> + }
> I'd rather check the MADT for at least the boot cpu to present, if it is
> not ACPI tables are horribly buggy and the kernel should barf on that.
>
>> +#endif
>> +
>> + /* Make boot-up look pretty */
>> + pr_info("%d CPUs available, %d CPUs total\n", available_cpus,
>> + total_cpus);
> Ok, now, how can we use the "disabled" CPUs == (total_cpus - available_cpus) ?
For cpus can be hot-added later when system is running.
>
> Are we keeping track of them in the kernel at all ? It does not look
> like, so I wonder whether we need this bit of info. I do not see why it
> is pretty to know that there are disabled, aka unusable CPUs.
>
>> return 0;
>> }
>>
>> @@ -321,6 +401,9 @@ int __init early_acpi_boot_init(void)
>> if (acpi_disabled)
>> return -ENODEV;
>>
>> + /* Get the boot CPU's GIC cpu interface id before MADT parsing */
>> + boot_cpu_apic_id = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> See Sudeep's comment.
I will rework this part to get the GIC cpu interface id, not the MPIDR here.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] sunxi: dts: add a note that memory size is adjusted by boot loader.
From: Ian Campbell @ 2014-01-24 14:14 UTC (permalink / raw)
To: linux-arm-kernel
I had to spend a couple of minutes proving to myself that this was the case on
cubietruck, so add a comment to save the next guy some effort.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-sunxi at googlegroups.com
---
This patch applies cleanly against v3.13 and Hans' sunxi-devel branch.
A plausible alternative would be to pull the memory node out of the dtsi files
and into the board specific files. I didn't go straight to that since I'd have
to research all the various boards ;-)
I considered maing it "reg = <0 0>" but decided that having some sort of least
common denominator would let things work even if the bootloader were broken.
---
arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
arch/arm/boot/dts/sun5i-a10s.dtsi | 1 +
arch/arm/boot/dts/sun5i-a13.dtsi | 1 +
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
arch/arm/boot/dts/sun7i-a20.dtsi | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 3e60883..9ba0beb 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -30,6 +30,7 @@
};
memory {
+ /* 1GB by default, will be updated by U-Boot */
reg = <0x40000000 0x80000000>;
};
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 0376c50..d12ed7e 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -27,6 +27,7 @@
};
memory {
+ /* 512MB by default, will be updated by U-Boot */
reg = <0x40000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index b81aeb9..6f8bfd9 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -27,6 +27,7 @@
};
memory {
+ /* 512MB by default, will be updated by U-Boot */
reg = <0x40000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 3f6f07b..bcbef9a 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -46,6 +46,7 @@
};
memory {
+ /* 2GB by default, will be updated by U-Boot */
reg = <0x40000000 0x80000000>;
};
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 907cfcc..658e74b 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -38,6 +38,7 @@
};
memory {
+ /* 1GB by default, will be updated by U-Boot */
reg = <0x40000000 0x80000000>;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Kishon Vijay Abraham I @ 2014-01-24 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121144725.GF30451@saruman.home>
Hi,
On Tuesday 21 January 2014 08:17 PM, Felipe Balbi wrote:
> On Tue, Jan 21, 2014 at 03:41:38PM +0530, Kishon Vijay Abraham I wrote:
>> Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
>> do not return from probe if the USB PHY library returns -ENODEV as that
>
> this isn't correct, they all have PHYs, some of them might not be
> controllable.
right, but we use USB PHY library only for controllable PHYs (apart from using
nop).
>
>> indicates the platform does not have PHY.
>
> not really, that indicates the current platform tried to grab a PHY and
> the PHY doesn't exist. If there's anybody with a non-controllable PHY
> and someone gives me a really good reason for not using the generic
> no-op PHY, then we should add a flag and we could:
>
> if (!likely(dwc->flags & DWC3_USB2PHY_DRIVER_NOT_NEEDED))
> dwc3_grab_phys(dwc);
>
> But I really want to see the argument against using no-op. As far as I
> could see, everybody needs a PHY driver one way or another, some
> platforms just haven't sent any PHY driver upstream and have their own
> hacked up solution to avoid using the PHY layer.
I was trying to address Heikki concerns in my previous version [1] where I used
quirks to identify if the platform does not have PHY.
[1] -> https://lkml.org/lkml/2013/12/5/32
Thanks
Kishon
^ permalink raw reply
* Warning at __kmem_cache_create
From: Fabio Estevam @ 2014-01-24 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124131156.GE15937@n2100.arm.linux.org.uk>
On Fri, Jan 24, 2014 at 11:11 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> So it's some slub change which has yet to hit mainline... I can't say
> much more than that at the moment.
Yes, I found the commit that causes the warning.
Will start a new thread at linux-kernel at vger.kernel.org to discuss it.
Regards,
Fabio Estevam
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-24 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122051510.GB17284@gmail.com>
Just expanding distribution a little bit to see if anyone has any ideas.
On Tue, Jan 21, 2014 at 11:15:10PM -0600, Andrew Ruder wrote:
> Problem:
> ubifs corruption to the point where uboot can no longer deal with it and
> it takes multiple mounts to recover filesystem from Linux.
>
> My hardware:
> NOR flash
> [ 3.244397] 0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002301
> PXA270
>
> My software:
> 3.12.0 with some patches (not mtd or ubi or flash related) to support my
> board.
>
> I'm able to reproduce this fairly readily by the following sequence of
> commands. I'm not able to trigger it with full debug messages enabled
> but possibly I could enable them for certain files within the ubifs
> driver if something specific would be helpful. But basically it seems
> like if I reboot (or mount -o remount,ro) while ubifs is writing, it
> sometimes crashes and leaves the partition in a bad state. Sorry about
> some of the strangeness of the commands, I am scripting this with expect
> and this is my lame attempt to give me something to pattern recognize
> off of.
>
> I should also point out, I have not had any problems at all when I do an
> abrupt shutdown (either via pulling power or letting a hardware watchdog
> take care of the reset).
>
> ==============================================================
> ==============================================================
> ==============================================================
>
> Here's the log of ubifs driver crashing.
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 3.12.0-00041-g7f12d39-dirty (andy at andrewruder-hplin) (gcc version 4.8.2 (Buildroot 2013.11-rc1-00028-gf388663) ) #210 PREEMPT Tue Jan 21 21:36:54 CST 2014
> [ 0.000000] CPU: XScale-PXA270 [69054118] revision 8 (ARMv5TE), cr=0000397f
> ...
> [ 3.211589] 0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002301
> [ 3.322188] Amd/Fujitsu Extended Query Table at 0x0040
> [ 3.327405] Amd/Fujitsu Extended Query version 1.5.
> [ 3.370661] number of CFI chips: 1
> [ 3.378822] 5 cmdlinepart partitions found on MTD device 0.flash
> [ 3.385273] Creating 5 MTD partitions on "0.flash":
> [ 3.390212] 0x000000000000-0x000000080000 : "uboot"
> [ 3.423423] 0x000000080000-0x0000000a0000 : "env"
> [ 3.503423] 0x0000000a0000-0x0000000c0000 : "env_redund"
> [ 3.603453] 0x0000000c0000-0x0000000e0000 : "env_default"
> [ 3.674772] 0x0000000e0000-0x000004000000 : "data"
> ...
> Welcome to Buildroot
> buildroot login: root
> Password:
> [root at buildroot ~]# echo 7 > /proc/sys/kernel/printk; a=$?; sleep 2 ; [ x$a = x0 ] || echo "@@FAIL@@"
> [root at buildroot ~]# ubiattach -m 4 -d 0; a=$?; sleep 2 ; [ x$a = x0 ] || echo "@@FAIL@@"
> [ 10.055595] UBI: attaching mtd4 to ubi0
> [ 10.107901] UBI: scanning is finished
> [ 10.172362] UBI: attached mtd4 (name "data", size 63 MiB) to ubi0
> [ 10.178509] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 130944 bytes
> [ 10.220887] UBI: min./max. I/O unit sizes: 1/512, sub-page size 1
> [ 10.228545] UBI: VID header offset: 64 (aligned 64), data offset: 128
> [ 10.240011] UBI: good PEBs: 505, bad PEBs: 0, corrupted PEBs: 0
> [ 10.247227] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
> [ 10.255658] UBI: max/mean erase counter: 42/22, WL threshold: 4096, image sequence number: 2104545903
> [ 10.266343] UBI: available PEBs: 4, total reserved PEBs: 501, PEBs reserved for bad PEB handling: 0
> [ 10.276740] UBI: background thread "ubi_bgt0d" started, PID 510
> UBI device number 0, total 505 LEBs (66126720 bytes, 63.1 MiB), available 4 LEBs (523776 bytes, 511.5 KiB), LEB size 130944 bytes (127.9 KiB)
> [root at buildroot ~]# mkdir -p /mnt; a=$?; sleep 2 ; [ x$a = x0 ] || echo "@@FAIL@@"
> [root at buildroot ~]# mount -t ubifs ubi0:rootfs /mnt; a=$?; sleep 2 ; [ x$a = x0 ] || echo "@@FAIL@@"
> [ 14.463104] UBIFS: background thread "ubifs_bgt0_0" started, PID 516
> [ 14.985636] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
> [ 14.991670] UBIFS: LEB size: 130944 bytes (127 KiB), min./max. I/O unit sizes: 8 bytes/512 bytes
> [ 15.008984] UBIFS: FS size: 63769728 bytes (60 MiB, 487 LEBs), journal size 3142656 bytes (2 MiB, 24 LEBs)
> [ 15.020052] UBIFS: reserved for root: 3012001 bytes (2941 KiB)
> [ 15.027374] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 567F5BCB-663D-4F84-BF34-3282E100D2D9, small LPT model
> [root at buildroot ~]# rm -fr /mnt/fsstress; a=$?; sleep 2 ; [ x$a = x0 ] || echo "@@FAIL@@"
> [root at buildroot ~]# mkdir -p /mnt/fsstress; a=$?; sleep 2 ; [ x$a = x0 ] || echo "@@FAIL@@"
> [root at buildroot ~]# (sleep 41 ; reboot) &
> [1] 522
> [root at buildroot ~]# fsstress -p 10 -n 10 -X -d /mnt/fsstress -l 0
> seed = 653587
> [ 64.672770] UBIFS: background thread "ubifs_bgt0_0" stops
> The system is going down NOW!
> Sent SIGTERM to[ 64.753793] UBIFS assert failed in reserve_space at 125 (pid 14)
> all processes
> [ 64.760886] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [1]+ Done ( [ 64.773747] Workqueue: writeback bdi_writeback_workfnsleep 41; reboot (flush-ubifs_0_0) )
> Terminated
>
> [ 64.783579] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 64.792304] [<c00110c8>] (show_stack+0x10/0x14) from [<c00f2500>] (make_reservation+0x80/0x46c)
> [ 64.801054] [<c00f2500>] (make_reservation+0x80/0x46c) from [<c00f3630>] (ubifs_jnl_write_inode+0x90/0x1dc)
> [root at buildroot [ 64.811456] [<c00f3630>] (ubifs_jnl_write_inode+0x90/0x1dc) from [<c00f9f60>] (ubifs_write_inode+0xc0/0x140)
> ~]# [ 64.822628] [<c00f9f60>] (ubifs_write_inode+0xc0/0x140) from [<c00b99a0>] (__writeback_single_inode+0xe8/0xfc)
> [ 64.832988] [<c00b99a0>] (__writeback_single_inode+0xe8/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 64.843435] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 64.853547] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 64.863020] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 64.872487] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 64.882286] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 64.891555] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 64.899904] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 64.908159] UBIFS assert failed in ubifs_wbuf_write_nolock at 691 (pid 14)
> [ 64.915120] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 64.923452] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 64.930177] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 64.938823] [<c00110c8>] (show_stack+0x10/0x14) from [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc)
> [ 64.948291] [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc) from [<c00f2cfc>] (write_head.constprop.14+0x84/0xb0)
> [ 64.958876] [<c00f2cfc>] (write_head.constprop.14+0x84/0xb0) from [<c00f3668>] (ubifs_jnl_write_inode+0xc8/0x1dc)
> [ 64.969196] [<c00f3668>] (ubifs_jnl_write_inode+0xc8/0x1dc) from [<c00f9f60>] (ubifs_write_inode+0xc0/0x140)
> [ 64.979089] [<c00f9f60>] (ubifs_write_inode+0xc0/0x140) from [<c00b99a0>] (__writeback_single_inode+0xe8/0xfc)
> [ 64.989160] [<c00b99a0>] (__writeback_single_inode+0xe8/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 64.999487] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 65.009545] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 65.019000] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 65.028475] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 65.038284] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 65.047577] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 65.055909] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 65.064740] UBIFS assert failed in reserve_space at 125 (pid 14)
> [ 65.070780] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 65.079212] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 65.085974] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 65.094584] [<c00110c8>] (show_stack+0x10/0x14) from [<c00f2500>] (make_reservation+0x80/0x46c)
> [ 65.103362] [<c00f2500>] (make_reservation+0x80/0x46c) from [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc)
> [ 65.113174] [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 65.122630] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 65.131099] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 65.140122] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 65.149751] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 65.159814] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 65.170141] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 65.180205] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 65.189663] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 65.199127] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 65.208930] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 65.218227] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 65.226564] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 65.234798] UBIFS assert failed in ubifs_wbuf_write_nolock at 691 (pid 14)
> [ 65.241702] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 65.250053] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 65.256797] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 65.265404] [<c00110c8>] (show_stack+0x10/0x14) from [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc)
> [ 65.274857] [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc) from [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc)
> [ 65.285346] [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 65.294798] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 65.303295] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 65.312310] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 65.321940] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 65.332008] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 65.342330] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 65.352393] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 65.361818] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 65.371272] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 65.381070] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 65.390351] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 65.398679] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 65.407416] UBIFS assert failed in reserve_space at 125 (pid 14)
> [ 65.413585] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 65.421910] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 65.428674] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 65.437276] [<c00110c8>] (show_stack+0x10/0x14) from [<c00f2500>] (make_reservation+0x80/0x46c)
> [ 65.446041] [<c00f2500>] (make_reservation+0x80/0x46c) from [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc)
> [ 65.455839] [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 65.465290] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 65.473786] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 65.482807] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 65.492439] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 65.502501] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 65.512820] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 65.522883] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 65.532342] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 65.541781] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 65.551589] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 65.560880] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 65.569215] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 65.577442] UBIFS assert failed in ubifs_wbuf_write_nolock at 691 (pid 14)
> [ 65.584389] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 65.592715] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 65.599412] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 65.608038] [<c00110c8>] (show_stack+0x10/0x14) from [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc)
> [ 65.617493] [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc) from [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc)
> [ 65.627984] [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 65.637436] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 65.645932] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 65.654964] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 65.664605] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 65.674680] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 65.685002] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 65.695061] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 65.704514] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 65.713968] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 65.723770] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 65.733050] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 65.741349] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 65.749527] UBIFS assert failed in ubifs_leb_write at 122 (pid 14)
> [ 65.755767] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 65.764086] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 65.770778] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 65.779391] [<c00110c8>] (show_stack+0x10/0x14) from [<c00feacc>] (ubifs_leb_write+0x4c/0x11c)
> Sent SIGKILL to[ 65.790297] [<c00feacc>] (ubifs_leb_write+0x4c/0x11c) from [<c010002c>] (ubifs_wbuf_write_nolock+0x460/0x7dc)
> [ 65.800424] [<c010002c>] (ubifs_wbuf_write_nolock+0x460/0x7dc) from [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc)
> [ 65.811038] [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 65.820627] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 65.829195] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 65.838236] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 65.847988] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 65.858194] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 65.868593] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 65.878679] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 65.888133] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 65.897596] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 65.907392] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 65.916685] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 65.925018] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 65.934393] UBIFS assert failed in reserve_space at 125 (pid 14)
> [ 65.940435] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 65.948879] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 65.955654] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 65.964264] [<c00110c8>] (show_stack+0x10/0x14) from [<c00f2500>] (make_reservation+0x80/0x46c)
> [ 65.973019] [<c00f2500>] (make_reservation+0x80/0x46c) from [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc)
> [ 65.982820] [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 65.992271] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 66.000743] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 66.009760] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 66.019387] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 66.029460] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 66.039783] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 66.049843] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 66.059303] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 66.068770] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 66.078568] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 66.087861] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 66.096199] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 66.104420] UBIFS assert failed in ubifs_wbuf_write_nolock at 691 (pid 14)
> [ 66.111315] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 66.119654] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 66.126379] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 66.134988] [<c00110c8>] (show_stack+0x10/0x14) from [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc)
> [ 66.144452] [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc) from [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc)
> [ 66.154956] [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 66.164415] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 66.172904] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 66.181892] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 66.191527] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 66.201593] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 66.211919] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 66.222000] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 66.231430] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 66.240898] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 66.250705] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 66.259989] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 66.268314] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 66.277052] UBIFS assert failed in reserve_space at 125 (pid 14)
> [ 66.283220] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 66.291545] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 66.298329] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 66.306939] [<c00110c8>] (show_stack+0x10/0x14) from [<c00f2500>] (make_reservation+0x80/0x46c)
> [ 66.315700] [<c00f2500>] (make_reservation+0x80/0x46c) from [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc)
> [ 66.325498] [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 66.334950] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 66.343447] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 66.352458] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 66.362096] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 66.372167] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 66.382495] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 66.392556] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 66.402011] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 66.411450] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 66.421264] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 66.430556] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 66.438895] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 66.447126] UBIFS assert failed in ubifs_wbuf_write_nolock at 691 (pid 14)
> [ 66.454079] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 66.462399] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 66.469093] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 66.477706] [<c00110c8>] (show_stack+0x10/0x14) from [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc)
> [ 66.487162] [<c00ffe10>] (ubifs_wbuf_write_nolock+0x244/0x7dc) from [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc)
> [ 66.497653] [<c00f34d8>] (ubifs_jnl_write_data+0x214/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 66.507103] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 66.515593] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 66.524603] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 66.534228] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 66.544289] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 66.554609] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 66.564671] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 66.574124] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 66.583579] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 66.593378] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 66.602658] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 66.610959] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 66.619785] UBIFS assert failed in reserve_space at 125 (pid 14)
> [ 66.625961] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 66.634324] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
> [ 66.641055] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 66.649675] [<c00110c8>] (show_stack+0x10/0x14) from [<c00f2500>] (make_reservation+0x80/0x46c)
> [ 66.658435] [<c00f2500>] (make_reservation+0x80/0x46c) from [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc)
> [ 66.668239] [<c00f345c>] (ubifs_jnl_write_data+0x198/0x2dc) from [<c00f5048>] (do_writepage+0xc0/0x1fc)
> [ 66.677692] [<c00f5048>] (do_writepage+0xc0/0x1fc) from [<c006d4ec>] (__writepage+0x14/0x5c)
> [ 66.686189] [<c006d4ec>] (__writepage+0x14/0x5c) from [<c006db84>] (write_cache_pages+0x23c/0x330)
> [ 66.695206] [<c006db84>] (write_cache_pages+0x23c/0x330) from [<c006dcb4>] (generic_writepages+0x3c/0x58)
> [ 66.704830] [<c006dcb4>] (generic_writepages+0x3c/0x58) from [<c00b98ec>] (__writeback_single_inode+0x34/0xfc)
> [ 66.714893] [<c00b98ec>] (__writeback_single_inode+0x34/0xfc) from [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c)
> [ 66.725213] [<c00ba5c0>] (writeback_sb_inodes+0x200/0x37c) from [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4)
> [ 66.735272] [<c00ba7a4>] (__writeback_inodes_wb+0x68/0xa4) from [<c00ba8ec>] (wb_writeback+0x10c/0x1a4)
> [ 66.744727] [<c00ba8ec>] (wb_writeback+0x10c/0x1a4) from [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304)
> [ 66.754190] [<c00baaa4>] (bdi_writeback_workfn+0x78/0x304) from [<c0030db0>] (process_one_work+0x208/0x344)
> [ 66.763988] [<c0030db0>] (process_one_work+0x208/0x344) from [<c00313a8>] (worker_thread+0x22c/0x36c)
> [ 66.773279] [<c00313a8>] (worker_thread+0x22c/0x36c) from [<c0035d40>] (kthread+0xa0/0xac)
> [ 66.781580] [<c0035d40>] (kthread+0xa0/0xac) from [<c000e0f0>] (ret_from_fork+0x14/0x24)
> [ 66.789798] UBIFS assert failed in ubifs_wbuf_write_nolock at 691 (pid 14)
> [ 66.797145] CPU: 0 PID: 14 Comm: kworker/u2:1 Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 66.808684] reboot: Restarting system
>
> ==============================================================
> ==============================================================
> ==============================================================
>
> Here's what happens if I then try to mount/load a file from u-boot.
>
> U-Boot 2013.10-00014-gce4b76b (Nov 25 2013 - 17:12:39)
>
> CPU: Marvell PXA27x rev. Unknown
> Checking SDRAM U16/U20 data
> pass
> Checking SDRAM U44/U45 data
> pass
> Checking SDRAM U16/U20 address
> pass
> Checking SDRAM U44/U45 address
> pass
> DRAM: 256 MiB
> WARNING: Caches not enabled
> Flash: 64 MiB
> MMC: PXA MMC: 0
> In: serial
> Out: serial
> Err: serial
> KSZ8895MQ REV0 found, configuring...done
> Net: dm9000
> Warning: dm9000 using MAC address from net device
>
> Hit any key to stop autoboot: 0
> $ <INTERRUPT>
> $ <INTERRUPT>
> $ <INTERRUPT>
> $ ubi part data || echo FAIL ; ubifsmount ubi0:rootfs || echo FAIL ; ubifsload ${scratch} ${kernel.ubi.path} || echo FAIL
> UBI: attaching mtd1 to ubi0
> UBI: physical eraseblock size: 131072 bytes (128 KiB)
> UBI: logical eraseblock size: 130944 bytes
> UBI: smallest flash I/O unit: 1
> UBI: VID header offset: 64 (aligned 64)
> UBI: data offset: 128
> UBI: attached mtd1 to ubi0
> UBI: MTD device name: "mtd=4"
> UBI: MTD device size: 63 MiB
> UBI: number of good PEBs: 505
> UBI: number of bad PEBs: 0
> UBI: max. allowed volumes: 128
> UBI: wear-leveling threshold: 4096
> UBI: number of internal volumes: 1
> UBI: number of user volumes: 1
> UBI: available PEBs: 4
> UBI: total number of reserved PEBs: 501
> UBI: number of PEBs reserved for bad PEB handling: 0
> UBI: max/mean erase counter: 42/22
> UBIFS error (pid 0): ubifs_check_node: bad CRC: calculated 0x5bfc9168, read 0x653f8e7
> UBIFS error (pid 0): ubifs_check_node: bad node at LEB 46:61392
> UBIFS error (pid 0): ubifs_scanned_corruption: corrupted data at LEB 46:61392
> UBIFS error (pid 0): ubifs_scan: LEB 46 scanning failed
> UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume 'ubi0:rootfs' errno=-117!
>
> ubifsmount - mount UBIFS volume
>
> Usage:
> ubifsmount <volume-name>
> - mount 'volume-name' volume
> FAIL
> UBIFS not mounted, use ubifs mount to mount volume first!
> ubifsload - load file from an UBIFS filesystem
>
> Usage:
> ubifsload <addr> <filename> [bytes]
> - load file 'filename' to address 'addr'
> FAIL
> $ We have corrupted our ubifs partition (Run #1)
> while executing
> "return -level 1 -code error $errorMsg"
>
> ==============================================================
> ==============================================================
> ==============================================================
>
> Here's the recovery process from Linux. Note that I mount twice to get
> a successful mount.
>
> [root at buildroot ~]# echo 7 > /proc/sys/kernel/printk
> [root at buildroot ~]# ubiattach -m4 -d0
> [ 45.556102] UBI: attaching mtd4 to ubi0
> [ 45.608396] UBI: scanning is finished
> [ 45.672433] UBI: attached mtd4 (name "data", size 63 MiB) to ubi0
> [ 45.678581] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 130944 bytes
> [ 45.720983] UBI: min./max. I/O unit sizes: 1/512, sub-page size 1
> [ 45.728883] UBI: VID header offset: 64 (aligned 64), data offset: 128
> [ 45.740496] UBI: good PEBs: 505, bad PEBs: 0, corrupted PEBs: 0
> [ 45.747679] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
> [ 45.756101] UBI: max/mean erase counter: 42/22, WL threshold: 4096, image sequence number: 2104545903
> [ 45.766843] UBI: available PEBs: 4, total reserved PEBs: 501, PEBs reserved for bad PEB handling: 0
> [ 45.777256] UBI: background thread "ubi_bgt0d" started, PID 509
> UBI device number 0, total 505 LEBs (66126720 bytes, 63.1 MiB), available 4 LEBs (523776 bytes, 511.5 KiB), LEB size 130944 bytes (127.9 KiB)
> [root at buildroot ~]# mount -t ubifs ubi0:rootfs /mnt
> [ 59.813152] UBIFS: background thread "ubifs_bgt0_0" started, PID 512
> [ 60.436819] UBIFS error (pid 510): ubifs_check_node: bad CRC: calculated 0x5bfc9168, read 0x653f8e7
> [ 60.470007] UBIFS error (pid 510): ubifs_check_node: bad node at LEB 46:61392
> [ 60.491545] magic 0x6101831
> [ 60.495442] crc 0x653f8e7
> [ 60.499127] node_type 1 (data node)
> [ 60.503205] group_type 0 (no node group)
> [ 60.507577] sqnum 32292
> [ 60.510910] len 92
> [ 60.514016] key (3682, data, 174)
> [ 60.518383] size 4096
> [ 60.521620] compr_typ 1
> [ 60.524648] data size 44
> [ 60.527712] data:
> [ 60.529753] 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 60.540515] 00000020: ff ff ff ff ff ff ff ff ff ff ff ff
> [ 60.553316] CPU: 0 PID: 510 Comm: mount Not tainted 3.12.0-00041-g7f12d39-dirty #210
> [ 60.561188] [<c0013390>] (unwind_backtrace+0x0/0xe0) from [<c00110c8>] (show_stack+0x10/0x14)
> [ 60.601841] [<c00110c8>] (show_stack+0x10/0x14) from [<c00ff15c>] (ubifs_check_node+0x27c/0x2b8)
> [ 60.613301] [<c00ff15c>] (ubifs_check_node+0x27c/0x2b8) from [<c0105dd8>] (ubifs_scan_a_node+0x14c/0x290)
> [ 60.624261] [<c0105dd8>] (ubifs_scan_a_node+0x14c/0x290) from [<c0106334>] (ubifs_scan+0x98/0x31c)
> [ 60.634852] [<c0106334>] (ubifs_scan+0x98/0x31c) from [<c0107184>] (ubifs_replay_journal+0x8c0/0x1550)
> [ 60.645449] [<c0107184>] (ubifs_replay_journal+0x8c0/0x1550) from [<c00fc10c>] (ubifs_mount+0xd30/0x1960)
> [ 60.656319] [<c00fc10c>] (ubifs_mount+0xd30/0x1960) from [<c009d0d8>] (mount_fs+0x10/0xc0)
> [ 60.665944] [<c009d0d8>] (mount_fs+0x10/0xc0) from [<c00b2d78>] (vfs_kern_mount+0x48/0xc4)
> [ 60.675557] [<c00b2d78>] (vfs_kern_mount+0x48/0xc4) from [<c00b502c>] (do_mount+0x6fc/0x800)
> [ 60.685354] [<c00b502c>] (do_mount+0x6fc/0x800) from [<c00b51b4>] (SyS_mount+0x84/0xb8)
> [ 60.694719] [<c00b51b4>] (SyS_mount+0x84/0xb8) from [<c000e060>] (ret_fast_syscall+0x0/0x2c)
> [ 60.704467] UBIFS error (pid 510): ubifs_scan: bad node
> [ 60.709747] UBIFS error (pid 510): ubifs_scanned_corruption: corruption at LEB 46:61392
> [ 60.719347] UBIFS error (pid 510): ubifs_scanned_corruption: first 8192 bytes from LEB 46:61392
> [ 60.756438] UBIFS error (pid 510): ubifs_scan: LEB 46 scanning failed
> [ 60.776467] UBIFS: background thread "ubifs_bgt0_0" stops
> mount: mounting ubi0:rootfs on /mnt failed: Structure needs cleaning
> [root at buildroot ~]# echo $?
> 255
> [root at buildroot ~]# mount -t ubifs ubi0:rootfs /mnt
> [ 70.023360] UBIFS: background thread "ubifs_bgt0_0" started, PID 516
> [ 70.305482] UBIFS: recovery needed
> [ 71.169289] UBIFS: recovery completed
> [ 71.180961] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
> [ 71.199497] UBIFS: LEB size: 130944 bytes (127 KiB), min./max. I/O unit sizes: 8 bytes/512 bytes
> [ 71.226483] UBIFS: FS size: 63769728 bytes (60 MiB, 487 LEBs), journal size 3142656 bytes (2 MiB, 24 LEBs)
> [ 71.254470] UBIFS: reserved for root: 3012001 bytes (2941 KiB)
> [ 71.260366] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 567F5BCB-663D-4F84-BF34-3282E100D2D9, small LPT model
> [root at buildroot ~]# echo $?
> 0
> ==============================================================
> ==============================================================
> ==============================================================
^ permalink raw reply
* [PATCH] clk: samsung: pll: bugfix about segmentation fault
From: taikyung yu @ 2014-01-24 13:26 UTC (permalink / raw)
To: linux-arm-kernel
init has pll initialization information. but it has local variable.
so it is just valid in samsung_clk_register_pll2550x() function.
Signed-off-by: taikyung yu <taikyung.yu@gmail.com>
---
drivers/clk/samsung/clk-pll.c | 61 +++++++++++++++++++++++++----------------
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 529e11d..c90808c 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -679,7 +679,7 @@ struct clk * __init samsung_clk_register_pll2550x(const char *name,
{
struct samsung_clk_pll2550x *pll;
struct clk *clk;
- struct clk_init_data init;
+ struct clk_init_data *init;
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll) {
@@ -687,13 +687,19 @@ struct clk * __init samsung_clk_register_pll2550x(const char *name,
return NULL;
}
- init.name = name;
- init.ops = &samsung_pll2550x_clk_ops;
- init.flags = CLK_GET_RATE_NOCACHE;
- init.parent_names = &pname;
- init.num_parents = 1;
+ init = kzalloc(sizeof(*init), GFP_KERNEL);
+ if (!init) {
+ pr_err("%s: could not allocate pll init clk %s\n", __func__, name);
+ return NULL;
+ }
- pll->hw.init = &init;
+ init->name = name;
+ init->ops = &samsung_pll2550x_clk_ops;
+ init->flags = CLK_GET_RATE_NOCACHE;
+ init->parent_names = &pname;
+ init->num_parents = 1;
+
+ pll->hw.init = init;
pll->reg_base = reg_base;
pll->offset = offset;
@@ -715,7 +721,7 @@ static void __init _samsung_clk_register_pll(struct samsung_pll_clock *pll_clk,
{
struct samsung_clk_pll *pll;
struct clk *clk;
- struct clk_init_data init;
+ struct clk_init_data *init;
int ret, len;
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
@@ -725,10 +731,17 @@ static void __init _samsung_clk_register_pll(struct samsung_pll_clock *pll_clk,
return;
}
- init.name = pll_clk->name;
- init.flags = pll_clk->flags;
- init.parent_names = &pll_clk->parent_name;
- init.num_parents = 1;
+ init = kzalloc(sizeof(*init), GFP_KERNEL);
+ if (!init) {
+ pr_err("%s: could not allocate pll init clk %s\n",
+ __func__, pll_clk->name);
+ return;
+ }
+
+ init->name = pll_clk->name;
+ init->flags = pll_clk->flags;
+ init->parent_names = &pll_clk->parent_name;
+ init->num_parents = 1;
if (pll_clk->rate_table) {
/* find count of rates in rate_table */
@@ -750,48 +763,48 @@ static void __init _samsung_clk_register_pll(struct samsung_pll_clock *pll_clk,
case pll_35xx:
case pll_2550:
if (!pll->rate_table)
- init.ops = &samsung_pll35xx_clk_min_ops;
+ init->ops = &samsung_pll35xx_clk_min_ops;
else
- init.ops = &samsung_pll35xx_clk_ops;
+ init->ops = &samsung_pll35xx_clk_ops;
break;
case pll_4500:
- init.ops = &samsung_pll45xx_clk_min_ops;
+ init->ops = &samsung_pll45xx_clk_min_ops;
break;
case pll_4502:
case pll_4508:
if (!pll->rate_table)
- init.ops = &samsung_pll45xx_clk_min_ops;
+ init->ops = &samsung_pll45xx_clk_min_ops;
else
- init.ops = &samsung_pll45xx_clk_ops;
+ init->ops = &samsung_pll45xx_clk_ops;
break;
/* clk_ops for 36xx and 2650 are similar */
case pll_36xx:
case pll_2650:
if (!pll->rate_table)
- init.ops = &samsung_pll36xx_clk_min_ops;
+ init->ops = &samsung_pll36xx_clk_min_ops;
else
- init.ops = &samsung_pll36xx_clk_ops;
+ init->ops = &samsung_pll36xx_clk_ops;
break;
case pll_6552:
- init.ops = &samsung_pll6552_clk_ops;
+ init->ops = &samsung_pll6552_clk_ops;
break;
case pll_6553:
- init.ops = &samsung_pll6553_clk_ops;
+ init->ops = &samsung_pll6553_clk_ops;
break;
case pll_4600:
case pll_4650:
case pll_4650c:
if (!pll->rate_table)
- init.ops = &samsung_pll46xx_clk_min_ops;
+ init->ops = &samsung_pll46xx_clk_min_ops;
else
- init.ops = &samsung_pll46xx_clk_ops;
+ init->ops = &samsung_pll46xx_clk_ops;
break;
default:
pr_warn("%s: Unknown pll type for pll clk %s\n",
__func__, pll_clk->name);
}
- pll->hw.init = &init;
+ pll->hw.init = init;
pll->type = pll_clk->type;
pll->lock_reg = base + pll_clk->lock_offset;
pll->con_reg = base + pll_clk->con_offset;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Lars-Peter Clausen @ 2014-01-24 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1L6yvCwA3mKCwz83LQbXiVau110REV64rYrSzUhGE4ucA@mail.gmail.com>
On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
> Hi Lars,
>
> On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
>> [...]
>>> +/**
>>> + * xilinx_vdma_device_control - Configure DMA channel of the device
>>> + * @dchan: DMA Channel pointer
>>> + * @cmd: DMA control command
>>> + * @arg: Channel configuration
>>> + *
>>> + * Return: '0' on success and failure value on error
>>> + */
>>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
>>> + enum dma_ctrl_cmd cmd, unsigned long arg)
>>> +{
>>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
>>> +
>>> + switch (cmd) {
>>> + case DMA_TERMINATE_ALL:
>>> + xilinx_vdma_terminate_all(chan);
>>> + return 0;
>>> + case DMA_SLAVE_CONFIG:
>>> + return xilinx_vdma_slave_config(chan,
>>> + (struct xilinx_vdma_config *)arg);
>>
>> You really shouldn't be overloading the generic API with your own semantics.
>> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
>
> Ok. The driver needs few additional configuration from the slave
> device like Vertical
> Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
> suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
> defined for Freescale drivers?
In my opinion it is not a good idea to have driver implement a generic API,
but at the same time let the driver have custom semantics for those API
calls. It's a bit like having a gpio driver that expects 23 and 42 as the
values passed to gpio_set_value instead of 0 and 1. It completely defeats
the purpose of a generic API, namely that you are able to write generic code
that makes use of the API without having to know about which implementation
API it is talking to. The dmaengine framework provides the
dmaengine_prep_interleaved_dma() function to setup two dimensional
transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
- Lars
^ permalink raw reply
* Warning at __kmem_cache_create
From: Russell King - ARM Linux @ 2014-01-24 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Cbws-Kj-q63iCAFFOyR7gm24Z+VUZTAdzeOgud3B4cjQ@mail.gmail.com>
On Fri, Jan 24, 2014 at 11:01:17AM -0200, Fabio Estevam wrote:
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> vmalloc : 0xa0800000 - 0xff000000 (1512 MB)
> lowmem : 0x80000000 - 0xa0000000 ( 512 MB)
> pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
> modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
> .text : 0x80008000 - 0x807e0edc (8036 kB)
> .init : 0x807e1000 - 0x8082e300 ( 309 kB)
> .data : 0x80830000 - 0x8088b900 ( 367 kB)
> .bss : 0x8088b908 - 0x80debdb0 (5506 kB)
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at mm/slub.c:1511 __kmem_cache_create+0x24c/0x318()
I don't tend to track linux-next as I don't have the capacity to.
arm-soc and their autobuilder and autobooter do, but they only provide
abbreviated results when things actually result in a failure to boot.
It would be better if that facility had the provision for full boot
logs as mine does.
Just looked in my trees (which includes arm-soc), and 1511 doesn't
correspond with anything that issues a warning. I just booted Linus'
tip on the cubox-i4, and it booted without warning.
So it's some slub change which has yet to hit mainline... I can't say
much more than that at the moment.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] ARM: integrator: restore static map on the CP
From: Linus Walleij @ 2014-01-24 13:04 UTC (permalink / raw)
To: linux-arm-kernel
Commit 78d1632183454dba46ca8295484a5e7603acdc18 deleted the
static mappings of the core modules, but this static map is
still needed on the Integrator/CP (not the Integrator/AP).
Restore the static map on the Integrator/CP.
Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this fix directly to ARM SoC
if you're OK with it.
---
arch/arm/mach-integrator/integrator_cp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 5e84149d1790..a3ef961e4a93 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -64,6 +64,7 @@ static void __iomem *intcp_con_base;
/*
* Logical Physical
+ * f1000000 10000000 Core module registers
* f1300000 13000000 Counter/Timer
* f1400000 14000000 Interrupt controller
* f1600000 16000000 UART 0
@@ -75,6 +76,11 @@ static void __iomem *intcp_con_base;
static struct map_desc intcp_io_desc[] __initdata __maybe_unused = {
{
+ .virtual = IO_ADDRESS(INTEGRATOR_HDR_BASE),
+ .pfn = __phys_to_pfn(INTEGRATOR_HDR_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE
+ }, {
.virtual = IO_ADDRESS(INTEGRATOR_CT_BASE),
.pfn = __phys_to_pfn(INTEGRATOR_CT_BASE),
.length = SZ_4K,
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jyri Sarha @ 2014-01-24 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121191547.GX17314@sirena.org.uk>
On 01/21/2014 09:15 PM, Mark Brown wrote:
> On Wed, Jan 15, 2014 at 01:27:21PM +0200, Jyri Sarha wrote:
>> On 12/31/2013 03:25 PM, Mark Brown wrote:
>
>>>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>>>> The 8 least significant bits are ignored.
>
>>> Where does this constraint come from?
>
>> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
>> register statically to a value that works only with 4 byte samples.
>> According to my tests it is possible to support 3 and 2 byte samples
>> too by changing the CTS_N register value, but I am not sure if the
>> configuration can be changed on the fly. My data sheet of the nxp
>> chip is very vague about the register definitions, but I suppose the
>> register configures some clock divider on the chip. HDMI supports
>> only upto 24bit audio and the data sheet states that any extraneous
>> least significant bits are ignored.
>
> Hrm. This sounds like it ought to be presenting as an ASoC CODEC
> driver.
>
I do not disagree. I just do no not have a clear understanding how
something like that should be done. Either the tda998x_drv it self
should provide the ASoC codec driver or there should be some kind of API
that could be accessed by some driver under sound/soc/codecs. Anyway it
sound like Jean-Francois Moine is already doing that. I'll take his
driver into use as soon as his code is merged.
However, for now a simple implementation that I have does not really
need any interaction with the HDMI encoder and thus no codec driver either.
>>>> + snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
>>>> + 2, 2);
>
>>> Why not just set all this statically when registering the DAI?
>
>> Because there is no relevant DAI to where to put these limitations.
>> I did not want to add yet another dummy codec driver, but decided to
>> use the already existing ASoC HDMI codec. By default the driver
>> support all audio params supported by HDMI. The limitations are
>> coming from NXP chip, the NXP driver, and because the chip is used
>> in i2s mode. In other words the limitation is coming from machine
>> setup, not from the DAIs.
>
> OK, but it sounds like it's got register configuration as well? That
> really does sound like a device that ought to have a driver...
>
Sure, but it would not save form making runtime constraints. The usage
of i2s mode, which limits the number of channels, is selected by dai_fmt
call after dai registering.
Best regards,
Jyri
^ permalink raw reply
* Warning at __kmem_cache_create
From: Fabio Estevam @ 2014-01-24 13:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
When running linux-next on mx51 or mx6 I get the following warning:
Booting Linux on physical CPU 0x0
Linux version 3.13.0-next-20140124 (fabio at fabio-Latitude-E6410) (gcc version 4.7
.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #685 SMP Fri Jan 24 10:54:30 BRST 2014
CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Freescale i.MX51 Babbage Board
Memory policy: Data cache writeback
On node 0 totalpages: 131072
free_area_init_node: node 0, pgdat 8088ac00, node_mem_map 9fbf8000
Normal zone: 1024 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 131072 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
PERCPU: Embedded 8 pages/cpu @9fbe1000 s8960 r8192 d15616 u32768
pcpu-alloc: s8960 r8192 d15616 u32768 alloc=8*4096
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.16
8.0.25:/tftpboot/rfs,v3,tcp earlyprintk
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 505424K/524288K available (6043K kernel code, 366K rwdata, 1992K rodata,
308K init, 5505K bss, 18864K reserved, 0K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xa0800000 - 0xff000000 (1512 MB)
lowmem : 0x80000000 - 0xa0000000 ( 512 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.text : 0x80008000 - 0x807e0edc (8036 kB)
.init : 0x807e1000 - 0x8082e300 ( 309 kB)
.data : 0x80830000 - 0x8088b900 ( 367 kB)
.bss : 0x8088b908 - 0x80debdb0 (5506 kB)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at mm/slub.c:1511 __kmem_cache_create+0x24c/0x318()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-next-20140124 #685
Backtrace:
[<8001235c>] (dump_backtrace) from [<800124f8>] (show_stack+0x18/0x1c)
r6:800da30c r5:00000009 r4:00000000 r3:00000000
[<800124e0>] (show_stack) from [<805e56d8>] (dump_stack+0x80/0x9c)
[<805e5658>] (dump_stack) from [<80027834>] (warn_slowpath_common+0x70/0x94)
r4:00000000 r3:8083bcf0
[<800277c4>] (warn_slowpath_common) from [<8002787c>] (warn_slowpath_null+0x24/0
x2c)
r8:80dbeb18 r7:00002000 r6:80821c94 r5:9ffd8000 r4:9f000000
[<80027858>] (warn_slowpath_null) from [<800da30c>] (__kmem_cache_create+0x24c/0
x318)
[<800da0c0>] (__kmem_cache_create) from [<80801d34>] (create_boot_cache+0x50/0x7
8)
r10:9fffcb80 r9:412fc085 r8:80838880 r7:80821d08 r6:8073e360 r5:80821c94
r4:0000002c
[<80801ce4>] (create_boot_cache) from [<80803544>] (kmem_cache_init+0x3c/0xe0)
r6:80dbeb14 r5:80821c94 r4:80dc41a4 r3:00002000
[<80803508>] (kmem_cache_init) from [<807e19cc>] (start_kernel+0x198/0x384)
r8:80838880 r7:8081f4c0 r6:ffffffff r5:8088b940 r4:00000001
[<807e1834>] (start_kernel) from [<90008074>] (0x90008074)
r10:00000000 r8:90004059 r7:8083d3ac r6:8081f4bc r5:80838928 r4:10c53c7d
---[ end trace 3406ff24bd97382e ]---
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Any ideas?
Regards,
Fabio Estevam
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jyri Sarha @ 2014-01-24 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122114647.20f75d0d@armhf>
On 01/22/2014 12:46 PM, Jean-Francois Moine wrote:
> On Wed, 22 Jan 2014 11:19:53 +0100
> Jean-Francois Moine <moinejf@free.fr> wrote:
>
>> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
>> I wrote a tda998x CODEC which gets the audio ports from the DT and
>> dynamically sets these ports and the audio type (i2s / spdif) on audio
>> streaming start. I have not submitted yet this codec and the associated
>> changes in tda998x, because I am waiting for a first patch series on the
>> tda998x to be applied
>> (http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
>
> Sorry, the last patch request is
>
> http://lists.freedesktop.org/archives/dri-devel/2014-January/052201.html
>
I checked the sample format support again with and without your patches.
On my other TV all the formats produce something that sounds Ok if you
do not listen too carefully or use sine sweep etc. make the short
comings audible. The other TV is completely silent when playing the "non
supported" formats.
Could you give me a link to a git repo with your tda998x codec code so I
could prepare to use that too?
Best regards,
Jyri
^ permalink raw reply
* [Linaro-acpi] [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Lorenzo Pieralisi @ 2014-01-24 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E22DD4.3050807@linaro.org>
Hi Hanjun,
On Fri, Jan 24, 2014 at 09:09:40AM +0000, Hanjun Guo wrote:
> On 2014?01?23? 23:56, Tomasz Nowicki wrote:
> > Hi Lorenzo,
> >
> > W dniu 22.01.2014 12:54, Lorenzo Pieralisi pisze:
> >> On Fri, Jan 17, 2014 at 12:24:58PM +0000, Hanjun Guo wrote:
> >>
> >> [...]
> >>
> >>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> >>> index bd9bbd0..2210353 100644
> >>> --- a/arch/arm64/kernel/setup.c
> >>> +++ b/arch/arm64/kernel/setup.c
> >>> @@ -41,6 +41,7 @@
> >>> #include <linux/memblock.h>
> >>> #include <linux/of_fdt.h>
> >>> #include <linux/of_platform.h>
> >>> +#include <linux/acpi.h>
> >>>
> >>> #include <asm/cputype.h>
> >>> #include <asm/elf.h>
> >>> @@ -225,6 +226,11 @@ void __init setup_arch(char **cmdline_p)
> >>>
> >>> arm64_memblock_init();
> >>>
> >>> + /* Parse the ACPI tables for possible boot-time configuration */
> >>> + acpi_boot_table_init();
> >>> + early_acpi_boot_init();
> >>> + acpi_boot_init();
> >>> +
> >>> paging_init();
> >>
> >> Can I ask you please why we need to parse ACPI tables before
> >> paging_init() ?
> > This is for future usage and because of couple of reasons. Mainly SRAT
> > table parsing should be done (before paging_init()) for proper NUMA
> > initialization and then paging_init().
Thank you for the explanation. I still have some questions:
1) What are the other reasons ?
2) NUMA is not supported at the moment and I reckon SRAT needs updating
since the only way to associate a CPU to a memory node is through
a local APIC id that is non-existent on ARM and at least deserves a
new entry.
I am still not sure that providing a hook for parsing the ACPI tables before
paging_init() is the main focus at the moment, it is probably best, as we've
mentioned manifold times, to make sure that the infrastructure to detect
ACPI vs DT at run-time is in place in the kernel and allows us to boot
either with ACPI or DT, in a mutual exclusive way (same binary kernel
supporting both, runtime detection/decision on what data to use, ACPI tables
vs DT nodes, detection made once for all and NOT on a per property basis).
I will have a look at SRAT and how it is used on x86, and get back to you on
this.
[...]
> >>> + * acpi_boot_table_init() and acpi_boot_init()
> >>> + * called from setup_arch(), always.
> >>> + * 1. checksums all tables
> >>> + * 2. enumerates lapics
> >>> + * 3. enumerates io-apics
> >>> + *
> >>> + * acpi_table_init() is separated to allow reading SRAT without
> >>> + * other side effects.
> >>> + */
> >>> +void __init acpi_boot_table_init(void)
> >>> +{
> >>> + /*
> >>> + * If acpi_disabled, bail out
> >>> + */
> >>> + if (acpi_disabled)
> >>> + return;
> >>> +
> >>> + /*
> >>> + * Initialize the ACPI boot-time table parser.
> >>> + */
> >>> + if (acpi_table_init()) {
> >>> + disable_acpi();
> >>> + return;
> >>> + }
> >>> +}
> >>> +
> >>> +int __init early_acpi_boot_init(void)
> >>> +{
> >>> + /*
> >>> + * If acpi_disabled, bail out
> >>> + */
> >>> + if (acpi_disabled)
> >>> + return -ENODEV;
> >>> +
> >>> + /*
> >>> + * Process the Multiple APIC Description Table (MADT), if present
> >>> + */
> >>> + early_acpi_process_madt();
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +int __init acpi_boot_init(void)
> >>> +{
> >>> + /*
> >>> + * If acpi_disabled, bail out
> >>> + */
> >>> + if (acpi_disabled)
> >>> + return -ENODEV;
> >>> +
> >>> + acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> >>> +
> >>> + /*
> >>> + * Process the Multiple APIC Description Table (MADT), if present
> >>> + */
> >>> + acpi_process_madt();
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> Well, apart from having three init calls, one returning void and two
> >> returning proper values, do not understand why, and do not understand
> >> why we need three calls in the first place...why should we process MADT
> >> twice in two separate calls ? What is supposed to change in between that
> >> prevents you from merging the two together ?
>
> Thanks for pointing this out. I can merge acpi_boot_table_init() and
> early_acpi_boot_init() together, but can not merge early_acpi_boot_init()
> and acpi_boot_init() together.
>
> early_acpi_boot_init() and acpi_boot_init() was separated intentionally for
> memory hotplug reasons. memory allocated in this stage can not be migrated
> and cause memory hot-remove failed, in order to keep memory allocated
> at base node (general NUMA node 0 in the system) at boot stage, we should
> parse SRAT first before CPU is enumerated, does this make sense to you?
Are you parsing the SRAT in this series to get memory info or memory is
still initialized by DT even when system is supposed to be booted with ACPI
(ie there is a valid ACPI root table ?)
I have a hunch the latter is what's happening (and that's wrong, because
memory information when kernel is booted through ACPI must be retrieved
from UEFI - at least that's what has been defined), so I still see an early
hook to initialize ACPI tables before paging_init() that has no use as the
current patchset stands, please correct me if I am wrong.
Thank you,
Lorenzo
^ 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