* [PATCH v2 1/2] ARM: imx: clk: Split SSI clock into 'ipg' and 'per'
From: Fabio Estevam @ 2012-10-08 19:40 UTC (permalink / raw)
To: linux-arm-kernel
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.
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
^ permalink raw reply related
* [PATCH 5/6] ARM: dove: Remove watchdog from DT
From: Andrew Lunn @ 2012-10-08 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008184016.GA30416@jirafa.cyrius.com>
Hi Martin
> Arnaud Patard pointed out this conversation to me. I added Orion and
> Kirkwood support to Debian.
I used your guide at http://www.cyrius.com/debian/kirkwood/qnap/
to convert my QNAP-119P+ over to Debian. Works great.
> If someone volunteers to keep the Orion code up-to-date and/or port it
> to DT, I can perform tests from time to time. I have the following
> Orion devices: QNAP TS-209, QNAP TS-409, HP mv2120 and D-Link DNS-323.
At the moment Kirkwood is my priority, but i think we should have most
of it converted to DT in the next three months. Once that is over, i
can look at Orion5x.
It is great you offered to test. I have a Marvell orion5x reference
system, rd88f5182. So i can do a lot of the conversion using
that. What i think will cause problems is PCI. There is scary looking
PCI code in the -setup.c files. I don't know how easy that will be to
convert to DT. However, it looks like most targets don't actually use
PCI, so maybe some will be easier to convert than others.
Andrew
^ permalink raw reply
* [PATCH V3 2/2] ARM: Handle user space mapped pages in flush_kernel_dcache_page
From: Simon Baatz @ 2012-10-08 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008174428.GB3204@arm.com>
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().
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.
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. On the other hand, if we clear the
PG_dcache_clean flag in a function that is not even supposed to
handle anon pages, then why shouldn't we do it in a function that is?
I wanted to play safe here and apply the same logic in both
functions.
- Simon
^ permalink raw reply
* [PATCH 5/6] ARM: dove: Remove watchdog from DT
From: Arnd Bergmann @ 2012-10-08 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008195706.GM21046@lunn.ch>
On Monday 08 October 2012, Andrew Lunn wrote:
> > Arnaud Patard pointed out this conversation to me. I added Orion and
> > Kirkwood support to Debian.
>
> I used your guide at http://www.cyrius.com/debian/kirkwood/qnap/
> to convert my QNAP-119P+ over to Debian. Works great.
>
> > If someone volunteers to keep the Orion code up-to-date and/or port it
> > to DT, I can perform tests from time to time. I have the following
> > Orion devices: QNAP TS-209, QNAP TS-409, HP mv2120 and D-Link DNS-323.
>
> At the moment Kirkwood is my priority, but i think we should have most
> of it converted to DT in the next three months. Once that is over, i
> can look at Orion5x.
>
> It is great you offered to test. I have a Marvell orion5x reference
> system, rd88f5182. So i can do a lot of the conversion using
> that. What i think will cause problems is PCI. There is scary looking
> PCI code in the -setup.c files. I don't know how easy that will be to
> convert to DT. However, it looks like most targets don't actually use
> PCI, so maybe some will be easier to convert than others.
I can offer some help with the PCI bits. I don't have any orion hardware,
but if you get stuck, you can find me on IRC or we can talk on the phone
about how it should be done.
Arnd
^ permalink raw reply
* [PATCH V3 2/2] ARM: Handle user space mapped pages in flush_kernel_dcache_page
From: Russell King - ARM Linux @ 2012-10-08 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008200216.GA14167@schnuecks.de>
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.
Remember that these functions only get used on so-called "minority"
architectures where the caches are a hinderance - to put that a
different way, most people don't care about these calls because x86
just works.
> 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".
^ permalink raw reply
* [PATCH 5/6] ARM: dove: Remove watchdog from DT
From: Andrew Lunn @ 2012-10-08 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210082010.13928.arnd@arndb.de>
Hi Arnd
> > It is great you offered to test. I have a Marvell orion5x reference
> > system, rd88f5182. So i can do a lot of the conversion using
> > that. What i think will cause problems is PCI. There is scary looking
> > PCI code in the -setup.c files. I don't know how easy that will be to
> > convert to DT. However, it looks like most targets don't actually use
> > PCI, so maybe some will be easier to convert than others.
>
> I can offer some help with the PCI bits. I don't have any orion hardware,
> but if you get stuck, you can find me on IRC or we can talk on the phone
> about how it should be done.
Thanks for the offer.
I know that the Free Electron guys, Thomas or Gregory, will be looking
at PCI for 370/XP soon and Kirkwood and Dove are in scope for that
work, as far as i know. So i will see how that developers, maybe lend
a hand, and see how easy it is to integrate support for Orion5x.
I suspect Orion5x might be a problem though. Its both PCI and PCIe,
where as the others are purely PCIe and orion5x has WA access method,
which all the other Marvell systems don't have. Also, it seems like
some Orion5x boards have the PCI IRQ on GPIO lines where as all the
other SoC have dedicated pins.
Andrew
^ permalink raw reply
* [PATCH v2 3/5] ARM: use generic unaligned.h
From: Rob Herring @ 2012-10-08 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008164353.GB6140@S2101-09.ap.freescale.net>
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 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.
Rob
> ef1c209 ARM: 7492/1: add strstr declaration for decompressors
>
> Shawn
>
> On Sat, Aug 04, 2012 at 08:23:58PM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This moves ARM over to the asm-generic/unaligned.h header. This has the
>> benefit of better code generated especially for ARMv7 on gcc 4.7+
>> compilers.
>>
>> As Arnd Bergmann, points out: The asm-generic version uses the "struct"
>> version for native-endian unaligned access and the "byteshift" version
>> for the opposite endianess. The current ARM version however uses the
>> "byteshift" implementation for both.
>>
>> Thanks to Nicolas Pitre for the excellent analysis:
>>
>> Test case:
>>
>> int foo (int *x) { return get_unaligned(x); }
>> long long bar (long long *x) { return get_unaligned(x); }
>>
>> With the current ARM version:
>>
>> foo:
>> ldrb r3, [r0, #2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
>> ldrb r1, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
>> ldrb r2, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
>> mov r3, r3, asl #16 @ tmp154, MEM[(const u8 *)x_1(D) + 2B],
>> ldrb r0, [r0, #3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
>> orr r3, r3, r1, asl #8 @, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
>> orr r3, r3, r2 @ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
>> orr r0, r3, r0, asl #24 @,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
>> bx lr @
>>
>> bar:
>> stmfd sp!, {r4, r5, r6, r7} @,
>> mov r2, #0 @ tmp184,
>> ldrb r5, [r0, #6] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
>> ldrb r4, [r0, #5] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
>> ldrb ip, [r0, #2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
>> ldrb r1, [r0, #4] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
>> mov r5, r5, asl #16 @ tmp175, MEM[(const u8 *)x_1(D) + 6B],
>> ldrb r7, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
>> orr r5, r5, r4, asl #8 @, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
>> ldrb r6, [r0, #7] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
>> orr r5, r5, r1 @ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
>> ldrb r4, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
>> mov ip, ip, asl #16 @ tmp188, MEM[(const u8 *)x_1(D) + 2B],
>> ldrb r1, [r0, #3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
>> orr ip, ip, r7, asl #8 @, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
>> orr r3, r5, r6, asl #24 @,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
>> orr ip, ip, r4 @ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
>> orr ip, ip, r1, asl #24 @, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
>> mov r1, r3 @,
>> orr r0, r2, ip @ tmp171, tmp184, tmp194
>> ldmfd sp!, {r4, r5, r6, r7}
>> bx lr
>>
>> In both cases the code is slightly suboptimal. One may wonder why
>> wasting r2 with the constant 0 in the second case for example. And all
>> the mov's could be folded in subsequent orr's, etc.
>>
>> Now with the asm-generic version:
>>
>> foo:
>> ldr r0, [r0, #0] @ unaligned @,* x
>> bx lr @
>>
>> bar:
>> mov r3, r0 @ x, x
>> ldr r0, [r0, #0] @ unaligned @,* x
>> ldr r1, [r3, #4] @ unaligned @,
>> bx lr @
>>
>> This is way better of course, but only because this was compiled for
>> ARMv7. In this case the compiler knows that the hardware can do
>> unaligned word access. This isn't that obvious for foo(), but if we
>> remove the get_unaligned() from bar as follows:
>>
>> long long bar (long long *x) {return *x; }
>>
>> then the resulting code is:
>>
>> bar:
>> ldmia r0, {r0, r1} @ x,,
>> bx lr @
>>
>> So this proves that the presumed aligned vs unaligned cases does have
>> influence on the instructions the compiler may use and that the above
>> unaligned code results are not just an accident.
>>
>> Still... this isn't fully conclusive without at least looking at the
>> resulting assembly fron a pre ARMv6 compilation. Let's see with an
>> ARMv5 target:
>>
>> foo:
>> ldrb r3, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
>> ldrb r1, [r0, #1] @ zero_extendqisi2 @ tmp140,
>> ldrb r2, [r0, #2] @ zero_extendqisi2 @ tmp143,
>> ldrb r0, [r0, #3] @ zero_extendqisi2 @ tmp146,
>> orr r3, r3, r1, asl #8 @, tmp142, tmp139, tmp140,
>> orr r3, r3, r2, asl #16 @, tmp145, tmp142, tmp143,
>> orr r0, r3, r0, asl #24 @,, tmp145, tmp146,
>> bx lr @
>>
>> bar:
>> stmfd sp!, {r4, r5, r6, r7} @,
>> ldrb r2, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
>> ldrb r7, [r0, #1] @ zero_extendqisi2 @ tmp140,
>> ldrb r3, [r0, #4] @ zero_extendqisi2 @ tmp149,
>> ldrb r6, [r0, #5] @ zero_extendqisi2 @ tmp150,
>> ldrb r5, [r0, #2] @ zero_extendqisi2 @ tmp143,
>> ldrb r4, [r0, #6] @ zero_extendqisi2 @ tmp153,
>> ldrb r1, [r0, #7] @ zero_extendqisi2 @ tmp156,
>> ldrb ip, [r0, #3] @ zero_extendqisi2 @ tmp146,
>> orr r2, r2, r7, asl #8 @, tmp142, tmp139, tmp140,
>> orr r3, r3, r6, asl #8 @, tmp152, tmp149, tmp150,
>> orr r2, r2, r5, asl #16 @, tmp145, tmp142, tmp143,
>> orr r3, r3, r4, asl #16 @, tmp155, tmp152, tmp153,
>> orr r0, r2, ip, asl #24 @,, tmp145, tmp146,
>> orr r1, r3, r1, asl #24 @,, tmp155, tmp156,
>> ldmfd sp!, {r4, r5, r6, r7}
>> bx lr
>>
>> Compared to the initial results, this is really nicely optimized and I
>> couldn't do much better if I were to hand code it myself.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Reviewed-by: Nicolas Pitre <nico@linaro.org>
>> ---
>> arch/arm/include/asm/Kbuild | 1 +
>> arch/arm/include/asm/unaligned.h | 19 -------------------
>> 2 files changed, 1 insertion(+), 19 deletions(-)
>> delete mode 100644 arch/arm/include/asm/unaligned.h
>>
>> diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
>> index 6cc8a13..a86cabf 100644
>> --- a/arch/arm/include/asm/Kbuild
>> +++ b/arch/arm/include/asm/Kbuild
>> @@ -33,3 +33,4 @@ generic-y += sockios.h
>> generic-y += termbits.h
>> generic-y += timex.h
>> generic-y += types.h
>> +generic-y += unaligned.h
>> diff --git a/arch/arm/include/asm/unaligned.h b/arch/arm/include/asm/unaligned.h
>> deleted file mode 100644
>> index 44593a8..0000000
>> --- a/arch/arm/include/asm/unaligned.h
>> +++ /dev/null
>> @@ -1,19 +0,0 @@
>> -#ifndef _ASM_ARM_UNALIGNED_H
>> -#define _ASM_ARM_UNALIGNED_H
>> -
>> -#include <linux/unaligned/le_byteshift.h>
>> -#include <linux/unaligned/be_byteshift.h>
>> -#include <linux/unaligned/generic.h>
>> -
>> -/*
>> - * Select endianness
>> - */
>> -#ifndef __ARMEB__
>> -#define get_unaligned __get_unaligned_le
>> -#define put_unaligned __put_unaligned_le
>> -#else
>> -#define get_unaligned __get_unaligned_be
>> -#define put_unaligned __put_unaligned_be
>> -#endif
>> -
>> -#endif /* _ASM_ARM_UNALIGNED_H */
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-08 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5072B9EF.1020005@arm.com>
* Marc Zyngier <marc.zyngier@arm.com> [121008 04:34]:
> On 08/10/12 12:01, Dave Martin wrote:
> >
> > In an attempt to narrow this down...
> >
> > Can you follow this (i.e., _after_ a known successful switch to SVC mode)
> >
> > (a)
> > mrs \reg, cpsr
> > msr spsr_cxsf, \reg
> > adr \reg, 3f
> > movs pc, lr
> > 3:
> >
> > and (b)
> >
> > mrs \reg, cpsr
> > orr \reg, \reg, #CPSR_A_BIT
> > msr cpsr_cxsf, \reg
> >
> > and (c)
> >
> > mrs \reg, cpsr
> > orr \reg, \reg, #CPSR_A_BIT
> > msr spsr_cxsf, \reg
> > adr \reg, 3f
> > movs pc, lr
> > 3:
> >
> >
> >
> >
> > If only (a) works, this would suggest that the attempt to set the A bit
> > is causing the problem.
> >
> > If only (b) works, this suggests that the A bit is OK but that some
> > invalid hardware state, or something else we don't understand, is causing
> > exception returns to fail in general.
> >
> > If (a) and (b) work but (c) fails, this suggests that specifically
> > trying to set the A bit via an exception return is problematic.
> >
> > If all of them work then this suggests some invalid hardware state or
> > something else we don't understand, but which is cleared by the initial
> > msr cpsr_c which clobbers the processor mode.
Thanks it does not seem to be the A bit..
> Playing with an Integrator-CP with a 1136 tile, the only way I could
> cause the thing to fail was to boot the thing in SYSTEM mode.
>
> Tony, can you possibly also try the attached patch?
Yup you figured it out n800 is in system mode while 2430sdp is not..
I verified it with printhex2.
Your patch fails to compile with:
arch/arm/kernel/head.S: Assembler messages:
arch/arm/kernel/head.S:336: Error: symbol `omgsys' is already defined
Probably because it's included twice. Also, shouldn't it
be bne omgsys instead of beq?
Regards,
Tony
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 683a1e6..7714ec7 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -253,6 +253,8 @@
> mrs \reg , cpsr
> mov lr , \reg
> and lr , lr , #MODE_MASK
> + cmp lr , #SYSTEM_MODE /* Yet another braindead platform? */
> + beq omgsys
> cmp lr , #HYP_MODE
> orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> bic \reg , \reg , #MODE_MASK
> @@ -264,6 +266,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
> __MSR_ELR_HYP(14)
> __ERET
> 1: movs pc, lr
> +omgsys: msr cpsr_c, \reg
> 2:
> .endm
>
^ permalink raw reply
* [PATCH 1/1] ARM: Add option to configure output line for McSPI driver
From: Tony Lindgren @ 2012-10-08 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348684467-5707-1-git-send-email-stanhu@gmail.com>
* Stan Hu <stanhu@gmail.com> [120926 11:36]:
> McSPI driver previously assumed that D0 was input (MISO) and D1 was output (MOSI).
> This forces the hardware designer to wire all SPI peripherals in this way when
> it should be a software configuration option.
>
> Signed-off-by: Stan Hu <stanhu@gmail.com>
> ---
> arch/arm/plat-omap/include/plat/mcspi.h | 2 ++
> drivers/spi/spi-omap2-mcspi.c | 11 +++++++++--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/mcspi.h b/arch/arm/plat-omap/include/plat/mcspi.h
> index a357eb2..0a6b790 100644
> --- a/arch/arm/plat-omap/include/plat/mcspi.h
> +++ b/arch/arm/plat-omap/include/plat/mcspi.h
> @@ -18,6 +18,8 @@ struct omap2_mcspi_dev_attr {
>
> struct omap2_mcspi_device_config {
> unsigned turbo_mode:1;
> + /* 1 -> [D0 = MOSI, D1 = MISO], otherwise vice versa */
> + unsigned d0_is_output:1;
> };
>
> #endif
FYI, if this did not yet get applied, this header has now been
moved to linux/platform_data/spi-omap2-mcspi.h. So you may want
to updated it and repost.
Also, you should probably Cc spi-devel-general at lists.sourceforge.net.
Regards,
Tony
^ permalink raw reply
* [PATCH] video: imxfb: Do not crash on reboot
From: Sascha Hauer @ 2012-10-08 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349703336-8105-1-git-send-email-fabio.estevam@freescale.com>
On Mon, Oct 08, 2012 at 10:35:36AM -0300, Fabio Estevam wrote:
> Issuing a "reboot" command after the LCD times out causes the following
> warnings:
>
> Requesting system reboot
[...]
>
> 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>
> ---
> drivers/video/imxfb.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index f3363b2..6acf98a 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
> @@ -530,9 +531,12 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
> */
> 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);
> + if (!fbi->enabled) {
> + 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);
> @@ -551,9 +555,12 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
>
> writel(0, fbi->regs + LCDC_RMCR);
>
> - clk_disable_unprepare(fbi->clk_per);
> - clk_disable_unprepare(fbi->clk_ipg);
> - clk_disable_unprepare(fbi->clk_ahb);
> + if (fbi->enabled) {
> + clk_disable_unprepare(fbi->clk_per);
> + clk_disable_unprepare(fbi->clk_ipg);
> + clk_disable_unprepare(fbi->clk_ahb);
> + fbi->enabled = 0;
> + }
I think the complete functions should be protected, not only the clocks.
Sascha
--
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
* Kernel panic in mxs_auart_irq_handle with latest kernel?
From: Subodh Nijsure @ 2012-10-08 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008082450.GB18531@pengutronix.de>
On 10/08/2012 01:24 AM, Uwe Kleine-K?nig wrote:
> Hello Russell,
>
> On Mon, Oct 08, 2012 at 09:07:54AM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 08, 2012 at 09:45:47AM +0200, Uwe Kleine-K?nig wrote:
>>> On Fri, Oct 05, 2012 at 11:58:26PM +0000, Subodh Nijsure wrote:
>>>> On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
>>>> (I will start bisecting and see if I can find a reason this wknd)
>>>>
>>>> -Subodh
>>>>
>>> This dump is not complete, there is at least a line missing that reads
>>>
>>> [ $timestamp] pgd = ....
>>>
>>> It's a good habit to always provide the full info.
>>>
>>>> [ 9.700000] [00000118] *pgd=00000000
>> Uwe, yes it is, it is the line above. It's saying that there is no
>> pgd entry at address 0x118 (which is correct.)
> I'm not sure I got you right, but show_pte() has:
>
> printk(KERN_ALERT "pgd = %p\n", mm->pgd);
> pgd = pgd_offset(mm, addr);
> printk(KERN_ALERT "[%08lx] *pgd=%08llx",
> addr, (long long)pgd_val(*pgd));
>
> So there is indeed missing a line. I don't think it's essential here,
> still I think in general it's advisable to let people know not to
> shorten the output. Probably even let them post the complete kernel log.
> (Isn't there an oops marker, too?)
>
>>>> [ 9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
>>>> [ 9.700000] Modules linked in:
>>>> [ 9.700000] CPU: 0 Not tainted (3.6.0-11641-gbe4ae13-dirty #1)
>>>> [ 9.700000] PC is at uart_insert_char+0x38/0x130
>>>> [ 9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
>>>> [ 9.700000] pc : [<c025a3e0>] lr : [<c0261700>] psr: 40000093
>>>> [ 9.700000] sp : c0549ea0 ip : 00000000 fp : 00000001
>>>> [ 9.700000] r10: 00000000 r9 : c057e64e r8 : 00000020
>>>> [ 9.700000] r7 : 00000000 r6 : 00080000 r5 : 00000000 r4 : c39566c0
>>>> [ 9.700000] r3 : 00000020 r2 : 00000000 r1 : 00000000 r0 : 00000000
>>> I don't see what should access the address 0x118 here, can you please
>>> provide the output of
>>>
>>> objdump -d vmlinux | sed -nr '/^[0-9]{8} <uart_insert_char/,/^$/p'
>> objdump -d vmlinux --start-addr=0xc025a3a8 | less
>>
>> will give you the disassembly starting at uart_insert_char().
>>
>> The faulting instruction is (which is below in the Code: line of the oops
>> dump):
> Ah, I already knew some time ago that the code is included in the dump,
> I just did miss it because there are no address infos included there.
>
>> e5973118
>>
>> It's an "ldr r3, [r7, #280] ; 0x118" instruction. r7 is zero, and the
>> instruction has an pre-indexed offset of 0x118. _That_ is where 0x118
>> is coming from.
> obviously.
>
>> The full code line is:
>>
>> 28: 1a000012 bne 0x78
>> 2c: e59d2020 ldr r2, [sp, #32]
>> 30: e5cd3006 strb r3, [sp, #6]
>> 34: e5cd2007 strb r2, [sp, #7]
>> 38: e5973118 ldr r3, [r7, #280] ; 0x118
>>
>> I suspect the problem is that the mxs serial driver is calling
>> uart_insert_char() when the port has been closed by userland, which
>> means there's no tty associated with it.
> Thanks for your insights. At least my mail wasn't for nothing because I
> learned again something about oopses.
My apologies. Problem that I came across was caused by some other
vendor driver for a wireless device that is on this board.
As soon as I disable that driver I don't see this kernel panic.
-Subodh
^ permalink raw reply
* [PATCH] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
From: Tony Lindgren @ 2012-10-08 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFoWwXv2GjWt2+sCYqM+vbtJ5xJBJAJMSuZhjKLKtURQ0eziVw@mail.gmail.com>
* Dejan Ga?nik <dejan.gacnik@gmail.com> [120927 07:13]:
>
> I and my colleagues have developed a brand new very enhanced board having
> AM35xx CPU, 512MB DDR2, DVI, true dual Ethernet support (not using PRUSS),
> CAN, SPI, I2C, 7 USBs, etc?Board is already materialized and operational.
>
>
> According to our board we have create new machine type in the kernel
> (version: linux-3.2-psp04.06.00.07.sdk) and all other required stuff to
> support our board, modify some things, like adding support for dual eth,
> etc. Our goal is to provide this new board to the market (let say with
> large quantity) and therefore I am wondering how to start or if it is even
> possible to transfer our kernel change the main stream of this distro?
> During this kernel modification process we have been looking to not
> changing anything in kernel, what could affect other machine types.
For the mainline kernel, you should go with device tree based booting
to start with, we are no longer adding new board-*.c files. For older
distro kernels you need to maintain a separate board-*.c file until
we have moved everything to use device tree and distros are using
that kernel.
Regards,
Tony
^ permalink raw reply
* [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
From: Tony Lindgren @ 2012-10-08 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120925151755.GA4840@atomide.com>
* Tony Lindgren <tony@atomide.com> [120925 08:19]:
> * R, Sricharan <r.sricharan@ti.com> [120925 00:44]:
> > Hi Tony,
> >
> > [snip..]
> >
> > >> > index dbf1e03..2bc51fb 100644
> > >> > --- a/arch/arm/plat-omap/counter_32k.c
> > >> > +++ b/arch/arm/plat-omap/counter_32k.c
> > >> > @@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
> > >> > * nsecs and adds to a monotonically increasing timespec.
> > >> > */
> > >> > static struct timespec persistent_ts;
> > >> > -static cycles_t cycles, last_cycles;
> > >> > +static cycles_t cycles;
> > >> > static unsigned int persistent_mult, persistent_shift;
> > >> > +static DEFINE_SPINLOCK(read_persistent_clock_lock);
> > >> > +
> > >> > static void omap_read_persistent_clock(struct timespec *ts)
> > >> > {
> > >> > unsigned long long nsecs;
> > >> > - cycles_t delta;
> > >> > - struct timespec *tsp = &persistent_ts;
> > >> > + cycles_t last_cycles;
> > >> > + unsigned long flags;
> > >> > +
> > >> > + spin_lock_irqsave(&read_persistent_clock_lock, flags);
> > >> >
> > >> > last_cycles = cycles;
> > >> > cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
> > >> > - delta = cycles - last_cycles;
> > >> >
> > >> > - nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
> > >> > + nsecs = clocksource_cyc2ns(cycles - last_cycles,
> > >> > + persistent_mult, persistent_shift);
> > >
> > > ..I think there's another bug here where cycles - last_cycles
> > > returns wrong value when the timer wraps around as cycles_t is
> > > 64 bits and the counter is 32 bits. It seems it's been there
> > > since when the read_persistent_clock was added with commit
> > > d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
> > >
> > > It seems that after this patch cycles should not be cycles_t
> > > but u32, and the result of cycles - last_cycles should also
> > > be u32.
> > >
> > cycles_t is defined as typedef unsigned long cycles_t;
> > Am i missing something here ?
>
> Oh right, cycles_t is unsigned long, it's OK then. Must
> have grepped for it from some other arch.
Applying to fixes with Cc stable.
Regards,
Tony
^ permalink raw reply
* [PATCH V2] ARM: OMAP2+: Round of the carve out memory requested to section_size
From: Tony Lindgren @ 2012-10-08 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMQu2gwuQ6uht0iHtPuhFU4B9P+zgNHYazK+BqE-rnBfnhL2cg@mail.gmail.com>
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120927 23:35]:
> On Wed, Sep 12, 2012 at 12:44 PM, R Sricharan <r.sricharan@ti.com> wrote:
> > memblock_steal tries to reserve physical memory during boot.
> > When the requested size is not aligned on the section size
> > then, the remaining memory available for lowmem becomes
> > unaligned on the section boundary. There is a issue with this,
> > which is discussed in the thread below.
> >
> > https://lkml.org/lkml/2012/6/28/112
> >
> > The final conclusion from the thread seems to
> > be align the memblock_steal calls on the SECTION boundary.
> > The issue comes out when LPAE is enabled, where the
> > section size is 2MB.
> >
> > Boot tested this on OMAP5 evm with and without LPAE.
> >
> > Signed-off-by: R Sricharan <r.sricharan@ti.com>
> > ---
> > [V2] Corrected the subject and added one more description line.
> >
> Looks good.
> Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Tony,
> Can you take this into your next "fixes-noncritical" queue please ?
Applying it now into fixes for the -rc cycle.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP: rx51: Fix a section mismatch warn
From: Tony Lindgren @ 2012-10-08 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347460624-25259-1-git-send-email-shubhrajyoti@ti.com>
* Shubhrajyoti D <shubhrajyoti@ti.com> [120912 07:38]:
> rx51_si4713_dev is referenced only from rx51_init_si4713.
> So the memory for rx51_si4713_dev can be safely freed after init.
> Also it references rx51_si4713_board_info which is __initdata_or_module.
Thanks applying into fixes.
Tony
^ permalink raw reply
* [PATCH V2 0/7] ARM: OMAP2+: Add device-tree support for timers
From: Tony Lindgren @ 2012-10-08 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50661B07.1040200@ti.com>
* Jon Hunter <jon-hunter@ti.com> [120928 14:48]:
>
> What is interesting is that it is the interrupt test that is failing for
> timers 5-7. Any chance there is a problem with the interrupt mapping? I
> checked the documentation for AM335x and I don't see anything obvious
> that is wrong with the binding unless the documentation itself is wrong.
This could also be caused by some timers not being able to wake up
the system from idle?
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
From: Tony Lindgren @ 2012-10-08 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK5ve-L92DqDv7ZApaaN5BOby+oPf2Ate-3jvgkadm7gfXZLcg@mail.gmail.com>
* Bryan Wu <bryan.wu@canonical.com> [120918 01:03]:
> On Tue, Sep 18, 2012 at 2:49 PM, Axel Lin <axel.lin@gmail.com> wrote:
> > 2012/9/18 Bryan Wu <bryan.wu@canonical.com>:
> >> On Tue, Sep 18, 2012 at 11:30 AM, Axel Lin <axel.lin@gmail.com> wrote:
> >>> 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'
> >>> make: *** [vmlinux] Error 1
> >>>
> >>
> >> Thanks for posting this. But I think Tony has already fixed it in mainline:
> >> --
> >> commit 359f64f7b3997e94ee71039b5fcdc1278b9b77c4
> >> Author: Tony Lindgren <tony@atomide.com>
> >> Date: Wed Sep 15 10:18:51 2010 -0700
> >>
> >> omap: Fix compile dependency to LEDS_CLASS
> >>
> >> If we LEDS_CLASS is not selected, we will get undefined reference
> >> to `led_classdev_register'.
> >>
> >> Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > Commit 359f64f7b was commited on Sep 15 2010.
> > This patch is against current linux-next tree.
> > I got the build error on linux-next tree (next-20120917).
> >
>
> Obviously, linux-next is not updated to latest mainline, -:D
Thanks I'll apply this to fixes.
Regards,
Tony
^ permalink raw reply
* [PATCH] arch/arm/mach-omap1/devices.c: Remove unecessary semicolon
From: Tony Lindgren @ 2012-10-08 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347986174-30287-3-git-send-email-peter.senna@gmail.com>
* Peter Senna Tschudin <peter.senna@gmail.com> [120918 09:37]:
> Found by http://coccinelle.lip6.fr/
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
> ---
> arch/arm/mach-omap1/devices.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
> index fa1fa4d..688b23a 100644
> --- a/arch/arm/mach-omap1/devices.c
> +++ b/arch/arm/mach-omap1/devices.c
> @@ -232,7 +232,7 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data **mmc_data,
>
> omap_mmc_add("mmci-omap", i, base, size, irq,
> rx_req, tx_req, mmc_data[i]);
> - };
> + }
> }
>
> #endif
Thanks applying into omap fixes branch.
Regards,
Tony
^ permalink raw reply
* [PATCH] arch/arm/mach-omap2: Remove unecessary semicolon
From: Tony Lindgren @ 2012-10-08 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347986174-30287-4-git-send-email-peter.senna@gmail.com>
* Peter Senna Tschudin <peter.senna@gmail.com> [120918 09:37]:
> Found by http://coccinelle.lip6.fr/
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
> ---
> arch/arm/mach-omap2/board-flash.c | 2 +-
> arch/arm/mach-omap2/clkt_clksel.c | 2 +-
> arch/arm/mach-omap2/mux.c | 2 +-
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 6 +++---
> arch/arm/mach-omap2/pm-debug.c | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
Thanks applying into omap fixes branch.
Regards,
Tony
^ permalink raw reply
* [PATCH] arch/arm/plat-omap/omap-pm-noop.c: Remove unecessary semicolon
From: Tony Lindgren @ 2012-10-08 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347986174-30287-6-git-send-email-peter.senna@gmail.com>
* Peter Senna Tschudin <peter.senna@gmail.com> [120918 09:37]:
> Found by http://coccinelle.lip6.fr/
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
> ---
> arch/arm/plat-omap/omap-pm-noop.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Thanks applying into omap fixes branch.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/5] [media] omap3isp: Fix compilation error in ispreg.h
From: Tony Lindgren @ 2012-10-08 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121007101718.073aed3b@infradead.org>
* Mauro Carvalho Chehab <mchehab@infradead.org> [121007 06:18]:
> Em Tue, 2 Oct 2012 09:31:58 -0700
> Tony Lindgren <tony@atomide.com> escreveu:
>
> > * Ido Yariv <ido@wizery.com> [121001 15:48]:
> > > Commit c49f34bc ("ARM: OMAP2+ Move SoC specific headers to be local to
> > > mach-omap2") moved omap34xx.h to mach-omap2. This broke omap3isp, as it
> > > includes omap34xx.h.
> > >
> > > Instead of moving omap34xx to platform_data, simply add the two
> > > definitions the driver needs and remove the include altogether.
> > >
> > > Signed-off-by: Ido Yariv <ido@wizery.com>
> >
> > I'm assuming that Mauro picks this one up, sorry
> > for breaking it.
>
> Picked, thanks.
>
> With regards to the other patches in this series, IMHO, it
> makes more sense to go through arm omap tree, so, for the
> patches on this series that touch at drivers/media/platform/*:
>
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks yeah it's best that I pick up the rest. I can setup
a minimal branch that can also be pulled into iommu branch
after -rc1.
Regards,
Tony
^ permalink raw reply
* [PATCH] OMAPDSS: fix return value check in create_dss_pdev()
From: Tony Lindgren @ 2012-10-08 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd-G9Otuu2KT3e8WuW+yxLrHH68vj3dEgOXOZFo70=YFnQ@mail.gmail.com>
* Wei Yongjun <weiyj.lk@gmail.com> [120920 23:29]:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function omap_device_alloc() returns ERR_PTR()
> not NULL pointer. The NULL test in the return value check should
> be replaced with IS_ERR().
Thanks applying into omap fixes.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP: hsmmc: fix return value check in omap_hsmmc_init_one()
From: Tony Lindgren @ 2012-10-08 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd9RvEA1_dtaHOTCnuoboU3jcwzn_trwucu9kDqqdR1Lcw@mail.gmail.com>
* Wei Yongjun <weiyj.lk@gmail.com> [120920 23:31]:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function omap_device_alloc() returns ERR_PTR()
> not NULL pointer. The NULL test in the return value check should
> be replaced with IS_ERR().
Thanks applying into omap fixes.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] ARM: OMAP2+: Add am335x evm and bone targets to common Makefile
From: Tony Lindgren @ 2012-10-08 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348511491-455-1-git-send-email-hvaibhav@ti.com>
* Vaibhav Hiremath <hvaibhav@ti.com> [120924 11:38]:
> This adds am335x-evm and am335x-bone dtb targets to
> 'make dtbs', just like other platforms.
Thanks applying into omap fixes.
Tony
^ 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