1. 24 4月, 2014 1 次提交
    • T
      ARM: OMAP2+: Fix GPMC remap for devices using an offset · fb677ef7
      Tony Lindgren 提交于
      At least the smc91x driver expects the device to be at 0x300
      offset from bus base address. This does not work currently
      for GPMC when booted in device tree mode as it attempts to
      remap the the allocated GPMC partition to the address
      configured by the device tree plus the device offset.
      
      Note that this works just fine when booted with legacy mode.
      
      Let's fix the issue by just ignoring any device specific
      offset while remapping. And let's make sure the remap
      address confirms to the GPMC 16MB minimum granularity
      as listed in the TRM for GPMC_CONFIG7 BASEADDRESS bits.
      
      Otherwise we can get something like this:
      
      omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300
      
      Cc: Pekon Gupta <pekon@ti.com>
      Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      fb677ef7
  2. 22 4月, 2014 1 次提交
    • T
      ARM: OMAP2+: Fix oops for GPMC free · efe80723
      Tony Lindgren 提交于
      If gpmc_cs_remap() fails we will get an error because we are calling
      release_resource() on an uninitialized resource. Let's fix that by
      checking the resource flags. And while at it, let's also make
      gpmc_cs_delete_mem() use the res pointer that we already have to
      avoid confusion.
      
      Without this patch we can get the following error:
      
      omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300
      Unable to handle kernel NULL pointer dereference at virtual address 00000018
      ...
      (gpmc_cs_free+0x94/0xc8)
      (gpmc_probe_generic_child+0x178/0x1ec)
      (gpmc_probe_dt+0x1bc/0x2cc)
      (gpmc_probe+0x250/0x44c)
      (platform_drv_probe+0x3c/0x6c)
      (really_probe+0x74/0x208)
      (driver_probe_device+0x34/0x50)
      (bus_for_each_drv+0x60/0x8c)
      (device_attach+0x80/0xa4)
      (bus_probe_device+0x88/0xb0)
      (device_add+0x320/0x450)
      (of_platform_device_create_pdata+0x80/0x9c)
      (of_platform_bus_create+0xd0/0x170)
      (of_platform_bus_create+0x12c/0x170)
      (of_platform_populate+0x60/0x98)
      (pdata_quirks_init+0x30/0x48)
      (customize_machine+0x20/0x48)
      (do_one_initcall+0x2c/0x14c)
      (do_basic_setup+0x98/0xd8)
      (kernel_init_freeable+0x12c/0x1e0)
      (kernel_init+0x8/0xf0)
      (ret_from_fork+0x14/0x2c)
      Code: e1a04000 e59f0070 eb195136 e5942010 (e5923018)
      
      Cc: Pekon Gupta <pekon@ti.com>
      Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
      Signed-off-by: Ntony Lindgren <tony@atomide.com>
      efe80723
  3. 19 4月, 2014 1 次提交
  4. 12 4月, 2014 3 次提交
  5. 11 4月, 2014 1 次提交
    • T
      ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register · 390403fd
      Tero Kristo 提交于
      There is a solitary write to this register every wakeup from off-mode,
      which isn't doing anything, so remove it.
      
      Also note that modifying this register trashes any attempted
      voltage scaling configuration and the change probably should
      never have gotten merged in the first place.
      
      Cc: Nishanth Menon <nm@ti.com>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [tony@atomide.com: updated comments to describe regression]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      390403fd
  6. 04 4月, 2014 8 次提交
  7. 02 4月, 2014 1 次提交
  8. 19 3月, 2014 2 次提交
    • T
      ARM: OMAP2+: DT 'compatible' tweak for displays · 6a0e6b38
      Tomi Valkeinen 提交于
      As there is no common panel framework in the kernel, we have OMAP
      specific panel drivers. However, the DT data should be generic. This
      brings the issue that some other platform could use the same panels, and
      would need to create a driver with the same 'compatible' string as the
      OMAP driver.
      
      In the long run, we have to get a common panel framework. For the time
      being, this patch solves the issue:
      
      At early boot time, we go through the DT nodes looking for the panels
      the kernel supports for OMAP. For each found node, the 'compatible'
      string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
      "omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
      at the beginning of their compatible field.
      
      This allows us to have generic DT data, but OMAP specific display
      drivers.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      6a0e6b38
    • T
      ARM: OMAP2+: add omapdss_init_of() · dcdf407b
      Tomi Valkeinen 提交于
      The OMAP display architecture requires a bunch of platform devices which
      are not created via .dts (for now). We also need to pass a few function
      pointers and the DSS hardware version from the arch code to omapdss
      driver.
      
      This patch adds omapdss_init_of() function, called from board-generic at
      init time, which handles those tasks.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      dcdf407b
  9. 14 3月, 2014 5 次提交
  10. 13 3月, 2014 6 次提交
  11. 05 3月, 2014 3 次提交
  12. 03 3月, 2014 1 次提交
  13. 01 3月, 2014 7 次提交