* bug with 3.4.6, 3.5.3, 3.6.1
From: Gilles Chanteperdrix @ 2012-10-11 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011135905.GL30598@mudshark.cambridge.arm.com>
On 10/11/2012 03:59 PM, Will Deacon wrote:
> On Thu, Oct 11, 2012 at 02:32:06PM +0100, Gilles Chanteperdrix wrote:
>> On 10/11/2012 12:36 PM, Will Deacon wrote:
>>> On Thu, Oct 11, 2012 at 06:46:35AM +0100, Gilles Chanteperdrix wrote:
>>>> Hi,
>>>
>>> Hi Gilles,
>>>
>>>> when booting Linux v3.4.6, v3.5.3, or v3.6.1 on a pandaboard with an
>>>> OMAP4430 ES2.1, compiled with the following configuration:
>>>> http://xenomai.org/~gch/config-panda
>>>>
>>>> I get the bug below after mounting the root filesystem.
>>>>
>>>> CONFIG_VMSPLIT_2G and CONFIG_THUMB2_KERNEL disabled seems to be the
>>>> combination which triggers the bug.
>>>>
>>>> With this configuration, it seems the init_mm.mm_count incrementation
>>>> done at the beginning of secondary_start_kernel() is "lost" after the
>>>> calls to cpu_switch_mm() and local_flush_tlb().
>>>>
>>>> Modifying the secondary_startup() function in head.S to pass the
>>>> swapper pgdir instead of the idmap pgdir in r4 also avoids the issue.
>>>
>>> What's your PHYS_OFFSET? I suspect it's >= 2GB, in which case I have some
>>> ideas about this problem.
>>
>> Yes, according to /proc/iomem:
>> 80000000-bfefffff : System RAM
>> 80008000-80339fff : Kernel code
>> 80364000-803c52e7 : Kernel data
>>
>> So, PHYS_OFFSET is 0x80000000 that is, 2GB.
>
> Argh, then there's something fishy with the interaction between the idmap
> and swapper. The overwritten entries *should* be identical, but something is
> causing us to corrupt the initial tables from pgd_alloc(). Perhaps something
> to do with us mapping in sections...
>
> I'll have to do some digging and get back to you.
To satisfy my curiosity, what is the difference between VMSPLIT_3G and
VMSPLIT_2G? The fact that with VMSPLIT_2G with have physical == virtual?
--
Gilles.
^ permalink raw reply
* [PATCH 01/15] pinctrl: samsung: Detect and handle unsupported configuration types
From: Kyungmin Park @ 2012-10-11 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbRNfic7LYkcRWQSJjWop+OH7ap_z0UpPco6+m_AASYPA@mail.gmail.com>
Hi Linus,
On Thu, Oct 11, 2012 at 10:57 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Oct 11, 2012 at 10:11 AM, Tomasz Figa <t.figa@samsung.com> wrote:
>
>> This patch modifies the pinctrl-samsung driver to detect when width of a
>> bit field is set to zero (which means that such configuraton type is not
>> supported) and return an error instead of trying to modify an inexistent
>> register.
>>
>> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>
> I'm quite happy with these 17 patches, but I'd like to have Thomas
> Abraham's definitive ACK before I merge anything.
Thomas did ACK at [00/17] ... mail.
Thank you,
Kyungmin Park
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Russell King - ARM Linux @ 2012-10-11 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076CA43.9070503@gmail.com>
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
> This only affects v7 cores. It should not vary for v7 cores as unaligned
> access is a required feature. So how is it going to vary on v7 CPUs?
> We've got bigger problems if there are v7 cores that don't handle
> unaligned accesses.
Oh, and this gives me a third reason to NAK this patch. Why only ensure
that the A bit is clear for v7 CPUs? Why not v6, v5, v4 too? Why does
ARMv7 get this special treatment?
Any argument you can make for clearing the bit on ARMv7 also applies to
the other architectures too, but not even that negates my point (2) which
is far more fundamental.
^ permalink raw reply
* bug with 3.4.6, 3.5.3, 3.6.1
From: Will Deacon @ 2012-10-11 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076CA56.3020006@xenomai.org>
On Thu, Oct 11, 2012 at 02:32:06PM +0100, Gilles Chanteperdrix wrote:
> On 10/11/2012 12:36 PM, Will Deacon wrote:
> > On Thu, Oct 11, 2012 at 06:46:35AM +0100, Gilles Chanteperdrix wrote:
> >> Hi,
> >
> > Hi Gilles,
> >
> >> when booting Linux v3.4.6, v3.5.3, or v3.6.1 on a pandaboard with an
> >> OMAP4430 ES2.1, compiled with the following configuration:
> >> http://xenomai.org/~gch/config-panda
> >>
> >> I get the bug below after mounting the root filesystem.
> >>
> >> CONFIG_VMSPLIT_2G and CONFIG_THUMB2_KERNEL disabled seems to be the
> >> combination which triggers the bug.
> >>
> >> With this configuration, it seems the init_mm.mm_count incrementation
> >> done at the beginning of secondary_start_kernel() is "lost" after the
> >> calls to cpu_switch_mm() and local_flush_tlb().
> >>
> >> Modifying the secondary_startup() function in head.S to pass the
> >> swapper pgdir instead of the idmap pgdir in r4 also avoids the issue.
> >
> > What's your PHYS_OFFSET? I suspect it's >= 2GB, in which case I have some
> > ideas about this problem.
>
> Yes, according to /proc/iomem:
> 80000000-bfefffff : System RAM
> 80008000-80339fff : Kernel code
> 80364000-803c52e7 : Kernel data
>
> So, PHYS_OFFSET is 0x80000000 that is, 2GB.
Argh, then there's something fishy with the interaction between the idmap
and swapper. The overwritten entries *should* be identical, but something is
causing us to corrupt the initial tables from pgd_alloc(). Perhaps something
to do with us mapping in sections...
I'll have to do some digging and get back to you.
Cheers,
Will
^ permalink raw reply
* [PATCH 01/15] pinctrl: samsung: Detect and handle unsupported configuration types
From: Linus Walleij @ 2012-10-11 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349943081-27939-2-git-send-email-t.figa@samsung.com>
On Thu, Oct 11, 2012 at 10:11 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch modifies the pinctrl-samsung driver to detect when width of a
> bit field is set to zero (which means that such configuraton type is not
> supported) and return an error instead of trying to modify an inexistent
> register.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
I'm quite happy with these 17 patches, but I'd like to have Thomas
Abraham's definitive ACK before I merge anything.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 04/16] pinctrl: samsung: Parse pin banks from DT
From: Linus Walleij @ 2012-10-11 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1983938.6eHV2XjAIK@amdc1227>
On Wed, Oct 10, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> On Wednesday 10 of October 2012 09:34:05 Linus Walleij wrote:
>> If you will end up with a hybrid approach with some
>> stuff in the device tree and some stuff in the code,
>> it's better to keep the old driver.
>
> This will allow us to cover all the existing Samsung SoCs, starting from
> S3C24xx, through S3C64xx, S5P*, all supported Exynos SoCs and ending on any
> future SoCs using this kind of pin controller, without bloating the driver
> with hardly readable macros, lots of (often duplicated) static data and
> similar.
I do not agree with this, as you probably have realized by now...
I think it's better to use the compatible string to choose the offset
variable directly in the driver. But hey, it's just me, still.
> If there are some serious problems with this approach, just let me know and
> I will reconsider it, but if not, I'd like to keep it, because of the
> benefits it gives.
I'd like some input from Thomas Abraham before I make up my
mind about it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 00/16] pinctrl: samsung: Usability and extensibiltiy improvements
From: Linus Walleij @ 2012-10-11 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1574970.TNZCJfSix7@amdc1227>
On Wed, Oct 10, 2012 at 5:22 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> I have managed to rework the changes to drop (1). I will send next version
> of patches tomorrow. It would be nice to have them merged for 3.7, as they
> are rather important for further work.
>
> Moving data from the driver to device tree is not as important, so it might
> be discussed later.
Thanks! :-D
I'll look at it now... I still would really like to see Mr. Abraham's
ACK on this before I merge any of it.
Yours,
Linus Walleij
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076C78E.1020408@gmail.com>
On Thu, 2012-10-11 at 08:20 -0500, Rob Herring wrote:
> On 10/11/2012 07:40 AM, Eric Dumazet wrote:
> > On Thu, 2012-10-11 at 12:28 +0000, Arnd Bergmann wrote:
> >
> >>
> >> Rob Herring as the original reporter has dropped off the Cc list, adding
> >> him back.
> >>
> >> I assume that the calxeda xgmac driver is the culprit then. It uses
> >> netdev_alloc_skb() rather than netdev_alloc_skb_ip_align() in
> >> xgmac_rx_refill but it is not clear whether it does so intentionally
> >> or by accident.
>
> This in fact does work and eliminates the unaligned traps. However, not
> all h/w can do IP aligned DMA (i.MX FEC for example), so I still think
> this is a questionable optimization by the compiler. We're saving 1 load
> instruction here for data that is likely already in the cache. It may be
> legal per the ABI, but the downside of this optimization is much greater
> than the upside.
Compiler is asked to perform a 32bit load, it does it.
There is no questionable optimization here. Really.
Please stop pretending this, this makes no sense.
As I said, if some h/w cannot do IP aligned DMA, driver can use a
workaround, or a plain memmove() (some drivers seems to do this to work
around this h/w limitation, just grep for memmove() in drivers/net)
>
> >
> > Thanks Arnd
> >
> > It seems an accident, since driver doesnt check skb->data alignment at
> > all (this can change with SLAB debug on/off)
> >
> > It also incorrectly adds 64 bytes to bfsize, there is no need for this.
>
> I'm pretty sure this was needed as the h/w writes out full bursts of
> data, but I'll go back and check.
Maybe the ALIGN() was needed then. But the 64 + NE_IP_ALIGN sounds like
the head room that we allocate/reserve in netdev_alloc_skb_ip_align()
So you allocate this extra room twice.
Thanks
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Lee Jones @ 2012-10-11 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-1-git-send-email-ulf.hansson@stericsson.com>
> Patches are based on Linus Torvalds tree with latest commit as of okt 10.
Hmm... I get:
Applying: clk: ux500: Support for prcmu_scalable_rate clock
error: drivers/clk/ux500/clk-prcmu.c: does not exist in index
error: drivers/clk/ux500/clk.h: does not exist in index
Patch failed at 0001 clk: ux500: Support for prcmu_scalable_rate clock
So when did drivers/clk/ux500/* arrive?
Or is it still sitting in your tree?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 4/8] cpufreq: db8500: Fetch cpufreq table from platform data
From: Lee Jones @ 2012-10-11 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-5-git-send-email-ulf.hansson@stericsson.com>
> -static struct cpufreq_frequency_table freq_table[] = {
> - [0] = {
> - .index = 0,
> - .frequency = 200000,
> - },
> - [1] = {
> - .index = 1,
> - .frequency = 400000,
> - },
> - [2] = {
> - .index = 2,
> - .frequency = 800000,
> - },
> - [3] = {
> - /* Used for MAX_OPP, if available */
> - .index = 3,
> - .frequency = CPUFREQ_TABLE_END,
> - },
> - [4] = {
> - .index = 4,
> - .frequency = CPUFREQ_TABLE_END,
> - },
> -};
So where has this table gone? Am I missing a patch?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Russell King - ARM Linux @ 2012-10-11 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076CA43.9070503@gmail.com>
On Thu, Oct 11, 2012 at 08:31:47AM -0500, Rob Herring wrote:
> On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
> > On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> >> The contents of this were already reviewed on this thread, so I sent this
> >> to the patch system and this was Russell's reply:
> >
> > So that's why I couldn't find it - the mailing list thread has a different
> > subject line to the patch. Don't do that. Given the amount of list
> > traffic we have today, that's as good as not having been posted at all.
> >
> >>> NAK for two reasons.
> >>>
> >>> 1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
> >>> in my mailbox)
> >>>
> >>> 2. The behaviour of unaligned accesses vary depending on CPU. Some
> >>> fix-up the access, others load the word and then rotate it. If we have
> >>> decompressors which perform unaligned accesses, we need to fix this
> >>> properly to avoid the CPU specific behaviour, rather than tweaking
> >>> control bits to hide the problem.
> >>
> >> I'm simply matching the behavior of the kernel itself. The A bit is cleared
> >> for v7 kernels and compilers only generate unaligned accesses for v7.
> >> Without this the initial state of the A bit is undefined as a bootloader
> >> could have cleared it already. We should document the required state or set
> >> it to what we want.
> >
> > Irrespective of this, (2) still stands. Unaligned accesses in the
> > decompressor without a fixup (which will be very hard to provide)
> > will return different data depending on the CPU as I mention in point
> > 2.
>
> This only affects v7 cores. It should not vary for v7 cores as unaligned
> access is a required feature. So how is it going to vary on v7 CPUs?
> We've got bigger problems if there are v7 cores that don't handle
> unaligned accesses.
Rob,
Your patch may only affect v7 cores, but you've raised the issue of the
decompressor performing unaligned accesses in general. Shall I re-repeat
my point over that or is the problem here going to finally sink in?
^ permalink raw reply
* alignment faults in 3.6
From: Arnd Bergmann @ 2012-10-11 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076C78E.1020408@gmail.com>
On Thursday 11 October 2012, Rob Herring wrote:
>
> On 10/11/2012 07:40 AM, Eric Dumazet wrote:
> > On Thu, 2012-10-11 at 12:28 +0000, Arnd Bergmann wrote:
> >
> >>
> >> Rob Herring as the original reporter has dropped off the Cc list, adding
> >> him back.
> >>
> >> I assume that the calxeda xgmac driver is the culprit then. It uses
> >> netdev_alloc_skb() rather than netdev_alloc_skb_ip_align() in
> >> xgmac_rx_refill but it is not clear whether it does so intentionally
> >> or by accident.
>
> This in fact does work and eliminates the unaligned traps. However, not
> all h/w can do IP aligned DMA (i.MX FEC for example), so I still think
> this is a questionable optimization by the compiler. We're saving 1 load
> instruction here for data that is likely already in the cache. It may be
> legal per the ABI, but the downside of this optimization is much greater
> than the upside.
>
What about the other approach that Eric suggested for such hardware
in http://www.spinics.net/lists/arm-kernel/msg200206.html ?
Arnd
^ permalink raw reply
* [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
From: Nishanth Menon @ 2012-10-11 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349313974-5473-1-git-send-email-mturquette@ti.com>
On 18:26-20121003, Mike Turquette wrote:
> From: Mike Turquette <mturquette@linaro.org>
[...]
>
> arch/arm/mach-omap2/Makefile | 8 +-
> arch/arm/mach-omap2/abb.c | 322 +++++++++++++++++++++++++
> arch/arm/mach-omap2/abb.h | 94 ++++++++
[...]
> arch/arm/plat-omap/include/plat/voltage.h | 1 +
> 18 files changed, 699 insertions(+), 37 deletions(-)
> create mode 100644 arch/arm/mach-omap2/abb.c
> create mode 100644 arch/arm/mach-omap2/abb.h
> create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
> create mode 100644 arch/arm/mach-omap2/abb44xx_data.c
dumb question: with the request to move everything out of mach-omap2
directory, do we still want to add more files into mach-omap2?
Regards,
NM
^ permalink raw reply
* alignment faults in 3.6
From: Måns Rullgård @ 2012-10-11 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076C78E.1020408@gmail.com>
Rob Herring <robherring2@gmail.com> writes:
> On 10/11/2012 07:40 AM, Eric Dumazet wrote:
>> On Thu, 2012-10-11 at 12:28 +0000, Arnd Bergmann wrote:
>>
>>>
>>> Rob Herring as the original reporter has dropped off the Cc list, adding
>>> him back.
>>>
>>> I assume that the calxeda xgmac driver is the culprit then. It uses
>>> netdev_alloc_skb() rather than netdev_alloc_skb_ip_align() in
>>> xgmac_rx_refill but it is not clear whether it does so intentionally
>>> or by accident.
>
> This in fact does work and eliminates the unaligned traps. However, not
> all h/w can do IP aligned DMA (i.MX FEC for example), so I still think
> this is a questionable optimization by the compiler. We're saving 1 load
> instruction here for data that is likely already in the cache. It may be
> legal per the ABI, but the downside of this optimization is much greater
> than the upside.
The compiler is working *exactly* as it should. Merging the loads saves
cycles *and* code size. Many of these added up can make a real difference.
When writing code, you must follow all the rules, whether you like them
or not. Without rules, the compiler would be very limited in the
optimisations it could perform.
Unfortunately, new optimisations occasionally uncover broken code
violating some constraint or other. When this happens, the correct
course of action is to fix the code, not cripple the compiler.
--
M?ns Rullg?rd
mans at mansr.com
^ permalink raw reply
* bug with 3.4.6, 3.5.3, 3.6.1
From: Gilles Chanteperdrix @ 2012-10-11 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011103637.GC30598@mudshark.cambridge.arm.com>
On 10/11/2012 12:36 PM, Will Deacon wrote:
> On Thu, Oct 11, 2012 at 06:46:35AM +0100, Gilles Chanteperdrix wrote:
>> Hi,
>
> Hi Gilles,
>
>> when booting Linux v3.4.6, v3.5.3, or v3.6.1 on a pandaboard with an
>> OMAP4430 ES2.1, compiled with the following configuration:
>> http://xenomai.org/~gch/config-panda
>>
>> I get the bug below after mounting the root filesystem.
>>
>> CONFIG_VMSPLIT_2G and CONFIG_THUMB2_KERNEL disabled seems to be the
>> combination which triggers the bug.
>>
>> With this configuration, it seems the init_mm.mm_count incrementation
>> done at the beginning of secondary_start_kernel() is "lost" after the
>> calls to cpu_switch_mm() and local_flush_tlb().
>>
>> Modifying the secondary_startup() function in head.S to pass the
>> swapper pgdir instead of the idmap pgdir in r4 also avoids the issue.
>
> What's your PHYS_OFFSET? I suspect it's >= 2GB, in which case I have some
> ideas about this problem.
Yes, according to /proc/iomem:
80000000-bfefffff : System RAM
80008000-80339fff : Kernel code
80364000-803c52e7 : Kernel data
So, PHYS_OFFSET is 0x80000000 that is, 2GB.
--
Gilles.
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Rob Herring @ 2012-10-11 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011130955.GP4625@n2100.arm.linux.org.uk>
On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
>> The contents of this were already reviewed on this thread, so I sent this
>> to the patch system and this was Russell's reply:
>
> So that's why I couldn't find it - the mailing list thread has a different
> subject line to the patch. Don't do that. Given the amount of list
> traffic we have today, that's as good as not having been posted at all.
>
>>> NAK for two reasons.
>>>
>>> 1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
>>> in my mailbox)
>>>
>>> 2. The behaviour of unaligned accesses vary depending on CPU. Some
>>> fix-up the access, others load the word and then rotate it. If we have
>>> decompressors which perform unaligned accesses, we need to fix this
>>> properly to avoid the CPU specific behaviour, rather than tweaking
>>> control bits to hide the problem.
>>
>> I'm simply matching the behavior of the kernel itself. The A bit is cleared
>> for v7 kernels and compilers only generate unaligned accesses for v7.
>> Without this the initial state of the A bit is undefined as a bootloader
>> could have cleared it already. We should document the required state or set
>> it to what we want.
>
> Irrespective of this, (2) still stands. Unaligned accesses in the
> decompressor without a fixup (which will be very hard to provide)
> will return different data depending on the CPU as I mention in point
> 2.
This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.
Rob
> So, using unaligned accesses in the decompressor may not give expected
> results in all cases, so they're best avoided.
>
> And if they're avoided, then we don't care about the setting of the A
> bit.
>
^ permalink raw reply
* alignment faults in 3.6
From: Rob Herring @ 2012-10-11 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959248.21172.8970.camel@edumazet-glaptop>
On 10/11/2012 07:40 AM, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 12:28 +0000, Arnd Bergmann wrote:
>
>>
>> Rob Herring as the original reporter has dropped off the Cc list, adding
>> him back.
>>
>> I assume that the calxeda xgmac driver is the culprit then. It uses
>> netdev_alloc_skb() rather than netdev_alloc_skb_ip_align() in
>> xgmac_rx_refill but it is not clear whether it does so intentionally
>> or by accident.
This in fact does work and eliminates the unaligned traps. However, not
all h/w can do IP aligned DMA (i.MX FEC for example), so I still think
this is a questionable optimization by the compiler. We're saving 1 load
instruction here for data that is likely already in the cache. It may be
legal per the ABI, but the downside of this optimization is much greater
than the upside.
>
> Thanks Arnd
>
> It seems an accident, since driver doesnt check skb->data alignment at
> all (this can change with SLAB debug on/off)
>
> It also incorrectly adds 64 bytes to bfsize, there is no need for this.
I'm pretty sure this was needed as the h/w writes out full bursts of
data, but I'll go back and check.
Rob
> (or if its needed, a comment would be nice, because on prior kernels,
> this makes skb->head allocations uses kmalloc-4096 instead of
> kmalloc-2048 slab cache... With 3.7 its less an issue now we use order-3
> pages to deliver fragments for rx skbs
>
> So the following patch should fix the alignment, and makes driver uses
> half memory than before for stable kernels
>
> diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
> index 16814b3..a895e18 100644
> --- a/drivers/net/ethernet/calxeda/xgmac.c
> +++ b/drivers/net/ethernet/calxeda/xgmac.c
> @@ -671,7 +671,8 @@ static void xgmac_rx_refill(struct xgmac_priv *priv)
> p = priv->dma_rx + entry;
>
> if (priv->rx_skbuff[entry] == NULL) {
> - skb = netdev_alloc_skb(priv->dev, priv->dma_buf_sz);
> + skb = netdev_alloc_skb_ip_align(priv->dev,
> + priv->dma_buf_sz);
> if (unlikely(skb == NULL))
> break;
>
> @@ -703,7 +704,7 @@ static int xgmac_dma_desc_rings_init(struct net_device *dev)
> /* Set the Buffer size according to the MTU;
> * indeed, in case of jumbo we need to bump-up the buffer sizes.
> */
> - bfsize = ALIGN(dev->mtu + ETH_HLEN + ETH_FCS_LEN + NET_IP_ALIGN + 64,
> + bfsize = ALIGN(dev->mtu + ETH_HLEN + ETH_FCS_LEN,
> 64);
>
> netdev_dbg(priv->dev, "mtu [%d] bfsize [%d]\n", dev->mtu, bfsize);
>
>
^ permalink raw reply
* [PATCH v2] vfs: bogus warnings in fs/namei.c
From: Arnd Bergmann @ 2012-10-11 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011043734.GE2616@ZenIV.linux.org.uk>
The follow_link() function always initializes its *p argument,
or returns an error, but when building with 'gcc -s', the compiler
gets confused by the __always_inline attribute to the function
and can no longer detect where the cookie was initialized.
The solution is to always initialize the pointer from follow_link,
even in the error path. When building with -O2, this has zero impact
on generated code and adds a single instruction in the error path
for a -Os build on ARM.
Without this patch, building with gcc-4.6 through gcc-4.8 and
CONFIG_CC_OPTIMIZE_FOR_SIZE results in:
fs/namei.c: In function 'link_path_walk':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1544:9: note: 'cookie' was declared here
fs/namei.c: In function 'path_lookupat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1934:10: note: 'cookie' was declared here
fs/namei.c: In function 'path_openat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:2899:9: note: 'cookie' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/fs/namei.c b/fs/namei.c
index 6d47fac..c1f18e4 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -810,6 +810,7 @@ follow_link(struct path *link, struct nameidata *nd, void **p)
return error;
out_put_nd_path:
+ *p = NULL;
path_put(&nd->path);
path_put(link);
return error;
^ permalink raw reply related
* [PATCH v2 0/6] ARM: EXYNOS: Add secure firmware support
From: Tomasz Figa @ 2012-10-11 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010161136.GD582@quad.lixom.net>
Hi Olof,
On Wednesday 10 of October 2012 09:11:36 Olof Johansson wrote:
> Hi,
>
> On Thu, Oct 11, 2012 at 12:35:54AM +0900, Kyungmin Park wrote:
> > Hi Arnd or Olof,
> >
> > Can you pick up for v3.7?
> >
> > To Tomasz,
> > Can you rebase it on the latest arm-soc tree?
>
> This code should have been in arm-soc by the beginning of the merge
> window (and in linux-next) to be merged for 3.7, but we will be happy to
> queue it up for 3.8 once 3.7-rc1 is out. I have one outstanding comment
> on the DT binding but the rest looks OK to me.
>
> Tomasz, please rebase and send this to Kukjin so he can queue it up with
> other Samsung code.
OK.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 5/6] ARM: EXYNOS: Add support for Exynos secure firmware
From: Tomasz Figa @ 2012-10-11 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010160027.GA582@quad.lixom.net>
Hi Olof,
On Wednesday 10 of October 2012 09:00:27 Olof Johansson wrote:
> Hi,
>
> On Mon, Sep 24, 2012 at 04:28:32PM +0200, Tomasz Figa wrote:
> > Some Exynos-based boards contain secure firmware and must use firmware
> > operations to set up some hardware.
> >
> > This patch adds firmware operations for Exynos secure firmware and a
> > way
> > for board code and device tree to specify that they must be used.
> >
> > Example of use:
> >
> > In board code:
> > ...MACHINE_START(...)
> >
> > /* ... */
> > .init_early = exynos_firmware_init,
> > /* ... */
> >
> > MACHINE_END
> >
> > In device tree:
> > / {
> >
> > /* ... */
> >
> > firmware {
> >
> > compatible = "samsung,secure-firmware";
> >
> > };
> >
> > /* ... */
> >
> > };
> >
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > ---
> >
> > .../devicetree/bindings/arm/samsung-boards.txt | 8 ++++
> > arch/arm/mach-exynos/Makefile | 1 +
> > arch/arm/mach-exynos/common.h | 2 +
> > arch/arm/mach-exynos/firmware.c | 54
> > ++++++++++++++++++++++ arch/arm/mach-exynos/mach-exynos4-dt.c
> > | 1 +
> > 5 files changed, 66 insertions(+)
> > create mode 100644 arch/arm/mach-exynos/firmware.c
> >
> > diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
> > b/Documentation/devicetree/bindings/arm/samsung-boards.txt index
> > 0bf68be..f447059 100644
> > --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
> > +++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
> >
> > @@ -6,3 +6,11 @@ Required root node properties:
> > - compatible = should be one or more of the following.
> >
> > (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
> > (b) "samsung,exynos4210" - for boards based on Exynos4210
> > SoC.
> >
> > +
> > +Optional:
> > + - firmware node, specifying presence and type of secure firmware,
> > currently + supported value of compatible property is
> > "samsung,secure-firmware": +
> > + firmware {
> > + compatible = "samsung,secure-firmware";
> > + };
>
> If you require the binding to specify the memory area, then you at least
> allow for future work to move to a dynamic mapping without updating the
> binding and all device trees. So, please do that even if the code is
> hardcoded to the static address today.
All right.
> For extra credit, make sure that the reg property is matching the static
> mapping when you setup your firmware interface on your platform.
Hmm, do you know a way to look up physical address of such static mapping,
given only the virtual address? Additional problem is that the code is
executed very early (in init_early callback), before most of VM
initialization code.
I could do something like
if (soc_is_exynos4210())
paddr = EXYNOS4210_PA_SYSRAM_NS;
else if (soc_is_exynos4212() || soc_is_exynos4412())
paddr = EXYNOS4x12_PA_SYSRAM_NS;
...
and compare paddr with address received from device tree, but I don't
really like this construct.
> > +static int exynos_cpu_boot_reg(int cpu, void __iomem **ptr)
> > +{
> > + *ptr = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
> > + return 0;
> > +}
>
> It would be nice to get a memory map for the SMC area in documentation
> somewhere, but that can be done separately later.
OK.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Russell King - ARM Linux @ 2012-10-11 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959402-24164-1-git-send-email-robherring2@gmail.com>
On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> The contents of this were already reviewed on this thread, so I sent this
> to the patch system and this was Russell's reply:
So that's why I couldn't find it - the mailing list thread has a different
subject line to the patch. Don't do that. Given the amount of list
traffic we have today, that's as good as not having been posted at all.
> > NAK for two reasons.
> >
> > 1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
> > in my mailbox)
> >
> > 2. The behaviour of unaligned accesses vary depending on CPU. Some
> > fix-up the access, others load the word and then rotate it. If we have
> > decompressors which perform unaligned accesses, we need to fix this
> > properly to avoid the CPU specific behaviour, rather than tweaking
> > control bits to hide the problem.
>
> I'm simply matching the behavior of the kernel itself. The A bit is cleared
> for v7 kernels and compilers only generate unaligned accesses for v7.
> Without this the initial state of the A bit is undefined as a bootloader
> could have cleared it already. We should document the required state or set
> it to what we want.
Irrespective of this, (2) still stands. Unaligned accesses in the
decompressor without a fixup (which will be very hard to provide)
will return different data depending on the CPU as I mention in point
2.
So, using unaligned accesses in the decompressor may not give expected
results in all cases, so they're best avoided.
And if they're avoided, then we don't care about the setting of the A
bit.
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959881.1232.44.camel@sakura.staff.proxad.net>
On Thu, 2012-10-11 at 14:51 +0200, Maxime Bizon wrote:
> Hey I cannot go back in time, when that hardware was built in 2004 (mips
> @250Mhz), it was considered good, and we did manufacture a lot of it, so
> it's still maintained.
>
> People run recent kernels on older hardware because they are *encouraged
> to do so*.
>
> I fought inside my company to be good kernel citizen, not using
> proprietary BSP, rewrite & mainline the drivers, because that was the
> community promise: mainline it, we will support it for you, you will get
> the latest kernel features for free.
>
>
> That worked, but with some drawbacks:
>
> - kernel footprint grew that much (we started from 2.4) that it does
> not fit in device flash anymore
>
> - performance took a hit each time we upgrade, mostly because of cache
> footprint growth.
>
> - as kernel footprint grew, available RAM for conntrack & route cache
> entries was smaller each time
>
>
> But I had to stop upgrading after 2.6.20. Everything below is not
> anybody's fault. Bloat is unavoidable for software project that big.
>
> I'm perfectly ok with that, but I don't want to be ridiculed for running
> mainline kernel on old hardware.
Hmm, I am sorry if you felt that, it was not my intent.
>
>
> > Adding get_unaligned() everywhere in linux network stacks is not an
> > option.
> >
> > We actually want to be able to read the code and fix the bugs, not only
> > run it on a cheap low end router.
>
> That was not a request, I just needed a clarification.
>
> Documentation/unaligned-memory-access.txt does not say it's a big no-no,
> it says you can give unaligned pointers to the networking stack if you
> arch can do unaligned access (with an "efficiency" notion).
>
> MIPS and ARM have a software handler for this, and performance wise in
> my case it's better to take the faults, a driver writer may think a
> benchmark will dictate what to do.
>
Sure, but all this discussion started because one arch apparently did
not like these mis alignments, and some people complained that network
guys would not add _needed_ get_unaligned_xxx() wrappers ...
So far, linux is 20 years old, I dont think we are going to add wrappers
right now. Machines that could have cared are dying anyway.
Please note we still support NET_IP_ALIGN, even if its 0 on x86.
^ permalink raw reply
* [PATCH] pinctrl/nomadik: provide stubs for legacy Nomadik
From: Arnd Bergmann @ 2012-10-11 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959302-12151-1-git-send-email-linus.walleij@stericsson.com>
On Thursday 11 October 2012, Linus Walleij wrote:
>
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The compilation of the pinctrl driver failed on the legacy
> Nomadik NHK8815 platform because it was not providing the PRCMU
> interfaces needed to support the extended alternate functions
> used by the ux500 series.
>
> Solve this by providing some stubs for the legacy platform, to
> avoid too much #ifdefs in the code per se. Theoretically this
> actually allows the Nomadik and Ux500 to have a single kernel
> image with support for the PRCM registers on the Ux500 (though
> they have incompatible archs, but the spirit is there).
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Thanks for the quick reply!
This looks like it will work correctly, but I've also just
looked into the problem deeper and found that we actually have
too many inline function alternatives in the !UX500 case.
The below is what I just added locally. I don't care which version
you end up using though, as you maintain both the driver and the
platform sides of the problem.
Arnd
commit c386dcea42be85822ef5a9ab5ab1785a063da889
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Oct 11 12:39:07 2012 +0000
mfd: db8500-prcmu: remove duplicate declarations
These are already present in dbx500-prcmu.h, so we must not define them
here or nomadik won't build.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
index b82f6ee..7ef550b 100644
--- a/include/linux/mfd/db8500-prcmu.h
+++ b/include/linux/mfd/db8500-prcmu.h
@@ -521,16 +521,12 @@ void prcmu_configure_auto_pm(struct prcmu_auto_pm_config *sleep,
struct prcmu_auto_pm_config *idle);
bool prcmu_is_auto_pm_enabled(void);
-int prcmu_config_clkout(u8 clkout, u8 source, u8 div);
int prcmu_set_clock_divider(u8 clock, u8 divider);
int db8500_prcmu_config_hotdog(u8 threshold);
int db8500_prcmu_config_hotmon(u8 low, u8 high);
int db8500_prcmu_start_temp_sense(u16 cycles32k);
int db8500_prcmu_stop_temp_sense(void);
-int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size);
-int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size);
-int prcmu_ac_wake_req(void);
void prcmu_ac_sleep_req(void);
void db8500_prcmu_modem_reset(void);
@@ -640,11 +636,6 @@ static inline bool prcmu_is_auto_pm_enabled(void)
return false;
}
-static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
-{
- return 0;
-}
-
static inline int prcmu_set_clock_divider(u8 clock, u8 divider)
{
return 0;
@@ -670,23 +661,6 @@ static inline int db8500_prcmu_stop_temp_sense(void)
return 0;
}
-static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
-{
- return -ENOSYS;
-}
-
-static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
-{
- return -ENOSYS;
-}
-
-static inline int prcmu_ac_wake_req(void)
-{
- return 0;
-}
-
-static inline void prcmu_ac_sleep_req(void) {}
-
static inline void db8500_prcmu_modem_reset(void) {}
static inline void db8500_prcmu_system_reset(u16 reset_code) {}
^ permalink raw reply related
* bug with 3.4.6, 3.5.3, 3.6.1
From: Gilles Chanteperdrix @ 2012-10-11 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011103637.GC30598@mudshark.cambridge.arm.com>
On 10/11/2012 12:36 PM, Will Deacon wrote:
> On Thu, Oct 11, 2012 at 06:46:35AM +0100, Gilles Chanteperdrix wrote:
>> Hi,
>
> Hi Gilles,
>
>> when booting Linux v3.4.6, v3.5.3, or v3.6.1 on a pandaboard with an
>> OMAP4430 ES2.1, compiled with the following configuration:
>> http://xenomai.org/~gch/config-panda
>>
>> I get the bug below after mounting the root filesystem.
>>
>> CONFIG_VMSPLIT_2G and CONFIG_THUMB2_KERNEL disabled seems to be the
>> combination which triggers the bug.
>>
>> With this configuration, it seems the init_mm.mm_count incrementation
>> done at the beginning of secondary_start_kernel() is "lost" after the
>> calls to cpu_switch_mm() and local_flush_tlb().
>>
>> Modifying the secondary_startup() function in head.S to pass the
>> swapper pgdir instead of the idmap pgdir in r4 also avoids the issue.
>
> What's your PHYS_OFFSET? I suspect it's >= 2GB, in which case I have some
> ideas about this problem.
You mean the physical address of RAM ? I believe it is 0x80000000, will
check.
--
Gilles.
^ permalink raw reply
* alignment faults in 3.6
From: Maxime Bizon @ 2012-10-11 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349956456.21172.8820.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 13:54 +0200, Eric Dumazet wrote:
> Of course, if you use a forwarding setup, and the tx driver is not SG
> capable, performance will be bad (You have to copy the data into a
> single skb (linearize the skb))
>
> But in 2012, having to use hardware without SG for a router sounds a bad
> joke (if cpu speed is _also_ too low)
Hey I cannot go back in time, when that hardware was built in 2004 (mips
@250Mhz), it was considered good, and we did manufacture a lot of it, so
it's still maintained.
People run recent kernels on older hardware because they are *encouraged
to do so*.
I fought inside my company to be good kernel citizen, not using
proprietary BSP, rewrite & mainline the drivers, because that was the
community promise: mainline it, we will support it for you, you will get
the latest kernel features for free.
That worked, but with some drawbacks:
- kernel footprint grew that much (we started from 2.4) that it does
not fit in device flash anymore
- performance took a hit each time we upgrade, mostly because of cache
footprint growth.
- as kernel footprint grew, available RAM for conntrack & route cache
entries was smaller each time
But I had to stop upgrading after 2.6.20. Everything below is not
anybody's fault. Bloat is unavoidable for software project that big.
I'm perfectly ok with that, but I don't want to be ridiculed for running
mainline kernel on old hardware.
> Adding get_unaligned() everywhere in linux network stacks is not an
> option.
>
> We actually want to be able to read the code and fix the bugs, not only
> run it on a cheap low end router.
That was not a request, I just needed a clarification.
Documentation/unaligned-memory-access.txt does not say it's a big no-no,
it says you can give unaligned pointers to the networking stack if you
arch can do unaligned access (with an "efficiency" notion).
MIPS and ARM have a software handler for this, and performance wise in
my case it's better to take the faults, a driver writer may think a
benchmark will dictate what to do.
--
Maxime
^ 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