Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 22 12月, 2010 7 次提交
  3. 21 12月, 2010 1 次提交
  5. 18 12月, 2010 3 次提交
  7. 08 12月, 2010 1 次提交
    • V
      OMAP: GPIO: Implement GPIO as a platform device · 77640aab
      由 Varadarajan, Charulatha 提交于 
      Implement GPIO as a platform device.

GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before board_init. Therefore
GPIO device register and driver register are implemented as
postcore_initcalls.

omap_gpio_init() does nothing now and this function would be
removed in the next patch as it's usage is spread across most
of the board files.

Inorder to convert GPIO as platform device, modifications are
required in clockxxxx_data.c file for OMAP1 so that device names
can be used to obtain clock instead of getting clocks by
name/NULL ptr.

Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling
or disabling the clocks, modify sysconfig settings and remove usage
of clock FW APIs.
Note 1: Converting GPIO driver to use runtime PM APIs is not done as a
separate patch because GPIO clock names are different for various OMAPs
and are different for some of the banks in the same CPU. This would need
usage of cpu_is checks and bank id checks while using clock FW APIs in
the gpio driver. Hence while making GPIO a platform driver framework,
PM runtime APIs are used directly.

Note 2: While implementing GPIO as a platform device, pm runtime APIs
are used as mentioned above and modification is not done in gpio's
prepare for idle/ resume after idle functions. This would be done
in the next patch series and GPIO driver would be made to use dev_pm_ops
instead of sysdev_class in that series only.

Due to the above, the GPIO driver implicitly relies on
CM_AUTOIDLE = 1 on its iclk for power management to work, since the
driver never disables its iclk.
This would be taken care in the next patch series (see Note 3 below).

Refer to
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html
for more details.

Note 3: only pm_runtime_get_sync is called in gpio's probe() and
pm_runtime_put* is never called. This is to make the implementation
similar to the existing GPIO code. Another patch series would be sent
to correct this.

In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They
are enabled/ disabled whenever required using clock framework APIs

TODO:
1. Cleanup the GPIO driver. Use function pointers and register
offest pointers instead of using hardcoded values
2. Remove all cpu_is_ checks and OMAP specific macros
3. Remove usage of gpio_bank array so that only
   instance specific information is used in driver code
4. Rename 'method'/ avoid it's usage
5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4
6. Modify gpio's prepare for idle/ resume after idle functions
   to use runtime pm implentation.
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Reviewed-by: NBasak, Partha <p-basak2@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
[tony@atomide.com: updated for bank specific revision and updated boards]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      77640aab
  9. 01 12月, 2010 2 次提交
  11. 17 11月, 2010 1 次提交
  13. 09 10月, 2010 2 次提交
    • P
      OMAP: split plat-omap/common.c · aa218daf
      由 Paul Walmsley 提交于 
      Split plat-omap/common.c into three pieces:

1. the 32KiHz sync timer and clocksource code, which now lives in
   plat-omap/counter_32k.c;

2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;

3. and the remainder of the OMAP-wide common code, which includes the
   deprecated ATAGs code and a deprecated video RAM reservation function.

The primary motivation for doing this is to move the OMAP2+-specific parts
into an OMAP2+-specific file, so that build breakage related to the
System Control Module code can be resolved.

Benoît Cousson <b-cousson@ti.com> suggested a new filename and found
some bugs in the counter_32k.c comments - thanks Benoît.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      aa218daf
    • E
      omap3: Add minimal OMAP3 IGEP module support · e844b1da
      由 Enric Balletbo i Serra 提交于 
      The OMAP3 IGEP module is a low-power, high performance production-ready
system-on-module (SOM) based on TI's OMAP3 family. More about this
board at www.igep.es.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
[tony@atomide.com: updated for the mmc changes and to be selected by default]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      e844b1da
  15. 06 10月, 2010 1 次提交
  17. 29 9月, 2010 2 次提交
  19. 28 9月, 2010 1 次提交
  21. 24 9月, 2010 1 次提交
    • B
      OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2 · 55d2cb08
      由 Benoit Cousson 提交于 
      The current version contains only the interconnects and the
mpu hwmods.
The remaining hwmods will be introduced by further patches on
top of this one.

- enable as well omap_hwmod.c build for OMAP4 Soc

Please not that this file uses the new naming convention for
naming HW IPs. This convention will be backported soon for previous
OMAP2 & 3 data files.

new name        trm name
-------------   -------------------
counter_32k     synctimer_32k
l3_main         l3
timerX          gptimerX / dmtimerX
mmcX            mmchsX / sdmmcX
dma_system      sdma
smartreflex_X   sr_X / sr?
usb_host_fs     usbfshost
usb_otg_hs      hsusbotg
usb_tll_hs      usbtllhs_config
wd_timerX       wdtimerX
ipu             cortexm3 / ducati
dsp             c6x / tesla
iva             ivahd / iva2.2
kbd             kbdocp / keyboard
mailbox         system_mailbox
mpu             cortexa9 / chiron
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      55d2cb08
  23. 22 9月, 2010 3 次提交
    • P
      OMAP2/3: PRM: add module hard reset support · cf21405f
      由 Paul Walmsley 提交于 
      This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
on OMAP2/3 platforms.  It's based on the OMAP4 hard-reset support that Benoît
developed in the previous patch.

This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      cf21405f
    • B
      OMAP4: PRM: add module hard reset support · 0be1621a
      由 Benoît Cousson 提交于 
      Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
under the control of the PRM.  This patch adds an API for this purpose
for OMAP4 devices:

int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);

This API is intended to be used only by the hwmod code - a subsequent
patch will add that support to hwmod.

This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      0be1621a
    • K
      OMAP2+: PM: initial runtime PM core support · 57e6fe7b
      由 Kevin Hilman 提交于 
      Implement the new runtime PM framework as a thin layer on top of the
omap_device API.  OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.

In order to determine if a device is an omap_device, its parent device
is checked.  All omap_devices have a new 'omap_device_parent_ device
as their parent device, so checking for this parent is used to check
for valid omap_devices.  If a device is an omap_device, then the
appropriate omap_device functions are called for it.  If not, only the
generic runtime PM functions are called.

Device driver's ->runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device.  Driver's ->runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver ->runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)

OMAP4 build support from Rajendra Nayak <rnayak@ti.com>.
OMAP2 build support from Charulatha V <charu@ti.com>

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Charulatha V <charu@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      57e6fe7b
  25. 16 8月, 2010 1 次提交
  27. 02 8月, 2010 8 次提交
  29. 27 7月, 2010 2 次提交
  31. 05 7月, 2010 3 次提交
  33. 29 6月, 2010 1 次提交