* [PATCH 1/6] ARM: bcm476x: Add infrastructure
From: Stephen Warren @ 2012-10-09 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121007225417.GA29996@glitch>
On 10/07/2012 04:54 PM, Domenico Andreoli wrote:
> On Sun, Oct 07, 2012 at 09:57:59PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 03:53 Sun 07 Oct , Domenico Andreoli wrote:
>>> From: Domenico Andreoli <domenico.andreoli@linux.com>
>>>
>>> BCM476x's minimal infrastructure, Kernel's great reuse.
>>>
>>> Look mom, no include/mach directory!
(sigh, Jean-Christophe, it's a really good idea when replying to patches
to delete everything except what you're replying to so that others can
actually find what they wrote in the email...)
>>> Index: b/arch/arm/boot/dts/bcm476x.dtsi
>>> + vic0: interrupt-controller at 80000 {
>>> + compatible = "brcm,bcm476x-pl192", "arm,pl192-vic", "arm,primecell";
>> why brcm specific compatbile?
>
> Nothing breaks if I drop it. I think it's a future-proof clause, especially
> if you consider that the devicetree could be not easy to upgrade and you
> may need a way to differentiate the bcm476x's implementation from the
> common one. I'm not sure it's an actual requirement with use cases.
Indeed, everything works fine right now if you drop that. However, it is
correct practice to include a compatible value for the particular SoC
that incorporates the IP so that if in the future some SoC-specific
workaround is required, the compatible value needed to trigger this is
already in all historical .dts file.
>>> Index: b/arch/arm/include/debug/bcm476x.S
>>> +#if defined(CONFIG_DEBUG_BCM476X_UART0)
>>> +# define BCM476X_DEBUG_PHYS 0x000c0000
>>> +# define BCM476X_DEBUG_VIRT 0xd00c0000
>>> +#elif defined(CONFIG_DEBUG_BCM476X_UART1)
>>> +# define BCM476X_DEBUG_PHYS 0x000c1000
>>> +# define BCM476X_DEBUG_VIRT 0xd00c1000
>>> +#elif defined(CONFIG_DEBUG_BCM476X_UART2)
>>> +# define BCM476X_DEBUG_PHYS 0x000b2000
>>> +# define BCM476X_DEBUG_VIRT 0xd00b2000
>>> +#else
>>> +# error Unknown BCM476x debug port
>>> +#endif
>>
>> can't you detect it?
>
> If I can assume that the boot loader will configure and enable only the
> console port, I could use the first one in such state.
>
> Where could I place such detection, in the maco addruart itself?
Auto-detection is not necessarily a good idea; there's no reason in
general to believe that no future board will ever use a UART for any
purposes other than console/debug. Being explicit is probably good.
^ permalink raw reply
* [PATCH] clk: fix return value check in bcm2835_init_clocks()
From: Stephen Warren @ 2012-10-09 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd95ofKiKWC9B67q9mgkjsc6_YJ5x92aY0xKPiohuUMk4Q@mail.gmail.com>
On 10/07/2012 08:02 AM, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function clk_register_fixed_rate() returns
> ERR_PTR() and never returns NULL. The NULL test in the return value
> check should be replaced with IS_ERR().
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Mike, this driver was added through arm-soc; I assume it's simplest to
take this fixup through there too for 3.7-rc*? If so, Wei, could you
resend this patch with my ack to arm at kernel.org? Thanks.
^ permalink raw reply
* [PATCH v2 3/5] ARM: use generic unaligned.h
From: Rob Herring @ 2012-10-09 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008232853.GA21822@S2101-09.ap.freescale.net>
On 10/08/2012 06:28 PM, Shawn Guo wrote:
> On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
>> On 10/08/2012 11:43 AM, Shawn Guo wrote:
>>> This patch has been merged into mainline as commit below.
>>>
>>> d25c881 ARM: 7493/1: use generic unaligned.h
>>>
>>> It introduces a regression for me. Check out the commit on mainline,
>>> build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
>>> halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
>>> kernel built on the parent commit below works all fine.
>>
>> It actually fails in the decompressor or that's the last output you get?
>
> I think it fails in the decompressor, because what I see is
>
> Uncompressing Linux...
>
> not
>
> Uncompressing Linux... done, booting the kernel.
>
>> I compared the decompressor disassembly of both cases and get the same
>> number of ldrb/strb instructions, so I don't think it is directly
>> related to alignment.
>>
>> I tried the XY decompressor as that is one difference, but that works
>> fine for me on highbank.
>>
>> Does it work with an empty uncompress.h functions? That should be the
>> only difference in our decompressor code.
>
> No, empty putc() in uncompress.h does not help.
>
> New finding is that it only fails with LZO decompressor while the other
> 3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
> one in imx_v6_v7_defconfig.
I must have had an old config with XZ. LZO fails because of this:
lib/decompress_unlzo.c: version = get_unaligned_be16(parse);
lib/decompress_unlzo.c: if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
lib/decompress_unlzo.c: dst_len = get_unaligned_be32(in_buf);
lib/decompress_unlzo.c: src_len = get_unaligned_be32(in_buf);
This was what I was afraid of. The decompressor runs with the sysctrl
register A bit in whatever state the bootloader left it in. In the case
of u-boot it is set, and the maintainers are pretty set on not allowing
unaligned accesses if you've seen the recent discussion.
This should fix things.
Rob
8<---------------------------------------------------------------------
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index bc67cbf..1f87d22 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -654,6 +654,7 @@ __armv7_mmu_cache_on:
#endif
mrc p15, 0, r0, c1, c0, 0 @ read control reg
bic r0, r0, #1 << 28 @ clear SCTLR.TRE
+ bic r0, r0, #1 << 1 @ clear SCTLR.A
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
orr r0, r0, #0x003c @ write buffer
#ifdef CONFIG_MMU
^ permalink raw reply related
* [PATCH] ARM: imx: clk-imx27: Fix divider width field
From: Fabio Estevam @ 2012-10-09 2:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
As per mx27 reference manual, H264DIV and SSI2DIV are 6-bit wide fields in
register PCDR0.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/clk-imx27.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 3b6b640..366e5d5 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -109,7 +109,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk[per3_div] = imx_clk_divider("per3_div", "mpll_main2", CCM_PCDR1, 16, 6);
clk[per4_div] = imx_clk_divider("per4_div", "mpll_main2", CCM_PCDR1, 24, 6);
clk[vpu_sel] = imx_clk_mux("vpu_sel", CCM_CSCR, 21, 1, vpu_sel_clks, ARRAY_SIZE(vpu_sel_clks));
- clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 3);
+ clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 6);
clk[usb_div] = imx_clk_divider("usb_div", "spll", CCM_CSCR, 28, 3);
clk[cpu_sel] = imx_clk_mux("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks));
clk[clko_sel] = imx_clk_mux("clko_sel", CCM_CCSR, 0, 5, clko_sel_clks, ARRAY_SIZE(clko_sel_clks));
@@ -121,7 +121,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk[ssi1_sel] = imx_clk_mux("ssi1_sel", CCM_CSCR, 22, 1, ssi_sel_clks, ARRAY_SIZE(ssi_sel_clks));
clk[ssi2_sel] = imx_clk_mux("ssi2_sel", CCM_CSCR, 23, 1, ssi_sel_clks, ARRAY_SIZE(ssi_sel_clks));
clk[ssi1_div] = imx_clk_divider("ssi1_div", "ssi1_sel", CCM_PCDR0, 16, 6);
- clk[ssi2_div] = imx_clk_divider("ssi2_div", "ssi2_sel", CCM_PCDR0, 26, 3);
+ clk[ssi2_div] = imx_clk_divider("ssi2_div", "ssi2_sel", CCM_PCDR0, 26, 6);
clk[clko_en] = imx_clk_gate("clko_en", "clko_div", CCM_PCCR0, 0);
clk[ssi2_ipg_gate] = imx_clk_gate("ssi2_ipg_gate", "ipg", CCM_PCCR0, 0);
clk[ssi1_ipg_gate] = imx_clk_gate("ssi1_ipg_gate", "ipg", CCM_PCCR0, 1);
--
1.7.9.5
^ permalink raw reply related
* Single zImage and A15/LPAE
From: Nicolas Pitre @ 2012-10-09 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50735B75.8070109@wwwdotorg.org>
On Mon, 8 Oct 2012, Stephen Warren wrote:
> I'm curious what the single-zImage story is for Cortex A15 CPUs with
> LPAE extensions; IIRC, LPAE entails a different page table format and so
> isn't going to co-exist in the same zImage as non-LPAE
LPAE vs non LPAE is an even more invasive change than ARMv6+ vs pre
ARMv6 support. So no, I don't think we'll ever support LPAE and non
LPAE configs in the same kernel binary.
> (although doesn't x86 support that now; I though separate
> LPAE/non-LPAE kernels went away there?)
I don't think so. At least Ubuntu apparently still carries a PAE and
non PAE kernel packages. Fedora doesn't, probably because they decided
not to support non PAE capable machines anymore. We certainly cannot
make this choice on ARM yet.
> Presumably though, the intent is to be able to disable LPAE in Kconfig,
> and create a single zImage with both A9 and A15 support, or to enable
> LPAE and only support A15 with LPAE, and which you'd choose to do simply
> depends on whether you care about LPAE based on how much RAM the boards
> you want to support have (or perhaps also what physical address your
> peripherals are at)?
Yes.
Nicolas
^ permalink raw reply
* [PATCH 08/16] ipvs: fix ip_vs_set_timeout debug messages
From: Simon Horman @ 2012-10-09 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210060954.15831.arnd@arndb.de>
On Sat, Oct 06, 2012 at 09:54:15AM +0000, Arnd Bergmann wrote:
> On Saturday 06 October 2012, Julian Anastasov wrote:
> > On Sat, 6 Oct 2012, Arnd Bergmann wrote:
> > > > Are there any CONFIG_IP_VS_PROTO_xxx options in this
> > > > default config? It is a waste of memory if IPVS is compiled
> > > > without any protocols.
> > >
> > > They all appear to be turned off:
> > >
> > > $ grep CONFIG_IP_VS obj-tmp/.config
> > > CONFIG_IP_VS=m
> > > CONFIG_IP_VS_DEBUG=y
> > > CONFIG_IP_VS_TAB_BITS=12
> > > # CONFIG_IP_VS_PROTO_TCP is not set
> > > # CONFIG_IP_VS_PROTO_UDP is not set
> > > # CONFIG_IP_VS_PROTO_AH_ESP is not set
> > > # CONFIG_IP_VS_PROTO_ESP is not set
> > > # CONFIG_IP_VS_PROTO_AH is not set
> > > # CONFIG_IP_VS_PROTO_SCTP is not set
> >
> > Something should be changed here, may be at least
> > TCP/UDP, who knows.
>
> I don't try to read too much into our defconfigs. We have 140 of them
> on ARM, and they are mainly useful to give a reasonable build coverage,
> but I wouldn't expect them to be actually used on that hardware.
>
> I'll leave it up to Krzysztof to send a patch for this if he wants.
>
> > > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > > @@ -2590,6 +2588,7 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> > > #if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
> > > struct ip_vs_proto_data *pd;
> > > #endif
> >
> > That is what we want. If you plan another submission
> > you can add empty line before this memset and to replace
> > the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
> > memset but they are cosmetic changes. Or may be Simon will
> > take care about the coding style when applying the change.
> >
> > Acked-by: Julian Anastasov <ja@ssi.bg>
>
> I'd prefer Simon to pick up the patch. He should also decide whether he wants
> to add it to stable. In theory, this is a small leak of kernel stack data
> to user space, but as you say in practice it should not happen because it
> only exists for silly configurations that nobody should be using.
>
> AFAICT, removing the call to __ip_vs_get_timeouts in do_ip_vs_get_ctl would
> be a semantic change for the case where a user sends a IPVS_CMD_SET_CONFIG
> message without without the complete set of attributes inside it. The current
> behavior is to leave the timeouts alone, replacing the __ip_vs_get_timeouts
> with a memset would zero them. I left this part alone then.
>
> Arnd
Hi,
sorry for being a bit slow, it was a long weekend here.
This patch looks reasonable and I think it is appropriate for stable.
I'll see about getting it merged accordingly.
>
> 8<-----
> ipvs: initialize returned data in do_ip_vs_get_ctl
>
> As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
> all the members of the ip_vs_timeout_user structure it returns if
> at least one of the TCP or UDP protocols is disabled for ipvs.
>
> This makes sure that the data is always initialized, before it is
> returned as a response to IPVS_CMD_GET_CONFIG or printed as a
> debug message in IPVS_CMD_SET_CONFIG.
>
> Without this patch, building ARM ixp4xx_defconfig results in:
>
> net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Julian Anastasov <ja@ssi.bg>
> ---
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 2770f85..c4ee437 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2591,6 +2589,8 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> struct ip_vs_proto_data *pd;
> #endif
>
> + memset(u, 0, sizeof (*u));
> +
> #ifdef CONFIG_IP_VS_PROTO_TCP
> pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
> u->tcp_timeout = pd->timeout_table[IP_VS_TCP_S_ESTABLISHED] / HZ;
> @@ -2768,7 +2768,6 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
> {
> struct ip_vs_timeout_user t;
>
> - memset(&t, 0, sizeof(t));
> __ip_vs_get_timeouts(net, &t);
> if (copy_to_user(user, &t, sizeof(t)) != 0)
> ret = -EFAULT;
>
^ permalink raw reply
* [alsa-devel] [PATCH v2 1/2] ARM: imx: clk: Split SSI clock into 'ipg' and 'per'
From: Fabio Estevam @ 2012-10-08 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008214452.GA27665@pengutronix.de>
Hi Sascha,
On Mon, Oct 8, 2012 at 6:44 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> I am not sure it's good to work around that issue in the ssi driver. We
> could also just enable the clock in the clk driver as it seems to be a
> ccm related issue.
Yes, it would be better if we could fix this in clk-imx27 instead, but
I was not able to provide such fix yet.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v2 3/5] ARM: use generic unaligned.h
From: Shawn Guo @ 2012-10-08 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507338F1.7030604@gmail.com>
On Mon, Oct 08, 2012 at 03:34:57PM -0500, Rob Herring wrote:
> On 10/08/2012 11:43 AM, Shawn Guo wrote:
> > This patch has been merged into mainline as commit below.
> >
> > d25c881 ARM: 7493/1: use generic unaligned.h
> >
> > It introduces a regression for me. Check out the commit on mainline,
> > build a v7 only kernel (imx5/6) with imx_v6_v7_defconfig, the kernel
> > halts in decompressor. But v6/v7 kernel (imx3/5/6) works fine. The
> > kernel built on the parent commit below works all fine.
>
> It actually fails in the decompressor or that's the last output you get?
I think it fails in the decompressor, because what I see is
Uncompressing Linux...
not
Uncompressing Linux... done, booting the kernel.
> I compared the decompressor disassembly of both cases and get the same
> number of ldrb/strb instructions, so I don't think it is directly
> related to alignment.
>
> I tried the XY decompressor as that is one difference, but that works
> fine for me on highbank.
>
> Does it work with an empty uncompress.h functions? That should be the
> only difference in our decompressor code.
No, empty putc() in uncompress.h does not help.
New finding is that it only fails with LZO decompressor while the other
3 Gzip, LZMA and XZ all work good. We happen to have LZO as the default
one in imx_v6_v7_defconfig.
Shawn
^ permalink raw reply
* [PATCH V3 2/2] ARM: Handle user space mapped pages in flush_kernel_dcache_page
From: Simon Baatz @ 2012-10-08 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008202040.GC4625@n2100.arm.linux.org.uk>
Hi Russell,
On Mon, Oct 08, 2012 at 09:20:40PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 08, 2012 at 10:02:16PM +0200, Simon Baatz wrote:
> > Hi Catalin,
> >
> > On Mon, Oct 08, 2012 at 06:44:28PM +0100, Catalin Marinas wrote:
> > > On Sun, Oct 07, 2012 at 12:29:12PM +0100, Simon Baatz wrote:
> > > > Commit f8b63c1 made flush_kernel_dcache_page() a no-op assuming that
> > > > the pages it needs to handle are kernel mapped only. However, for
> > > > example when doing direct I/O, pages with user space mappings may
> > > > occur.
> > > >
> > > > Thus, do lazy flushing like in flush_dcache_page() if there are no user
> > > > space mappings. Otherwise, flush the kernel cache lines directly.
> > >
> > > Do you need to fix the VIPT non-aliasing case as well? Does
> > > flush_kernel_dcache_page() need to handle I-cache?
> >
> > Good question. My previous version of the patch did not handle it,
> > but after our discussion on the arm64 case, I came to the conclusion
> > that we probably need to handle it.
> >
> > flush_dcache_page() and flush_kernel_dcache_page() are both used when
> > a page was modified via its kernel mapping. For example,
> > crypto/scatterwalk.c uses flush_dcache_page() whereas
> > lib/scatterlist.c uses flush_kernel_dcache_page().
>
> It's likely that this stuff is incredibly buggy - and where we suspect
> there's problems (like using the wrong flush_dcache_page() vs
> flush_kernel_dcache_page() call) that needs to be fixed.
>
> I suspect crypto/scatterwalk.c was created long before
> flush_kernel_dcache_page() came into existence, and it probably needs
> to be fixed.
>
> > Thus, the reasoning is that if flush_dcache_page() needs to handle
> > I-cache in the case there is no hook later (already user-mapped page
> > cache page) then flush_kernel_dcache_page() needs to do the same.
>
> This sounds like we're heading in the direction that flush_kernel_dcache_page()
> and flush_dcache_page() end up being virtually identical. This isn't
> supposed to be - they _are_ supposed to be different. Again, maybe
> that's because the users have chosen the wrong function.
> ...
Yes, it is a mess and may be incredibly buggy.
According to documentation flush_kernel_dcache_page() is supposed to
handle user pages. It can assume that potential user mappings have
been flushed. However, the documentation does not mention the case
of page cache pages with no user mappings explicitly.
flush_dcache_page() is supposed to deal with the user and kernel
mappings. However, the documentation does explicitly state that it is
not supposed to handle anon pages (but the arm implementation does
flush the kernel mapping).
Now, what should crypto/scatterwalk.c do? In the write to page path,
it can see page cache pages with and without user mappings and anon
pages. If there are user mappings, it can assume that they have been
flushed. I would argue it should use flush_kernel_dcache_page().
But if so, our current implementation does not handle two of these
three cases at all.
And the proposed flush_kernel_dcache_page() is different. It only
flushes the kernel mapping in the relevant cases whereas
flush_dcache_page() needs to care about user mappings as well.
According to documentation we could remove the anon page case in
flush_dcache_page(), but uses like in crypto/scatterwalk.c currently
prevent that.
> > With respect to clearing the flag in the VIPT non-aliasing case with
> > anon pages: Declaring the pages dirty by default may already be
> > sufficient in this case, at least that is what the current
> > implementation assumes.
>
> PG_arch_1 has no meaning what so ever for anon pages. Don't even try
> to make it have meaning there, it will cause lots of pain if you do.
> The reason is that anon pages have no mapping, and so trying to do the
> PG_arch_1 trick will result in most places deciding "there is no
> userspace mapping we can skip that".
Hmm, now that you say it, it's quite obvious. There is the following
in __sync_icache_dcache():
if (cache_is_vipt_aliasing())
mapping = page_mapping(page);
else
mapping = NULL;
if (!test_and_set_bit(PG_dcache_clean, &page->flags))
__flush_dcache_page(mapping, page);
if (pte_exec(pteval))
__flush_icache_all();
At least this looks strange to me given that PG_dcache_clean has no
meaning for anon pages. Is this correct?
- Simon
^ permalink raw reply
* Single zImage and A15/LPAE
From: Stephen Warren @ 2012-10-08 23:02 UTC (permalink / raw)
To: linux-arm-kernel
I'm curious what the single-zImage story is for Cortex A15 CPUs with
LPAE extensions; IIRC, LPAE entails a different page table format and so
isn't going to co-exist in the same zImage as non-LPAE (although doesn't
x86 support that now; I though separate LPAE/non-LPAE kernels went away
there?)
Presumably though, the intent is to be able to disable LPAE in Kconfig,
and create a single zImage with both A9 and A15 support, or to enable
LPAE and only support A15 with LPAE, and which you'd choose to do simply
depends on whether you care about LPAE based on how much RAM the boards
you want to support have (or perhaps also what physical address your
peripherals are at)?
^ permalink raw reply
* [PATCH v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Fabio Estevam @ 2012-10-08 22:37 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
By not doing so the camera sensor does not probe correctly:
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
mx2-camera mx2-camera.0: Camera driver attached to camera 0
ov2640 0-0030: Product ID error fb:fb
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000
Adapt the mx2_camera driver to the new clock framework and make it functional
again.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Rebased against linux-next 20121008.
drivers/media/platform/soc_camera/mx2_camera.c | 47 +++++++++++++++++-------
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c
index 403d7f1..9f8c5f0 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -272,7 +272,8 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_csi_ahb, *clk_csi_per;
void __iomem *base_csi, *base_emma;
@@ -432,7 +433,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
unsigned long flags;
- clk_disable_unprepare(pcdev->clk_csi);
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
+ clk_disable_unprepare(pcdev->clk_csi_per);
writel(0, pcdev->base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev->base_emma + PRP_CNTL);
@@ -460,7 +462,11 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
if (pcdev->icd)
return -EBUSY;
- ret = clk_prepare_enable(pcdev->clk_csi);
+ ret = clk_prepare_enable(pcdev->clk_csi_ahb);
+ if (ret < 0)
+ return ret;
+
+ ret = clk_prepare_enable(pcdev->clk_csi_per);
if (ret < 0)
return ret;
@@ -1725,11 +1731,18 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
goto exit;
}
- pcdev->clk_csi = devm_clk_get(&pdev->dev, "ahb");
- if (IS_ERR(pcdev->clk_csi)) {
- dev_err(&pdev->dev, "Could not get csi clock\n");
- err = PTR_ERR(pcdev->clk_csi);
- goto exit;
+ pcdev->clk_csi_ahb = devm_clk_get(&pdev->dev, "ahb");
+ if (IS_ERR(pcdev->clk_csi_ahb)) {
+ dev_err(&pdev->dev, "Could not get csi ahb clock\n");
+ err = PTR_ERR(pcdev->clk_csi_ahb);
+ goto exit;
+ }
+
+ pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
+ if (IS_ERR(pcdev->clk_csi_per)) {
+ dev_err(&pdev->dev, "Could not get csi per clock\n");
+ err = PTR_ERR(pcdev->clk_csi_per);
+ goto exit_csi_ahb;
}
pcdev->pdata = pdev->dev.platform_data;
@@ -1738,14 +1751,15 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
pcdev->platform_flags = pcdev->pdata->flags;
- rate = clk_round_rate(pcdev->clk_csi, pcdev->pdata->clk * 2);
+ rate = clk_round_rate(pcdev->clk_csi_per,
+ pcdev->pdata->clk * 2);
if (rate <= 0) {
err = -ENODEV;
- goto exit;
+ goto exit_csi_per;
}
- err = clk_set_rate(pcdev->clk_csi, rate);
+ err = clk_set_rate(pcdev->clk_csi_per, rate);
if (err < 0)
- goto exit;
+ goto exit_csi_per;
}
INIT_LIST_HEAD(&pcdev->capture);
@@ -1801,7 +1815,7 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
goto exit_free_emma;
dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock frequency: %ld\n",
- clk_get_rate(pcdev->clk_csi));
+ clk_get_rate(pcdev->clk_csi_per));
return 0;
@@ -1812,6 +1826,10 @@ eallocctx:
clk_disable_unprepare(pcdev->clk_emma_ipg);
clk_disable_unprepare(pcdev->clk_emma_ahb);
}
+exit_csi_per:
+ clk_disable_unprepare(pcdev->clk_csi_per);
+exit_csi_ahb:
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
exit:
return err;
}
@@ -1831,6 +1849,9 @@ static int __devexit mx2_camera_remove(struct platform_device *pdev)
clk_disable_unprepare(pcdev->clk_emma_ahb);
}
+ clk_disable_unprepare(pcdev->clk_csi_per);
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
+
dev_info(&pdev->dev, "MX2 Camera driver unloaded\n");
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use
From: Jon Hunter @ 2012-10-08 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1208010932270.21488@utopia.booyaka.com>
Hi Paul,
On 08/01/2012 10:36 AM, Paul Walmsley wrote:
> Hi Jon et al,
>
> Here's what I'm planning to queue here. The only changes from what Jon
> posted are the patch changelog and some checkpatch fixes. If anyone
> has any final comments, please let me know.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Wed, 1 Aug 2012 09:11:20 -0600
> Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
> clockdomain idle problems
[snip]
> diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> index f99e65c..3f4b04b 100644
> --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> @@ -248,6 +248,17 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain *clkdm)
> if (!clkdm->clktrctrl_mask)
> return 0;
>
> + /*
> + * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
> + * more details on the unpleasant problem this is working
> + * around
> + */
> + if ((clkdm->flags & CLKDM_MISSING_IDLE_REPORTING) &&
> + (clkdm->flags & CLKDM_CAN_FORCE_WAKEUP)) {
> + omap3_clkdm_wakeup(clkdm);
> + return 0;
> + }
> +
> hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
> clkdm->clktrctrl_mask);
>
> @@ -271,6 +282,17 @@ static int omap3xxx_clkdm_clk_disable(struct clockdomain *clkdm)
> if (!clkdm->clktrctrl_mask)
> return 0;
>
> + /*
> + * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
> + * more details on the unpleasant problem this is working
> + * around
> + */
> + if (clkdm->flags & CLKDM_MISSING_IDLE_REPORTING &&
> + !(clkdm->flags & CLKDM_CAN_FORCE_SLEEP)) {
> + _enable_hwsup(clkdm);
> + return 0;
> + }
> +
> hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
> clkdm->clktrctrl_mask);
I was looking at what got merged and it appears that the above code was
added to the omap2 clkdm enable/disable functions and not omap3. I believe
that is a mistake? If so the below fixes this.
Cheers
Jon
>From 16db11f3373bc6e03254c4d1d92ee762f69cbacc Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Wed, 1 Aug 2012 09:36:13 -0600
Subject: [PATCH] ARM: OMAP3: fix workaround for EMU clockdomain
Commit b71c721 (ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
clockdomain idle problems) added a workaround for the EMU clock domain on
OMAP3/4 devices to prevent the clock domain for transitioning while it is
in use.
In the proposed patch [1] code was added to the omap3xxx_clkdm_clk_enable()
and omap3xxx_clkdm_clk_disable() functions to check for the flag
CLKDM_MISSING_IDLE_REPORTING and perform the appropriate action. However, in the
merged patch it appears that this code was added to the omap2_clkdm_clk_enable()
and omap2_clkdm_clk_disable() functions by mistake.
[1] http://marc.info/?l=linux-arm-kernel&m=134383567112518&w=2
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 44 ++++++++++++++--------------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 9a7792a..70294f5 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -183,17 +183,6 @@ static int omap2_clkdm_clk_enable(struct clockdomain *clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
- /*
- * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
- * more details on the unpleasant problem this is working
- * around
- */
- if (clkdm->flags & CLKDM_MISSING_IDLE_REPORTING &&
- !(clkdm->flags & CLKDM_CAN_FORCE_SLEEP)) {
- _enable_hwsup(clkdm);
- return 0;
- }
-
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
clkdm->clktrctrl_mask);
@@ -217,17 +206,6 @@ static int omap2_clkdm_clk_disable(struct clockdomain *clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
- /*
- * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
- * more details on the unpleasant problem this is working
- * around
- */
- if ((clkdm->flags & CLKDM_MISSING_IDLE_REPORTING) &&
- (clkdm->flags & CLKDM_CAN_FORCE_WAKEUP)) {
- omap3_clkdm_wakeup(clkdm);
- return 0;
- }
-
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
clkdm->clktrctrl_mask);
@@ -269,6 +247,17 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain *clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
+ /*
+ * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
+ * more details on the unpleasant problem this is working
+ * around
+ */
+ if ((clkdm->flags & CLKDM_MISSING_IDLE_REPORTING) &&
+ (clkdm->flags & CLKDM_CAN_FORCE_WAKEUP)) {
+ omap3_clkdm_wakeup(clkdm);
+ return 0;
+ }
+
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
clkdm->clktrctrl_mask);
@@ -292,6 +281,17 @@ static int omap3xxx_clkdm_clk_disable(struct clockdomain *clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
+ /*
+ * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
+ * more details on the unpleasant problem this is working
+ * around
+ */
+ if (clkdm->flags & CLKDM_MISSING_IDLE_REPORTING &&
+ !(clkdm->flags & CLKDM_CAN_FORCE_SLEEP)) {
+ _enable_hwsup(clkdm);
+ return 0;
+ }
+
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
clkdm->clktrctrl_mask);
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] ARM: OMAP: PM fixes for v3.7-rc
From: Kevin Hilman @ 2012-10-08 22:24 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Please pull the following OMAP PM fixes for v3.7-rc.
Thanks,
Kevin
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-fixes-pm
for you to fetch changes up to ce3810cdb4ca31238c87e095d2c494a5eaa4f65d:
ARM: OMAP: SmartReflex: fix error path in init function (2012-10-02 14:55:31 -0700)
----------------------------------------------------------------
OMAP PM related fixes for v3.7-rc
----------------------------------------------------------------
Jean Pihet (2):
ARM: OMAP: SmartReflex: select CONFIG_POWER_SUPPLY in Kconfig
ARM: OMAP: SmartReflex: fix error path in init function
Wei Yongjun (4):
ARM: OMAP: fix return value check in beagle_opp_init()
ARM: OMAP: omap_device: fix return value check in omap_device_build_ss()
ARM: OMAP2+: SmartReflex: fix return value check in sr_dev_init()
ARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage()
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/pm.c | 2 +-
arch/arm/mach-omap2/sr_device.c | 2 +-
arch/arm/plat-omap/Kconfig | 1 +
arch/arm/plat-omap/omap_device.c | 2 +-
drivers/power/avs/smartreflex.c | 8 ++++----
6 files changed, 9 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH v2] video: imxfb: Do not crash on reboot
From: Fabio Estevam @ 2012-10-08 22:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Issuing a "reboot" command after the LCD times out causes the following
warnings:
Requesting system reboot
------------[ cut here ]------------
WARNING: at drivers/clk/clk.c:471 clk_disable+0x24/0x50()
Modules linked in:
[<c001ad90>] (unwind_backtrace+0x0/0xf4) from [<c0025aac>] (warn_slowpath_common+0x48/0x60)
[<c0025aac>] (warn_slowpath_common+0x48/0x60) from [<c0025ae0>] (warn_slowpath_null+0x1c/0x24)
[<c0025ae0>] (warn_slowpath_null+0x1c/0x24) from [<c03960a0>] (clk_disable+0x24/0x50)
[<c03960a0>] (clk_disable+0x24/0x50) from [<c02695a0>] (imxfb_disable_controller+0x48/0x7c)
[<c02695a0>] (imxfb_disable_controller+0x48/0x7c) from [<c029d838>] (platform_drv_shutdown+0x18/0x1c)
[<c029d838>] (platform_drv_shutdown+0x18/0x1c) from [<c02990fc>] (device_shutdown+0x48/0x14c)
[<c02990fc>] (device_shutdown+0x48/0x14c) from [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c)
[<c003d09c>] (kernel_restart_prepare+0x2c/0x3c) from [<c003d0e4>] (kernel_restart+0xc/0x48)
[<c003d0e4>] (kernel_restart+0xc/0x48) from [<c003d1e8>] (sys_reboot+0xc0/0x1bc)
[<c003d1e8>] (sys_reboot+0xc0/0x1bc) from [<c0014ca0>] (ret_fast_syscall+0x0/0x2c)
---[ end trace da6b502ca79c854f ]---
------------[ cut here ]------------
WARNING: at drivers/clk/clk.c:380 clk_unprepare+0x1c/0x2c()
Modules linked in:
[<c001ad90>] (unwind_backtrace+0x0/0xf4) from [<c0025aac>] (warn_slowpath_common+0x48/0x60)
[<c0025aac>] (warn_slowpath_common+0x48/0x60) from [<c0025ae0>] (warn_slowpath_null+0x1c/0x24)
[<c0025ae0>] (warn_slowpath_null+0x1c/0x24) from [<c0396338>] (clk_unprepare+0x1c/0x2c)
[<c0396338>] (clk_unprepare+0x1c/0x2c) from [<c02695a8>] (imxfb_disable_controller+0x50/0x7c)
[<c02695a8>] (imxfb_disable_controller+0x50/0x7c) from [<c029d838>] (platform_drv_shutdown+0x18/0x1c)
[<c029d838>] (platform_drv_shutdown+0x18/0x1c) from [<c02990fc>] (device_shutdown+0x48/0x14c)
[<c02990fc>] (device_shutdown+0x48/0x14c) from [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c)
[<c003d09c>] (kernel_restart_prepare+0x2c/0x3c) from [<c003d0e4>] (kernel_restart+0xc/0x48)
[<c003d0e4>] (kernel_restart+0xc/0x48) from [<c003d1e8>] (sys_reboot+0xc0/0x1bc)
[<c003d1e8>] (sys_reboot+0xc0/0x1bc) from [<c0014ca0>] (ret_fast_syscall+0x0/0x2c)
---[ end trace da6b502ca79c8550 ]---
------------[ cut here ]------------
This happens because "reboot" triggers imxfb_shutdown(), which calls
imxfb_disable_controller with the clocks already disabled.
To prevent this, add a clock enabled status so that we can check if the clocks
are enabled before disabling them.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Protect the whole function instead of only the clocks
drivers/video/imxfb.c | 63 +++++++++++++++++++++++++++----------------------
1 file changed, 35 insertions(+), 28 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index cf2688d..32c71e5 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -134,6 +134,7 @@ struct imxfb_info {
struct clk *clk_ipg;
struct clk *clk_ahb;
struct clk *clk_per;
+ int enabled;
/*
* These are the addresses we mapped
@@ -513,47 +514,53 @@ static void imxfb_exit_backlight(struct imxfb_info *fbi)
static void imxfb_enable_controller(struct imxfb_info *fbi)
{
- pr_debug("Enabling LCD controller\n");
+ if (!fbi->enabled) {
+ pr_debug("Enabling LCD controller\n");
- writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
+ writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
- /* panning offset 0 (0 pixel offset) */
- writel(0x00000000, fbi->regs + LCDC_POS);
+ /* panning offset 0 (0 pixel offset) */
+ writel(0x00000000, fbi->regs + LCDC_POS);
- /* disable hardware cursor */
- writel(readl(fbi->regs + LCDC_CPOS) & ~(CPOS_CC0 | CPOS_CC1),
- fbi->regs + LCDC_CPOS);
+ /* disable hardware cursor */
+ writel(readl(fbi->regs + LCDC_CPOS) & ~(CPOS_CC0 | CPOS_CC1),
+ fbi->regs + LCDC_CPOS);
- /*
- * RMCR_LCDC_EN_MX1 is present on i.MX1 only, but doesn't hurt
- * on other SoCs
- */
- writel(RMCR_LCDC_EN_MX1, fbi->regs + LCDC_RMCR);
+ /*
+ * RMCR_LCDC_EN_MX1 is present on i.MX1 only, but doesn't hurt
+ * on other SoCs
+ */
+ writel(RMCR_LCDC_EN_MX1, fbi->regs + LCDC_RMCR);
- clk_prepare_enable(fbi->clk_ipg);
- clk_prepare_enable(fbi->clk_ahb);
- clk_prepare_enable(fbi->clk_per);
+ clk_prepare_enable(fbi->clk_ipg);
+ clk_prepare_enable(fbi->clk_ahb);
+ clk_prepare_enable(fbi->clk_per);
+ fbi->enabled = 1;
- if (fbi->backlight_power)
- fbi->backlight_power(1);
- if (fbi->lcd_power)
- fbi->lcd_power(1);
+ if (fbi->backlight_power)
+ fbi->backlight_power(1);
+ if (fbi->lcd_power)
+ fbi->lcd_power(1);
+ }
}
static void imxfb_disable_controller(struct imxfb_info *fbi)
{
- pr_debug("Disabling LCD controller\n");
+ if (fbi->enabled) {
+ pr_debug("Disabling LCD controller\n");
- if (fbi->backlight_power)
- fbi->backlight_power(0);
- if (fbi->lcd_power)
- fbi->lcd_power(0);
+ if (fbi->backlight_power)
+ fbi->backlight_power(0);
+ if (fbi->lcd_power)
+ fbi->lcd_power(0);
- clk_disable_unprepare(fbi->clk_per);
- clk_disable_unprepare(fbi->clk_ipg);
- clk_disable_unprepare(fbi->clk_ahb);
+ clk_disable_unprepare(fbi->clk_per);
+ clk_disable_unprepare(fbi->clk_ipg);
+ clk_disable_unprepare(fbi->clk_ahb);
+ fbi->enabled = 0;
- writel(0, fbi->regs + LCDC_RMCR);
+ writel(0, fbi->regs + LCDC_RMCR);
+ }
}
static int imxfb_blank(int blank, struct fb_info *info)
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] ARM: OMAP: CPUfreq fixes for v3.7-rc
From: Kevin Hilman @ 2012-10-08 22:22 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 16642a2e7be23bbda013fc32d8f6c68982eab603:
Merge tag 'pm-for-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2012-10-02 18:32:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-fixes-cpufreq
for you to fetch changes up to 24d7b40a60cf19008334bcbcbd98da374d4d9c64:
ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS (2012-10-08 14:59:04 -0700)
----------------------------------------------------------------
This series a couple bug fixes and a couple fixes that make this
driver support recently added OMAP-based SoCs.
The 'get_cpu_device' patch is needed due to a change in the OMAP
OMAP PM core code which enforces use of get_cpu_device() instead of
a deprecated OMAP-specific API.
The usage of plat/*.h headers breaks single zImage, so platforms are
cleaning up and/or removing plat/*.h so the driver needs to be fixed
accordingly.
This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into
Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603.
----------------------------------------------------------------
Kevin Hilman (4):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused <plat/omap-pm.h>
cpufreq: OMAP: use get_cpu_device() instead of omap_device API
ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS
Paul Walmsley (1):
cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes
arch/arm/mach-omap2/opp.c | 23 +++++++++++++++++------
arch/arm/mach-omap2/pm.c | 11 ++++++++++-
arch/arm/mach-omap2/twl-common.c | 2 +-
drivers/cpufreq/omap-cpufreq.c | 36 ++++++++++++------------------------
4 files changed, 40 insertions(+), 32 deletions(-)
^ permalink raw reply
* [PATCH] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
From: Tony Lindgren @ 2012-10-08 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210080145080.5736@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121007 18:48]:
>
> Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> debug_card_init() function") results in the following new sparse[1]
> warning:
>
> arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static?
>
> Normally this could be fixed by including the appropriate header file
> in plat-omap/debug-devices.c, but the header file now exists only in
> mach-omap2/, so this would require a "sideways include" and is thus
> impractical. It turns out that only code in mach-omap2/ currently
> uses the debug-devices.c and debug-leds.c files, so move them there.
> In the long term, these devices should be created by DT, and the code
> should be moved into drivers/ somewhere.
Hmm are you sure that omap1 is not using debug-leds.c?
At least the initcall seems like it should run on omap1
if enabled.
The sideways include here is OK, it does not get exposed to
the drivers, it seems that plat-omap is still the right location
for at least debug-leds.c code.
> rename from arch/arm/plat-omap/debug-leds.c
> rename to arch/arm/mach-omap2/debug-leds.c
> index ea29bbe..c12350b 100644
> --- a/arch/arm/plat-omap/debug-leds.c
> +++ b/arch/arm/mach-omap2/debug-leds.c
> @@ -146,11 +146,8 @@ static struct platform_driver led_driver = {
>
> static int __init fpga_init(void)
> {
> - if (machine_is_omap_h4()
> - || machine_is_omap_h3()
> - || machine_is_omap_h2()
> - || machine_is_omap_perseus2()
> - )
> + if (machine_is_omap_h4() || machine_is_omap_h3() ||
> + machine_is_omap_h2() || machine_is_omap_perseus2())
> return platform_driver_register(&led_driver);
> return 0;
> }
This looks like it should work fine for the boards using
the debug leds on omap1 too.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP: fix return value check in realtime_counter_init()
From: Tony Lindgren @ 2012-10-08 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd_X+vT-AtkHCAmmieEtdQbVz6RcUWogY83qZyvzK_tidA@mail.gmail.com>
* Wei Yongjun <weiyj.lk@gmail.com> [121007 07:00]:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function clk_get() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value
> check should be replaced with IS_ERR().
Thanks applying into omap fixes.
Tony
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> arch/arm/mach-omap2/timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 8847d6e..44f9aa7 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -378,7 +378,7 @@ static void __init realtime_counter_init(void)
> return;
> }
> sys_clk = clk_get(NULL, "sys_clkin_ck");
> - if (!sys_clk) {
> + if (IS_ERR(sys_clk)) {
> pr_err("%s: failed to get system clock handle\n", __func__);
> iounmap(base);
> return;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2+: remove duplicated include from board-omap3stalker.c
From: Tony Lindgren @ 2012-10-08 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd-DH3T=WxZqSBF0hHAsJbqC2Kw0K-+R9GLT8dtKsFfYjA@mail.gmail.com>
* Wei Yongjun <weiyj.lk@gmail.com> [121007 06:26]:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove duplicated include.
Thanks applying into omap fixes.
Tony
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> arch/arm/mach-omap2/board-omap3stalker.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
> index c7f3d02..731235e 100644
> --- a/arch/arm/mach-omap2/board-omap3stalker.c
> +++ b/arch/arm/mach-omap2/board-omap3stalker.c
> @@ -48,11 +48,6 @@
> #include <video/omap-panel-tfp410.h>
>
> #include <linux/platform_data/spi-omap2-mcspi.h>
> -#include <linux/input/matrix_keypad.h>
> -#include <linux/spi/spi.h>
> -#include <linux/interrupt.h>
> -#include <linux/smsc911x.h>
> -#include <linux/i2c/at24.h>
>
> #include "sdram-micron-mt46h32m32lf-6.h"
> #include "mux.h"
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 v2] ARM: OMAP: Fix dependency for OMAP_DEBUG_LEDS
From: Tony Lindgren @ 2012-10-08 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349604805.6017.1.camel@phoenix>
* Axel Lin <axel.lin@ingics.com> [121007 03:14]:
> This fixes below build error when CONFIG_LEDS_CLASS is not set.
>
> LD init/built-in.o
> arch/arm/plat-omap/built-in.o: In function `fpga_probe':
> arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register'
> arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register'
> arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register'
> arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register'
> arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register'
> arch/arm/plat-omap/built-in.o:arch/arm/plat-omap/debug-leds.c:113: more undefined references to `led_classdev_register' follow
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
Thanks looks like I have already an earlier version of the same
patch from you already queued.
Regards,
Tony
> ---
> arch/arm/plat-omap/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> index ca83a76..c262781 100644
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -43,6 +43,7 @@ config OMAP_DEBUG_DEVICES
>
> config OMAP_DEBUG_LEDS
> def_bool y if NEW_LEDS
> + select LEDS_CLASS
> depends on OMAP_DEBUG_DEVICES
>
> config POWER_AVS_OMAP
> --
> 1.7.9.5
>
>
>
^ permalink raw reply
* [PATCH 14/15] KVM: ARM: Handle I/O aborts
From: Christoffer Dall @ 2012-10-08 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008100412.GA2302@linaro.org>
On Mon, Oct 8, 2012 at 6:04 AM, Dave Martin <dave.martin@linaro.org> wrote:
> On Fri, Oct 05, 2012 at 10:00:25AM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 01, 2012 at 01:53:26PM +0100, Dave Martin wrote:
>> > A good starting point would be load/store emulation as this seems to be a
>> > common theme, and we would need a credible deployment for any new
>> > framework so that we know it's fit for purpose.
>>
>> Probably not actually, that code is written to be fast, because things
>> like IP stack throughput depend on it - particularly when your network
>> card can only DMA packets to 32-bit aligned addresses (resulting in
>> virtually all network data being misaligned.)
>
> A fair point, but surely it would still be worth a try?
>
> We might decide that a few particular cases of instruction decode
> should not use the generic framework for performance reaons, but in
> most cases being critically dependent on fault-driven software
> emulation for performance would be a serious mistake in the first place
> (discussions about the network code notwithstanding).
>
> This is not an argument for being slower just for the sake of it, but
> it can make sense to factor code on paths where performance is not an
> issue.
>
I'm all for unifying this stuff, but I still think it doesn't qualify
for holding back on merging KVM patches. The ARM mode instruction
decoding can definitely be cleaned up though to look more like the
Thumb2 mode decoding which will be a good step before refactoring to
use a more common framework. Currently we decode too many types of
instructions (not just the ones with cleared HSR.IV) in ARM mode, so
the whole complexity of that code can be reduced.
I'll give that a go before re-sending the KVM patch series.
-Christoffer
^ permalink raw reply
* [PATCH] ARM: OMAP2+: gpmc: annotate exit sections properly
From: Tony Lindgren @ 2012-10-08 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349339517-17882-1-git-send-email-afzal@ti.com>
* Afzal Mohammed <afzal@ti.com> [121004 01:33]:
> compiler complained,
> `gpmc_remove' referenced in section `.data' of arch/arm/mach-omap2/built-in.o: defined in discarded section `.exit.text' of arch/arm/mach-omap2/built-in.o
>
> Annotate gpmc_remove function and dependents with __devexit.
Thanks applying into omap fixes.
Tony
^ permalink raw reply
* [PATCH v2 1/2] ARM: imx: clk: Split SSI clock into 'ipg' and 'per'
From: Sascha Hauer @ 2012-10-08 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349725213-11354-1-git-send-email-fabio.estevam@freescale.com>
On Mon, Oct 08, 2012 at 04:40:13PM -0300, Fabio Estevam wrote:
> Currently imx ssi driver has been using only the ipg clock as only slave mode
> is supported.
>
> For mx27 it is necessay to provide both 'ipg' and 'per' clocks in order to get
> ssi functional.
>
> This issue was found on mx27 by unselecting the mmc driver from the kernel
> ,which resulted on a system that could not play audio.
>
> When the mmc driver is selected the required 'per2' clock is provided and it
> allows the ssi to work.
I am not sure it's good to work around that issue in the ssi driver. We
could also just enable the clock in the clk driver as it seems to be a
ccm related issue.
According to the datasheet per2_clk has absolutely nothing to do with
the ssi unit. Are you really sure there is not another bug in the clk
driver triggering this behaviour?
BTW i.MX6 would need a fixup aswell.
Sascha
>
> Add the required 'per' clock to the mx27 ssi and a dummy one for the other SoCs.
>
> Reported-by: Ga?tan Carlier <gcembed@gmail.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Drop per4 from the camera clok, which belonged to a different patch
> arch/arm/mach-imx/clk-imx21.c | 11 +++++++----
> arch/arm/mach-imx/clk-imx25.c | 6 ++++--
> arch/arm/mach-imx/clk-imx27.c | 8 ++++----
> arch/arm/mach-imx/clk-imx31.c | 11 +++++++----
> arch/arm/mach-imx/clk-imx35.c | 10 +++++++---
> arch/arm/mach-imx/clk-imx51-imx53.c | 19 +++++++++++++------
> 6 files changed, 42 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx21.c b/arch/arm/mach-imx/clk-imx21.c
> index cf65148..2ed49c8 100644
> --- a/arch/arm/mach-imx/clk-imx21.c
> +++ b/arch/arm/mach-imx/clk-imx21.c
> @@ -51,8 +51,8 @@ static const char *mpll_sel_clks[] = { "fpm", "ckih", };
> static const char *spll_sel_clks[] = { "fpm", "ckih", };
>
> enum imx21_clks {
> - ckil, ckih, fpm, mpll_sel, spll_sel, mpll, spll, fclk, hclk, ipg, per1,
> - per2, per3, per4, uart1_ipg_gate, uart2_ipg_gate, uart3_ipg_gate,
> + dummy, ckil, ckih, fpm, mpll_sel, spll_sel, mpll, spll, fclk, hclk, ipg,
> + per1, per2, per3, per4, uart1_ipg_gate, uart2_ipg_gate, uart3_ipg_gate,
> uart4_ipg_gate, gpt1_ipg_gate, gpt2_ipg_gate, gpt3_ipg_gate,
> pwm_ipg_gate, sdhc1_ipg_gate, sdhc2_ipg_gate, lcdc_ipg_gate,
> lcdc_hclk_gate, cspi3_ipg_gate, cspi2_ipg_gate, cspi1_ipg_gate,
> @@ -72,6 +72,7 @@ int __init mx21_clocks_init(unsigned long lref, unsigned long href)
> {
> int i;
>
> + clk[dummy] = imx_clk_fixed("dummy", 0);
> clk[ckil] = imx_clk_fixed("ckil", lref);
> clk[ckih] = imx_clk_fixed("ckih", href);
> clk[fpm] = imx_clk_fixed_factor("fpm", "ckil", 512, 1);
> @@ -174,8 +175,10 @@ int __init mx21_clocks_init(unsigned long lref, unsigned long href)
> clk_register_clkdev(clk[gpio_gate], "gpio", NULL);
> clk_register_clkdev(clk[rtc_gate], "rtc", NULL);
> clk_register_clkdev(clk[csi_hclk_gate], "csi", NULL);
> - clk_register_clkdev(clk[ssi1_gate], "ssi1", NULL);
> - clk_register_clkdev(clk[ssi2_gate], "ssi2", NULL);
> + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.1");
> clk_register_clkdev(clk[sdhc1_ipg_gate], "sdhc1", NULL);
> clk_register_clkdev(clk[sdhc2_ipg_gate], "sdhc2", NULL);
>
> diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
> index d20d479..c81864d 100644
> --- a/arch/arm/mach-imx/clk-imx25.c
> +++ b/arch/arm/mach-imx/clk-imx25.c
> @@ -222,8 +222,10 @@ int __init mx25_clocks_init(void)
> clk_register_clkdev(clk[lcdc_ipg], "ipg", "imx-fb.0");
> clk_register_clkdev(clk[lcdc_ahb], "ahb", "imx-fb.0");
> clk_register_clkdev(clk[wdt_ipg], NULL, "imx2-wdt.0");
> - clk_register_clkdev(clk[ssi1_ipg], NULL, "imx-ssi.0");
> - clk_register_clkdev(clk[ssi2_ipg], NULL, "imx-ssi.1");
> + clk_register_clkdev(clk[ssi1_ipg], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[ssi2_ipg], "ipg", "imx-ssi.1");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.1");
> clk_register_clkdev(clk[esdhc1_ipg_per], "per", "sdhci-esdhc-imx25.0");
> clk_register_clkdev(clk[esdhc1_ipg], "ipg", "sdhci-esdhc-imx25.0");
> clk_register_clkdev(clk[esdhc1_ahb], "ahb", "sdhci-esdhc-imx25.0");
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 3b6b640..8cbb6b5 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -236,8 +236,10 @@ int __init mx27_clocks_init(unsigned long fref)
> clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2");
> clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.2");
> clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.2");
> - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0");
> - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
> + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "imx-ssi.1");
> + clk_register_clkdev(clk[per2_gate], "per", "imx-ssi.0");
> + clk_register_clkdev(clk[per2_gate], "per", "imx-ssi.1");
> clk_register_clkdev(clk[nfc_baud_gate], NULL, "mxc_nand.0");
> clk_register_clkdev(clk[vpu_baud_gate], "per", "coda-imx27.0");
> clk_register_clkdev(clk[vpu_ahb_gate], "ahb", "coda-imx27.0");
> @@ -262,8 +264,6 @@ int __init mx27_clocks_init(unsigned long fref)
> clk_register_clkdev(clk[scc_ipg_gate], "scc", NULL);
> clk_register_clkdev(clk[cpu_div], "cpu", NULL);
> clk_register_clkdev(clk[emi_ahb_gate], "emi_ahb" , NULL);
> - clk_register_clkdev(clk[ssi1_baud_gate], "bitrate" , "imx-ssi.0");
> - clk_register_clkdev(clk[ssi2_baud_gate], "bitrate" , "imx-ssi.1");
>
> mxc_timer_init(MX27_IO_ADDRESS(MX27_GPT1_BASE_ADDR), MX27_INT_GPT1);
>
> diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c
> index 1253af2..61567dc 100644
> --- a/arch/arm/mach-imx/clk-imx31.c
> +++ b/arch/arm/mach-imx/clk-imx31.c
> @@ -35,8 +35,8 @@ static const char *csi_sel[] = { "upll", "spll", };
> static const char *fir_sel[] = { "mcu_main", "upll", "spll" };
>
> enum mx31_clks {
> - ckih, ckil, mpll, spll, upll, mcu_main, hsp, ahb, nfc, ipg, per_div,
> - per, csi, fir, csi_div, usb_div_pre, usb_div_post, fir_div_pre,
> + dummy, ckih, ckil, mpll, spll, upll, mcu_main, hsp, ahb, nfc, ipg,
> + per_div, per, csi, fir, csi_div, usb_div_pre, usb_div_post, fir_div_pre,
> fir_div_post, sdhc1_gate, sdhc2_gate, gpt_gate, epit1_gate, epit2_gate,
> iim_gate, ata_gate, sdma_gate, cspi3_gate, rng_gate, uart1_gate,
> uart2_gate, ssi1_gate, i2c1_gate, i2c2_gate, i2c3_gate, hantro_gate,
> @@ -53,6 +53,7 @@ int __init mx31_clocks_init(unsigned long fref)
> void __iomem *base = MX31_IO_ADDRESS(MX31_CCM_BASE_ADDR);
> int i;
>
> + clk[dummy] = imx_clk_fixed("dummy", 0);
> clk[ckih] = imx_clk_fixed("ckih", fref);
> clk[ckil] = imx_clk_fixed("ckil", 32768);
> clk[mpll] = imx_clk_pllv1("mpll", "ckih", base + MXC_CCM_MPCTL);
> @@ -161,8 +162,10 @@ int __init mx31_clocks_init(unsigned long fref)
> clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1.0");
> clk_register_clkdev(clk[sdhc1_gate], NULL, "mxc-mmc.0");
> clk_register_clkdev(clk[sdhc2_gate], NULL, "mxc-mmc.1");
> - clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0");
> - clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1");
> + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.1");
> clk_register_clkdev(clk[firi_gate], "firi", NULL);
> clk_register_clkdev(clk[ata_gate], NULL, "pata_imx");
> clk_register_clkdev(clk[rtic_gate], "rtic", NULL);
> diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
> index 177259b..1ab7467 100644
> --- a/arch/arm/mach-imx/clk-imx35.c
> +++ b/arch/arm/mach-imx/clk-imx35.c
> @@ -50,7 +50,7 @@ static const char *std_sel[] = {"ppll", "arm"};
> static const char *ipg_per_sel[] = {"ahb_per_div", "arm_per_div"};
>
> enum mx35_clks {
> - ckih, mpll, ppll, mpll_075, arm, hsp, hsp_div, hsp_sel, ahb, ipg,
> + dummy, ckih, mpll, ppll, mpll_075, arm, hsp, hsp_div, hsp_sel, ahb, ipg,
> arm_per_div, ahb_per_div, ipg_per, uart_sel, uart_div, esdhc_sel,
> esdhc1_div, esdhc2_div, esdhc3_div, spdif_sel, spdif_div_pre,
> spdif_div_post, ssi_sel, ssi1_div_pre, ssi1_div_post, ssi2_div_pre,
> @@ -88,6 +88,7 @@ int __init mx35_clocks_init()
> aad = &clk_consumer[0];
> }
>
> + clk[dummy] = imx_clk_fixed("dummy", 0);
> clk[ckih] = imx_clk_fixed("ckih", 24000000);
> clk[mpll] = imx_clk_pllv1("mpll", "ckih", base + MX35_CCM_MPCTL);
> clk[ppll] = imx_clk_pllv1("ppll", "ckih", base + MX35_CCM_PPCTL);
> @@ -234,8 +235,11 @@ int __init mx35_clocks_init()
> clk_register_clkdev(clk[kpp_gate], NULL, "imx-keypad");
> clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1");
> clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
> - clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0");
> - clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1");
> + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.1");
> +
> /* i.mx35 has the i.mx21 type uart */
> clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
> clk_register_clkdev(clk[ipg], "ipg", "imx21-uart.0");
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index a0bf848..46d679c 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -273,9 +273,12 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
> clk_register_clkdev(clk[usboh3_gate], "ipg", "fsl-usb2-udc");
> clk_register_clkdev(clk[usboh3_gate], "ahb", "fsl-usb2-udc");
> clk_register_clkdev(clk[nfc_gate], NULL, "mxc_nand");
> - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0");
> - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
> - clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "imx-ssi.2");
> + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "imx-ssi.0");
> + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "imx-ssi.1");
> + clk_register_clkdev(clk[ssi3_ipg_gate], "ipg", "imx-ssi.2");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.0");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.1");
> + clk_register_clkdev(clk[dummy], "per", "imx-ssi.2");
> clk_register_clkdev(clk[ssi_ext1_gate], "ssi_ext1", NULL);
> clk_register_clkdev(clk[ssi_ext2_gate], "ssi_ext2", NULL);
> clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
> @@ -366,9 +369,13 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
> clk_register_clkdev(clk[esdhc4_ipg_gate], "ipg", "sdhci-esdhc-imx51.3");
> clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx51.3");
> clk_register_clkdev(clk[esdhc4_per_gate], "per", "sdhci-esdhc-imx51.3");
> - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "83fcc000.ssi");
> - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "70014000.ssi");
> - clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "83fe8000.ssi");
> + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "83fcc000.ssi");
> + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "70014000.ssi");
> + clk_register_clkdev(clk[ssi3_ipg_gate], "ipg", "83fe8000.ssi");
> + clk_register_clkdev(clk[dummy], "per", "83fcc000.ssi");
> + clk_register_clkdev(clk[dummy], "per", "70014000.ssi");
> + clk_register_clkdev(clk[dummy], "per", "83fe8000.ssi");
> +
> clk_register_clkdev(clk[nfc_gate], NULL, "83fdb000.nand");
>
> /* set the usboh3 parent to pll2_sw */
> --
> 1.7.9.5
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] arm/omap: Replace board_ref_clock with enum values
From: Tony Lindgren @ 2012-10-08 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADTbHxozV2UyJjWoDaK3acpDxbtDJDOoapiV19w3FSMZUdMtpA@mail.gmail.com>
* Pankaj Jangra <jangra.pankaj9@gmail.com> [120927 19:25]:
> Hi,
>
> On Wed, Sep 26, 2012 at 10:12 PM, Vikram Narayanan <vikram186@gmail.com> wrote:
> > Use the enum for board_ref_clock from linux/wl12xx.h
> >
> > Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: linux-omap at vger.kernel.org
> > ---
> > I'm not subscribed to the list. So please keep me in Cc for the replies.
> >
> > arch/arm/mach-omap2/board-omap4panda.c | 3 +--
> > arch/arm/mach-omap2/board-zoom-peripherals.c | 3 +--
> > 2 files changed, 2 insertions(+), 4 deletions(-)
> >
>
> Looks good.
>
> Reviewed-by: Pankaj Jangra<jangra.pankaj9@gmail.com>
Thanks applying into omap fixes.
Tony
^ permalink raw reply
* [PATCH] arm: increase FORCE_MAX_ZONEORDER for TI AM33XX
From: Tony Lindgren @ 2012-10-08 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348562644-14447-1-git-send-email-yegorslists@googlemail.com>
* yegorslists at googlemail.com <yegorslists@googlemail.com> [120925 01:45]:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
> of consistent DMA memory (da8xx frame buffer driver).
>
> Signed-off-by: Dejan Gacnik <dejan.gacnik@gmail.com>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Thanks for updating this, applying this into omap fixes.
Regards,
Tony
> ---
> arch/arm/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2f88d8d..06d489e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1768,6 +1768,7 @@ source "mm/Kconfig"
> config FORCE_MAX_ZONEORDER
> int "Maximum zone order" if ARCH_SHMOBILE
> range 11 64 if ARCH_SHMOBILE
> + default "12" if SOC_AM33XX
> default "9" if SA1111
> default "11"
> help
^ permalink raw reply
* [PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2
From: Kevin Hilman @ 2012-10-08 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1505601.8trb51fSMV@vostro.rjw.lan>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Wednesday 03 of October 2012 16:00:25 Kevin Hilman wrote:
>> From: Kevin Hilman <khilman@ti.com>
>>
>> Here's a series with a couple bug fixes and a couple fixes that
>> make this driver support newer OMAP-based SoCs.
>>
>> The 'get_cpu_device' patch is needed due to a change in the OMAP
>> OMAP PM core code which enforces use of get_cpu_device() instead of
>> a deprecated OMAP-specific API.
>>
>> The usage of plat/*.h headers breaks single zImage, so platforms are
>> cleaning up and/or removing plat/*.h so the driver needs to be fixed
>> accordingly.
>>
>> This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into
>> Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603.
>>
>> Tested CPUfreq on OMAP platforms: 3430/n900, 3530/Overo,
>> 3730/OveroSTORM, 3730/Beagle-XM, 4430/Panda.
>>
>> Rafael, if you're OK with this series, I'll get a pull request
>> ASAP so it can be included for v3.7-rc2.
>
> The patches are fine by me, but there may be a bit of a timing issue with
> them, because I'll be travelling between October 12 and October 21 inclusive
> and I won't be pushing stuff to kernel.org during that time.
>
> So I think it would be better to merge this material through the arm-soc tree,
> if that's not a problem. If you decide to do so, please feel free to add my
> ACK to the patches.
Thanks, I'll get them queued.
Kevin
^ 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