1. 13 Oct, 2010 1 commit
  2. 12 Oct, 2010 1 commit
    • Ben Gardiner's avatar
      davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr · 7b37a27e
      Ben Gardiner authored
      
      
      This patch proposes to migrate the davinci_emac driver to using the
      eth_device->write_hwaddr function pointer as suggested by Ben Warren.
      
      All the davinci boards had the behaviour, prior to this patch, of
      sync'ing the environment variable enetaddr with the MAC address read
      from non-volatile storage on boot -- when the two locations disagreed,
      the environment variable value took precendence. This patch keeps the
      same behaviour but lets eth_initialize take care of it.
      
      This patch refactors davinci_emac setup in the boards so that the MAC
      address is read from non-volatile storage into the environment variable
      and then the environment variable value is use in eth_intialize. The
      only exception is the direct call to davinci_eth_set_mac_addr made by
      the da830evm board init which was changed into an assignment of the
      enetaddr field.
      Signed-off-by: default avatarBen Gardiner <bengardiner@nanometrics.ca>
      Tested-by: default avatarNick Thompson <nick.thompson@ge.com>
      Signed-off-by: default avatarBen Warren <biggerbadderben@gmail.com>
      7b37a27e
  3. 19 Sep, 2010 2 commits
  4. 03 Aug, 2010 1 commit
    • Wolfgang Denk's avatar
      Rename getenv_r() into getenv_f() · cdb74977
      Wolfgang Denk authored
      
      
      While running from flash, i. e. before relocation, we have only a
      limited C runtime environment without writable data segment. In this
      phase, some configurations (for example with environment in EEPROM)
      must not use the normal getenv(), but a special function.  This
      function had been called getenv_r(), with the idea that the "_r"
      suffix would mean the same as in the _r_eentrant versions of some of
      the C library functions (for example getdate vs. getdate_r, getgrent
      vs. getgrent_r, etc.).
      
      Unfortunately this was a misleading name, as in U-Boot the "_r"
      generally means "running from RAM", i. e. _after_ relocation.
      
      To avoid confusion, rename into getenv_f() [as "running from flash"]
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Acked-by: default avatarDetlev Zundel <dzu@denx.de>
      cdb74977
  5. 13 Apr, 2010 1 commit
  6. 07 Mar, 2010 1 commit
  7. 11 Nov, 2009 1 commit
  8. 11 Oct, 2009 1 commit
  9. 03 Oct, 2009 3 commits
  10. 04 Sep, 2009 3 commits
  11. 25 Aug, 2009 1 commit
  12. 17 Jul, 2009 1 commit
    • Jean-Christophe PLAGNIOL-VILLARD's avatar
      stdio/device: rework function naming convention · 52cb4d4f
      Jean-Christophe PLAGNIOL-VILLARD authored
      
      
      So far the console API uses the following naming convention:
      
      	======Extract======
      	typedef struct device_t;
      
      	int	device_register (device_t * dev);
      	int	devices_init (void);
      	int	device_deregister(char *devname);
      	struct list_head* device_get_list(void);
      	device_t* device_get_by_name(char* name);
      	device_t* device_clone(device_t *dev);
      	=======
      
      which is too generic and confusing.
      
      Instead of using device_XX and device_t we change this
      into stdio_XX and stdio_dev
      
      This will also allow to add later a generic device mechanism in order
      to have support for multiple devices and driver instances.
      Signed-off-by: default avatarJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      
      Edited commit message.
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      52cb4d4f
  13. 21 Jun, 2009 1 commit
  14. 12 Jun, 2009 6 commits
  15. 26 Apr, 2009 1 commit
  16. 16 Apr, 2009 1 commit
  17. 20 Mar, 2009 2 commits
    • Mike Frysinger's avatar
      cmc_pu2: get mac address from environment · 92b50ffe
      Mike Frysinger authored
      
      
      The environment is the canonical storage location of the mac address, so
      we're killing off the global data location and moving everything to
      querying the env directly.
      
      Also rename load_sernum_ethaddr() to misc_init_r() so we don't need to
      handle this board specially in common ARM code.
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      CC: Ben Warren <biggerbadderben@gmail.com>
      92b50ffe
    • Mike Frysinger's avatar
      arm: get mac address from environment · f11e6ff5
      Mike Frysinger authored
      
      
      The environment is the canonical storage location of the mac address, so
      we're killing off the global data location and moving everything to
      querying the env directly.
      
      Some warts are remaining and should be killed off (by moving the func to
      the appropriate board init code):
      	- davinci_eth_set_mac_addr
      	- cs8900_get_enetaddr
      	- smc_set_mac_addr
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      CC: Ben Warren <biggerbadderben@gmail.com>
      f11e6ff5
  18. 22 Feb, 2009 1 commit
  19. 17 Feb, 2009 1 commit
  20. 06 Feb, 2009 1 commit
  21. 31 Jan, 2009 1 commit
  22. 06 Dec, 2008 1 commit
  23. 18 Oct, 2008 1 commit
  24. 08 Oct, 2008 1 commit
  25. 30 Sep, 2008 1 commit
  26. 30 Aug, 2008 1 commit
    • Sandeep Paulraj's avatar
      ARM DaVinci: Changing function names for EMAC driver · fcaac589
      Sandeep Paulraj authored
      
      
      DM644x is just one of a series of DaVinci chips that use the EMAC driver.
      By replacing all the function names that start with dm644x_* to davinci_*
      we make these function more portable. I have tested this change on my EVM.
      DM6467 is another DaVinci SOC which uses the EMAC driver and i will
      be sending patches that add DaVinci DM6467 support to the list soon.
      Signed-off-by: default avatarSandeep Paulraj <s-paulraj@ti.com>
      fcaac589
  27. 20 Aug, 2008 1 commit
  28. 06 Aug, 2008 1 commit
  29. 29 Jul, 2008 1 commit
    • Remy Bohmer's avatar
      ARM: set GD_FLG_RELOC for boards skipping relocation to RAM · f96b44ce
      Remy Bohmer authored
      
      
      If CONFIG_SKIP_RELOCATE_UBOOT is set the flag GD_FLG_RELOC is usually
      never set, because relocation to RAM is actually never done by U-boot
      itself. However, several pieces of code check if this flag is set at
      some time.
      
      So, to make sure this flag is set on boards skipping relocation, this
      is added to the initialisation of U-boot at a moment where it is safe
      to do so.
      Signed-off-by: default avatarRemy Bohmer <linux@bohmer.net>
      f96b44ce