1. 26 9月, 2011 1 次提交
  2. 20 4月, 2011 1 次提交
  3. 22 6月, 2010 2 次提交
  4. 07 5月, 2010 1 次提交
  5. 26 8月, 2009 2 次提交
    • H
      davinci: Move IO device mapping macros from io.h to hardware.h · 9eb7115b
      Hemant Pedanekar 提交于
      This patch takes out IO mapping macros from mach/io.h and puts them in
      mach/hardware.h avoiding need to include mach/io.h in various files such as
      serial.h, vmalloc.h etc.
      
      The main reason to avoid inclusion of mach/io.h is, when default in/out macros
      are overridden by machine specific functions (e.g., in case of PCI I/O), they
      result into linker error. An example snippet and error snapshot is listed below.
      
      Following code in mach/io.h:
      
      	#define inl(p)  my_inl()
      
      	static inline unsigned int my_inl(unsigned int addr)
      	{
      		if (IS_PCI_IO(addr))
      			return pci_inl ();
      		else
      			return le32_to_cpu(__raw_readl(__typesafe_io(addr)));
      	}
      
      leads to error:
      	LD      arch/arm/boot/compressed/vmlinux
      	arch/arm/boot/compressed/misc.o: In function `my_inl':
      	misc.c:(.text+0x2744): undefined reference to `pci_inl'
      	make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1
      
      This is because mach/io.h gets included in arch/arm/boot/compressed/misc.c
      through mach/serial.h but pci.c file, which defines 'pci_inl' doesn't get built
      into compressed vmlinux.
      Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      9eb7115b
    • M
      davinci: da8xx: Add base DA830/OMAP-L137 SoC support · 55c79a40
      Mark A. Greer 提交于
      The da830/omap l137 is a new SoC from TI that is similar
      to the davinci line.  Since its so similar to davinci,
      put the support for the da830 in the same directory as
      the davinci code.
      
      There are differences, however.  Some of those differences
      prevent support for davinci and da830 platforms to work
      in the same kernel binary.  Those differences are:
      
      1) Different physical address for RAM.  This is relevant
         to Makefile.boot addresses and PHYS_OFFSET.  The
         Makefile.boot issue isn't truly a kernel issue but
         it means u-boot won't work with a uImage including
         both architectures.  The PHYS_OFFSET issue is
         addressed by the "Allow for runtime-determined
         PHYS_OFFSET" patch by Lennert Buytenhek but it
         hasn't been accepted yet.
      
      2) Different uart addresses.  This is only an issue
         for the 'addruart' assembly macro when CONFIG_DEBUG_LL
         is enabled.  Since the code in that macro is called
         so early (e.g., by _error_p in kernel/head.S when
         the processor lookup fails), we can't determine what
         platform the kernel is running on at runtime to use
         the correct uart address.
      
      These areas have compile errors intentionally inserted
      to indicate to the builder they're doing something wrong.
      
      A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added
      to distinguish between a true davinci architecture and
      the da830 architecture.
      
      Note that the da830 currently has an issue with writeback
      data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be
      enabled when building a da830 kernel.
      
      Additional generalizations for future SoCs in the da8xx family done by
      Sudhakar Rajashekhara and Sekhar Nori.
      Signed-off-by: NSteve Chen <schen@mvista.com>
      Signed-off-by: NMikhail Cherkashin <mcherkashin@ru.mvista.com>
      Signed-off-by: NMark A. Greer <mgreer@mvista.com>
      Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      55c79a40
  6. 29 5月, 2009 2 次提交
  7. 26 5月, 2009 1 次提交
  8. 28 4月, 2009 1 次提交
  9. 07 8月, 2008 1 次提交
  10. 12 5月, 2007 1 次提交