Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 8月, 2017 1 次提交
  3. 16 8月, 2017 2 次提交
  5. 06 1月, 2017 2 次提交
  7. 10 11月, 2016 1 次提交
  9. 03 6月, 2016 1 次提交
  11. 04 6月, 2015 2 次提交
  13. 01 4月, 2015 1 次提交
  15. 19 9月, 2014 1 次提交
  17. 28 5月, 2014 1 次提交
  19. 09 5月, 2014 3 次提交
  21. 19 3月, 2014 2 次提交
    • T
      ARM: OMAP2+: DT 'compatible' tweak for displays · 6a0e6b38
      由 Tomi Valkeinen 提交于 
      As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.

In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:

At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.

This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
      6a0e6b38
    • T
      ARM: OMAP2+: add omapdss_init_of() · dcdf407b
      由 Tomi Valkeinen 提交于 
      The OMAP display architecture requires a bunch of platform devices which
are not created via .dts (for now). We also need to pass a few function
pointers and the DSS hardware version from the arch code to omapdss
driver.

This patch adds omapdss_init_of() function, called from board-generic at
init time, which handles those tasks.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
      dcdf407b
  23. 28 2月, 2014 1 次提交
  25. 18 12月, 2013 1 次提交
  27. 19 11月, 2013 1 次提交
  29. 09 10月, 2013 3 次提交
  31. 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
  33. 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
  35. 09 11月, 2012 1 次提交
  37. 29 10月, 2012 1 次提交
  39. 19 10月, 2012 3 次提交
  41. 18 10月, 2012 1 次提交
  43. 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
  45. 09 10月, 2012 1 次提交
  47. 06 10月, 2012 1 次提交
  49. 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
  51. 22 8月, 2012 1 次提交
  53. 29 6月, 2012 1 次提交
  55. 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
  57. 11 5月, 2012 2 次提交
    • 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