generic arm needed for msm

From: Taniya Das <[email protected]>

Signed-off-by Taniya Das <[email protected]>

Signed-off-by Daniel Walker <[email protected]>

---
 arch/arm/Makefile |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

arch/arm/Makefile +7 -1

index e9da084..aa32b39 100644
@@ -50,7 +50,13 @@ comma = ,
 # Note that GCC does not numerically define an architecture version
 # macro, but instead defines a whole series of macros which makes
 # testing for a specific architecture or later rather impossible.
-arch-$(CONFIG_CPU_32v7)		:=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
+CONFIG_SHELL	:=/bin/sh
+GCC_VERSION	:= $(shell $(CONFIG_SHELL) $(PWD)/scripts/gcc-version.sh $(CROSS_COMPILE)gcc)
+ifeq ($(GCC_VERSION),0401)
+arch-$(CONFIG_CPU_32v7)		:=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7a,-march=armv5t -Wa$(comma)-march=armv7a)
+else
+arch-$(CONFIG_CPU_32v7)		:=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7a)
+endif
 arch-$(CONFIG_CPU_32v6)		:=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
 # Only override the compiler option if ARMv6. The ARMv6K extensions are
 # always available in ARMv7

Signature · 1 line

1.6.3.3

From: Dave Estes <[email protected]>

Handle incorrectly reported permission faults for qsd8650. On permission faults, retry MVA to PA conversion. If retry detects translation fault. Report as translation fault.

From: Steve Muckle <[email protected]>

ARCH_MSM_SCORPION supports Qualcomm SnapDragon chipsets.

Signed-off-by Steve Muckle <[email protected]>

Signed-off-by Daniel Walker <[email protected]>

---
 arch/arm/mm/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

arch/arm/mm/Kconfig +0 -0

index 155c7a3..c721880 100644

You don't understand what's going on here. You want to offer the question "Support ARM V7 processor" to the user, and it's acceptable on Scorpion to say "no" to this?

I think not. Do it in the same way other platforms do it, and select CPU_V7 from ARCH_MSM_SCORPION - if you have Scorpion, then surely V7 CPU support is mandatory.

You only add to the 'if' line if the support is optional for your platform.

From: Steve Muckle <[email protected]>

The Scorpion CPU speculatively reads data into the cache. This may occur while a region of memory is being written via DMA, so that region must be invalidated when it is brought under CPU control after the DMA transaction finishes, assuming the DMA was either bidirectional or from the device.

Currently both a clean and invalidate are being done for DMA_BIDIRECTIONAL in dma_unmap_single. Only an invalidate should be required here. There are drivers that currently rely on the clean however so this will be removed when those drivers are updated.

From: Larry Bassel <[email protected]>

Both the clean and invalidate functionality needed for the video encoder and 7x27 barrier code need to have a strongly ordered mapping set up so that one may perform a write to strongly ordered memory. The generic ARM code does not provide this.

The generic ARM code does provide MT_DEVICE, which starts as strongly ordered, but the code later turns the buffered flag on for ARMv6 in order to make the device shared. This is not suitable for my purpose, so this patch adds code for a MT_DEVICE_STRONGLY_ORDERED mapping type.

From: Larry Bassel <[email protected]>

For 7x27 it is necessary to write to strongly ordered memory after executing the coprocessor 15 instruction dmb instruction.

This is only for data barrier dmb().
Note that the test for 7x27 is done on all MSM platforms (even ones such as 7201a whose kernel is distinct from that of 7x25/7x27).

Acked-by Willie Ruan <[email protected]>

Signed-off-by Larry Bassel <[email protected]>

Signed-off-by Daniel Walker <[email protected]>

From: Willie Ruan <[email protected]>

Suspend function should be called before L2 cache power is turned off to save power. Resume function should be called when the power is reapplied.

Quoted 6 lines · Daniel Walker

From: Larry Bassel <[email protected]>

For 7x27 it is necessary to write to strongly ordered memory after executing the coprocessor 15 instruction dmb instruction.

Quoted 8 lines

This is only for data barrier dmb().
Note that the test for 7x27 is done on all MSM platforms (even ones such as 7201a whose kernel is distinct from that of 7x25/7x27).

Acked-by Willie Ruan <[email protected]>

Signed-off-by Larry Bassel <[email protected]>

Signed-off-by Daniel Walker <[email protected]>

Can only see half of this change - what's the actual implementation of arch_barrier_extra()?

I'd prefer not to include asm/memory.h into asm/system.h to avoid needlessly polluting headers.

From: Larry Bassel <[email protected]>

This change improves the following LMBench benchmarks by over 15%:

Quoted 16 lines · Russell King - ARM Linux

Quoted 6 lines · Daniel Walker

From: Larry Bassel <[email protected]>

For 7x27 it is necessary to write to strongly ordered memory after executing the coprocessor 15 instruction dmb instruction.

Quoted 8 lines

This is only for data barrier dmb().
Note that the test for 7x27 is done on all MSM platforms (even ones such as 7201a whose kernel is distinct from that of 7x25/7x27).

Acked-by Willie Ruan <[email protected]>

Signed-off-by Larry Bassel <[email protected]>

Signed-off-by Daniel Walker <[email protected]>

Quoted 5 lines

Can only see half of this change - what's the actual implementation of arch_barrier_extra()?

I'd prefer not to include asm/memory.h into asm/system.h to avoid needlessly polluting headers.

I don't have a real patch for it yet, but here are the pieces ..

(quoted diff) +4 -0

+#define arch_barrier_extra() do \
+       { if (machine_is_msm7x27_surf() || machine_is_msm7x27_ffa())  \
+               write_to_strongly_ordered_memory(); \
+       } while (0)

(btw, the machine types above registered either..)

static void map_zero_page_strongly_ordered(void)

{
	if (zero_page_strongly_ordered)
		return;

	zero_page_strongly_ordered =
		ioremap_strongly_ordered(page_to_pfn(empty_zero_page)
		<< PAGE_SHIFT, PAGE_SIZE);

void flush_axi_bus_buffer(void)

{
	__asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" \
				    : : "r" (0) : "memory");
	write_to_strongly_ordered_memory();

}

void *alloc_bootmem_aligned(unsigned long size, unsigned long alignment)

{
	void *unused_addr = NULL;
	unsigned long addr, tmp_size, unused_size;

	/* Allocate maximum size needed, see where it ends up.
	 * Then free it -- in this path there are no other allocators
	 * so we can depend on getting the same address back
	 * when we allocate a smaller piece that is aligned
	 * at the end (if necessary) and the piece we really want,
	 * then free the unused first piece.
	 */

	tmp_size = size + alignment - PAGE_SIZE;
	addr = (unsigned long)alloc_bootmem(tmp_size);
	free_bootmem(__pa(addr), tmp_size);

	unused_size = alignment - (addr % alignment);

	if (unused_size)
		unused_addr = alloc_bootmem(unused_size);

	addr = (unsigned long)alloc_bootmem(size);
	if (unused_size)
		free_bootmem(__pa(unused_addr), unused_size);

	return (void *)addr;

Quoted 8 lines · Daniel Walker

From: Steve Muckle <[email protected]>

The Scorpion CPU speculatively reads data into the cache. This may occur while a region of memory is being written via DMA, so that region must be invalidated when it is brought under CPU control after the DMA transaction finishes, assuming the DMA was either bidirectional or from the device.

Quoted 4 lines

Currently both a clean and invalidate are being done for DMA_BIDIRECTIONAL in dma_unmap_single. Only an invalidate should be required here. There are drivers that currently rely on the clean however so this will be removed when those drivers are updated.

NAK. There are patches around (and potentially queued) for the next merge window which properly address this.

From: Willie Ruan <[email protected]>

Suspend function should be called before L2 cache power is turned off to save power. Resume function should be called when the power is reapplied.

Quoted 14 lines · Russell King - ARM Linux

Quoted 12 lines · Daniel Walker

From: Steve Muckle <[email protected]>

The Scorpion CPU speculatively reads data into the cache. This may occur while a region of memory is being written via DMA, so that region must be invalidated when it is brought under CPU control after the DMA transaction finishes, assuming the DMA was either bidirectional or from the device.

Currently both a clean and invalidate are being done for DMA_BIDIRECTIONAL in dma_unmap_single. Only an invalidate should be required here. There are drivers that currently rely on the clean however so this will be removed when those drivers are updated.

Quoted 2 lines

NAK. There are patches around (and potentially queued) for the next merge window which properly address this.

Do you have any hints on who's doing the development ?

Quoted 4 lines · Daniel Walker

From: Larry Bassel <[email protected]>

This change improves the following LMBench benchmarks by over 15%:

Is this something that could be done in the platform initialisation code rather than the processor code? It's clearly not specific to all ARMv7 CPUs.

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Catalin Marinas
Sent: Tuesday, January 12, 2010 4:22 PM
To: Russell King - ARM Linux
Cc: Larry Bassel; Daniel Walker; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC 08/18] arm: msm: set L2CR1 to enable prefetch and burston Scorpion.

Quoted 9 lines · Russell King - ARM Linux

Quoted 4 lines · Daniel Walker

From: Larry Bassel <[email protected]>

This change improves the following LMBench benchmarks by over 15%:

Is this something that could be done in the platform initialisation code rather than the processor code? It's clearly not specific to all ARMv7 CPUs.

We discussed in the past but the thread died. There are various bits that may need to be enabled before the CPU is initialised but it is highly dependent on the hardware configuration and not only the CPU type. For example, Cortex-A8/A9 may have some bits in the ACTLR register which are fine to set on RealView but not on OMAP because the kernel there is running in non-secure mode. Now Scorpion has other needs.

Since such initialisation would run before the MMU is enabled, should we add an additional per-platform macro to be invoked before the CPU is set up? A pointer in the machine_desc structure to an asm routine would also work assuming that care is taken to calculate the phys address and the code is position independent.

An alternative would be to briefly enable the MMU for the initialisation (using a temporary page table) than disable it and switch to the proper one built via create_mapping(). This would allow some initialisation code to be written in C (though I'm not sure it's worth the effort).

We discussed in the past but the thread died. There are various bits that may need to be enabled before the CPU is initialised but it is highly dependent on the hardware configuration and not only the CPU type. For example, Cortex-A8/A9 may have some bits in the ACTLR register which are fine to set on RealView but not on OMAP because the kernel there is running in non-secure mode. Now Scorpion has other needs.

Since such initialisation would run before the MMU is enabled, should we add an additional per-platform macro to be invoked before the CPU is set up? A pointer in the machine_desc structure to an asm routine would also work assuming that care is taken to calculate the phys address and the code is position independent.

An alternative would be to briefly enable the MMU for the initialisation (using a temporary page table) than disable it and switch to the proper one built via create_mapping(). This would allow some initialisation code to be written in C (though I'm not sure it's worth the effort).

Quoted 7 lines · Catalin Marinas

We discussed in the past but the thread died. There are various bits that may need to be enabled before the CPU is initialised but it is highly dependent on the hardware configuration and not only the CPU type. For example, Cortex-A8/A9 may have some bits in the ACTLR register which are fine to set on RealView but not on OMAP because the kernel there is running in non-secure mode. Now Scorpion has other needs.

Quoted 5 lines

Since such initialisation would run before the MMU is enabled, should we add an additional per-platform macro to be invoked before the CPU is set up? A pointer in the machine_desc structure to an asm routine would also work assuming that care is taken to calculate the phys address and the code is position independent.

What you're asking for is bith platform and CPU dependent - which makes it much more difficult to generalize. It also throws a spanner in the works for the DT people.

Quoted 5 lines

An alternative would be to briefly enable the MMU for the initialisation (using a temporary page table) than disable it and switch to the proper one built via create_mapping(). This would allow some initialisation code to be written in C (though I'm not sure it's worth the effort).

How would that work? You're saying on one hand that there's initialization which needs to be done before the MMU is initialized, and in this paragraph you're saying it can be done while the MMU is initialized and enabled.

Actually, what you describe is what's already being done by the head.S code - we already build a temporary page table and enable the MMU so that we can get the C code running to setup the page tables properly.

It strikes me that things are just becoming excessively complicated with these seemingly "catch-22" issues. Maybe a totally different approach is needed - such as requiring some of this low level setup to be done by the platform's boot loader?

Quoted 3 lines · Russell King - ARM Linux

What you're asking for is bith platform and CPU dependent - which makes it much more difficult to generalize. It also throws a spanner in the works for the DT people.

If it would only be CPU dependent, we could just add some ID checking in proc-v*.S and but for some cases it's also platform dependent (like secure vs. non-secure vs. secure monitor API).

Quoted 5 lines

Quoted 4 lines

An alternative would be to briefly enable the MMU for the initialisation (using a temporary page table) than disable it and switch to the proper one built via create_mapping(). This would allow some initialisation code to be written in C (though I'm not sure it's worth the effort).

Quoted 3 lines

How would that work? You're saying on one hand that there's initialization which needs to be done before the MMU is initialized, and in this paragraph you're saying it can be done while the MMU is initialized and enabled.

Standard (architecture) MMU initialisation without additional optimisation bits (similar to what we have in the decompressor). It won't support SMP, shared page tables etc.

Quoted 3 lines

Actually, what you describe is what's already being done by the head.S code - we already build a temporary page table and enable the MMU so that we can get the C code running to setup the page tables properly.

Yes, that's the table I was referring to. It could be even made not to depend on CONFIG_SMP and always make it UP (no shared bit, this way it would be simpler to run SMP kernel on UP hardware by doing some checks later).

Quoted 9 lines · Catalin Marinas

Quoted 3 lines · Russell King - ARM Linux

Actually, what you describe is what's already being done by the head.S code - we already build a temporary page table and enable the MMU so that we can get the C code running to setup the page tables properly.

Yes, that's the table I was referring to. It could be even made not to depend on CONFIG_SMP and always make it UP (no shared bit, this way it would be simpler to run SMP kernel on UP hardware by doing some checks later).

From what I remember, there's a problem where the TTB flags don't match the memory which the page tables live in, so we had to make the two match - and it's not possible to change the TTB flags and the page tables simultaneously, certainly not without turning the MMU off, doing the modification and turning it back on again.

Quoted 4 lines

We still have things like the SMP/nAMP mode which is Cortex-A9 and ARM11MPCore specific. There is also the TLB ops broadcasting bit in ACTLR which is also specific to ARM Ltd cores and some of these bits may not be accessible directly if you run in non-secure mode.

If you're running in non-secure mode and the parts of the system you don't have access to haven't already been setup, you're running in a crippled environment - so this isn't really an argument.

Quoted 10 lines

Quoted 4 lines

It strikes me that things are just becoming excessively complicated with these seemingly "catch-22" issues. Maybe a totally different approach is needed - such as requiring some of this low level setup to be done by the platform's boot loader?

Ideally, yes, it would be nice if these were done by the boot loader. We would have to define some clear requirements or at least saying that Linux only touches the architectured registers and not the implementation defined ones. But I'm not sure how feasible this would be.

Unless we do something like this, we're going to end up with lots of bits of additional platform specific non-conditional assembly in the early kernel boot path.

Quoted 3 lines

There is also the CPU hotplug case where CPUs come back via the setup function and may need to touch bits like SMP/nAMP. This should work together with a boot monitor.

How does the CPU get back to the setup function? Is the hardware aware of the address of our setup function? I don't think so, so I don't buy this argument.

If the CPU is reset (eg, because power has been removed), it's going to want to start executing from the reset vector - which means it will come back to us via the boot loader.

My argument was that ACTLR is implementation-defined, so other cores like Scorpion may have a different meaning for such bits (Daniel's patches are probably held in the moderation queue, I only saw your replies).

Quoted 7 lines · Catalin Marinas

We discussed in the past but the thread died. There are various bits that may need to be enabled before the CPU is initialised but it is highly dependent on the hardware configuration and not only the CPU type. For example, Cortex-A8/A9 may have some bits in the ACTLR register which are fine to set on RealView but not on OMAP because the kernel there is running in non-secure mode. Now Scorpion has other needs.

Quoted 5 lines

Since such initialisation would run before the MMU is enabled, should we add an additional per-platform macro to be invoked before the CPU is set up? A pointer in the machine_desc structure to an asm routine would also work assuming that care is taken to calculate the phys address and the code is position independent.

What you're asking for is bith platform and CPU dependent - which makes it much more difficult to generalize. It also throws a spanner in the works for the DT people.

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Catalin Marinas
Sent: Tuesday, January 12, 2010 7:03 PM
To: Russell King - ARM Linux
Cc: Larry Bassel; Daniel Walker; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC 08/18] arm: msm: set L2CR1 to enable prefetch and burstonScorpion.

Quoted 14 lines · Russell King - ARM Linux

Quoted 7 lines · Catalin Marinas

We discussed in the past but the thread died. There are various bits that may need to be enabled before the CPU is initialised but it is highly dependent on the hardware configuration and not only the CPU type. For example, Cortex-A8/A9 may have some bits in the ACTLR register which are fine to set on RealView but not on OMAP because the kernel there is running in non-secure mode. Now Scorpion has other needs.

Quoted 5 lines

Since such initialisation would run before the MMU is enabled, should we add an additional per-platform macro to be invoked before the CPU is set up? A pointer in the machine_desc structure to an asm routine would also work assuming that care is taken to calculate the phys address and the code is position independent.

Quoted 3 lines

What you're asking for is bith platform and CPU dependent - which makes it much more difficult to generalize. It also throws a spanner in the works for the DT people.

If it would only be CPU dependent, we could just add some ID checking in proc-v*.S and but for some cases it's also platform dependent (like secure vs. non-secure vs. secure monitor API).

Quoted 9 lines

Quoted 5 lines

An alternative would be to briefly enable the MMU for the initialisation (using a temporary page table) than disable it and switch to the proper one built via create_mapping(). This would allow some initialisation code to be written in C (though I'm not sure it's worth the effort).

How would that work? You're saying on one hand that there's initialization which needs to be done before the MMU is initialized, and in this paragraph you're saying it can be done while the MMU is initialized and enabled.

Standard (architecture) MMU initialisation without additional optimisation bits (similar to what we have in the decompressor). It won't support SMP, shared page tables etc.

Quoted 3 lines

Actually, what you describe is what's already being done by the head.S code - we already build a temporary page table and enable the MMU so that we can get the C code running to setup the page tables properly.

Yes, that's the table I was referring to. It could be even made not to depend on CONFIG_SMP and always make it UP (no shared bit, this way it would be simpler to run SMP kernel on UP hardware by doing some checks later).

We still have things like the SMP/nAMP mode which is Cortex-A9 and ARM11MPCore specific. There is also the TLB ops broadcasting bit in ACTLR which is also specific to ARM Ltd cores and some of these bits may not be accessible directly if you run in non-secure mode.

Quoted 4 lines

It strikes me that things are just becoming excessively complicated with these seemingly "catch-22" issues. Maybe a totally different approach is needed - such as requiring some of this low level setup to be done by the platform's boot loader?

Ideally, yes, it would be nice if these were done by the boot loader. We would have to define some clear requirements or at least saying that Linux only touches the architectured registers and not the implementation defined ones. But I'm not sure how feasible this would be.

There is also the CPU hotplug case where CPUs come back via the setup function and may need to touch bits like SMP/nAMP. This should work together with a boot monitor.

Quoted 4 lines · Catalin Marinas

My argument was that ACTLR is implementation-defined, so other cores like Scorpion may have a different meaning for such bits (Daniel's patches are probably held in the moderation queue, I only saw your replies).

Yeah, they are being held for moderator approval ("Message has a suspicious header") .. I see a lot of other patchsets going through, does anyone have a location for the right method to submit a series to this list?

From: Steve Muckle <[email protected]>

The mask and ID pattern for older ARM IDs in the kernel decompressor matches the CPU ID for Scorpion, causing the v7 caching routines not to be run and kernel decompression to take significantly longer.

QSD may eventually use CPUs other than Scorpion, but they will adhere to the new ARM CPU ID format, which is incompatible with the entry for older ARM CPU IDs.

From: Steve Muckle <[email protected]>

(quoted diff) +7 -0

+static int
+do_imprecise_ext(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
+{
+#ifdef CONFIG_ARCH_MSM_SCORPION
+ ? ? ? unsigned int regval;
+ ? ? ? static unsigned char flush_toggle;
+

+ ? ? ? ? ? ? ? /* Clear fault in EFSR. */
+ ? ? ? ? ? ? ? asm("mcr p15, 7, %0, c15, c0, 1\n"
+ ? ? ? ? ? ? ? ? ? :
+ ? ? ? ? ? ? ? ? ? : "r" (regval));
+ ? ? ? ? ? ? ? /* Clear fault in ADFSR. */
+ ? ? ? ? ? ? ? regval = 0;
+ ? ? ? ? ? ? ? asm("mcr p15, 0, %0, c5, c1, 0\n"
+ ? ? ? ? ? ? ? ? ? :
+ ? ? ? ? ? ? ? ? ? : "r" (regval));
+ ? ? ? ? ? ? ? return 0;
+ ? ? ? }

(quoted diff) +2 -0

+#endif
+

Quoted 11 lines

(quoted diff) +11 -0

+static int
+do_imprecise_ext(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
+{
+#ifdef CONFIG_ARCH_MSM_SCORPION
+ ? ? ? unsigned int regval;
+ ? ? ? static unsigned char flush_toggle;
+
+ ? ? ? asm("mrc p15, 0, %0, c5, c1, 0\n" /* read adfsr for fault status */
+ ? ? ? ? ? : "=r" (regval));
+ ? ? ? if (regval == 0x2) {
+ ? ? ? ? ? ? ? /* Fault was caused by icache parity error. Alternate

Quoted 6 lines

+ ? ? ? ? ? ? ? ?* simply retrying the access and flushing the icache. */
+ ? ? ? ? ? ? ? flush_toggle ^= 1;
+ ? ? ? ? ? ? ? if (flush_toggle)
+ ? ? ? ? ? ? ? ? ? ? ? asm("mcr p15, 0, %0, c7, c5, 0\n"
+ ? ? ? ? ? ? ? ? ? ? ? ? ? :
+ ? ? ? ? ? ? ? ? ? ? ? ? ? : "r" (regval)); /* input value is ignored */

Wouldn't you need regval = 0 here, to clear the EFSR ?

Quoted 5 lines · Daniel Walker

From: Dave Estes <[email protected]>

Handle incorrectly reported permission faults for qsd8650. On permission faults, retry MVA to PA conversion. If retry detects translation fault. Report as translation fault.

This is totally unacceptable to add such a demanding copyright header to any file, imposing this notice upon pre-existing code. Please remove it.

From: Larry Bassel <[email protected]>

For 7x27 it is necessary to write to strongly ordered memory after executing the coprocessor 15 instruction dmb instruction.

This is only for data barrier dmb().
Note that the test for 7x27 is done on all MSM platforms (even ones such as 7201a whose kernel is distinct from that of 7x25/7x27).

Quoted 3 lines

	zero_page_strongly_ordered =
		ioremap_strongly_ordered(page_to_pfn(empty_zero_page)
		<< PAGE_SHIFT, PAGE_SIZE);

This can't work. You're not allowed to map the same memory with differing memory types from ARMv7. This ends up mapping 'empty_zero_page' as both cacheable memory and strongly ordered. That's illegal according to the ARM ARM.

You need to find something else to map - allocating a page of system memory for this won't work either (it'll have the same issue.)

Quoted 1 line

[alloc_bootmem_aligned]

Erm, there is __alloc_bootmem(size, align, 0) - the bootmem allocator already does alignment.

Notably:

(quoted diff) +3 -0

+Redistributions in source form must retain the above copyright notice, this
+list of conditions and the following disclaimer as the first lines of this
+file unmodified.

So nobody can add a title to the documentation, add another copyright year and name, convert it to Docbook, etc....?

For another file, I'm not sure that adding "All rights reserved" is ok. Under the GPL, all rights are _not_ reserved:

If you use Git, it has some options to send patches unthreaded (which I don't particularly like but that's a way around this problem; an alternative is to convince the moderator to remove this rule).

Everything I release will ultimately be licensed under the GPLv2 regardless of the license in the current files.. So it's just a matter of removing that old license ..

Quoted 2 lines

For another file, I'm not sure that adding "All rights reserved" is ok. Under the GPL, all rights are _not_ reserved:

This would be a problem because our lawyers mandate this.. AFAIK, it doesn't change the licensing tho.

Quoted 3 lines · Daniel Walker

Everything I release will ultimately be licensed under the GPLv2 regardless of the license in the current files.. So it's just a matter of removing that old license ..

Ok. Please do :-)

Quoted 5 lines

Quoted 2 lines

For another file, I'm not sure that adding "All rights reserved" is ok. Under the GPL, all rights are _not_ reserved:

This would be a problem because our lawyers mandate this.. AFAIK, it doesn't change the licensing tho.

If it doesn't change the license, why is it mandated?

Sounds like your lawyers aren't very familiar with open source licensing.

Quoted 4 lines · Russell King - ARM Linux

Quoted 3 lines

	zero_page_strongly_ordered =
		ioremap_strongly_ordered(page_to_pfn(empty_zero_page)
		<< PAGE_SHIFT, PAGE_SIZE);

Quoted 4 lines

This can't work. You're not allowed to map the same memory with differing memory types from ARMv7. This ends up mapping 'empty_zero_page' as both cacheable memory and strongly ordered. That's illegal according to the ARM ARM.

It's not an ARMv7, otherwise it wouldn't be using the mcr version of dmb(). Does that make the mapping ok, since it's been ok for years on < ARMv7? Or are we trying to get away from doing that on all ARMs?

Actually it is only used on two very specific CPUs. Perhaps it can be confirmed as Not A Problem(tm) on those, with a comment to say why it's ok in the mapping call?

Quoted 2 lines

You need to find something else to map - allocating a page of system memory for this won't work either (it'll have the same issue.)

Is strongly ordered RAM or even uncached RAM used at all for anything at the moment? It looks quite tricky to allocate a little RAM that never becomes part of the kernel direct mapping.

Quoted 3 lines · Daniel Walker

Everything I release will ultimately be licensed under the GPLv2 regardless of the license in the current files.. So it's just a matter of removing that old license ..

Ok. Please do :-)

Quoted 3 lines

Quoted 2 lines

For another file, I'm not sure that adding "All rights reserved" is ok. Under the GPL, all rights are _not_ reserved:

Quoted 2 lines

This would be a problem because our lawyers mandate this.. AFAIK, it doesn't change the licensing tho.

If it doesn't change the license, why is it mandated?

Sounds like your lawyers aren't very familiar with open source licensing.

Quoted 3 lines

It's not an ARMv7, otherwise it wouldn't be using the mcr version of dmb(). Does that make the mapping ok, since it's been ok for years on < ARMv7? Or are we trying to get away from doing that on all ARMs?

Technically, it also applies to ARMv6 as well.

Quoted 3 lines

Actually it is only used on two very specific CPUs. Perhaps it can be confirmed as Not A Problem(tm) on those, with a comment to say why it's ok in the mapping call?

The fact of the matter is that cache lines will be allocated for empty_zero_page. If this CPU is ARMv6 or ARMv7, with either an aliasing or non-aliasing VIPT cache, you will get cache lines allocated for this page which will overlap the strongly ordered mapping.

That in turn can turn the strongly ordered mapping into a cached mapping which is definitely not what you want.

If your CPU speculatively prefetches, and it prefetches some data via a cached mapping, the same thing can happen.

'Memory, uncached' is used for DMA mappings on ARMv7 and soon to be on ARMv6 as well to comply with the architecture requirements. Strongly ordered is used for a certain set of IOP3xx registers because that is what is stipulated in the device documentation.

What is expressly not permitted for ARMv7 (and ARMv6) is having two or more mappings of the same physical address with differing memory types or sharability settings.

(Technically, that extends to cacheability modes as well - but if ARM Ltd think that the kernel's going to comply with that, I think they're in cloud cuckoo land. Well, we could do _if_ (eg) ARM Ltd bring in hardware DMA coherency as a mandatory architecture requirement.)

Fair enough. Is it like this?

1. Data ends up in cache lines from access via the cached mapping.
2. Access via the strongly ordered mapping may still look at the cache, because it's easier that way and it's not supposed to have any data.
3. Cache effectively intercepts the access.
4. Bus does not see strongly ordered access.

Isn't the above sequence of events you described earlier even _more_ likely to occur when there are simultaneous cacheable and non-cacheable mappings?

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

Documentation/arm/msm/emulate_domain_manager.txt new file +0 -0

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

It doesn't require handling domain faults and works on SMP as well. Another advantage is that we can re-implement functions like copy_from_user etc. only using LDR/LDM rather than LDRT with some performance improvements.

Of course, being my patch, I'm pushing for it :-) but I think longer term is a better approach that the domains emulation. Any thoughts on this?

Quoted 8 lines · Daniel Walker

From: Larry Bassel <[email protected]>

Both the clean and invalidate functionality needed for the video encoder and 7x27 barrier code need to have a strongly ordered mapping set up so that one may perform a write to strongly ordered memory. The generic ARM code does not provide this.

Quoted 5 lines

The generic ARM code does provide MT_DEVICE, which starts as strongly ordered, but the code later turns the buffered flag on for ARMv6 in order to make the device shared. This is not suitable for my purpose, so this patch adds code for a MT_DEVICE_STRONGLY_ORDERED mapping type.

This doesn't really describe what "my purpose" is; the patch description is too vague to ascertain why this is required.

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

Quoted 12 lines · Catalin Marinas

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

Quoted 2 lines

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

I didn't find this in 2.6.34 ? Are you re-writing it? Why has it been around so long out of mainline?

Quoted 13 lines · Daniel Walker

Quoted 12 lines · Catalin Marinas

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

Quoted 5 lines

Quoted 2 lines

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

I didn't find this in 2.6.34 ? Are you re-writing it? Why has it been around so long out of mainline?

Because no real hardware out there needed it until recently, i.e. inertia.

Quoted 18 lines · Nicolas Pitre

Quoted 16 lines · Daniel Walker

Quoted 14 lines · Catalin Marinas

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

Quoted 5 lines

Quoted 2 lines

I didn't find this in 2.6.34 ? Are you re-writing it? Why has it been around so long out of mainline?

Because no real hardware out there needed it until recently, i.e. inertia.

Current MSM hardware needs it, just to cover up a defect in the processor. At least that's what this thread was originally about.

Quoted 25 lines · Daniel Walker

Quoted 23 lines · Nicolas Pitre

Quoted 13 lines · Daniel Walker

Quoted 12 lines · Catalin Marinas

Hi Daniel,

Quoted 3 lines · Daniel Walker

Do not set domain manager bits in cp15 dacr. Emulate using SW. Add kernel hooks to handle domain changes, permission faults, and context switches.

In case you were not aware, there's a patch around (I think since 2007) that removes the domain switching entirely from the kernel (given that they have been deprecated for some time and may disappear completely in the future):

Quoted 5 lines

Quoted 2 lines

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005616.html

I didn't find this in 2.6.34 ? Are you re-writing it? Why has it been around so long out of mainline?

Because no real hardware out there needed it until recently, i.e. inertia.

Quoted 2 lines

Current MSM hardware needs it, just to cover up a defect in the processor. At least that's what this thread was originally about.

Some other processors should need it too for some architecturally defined reasons. Would be a good thing if you could remove your emulation and replace it with this patch, and confirm it works for you by providing Tested-by tags.