;
> 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
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
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
Tested-by: Bastian Stender
---
arch/arm/mach-omap2/omap4-common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2
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 unmasking is done
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 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
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/pdata-quirks.c | 29
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
Acked-by: Hauke Mehrtens
---
arch/arm/mach-bcm/bcm_5301x.c | 35
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
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
---
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
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
---
arch/arm/mach-bcm/bcm_5301x.c | 35 ---
1 file
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
---
arch/arm/mach-omap2/pdata-quirks.c | 29 -
1 file
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
---
arch/arm/mach-mvebu/board-v7.c | 35 ---
1
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
---
arch/arm/mm/fault.c | 15 +++
arch/arm/mm/fault.h | 2 ++
arch/arm/mm/mmu.c | 19 ++-
3 files changed, 35 insertions(+), 1
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
AM 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 |
Industr
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 w
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 intern
e-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/ |
Pe
20 matches
Mail list logo