e 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 absolute
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
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
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 fil
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
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 un
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 un
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>
-
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
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>
-
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 warnin
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
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 c
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.
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.
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.
ratch, 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 |
Industria
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
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
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
20 matches
Mail list logo
