* [v2 1/1] ARM: Add API to detect SCU base address from CP15
From: Russell King - ARM Linux @ 2013-01-21 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358754175-15484-1-git-send-email-hdoyu@nvidia.com>
On Mon, Jan 21, 2013 at 09:42:55AM +0200, Hiroshi Doyu wrote:
> Add API to detect SCU base address from CP15.
>
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> For usage: http://patchwork.ozlabs.org/patch/212013/
> ---
> arch/arm/include/asm/smp_scu.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> index 4eb6d00..1733ec7 100644
> --- a/arch/arm/include/asm/smp_scu.h
> +++ b/arch/arm/include/asm/smp_scu.h
> @@ -6,6 +6,18 @@
> #define SCU_PM_POWEROFF 3
>
> #ifndef __ASSEMBLER__
> +
> +#include <asm/cputype.h>
> +
> +static inline phys_addr_t scu_get_base(void)
> +{
> + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9) {
> + phys_addr_t pa;
> + asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (pa));
> + return pa;
> + }
> + return 0;
> +}
> unsigned int scu_get_core_count(void __iomem *);
> void scu_enable(void __iomem *);
> int scu_power_mode(void __iomem *, unsigned int);
Not sure what iteration this patch is at but... it's easy to avoid more
iterations when you review the patch yourself before sending.
Reasonable coding style suggests there should be a blank line after the
new } and before the prototypes.
However, as I _am_ commenting on this patch because of the above, I'll
also suggest that we don't do it like this. And actually, the above
code is buggy. If phys_addr_t is 64-bit, the upper half of 'pa' won't
be set.
I'd suggest this instead:
static inline bool scu_a9_has_base(void)
{
return read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9;
}
static inline unsigned long scu_a9_get_base(void)
{
unsigned long pa;
asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (pa));
return pa;
}
and let the user of these functions decide whether to read it using
scu_a9_has_base().
And why 'unsigned long' ? Well, it could also be u32, but on 32-bit
ARM, it's been more conventional to use unsigned long for phys addresses
which can't be larger than 32-bit - which this one can't because the
mrc instruction is limited to writing one 32-bit register.
^ permalink raw reply
* [PATCH v7 08/15] gpio: pl061: bind pinctrl by gpio request
From: Haojian Zhuang @ 2013-01-21 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZo6mVSaHBr6PJt8QCkiKp-Vs7mWup8n=4zyacRwf8V3g@mail.gmail.com>
On 21 January 2013 22:37, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Jan 18, 2013 at 8:31 AM, Haojian Zhuang
> <haojian.zhuang@linaro.org> wrote:
>
> > Add the pl061_gpio_request() to request pinctrl. Create the logic
> > between pl061 gpio driver and pinctrl (pinctrl-single) driver.
> >
> > While a gpio pin is requested, it will request pinctrl driver to
> > set that pin with gpio function mode. So pinctrl driver should
> > append .gpio_request_enable() in pinmux_ops.
> >
> > Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> (...)
> > +static int pl061_gpio_request(struct gpio_chip *chip, unsigned offset)
> > +{
> > + /*
> > + * Map back to global GPIO space and request muxing, the direction
> > + * parameter does not matter for this controller.
> > + */
> > + int gpio = chip->base + offset;
> > +
> > + /*
> > + * Do NOT check the return value at here. Since sometimes the gpio
> > + * pin needn't to be configured in pinmux controller. So it's
> > + * impossible to find the matched gpio range.
> > + */
> > + pinctrl_request_gpio(gpio);
>
> Handling of error code?
>
> (Maybe I should add a __must_check on this function.)
>
My case is a little special. I don't want to check return value because some
gpio pins don't have pinmux registers in Hisilicon SoC.
So pinctrl_request_gpio() will always return error for these special pins in
Hisilicon SoC.
If we must check the return value, maybe we need append a dummy pinctrl driver
for those special gpio pins. How do you think about it? Of course, I
need to evaluate
whether it's possible to implement.
> > + return 0;
> > +}
> > +
> > static int pl061_direction_input(struct gpio_chip *gc, unsigned offset)
> > {
> > struct pl061_gpio *chip = container_of(gc, struct pl061_gpio, gc);
> > @@ -251,6 +269,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
> >
> > spin_lock_init(&chip->lock);
> >
> > + chip->gc.request = pl061_gpio_request;
> > chip->gc.direction_input = pl061_direction_input;
> > chip->gc.direction_output = pl061_direction_output;
> > chip->gc.get = pl061_get_value;
>
> What happens on a platform that has a PL061
> GPIO block but no pinctrl related to it?
>
> But still has some other pinctrl driver in the platform ....
>
> Right, it'll return -EPROBE_DEFER from pinctrl_request_gpio().
>
> This may happen on for example a combined SPEAr
> kernel where some platforms have PL061 and others us
> a pin controller, so both will be enabled.
>
> I think, add a field like this to struct pl061_gpio:
>
> bool has_pinctrl_backend;
>
> The only call that from pl061_gpio_request() if this is
> set:
>
> if (pl061->has_pinctrl_backend)
> ret = pinctrl_request_gpio(gpio);
I'm OK to append "has_pinctrl_backend". But if we append a dummy pinctrl
driver, is it OK to SPEAr kernel? Do we still need has_pinctrl_backend?
>
> Then assign it in some clever way. For DT I think the
> proper way would be so add a cross-binding to the
> pin controller, like:
>
> gpio2: gpio at d8100000 {
> #gpio-cells = <2>;
> compatible = "arm,pl061", "arm,primecell";
> (...)
> pinctrl = <&mr_pincontrol>;
> };
If we could append a dummy pinctrl driver, maybe we needn't
to append pinctrl property into gpio node. What's your opinion?
>
> Then just check if you have this pinctrl binding set
> to figure out if has_pinctrl_backend should be true.
>
> Yours,
> Linus Walleij
Regards
Haojian
^ permalink raw reply
* [V4 PATCH 18/26] usb: phy: mv_usb2_phy: add externel chip support
From: Russell King - ARM Linux @ 2013-01-21 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358762864-9249-19-git-send-email-chao.xie@marvell.com>
On Mon, Jan 21, 2013 at 05:07:36AM -0500, Chao Xie wrote:
> + mv_phy->extern_chip.head = devm_kzalloc(&pdev->dev,
> + sizeof(*mv_phy->extern_chip.head),
> + GFP_KERNEL);
> + if (mv_phy->extern_chip.head == NULL)
> + return -ENOMEM;
> + ATOMIC_INIT_NOTIFIER_HEAD(mv_phy->extern_chip.head);
Why do you need to allocate an atomic notifier list head as an entirely
separate data structure?
^ permalink raw reply
* [PATCH 02/33] ARM: Convert to devm_ioremap_resource()
From: Russell King - ARM Linux @ 2013-01-21 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358762966-20791-3-git-send-email-thierry.reding@avionic-design.de>
On Mon, Jan 21, 2013 at 11:08:55AM +0100, Thierry Reding wrote:
> Convert all uses of devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
Does this include the resource part of the handling too?
^ permalink raw reply
* [PATCH] ARM: plat-samsung: using vsnprintf instead of vsprintf for the limit buffer length 256
From: Russell King - ARM Linux @ 2013-01-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD178E.9090105@asianux.com>
On Mon, Jan 21, 2013 at 06:25:18PM +0800, Chen Gang wrote:
>
> the buff size is 256, so need use vsnprintf instead of vsprintf.
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> arch/arm/plat-samsung/pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
> index 1507028..8d07b45 100644
> --- a/arch/arm/plat-samsung/pm.c
> +++ b/arch/arm/plat-samsung/pm.c
> @@ -51,7 +51,7 @@ void s3c_pm_dbg(const char *fmt, ...)
> char buff[256];
>
> va_start(va, fmt);
> - vsprintf(buff, fmt, va);
> + vsnprintf(buff, 256, fmt, va);
sizeof(buff) would be better here so that it depends on the actual buffer
size.
^ permalink raw reply
* Compilation problem with drivers/staging/zsmalloc when !SMP on ARM
From: Matt Sealey @ 2013-01-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121055541.GD3666@blaptop>
Hi Minchan,
On Sun, Jan 20, 2013 at 11:55 PM, Minchan Kim <minchan@kernel.org> wrote:
> On Fri, Jan 18, 2013 at 11:46:02PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote:
>> >
>> > diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
>> > b/drivers/staging/zsmalloc/zsmalloc-main.c
>> > index 09a9d35..ecf75fb 100644
>> > --- a/drivers/staging/zsmalloc/zsmalloc-main.c
>> > +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
>> > @@ -228,7 +228,7 @@ struct zs_pool {
>> > * mapping rather than copying
>> > * for object mapping.
>> > */
>> > -#if defined(CONFIG_ARM)
>> > +#if defined(CONFIG_ARM) && defined(CONFIG_SMP)
>> > #define USE_PGTABLE_MAPPING
>
> I don't get it. How to prevent the problem Russel described?
> The problem is that other CPU can prefetch _speculatively_ under us.
It prevents no problems, but if that isn't there, kernels build
without SMP support (i.e. specifically uniprocessor kernels) will fail
at the linker stage.
That's not desirable.
We have 3 problems here, this solves the first of them, and creates
the third. The second is constant regardless..
1) zsmalloc will not build on ARM without CONFIG_SMP because on UP
local_tlb_flush_kern_range uses a function which uses an export which
isn't required on SMP
Basically, with CONFIG_SMP (and CONFIG_UP_ON_SMP),
local_tlb_flush_kern_range is calling functions by dereference from
the per-cpu global cpu_tlb structure.
On UP (!CONFIG_SMP), it is calling functions directly (in my case,
v7wbi_local_tlb_flush_kern_range or whatever, but on v6, v5, v4 ARM
processor kernel builds it may be different) which need to be exported
outside of the MM core.
If this difference is going to stick around - Russell is refusing here
to export that/those direct functions - then the optimized vm mapping
code simply should never be allowed to run on non-SMP systems to keep
it building for everyone.
The patch above is simply a build fix for !CONFIG_SMP in this case to
force it to use the slow path for systems where the above missing
export problem will cause the linker failure.
2) the optimized vm mapping isn't per-cpu aware as per Russell's
arguments. I'll let you guys discuss that as I have no idea what the
real implications are for SMP systems (and my current testing is only
on a non-SMP CPU, I will have to go grab a couple boards from the lab
for SMP)
3) it somewhat defeats the purpose of the optimization if UP systems
(which tend to have less memory and might benefit from things like
zsmalloc/zram more) cannot use it, but SMP systems which tend to have
more memory (unless we're talking about a frugal configuration of a
virtual machine, perhaps). Given the myriad use cases of zram that is
not a pervasive or persuasive argument, I know, but it does seem
slightly backwards.
> If I don't miss something, we could have 2 choice.
>
> 1) use flush_tlb_kernel_range instead of local_flush_tlb_kernel_range
> Or
> 2) use only memory copy
>
> I guess everybody want 2 because it makes code very simple and maintainable.
> Even, rencently Joonsoo sent optimize patch.
> Look at https://lkml.org/lkml/2013/1/16/68 so zram/zcache effect caused by 2
> would be minimized.
>
> But please give me the time and I will borrow quad-core embedded target board
> and test 1 on the phone with Seth's benchmark.
In the meantime please take into account building a non-SMP kernel for
this board and testing that; if there is a way to do the flush without
using the particular function which uses the particular export that
Russell will not export, then that would be better. Maybe for
!CONFIG_SMP using flush_tlb_kernel_range is doing the exact same job
and the real patch is not to disable the optimization with
!CONFIG_SMP, but to additionally #if defined(CONFIG_SMP) around
local_flush_tlb_kernel_range and alternatively for UP use
flush_tlb_kernel_range which.. probably.. doesn't use that contentious
export?
This is far beyond the level I want to be digging around in the Linux
kernel so I am not comfortable even trying that to find out.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [GIT PULL] ARM: OMAP: some clock/hwmod fixes for v3.8-rc
From: Paul Walmsley @ 2013-01-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony,
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-v3.8-rc
for you to fetch changes up to bdcc61275232db897ba831f87a16df98ab248571:
ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls (2013-01-18 16:48:16 -0700)
- ----------------------------------------------------------------
A few OMAP integration fixes for v3.8-rc, for OMAP4 audio and OMAP2 reboot.
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/prcm_fixes_c_v3.8-rc/20130121073904/
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_v3.8-rc4 (7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619)):
text data bss total kernel
0 0 0 0 am33xx_only
+8 +24 0 +32 n800_multi_omap2xxx
+4 -8 0 -4 n800_only_a
0 0 0 0 omap1_defconfig
0 0 0 0 omap1_defconfig_1510innovator_only
0 0 0 0 omap1_defconfig_5912osk_only
-8 +8 0 0 omap2plus_defconfig
+4 +24 0 +28 omap2plus_defconfig_2430sdp_only
-8 +8 0 0 omap2plus_defconfig_cpupm
-8 +8 0 0 omap2plus_defconfig_no_pm
-8 +8 0 0 omap2plus_defconfig_omap2_4_only
-16 +16 0 0 omap2plus_defconfig_omap3_4_only
-8 +8 0 0 rmk_omap3430_ldp_allnoconfig
0 0 0 0 rmk_omap3430_ldp_oldconfig
-8 +8 0 0 rmk_omap4430_sdp_allnoconfig
-16 +16 0 0 rmk_omap4430_sdp_oldconfig
Jon Hunter (1):
ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls
Peter Ujfalusi (2):
ARM: OMAP4: clock data: Lock ABE DPLL on all revisions
ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM
arch/arm/mach-omap2/cclock2420_data.c | 2 ++
arch/arm/mach-omap2/cclock2430_data.c | 2 ++
arch/arm/mach-omap2/cclock44xx_data.c | 13 ++++++-------
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 +++++-
4 files changed, 15 insertions(+), 8 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQ/WYEAAoJEMePsQ0LvSpLjwcP/3ZgPMHcwk+/rdSOtCF9BR4V
BFc9GSyUnj5jJMmVo2yixHgM6hnf0nqP9lEHW6wYaqFF7wb6swo5mKCsK3VErgF/
xJXL1j9DmdnnF+uUeoRmKlNkQ2y2+zkbHCBY8A6zxzKQMYW6xSwkhM1Jdmw55Vxn
ROgPXuzjOnXUsTtodYsVkW/3hGNKCxoP8/hH7M+GcQVql9Iebh2E/efW67pSFTvp
ChisfYiHWJWzDso8FfKkLwYHSZfK5qq3KNFgRq2n0xuxEsJMGqM5rKaQypJ6LMK/
ExvPgFAhgHnsSvtESNWAKsAXDtVvr2z/HYPIsoCVYUy7C33P857uQpbIXuD4gS4w
CLon1M9k4Wpuzd4Da/WY6O8L6goCrTuL7Cx1ayWBmvZNDpwNAUVQi8k1Ei9vcFiv
N3vxutc/QrYQ11x7uNe2A8XWp8fsVvwQ6+XiVk96ZXgKe+Fc1COOz17lMyxhJqdo
PhAXvnvo5avzDueiu4AluFkIwsNl5vDqphkxqhOdlDzcuZHN4dzguoN/fKIbSXfy
fKS6GXDwU1vTTpvzbefdDUiVU+rEi9HIbXv8tkXp5FPnAs0YLD0vdbC6bIeUFO1K
S7AW075XkmB04VYPZeUh6vBCBjoWXYClMyIzeEEVvAxOTEHMi3+nZn7jIel7uVMa
l0wEGhU+lY3MHfbHdmh2
=1k3b
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v9 05/22] mfd: omap-usb-tll: Clean up clock handling
From: Russell King - ARM Linux @ 2013-01-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358766286-5425-1-git-send-email-rogerq@ti.com>
On Mon, Jan 21, 2013 at 01:04:46PM +0200, Roger Quadros wrote:
> Every channel has a functional clock that is similarly named.
> It makes sense to use a for loop to manage these clocks as OMAPs
> can come with up to 3 channels.
>
> Dynamically allocate and get channel clocks depending on the
> number of clocks avaiable on the platform.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
Much better from the clk API usage, thanks.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
^ permalink raw reply
* [PATCH 7/7] clk: vexpress: Use common of_clk_init() function
From: Pawel Moll @ 2013-01-21 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130118175827.3982.65450@quantum>
On Fri, 2013-01-18 at 17:58 +0000, Mike Turquette wrote:
> Quoting Prashant Gaikwad (2013-01-03 23:00:58)
> > Use common of_clk_init() function for clock initialization.
> >
> > Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
>
> Pawel or Linus,
>
> Can I get a Tested-by before I take this series into clk-next?
I'll just got back to work and will test it soon, most likely tomorrow.
Cheers!
Pawel
^ permalink raw reply
* [PATCH 02/33] ARM: Convert to devm_ioremap_resource()
From: Thierry Reding @ 2013-01-21 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121155846.GN23505@n2100.arm.linux.org.uk>
On Mon, Jan 21, 2013 at 03:58:46PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 21, 2013 at 11:08:55AM +0100, Thierry Reding wrote:
> > Convert all uses of devm_request_and_ioremap() to the newly introduced
> > devm_ioremap_resource() which provides more consistent error handling.
>
> Does this include the resource part of the handling too?
I'm not sure I understand your question. devm_ioremap_resource() does a
devm_request_mem_region() internally if that's what you were asking.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130121/b1ffe047/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] ARM: cache-l2x0: Manage the errata at run time
From: Russell King - ARM Linux @ 2013-01-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121131451.GA29855@bnru10>
On Mon, Jan 21, 2013 at 06:44:53PM +0530, srinidhi kasagar wrote:
> +/*
> + * Identify ther RTL releases of l2x0 - This might help in applying
> + * the l2x0 errata's dynamically rather compile time options
> + */
> +asmlinkage u32 l2x0_get_rtl_release(void)
Why asmlinkage?
> +{
> + return readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
> + L2X0_CACHE_ID_RTL_MASK;
> +}
> +
> static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
> {
> /* wait for cache operation by line or way to complete */
> @@ -87,46 +97,41 @@ static inline void l2x0_inv_line(unsigned long addr)
> writel_relaxed(addr, base + L2X0_INV_LINE_PA);
> }
>
> -#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
> -static inline void debug_writel(unsigned long val)
> +static void debug_writel(unsigned long val)
> {
> - if (outer_cache.set_debug)
> - outer_cache.set_debug(val);
> + u32 l2x0_revision = l2x0_get_rtl_release();
> +
> + if (l2x0_revision == L2X0_CACHE_ID_RTL_R3P0 ||
> + l2x0_revision == L2X0_CACHE_ID_RTL_R2P0 ||
> + l2x0_revision == L2X0_CACHE_ID_RTL_R1P0 ||
> + l2x0_revision == L2X0_CACHE_ID_RTL_R0P0)
> + if (outer_cache.set_debug)
> + outer_cache.set_debug(val);
This needs comments from the TI folk. Also, change this around - if
there's no setting for 'set_debug' there's no point reading the rtl
release and checking it against a set of values. Added Santosh.
> static inline void l2x0_flush_line(unsigned long addr)
> {
> void __iomem *base = l2x0_base;
> - cache_wait(base + L2X0_CLEAN_INV_LINE_PA, 1);
> - writel_relaxed(addr, base + L2X0_CLEAN_INV_LINE_PA);
> + u32 l2x0_revision = l2x0_get_rtl_release();
> +
> + if (l2x0_revision == L2X0_CACHE_ID_RTL_R0P0 ||
> + l2x0_revision == L2X0_CACHE_ID_RTL_R1P0)
> + {
Coding standards.
if (l2x0_revision == L2X0_CACHE_ID_RTL_R0P0 ||
l2x0_revision == L2X0_CACHE_ID_RTL_R1P0) {
^ permalink raw reply
* [PATCH 4/4] ARM: apply the l2x0 Errata 769419 at run time
From: Russell King - ARM Linux @ 2013-01-21 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121131709.GA29927@bnru10>
On Mon, Jan 21, 2013 at 06:47:12PM +0530, srinidhi kasagar wrote:
> Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> ---
> arch/arm/kernel/process.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index c6dec5f..c94d84f 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -39,6 +39,7 @@
> #include <asm/thread_notify.h>
> #include <asm/stacktrace.h>
> #include <asm/mach/time.h>
> +#include <asm/hardware/cache-l2x0.h>
>
> #ifdef CONFIG_CC_STACKPROTECTOR
> #include <linux/stackprotector.h>
> @@ -201,9 +202,11 @@ void cpu_idle(void)
> * to ensure we don't miss a wakeup call.
> */
> local_irq_disable();
> -#ifdef CONFIG_PL310_ERRATA_769419
> - wmb();
> -#endif
> +
> + /* Check for PL310 ERRATA 769419 */
> + if (l2x0_get_rtl_release() == L2X0_CACHE_ID_RTL_R3P0)
> + wmb();
You have to be joking if you think that is suitable... two reasons:
1. It's a horrid layering violation.
2. l2x0_get_rtl_release() unconditionally reads from a register in the L2
controller. What if you don't have a L2 controller?
Is it really worth this hastle, or would it just be better to keep the
ifdef there, using the configuration symbol as a way to indicate whether
we want this work-around included in the kernel, and always have the
wmb() there if the symbol is enabled?
^ permalink raw reply
* [PATCH 02/33] ARM: Convert to devm_ioremap_resource()
From: Russell King - ARM Linux @ 2013-01-21 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121160547.GA10790@avionic-0098.adnet.avionic-design.de>
On Mon, Jan 21, 2013 at 05:05:47PM +0100, Thierry Reding wrote:
> On Mon, Jan 21, 2013 at 03:58:46PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 21, 2013 at 11:08:55AM +0100, Thierry Reding wrote:
> > > Convert all uses of devm_request_and_ioremap() to the newly introduced
> > > devm_ioremap_resource() which provides more consistent error handling.
> >
> > Does this include the resource part of the handling too?
>
> I'm not sure I understand your question. devm_ioremap_resource() does a
> devm_request_mem_region() internally if that's what you were asking.
Ah, that's fine then. The function name is a little misleading, and as
it doesn't exist in mainline at present, it is not something I know about.
^ permalink raw reply
* Compilation problem with drivers/staging/zsmalloc when !SMP on ARM
From: Matt Sealey @ 2013-01-21 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130119044602.GC5391@phenom.dumpdata.com>
On Fri, Jan 18, 2013 at 10:46 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote:
>> On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux
>>
>> I'm gonna put this out to the maintainers (Konrad, and Seth since he
>> committed it) that if this code is buggy it gets taken back out, even
>> if it makes zsmalloc "slow" on ARM, for the following reasons:
>
> Just to make sure I understand, you mean don't use page table
> mapping but instead use copying?
Yes, just back out the USE_PGTABLE_MAPPING code. But as I just replied
with Minchan, maybe there is a better way.
The only real problem here apart from the non-per-cpu usage Russell
describes (which does not affect UP systems anyway) is that without
CONFIG_SMP we have a FTBFS.
However I am sure you agree on the odd fix of enabling pagetable
mapping optimization only on "high end" systems and leaving the low
end using the slow path. It *is* odd. Also, my rudimentary patch for
disabling the code on !CONFIG_SMP is just *hiding* a misuse of a
non-exported mm function...
The FTBFS showed the problem, I don't want the fix to be to hide it,
which is why I brought it up.
>> * It's buggy on SMP as Russell describes above
>> * It might not be buggy on UP (opposite to Russell's description above
>> as the restrictions he states do not exist), but that would imply an
>> export for a really core internal MM function nobody should be using
>> anyway
>> * By that assessment, using that core internal MM function on SMP is
>> also bad voodoo that zsmalloc should not be doing
>
> 'local_tlb_flush' is bad voodoo?
See previous mail to Minchan; local_tlb_flush_kernel_range calls
cpu_tlb.flush_kernel_range on SMP, but a direct function call
("glue(_TLB, flush_kernel_range)" which resolves to
v7wbi_flush_kernel_range etc. etc.) without CONFIG_SMP. That direct
function call it resolves to is not an export and Russell just said he
won't accept a patch to export it.
> If you have an ARM server that you would be willing to part with I would
> be thrilled to look at it.
>> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
>> b/drivers/staging/zsmalloc/zsmalloc-main.c
>> index 09a9d35..ecf75fb 100644
> > --- a/drivers/staging/zsmalloc/zsmalloc-main.c
>> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
>> @@ -228,7 +228,7 @@ struct zs_pool {
>> * mapping rather than copying
>> * for object mapping.
>> */
>> -#if defined(CONFIG_ARM)
>> +#if defined(CONFIG_ARM) && defined(CONFIG_SMP)
>> #define USE_PGTABLE_MAPPING
>> #endif
>>
>> .. such that it even compiles in both "guess" configurations, the
>> slower Cortex-A8 600MHz single core system gets to use the slow copy
>> path and the dual-core 1GHz+ Cortex-A9 (with twice the RAM..) gets to
>> use the fast mapping path. Essentially all the patch does is "improve
>> performance" on the fastest, best-configured, large-amounts-of-RAM,
>> lots-of-CPU-performance ARM systems (OMAP4+, Snapdragon, Exynos4+,
>> marvell armada, i.MX6..) while introducing the problems Russell
>> describes, and leave performance exactly the same and potentially far
>> more stable on the slower, memory-limited ARM machines.
>
> Any ideas on how to detect that?
Nope, sorry. It would rely on knowing the precise configuration *and*
the user intent of using zram which is far beyond the scope of zram or
zsmalloc itself. It could be a VM, a phone with only 256MB RAM and
slow storage, it could be a device with 2TB RAM but no fast local
storage.. whether using it as a compressed block device or a swap
device that is compressed, you can never know inside the driver what
the real use it except the kernel build time config.
All we can know in zram, at build time, is whether we're configuring
for SMP, UP-on-SMP, or UP (!SMP) and which code path makes more sense
to build (ideally, SMP and UP would run the pagetable mapping code
alike). If we can make the pagetable mapping code compile on UP
without the above patch being required, and it has the same effect,
then this would be the best solution. Then the code needs to be fixed
for proper operation on SMP anyway.
If there are still a bunch of export problems with an alternate method
of flushing the tlb for a range of kernel memory exposed by trying a
different way around, this is just proving an issue here that the ARM
guys disagree that things that can be built as modules should be doing
such things, or that the cpu_tlb.flush_kernel_range vs.
v7wbi_tlb_flush_kernel_range export thing is confusing as crap at the
very least in that the CPU topology model the kernel lives by and is
compiled for at build time causes build breakages if you don't want
(or have) your driver to be knowledgable of the differences :)
>> can build for SMP and UP and get the same code.. with less bugs.
>
> I get that you want to have this fixed right now.
Somewhat. It is not urgent, since I fixed it "for now" in my tree, I
am just worried that if that "fix" goes upstream it hides a real, more
important issue here.
I am mostly only concerned about whether zram as swap in any
configuration causes any issues with performance on my system, as I
would *like* to use it. We have noticed in the past (when it was
compcache, and zram before the xsmalloc ->zsmalloc/zcache2 rewrite)
that it did make a difference. Given the changes I just wanted to be
sure. We have some acceptably performing storage but limited RAM, so
there has to be a happy medium between reserving an in-memory
compressed block device and an amount of real disk swap in the back,
for use cases such as webservers with high number of connections, web
browsers with high numbers of tabs, media playback and suchlike.
Compression obviously takes CPU time, but swapping to disk blocks, so
keeping the system feeling smooth from a UX point of view while
allowing them to do a tiny bit more is what we're looking for. As I
said, we saw great benefits a couple years ago, a year ago, I just
wanted to pull some benchmarks from a current kernel. I was not under
the impression, though, that this code would FTBFS on my preferred
kernel configuration :D
> fixed the right way is a better choice. Lets discuss that first
> before we start tossing patches to disable parts of it.
Agreed.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH v5 00/12] clk: exynos4: migrate to common clock framework
From: Tomasz Figa @ 2013-01-21 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD50BC.4020902@samsung.com>
Hi Thomas, Sylwester,
On Monday 21 of January 2013 15:29:16 Sylwester Nawrocki wrote:
> On 12/30/2012 01:33 AM, Thomas Abraham wrote:
> > Changes since v4:
> > - Rebased to linux-3.8-rc1.
> >
> > Changes since v3:
> > - Includes changes suggested by Tomasz Figa <tomasz.figa@gmail.com>
> >
> > This patch series migrates the Samsung Exynos4 SoC clock code to adopt
> > the common clock framework. The use of Samsung specific clock
> > structures has been removed and all board support code has been
> > updated. imx-style of clock registration and lookup has been adopted
> > for device tree based exynos4 platforms.
> >
> > This patch series depends on this series:
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg14471
> > .html and this patch
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg14472
> > .html>
> > Thomas Abraham (12):
> > clk: samsung: add common clock framework helper functions for
> > Samsung platforms clk: samsung: add pll clock registration helper
> > functions
> > clk: exynos4: register clocks using common clock framework
> > ARM: Exynos: Rework timer initialization sequence
> > ARM: Exynos4: Migrate clock support to common clock framework
> > ARM: dts: add exynos4 clock controller nodes
> > ARM: dts: add xxti and xusbxti fixed rate clock nodes for exynos4
> > based platforms ARM: Exynos4: allow legacy board support to specify
> > xxti and xusbxti clock speed ARM: dts: add clock provider
> > information for all controllers in Exynos4 SoC ARM: Exynos4: remove
> > auxdata table from machine file
> > ARM: Exynos: use fin_pll clock as the tick clock source for mct
> > ARM: Exynos: add support for mct clock setup
> >
> > .../devicetree/bindings/clock/exynos4-clock.txt | 215 +++++++
> > arch/arm/boot/dts/exynos4.dtsi | 50 ++
> > arch/arm/boot/dts/exynos4210-origen.dts | 12 +
> > arch/arm/boot/dts/exynos4210-smdkv310.dts | 12 +
> > arch/arm/boot/dts/exynos4210.dtsi | 6 +
> > arch/arm/boot/dts/exynos4412-origen.dts | 12 +
> > arch/arm/boot/dts/exynos4412-smdk4412.dts | 12 +
> > arch/arm/boot/dts/exynos4x12.dtsi | 6 +
> > arch/arm/mach-exynos/Kconfig | 1 +
> > arch/arm/mach-exynos/Makefile | 3 -
> > arch/arm/mach-exynos/clock-exynos4.h | 35 -
> > arch/arm/mach-exynos/clock-exynos4210.c | 188 ------
> > arch/arm/mach-exynos/clock-exynos4212.c | 192 ------
> > arch/arm/mach-exynos/common.c | 57 ++-
> > arch/arm/mach-exynos/common.h | 21 +-
> > arch/arm/mach-exynos/mach-armlex4210.c | 3 +-
> > arch/arm/mach-exynos/mach-exynos4-dt.c | 72 +--
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 2 +-
> > arch/arm/mach-exynos/mach-nuri.c | 5 +-
> > arch/arm/mach-exynos/mach-origen.c | 5 +-
> > arch/arm/mach-exynos/mach-smdk4x12.c | 5 +-
> > arch/arm/mach-exynos/mach-smdkv310.c | 7 +-
> > arch/arm/mach-exynos/mach-universal_c210.c | 3 +-
> > arch/arm/mach-exynos/mct.c | 32 +-
> > arch/arm/plat-samsung/Kconfig | 4 +-
> > drivers/clk/Makefile | 1 +
> > drivers/clk/samsung/Makefile | 6 +
> > drivers/clk/samsung/clk-exynos4.c | 655
> > ++++++++++++++++++++ drivers/clk/samsung/clk-pll.c
> > | 400 ++++++++++++ drivers/clk/samsung/clk-pll.h
> > | 38 ++
> > drivers/clk/samsung/clk.c | 180 ++++++
> > drivers/clk/samsung/clk.h | 216 +++++++
> > 32 files changed, 1919 insertions(+), 537 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/exynos4-clock.txt delete
> > mode 100644 arch/arm/mach-exynos/clock-exynos4.h
> > delete mode 100644 arch/arm/mach-exynos/clock-exynos4210.c
> > delete mode 100644 arch/arm/mach-exynos/clock-exynos4212.c
> > create mode 100644 drivers/clk/samsung/Makefile
> > create mode 100644 drivers/clk/samsung/clk-exynos4.c
> > create mode 100644 drivers/clk/samsung/clk-pll.c
> > create mode 100644 drivers/clk/samsung/clk-pll.h
> > create mode 100644 drivers/clk/samsung/clk.c
> > create mode 100644 drivers/clk/samsung/clk.h
>
> Thanks Thomas! The patch series generally looks good to me, I've tested
> it on an Exynos4412 based board. I have applied couple fixes that Tomasz
> Figa has sent you off the mailing list. And to make a MIPI-CSI2 camera
> working a small fixup patch as below.
>
> I have just one remark, but this could possibly be done as a follow up
> patch. Namely it may make sense to rename various sclk_* clocks to just
> "sclk", so for instance we don't have "fimd", "sclk_fimd", "fimc",
> "sclk_fimc" but e.g. "bus" or "gate" and "sclk" for each device. Such
> naming might be better for handling devices at core subsystems level,
> e.g. Runtime PM or devfreq.
>
> Please feel free to add:
>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
I fully agree with Sylwester. After adding mentioned fixup patches, feel
free to add my Reviewed-by and Tested-by as well.
>
> I would be great to have this patch set merged for 3.9, so people can
> switch earlier to the common clock API, rather than modifying files
> that will be removed soon.
Yes, it would be great to have this series merged earlier, because it's
very important for further development of Device Tree support on Samsung
platforms. Possibly for 3.9 it could be merged as an alternative to the
legacy clock code and after enough testing legacy code could be dropped in
next kernel release.
Best regards
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [PATCH v7 09/15] gpio: pl061: set initcall level to module init
From: Pawel Moll @ 2013-01-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb=vf5s-XmfYYn5W-BjeNaf9vw6-sDSH6VDC41PBX0rdQ@mail.gmail.com>
On Mon, 2013-01-21 at 14:41 +0000, Linus Walleij wrote:
> On Fri, Jan 18, 2013 at 8:31 AM, Haojian Zhuang
> <haojian.zhuang@linaro.org> wrote:
>
> > Replace subsys initcall by module initcall level. Since pinctrl
> > driver is already launched before gpio driver. It's unnecessary
> > to set gpio driver in subsys init call level.
> >
> > Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
>
> On you platform maybe it works, but have you made sure that nobody
> else will be affected?
>
> SPEAr of course, then these:
>
> arch/arm/mach-realview/core.c: * GPIO on PL061 is active,
> which is the proper
> arch/arm/mach-socfpga/Kconfig: select GPIO_PL061 if GPIOLIB
>
> Pawel, Dinh: are you OK with this change?
Hm. Doesn't this make the MMCI probing depending on the module_init
order? As in: wouldn't it make the mmci probe completely fail (not even
defer it) if it was called before the pl061? In that case even your,
Linus, hack with inverting the CD status wouldn't work...
Pawel
^ permalink raw reply
* Compilation problem with drivers/staging/zsmalloc when !SMP on ARM
From: Russell King - ARM Linux @ 2013-01-21 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1b=whdh9=ke0efUXnJdT-op=7G1uVh82=3OxT5GoHhWvdA@mail.gmail.com>
On Mon, Jan 21, 2013 at 10:20:38AM -0600, Matt Sealey wrote:
> See previous mail to Minchan; local_tlb_flush_kernel_range calls
> cpu_tlb.flush_kernel_range on SMP, but a direct function call
> ("glue(_TLB, flush_kernel_range)" which resolves to
> v7wbi_flush_kernel_range etc. etc.) without CONFIG_SMP.
Actually, that's wrong - it's got nothing to do with SMP vs non-SMP.
It's more to do with which CPUs are being supported. If they all use one
single cache maintanence implementation, then direct calls are used as an
optimization. If they require more than one cache maintanence
implementation, they are indirect calls. SMP really doesn't come into
that decision.
So:
> >> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> index 09a9d35..ecf75fb 100644
> > > --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> @@ -228,7 +228,7 @@ struct zs_pool {
> >> * mapping rather than copying
> >> * for object mapping.
> >> */
> >> -#if defined(CONFIG_ARM)
> >> +#if defined(CONFIG_ARM) && defined(CONFIG_SMP)
Would be wrong.
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Mark Jackson @ 2013-01-21 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301202136290.31667@utopia.booyaka.com>
Vaibhav / Matt
On 20/01/13 21:38, Paul Walmsley wrote:
>
> Here are some basic OMAP test results for Linux v3.8-rc4.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/
<snip>
> Failing tests: needing investigation
> ------------------------------------
>
> Boot tests:
>
> * am335xbone: hangs after "Starting kernel"
> - Cause unknown
> - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
<snip>
> Failing tests: needing local investigation (may be due to testbed issues)
> -------------------------------------------------------------------------
>
> Boot tests:
>
> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> - May be fixed now, pending retest:
> - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> - Not yet part of the automated test suite
> - Nishanth Menon & Vaibhav Hiremath report that it works for them
> * May be due to an old U-boot with FDT support problems used here?
> Pending local investigation and re-test
Does anyone know when the BeagleBone support is going to be fixed in mainline ?
I've just tried the latest linux-next git, and no joy.
However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:-
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4
(Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
Are we just waiting for Matt's DMA stuff to be accepted ?
Cheers
Mark J.
^ permalink raw reply
* [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Russell King - ARM Linux @ 2013-01-21 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FCD463.5000006@ti.com>
On Mon, Jan 21, 2013 at 11:08:43AM +0530, Sekhar Nori wrote:
> > + if (IS_ERR_OR_NULL(r)) {
> > + dev_err(dev, "platform_get_resource() error: %ld\n",
> > + PTR_ERR(r));
> > +
> > + return PTR_ERR(r);
Sigh. Bug.
> > + }
> > + host1cfg_physaddr = (unsigned long)r->start;
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(dev, "platform_get_irq(pdev, 0) error: %d\n", irq);
> > +
> > + return irq;
> > + }
> > +
> > + irq_data = irq_get_irq_data(irq);
> > + if (IS_ERR_OR_NULL(irq_data)) {
> > + dev_err(dev, "irq_get_irq_data(%d) error: %ld\n",
> > + irq, PTR_ERR(irq_data));
> > +
> > + return PTR_ERR(irq_data);
Bug.
> > + }
> > + ack_fxn = irq_data->chip->irq_ack;
> > +
> > + ret = request_threaded_irq(irq, davinci_rproc_callback, handle_event,
> > + 0, "davinci-remoteproc", drproc);
> > + if (ret) {
> > + dev_err(dev, "request_threaded_irq error: %d\n", ret);
> > +
> > + return ret;
> > + }
> > +
> > + syscfg0_base = ioremap(host1cfg_physaddr & PAGE_MASK, SZ_4K);
> > + host1cfg_offset = offset_in_page(host1cfg_physaddr);
> > + writel(rproc->bootaddr, syscfg0_base + host1cfg_offset);
> > +
> > + dsp_clk = clk_get(dev, NULL);
>
> devm_clk_get() here.
>
> > + if (IS_ERR_OR_NULL(dsp_clk)) {
> > + dev_err(dev, "clk_get error: %ld\n", PTR_ERR(dsp_clk));
> > + ret = PTR_ERR(dsp_clk);
Bug.
See, yet again... almost every use of IS_ERR_OR_NULL() is a bug.
^ permalink raw reply
* [PATCH] MAINTAINERS: Add ARM/Zynq architecture entry
From: Michal Simek @ 2013-01-21 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
MAINTAINERS | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e2a1f6..61bf074 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1264,6 +1264,14 @@ S: Maintained
F: arch/arm/mach-pxa/z2.c
F: arch/arm/mach-pxa/include/mach/z2.h
+ARM/ZYNQ ARCHITECTURE
+M: Michal Simek <michal.simek@xilinx.com>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+W: http://wiki.xilinx.com
+T: git git://git.xilinx.com/linux-xlnx.git
+S: Supported
+F: arch/arm/mach-zynq/
+
ARM64 PORT (AARCH64 ARCHITECTURE)
M: Catalin Marinas <catalin.marinas@arm.com>
M: Will Deacon <will.deacon@arm.com>
--
1.7.0.4
^ permalink raw reply related
* OMAP baseline test results for v3.8-rc4
From: Nishanth Menon @ 2013-01-21 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD6D8D.6030106@mimc.co.uk>
On 16:32-20130121, Mark Jackson wrote:
> Vaibhav / Matt
>
> On 20/01/13 21:38, Paul Walmsley wrote:
[...]
>
> > Failing tests: needing local investigation (may be due to testbed issues)
> > -------------------------------------------------------------------------
> >
> > Boot tests:
> >
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > - May be fixed now, pending retest:
> > - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> > - Not yet part of the automated test suite
> > - Nishanth Menon & Vaibhav Hiremath report that it works for them
> > * May be due to an old U-boot with FDT support problems used here?
> > Pending local investigation and re-test
>
> Does anyone know when the BeagleBone support is going to be fixed in mainline ?
>
> I've just tried the latest linux-next git, and no joy.
>
> However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:-
>
> Uncompressing Linux... done, booting the kernel.
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4
> (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013
> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
>
> Are we just waiting for Matt's DMA stuff to be accepted ?
>
for MMC filesystem - we need the edma series. for a ramdisk, I am able
to boot up to shell with 3.8-rc4 tag
see: http://pastebin.com/bGNxJnZJ
build configuration:
compiler:
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
U-boot:
git://git.denx.de/u-boot.git v2013.01-rc3
config: am335x_evm_config
kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v3.8-rc4
config: omap2plus_defconfig
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v7 01/15] Revert "pinctrl: single: support gpio request and free"
From: Tony Lindgren @ 2013-01-21 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358494279-16503-2-git-send-email-haojian.zhuang@linaro.org>
* Haojian Zhuang <haojian.zhuang@linaro.org> [130117 23:34]:
> This reverts commit 2e8b2eab94c35d83bb7da71c63b4695f32ddca88.
>
> Conflicts:
> drivers/pinctrl/pinctrl-single.c
>
> ERROR: "__aeabi_uldivmod" [drivers/pinctrl/pinctrl-single.ko]
> undefined!]
>
> On Fri, Jan 11, 2013 at 4:00 PM, Russell King wrote:
>
> > The above error happens in builds including pinctrl-single - the
> > reason
> > is this, where resource_size_t may be 64-bit.
> >
> > gpio->range.pin_base = (r.start - pcs->res->start) /
> > mux_bytes;
> > gpio->range.npins = (r.end - r.start) / mux_bytes + 1;
>
> The reason of not fixing this issue and reverting the patch instead is
> this patch can't handle another case. It's not easy to handle multiple
> gpios sharing one pin register. So this gpio range feature will be
> implemented by other patches.
Makes sense to me, I don't think we have any users yet for this:
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/pinctrl/pinctrl-single.c | 79 +-------------------------------------
> 1 file changed, 2 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index f6a360b..5c32e88 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -30,7 +30,6 @@
> #define PCS_MUX_BITS_NAME "pinctrl-single,bits"
> #define PCS_REG_NAME_LEN ((sizeof(unsigned long) * 2) + 1)
> #define PCS_OFF_DISABLED ~0U
> -#define PCS_MAX_GPIO_VALUES 2
>
> /**
> * struct pcs_pingroup - pingroups for a function
> @@ -78,16 +77,6 @@ struct pcs_function {
> };
>
> /**
> - * struct pcs_gpio_range - pinctrl gpio range
> - * @range: subrange of the GPIO number space
> - * @gpio_func: gpio function value in the pinmux register
> - */
> -struct pcs_gpio_range {
> - struct pinctrl_gpio_range range;
> - int gpio_func;
> -};
> -
> -/**
> * struct pcs_data - wrapper for data needed by pinctrl framework
> * @pa: pindesc array
> * @cur: index to current element
> @@ -414,26 +403,9 @@ static void pcs_disable(struct pinctrl_dev *pctldev, unsigned fselector,
> }
>
> static int pcs_request_gpio(struct pinctrl_dev *pctldev,
> - struct pinctrl_gpio_range *range, unsigned pin)
> + struct pinctrl_gpio_range *range, unsigned offset)
> {
> - struct pcs_device *pcs = pinctrl_dev_get_drvdata(pctldev);
> - struct pcs_gpio_range *gpio = NULL;
> - int end, mux_bytes;
> - unsigned data;
> -
> - gpio = container_of(range, struct pcs_gpio_range, range);
> - end = range->pin_base + range->npins - 1;
> - if (pin < range->pin_base || pin > end) {
> - dev_err(pctldev->dev,
> - "pin %d isn't in the range of %d to %d\n",
> - pin, range->pin_base, end);
> - return -EINVAL;
> - }
> - mux_bytes = pcs->width / BITS_PER_BYTE;
> - data = pcs->read(pcs->base + pin * mux_bytes) & ~pcs->fmask;
> - data |= gpio->gpio_func;
> - pcs->write(data, pcs->base + pin * mux_bytes);
> - return 0;
> + return -ENOTSUPP;
> }
>
> static struct pinmux_ops pcs_pinmux_ops = {
> @@ -907,49 +879,6 @@ static void pcs_free_resources(struct pcs_device *pcs)
>
> static struct of_device_id pcs_of_match[];
>
> -static int pcs_add_gpio_range(struct device_node *node, struct pcs_device *pcs)
> -{
> - struct pcs_gpio_range *gpio;
> - struct device_node *child;
> - struct resource r;
> - const char name[] = "pinctrl-single";
> - u32 gpiores[PCS_MAX_GPIO_VALUES];
> - int ret, i = 0, mux_bytes = 0;
> -
> - for_each_child_of_node(node, child) {
> - ret = of_address_to_resource(child, 0, &r);
> - if (ret < 0)
> - continue;
> - memset(gpiores, 0, sizeof(u32) * PCS_MAX_GPIO_VALUES);
> - ret = of_property_read_u32_array(child, "pinctrl-single,gpio",
> - gpiores, PCS_MAX_GPIO_VALUES);
> - if (ret < 0)
> - continue;
> - gpio = devm_kzalloc(pcs->dev, sizeof(*gpio), GFP_KERNEL);
> - if (!gpio) {
> - dev_err(pcs->dev, "failed to allocate pcs gpio\n");
> - return -ENOMEM;
> - }
> - gpio->range.name = devm_kzalloc(pcs->dev, sizeof(name),
> - GFP_KERNEL);
> - if (!gpio->range.name) {
> - dev_err(pcs->dev, "failed to allocate range name\n");
> - return -ENOMEM;
> - }
> - memcpy((char *)gpio->range.name, name, sizeof(name));
> -
> - gpio->range.id = i++;
> - gpio->range.base = gpiores[0];
> - gpio->gpio_func = gpiores[1];
> - mux_bytes = pcs->width / BITS_PER_BYTE;
> - gpio->range.pin_base = (r.start - pcs->res->start) / mux_bytes;
> - gpio->range.npins = (r.end - r.start) / mux_bytes + 1;
> -
> - pinctrl_add_gpio_range(pcs->pctl, &gpio->range);
> - }
> - return 0;
> -}
> -
> static int pcs_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> @@ -1046,10 +975,6 @@ static int pcs_probe(struct platform_device *pdev)
> goto free;
> }
>
> - ret = pcs_add_gpio_range(np, pcs);
> - if (ret < 0)
> - goto free;
> -
> dev_info(pcs->dev, "%i pins at pa %p size %u\n",
> pcs->desc.npins, pcs->base, pcs->size);
>
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Ezequiel Garcia @ 2013-01-21 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121123020.GI15707@e106331-lin.cambridge.arm.com>
Hi Mark,
On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> [...]
>
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index 01ce462..f7de9eb 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -39,6 +39,7 @@
>> #include "omap_device.h"
>> #include "gpmc.h"
>> #include "gpmc-nand.h"
>> +#include "gpmc-onenand.h"
>>
>> #define DEVICE_NAME "omap-gpmc"
>>
>> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
>> }
>> #endif
>>
>> +#ifdef CONFIG_MTD_ONENAND
>> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> + struct device_node *child)
>> +{
>> + u32 val;
>> + struct omap_onenand_platform_data *gpmc_onenand_data;
>> +
>> + if (of_property_read_u32(child, "reg", &val) < 0) {
>> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> + child->full_name);
>> + return -ENODEV;
>> + }
>> +
>> + gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
>> + GFP_KERNEL);
>> + if (!gpmc_onenand_data)
>> + return -ENOMEM;
>> +
>> + gpmc_onenand_data->cs = val;
>> + gpmc_onenand_data->of_node = child;
>> + gpmc_onenand_data->dma_channel = -1;
>> +
>> + if (!of_property_read_u32(child, "dma-channel", &val))
>> + gpmc_onenand_data->dma_channel = val;
>> +
>> + gpmc_onenand_init(gpmc_onenand_data);
>> +
>> + return 0;
>> +}
>> +#else
>> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> + struct device_node *child)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> static int gpmc_probe_dt(struct platform_device *pdev)
>> {
>> int ret;
>> @@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>> return ret;
>> }
>>
>
> This doesn't look right to me:
>
>> + for_each_node_by_name(child, "onenand") {
>> + ret = gpmc_probe_onenand_child(pdev, child);
>> + of_node_put(child);
>> + if (ret < 0)
>> + return ret;
>> + }
>
> for_each_node_by_name automatically calls of_node_put on each node once passed,
> and as far as I can tell, gpmc_probe_onenand_child doesn't do anything that'd
> increment a node's refcount.
>
> As far as I can see, you only need the of_node_put in the error case:
>
> for_each_node_by_name(child, "onenand") {
> ret = gpmc_probe_onenand_child(pdev, child);
> if (ret < 0) {
> of_node_put(child);
> return ret;
> }
> }
>
> Have I missed something here?
>
Mmm... perhaps I've overlooked that code.
After some digging through source and reading for_each_node_by_name()
it seems to me you're right.
@Daniel: It seems this would also apply to the NAND binding.
What do you think?
--
Ezequiel
^ permalink raw reply
* [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
From: Matt Sealey @ 2013-01-21 17:02 UTC (permalink / raw)
To: linux-arm-kernel
The optimized assembler SHA1 code for ARM does not conform to Thumb2
register usage requirements, so it cannot be built when the kernel is
configured with THUMB2_KERNEL.
Fix the FTBFS for now by preventing misconfigurations of the kernel.
Signed-off-by: Matt Sealey <matt@genesi-usa.com>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4641d95..304d60b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -472,7 +472,7 @@ config CRYPTO_SHA1_SPARC64
config CRYPTO_SHA1_ARM
tristate "SHA1 digest algorithm (ARM-asm)"
- depends on ARM
+ depends on ARM && !THUMB2_KERNEL
select CRYPTO_SHA1
select CRYPTO_HASH
help
--
1.7.10.4
^ permalink raw reply related
* OMAP baseline test results for v3.8-rc4
From: Matt Porter @ 2013-01-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <49ca66a84bb245ca9cfe4fd044c4d6f6@DFLE72.ent.ti.com>
On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote:
> Vaibhav / Matt
>
> On 20/01/13 21:38, Paul Walmsley wrote:
> >
> > Here are some basic OMAP test results for Linux v3.8-rc4.
> > Logs and other details at:
> >
> > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/
>
> <snip>
>
> > Failing tests: needing investigation
> > ------------------------------------
> >
> > Boot tests:
> >
> > * am335xbone: hangs after "Starting kernel"
> > - Cause unknown
> > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
>
> <snip>
>
> > Failing tests: needing local investigation (may be due to testbed issues)
> > -------------------------------------------------------------------------
> >
> > Boot tests:
> >
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > - May be fixed now, pending retest:
> > - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> > - Not yet part of the automated test suite
> > - Nishanth Menon & Vaibhav Hiremath report that it works for them
> > * May be due to an old U-boot with FDT support problems used here?
> > Pending local investigation and re-test
>
> Does anyone know when the BeagleBone support is going to be fixed in mainline ?
Hi Mark,
I'm not sure what needs to be fixed. The only thing my edma dmaengine
series adds is new features (specifically, mmc and spi dma support).
I would suspect some boot problem specific to Paul's configuration
if it's hanging. I just booted current mainline with an
omap2plus_defconfig build on my bone a5 and it came up fine.
> I've just tried the latest linux-next git, and no joy.
>
> However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:-
>
>
> Uncompressing Linux... done, booting the kernel.
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4
> (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013
> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
>
> Are we just waiting for Matt's DMA stuff to be accepted ?
For the features I listed above, yes. Also Mark Greer's crypto patches
for AM33xx depend on that series as does a patch series (not ready yet)
that I have to support the Bone audio capes.
There's a dependency I'm working through in a separate thread on lkml
since the dmaengine edma series requires the proposed
dma_get_channel_caps() api...still discussing that implementation.
-Matt
^ 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