Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 9月, 2010 2 次提交
    • 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 7 次提交
    • 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
    • K
      OMAP: PM: create omap_devices for MPU, DSP, L3 · 6f88e9bc
      由 Kevin Hilman 提交于 
      Create simple omap_devices for the main processors and busses.

This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.

Also, move these common PM init functions into a common_pm_init call
that is called as a device_initcall().  The PM init is done at this level
to ensure that the driver core is initialized before initialized.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: sparse warnings cleaned up; newly-created functions moved
 from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
 to start with "omap2" rather than "omap"]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6f88e9bc
    • K
      OMAP: omap_device: ensure hwmod tracks attached omap_device pointer · 06563581
      由 Kevin Hilman 提交于 
      The omap_hwmod struct has a field to track the omap_device that is
attached to it, but it was not being assigned.  Fix by assigning omap_device
pointer when omap_device is built.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: use an array index rather than pointer arithmetic]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      06563581