Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 10月, 2013 1 次提交
  3. 29 8月, 2013 1 次提交
    • T
      OMAPDSS: fix DPI and SDI device ids · 35f5df6f
      由 Tomi Valkeinen 提交于 
      The DPI and SDI platform devices are currently created with the ID of
-1. The ID doesn't currently affect anything.

However, we have added regulator supply entries for "omapdss_dpi.0" and
"omapdss_sdi.0" to the board files, although these supply entries are
not yet used. As the ID used for the devices is -1, these regulator
supply entries will not work.

To fix the issue, assign ID of 0 to the devices. In the future there may
be more than one DPI or SDI output, so it makes sense to have a proper
ID for them.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
      35f5df6f
  5. 26 1月, 2013 1 次提交
    • P
      ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code · c1d1cd59
      由 Paul Walmsley 提交于 
      Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c.  This
mostly consists of removing the first attempt at device PM latency
handling.  This was never really used, has been replaced by the common
dev_pm_qos code, and needs to go away as part of the DT conversion.
Also, the early platform_device creation code has been removed, as it
appears to be unused.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
      c1d1cd59
  7. 09 11月, 2012 1 次提交
  9. 29 10月, 2012 1 次提交
  11. 19 10月, 2012 3 次提交
  13. 18 10月, 2012 1 次提交
  15. 16 10月, 2012 1 次提交
    • T
      OMAPDSS: add omapdss_version · acd18af9
      由 Tomi Valkeinen 提交于 
      Add new enum, omapdss_version, that is used to tell which DSS hardware
version the SoC has. This enum is initialized during platform init, and
passed in the platform data to omapdss driver.

Note that the versions are not "continuous", that is, you cannot check
if the version is less or greater than something, but you need to check
for exact version match. In other words, this is invalid:

/* test if DSS is 3630 or earlier */
if (ver <= OMAPDSS_VER_OMAP3630)
	...
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      acd18af9
  17. 09 10月, 2012 1 次提交
  19. 06 10月, 2012 1 次提交
  21. 23 9月, 2012 1 次提交
    • R
      ARM: omap: clk: add clk_prepare and clk_unprepare · 4d7cb45e
      由 Rajendra Nayak 提交于 
      As part of Common Clk Framework (CCF) the clk_enable() operation
was split into a clk_prepare() which could sleep, and a clk_enable()
which should never sleep. Similarly the clk_disable() was
split into clk_disable() and clk_unprepare(). This was
needed to handle complex cases where in a clk gate/ungate
would require a slow and a fast part to be implemented.
None of the clocks below seem to be in the 'complex' clocks
category and are just simple clocks which are enabled/disabled
through simple register writes.
Most of the instances also seem to be called in non-atomic
context which means its safe to move all of those from
using a clk_enable() to clk_prepare_enable() and clk_disable() to
clk_disable_unprepare().

For some others, mainly the ones handled through the hwmod framework
there is a possibility that they get called in either an atomic
or a non-atomic context.

The way these get handled below work only as long as clk_prepare
is implemented as a no-op (which is the case today) since this gets
called very early at boot while most subsystems are unavailable.
Hence these are marked with a *HACK* comment, which says we need
to re-visit these once we start doing something meaningful with
clk_prepare/clk_unprepare like doing voltage scaling or something
that involves i2c.

This is in preparation of OMAP moving to CCF.

Based on initial changes from Mike Turquette.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d7cb45e
  23. 22 8月, 2012 1 次提交
  25. 29 6月, 2012 1 次提交
  27. 05 6月, 2012 1 次提交
    • T
      OMAPDSS: fix registration of DPI and SDI devices · c3a21fc7
      由 Tomi Valkeinen 提交于 
      The omapdss arch initialization code registers all the output devices as
omap_devices. However, DPI and SDI are not proper omap_devices, as they
do not have any corresponding HWMOD. This leads to crashes or problems
when the platform code tries to use omap_device functions for DPI and
SDI devices.

One such crash was reported by John Stultz <johnstul@us.ibm.com>:

[   18.756835] Unable to handle kernel NULL pointer dereference at
virtual addr8
[   18.765319] pgd = ea6b8000
[   18.768188] [00000018] *pgd=aa942831, *pte=00000000, *ppte=00000000
[   18.774749] Internal error: Oops: 17 [#1] SMP ARM
[   18.779663] Modules linked in:
[   18.782836] CPU: 0    Not tainted  (3.5.0-rc1-dirty #456)
[   18.788482] PC is at _od_resume_noirq+0x1c/0x78
[   18.793212] LR is at _od_resume_noirq+0x6c/0x78
[   18.797943] pc : [<c00307ec>]    lr : [<c003083c>]    psr: 20000113
[   18.797943] sp : ec3abe80  ip : ec3abdb8  fp : 00000006
[   18.809936] r10: ec1148b8  r9 : c08a48f0  r8 : c00307d0
[   18.815368] r7 : 00000000  r6 : 00000000  r5 : ec114800  r4 :
ec114808
[   18.822174] r3 : 00000000  r2 : 00000000  r1 : ec154fe8  r0 :
00000006
[   18.829010] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment user
[   18.836456] Control: 10c5387d  Table: aa6b804a  DAC: 00000015
[   18.842437] Process sh (pid: 1139, stack limit = 0xec3aa2f0)
[   18.848358] Stack: (0xec3abe80 to 0xec3ac000)

DPI and SDI can be plain platform_devices. This patch changes the
registration from omap_device_register() to platform_device_add().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NJohn Stultz <johnstul@us.ibm.com>
Tested-by: NJean Pihet <jean.pihet@newoldbits.com>
      c3a21fc7
  29. 11 5月, 2012 4 次提交
    • T
      OMAPDSS: interface drivers register their panel devices · 35deca3d
      由 Tomi Valkeinen 提交于 
      Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.

With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have "dpi" node, under which we would
have the display that uses DPI. In other words, each output driver
handles the displays that use that particular output.

To make the current code ready for DT, this patch modifies the output
drivers so that each of them creates the display devices which use that
output. However, instead of changing the platform data to suit this
method, each output driver is passed the full list of displays, and the
drivers pick the displays that are meant for them. This allows us to
keep the old platform data, and thus we avoid the need to change the
board files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      35deca3d
    • T
      OMAPDSS: create DPI & SDI devices · 53f576a8
      由 Tomi Valkeinen 提交于 
      We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.

This patch modifies arch/arm/mach-omap2/display.c to create platform
devices for DPI and SDI, and later patches will implement driver for
them.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      53f576a8
    • T
      OMAPDSS: create custom pdevs for DSS omap_devices · 966eaed0
      由 Tomi Valkeinen 提交于 
      Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      966eaed0
    • T
      OMAPDSS: clean up the omapdss platform data mess · 00928eaf
      由 Tomi Valkeinen 提交于 
      The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
  wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
  dss hwmods do not need the platform data. This should also work better
  for DT, as we can create omapdss device programmatically in generic omap
  boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
  that the dss hwmod drivers can call.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      00928eaf
  31. 23 4月, 2012 1 次提交
  33. 20 3月, 2012 1 次提交
  35. 25 2月, 2012 2 次提交
  37. 26 1月, 2012 1 次提交
  39. 05 1月, 2012 2 次提交
  41. 07 12月, 2011 1 次提交
  43. 08 11月, 2011 2 次提交
    • A
      ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader · b923d40d
      由 Archit Taneja 提交于 
      Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.

Add function dispc_disable_outputs() which disables all active overlay manager
and ensure all frame transfers are completed.

Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
DSS2 driver starts.

This resolves the hang issue(caused by a L3 error during boot) seen on the
beagle board C3, which has a factory bootloader that enables display. The issue
is resolved with this patch.

Thanks to Tomi and Sricharan for some additional testing.
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NR, Sricharan <r.sricharan@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
[paul@pwsan.com: restructured code, removed omap_{read,write}l(), removed
 cpu_is_omap*() calls and converted to dev_attr]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b923d40d
    • T
      ARM: OMAP: HWMOD: Unify DSS resets for OMAPs · 13662dc5
      由 Tomi Valkeinen 提交于 
      This patch adds a custom DSS reset function used on OMAPs from OMAP2
forward.

The function doesn't actually do a reset, it only waits for the reset to
complete. The reason for this is that on OMAP4 there is no possibility
to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
all the other DSS modules also, thus breaking the HWMOD model where
every DSS module is handled independently.

This fixes the problem with DSS reset on OMAP4, caused by the fact that
because there's no SW reset for dss_core on OMAP4, the HWMOD framework
doesn't try to reset dss_core and thus the DSS clocks were never enabled
at the same time. This causes causes the HWMOD reset to fail for
dss_dispc and dss_rfbi.

The common reset function will also allow us to fix another problem in
the future: before doing a reset we need to disable DSS outputs, which
are in some cases enabled by the bootloader, as otherwise DSS HW seems
to get more or less stuck, requiring a power reset to recover.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
[paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o
 unconditionally to avoid an error when !CONFIG_OMAP2_DSS]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      13662dc5
  45. 01 11月, 2011 1 次提交
    • P
      arm: fix implicit memset/string.h usage in various arch/arm files · d44b28c4
      由 Paul Gortmaker 提交于 
      To fix things like this:

arch/arm/mach-omap2/usb-tusb6010.c:58: error: implicit declaration of function 'memset'
arch/arm/kernel/leds.c:40: error: implicit declaration of function 'strcspn'
arch/arm/kernel/leds.c:40: warning: incompatible implicit declaration of built-in function 'strcspn'
arch/arm/kernel/leds.c:45: error: implicit declaration of function 'strncmp'
arch/arm/kernel/leds.c:55: error: implicit declaration of function 'strlen'
arch/arm/kernel/leds.c:55: warning: incompatible implicit declaration of built-in function 'strlen'
arch/arm/mach-omap2/clockdomain.c:52: error: implicit declaration of function 'strcmp'
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      d44b28c4
  47. 05 10月, 2011 1 次提交
  49. 30 9月, 2011 3 次提交
  51. 16 9月, 2011 1 次提交
    • K
      OMAP: omap_device: when building return platform_device instead of omap_device · 3528c58e
      由 Kevin Hilman 提交于 
      All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      3528c58e
  53. 25 7月, 2011 4 次提交