Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 9月, 2010 2 次提交
  3. 28 9月, 2010 9 次提交
  5. 24 9月, 2010 6 次提交
    • D
      omap4: Panda: Add DEBUG_LL support · b5be6b66
      由 David Anders 提交于 
      Add support for use of DEBUG_LL for use with PandaBoard.
Signed-off-by: NDavid Anders <x0132446@ti.com>
      b5be6b66
    • S
      omap4: Update id.c and cpu.h for es2.0 · ed6be0ba
      由 Santosh Shilimkar 提交于 
      This patch updates the id.c and cpu.h files to support
omap4 ES2.0 silicon detection. Few initial omap4 es2 samples
IDCODE is same as es1. So the patch uses ARM cpuid register to
detect the ES version for such samples
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      ed6be0ba
    • 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
  7. 22 9月, 2010 8 次提交
    • P
      OMAP: hwmod: improve documentation, clean up function names · 74ff3a68
      由 Paul Walmsley 提交于 
      This patch:

- adds more documentation to the hwmod code

- fixes some documentation typos elsewhere in the file

- changes the _sysc_*() function names to appear in (verb, noun) order,
  to match the rest of the function names.

This patch should not result in any functional change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      74ff3a68
    • B
      OMAP: hwmod: Fix softreset for modules with optional clocks · 96835af9
      由 Benoit Cousson 提交于 
      Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.

TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.
Reported-by: NPartha Basak <p-basak2@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
      96835af9
    • B
      OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs · 2cb06814
      由 Benoit Cousson 提交于 
      In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
use the SYSC softreset bit to provide the status.

Other cases might exist:
- Some IPs like McBSP does have a softreset control but no reset status.
- Some IPs that represent subsystem, like the DSS, can contains
a reset status without softreset control. The status is the aggregation
of all the sub modules reset status.

- Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
and replace the previous SYSS_MISSING, that was used to flag IP with
softreset control but without the SYSSTATUS register, with a specific
SYSS_HAS_RESET_STATUS flag.

- MCSPI and MMC contains both programming models, so the legacy one
will be prevented by removing the syss offset field that become useless.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      2cb06814
    • P
      OMAP: hwmod: add an hardreset API for use by other core code · aee48e3c
      由 Paul Walmsley 提交于 
      Expose an hardreset API from hwmod in order to assert / deassert all the
individual reset lines that belong to an hwmod.  This API is needed by
some of the more complicated processor drivers, e.g., DSP/Bridge,
Syslink, etc.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      aee48e3c
    • B
      OMAP: hwmod: Add hardreset management support · 5365efbe
      由 Benoît Cousson 提交于 
      Most processor IPs does have a hardreset signal controlled by the PRM.
This is different of the softreset used for local IP reset from the
SYSCONFIG register.
The granularity can be much finer than orginal HWMOD, for ex, the IVA
hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2...
Since this granularity is needed by the driver, we have to ensure
than one hwmod exist for each hardreset line.

- Store reset lines as hwmod resources that a driver can query by name like
  an irq or sdma line.

- Add two functions for asserting / deasserting reset lines in hwmods
  processor that require manual reset control.
- Add one functions to get the current reset state.
- If an hwmod contains only one line, an automatic assertion / de-assertion
  is done.
  -> de-assert the hardreset line only during enable from disable transition
  -> assert the hardreset line only during shutdown

Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be
kept in INITIALIZED state.
They can be properly enabled only if the hardreset line is de-asserted
before.

For information here is the list of IPs with HW reset control
on an OMAP4430 device:

RM_DSP_RSTCTRL
  1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control'
  0,0,'RST1','RW','1','DSP - DSP reset control'

RM_IVA_RSTCTRL
  2,2,'RST3','RW','1','IVA logic and SL2 reset control'
  1,1,'RST2','RW','1','IVA Sequencer2 reset control'
  0,0,'RST1','RW','1','IVA sequencer1 reset control'

RM_IPU_RSTCTRL
  2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.'
  1,1,'RST2','RW','1','IPU Cortex M3 CPU2  reset control.'
  0,0,'RST1','RW','1','IPU Cortex M3 CPU1  reset control.'

PRM_RSTCTRL
  1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.'
  0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.'

RM_CPU0_CPU0_RSTCTRL
RM_CPU1_CPU1_RSTCTRL
  0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control'
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: made the hardreset functions static; moved the register
 twiddling into prm*.c functions in previous patches; changed the
 function names to conform with hwmod practice]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      5365efbe
    • B
      OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM · 16b04012
      由 Benoit Cousson 提交于 
      Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so define temp
version until the proper ones are defined.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      16b04012
    • K
      OMAP: hwmod: separate list locking and hwmod hardware locking · 12b1fdb4
      由 Kevin Hilman 提交于 
      Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions.  This
patch separates these two types of locking.

First, omap_hwmod_mutex is used only to protect access and
modification of omap_hwmod_list.  Also cleaned up some comments
referring to this mutex that are no longer needed.

Then, for protecting concurrent access to hwmod functions, use a
per-hwmod mutex.  This protects concurrent access to a single hwmod,
but would allow concurrent access to different hwmods.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: added structure documentation; changed mutex variable
 name]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      12b1fdb4
    • B
      OMAP: hwmod: Rename dma_ch to dma_req · 9ee9fff9
      由 Benoit Cousson 提交于 
      The dma request line attribute was named dma channel, which leads
to confusion with the real dma channel definition.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      9ee9fff9
  9. 16 8月, 2010 1 次提交
  11. 11 8月, 2010 1 次提交
  13. 05 8月, 2010 1 次提交
  15. 04 8月, 2010 7 次提交
  17. 03 8月, 2010 3 次提交
  19. 02 8月, 2010 2 次提交