Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

2015-12-08 Thread Lucas Stach 
Hi Bjorn,

Am Montag, den 07.12.2015, 21:33 -0600 schrieb Bjorn Helgaas:
> [+cc Jingoo (exynos), Richard, Lucas (imx6), Pratyush (spear13xx)]
> 
> On Fri, Dec 04, 2015 at 11:22:50PM +0200, Grygorii Strashko wrote:
> > On 12/04/2015 08:46 PM, Bjorn Helgaas wrote:
> > > Hi Grygorii,
[...]
> > >>   
> > >> +/*
> > >> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
> > >> + * On -RT and if kernel is booting with "threadirqs" cmd line 
> > >> parameter
> > >> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded 
> > >> but,
> > >> + * in the same time, it's IRQ dispatcher and calls 
> > >> generic_handle_irq(),
> > >> + * which, in turn, will be resolved to handle_simple_irq() call.
> > >> + * The handle_simple_irq() expected to be called with IRQ 
> > >> disabled, as
> > >> + * result kernle will display warning:
> > >> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
> > >> + */
> > >>  ret = devm_request_irq(>dev, pp->irq,
> > >> -   dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
> > >> +   dra7xx_pcie_msi_irq_handler,
> > >> +   IRQF_SHARED | IRQF_NO_THREAD,
> > >> "dra7-pcie-msi", pp);
> > > 
> > > There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
> > > and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
> > > why not?
> > > 
> > > I see your discussion about DRA7 hardware design, but my impression is
> > > that this problem affects anybody who calls dw_handle_msi_irq() from a
> > > handler registered with IRQF_SHARED.
> > 
> > Issue fixed by this patch is not related to IRQF_SHARED. 
> > It will happen on -RT or if kernel will boot with "threadirqs" cmd line 
> > parameter
> > - in both cases these PCI IRQ handlers will be forced to be threaded and,
> > as result, generic_handle_irq() will produce above backtrace.
> > 
> > Personally, I don't have strong opinion about "should similar change be 
> > applied
> > to other PCI drivers or not?" And I think, that owners of those driver 
> > should
> > make such decision.
> 
> If the same issue affects several drivers, I'd like to see them all
> handle it the same way.  Otherwise, somebody coming along later will
> wonder why they're different, and there won't be a good answer.
> 
> I cc'd the other maintainers to see what they think.
> 
Yes, this should absolutely be changed in all drivers, based on the DW
core. There were some patches for this already, but apparently they have
not been applied, because some review feedback wasn't taken care of.

I have a patch titled "PCI: designware: Mark the msi cascade handler
IRQF_NO_THREAD" in my inbox that did this, and I still think it's the
right thing to do.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP4: execute initcall to reserve SRAM for I688 only on OMAP4

2015-12-01 Thread Lucas Stach 
Am Montag, den 30.11.2015, 20:27 +0200 schrieb Grygorii Strashko:
> On 11/30/2015 07:27 PM, Lucas Stach wrote:
> > Am Montag, den 16.11.2015, 14:24 +0200 schrieb Grygorii Strashko:
> >> On 11/16/2015 01:25 PM, Lucas Stach wrote:
> >>> omap_interconnect_sync() is the only user of the SRAM scratch area
> >>> allocated in the omap4_sram_init initcall. The interconnect sync is
> >>> used exclusively in the OMAP4 specific WFI implementation, so there
> >>> is no point in allocating the SRAM scratch on other SoC types.
> >>>
> >>> Bail out of the initcall if the kernel is not running on OMAP4 to
> >>> avoid a confusing warning about being unable to allocate the SRAM
> >>> needed for I688 handling.
> >>>
> >>> Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
> >>> Tested-by: Bastian Stender <b...@pengutronix.de>
> >>> ---
> >>>arch/arm/mach-omap2/omap4-common.c | 3 +++
> >>>1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/omap4-common.c 
> >>> b/arch/arm/mach-omap2/omap4-common.c
> >>> index 949696b6f17b..6db393a30a28 100644
> >>> --- a/arch/arm/mach-omap2/omap4-common.c
> >>> +++ b/arch/arm/mach-omap2/omap4-common.c
> >>> @@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
> >>>   struct device_node *np;
> >>>   struct gen_pool *sram_pool;
> >>>
> >>> + if (!cpu_is_omap44xx())
> >>> + return 0;
> >>
> >> This one affects on am43xx also
> >>
> > So you are saying this erratum is also present on AM43xx? I wasn't able
> > to deduce this from the information provided by Richard Woodruff.
> > 
> 
> "..SOCs using similar chassis components of OMAP4430 time are impacted..."
> "..But AM335x should be immune from this particular issue..."
> 
> Advisory 11 Asynchronous Bridge Corruption
> http://www.ti.com/lit/er/sprz408b/sprz408b.pdf
> 
> 
Thanks for the link, it makes things a lot more clear.
> 
> >>
> >>> +
> >>>   np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
> >>>   if (!np)
> >>>   pr_warn("%s:Unable to allocate sram needed to handle 
> >>> errata I688\n",
> >>
> >> Since all OMAP4+ platforms are now DT based why can't we just return from 
> >> here silently?
> >>
> > If we are unable to allocate the SRAM needed to work around I688 this is
> > a real error on platforms that expose this erratum, so silently bailing
> > out at this point may obscure a real issue.
> > 
> 
> SRAM is not allocated here - It's just check to understand do we need it or 
> not
> in case of multiplatform build where CONFIG_OMAP_INTERCONNECT_BARRIER will be 
> selected most
> probably.
> 
> And if "ti,omap4-mpu" was not found - it just means that this, particular, 
> platform
> is not affected by i688 errata.
> If someone misses corresponding node in DT - we can't do nothing :)
> 
Okay, so the above document says that AM43xx is affected by the erratum,
but the am4372.dtsi doesn't contain a "ti,omap4-mpu" node, so the
workaround will not be applied. If we silence the warning, we now have a
system that will be prone to data corruption without ever warning the
user about it. This is surely not what anyone wants.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP4: execute initcall to reserve SRAM for I688 only on OMAP4

2015-11-30 Thread Lucas Stach 
Am Montag, den 16.11.2015, 14:24 +0200 schrieb Grygorii Strashko:
> On 11/16/2015 01:25 PM, Lucas Stach wrote:
> > omap_interconnect_sync() is the only user of the SRAM scratch area
> > allocated in the omap4_sram_init initcall. The interconnect sync is
> > used exclusively in the OMAP4 specific WFI implementation, so there
> > is no point in allocating the SRAM scratch on other SoC types.
> > 
> > Bail out of the initcall if the kernel is not running on OMAP4 to
> > avoid a confusing warning about being unable to allocate the SRAM
> > needed for I688 handling.
> > 
> > Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
> > Tested-by: Bastian Stender <b...@pengutronix.de>
> > ---
> >   arch/arm/mach-omap2/omap4-common.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/arm/mach-omap2/omap4-common.c 
> > b/arch/arm/mach-omap2/omap4-common.c
> > index 949696b6f17b..6db393a30a28 100644
> > --- a/arch/arm/mach-omap2/omap4-common.c
> > +++ b/arch/arm/mach-omap2/omap4-common.c
> > @@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
> > struct device_node *np;
> > struct gen_pool *sram_pool;
> >   
> > +   if (!cpu_is_omap44xx())
> > +   return 0;
> 
> This one affects on am43xx also
> 
So you are saying this erratum is also present on AM43xx? I wasn't able
to deduce this from the information provided by Richard Woodruff.

> 
> > +
> > np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
> > if (!np)
> > pr_warn("%s:Unable to allocate sram needed to handle errata 
> > I688\n",
> 
> Since all OMAP4+ platforms are now DT based why can't we just return from 
> here silently?
> 
If we are unable to allocate the SRAM needed to work around I688 this is
a real error on platforms that expose this erratum, so silently bailing
out at this point may obscure a real issue.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP4: execute initcall to reserve SRAM for I688 only on OMAP4

2015-11-16 Thread Lucas Stach 
omap_interconnect_sync() is the only user of the SRAM scratch area
allocated in the omap4_sram_init initcall. The interconnect sync is
used exclusively in the OMAP4 specific WFI implementation, so there
is no point in allocating the SRAM scratch on other SoC types.

Bail out of the initcall if the kernel is not running on OMAP4 to
avoid a confusing warning about being unable to allocate the SRAM
needed for I688 handling.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
Tested-by: Bastian Stender <b...@pengutronix.de>
---
 arch/arm/mach-omap2/omap4-common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 949696b6f17b..6db393a30a28 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;
 
+   if (!cpu_is_omap44xx())
+   return 0;
+
np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
if (!np)
pr_warn("%s:Unable to allocate sram needed to handle errata 
I688\n",
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] ARM: OMAP2+: remove custom abort handler for t410

2015-11-12 Thread Lucas Stach 
Tony,

can you please take this patch through the OMAP tree for 4.4? The first
patch in this series went in through Russells tree, so the below code
now has the possibility to hide a real abort later during boot.

Regards,
Lucas

Am Donnerstag, den 15.10.2015, 12:32 +0200 schrieb Lucas Stach:
> This is not needed anymore. Handling a potentially pending imprecise external
> abort left behind by the bootloader is now done in a slightly safer way inside
> the common ARM startup code.
> 
> Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
> Acked-by: Tony Lindgren <t...@atomide.com>
> ---
>  arch/arm/mach-omap2/pdata-quirks.c | 29 -
>  1 file changed, 29 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
> b/arch/arm/mach-omap2/pdata-quirks.c
> index ea56397599c2..3a2bc2a88db4 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -24,9 +24,6 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
> -
>  #include "common.h"
>  #include "common-board-devices.h"
>  #include "dss-common.h"
> @@ -385,29 +382,6 @@ static void __init omap3_pandora_legacy_init(void)
>  }
>  #endif /* CONFIG_ARCH_OMAP3 */
>  
> -#ifdef CONFIG_SOC_TI81XX
> -static int fault_fixed_up;
> -
> -static int t410_abort_handler(unsigned long addr, unsigned int fsr,
> -   struct pt_regs *regs)
> -{
> - if ((fsr == 0x406 || fsr == 0xc06) && !fault_fixed_up) {
> - pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
> ignored.\n",
> - addr, fsr);
> - fault_fixed_up = 1;
> - return 0;
> - }
> -
> - return 1;
> -}
> -
> -static void __init t410_abort_init(void)
> -{
> - hook_fault_code(16 + 6, t410_abort_handler, SIGBUS, BUS_OBJERR,
> - "imprecise external abort");
> -}
> -#endif
> -
>  #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
>  static struct iommu_platform_data omap4_iommu_pdata = {
>   .reset_name = "mmu_cache",
> @@ -536,9 +510,6 @@ static struct pdata_init pdata_quirks[] __initdata = {
>   { "openpandora,omap3-pandora-600mhz", omap3_pandora_legacy_init, },
>   { "openpandora,omap3-pandora-1ghz", omap3_pandora_legacy_init, },
>  #endif
> -#ifdef CONFIG_SOC_TI81XX
> - { "hp,t410", t410_abort_init, },
> -#endif
>  #ifdef CONFIG_SOC_OMAP5
>   { "ti,omap5-uevm", omap5_uevm_legacy_init, },
>  #endif

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-19 Thread Lucas Stach 
Am Donnerstag, den 15.10.2015, 16:32 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > Install a non-faulting handler just before unmasking imprecise aborts
> > and switch back to the regular one after unmasking is done.
> > 
> > This catches any pending imprecise abort that the firmware/bootloader
> > may have left behind that would normally crash the kernel at that point.
> > As there are apparently a lot of bootlaoders out there that do such a
> > thing it makes sense to handle it in the common startup code.
> > 
> > Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
> 
> Much better.  Please feel free to add it to the patch system, thanks.
> 
> I think, given that the original seems to be breaking platforms, this
> patch needs to go into -rc kernels, right?
> 
Okay, this is in the patch system as patch 8447/1 now.

As Russell hasn't said whether he would like to pick up the platform
patches I've omitted them for now and would ask the platform maintainers
to pick them up themselves for kernel 4.4.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-16 Thread Lucas Stach 
Am Donnerstag, den 15.10.2015, 16:32 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > Install a non-faulting handler just before unmasking imprecise aborts
> > and switch back to the regular one after unmasking is done.
> > 
> > This catches any pending imprecise abort that the firmware/bootloader
> > may have left behind that would normally crash the kernel at that point.
> > As there are apparently a lot of bootlaoders out there that do such a
> > thing it makes sense to handle it in the common startup code.
> > 
> > Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
> 
> Much better.  Please feel free to add it to the patch system, thanks.
> 
Do you feel like taking patches 2 and 3 through your tree too, given
that they are already acked by the platform maintainers, or should they
pick them up themselves?

> I think, given that the original seems to be breaking platforms, this
> patch needs to go into -rc kernels, right?
> 
No, the original patch is only queued for 4.4, so the regression is only
in -next. This patch only needs to make it into your 4.4 pull request.

Thanks,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] ARM: OMAP2+: remove custom abort handler for t410

2015-10-15 Thread Lucas Stach 
This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
Acked-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ea56397599c2..3a2bc2a88db4 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,9 +24,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include "common.h"
 #include "common-board-devices.h"
 #include "dss-common.h"
@@ -385,29 +382,6 @@ static void __init omap3_pandora_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#ifdef CONFIG_SOC_TI81XX
-static int fault_fixed_up;
-
-static int t410_abort_handler(unsigned long addr, unsigned int fsr,
- struct pt_regs *regs)
-{
-   if ((fsr == 0x406 || fsr == 0xc06) && !fault_fixed_up) {
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-   fault_fixed_up = 1;
-   return 0;
-   }
-
-   return 1;
-}
-
-static void __init t410_abort_init(void)
-{
-   hook_fault_code(16 + 6, t410_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
-#endif
-
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = "mmu_cache",
@@ -536,9 +510,6 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "openpandora,omap3-pandora-600mhz", omap3_pandora_legacy_init, },
{ "openpandora,omap3-pandora-1ghz", omap3_pandora_legacy_init, },
 #endif
-#ifdef CONFIG_SOC_TI81XX
-   { "hp,t410", t410_abort_init, },
-#endif
 #ifdef CONFIG_SOC_OMAP5
{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
 #endif
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] ARM: handle imprecise aborts from firmware in common code

2015-10-15 Thread Lucas Stach 
This series implements the handling of a pending imprecise abort left behind
by the bootloader/firmware running before Linux in the common ARM startup code.

It turns pending imprecise aborts that may signal during the first unmasking
of such aborts on the boot CPU into a non-faulting event and warns the user
that the firmware of the machine might be buggy.

Handling this in the common code makes sure that we only ignore already pending
aborts and not those that may happen later during system boot/usage. It also
allows to remove the custom fault handler from the 3 architectures that are
known to have bad firmware/bootloaders.

V2 adapts patch 1 to suggestions from Russell and Hauke and drops former
patch 3 (ARM: mvebu: remove the workaround imprecise abort fault handler)
as it has already been applied.

Regards,
Lucas

Lucas Stach (3):
  ARM: catch pending imprecise abort on unmask
  ARM: OMAP2+: remove custom abort handler for t410
  ARM: BCM5301X: remove workaround imprecise abort fault handler

 arch/arm/mach-bcm/bcm_5301x.c  | 35 ---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 arch/arm/mm/fault.c| 22 ++
 arch/arm/mm/fault.h|  1 +
 arch/arm/mm/mmu.c  |  3 ++-
 5 files changed, 25 insertions(+), 65 deletions(-)

-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] ARM: BCM5301X: remove workaround imprecise abort fault handler

2015-10-15 Thread Lucas Stach 
This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
Acked-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 arch/arm/mach-bcm/bcm_5301x.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
index 5478fe6bcce6..c8830a2b0d60 100644
--- a/arch/arm/mach-bcm/bcm_5301x.c
+++ b/arch/arm/mach-bcm/bcm_5301x.c
@@ -9,40 +9,6 @@
 #include 
 
 #include 
-#include 
-#include 
-
-
-static bool first_fault = true;
-
-static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
-struct pt_regs *regs)
-{
-   if ((fsr == 0x1406 || fsr == 0x1c06) && first_fault) {
-   first_fault = false;
-
-   /*
-* These faults with codes 0x1406 (BCM4709) or 0x1c06 happens
-* for no good reason, possibly left over from the CFE boot
-* loader.
-*/
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-
-   /* Returning non-zero causes fault display and panic */
-   return 0;
-   }
-
-   /* Others should cause a fault */
-   return 1;
-}
-
-static void __init bcm5301x_init_early(void)
-{
-   /* Install our hook */
-   hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
 
 static const char *const bcm5301x_dt_compat[] __initconst = {
"brcm,bcm4708",
@@ -52,6 +18,5 @@ static const char *const bcm5301x_dt_compat[] __initconst = {
 DT_MACHINE_START(BCM5301X, "BCM5301X")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
-   .init_early = bcm5301x_init_early,
.dt_compat  = bcm5301x_dt_compat,
 MACHINE_END
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Lucas Stach 
Install a non-faulting handler just before unmasking imprecise aborts
and switch back to the regular one after unmasking is done.

This catches any pending imprecise abort that the firmware/bootloader
may have left behind that would normally crash the kernel at that point.
As there are apparently a lot of bootlaoders out there that do such a
thing it makes sense to handle it in the common startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
v2:
- move temporary fault handler swapping into fault.c to hide it from
  other parts of the kernel
- print FSR, when warning user about bad firmware/bootloader
---
 arch/arm/mm/fault.c | 22 ++
 arch/arm/mm/fault.h |  1 +
 arch/arm/mm/mmu.c   |  3 ++-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 0d629b8f973f..daafcf121ce0 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -593,6 +593,28 @@ do_PrefetchAbort(unsigned long addr, unsigned int ifsr, 
struct pt_regs *regs)
arm_notify_die("", regs, , ifsr, 0);
 }
 
+/*
+ * Abort handler to be used only during first unmasking of asynchronous aborts
+ * on the boot CPU. This makes sure that the machine will not die if the
+ * firmware/bootloader left an imprecise abort pending for us to trip over.
+ */
+static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
+ struct pt_regs *regs)
+{
+   pr_warn("Hit pending asynchronous external abort (FSR=0x%08x) during "
+   "first unmask, this is most likely caused by a "
+   "firmware/bootloader bug.\n", fsr);
+
+   return 0;
+}
+
+void __init early_abt_enable(void)
+{
+   fsr_info[22].fn = early_abort_handler;
+   local_abt_enable();
+   fsr_info[22].fn = do_bad;
+}
+
 #ifndef CONFIG_ARM_LPAE
 static int __init exceptions_init(void)
 {
diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
index cf08bdfbe0d6..05ec5e0df32d 100644
--- a/arch/arm/mm/fault.h
+++ b/arch/arm/mm/fault.h
@@ -24,5 +24,6 @@ static inline int fsr_fs(unsigned int fsr)
 
 void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
 unsigned long search_exception_table(unsigned long addr);
+void early_abt_enable(void);
 
 #endif /* __ARCH_ARM_FAULT_H */
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f65a6f344b6d..4867f5daf82c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 
+#include "fault.h"
 #include "mm.h"
 #include "tcm.h"
 
@@ -1365,7 +1366,7 @@ static void __init devicemaps_init(const struct 
machine_desc *mdesc)
flush_cache_all();
 
/* Enable asynchronous aborts */
-   local_abt_enable();
+   early_abt_enable();
 }
 
 static void __init kmap_init(void)
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] ARM: handle imprecise aborts from firmware in common code

2015-10-14 Thread Lucas Stach 
This series implements the handling of a pending imprecise abort left behind
by the bootloader/firmware running before Linux in the common ARM startup code.

It turns pending imprecise aborts that may signal during the first unmasking
of such aborts on the boot CPU into a non-faulting event and warns the user
that the firmware of the machine might be buggy.

Handling this in the common code makes sure that we only ignore already pending
aborts and not those that may happen later during system boot/usage. It also
allows to remove the custom fault handler from the 3 architectures that are
known to have bad firmware/bootloaders.

The patches changing OMAP, MVEBU and BCM5301X are only build tested as I have
no hardware to test on. So I would appreciate a tested-by for those.

Regards,
Lucas

Lucas Stach (4):
  ARM: catch pending imprecise abort on unmask
  ARM: OMAP2+: remove custom abort handler for t410
  ARM: mvebu: remove the workaround imprecise abort fault handler
  ARM: BCM5301X: remove workaround imprecise abort fault handler

 arch/arm/mach-bcm/bcm_5301x.c  | 35 ---
 arch/arm/mach-mvebu/board-v7.c | 35 ---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 arch/arm/mm/fault.c| 15 +++
 arch/arm/mm/fault.h|  2 ++
 arch/arm/mm/mmu.c  | 19 ++-
 6 files changed, 35 insertions(+), 100 deletions(-)

-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] ARM: catch pending imprecise abort on unmask

2015-10-14 Thread Lucas Stach 
Install a non-faulting handler just before unmasking imprecise aborts
and switch back to the regular one after unmasking is done.

This catches any pending imprecise abort that the firmware/bootloader
may have left behind that would normally crash the kernel at that point.
As there are apparently a lot of bootlaoders out there that do such a
thing it makes sense to handle it in the common startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
 arch/arm/mm/fault.c | 15 +++
 arch/arm/mm/fault.h |  2 ++
 arch/arm/mm/mmu.c   | 19 ++-
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 0d629b8f973f..519f694ec9db 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -538,6 +538,21 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned 
int, struct pt_regs *)
fsr_info[nr].name = name;
 }
 
+void * __init
+swap_fault_function(int nr,
+   int (*fn)(unsigned long, unsigned int, struct pt_regs *))
+{
+   void *old_fn;
+
+   if (nr < 0 || nr >= ARRAY_SIZE(fsr_info))
+   BUG();
+
+   old_fn = fsr_info[nr].fn;
+   fsr_info[nr].fn = fn;
+
+   return old_fn;
+}
+
 /*
  * Dispatch a data abort to the relevant handler.
  */
diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
index cf08bdfbe0d6..2deb7494d84f 100644
--- a/arch/arm/mm/fault.h
+++ b/arch/arm/mm/fault.h
@@ -24,5 +24,7 @@ static inline int fsr_fs(unsigned int fsr)
 
 void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
 unsigned long search_exception_table(unsigned long addr);
+void *swap_fault_function(int nr,
+   int (*fn)(unsigned long, unsigned int, struct pt_regs *));
 
 #endif /* __ARCH_ARM_FAULT_H */
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f65a6f344b6d..78c420776f4c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 
+#include "fault.h"
 #include "mm.h"
 #include "tcm.h"
 
@@ -1259,6 +1260,20 @@ void __init arm_mm_memblock_reserve(void)
 }
 
 /*
+ * Abort handler to be used only during unmasking of imprecise aborts. This
+ * makes sure that the machine will not die if the firmware/bootloader left an
+ * imprecise abort pending for us to trip over.
+ */
+static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
+ struct pt_regs *regs)
+{
+   pr_warn("Hit pending imprecise external abort during first unmask, "
+   "this is most likely caused by a firmware/bootloader bug.\n");
+
+   return 0;
+}
+
+/*
  * Set up the device mappings.  Since we clear out the page tables for all
  * mappings above VMALLOC_START, except early fixmap, we might remove debug
  * device mappings.  This means earlycon can be used to debug this function
@@ -1269,7 +1284,7 @@ static void __init devicemaps_init(const struct 
machine_desc *mdesc)
 {
struct map_desc map;
unsigned long addr;
-   void *vectors;
+   void *vectors, *saved_fault_fn;
 
/*
 * Allocate the vector page early.
@@ -1365,7 +1380,9 @@ static void __init devicemaps_init(const struct 
machine_desc *mdesc)
flush_cache_all();
 
/* Enable asynchronous aborts */
+   saved_fault_fn = swap_fault_function(22, early_abort_handler);
local_abt_enable();
+   swap_fault_function(22, saved_fault_fn);
 }
 
 static void __init kmap_init(void)
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] ARM: BCM5301X: remove workaround imprecise abort fault handler

2015-10-14 Thread Lucas Stach 
This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
 arch/arm/mach-bcm/bcm_5301x.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
index 5478fe6bcce6..c8830a2b0d60 100644
--- a/arch/arm/mach-bcm/bcm_5301x.c
+++ b/arch/arm/mach-bcm/bcm_5301x.c
@@ -9,40 +9,6 @@
 #include 
 
 #include 
-#include 
-#include 
-
-
-static bool first_fault = true;
-
-static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
-struct pt_regs *regs)
-{
-   if ((fsr == 0x1406 || fsr == 0x1c06) && first_fault) {
-   first_fault = false;
-
-   /*
-* These faults with codes 0x1406 (BCM4709) or 0x1c06 happens
-* for no good reason, possibly left over from the CFE boot
-* loader.
-*/
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-
-   /* Returning non-zero causes fault display and panic */
-   return 0;
-   }
-
-   /* Others should cause a fault */
-   return 1;
-}
-
-static void __init bcm5301x_init_early(void)
-{
-   /* Install our hook */
-   hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
 
 static const char *const bcm5301x_dt_compat[] __initconst = {
"brcm,bcm4708",
@@ -52,6 +18,5 @@ static const char *const bcm5301x_dt_compat[] __initconst = {
 DT_MACHINE_START(BCM5301X, "BCM5301X")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
-   .init_early = bcm5301x_init_early,
.dt_compat  = bcm5301x_dt_compat,
 MACHINE_END
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] ARM: OMAP2+: remove custom abort handler for t410

2015-10-14 Thread Lucas Stach 
This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ea56397599c2..3a2bc2a88db4 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,9 +24,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include "common.h"
 #include "common-board-devices.h"
 #include "dss-common.h"
@@ -385,29 +382,6 @@ static void __init omap3_pandora_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#ifdef CONFIG_SOC_TI81XX
-static int fault_fixed_up;
-
-static int t410_abort_handler(unsigned long addr, unsigned int fsr,
- struct pt_regs *regs)
-{
-   if ((fsr == 0x406 || fsr == 0xc06) && !fault_fixed_up) {
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-   fault_fixed_up = 1;
-   return 0;
-   }
-
-   return 1;
-}
-
-static void __init t410_abort_init(void)
-{
-   hook_fault_code(16 + 6, t410_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
-#endif
-
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = "mmu_cache",
@@ -536,9 +510,6 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "openpandora,omap3-pandora-600mhz", omap3_pandora_legacy_init, },
{ "openpandora,omap3-pandora-1ghz", omap3_pandora_legacy_init, },
 #endif
-#ifdef CONFIG_SOC_TI81XX
-   { "hp,t410", t410_abort_init, },
-#endif
 #ifdef CONFIG_SOC_OMAP5
{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
 #endif
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] ARM: mvebu: remove the workaround imprecise abort fault handler

2015-10-14 Thread Lucas Stach 
This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
 arch/arm/mach-mvebu/board-v7.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 9f739f3cad4c..1648edd515a2 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -105,27 +104,6 @@ static void __init mvebu_memblock_reserve(void)
 static void __init mvebu_memblock_reserve(void) {}
 #endif
 
-/*
- * Early versions of Armada 375 SoC have a bug where the BootROM
- * leaves an external data abort pending. The kernel is hit by this
- * data abort as soon as it enters userspace, because it unmasks the
- * data aborts at this moment. We register a custom abort handler
- * below to ignore the first data abort to work around this
- * problem.
- */
-static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
-   struct pt_regs *regs)
-{
-   static int ignore_first;
-
-   if (!ignore_first && fsr == 0x1406) {
-   ignore_first = 1;
-   return 0;
-   }
-
-   return 1;
-}
-
 static void __init mvebu_init_irq(void)
 {
irqchip_init();
@@ -134,17 +112,6 @@ static void __init mvebu_init_irq(void)
BUG_ON(mvebu_mbus_dt_init(coherency_available()));
 }
 
-static void __init external_abort_quirk(void)
-{
-   u32 dev, rev;
-
-   if (mvebu_get_soc_id(, ) == 0 && rev > ARMADA_375_Z1_REV)
-   return;
-
-   hook_fault_code(16 + 6, armada_375_external_abort_wa, SIGBUS, 0,
-   "imprecise external abort");
-}
-
 static void __init i2c_quirk(void)
 {
struct device_node *np;
@@ -177,8 +144,6 @@ static void __init mvebu_dt_init(void)
 {
if (of_machine_is_compatible("marvell,armadaxp"))
i2c_quirk();
-   if (of_machine_is_compatible("marvell,a375-db"))
-   external_abort_quirk();
 
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

2015-10-13 Thread Lucas Stach 
Am Freitag, den 25.09.2015, 20:44 + schrieb Woodruff, Richard:
> > From: Menon, Nishanth
> > Sent: Friday, September 25, 2015 9:44 AM
> 
> > > If I688 is not needed on am335x, then it seems there are still some
> > > mysteries remaining with this erratum to unravel. Something like
> > > difference in the L3 implementation. Maybe somebody from TI can
> > > investigate which SoCs this is really needed on?
> 
> > + Richard who probably has the oldest history on the topic.
> > 
> > I suspect strongly that the erratum was discovered during A9 OMAP4 days,
> > but never percolated to older SoC erratum documentation. The need of
> > barrier logic was clarified with SoC folks to confirm the behavior though.
> 
> -0-
> After looking up i688 in data base and reviewing AM335x SOC I do NOT think 
> i688 will exhibit for AM335x.
>  - it appears not to be using pieces which have issues on path.
> 
> I688 could impact SOCs which use a DMM and the interconnect infrastructure 
> which supports it.
> 
> I believe hang issues on path could be mapped to 3 sources:
>   - asyncbrige used from MPUSS to Arteris NOC to DMM
>   - Dual EMIF idle (ocp-connect/disconnect) policy on path
>   - PL310 idle signal usage on path
> 
> SOCs using similar chassis components of OMAP4430 time are impacted.  Errata 
> aspect in generic bridge map to Aegis, J5E, ...
> 
> The hangs are brought out by enabling power management features which causes 
> micro-idles on path which can trigger a lock up.
> 
> Later SOCs pulled in fixes in one or all areas.  Some SOCs are not using 
> components.

So please help me to get this straight:

Errata I688 only affects OMAP4 which is consequently the only user of
omap_interconnect_sync() in it's WFI enter sequence, which in turn is
the only user of the SRAM scratch area to work around the erratum.

The OMAP specific barrier implementation which should be used also on
other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
the strongly ordered access.

So it is safe to say that we only ever need to run the initcall
allocating the SRAM scratch area on OMAP4.

Is this conclusion correct?

Thanks,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 14/21] ARM: imx6: convert GPC to stacked domains

2015-01-19 Thread Lucas Stach 
Am Montag, den 19.01.2015, 09:44 + schrieb Marc Zyngier:
 IMX6 has been (ab)using the gic_arch_extn to provide
 wakeup from suspend, and it makes a lot of sense to convert
 this code to use stacked domains instead.
 
 This patch does just this, updating the DT files to actually
 reflect what the HW provides.
 
 BIG FAT WARNING: because the DTs were so far lying by not
 exposing the fact that the GPC block is actually the first
 interrupt controller in the chain, kernels with this patch
 applied wont have any suspend-resume facility when booted
 with old DTs, and old kernels with updated DTs won't even boot.
 
 Tested-by: Stefan Agner ste...@agner.ch
 Acked-by: Stefan Agner ste...@agner.ch
 Signed-off-by: Marc Zyngier marc.zyng...@arm.com
 ---
  arch/arm/boot/dts/imx6qdl.dtsi  |   7 ++-
  arch/arm/boot/dts/imx6sl.dtsi   |   6 +-
  arch/arm/boot/dts/imx6sx.dtsi   |   6 +-
  arch/arm/mach-imx/common.h  |   1 -
  arch/arm/mach-imx/gpc.c | 127 
 
  arch/arm/mach-imx/mach-imx6q.c  |   1 -
  arch/arm/mach-imx/mach-imx6sl.c |   1 -
  arch/arm/mach-imx/mach-imx6sx.c |   1 -
  8 files changed, 119 insertions(+), 31 deletions(-)
 
[...]

 --- a/arch/arm/mach-imx/common.h
 +++ b/arch/arm/mach-imx/common.h
 @@ -102,7 +102,6 @@ static inline void imx_scu_map_io(void) {}
  static inline void imx_smp_prepare(void) {}
  #endif
  void imx_src_init(void);
 -void imx_gpc_init(void);
  void imx_gpc_pre_suspend(bool arm_power_off);
  void imx_gpc_post_resume(void);
  void imx_gpc_mask_all(void);
 diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
 index 5f3602e..838da3c 100644
 --- a/arch/arm/mach-imx/gpc.c
 +++ b/arch/arm/mach-imx/gpc.c
 @@ -22,6 +22,7 @@
  #define GPC_PGC_CPU_PDN  0x2a0
  
  #define IMR_NUM  4
 +#define GPC_MAX_IRQS (IMR_NUM * 32)
  
  static void __iomem *gpc_base;
  static u32 gpc_wake_irqs[IMR_NUM];
 @@ -56,17 +57,17 @@ void imx_gpc_post_resume(void)
  
  static int imx_gpc_irq_set_wake(struct irq_data *d, unsigned int on)
  {
 - unsigned int idx = d-hwirq / 32 - 1;
 + unsigned int idx = d-hwirq / 32;
   u32 mask;
  
 - /* Sanity check for SPI irq */
 - if (d-hwirq  32)
 - return -EINVAL;
 -
   mask = 1  d-hwirq % 32;
   gpc_wake_irqs[idx] = on ? gpc_wake_irqs[idx] | mask :
 gpc_wake_irqs[idx]  ~mask;
  
 + /*
 +  * Do *not* call into the parent, as the GIC doesn't have any
 +  * wake-up facility...
 +  */
   return 0;
  }
  
 @@ -96,7 +97,7 @@ void imx_gpc_hwirq_unmask(unsigned int hwirq)
   void __iomem *reg;
   u32 val;
  
 - reg = gpc_base + GPC_IMR1 + (hwirq / 32 - 1) * 4;
 + reg = gpc_base + GPC_IMR1 + hwirq / 32 * 4;
   val = readl_relaxed(reg);
   val = ~(1  hwirq % 32);
   writel_relaxed(val, reg);
 @@ -107,7 +108,7 @@ void imx_gpc_hwirq_mask(unsigned int hwirq)
   void __iomem *reg;
   u32 val;
  
 - reg = gpc_base + GPC_IMR1 + (hwirq / 32 - 1) * 4;
 + reg = gpc_base + GPC_IMR1 + hwirq / 32 * 4;
   val = readl_relaxed(reg);
   val |= 1  (hwirq % 32);
   writel_relaxed(val, reg);
 @@ -115,37 +116,115 @@ void imx_gpc_hwirq_mask(unsigned int hwirq)
  
  static void imx_gpc_irq_unmask(struct irq_data *d)
  {
 - /* Sanity check for SPI irq */
 - if (d-hwirq  32)
 - return;
 -
   imx_gpc_hwirq_unmask(d-hwirq);
 + irq_chip_unmask_parent(d);
  }
  
  static void imx_gpc_irq_mask(struct irq_data *d)
  {
 - /* Sanity check for SPI irq */
 - if (d-hwirq  32)
 - return;
 -
   imx_gpc_hwirq_mask(d-hwirq);
 + irq_chip_mask_parent(d);
 +}
 +
 +static struct irq_chip imx_gpc_chip = {
 + .name   = GPC,
 + .irq_eoi= irq_chip_eoi_parent,
 + .irq_mask   = imx_gpc_irq_mask,
 + .irq_unmask = imx_gpc_irq_unmask,
 + .irq_retrigger  = irq_chip_retrigger_hierarchy,
 + .irq_set_wake   = imx_gpc_irq_set_wake,
 +};
 +
 +static int imx_gpc_domain_xlate(struct irq_domain *domain,
 + struct device_node *controller,
 + const u32 *intspec,
 + unsigned int intsize,
 + unsigned long *out_hwirq,
 + unsigned int *out_type)
 +{
 + if (domain-of_node != controller)
 + return -EINVAL; /* Shouldn't happen, really... */
 + if (intsize != 3)
 + return -EINVAL; /* Not GIC compliant */
 + if (intspec[0] != 0)
 + return -EINVAL; /* No PPI should point to this domain */
 +
 + *out_hwirq = intspec[1];
 + *out_type = intspec[2];
 + return 0;
 +}
 +
 +static int imx_gpc_domain_alloc(struct irq_domain *domain,
 +   unsigned int irq,
 +   unsigned int nr_irqs, void *data)
 +{
 + struct of_phandle_args *args = data;
 + struct

Re: regression: Clock changes in next-20141205 break at least omap4

2014-12-17 Thread Lucas Stach 
Am Dienstag, den 16.12.2014, 22:25 + schrieb Paul Walmsley:
 + p...@pwsan.com (I prefer not having to deal with MS Exchange when 
 possible :-) )
 
 On Tue, 16 Dec 2014, Russell King - ARM Linux wrote:
 
  On Tue, Dec 16, 2014 at 08:45:25PM +, Paul Walmsley wrote:
   On Tue, 16 Dec 2014, Russell King - ARM Linux wrote:
   
On Tue, Dec 16, 2014 at 01:01:17PM -0700, Paul Walmsley wrote:
 So the reference clock and functional clock are (usually) required by 
 the
 PLL to operate, and should therefore be required by the PLL clock 
 driver
 code in the kernel; but one could claim that they aren't technically 
 parent
 clocks of the PLL in a clock tree sense, since the downstream output 
 clock
 isn't directly derived from either of those clocks.

The reference clock is the parent clock for a PLL, and the output clock 
is a derivative of the reference clock. The PLL maths show that very 
clearly.
   
   The PLL's internal oscillator is the electrical source of the PLL's 
   output 
   clock.  The reference clock is just used to discipline that internal 
   oscillator.  Even that's not necessary - the reference clock can be 
   optional on some clock source implementations, which can run the internal 
   oscillator in open-loop mode.
  
  I would argue that running a PLL in open-loop mode is an exceptional
  circumstance: in such scenarios, many PLLs will head towards a certain
  frequency (depending on their design) and some may be rather unstable
  in open loop mode.  Only those which have been explicitly designed to
  be stable in open loop mode should be run that way.
  
  And arguably, a PLL without a reference clock is not a phase *locked*
  loop at all - the clue is in the name.  A PLL without a reference clock
  is merely an oscillator.  There is no phase lock what so ever.
 
 ...
 
  This really is a question about how you view a PLL, and it's one which
  can be debated for a very long time, and everyone will have perfectly
  valid but conflicting ideas on it.
 
 Yep, I agree with most of what you wrote.  I was mostly thinking about our 
 Linux data structures and software abstraction for clocks that have 
 multiple input clocks that all need to be simultaneously active for the IP 
 block to work.  PLLs and PLL-like clock sources which take multiple input 
 clocks just happened to be the examples of this phenomenon that came to 
 mind.
 
 Those multiple input clocks could all be considered parents from a 
 use-counting point of view, and we could expect the core clock code to 
 deal with them.  Or one could take the electrical point of view and 
 consider only one of the input clocks to be the parent -- whatever's 
 directly driving the output clock -- and fix up the gating and constraint 
 details in the driver code for that clock source.
 
 I don't think this pot is boiling over at the moment; but, just something 
 for us to reflect on.
 
Maybe I'm thinking about this too lightly, but I think we already have
the right abstractions in place.

The clock tree in Linux is always modeled along the flow of reference
clocks. So typically the root of the tree is something like an
oscillator and everything spreads out from this in a parent/child
relation. So clearly the reference clock of a PLL is the PLLs parent. If
the PLL is running in open-loop mode (isn't this rather direct frequency
synthesis?) is has no parent and is the root of a tree itself.

If a PLL needs a functional clock to drive some internal logic, that
doesn't directly influence the clock synthesis from reference to
resulting clock, that clock would be no parent to the PLL. The PLL is
merely a consumer of this clock just like every other device in the
system.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT

2013-09-03 Thread Lucas Stach 
Am Dienstag, den 03.09.2013, 06:56 -0700 schrieb Russ Dill:
 On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak rna...@ti.com wrote:
  Use drivers/misc/sram.c driver to manage SRAM on all DT only
  OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
  the existing private implementation.
 
  Address and size related data  is removed from mach-omap2/sram.c
  and now passed to drivers/misc/sram.c from DT.
 
  Users can hence use general purpose allocator apis instead of
  OMAP private ones to manage and use SRAM.
 
  Currently there are no users on SRAM on these platfoms.
 
  Signed-off-by: Rajendra Nayak rna...@ti.com
 
 I was trying to experiment with this on am33xx, but I noticed that the
 ioremap region is not marked exec, so it cannot be used to run code.

Could you outline a use-case where you would need to execute code from
SRAM while running in a linux system? I'm curious what you would use
this for.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html