Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 4月, 2012 14 次提交
  3. 19 4月, 2012 6 次提交
    • P
      ARM: OMAP2+: hwmod data: remove forward declarations, reorganize · 844a3b63
      由 Paul Walmsley 提交于 
      Reorganize the hwmod data to declare the IP blocks first and the
interconnects second.  This allows us to remove the forward
declarations, which this patch also does. Saves some lines of source
data.  While here, take the opportunity to synchronize the order of
the OMAP44xx hwmod data with the autogenerator output -- it's slightly
different due to past mismerges -- and fix a few minor typos and
whitespace problems in the files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      844a3b63
    • P
      ARM: OMAP2+: hwmod data: convert to link registration · 0a78c5c5
      由 Paul Walmsley 提交于 
      Register interconnect links between IP blocks, rather than the IP
blocks themselves.  (The IP blocks will be registered as a side-effect
of registering the links.)

The objective is to reduce the number of lines of static data and
facilitate the sharing of IP block data between different SoCs.  These
objectives come at the penalty of increased boot time due to increased
computation.

While here, fix a few whitespace problems and inaccurate variable names.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      0a78c5c5
    • P
      ARM: OMAP4: hwmod data: uncomment some "excluded" hwmods · 53c4c6c3
      由 Paul Walmsley 提交于 
      Some hwmods were commented out from the OMAP4 data, under the theory
that they shouldn't be added until drivers were ready.  But part of
the utility of the hwmod code is that it can reset and properly
initialize IP blocks that have no drivers associated with them.
Rather than commenting the links in the future hwmod data conversion
patches, discussing this with Benoit, it seems best to simply
uncomment them now.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      53c4c6c3
    • P
      ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately · 3d10f0d6
      由 Paul Walmsley 提交于 
      One of the OMAP4 links was missing OCP_USER flags, since it was only
used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
Future patches will switch the hwmod code and data to register
interfaces, rather than hwmods, and it will be mandatory for all
interfaces to have at least one user bit set.  This patch resolves the
issue by adding OCP_USER_DSP and marking the DSP-IVA interface
appropriately.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      3d10f0d6
    • P
      ARM: OMAP4: hwmod data: remove bandgap hwmod · 8291113f
      由 Paul Walmsley 提交于 
      Commit 407a6888 ("OMAP4: hwmod data:
Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a
hwmod for the bandgap die temperature sensor IP block.  This IP block
has no interconnect port or firewall region, nor does it have an
independent register space or OCP control registers.  Its registers
are embedded in the System Control Module (SCM) IP block.  So it
appears that the bandgap device should be created by the SCM driver.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      8291113f
    • P
      ARM: OMAP4: hwmod data: remove pseudo-hwmods associated with hardreset lines · f2f5736c
      由 Paul Walmsley 提交于 
      Remove the pseudo-hwmods associated with hardreset lines from the
OMAP4 data file.  Future patches will convert this data to register
hwmods by interfaces, rather than registering hwmods directly.  The
pseudo-hwmods aren't associated with any interfaces, so this will
create a problem.

After this change, the hwmod code will reset processor IPs at the
hwmod level, rather than by individual hardreset lines.  So, for
example, if the IVA device driver code wishes to place one of the
sequencer cores into reset, while leaving the other active, it must do
so itself by calling the appropriate PRM functions.

This patch will cause a change in the initialization behavior of the
DSP, IVA, and IPU.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      f2f5736c
  5. 13 4月, 2012 1 次提交
    • F
      ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data · d99de7f5
      由 Fernando Guzman Lugo 提交于 
      Due to HW limitation, some IPs should not be accessed just after a
softreset. Since the current hwmod sequence is accessing the sysconfig
register just after the reset, it might lead to OCP bus error in
that case.

Add a new field in the sysconfig structure to specify a delay in usecs
needed after doing a softreset.

In the case of the ISS and FDIF modules, the L3 OCP port will be
disconnected upon a SW reset. That issue was confirmed with HW simulation
and an errata should be available soon. The HW recommendation to avoid
that is to wait for 100 OCP clk cycles, before accessing the IP.

Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
so a 1 usec delay is needed. Add an x2 margin to be safe.
Acked-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
 yet upstream; the FDIF change will need to be added later once the FDIF
 data is merged]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d99de7f5
  7. 04 4月, 2012 1 次提交
  9. 06 3月, 2012 2 次提交
  11. 26 1月, 2012 1 次提交
  13. 16 12月, 2011 2 次提交
  15. 08 11月, 2011 5 次提交
    • 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
    • T
      ARM: OMAP4: HWMOD: fix DSS clock data · 4d0698d9
      由 Tomi Valkeinen 提交于 
      The OMAP4 HWMOD data currently contains errors with DSS clocks:

dss_hdmi and dss_venc have their main_clks wrong. The clocks should be
dss_48mhz_clk and dss_tv_clk, respectively.

These problems were temporarily fixed with the DSS patches
9ede365a ("HACK: OMAP: DSS2: clk hack
for OMAP2/3"), and df5d3ed2 ("OMAP:
DSS2: HDMI: fix hdmi clock name"), which can be reverted after this
patch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d0698d9
    • T
      ARM: OMAP4: HWMOD: Add HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core · 37ad0855
      由 Tomi Valkeinen 提交于 
      DSS needs all DSS clocks to be enabled to be able to finish reset
properly. Before v3.1-rc1 the omapdss driver was managing clocks and
resets correctly. However, when omapdss started using runtime PM at
v3.1-rc1, the responsibility for the reset moved to HWMOD framework.

HWMOD framework does not currently enable all the DSS clocks when
resetting the DSS hardware. This causes the HWMOD frameworks boot-time
reset to fail, possibly leaving the DSS hardware in undefined state.

This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core. The flag
is actually not used on OMAP4, because dss_core hardware does not have
soft-reset functionality and thus the HWMOD framework never resets nor
waits for the reset to finish.

However, while the flag is not strictly needed currently, I think it
represents the HW correctly: all the DSS clocks should be enabled after
power-on to allow DSS hardware to finish its reset.

A custom reset function will be added in the following patches which
manages this correctly for OMAP4.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      37ad0855
    • T
      ARM: OMAP4: HWMOD: remove extra clocks · 4247878e
      由 Tomi Valkeinen 提交于 
      Remove the dss_dss_clk from dss_core's opt-clocks. dss_dss_clk already
defined as the dss main_clk, and thus is not needed as an opt-clock.

Remove opt-clocks for dss_dispc, as dispc only uses the main_clk.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4247878e
  17. 22 9月, 2011 2 次提交
  19. 15 9月, 2011 1 次提交
    • P
      OMAP2+: hwmod: remove OMAP_CHIP* · d6504acd
      由 Paul Walmsley 提交于 
      At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.

Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
AM3517/3505 support, and for other review comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>
      d6504acd
  21. 10 7月, 2011 5 次提交
    • B
      OMAP4: hwmod data: Add modulemode entry in omap_hwmod structure · 03fdefe5
      由 Benoit Cousson 提交于 
      Add a new field to provide the mode supported by the module.
The mode will control the way mandatory clocks are managed by the PRCM.

  0 : Module is temporarily disabled by SW. OCP access to module are stalled.
      Can be used to change timing parameter of GPMC module.
  1 : Module is managed automatically by HW according to clock domain
      transition. A clock domain sleep transition put module into idle.
      A wakeup domain transition put it back into function.
      If CLKTRCTRL=3, any OCP access to module is always granted.
      Module clocks may be gated according to the clock domain state.
  2 : Module is explicitly enabled. Interface clock (if not used for
      functions) may be gated according to the clock domain state.
      Functional clocks are guarantied to stay present. As long as
      in this configuration, power domain sleep transition cannot happen.

Some modules will have a modulemode initialized at 1 (HWCTRL) by default.
This is the case for interconnect and simple module like GPIO, WDT, MAILBOX.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      03fdefe5
    • B
      OMAP4: hwmod data: Add PRM context register offset · 27bb00b5
      由 Benoit Cousson 提交于 
      Add a 'context_offs' entry in the prcm.omap4 structure to all
IPs when applicable.
The offset will be used to retrieve the per module context lost
information now available on OMAP4.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      27bb00b5
    • B
      OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros · eaac329d
      由 Benoit Cousson 提交于 
      The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of an offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update prm_xxx accessors, move definition to the proper header file and
update copyrights.
Change the s16 register offset parameter to u16.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: use '_prminst_' in function names that are part of the
 prminst44xx.c file]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      eaac329d
    • B
      OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros · d0f0631d
      由 Benoit Cousson 提交于 
      The CLKCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of a offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update cm_xxx accessor, move definition to the proper header file and
update copyrights.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Todd Poynor <toddpoynor@google.com>
[paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; removed empty
 fn prototype section from cm44xx.h; incorporated comments from Todd;
 documented some functions]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d0f0631d
    • B
      OMAP4: hwmod data: Add clock domain attribute · a5322c6f
      由 Benoit Cousson 提交于 
      In OMAP PRCM terminology, the clock domain is defined as a group of IPs
that share some clocks and most of the time an interface clock.
Every IP does belong to a clockdomain.
For the moment the clock domain attribute is affected to a clock node.
The issue with that approach, is that a clock might or not belong to a
clock domain. Moreover during module transition, it is up to a module
to handle properly the clock domain state and not to a clock node.

Create a clkdm_name attribute to provide this information per hwmod.

Populate this attribute for every OMAP4 hwmod entries.

Future cleanup series with remove that information from the OMAP4 clock
when it is relevant.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: fix the mpuss_clkdm name]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a5322c6f