* [PULL] Add support for Texas Instruments C6X architecture
@ 2011-11-01 20:27 Mark Salter
2011-11-05 1:23 ` Linus Torvalds
0 siblings, 1 reply; 9+ messages in thread
From: Mark Salter @ 2011-11-01 20:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Hi Linus,
Please pull this port of Linux to the Texas Instruments C6X architecture.
The patches have all been acked and available for some time in linux-net.
The top commit has a signed tag: for-linus-3.2-merge-window
The following changes since commit 3ee72ca99288f1de95ec9c570e43f531c8799f06:
Merge git://github.com/davem330/net (2011-10-06 16:15:10 -0700)
are available in the git repository at:
git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git for-linux-next
Aurelien Jacquiot (14):
C6X: build infrastructure
C6X: early boot code
C6X: memory management and DMA support
C6X: process management
C6X: signal management
C6X: time management
C6X: interrupt handling
C6X: syscalls
C6X: build infrastructure
C6X: cache control
C6X: loadable module support
C6X: ptrace support
C6X: headers
C6X: library code
Mark Salter (10):
fix default __strnlen_user macro
fixed generic page.h for non-zero PAGE_OFFSET
add ELF machine define for TI C6X DSPs
add missing __iomem to generic iounmap declaration
C6X: devicetree support
C6X: clocks
C6X: general SoC support
C6X: EMIF - External Memory Interface
C6X: DSCR - Device State Configuration Registers
C6X: MAINTAINERS
Documentation/devicetree/bindings/c6x/clocks.txt | 40 +
Documentation/devicetree/bindings/c6x/dscr.txt | 127 +++
Documentation/devicetree/bindings/c6x/emifa.txt | 62 ++
.../devicetree/bindings/c6x/interrupt.txt | 104 +++
Documentation/devicetree/bindings/c6x/soc.txt | 28 +
Documentation/devicetree/bindings/c6x/timer64.txt | 26 +
MAINTAINERS | 8 +
arch/c6x/Kconfig | 174 +++++
arch/c6x/Makefile | 60 ++
arch/c6x/boot/Makefile | 30 +
arch/c6x/boot/dts/dsk6455.dts | 62 ++
arch/c6x/boot/dts/evmc6457.dts | 48 ++
arch/c6x/boot/dts/evmc6472.dts | 73 ++
arch/c6x/boot/dts/evmc6474.dts | 58 ++
arch/c6x/boot/dts/tms320c6455.dtsi | 96 +++
arch/c6x/boot/dts/tms320c6457.dtsi | 68 ++
arch/c6x/boot/dts/tms320c6472.dtsi | 134 ++++
arch/c6x/boot/dts/tms320c6474.dtsi | 89 +++
arch/c6x/boot/linked_dtb.S | 2 +
arch/c6x/configs/dsk6455_defconfig | 44 ++
arch/c6x/configs/evmc6457_defconfig | 41 +
arch/c6x/configs/evmc6472_defconfig | 42 +
arch/c6x/configs/evmc6474_defconfig | 42 +
arch/c6x/include/asm/Kbuild | 54 ++
arch/c6x/include/asm/asm-offsets.h | 1 +
arch/c6x/include/asm/bitops.h | 105 +++
arch/c6x/include/asm/byteorder.h | 12 +
arch/c6x/include/asm/cache.h | 90 +++
arch/c6x/include/asm/cacheflush.h | 65 ++
arch/c6x/include/asm/checksum.h | 34 +
arch/c6x/include/asm/clkdev.h | 22 +
arch/c6x/include/asm/clock.h | 148 ++++
arch/c6x/include/asm/delay.h | 67 ++
arch/c6x/include/asm/dma-mapping.h | 91 +++
arch/c6x/include/asm/dscr.h | 34 +
arch/c6x/include/asm/elf.h | 113 +++
arch/c6x/include/asm/ftrace.h | 6 +
arch/c6x/include/asm/hardirq.h | 20 +
arch/c6x/include/asm/irq.h | 302 ++++++++
arch/c6x/include/asm/irqflags.h | 72 ++
arch/c6x/include/asm/linkage.h | 30 +
arch/c6x/include/asm/megamod-pic.h | 9 +
arch/c6x/include/asm/memblock.h | 4 +
arch/c6x/include/asm/mmu.h | 18 +
arch/c6x/include/asm/module.h | 33 +
arch/c6x/include/asm/mutex.h | 6 +
arch/c6x/include/asm/page.h | 11 +
arch/c6x/include/asm/pgtable.h | 81 ++
arch/c6x/include/asm/processor.h | 132 ++++
arch/c6x/include/asm/procinfo.h | 28 +
arch/c6x/include/asm/prom.h | 1 +
arch/c6x/include/asm/ptrace.h | 174 +++++
arch/c6x/include/asm/sections.h | 12 +
arch/c6x/include/asm/setup.h | 32 +
arch/c6x/include/asm/sigcontext.h | 80 ++
arch/c6x/include/asm/signal.h | 17 +
arch/c6x/include/asm/soc.h | 35 +
arch/c6x/include/asm/string.h | 21 +
arch/c6x/include/asm/swab.h | 54 ++
arch/c6x/include/asm/syscall.h | 123 +++
arch/c6x/include/asm/syscalls.h | 55 ++
arch/c6x/include/asm/system.h | 168 ++++
arch/c6x/include/asm/thread_info.h | 121 +++
arch/c6x/include/asm/timer64.h | 6 +
arch/c6x/include/asm/timex.h | 33 +
arch/c6x/include/asm/tlb.h | 8 +
arch/c6x/include/asm/traps.h | 36 +
arch/c6x/include/asm/uaccess.h | 107 +++
arch/c6x/include/asm/unaligned.h | 170 +++++
arch/c6x/include/asm/unistd.h | 26 +
arch/c6x/kernel/Makefile | 12 +
arch/c6x/kernel/asm-offsets.c | 123 +++
arch/c6x/kernel/c6x_ksyms.c | 66 ++
arch/c6x/kernel/devicetree.c | 53 ++
arch/c6x/kernel/dma.c | 153 ++++
arch/c6x/kernel/entry.S | 803 ++++++++++++++++++++
arch/c6x/kernel/head.S | 84 ++
arch/c6x/kernel/irq.c | 728 ++++++++++++++++++
arch/c6x/kernel/module.c | 123 +++
arch/c6x/kernel/process.c | 263 +++++++
arch/c6x/kernel/ptrace.c | 187 +++++
arch/c6x/kernel/setup.c | 498 ++++++++++++
arch/c6x/kernel/signal.c | 377 +++++++++
arch/c6x/kernel/soc.c | 91 +++
arch/c6x/kernel/switch_to.S | 74 ++
arch/c6x/kernel/sys_c6x.c | 74 ++
arch/c6x/kernel/time.c | 65 ++
arch/c6x/kernel/traps.c | 423 ++++++++++
arch/c6x/kernel/vectors.S | 81 ++
arch/c6x/kernel/vmlinux.lds.S | 162 ++++
arch/c6x/lib/Makefile | 7 +
arch/c6x/lib/checksum.c | 36 +
arch/c6x/lib/csum_64plus.S | 419 ++++++++++
arch/c6x/lib/divi.S | 53 ++
arch/c6x/lib/divremi.S | 46 ++
arch/c6x/lib/divremu.S | 87 +++
arch/c6x/lib/divu.S | 98 +++
arch/c6x/lib/llshl.S | 37 +
arch/c6x/lib/llshr.S | 38 +
arch/c6x/lib/llshru.S | 38 +
arch/c6x/lib/memcpy_64plus.S | 46 ++
arch/c6x/lib/mpyll.S | 49 ++
arch/c6x/lib/negll.S | 31 +
arch/c6x/lib/pop_rts.S | 32 +
arch/c6x/lib/push_rts.S | 31 +
arch/c6x/lib/remi.S | 64 ++
arch/c6x/lib/remu.S | 82 ++
arch/c6x/lib/strasgi.S | 89 +++
arch/c6x/lib/strasgi_64plus.S | 39 +
arch/c6x/mm/Makefile | 5 +
arch/c6x/mm/dma-coherent.c | 143 ++++
arch/c6x/mm/init.c | 113 +++
arch/c6x/platforms/Kconfig | 16 +
arch/c6x/platforms/Makefile | 12 +
arch/c6x/platforms/cache.c | 445 +++++++++++
arch/c6x/platforms/dscr.c | 598 +++++++++++++++
arch/c6x/platforms/emif.c | 88 +++
arch/c6x/platforms/megamod-pic.c | 349 +++++++++
arch/c6x/platforms/platform.c | 17 +
arch/c6x/platforms/pll.c | 444 +++++++++++
arch/c6x/platforms/plldata.c | 404 ++++++++++
arch/c6x/platforms/timer64.c | 236 ++++++
include/asm-generic/io.h | 2 +-
include/asm-generic/page.h | 10 +-
include/asm-generic/uaccess.h | 7 +-
include/linux/elf-em.h | 1 +
126 files changed, 12972 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/c6x/clocks.txt
create mode 100644 Documentation/devicetree/bindings/c6x/dscr.txt
create mode 100644 Documentation/devicetree/bindings/c6x/emifa.txt
create mode 100644 Documentation/devicetree/bindings/c6x/interrupt.txt
create mode 100644 Documentation/devicetree/bindings/c6x/soc.txt
create mode 100644 Documentation/devicetree/bindings/c6x/timer64.txt
create mode 100644 arch/c6x/Kconfig
create mode 100644 arch/c6x/Makefile
create mode 100644 arch/c6x/boot/Makefile
create mode 100644 arch/c6x/boot/dts/dsk6455.dts
create mode 100644 arch/c6x/boot/dts/evmc6457.dts
create mode 100644 arch/c6x/boot/dts/evmc6472.dts
create mode 100644 arch/c6x/boot/dts/evmc6474.dts
create mode 100644 arch/c6x/boot/dts/tms320c6455.dtsi
create mode 100644 arch/c6x/boot/dts/tms320c6457.dtsi
create mode 100644 arch/c6x/boot/dts/tms320c6472.dtsi
create mode 100644 arch/c6x/boot/dts/tms320c6474.dtsi
create mode 100644 arch/c6x/boot/linked_dtb.S
create mode 100644 arch/c6x/configs/dsk6455_defconfig
create mode 100644 arch/c6x/configs/evmc6457_defconfig
create mode 100644 arch/c6x/configs/evmc6472_defconfig
create mode 100644 arch/c6x/configs/evmc6474_defconfig
create mode 100644 arch/c6x/include/asm/Kbuild
create mode 100644 arch/c6x/include/asm/asm-offsets.h
create mode 100644 arch/c6x/include/asm/bitops.h
create mode 100644 arch/c6x/include/asm/byteorder.h
create mode 100644 arch/c6x/include/asm/cache.h
create mode 100644 arch/c6x/include/asm/cacheflush.h
create mode 100644 arch/c6x/include/asm/checksum.h
create mode 100644 arch/c6x/include/asm/clkdev.h
create mode 100644 arch/c6x/include/asm/clock.h
create mode 100644 arch/c6x/include/asm/delay.h
create mode 100644 arch/c6x/include/asm/dma-mapping.h
create mode 100644 arch/c6x/include/asm/dscr.h
create mode 100644 arch/c6x/include/asm/elf.h
create mode 100644 arch/c6x/include/asm/ftrace.h
create mode 100644 arch/c6x/include/asm/hardirq.h
create mode 100644 arch/c6x/include/asm/irq.h
create mode 100644 arch/c6x/include/asm/irqflags.h
create mode 100644 arch/c6x/include/asm/linkage.h
create mode 100644 arch/c6x/include/asm/megamod-pic.h
create mode 100644 arch/c6x/include/asm/memblock.h
create mode 100644 arch/c6x/include/asm/mmu.h
create mode 100644 arch/c6x/include/asm/module.h
create mode 100644 arch/c6x/include/asm/mutex.h
create mode 100644 arch/c6x/include/asm/page.h
create mode 100644 arch/c6x/include/asm/pgtable.h
create mode 100644 arch/c6x/include/asm/processor.h
create mode 100644 arch/c6x/include/asm/procinfo.h
create mode 100644 arch/c6x/include/asm/prom.h
create mode 100644 arch/c6x/include/asm/ptrace.h
create mode 100644 arch/c6x/include/asm/sections.h
create mode 100644 arch/c6x/include/asm/setup.h
create mode 100644 arch/c6x/include/asm/sigcontext.h
create mode 100644 arch/c6x/include/asm/signal.h
create mode 100644 arch/c6x/include/asm/soc.h
create mode 100644 arch/c6x/include/asm/string.h
create mode 100644 arch/c6x/include/asm/swab.h
create mode 100644 arch/c6x/include/asm/syscall.h
create mode 100644 arch/c6x/include/asm/syscalls.h
create mode 100644 arch/c6x/include/asm/system.h
create mode 100644 arch/c6x/include/asm/thread_info.h
create mode 100644 arch/c6x/include/asm/timer64.h
create mode 100644 arch/c6x/include/asm/timex.h
create mode 100644 arch/c6x/include/asm/tlb.h
create mode 100644 arch/c6x/include/asm/traps.h
create mode 100644 arch/c6x/include/asm/uaccess.h
create mode 100644 arch/c6x/include/asm/unaligned.h
create mode 100644 arch/c6x/include/asm/unistd.h
create mode 100644 arch/c6x/kernel/Makefile
create mode 100644 arch/c6x/kernel/asm-offsets.c
create mode 100644 arch/c6x/kernel/c6x_ksyms.c
create mode 100644 arch/c6x/kernel/devicetree.c
create mode 100644 arch/c6x/kernel/dma.c
create mode 100644 arch/c6x/kernel/entry.S
create mode 100644 arch/c6x/kernel/head.S
create mode 100644 arch/c6x/kernel/irq.c
create mode 100644 arch/c6x/kernel/module.c
create mode 100644 arch/c6x/kernel/process.c
create mode 100644 arch/c6x/kernel/ptrace.c
create mode 100644 arch/c6x/kernel/setup.c
create mode 100644 arch/c6x/kernel/signal.c
create mode 100644 arch/c6x/kernel/soc.c
create mode 100644 arch/c6x/kernel/switch_to.S
create mode 100644 arch/c6x/kernel/sys_c6x.c
create mode 100644 arch/c6x/kernel/time.c
create mode 100644 arch/c6x/kernel/traps.c
create mode 100644 arch/c6x/kernel/vectors.S
create mode 100644 arch/c6x/kernel/vmlinux.lds.S
create mode 100644 arch/c6x/lib/Makefile
create mode 100644 arch/c6x/lib/checksum.c
create mode 100644 arch/c6x/lib/csum_64plus.S
create mode 100644 arch/c6x/lib/divi.S
create mode 100644 arch/c6x/lib/divremi.S
create mode 100644 arch/c6x/lib/divremu.S
create mode 100644 arch/c6x/lib/divu.S
create mode 100644 arch/c6x/lib/llshl.S
create mode 100644 arch/c6x/lib/llshr.S
create mode 100644 arch/c6x/lib/llshru.S
create mode 100644 arch/c6x/lib/memcpy_64plus.S
create mode 100644 arch/c6x/lib/mpyll.S
create mode 100644 arch/c6x/lib/negll.S
create mode 100644 arch/c6x/lib/pop_rts.S
create mode 100644 arch/c6x/lib/push_rts.S
create mode 100644 arch/c6x/lib/remi.S
create mode 100644 arch/c6x/lib/remu.S
create mode 100644 arch/c6x/lib/strasgi.S
create mode 100644 arch/c6x/lib/strasgi_64plus.S
create mode 100644 arch/c6x/mm/Makefile
create mode 100644 arch/c6x/mm/dma-coherent.c
create mode 100644 arch/c6x/mm/init.c
create mode 100644 arch/c6x/platforms/Kconfig
create mode 100644 arch/c6x/platforms/Makefile
create mode 100644 arch/c6x/platforms/cache.c
create mode 100644 arch/c6x/platforms/dscr.c
create mode 100644 arch/c6x/platforms/emif.c
create mode 100644 arch/c6x/platforms/megamod-pic.c
create mode 100644 arch/c6x/platforms/platform.c
create mode 100644 arch/c6x/platforms/pll.c
create mode 100644 arch/c6x/platforms/plldata.c
create mode 100644 arch/c6x/platforms/timer64.c
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-01 20:27 [PULL] Add support for Texas Instruments C6X architecture Mark Salter
@ 2011-11-05 1:23 ` Linus Torvalds
2011-11-05 21:39 ` Mark Salter
0 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2011-11-05 1:23 UTC (permalink / raw)
To: Mark Salter; +Cc: linux-kernel
On Tue, Nov 1, 2011 at 1:27 PM, Mark Salter <msalter@redhat.com> wrote:
>
> Please pull this port of Linux to the Texas Instruments C6X architecture.
> The patches have all been acked and available for some time in linux-net.
Ugh. So I finally was about to merge this, but wanted to check the
non-C6x files before I did.
And that seems broken. If I read that code correctly, your
ARCH_PFN_OFFSET thing is just insane, and thinking that "pfn_valid()"
has anything to do with PAGE_OFFSET is crazy.
PAGE_OFFSET is about *virtual* addresses. It has absolutely nothing to
do with pfn's that are the physical page number. virt_to_pfn() already
corrects for PAGE_OFFSET (that part of your patch looks fine), your
change to *also* do it in pfn_valid() looks entirely bogus to me.
I'm not pulling new architectures that look like they will break old
ones, and do odd things to generic files.
Linus
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-05 1:23 ` Linus Torvalds
@ 2011-11-05 21:39 ` Mark Salter
2011-11-05 22:38 ` Linus Torvalds
0 siblings, 1 reply; 9+ messages in thread
From: Mark Salter @ 2011-11-05 21:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
On Fri, 2011-11-04 at 18:23 -0700, Linus Torvalds wrote:
> On Tue, Nov 1, 2011 at 1:27 PM, Mark Salter <msalter@redhat.com> wrote:
> >
> > Please pull this port of Linux to the Texas Instruments C6X architecture.
> > The patches have all been acked and available for some time in linux-net.
>
> Ugh. So I finally was about to merge this, but wanted to check the
> non-C6x files before I did.
>
> And that seems broken. If I read that code correctly, your
> ARCH_PFN_OFFSET thing is just insane, and thinking that "pfn_valid()"
> has anything to do with PAGE_OFFSET is crazy.
>
> PAGE_OFFSET is about *virtual* addresses. It has absolutely nothing to
> do with pfn's that are the physical page number. virt_to_pfn() already
> corrects for PAGE_OFFSET (that part of your patch looks fine), your
> change to *also* do it in pfn_valid() looks entirely bogus to me.
>
> I'm not pulling new architectures that look like they will break old
> ones, and do odd things to generic files.
Okay, first of all, it doesn't break any old ones. There is one arch
that currently uses asm-generic/page.h (blackfin) and that one uses a
PAGE_OFFSET of 0x0 and has physical RAM starting at 0x0. My patch (wrong
as it may otherwise be) won't break blackfin.
Are you saying that PAGE_OFFSET should always be zero in the NOMMU case?
Or that ARCH_PFN_OFFSET shouldn't use PAGE_OFFSET (five existing arches
use that same definition)?
If PAGE_OFFSET should be zero for NOMMU, then the existing generic
page.h is wrong to use CONFIG_KERNEL_RAM_BASE_ADDRESS. Also,
free_area_init() in mm/page_alloc.c uses __pa(PAGE_OFFSET) which
seems wrong and is definitely broken in the NOMMU case if PAGE_OFFSET
must be zero on an arch where the RAM base is non-zero.
So what do I need to do to get this straightened out?
--Mark
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-05 21:39 ` Mark Salter
@ 2011-11-05 22:38 ` Linus Torvalds
2011-11-06 15:24 ` Mark Salter
2011-11-08 18:08 ` Mark Salter
0 siblings, 2 replies; 9+ messages in thread
From: Linus Torvalds @ 2011-11-05 22:38 UTC (permalink / raw)
To: Mark Salter; +Cc: linux-kernel
On Sat, Nov 5, 2011 at 2:39 PM, Mark Salter <msalter@redhat.com> wrote:
>
> Okay, first of all, it doesn't break any old ones. There is one arch
> that currently uses asm-generic/page.h (blackfin) and that one uses a
> PAGE_OFFSET of 0x0 and has physical RAM starting at 0x0. My patch (wrong
> as it may otherwise be) won't break blackfin.
Ok. And I didn't notice that when you added the PFN_OFFSET, you did
actually remove the subtraction of PAGE_OFFSET from the
virtual->physical translation.
But I don't really understand why you did that. It makes very little sense.
> Are you saying that PAGE_OFFSET should always be zero in the NOMMU case?
> Or that ARCH_PFN_OFFSET shouldn't use PAGE_OFFSET (five existing arches
> use that same definition)?
So If the memory is mapped at some non-zero offset, what would make
*sense* to me is have the old
#define __pa(x) ((unsigned long)(x) -- PAGE_OFFSET)
and that should already make sure that then the PFN is in the right
range, and doesn't need any fixups.
That's what the old version of the file did, and that seems to be a
sensible model. Why isn't it?
Linus
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-05 22:38 ` Linus Torvalds
@ 2011-11-06 15:24 ` Mark Salter
2011-11-06 19:07 ` Linus Torvalds
2011-11-08 18:08 ` Mark Salter
1 sibling, 1 reply; 9+ messages in thread
From: Mark Salter @ 2011-11-06 15:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
On Sat, 2011-11-05 at 15:38 -0700, Linus Torvalds wrote:
> On Sat, Nov 5, 2011 at 2:39 PM, Mark Salter <msalter@redhat.com> wrote:
> >
> > Okay, first of all, it doesn't break any old ones. There is one arch
> > that currently uses asm-generic/page.h (blackfin) and that one uses a
> > PAGE_OFFSET of 0x0 and has physical RAM starting at 0x0. My patch (wrong
> > as it may otherwise be) won't break blackfin.
>
> Ok. And I didn't notice that when you added the PFN_OFFSET, you did
> actually remove the subtraction of PAGE_OFFSET from the
> virtual->physical translation.
>
> But I don't really understand why you did that. It makes very little sense.
>
> > Are you saying that PAGE_OFFSET should always be zero in the NOMMU case?
> > Or that ARCH_PFN_OFFSET shouldn't use PAGE_OFFSET (five existing arches
> > use that same definition)?
>
> So If the memory is mapped at some non-zero offset, what would make
> *sense* to me is have the old
>
> #define __pa(x) ((unsigned long)(x) -- PAGE_OFFSET)
>
> and that should already make sure that then the PFN is in the right
> range, and doesn't need any fixups.
>
> That's what the old version of the file did, and that seems to be a
> sensible model. Why isn't it?
>
I think the best counter argument is that it leads to paddr != vaddr
in the case of NOMMU with a non-zero memory base. My view is that in
all NOMMU cases, physical and virtual addresses should be the same.
Otherwise, you end up breaking drivers which need to pass physical
addresses to devices.
Additionally, I think it is perfectly reasonable to have a non-zero
PAGE_OFFSET in the NOMMU case. PAGE_OFFSET is the base of kernel
virtual memory and in the NOMMU case this would match the physical
base of RAM which may be non-zero.
As for PFNs, there seems to be a number of places in the kernel where
the assumption is that PADDR == (PFN << PAGE_SHIFT). For this to hold
true, PFNs cannot be zero-based if RAM is physically based at a non-zero
address. Non zero-based PFNs is what ARCH_PFN_OFFSET is all about. Even
in the MMU case, PFNs are non zero-based for arm, mips, and a few
others. That's how I ended up with ARCH_PFN_OFFSET in the generic
definition of pfn_valid().
After thinking about it some more, the only thing I'd change in that
patch would be the default ARCH_PFN_OFFSET definition. It should either
default to (0), in which case arches would have to define their own, or
I'd use __pa(PAGE_OFFSET) instead of just PAGE_OFFSET so that it is
clear that it is dealing with a physical address.
--Mark
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-06 15:24 ` Mark Salter
@ 2011-11-06 19:07 ` Linus Torvalds
2011-11-06 20:05 ` Mark Salter
0 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2011-11-06 19:07 UTC (permalink / raw)
To: Mark Salter; +Cc: linux-kernel, Arnd Bergmann
On Sun, Nov 6, 2011 at 7:24 AM, Mark Salter <msalter@redhat.com> wrote:
>
> I think the best counter argument is that it leads to paddr != vaddr
> in the case of NOMMU with a non-zero memory base. My view is that in
> all NOMMU cases, physical and virtual addresses should be the same.
> Otherwise, you end up breaking drivers which need to pass physical
> addresses to devices.
That's a totally insane argument.
Quite frankly, if this is what things rest on, I really *really* don't
want to take the change.
It's a broken argument. It's stupid.
AND IT ISN'T EVEN TRUE!
The "device view" of memory need not at all be the same as the CPU
view, and that has absolutely nothing to do with CPU MMU remapping.
There is a very good reason why we consider "virtual" != "physical" !=
"bus dma" address, and it's very simple: they aren't the same things
at all.
I think some 32-bit PowerPC chips, for example, will see "physical
address zero" at zero (for the CPU), but the devices on the PCI bus
consider "address zero" to be the PCI memory mapping. The devices see
physical RAM starting at DMA address 0x80000000, while for the CPU,
thats's where PCI MMIO lives.
Dammit, if a driver needs to pass a DMA address, that driver will
absolutely need to translate virtual (*or* physical) addresses to
"bus" addresses. End of story. Trying to even *imply* anything else is
pure and utter garbage, and saying that virtual addresses have to
match physical ones in order to not break drivers is drivel that I am
not at all interested in hearing.
Of course, reality is even more complicated than that, and the "bus
address" may well depend on the particular bus the device lives on. So
these days we don't even really encourage the simple mappings like
"virt_to_bus()" any more, we use bus-specific DMA helper functions to
allocate and map the DMA addresses
I suggest you sit down with some other embedded developers and think
about it, and if you all can come up with a good argument for why
things should work a particular way, we can do it that way (regardless
of what that way is). The PowerPC people have seen all the craziness
there is, they would be good to talk to. They also tend to have some
of the more complicated setups.
I'm not saying that <asm-generic/page.h> should necessarily be the
most generic and complicated model out there (perhaps the reverse -
complicated models can use their own arch-specific ones), but I do
think that it should *not* be based on broken assumptions like "dma ==
physical == virtual" address, and encourage a model where simple
architectures don't need any mapping at all. Because that is NOT TRUE,
and has nothing to do with MMU or not-MMU.
So right now I'm not going to merge this, especially when the
arguments for the change are not ones I consider
to be even remotely valid.
And my gut feel is that architectures should *aim* at "pfn's" starting
basically at zero. I'm not saying it's a requirement, and I can be
convinced otherwise, but you should strive to think of pfn's as
"physical page indexes". If memory fundamentally starts at some
specific offset, and there cannot be RAM below that offset, then my
gut feel is that the right define for virt_to_pfn() on such an
architecture would be to subtract the offset and then shift by the
page size.
(Btw, that's not what PPC32 does - it has some "MEMORY_START" logic
which is actually fairly complex. Maybe they had reasons for their
choice, and maybe they are historical. But I want more discussion
about what the "asm-generic/page.h" implementation should be, and I
think the C6x changes are counter-intuitive)
Linus
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-06 19:07 ` Linus Torvalds
@ 2011-11-06 20:05 ` Mark Salter
0 siblings, 0 replies; 9+ messages in thread
From: Mark Salter @ 2011-11-06 20:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Arnd Bergmann
On Sun, 2011-11-06 at 11:07 -0800, Linus Torvalds wrote:
> >
> > I think the best counter argument is that it leads to paddr != vaddr
> > in the case of NOMMU with a non-zero memory base. My view is that in
> > all NOMMU cases, physical and virtual addresses should be the same.
> > Otherwise, you end up breaking drivers which need to pass physical
> > addresses to devices.
>
> That's a totally insane argument.
Not *totally* insane. Forget the last sentence. You're right that its a
driver problem. Creating a physical address space separate from the
"virtual" space on a NOMMU arch where the hw uses a one-to-one mapping
seems a long way to go. My point here is that the simplest NOMMU case is
paddr == vaddr. Right now, the generic headers are broken in that regard
for hardware that maps RAM at a non-zero address.
So, okay. Let's have some more discussion among more people. There is
certainly more than one approach to fix the currently broken bits and I
sure don't claim to have the one true way. I just want to do what needs
to be done to make the port acceptable for upstream inclusion.
--Mark
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-05 22:38 ` Linus Torvalds
2011-11-06 15:24 ` Mark Salter
@ 2011-11-08 18:08 ` Mark Salter
2011-11-08 19:03 ` Linus Torvalds
1 sibling, 1 reply; 9+ messages in thread
From: Mark Salter @ 2011-11-08 18:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, JACQUIOT-XID, Aurelien, Arnd Bergmann
On Sat, 2011-11-05 at 15:38 -0700, Linus Torvalds wrote:
> On Sat, Nov 5, 2011 at 2:39 PM, Mark Salter <msalter@redhat.com> wrote:
> >
> > Okay, first of all, it doesn't break any old ones. There is one arch
> > that currently uses asm-generic/page.h (blackfin) and that one uses a
> > PAGE_OFFSET of 0x0 and has physical RAM starting at 0x0. My patch (wrong
> > as it may otherwise be) won't break blackfin.
>
> Ok. And I didn't notice that when you added the PFN_OFFSET, you did
> actually remove the subtraction of PAGE_OFFSET from the
> virtual->physical translation.
>
> But I don't really understand why you did that. It makes very little sense.
>
> > Are you saying that PAGE_OFFSET should always be zero in the NOMMU case?
> > Or that ARCH_PFN_OFFSET shouldn't use PAGE_OFFSET (five existing arches
> > use that same definition)?
>
> So If the memory is mapped at some non-zero offset, what would make
> *sense* to me is have the old
>
> #define __pa(x) ((unsigned long)(x) -- PAGE_OFFSET)
>
> and that should already make sure that then the PFN is in the right
> range, and doesn't need any fixups.
>
> That's what the old version of the file did, and that seems to be a
> sensible model. Why isn't it?
>
Having a little time to think about this some more, I'm going to take
another crack at it. Defining __pa/__va with PAGE_OFFSET as they are
currently creates a physical space which doesn't match the hardware
when PAGE_OFFSET is non-zero.
For arches using device tree support, that means that the physical
addresses in the device tree are either linux-specific or early boot
code would have to go through the tree to fixup the "hardware physical"
addresses so that they are "linux physical" addresses for the kernel.
For arches not using device tree, the physical addresses used in headers
or printed out in log messages won't match the hardware documentation.
Not a huge problem, but a PITA for maintenance/debug.
--Mark
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] Add support for Texas Instruments C6X architecture
2011-11-08 18:08 ` Mark Salter
@ 2011-11-08 19:03 ` Linus Torvalds
0 siblings, 0 replies; 9+ messages in thread
From: Linus Torvalds @ 2011-11-08 19:03 UTC (permalink / raw)
To: Mark Salter; +Cc: linux-kernel, JACQUIOT-XID, Aurelien, Arnd Bergmann
On Tue, Nov 8, 2011 at 10:08 AM, Mark Salter <msalter@redhat.com> wrote:
>
> Having a little time to think about this some more, I'm going to take
> another crack at it. Defining __pa/__va with PAGE_OFFSET as they are
> currently creates a physical space which doesn't match the hardware
> when PAGE_OFFSET is non-zero.
>
> For arches using device tree support, that means that the physical
> addresses in the device tree are either linux-specific or early boot
> code would have to go through the tree to fixup the "hardware physical"
> addresses so that they are "linux physical" addresses for the kernel.
Ok, that's actually a good argument - external interfaces defining
what "physical" means.
Fair enough. I'll consider myself convinced.
Linus
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-11-08 19:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-01 20:27 [PULL] Add support for Texas Instruments C6X architecture Mark Salter
2011-11-05 1:23 ` Linus Torvalds
2011-11-05 21:39 ` Mark Salter
2011-11-05 22:38 ` Linus Torvalds
2011-11-06 15:24 ` Mark Salter
2011-11-06 19:07 ` Linus Torvalds
2011-11-06 20:05 ` Mark Salter
2011-11-08 18:08 ` Mark Salter
2011-11-08 19:03 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox