Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 4月, 2012 1 次提交
  3. 19 4月, 2012 5 次提交
    • P
      ARM: OMAP: hwmod: remove code support for direct hwmod registration · 11cd4b94
      由 Paul Walmsley 提交于 
      Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      11cd4b94
    • P
      ARM: OMAP2+: hwmod: add support for link registration · 2221b5cd
      由 Paul Walmsley 提交于 
      Add support for direct IP block interconnect ("link") registration to
the hwmod code via a new function, omap_hwmod_register_links().  This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().

This change will allow a subsequent patch to remove the hwmod data
link arrays.  This will reduce the size of the hwmod static data and
also make it easier to generate the data files.  It will also make it
possible to share some of the struct omap_hwmod records across
multiple SoCs, since the link array pointers will be removed from the
struct omap_hwmod.

The downside is that boot time will increase.  Minimizing boot time
was the reason why the link arrays were originally introduced.
Removing them will require extra computation during boot to allocate
memory and associate IP blocks with their interconnects.  However,
since the current kernel development focus is on reducing the number
of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
considered a lower priority.

This patch contains additional complexity to reduce the number of
memory allocations required for this change.  This reduces the boot
time impact: total hwmod link registration time was ~ 2655
microseconds with a simple allocation strategy, but is now ~ 549
microseconds[1] with the approach taken by this patch.

1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
   of 7 samples.  Total uncertainty is +/- 61 microseconds.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      2221b5cd
    • P
      ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits · 515237d6
      由 Paul Walmsley 提交于 
      Extend the OCP_* register offsets in the struct
omap_hwmod_class_sysconfig to 32 bits.  This is required to add the
OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
bits.

Another possible solution may be to simply add a single 16 bit offset
field in this structure, and to add code to factor that offset into
all OCP_* register accesses.  This would save some memory, since
almost no modules need 32 bit offsets.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      515237d6
    • 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: OMAP2+: hwmod: add omap_hwmod_get_resource_byname() · 5e8370f1
      由 Paul Walmsley 提交于 
      The timer integration code pokes around in hwmod data structures.
Those data structures are about to change.  Define a function,
omap_hwmod_get_resource_byname(), for the timer integration code to
use instead.

The original patch has been changed to use struct resource by Tony's
request, although the caller of this function should not be a driver._
Platform drivers should get their data through the regular platform_*
functions; DT drivers through the appropriate of_* functions.  This a
function is only for use by OMAP core code in arch/arm/*omap*.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
      5e8370f1
  5. 15 4月, 2012 1 次提交
  7. 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
  9. 05 4月, 2012 1 次提交
  11. 29 3月, 2012 1 次提交
  13. 28 3月, 2012 1 次提交
  15. 17 3月, 2012 1 次提交
  17. 14 3月, 2012 1 次提交
  19. 12 3月, 2012 5 次提交
  21. 07 3月, 2012 1 次提交
  23. 06 3月, 2012 7 次提交
  25. 29 2月, 2012 1 次提交
    • C
      ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts · 5a3ff847
      由 Cousson, Benoit 提交于 
      The following commit: 2f31b516
Author: Tero Kristo <t-kristo@ti.com>
Date:   Fri Dec 16 14:37:00 2011 -0700

    ARM: OMAP4: PRM: use PRCM interrupt handler

introduced the PRCM interrupt handler and thus the need
for 64 more interrupts. Since SPARSE_IRQ is still not fully
functional on OMAP, the NR_IRQS needs to be updated to avoid
the failure that happen during irq_alloc_descs call inside
the PRCM driver:

[    0.208221] PRCM: failed to allocate irq descs: -12

Later the mux framework is then unable to request an IRQ from
the PRCM interrupt handler.

[    1.802795] mux: Failed to setup hwmod io irq -22

Fix that by adding 64 more interrupts for OMAP2PLUS config.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      5a3ff847
  27. 25 2月, 2012 7 次提交
  29. 23 2月, 2012 3 次提交
  31. 22 2月, 2012 2 次提交
  33. 21 2月, 2012 1 次提交
    • O
      ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register} · 993e4fbd
      由 Ohad Ben-Cohen 提交于 
      Expose omap_device_{alloc, delete, register} so we can use them outside
of omap_device.c.

This approach allows users, which need to manipulate an archdata member
of a device before it is registered, to do so. This is also useful
for users who have their devices created very early so they can be used
at ->reserve() time to reserve CMA memory.

The immediate use case for this is to set the private iommu archdata
member, which binds a device to its associated iommu controller.
This way, generic code will be able to attach omap devices to their
iommus, without calling any omap-specific API.

With this in hand, we can further clean the existing mainline OMAP iommu
driver and its mainline users, and focus on generic IOMMU approaches
for future users (rpmsg/remoteproc and the upcoming generic DMA API).

This patch is still considered an interim solution until DT fully materializes
for omap; at that point, this functionality will be removed as DT will
take care of creating the devices and configuring them correctly.

Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any
omap-specific IOMMU API anymore.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      993e4fbd