Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 9月, 2010 4 次提交
    • 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
    • K
      OMAP: omap_device: make all devices a child of a new parent device · 0d5e8252
      由 Kevin Hilman 提交于 
      In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new common parent
device.

Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.

Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.

In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      0d5e8252
    • K
      Revert "OMAP: omap_device: add omap_device_is_valid()" · a1ed40cb
      由 Kevin Hilman 提交于 
      This reverts commit 0007122a.

The dereference method of checking for a valid omap_device when
wrapping a platform_device is rather unsafe and dangerous.

Instead, a better way of checking for a valid omap-device is
to use a common parent device for all omap_devices, then a check
can simply be made using the device parent.  The only user of this
API was the initial version of the runtime PM core for OMAP.  This
has now been switched to check device parent, so there are no more
users of this API.
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      a1ed40cb
    • T
      OMAP4: pm.c extensions for OMAP4 support · b3294e23
      由 Thara Gopinath 提交于 
      OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.
Signed-off-by: NThara Gopinath <thara@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b3294e23
  3. 16 8月, 2010 1 次提交
  5. 11 8月, 2010 1 次提交
  7. 05 8月, 2010 1 次提交
  9. 04 8月, 2010 17 次提交
  11. 03 8月, 2010 3 次提交
  13. 02 8月, 2010 8 次提交
  15. 27 7月, 2010 5 次提交
    • R
      ARM: OMAP: Convert OMAPFB and VRAM SDRAM reservation to LMB · 98864ff5
      由 Russell King 提交于 
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      98864ff5
    • P
      OMAP: PM constraints: add omap_pm_set_min_clk_rate() · fb8ce14c
      由 Paul Walmsley 提交于 
      Add omap_pm_set_min_clk_rate().  This constraint is meant for use by
device drivers to translate a certain device-specific performance
constraint (e.g., "minimum polygons per second") to a clock rate for
the driver's device, given the driver's intimate knowledge of the
device hardware (e.g., device type, device hardware revision, firmware
revision, etc.)  From a general PM core perspective, clock rate is
probably the closest general analog to "performance" that is
available, but the exact mapping from a use-case-specific performance
constraint to clock rate must be done by the driver.  Drivers intended for
upstream merging shouldn't hardcode specific clock rates in their code
without basing those rates on some performance criteria requested through
the driver's subsystem (ideally, from userspace).

Imre Deak <imre.deak@nokia.com> described the need and use-case for
this constraint, and discussed the implementation - thanks, Imre.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Imre Deak <imre.deak@nokia.com>
      fb8ce14c
    • P
      OMAP: PM constraints: add return values; add requesting device param to... · 564889c1
      由 Paul Walmsley 提交于 
      OMAP: PM constraints: add return values; add requesting device param to omap_pm_set_max_dev_wakeup_lat()

Add return values to the PM constraint functions.  This allows the PM
core to provide feedback to the caller if a constraint is not
possible.  Update the one upstream user of omap_pm_set_max_mpu_wakeup_lat()
to add a compatibility wrapper, needed until the driver is changed.

Update some of the documentation to conform more closely to kerneldoc style.

Add an additional device parameter to omap_pm_set_max_dev_wakeup_lat()
to identify the device requesting the constraint.  This is so repeated calls
to omap_pm_set_max_dev_wakeup_lat() with the same requesting device can
override the device's previously-set constraint.  Also, it allows the PM
core to make a decision as to whether or not the constraint should be
satisfied, based on the caller's identity.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      564889c1
    • P
      OMAP2+: hwmod/device: update documentation and copyright · 887adeac
      由 Paul Walmsley 提交于 
      Update some minor documentation issues and update copyright for
omap_device/omap_hwmod code.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      887adeac
    • P
      OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_va · db2a60bf
      由 Paul Walmsley 提交于 
      Add omap_device_get_mpu_rt_va().  This is intended to be used by
device drivers (currently, via a struct platform_data function
pointer) to retrieve their corresponding device's virtual base address
that the MPU should use to access the device.  This is needed because
the omap_hwmod code does its own ioremap(), in order to gain access to
the module's OCP_SYSCONFIG register.

Add omap_hwmod_get_mpu_rt_va().  omap_device_get_mpu_rt_va() calls this
function to do the real work.

While here, rename struct omap_hwmod._rt_va to struct
omap_hwmod._mpu_rt_va, to reinforce that it refers to the MPU's
register target virtual address base (as opposed to, for example, the
L3's).

In the future, this belongs as a function in an omap_bus, so it is not
necessary to call this through a platform_data function pointer.

The use-case for this function was originally presented by Santosh
Shilimkar <santosh.shilimkar@ti.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      db2a60bf